是否有可能让 Tizen 应用程序不间断地保持活动状态
Is it possible to keep Tizen application alive non stop
最近我开始为 Tizen OS 开发。我的应用程序仅为可穿戴设备创建，并且仅为特定设备创建，即 Samsung Gear Sport（板载 Tizen 3.0）。此应用程序的主要目的是在很长一段时间内收集完整的传感器数据。我对心率和一般运动传感器（陀螺仪和加速度计）感兴趣。然后，这些数据将被发送到云服务器并进行分析。目前我正在考虑一个 WEB 应用程序，因为到目前为止我没有发现 WEB API 缺少原生 API.
中存在的东西的证据
但是 Tizen OS 中有一个限制，到目前为止我无法克服。我的应用程序在一段时间后（10 分钟左右）进入休眠状态。此应用程序应在后台运行很长时间（最多 10 小时），这一点至关重要。为此，我尝试了以下方法：
- 具有背景类别的普通 Tizen 应用程序： 这种方法给出的数据仍然太零散，例如我有 15 分钟的漏洞，根本没有记录任何数据。有时甚至超过 30 分钟。
- Tizen 警报 API: 警报在保持应用程序活动的情况下完成了工作，但每次警报时，应用程序都会被带到前面，而这不是一个可接受的解决方案。有一个静默唤醒应用程序的选项（使用应用程序控制），但它没有任何回调，因此必须提前安排所有警报。
- CPU_AWAKE flag 使系统显示“此应用程序使用过多能量”弹出窗口，如果在 10 分钟左右内未回答，系统将终止我的应用程序 none尽管如此。
- Web Workers - 这个只是为了争论，web workers 和应用程序一起进入休眠状态
- 数据记录： 我希望得到类似于 Apple Health Kit 的东西，但我得到的东西根本不适用于 HRM。它以某种方式适用于
PRESSURE 传感器。 Tizen 允许开始记录 HRM，但在 - NotFoundError: Failed to read recorded data 之后没有任何记录。任何其他传感器给出 TypeMismatchError.
- Web Service app - 这个需要三星的合作伙伴级认证，而且受后台限制影响，as the documentation mentions.
- Watch Face 方法，在设备设置中将“保持始终开启”标志设置为 true。这个解决方案是我试过的最好的。表盘应用程序每分钟唤醒一次以更改时间，它还会接收传感器数据。不幸的是，经过更多测试后发现记录的数据中存在几个漏洞。
关于电池：none 上面的内容将电池耗尽到无法接受的程度。因此，首先我想找到一个解决方案，它能尽可能频繁地提供我需要的所有传感器数据，至少 10 小时，而且没有任何漏洞。之后，如果发现这个解决方案耗电太多，我会考虑如何优化它。
现在的问题是：是否可以让我的应用程序不间断地运行 10 多个小时？
如果您以本机服务应用程序为目标 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);
并且不要忘记在清单中设置背景类别（如果需要，传感器 + 位置），否则 Tizen 会在约 10 分钟后终止您的应用。
当然，几乎没有任何一个被正确记录...
我花了很多周的时间试图找到解决这个问题的方法。我最接近一直不停工作的应用程序是创建多包应用程序（也称为混合应用程序），包括：
- 用JS编写的WEB应用，是一个表盘应用
- 用C语言编写的本地服务应用程序（无UI）
所有应用程序都针对 Tizen API 2.3.1。这是关键部分，因为 3.0 API 存在多个问题，例如 OS 或 "too much battery usage" 提示意外终止应用程序，有时也会导致终止我的应用程序。关于 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 app负责检查哪些服务在工作，哪些服务需要唤醒或启动。
最终我使用了 4 个与 WEB 应用程序打包在一起的本地服务应用程序。每个服务应用程序都有自己的用途，如文件系统、网络、监控等。多线程服务应用程序真的很难维护，而且经常因不明原因崩溃。
最近我开始为 Tizen OS 开发。我的应用程序仅为可穿戴设备创建，并且仅为特定设备创建，即 Samsung Gear Sport（板载 Tizen 3.0）。此应用程序的主要目的是在很长一段时间内收集完整的传感器数据。我对心率和一般运动传感器（陀螺仪和加速度计）感兴趣。然后，这些数据将被发送到云服务器并进行分析。目前我正在考虑一个 WEB 应用程序，因为到目前为止我没有发现 WEB API 缺少原生 API.
中存在的东西的证据但是 Tizen OS 中有一个限制，到目前为止我无法克服。我的应用程序在一段时间后（10 分钟左右）进入休眠状态。此应用程序应在后台运行很长时间（最多 10 小时），这一点至关重要。为此，我尝试了以下方法：
- 具有背景类别的普通 Tizen 应用程序： 这种方法给出的数据仍然太零散，例如我有 15 分钟的漏洞，根本没有记录任何数据。有时甚至超过 30 分钟。
- Tizen 警报 API: 警报在保持应用程序活动的情况下完成了工作，但每次警报时，应用程序都会被带到前面，而这不是一个可接受的解决方案。有一个静默唤醒应用程序的选项（使用应用程序控制），但它没有任何回调，因此必须提前安排所有警报。
- CPU_AWAKE flag 使系统显示“此应用程序使用过多能量”弹出窗口，如果在 10 分钟左右内未回答，系统将终止我的应用程序 none尽管如此。
- Web Workers - 这个只是为了争论，web workers 和应用程序一起进入休眠状态
- 数据记录： 我希望得到类似于 Apple Health Kit 的东西，但我得到的东西根本不适用于 HRM。它以某种方式适用于
PRESSURE传感器。 Tizen 允许开始记录HRM，但在 -NotFoundError: Failed to read recorded data之后没有任何记录。任何其他传感器给出TypeMismatchError. - Web Service app - 这个需要三星的合作伙伴级认证，而且受后台限制影响，as the documentation mentions.
- Watch Face 方法，在设备设置中将“保持始终开启”标志设置为 true。这个解决方案是我试过的最好的。表盘应用程序每分钟唤醒一次以更改时间，它还会接收传感器数据。不幸的是，经过更多测试后发现记录的数据中存在几个漏洞。
关于电池：none 上面的内容将电池耗尽到无法接受的程度。因此，首先我想找到一个解决方案，它能尽可能频繁地提供我需要的所有传感器数据，至少 10 小时，而且没有任何漏洞。之后，如果发现这个解决方案耗电太多，我会考虑如何优化它。
现在的问题是：是否可以让我的应用程序不间断地运行 10 多个小时？
如果您以本机服务应用程序为目标 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);
并且不要忘记在清单中设置背景类别（如果需要，传感器 + 位置），否则 Tizen 会在约 10 分钟后终止您的应用。
当然，几乎没有任何一个被正确记录...
我花了很多周的时间试图找到解决这个问题的方法。我最接近一直不停工作的应用程序是创建多包应用程序（也称为混合应用程序），包括：
- 用JS编写的WEB应用，是一个表盘应用
- 用C语言编写的本地服务应用程序（无UI）
所有应用程序都针对 Tizen API 2.3.1。这是关键部分，因为 3.0 API 存在多个问题，例如 OS 或 "too much battery usage" 提示意外终止应用程序，有时也会导致终止我的应用程序。关于 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 app负责检查哪些服务在工作，哪些服务需要唤醒或启动。
最终我使用了 4 个与 WEB 应用程序打包在一起的本地服务应用程序。每个服务应用程序都有自己的用途，如文件系统、网络、监控等。多线程服务应用程序真的很难维护，而且经常因不明原因崩溃。