android進程被回收
Ⅰ Android進程級別與如何防止服務進程被回收
一般情況下系統進程強制停止後很快又會自動開啟，系統藍牙也一樣，除非你真的不想用藍牙，就把它卸載了，可以用qq手機管家裡的軟體管理功能，卸載系統部件後它可以在回收站裝回來，當然卸載系統軟體前提要root。。。
Ⅱ android service 什麼情況下會被系統回收
android service 開機啟動後被被自動關閉掉原因：
Android 系統對於內存管理有自己的一套方法，為了保障系統有序穩定的運信，系統內部會自動分配，控製程序的內存使用。當系統覺得當前的資源非常有限的時候，為了保 證一些優先順序高的程序能運行，就會殺掉一些他認為不重要的程序或者服務來釋放內存。這樣就能保證真正對用戶有用的程序仍然再運行。如果你的 Service 碰上了這種情況，多半會先被殺掉。但如果你增加 Service 的優先順序就能讓他多留一會，我們可以用 setForeground(true) 來設置 Service 的優先順序。
默認啟動的 Service 是被標記為 background，當前運行的 Activity 一般被標記為 foreground，也就是說你給 Service 設置了 foreground 那麼他就和正在運行的 Activity 類似優先順序得到了一定的提高。當讓這並不能保證你得 Service 永遠不被殺掉，只是提高了他的優先順序。
Ⅲ 如何判斷 android被 系統回收
我覺得沒有顯式的判斷方法。
Activity就像Java中的一個類，類可以實例化出很多個對象，但你無法判斷該類所有的對象是否已經被內存回收了。
android中顯式的調用finish()方法，或者隱身的（比如按「Back」鍵導致該activity被finish()掉），會導致該activity被回收。
Ⅳ 為什麼 12G 內存的 Android 手機依舊會被殺後台
不知不覺間 Android 陷入了一個關於「後台」的怪圈：一邊各大廠商陸續推出了 12G RAM 的手機，另一邊你剛剛放到後台的下載任務沒有如預期那樣後台掛機下載，打開微信發現還得陪啟動畫面的孤獨小人共賞藍色星球、按照教程辛辛苦苦做了半個小時的 Tasker 規則、卻沒有按照計劃自動執行……
於是一個耳熟能詳的句子開始在我們腦海中成型—— 我的後台又被「殺」了 。
應用開發者的「控訴」
遇到上述問題的人不止你一個，很多人選擇向這些應用的開發者反饋問題，殊不知問題其實不在應用本身。
Android 平台著名睡眠追蹤應用 Sleep as Android 的開發團隊 Urbandroid Team 不堪其擾，索性上線了一個名為「別『殺』我應用」的網站，矛頭直指手機廠商糟糕的後台管理機制。
以三星為例，Urbandroid Team 稱，三星的部分機型在升級到基於 Android 9 的 One UI 後「殺後台」現象變得尤為嚴重，自適應電池（Adaptive Battery）機制相比原生 Android 變得尤為激進，3 天內沒有啟動過的應用甚至無法從後台再次啟動。最為糟糕的情況是，如果你安裝了一個可以自動跳過周末的第三方鬧鍾，那這個鬧鍾應用很有可能不會像系統鬧鍾那樣在下周一早上准時響起……
正如「別『殺』我應用」網站上控訴的那樣，擁有類似機制的還包括華為、一加、小米、華碩等等手機廠商的定製版 Android 系統，它們管理後台的方式大同小異，但都秉承著 iOS 上那一套「劃掉就殺掉」的原則——當我們把某款應用的任務卡片從多任務界面劃去，它們也就徹底從手機後台中抹除掉了。
這里你可能會問很多問題：
我們得從一些基礎的原理說起。
Android 的內存回收機制
在 官方文檔 中，Google 將「不受應用自身直接控制的應用進程生命周期」描述為 Android 最為基礎也最為獨特的核心特性，這里我們不妨將「應用進程生命周期」暫時理解為文章開頭和第一部分所說的「後台」或「後台進程（process）」。
所以 Android 應用的後台進程去留本應是由 Android 系統來決定的 。
當可用運行內存空間不足時，Android 系統會自行決定對特定應用後台進程佔用的空間進行回收釋放，這個過程中 Android 揮舞著的那把大刀，叫做 LMK（Low Memory Killer）。那 LMK 又是如何判斷哪些應用可以被「殺」掉、哪些應用又該暫時放過的呢？
每個應用都有各種各樣的組成部分，其中特定組件的運行狀態共同組成了一套供 LMK 進行內存回收的「優先順序」參考，包括：前台進程、可見進程、服務進程和緩存進程。
前台進程、可見進程和服務進程往往與我們正在手機上執行的操作直接或間接相關 ，比如正在前台供我們交互和操作的活動窗口（Activity）、正在通過廣播接收器（BroadcastReceiver）等待觸發的 Tasker 規則、正在後台通過 Wi-Fi 網路自動上傳備份照片的 Google Photos 以及前面提到的有待觸發的鬧鍾等等。這些進程優先順序從高到低依次遞減，LMK 一般不會觸及。
緩存進程則是那些暫時放在運行內存中的部分，也是和本文探討話題主要相關的重點 。
只有在極端情況下 ，比如 Android 系統在回收掉所有緩存進程後發現空閑內存依然不夠用（比如在低內存的「老爺機」上運行《崩壞 3》），這時 LMK 才會根據優先順序繼續對服務進程、可見進程和前台進程採取回收策略。 而當這些我們在正常使用中能夠直觀感受到的進程都不得不被被回收時 ，文章開頭提到的微信重載、音樂中斷、下載消失等等現象也就出現了。
誰動了你的後台
在可用內存充裕的情況下遭遇「殺後台」現象，一方面可能是 LMK 這把「大刀」出了問題（常見於 Android 9 時期的 Pixel 3 用戶），另一方面則有可能是其它規則額外干預了 Android 系統正常的內存回收機制。
這里提到的「其它規則」主要有兩種形式，一種類似部分華為設備上預裝的「省電精靈」，它會將所有沒有加入後台白名單中的應用後台統統清除，另一種則依託於 Google 推出的 後台檢查 、 後台限制 和 自適應電池 等功能進行「魔改」，讓這些功能的實際效果遠超預期，甚至達到意料之外的負面效果。
根據 Don't kill my app! 的統計，第二種後台干預機制在三星、一加和早期的諾基亞機型中常見，這里廠商們通常會用到一種類似「白名單」的方法來進行過濾。
以三星手機基於 Android 9 的 One UI 為例，除了微信、QQ 等國內常見應用，One UI 默認會為所有第三方應用關閉「允許後台活動」這一選項，同時開啟「優化電池使用量」這一功能。
部分搭載氫 OS 的一加機型則將上面提到的應用進程進行拆分，除了基於原生 Android 的後台限制、電池優化，還有一套名為「自啟動管理」的設置來對應用的自啟動進行管理以及一套名為「深度優化」的電池優化機制，後者會造成很多智能手錶、手環設備在一段時間後丟失與手機的藍牙連接，最終導致睡眠追蹤、運動記錄等等功能的失效。
問題在於上述功能埋藏較深，一般用戶在安裝應用後往往不會第一時間前往設置，一加的氫 OS 更是以系統更新之後自動重置部分用戶設置聞名，那些需要在後台正常工作的應用，因此也被都被直接扔進了原生 Android 中用來限制「毒瘤」應用的「黑箱」里。
換句話說，國內大部分定製 ROM 在後台管理這件事情上都選擇採用一種「 寧肯錯殺一千不肯放過一個 」的做法。
關聯閱讀： 控制頻繁啟動的「毒瘤」，Android 9.0 用這些方法讓你的手機更省電
多任務管理還是後台管理？
從某種程度上來說，國產手機廠商在 Android 後台管理上的做法雖然偏激，但它們都是國內特殊生態下的產物 。
一方面，盡管 Google 為 Android 設想了一套非常理想化的應用運行與後台管理機制 ，但大多數於原生 Android 中行之有效的後台管理機制在國內似乎都會變成「雞肋」。
如果 Google 有 100 種提升 Android 應用運行效率，保證後台綠色、純凈的方法，國內毒瘤應用開發商就有 101 種繞過這些限制的方法。
藉助共用的第三方推送服務實現鏈式喚醒、藉助透明的懸浮窗保證後台存活、通過不斷獲取定位的方式來避免進程被系統回收……不管是出於實現消息推送這樣單純的目的還是為了不斷喚醒用戶設備以實現 KPI 目標這種下作的行為，在國內 Android 生態中均有出現。
雖然國內外的具體環境有所不同，但這類設計不規范的 Android 應用帶來的問題卻是一樣的，這類應用放在後台不僅不會為我們帶來便利，反而還會因為頻繁喚醒設備帶來不小的耗電問題。待機續航問題作為懸在國產 Android 機頭頂的幾把利劍之一，手機廠商不得不各自從系統層面推出自家的應對機制——這就有了上面提到的各種偏激式的後台管理方法。
另一方面，這里還涉及到一個非常重要的概念區分 ：多任務管理和後台管理究竟是不是一回事？
國內 Android 生態由於早期受 iOS 影響較深，無論是開發商還是用戶都更傾向於把「將應用卡片從多任務列表裡劃掉」的行為理解為清除對應用的後台進程。在上面提到的特殊生態環境的影響之下，這里被清除的後台進程往往又包括那些用於保證應用後台運行的可見進程、服務進程乃至前台進程在內。
在酷安應用市場，甚至還有得以在原生 Android 上實現類似「劃掉卡片即停止運行」效果的應用，iOS 的後台管理理念在國內有多麼深入人心可見一斑。
但這種後台管理理念卻與 Google 對 Android 的多任務管理設計方式相悖。Google 一直以來都將 Android 手機上呼出任務卡片的那個界面叫做 Recents，最近幾個版本的 Android 系統更是將其本地化為「概覽」。結合 Google 在 Android 9 和 Android 10 手勢交互上的變革，注重多任務管理而非後台管理的意圖也越發明顯。
當最近運行的應用以一張張卡片的形式呈現在我們面前時，Google 想要呈現的是一個能夠讓我們在不同任務間快速切換的多任務交互，而在理想狀態下，後台管理則是交由系統處理、完全不應被用戶感知的。
至於如何理性看待 Android 平台的後台管理，這里我們不妨借用綠色守護開發者 @OasisFeng 在「Android 多任務界面的劃除交互」這個話題上的 答疑 來回答這個問題：
換句話說， 今後絕大部分需要在海外市場搭載 Google 服務上市的手機都必須滿足這個要求 。
小結
就在上周三（9 月 25 日），醞釀已久的安卓統一推送聯盟正式宣布收到華為、OPPO、一加和 realme 四家公司的進度確認，雖然 Google 的缺席也讓國內 Android 生態也變得異常復雜，但國內 Android 設備也能用上的統一推送服務也算是終於邁出了具有實際意義的第一步。
只是距離轉變人們對 Android「殺後台」這件事的看法依然還有很長的路要走。事實上，國內早在四五年前就出現過一次對「Android 需不需要『殺後台』」問題的科普，但收效甚微，盲從 iOS 設計風格和交互邏輯國內 Android 廠商要負很大一部分責任。
希望靠譜、省電的統一推送系統能成為改觀的第一步，也希望 @OasisFeng 口中那個甚至可以跨越設備重啟恢復「後台狀態」的理想化生態早日到來——至於當下，我們依然只能見招拆招，遇到應用無法正常執行後台任務時打開手機設置仔細翻找、設置，把它們扔進白名單或是給它們的後台卡片套個「鎖」……
下載、安裝了一款非白名單應用，該如何確保它不被「殺後台」呢？歡迎在評論區把你的設置方法分享給大家。
Ⅳ Android 如何進行進程保活
每一個 Android 應用啟動後至少對應一個進程，有的是多個進程，而且主流應用中多個
進程的應用比例較大
對於任何一個進程，我們都可以通過 adb shell ps|grep <package_name>的方式來查看
它的基本信息
Android 中的進程跟封建社會一樣，分了三流九等，Android 系統把進程的劃為了如下
幾種（重要性從高到低），網上多位大神都詳細總結過（備註：嚴格來說是劃分了 6 種）。
場景：
1.某個進程持有一個正在與用戶交互的 Activity 並且該 Activity 正處於 resume 的
狀態。
2.某個進程持有一個 Service，並且該 Service 與用戶正在交互的 Activity 綁定。
3.某個進程持有一個 Service，並且該 Service 調用 startForeground()方法使之位於前台運行。
4.某個進程持有一個 Service，並且該 Service 正在執行它的某個生命周期回調方法，比如 onCreate()、 onStart()或 onDestroy()。
5.某個進程持有一個 BroadcastReceiver，並且該 BroadcastReceiver 正在執行其onReceive()方法。用戶正在使用的程序，一般系統是不會殺死前台進程的，除非用戶強制停止應用或者系統內存不足等極端情況會殺死。
場景：
1.擁有不在前台、但仍對用戶可見的 Activity（已調用 onPause()）。
2.擁有綁定到可見（或前台）Activity 的 Service
用戶正在使用，看得到，但是摸不著，沒有覆蓋到整個屏幕,只有屏幕的一部分可見進程
不包含任何前台組件，一般系統也是不會殺死可見進程的，除非要在資源吃緊的情況下，
要保持某個或多個前台進程存活
場景
1.某個進程中運行著一個 Service 且該 Service 是通過 startService()啟動的，與用戶看見的界面沒有直接關聯。
在內存不足以維持所有前台進程和可見進程同時運行的情況下，服務進程會被殺死
場景：
在用戶按了"back"或者"home"後,程序本身看不到了,但是其實還在運行的程序，
比如 Activity 調用了 onPause 方法系統可能隨時終止它們，回收內存
場景：
某個進程不包含任何活躍的組件時該進程就會被置為空進程，完全沒用,殺了它只有好處沒壞處,第一個干它!
上面是進程的分類，進程是怎麼被殺的呢？系統出於體驗和性能上的考慮，app 在退到
後台時系統並不會真正的 kill 掉這個進程，而是將其緩存起來。打開的應用越多，後台緩存的進程也越多。在系統內存不足的情況下，系統開始依據自身的一套進程回收機制
來判斷要 kill 掉哪些進程，以騰出內存來供給需要的 app, 這套殺進程回收內存的機制
就叫 Low Memory Killer。那這個不足怎麼來規定呢，那就是內存閾值，我們可以使用
cat /sys/mole/lowmemorykiller/parameters/minfree 來查看某個手機的內存閾值。
其實系統在進程回收跟內存回收類似也是有一套嚴格的策略，可以
自己去了解，大概是這個樣子的，oom_adj 越大，佔用物理內存越多會被最先 kill 掉，OK，那麼現在對於進程如何保活這個問題就轉化成，如何降低 oom_adj 的值，以及如
何使得我們應用占的內存最少。
據說這個是手 Q 的進程保活方案，基本思想，系統一般是不會殺死前台進程的。所以要
使得進程常駐，我們只需要在鎖屏的時候在本進程開啟一個 Activity，為了欺騙用戶，
讓這個 Activity 的大小是 1 像素，並且透明無切換動畫，在開屏幕的時候，把這個 Activity
關閉掉，所以這個就需要監聽系統鎖屏廣播，我試過了，的確好使，如下。
如果直接啟動一個 Activity，當我們按下 back 鍵返回桌面的時候，oom_adj 的值是 8，
上面已經提到過，這個進程在資源不夠的情況下是容易被回收的。現在造一個一個像素
的 Activity。
為了做的更隱藏，最好設置一下這個 Activity 的主題，當然也無所謂了
在屏幕關閉的時候把 LiveActivity 啟動起來，在開屏的時候把 LiveActivity 關閉掉，所以
要監聽系統鎖屏廣播，以介面的形式通知 MainActivity 啟動或者關閉 LiveActivity。
現在 MainActivity 改成如下
按下 back 之後，進行鎖屏，現在測試一下 oom_adj 的值
果然將進程的優先順序提高了。
但是還有一個問題，內存也是一個考慮的因素，內存越多會被最先 kill 掉，所以把上面
的業務邏輯放到 Service 中，而 Service 是在另外一個 進程中，在 MainActivity 開啟這
個服務就行了，這樣這個進程就更加的輕量，
OK，通過上面的操作，我們的應用就始終和前台進程是一樣的優先順序了，為了省電，
系統檢測到鎖屏事件後一段時間內會殺死後台進程，如果採取這種方案，就可以避免了
這個問題。但是還是有被殺掉的可能，所以我們還需要做雙進程守護，關於雙進程守護，
比較適合的就是 aidl 的那種方式，但是這個不是完全的靠譜，原理是 A 進程死的時候，
B 還在活著，B 可以將 A 進程拉起來，反之，B 進程死的時候，A 還活著，A 可以將 B
拉起來。所以雙進程守護的前提是，系統殺進程只能一個個的去殺，如果一次性殺兩個，
這種方法也是不 OK 的。
事實上
那麼我們先來看看 Android5.0 以下的源碼，ActivityManagerService 是如何關閉在應用
退出後清理內存的
在應用退出後，ActivityManagerService 不僅把主進程給殺死，另外把主進程所屬的進
程組一並殺死，這樣一來，由於子進程和主進程在同一進程組，子進程在做的事情，也
就停止了。所以在 Android5.0 以後的手機應用在進程被殺死後，要採用其他方案。
這種大部分人都了解，據說這個微信也用過的進程保活方案，移步微信 Android 客戶端
後台保活經驗分享，這方案實際利用了 Android 前台 service 的漏洞。
原理如下
對於 API level < 18 ：調用 startForeground(ID， new Notification())，發送空的
Notification ，圖標則不會顯示。
對於 API level >= 18：在需要提優先順序的 service A 啟動一個 InnerService，兩個服務
同時 startForeground，且綁定同樣的 ID。Stop 掉 InnerService ，這樣通知欄圖標即
被移除。
public class KeepLiveService extends Service{
public static final int NOTIFICATION_ID=0x11;
public KeepLiveService() {
}
@Override
public IBinder onBind(Intent intent){
throw new UnsupportedOperationException("Not yet implemented");
}
@Override
public void onCreate() {
super.onCreate(); //API 18 以下，直 接發 送 Notification 並 將 其 置 為 前 台
if(Build.VERSION.SDK_INT<Build.VERSION_CODES.JELLY_BEAN_MR2){
startForeground(NOTIFICATION_ID,new Notification());
} else { //API 18 以上，發送 Notification 並將其置為前台後，啟動 InnerService
Notification.Builder builder=new Notification.Builder(this);
builder.setSmallIcon(R.mipmap.ic_launcher);
startForeground(NOTIFICATION_ID, builder.build());
startService(new Intent(this, InnerService.class));
}
}
public class InnerService extends Service{
@Override public IBinder onBind(Intent intent) {
return null;
}
@Override public void onCreate() {
super.onCreate(); //發送與 KeepLiveService中 ID 相同的 Notification，然後將其取消並取消自己的前台顯示
Notification.Builder builder = new Notification.Builder(this);
builder.setSmallIcon(R.mipmap.ic_launcher);startForeground(NOTIFICATION_ID,
builder.build());
new Handler().postDelayed(new Runnable() {
@Override public void run() {
stopForeground(true);
NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
manager.cancel(NOTIFICATION_ID);
stopSelf();
}
},
100);
}
}
}
在沒有採取前台服務之前，啟動應用，oom_adj 值是 0，按下返回鍵之後，變成 9（不
同 ROM 可能不一樣）
相互喚醒的意思就是，假如你手機里裝了支付寶、淘寶、天貓、UC 等阿里系的 app，
那麼你打開任意一個阿里系的 app 後，有可能就順便把其他阿里系的 app 給喚醒了。
這個完全有可能的。此外，開機，網路切換、拍照、拍視頻時候，利用系統產生的廣播
也能喚醒 app，不過 Android N 已經將這三種廣播取消了。
如果應用想保活，要是 QQ，微信願意救你也行，有多少手機上沒有 QQ，微信呢？或
者像友盟，信鴿這種推送 SDK，也存在喚醒 app 的功能。
拉活方法
JobSheler是作為進程死後復活的一種手段，
native進程方式最大缺點是費電，Native
進程費電的原因是感知主進程是否存活有兩種實現方式，在 Native 進程中通過死循環
或定時器，輪訓判斷主進程是否存活，當主進程不存活時進行拉活。其次 5.0 以上系統
不支持。 但是 JobSheler 可以替代在 Android5.0 以上 native 進程方式，這種方式即
使用戶強制關閉，也能被拉起來，親測可行。
JobSheler@TargetApi(Build.VERSION_CODES.LOLLIPOP)
public class MyJobService extends JobService {
@Override
public void onCreate() {
super.onCreate();
startJobSheler();
}
public void startJobSheler() {
try {
JobInfo.Builder builder = new JobInfo.Builder(1,new ComponentName(getPackageName(), MyJobService.class.getName()));
builder.setPeriodic(5); builder.setPersisted(true); JobScheler jobScheler =(JobScheler)
this.getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheler.schele(builder.build());
}
catch
(Exception ex)
{ ex.printStackTrace(); } }
@Override
public boolean onStartJob(JobParameters jobParameters) {
return false;
} @Override public boolean onStopJob(JobParameters jobParameters) {
return false;
}
}
這個是系統自帶的，onStartCommand 方法必須具有一個整形的返回值，這個整形的返
回值用來告訴系統在服務啟動完畢後，如果被 Kill，系統將如何操作，這種方案雖然可
以，但是在某些情況 or 某些定製 ROM 上可能失效，我認為可以多做一種保保守方案。
1.START_STICKY
如果系統在 onStartCommand 返回後被銷毀，系統將會重新創建服務並依次調用
onCreate 和 onStartCommand（注意：根據測試 Android2.3.3 以下版本只會調用
onCreate 根本不會調用 onStartCommand，Android4.0 可以辦到），這種相當於服務
又重新啟動恢復到之前的狀態了）。
2.START_NOT_STICKY
如果系統在 onStartCommand 返回後被銷毀，如果返回該值，則在執行完
onStartCommand 方法後如果 Service 被殺掉系統將不會重啟該服務
3.START_REDELIVER_INTENT
START_STICKY 的兼容版本，不同的是其不保證服務被殺後一定能重啟。
4.相比與粘性服務與系統服務捆綁更厲害一點，這個來自愛哥的研究，這里說的系統服務
很好理解，比如 NotificationListenerService，NotificationListenerService 就是一個監聽
通知的服務，只要手機收到了通知，NotificationListenerService 都能監聽到，即時用戶
把進程殺死，也能重啟，所以說要是把這個服務放到我們的進程之中，那麼就可以呵呵
了
所以你的應用要是有消息推送的話，那麼可以用這種方式去欺騙用戶。
Ⅵ 如何防止android應用中的service被系統回收
永不被kill是不可能的，android系統應用都有可能會被kill，不要說用戶應用了，只能說被kill以後還能重新啟動。
Android中，當Service被kill後，如果重啟需要使用BroadcastReceiver來實現，即廣播接收者，例如利用BroadcastReceiver注冊網路廣播或者開關機廣播，當接收到廣播後直接啟動service,這樣就可以保證service被kill後，自動啟動。
實現代碼：
1.在配置文件AndroidManifest.xml中向系統注冊BroadcastReceiver
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
2.需要添加相應許可權
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
3.在Receiver中就可以添加開機，或者網路狀態改變後需要進行的操作
public class BootCompletedReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
}
}
4.執行操作，Intent intent = new Intent(context,Service.class); context.startService(intent); 這樣即可開機，或者網路狀態改變後啟動Service了。
Ⅶ Android應用程序被系統回收後處理
在android中如果一個應用程序被按Home鍵回到桌面了，這個時候應用程序就處於後台運行狀態，後台運行狀態的應用在系統內存不足的情況下有可能會被系統回收掉。我們可以用Android DDMS模擬一下把進程kill掉。然後重新進入應用的重啟情況。
這個是app從啟動-退出後台-系統kill-重啟的一個流程
Ⅷ android應用被強殺或應用被回收導致的空指針問題等其他問題
在開發中我們經常會遇見app退到後台再打開會出現空指針、頁面顯示不全等一系列奇怪的問題。
當我們的進程被強殺或者被回收的時候，Android系統雖然讓你的進程沒有了，但是此進程中Activity中棧的信息還是存在的，也就是說此時當你點開此應用的時候程序中的Activity棧信息任然存在，只不過Activity中的數據都沒有了，需要重新創建新的Activity數據。
分別涉及到：一個單例ConstantInstance 基類BaseAcyivity 首頁MainActivity 啟動頁IndexActivity
Ⅸ 如何防止 android service被回收
眾所周知, Service是跑後台的. 但是有些Rom廠商把一鍵清理做的真是太好用了, 以至於一鍵清理變成了一種習慣, Service已經變的不再是Service了. 那為什麼像諸如360, 微信, QQ...卻可以傍山傍水.哦, 用錯詞了. 大家懂的. .
言歸正傳, android的系統進程分為五個等級, Foreground Process(前台進程), Visible Process(可見進程), Service Process(服務進程), Background Process(後台進程), Empty Process(空進程), Service的進程處於第三個位置. 系統的回收會從低到高依次回收, 所以我們必須提高Service的等級, 仔細看Service的API會發現這么個方法.
查 看官方API請點我
public final void startForeground (int id, Notification notification)
這個方法是從API 5開始的, 又說費話了. 但是用了之後會發現通知欄會彈出個通知, 不彈通知人家讓你傳Notification幹嘛, 哦, 好吧, 我又NC了. 這就很好的解釋了360和LBE這些軟體的那個通知了. 那QQ,微信為什麼沒有呢. 方法是死的, 人是活的.
我們可以這樣.
private void startForegroundCompat() {
try {
if (Build.VERSION.SDK_INT < 18) {
Log.v(TAG, "startForgroundCompat");
startForeground(1120, new Notification());
}
} catch (Exception e) {
if (DEBUG) Log.e(TAG, "", e);
}
}
為什麼要低於版本18呢, 那你這句就問的就是廢話了. 有Bug唄, 開個玩笑, 在版本18以及以上, 會彈出個默認的通知, so, 要低於版本18.
那有人可能又想, 那我們寫成這樣呢.
startForeground(1120, null);
當然也不行了, 要是行還new個空的幹嘛, 這樣會報錯滴.
如果這樣做之後, 你會發現一鍵清理對你的Service是完全不起作用的(再也沒有那該死的正在重新啟動了, 你這么吊, 你經理知道嗎, 啊. 啊). 你可以哈哈大笑了, 總算解決了個殘留很久的問題了. 但是別高興太早, 一切都是有條件的. 實現以上效果必須系統同意你開機啟動(開機啟動? 跟著有毛關系? 唉....且看下文), 測試機型MIUI V5, 我也不知道它的那個自啟動管理怎麼做的, 我去了開機啟動的許可權以及廣播, 它那裡還是會顯示, 只有點允許才OK, so, 如果你的用戶大多是MIUI系統的話, 要想在那裡面自動允許, 只能商務了, 要不你也可以像360那樣, 整個引導界面, 讓用戶操作.
網上還有說通過startCommand的返回值讓Service是否重新啟動, 我覺著這樣很不好.
第一, 用戶清理這是一對多的關系,也許用戶並不想清理你的程序呢(當然這概率有點小. 你又不是微信, 人家是拿到船票的人, 跟你我屌絲能一樣嗎), 所以這樣做的必要是有的. 好像跟上面的問題沒多大關系啊.
其二, 我想清理, 結果你還重新啟動, 哇靠, 這什麼APP, 這么流氓, 關鍵我都定位到你那個詳情了, 點停止你還啟, 點停止你還啟...比如那個類微信...(當然也可以清理, 等它重新啟動的時候再停止一次, 就See Bye了)
最後, 咱最終還是本著決定權在用戶手裡的原則, 你要是真的讓我走, 我絕不死機白咧, 但是我得知道, 你真的指的是我, 走, 也要走的唯一!
按常理的話, 題目的解釋到這里就完成了.
但是我這人吧, 就喜歡多做一點點. 永遠超出別人的預期. 吼哈....
有的人會想, 那我API18以後怎麼辦, 我, 我, 我也不知道撒...
但是我可以保證的是, 只要用戶不刪你的APP, 你的服務就可以一直是活動的.
<receiver android:name=".NotifyReceiver" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.TIME_SET" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.DATE_CHANGED" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.TIMEZONE_CHANGED" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.PACKAGE_ADDED" />
<action android:name="android.intent.action.PACKAGE_REMOVED" />
<action android:name="android.intent.action.PACKAGE_REPLACED" />
<data android:scheme="package" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.MEDIA_BAD_REMOVAL" />
<action android:name="android.intent.action.MEDIA_EJECT" />
<action android:name="android.intent.action.MEDIA_MOUNTED" />
<action android:name="android.intent.action.MEDIA_REMOVED" />
<action android:name="android.intent.action.MEDIA_SCANNER_FINISHED" />
<action android:name="android.intent.action.MEDIA_SCANNER_STARTED" />
<action android:name="android.intent.action.MEDIA_SHARED" />
<action android:name="android.intent.action.MEDIA_UNMOUNTED" />
<data android:scheme="file" />
</intent-filter>
</receiver>
你注冊這么個廣播接收器, 在裡面啟動你的Service(當然啟動的時候最好判斷下是否啟動), 除非用戶不操作手機, 不安裝, 不卸載, 網路環境一直不變化. 否則, 嘿嘿
What, 我這是在扇自己的臉嗎. 我只是說有這么個方案, 當然不太建議大家去這么做, 簡直太流氓了, 反正我是這么做了. 需求讓人迷失自己!!! 迷失 Noooooooo, 程序員是沒有自己的.
Ⅹ android進程管理機制
Android系統與其他操作系統有個很不一樣的地方，就是其他操作系統盡可能移除不再活動的進程，從而盡可能保證多的內存空間，而Android系統卻是反其道而行之，盡可能保留進程。Android這樣設計有什麼優勢呢？又是通過怎樣的方法來管理這些被保留的進程的呢？Android用戶又該如何正確使用手機從而更好發揮Android系統所特有的優勢呢？本文將一一為您解開這些謎團。
本文的主要內容如下：
一、Android進程管理的特殊設計
Linux系統對進程的管理方式是一旦進程活動停止，系統就會結束該進程。盡管Android基於Linux Kernel，但在進程管理上，卻採取了另外一種獨特的設計：當進程活動停止時，系統並不會立刻結束它，而是會盡可能地將該進程保存在內存中，在以後的某個時間，一旦需要該進程，系統就會立即打開它，而不用再做一些初始化操作。只有當剩餘內存不夠用了，為了維持新開啟的進程或者比較重要的進程的正常運行，系統才會選擇性地殺掉一些不重要的內存，騰出內存空間來，所以Android系統永遠不會有內存不足的提示。
二、Android獨特進程管理設計的好處
Android這種獨特的設計，也正是Android標榜的優勢之一，這有兩個好處：
1、最大限度地提高內存的使用率。
比如，你的內存是8G，如果每次使用完某個進程就殺掉，那麼被使用的內存基本上會始終保持在某個值，比如4G以內，那麼內存的使用率就總是保存在50%以內，剩餘的4G內存形同虛設，發揮用處的機會非常少。而Android的這種設計，就可以做到有多少內存就用多少內存，盡可能大地提高內存使用率。同樣比如有8G內存，使用完的進程仍保留在內存中，累積下來，被使用的內存就盡可能地會接近8G。
2、提高再次啟動時的啟動速度
被駐留在內存中不再活動的進程（後台進程或空進程，後面會再講到），很多是經常需要使用的，當再次使用該進程的時候，系統立即打開它，而不需要再重新初始化。例如，我們常用的瀏覽器，當暫時不再使用時，按下Home鍵或Back鍵，瀏覽器進程就變成了不再活動的進程。如果下次又要使用了，點擊多任務鍵，在最近使用應用列表中點擊瀏覽器即可，瀏覽器界面仍然保持著退出前的界面。但如果退出時把該進程移除了，那麼再次使用時，就需要重新初始化，然後進入該應用，這往往會花費不少的時間。
三、Android進程的五個等級
Android系統將盡量長時間地保持應用進程，但為了新建進程或運行更重要的進程，最終需要移除舊進程來回收內存。為了確定保留或終止哪些進程，系統會根據進程中正在運行的組件以及這些組件的狀態，將每個進程放入「重要性層次結構」中。必要時，系統會首先消除重要性最低的進程，然後是重要性略遜的進程，以此類推，以回收系統資源。該「重要性層級結構」將進程分為了五個等級：
1、前台進程（foreground）
前台進程是指那些有組件正和用戶進行交互的應用程序的進程，也稱為Active進程。這些都是Android嘗試通過回收其他應用程序來使其保持相應的進程。這些進程的數量非常少，只有等到最後關頭才會終止這些進程，是用戶最不希望終止的進程。例如：而當你運行瀏覽器這類應用時，它們的界面就會顯示在前台，它們就屬於前台進程，當你按home鍵回到主界面，他們就變成了後台程序。
如果一個進程滿足以下任一條件，即視為前台進程：
（1）託管處於活動狀態的Activity，也就是說，它們位於前台並對用戶事件進行響應，此時的情形為響應了Activity中的onResume()生命周期方法，但沒有響應onPause()。
（2）託管正在執行onReceive()方法處理事件程序的BroadcastReceiver。
（3）託管正在執行onStart()、onCreate()或onDestroy()事件處理程序的Service。
（4）託管正在運行且被標記為在前台運行的Service，即調用了該Service的startForeground()方法。
（5）託管某個Service，且該Service正綁定在用戶正在交互的Activity的Service，即該Activity正處於活動狀態。
2、可見進程（visible）
沒有任何前台組件、但仍然會影響用戶在屏幕上所見內容的進程。如果一個進程滿足以下任一條件，即視為可見進程：
（1）託管不在前台、但仍對用戶可見的Activity（已調用其onPause（）方法）。例如：如果前台Acitivty啟動了一個對話框，或者啟動了一個非全屏，亦或是一個透明的Activity，允許在其後顯示上一個Activity，則可能會發生這種情況，這類Activity不在前台運行，也不能對用戶事件作出反應。
（2）託管綁定到可見Activity的Service。（官網上說是綁定到可見或前台Activity，但筆者有一點疑問，這個和「前台進程」中第（5）點相矛盾嗎，綁定到前台Activity，那就是前台進程了）
可見進程被視為是極其重要的進程，這類進程的數量也很少，只有在資源極度匱乏的環境下，為保證前台進程繼續執行時才會終止。
3、服務進程（Service）
正在運行已使用startService（）方法啟動的Serice且不屬於上述兩個更高類別進程的進程。盡管服務進程與用戶所見內容沒有直接關聯，但是它們通常在執行一些用戶關心的操作。因此，除非內存不足以維持所有前台進程和可見進程同時運行，否則系統會讓服務進程保持運行狀態。
有些資料上面也稱這種進程為次要服務（Secondary Service），而屬於上述兩個更高類別的進程則被稱為主要服務，主要服務往往屬於系統進程，如撥號進程等，不可能被進程管理輕易終止。這里我們以Android開發者官網的稱呼為標准，稱為服務進程。
4、後台進程（hidden）
包含目前對用戶不可見的Activity，即該Activity調用了onStop()方法。這些進程對用戶體驗沒有直接影響，系統可能隨時終止它們，以回收內存供上述三個更高級別的進程使用。通常會有很多後台進程在運行，它們會保存在LRU（Least Recently Used，最近最少使用）列表中，以確保包含用戶最近查看的Activity的進程最後一個被終止。如果某個Activity正確實現了生命周期方法，並保存了其當前狀態，則終止其進程不會對用戶體驗產生明顯影響，因為當用戶導航回該Activity時，Activity會恢復其所有可見狀態。
這里讀者可以做個試驗，先開啟微信，進入到朋友圈界面， 然後點擊手機屏幕下方的導航欄中的Home按鍵進入到後台，再點擊最近使用應用列表顯示按鈕（不同的手機位置不一樣，有的在Home鍵左邊，有的則在Home鍵右邊），在顯示的最近使用應用的列表中清理掉微信應用，最後再點擊桌面的微信圖標啟動微信，會發現顯示的界面仍然是朋友圈界面。
後台進程，我們可以簡單理解為，應用（只考慮只有Activity組件的情況）啟動後按Home鍵後被切換到後台的進程。如瀏覽器、閱讀器等，當程序顯示在屏幕上時，它們所運行的進程即為前台進程（foreground），一旦按home鍵（注意不是back鍵）返回到桌面，程序就停留在後台，成為後台進程。
5、空進程（empty）
不含任何活動應用組件的進程。保留這種進程的唯一目的是用作緩存，以縮短下次再其中運行組件所需要的啟動時間。一般來說，當應用按back按鍵退出後應用後，就變成了一個空進程。比如BTE，在程序退出後，依然會在進程中駐留一個空進程，這個進程里沒有任何數據在運行，作用往往是提高該程序下次的啟動速度或者記錄程序的一些歷史信息。當系統內存不夠用時，無疑，該進程是應該最先終止的。在最近使用應用列表中，可以看到按back鍵退出的應用。
根據進程中當前活動組件的重要程度，Android會將進程評定為它可能達到的最高級別。通俗地說，就是如果一個進程同時擁有多個對應上述不同等級進程的組件時，會以最高的那個等級作為該進程的等級。例如，如果某進程託管著服務和可見Activity，則會將此進程評定為可見進程，而不是服務進程。
此外，一個進程的級別可能會因為其他進程對它的依賴而有所提高，即服務於另一進程的進程其級別永遠不會低於其所服務的進程。例如，如果進程A中的內容提供程序為進程B中的客戶端提供服務，或者如果進程A中的服務綁定到進程B中的組件，則進程A始終被視為至少與進程B同樣重要。
由於運行服務的進程其級別高於託管後台Activity的進程，因此啟動長時間運行操作的Activity最好為該操作啟動Service，而不是簡單地創建工作線程，當操作有可能比Activity更加持久時更應該如此。例如，正在將圖片上傳到網站的Activity應該啟動服務來執行上傳，這樣一來，即使用戶退出Activity，仍可在後台繼續執行上傳操作。使用服務可以保證，無論Activity發生什麼情況，該操作至少具備「服務進程」優先順序。如果某個Activity開啟了線程執行耗時操作，當Activity退出時，該Activity的實例將不會釋放內存資源，直到線程執行完，這樣容易導致內存泄漏。同理，廣播接收器也應該使用服務，而不是簡單地將耗時冗長的操作放入線程中。
四、進程移除順序的依據——閾（yu，第四聲）值
前面講到，內存不夠用時，會根據進程的等級來決定優先回收哪類進程。那麼系統是根據什麼來判斷需要移除這些進程的時機的呢？答案是閾值。
1、查看閾值
我們可以採用如下方法查看手機中各個等級進程的閾值（需要root許可權），如第二排數據所示（其單位為頁）：
以第一個數據44032為例，計算方法為：
1page=4KB=4*1024B=4096B
44032page* 4048B/page = 180355072B
180355072B/1024/1024 = 172M
即第一個等級的進程的閾值為172M。依次類推，閾值依次為：172M，190M，208M，226M，316M，415M。
有必要說明一下，在Android開發者官方文檔中，是將Android應用進程分為了5個等級，但很多資料卻是分的6個等級，在後台進程和空進程之間還有一個「內容提供節點（content provider）進程」。內容提供節點，沒有實體程序，僅提供內容供別的程序去用 ，比如日歷供應節點，郵件供應節點等，在終止進程時，這類進程有比較高的優先權。手機中應該是採用的6個等級的方式，如上六個數據，正好對應著六個等級的進程，等級越高，閾值越低，即前台進程閾值為172M，空進程為415M。當系統的剩餘內存只剩餘不到415M的時候，系統首先會回收空進程，依次類推，只有剩餘內存不到172M了，才會去回收前台進程，這樣就起到了優化保護重要進程的作用。
五、Home鍵、Back鍵和多任務鍵
Home鍵、Back鍵和多任務鍵，在手機屏幕的下方，這三個按鍵一般稱為導航欄，中間的按鈕為Home鍵，多任務鍵和Back鍵分別在其左右，一般根據手機品牌不同，左右位置也有所差異。
在運行App的時候，如果按一下Home鍵或者Back鍵，都可以退到桌面，那麼這兩者有什麼區別呢？
Home鍵。按Home鍵的時候，App如果沒有Service開啟，會從一個前台進程轉變為一個後台進程；如果有前台service運行，就仍然是前台進程，比如QQ音樂播放器等；如果是只有普通service運行，那麼就轉變為服務進程（參照前文中講的Android進程的5個級別）。
Back鍵。按Back鍵的時候，App如果沒有Service開啟，會從一個前台進程轉變為一個空進程；對於有Service運行的情況，和按Home鍵一樣。
後台進程和空進程，都是駐留在後台，處於暫停狀態，也都是除了佔用一部分內存外，不佔用其他如cpu等資源的，那麼問題來了，為什麼要設計後台進程和空進程這兩種空進程呢？它們的區別到底在哪裡呢？我們在前文講Android進程的5個等級的時候講到過，當剩餘內存不足的時候，系統會按照等級順序，優先移除不太重要進程，以收回內存供更重要的進程運行。那麼，它們的區別就是，在剩餘內存不足時，會優先移除空進程，再不足，才會移除空進程。所以，如果確實要退出某個應用一段時間內不大使用了，如果這款應用有退出按鈕，就用應用自帶的退出功能；如果沒有，則最好按系統的Back鍵，這樣可以變成空進程，當系統要回收內存時，就會優先被回收，從而釋放的所佔的資源。如果只是暫時退出去做點別的，過一會還要切換回來，或者對這款應用使用比較頻繁，那就使用Home鍵，因為相比於按Back鍵，這樣可以盡可能保住後台進程，方便下次使用的時候快速啟動。
當然，按Home鍵或Back鍵，對用戶來說，其實感覺不到差異，使用起來沒什麼兩樣，但是，對於Android開發者來說，卻有必要作為常識來了解其中的道理和差異。無論是按Home鍵還是按Back鍵，在按多任務鍵的時候，都可以看到這些進程，如下圖所示。最下面的按鍵為清理按鍵，點擊後可以清除掉這些進程，回收內存了，當然，前面也講了很多遍了，不建議這樣做。
2、修改閾值。
可以採用命令：echo "44032,48640,53248,57856,80896,106241" > /sys/mole/lowmemorykiller/parameters/minfree來修改閾值，如下所示：
重啟後，會恢復為原來的值。至於如何永久性修改該閾值，這里不深入探討，有興趣的童鞋可以自行研究，一般來說，就按照系統給定的默認值使用就可以了，沒特殊用途的話，沒必要修改。
對於這一節閾值的內容，暫時先講到這里，如果要更深入，可以自行多研究研究。筆者也沒有看到比較好的更深入的文章，所以也不好推薦，如果讀者看到比較好的，可以推薦給筆者，感激不盡。
六、開發者選項中的進程管理功能
Android手機都帶有開發者選項，隱藏了很多功能，顧名思義，這些功能主要用於輔助開發者調試程序用的。其中有一些就是關於進程管理功能的，筆者這里簡單介紹一下其中兩款，如下圖紅框部分所示：
不保留活動。用戶離開以後即銷毀每個活動（Activity），這樣做使得後台進程都被銷毀了。筆者試驗過幾款app，比如微信，瀏覽器，開啟/關閉「不保留活動」前後，按Home鍵後，再打開應用，有明顯的差別。當然，也試用了簡訊，DD打車，就沒看出起了什麼作用。讀者若是感興趣可以深入研究研究，到時候在指導指導筆者！
後台進程限制。如下圖所示，給出了後台進程個數限制的選項。
七、進程管理軟體的使用
Windows操作系統用戶往往總想著保留更多的內存，在使用Android手機的時候，喜歡經常清理後台進程或空進程，而且清理完後，心裡有一種特別爽的感覺，就像給家裡做了一次大掃除一樣，筆者最初使用Android手機的時候也是這樣的心態-_-！基於這樣的心態，一些進程清理軟體，很受普通用戶的青睞。其實這樣做卻正好抹殺了Android系統所標榜的優勢，如前文所講到的。
那麼進程管理軟體有無必要呢？當然有的，只是需要注意使用場合。當需要運行大型程序的時候，可以手動關閉掉一些進程，騰出足夠的空間供大型程序使用，這樣就可以有效避免系統調用進程調度策略而引起的卡頓，這一點，第八大點第3小節中會有說明。而且由於開發者的原因，可能是程序寫得太爛，或程序容易出錯，或做不該做的動作，或是惡意程序，對於這類程序進程，手動移除也是有好處的。
但如果是運行一些小程序，就完全沒有必要去預先殺進程了，完全可以交給系統自己管理。讀者可能會疑惑，因為小程序啟動的時候，也有可能會因為內存不足而導致需要移除部分進程的情況。筆者認為，即便是內存不足，小程序運行引起的調用進程調度策略測的次數非常少，要移除的進程也非常少，產生的影響不大。同時，我們也要意識到另外一點就是，無論是手動殺死進程還是自動殺進程，都需要cpu去執行這些任務，所以也會拖慢手機和消耗電量。所以從這一點看，頻繁殺進程，也是一個不好的習慣。
八、答疑解惑
在以前沒有專門去了解Android進程管理機制的時候，甚至是在研究的過程中，筆者心裡都經常存在很多疑惑，以下整理了其中5個，不知道讀者您是否有也類似的困惑呢？
1、這么多駐留在內存的進程，不會耗電嗎？
大多數用慣了Windows操作系統的童鞋，看到Android系統盡可能保留不在活動的進程的設計，可能第一反應就是質疑，難道這樣不會增加耗電量嗎？其實，但一個程序按home鍵變成後台進程或者按back鍵退出變成空進程後，其實已經被暫停了，只保留了運行狀態，不會消耗cpu，一個程序會耗電，是因為它需要調用cpu來運算，現在不消耗cpu了，當然就不會耗電了。當然，開了service的應用就另當別論了，比如QQ音樂播放器，當按home鍵或back鍵後，音樂仍然播放，是因為它開啟了服務，而且是一個前台服務，在後面我們會繼續講到，此時它是一個前台進程，而不是後台進程或空進程。
2、為什麼一個不太app，運行時會佔用很大的內存呢？
我們經常會碰到這樣一種現象，一個只有20M的App，運行起來的時候，卻會耗掉100M以上的內存。一方面是，程序運行時為對象分配內存，另一方面，是Android虛擬機的原因。Android中的應用啟動的時候，系統都會給它開啟一個獨立的虛擬機，這樣做的好處是可以避免虛擬機崩潰導致整個系統崩潰，代價就是耗用更多的內存。
3、為什麼內存少的時候，運行大型程序會卡頓呢？
當剩餘內存不多時，打開大型程序，系統會觸發自身的進程調度策略，去移除一些等級比較低的進程來回收內存，以供大型程序運行。而這個進程調度策略在決定哪些進程需要被移除的過程，是一個十分消耗資源的操作，特別是一個程序頻繁像系統申內存的時候，這樣就導致了系統的卡頓。
4、應用開得太多了，手機變慢，是因為內存被佔用太多嗎？
其實手機變慢的根本原因是cpu被耗用太多，而不是內存佔用太多，因為真正執行程序所要完成的任務的最終執行者是CPU，而不是內存（RAM）。在內存足夠的情況下，如果系統中佔用cpu的進程太多，那無疑cpu總有忙不過來的時候，那肯定就會變慢了。這就好比，在一條道路上駕車，道路就像內存，車的引擎就像cpu，如果車的引擎的動力不夠，或者承載的貨物太多，車都跑不快，即便是道路上一路暢通無阻，也無濟於事。所以，內存佔用多少並不重要，只要道路提供給車輛前行的空間是足夠的，手機變慢的責任，就和內存無關了。這個比喻用來解釋第三點也很恰當，道路提供的車輛前進的空間無法滿足車輛所必需的空間時，就需要交通機制花時間來調節交通，給這輛車提供足夠的空間，而在此期間，這輛車只能乖乖候著。
5、Android手機越用越慢，是什麼原因呢？
Android手機常常是越用越慢，即使是恢復出廠設置，也無法改變這個現象。手機越用越慢，主要由如下幾個原因：（1）虛擬機機制問題。這一點在上一個問題中也提到了，在Android4.4以前的系統，使用的是Dalvik虛擬機，它的設計機制有缺陷，就是越用越慢；在Android4.4系統中有切換按鈕，可以在Art虛擬機和Dalvik虛擬機之間切換；在Android4.4以後的系統就徹底拋棄了Dalvik而全面使用Art。（2）開啟了太多的服務，導致耗用太多的CPU。隨著手機開機使用時間的增長，應用使用越來越多，很多應用看似退出了，而其實後台可能開了不少的服務，而他們可能還沒有關閉。這些服務正在執行一些操作，會消耗CPU，而CPU才是手機變慢的根本原因。 而且Android app比較開放的，有很多不良應用充斥其中，可能對服務處理不當，濫用服務等，增加系統中的服務。（3）系統頻繁調用自身的進程調度演算法。這一點在前面已經說明了，這里不再贅述。（4）手機硬體的自然老化