Android運(yùn)行環(huán)境一覽
Android基于linux內(nèi)核，面向移動(dòng)終端的操作系統(tǒng)。主要包括以下幾個(gè)方面：

Application Framework：
這一層為應(yīng)用開發(fā)者提供了豐富的應(yīng)用編程接口，如 Activity Manager，Content Provider，Notification Manager，以及各種窗口 Widget 資源等。所有的APP都是運(yùn)行在這一層之上。
Dalvik 虛擬機(jī)：
Dalvik VM采用寄存器架構(gòu)，而不是JVM的棧架構(gòu)，更適于移動(dòng)設(shè)備。java源代碼經(jīng)過編譯成為.class字節(jié)碼文件，然后由谷歌提供的 dx工具將其轉(zhuǎn)化為Dalvik可識(shí)別的.dex文件。
Linux kernel：
每個(gè)APP應(yīng)用程序由一個(gè)獨(dú)立的Dalvik VM來解釋執(zhí)行，而一個(gè)Dalvik VM實(shí)例對(duì)應(yīng)一個(gè)linux內(nèi)核進(jìn)程。
所以說，每個(gè)APP之間完全隔離，資源獨(dú)立。使得每個(gè)APP更加安全，但也不利于進(jìn)程間通信

Android官方介紹

**Android 系統(tǒng)架構(gòu)

Application framework
大部分開發(fā)者十分關(guān)心這一層。你必須要了解開發(fā)者會(huì)接觸到的所有API接口，大部分接口都與硬件抽象層(HAL層)接口一一對(duì)應(yīng)，而且它們會(huì)告訴你如何實(shí)現(xiàn)你自己的驅(qū)動(dòng)。

Binder IPC
Binder進(jìn)程間通信機(jī)制幫助Application framework層能夠跨進(jìn)程并且調(diào)用系統(tǒng)級(jí)服務(wù)。從根本上講，它幫助高級(jí)別的framework的API接口與Android系統(tǒng)服務(wù)進(jìn)行交互。

系統(tǒng)服務(wù)
大部分Application framework api具備的功能都要依靠與某種系統(tǒng)服務(wù)進(jìn)行通信從而操作底層硬件。系統(tǒng)服務(wù)根據(jù)不同的功能分成了若干模塊組件，例如Window Manager, Search Service, or Notification Manager。系統(tǒng)服務(wù)主要包含兩大塊：系統(tǒng)和媒體。前者對(duì)應(yīng)的服務(wù)包含如Window Manager 或 Notification Manager，后者對(duì)應(yīng)的服務(wù)都與播放或記錄媒體有關(guān)。
硬件抽象層Hardware abstraction layer (HAL)
硬件抽象層可以作為一個(gè)標(biāo)準(zhǔn)接口讓Android系統(tǒng)調(diào)用設(shè)備驅(qū)動(dòng)層而不用管這些驅(qū)動(dòng)和硬件時(shí)如何實(shí)現(xiàn)的。
![硬件驅(qū)動(dòng)層相關(guān)組件]
Linux Kernel
大多數(shù)情況下，你自己開發(fā)設(shè)備驅(qū)動(dòng)和開發(fā)linux設(shè)備驅(qū)動(dòng)時(shí)一樣的。Android挑選了一個(gè)特定的linux內(nèi)核版本，這個(gè)版本包含了如wakelocks(一個(gè)內(nèi)存管理系統(tǒng))，Binder IPC驅(qū)動(dòng)和其他一些特征，這些特征對(duì)于像Android一樣的移動(dòng)嵌入式平臺(tái)都非常重要。你也可以根據(jù)自己的需求選擇合適的kernel版本，只要它能支持一些必要的屬性如Binder IPC驅(qū)動(dòng)等。但是，我們?nèi)匀煌扑]你使用最新版本的Android內(nèi)核。具體可參考內(nèi)核編譯
相關(guān)知識(shí)點(diǎn)：
應(yīng)用程序進(jìn)程間隔離機(jī)制：
Android系統(tǒng)包括四層架構(gòu)：從底層往上依次是Linux kernel層、C/C++函數(shù)庫(kù)與Android運(yùn)行時(shí)環(huán)境(Dalvik VM等)層、Android Framwork框架層、應(yīng)用程序?qū)?。其中，Android運(yùn)行時(shí)環(huán)境層類似Java里的JRE層，主要用來運(yùn)行java程序，不過此處的虛擬機(jī)是Dalvik虛擬機(jī)。每一個(gè)Android應(yīng)用程序都運(yùn)行在單獨(dú)的Davlik進(jìn)程里，Dalvik虛擬機(jī)針對(duì)同時(shí)高效運(yùn)行多個(gè)虛擬機(jī)而優(yōu)化，在這一層實(shí)現(xiàn)了應(yīng)用程序的進(jìn)程間隔離。

Dalvik虛擬機(jī)與JVM區(qū)別：

JVM直接從.class或Jar包中加載字節(jié)碼解釋運(yùn)行，Dalvik通過DX工具將.class文件編譯為.dex文件（Dalvik Executable）來運(yùn)行。
JVM采用棧結(jié)構(gòu)，而Dalvik采用寄存器結(jié)構(gòu)，更適于移動(dòng)設(shè)備。
為何Android要采用Dalvik虛擬機(jī)而不是JVM呢？

大多數(shù)虛擬機(jī)（包括JVM）都是基于棧的，而Dalvik虛擬機(jī)則是基于寄存器的，性能更好，不過也導(dǎo)致硬件通用性略差；
運(yùn)行專有.dex文件。DX工具對(duì).class文件編譯時(shí)，去除里面的冗余信息，并把所有.class文件整合到一個(gè)文件中，提高了性能。同時(shí)DX工具還會(huì)對(duì).dex文件進(jìn)行性能優(yōu)化。

內(nèi)存管理及優(yōu)化
一、Android內(nèi)存基礎(chǔ)
物理內(nèi)存與進(jìn)程內(nèi)存
物理內(nèi)存即移動(dòng)設(shè)備上的RAM，當(dāng)啟動(dòng)一個(gè)Android程序時(shí)，會(huì)啟動(dòng)一個(gè)Dalvik VM進(jìn)程，系統(tǒng)會(huì)給它分配固定的內(nèi)存空間（16M,32M不定），這塊內(nèi)存空間會(huì)映射到RAM上某個(gè)區(qū)域。然后這個(gè)Android程序就會(huì)運(yùn)行在這塊空間上。Java里會(huì)將這塊空間分成Stack棧內(nèi)存和Heap堆內(nèi)存。stack里存放對(duì)象的引用，heap里存放實(shí)際對(duì)象數(shù)據(jù)。
在程序運(yùn)行中會(huì)創(chuàng)建對(duì)象，如果未合理管理內(nèi)存，比如不及時(shí)回收無效空間就會(huì)造成內(nèi)存泄露，嚴(yán)重的話可能導(dǎo)致使用內(nèi)存超過系統(tǒng)分配內(nèi)存，即內(nèi)存溢出OOM，導(dǎo)致程序卡頓甚至直接退出。

內(nèi)存泄露（Memory Leak）
Java內(nèi)存泄漏指的是進(jìn)程中某些對(duì)象（垃圾對(duì)象）已經(jīng)沒有使用價(jià)值了，但是它們卻可以直接或間接地引用到gc roots導(dǎo)致無法被GC回收。Dalvik VM具備的GC機(jī)制（垃圾回收機(jī)制）會(huì)在內(nèi)存占用過多時(shí)自動(dòng)回收，嚴(yán)重時(shí)會(huì)造成內(nèi)存溢出OOM。

內(nèi)存溢出OOM
當(dāng)應(yīng)用程序申請(qǐng)的java heap空間超過Dalvik VM HeapGrowthLimit時(shí)，溢出。
注意：OOM并不代表內(nèi)存不足，只要申請(qǐng)的heap超過Dalvik VM HeapGrowthLimit時(shí)，即使內(nèi)存充足也會(huì)溢出。效果是能讓較多進(jìn)程常駐內(nèi)存。

如果RAM不足時(shí)系統(tǒng)會(huì)做什么？
Android的Memory Killer會(huì)殺死優(yōu)先級(jí)較低的進(jìn)程，讓高優(yōu)先級(jí)進(jìn)程獲取更多內(nèi)存。

Android系統(tǒng)默認(rèn)內(nèi)存回收機(jī)制

進(jìn)程優(yōu)先級(jí)：Foreground進(jìn)程、Visible進(jìn)程、Service進(jìn)程、Background進(jìn)程、Empty進(jìn)程;
如果用戶按Home鍵返回桌面，那么該app成為Background進(jìn)程；如果按Back返回，則成為Empty進(jìn)程
ActivityManagerService直接管理所有進(jìn)程的內(nèi)存資源分配。所有進(jìn)程要申請(qǐng)或釋放內(nèi)存都需要通過ActivityManagerService對(duì)象。
垃圾回收不定期執(zhí)行。當(dāng)內(nèi)存不夠時(shí)就會(huì)遍歷heap空間，把垃圾對(duì)象刪除。
堆內(nèi)存越大，則GC的時(shí)間更長(zhǎng)

二、優(yōu)化
Bitmap優(yōu)化
Bitmap非常消耗內(nèi)存，而且在Android中，讀取bitmap時(shí)， 一般分配給虛擬機(jī)的圖片堆棧只有8M，所以經(jīng)常造成OOM問題。所以有必要針對(duì)Bitmap的使用作出優(yōu)化：

• 圖片顯示：加載合適尺寸的圖片，比如顯示縮略圖的地方不要加載大圖。
• 圖片回收：使用完bitmap，及時(shí)使用Bitmap.recycle()回收。
• 問題：Android不是自身具備垃圾回收機(jī)制嗎？此處為何要手動(dòng)回收。
• Bitmap對(duì)象不是new生成的，而是通過BitmapFactory生產(chǎn)的。而且通過源碼可發(fā)現(xiàn)是通過調(diào)用JNI生成Bitmap對(duì)象（nativeDecodeStream()等方法）。所以，加載bitmap到內(nèi)存里包括兩部分，Dalvik內(nèi)存和Linux kernel內(nèi)存。前者會(huì)被虛擬機(jī)自動(dòng)回收。而后者必須通過recycle()方法，內(nèi)部調(diào)用nativeRecycle()讓linux kernel回收。
• 捕獲OOM異常：程序中設(shè)定如果發(fā)生OOM的應(yīng)急處理方式。
• 圖片緩存：內(nèi)存緩存、硬盤緩存等
• 圖片壓縮：直接使用ImageView顯示Bitmap時(shí)會(huì)占很多資源，尤其當(dāng)圖片較大時(shí)容易發(fā)生OOM?？梢允褂肂itMapFactory.Options對(duì)圖片進(jìn)行壓縮。
• 圖片像素：android默認(rèn)顏色模式為ARGB_8888，顯示質(zhì)量最高，占用內(nèi)存最大。若要求不高時(shí)可采用RGB_565等模式。圖片大小：圖片長(zhǎng)度*寬度*單位像素所占據(jù)字節(jié)數(shù)
• ARGB_4444：每個(gè)像素占用2byte內(nèi)存
• ARGB_8888：每個(gè)像素占用4byte內(nèi)存 （默認(rèn)）
• RGB_565：每個(gè)像素占用2byte內(nèi)存

對(duì)象引用類型

強(qiáng)引用 strong：Object object=new Object()。當(dāng)內(nèi)存不足時(shí)，Java虛擬機(jī)寧愿拋出OOM內(nèi)存溢出異常，也不會(huì)輕易回收強(qiáng)引用對(duì)象來解決內(nèi)存不足問題；
軟引用 soft：只有當(dāng)內(nèi)存達(dá)到某個(gè)閾值時(shí)才會(huì)去回收，常用于緩存；
弱引用 weak ：只要被GC線程掃描到了就進(jìn)行回收；
虛引用
如果想要避免OOM發(fā)生，則使用軟引用對(duì)象，即當(dāng)內(nèi)存快不足時(shí)進(jìn)行回收；如果想盡快回收某些占用內(nèi)存較大的對(duì)象，例如bitmap，可以使用弱引用，能被快速回收。不過如果要對(duì)bitmap作緩存就不要使用弱引用，因?yàn)楹芸炀蜁?huì)被GC回收，導(dǎo)致緩存失敗。
池 pool

對(duì)象池：如果某個(gè)對(duì)象在創(chuàng)建時(shí)，需要較大的資源開銷，那么可以將其放入對(duì)象池，即將對(duì)象保存起來，下次需要時(shí)直接取出使用，而不用再次創(chuàng)建對(duì)象。當(dāng)然，維護(hù)對(duì)象池也需要一定開銷，故要衡量。
線程池：與對(duì)象池差不多，將線程對(duì)象放在池中供反復(fù)使用，減少反復(fù)創(chuàng)建線程的開銷。

最新評(píng)論