1）Android為每個(gè)應(yīng)用程序分配的內(nèi)存大小是多少？
2）Android中進(jìn)程內(nèi)存的分配，能不能自己分配定額內(nèi)存？
3）進(jìn)程?；畹姆绞?br>
4）如何保證一個(gè)后臺服務(wù)不被殺死？（相同問題：如何保證service在后臺不被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í)，采用彈性的分配方式，即剛開始并不會給應(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。
這臺手機(jī)，系統(tǒng)正常分配的內(nèi)存最多為192M；當(dāng)設(shè)置largeHeap時(shí)，最多可申請512M。當(dāng)超過這個(gè)值時(shí)，就會出現(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申請的最大內(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會對這個(gè)值進(jìn)行修改，所以存在差異。
在App中獲取內(nèi)存信息
我們在應(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)程?；罘绞?/h5>
Android 進(jìn)程拉活包括兩個(gè)層面：
- 提供進(jìn)程優(yōu)先級，降低進(jìn)程被殺死的概率
- 在進(jìn)程被殺死后，進(jìn)行拉活
2.1 進(jìn)程的優(yōu)先級
進(jìn)程的重要性，劃分5級：
前臺進(jìn)程 (Foreground process)
可見進(jìn)程 (Visible process)
服務(wù)進(jìn)程 (Service process)
后臺進(jìn)程 (Background process)
空進(jìn)程 (Empty process)
2.1.1 前臺進(jìn)程
用戶當(dāng)前操作所必需的進(jìn)程。通常在任意給定時(shí)間前臺進(jìn)程都為數(shù)不多。只有在內(nèi)存不足以支持它們同時(shí)繼續(xù)運(yùn)行這一萬不得已的情況下，系統(tǒng)才會終止它們。
1） 擁有用戶正在交互的 Activity（已調(diào)用 onResume()）
2） 擁有某個(gè) Service，后者綁定到用戶正在交互的 Activity
3） 擁有正在“前臺”運(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)程
沒有任何前臺組件、但仍會影響用戶在屏幕上所見內(nèi)容的進(jìn)程。可見進(jìn)程被視為是極其重要的進(jìn)程，除非為了維持所有前臺進(jìn)程同時(shí)運(yùn)行而必須終止，否則系統(tǒng)不會終止這些進(jìn)程。
1）擁有不在前臺、但仍對用戶可見的 Activity（已調(diào)用 onPause()）
2）擁有綁定到可見（或前臺）Activity 的 Service
2.1.3 服務(wù)進(jìn)程
盡管服務(wù)進(jìn)程與用戶所見內(nèi)容沒有直接關(guān)聯(lián)，但是它們通常在執(zhí)行一些用戶關(guān)心的操作（例如，在后臺播放音樂或從網(wǎng)絡(luò)下載數(shù)據(jù)）。因此，除非內(nèi)存不足以維持所有前臺進(jìn)程和可見進(jìn)程同時(shí)運(yùn)行，否則系統(tǒng)會讓服務(wù)進(jìn)程保持運(yùn)行狀態(tài)。
正在運(yùn)行 startService() 方法啟動(dòng)的服務(wù)，且不屬于上述兩個(gè)更高類別進(jìn)程的進(jìn)程。
2.1.4 后臺進(jìn)程
后臺進(jìn)程對用戶體驗(yàn)沒有直接影響，系統(tǒng)可能隨時(shí)終止它們，以回收內(nèi)存供前臺進(jìn)程、可見進(jìn)程或服務(wù)進(jìn)程使用。 通常會有很多后臺進(jìn)程在運(yùn)行，因此它們會保存在 LRU 列表中，以確保包含用戶最近查看的 Activity 的進(jìn)程最后一個(gè)被終止。如果某個(gè) Activity 正確實(shí)現(xiàn)了生命周期方法，并保存了其當(dāng)前狀態(tài)，則終止其進(jìn)程不會對用戶體驗(yàn)產(chǎn)生明顯影響，因?yàn)楫?dāng)用戶導(dǎo)航回該 Activity 時(shí)，Activity 會恢復(fù)其所有可見狀態(tài)。
對用戶不可見的 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)往往會終止這些進(jìn)程。
不含任何活動(dòng)應(yīng)用組件的進(jìn)程。
####### 2.2 Android進(jìn)程回收策略
Android 中對于內(nèi)存的回收，主要依靠 Lowmemorykiller 來完成，是一種根據(jù) OOM_ADJ 閾值級別觸發(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í)會根據(jù)進(jìn)程的級別優(yōu)先殺死 OOM_ADJ 比較大的進(jìn)程，對于優(yōu)先級相同的進(jìn)程則進(jìn)一步受到進(jìn)程所占內(nèi)存和進(jìn)程存活時(shí)間的影響。
Android 手機(jī)中進(jìn)程被殺死可能有如下情況：
綜上，可以得出減少進(jìn)程被殺死概率無非就是想辦法提高進(jìn)程優(yōu)先級，減少進(jìn)程在內(nèi)存不足等情況下被殺死的概率。
2.3 提升進(jìn)程優(yōu)先級的方案
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)先級在屏幕鎖屏?xí)r間由4提升為最高優(yōu)先級1。
方案適用范圍：
- 適用場景：本方案主要解決第三方應(yīng)用及系統(tǒng)管理工具在檢測到鎖屏事件后一段時(shí)間（一般為5分鐘以內(nèi)）內(nè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)先級為4，通過 setForeground 接口可以將后臺 Service 設(shè)置為前臺 Service，使進(jìn)程的優(yōu)先級由 4 提升為 2 ，從而使進(jìn)程的優(yōu)先級僅僅低于用戶當(dāng)前正在交互的進(jìn)程，與可見進(jìn)程優(yōu)先級一致，使進(jìn)程被殺死的概率大大降低。
方案實(shí)現(xiàn)挑戰(zhàn)：從 Android2.3 開始調(diào)用 setForeground 將后臺 Service 設(shè)置為前臺 Service 時(shí)，必須在系統(tǒng)的通知欄發(fā)送一條通知，也就是前臺 Service 與一條可見的通知時(shí)綁定在一起的。
對于不需要常駐通知欄的應(yīng)用來說，該方案雖好，但卻是用戶感知的，無法直接使用。
方案挑戰(zhàn)應(yīng)對措施：通過實(shí)現(xiàn)一個(gè)內(nèi)部 Service，在 LiveService 和其內(nèi)部 Service 中同時(shí)發(fā)送具有相同 ID 的 Notification，然后將內(nèi)部 Service 結(jié)束掉。隨著內(nèi)部 Service 的結(jié)束，Notification 將會消失，但系統(tǒng)優(yōu)先級依然保持為2。
方案適用范圍：適用于目前已知所有版本。
方案具體實(shí)現(xiàn)：
2.4 進(jìn)程死后拉活的方案
2.4.1 利用系統(tǒng)廣播拉活
方案設(shè)計(jì)思想：在發(fā)生特定系統(tǒng)事件時(shí)，系統(tǒng)會發(fā)出響應(yīng)的廣播，通過在 AndroidManifest 中“靜態(tài)”注冊對應(yīng)的廣播監(jiān)聽器，即可在發(fā)生響應(yīng)事件時(shí)拉活。
常用的用于拉活的廣播事件包括：
方案適用范圍：適用于全部 Android 平臺。但存在如下幾個(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í)，就會將我們的應(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 第一次被異常殺死后會在5秒內(nèi)重啟，第二次被殺死會在10秒內(nèi)重啟，第三次會在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)程中立即對主進(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)對 Native 進(jìn)程等加強(qiáng)了管理，Native 拉活方式失效。系統(tǒng)在 Android5.0 以上版本提供了 JobScheduler 接口，系統(tǒng)會定時(shí)調(diào)用該進(jìn)程以使應(yīng)用進(jìn)行一些邏輯操作。
對 JobScheduler 進(jìn)行了進(jìn)一步封裝，兼容 Android5.0 以下版本。封裝后 JobScheduler 接口的使用如下：
方案適用范圍：該方案主要適用于 Android5.0 以上版本手機(jī)。
該方案在 Android5.0 以上版本中不受 forcestop 影響，被強(qiáng)制停止的應(yīng)用依然可以被拉活，在 Android5.0 以上版本拉活效果非常好。
僅在小米手機(jī)可能會出現(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。
