android AlarmManager 研究

1、AlarmManager研究android 4.0目錄(?)-概述AlarmManagerAlarmManager的成員函數(shù)AlarmManagerService邏輯鬧鐘主要行為設(shè)置alarm重復(fù)性alarm取消alarm設(shè)置系統(tǒng)時間和時區(qū)運作細(xì)節(jié)AlarmThread和Alarm的激發(fā)AlarmThread中的runwaitForAlarmtriggerAlarmsLocked進一步處理喚醒鬧鐘說說AlarmManagerService中的mBroadcastRefCountAlarmManager研究侯 亮 1.概述     &#

2、160;  在Android系統(tǒng)中，鬧鐘和喚醒功能都是由Alarm Manager Service控制并管理的。我們所熟悉的RTC鬧鐘以及定時器都和它有莫大的關(guān)系。為了便于稱呼，我常常也把這個service簡稱為ALMS。        另外，ALMS還提供了一個AlarmManager輔助類。在實際的代碼中，應(yīng)用程序一般都是通過這個輔助類來和ALMS打交道的。就代碼而言，輔助類只不過是把一些邏輯語義傳遞給ALMS服務(wù)端而已，具體怎么做則完全要看ALMS的實現(xiàn)代碼了。    

3、    ALMS的實現(xiàn)代碼并不算太復(fù)雜，主要只是在管理“邏輯鬧鐘”。它把邏輯鬧鐘分成幾個大類，分別記錄在不同的列表中。然后ALMS會在一個專門的線程中循環(huán)等待鬧鐘的激發(fā)，一旦時機到了，就“回調(diào)”邏輯鬧鐘對應(yīng)的動作。        以上只是一些概要性的介紹，下面我們來看具體的技術(shù)細(xì)節(jié)。 2.AlarmManager        前文我們已經(jīng)說過，ALMS只是服務(wù)端的東西。它必須向外提供具體的接口，才能被外界使用。在A

4、ndroid平臺中，ALMS的外部接口為IAlarmManager。其定義位于frameworksbasecorejavaandroidappIAlarmManager.aidl腳本中，定義截選如下： interface IAlarmManager void set(int type, long triggerAtTime, in PendingIntent operation); void setRepeating(int type, long triggerAtTime, long interval, in PendingIntent operation); void setIn

5、exactRepeating(int type, long triggerAtTime, long interval, in PendingIntent operation); void setTime(long millis); void setTimeZone(String zone); void remove(in PendingIntent operation);        在一般情況下，service的使用者會通過Service Manager Service接口，先拿到它感興趣的service對應(yīng)的代理I接口

6、，然后再調(diào)用I接口的成員函數(shù)向service發(fā)出請求。所以按理說，我們也應(yīng)該先拿到一個IAlarmManager接口，然后再使用它?？墒牵瑢larm Manager Service來說，情況略有不同，其最常見的調(diào)用方式如下：manager = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);其中，getSystemService()返回的不再是IAlarmManager接口，而是AlarmManager對象。         

7、我們參考AlarmManager.java文件，可以看到AlarmManager類中聚合了一個IAlarmManager接口，private final IAlarmManager mService;也就是說在執(zhí)行實際動作時，AlarmManager只不過是把外界的請求轉(zhuǎn)發(fā)給內(nèi)部聚合的IAlarmManager接口而已。 2.1  AlarmManager的成員函數(shù)        AlarmManager的成員函數(shù)有：AlarmManager(IAlarmManager service)public void se

8、t(int type, long triggerAtTime, PendingIntent operation)public void setRepeating(int type, long triggerAtTime, long interval, PendingIntent operation)public void setInexactRepeating(int type, long triggerAtTime, long interval, PendingIntent operation)public void cancel(PendingIntent operation)public

9、 void setTime(long millis)public void setTimeZone(String timeZone)即1個構(gòu)造函數(shù)，6個功能函數(shù)。基本上完全和IAlarmManager的成員函數(shù)一一對應(yīng)。         另外，AlarmManager類中會以不同的公共常量來表示多種不同的邏輯鬧鐘，在Android 4.0的原生代碼中有4種邏輯鬧鐘： 1）  RTC_WAKEUP 2）  RTC 3）  ELAPSED_REALTIME_W

10、AKEUP 4）  ELAPSED_REALTIME       應(yīng)用側(cè)通過調(diào)用AlarmManager對象的成員函數(shù)，可以把語義傳遞到AlarmManagerService，并由它進行實際的處理。 3.AlarmManagerService        ALMS的重頭戲在AlarmManagerService中，這個類繼承于IAlarmManager.Stub，所以是個binder實體。它包含的重要成員如下：其中，mRtcWakeu

11、pAlarms等4個ArrayList<Alarm>數(shù)組分別對應(yīng)著前文所說的4種“邏輯鬧鐘”。為了便于理解，我們可以想象在底層有4個“實體鬧鐘”，注意，是4個，不是4類。上面每一類“邏輯鬧鐘”都會對應(yīng)一個“實體鬧鐘”，而邏輯鬧鐘則可以有若干個，它們被存儲在ArrayList中，示意圖如下： 當(dāng)然，這里所說的“實體鬧鐘”只是個概念而已，其具體實現(xiàn)和底層驅(qū)動有關(guān)，在frameworks層不必過多關(guān)心。          Frameworks層應(yīng)該關(guān)心的是那幾個ArrayList<A

12、larm>。這里的Alarm對應(yīng)著邏輯鬧鐘。 3.1  邏輯鬧鐘        Alarm是AlarmManagerService的一個內(nèi)嵌類Alarm，定義截選如下：private static class Alarm public int type; public int count; public long when; public long repeatInterval; public PendingIntent operation; public int uid; public int p

13、id; . . . . . .其中記錄了邏輯鬧鐘的一些關(guān)鍵信息。 type域：記錄著邏輯鬧鐘的鬧鐘類型，比如RTC_WAKEUP、ELAPSED_REALTIME_WAKEUP等；count域：是個輔助域，它和repeatInterval域一起工作。當(dāng)repeatInterval大于0時，這個域可被用于計算下一次重復(fù)激發(fā)alarm的時間，詳細(xì)情況見后文；when域：記錄鬧鐘的激發(fā)時間。這個域和type域相關(guān)，詳細(xì)情況見后文；repeatInterval域：表示重復(fù)激發(fā)鬧鐘的時間間隔，如果鬧鐘只需激發(fā)一次，則此域為0，如果鬧鐘需要重復(fù)激發(fā)，此域為以毫秒為單位的時間間隔；operation域：記錄

14、鬧鐘激發(fā)時應(yīng)該執(zhí)行的動作，詳細(xì)情況見后文；uid域：記錄設(shè)置鬧鐘的進程的uid；pid域：記錄設(shè)置鬧鐘的進程的pid。         總體來說還是比較簡單的，我們先補充說明一下其中的count域。這個域是針對重復(fù)性鬧鐘的一個輔助域。重復(fù)性鬧鐘的實現(xiàn)機理是，如果當(dāng)前時刻已經(jīng)超過鬧鐘的激發(fā)時刻，那么ALMS會先從邏輯鬧鐘數(shù)組中摘取下Alarm節(jié)點，并執(zhí)行鬧鐘對應(yīng)的邏輯動作，然后進一步比較“當(dāng)前時刻”和“Alarm理應(yīng)激發(fā)的理想時刻”之間的時間跨度，從而計算出Alarm的“下一次理應(yīng)激發(fā)的理想時刻”，并將這個激發(fā)時間記

15、入Alarm節(jié)點，接著將該節(jié)點重新排入邏輯鬧鐘列表。這一點和普通Alarm不太一樣，普通Alarm節(jié)點摘下后就不再還回邏輯鬧鐘列表了。         “當(dāng)前時刻”和“理應(yīng)激發(fā)時刻”之間的時間跨度會隨實際的運作情況而變動。我們分兩步來說明“下一次理應(yīng)激發(fā)時刻”的計算公式： 1）  count  =  (時間跨度 /  repeatInterval ) + 1 ； 2）  “下一次理應(yīng)激發(fā)時刻” = “上一次理應(yīng)激發(fā)時刻”+ count * rep

16、eatInterval ；          我們畫一張示意圖，其中綠色的可激發(fā)時刻表示“上一次理應(yīng)激發(fā)時刻”，我們假定“當(dāng)前時刻”分別為now_1處或now_2處，可以看到會計算出不同的“下一次理應(yīng)激發(fā)時刻”，這里用桔紅色表示。          可以看到，如果當(dāng)前時刻為now_1，那么它和“上一次理應(yīng)激發(fā)時刻”之間的“時間跨度”是小于一個repeatInterval的，所以count數(shù)為1。而如果當(dāng)前時刻為now

17、_2，那么“時間跨度”與repeatInterval的商取整后為2，所以count數(shù)為3。另外，圖中那兩個虛線箭頭對應(yīng)的可激發(fā)時刻，只是用來做刻度的東西。 3.2  主要行為        接下來我們來看ALMS中的主要行為，這些行為和AlarmManager輔助類提供的成員函數(shù)相對應(yīng)。 3.2.1   設(shè)置alarm        外界能接觸的設(shè)置alarm的函數(shù)是set()：public void se

18、t(int type, long triggerAtTime, PendingIntent operation)type：表示要設(shè)置的alarm類型。如前文所述，有4個alarm類型。 triggerAtTime：表示alarm“理應(yīng)激發(fā)”的時間。 operation：指明了alarm鬧鈴激發(fā)時需要執(zhí)行的動作，比如執(zhí)行某種廣播通告。         設(shè)置alarm的動作會牽扯到一個發(fā)起者。簡單地說，發(fā)起者會向Alarm Manager Service發(fā)出一個設(shè)置alarm的請求，而且在請求里注明

19、了到時間后需要執(zhí)行的動作。由于“待執(zhí)行的動作”一般都不會馬上執(zhí)行，所以要表達成PendingIntent的形式。（PendingIntent的詳情可參考其他文章）          另外，triggerAtTime參數(shù)的意義也會隨type參數(shù)的不同而不同。簡單地說，如果type是和RTC相關(guān)的話，那么triggerAtTime的值應(yīng)該是標(biāo)準(zhǔn)時間，即從1970 年 1 月 1 日午夜開始所經(jīng)過的毫秒數(shù)。而如果type是其他類型的話，那么triggerAtTime的值應(yīng)該是從本次開機開始算起的毫秒數(shù)。

20、0;3.2.2   重復(fù)性alarm        另一個設(shè)置alarm的函數(shù)是setRepeating()：public void setRepeating(int type, long triggerAtTime, long interval,PendingIntent operation)其參數(shù)基本上和set()函數(shù)差不多，只是多了一個“時間間隔”參數(shù)。事實上，在Alarm Manager Service一側(cè)，set()函數(shù)內(nèi)部也是在調(diào)用setRepeating()的，只不過會把interval設(shè)成

21、了0。           setRepeating()的實現(xiàn)函數(shù)如下：public void setRepeating(int type, long triggerAtTime, long interval, PendingIntent operation) if (operation = null) Slog.w(TAG, "set/setRepeating ignored because there is no intent"); return; synchronize

22、d (mLock) Alarm alarm = new Alarm(); alarm.type = type; alarm.when = triggerAtTime; alarm.repeatInterval = interval; alarm.operation = operation; / Remove this alarm if already scheduled. removeLocked(operation); if (localLOGV) Slog.v(TAG, "set: " + alarm); int index = addAlarmLocked(alarm

23、); if (index = 0) setLocked(alarm);          代碼很簡單，會創(chuàng)建一個邏輯鬧鐘Alarm，而后調(diào)用addAlarmLocked()將邏輯鬧鐘添加到內(nèi)部邏輯鬧鐘數(shù)組的某個合適位置。private int addAlarmLocked(Alarm alarm) ArrayList<Alarm> alarmList = getAlarmList(alarm.type); int index = Collections.binarySearch(alarmList, a

24、larm, mIncreasingTimeOrder); if (index < 0) index = 0 - index - 1; if (localLOGV) Slog.v(TAG, "Adding alarm " + alarm + " at " + index); alarmList.add(index, alarm); . . . . . . return index;         邏輯鬧鐘列表是依據(jù)alarm的激發(fā)時間進行排序的，越早激發(fā)的alarm，越

25、靠近第0位。所以，addAlarmLocked()在添加新邏輯鬧鐘時，需要先用二分查找法快速找到列表中合適的位置，然后再把Alarm對象插入此處。 如果所插入的位置正好是第0位，就說明此時新插入的這個邏輯鬧鐘將會是本類alarm中最先被激發(fā)的alarm，而正如我們前文所述，每一類邏輯鬧鐘會對應(yīng)同一個“實體鬧鐘”，此處我們在第0位設(shè)置了新的激發(fā)時間，明確表示我們以前對“實體鬧鐘”設(shè)置的激發(fā)時間已經(jīng)不準(zhǔn)確了，所以setRepeating()中必須重新調(diào)整一下“實體鬧鐘”的激發(fā)時間，于是有了下面的句子：if (index = 0) setLocked(alarm);  

26、       setLocked()內(nèi)部會調(diào)用native函數(shù)set()：private native void set(int fd, int type, long seconds, long nanoseconds);重新設(shè)置“實體鬧鐘”的激發(fā)時間。這個函數(shù)內(nèi)部會調(diào)用ioctl()和底層打交道。具體代碼可參考frameworks/base/services/jni/com_android_server_AlarmManagerService.cpp文件：static void android_server_AlarmManager

27、Service_set(JNIEnv* env, jobject obj, jint fd, jint type, jlong seconds, jlong nanoseconds) struct timespec ts; ts.tv_sec = seconds; ts.tv_nsec = nanoseconds; int result = ioctl(fd, ANDROID_ALARM_SET(type), &ts); if (result < 0) ALOGE("Unable to set alarm to %lld.%09lld: %sn", secon

28、ds, nanoseconds, strerror(errno);           我們知道，PendingIntent只是frameworks一層的概念，和底層驅(qū)動是沒有關(guān)系的。所以向底層設(shè)置alarm時只需要type信息以及激發(fā)時間信息就可以了。 3.2.3   取消alarm        用戶端是調(diào)用AlarmManager對象的cancel()函數(shù)來取消alarm的。這個函數(shù)內(nèi)部其實是調(diào)用IA

29、larmManager的remove()函數(shù)。所以我們只來看AlarmManagerService的remove()就可以了。public void remove(PendingIntent operation) if (operation = null) return; synchronized (mLock) removeLocked(operation);               注意，在取消alarm時，是以一個PendingIntent對象作為參數(shù)的。

30、這個PendingIntent對象正是當(dāng)初設(shè)置alarm時，所傳入的那個operation參數(shù)。我們不能隨便創(chuàng)建一個新的PendingIntent對象來調(diào)用remove()函數(shù)，否則remove()是不會起作用的。PendingIntent的運作細(xì)節(jié)不在本文論述范圍之內(nèi)，此處我們只需粗淺地知道，PendingIntent對象在AMS（Activity Manager Service）端會對應(yīng)一個PendingIntentRecord實體，而ALMS在遍歷邏輯鬧鐘列表時，是根據(jù)是否指代相同PendingIntentRecord實體來判斷PendingIntent的相符情況的。如果我們隨便創(chuàng)建一個

31、PendingIntent對象并傳入remove()函數(shù)的話，那么在ALMS端勢必找不到相符的PendingIntent對象，所以remove()必然無效。          remove()中調(diào)用的removeLocked()如下：public void removeLocked(PendingIntent operation) removeLocked(mRtcWakeupAlarms, operation); removeLocked(mRtcAlarms, operation); removeLo

32、cked(mElapsedRealtimeWakeupAlarms, operation); removeLocked(mElapsedRealtimeAlarms, operation);簡單地說就是，把4個邏輯鬧鐘數(shù)組都遍歷一遍，刪除其中所有和operation相符的Alarm節(jié)點。removeLocked()的實現(xiàn)代碼如下：private void removeLocked(ArrayList<Alarm> alarmList, PendingIntent operation) if (alarmList.size() <= 0) return; / iterator

33、over the list removing any it where the intent match Iterator<Alarm> it = alarmList.iterator(); while (it.hasNext() Alarm alarm = it.next(); if (alarm.operation.equals(operation) it.remove();           請注意，所謂的取消alarm，只是刪除了對應(yīng)的邏輯Alarm節(jié)點而已，并不會和底層驅(qū)動再打什么

34、交道。也就是說，是不存在針對底層“實體鬧鐘”的刪除動作的。所以，底層“實體鬧鐘”在到時之時，還是會被“激發(fā)”出來的，只不過此時在frameworks層，會因為找不到符合要求的“邏輯鬧鐘”而不做進一步的激發(fā)動作。 3.2.4   設(shè)置系統(tǒng)時間和時區(qū)        AlarmManager還提供設(shè)置系統(tǒng)時間的功能，設(shè)置者需要具有android.permission.SET_TIME權(quán)限。public void setTime(long millis) mContext.enforceCallingO

35、rSelfPermission("android.permission.SET_TIME", "setTime"); SystemClock.setCurrentTimeMillis(millis);          另外，還具有設(shè)置時區(qū)的功能：public void setTimeZone(String tz)相應(yīng)地，設(shè)置者需要具有android.permission.SET_TIME_ZONE權(quán)限。 3.3  運作細(xì)節(jié)3.3.1 

36、  AlarmThread和Alarm的激發(fā)        AlarmManagerService內(nèi)部是如何感知底層激發(fā)alarm的呢？首先，AlarmManagerService有一個表示線程的mWaitThread成員：private final AlarmThread mWaitThread = new AlarmThread();在AlarmManagerService構(gòu)造之初，就會啟動這個專門的“等待線程”。public AlarmManagerService(Context context) mCont

37、ext = context; mDescriptor = init(); . . . . . . . . . . . . if (mDescriptor != -1) mWaitThread.start(); / 啟動線程！ else Slog.w(TAG, "Failed to open alarm driver. Falling back to a handler."); AlarmManagerService的構(gòu)造函數(shù)一開始就會調(diào)用一個init()函數(shù)，該函數(shù)是個native函數(shù)，它的內(nèi)部會打開alarm驅(qū)動，并返回驅(qū)動文件句柄。只要能夠順利打開alarm驅(qū)動，ALM

38、S就可以走到mWaitThread.start()一句，于是“等待線程”就啟動了。 3.3.1.1  AlarmThread中的run()         AlarmThread本身是AlarmManagerService中一個繼承于Thread的內(nèi)嵌類：private class AlarmThread extends Thread其最核心的run()函數(shù)的主要動作流程圖如下：  我們分別來闡述上圖中的關(guān)鍵步驟。 3.3.1.2  waitForAlarm()&#

39、160;       首先，從上文的流程圖中可以看到，AlarmThread線程是在一個while(true)循環(huán)里不斷調(diào)用waitForAlarm()函數(shù)來等待底層alarm激發(fā)動作的。waitForAlarm()是一個native函數(shù)：private native int waitForAlarm(int fd);其對應(yīng)的C+層函數(shù)是android_server_AlarmManagerService_waitForAlarm()：【com_android_server_AlarmManagerService.cpp】static

40、 jint android_server_AlarmManagerService_waitForAlarm(JNIEnv* env, jobject obj, jint fd) int result = 0; do result = ioctl(fd, ANDROID_ALARM_WAIT); while (result < 0 && errno = EINTR); if (result < 0) ALOGE("Unable to wait on alarm: %sn", strerror(errno); return 0; return res

41、ult;        當(dāng)AlarmThread調(diào)用到ioctl()一句時，線程會阻塞住，直到底層激發(fā)alarm。而且所激發(fā)的alarm的類型會記錄到ioctl()的返回值中。這個返回值對外界來說非常重要，外界用它來判斷該遍歷哪個邏輯鬧鐘列表。 3.3.1.3  triggerAlarmsLocked()        一旦等到底層驅(qū)動的激發(fā)動作，AlarmThread會開始遍歷相應(yīng)的邏輯鬧鐘列表：ArrayList<Alarm&

42、gt; triggerList = new ArrayList<Alarm>();. . . . . .final long nowRTC = System.currentTimeMillis();final long nowELAPSED = SystemClock.elapsedRealtime();. . . . . .if (result & RTC_WAKEUP_MASK) != 0) triggerAlarmsLocked(mRtcWakeupAlarms, triggerList, nowRTC);if (result & RTC_MASK) != 0

43、) triggerAlarmsLocked(mRtcAlarms, triggerList, nowRTC);if (result & ELAPSED_REALTIME_WAKEUP_MASK) != 0) triggerAlarmsLocked(mElapsedRealtimeWakeupAlarms, triggerList, nowELAPSED);if (result & ELAPSED_REALTIME_MASK) != 0) triggerAlarmsLocked(mElapsedRealtimeAlarms, triggerList, nowELAPSED);&#

44、160;         可以看到，AlarmThread先創(chuàng)建了一個臨時的數(shù)組列表triggerList，然后根據(jù)result的值對相應(yīng)的alarm數(shù)組列表調(diào)用triggerAlarmsLocked()，一旦發(fā)現(xiàn)alarm數(shù)組列表中有某個alarm符合激發(fā)條件，就把它移到triggerList中。這樣，4條alarm數(shù)組列表中需要激發(fā)的alarm就匯總到triggerList數(shù)組列表中了。          接下來，只需遍歷

45、一遍triggerList就可以了：Iterator<Alarm> it = triggerList.iterator();while (it.hasNext() Alarm alarm = it.next(); . . . . . . alarm.operation.send(mContext, 0, mBackgroundIntent.putExtra(Intent.EXTRA_ALARM_COUNT, alarm.count), mResultReceiver, mHandler); / we have an active broadcast so stay awake. i

46、f (mBroadcastRefCount = 0) setWakelockWorkSource(alarm.operation); mWakeLock.acquire(); mInFlight.add(alarm.operation); mBroadcastRefCount+; mTriggeredUids.add(new Integer(alarm.uid); BroadcastStats bs = getStatsLocked(alarm.operation); if (bs.nesting = 0) bs.startTime = nowELAPSED; else bs.nesting+

47、; if (alarm.type = AlarmManager.ELAPSED_REALTIME_WAKEUP | alarm.type = AlarmManager.RTC_WAKEUP) bs.numWakeup+; ActivityManagerNative.noteWakeupAlarm(alarm.operation); 在上面的while循環(huán)中，每遍歷到一個Alarm對象，就執(zhí)行它的alarm.operation.send()函數(shù)。我們知道，alarm中記錄的operation就是當(dāng)初設(shè)置它時傳來的那個PendingIntent對象，現(xiàn)在開始執(zhí)行PendingIntent的send

48、()操作啦。          PendingIntent的send()函數(shù)代碼是：public void send(Context context, int code, Intent intent, OnFinished onFinished, Handler handler) throws CanceledException send(context, code, intent, onFinished, handler, null);調(diào)用了下面的send()函數(shù)：public void send(Co

49、ntext context, int code, Intent intent, OnFinished onFinished, Handler handler, String requiredPermission) throws CanceledException try String resolvedType = intent != null ? intent.resolveTypeIfNeeded(context.getContentResolver() : null; int res = mTarget.send(code, intent, resolvedType, onFinished

50、 != null ? new FinishedDispatcher(this, onFinished, handler) : null, requiredPermission); if (res < 0) throw new CanceledException(); catch (RemoteException e) throw new CanceledException(e); mTarget是個IPendingIntent代理接口，它對應(yīng)AMS（Activity Manager Service）中的某個PendingIntentRecord實體。需要說明的是，PendingInten

51、t的重要信息都是在AMS的PendingIntentRecord以及PendingIntentRecord.Key對象中管理的。AMS中有一張哈希表專門用于記錄所有可用的PendingIntentRecord對象。         相較起來，在創(chuàng)建PendingIntent對象時傳入的intent數(shù)組，其重要性并不太明顯。這種intent數(shù)組主要用于一次性啟動多個activity，如果你只是希望啟動一個activity或一個service，那么這個intent的內(nèi)容有可能在最終執(zhí)行PendingIntent的sen

52、d()動作時，被新傳入的intent內(nèi)容替換掉。          AMS中關(guān)于PendingIntentRecord哈希表的示意圖如下：AMS是整個Android平臺中最復(fù)雜的一個核心service了，所以我們不在這里做過多的闡述，有興趣的讀者可以參考其他相關(guān)文檔。 3.3.1.4  進一步處理“喚醒鬧鐘”        在AlarmThread.run()函數(shù)中while循環(huán)的最后，會進一步判斷，當(dāng)前激發(fā)的ala

53、rm是不是“喚醒鬧鐘”。如果鬧鐘類型為RTC_WAKEUP或ELAPSED_REALTIME_WAKEUP，那它就屬于“喚醒鬧鐘”，此時需要通知一下AMS：if (alarm.type = AlarmManager.ELAPSED_REALTIME_WAKEUP | alarm.type = AlarmManager.RTC_WAKEUP) bs.numWakeup+; ActivityManagerNative.noteWakeupAlarm(alarm.operation);這兩種alarm就是我們常說的0型和2型鬧鐘，它們和我們手機的續(xù)航時間息息相關(guān)。   

54、        AMS里的noteWakeupAlarm()比較簡單，只是在調(diào)用BatteryStatsService服務(wù)的相關(guān)動作，但是卻會導(dǎo)致機器的喚醒：public void noteWakeupAlarm(IIntentSender sender) if (!(sender instanceof PendingIntentRecord) return; BatteryStatsImpl stats = mBatteryStatsService.getActiveStatistics(); synchronized (

55、stats) if (mBatteryStatsService.isOnBattery() mBatteryStatsService.enforceCallingPermission(); PendingIntentRecord rec = (PendingIntentRecord)sender; int MY_UID = Binder.getCallingUid(); int uid = rec.uid = MY_UID ? Process.SYSTEM_UID : rec.uid; BatteryStatsImpl.Uid.Pkg pkg = stats.getPackageStatsLo

56、cked(uid, rec.key.packageName); pkg.incWakeupsLocked();           好了，說了這么多，我們還是畫一張AlarmThread示意圖作為總結(jié)：  3.3.2   說說AlarmManagerService中的mBroadcastRefCount        下面我們說說AlarmManagerService中的mBroadcastRefCount，之所以要說它，僅僅是因為我在修改AlarmManagerService代碼的時候，吃過它的虧。         我們先回顧一下處理triggerList列表的代碼，如下：Iterator<Alarm> it = trig