Android系統(tǒng)每隔16ms發(fā)出VSYNC信號（vertical synchronization --場掃描同步睬魂，場同步，垂直同步）镀赌，觸發(fā)對UI進(jìn)行渲染氯哮，如果每次渲染都成功，這樣就能夠達(dá)到流暢的畫面所需要的60fps佩脊，為了能夠?qū)崿F(xiàn)60fps蛙粘，這意味著程序的大多數(shù)操作都必須在16ms（1000/60=16.67ms）內(nèi)完成。

如果你的某個操作花費(fèi)時間是24ms威彰，系統(tǒng)在得到VSYNC信號的時候就無法進(jìn)行正常渲染浦译，這樣就發(fā)生了丟幀現(xiàn)象。那么用戶在32ms內(nèi)看到的會是同一幀畫面刀疙。

1魏滚、過度繪制

Overdraw（過度繪制）描述的是屏幕上的某個像素在同一幀的時間內(nèi)被繪制了多次。在多層次的UI結(jié)構(gòu)里面豹缀，如果不可見的UI也在做繪制的操作伯复，這就會導(dǎo)致某些像素區(qū)域被繪制了多次。這就浪費(fèi)大量的CPU以及GPU資源邢笙，找出界面滑動不流暢啸如、界面啟動速度慢、手機(jī)發(fā)熱氮惯。

• 如何查看過度繪制叮雳？

  設(shè)置 — 開發(fā)中選項(xiàng) — 調(diào)試GPU過度繪制

• 來看看手雷里的過度繪制和優(yōu)化效果（目前手雷還存在很多待優(yōu)化的頁面）

  
  

• 上圖中的各種顏色都代表什么意思？

  
  

    每個顏色的說明如下：
  
    原色：沒有過度繪制
    紫色：1 次過度繪制
    綠色：2 次過度繪制
    粉色：3 次過度繪制
    紅色：4 次及以上過度繪制
  

• 造成過度優(yōu)化的關(guān)鍵是什么妇汗？多余的背景（Background）

• 接下來舉例說明：

  • 1帘不、MainTabActivity

    在MainTabActivity的Theme中修改背景

    
    

    去除布局（main_activity_linerlayout.xml）中的background

    
    

    如果不給當(dāng)前Activity設(shè)置主題，默認(rèn)主題是什么杨箭，默認(rèn)主題背景是什么寞焙？

    
    
    
    
    
    
    
    
    
    
    
    
    

      可以在默認(rèn)主題中添加通用主題背景
      <item name="android:windowBackground">@drawable/common_layout_content_bkg</item>
      去除背景
      <item name="android:windowBackground">null</item>
    

  • 2、除了布局中多余背景，還有可能在代碼里添加了多余的背景捣郊。

    
    

    查看分享彈窗的布局代碼發(fā)現(xiàn)只有一個background辽狈，但為什么會過度繪制呢？

    
    
    
    

    代碼修改（SharePlatformsDialog.java）

    
    

  • 3模她、彈窗底部布局不會導(dǎo)致彈窗本身過度繪制

    
    

    彈窗的繪制是屬于剪切式繪制不是覆蓋繪制稻艰，蒙層是透明度亮度的調(diào)節(jié)不是繪制一層灰色。
    如果我們不想用系統(tǒng)dialog而是自定義一個彈窗view侈净，就需要考慮過度繪制問題尊勿。

  • 4、自定義view時畜侦，通過Canvas的clipRect方法控制每個視圖每次刷新的區(qū)域元扔，這樣可以避免刷新不必要的區(qū)域，從而規(guī)避過渡繪制的問題旋膳。還可以使用canvas.quickreject()來判斷是否和某個矩形相交澎语，從而跳過那些非矩形區(qū)域內(nèi)的繪制操作。參考：http://jaeger.itscoder.com/android/2016/09/29/android-performance-overdraw.html

• 優(yōu)化方法和步驟關(guān)鍵總結(jié)

    總結(jié)一下验懊，優(yōu)化步驟如下：
  
    1擅羞、移除或修改Window默認(rèn)的Background
    2、移除XML布局文件中非必需的Background
    3义图、按需顯示占位背景圖片
    4减俏、控制繪制區(qū)域
  

2、布局優(yōu)化

布局太過復(fù)雜碱工，層級嵌套太深導(dǎo)致繪制操作耗時娃承，且增加內(nèi)存的消耗。
我們的目標(biāo)就是怕篷，層級扁平化历筝。

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

  • 第一個建議：可以使用相對布局減少層級的就使用相對布局，否則使用線性布局廊谓。Android中RelativeLayout和LinearLayout性能分析梳猪，參考：http://www.reibang.com/p/8a7d059da746#

  • 第二個建議：用merge標(biāo)簽來合并布局，這可以減少布局層次蒸痹。

  • 第三個建議：用include標(biāo)簽來重用布局春弥，抽取通用的布局可以讓布局的邏輯更清晰明了，但要避免include亂用电抚。

  • 第四個建議：避免創(chuàng)建不必要的布局層級。（最容易發(fā)生的竖共！）

  • 第五個建議：使用惰性控件ViewStub實(shí)現(xiàn)布局動態(tài)加載

• 如何借助工具查看代碼布局蝙叛？

  Android SDK 工具箱中有一個叫做 Hierarchy Viewer 的工具，能夠在程序運(yùn)行時分析 Layout公给。
  可以用這個工具找到 Layout 的性能瓶頸
  該工具的使用條件：模擬器或者Root版真機(jī)借帘。
  如何開啟該功能：AndroidStudio中蜘渣，Tools — Android — Android Devices Monitor
  該工具的缺點(diǎn)：使用起來麻煩。

  
  

• 看看項(xiàng)目中遇到的問題（MainTabAvtivity）肺然。

  • merge標(biāo)簽的使用

    
    

    未使用merge蔫缸，例如：XLTabLayout.java

    
    
    
    
    

    使用merge，例如：賬號信息頁的條目UserAccountItem

    
    

  • include標(biāo)簽的使用導(dǎo)致的問題

    
    
    
    

  • 避免創(chuàng)建不必要的層級（MainTabActivity）

    
    

  • ViewStub的使用

    這個標(biāo)簽最大的優(yōu)點(diǎn)是當(dāng)你需要時才會加載际起，使用他并不會影響UI初始化時的性能拾碌。
    通常情況下我們需要在某個條件下使用某個布局的時候會通過gone或者invisible來隱藏，其實(shí)這樣的方式雖然隱藏了布局街望，但是當(dāng)顯示該界面的時候還是將該布局實(shí)例化的校翔。使用ViewStub可以避免內(nèi)存的浪費(fèi)，加快渲染速度灾前。
    其實(shí)ViewStub就是一個寬高都為0的一個View防症，它默認(rèn)是不可見的，只有通過調(diào)用setVisibility函數(shù)或者Inflate函數(shù)才會將其要裝載的目標(biāo)布局給加載出來哎甲，從而達(dá)到延遲加載的效果蔫敲，這個要被加載的布局通過android:layout屬性來設(shè)置。

    
    

    當(dāng)準(zhǔn)備inflate ViewStub時炭玫，調(diào)用inflate()方法即可奈嘿。還可以設(shè)定ViewStub的Visibility為VISIBLE或INVISIBLE，也會觸發(fā)inflate础嫡。注意的是指么，使用inflate()方法能返回布局文件的根View。

      ((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);
      // or
      View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();
    

    setVisibility的時候會觸發(fā)了inflate

    
    

    注意：使用ViewStub加載的布局中不能使用merge標(biāo)簽榴鼎。

• 看看Space標(biāo)簽（不常用）

  space標(biāo)簽可以只在布局文件中占位伯诬，不繪制，Space標(biāo)簽有對應(yīng)的java類Space.java巫财，通過閱讀源碼可以發(fā)現(xiàn)盗似，它繼承至View.java，并且復(fù)寫了draw方法平项，該方法為空赫舒，既沒有調(diào)用父類的draw方法，也沒有執(zhí)行自己的代碼闽瓢，表示該類是沒有繪制操作的接癌，但onMeasure方法正常調(diào)用，說明是有寬高的扣讼。
  主要功能用來設(shè)置間距缺猛，這個標(biāo)簽不常用，常使用margin或padding。

3荔燎、介紹一下查看渲染性能的工具

• GPU呈現(xiàn)模式分析（大致定位問題）

  開發(fā)者選項(xiàng) — GPU呈現(xiàn)模式分析 — 選擇“在屏幕上顯示為條形圖”

  
  

  Android開發(fā)者選項(xiàng)——Gpu呈現(xiàn)模式分析耻姥，參考：http://www.voidcn.com/blog/gjy211/article/p-6210447.html
  自動播放的視頻停止的時候會有兩條很長的柱線，下個視頻播放的時候還會有一條有咨。這里有一個明顯的卡頓琐簇。
  播放器操作（DefaultPlayerView.java - doPlay，player_auto_control_layout.xml）：

  
  

    上圖的E total time = 68 是播放器停止播放的時候耗費(fèi)的時間座享。
  
    total time = 29 是播放器開始播放的時候耗費(fèi)的時間婉商。
    其中，大部分時間耗費(fèi)在了 5total time = 18 上面征讲，這個是inflate播放器界面的時候耗費(fèi)的時間据某。
  

  
  

  是不是所有的inflate都很耗費(fèi)時間，看一下賬號信息頁：

  
  
  
  

• GPU Monitor

• 啟用嚴(yán)格模式（不止渲染性能）

  應(yīng)用在主線程上執(zhí)行長時間操作時會閃爍屏幕诗箍。
  通過代碼進(jìn)行嚴(yán)格模式（StrictMode）調(diào)試癣籽，參考：http://www.tuicool.com/articles/ueeM7b6

二、內(nèi)存問題

1滤祖、內(nèi)存浪費(fèi)

程序內(nèi)存的管理是否合理高效對應(yīng)用的性能有著很大的影響筷狼。
推薦閱讀Android性能優(yōu)化典范-第3季，參考：http://hukai.me/android-performance-patterns-season-3/

• ArrayMap（我們項(xiàng)目中沒有用到匠童，Android源碼中很多使用）

  Android為移動操作系統(tǒng)特意編寫了一些更加高效的容器埂材，例如ArrayMap、SparseArray汤求。
  為了解決HashMap更占內(nèi)存的弊端俏险，Android提供了內(nèi)存效率更高的ArrayMap。

  • 先來看看HashMap的原理

    HashMap的整體結(jié)構(gòu)如下：

    
    

    存儲位置的確定流程：

    !()[http://img.hb.aicdn.com/16b2993c41a413b24470e1b9b74227674cd16fdb9a09-UTrZIe]
    

    
    

  • 再看來看看ArrayMap是如何優(yōu)化內(nèi)存的

    它內(nèi)部使用兩個數(shù)組進(jìn)行工作扬绪，其中一個數(shù)組記錄key hash過后的順序列表竖独，另外一個數(shù)組按key的順序記錄Key-Value值，如下圖所示：

    
    

    當(dāng)你想獲取某個value的時候挤牛，ArrayMap會計(jì)算輸入key轉(zhuǎn)換過后的hash值莹痢，然后對hash數(shù)組使用二分查找法尋找到對應(yīng)的index，然后我們可以通過這個index在另外一個數(shù)組中直接訪問到需要的鍵值對墓赴。

    
    

    既然ArrayMap中的內(nèi)存占用是連續(xù)不間斷的竞膳，那么它是如何處理插入與刪除操作的呢？它跟HashMap有什么區(qū)別诫硕？二者之間的刪除插入效率有什么差異坦辟？請看下圖所示，演示了Array的特性：

    
    
    
    

    HashMap與ArrayMap之間的內(nèi)存占用效率對比圖如下：

    
    

    與HashMap相比章办，ArrayMap在循環(huán)遍歷的時候更加高效锉走。

    
    

    什么時候使用ArrayMap呢滔吠？

      1、對象個數(shù)的數(shù)量級最好是千以內(nèi)挠日，沒有頻繁的插入刪除操作
      2、數(shù)據(jù)組織形式包含Map結(jié)構(gòu)
    

• Autoboxing（避免自動裝箱）

  Autoboxing的行為還經(jīng)常發(fā)生在類似HashMap這樣的容器里面翰舌，對HashMap的增刪改查操作都會發(fā)生了大量的autoboxing的行為嚣潜。當(dāng)key是int類型的時候，HashMap和ArrayMap都有Autoboxing行為椅贱。

• SparseArray（項(xiàng)目中用到較多 -- 后面再說如何利用工具查找該用SparseArray而沒有用到的地方）

  為了避免Autoboxing行為Android提供了SparseArray懂算，此容器使用于key為int類型。
  SparseBooleanMap庇麦，SparseIntMap计技，SparseLongMap等容器，是key為int山橄，value類型相應(yīng)為boolean垮媒、int、long等航棱。

• Enum（枚舉睡雇，項(xiàng)目中較多使用，應(yīng)盡量避免）

  Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.
  Android官方強(qiáng)烈建議不要在Android程序里面使用到enum饮醇。
  關(guān)于enum的效率它抱，請看下面的討論。假設(shè)我們有這樣一份代碼朴艰，編譯之后的dex大小是2556 bytes观蓄，在此基礎(chǔ)之上，添加一些如下代碼祠墅，這些代碼使用普通static常量相關(guān)作為判斷值：

  
  

  增加上面那段代碼之后侮穿，編譯成dex的大小是2680 bytes，相比起之前的2556 bytes只增加124 bytes饵隙。假如換做使用enum撮珠，情況如下：

  
  

  使用enum之后的dex大小是4188 bytes，相比起2556增加了1632 bytes金矛，增長量是使用static int的13倍芯急。不僅僅如此，使用enum驶俊，運(yùn)行時還會產(chǎn)生額外的內(nèi)存占用娶耍，如下圖所示：

  
  

• 推薦一些文章：

  • HashMap，ArrayMap饼酿，SparseArray源碼分析及性能對比榕酒，參考：http://www.reibang.com/p/7b9a1b386265#

  • Android性能優(yōu)化--小心自動裝箱：http://blog.csdn.net/lgz_ei/article/details/69208784

  • Android性能優(yōu)化篇：Android中如何避免創(chuàng)建不必要的對象：http://blog.csdn.net/jia635/article/details/52525243

  • HashMap胚膊、ArrayMap、SparseArray分析比較：http://blog.csdn.net/chen_lifeng/article/details/52057427

  • Android性能優(yōu)化之String篇：http://www.androidchina.net/5940.html

  • SharedPreferences的commit和apply分析：http://blog.csdn.net/u010198148/article/details/51706483

2想鹰、內(nèi)存泄漏

• 什么是內(nèi)存泄漏紊婉？

  一些不用的對象被長期持有，導(dǎo)致內(nèi)存無法被釋放辑舷。

• 可能發(fā)生內(nèi)存泄漏的地方有哪些喻犁？

  • 內(nèi)部類引用導(dǎo)致Activity的泄漏

    在Java中，非靜態(tài)(匿名)內(nèi)部類會默認(rèn)隱性引用外部類對象何缓。而靜態(tài)內(nèi)部類不會引用外部類對象肢础。
    最典型的場景是Handler導(dǎo)致的Activity泄漏，如果Handler中有延遲的任務(wù)或者是等待執(zhí)行的任務(wù)隊(duì)列過長碌廓，都有可能因?yàn)镠andler繼續(xù)執(zhí)行而導(dǎo)致Activity發(fā)生泄漏传轰。
    為了解決這個問題，可以在UI退出之前谷婆，執(zhí)行remove Handler消息隊(duì)列中的消息與runnable對象慨蛙。或者是使用Static + WeakReference的方式來達(dá)到斷開Handler與Activity之間存在引用關(guān)系的目的纪挎。
    舉例股淡，MainTabActivity - MainTabHandler：

    
    
    
    
    
    
    
    

    如何修復(fù)？

    
    
    
    
    
    

    Android Weak Handler：可以避免內(nèi)存泄漏的Handler庫廷区，參考：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2014/1123/2047.html

  • Activity Context被傳遞到其他實(shí)例中唯灵，這可能導(dǎo)致自身被引用而發(fā)生泄漏。

    考慮使用Application Context而不是Activity Context隙轻。
    例如：全局Dialog或者Context被單例持有埠帕。

  • 靜態(tài)造成的內(nèi)存泄漏

    
    
    
    

    還有靜態(tài)變量持有View，例如：

      private static View view;
    
      void setStaticView() {
          view = findViewById(R.id.sv_button);
      }
    

  • 注意監(jiān)聽器的注銷（稍后利用工具分析一個例子）

    regist就要unregist

  • 注意Cursor對象是否及時關(guān)閉（項(xiàng)目中也存在玖绿，不再列舉）

  • WebView的引起的泄漏（暫時沒有研究）

• 使用工具分析定位解決內(nèi)存泄漏

  • Memory monitor

    通過MemoryMonitor可以看到敛瓷，啟動手雷進(jìn)入手雷的內(nèi)存情況如下（為什么沒有做任何操作內(nèi)存一直在增加？）：

    
    
    
    

    通過實(shí)例分析一處內(nèi)存泄漏斑匪，操作步驟如下：
    啟動手雷 - 進(jìn)入首頁 - 切換底部tab到我的tab - 點(diǎn)擊登錄彈窗彈窗 - 登錄成功返回首頁

    
    
    
    

  • MAT（Memory Analyzer Tool）

    需要下載MAT獨(dú)立版呐籽，可到這里下載解壓使用：\\192.168.8.188\上傳2\ltsoft
    分析剛才的操作內(nèi)存情況

    
    
    
    
    
    

    進(jìn)入首頁并沒有進(jìn)行任何活動操作，為什么會有那么多bitmap對象呢?

    
    

  • LeakCanary

    
    

    LeakCanary 中文使用說明蚀瘸，參考：https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/
    LeakCanary:讓內(nèi)存泄露無所遁形狡蝶，參考：https://www.liaohuqiu.net/cn/posts/leak-canary/

  • TraceView（不做詳細(xì)分析）

  • GT（應(yīng)該更適合測試同學(xué)測試APP性能）

    利用GT，僅憑一部手機(jī)贮勃，無需連接電腦贪惹，您即可對APP進(jìn)行快速的性能測試(CPU、內(nèi)存寂嘉、流量奏瞬、電量枫绅、幀率/流暢度等等)、開發(fā)日志的查看硼端、Crash日志查看并淋、網(wǎng)絡(luò)數(shù)據(jù)包的抓取、APP內(nèi)部參數(shù)的調(diào)試珍昨、真機(jī)代碼耗時統(tǒng)計(jì)等预伺。
    GT官網(wǎng)：http://gt.qq.com/index.html

• 內(nèi)存使用策略優(yōu)化

  • 看看下載一個視頻加上瀏覽一下精選頁，然后將應(yīng)用切到后臺曼尊，內(nèi)存使用情況

    
    
    
    
    
    

  • 有什么優(yōu)化內(nèi)存的策略

    • onLowMemory()：Android系統(tǒng)提供了一些回調(diào)來通知當(dāng)前應(yīng)用的內(nèi)存使用情況，通常來說脏嚷，當(dāng)所有的background應(yīng)用都被kill掉的時候骆撇，forground應(yīng)用會收到onLowMemory()的回調(diào)。在這種情況下父叙，需要盡快釋放當(dāng)前應(yīng)用的非必須的內(nèi)存資源神郊，從而確保系統(tǒng)能夠繼續(xù)穩(wěn)定運(yùn)行。

    • onTrimMemory(int)：Android系統(tǒng)從4.0開始還提供了onTrimMemory()的回調(diào)趾唱，當(dāng)系統(tǒng)內(nèi)存達(dá)到某些條件的時候涌乳，所有正在運(yùn)行的應(yīng)用都會收到這個回調(diào)，同時在這個回調(diào)里面會傳遞參數(shù)甜癞，代表不同的內(nèi)存使用情況夕晓，收到onTrimMemory()回調(diào)的時候，需要根據(jù)傳遞的參數(shù)類型進(jìn)行判斷悠咱，合理的選擇釋放自身的一些內(nèi)存占用蒸辆，一方面可以提高系統(tǒng)的整體運(yùn)行流暢度，另外也可以避免自己被系統(tǒng)判斷為優(yōu)先需要?dú)⒌舻膽?yīng)用析既。

• 文章推薦：

  • Android內(nèi)存優(yōu)化之OOM：http://hukai.me/android-performance-oom/

  • 內(nèi)存泄露從入門到精通三部曲之基礎(chǔ)知識篇：http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=21&extra=page%3D4

  • 內(nèi)存泄露從入門到精通三部曲之排查方法篇：http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=62&extra=page%3D5

  • 內(nèi)存泄露從入門到精通三部曲之常見原因與用戶實(shí)踐：http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=125&highlight=%E5%86%85%E5%AD%98%E6%B3%84%E9%9C%B2

  • 胡凱Android性能典范系列

3躬贡、性能優(yōu)化必備神器推薦（Lint）

• 上面分析的一些項(xiàng)目中的問題，怎么找到的呢眼坏？

  Lint：靜態(tài)代碼分析工具

• 如何通過Lint查找項(xiàng)目中的問題拂玻，如何使用？

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• 如果只想分析某個文件夾的代碼

  
  
  
  

• 設(shè)置代碼分析選項(xiàng)

  
  

三宰译、耗電問題

例如：關(guān)閉屏幕時關(guān)閉掉登錄ping檐蚜，屏幕亮?xí)r再打開。
以上的很多問題都會導(dǎo)致耗電量增加沿侈。
如何優(yōu)化后臺下載時的耗電手機(jī)發(fā)燙問題熬甚？
需要具體的硬件工具測試應(yīng)用耗電量，需要一套耗電量測試標(biāo)準(zhǔn)肋坚。