AlarmManager启动服务时的唤醒锁
Android 的 AlarmManager Javadoc 声明
当闹钟响起时，Intent 它
Android 提供的 API 演示中有一个 AlarmService （包 com.example.android.apis.app）， 在使用。
其中我们有以下内容（为清楚起见进行了编辑）：
PendingIntent mAlarmSender = PendingIntent.getService(AlarmService.this,
0, new Intent(AlarmService.this, AlarmService_Service.class), 0);
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 30*1000, mAlarmSender);
因此，在本示例中，它不执行 PendingIntent mAlarmSender = PendingIntent.getBroadcast(...); 而是执行 getService< /code> Javadoc 从未提及过。
我之所以问这个问题是因为 CPU 唤醒锁的影响。 Javadoc 表示，一旦广播接收器的 onReceive() 返回，AlarmManger 的唤醒锁就会被释放。
我想知道的是，如果您使用示例中的警报，唤醒锁会产生什么影响？ Javadoc 似乎没有解决这个问题。如果有的话，它似乎暗示您在设置警报时必须使用广播技术。
Android's AlarmManager Javadoc states
When an alarm goes off, the Intent that had been registered for it is broadcast by the system,
There is an AlarmService (package com.example.android.apis.app) in the API demos supplied with Android which demonstrate AlarmService in use.
In it we have the following (edited for clarity):
PendingIntent mAlarmSender = PendingIntent.getService(AlarmService.this,
0, new Intent(AlarmService.this, AlarmService_Service.class), 0);
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 30*1000, mAlarmSender);
So in this example it doesn't do a PendingIntent mAlarmSender = PendingIntent.getBroadcast(...); instead it does a getService which the Javadoc never alludes to.
The reason I am asking about this is because of the implications of the CPU wake lock. The Javadoc says that the AlarmManger's wake lock will be released once a Broadcast receiver's onReceive() returns.
What I am wondering is what are the wake lock implications if you use an Alarm like in the example? The Javadoc doesn't seem to address this. If anything it seems to imply that you must use the broadcast technique when setting alarms.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
无法保证您的服务将在设备进入睡眠状态之前获得控制权。
对于
_WAKEUP警报，是的，因为这是保证我们在设备仍处于唤醒状态时获得控制的唯一途径。由于
_WAKEUP警报要完成的工作通常超出了您在清单注册的BroadcastReceiveronReceive()中可以安全执行的范围code>，一种常见的模式是将工作委托给IntentService。为此，我打包了WakefulIntentService来实现该模式用于安全地将控制权传递给IntentService并保持设备唤醒足够长的时间以使服务能够完成其工作。There are no guarantees that your service will get control before the device falls asleep.
For
_WAKEUPalarms, yes, as that is the only path in which we are guaranteed to get control while the device is still awake.Since the work to be done by the
_WAKEUPalarm is typically beyond the scope of what you can safely do inonReceive()of a manifest-registeredBroadcastReceiver, a common pattern is to delegate the work to anIntentService. To that end, I have packaged upWakefulIntentService, to implement the pattern for safely passing control to anIntentServiceand keeping the device awake long enough for the service to do its work.