handler.postDelayed与AlarmManager VS [英] handler.postDelayed vs. AlarmManager vs
问题描述
我在我的应用程序一个小问题。它采用了的BroadcastReceiver 来检测呼叫完成，然后进行一些小的日常任务。这些都被延迟了几秒，以允许用户看到一些数据，并确保通话记录已经被更新。我目前使用 handler.postDelayed（）为了这个目的：
公共类CallEndReceiver扩展的BroadcastReceiver {
@覆盖
公共无效的onReceive（最终上下文的背景下，最终的意图意图）{
如果（DebugFlags.LOG_OUTGOING）
Log.v（CallState改为
+ intent.getStringExtra（TelephonyManager.EXTRA_STATE））;
如果（intent.getStringExtra（TelephonyManager.EXTRA_STATE）
.equalsIgnoreCase（TelephonyManager.EXTRA_STATE_IDLE））{
共享preferences preFS = Utils.get preferences（上下文）;
如果（prefs.getBoolean（auto_cancel_notification，真））{
如果（DebugFlags.LOG_OUTGOING）
Log.v（张贴处理程序删除通知）;
最终的处理程序mHandler =新的处理程序（）;
最终的可运行mCancelNotification =新的Runnable（）{
公共无效的run（）{
NotificationManager notificationMgr =（NotificationManager）上下文
.getSystemService（Service.NOTIFICATION_SERVICE）;
notificationMgr.cancel（12443）;
如果（DebugFlags.LOG_OUTGOING）
Log.v（删除通知）;
}
};
mHandler.postDelayed（mCancelNotification，4000）;
}
最终的处理程序updateHandler =新的处理程序（）;
最终的可运行mUpdate =新的Runnable（）{
公共无效的run（）{
如果（DebugFlags.LOG_OUTGOING）
Log.v（启动updateService）;
意图newBackgroundService =新的意图（背景下，
CallLogUpdateService.class）;
context.startService（newBackgroundService）;
}
};
updateHandler.postDelayed（mUpdate，5000）;
如果（DebugFlags.TRACE_OUTGOING）
Debug.stopMethodTracing（）;
尝试
{
//停止老服务
意图backgroundService =新的意图（背景下，
NetworkCheckService.class）;
context.stopService（backgroundService）;
context.unregisterReceiver（本）;
}
赶上（例外五）
{
Log.e（Fehler BEIM Entfernen DES接收器，E）;
}
}
}
}
现在我有问题，那这种设置工作约90％的时间。在约10％的情况下，通知不会被删除。我怀疑，该线程死亡的消息队列处理消息/可运行。
在我现在想的替代品 postDelayed（）和我的选择之一显然是AlarmManager。不过，我不知道对性能的影响（或者它使用的资源）。
也许有更好的方法，以确保所有邮件已处理一个线程死亡或另一种方式来延缓code这两个位执行之前。
感谢您
我目前使用handler.postDelayed（）用于此目的：
这是不是一个好主意，假设的BroadcastReceiver 是由在清单中的过滤器被触发。
现在我有问题，那这种设置工作约90％的时间。在约10％的情况下，通知不会被删除。我怀疑，该线程死亡的消息队列处理消息/可运行。
在
更准确地说，处理终止，同时一切与它
我现在想替代postDelayed（）和我的选择之一显然是AlarmManager。不过，我不知道对性能的影响（或者它使用的资源）。
这并不坏。另一种可能性是做你的工作延误在 IntentService - 通过调用触发 startService（） - 和有它睡在它的后台线程的几秒钟。
I have a minor problem in one of my apps. It uses a BroadCastReceiver to detect when a call finishes and then performs some minor housekeeping tasks. These have to be delayed for a few seconds, to allow the user to see some data and to ensure that the call log has been updated. I'm currently using handler.postDelayed() for this purpose:
public class CallEndReceiver extends BroadcastReceiver {
@Override
public void onReceive(final Context context, final Intent intent) {
if (DebugFlags.LOG_OUTGOING)
Log.v("CallState changed "
+ intent.getStringExtra(TelephonyManager.EXTRA_STATE));
if (intent.getStringExtra(TelephonyManager.EXTRA_STATE)
.equalsIgnoreCase(TelephonyManager.EXTRA_STATE_IDLE)) {
SharedPreferences prefs = Utils.getPreferences(context);
if (prefs.getBoolean("auto_cancel_notification", true)) {
if (DebugFlags.LOG_OUTGOING)
Log.v("Posting Handler to remove Notification ");
final Handler mHandler = new Handler();
final Runnable mCancelNotification = new Runnable() {
public void run() {
NotificationManager notificationMgr = (NotificationManager) context
.getSystemService(Service.NOTIFICATION_SERVICE);
notificationMgr.cancel(12443);
if (DebugFlags.LOG_OUTGOING)
Log.v("Removing Notification ");
}
};
mHandler.postDelayed(mCancelNotification, 4000);
}
final Handler updateHandler = new Handler();
final Runnable mUpdate = new Runnable() {
public void run() {
if (DebugFlags.LOG_OUTGOING)
Log.v("Starting updateService");
Intent newBackgroundService = new Intent(context,
CallLogUpdateService.class);
context.startService(newBackgroundService);
}
};
updateHandler.postDelayed(mUpdate, 5000);
if (DebugFlags.TRACE_OUTGOING)
Debug.stopMethodTracing();
try
{
// Stopping old Service
Intent backgroundService = new Intent(context,
NetworkCheckService.class);
context.stopService(backgroundService);
context.unregisterReceiver(this);
}
catch(Exception e)
{
Log.e("Fehler beim Entfernen des Receivers", e);
}
}
}
}
Now I have the problem, that this setup works about 90% of the time. In about 10% of cases, the notification isn't removed. I suspect, that the thread dies before the message queue processes the message/runnable.
I'm now thinking about alternatives to postDelayed() and one of my choices is obviously the AlarmManager. However, I'm not sure about the performance impact (or the resources it uses).
Maybe there is a better way to ensure that all messages have been processed before a thread dies or another way to delay the execution of those two bits of code.
Thank you
I'm currently using handler.postDelayed() for this purpose:
That's not a good idea, assuming the BroadcastReceiver is being triggered by a filter in the manifest.
Now I have the problem, that this setup works about 90% of the time. In about 10% of cases, the notification isn't removed. I suspect, that the thread dies before the message queue processes the message/runnable.
More accurately, the process is terminated, taking everything with it.
I'm now thinking about alternatives to postDelayed() and one of my choices is obviously the AlarmManager. However, I'm not sure about the performance impact (or the resources it uses).
It's not that bad. Another possibility is to do your delayed work in an IntentService -- triggered via a call to startService() -- and have it sleep on its background thread for a couple of seconds.
这篇关于handler.postDelayed与AlarmManager VS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
