詳解Android進程?;畹姆椒?/h1>
更新時間:2017年03月06日 09:46:02 作者:lianghe
本篇文章主要介紹了Android進程?;?,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
關于 Android 平臺的進程?;钸@一塊,想必是所有 Android 開發(fā)者矚目的內容之一。你到網上搜 Android 進程?;?,可以搜出各種各樣神乎其技的做法,絕大多數(shù)都是極其不靠譜。前段時間,Github還出現(xiàn)了一個很火的“黑科技”進程?;顜欤暦Q可以做到進程永生不死。
懷著學習和膜拜的心情進去Github圍觀,結果發(fā)現(xiàn)很多人提了 Issue 說各種各樣的機子無法成功?;?。
看到這里,我瞬間就放心了。坦白的講,我是真心不希望有這種黑科技存在的,它只會滋生更多的流氓應用,拖垮我大 Android 平臺的流暢性。
扯了這么多,接下來就直接進入本文的正題,談談關于進程?;畹闹R。提前聲明以下四點
- 本文是本人開發(fā) Android 至今綜合各方資料所得
- 不以節(jié)能來維持進程保活的手段,都是耍流氓
- 本文不是教你做永生不死的進程,如果指望實現(xiàn)進程永生不死,請忽略本文
- 本文有錯誤的地方,歡迎留下評論互相探討(拍磚請輕拍)
?;钍侄?/strong>
當前業(yè)界的Android進程?;钍侄沃饕譃?黑、白、灰 三種,其大致的實現(xiàn)思路如下:
黑色保活:不同的app進程,用廣播相互喚醒(包括利用系統(tǒng)提供的廣播進行喚醒)
白色?;睿簡忧芭_Service
灰色?;睿豪孟到y(tǒng)的漏洞啟動前臺Service
黑色?;?/strong>
所謂黑色?;?,就是利用不同的app進程使用廣播來進行相互喚醒。舉個3個比較常見的場景:
場景1:開機,網絡切換、拍照、拍視頻時候,利用系統(tǒng)產生的廣播喚醒app
場景2:接入第三方SDK也會喚醒相應的app進程,如微信sdk會喚醒微信,支付寶sdk會喚醒支付寶。由此發(fā)散開去,就會直接觸發(fā)了下面的 場景3
場景3:假如你手機里裝了支付寶、淘寶、天貓、UC等阿里系的app,那么你打開任意一個阿里系的app后,有可能就順便把其他阿里系的app給喚醒了。(只是拿阿里打個比方,其實BAT系都差不多)
沒錯,我們的Android手機就是一步一步的被上面這些場景給拖卡機的。
針對場景1,估計Google已經開始意識到這些問題,所以在最新的Android N取消了 ACTION_NEW_PICTURE(拍照),ACTION_NEW_VIDEO(拍視頻),CONNECTIVITY_ACTION(網絡切換)等三種廣播,無疑給了很多app沉重的打擊。我猜他們的心情是下面這樣的
而開機廣播的話,記得有一些定制ROM的廠商早已經將其去掉。
針對場景2和場景3,因為調用SDK喚醒app進程屬于正常行為,此處不討論。但是在借助LBE分析app之間的喚醒路徑的時候,發(fā)現(xiàn)了兩個問題:
1.很多推送SDK也存在喚醒app的功能
2.app之間的喚醒路徑真是多,且錯綜復雜
我把自己使用的手機測試結果給大家圍觀一下(我的手機是小米4C,刷了原生的Android5.1系統(tǒng),且已經獲得Root權限才能查看這些喚醒路徑)

15組相互喚醒路徑

全部喚醒路徑
我們直接點開 簡書 的喚醒路徑進行查看

簡書喚醒路徑
可以看到以上3條喚醒路徑,但是涵蓋的喚醒應用總數(shù)卻達到了23+43+28款,數(shù)目真心驚人。請注意,這只是我手機上一款app的喚醒路徑而已,到了這里是不是有點細思極恐。
當然,這里依然存在一個疑問,就是LBE分析這些喚醒路徑和互相喚醒的應用是基于什么思路,我們不得而知。所以我們也無法確定其分析結果是否準確,如果有LBE的童鞋看到此文章,不知可否告知一下思路呢?但是,手機打開一個app就喚醒一大批,我自己可是親身體驗到這種酸爽的......

白色?;?/strong>
白色?;钍侄畏浅:唵?,就是調用系統(tǒng)api啟動一個前臺的Service進程,這樣會在系統(tǒng)的通知欄生成一個Notification,用來讓用戶知道有這樣一個app在運行著,哪怕當前的app退到了后臺。如下方的LBE和QQ音樂這樣:

灰色?;?/strong>
灰色?;?,這種保活手段是應用范圍最廣泛。它是利用系統(tǒng)的漏洞來啟動一個前臺的Service進程,與普通的啟動方式區(qū)別在于,它不會在系統(tǒng)通知欄處出現(xiàn)一個Notification,看起來就如同運行著一個后臺Service進程一樣。這樣做帶來的好處就是,用戶無法察覺到你運行著一個前臺進程(因為看不到Notification),但你的進程優(yōu)先級又是高于普通后臺進程的。那么如何利用系統(tǒng)的漏洞呢,大致的實現(xiàn)思路和代碼如下:
思路一:API < 18,啟動前臺Service時直接傳入new Notification();
思路二:API >= 18,同時啟動兩個id相同的前臺Service,然后再將后啟動的Service做stop處理;
public class GrayService extends Service {
private final static int GRAY_SERVICE_ID = 1001;
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
if (Build.VERSION.SDK_INT < 18) {
startForeground(GRAY_SERVICE_ID, new Notification());//API < 18 ,此方法能有效隱藏Notification上的圖標
} else {
Intent innerIntent = new Intent(this, GrayInnerService.class);
startService(innerIntent);
startForeground(GRAY_SERVICE_ID, new Notification());
}
return super.onStartCommand(intent, flags, startId);
}
...
...
/**
* 給 API >= 18 的平臺上用的灰色?;钍侄?
*/
public static class GrayInnerService extends Service {
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
startForeground(GRAY_SERVICE_ID, new Notification());
stopForeground(true);
stopSelf();
return super.onStartCommand(intent, flags, startId);
}
}
}
代碼大致就是這樣,能讓你神不知鬼不覺的啟動著一個前臺Service。其實市面上很多app都用著這種灰色?;畹氖侄?,什么?你不信?好吧,我們來驗證一下。流程很簡單,打開一個app,看下系統(tǒng)通知欄有沒有一個 Notification,如果沒有,我們就進入手機的adb shell模式,然后輸入下面的shell命令
dumpsys activity services PackageName
打印出指定包名的所有進程中的Service信息,看下有沒有 isForeground=true 的關鍵信息。如果通知欄沒有看到屬于app的 Notification 且又看到 isForeground=true 則說明了,此app利用了這種灰色保活的手段。
下面分別是我手機上微信、qq、支付寶、陌陌的測試結果,大家有興趣也可以自己驗證一下。

微信

手Q

支付寶

陌陌
其實Google察覺到了此漏洞的存在,并逐步進行封堵。這就是為什么這種?;罘绞椒?API >= 18 和 API < 18 兩種情況,從Android5.0的ServiceRecord類的postNotification函數(shù)源代碼中可以看到這樣的一行注釋

當某一天 API >= 18 的方案也失效的時候,我們就又要另謀出路了。需要注意的是,使用灰色?;畈⒉淮碇愕腟ervice就永生不死了,只能說是提高了進程的優(yōu)先級。如果你的app進程占用了大量的內存,按照回收進程的策略,同樣會干掉你的app。感興趣于灰色?;钍侨绾卫孟到y(tǒng)漏洞不顯示 Notification 的童鞋,可以研究一下系統(tǒng)的 ServiceRecord、NotificationManagerService 等相關源代碼,因為不是本文的重點,所以不做詳述。
嘮叨的分割線
到這里基本就介紹完了 黑、白、灰 三種實現(xiàn)方式,僅僅從代碼層面去講?;钍遣粔虻模蚁M軌蛲ㄟ^系統(tǒng)的進程回收機制來理解?;睿@樣能夠讓我們更好的避免踩到進程被殺的坑。
進程回收機制
熟悉Android系統(tǒng)的童鞋都知道,系統(tǒng)出于體驗和性能上的考慮,app在退到后臺時系統(tǒng)并不會真正的kill掉這個進程,而是將其緩存起來。打開的應用越多,后臺緩存的進程也越多。在系統(tǒng)內存不足的情況下,系統(tǒng)開始依據自身的一套進程回收機制來判斷要kill掉哪些進程,以騰出內存來供給需要的app。這套殺進程回收內存的機制就叫 Low Memory Killer ,它是基于Linux內核的 OOM Killer(Out-Of-Memory killer)機制誕生。
了解完 Low Memory Killer,再科普一下oom_adj。什么是oom_adj?它是linux內核分配給每個系統(tǒng)進程的一個值,代表進程的優(yōu)先級,進程回收機制就是根據這個優(yōu)先級來決定是否進行回收。對于oom_adj的作用,你只需要記住以下幾點即可:
- 進程的oom_adj越大,表示此進程優(yōu)先級越低,越容易被殺回收;越小,表示進程優(yōu)先級越高,越不容易被殺回收
- 普通app進程的oom_adj>=0,系統(tǒng)進程的oom_adj才可能<0
那么我們如何查看進程的oom_adj值呢,需要用到下面的兩個shell命令
ps | grep PackageName //獲取你指定的進程信息

這里是以我寫的demo代碼為例子,紅色圈中部分別為下面三個進程的ID
- UI進程:com.clock.daemon
- 普通后臺進程:com.clock.daemon:bg
- 灰色?;钸M程:com.clock.daemon:gray
當然,這些進程的id也可以通過AndroidStudio獲得

接著我們來再來獲取三個進程的oom_adj
cat /proc/進程ID/oom_adj

從上圖可以看到UI進程和灰色?;頢ervice進程的oom_adj=0,而普通后臺進程oom_adj=15。到這里估計你也能明白,為什么普通的后臺進程容易被回收,而前臺進程則不容易被回收了吧。但明白這個還不夠,接著看下圖

上面是我把app切換到后臺,再進行一次oom_adj的檢驗,你會發(fā)現(xiàn)UI進程的值從0變成了6,而灰色?;畹腟ervice進程則從0變成了1。這里可以觀察到,app退到后臺時,其所有的進程優(yōu)先級都會降低。但是UI進程是降低最為明顯的,因為它占用的內存資源最多,系統(tǒng)內存不足的時候肯定優(yōu)先殺這些占用內存高的進程來騰出資源。所以,為了盡量避免后臺UI進程被殺,需要盡可能的釋放一些不用的資源,尤其是圖片、音視頻之類的。
從Android官方文檔中,我們也能看到優(yōu)先級從高到低列出了這些不同類型的進程:Foreground process、Visible process、Service process、Background process、Empty process。
總結(文末有福利)
絮絮叨叨寫完了這么多,最后來做個小小的總結?;貧w到開篇提到QQ進程不死的問題,我也曾認為存在這樣一種技術??上野咽謾Croot后,殺掉QQ進程之后就再也起不來了。有些手機廠商把這些知名的app放入了自己的白名單中,保證了進程不死來提高用戶體驗(如微信、QQ、陌陌都在小米的白名單中)。如果從白名單中移除,他們終究還是和普通app一樣躲避不了被殺的命運,為了盡量避免被殺,還是老老實實去做好優(yōu)化工作吧。
所以,進程?;畹母痉桨附K究還是回到了性能優(yōu)化上,進程永生不死終究是個徹頭徹尾的偽命題!
補充更新
有童鞋問,在華為的機子上發(fā)現(xiàn)微信和手Q的UI進程退到后臺,oom_adj的值一點都沒有變,是不是有什么黑科技在其中。為此,我稍稍驗證了一下,驗證方式就是把demo工程的包名改成手機QQ的,編譯運行在華為的機子上,發(fā)現(xiàn)我的進程怎么殺也都是不死的,退到后臺oom_adj的值同樣不發(fā)生變化,而恢復原來的包名就不行了。所以,你懂的,手Q就在華為機子的白名單中。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關文章
-
Android如何實現(xiàn)社交應用中的評論與回復功能詳解
目前,各種App的社區(qū)或者用戶曬照片、發(fā)說說的地方,都提供了評論功能,為了更好地學習,自己把這個功能實現(xiàn)了一下,下面這篇文章主要給大家介紹了關于Android如何實現(xiàn)社交應用中的評論與回復功能的相關資料,需要的朋友可以參考下 2018-07-07
-
Android JSON數(shù)據與實體類之間的相互轉化(GSON的用法)
這篇文章主要介紹了Android JSON數(shù)據與實體類之間的相互轉化(GSON的用法),非常具有實用價值,需要的朋友可以參考下。 2017-01-01
-
基于android樣式與主題(style&theme)的詳解
本篇文章是對android中的樣式與主題(style&theme)進行了詳細的分析介紹,需要的朋友參考下 2013-06-06
-
Android實現(xiàn)音樂播放進度條傳遞信息的兩種方式(在service和activity中)
這篇文章主要介紹了Android:在service和activity之中,實現(xiàn)音樂播放進度條傳遞信息的兩種方式,MediaPlayer做音樂播放器采坑以及解決辦法,需要的朋友可以參考下 2020-05-05
-
Android搜索框(SearchView)的功能和用法詳解
這篇文章主要為大家詳細介紹了Android搜索框SearchView的功能和用法,具有一定的參考價值,感興趣的小伙伴們可以參考一下 2017-05-05
-
android 字體顏色選擇器(ColorPicker)介紹
本文將詳細介紹android 字體顏色選擇器(ColorPicker)需要了解更多的朋友可以參考下 2012-11-11
-
Android滑動到頂部和底部時出現(xiàn)的陰影如何去掉
本文給大家介紹android滑動到頂部和底部時出現(xiàn)的陰影去掉的解決方法,本文還涉及到listview各個屬性的用法介紹,非常不錯,具有參考借鑒價值,感興趣的朋友一起看看吧 2016-10-10
最新評論
關于 Android 平臺的進程?;钸@一塊,想必是所有 Android 開發(fā)者矚目的內容之一。你到網上搜 Android 進程?;?,可以搜出各種各樣神乎其技的做法,絕大多數(shù)都是極其不靠譜。前段時間,Github還出現(xiàn)了一個很火的“黑科技”進程?;顜欤暦Q可以做到進程永生不死。
懷著學習和膜拜的心情進去Github圍觀,結果發(fā)現(xiàn)很多人提了 Issue 說各種各樣的機子無法成功?;?。
看到這里,我瞬間就放心了。坦白的講,我是真心不希望有這種黑科技存在的,它只會滋生更多的流氓應用,拖垮我大 Android 平臺的流暢性。
扯了這么多,接下來就直接進入本文的正題,談談關于進程?;畹闹R。提前聲明以下四點
- 本文是本人開發(fā) Android 至今綜合各方資料所得
- 不以節(jié)能來維持進程保活的手段,都是耍流氓
- 本文不是教你做永生不死的進程,如果指望實現(xiàn)進程永生不死,請忽略本文
- 本文有錯誤的地方,歡迎留下評論互相探討(拍磚請輕拍)
?;钍侄?/strong>
當前業(yè)界的Android進程?;钍侄沃饕譃?黑、白、灰 三種,其大致的實現(xiàn)思路如下:
黑色保活:不同的app進程,用廣播相互喚醒(包括利用系統(tǒng)提供的廣播進行喚醒)
白色?;睿簡忧芭_Service
灰色?;睿豪孟到y(tǒng)的漏洞啟動前臺Service
黑色?;?/strong>
所謂黑色?;?,就是利用不同的app進程使用廣播來進行相互喚醒。舉個3個比較常見的場景:
場景1:開機,網絡切換、拍照、拍視頻時候,利用系統(tǒng)產生的廣播喚醒app
場景2:接入第三方SDK也會喚醒相應的app進程,如微信sdk會喚醒微信,支付寶sdk會喚醒支付寶。由此發(fā)散開去,就會直接觸發(fā)了下面的 場景3
場景3:假如你手機里裝了支付寶、淘寶、天貓、UC等阿里系的app,那么你打開任意一個阿里系的app后,有可能就順便把其他阿里系的app給喚醒了。(只是拿阿里打個比方,其實BAT系都差不多)
沒錯,我們的Android手機就是一步一步的被上面這些場景給拖卡機的。
針對場景1,估計Google已經開始意識到這些問題,所以在最新的Android N取消了 ACTION_NEW_PICTURE(拍照),ACTION_NEW_VIDEO(拍視頻),CONNECTIVITY_ACTION(網絡切換)等三種廣播,無疑給了很多app沉重的打擊。我猜他們的心情是下面這樣的
而開機廣播的話,記得有一些定制ROM的廠商早已經將其去掉。
針對場景2和場景3,因為調用SDK喚醒app進程屬于正常行為,此處不討論。但是在借助LBE分析app之間的喚醒路徑的時候,發(fā)現(xiàn)了兩個問題:
1.很多推送SDK也存在喚醒app的功能
2.app之間的喚醒路徑真是多,且錯綜復雜
我把自己使用的手機測試結果給大家圍觀一下(我的手機是小米4C,刷了原生的Android5.1系統(tǒng),且已經獲得Root權限才能查看這些喚醒路徑)
15組相互喚醒路徑
全部喚醒路徑
我們直接點開 簡書 的喚醒路徑進行查看
簡書喚醒路徑
可以看到以上3條喚醒路徑,但是涵蓋的喚醒應用總數(shù)卻達到了23+43+28款,數(shù)目真心驚人。請注意,這只是我手機上一款app的喚醒路徑而已,到了這里是不是有點細思極恐。
當然,這里依然存在一個疑問,就是LBE分析這些喚醒路徑和互相喚醒的應用是基于什么思路,我們不得而知。所以我們也無法確定其分析結果是否準確,如果有LBE的童鞋看到此文章,不知可否告知一下思路呢?但是,手機打開一個app就喚醒一大批,我自己可是親身體驗到這種酸爽的......
白色?;?/strong>
白色?;钍侄畏浅:唵?,就是調用系統(tǒng)api啟動一個前臺的Service進程,這樣會在系統(tǒng)的通知欄生成一個Notification,用來讓用戶知道有這樣一個app在運行著,哪怕當前的app退到了后臺。如下方的LBE和QQ音樂這樣:
灰色?;?/strong>
灰色?;?,這種保活手段是應用范圍最廣泛。它是利用系統(tǒng)的漏洞來啟動一個前臺的Service進程,與普通的啟動方式區(qū)別在于,它不會在系統(tǒng)通知欄處出現(xiàn)一個Notification,看起來就如同運行著一個后臺Service進程一樣。這樣做帶來的好處就是,用戶無法察覺到你運行著一個前臺進程(因為看不到Notification),但你的進程優(yōu)先級又是高于普通后臺進程的。那么如何利用系統(tǒng)的漏洞呢,大致的實現(xiàn)思路和代碼如下:
思路一:API < 18,啟動前臺Service時直接傳入new Notification();
思路二:API >= 18,同時啟動兩個id相同的前臺Service,然后再將后啟動的Service做stop處理;
public class GrayService extends Service { private final static int GRAY_SERVICE_ID = 1001; @Override public int onStartCommand(Intent intent, int flags, int startId) { if (Build.VERSION.SDK_INT < 18) { startForeground(GRAY_SERVICE_ID, new Notification());//API < 18 ,此方法能有效隱藏Notification上的圖標 } else { Intent innerIntent = new Intent(this, GrayInnerService.class); startService(innerIntent); startForeground(GRAY_SERVICE_ID, new Notification()); } return super.onStartCommand(intent, flags, startId); } ... ... /** * 給 API >= 18 的平臺上用的灰色?;钍侄? */ public static class GrayInnerService extends Service { @Override public int onStartCommand(Intent intent, int flags, int startId) { startForeground(GRAY_SERVICE_ID, new Notification()); stopForeground(true); stopSelf(); return super.onStartCommand(intent, flags, startId); } } }
代碼大致就是這樣,能讓你神不知鬼不覺的啟動著一個前臺Service。其實市面上很多app都用著這種灰色?;畹氖侄?,什么?你不信?好吧,我們來驗證一下。流程很簡單,打開一個app,看下系統(tǒng)通知欄有沒有一個 Notification,如果沒有,我們就進入手機的adb shell模式,然后輸入下面的shell命令
dumpsys activity services PackageName
打印出指定包名的所有進程中的Service信息,看下有沒有 isForeground=true 的關鍵信息。如果通知欄沒有看到屬于app的 Notification 且又看到 isForeground=true 則說明了,此app利用了這種灰色保活的手段。
下面分別是我手機上微信、qq、支付寶、陌陌的測試結果,大家有興趣也可以自己驗證一下。
微信
手Q
支付寶
陌陌
其實Google察覺到了此漏洞的存在,并逐步進行封堵。這就是為什么這種?;罘绞椒?API >= 18 和 API < 18 兩種情況,從Android5.0的ServiceRecord類的postNotification函數(shù)源代碼中可以看到這樣的一行注釋
當某一天 API >= 18 的方案也失效的時候,我們就又要另謀出路了。需要注意的是,使用灰色?;畈⒉淮碇愕腟ervice就永生不死了,只能說是提高了進程的優(yōu)先級。如果你的app進程占用了大量的內存,按照回收進程的策略,同樣會干掉你的app。感興趣于灰色?;钍侨绾卫孟到y(tǒng)漏洞不顯示 Notification 的童鞋,可以研究一下系統(tǒng)的 ServiceRecord、NotificationManagerService 等相關源代碼,因為不是本文的重點,所以不做詳述。
嘮叨的分割線
到這里基本就介紹完了 黑、白、灰 三種實現(xiàn)方式,僅僅從代碼層面去講?;钍遣粔虻模蚁M軌蛲ㄟ^系統(tǒng)的進程回收機制來理解?;睿@樣能夠讓我們更好的避免踩到進程被殺的坑。
進程回收機制
熟悉Android系統(tǒng)的童鞋都知道,系統(tǒng)出于體驗和性能上的考慮,app在退到后臺時系統(tǒng)并不會真正的kill掉這個進程,而是將其緩存起來。打開的應用越多,后臺緩存的進程也越多。在系統(tǒng)內存不足的情況下,系統(tǒng)開始依據自身的一套進程回收機制來判斷要kill掉哪些進程,以騰出內存來供給需要的app。這套殺進程回收內存的機制就叫 Low Memory Killer ,它是基于Linux內核的 OOM Killer(Out-Of-Memory killer)機制誕生。
了解完 Low Memory Killer,再科普一下oom_adj。什么是oom_adj?它是linux內核分配給每個系統(tǒng)進程的一個值,代表進程的優(yōu)先級,進程回收機制就是根據這個優(yōu)先級來決定是否進行回收。對于oom_adj的作用,你只需要記住以下幾點即可:
- 進程的oom_adj越大,表示此進程優(yōu)先級越低,越容易被殺回收;越小,表示進程優(yōu)先級越高,越不容易被殺回收
- 普通app進程的oom_adj>=0,系統(tǒng)進程的oom_adj才可能<0
那么我們如何查看進程的oom_adj值呢,需要用到下面的兩個shell命令
ps | grep PackageName //獲取你指定的進程信息
這里是以我寫的demo代碼為例子,紅色圈中部分別為下面三個進程的ID
- UI進程:com.clock.daemon
- 普通后臺進程:com.clock.daemon:bg
- 灰色?;钸M程:com.clock.daemon:gray
當然,這些進程的id也可以通過AndroidStudio獲得
接著我們來再來獲取三個進程的oom_adj
cat /proc/進程ID/oom_adj
從上圖可以看到UI進程和灰色?;頢ervice進程的oom_adj=0,而普通后臺進程oom_adj=15。到這里估計你也能明白,為什么普通的后臺進程容易被回收,而前臺進程則不容易被回收了吧。但明白這個還不夠,接著看下圖
上面是我把app切換到后臺,再進行一次oom_adj的檢驗,你會發(fā)現(xiàn)UI進程的值從0變成了6,而灰色?;畹腟ervice進程則從0變成了1。這里可以觀察到,app退到后臺時,其所有的進程優(yōu)先級都會降低。但是UI進程是降低最為明顯的,因為它占用的內存資源最多,系統(tǒng)內存不足的時候肯定優(yōu)先殺這些占用內存高的進程來騰出資源。所以,為了盡量避免后臺UI進程被殺,需要盡可能的釋放一些不用的資源,尤其是圖片、音視頻之類的。
從Android官方文檔中,我們也能看到優(yōu)先級從高到低列出了這些不同類型的進程:Foreground process、Visible process、Service process、Background process、Empty process。
總結(文末有福利)
絮絮叨叨寫完了這么多,最后來做個小小的總結?;貧w到開篇提到QQ進程不死的問題,我也曾認為存在這樣一種技術??上野咽謾Croot后,殺掉QQ進程之后就再也起不來了。有些手機廠商把這些知名的app放入了自己的白名單中,保證了進程不死來提高用戶體驗(如微信、QQ、陌陌都在小米的白名單中)。如果從白名單中移除,他們終究還是和普通app一樣躲避不了被殺的命運,為了盡量避免被殺,還是老老實實去做好優(yōu)化工作吧。
所以,進程?;畹母痉桨附K究還是回到了性能優(yōu)化上,進程永生不死終究是個徹頭徹尾的偽命題!
補充更新
有童鞋問,在華為的機子上發(fā)現(xiàn)微信和手Q的UI進程退到后臺,oom_adj的值一點都沒有變,是不是有什么黑科技在其中。為此,我稍稍驗證了一下,驗證方式就是把demo工程的包名改成手機QQ的,編譯運行在華為的機子上,發(fā)現(xiàn)我的進程怎么殺也都是不死的,退到后臺oom_adj的值同樣不發(fā)生變化,而恢復原來的包名就不行了。所以,你懂的,手Q就在華為機子的白名單中。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關文章
Android如何實現(xiàn)社交應用中的評論與回復功能詳解
目前,各種App的社區(qū)或者用戶曬照片、發(fā)說說的地方,都提供了評論功能,為了更好地學習,自己把這個功能實現(xiàn)了一下,下面這篇文章主要給大家介紹了關于Android如何實現(xiàn)社交應用中的評論與回復功能的相關資料,需要的朋友可以參考下2018-07-07Android JSON數(shù)據與實體類之間的相互轉化(GSON的用法)
這篇文章主要介紹了Android JSON數(shù)據與實體類之間的相互轉化(GSON的用法),非常具有實用價值,需要的朋友可以參考下。2017-01-01基于android樣式與主題(style&theme)的詳解
本篇文章是對android中的樣式與主題(style&theme)進行了詳細的分析介紹,需要的朋友參考下2013-06-06Android實現(xiàn)音樂播放進度條傳遞信息的兩種方式(在service和activity中)
這篇文章主要介紹了Android:在service和activity之中,實現(xiàn)音樂播放進度條傳遞信息的兩種方式,MediaPlayer做音樂播放器采坑以及解決辦法,需要的朋友可以參考下2020-05-05Android搜索框(SearchView)的功能和用法詳解
這篇文章主要為大家詳細介紹了Android搜索框SearchView的功能和用法,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-05-05android 字體顏色選擇器(ColorPicker)介紹
本文將詳細介紹android 字體顏色選擇器(ColorPicker)需要了解更多的朋友可以參考下2012-11-11Android滑動到頂部和底部時出現(xiàn)的陰影如何去掉
本文給大家介紹android滑動到頂部和底部時出現(xiàn)的陰影去掉的解決方法,本文還涉及到listview各個屬性的用法介紹,非常不錯,具有參考借鑒價值,感興趣的朋友一起看看吧2016-10-10