本文的應(yīng)用部分使用藍(lán)色表示

介紹服務(wù)開發(fā)：

介紹關(guān)于服務(wù)不被殺死，以及微信的永久駐村謎底；

第一次做關(guān)于服務(wù)的開發(fā)，看了很多文章，終于有個(gè)大概，任后開始寫程序測試并感受。在這里把學(xué)到的東西匯總一下，分享給大家。

隨便一搜索很對關(guān)于Android開發(fā)service的文章，所以這簡要說明。有一篇文章說的很好：“它是一種長生命周期的，沒有可視化界面，運(yùn)行于后臺(tái)的一種服務(wù)程序。比如我們播放音樂的 時(shí)候，有可能想邊聽音樂邊干些其他事情，當(dāng)退出播放音樂的應(yīng)用，如果不用Service，我 們就聽不到歌了，所以這時(shí)候就得用到Service了?！?/p>

我喜歡這個(gè)解釋。當(dāng)然除此之外，普通應(yīng)用使用了service使得整個(gè)應(yīng)用有好的耦合性（功能實(shí)現(xiàn)不互相依靠，相對比較獨(dú)立）。就從字面意思來理解，提供服務(wù)的功能部分一般適合開發(fā)成一個(gè)服務(wù)。比如藍(lán)牙連接服務(wù)。網(wǎng)絡(luò)通信服務(wù)。音樂播放服務(wù)。當(dāng)然我們自己開發(fā)的服務(wù)一般只給自己的應(yīng)用使用。

以下簡單匯總一下其他文章提到的精華部分，以及不全其他文章不足的地方。

1．Android service分類：startservice bindservice兩種方式。

startservice適合服務(wù)與應(yīng)用程序在一塊的情況，service和調(diào)用的應(yīng)用程序在同一個(gè)進(jìn)程里面。一般用于執(zhí)行更新，加載等費(fèi)事的操作。

Bindservice適用于完成一個(gè)獨(dú)立功能的部分。不如一個(gè)藍(lán)牙服務(wù)，需要藍(lán)牙服務(wù)的app只需要bind服務(wù)就可以使用這個(gè)服務(wù)，相對于startservice來說，bindservice給更多調(diào)用者服務(wù)。

生命周期，網(wǎng)上文章說，startservice調(diào)用者不在了，還可以繼續(xù)執(zhí)行，

而，bindservice可以支持好多調(diào)用者綁定，當(dāng)時(shí)一旦所有綁定者都死掉的化，bindservice也就退出了。當(dāng)然startservice調(diào)用的時(shí)候會(huì)啟動(dòng)服務(wù)，bindservice在調(diào)用的時(shí)候如果服務(wù)還沒有被啟動(dòng)則會(huì)啟動(dòng)服務(wù)。我在實(shí)際測試中，只要用清理工具清理了調(diào)用服務(wù)的軟件，調(diào)用者不在了，無論那種方式啟動(dòng)的服務(wù)都會(huì)被關(guān)閉。

下面專門說一下“永不退出的服務(wù)”

為了本文方便描述：先介紹測試中用到的兩種關(guān)閉服務(wù)的方法：

在用使用清理運(yùn)行軟件的功能作為關(guān)閉服務(wù)的第一種測試方法：向側(cè)面滑動(dòng)應(yīng)用就被關(guān)閉。即清理后臺(tái)運(yùn)行的軟件。

在測試時(shí)關(guān)閉服務(wù)的第二種測試方式：在“正在運(yùn)行的軟件”里點(diǎn)擊停止

關(guān)于周期網(wǎng)上有好多文章都是提到了“不死的服務(wù)”。很多文章提到了做出一個(gè)不死的服務(wù)。具體提到的方式有：

onStartCommand方法，返回START_STICKY

也就是在service的onstartcommand函數(shù)里返回這個(gè)值

@Override  

public int onStartCommand(Intent intent, int flags, int startId) {  

    flags = START_STICKY;  

    return super.onStartCommand(intent, flags, startId);  

}  

這個(gè)時(shí)候如果清理的是一個(gè)設(shè)置了START_STICKY的app，用方法一和二的時(shí)候服務(wù)都會(huì)被殺掉，后來我測試多了，發(fā)現(xiàn)在清理軟件里吧這個(gè)應(yīng)用加入白名單之后。在使用方法一的時(shí)候。acrivity被清理掉了，但是服務(wù)不會(huì)被清理。，使用方法二的時(shí)候，服務(wù)會(huì)被關(guān)閉，然后一段時(shí)間又會(huì)重新自動(dòng)出現(xiàn)。即START_STICKY產(chǎn)生的效果。

1． 設(shè)置服務(wù)為前臺(tái)進(jìn)程。startForeground(0x111, notification);具體操作過程查看其他文章。這里說一下效果，實(shí)現(xiàn)了前臺(tái)進(jìn)程其實(shí)就是在狀態(tài)欄顯示一個(gè)提示，應(yīng)該是用來告訴用戶所執(zhí)行的動(dòng)作在后臺(tái)還在進(jìn)行者，只能說service的優(yōu)先級提高了，在系統(tǒng)內(nèi)存不足的時(shí)候不會(huì)被第一個(gè)銷毀。但是用戶是可以通過方法一和二關(guān)閉這個(gè)服務(wù)的。（即調(diào)用者死掉，其服務(wù)也會(huì)被殺掉）。

在service的ondestroy里發(fā)送開啟服務(wù)的intent。以及開啟兩個(gè)service相互監(jiān)視，誰死掉就發(fā)送intent啟動(dòng)誰。本人沒有測試。由于看清了服務(wù)的一些使用特性，覺得開發(fā)這樣死活關(guān)不掉的應(yīng)用實(shí)在是不好。

還有就是要做成系統(tǒng)應(yīng)用，即把手機(jī)開啟root賬號，然后安裝app到系統(tǒng)到system/app目錄下。以使app獲取系統(tǒng)級別的啟動(dòng)權(quán)限。

還有人為了達(dá)到不是服務(wù)真是用心良苦。居然研究了從linux底層開啟進(jìn)程做起，因?yàn)槭强吹较裎⑿?，搜狐。說實(shí)話，很佩服這些人的頭腦以及技術(shù)。

以下這三篇文章講的很好關(guān)于這方面。

http://blog.csdn.net/ztemt_sw2/article/details/27101681

http://download.csdn.net/detail/mihang2/9283985

http://blog.csdn.net/huaxun66/article/details/53158162

總結(jié)一下自己為啥放棄開發(fā)一個(gè)不死的服務(wù)。

1． 需求方面：只有我的軟件在運(yùn)行的時(shí)候，我的服務(wù)才有存在的必要。

2． 我用的是魅族和華為手機(jī)做的測試，使用清理后臺(tái)應(yīng)用（即：測試方法一）只要activity被殺死，那么跟著其對應(yīng)的service也被殺死，對于網(wǎng)上來說的很多實(shí)現(xiàn)不被殺死方法都是因?yàn)槠錅y試用的手機(jī)系統(tǒng)比較原生，一般不會(huì)強(qiáng)制殺死一個(gè)沒有被調(diào)用的服務(wù)。當(dāng)然我也沒有在模擬器里運(yùn)行測試，就是在兩個(gè)手機(jī)上運(yùn)行測試，是這樣的。

3． 發(fā)現(xiàn)微信也不是不死的app。發(fā)現(xiàn)酷狗音樂這種播放音樂的軟件也會(huì)在activity死掉的時(shí)候，停止播放音樂。

4． 關(guān)于用戶體驗(yàn)的思考。對于普通應(yīng)用沒有必要在關(guān)閉activity之后仍然運(yùn)行service。

關(guān)于要不要開啟一個(gè)不死的服務(wù)：看到了一片英文文章，關(guān)于要不要做一個(gè)不死服務(wù)的必要性講的很好。

原文如下：

Diamonds Are Forever. ServicesAre Not.

By AndroidGuys

Android offers a “service” component. Unlike “activities”(screens) that interact directly with the user, services are more for managingbackground operations. The quintessential example is a music player, continuingto play tunes while its UI is not running.

Some developers then make the leap from “it is possible” to “itis a really good idea and should be used wherever”. Many people on AndroidGoogle Groups or StackOverflow propose to create services that “run forever”and ask how to prevent them from being killed off, and such.

These developers appear to ignore the costs of this approach:

·        While running, a serviceconsumes one process’ worth of memory, which is a substantial chunk, despiteDalvik’s heavy use of copy-on-write techniques to share memory betweenprocesses. A single service hogging memory is not that big of a deal; a dozensuch services will prevent the Android device from being usable. Hence, even ifthe memory footprint does not impact the developer directly, it impacts theusers indirectly — much like how pollution benefits the polluter with acorresponding cost to society.

·        While running, the servicewill need to fight Android, which will want to shut down the service if RAMgets too tight. While Android should, in principle, restart the service oncememory is plentiful again, the developer will have no control over the timingof this.

·        While running, the servicewill need to fight its own users, who may elect to shut down the service viathe Manage Applications screen, or through a third-party task manager. In thiscase, Android will not restart the service automatically.

·        The service will fall asleepwhen the device falls asleep and shuts down the CPU, which means even if theservice “runs forever”, it will not be able to run forever, unless it prevents the CPUfrom stopping, which wrecks battery life.

The recommended alternative is to use AlarmManager, as describedin a previous post and in finer Android programming books. Think of yourAndroid service as a cron job or Windows scheduled task, not as a persistentdaemon or Windows service. This approach works much better with Android’sframework and device limitations:

·        The service only uses memorywhen it is actually doing something, not just sitting around waiting.

·        The odds that Android willneed to kill off the service decreases, in part because the service will not be“old” and other services are likely to be killed first.

·        The odds that the user willneed to kill off the service decreases, because the service is less likely tocause any pollution that may cause the user problems.

·        The service can hold aWakeLock for the duration of its bit of work to keep the CPU running for ashort period

Now, the AlarmManager API is not the friendliest. Somedevelopers get tripped up while trying to handle multiple outstanding alarms.While there are ways to deal with this (via careful construction ofPendingIntent objects), sometimes you do not truly need more than one alarm. Ifyou have code that you want to run every 15 minutes, and other code that youwant to run every 24 hours, use one 15-minute alarm and trigger theonce-every-24-hours code every 96th time the 15-minute alarm goes off.

I encourage Android developers to try to avoid long-runningservices wherever possible. If you are uncertain how to design an app to avoidthe long-running service, post a clear description of the business scenario(not just low-level technical stuff) to the [android-developers] group or to StackOverflow with the #android tag. We can try to help you find ways ofachieving your business objectives in an Android-friendly fashion.

原文大體翻譯如下：

很多開發(fā)者為了達(dá)到服務(wù)隨時(shí)被啟動(dòng)起來的activity調(diào)用，而忽略了以下這些消耗：

在運(yùn)行的時(shí)候，盡管dalvik使用了用時(shí)復(fù)制技術(shù)來共享相同的內(nèi)存。但是一個(gè)存留的服務(wù)耗費(fèi)了一個(gè)進(jìn)程所占用的內(nèi)存。

在運(yùn)行的時(shí)候，RAM耗盡的時(shí)候，服務(wù)仍然對抗android系統(tǒng)不讓殺掉自己

在運(yùn)行的時(shí)候，服務(wù)要對抗關(guān)閉它的用戶。（用戶用應(yīng)用管理器或第三方管理器）

在運(yùn)行的時(shí)候，當(dāng)設(shè)備睡眠的時(shí)候，CPU被關(guān)閉。即服務(wù)也被關(guān)閉了，除非這個(gè)服務(wù)開啟阻擋手機(jī)睡眠選項(xiàng)。這就意味著電池電量的消耗。

因此推薦的方法是：使用AlarmManager。把你的服務(wù)當(dāng)成定時(shí)執(zhí)行任務(wù)或者計(jì)劃執(zhí)行任務(wù)。而不是一個(gè)永久的服務(wù)就像windows服務(wù)那樣。

以下這樣的設(shè)計(jì)方法會(huì)是的應(yīng)用更好的與android系統(tǒng)構(gòu)架和諧并存。

1.    只有服務(wù)真的在做事情的時(shí)候才開啟服務(wù)，不要讓服務(wù)坐著干等

2.    其實(shí)android殺死服務(wù)的幾率很低。因?yàn)橹灰阏谑褂梅?wù)，服務(wù)就不會(huì)變老。系統(tǒng)也就會(huì)殺掉其他服務(wù)而不是你正在使用的服務(wù)。

3.    用戶停掉服務(wù)的幾率也在減少。因?yàn)橐粋€(gè)好的服務(wù)不會(huì)給用戶造成影響，也不會(huì)給用戶導(dǎo)致問題。

4.    服務(wù)在其工作期間可以使用一段時(shí)間的WakeLock來保持CPU保持運(yùn)作。但用完時(shí)候馬上停用WakeLock。

我鼓勵(lì)android開發(fā)者在可能的情況下盡量避免開發(fā)長時(shí)間運(yùn)行的服務(wù)。

以上是原文精華。

那么說這樣設(shè)計(jì)的例子有哪些。下面我舉“酷狗音樂”的例子。

當(dāng)你打開“酷狗音樂”并且播放了一首音樂，音樂在播放，你按下home鍵，然后activity被放置在后天，這個(gè)時(shí)候，后臺(tái)服務(wù)來播放音樂。在播放的時(shí)候會(huì)在消息欄顯示一個(gè)正在播放的音樂狀態(tài)，以及控制按鈕，這個(gè)部分是把服務(wù)設(shè)置為前臺(tái)服務(wù)。提高了服務(wù)的優(yōu)先級。那么現(xiàn)在你使用我上面說的方法一，即把“酷狗音樂”的activity真正關(guān)閉之后，（調(diào)用者死掉）這個(gè)時(shí)候你會(huì)發(fā)現(xiàn)之前正在播放的音樂也會(huì)立即停止掉。即沒有使用者服務(wù)就立馬停掉。再進(jìn)一步使用方法二手動(dòng)關(guān)閉“酷狗音樂”的服務(wù)。音樂也會(huì)停止，并不再啟動(dòng)。這樣的設(shè)計(jì)即使遵循了上面那篇英文文章所描述的方法。就是系統(tǒng)和用戶其實(shí)在需要你服務(wù)的時(shí)候是不會(huì)把你的服務(wù)停掉的，除非系統(tǒng)和用戶真的就是要停止你，那么你這個(gè)app為啥還不讓停止的。

Android系統(tǒng)不會(huì)無端停止一個(gè)正在被使用的service。除非你這service自己就自己一個(gè)人硬抗，答案是你抗不住的。無論你用什么手段。除非系統(tǒng)說你是個(gè)好人放過你吧。

下面介紹微信為什么死不掉。先說結(jié)果。微信其實(shí)也是遵循英文文章提到的設(shè)計(jì)模式。即你有界面正在聊天的時(shí)候，服務(wù)也一直在后臺(tái)運(yùn)行。一般用戶關(guān)閉微信是使用home鍵。即activity放在了后臺(tái)，即“微信”中調(diào)用者的身份還在。

但是，但是接下來的就是神奇的部分，無論使用方法一還是方法二，都阻止不了微信繼續(xù)可以收到消息。為啥呢，微信到底是使用了什么手段。什么黑科技。而且后臺(tái)確實(shí)有兩個(gè)進(jìn)程，每個(gè)進(jìn)程里都有一個(gè)或幾個(gè)服務(wù)。而且用方法二關(guān)閉服務(wù)，很快服務(wù)又會(huì)重新出現(xiàn)。難道這個(gè)真是有兩個(gè)服務(wù)互相監(jiān)視，或者是有個(gè)非常底層的一個(gè)守護(hù)進(jìn)程來保持應(yīng)用不退出。

就在此時(shí)我沒有寫代碼，而是下載了一個(gè)號稱開啟守護(hù)進(jìn)程用jni開發(fā)的不死例子。

例子網(wǎng)址如下：http://download.csdn.net/detail/mihang2/9283985

下載下來并安裝到手機(jī)上，使用方法一個(gè)和二測試。方法二的時(shí)候，“正在運(yùn)行的應(yīng)用程序”界面確實(shí)可以顯示停止了，即在界面里面看不到這個(gè)服務(wù)的身影，但是從調(diào)試信息里看到服務(wù)仍然還在運(yùn)行者，雖然“正在運(yùn)行的應(yīng)用程序”里看不到服務(wù)的身影。然后使用方法一的測試結(jié)果是，服務(wù)馬上就死掉了。那么回頭繼續(xù)來總結(jié)一下，為什么方法二沒有真正停止服務(wù)呢，我想是因?yàn)殡m然activity被放置在后臺(tái)，它是它并沒有死，還在調(diào)用服務(wù)。所以服務(wù)并沒有被系統(tǒng)正真殺掉，系統(tǒng)知道調(diào)用者activity還在運(yùn)行。那么為啥用方法一，服務(wù)馬上就死掉了，因?yàn)橄到y(tǒng)發(fā)現(xiàn)你這activity不在了，留下你這個(gè)服務(wù)也沒啥用，浪費(fèi)資源和電池干脆把你立刻就停止。（當(dāng)然這里只服務(wù)和調(diào)用activity在同一個(gè)進(jìn)程里，即便不在一個(gè)進(jìn)程里，如果沒有調(diào)用者，這個(gè)服務(wù)仍然會(huì)被殺掉）

那么接著回來看“微信”進(jìn)程為啥可以不死。我們從另一個(gè)角度觀察微信的進(jìn)程。

首先從手機(jī)正在運(yùn)行的程序來看是如下結(jié)果：

從上面的截圖也可以看到這幾個(gè)進(jìn)程以及對應(yīng)的服務(wù)

大家都是Android開發(fā)者，我是在windows下開發(fā)。打開命令提示符，插入一個(gè)開啟了調(diào)試模式的手機(jī)，登錄運(yùn)行一個(gè)微信，輸入：“adb shell”這個(gè)時(shí)候你就進(jìn)入了android手機(jī)的命令行終端，（linux終端）?？梢詧?zhí)行l(wèi)inux命令。然后執(zhí)行top命令查看當(dāng)前運(yùn)行的進(jìn)程。執(zhí)行如下命令:top –n 1 | greptencent

可以看到微信有三個(gè)進(jìn)程，進(jìn)程pid分別是“4087”，“4221”，“29839”

可以從ps的結(jié)果發(fā)現(xiàn)，雖然是三個(gè)獨(dú)立的進(jìn)程，但是他們的父進(jìn)程都是396，也就是說三個(gè)進(jìn)程都是由同一個(gè)進(jìn)場所創(chuàng)建。

繼續(xù)往下看，現(xiàn)在查看我之前下載的那個(gè)關(guān)于使用的守護(hù)進(jìn)程（使用jni開發(fā)的那個(gè)）例子http://download.csdn.net/detail/mihang2/9283985。

運(yùn)行這個(gè)軟件，然后用top命令和ps命令看：

發(fā)現(xiàn)問題了嗎？，dameonsercice確實(shí)是有兩個(gè)進(jìn)程但是者兩個(gè)進(jìn)程的父進(jìn)程居然不一樣，而微信的是一樣的。難道這就是其所說的守護(hù)進(jìn)程。然后繼續(xù)分析，看到另一個(gè)父進(jìn)程不是396的進(jìn)程的父進(jìn)程為9846，而這個(gè)9846，是這個(gè)dameonservice進(jìn)程的pid進(jìn)程。也就是說。這個(gè)守護(hù)進(jìn)程是有原來的進(jìn)程創(chuàng)建而來的。，因此當(dāng)我使用方法一關(guān)掉activity的時(shí)候，相當(dāng)于把父進(jìn)程銷毀了，但是根據(jù)linux的知識(shí)，這個(gè)自進(jìn)程不會(huì)被銷毀，應(yīng)該會(huì)被init進(jìn)程收留成為正真linux下的守護(hù)進(jìn)程，我查看了一下其它父進(jìn)程為1的進(jìn)程（linux守護(hù)進(jìn)程）都是系統(tǒng)的軟件，沒有任何app是屬于守護(hù)進(jìn)程的。應(yīng)該是Android構(gòu)架限制了吧。所以這個(gè)作者做的守護(hù)進(jìn)程方法，經(jīng)過測試，其實(shí)是沒有成功的。

先不管這個(gè)，，先看看為啥其中一個(gè)父進(jìn)程和微信的父進(jìn)程一樣呢。所以來看一下，關(guān)于這個(gè)“396”進(jìn)程，首先根據(jù)linux，子進(jìn)程都是被父進(jìn)程創(chuàng)建（fork）而來的，也就是說微信和這個(gè)應(yīng)用都有同一個(gè)父進(jìn)程。使用ps | grep 396和 top –n 1 | grep396查看結(jié)果如下：

原來，所有運(yùn)行的安卓app都是由zygote這個(gè)進(jìn)程創(chuàng)建而來。仔細(xì)查看zygote的那一行?？梢钥吹狡鋚id即進(jìn)程id為396。而其父進(jìn)程為1，也就是說zygote是一個(gè)正真意義上的linux守護(hù)進(jìn)程。又學(xué)習(xí)了一下。

最后這里給解釋一下微信的這么多進(jìn)程到底是怎么來的，由于以上測試可知，如果用jni用c++開啟來開啟一個(gè)進(jìn)程的話，那么其父進(jìn)程就不會(huì)是zygote。但是現(xiàn)在我們看到的微信所有父進(jìn)程都是zygote也就是說微信沒有使用jni里面創(chuàng)建進(jìn)程。也就否定了其他博客對微信開啟什么守護(hù)進(jìn)程的猜想了。

那么微信的這些進(jìn)程到底是怎么來的呢：

我是從這篇文章看到的相關(guān)信息

http://www./a/anzhuokaifa/androidkaifa/2015/0403/2686.html

文章提到了Androidmannifest.xml里面service部分的process元素。一下是一部分的原文：

理解Android進(jìn)程

你應(yīng)該已經(jīng)知道了,安卓系統(tǒng)是基于Linux的。因此,每個(gè)應(yīng)用程序都運(yùn)行在其本身的進(jìn)程(擁有一個(gè)獨(dú)一無二的PID)中:這允許應(yīng)用運(yùn)行在一個(gè)相互隔離的環(huán)境中,不能被其他應(yīng)用程序/進(jìn)程干擾。通常來說,當(dāng)你想啟動(dòng)一個(gè)應(yīng)用程序,Android創(chuàng)建一個(gè)進(jìn)程(從Zygote中fork出來的),并 創(chuàng)建一個(gè)主線程，然后開始運(yùn)行Main Activity。

你可能不知道的是,你可以指定應(yīng)用程序的一些組件運(yùn)行在不同的進(jìn)程中，而不是那個(gè)被用于啟動(dòng)應(yīng)用程序的。先來看一下這個(gè)Nice的屬性:

android:process

該進(jìn)程屬性可用于activities、services、content providers和broadcast receivers 和指定的進(jìn)程中應(yīng)該執(zhí)行的特定組件。

在這個(gè)例子中,我指定MusicService必須執(zhí)行在一個(gè)單獨(dú)的“music”的進(jìn)程:

<manifest ...>

  <application

    android:icon="@drawable/ic_launcher"

    android:label="@string/app_name"

    android:theme="@style/Theme.Main" >

    <activity

      android:name=".MusicActivity"

      />

    <service

      android:name=".MusicService"

      android:process=":music"

    />

  </application>

</manifest>

然后我們看反編譯微信里的Androidmannifest.xml，當(dāng)然只反編譯了資源文件。

從內(nèi)容可以看到其中我們在之前看到的push進(jìn)程是怎樣來的。

也就證明出了，微信開啟進(jìn)程的方法。

接下來看看“微信”在面對兩種測試方法其進(jìn)程到底是怎樣的。（真正的揭秘微信不死的面紗）

先從adb shell 命令里執(zhí)行top –n 1 | grep tencent來查看一下微信正常運(yùn)行是的狀態(tài)。

現(xiàn)在使用方法二來停止服務(wù)：

我把“正在運(yùn)行”里面的可以看到的服務(wù)都關(guān)閉了，然后運(yùn)行top –n 1 | grep tencent結(jié)果如下：

可見服務(wù)并沒有變化，當(dāng)然按我的理解是，因?yàn)橛幸粋€(gè)后臺(tái)的activity正在使用服務(wù)，所以服務(wù)沒有被系統(tǒng)銷毀了，因?yàn)槲覀冏约旱臏y試服務(wù)如果被方法二關(guān)閉的化，我們看到調(diào)試信息里，服務(wù)仍然在運(yùn)行，也就是就像我們現(xiàn)在看到的，其實(shí)服務(wù)進(jìn)程并沒有被銷毀。

然后使用方法一來停止服務(wù)：

結(jié)果是，這幾條服務(wù)還在，這也就是人們感覺對微信的深不可測，沒有被銷毀。雖然，我已經(jīng)把放置到后臺(tái)的activity銷毀了，但是服務(wù)沒停。那么接下來我是怎么樣發(fā)現(xiàn)微信的不死秘密的呢。

答案如下：

我以我的魅族手機(jī)為例：可以看到加速的時(shí)候（也就是我的測試方式一）其實(shí)并沒有清除微信的任何進(jìn)程，右面是華為的，華為的沒有找到具體顯示吧微信放在白名單的。但是很顯然華為系統(tǒng)是有一個(gè)“內(nèi)存加速白名單”，微信這樣的應(yīng)用就在白名單里。

再看下面?zhèn)z張圖。顯示了魅族和華為的加速白名單。微信默認(rèn)就在里面。

那么按照我看到這個(gè)之后的猜想，把微信從白名單里去掉或者把我自己開發(fā)的軟件放到白名單都可以驗(yàn)證“微信”殺不掉的原因。

現(xiàn)在我吧微信從白名單里移除，然后使用方法一來測試：

可以看到，微信的進(jìn)程都沒有了，當(dāng)然是死掉了。

知道微信為啥不死了吧，其實(shí)我查找文章的時(shí)候，看到一個(gè)論壇提到了說“系統(tǒng)給微信設(shè)置了白名單，其實(shí)微信沒有做什么黑科技”，我當(dāng)時(shí)感覺不信，就此折騰了幾天。

當(dāng)然，微信有好多服務(wù)和進(jìn)程，只有當(dāng)服務(wù)需要執(zhí)行功能的時(shí)候，我們才可以看到服務(wù)進(jìn)程，也就是說微信把暫時(shí)不用的服務(wù)都停止掉了。我的測試不能排除微信使用了雙服務(wù)互相啟動(dòng)，雖然微信在系統(tǒng)白名單里。

當(dāng)然可以從Androidmannifest.xml看出微信使用了開機(jī)啟動(dòng)，和激活屏幕啟動(dòng)。當(dāng)然從華為的那張截圖里可以看到微信使用wakelock，就是微信在關(guān)閉屏幕之后還在后天運(yùn)行。

關(guān)于wakelock詳細(xì)內(nèi)容查看以下文章。

http://blog.sina.com.cn/s/blog_4ad7c2540101n2k2.html

其中有個(gè)選項(xiàng)為：PARTIAL_WAKE_LOCK:保持CPU 運(yùn)轉(zhuǎn)，屏幕和鍵盤燈有可能是關(guān)閉的。