是否有可能保持Tizen应用程序不间断运行 [英] Is it possible to keep Tizen application alive non stop

问题描述

最近我已经开始为Tizen OS开发.我的应用程序仅适用于可穿戴设备，并且仅适用于Samsung Gear Sport(板载Tizen 3.0)的特定设备.该应用程序的主要目的是长时间收集完整的传感器数据.我对心率和一般的运动传感器(陀螺仪和加速度计)感兴趣.然后，该数据将被发送到云服务器并进行分析.目前，我正在考虑使用WEB应用程序，因为到目前为止，我还没有发现证据表明WEB API缺少本机API中存在的某些东西.

recently I’ve started developing for Tizen OS. My application is created only for wearable and only for specific device which is Samsung Gear Sport (Tizen 3.0 on board). Main purpose of this application is to gather complete sensor data over a long period of time. I’m interested in heart rate, and movement sensors in general (gyroscope and accelerometer). Then, this data will be send to cloud server and analysed. Currently I’m considering a WEB application because so far I have found no evidence that WEB API is missing something that exists in native API.

但是Tizen OS有一个限制，到目前为止，我还无法克服.我的应用程序在一段时间(约10分钟)后进入睡眠状态.至关重要的是，此应用程序应在后台长时间(最多10个小时)运行.为此，我尝试了以下方法:

But there is one limitation in Tizen OS that so far I am unable to overcome. My application is put to sleep after a while (10 minutes or so). It is crucial that this app should work in the background for a long time (up to 10 hours). To achieve this, I’ve tried following approaches:

• 具有背景类别的普通Tizen应用程序:此方法提供的数据仍然过于零散，例如，我有15分钟的空缺时间，根本没有记录任何数据.有时甚至有超过30分钟的空洞.
• Tizen警报API:在保持应用程序存活的情况下完成了警报工作，但是每次发出警报时，应用程序都被置于最前端，这不是可接受的解决方案.有一个选项(使用应用程序控件)以静默方式唤醒应用程序，但它没有任何回调，因此所有警报都必须预先安排.
• CPU_AWAKE标志使系统显示此应用程序消耗了过多的能量"弹出窗口，并且在10分钟左右未响应时，系统仍然会杀死我的应用程序.
• Web Workers -这只是出于争论的目的，Web Workers与应用程序一起进入睡眠状态
• 数据记录:我希望获得类似于Apple Health Kit的功能，但是却得到了一些根本不适用于HRM的功能.它以某种方式适用于PRESSURE传感器. Tizen允许开始HRM的记录，但是-NotFoundError: Failed to read recorded data之后没有任何记录.任何其他传感器给出TypeMismatchError.
• Web服务应用程序-该应用程序需要获得三星的合作伙伴级认证，并且受背景限制

• Normal Tizen app with background-category: data given by this approach is still too fragmented, for example I got 15 minutes holes where no data was recorded at all. Sometimes there were holes even longer than 30 minutes.
• Tizen alarms API: alarms did the job in case of keeping the app alive, but with every alarm, app was brought to the front and this is not an acceptable solution. There is an option to silently wake up the app (using app control), but it does not have any callback, so all alarms would have to be scheduled upfront.
• CPU_AWAKE flag made the system show "this app is using too much energy" popup, and when not answered within 10 minutes or so, system would kill my app nonetheless.
• Web Workers - this one is only for the sake of argument, web workers are put to sleep along with the application
• Data recording: I was hoping for something similar to Apple Health Kit, but instead I got something that is not working for HRM at all. Somehow it works for PRESSURE sensor. Tizen allows to start recording for HRM but nothing is recorded after - NotFoundError: Failed to read recorded data. Any other sensor gives TypeMismatchError.
• Web Service app - this one requires partner-level certification with Samsung, also it’s affected by the background limitations, as the documentation mentions.
• Watch Face approach with "keep always on" flag set to true in device settings. This solution was the best I’ve tried. Watch face app wakes up every minute to change the time and it also receives sensor data. Unfortunately after more testing it turned out that there were couple holes in the data recorded.

关于电池:以上所有内容均未将电池耗尽到无法接受的程度.因此，首先，我想找到一种解决方案，该解决方案将在至少10个小时内尽可能频繁地为我提供所需的所有传感器数据，并且不会出现任何漏洞.然后，如果事实证明该解决方案消耗了过多的电池，我将考虑如何对其进行优化.

About the battery: none of the above was draining the battery to a point where it became unacceptable. So first I’d like to find a solution that will give me all the sensor data I need, as frequently as possible from at least 10 hours, with no holes in it. And after that, if it turns out that this solution is draining too much battery, I will think about how to optimize it.

现在的问题是:是否可以使我的应用程序不间断运行10多个小时?

推荐答案

我花了很多周的时间来寻找解决此问题的方法.我最接近的始终不停止工作应用程序是创建包含以下内容的多包应用程序(也称为混合应用程序):

I've spend many weeks trying to find the solution to this problem. The closest I got to the all time non stop working application was to create multi package application (also called a hybrid app) that consisted of:

• 用JS编写的WEB应用程序，它是一个表面应用程序
• 用C编写的本地服务应用程序(无UI)

所有应用都针对Tizen API 2.3.1.这是至关重要的部分，因为3.0 API存在多个问题，例如操作系统意外杀死应用程序或出现电池使用过多"提示，有时还会导致我的应用程序被杀死. Tizen OS的有趣之处在于，当由于过多的资源使用而终止了表盘应用程序时，手表的主屏幕仅为纯黑色.不幸的是，定位API 2.3.1导致无法使用此版本之后添加的多个API.

All apps were targeting Tizen API 2.3.1. This is the crucial part because there were multiple problems with 3.0 API like unexpected application kills by the OS or "too much battery usage" prompts that sometimes also resulted in killing my app. Funny thing about the Tizen OS is that when it kills the watch face app due to too much resource usage, the main screen of the watch is just plain black. Unfortunately targeting API 2.3.1 resulted in not being able to use multiple APIs added after this version.

我接下来使用的是所有本机服务应用程序中的device_power_request_lock(POWER_LOCK_CPU, 0);.我相信使用较旧的API(2.3.1而不是3.0)可以使应用程序工作更长的时间，而不会被系统杀死.我认为这是我利用的这个Tizen OS版本中的一个缺陷.

Next thing I've used was device_power_request_lock(POWER_LOCK_CPU, 0); in all the native service apps. I believe that using the older API (2.3.1 instead of 3.0) allowed the application to work much longer without being killed by the system. I think that this is a flaw in this Tizen OS version that I've leveraged.

在WEB应用程序中，我使用了ScreenStateChangeListener和timetick事件来检查服务应用程序是否正在运行.如果不是->它是由WEB应用程序启动的.为了在服务和表盘之间进行通信，我使用了偏好监听器API.表盘WEB应用程序负责检查哪些服务正在运行以及什么服务需要唤醒或启动.

In the WEB app I've used ScreenStateChangeListener and timetick events to check if the service app is running. If not -> it was started by the WEB application. For communication between service and the watch face I've used preferences listener API. Watch face WEB app was responsible for checking what service is working and what service needs to be woken up or started.

最后，我最终使用了与WEB应用程序打包在一起的4个本机服务应用程序.每个服务应用程序都有自己的用途，例如文件系统，网络，监视等.多线程服务应用程序确实很难维护，并且经常由于未知原因而崩溃.

In the end I've ended up using 4 native service applications packaged together with the WEB app. Each service app had its own purpose like filesystem, network, monitoring, etc. Multithreaded service apps were really hard to maintain and often crashed for unknown reason.

这篇关于是否有可能保持Tizen应用程序不间断运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！