转载请注明出处:http://blog.csdn.net/singwhatiwanna/article/details/18448997
前言
本次给大家分析的是Android中Alarm的机制以及它和Binder的交互,所用源码为最新的Android4.4。因为Alarm的功能都是通过Binder来完成的,所以,介绍Alarm之前必须要先介绍下它是如何调用Binder来完成定时功能的。由于内容较多,本文会比较长,在文章结构安排上是这样的:首先简单介绍如何使用Alarm并给出其工作原理,接着分析Alarm和Timer以及Handler在完成定时任务上的差别,然后分析Alarm与Binder的交互,最后分析Alarm机制的源码。
什么是Alarm
Alarm是android提供的用于完成闹钟式定时任务的类,系统通过AlarmManager来管理所有的Alarm,Alarm支持一次性定时任务和循环定时任务,它的使用方式很简单,这里不多做介绍,只给出一个简单的示例:
- AlarmManager alarmMgr = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
- Intent intent = new Intent(getApplicationContext(), TestActivity.class);
- PendingIntent pendIntent = PendingIntent.getActivity(getApplicationContext(),
- 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
- //5秒后发送广播,只发送一次
- int triggerAtTime = SystemClock.elapsedRealtime() + 5 * 1000;
- alarmMgr.set(AlarmManager.ELAPSED_REALTIME, triggerAtTime, pendIntent);
Alarm和Timer以及Handler在定时任务上的区别
相同点:
三者都可以完成定时任务,都支持一次性定时和循环定时(注:Handler可以间接支持循环定时任务)
不同点:
Handler和Timer在定时上是类似的,二者在系统休眠的情况下无法正常工作,定时任务不会按时触发。Alarm在系统休眠的情况下可以正常工作,并且还可以决定是否唤醒系统,同时Alarm在自身不启动的情况下仍能正常收到定时任务提醒,但是当系统重启或者应用被杀死的情况下,Alarm定时任务会被取消。另外,从Android4.4开始,Alarm事件默认采用非精准方式,即定时任务可能会有小范围的提前或延后,当然我们可以强制采用精准方式,而在此之前,Alarm事件都是精准方式。
Alarm与Binder的交互
Alarm由AlarmManager来管理,从使用方式来看,AlarmManager很简单,我们只要得到了AlarmManager的对象,就可以调用set方法来设定定时任务了,而如何得到AlarmManager对象呢?也很简单,AlarmManager alarmMgr = (AlarmManager) getSystemService(Context.ALARM_SERVICE);下面我们去看看AlarmManager的set方法,当然AlarmManager还有setRepeating方法,但是二者是类似的。为了更好地理解下面的内容,需要你了解AIDL,如果你还不了解,请参看android跨进程通信(IPC):使用AIDL。
code:AlarmManager#set
- public void set(int type, long triggerAtMillis, PendingIntent operation) {
- setImpl(type, triggerAtMillis, legacyExactLength(), 0, operation, null);
- }
- public void set(int type, long triggerAtMillis, long windowMillis, long intervalMillis,
- PendingIntent operation, WorkSource workSource) {
- setImpl(type, triggerAtMillis, windowMillis, intervalMillis, operation, workSource);
- }
- private void setImpl(int type, long triggerAtMillis, long windowMillis, long intervalMillis,
- PendingIntent operation, WorkSource workSource) {
- if (triggerAtMillis < 0) {
- /* NOTYET
- if (mAlwaysExact) {
- // Fatal error for KLP+ apps to use negative trigger times
- throw new IllegalArgumentException("Invalid alarm trigger time "
- + triggerAtMillis);
- }
- */
- triggerAtMillis = 0;
- }
- try {
- //定时任务实际上都有mService来完成,也就是说AlarmManager只是一个空壳
- //从下面的构造方法可以看出,这个mService是IAlarmManager类型的,而IAlarmManager是一个接口
- //如果大家了解AIDL就应该知道IAlarmManager应该是一个AIDL接口
- mService.set(type, triggerAtMillis, windowMillis, intervalMillis, operation,
- workSource);
- } catch (RemoteException ex) {
- }
- }
- AlarmManager(IAlarmManager service, Context ctx) {
- mService = service;
- final int sdkVersion = ctx.getApplicationInfo().targetSdkVersion;
- mAlwaysExact = (sdkVersion < Build.VERSION_CODES.KITKAT);
- }
说明:我对代码进行了注释,从注释可以看出,现在我们需要去找到这个mService,其实我已经帮大家找到了,它就是AlarmManagerService,看下它的类的声明:
class AlarmManagerService extends IAlarmManager.Stub
很显然,AlarmManagerService的确实现了IAlarmManager接口,为什么是显然呢?因为按照AIDL的规范,IAlarmManager.Stub是按照如下这种方式声明的:
- public static abstract class Stub extends Binder implements IAlarmManager {
- public static IAlarmManager asInterface(IBinder obj)
- ...
- }
可见这个Stub类就是一个普通的Binder,只不过它实现了IAlarmManager接口。它还有一个静态方法asInterface,这个方法很有用,通过它,我们就可以将IBinder对象转换成IAlarmManager的实例,进而通过实例来调用其方法。什么是Binder?这个还真不好说,但是我们要知道Binder在Android系统中有大量的应用,大部分Manager都通过Binder来实现(包括AlarmManager),而Service和AIDL也是通过Binder来实现调用的。至于Binder和IBinder的关系,很简单,就是Binder实现了IBinder接口。由于AlarmManagerService继承了IAlarmManager.Stub,所以AlarmManagerService也相当于实现了IAlarmManager接口,所以很显然,AlarmManagerService就是AlarmManager中用于和其交互的mService。不过,还没有完,因为上面的结论不是我瞎猜的,是有代码层面的依据的,下面我将带领大家一起去探索寻找mService的过程,通过这个过程,我们会对Binder机制有更加深刻的认识。
各种Manager和Binder服务的对应关系
首先Dalvik虚拟机会在SystemServer中创建一个叫做ServerThread的线程并调用它的initAndLoop方法,在initAndLoop方法中会创建主线程Looper和初始化各种Manager所对应的Binder服务,我们所常见的Binder服务如WindowManagerService、AlarmManagerService、PowerManagerService等均在这里创建并加入到ServiceManager中进行统一管理。而我们通过getSystemService方式来得到各种Manager的工作主要是在ContextImpl中完成的,不过LayoutInflater、WindowManager以及SearchManager除外。通过ContextImpl我们可以知道各种Manager和Binder服务的一一对应关系,比如AlarmManager对应AlarmManagerService、WindowManager对应WindowManagerService。
上面只是结论,为了真正搞清楚各种Manager所对应的Binder服务,下面将要看一系列代码,首先看SystemServer的代码:
code:SystemServer
- public class SystemServer {
- private static final String TAG = "SystemServer";
- public static final int FACTORY_TEST_OFF = 0;
- public static final int FACTORY_TEST_LOW_LEVEL = 1;
- public static final int FACTORY_TEST_HIGH_LEVEL = 2;
- static Timer timer;
- static final long SNAPSHOT_INTERVAL = 60 * 60 * 1000; // 1hr
- // The earliest supported time. We pick one day into 1970, to
- // give any timezone code room without going into negative time.
- private static final long EARLIEST_SUPPORTED_TIME = 86400 * 1000;
- /**
- * Called to initialize native system services.
- * 初始化本地系统服务,jni方法
- */
- private static native void nativeInit();
- //main方法,由底层调用
- public static void main(String[] args) {
- if (System.currentTimeMillis() < EARLIEST_SUPPORTED_TIME) {
- // If a device's clock is before 1970 (before 0), a lot of
- // APIs crash dealing with negative numbers, notably
- // java.io.File#setLastModified, so instead we fake it and
- // hope that time from cell towers or NTP fixes it
- // shortly.
- Slog.w(TAG, "System clock is before 1970; setting to 1970.");
- SystemClock.setCurrentTimeMillis(EARLIEST_SUPPORTED_TIME);
- }
- if (SamplingProfilerIntegration.isEnabled()) {
- SamplingProfilerIntegration.start();
- timer = new Timer();
- timer.schedule(new TimerTask() {
- @Override
- public void run() {
- SamplingProfilerIntegration.writeSnapshot("system_server", null);
- }
- }, SNAPSHOT_INTERVAL, SNAPSHOT_INTERVAL);
- }
- // Mmmmmm... more memory!
- dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();
- // The system server has to run all of the time, so it needs to be
- // as efficient as possible with its memory usage.
- VMRuntime.getRuntime().setTargetHeapUtilization(0.8f);
- Environment.setUserRequired(true);
- System.loadLibrary("android_servers");
- Slog.i(TAG, "Entered the Android system server!");
- // 初始化本地服务.
- nativeInit();
- //这里是关键,ServerThread被创建,同时其initAndLoop被调用
- ServerThread thr = new ServerThread();
- thr.initAndLoop();
- }
- }
接着看ServerThread的initAndLoop方法,该方法中,主线程Looper会被创建,各种Binder服务会被创建。该方法太长,我进行了截断,只展出我们所关心的代码。
code:ServerThread#initAndLoop
- public void initAndLoop() {
- EventLog.writeEvent(EventLogTags.BOOT_PROGRESS_SYSTEM_RUN,
- SystemClock.uptimeMillis());
- //主线程Looper被创建
- Looper.prepareMainLooper();
- android.os.Process.setThreadPriority(
- android.os.Process.THREAD_PRIORITY_FOREGROUND);
- BinderInternal.disableBackgroundScheduling(true);
- android.os.Process.setCanSelfBackground(false);
- ...此处省略
- //下面是各种Binder服务,从名字我们应该能够大致看出它们所对应的Manager
- Installer installer = null;
- AccountManagerService accountManager = null;
- ContentService contentService = null;
- LightsService lights = null;
- PowerManagerService power = null;
- DisplayManagerService display = null;
- BatteryService battery = null;
- VibratorService vibrator = null;
- AlarmManagerService alarm = null;
- MountService mountService = null;
- NetworkManagementService networkManagement = null;
- NetworkStatsService networkStats = null;
- NetworkPolicyManagerService networkPolicy = null;
- ConnectivityService connectivity = null;
- WifiP2pService wifiP2p = null;
- WifiService wifi = null;
- NsdService serviceDiscovery= null;
- IPackageManager pm = null;
- Context context = null;
- WindowManagerService wm = null;
- BluetoothManagerService bluetooth = null;
- DockObserver dock = null;
- UsbService usb = null;
- SerialService serial = null;
- TwilightService twilight = null;
- UiModeManagerService uiMode = null;
- RecognitionManagerService recognition = null;
- NetworkTimeUpdateService networkTimeUpdater = null;
- CommonTimeManagementService commonTimeMgmtService = null;
- InputManagerService inputManager = null;
- TelephonyRegistry telephonyRegistry = null;
- ConsumerIrService consumerIr = null;
- ...此处省略
- Slog.i(TAG, "Alarm Manager");
- //这里AlarmManager对应的Binder服务被创建
- alarm = new AlarmManagerService(context);
- //将AlarmManagerService加入ServiceManager中统一管理
- ServiceManager.addService(Context.ALARM_SERVICE, alarm);
- Slog.i(TAG, "Init Watchdog");
- Watchdog.getInstance().init(context, battery, power, alarm,
- ActivityManagerService.self());
- Watchdog.getInstance().addThread(wmHandler, "WindowManager thread");
- Slog.i(TAG, "Input Manager");
- inputManager = new InputManagerService(context, wmHandler);
- Slog.i(TAG, "Window Manager");
- //这里WindowManager所对应的Binder服务被创建
- wm = WindowManagerService.main(context, power, display, inputManager,
- wmHandler, factoryTest != SystemServer.FACTORY_TEST_LOW_LEVEL,
- !firstBoot, onlyCore);
- //将WindowManagerService加入ServiceManager中统一管理
- ServiceManager.addService(Context.WINDOW_SERVICE, wm);
- ServiceManager.addService(Context.INPUT_SERVICE, inputManager);
- ActivityManagerService.self().setWindowManager(wm);
- ...此处省略
- }
说明:针对上述代码,我要说明一下,首先其创建的各种Binder服务其实并不是真正的服务,说它们是Binder比较恰当,因为它们的确继承自Binder而不是Service;另一点就是ServiceManager其实也仅仅是个壳子,真正的工作是通过其Binder服务ServiceManagerNative来完成的,ServiceManager提供的工厂方法addService和getService均在ServiceManagerNative中通过代理来实现。
到此为止,我们已经知道各种Binder服务的创建过程,下面我们要看一下Manager是如何和其Binder服务关联上的,再回到getSystemService方法。首先我们要知道Activity的继承关系,如下图所示:
再看如下代码,观察下它们中的getSystemService方法是如何实现的
code:各种getSystemService方法
- //#Context
- public abstract Object getSystemService(String name);
- //#ContextWrapper
- @Override
- public Object getSystemService(String name) {
- return mBase.getSystemService(name);
- }
- //#ContextThemeWrapper
- @Override
- public Object getSystemService(String name) {
- if (LAYOUT_INFLATER_SERVICE.equals(name)) {
- if (mInflater == null) {
- mInflater = LayoutInflater.from(mBase).cloneInContext(this);
- }
- return mInflater;
- }
- return mBase.getSystemService(name);
- }
- //#Activity
- @Override
- public Object getSystemService(String name) {
- if (getBaseContext() == null) {
- throw new IllegalStateException(
- "System services not available to Activities before onCreate()");
- }
- if (WINDOW_SERVICE.equals(name)) {
- return mWindowManager;
- } else if (SEARCH_SERVICE.equals(name)) {
- ensureSearchManager();
- return mSearchManager;
- }
- return super.getSystemService(name);
- }
说明:通过上述代码可以看出LayoutInflater、WindowManager以及SearchManager的处理比较特殊,直接在方法中返回对象,剩下的所有Manager将通过mBase.getSystemService(name)返回,现在问题转移到mBase上面,mBase是什么呢?我已经查清楚了,Activity的mBase就是ContextImpl对象,何以见得?请看下面分析
ContextImpl:Activity的mBase
不知道大家对我写的另外一篇源码分析是否有印象:Android源码分析-Activity的启动过程,在这篇文章中我指出:Activity的最终启动过程由ActivityThread中的performLaunchActivity方法来完成,在performLaunchActivity中,Activity的mBase将被赋值为ContextImpl对象,下面通过代码来说明:
code:mBase的赋值过程
- private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
- ...
- if (activity != null) {
- //这里的appContext就是ContextImpl对象
- Context appContext = createBaseContextForActivity(r, activity);
- CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
- Configuration config = new Configuration(mCompatConfiguration);
- if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity "
- + r.activityInfo.name + " with config " + config);
- //通过Activity的attach方法将ContextImpl对象赋值给mBase
- activity.attach(appContext, this, getInstrumentation(), r.token,
- r.ident, app, r.intent, r.activityInfo, title, r.parent,
- r.embeddedID, r.lastNonConfigurationInstances, config);
- ...
- }
- ...
- }
- private Context createBaseContextForActivity(ActivityClientRecord r,
- final Activity activity) {
- //很显然,此方法返回的就是ContextImpl对象
- ContextImpl appContext = new ContextImpl();
- appContext.init(r.packageInfo, r.token, this);
- appContext.setOuterContext(activity);
- Context baseContext = appContext;
- ...
- return baseContext;
- }
- final void attach(Context context, ActivityThread aThread,
- Instrumentation instr, IBinder token, int ident,
- Application application, Intent intent, ActivityInfo info,
- CharSequence title, Activity parent, String id,
- NonConfigurationInstances lastNonConfigurationInstances,
- Configuration config) {
- //将context赋值给mBase,这里的context就是performLaunchActivity中的appContext,即ContextImpl对象
- attachBaseContext(context);
- mFragments.attachActivity(this, mContainer, null);
- mWindow = PolicyManager.makeNewWindow(this);
- mWindow.setCallback(this);
- ...
- }
- @Override protected void attachBaseContext(Context newBase) {
- super.attachBaseContext(newBase);
- //这里很显然,对mBase进行赋值
- mBase = newBase;
- }
说明:看了上面的代码,我们已经知道,mBase的确是ContextImpl对象。上面我提到:除了LayoutInflater、WindowManager以及SearchManager,剩下的所有Manager将通过mBase.getSystemService(name)返回,那么现在,我们去看下ContextImpl中的getSystemService方法。
code:ContextImpl#getSystemService
- class ContextImpl extends Context {
- ...
- @Override
- public Object getSystemService(String name) {
- //首先从SYSTEM_SERVICE_MAP根据服务名得到一个fetcher对象
- //其中SYSTEM_SERVICE_MAP是一个HashMap,然后再通过fetcher去取service
- ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
- return fetcher == null ? null : fetcher.getService(this);
- }
- ...
- }
说明:看了ContextImpl的getSystemService方法,发现失望了,还没有找到真正的实现,看来还要去看这个fetcher是怎么回事,下面请看代码:
code:服务注册过程和fetcher
- //一个哈希表,用来根据服务名存储对应服务的ServiceFetcher(可以理解为通过ServiceFetcher可以得到服务)
- private static final HashMap<String, ServiceFetcher> SYSTEM_SERVICE_MAP =
- new HashMap<String, ServiceFetcher>();
- //注册服务,将服务的fetcher存到哈希表中
- private static void registerService(String serviceName, ServiceFetcher fetcher) {
- if (!(fetcher instanceof StaticServiceFetcher)) {
- fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;
- }
- SYSTEM_SERVICE_MAP.put(serviceName, fetcher);
- }
- //静态代码块,注册各种服务
- //也就是说,ContextImpl这个类被加载的时候就会把如下的各种服务的fetcher加入到哈希表中
- //这样我们通过getSystemService就可以得到一个服务的fetcher,再通过fetcher去得到服务的对象
- static {
- registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() {
- public Object getService(ContextImpl ctx) {
- return AccessibilityManager.getInstance(ctx);
- }});
- registerService(CAPTIONING_SERVICE, new ServiceFetcher() {
- public Object getService(ContextImpl ctx) {
- return new CaptioningManager(ctx);
- }});
- registerService(ACCOUNT_SERVICE, new ServiceFetcher() {
- public Object createService(ContextImpl ctx) {
- IBinder b = ServiceManager.getService(ACCOUNT_SERVICE);
- IAccountManager service = IAccountManager.Stub.asInterface(b);
- return new AccountManager(ctx, service);
- }});
- registerService(ACTIVITY_SERVICE, new ServiceFetcher() {
- public Object createService(ContextImpl ctx) {
- return new ActivityManager(ctx.getOuterContext(), ctx.mMainThread.getHandler());
- }});
- //这里是Alarm服务的注册
- registerService(ALARM_SERVICE, new ServiceFetcher() {
- public Object createService(ContextImpl ctx) {
- /**还记得ALARM_SERVICE吗?
- * alarm = new AlarmManagerService(context);
- * 将AlarmManagerService加入ServiceManager中统一管理
- * ServiceManager.addService(Context.ALARM_SERVICE, alarm);
- */
- //通过ServiceManager的getService得到Alarm服务,很显然,下面的b就是AlarmManagerService对象
- IBinder b = ServiceManager.getService(ALARM_SERVICE);
- //还记得AlarmManager中的mService吗?就是这里的service,很显然它是一个Binder服务
- //分析到这里,事实已经得出:AlarmManager所对应的Binder服务就是AlarmManagerService
- IAlarmManager service = IAlarmManager.Stub.asInterface(b);
- return new AlarmManager(service, ctx);
- }});
- registerService(AUDIO_SERVICE, new ServiceFetcher() {
- public Object createService(ContextImpl ctx) {
- return new AudioManager(ctx);
- }});
- ...省略:下面还有许多服务
- }
Alarm机制分析
通过上面的一系列分析,我们知道AlarmManager的所有功能都是通过AlarmManagerService来完成的,在分析源码之前,我先来描述下Alarm的工作原理:从Android4.4开始,Alarm默认为非精准模式,除非显示指定采用精准模式。在非精准模式下,Alarm是批量提醒的,每个alarm根据其触发时间和最大触发时间的不同会被加入到不同的batch中,同一个batch的不同alarm是同时发生的,这样就无法实现精准闹钟,官方的解释是批量处理可以减少设备被唤醒次数以及节约电量,不过针对精准闹钟,官方预留的方法是setExact和setWindow,二者都是通过将时间窗口定义为0来实现精准闹钟的,因为时间窗口为0,意味着触发时间和最大触发时间是一样的,因为典型的情况下:最大触发时间= 触发时间 + 时间窗口。同时所有的batch是按开始时间升序排列的,在一个batch内部,不同的闹钟也是按触发时间升序排列的,所以闹钟的唤醒顺序是按照batch的排序依次触发的,而同一个batch中的alarm是同时触发的,可以用下面这个示意图来描述:
上图是示意图,系统中可以有多个batch,每个batch中可以有多个alarm。下面我们分析一下AlarmManagerService中的代码。其入口方法为set,set又调用了setImplLocked,所以我们直接看setImplLocked。
code:AlarmManagerService#setImplLocked
- private void setImplLocked(int type, long when, long whenElapsed, long maxWhen, long interval,
- PendingIntent operation, boolean isStandalone, boolean doValidate,
- WorkSource workSource) {
- /**创建一个alarm,其中各参数的含义如下:
- * type 闹钟类型 ELAPSED_REALTIME、RTC、RTC_WAKEUP等
- * when 触发时间 UTC类型,绝对时间,通过System.currentTimeMillis()得到
- * whenElapsed 相对触发时间,自开机算起,含休眠,通过SystemClock.elapsedRealtime()得到
- * maxWhen 最大触发时间
- * interval 触发间隔,针对循环闹钟有效
- * operation 闹钟触发时的行为,PendingIntent类型
- */
- Alarm a = new Alarm(type, when, whenElapsed, maxWhen, interval, operation, workSource);
- //根据PendingIntent删除之前已有的同一个闹钟
- removeLocked(operation);
- boolean reschedule;
- //尝试将alarm加入到合适的batch中,如果alarm是独立的或者无法找到合适的batch去容纳此alarm,返回-1
- int whichBatch = (isStandalone) ? -1 : attemptCoalesceLocked(whenElapsed, maxWhen);
- if (whichBatch < 0) {
- //没有合适的batch去容纳alarm,则新建一个batch
- Batch batch = new Batch(a);
- batch.standalone = isStandalone;
- //将batch加入mAlarmBatches中,并对mAlarmBatches进行排序:按开始时间升序排列
- reschedule = addBatchLocked(mAlarmBatches, batch);
- } else {
- //如果找到合适了batch去容纳此alarm,则将其加入到batch中
- Batch batch = mAlarmBatches.get(whichBatch);
- //如果当前alarm的加入引起了batch开始时间和结束时间的改变,则reschedule为true
- reschedule = batch.add(a);
- if (reschedule) {
- //由于batch的起始时间发生了改变,所以需要从列表中删除此batch并重新加入、重新对batch列表进行排序
- mAlarmBatches.remove(whichBatch);
- addBatchLocked(mAlarmBatches, batch);
- }
- }
- if (DEBUG_VALIDATE) {
- if (doValidate && !validateConsistencyLocked()) {
- Slog.v(TAG, "Tipping-point operation: type=" + type + " when=" + when
- + " when(hex)=" + Long.toHexString(when)
- + " whenElapsed=" + whenElapsed + " maxWhen=" + maxWhen
- + " interval=" + interval + " op=" + operation
- + " standalone=" + isStandalone);
- rebatchAllAlarmsLocked(false);
- reschedule = true;
- }
- }
- if (reschedule) {
- rescheduleKernelAlarmsLocked();
- }
- }
说明:通过上述代码可以看出,当我们创建一个alarm的时候,仅仅是将这个alarm加入到某个batch中,系统中有一个batch列表,专门用于存储所有的alarm。可是仅仅把alarm加入到batch中还不行,系统还必须提供一个类似于Looper的东西一直去遍历这个列表,一旦它发现有些alarm的时间已经到达就要把它取出来去执行。事实上,AlarmManagerService中的确有一个类似于Looper的东西去干这个事情,只不过它是个线程,叫做AlarmThread。下面看它的代码:
code:AlarmManagerService#AlarmThread
- private class AlarmThread extends Thread
- {
- public AlarmThread()
- {
- super("AlarmManager");
- }
- public void run()
- {
- //当前时间触发的alarm列表
- ArrayList<Alarm> triggerList = new ArrayList<Alarm>();
- while (true)
- {
- //jni方法,顾名思义,阻塞式方法,当有alarm的时候会被唤醒
- int result = waitForAlarm(mDescriptor);
- triggerList.clear();
- if ((result & TIME_CHANGED_MASK) != 0) {
- if (DEBUG_BATCH) {
- Slog.v(TAG, "Time changed notification from kernel; rebatching");
- }
- remove(mTimeTickSender);
- //将所有的alarm重新排序
- rebatchAllAlarms();
- mClockReceiver.scheduleTimeTickEvent();
- Intent intent = new Intent(Intent.ACTION_TIME_CHANGED);
- intent.addFlags(Intent.FLAG_RECEIVER_REPLACE_PENDING
- | Intent.FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT);
- mContext.sendBroadcastAsUser(intent, UserHandle.ALL);
- }
- synchronized (mLock) {
- final long nowRTC = System.currentTimeMillis();
- final long nowELAPSED = SystemClock.elapsedRealtime();
- if (localLOGV) Slog.v(
- TAG, "Checking for alarms... rtc=" + nowRTC
- + ", elapsed=" + nowELAPSED);
- if (WAKEUP_STATS) {
- if ((result & IS_WAKEUP_MASK) != 0) {
- long newEarliest = nowRTC - RECENT_WAKEUP_PERIOD;
- int n = 0;
- for (WakeupEvent event : mRecentWakeups) {
- if (event.when > newEarliest) break;
- n++; // number of now-stale entries at the list head
- }
- for (int i = 0; i < n; i++) {
- mRecentWakeups.remove();
- }
- recordWakeupAlarms(mAlarmBatches, nowELAPSED, nowRTC);
- }
- }
- //这个方法会把batch列表中的第一个batch取出来然后加到触发列表中
- //当然,前提是此batch的开始时间不大于当前时间
- //同时,如果是循环闹钟,则会对下次任务进行再次定时
- triggerAlarmsLocked(triggerList, nowELAPSED, nowRTC);
- rescheduleKernelAlarmsLocked();
- // 遍历触发列表,发送PendingIntent
- for (int i=0; i<triggerList.size(); i++) {
- Alarm alarm = triggerList.get(i);
- try {
- if (localLOGV) Slog.v(TAG, "sending alarm " + alarm);
- //这里PendingIntent会被send,结果就是我们的定时任务被执行了
- alarm.operation.send(mContext, 0,
- mBackgroundIntent.putExtra(
- Intent.EXTRA_ALARM_COUNT, alarm.count),
- mResultReceiver, mHandler);
- // we have an active broadcast so stay awake.
- if (mBroadcastRefCount == 0) {
- setWakelockWorkSource(alarm.operation, alarm.workSource);
- mWakeLock.acquire();
- }
- final InFlight inflight = new InFlight(AlarmManagerService.this,
- alarm.operation, alarm.workSource);
- mInFlight.add(inflight);
- mBroadcastRefCount++;
- final BroadcastStats bs = inflight.mBroadcastStats;
- bs.count++;
- if (bs.nesting == 0) {
- bs.nesting = 1;
- bs.startTime = nowELAPSED;
- } else {
- bs.nesting++;
- }
- final FilterStats fs = inflight.mFilterStats;
- fs.count++;
- if (fs.nesting == 0) {
- fs.nesting = 1;
- fs.startTime = nowELAPSED;
- } else {
- fs.nesting++;
- }
- if (alarm.type == ELAPSED_REALTIME_WAKEUP
- || alarm.type == RTC_WAKEUP) {
- bs.numWakeup++;
- fs.numWakeup++;
- //针对能唤醒设备的闹钟,这里会做一些唤醒设备的事情
- ActivityManagerNative.noteWakeupAlarm(
- alarm.operation);
- }
- } catch (PendingIntent.CanceledException e) {
- if (alarm.repeatInterval > 0) {
- // This IntentSender is no longer valid, but this
- // is a repeating alarm, so toss the hoser.
- remove(alarm.operation);
- }
- } catch (RuntimeException e) {
- Slog.w(TAG, "Failure sending alarm.", e);
- }
- }
- }
- }
- }
- }
总结
本文没有详细介绍如何使用Alarm,因为很简单,看一下官方文档或者网上搜一下,到处都是。关于Alarm,有一点需要强调一下:当手机重启或者应用被杀死的时候,Alarm会被删除,因此,如果想通过Alarm来完成长久定时任务是不可靠的,如果非要完成长久定时任务,可以这样:将应用的所有Alarm信息存到数据库中,每次应用启动的时候都重新注册Alarm并更新Alarm的触发时间,通过这种方式就不存在Alarm丢失的情况了。本文很长,耗时8个小时才完成的,感谢大家阅读本文,希望本文能给大家带来一点帮助。