轉(zhuǎn)載：https://blog.csdn.net/haoxuhong/article/details/80599176

導(dǎo)語(yǔ)

安卓大軍浩浩蕩蕩，發(fā)展已近十個(gè)年頭，技術(shù)優(yōu)化月新日異，如今Android 9.0 代號(hào)P都發(fā)布了，Android系統(tǒng)性能已經(jīng)非常流暢了。但是，到了各大廠商手里，改源碼自定系統(tǒng)，使得Android原生系統(tǒng)變得魚(yú)龍混雜。另外，到了不同層次的開(kāi)發(fā)工程師手里，因?yàn)榧夹g(shù)水平的參差不齊，即使很多手機(jī)在跑分軟件性能非常高，打開(kāi)應(yīng)用依然存在卡頓現(xiàn)象。另外，隨著產(chǎn)品內(nèi)容迭代，功能越來(lái)越復(fù)雜，UI頁(yè)面也越來(lái)越豐富，也成為流暢運(yùn)行的一種阻礙。綜上所述，對(duì)APP進(jìn)行性能優(yōu)化已成為開(kāi)發(fā)者該有的一種綜合素質(zhì)，也是開(kāi)發(fā)者能夠完成高質(zhì)量應(yīng)用程序的重要考核之一。

一、性能檢測(cè)工具

（一）網(wǎng)易開(kāi)源的Emmagee ，https://github.com/NetEase/Emmagee? ?

????Emmagee(機(jī)關(guān)槍)是網(wǎng)易杭州研究院QA團(tuán)隊(duì)開(kāi)發(fā)的一個(gè)簡(jiǎn)單易上手的Android性能監(jiān)測(cè)小工具，主要用于監(jiān)控單個(gè)App的CPU，內(nèi)存，流量，啟動(dòng)耗時(shí)，電量，電流等性能狀態(tài)的變化，且用戶可自定義配置監(jiān)控的頻率以及性能的實(shí)時(shí)顯示，并最終生成一份性能統(tǒng)計(jì)文件。對(duì)于手游實(shí)時(shí)分析CPU和內(nèi)存占比幫助非常大。

（1）優(yōu)勢(shì)

開(kāi)源；

無(wú)需root權(quán)限；

使用方便；

實(shí)時(shí)展示數(shù)據(jù)；

CSV格式保存性能數(shù)據(jù)，方便轉(zhuǎn)換為其它格式；

自定義采集頻率；

支持2.2以及以上版本。(由于Google 安全限制，在7.0版本手機(jī)不支持，找個(gè)低版本手機(jī)去測(cè)就完了）

（2）檢測(cè)案例

1、在GitHub下載安裝包Apk

2、運(yùn)行Emmagee.app。可以設(shè)置采集頻率。

3、點(diǎn)擊APP"測(cè)試報(bào)告"查看，也可以配置郵件下發(fā)CSV文件。而我選擇盜取文件到電腦上用Excel表格看。

（本地內(nèi)部存儲(chǔ)Emmagee目錄”storage\sdcard0\Emmagee\某日期時(shí)間_APP包名.csv”的文件，即為監(jiān)控?cái)?shù)據(jù)）

操作adb查看命令：

[objc]view plaincopy

$?adb?shell????//回車??

$?cd?storage/sdcard0/Emmagee/????//回車??

$?ls//回車?，結(jié)果如下：??

20180605154517_com.daojia.csv??

20180605160747_me.ele.csv??

*手機(jī)導(dǎo)出的csv文件出現(xiàn)亂碼，原因是由于導(dǎo)出的CSV文件編碼為UTF-8 。解決辦法：（Windows）使用記事本打開(kāi)另存為“ANSI編碼”的CSV格式文件即可。(Mac OS）文本編輯打開(kāi)重新保存即可。

上面分別是對(duì)到家點(diǎn)餐APP、餓了么點(diǎn)餐APP的CSV檢測(cè)數(shù)據(jù)。移動(dòng)文件到電腦Excel打開(kāi)查看：

（二）騰訊開(kāi)源的GT，https://github.com/TencentOpen/GT

（1）什么是GT?

GT（隨身調(diào)）安卓/IOS手機(jī)端調(diào)測(cè)組件，用于APP的性能測(cè)試、競(jìng)品測(cè)試及僅憑一臺(tái)手機(jī)即可進(jìn)行App測(cè)試。利用GT，僅憑一部手機(jī)，無(wú)需連接電腦，您即可對(duì)APP進(jìn)行快速的性能測(cè)試(CPU、內(nèi)存、流量、電量、幀率/流暢度等)、 開(kāi)發(fā)日志的查看、Crash日志查看、網(wǎng)絡(luò)數(shù)據(jù)包的抓取、APP內(nèi)部參數(shù)的調(diào)試、真機(jī)代碼耗時(shí)統(tǒng)計(jì)等等；更重要的是，您可以在任意真實(shí)場(chǎng)所、 任何時(shí)候做如上的系列事情，這就是“APP的場(chǎng)測(cè)”。如果您覺(jué)得GT提供的功能還不夠滿足您的需要， 您還可以利用GT提供的基礎(chǔ)API自行開(kāi)發(fā)有特殊功能的GT插件（目前，僅iOS版支持）， 幫助您解決更加復(fù)雜的APP調(diào)試、測(cè)試問(wèn)題。

（2）如何使用？

????GT支持iOS和Android兩個(gè)手機(jī)平臺(tái)，其中： Android版由一個(gè)可直接安裝的GT控制臺(tái)APP 和GT SDK插件擴(kuò)展檢測(cè)。GT控制臺(tái)可以獨(dú)立安裝使用，SDK需嵌入被調(diào)測(cè)的應(yīng)用、并利用GT控制臺(tái)進(jìn)行信息展示和參數(shù)修改。 iOS版是一個(gè)Framework包，必須嵌入APP工程，編譯出帶GT的APP才能使用；iPhone和iPad應(yīng)用都能支持。

此處以Android版GT控制臺(tái)APP 檢測(cè)主功能為案例，簡(jiǎn)要介紹使用步驟：

1、應(yīng)用寶下載GT.APP，安裝運(yùn)行GT。

2、選擇應(yīng)用 ? ? ? ? ? ? ? ? ? ? ? ? ??????????????????????????????? ? ? ? ??? ? ? ??

3、選擇關(guān)注的監(jiān)控?cái)?shù)據(jù) ??????????????????? ? 4、結(jié)果展示

（三）科大訊飛的iTest，http://www.liqucn.com/rj/410791.shtml

iTest官方介紹：

該工具由科大訊飛測(cè)試技術(shù)部開(kāi)發(fā)，在多個(gè)項(xiàng)目中成功應(yīng)用，具有較高的準(zhǔn)確性和穩(wěn)定性。它填補(bǔ)了手機(jī)端自動(dòng)化測(cè)試的空白，以實(shí)用高效為宗旨，記錄特定應(yīng)用的性能消耗情況，包括cpu、內(nèi)存、流量、電量等信息。效果圖如下所示。

遺憾本人尋遍全網(wǎng)，只能查找下載安裝Apk的地址，查閱其他的相關(guān)介紹和資料太少。

畢竟科大訊飛在業(yè)界是很有名氣的是訊飛語(yǔ)音。

（四）Google的開(kāi)源Battery Historian，https://github.com/google/battery-historian

文檔是純英文版的，使用需要配置環(huán)境，包括go/java/python/git的安裝與配置。

從github上下載Battery Historian。經(jīng)過(guò)一頓操作后，最終效果圖如下。

由于需要花費(fèi)大量時(shí)間和精力成本投入到研究當(dāng)中，所以后期有機(jī)會(huì)再補(bǔ)全使用教程。

二、性能優(yōu)化方法

使用性能檢查工具，可以將自身產(chǎn)品與競(jìng)爭(zhēng)者產(chǎn)品做對(duì)比，發(fā)現(xiàn)自身的優(yōu)勢(shì)的同時(shí)，也可以找到自身產(chǎn)品存在的不足之處。那么，接下來(lái)需要思考自身產(chǎn)品如何進(jìn)行性能的優(yōu)化和改進(jìn)的方法。本著人道主義，一切從用戶體驗(yàn)的角度去思考，置身處地得把自己當(dāng)做用戶去玩一款應(yīng)用時(shí)候會(huì)在意些什么呢？假如飯點(diǎn)將至，需要打開(kāi)到家APP進(jìn)行點(diǎn)餐，首先一定不希望，在瀏覽商家和菜品列表內(nèi)容很豐富的時(shí)候遇到卡頓現(xiàn)象，然后千挑萬(wàn)選后在期待美食將至的心情下準(zhǔn)備下單，突然遇到閃退崩潰那簡(jiǎn)直想卸載到家APP的心都有了。其次就是配送員在配送過(guò)程中不希望耗電和耗流量太嚴(yán)重。最后就是版本更新的時(shí)候安裝包希望能小一點(diǎn)。

????用戶希望的四個(gè)方面需求總結(jié)如下：

穩(wěn)定（內(nèi)存溢出、崩潰）

流暢（卡頓）

耗損（耗電、流量）

安裝包（APK瘦身）

（一）穩(wěn)定——內(nèi)存優(yōu)化

????由于Android應(yīng)用的沙箱機(jī)制，即每一個(gè)Android應(yīng)用程序都在它自己的進(jìn)程中運(yùn)行，都擁有一個(gè)獨(dú)立的Dalvik虛擬機(jī)實(shí)例，系統(tǒng)默認(rèn)給每個(gè)應(yīng)用所分配的內(nèi)存大小是有限度的，例如：華為mate7，192m ；小米4，128m ；紅米，128m ；三星SM-N7508v：96m。Android4.0以后，可以通過(guò)在application節(jié)點(diǎn)中設(shè)置屬性android:largeHeap=”true”來(lái)設(shè)置最大可分配多少內(nèi)存空間就可以突破一定限制。但是，當(dāng)系統(tǒng)內(nèi)存太低依然會(huì)觸發(fā)LMK（Low Memory Killer）機(jī)制，即閃退、崩潰現(xiàn)象。

以下分享本人總結(jié)Java內(nèi)存分配及Android常見(jiàn)內(nèi)存泄漏分析相關(guān)文章：

Java 垃圾回收器的GC機(jī)制，看這一篇就夠了

Android 內(nèi)存泄漏常見(jiàn)案例及分析

了解內(nèi)存如何分配和回收機(jī)制的同學(xué)，對(duì)內(nèi)存優(yōu)化會(huì)有一定的認(rèn)識(shí)和掌握。可以借助內(nèi)存分析工具，方便定位內(nèi)存優(yōu)化的代碼。

舉個(gè)例子，代碼如下所示：

[java]view plaincopy

public?class?CommUtil?{??

private?static?CommUtil?instance;??

private?Context?context;??

private?CommUtil(Context?context)?{??

this.context=context;??

????}??

public?static?CommUtil?getInstance(Context?context){??

if(null==instance){??

instance=new?CommUtil(context);??

????????}??

return?instance;??

????}??

}??

public?class?MainActivity?extends?AppCompatActivity?{??

@Override??

protected?void?onCreate(Bundle?savedInstanceState)?{??

super.onCreate(savedInstanceState);??

????????setContentView(R.layout.activity_main);??

CommUtil?instance?=?CommUtil.getInstance(this);//??

????}??

}??

一個(gè)工具類?CommUtil.class 使用創(chuàng)建型設(shè)計(jì)模式——單例模式，在MainActivity.class中引用，那么這個(gè)單例對(duì)象會(huì)持有Activity的實(shí)例。然后運(yùn)行起來(lái) ，再將手機(jī)屏幕旋轉(zhuǎn)幾下。這樣的代碼會(huì)造成什么錯(cuò)誤？

（旋轉(zhuǎn)屏幕的時(shí)候 Activity會(huì)被銷毀重新創(chuàng)建，但是這里的單例會(huì)持有銷毀Activity的實(shí)例就造成內(nèi)存泄漏）

使用分析工具如下：

Memory Monitor 工具：

它是Android Studio自帶的一個(gè)內(nèi)存監(jiān)視工具，它可以很好地幫助我們進(jìn)行內(nèi)存實(shí)時(shí)分析。通過(guò)點(diǎn)擊Android Studio右下角的Memory Monitor標(biāo)簽，打開(kāi)工具可以看見(jiàn)較淺藍(lán)色代表free的內(nèi)存，而深色的部分代表使用的內(nèi)存從內(nèi)存變換的走勢(shì)圖變換，可以判斷關(guān)于內(nèi)存的使用狀態(tài)，例如當(dāng)內(nèi)存持續(xù)增高時(shí)，可能發(fā)生內(nèi)存泄漏；當(dāng)內(nèi)存突然減少時(shí)，可能發(fā)生GC等，如下圖所示。

*案例參考

Memory Analyzer 工具：

MAT(Memory Analyzer Tool) 是一個(gè)快速，功能豐富的 Java Heap 分析工具，通過(guò)分析 Java 進(jìn)程的內(nèi)存快照 HPROF 分析，從眾多的對(duì)象中分析，快速計(jì)算出在內(nèi)存中對(duì)象占用的大小，查看哪些對(duì)象不能被垃圾收集器回收，并可以通過(guò)視圖直觀地查看可能造成這種結(jié)果的對(duì)象。檢測(cè)步驟如下：

（1）（屏幕多次翻轉(zhuǎn)，出現(xiàn)內(nèi)存持續(xù)增高時(shí)）點(diǎn)擊?Dump java Heap就會(huì)生成運(yùn)行內(nèi)存快照hprof文件。

（2）然后將APP完全退出，重新啟動(dòng)，打開(kāi)Android Monitor 再次點(diǎn)擊Dump java Heap 生成一份還沒(méi)操作(旋轉(zhuǎn)屏幕)前的內(nèi)存快照hprof文件。現(xiàn)在就已經(jīng)生成好了2份hprof文件， 一份是沒(méi)有旋轉(zhuǎn)過(guò)屏幕的 ，一份是旋轉(zhuǎn)過(guò)屏幕多次的。

（3）然后選中Android Studio 最左邊的Captures 進(jìn)行將hprof文件導(dǎo)出。導(dǎo)出的時(shí)候需要選擇保存的目錄以及文件名。

（4）打開(kāi)MAT ，導(dǎo)入我們的2個(gè)hprof文件 Open File-->選擇文件-->Leak Suspects Report-->Finish：*案例參考

LeakCanary工具：

簡(jiǎn)單，傻瓜式操作?？梢栽贕itHup官網(wǎng)查閱https://github.com/square/leakcanary，我們可以在Gradle文件里添加依賴。這個(gè)工具是Square公司在Github開(kāi)源的。行業(yè)內(nèi)不是有一句話嘛，Square出品必屬精品，主流的庫(kù)像okhttp、Picasso、retrofit、Dagger等都出自Square之手。說(shuō)到這不得不讓我聯(lián)想到一位在Android開(kāi)發(fā)領(lǐng)域神一般存在的人物，他就是大名鼎鼎的Jake Wharton（杰克.沃頓），ButterKnife的創(chuàng)造者，也參與貢獻(xiàn)了Retrofit, okhttp等。

Android Lint 工具：

Android Lint Tool?是Android Sutido種集成的一個(gè)Android代碼提示工具，它可以給你布局、代碼提供非常強(qiáng)大的幫助。

硬編碼會(huì)提示以級(jí)別警告，例如：在布局文件中寫(xiě)了三層冗余的LinearLayout布局、直接在TextView中寫(xiě)要顯示的文字、字體大小使用dp而不是sp為單位，就會(huì)在編輯器右邊看到提示。使用Android Studio的lint可以清除無(wú)用的資源文件：點(diǎn)擊菜單欄的Analyze -> Run Inspection by Name, 輸入unused resource。

當(dāng)然以上都是一個(gè)簡(jiǎn)單的舉例，Lint的功能非常強(qiáng)大，大家應(yīng)該養(yǎng)成寫(xiě)完代碼查看Lint的習(xí)慣，這不僅讓你及時(shí)發(fā)現(xiàn)代碼種隱藏的一些問(wèn)題，更能讓你養(yǎng)成良好的代碼風(fēng)格，要知道，這些Lint提示可都是Google大牛們汗水合智慧的結(jié)晶。

小結(jié)

????影響穩(wěn)定性的原因很多，比如內(nèi)存使用不合理、代碼異常場(chǎng)景考慮不周全、代碼邏輯不合理等，都會(huì)對(duì)應(yīng)用的穩(wěn)定性造成影響。其中最常見(jiàn)的兩個(gè)場(chǎng)景是：Crash 和 ANR，這兩個(gè)錯(cuò)誤將會(huì)使得程序無(wú)法使用。所以做好Crash監(jiān)控，把崩潰信息、異常信息收集記錄起來(lái)，以便后續(xù)分析;合理使用主線程處理業(yè)務(wù)，不要在主線程中做耗時(shí)操作，防止ANR程序無(wú)響應(yīng)發(fā)生。

二、流暢——交互優(yōu)化

交互是與用戶體驗(yàn)最直接的方面，交互場(chǎng)景大概分為四個(gè)部分：UI 繪制、應(yīng)用啟動(dòng)、頁(yè)面跳轉(zhuǎn)、事件響應(yīng)，如圖：

四個(gè)方面大致歸為如下兩類：

界面繪制：主要原因是繪制的層級(jí)深、頁(yè)面復(fù)雜、刷新不合理，由于這些原因?qū)е驴D的場(chǎng)景更多出現(xiàn)在 UI 和啟動(dòng)后的初始界面以及跳轉(zhuǎn)到頁(yè)面的繪制上。

數(shù)據(jù)處理：導(dǎo)致這種卡頓場(chǎng)景的原因是數(shù)據(jù)處理量太大，一般分為三種情況，一是數(shù)據(jù)在處理 UI 線程，二是數(shù)據(jù)處理占用 CPU 高，導(dǎo)致主線程拿不到時(shí)間片，三是內(nèi)存增加導(dǎo)致 GC 頻繁，從而引起卡頓。

分析:

我們知道Android的繪制步驟是：：Measure、Layout、Draw，所以布局的層級(jí)越深、元素越多、耗時(shí)也就越長(zhǎng)。還有就是Android 系統(tǒng)每隔 16ms 發(fā)出 VSYNC 信號(hào)，觸發(fā)對(duì) UI 進(jìn)行渲染，如果每次渲染都成功，這樣就能夠達(dá)到流暢的畫(huà)面所需的 60FPS。如果某個(gè)操作花費(fèi)的時(shí)間是 24ms ，系統(tǒng)在得到 VSYNC 信號(hào)時(shí)就無(wú)法正常進(jìn)行正常渲染，這樣就發(fā)生了丟幀現(xiàn)象。那么用戶在 32ms 內(nèi)看到的會(huì)是同一幀畫(huà)面，無(wú)法在 16ms 完成渲染，最終引起刷新不及時(shí)。

兩個(gè)根本原因：

繪制任務(wù)太重，繪制一幀內(nèi)容耗時(shí)太長(zhǎng)。

主線程太忙，根據(jù)系統(tǒng)傳遞過(guò)來(lái)的 VSYNC 信號(hào)來(lái)時(shí)還沒(méi)準(zhǔn)備好數(shù)據(jù)導(dǎo)致丟幀。

建議1：布局優(yōu)化

在Android種系統(tǒng)對(duì)View進(jìn)行測(cè)量、布局和繪制時(shí)，都是通過(guò)對(duì)View數(shù)的遍歷來(lái)進(jìn)行操作的。如果一個(gè)View數(shù)的高度太高就會(huì)嚴(yán)重影響測(cè)量、布局和繪制的速度。Google也在其API文檔中建議View高度不宜哦過(guò)10層。現(xiàn)在版本種Google使用RelativeLayout替代LineraLayout作為默認(rèn)根布局，目的就是降低LineraLayout嵌套產(chǎn)生布局樹(shù)的高度，從而提高UI渲染的效率。

布局復(fù)用，使用<include>標(biāo)簽重用layout；

提高顯示速度，使用<ViewStub>延遲View加載；

減少層級(jí)，使用<merge>標(biāo)簽替換父級(jí)布局；

注意使用wrap_content，會(huì)增加measure計(jì)算成本；

刪除控件中無(wú)用屬性；

建議2：繪制優(yōu)化

過(guò)度繪制是指在屏幕上的某個(gè)像素在同一幀的時(shí)間內(nèi)被繪制了多次。在多層次重疊的 UI 結(jié)構(gòu)中，如果不可見(jiàn)的 UI 也在做繪制的操作，就會(huì)導(dǎo)致某些像素區(qū)域被繪制了多次，從而浪費(fèi)了多余的 CPU 以及 GPU 資源。所以避免過(guò)度繪制：

布局上的優(yōu)化。移除 XML 中非必須的背景，移除 Window 默認(rèn)的背景、按需顯示占位背景圖片

自定義View優(yōu)化。使用 canvas.clipRect()來(lái)幫助系統(tǒng)識(shí)別那些可見(jiàn)的區(qū)域，只有在這個(gè)區(qū)域內(nèi)才會(huì)被繪制。

建議3：?jiǎn)?dòng)優(yōu)化

UI 布局。應(yīng)用一般都有閃屏頁(yè)，優(yōu)化閃屏頁(yè)的 UI 布局，可以通過(guò) Profile GPU Rendering 檢測(cè)丟幀情況。

啟動(dòng)加載邏輯優(yōu)化?？梢圆捎梅植技虞d、異步加載、延期加載策略來(lái)提高應(yīng)用啟動(dòng)速度。

數(shù)據(jù)準(zhǔn)備。數(shù)據(jù)初始化分析，加載數(shù)據(jù)可以考慮用線程初始化等策略。

建議4：刷新優(yōu)化

減少刷新次數(shù)；

縮小刷新區(qū)域；

建議5：動(dòng)畫(huà)優(yōu)化

在實(shí)現(xiàn)動(dòng)畫(huà)效果時(shí)，需要根據(jù)不同場(chǎng)景選擇合適的動(dòng)畫(huà)框架來(lái)實(shí)現(xiàn)。有些情況下，可以用硬件加速方式來(lái)提供流暢度。

三、節(jié)省——耗電優(yōu)化

????在移動(dòng)設(shè)備中，電池的重要性不言而喻，沒(méi)有電什么都干不成。對(duì)于操作系統(tǒng)和設(shè)備開(kāi)發(fā)商來(lái)說(shuō)，耗電優(yōu)化一致沒(méi)有停止，去追求更長(zhǎng)的待機(jī)時(shí)間，而對(duì)于一款應(yīng)用來(lái)說(shuō)，并不是可以忽略電量使用問(wèn)題，特別是那些被歸為“電池殺手”的應(yīng)用，最終的結(jié)果是被卸載。因此，應(yīng)用開(kāi)發(fā)者在實(shí)現(xiàn)需求的同時(shí)，需要盡量減少電量的消耗。

????在 Android5.0 以前，在應(yīng)用中測(cè)試電量消耗比較麻煩，也不準(zhǔn)確，5.0 之后專門(mén)引入了一個(gè)獲取設(shè)備上電量消耗信息的 API:Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系統(tǒng)電量分析工具，和Systrace 一樣，是一款圖形化數(shù)據(jù)分析工具，直觀地展示出手機(jī)的電量消耗過(guò)程，通過(guò)輸入電量分析文件，顯示消耗情況，最后提供一些可供參考電量?jī)?yōu)化的方法。

除此之外，還有一些常用方案可提供：

計(jì)算優(yōu)化，避開(kāi)浮點(diǎn)運(yùn)算等。

避免 WaleLock 使用不當(dāng)。

使用 Job Scheduler。

四、APK瘦身

????應(yīng)用安裝包大小對(duì)應(yīng)用使用沒(méi)有影響，但應(yīng)用的安裝包越大，用戶下載的門(mén)檻越高，特別是在移動(dòng)網(wǎng)絡(luò)情況下，用戶在下載應(yīng)用時(shí)，對(duì)安裝包大小的要求更高，因此，減小安裝包大小可以讓更多用戶愿意下載和體驗(yàn)產(chǎn)品。

常用應(yīng)用安裝包的構(gòu)成，如圖所示：

從圖中我們可以看到：

assets文件夾。存放一些配置文件、資源文件，assets不會(huì)自動(dòng)生成對(duì)應(yīng)的 ID，而是通過(guò) AssetManager 類的接口獲取。

res。res 是 resource 的縮寫(xiě)，這個(gè)目錄存放資源文件，會(huì)自動(dòng)生成對(duì)應(yīng)的 ID 并映射到 .R 文件中，訪問(wèn)直接使用資源 ID。

META-INF。保存應(yīng)用的簽名信息，簽名信息可以驗(yàn)證 APK 文件的完整性。

AndroidManifest.xml。這個(gè)文件用來(lái)描述 Android 應(yīng)用的配置信息，一些組件的注冊(cè)信息、可使用權(quán)限等。

classes.dex。Dalvik 字節(jié)碼程序，讓 Dalvik 虛擬機(jī)可執(zhí)行，一般情況下，Android 應(yīng)用在打包時(shí)通過(guò) Android SDK 中的 dx 工具將 Java 字節(jié)碼轉(zhuǎn)換為 Dalvik 字節(jié)碼。

resources.arsc。記錄著資源文件和資源 ID 之間的映射關(guān)系，用來(lái)根據(jù)資源 ID 尋找資源。

APK瘦身減少安裝包大小的常用方案：

代碼混淆。使用proGuard 代碼混淆器工具，它包括壓縮、優(yōu)化、混淆等功能。

資源優(yōu)化。比如使用?Android Lint?刪除冗余資源，資源文件最少化等。

圖片優(yōu)化。比如利用PNG優(yōu)化工具對(duì)圖片做壓縮處理。推薦：zopfliPNG

避免重復(fù)功能的庫(kù)，如果應(yīng)用在4.0版本以上，使用WebP圖片格式等。

插件化。比如功能模塊放在服務(wù)器上，按需下載，可以減少安裝包大小。

可以使用微信開(kāi)源資源文件混淆工具——AndResGuard。一般可以壓縮apk的1M左右大。

五、小結(jié)

????最后說(shuō)一句，性能優(yōu)化是一個(gè)非常具有挑戰(zhàn)性的工作，上面列出很多分析內(nèi)存、優(yōu)化內(nèi)存的方法，但是真正優(yōu)化工作遠(yuǎn)不止這么簡(jiǎn)單，這里只是列舉了一些入門(mén)的方法，而要進(jìn)行完美的內(nèi)存優(yōu)化、內(nèi)存分析絕非一日之功，需要開(kāi)發(fā)者深厚的技術(shù)功底合耐心