我的IntentService会被警报或活动从2个地方触发,因为持续时间与从网络上获取所需的数据量相关,据我所知,我需要保留部分唤醒锁
这是我的实施:
@Override
protected void onHandleIntent(Intent intent) {
PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
WakeLock wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "WakeLock");
try {
wakeLock.setReferenceCounted(false);
wakeLock.acquire(3600000);
///other code here
}
catch{
}
finally{
if (wakeLock.isHeld()) {
wakeLock.release();
}
}
我的问题是:这项工作是否足够好? finally
是否确保在任何情况下释放唤醒锁?据我所知onHandleIntent
一个接一个地处理意图,所以在同一时间内没有2个意图/ 2个唤醒锁的风险。
稍后编辑:
以两种方式调用IntentService:
来自我的活动,如
startService(new Intent(context, MyService.class).putExtra()..);
Alarm
获取2
PendingIntent pendingIntent = PendingIntent.getService(context, someId, myServiceIntent, PendingIntent.FLAG_UPDATE_CURRENT);
从Alarm
跑出来时,服务是否有足够的时间来获取唤醒锁?
答案 0 :(得分:1)
是否需要保持唤醒锁定与Service
所做的工作量无关 - 理论上,即使工作量很小,设备也可以进入睡眠状态。
只有在绝对必须确保设备在Service
运行时无法休眠时,才应考虑唤醒锁定。这种情况非常罕见。一些例子:
大多数应用程序都没有这么严格的时间要求。例如,以下不是使用唤醒锁的好理由:
如果您确实需要确保设备在Service
执行期间不会休眠,那么您需要获取唤醒锁定(几种类型之一)。让我们假设这是这种情况。
你希望能够启动"清醒"来自应用程序用户界面Service
的{{1}},并使用Activity
。
从UI开始
由于设备应完全唤醒以便用户与UI进行交互,因此您可以放心地假设,如果您启动AlarmManager
以响应UI交互,则它将有机会获得唤醒锁定(但是在Service
开始后立即执行。)
您的解决方案涵盖了这种情况。
从Service
不幸的是,无法保证(至少没有文件保证)当AlarmManager
启动AlarmManager
时,它将保持唤醒锁并允许Service
获得自己的唤醒 - 锁。这意味着设备可以在警报触发后进入休眠状态,但在Service
有机会获得唤醒锁之前。
这意味着您的解决方案将会突破"在这种情况下。
唯一记录的方案Service
将帮助您进行唤醒锁定涉及广播:
只要报警,报警管理器就会保持CPU唤醒锁定 接收者的onReceive()方法正在执行。这保证了 在完成广播处理后,手机才会睡眠。 一旦onReceive()返回,Alarm Manager就会释放此唤醒锁定。 这意味着手机在某些情况下会尽快睡觉 onReceive()方法完成。如果你的报警接收器叫 Context.startService(),手机可能会睡眠 在请求的服务启动之前。为了防止这种情况,你的 BroadcastReceiver和Service需要实现单独的唤醒 锁定策略以确保手机继续运行直到 服务变得可用。
这是WakefulBroadcastReceiver非常方便的地方。
请注意,如果您使用此方案,则无需为" UI启动"提供支持。案例 - 在两种情况下都使用相同的方法。
您可能还想看看@CommonsWare开发的this library(我自己没有使用它)。