手機淘寶性能優化全記錄

手機淘寶做爲一個航母級的應用，承載了100多個業務方，部分是H5的形式接入，還有超過50個Native的業務方。爲了規避安卓DEX65535的方法數限制以及各業務獨立開發等須要，淘寶工程師門也是採用了多DEX(多Bundle)的開發形式，並且手淘做爲一個以圖片顯示爲重點的APP，在性能上不可避免的遇到了比較多的問題。

手機淘寶遇到了那些性能問題?淘寶技術專家使用那些優化分析工具找出各類性能瓶頸的?在應用界面到中間件的優化過程當中，淘寶又有那些經驗與咱們分享?你不在現場?不要緊，王曜東演講的技術要點就在這裏。

手機淘寶遭遇的5大性能問題

一、APP啓動慢

二、界面跳轉慢

三、事件相應慢

四、滑動和動畫卡頓

五、展示內容慢

手機淘寶的目前使用的主要優化工具

開發者選項中和Android提供了多個分析工具。

• GPU Profile：查看每一幀的繪製狀況。除了查看幀率，我還會用這個工具檢查各個界面在靜默狀態下的沒必要要的刷新問題。

• Show GPU Overdraw：查看過渡繪製用的工具，由於手淘的不少界面效果也比較複雜，很容易出現過渡繪製。

• Dump View Hierarchy：用於查看界面的佈局、View和層級嵌套狀況。特別是在沒有源代碼的狀況下，查看很是方便。

• TraceView：強大的性能跟蹤工具，也是咱們在優化中用的最多的工具。

• SysTrace：主要用於查看UI的繪製問題，跟蹤CPU執行狀況等。

• Trace OpenGL：能夠錄製每一幀的繪製過程，逐個繪製命令查看。

• AlloCation Tracker：內存分配跟蹤，也是個調試性能的強大工具。

• Threads 工具能夠顯示全部線程信息及查看線程正在執行的代碼。

• Heap和Memory Monitor：查看內存的分配和變化狀況。Memory Monitor還能夠查看內存的抖動和GC狀況。

　　

TraceView做爲最主要的工具，王曜東特別強調了手淘在優化過程當中的一些經驗。好比找出高頻率調用函數有時候會比較特殊，要結合實際代碼，好比寫SharedPreferences的apply函數須要注意，由於Commit函數會阻塞IO，這個函數雖然執行很快，可是系統會有另一個線程來負責寫操做，當apply頻率高的時候，該線程就會比較佔用CPU資源。相似的還有統計埋點等，在主線程埋點但異步線程提交，頻率高的狀況也會出現這樣的問題。

其次查看佈局性能，一種是直接查看，如onMeasure，OnLayout函數佔用的百分比和平均執行時間太高致使的性能問題，很直觀就能夠看出來。還有就是例如getview中的佈局性能，總體的查看inflate的個數和耗時問題的跟蹤。還有一種是經過View的draw函數或者buildeDisplayList函數的調用和遞歸調用次數來判斷佈局的複雜度。

關於複用問題，好比在listview滑動過一遍後，在對這部分區域作跟蹤，若是getview中還有infalte佈局，那就是複用還有能夠優化的地方。

類的初始化耗時，像構造函數，靜態初始化等這些問題很容易忽視，可是在性能優化的後期，這些小的細節點，也是優化的方向，特別是在主線程中調用的時候。

手淘啓動過程優化詳解

啓動過程優化是全部大型APP都會遇到的問題，啓動慢，加載多。手淘也不例外，手淘的模塊很是多，各業務方都但願在啓動的時候都能把本身先初始化起來，加上手淘也是分了不少了dex文件的，這樣在首次啓動的時候不只要dexpot這些模塊的dex，還有主dex中的很多模塊有初始化動做。

▲手機淘寶啓動過程優化

▲啓動變慢案例分析

一、分析各個模塊的線程數量，檢查線程池的合理性。經過去掉沒必要要的線程和線程池，再控制線程池的併發數。減小啓動階段的線程以及控制線程的啓動時機。

二、經過MAT等工具，找出那些分配過多的對象和數量特別多的對象，咱們前面看到不少的容器，其實大部分都用不到，不須要在啓動時就建立。淘寶工程師也發現首頁緩存的佈局太多，浪費較多的資源，因此須要減小緩存的數量。經過Systrace，能夠發如今網絡線程，統計，主線程等GC不少，因此對頻繁建立的對象如網絡庫的Byte數組，Buffer等作複用。

三、當有較多的主線程耗時，須要將主線程中的耗時操做都異步處理或者移除。

四、IO：經過TraceView能夠發現SharedPreference有2個線程常常佔用不少的CPU時間，還有幾個下載文件的線程如update等以及數據庫操做這些都是IO操做。優化過程就是刪除沒必要要的io操做，有些作延後處理。例如統計數據，淘寶減小了採樣的頻率，而且增長緩存數量，以空間換時間，減小數據庫和SharedPreference的讀寫。在作較多數據庫操做的時候也會開啓事務功能來減小IO的次數。

五、之前在啓動階段會安裝主要模塊的bundle，首頁再啓動後過3秒也會發送通知來喚起更多的模塊，像淘寶的webview框架，在初始化的時候會把線上活動資源都緩存到本地，這個過程設計到json的解析，下載和解壓縮等，很是耗資源等等，這些模塊疊加在一塊兒就致使了首頁就會直接卡主及白屏很長一段時間，因此對這一種模塊改成懶加載，而且要限制拉取活動的數量。還有像購物車，微淘，店鋪，旺信等之前是首次啓動會安裝，也是改成懶加載。由於首次Dexopt會比較費時，特別是安卓5.0之後，因此不少模塊都改成懶加載，這樣首次使用該模塊的時候變慢一點，可是總體啓動速度一下就提高了。

六、降級搖一搖功能的檢測頻率，減小地理信息的數量

七、首頁在歡迎頁的時候開始初始化佈局等，加快展現。退出的時候之前都是銷燬Activity的，爲了加快下次啓動，釋放到圖片等主要資源，Activity不作銷燬。

手機淘寶各界面的優化

　　GPU過渡繪製的優化

　　不須要顯示的佈局及時隱藏

　　去掉層疊佈局中多餘的背景設置

　　圖片控件有前景內容的時候不顯示背景

　　界面背景定義到Activity的主題中

　　減小Drawable的複雜Shape使用

　　自定義控件onDraw函數減小繪製層次

　　自定義控件使用canvas.clipRect

　　優化佈局性能

　　優化層級

　　靈活使用佈局

　　減小View數量

　　異步infalte或者提早infalte

　　本身作控件的回收複用

　　加快界面顯示

　　主線程不作耗時操做

　　減小主線程GC停頓

　　利用本地緩存

　　減小數據傳輸和解析時間

　　注意線程優先級

　　利用局部刷新

總結：

　　一、發現性能問題的時候首先要分析緣由，是卡住仍是卡頓，是網絡慢的問題，仍是是內存問題亦或是其餘系統的問題。手淘遇到有時候手機廠商的一些特殊控件的bug也會致使問題。安卓系統自己的內存管理和一些監控軟件有時候也會致使性能問題。

　　二、經過多種工具額配合找出問題。

　　三、有些問題，一個地方存在極可能其餘地方也有，能夠到相似的模塊去查看，如圓形的圖案，輸入控件在輸入法退出時引起的自動刷新問題。

　　四、創建程序內的監控，以及代碼層面的掃描等，手淘本身的代碼平臺有一些性能的掃描，但還不夠完善，手淘APP內部也有性能監控的模塊能夠實時監控和統計程序中的性能問題。

　　五、冰凍三尺非一日之寒。代碼掃描和監控等自己都有必定的侷限性，並且監控自己就會致使必定的性能損耗。因此一個性能好的APP應該防患於未然，從源頭抓起，只有開發人員都對Java和android相關的性能至關熟悉，在開發的時候到處考慮到性能和內存問題，追求卓越，才能防微杜漸，這也是手機淘寶接下來努力的方向之一。

　　

優化是沒有止境的，雖然經過這幾個月的優化，手淘在內存使用上降低了接近50%，平均幀率提升了近20%，首頁的GC減小了90%。可是在低內存，低性能的手機上，手淘仍是面臨不少的挑戰，須要不斷的去優化，也須要從源頭上就把性能這塊提高。