最近我开始为Tizen OS开发。我的应用程序仅针对可穿戴设备创建,仅适用于Samsung Gear Sport(Tizen 3.0 on board)的特定设备。该应用程序的主要目的是在很长一段时间内收集完整的传感器数据。我对心率和运动传感器(陀螺仪和加速度计)感兴趣。然后,这些数据将被发送到云服务器并进行分析。目前我正在考虑使用WEB应用程序,因为到目前为止,我没有发现WEB API缺少本机API中存在的内容。
但Tizen OS有一个限制,到目前为止我无法克服。我的应用程序在一段时间后(大约10分钟左右)进入睡眠状态。这个应用程序应该在后台工作很长时间(最多10个小时)至关重要。为实现这一目标,我尝试了以下方法:
PRESSURE
传感器。 Tizen允许开始录制HRM
,但在NotFoundError: Failed to read recorded data
之后没有录制任何内容。任何其他传感器都会提供TypeMismatchError
。关于电池:以上都没有将电池耗尽到不可接受的程度。首先,我想找到一个解决方案,它能够为我提供所需的所有传感器数据,并且至少需要10个小时,并且没有任何漏洞。之后,如果事实证明这个解决方案耗尽了太多电池,我会考虑如何优化它。
现在的问题是:是否可以让我的应用程序保持活动状态超过10个小时?
答案 0 :(得分:2)
我花了数周的时间试图找到解决该问题的方法。我最接近的不间断工作应用程序是创建包含以下内容的多包应用程序(也称为混合应用程序):
所有应用都针对Tizen API 2.3.1。这是至关重要的部分,因为3.0 API存在多个问题,例如操作系统意外杀死应用程序或出现“电池使用过多”提示,有时还会导致我的应用程序被杀死。 Tizen OS的有趣之处在于,当由于过多的资源使用而终止了表盘应用程序时,手表的主屏幕仅为纯黑色。不幸的是,针对API 2.3.1导致无法使用此版本之后添加的多个API。
我接下来使用的是所有本机服务应用程序中的device_power_request_lock(POWER_LOCK_CPU, 0);
。我相信使用较旧的API(2.3.1而不是3.0)可以使应用程序工作更长的时间,而不会被系统杀死。我认为这是我利用的Tizen OS版本中的一个缺陷。
在WEB应用程序中,我使用了ScreenStateChangeListener
和timetick事件来检查服务应用程序是否正在运行。如果不是->它是由WEB应用程序启动的。为了在服务和表盘之间进行通信,我使用了偏好监听器API。表盘WEB应用程序负责检查哪些服务正在运行以及什么服务需要唤醒或启动。
最后,我最终使用了与WEB应用程序打包在一起的4个本机服务应用程序。每个服务应用程序都有自己的用途,例如文件系统,网络,监视等。多线程服务应用程序确实很难维护,并且经常由于未知原因而崩溃。
答案 1 :(得分:0)
如果您定位本机Service App API 3.0,请获取以下内容:
device_power_request_lock(POWER_LOCK_CPU, 0);
sensor_listener_set_option(listener, SENSOR_OPTION_ALWAYS_ON);
sensor_listener_set_attribute_int(listener, SENSOR_ATTRIBUTE_PAUSE_POLICY, SENSOR_PAUSE_NONE);
并且不要忘记在Manifest中设置背景类别(传感器+位置,如果需要),因为否则Tizen会在~10分钟后杀死你的应用程序。
当然,几乎所有这些都没有得到妥善记录......