在Android系統(tǒng)上啟動(dòng)知乎app時(shí)會(huì)喚醒微信是什么原因？

知乎調(diào)用微信sdk中分享的相關(guān)接口，微信sdk的相關(guān)接口里面，給微信發(fā)送了一個(gè)廣播，微信app就被喚醒了，這不是知乎的主觀行為，而是微信的（而且結(jié)合實(shí)際的分析來看，這個(gè)應(yīng)該也算是正常的功能）。

十載的石鼓網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整石鼓建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)建站從事“石鼓網(wǎng)站設(shè)計(jì)”,“石鼓網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

1首先說一下app的被喚醒（自啟動(dòng)）機(jī)制。

app自啟動(dòng)，基本上都是依靠Android的廣播來實(shí)現(xiàn)的，而且是靜態(tài)注冊的廣播（在AndroidManifest.xml文件中進(jìn)行配置的廣播），發(fā)送廣播的方法在一般情況下是sendBroadcast。

2按照慣例，反編譯一下微信apk，然后搜索一下它能夠由哪些靜態(tài)廣播進(jìn)行喚醒，同時(shí)抓取廣播相關(guān)的log。

結(jié)合微信的AndroidManifest.xml文件以及抓取的log，可以知道相關(guān)的BroadcastReceiver是EntryReceiver，相關(guān)的action為

com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_REGISTER

com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_UNREGISTER

從其名稱上看，是和注冊/注銷相關(guān),具體接收到廣播之后做了哪些處理，這些就不贅述了。

3接下來分析知乎的代碼,搜索一下知乎反編譯之后的smali文件(sendBroadcast),其中只有一條是和微信相關(guān)的

Android-讓設(shè)備保持喚醒（激活）狀態(tài)

為了避免電池尿崩，Android會(huì)在沒有任務(wù)的時(shí)候快速進(jìn)入睡眠狀態(tài)。然而有時(shí)候應(yīng)用需要保持激活狀態(tài)。

你的需求決定了你選擇的方法。一般來說，盡可能選擇盡量輕量的方法滿足你的需求。下面幾個(gè)選項(xiàng)講述了如何選擇這些方法。

attribute:

簡而言之，通過設(shè)置 FLAG_KEEP_SCREEN_ON 標(biāo)記來是屏幕保持常亮，這是一種比較輕量級的方法，系統(tǒng)會(huì)根據(jù)App是否在前臺(tái)決定這個(gè)設(shè)置是否生效，如果是一般閱讀類App，電影App推薦使用這個(gè)。

To release the wake lock, call wakelock.release() . This releases your claim to the CPU. It's important to release a wake lock as soon as your app is finished using it to avoid draining the battery.

使用WAKE_LOCK保持CPU運(yùn)算，但是一般不推薦使用，除非你有非要完成的任務(wù)。絕對不要在Activity中使用，一般在Service中使用即可。具體使用方法已經(jīng)很清楚了，不譯了。

android app被殺死 alarmmanager能不能喚醒

可以喚醒的，但是得需要注意設(shè)置進(jìn)程屬性。

在Android中，AlarmManager提供了不受休眠狀態(tài)的系統(tǒng)定時(shí)功能，其一般使用方法如下。

1、創(chuàng)建一個(gè)BroadcastReceiver類的子類，接收定時(shí)器事件：

public class MyReceiver extends BroadcastReceiver {

......

}

2、在AndroidMenifest.xml中定義上述廣播事件接收類的定義：

receiver android:name=".MyReceiver"

/receiver

3、在程序中在需要時(shí)設(shè)置定時(shí)器：

Intent intent = new Intent(context,MyReceiver.class);

PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);

AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);

alarmManager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP , SystemClock.elapsedRealtime() + ms, pendingIntent);

經(jīng)過ms毫秒之后，MyReceiver會(huì)被調(diào)用，從而實(shí)現(xiàn)定時(shí)觸發(fā)。

Android 休眠喚醒頻繁問題分析的一些工具

大家都知道目前的手機(jī)，平板等電子設(shè)備耗電都比較大，Android系統(tǒng)因?yàn)闅v史和開源等原因，一直對耗電支持的不是很好。特別現(xiàn)在很多apk完全不care耗電，動(dòng)不動(dòng)給你裝上全家桶，還會(huì)相互間互相喚醒進(jìn)程，簡直就是流氓軟件。從現(xiàn)有的應(yīng)用來說，為了他們商業(yè)目的，有很多是類似要求長期后臺(tái)運(yùn)行的，或者定時(shí)運(yùn)行的，這些服務(wù)對耗電影響都非常大。

雖然Android每次版本大更新，都對其進(jìn)行了優(yōu)化，加入了很多特性。比如在Android 5.0加入了JobScheduler API機(jī)制（批處理）；在Android 6.0加入App Standby（應(yīng)用待機(jī)），Doze休眠機(jī)制;并且在Android7.0谷歌對Doze休眠機(jī)制做了進(jìn)一步的優(yōu)化，只要手動(dòng)在后臺(tái)刪掉應(yīng)用卡片，關(guān)屏后該應(yīng)用就會(huì)被很快深度休眠。

但是應(yīng)用開發(fā)工程師由于各種原因沒有使用新的特性，導(dǎo)致用戶感覺設(shè)備耗電還是很大。所以國內(nèi)很多手機(jī)廠家都有對android系統(tǒng)的耗電進(jìn)行優(yōu)化，從原理來說，目前這些廠家也是主要對兩方面進(jìn)行優(yōu)化：

1.減少定時(shí)休眠喚醒頻率，比如合并應(yīng)用申請的定時(shí)喚醒鬧鐘來喚醒已經(jīng)休眠的設(shè)備。

2.減少wake lock的頻率和時(shí)間。只要系統(tǒng)中存在任一有效的wake_lock，系統(tǒng)就不能進(jìn)入深度休眠，但可以進(jìn)行設(shè)備的淺度休眠操作。wake_lock一般在關(guān)閉lcd、tp但系統(tǒng)仍然需要正常運(yùn)行的情況下使用，比如聽歌、傳輸很大的文件等。

可通過如下打印來確認(rèn)喚醒源：

4[ 1321.989235] wakeup gpio0: 00000010

具體意思如下：

gpio0：表示是GPIO0

00000010：表示的是GPIO分組從高到低四個(gè)字節(jié)分別是：DCBA，每個(gè)字節(jié)的0-7bit就表示D7-D0 ?C7-C0 ?B7-B0 ?A7-A0.

從這里可以看出上面喚醒的GPIO是：GPIO0 PA4，對應(yīng)的是RTC的中斷腳。

通過dumpsys alarm命令打印可以看到哪個(gè)應(yīng)用喚醒次數(shù)比較多，和總共占用的時(shí)間：

這里的喚醒統(tǒng)計(jì)的是：應(yīng)用申請 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 的Alarm。不管系統(tǒng)是否在休眠，都會(huì)產(chǎn)生Alarm，所以這里的Alarm次數(shù)與第一章中說的kernel中統(tǒng)計(jì)的被RTC中斷喚醒的次數(shù)是匹配不上的，前都會(huì)大于后者。

看下Android系統(tǒng)定義的休眠喚醒不同的類型。

這個(gè)信息可以通過Project Volta里的工具h(yuǎn)istorian.py將其圖形化顯示。

先導(dǎo)出bugreport

將其轉(zhuǎn)換成圖形化結(jié)果（目前好像只有百度瀏覽器才能打開這個(gè)html）

簡單說明如下：

1.橫軸是時(shí)間

2. wifi_scan指的是wifi處于掃描

3. wifi_running指的是wifi打開狀態(tài)

4. screen指的是屏亮的狀態(tài)

5. plugged指的是插入外設(shè)

6. wake_lock指的是kernel中被鎖住的狀態(tài)

可通過screen與wake_lock來初步確認(rèn)系統(tǒng)是否被喚醒，如果screen是關(guān)的，然后又有wake_lock，也表明系統(tǒng)被喚醒并被鎖住一段時(shí)間。

把上層的喚醒和wifi喚醒都關(guān)了，測試了39個(gè)小時(shí)消耗30%電量

有以下幾個(gè)問題：

1.喚醒次數(shù)的確少了，但是healthd每10分鐘喚醒在圖上體現(xiàn)不出來

2.有2次喚醒后，系統(tǒng)被鎖住10多鐘才休眠下去

查看Alarm狀態(tài)，可以很明顯看到上層沒有再去wake up

但是驅(qū)動(dòng)中還看到有被RTC喚醒，經(jīng)過驗(yàn)證是healthd喚醒的，不插充電的時(shí)候10分鐘，插充電的時(shí)候1分鐘間隔。這個(gè)喚醒后就更新battery的信息，上層Baterry更新下，UI刷新下。

系統(tǒng)被鎖住10幾分鐘，通過log分析在wifi斷開的時(shí)候，gms剛好去連接服務(wù)器，通訊很久造成wake 比較久。從下面的信息可以判斷，系統(tǒng)目前wake lock線程最多的是gms線程。

Wake lock 在Android的電源管理系統(tǒng)中扮演一個(gè)核心的角色，wakelock是一種鎖的機(jī)制, 只要有task拿著這個(gè)鎖, 系統(tǒng)就無法進(jìn)入休眠, 可以被用戶態(tài)進(jìn)程和內(nèi)核線程獲得。這個(gè)鎖可以是有超時(shí)的或者是沒有超時(shí)的, 超時(shí)的鎖會(huì)在時(shí)間過去以后自動(dòng)解鎖。如果沒有鎖了或者超時(shí)了, 內(nèi)核就會(huì)啟動(dòng)標(biāo)準(zhǔn)Linux的那套休眠機(jī)制機(jī)制來進(jìn)入休眠。

提高電池續(xù)航，也就意味著減少系統(tǒng)和程序的電量消耗。為此 經(jīng)過測試發(fā)現(xiàn)，每次喚醒設(shè)備，1-2秒的時(shí)候，都會(huì)消耗2分鐘（個(gè)別應(yīng)用更久）的待機(jī)電量，可見每次喚醒設(shè)備的時(shí)候，不僅僅是點(diǎn)亮了屏幕，系統(tǒng)也在后臺(tái)處理很多事情。

電池消耗比較大，從系統(tǒng)的行為上分析，有兩個(gè)地方影響最大

1.系統(tǒng)在被喚醒的期間，被一些應(yīng)用wake lock比較久，造成很久時(shí)間無法再進(jìn)入二級休眠。

2.系統(tǒng)頻繁的被喚醒，系統(tǒng)被喚醒目前包含三個(gè)喚醒源

（1）.系統(tǒng)上層通過AlarmMananger的接口注冊rtc喚醒，

（2）.wifi芯片自動(dòng)喚醒，

（3）.電池healthd定頻喚醒。

所以如果應(yīng)用比較多的時(shí)候，應(yīng)用在喚醒期間動(dòng)作比較多，容易造成系統(tǒng)被wake lock，從而不會(huì)很快的進(jìn)入二級休眠。

通過上述的分析來看，系統(tǒng)可以優(yōu)化的地方有4個(gè)方面。

1).查看系統(tǒng)wake lock最多的線程，看能不能優(yōu)化。

2).系統(tǒng)上層過濾的應(yīng)用喚醒行為，從而降低喚醒頻率。AlarmManager包含四種類型定時(shí)策略，AlarmManager.ELAPSED_REALTIME、AlarmManager.ELAPSED_REALTIME_WAKEUP、AlarmManager.RTC、AlarmManager.RTC_WAKEUP、AlarmManager.POWER_OFF_WAKEUP。

其中應(yīng)用申請RTC_WAKEUP或ELAPSED_REALTIME_WAKEUP的Alarm在系統(tǒng)休眠的情況下會(huì)喚醒系統(tǒng)。通過建立白名單或者黑名單的方式過濾此種應(yīng)用的喚醒行為

3）. 定時(shí)批處理一批操作，壓縮硬件喚醒時(shí)間，就像心跳一樣，讓硬件充分休息，還有就是精確監(jiān)測應(yīng)用請求，智能安排請求執(zhí)行時(shí)間，讓資源利用最大化。

4).擴(kuò)大healthd的定頻喚醒間隔（適度不然造成電池電量不準(zhǔn)）

最后改一張調(diào)整過的電池狀態(tài)圖：