1）Android為每個(gè)應(yīng)用程序分配的內(nèi)存大小是多少？
2）Android中進(jìn)程內(nèi)存的分配囱桨，能不能自己分配定額內(nèi)存馅扣？
3）進(jìn)程庇活的方式
4）如何保證一個(gè)后臺(tái)服務(wù)不被殺死？（相同問題：如何保證service在后臺(tái)不被kill大溜？）比較省電的方式是什么化漆？
5）App中喚醒其他進(jìn)程的實(shí)現(xiàn)方式
一. Android為每個(gè)應(yīng)用程序分配的內(nèi)存大小钦奋？
熟悉Android內(nèi)存分配機(jī)制的朋友都知道座云，Android為每個(gè)進(jìn)程分配內(nèi)存時(shí)，采用彈性的分配方式付材，即剛開始并不會(huì)給應(yīng)用分配很多的內(nèi)存朦拖，而是給每一個(gè)進(jìn)程分配一個(gè)“夠用”的內(nèi)存大小。
實(shí)際測試一下：
private void getMaxMemoryInfo(){
Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();
Log.e("MaxMemory:", Long.toString(maxMemory/(1024*1024)));
ActivityManager activityManager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
Log.e("MemoryClass:", Long.toString(activityManager.getMemoryClass()));
Log.e("LargeMemoryClass:", Long.toString(activityManager.getLargeMemoryClass()));
}
輸出結(jié)果為：
06-06 15:27:22.740 11917-11917/com.suning.myapp E/MaxMemory:: 192
06-06 15:27:22.740 11917-11917/com.suning.myapp E/MemoryClass:: 192
06-06 15:27:22.740 11917-11917/com.suning.myapp E/LargeMemoryClass:: 512
把AndroidManifest.xml中的application標(biāo)簽加上
<application
...
android:largeHeap="true"
...>
...
</application>
輸出結(jié)果為：
06-06 15:32:06.168 21973-21973/com.suningtang.myapp E/MaxMemory:: 512
06-06 15:32:06.168 21973-21973/com.suningtang.myapp E/MemoryClass:: 192
06-06 15:32:06.168 21973-21973/com.suningtang.myapp E/LargeMemoryClass:: 512
設(shè)置largeHeap為true時(shí)厌衔， 通過rt.maxMemory();獲取的值為512M贞谓。
這臺(tái)手機(jī)，系統(tǒng)正常分配的內(nèi)存最多為192M葵诈；當(dāng)設(shè)置largeHeap時(shí)裸弦，最多可申請(qǐng)512M。當(dāng)超過這個(gè)值時(shí)作喘，就會(huì)出現(xiàn)OOM了理疙。
這個(gè)值是在哪設(shè)置的呢？查看/system/build.prop文件內(nèi)容：
shell@NX510J:/ $ cat /system/build.prop | grep heap
dalvik.vm.heapsize=36m
dalvik.vm.heapstartsize=8m ----起始分配內(nèi)存
dalvik.vm.heapgrowthlimit=192m ---- 一般情況app申請(qǐng)的最大內(nèi)存 dalvik.vm.heapsize=512m
---- 設(shè)置largeheap時(shí)泞坦，App可用的最大內(nèi)存dalvik.vm.heaptargetutilization=0.75 ---- GC相關(guān)
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m ----- GC機(jī)制相關(guān)
那ActivityManager的 getMemoryClass() 和 getLargeMemoryClass() 方法返回的的是哪里的值呢窖贤？
//ActivityManager.java
public int getMemoryClass() {
return staticGetMemoryClass();
}
/** @hide */
static public int staticGetMemoryClass() {
String vmHeapSize = SystemProperties.get("dalvik.vm.heapgrowthlimit", "");
if (vmHeapSize != null && !"".equals(vmHeapSize)) {
return Integer.parseInt(vmHeapSize.substring(0, vmHeapSize.length()-1));
}
return staticGetLargeMemoryClass();
}
/**
* Return the approximate per-application memory class of the current
* device when an application is running with a large heap. This is the
* space available for memory-intensive applications; most applications
* should not need this amount of memory, and should instead stay with the
* {@link #getMemoryClass()} limit. The returned value is in megabytes.
* This may be the same size as {@link #getMemoryClass()} on memory
* constrained devices, or it may be significantly larger on devices with
* a large amount of available RAM.
*
* <p>The is the size of the application's Dalvik heap if it has
* specified <code>android:largeHeap="true"</code> in its manifest.
*/
public int getLargeMemoryClass() {
return staticGetLargeMemoryClass();
}
/** @hide */
static public int staticGetLargeMemoryClass() {
String vmHeapSize = SystemProperties.get("dalvik.vm.heapsize", "16m");
return Integer.parseInt(vmHeapSize.substring(0, vmHeapSize.length() - 1));
}
上面的源碼表明，getMemoryClass()和getLargeMemoryClass()方法最終讀取的仍然是dalvik.vm.heapgrowthlimit 和 dalvik.vm.heapsize 的值。而且赃梧，dalvik.vm.heapsize 默認(rèn)值為16M滤蝠，這也是解釋了google的原生OS默認(rèn)值是16M了。而 dalvik.vm.heapgrowthlimit 和 dalvik.vm.heapsize 的值各個(gè)手機(jī)廠家的OS會(huì)對(duì)這個(gè)值進(jìn)行修改授嘀，所以存在差異物咳。
在App中獲取內(nèi)存信息
我們?cè)趹?yīng)用中可以通過ActivityManager的MemoryInfo內(nèi)部類獲取內(nèi)存信息，方法如下：
private void getMemoryInfo() {
ActivityManager manager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo();
manager.getMemoryInfo(info);
Log.e("Memory","系統(tǒng)總內(nèi)存:"+(info.totalMem / (1024*1024))+"M");
Log.e("Memory","系統(tǒng)剩余內(nèi)存:"+(info.availMem / (1024*1024))+"M");
Log.e("Memory","系統(tǒng)是否處于低內(nèi)存運(yùn)行："+info.lowMemory );
Log.e("Memory","系統(tǒng)剩余內(nèi)存低于"+( info.threshold / (1024*1024))+"M時(shí)為低內(nèi)存運(yùn)行");
}
二. 進(jìn)程碧阒澹活方式
Android 進(jìn)程拉活包括兩個(gè)層面：
- 提供進(jìn)程優(yōu)先級(jí)览闰，降低進(jìn)程被殺死的概率
- 在進(jìn)程被殺死后，進(jìn)行拉活
2.1 進(jìn)程的優(yōu)先級(jí)
進(jìn)程的重要性巷折，劃分5級(jí)：
前臺(tái)進(jìn)程 (Foreground process)
可見進(jìn)程 (Visible process)
服務(wù)進(jìn)程 (Service process)
后臺(tái)進(jìn)程 (Background process)
空進(jìn)程 (Empty process)
2.1.1 前臺(tái)進(jìn)程
用戶當(dāng)前操作所必需的進(jìn)程压鉴。通常在任意給定時(shí)間前臺(tái)進(jìn)程都為數(shù)不多。只有在內(nèi)存不足以支持它們同時(shí)繼續(xù)運(yùn)行這一萬不得已的情況下锻拘，系統(tǒng)才會(huì)終止它們油吭。
1） 擁有用戶正在交互的 Activity（已調(diào)用 onResume()）
2） 擁有某個(gè) Service，后者綁定到用戶正在交互的 Activity
3） 擁有正在“前臺(tái)”運(yùn)行的 Service（服務(wù)已調(diào)用 startForeground()）
4） 擁有正執(zhí)行一個(gè)生命周期回調(diào)的 Service（onCreate()署拟、onStart() 或 onDestroy()）
5） 擁有正執(zhí)行其 onReceive() 方法的 BroadcastReceiver
2.1.2 可見進(jìn)程
沒有任何前臺(tái)組件上鞠、但仍會(huì)影響用戶在屏幕上所見內(nèi)容的進(jìn)程⌒旧ィ可見進(jìn)程被視為是極其重要的進(jìn)程芍阎，除非為了維持所有前臺(tái)進(jìn)程同時(shí)運(yùn)行而必須終止，否則系統(tǒng)不會(huì)終止這些進(jìn)程缨恒。
1）擁有不在前臺(tái)谴咸、但仍對(duì)用戶可見的 Activity（已調(diào)用 onPause()）
2）擁有綁定到可見（或前臺(tái)）Activity 的 Service
2.1.3 服務(wù)進(jìn)程
盡管服務(wù)進(jìn)程與用戶所見內(nèi)容沒有直接關(guān)聯(lián)，但是它們通常在執(zhí)行一些用戶關(guān)心的操作（例如骗露，在后臺(tái)播放音樂或從網(wǎng)絡(luò)下載數(shù)據(jù)）岭佳。因此，除非內(nèi)存不足以維持所有前臺(tái)進(jìn)程和可見進(jìn)程同時(shí)運(yùn)行萧锉，否則系統(tǒng)會(huì)讓服務(wù)進(jìn)程保持運(yùn)行狀態(tài)珊随。
正在運(yùn)行 startService() 方法啟動(dòng)的服務(wù)，且不屬于上述兩個(gè)更高類別進(jìn)程的進(jìn)程柿隙。
2.1.4 后臺(tái)進(jìn)程
后臺(tái)進(jìn)程對(duì)用戶體驗(yàn)沒有直接影響叶洞，系統(tǒng)可能隨時(shí)終止它們，以回收內(nèi)存供前臺(tái)進(jìn)程禀崖、可見進(jìn)程或服務(wù)進(jìn)程使用衩辟。 通常會(huì)有很多后臺(tái)進(jìn)程在運(yùn)行，因此它們會(huì)保存在 LRU 列表中波附，以確保包含用戶最近查看的 Activity 的進(jìn)程最后一個(gè)被終止艺晴。如果某個(gè) Activity 正確實(shí)現(xiàn)了生命周期方法昼钻，并保存了其當(dāng)前狀態(tài)，則終止其進(jìn)程不會(huì)對(duì)用戶體驗(yàn)產(chǎn)生明顯影響封寞，因?yàn)楫?dāng)用戶導(dǎo)航回該 Activity 時(shí)然评，Activity 會(huì)恢復(fù)其所有可見狀態(tài)。
對(duì)用戶不可見的 Activity 的進(jìn)程（已調(diào)用 Activity的onStop() 方法）
2.1.5 空進(jìn)程
保留這種進(jìn)程的的唯一目的是用作緩存狈究，以縮短下次在其中運(yùn)行組件所需的啟動(dòng)時(shí)間碗淌。 為使總體系統(tǒng)資源在進(jìn)程緩存和底層內(nèi)核緩存之間保持平衡，系統(tǒng)往往會(huì)終止這些進(jìn)程谦炒。
不含任何活動(dòng)應(yīng)用組件的進(jìn)程贯莺。
####### 2.2 Android進(jìn)程回收策略
Android 中對(duì)于內(nèi)存的回收风喇，主要依靠 Lowmemorykiller 來完成宁改，是一種根據(jù) OOM_ADJ 閾值級(jí)別觸發(fā)相應(yīng)力度的內(nèi)存回收的機(jī)制。
關(guān)于 OOM_ADJ 的說明如下：
其中紅色部分代表比較容易被殺死的 Android 進(jìn)程（OOM_ADJ>=4）魂莫，綠色部分表示不容易被殺死的 Android 進(jìn)程还蹲，其他表示非 Android 進(jìn)程（純 Linux 進(jìn)程）。在 Lowmemorykiller 回收內(nèi)存時(shí)會(huì)根據(jù)進(jìn)程的級(jí)別優(yōu)先殺死 OOM_ADJ 比較大的進(jìn)程耙考，對(duì)于優(yōu)先級(jí)相同的進(jìn)程則進(jìn)一步受到進(jìn)程所占內(nèi)存和進(jìn)程存活時(shí)間的影響谜喊。
Android 手機(jī)中進(jìn)程被殺死可能有如下情況：
綜上，可以得出減少進(jìn)程被殺死概率無非就是想辦法提高進(jìn)程優(yōu)先級(jí)倦始，減少進(jìn)程在內(nèi)存不足等情況下被殺死的概率斗遏。
2.3 提升進(jìn)程優(yōu)先級(jí)的方案
2.3.1 利用 Activity 提升權(quán)限
方案設(shè)計(jì)思想：監(jiān)控手機(jī)鎖屏解鎖事件，在屏幕鎖屏?xí)r啟動(dòng)1個(gè)像素的 Activity鞋邑，在用戶解鎖時(shí)將 Activity 銷毀掉诵次。注意該 Activity 需設(shè)計(jì)成用戶無感知。
通過該方案枚碗，可以使進(jìn)程的優(yōu)先級(jí)在屏幕鎖屏?xí)r間由4提升為最高優(yōu)先級(jí)1逾一。
方案適用范圍：
- 適用場景：本方案主要解決第三方應(yīng)用及系統(tǒng)管理工具在檢測到鎖屏事件后一段時(shí)間（一般為5分鐘以內(nèi)）內(nèi)會(huì)殺死后臺(tái)進(jìn)程，已達(dá)到省電的目的問題肮雨。
- 適用版本：適用于所有的 Android 版本遵堵。
方案具體實(shí)現(xiàn)：首先定義 Activity，并設(shè)置 Activity 的大小為1像素：
其次怨规，從 AndroidManifest 中通過如下屬性陌宿，排除 Activity 在 RecentTask 中的顯示：
最后，控制 Activity 為透明：
Activity 啟動(dòng)與銷毀時(shí)機(jī)的控制：
2.3.2 利用 Notification 提升權(quán)限
方案設(shè)計(jì)思想：Android 中 Service 的優(yōu)先級(jí)為4波丰，通過 setForeground 接口可以將后臺(tái) Service 設(shè)置為前臺(tái) Service限番，使進(jìn)程的優(yōu)先級(jí)由 4 提升為 2 ，從而使進(jìn)程的優(yōu)先級(jí)僅僅低于用戶當(dāng)前正在交互的進(jìn)程呀舔，與可見進(jìn)程優(yōu)先級(jí)一致弥虐，使進(jìn)程被殺死的概率大大降低扩灯。
方案實(shí)現(xiàn)挑戰(zhàn)：從 Android2.3 開始調(diào)用 setForeground 將后臺(tái) Service 設(shè)置為前臺(tái) Service 時(shí)，必須在系統(tǒng)的通知欄發(fā)送一條通知霜瘪，也就是前臺(tái) Service 與一條可見的通知時(shí)綁定在一起的珠插。
對(duì)于不需要常駐通知欄的應(yīng)用來說，該方案雖好颖对，但卻是用戶感知的捻撑，無法直接使用。
方案挑戰(zhàn)應(yīng)對(duì)措施：通過實(shí)現(xiàn)一個(gè)內(nèi)部 Service缤底，在 LiveService 和其內(nèi)部 Service 中同時(shí)發(fā)送具有相同 ID 的 Notification顾患，然后將內(nèi)部 Service 結(jié)束掉。隨著內(nèi)部 Service 的結(jié)束个唧，Notification 將會(huì)消失江解，但系統(tǒng)優(yōu)先級(jí)依然保持為2。
方案適用范圍：適用于目前已知所有版本徙歼。
方案具體實(shí)現(xiàn)：
2.4 進(jìn)程死后拉活的方案
2.4.1 利用系統(tǒng)廣播拉活
方案設(shè)計(jì)思想：在發(fā)生特定系統(tǒng)事件時(shí)犁河，系統(tǒng)會(huì)發(fā)出響應(yīng)的廣播，通過在 AndroidManifest 中“靜態(tài)”注冊(cè)對(duì)應(yīng)的廣播監(jiān)聽器魄梯，即可在發(fā)生響應(yīng)事件時(shí)拉活桨螺。
常用的用于拉活的廣播事件包括：
方案適用范圍：適用于全部 Android 平臺(tái)。但存在如下幾個(gè)缺點(diǎn)：
- 廣播接收器被管理軟件酿秸、系統(tǒng)軟件通過“自啟管理”等功能禁用的場景無法接收到廣播灭翔，從而無法自啟。
- 系統(tǒng)廣播事件不可控辣苏，只能保證發(fā)生事件時(shí)拉活進(jìn)程肝箱，但無法保證進(jìn)程掛掉后立即拉活。
2.4.2 利用第三方應(yīng)用廣播拉活
方案設(shè)計(jì)思想：該方案總的設(shè)計(jì)思想與接收系統(tǒng)廣播類似考润，不同的是該方案為接收第三方 Top 應(yīng)用廣播狭园。
通過反編譯第三方 Top 應(yīng)用，如：手機(jī)QQ糊治、微信唱矛、支付寶、UC瀏覽器等井辜，以及友盟绎谦、信鴿、個(gè)推等 SDK粥脚，找出它們外發(fā)的廣播窃肠，在應(yīng)用中進(jìn)行監(jiān)聽，這樣當(dāng)這些應(yīng)用發(fā)出廣播時(shí)刷允，就會(huì)將我們的應(yīng)用拉活冤留。
方案適用范圍：該方案的有效程度除與系統(tǒng)廣播一樣的因素外碧囊，主要受如下因素限制：
- 反編譯分析過的第三方應(yīng)用的多少
- 第三方應(yīng)用的廣播屬于應(yīng)用私有，當(dāng)前版本中有效的廣播纤怒，在后續(xù)版本隨時(shí)就可能被移除或被改為不外發(fā)糯而。
2.4.3 利用系統(tǒng)Service機(jī)制拉活
方案設(shè)計(jì)思想：將 Service 設(shè)置為 START_STICKY，利用系統(tǒng)機(jī)制在 Service 掛掉后自動(dòng)拉活：
方案適用范圍：如下兩種情況無法拉活
- Service 第一次被異常殺死后會(huì)在5秒內(nèi)重啟泊窘，第二次被殺死會(huì)在10秒內(nèi)重啟熄驼，第三次會(huì)在20秒內(nèi)重啟，一旦在短時(shí)間內(nèi) Service 被殺死達(dá)到5次烘豹，則系統(tǒng)不再拉起瓜贾。
- 進(jìn)程被取得 Root 權(quán)限的管理工具或系統(tǒng)工具通過 forestop 停止掉，無法重啟携悯。
2.4.4 利用Native進(jìn)程拉活
方案設(shè)計(jì)思想：
- 主要思想：利用 Linux 中的 fork 機(jī)制創(chuàng)建 Native 進(jìn)程祭芦，在 Native 進(jìn)程中監(jiān)控主進(jìn)程的存活，當(dāng)主進(jìn)程掛掉后蚌卤，在 Native 進(jìn)程中立即對(duì)主進(jìn)程進(jìn)行拉活实束。
- 主要原理：在 Android 中所有進(jìn)程和系統(tǒng)組件的生命周期受 ActivityManagerService 的統(tǒng)一管理奥秆。而且逊彭，通過 Linux 的 fork 機(jī)制創(chuàng)建的進(jìn)程為純 Linux 進(jìn)程，其生命周期不受 Android 的管理构订。
2.4.5 利用 JobScheduler 機(jī)制拉活
方案設(shè)計(jì)思想：Android5.0 以后系統(tǒng)對(duì) Native 進(jìn)程等加強(qiáng)了管理侮叮，Native 拉活方式失效。系統(tǒng)在 Android5.0 以上版本提供了 JobScheduler 接口悼瘾，系統(tǒng)會(huì)定時(shí)調(diào)用該進(jìn)程以使應(yīng)用進(jìn)行一些邏輯操作囊榜。
對(duì) JobScheduler 進(jìn)行了進(jìn)一步封裝，兼容 Android5.0 以下版本亥宿。封裝后 JobScheduler 接口的使用如下：
方案適用范圍：該方案主要適用于 Android5.0 以上版本手機(jī)卸勺。
該方案在 Android5.0 以上版本中不受 forcestop 影響，被強(qiáng)制停止的應(yīng)用依然可以被拉活烫扼，在 Android5.0 以上版本拉活效果非常好曙求。
僅在小米手機(jī)可能會(huì)出現(xiàn)有時(shí)無法拉活的問題。
2.5 其他有效拉活方案
這些方案包括：
- 利用系統(tǒng)通知管理權(quán)限進(jìn)行拉活
- 利用輔助功能拉活映企，將應(yīng)用加入廠商或管理軟件白名單悟狱。
這些方案需要結(jié)合具體產(chǎn)品特性來搞。
上面所有解釋這些方案都是考慮的無 Root 的情況堰氓。
其他還有一些技術(shù)之外的措施挤渐，比如說應(yīng)用內(nèi) Push 通道的選擇：
- 國外版應(yīng)用：接入 Google 的 GCM。
- 國內(nèi)版應(yīng)用：根據(jù)終端不同双絮，在小米手機(jī)（包括 MIUI）接入小米推送浴麻、華為手機(jī)接入華為推送得问；其他手機(jī)可以考慮接入騰訊信鴿或極光推送與小米推送做 A/B Test。
