该应用程序需要一个底层功能,可以获取位置并将它们发送到服务器.这必须定期发生(大约每1-5分钟),但最重要的是它必须始终发生,永不停止,防止操作系统关闭进程以回收内存,以及应用程序本身未运行时.
我已经向我建议了以下解决方案.我熟悉处理Android位置,这里的问题是确保它们继续,即使应用程序不在内存中,并通过内存回收持续存在.
服务.使用服务收集位置事件并处理它们.使用boot和screen-on广播来确保服务始终在运行(并且还可能提高服务优先级以防止内存回收).
警报.我收集这些可以在内存短暂时关闭.我该如何防范呢？这似乎是一个丑陋的解决方案,因为位置无论如何都会按计划到达,因此似乎没有必要再使用其他基于时间的组件.
通过广播的位置.通过广播意图传送的位置意味着我可以在广播接收器中处理位置事件.这些位置警报会无限期地继续吗？除设备关闭或应用程序关闭以外的任何其他设备会导致它们停止吗？
什么是最耐用的方法？
Com*_*are 11
这必须定期发生(大约每1-5分钟),但最重要的是它必须始终发生,永不停止,防止操作系统关闭进程以回收内存,以及应用程序本身未运行时.
在各种方面,这不是严格可行的.
我们一次拿一件:
这必须定期发生(大约每1-5分钟)
您可能无法获得地点,期间,更不用说每1-5分钟一次.用户可能已禁用所有位置提供程序.用户可能将设备置于飞行模式.用户可能位于连接较差的大型建筑物(阻挡GPS)中(使网络提供商不可靠).
从不停止
用户可以通过"设置"或任务杀手中的"管理服务"屏幕随时清除您.如果他们这样做,特别是在Android 3.1+上,您的应用程序将永远不会以任何理由再次运行,直到用户启动您的活动(例如,通过启动器).当然,用户也可以卸载您的应用程序.
防止操作系统关闭进程以回收内存
你不能保证不会这样.你可以降低几率,但就是这样.
现在,让我们来看看你的各种解决方案:
使用服务收集位置事件并处理它们.
从你说出这个(和后续句子)的方式来看,你指的是一个永恒的服务,一个旨在全天候运行的服务.根据定义,这意味着您的应用正在运行,这违反了您的一条规则.假设你放松了这个规则,这个解决方案大大增加了用户摆脱你的服务的几率,并增加了Android摆脱你的服务的几率.您可以通过使用最小化后者startForeground().
警报.我收集这些可以在内存短暂时关闭.
不是我知道的.但是,如果用户将您清除,您的警报将被删除.
这似乎是一个丑陋的解决方案,因为无论如何地点都会按计划到达
不,他们不会.时间参数on requestLocationUpdates()并不意味着"位置无论如何都会按计划到达".
通过广播意图传送的位置意味着我可以在广播接收器中处理位置事件.
你不能.您已指出您的部分工作是将此数据发送到服务器.您无法在主应用程序线程上可靠地执行此操作,因为它可能需要很长时间.A getService() PendingIntent,指向一个IntentService会更可靠.
这些位置警报会无限期地继续吗？
不,见下文.
除设备关闭或应用程序关闭以外的任何其他设备会导致它们停止吗？
用户可以摆脱您的应用程序(卸载,任务杀手,管理服务).用户可以禁用位置提供程序.用户可以进入无法确定位置的区域.等等.
此外,该设备可能睡着了,AFAIK.系统可能会在WakeLock您注册的更新请求期间保留一个.甚至可能系统将在AlarmManager内部使用以安排在您提供的时间段内唤醒自己,因此它不必持续唤醒设备.但是,您需要彻底测试.
什么是最耐用的方法？
如果操作系统处理我上一段中的问题,那么您的第三个选项可能是最强大的.在退出之前使用startForeground()你的IntentService()电话- 即使是短暂的服务也可能因内存不足而被杀掉,这让我大吃一惊.stopForeground()onHandleIntent()AlarmManager
话虽如此,您所期望的行为似乎可能比用户可能需要的电池寿命更长.请允许用户控制轮询周期,包括"从不轮询,我会手动更新"的选项.
| 归档时间： |
|
| 查看次数： |
3550 次 |
| 最近记录： |