嵌入式设备上下文中的前台传感器服务答案

【问题标题】：Foreground sensor service in an embedded device context嵌入式设备上下文中的前台传感器服务
【发布时间】：2014-03-12 20:16:23
【问题描述】：

问题：
嵌入式环境中持久/始终在线的传感器数据收集服务的最佳实践是什么？永久连接的电源，没有用户因其他正在运行的服务而恶化，因此没有电池寿命或可用性问题。

计划：
一个本地的Service，startForeground()，START_STICKY，可能会获得一个PARTIAL_WAKE_LOCK，从BOOT_COMPLETED开始。这将不是 Play 商店应用程序。我将有一个可以绑定到服务的活动，以获取反馈、设置首选项，并在需要时手动启动/停止服务。由于这将在没有 UI 的专用设备上运行并且不依赖电池电量，这应该绕过服务的大多数常见问题，我可以/应该做些什么来确保服务以高优先级运行它被杀死的可能性最小？有没有比以这种方式实现的服务更好的选择？

背景（可选阅读）：
我编写了一个基于多线程 Activity 的应用程序，它在启动完成时通过广播接收器启动，运行验证，运行数据收集线程，连接到远程服务的数据传输线程，并执行其他任务t 与本次讨论有关。我需要过渡到基于服务的解决方案。根据我的阅读，收集传感器数据的服务的最佳实践通常涉及通过AlarmManager 定期启动服务。这在我的情况下不起作用。

【问题讨论】：

好问题！我建议稍微提炼一下，如果人们不必阅读太多，他们会更愿意回答。
感谢您的建议！我尽可能地蒸馏
你把传感器控制器放在哪里了？如果服务只是为了保持应用程序运行，那么控制器可以是单例，或者由 Application 类中的某个对象持有，对吧？

标签： android service

【解决方案1】：

一般来说，Service 接收传感器数据没有问题。但是，请确保您在后台线程上而不是在 SensorListener 回调中处理任何数据。如果您需要在屏幕关闭时继续接收数据，则需要保持部分唤醒锁以防止系统进入较低的电源状态。电池寿命受“前台”服务的影响只是因为您让传感器在某个时间间隔处于激活状态。否则，将服务视为前台并没有什么神奇之处，只是它被框架杀死的可能性非常低。

您可能还需要确保传感器的准确性不会改变（通过侦听器回调），如果它与您的算法期望的不同，则必须使用 SensorManager 重新配置它.基于Activity 的解决方案不会真正实现您所说的，因为Activity 仅在用户可见时才“运行”。

【讨论】：

谢谢，我没有考虑过。我认为SensorListener 已被弃用，但我在当前的活动中使用SensorEventListener。您认为这会成为服务中的问题吗？我认为您的意思是，例如，在onSensorChanged() 或onLocationChanged() 中填充实例变量，然后让另一个线程读取并处理这些值？
抱歉，我指的是SensorEventListener，而不是SensorListener。在服务中使用没有问题，您只需要适当地管理您的服务，使其长时间运行并且可以在需要时适当地保持设备唤醒（即保持唤醒锁定）。最好在另一个线程中处理数据，但这可能很简单，例如将引用 SensorEvent 数据的 Runnable 发布到绑定到另一个线程的 Handler。
OP 或@LarrySchiefer，你们能告诉我如何在服务中调用 getSystemService() 吗？如果我想这样做，由于基础上下文为空，我必须放入启动服务的活动的 Conext，而不是正在运行的服务本身。如果您不确定我在问什么，这是完全解释的问题：stackoverflow.com/questions/24970677/…，非常感谢您的帮助。
您可以毫无问题地从您的Service 拨打getSystemService()。您服务扩展的Service 对象也派生自Context 对象。您不需要（也不想使用）Activity 上下文。另一个问题看起来好像提出问题的人是手动创建服务，而不是使用startService() 或bindService()。您必须从这些框架调用开始，否则您的服务将无法正确初始化并完成其生命周期。