1 進(jìn)程通訊

定義多進(jìn)程

Android應(yīng)用中使用多進(jìn)程只有一個(gè)辦法（用NDK的fork來(lái)做除外），就是在AndroidManifest.xml中聲明組件時(shí)，用android:process屬性來(lái)指定。

不知定process屬性，則默認(rèn)運(yùn)行在主進(jìn)程中，主進(jìn)程名字為包名。

android:process = package:remote，將運(yùn)行在package:remote進(jìn)程中，屬于全局進(jìn)程，其他具有相同shareUID與簽名的APP可以跑在這個(gè)進(jìn)程中。

android:process = :remote ，將運(yùn)行在默認(rèn)包名:remote進(jìn)程中，而且是APP的私有進(jìn)程，不允許其他APP的組件來(lái)訪問(wèn)。

多進(jìn)程引發(fā)的問(wèn)題

靜態(tài)成員和單例失效：每個(gè)進(jìn)程保持各自的靜態(tài)成員和單例，相互獨(dú)立。

線程同步機(jī)制失效：每個(gè)進(jìn)程有自己的線程鎖。

SharedPreferences可靠性下降：不支持并發(fā)寫(xiě)，會(huì)出現(xiàn)臟數(shù)據(jù)。

Application多次創(chuàng)建：不同進(jìn)程跑在不同虛擬機(jī)，每個(gè)虛擬機(jī)啟動(dòng)會(huì)創(chuàng)建自己的Application，自定義Application時(shí)生命周期會(huì)混亂。

綜上，不同進(jìn)程擁有各自獨(dú)立的虛擬機(jī)，Application，內(nèi)存空間，由此引發(fā)一系列問(wèn)題。

Bundle的使用

public final class Bundle extends BaseBundle implements Cloneable, Parcelable

可以看到Bundle實(shí)現(xiàn)了Parcelable 接口。

優(yōu)點(diǎn)：簡(jiǎn)單易用

缺點(diǎn)：只能傳遞Bundle支持的數(shù)據(jù)類型

使用場(chǎng)景：四大組件間的進(jìn)程通訊

2.文件共享

優(yōu)點(diǎn)：簡(jiǎn)單易用

缺點(diǎn)：不適合高并發(fā)的場(chǎng)景，不能做到即時(shí)通訊。

使用場(chǎng)景：無(wú)并發(fā)訪問(wèn)的情景，簡(jiǎn)單的交換數(shù)據(jù)，實(shí)時(shí)性要求不高。

3.AIDI

優(yōu)點(diǎn)：功能強(qiáng)大，支持一對(duì)多并發(fā)通信，支持實(shí)時(shí)通信。

缺點(diǎn)：一定要處理好線程同步的問(wèn)題

使用場(chǎng)景：一對(duì)多進(jìn)行通訊，有RPC（遠(yuǎn)程過(guò)程調(diào)用協(xié)議）的需求

4.Messenger(信使)

優(yōu)點(diǎn)：功能一般，支持一對(duì)多串行通信，支持實(shí)時(shí)通信。

缺點(diǎn)：不能很好的處理高并發(fā)場(chǎng)景，不支持RPC，數(shù)據(jù)通過(guò)Message進(jìn)行傳輸，因此只能支持Bundle支持的數(shù)據(jù)類型。

使用場(chǎng)景：低并發(fā)的一對(duì)多的實(shí)時(shí)通訊，沒(méi)有RPC的需求或者說(shuō)沒(méi)有返回結(jié)果的RPC（不調(diào)用服務(wù)端的相關(guān)方法）

5.ContentProvider

優(yōu)點(diǎn)：主要用于數(shù)據(jù)訪問(wèn)，支持一對(duì)多的并發(fā)數(shù)據(jù)共享。

缺點(diǎn)：受約束，主要針對(duì)數(shù)據(jù)源的增刪改查。

使用場(chǎng)景：一對(duì)多的數(shù)據(jù)共享。

6.Socket(套接字)

優(yōu)點(diǎn)：功能強(qiáng)大，通過(guò)讀寫(xiě)網(wǎng)絡(luò)傳輸字節(jié)流，支持一對(duì)多的并發(fā)的實(shí)時(shí)通訊。

缺點(diǎn)：不支持直接的RPC（這里我也不是很明白，間接的怎么實(shí)現(xiàn)？）

使用場(chǎng)景：網(wǎng)絡(luò)的數(shù)據(jù)交換

2 內(nèi)存管理

轉(zhuǎn)自http://m.itdecent.cn/p/c4b283848970

1、初識(shí)內(nèi)存優(yōu)化

在Android的性能優(yōu)化的各個(gè)部分里，內(nèi)存的問(wèn)題絕對(duì)是最令人頭疼的一部分，雖然Android有垃圾自動(dòng)回收機(jī)制不需要手動(dòng)干預(yù)，但也恰因?yàn)榇?，出現(xiàn)內(nèi)存問(wèn)題如內(nèi)存泄漏和內(nèi)存溢出等，如果對(duì)內(nèi)存管理機(jī)制不熟悉，會(huì)更加難以排查問(wèn)題。

因?yàn)閮?nèi)存方面的知識(shí)較多且不易理解，內(nèi)存優(yōu)化部分就分兩篇文章進(jìn)行，本文主要是關(guān)于Java、Android的內(nèi)存分配、回收、GC等理論知識(shí)。

2、內(nèi)存分配

談Android的內(nèi)存，就不能不提Java的內(nèi)存管理。Java程序在運(yùn)行的過(guò)程中會(huì)將其管理的內(nèi)存分為若干個(gè)不同的數(shù)據(jù)區(qū)：

JVM運(yùn)行時(shí)數(shù)據(jù)區(qū)

方法區(qū)：方法區(qū)存放的是類信息、常量、靜態(tài)變量，所有線程共享區(qū)域。

虛擬機(jī)棧：每個(gè)方法在執(zhí)行的同時(shí)都會(huì)創(chuàng)建一個(gè)棧幀（Stack Frame）用于存儲(chǔ)局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等信息，線程私有區(qū)域。

本地方法棧：與虛擬機(jī)棧類似，區(qū)別是虛擬機(jī)棧為虛擬機(jī)執(zhí)行Java方法服務(wù)，本地方法棧為虛擬機(jī)使用到的Native方法服務(wù)。

堆：JVM管理的內(nèi)存中最大的一塊，所有線程共享；用來(lái)存放對(duì)象實(shí)例，幾乎所有的對(duì)象實(shí)例都在堆上分配內(nèi)存；此區(qū)域也是垃圾回收器（Garbage Collection）主要的作用區(qū)域，內(nèi)存泄漏就發(fā)生在這個(gè)區(qū)域。

程序計(jì)數(shù)器：可看做是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號(hào)指示器；如果線程在執(zhí)行Java方法，這個(gè)計(jì)數(shù)器記錄的是正在執(zhí)行的虛擬機(jī)字節(jié)碼指令地址；如果執(zhí)行的是Native方法，這個(gè)計(jì)數(shù)器的值為空（Undefined）。

備注：

有一種習(xí)慣說(shuō)法：把Java的內(nèi)存區(qū)域分為堆內(nèi)存（Heap）和棧內(nèi)存（Stack），Stack訪問(wèn)快，Heap訪問(wèn)慢，Stack中保存的是對(duì)象的引用（指針），Heap中保存的是對(duì)象的實(shí)例。

實(shí)際上這種說(shuō)法是籠統(tǒng)、粗糙的，此處所說(shuō)的Stack僅僅是虛擬機(jī)棧中的局部變量表部分。虛擬機(jī)棧與JVM運(yùn)行時(shí)數(shù)據(jù)區(qū)涵蓋的都比此種說(shuō)法多。

3、內(nèi)存回收

3.1標(biāo)記-清除算法

最基礎(chǔ)的收集算法：分為“標(biāo)記”和“清除”兩個(gè)階段，首先，標(biāo)記出所有需要回收的對(duì)象，然后統(tǒng)一回收所有被標(biāo)記的對(duì)象。

這種方法有兩個(gè)不足點(diǎn)：

效率問(wèn)題，標(biāo)記和清除兩個(gè)過(guò)程的效率都不高；

空間問(wèn)題，標(biāo)記清除之后會(huì)產(chǎn)生大量的不連續(xù)的內(nèi)存碎片。

“標(biāo)記-清除”算法示意圖

3.2復(fù)制算法

將內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊，當(dāng)這一塊內(nèi)存將用完了，就將還存活著的對(duì)象復(fù)制到另一塊內(nèi)存上面，然后再把已使用過(guò)的內(nèi)存空間一次清理掉。

這種方法的特點(diǎn)：

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，運(yùn)行高效；每次都是對(duì)整個(gè)半?yún)^(qū)進(jìn)行內(nèi)存回收，內(nèi)存分配時(shí)也不需要考慮內(nèi)存碎片等情況，只要移動(dòng)堆頂指針，按順序分配內(nèi)存即可；

缺點(diǎn)：粗暴的將內(nèi)存縮小為原來(lái)的一半，代價(jià)實(shí)在有點(diǎn)高。

“復(fù)制”算法示意圖

3.3標(biāo)記-整理算法

先標(biāo)記需要回收的對(duì)象（標(biāo)記過(guò)程與“標(biāo)記-清除”算法一樣），然后把所有存活的對(duì)象都向一端移動(dòng)，然后直接清理掉端邊界以外的內(nèi)存。

這種方法的特點(diǎn)：

避免了內(nèi)存碎片；

避免了“復(fù)制”算法50%的空間浪費(fèi)；

主要針對(duì)對(duì)象存活率高的老年代。

“標(biāo)記-整理”算法示例圖.png

3.4分代收集算法

根據(jù)對(duì)象的存活周期的不同將內(nèi)存劃分為幾塊，一般是把Java堆分為新生代和老年代，這樣就可以根據(jù)各個(gè)年代的特點(diǎn)采用最適當(dāng)?shù)氖占惴?。在新生代中，每次垃圾收集時(shí)都會(huì)發(fā)現(xiàn)有大量對(duì)象死去，只有少量存活，那就選用復(fù)制算法，只需要付出少量存活對(duì)象的復(fù)制成本就可以完成收集。而老年代中因?yàn)閷?duì)象存活率高、沒(méi)有額外空間對(duì)它進(jìn)行分配擔(dān)保，就必須使用標(biāo)記—清除算法或標(biāo)記—整理算法來(lái)進(jìn)行回收。

4、對(duì)象是否回收的依據(jù)

4.1引用計(jì)數(shù)算法

給對(duì)象中添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用該對(duì)象時(shí)，計(jì)數(shù)器值加1；引用失效時(shí)，計(jì)數(shù)器值減1；任意時(shí)刻計(jì)數(shù)器為0的對(duì)象就是不可能再被使用的，表示該對(duì)象不存在引用關(guān)系。

這種方法的特點(diǎn)：

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，判定效率也很高；

缺點(diǎn)：難以解決對(duì)象之間相互循環(huán)引用導(dǎo)致計(jì)數(shù)器值不等于0的問(wèn)題。

4.2可達(dá)性分析算法

以一系列成為“GC Roots”的對(duì)象作為起始點(diǎn)，從這些節(jié)點(diǎn)開(kāi)始向下搜索，搜索所走過(guò)的路徑稱為引用鏈，當(dāng)一個(gè)對(duì)象到GC Roots沒(méi)有任何引用鏈相連（GC Roots到這個(gè)對(duì)象不可達(dá)），則證明此對(duì)象是不可用的。

可達(dá)性分析算法判定對(duì)象是否可回收

5、Android的內(nèi)存管理

Android系統(tǒng)的ART和Dalvik虛擬機(jī)扮演了常規(guī)的內(nèi)存垃圾自動(dòng)回收的角色， 使用paging和memory-mapping來(lái)管理內(nèi)存，這意味著不管是因?yàn)閯?chuàng)建對(duì)象還是使用使用內(nèi)存頁(yè)面造成的任何被修改的內(nèi)存，都會(huì)一直存在于內(nèi)存中，App唯一釋放內(nèi)存的方法就是釋放App持有的對(duì)象引用，使GC可以回收。

Android Runtime內(nèi)存堆劃分

5.1內(nèi)存回收

在Android的高級(jí)系統(tǒng)版本里面針對(duì)Heap空間有一個(gè)Generational Heap Memory的模型，最近分配的對(duì)象會(huì)存放在Young Generation區(qū)域，當(dāng)這個(gè)對(duì)象在這個(gè)區(qū)域停留的時(shí)間達(dá)到一定程度，它會(huì)被移動(dòng)到Old Generation，最后累積一定時(shí)間再移動(dòng)到Permanent Generation區(qū)域。系統(tǒng)會(huì)根據(jù)內(nèi)存中不同的內(nèi)存數(shù)據(jù)類型分別執(zhí)行不同的gc操作。例如，剛分配到Y(jié)oung Generation區(qū)域的對(duì)象通常更容易被銷毀回收，同時(shí)在Young Generation區(qū)域的gc操作速度會(huì)比Old Generation區(qū)域的gc操作速度更快。

5.2共享內(nèi)存

Android應(yīng)用的進(jìn)程都是從一個(gè)叫做Zygote的進(jìn)程fork出來(lái)的。Zygote進(jìn)程在系統(tǒng)啟動(dòng)并且載入通用的framework的代碼與資源之后開(kāi)始啟動(dòng)。為了啟動(dòng)一個(gè)新的程序進(jìn)程，系統(tǒng)會(huì)fork Zygote進(jìn)程生成一個(gè)新的進(jìn)程，然后在新的進(jìn)程中加載并運(yùn)行應(yīng)用程序的代碼。這使得大多數(shù)的RAM pages被用來(lái)分配給framework的代碼，同時(shí)使得RAM資源能夠在應(yīng)用的所有進(jìn)程之間進(jìn)行共享。

大多數(shù)static的數(shù)據(jù)被mmapped到一個(gè)進(jìn)程中。這不僅僅使得同樣的數(shù)據(jù)能夠在進(jìn)程間進(jìn)行共享，而且使得它能夠在需要的時(shí)候被paged out。常見(jiàn)的static數(shù)據(jù)包括Dalvik Code，app resources，so文件等。

大多數(shù)情況下，Android通過(guò)顯式的分配共享內(nèi)存區(qū)域(例如ashmem或者gralloc)來(lái)實(shí)現(xiàn)動(dòng)態(tài)RAM區(qū)域能夠在不同進(jìn)程之間進(jìn)行共享的機(jī)制。例如，Window Surface在App與Screen Compositor之間使用共享的內(nèi)存，Cursor Buffers在Content Provider與Clients之間共享內(nèi)存。

5.3分配與回收內(nèi)存

每一個(gè)進(jìn)程的Dalvik heap都反映了使用內(nèi)存的占用范圍。這就是通常邏輯意義上提到的Dalvik Heap Size，它可以隨著需要進(jìn)行增長(zhǎng)，但是增長(zhǎng)行為會(huì)有一個(gè)系統(tǒng)為它設(shè)定的上限。

邏輯上講的Heap Size和實(shí)際物理意義上使用的內(nèi)存大小是不對(duì)等的，Proportional Set Size(PSS)記錄了應(yīng)用程序自身占用以及和其他進(jìn)程進(jìn)行共享的內(nèi)存。

5.4限制應(yīng)用的內(nèi)存

為了整個(gè)Android系統(tǒng)的內(nèi)存控制需要，Android系統(tǒng)為每一個(gè)應(yīng)用程序都設(shè)置了一個(gè)硬性的Dalvik Heap Size最大限制閾值，這個(gè)閾值在不同的設(shè)備上會(huì)因?yàn)镽AM大小不同而各有差異。如果你的應(yīng)用占用內(nèi)存空間已經(jīng)接近這個(gè)閾值，此時(shí)再嘗試分配內(nèi)存的話，很容易引起OutOfMemoryError的錯(cuò)誤。

ActivityManager.getMemoryClass()可以用來(lái)查詢當(dāng)前應(yīng)用的Heap Size閾值，這個(gè)方法會(huì)返回一個(gè)整數(shù)，表明你的應(yīng)用的Heap Size閾值是多少M(fèi)b(megabates)。

5.5應(yīng)用切換

Android系統(tǒng)并不會(huì)在用戶切換應(yīng)用的時(shí)候做交換內(nèi)存的操作。Android會(huì)把那些不包含F(xiàn)oreground組件的應(yīng)用進(jìn)程放到LRU Cache中。例如，當(dāng)用戶開(kāi)始啟動(dòng)了一個(gè)應(yīng)用，系統(tǒng)會(huì)為它創(chuàng)建了一個(gè)進(jìn)程，但是當(dāng)用戶離開(kāi)這個(gè)應(yīng)用，此進(jìn)程并不會(huì)立即被銷毀，而是會(huì)被放到系統(tǒng)的Cache當(dāng)中，如果用戶后來(lái)再切換回到這個(gè)應(yīng)用，此進(jìn)程就能夠被馬上完整的恢復(fù)，從而實(shí)現(xiàn)應(yīng)用的快速切換。

如果你的應(yīng)用中有一個(gè)被緩存的進(jìn)程，這個(gè)進(jìn)程會(huì)占用一定的內(nèi)存空間，它會(huì)對(duì)系統(tǒng)的整體性能有影響。因此當(dāng)系統(tǒng)開(kāi)始進(jìn)入Low Memory的狀態(tài)時(shí)，它會(huì)由系統(tǒng)根據(jù)LRU的規(guī)則與應(yīng)用的優(yōu)先級(jí)，內(nèi)存占用情況以及其他因素的影響綜合評(píng)估之后決定是否被殺掉。

需要特別注意的：

在Dalvik下，大部分Davik采取的都是標(biāo)記-清理回收算法，而且具體使用什么算法是在編譯期決定的，無(wú)法在運(yùn)行的時(shí)候動(dòng)態(tài)更換。標(biāo)記-清理回收算法無(wú)法對(duì)Heap中空閑內(nèi)存區(qū)域做碎片整理。系統(tǒng)僅僅會(huì)在新的內(nèi)存分配之前判斷Heap的尾端剩余空間是否足夠，如果空間不夠會(huì)觸發(fā)gc操作，從而騰出更多空閑的內(nèi)存空間；這樣內(nèi)存空洞就產(chǎn)生了。

內(nèi)存碎片的產(chǎn)生

如上圖所示，第一行，在開(kāi)始階段，內(nèi)存分配較滿；第二行，經(jīng)過(guò)GC之后，大部分對(duì)象被釋放。此時(shí)可能產(chǎn)生的問(wèn)題是，因?yàn)闆](méi)有內(nèi)存整理功能，整個(gè)頁(yè)面的4KB內(nèi)存（內(nèi)存分配的最小單位是頁(yè)面，通常為4KB）可能只有一個(gè)小對(duì)象，但是統(tǒng)計(jì)PrivateDirty/Pss時(shí)還是按照4KB計(jì)算。所以對(duì)于Dalvik虛擬機(jī)的手機(jī)來(lái)說(shuō)，我們首先要盡量避免掉頻繁生成很多臨時(shí)小變量（比如說(shuō)：getView, onDraw等函數(shù)中new對(duì)象），另一個(gè)又要盡量去避免產(chǎn)生很多長(zhǎng)生命周期的大對(duì)象。

ART在GC上不像Dalvik僅有一種回收算法，ART在不同的情況下會(huì)選擇不同的回收算法。應(yīng)用程序在前臺(tái)運(yùn)行時(shí)，響應(yīng)性是最重要的，因此也要求執(zhí)行的GC是高效的。相反，應(yīng)用程序在后臺(tái)運(yùn)行時(shí)，響應(yīng)性不是最重要的，這時(shí)候就適合用來(lái)解決堆的內(nèi)存碎片問(wèn)題。因此，Mark-Sweep GC適合作為Foreground GC，而Mark-Compact GC適合作為Background GC。由于有Compact的能力存在，內(nèi)存碎片在ART上可以很好的被避免，這個(gè)也是ART一個(gè)很好的能力。

六、Android GC何時(shí)發(fā)生？

由上文我們知道，GC操作主要是由系統(tǒng)決定的，但是我們可以監(jiān)聽(tīng)系統(tǒng)的GC過(guò)程，以此來(lái)分析我們應(yīng)用程序當(dāng)前的內(nèi)存狀態(tài)。

Dalvik虛擬機(jī)，每一次GC打印內(nèi)容格式：

D/dalvikvm:,,,

含義解析

GC Reason：GC觸發(fā)原因

GC_CONCURRENT：當(dāng)已分配內(nèi)存達(dá)到某一值時(shí)，觸發(fā)并發(fā)GC；

GC_FOR_MALLOC：當(dāng)嘗試在堆上分配內(nèi)存不足時(shí)觸發(fā)的GC；系統(tǒng)必須停止應(yīng)用程序并回收內(nèi)存；

GC_HPROF_DUMP_HEAP： 當(dāng)需要?jiǎng)?chuàng)建HPROF文件來(lái)分析堆內(nèi)存時(shí)觸發(fā)的GC；

GC_EXPLICIT：當(dāng)明確的調(diào)用GC時(shí)，例如調(diào)用System.gc()或者通過(guò)DDMS工具顯式地告訴系統(tǒng)進(jìn)行GC操作等；

GC_EXTERNAL_ALLOC： 僅在API級(jí)別為10或者更低時(shí)（新版本分配內(nèi)存都在Dalvik堆上）

Amount freed GC：回收的內(nèi)存大小

Heap stats：堆上的空閑內(nèi)存百分比 （已用內(nèi)存）/（堆上總內(nèi)存）

External memory stats： API級(jí)別為10或者更低：（已分配的內(nèi)存量）/ （即將發(fā)生垃圾的極限）

Pause time：這次GC操作導(dǎo)致應(yīng)用程序暫停的時(shí)間。關(guān)于這個(gè)暫停的時(shí)間，在2.3之前GC操作是不能并發(fā)進(jìn)行的，也就是系統(tǒng)正在進(jìn)行GC，那么應(yīng)用程序就只能阻塞住等待GC結(jié)束。而自2.3之后，GC操作改成了并發(fā)的方式進(jìn)行，就是說(shuō)GC的過(guò)程中不會(huì)影響到應(yīng)用程序的正常運(yùn)行，但是在GC操作的開(kāi)始和結(jié)束的時(shí)候會(huì)短暫阻塞一段時(shí)間。

Art虛擬機(jī)，每一次GC打印內(nèi)容格式：

I/art:,,,,

基本情況和Dalvik沒(méi)有什么差別，GC的Reason更多了，還多了一個(gè)LOS_Space_Status.

LOS_Space_Status：Large Object Space，大對(duì)象占用的空間，這部分內(nèi)存并不是分配在堆上的，但仍屬于應(yīng)用程序內(nèi)存空間，主要用來(lái)管理 Bitmap 等占內(nèi)存大的對(duì)象，避免因分配大內(nèi)存導(dǎo)致堆頻繁 GC。

七、獲取內(nèi)存使用情況

通過(guò)命令行adb shell dumpsys meminfo packagename查看內(nèi)存詳細(xì)占用情況：

命令行查看內(nèi)存分配情況

其中幾個(gè)關(guān)鍵的數(shù)據(jù)：

Private（Clean和Dirty的）：應(yīng)用進(jìn)程單獨(dú)使用的內(nèi)存，代表著系統(tǒng)殺死你的進(jìn)程后可以實(shí)際回收的內(nèi)存總量**。通常需要特別關(guān)注其中更為昂貴的dirty部分，它不僅只被你的進(jìn)程使用而且會(huì)持續(xù)占用內(nèi)存而不能被從內(nèi)存中置換出存儲(chǔ)。申請(qǐng)的全部Dalvik和本地heap內(nèi)存都是Dirty的，和Zygote共享的Dalvik和本地heap內(nèi)存也都是Dirty的。

Dalvik Heap：Dalvik虛擬機(jī)使用的內(nèi)存，包含dalvik-heap和dalvik-zygote，堆內(nèi)存，所有的Java對(duì)象實(shí)例都放在這里。

Heap Alloc：累加了Dalvik和Native的heap。

PSS：這是加入與其他進(jìn)程共享的分頁(yè)內(nèi)存后你的應(yīng)用占用的內(nèi)存量，你的進(jìn)程單獨(dú)使用的全部?jī)?nèi)存也會(huì)加入這個(gè)值里，多進(jìn)程共享的內(nèi)存按照共享比例添加到PSS值中。如一個(gè)內(nèi)存分頁(yè)被兩個(gè)進(jìn)程共享，每個(gè)進(jìn)程的PSS值會(huì)包括此內(nèi)存分頁(yè)大小的一半在內(nèi)。

Dalvik Pss內(nèi)存 = 私有內(nèi)存Private Dirty + （共享內(nèi)存Shared Dirty / 共享進(jìn)程數(shù)）

TOTAL：上面全部條目的累加值，全局的展示了你的進(jìn)程占用的內(nèi)存情況。

ViewRootImpl：應(yīng)用進(jìn)程里的活動(dòng)窗口視圖個(gè)數(shù)，可以用來(lái)監(jiān)測(cè)對(duì)話框或者其他窗口的內(nèi)存泄露。

AppContexts及Activities：應(yīng)用進(jìn)程里Context和Activity的對(duì)象個(gè)數(shù)，可以用來(lái)監(jiān)測(cè)Activity的內(nèi)存泄露。

作者：頭條祁同偉

鏈接：http://m.itdecent.cn/p/c4b283848970

來(lái)源：簡(jiǎn)書(shū)

簡(jiǎn)書(shū)著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請(qǐng)聯(lián)系作者獲得授權(quán)并注明出處。