天貓11.11：手機淘寶 521 性能優化項目揭秘

又是一年雙十一，億萬用戶都會在這一天打開手機淘寶，高興地在會場頁面不斷瀏覽，面對琳瑯滿目的商品圖片，搶著添加購物車，下單付款。為了讓用戶 更順暢更方便地實現這一切，做到“如絲般順滑”，雙十一前夕手機淘寶成立了“521”（我愛你）性能優化項目，在日常優化基礎之上進行三個方面的專項優化 攻關，分別是1)H5頁面的一秒法則；2)啟動時間和頁面幀率提升20%；3)Android內存占用降低50%。優化過程中遇到的困難，思考后找尋的方 案，實施后提取的經驗都會在下面詳細地介紹給讀者。

第一章 一秒法則的實現

“1S法則”是面向Web側，H5鏈路上加載性能和體驗方向上的一個指標，具體指：1)“強網”（4G/WIFI）下，1秒完全完成頁面加載，包括首屏資源，可看亦可用;2)3G下1秒完成首包的返回;3)2G下1秒完成建連。

在移動網絡環境下，http請求和資源加載與有線網絡或者PC時代相比有著本質區別，尤其是在2G/3G網絡下，往往一個資源請求建連的時間都會 是整個Request-Response流程里面的大頭，一些小資源上拖累效應尤其明顯。例如一個1k的圖片，即使在10k/s 的極慢網速下，理論上0.1秒可下載完畢，但由于建立連接的巨大消耗，這樣一個請求會要耗上好幾秒。

僅僅“建連”這一個點，就能說明移動時代的Web側性能優化和PC時代目標和方式都相去甚遠，要求我們必須從更底層，更細致的去抓，才能取得看起來相對有效的結果。

15年初的性能情況

平均LoadTime-WIFI	平均LoadTime - 4G	平均LoadTime - 2G
3.35s	3.84s	14.34s

可以看到優化前,平均時間很難接近1秒。為了實現優化目標，在技術和實施抓手層面，由底層往上，做了四方面事情：

1. 網絡節點：HttpDNS優化
2. 建連復用：SSL化，SPDY建連高復用
3. 容器層面：離線化和預加載方案
4. 前端組件：請求控制，域名收斂，圖片庫，前端性能CheckList

網絡節點：HttpDNS優化

DNS解析想必大家都知道，在傳統PC時代DNS Lookup基本在幾十ms內。而我們通過大量的數據采集和真實網絡抓包分析（存在DNS解析的請求），DNS的消耗相當可觀，2G網絡大量5-10s，3G網絡平均也要3-5s。

針對這種情況，手淘開發了一套HttpDNS－面向無線端的域名解析服務，與傳統走UDP協議的DNS不同，HttpDNS基于HTTP協議。基于HTTP的域名解析，減少域名解析部分的時間并解決DNS劫持的問題。

手淘HttpDNS服務在啟動的時候就會對白名單的域名進行域名解析,返回對應服務的最近IP(各運營商),端口號,協議類型,心跳等信息。

優點

1)防止域名劫持

傳統DNS由Local DNS解析域名，不同運營商的Local DNS有不同的策略，某些Local DNS可能會劫持特定的域名。采用HttpDNS能夠繞過Local DNS，避免被劫持；另外，HttpDNS的解析結果包含HMAC校驗，也能夠防止解析結果被中間網絡設備篡改。

2)更精準的調度

對域名解析而言，尤其是CDN域名，解析得到的IP應該更靠近客戶端的地區和運營商，這樣才能有更快的網絡訪問速度。然而，由于運營商策略的多樣 性，其推送的Local DNS可能和客戶端不在同一個地區，這時得到的解析結果可能不是最優的。HttpDNS能夠得到客戶端的出口網關IP，從而能夠更準確地判斷客戶端的地區 和運營商，得到更精準的解析結果。

3)更小的解析延遲和波動

在2G/3G這種移動網絡下，DNS解析的延遲和波動都比較大。就單次解析請求而言，HttpDNS不會比傳統的DNS更快，但通過 HttpDNS客戶端SDK的配合，總體而言，能夠顯著降低解析延遲和波動。HttpDNS客戶端SDK有幾個特性：預解析、多域名解析、TTL緩存和異 步請求。

4)額外的域名相關信息

傳統DNS的解析結果只有ip，HttpDNS的解析結果采用JSON格式，除了ip外，還支持其它域名相關的信息，比如端口、spdy協議等。利用這些額外的信息，APP可以啟用或停止某個功能，甚至利用HttpDNS來做灰度發布，通過HttpDNS控制灰度的比例。

建連復用：SSL化，SPDY建連高復用

出于安全目的，淘寶實現了全站SSL化。本身和H5鏈路性能優化沒有直接的關系，但是從數據層面看，SSL化之后的資源加載耗時都會略優于普通的Http連接。

有讀者會有疑惑，SSL化之后每個域名首次請求會額外增加一個“SSL握手”的時間，DNS建連也會比http的狀態下要長，這是不可避免的，但是為什么一次完整的RequestRespone 流程耗時會比http狀態下短呢？

合理的解釋是：SSL化之后，SPDY可以默認開啟，SPDY協議下的傳輸效率和建連復用效益將最大化。SPDY協議下，資源并發請求數將不再受瀏覽器webview的并發請求數量限制，并發100+都是可能的。

同時，在保證了域名收斂之后，同樣域名下的資源請求將可以完全復用第一次的DNS建連和SSL握手，所以，僅在第一次消耗的時間完全可以被 SPDY后續帶來的資源傳輸效率，并發能力，以及連接復用度帶來的收益補回來。甚至理論上，越復雜的頁面，資源越多的情況，SSL化+SPDY之后在性能 上帶來的收益越大。

容器層面：離線化和預加載方案

收益最明顯，實現中遇到困難最多的就是離線化或者說資源預加載的方案。預加載方案是為了在 用戶訪問H5之前，將頁面靜態資源（HTML/JS/CSS/IMG...）打包預加載到客戶端；用戶訪問H5時，將網絡IO攔截并替換為本地文件IO；從而實現H5加載性能的大幅度提升。

手淘實現要比上面的通用示意圖復雜：因為Android和iOS安裝包已經很大，所以預加載Zip包（以下簡稱“包”）都是從服務器端下載到客戶端；本地 需要記錄整體包狀態，并在合適的時機與服務器通信并交換狀態信息。在包發布更新的過程中要注意，本地版本和服務端最新包之間的差量同步，必要的網絡判 斷，WiFi下才下載等。

面對億級UV，并且在服務器資源很有限的情況下搞定這個流程，需要借助CDN來扛住壓力，實際上CDN扛住了約98%的流量。

需要注意的是預加載實際上也是一種緩存，更新比H5稍慢一些，主要受幾個因素影響：推送到達率（用戶是否在線，用戶所在網絡質量），總控，服務端策略等，所以需要通過推拉結合的觸發策略并優化下載包的體積（增量包）來提升到達率。

除了優化到達率，手淘還做了url解CDN Combo后再映射的優化工作，若 URL 是 Combo URL，那么會對 URL 解 Combo，解析出其中包含的資源。然后嘗試從本地讀取包含的資源，如果所有資源都在本地存在，那么將本地文件內容拼裝為一份完整文件并返回；否則 URL 直接走線上，不做任何操作。

提升到達率和解CDN Combo再映射，這兩個容器側對于離線化方案的優化對于本次H5鏈路上整體性能的提升有著至關重要的意義。

前端組件：請求控制，域名收斂，圖片庫，前端性能CheckList

嚴格執行性能方面的CheckList，主要有三個點：

1)圖片資源域名全部收斂到gw.alicdn.com;

2)前端圖片庫根據強弱網和設備分辨率做適配;

3)首屏數據合并請求為一個。

在執行中，性能的檢查和校驗一定要納入到發布階段，否則就不是一個合理的流程。性能的工具和校驗一定應該是工程化，研發流程里面的一部分，才能夠保障性能自動化，低成本，不退化。

通過以上優化方案，H5頁面的平均Loadtime在Wifi，4G下均如期進入1秒，3G和2G也有80％多達成1s法則的目標。

第二章 啟動時間和頁面幀率20%的提升

很多App都會遇到以下幾個常見的性能問題：啟動速度慢；界面跳轉慢；事件響應慢；滑動和動畫卡頓。

手機淘寶也不例外。我們分為兩部分來做，第一部分是啟動階段優化，目的解決啟動任務繁多，缺乏管控的問題，減少啟動和首頁響應時間。第二部分是針 對各個界面做優化，提升界面跳轉時間和滑動幀率，解決卡頓問題。雙十一性能優化目標之一就是將啟動時間和頁面幀率在原有基礎上繼續優化提升20%，接下來 就從這兩部分的優化過程來做一一介紹。

一.啟動階段的優化

手機淘寶作為阿里無線的航母，接入的業務Bundle超過100個，啟動初始化任務超過30個，這些任務缺少管控和性能監控。

那么首要任務就是：

建立任務管理機制

所有的初始化任務可以用兩個維度來區分：

1）任務必要性：有些任務是應用啟動所必需的，比如網絡、主容器；有些任務則不是必需的，僅僅實現單個業務功能，甚至是為了業務自身體驗和性能而考慮在啟動階段提前執行，其合理性值得推敲。

2）任務獨立性：將應用的架構簡單分成基礎庫、中間件、業務三層，這三層中業務層最為龐大，其初始化任務也最多。對于中間件來說，其初始化可能依賴于另外一個中間件。但對于一個獨立的業務模塊來說，其初始化任務應該也具有獨立性，不存在跟其他業務模塊依賴關系。

啟動階段任務管理機制包含了如下幾方面的內容

1）任務可并行

既然很多初始化任務是獨立的，那么并行執行可以提高啟動效率。

2）任務可串行

雖然我們期望所有初始化任務都相互獨立，但是在實際中不可避免會存在相互依賴的初始化任務。為了支持這種情況，我們設計任務的異步串行機制，這里主要借鑒了前端的Promise思想實現。

3）任務可插拔

面對這么多不同優先級的初始化任務，任何一個出現異常都會導致應用不能啟動，給穩定性帶來嚴重挑戰。因此我們設計了可插拔機制，當某一項初始化任 務出現問題時能夠跳過該任務，從而不影響整個應用的啟動使用。這里我們根據初始化任務的必要性做了區分，只有非必要的初始化任務才會應用可插拔的特性，這 也是為了防止出現不執行一個必要的初始化任務導致應用啟動使用出現問題。

4）任務可配置

在ios上通過plist指定每一項啟動任務， 其中字段optional表示該項是否是必需的，當之前運行出現crash或者異常時，若值為YES則可以不執行該項。

有了任務管理機制，并引入懶加載的理念，可以持續地合理有效管控啟動階段的各項初始化任務，是大型app必不可少的環節。

檢測超時方法，優化主線程

性能優化前，初始化代碼都在主線程中執行，為了啟動性能已將部分初始化任務放入后臺線程或者異步執行。但是隨著手淘業務發展和人員變更，還是出現 了在主線程中執行很重的初始化任務。為此，在ios實現了一套應用運行時方法耗時檢測機制，能夠對應用中所有類的方法調用做耗時統計。方便的找到超時的方 法調用之后，就可以有針對性的做出修改，或刪除或異步化。這種方法調用耗時檢測機制同樣適用于APP運行過程中，從而找到導致應用卡頓的根本原因，最后做 出對應修改。

多線程治理

分析各個模塊的線程數量，檢查線程池的合理性。通過去掉不必要的線程和線程池，再控制線程池的并發數和優先級。進一步通過框架層的線程池來接管業務方的線程使用，以減少線程太多的問題。

減少IO讀寫

從自身業務出發，去除若干初始化階段不必要的文件操作，以及將若干非實時性要求的文件操作延后處理。Android上對于頻繁讀寫數據庫和 SharedPreference以及文件的模塊，通過增加緩存和降低采樣率等手段減少對IO的讀寫。對于SharedPreference進行了專門的 優化，減少單個文件的大小，將毫無聯系的存儲鍵值分開到不同文件中，并且防止將大數據塊存儲到SharedPreference中，這樣既不利于性能也不 利于內存，因為SharedPreference會有額外的一份緩存長期存在。

降級部分功能

例如搖一搖功能，測試發現應用場景不頻密，但業務使用了高頻率的游戲模式，會耗電及占用主線程時間。對該功能做了降級處理，降低檢測頻率。同理，對于其他非必須使用但又占據較多資源的模塊也都做了適當的降級處理。

熱啟動時間的縮短

在安卓手機上我們把啟動分為兩類進行檢測和優化：冷啟動和熱啟動。冷啟動是程序進程不存在的情況下啟動，熱啟動是指用戶將程序切換到后臺或者不斷按Back鍵退出程序，實際進程還存在的情況下點擊圖標運行。

之前安卓手淘在按Back鍵退出時整個首頁Activity銷毀了，熱啟動會經過一個比較長的過程。優化后首頁在退出的時候并不銷毀 Activity，但是會釋放圖片等主要資源，在下次熱啟動時就能更快的進入。另外，將手淘歡迎頁的界面從其它bundle轉移到首頁的模塊，在進入歡迎 頁時就開始初始化首頁資源，做到更快展示。

在經過一系列的優化后，啟動方面已經有了明顯的改善，在進入首頁的時候不會卡頓，GC次數也減少了一半以上。

二.各個界面的優化

各界面優化我們也是圍繞著提高幀率和加快展現而展開的，手淘的幾個主鏈路界面，都是相對比較復雜的，既使用多圖，也使用了動態模板的技術。功能越 復雜，也越容易產生性能問題，所以常遇到布局復雜、過渡繪制多、Activity主要函數耗時、內容展示慢、界面重新布局（Layout）、GC次數多等 問題。

優化GPU的過渡繪制

通過開發者選項的GPU過渡繪制選項檢查界面的過渡繪制情況。該優化并不復雜，通過去掉層疊布局中多余的背景設置、圖片控件有前景內容的時候不顯 示背景、界面背景定義到Activity的主題中、減少Drawable的復雜Shape使用等手段就可以基本消除過渡繪制，減少對GPU和CPU的浪 費。

優化層級和布局

層級越多，測量和布局的時間就會相應增加，創建硬件列表的時間也會相應增加。有時我們會嵌套很多布局來實現原本只要簡單布局就可以實現的功能，有 時還會添加一些測試階段才會使用的布局。通過刪除無用的層級，使用Merge標簽或者ViewStub標簽來優化整個布局性能。比如一些顯示錯誤界面、加 載提示框界面等，不是必須顯示的這些布局可以使用ViewStub標簽來提升性能。

另外要靈活使用布局，并不是層級越多就會性能越差，有時候1層的RelativeLayout會比3層嵌套的LinearLayout實現的性能更糟糕。

除了靈活使用布局，另外我們還通過提前inflate以及在線程中做一些必要的inflate等來提前初始化布局，減少實際顯示時候的耗時。對于一些復雜的布局，我們還會自己做復用池，減少inflate帶來的性能損耗，特別是在列表中。

加快界面顯示

1）可以通過TraceView工具找出主線程的耗時操作和其他耗時的線程并作優化。另外減少主線程的GC停頓，因為即使并行GC，也會對 heap加鎖，如果主線程請求分配內存的話，也會被掛起，所以盡量避免在主線程分配較多對象和較大的對象，特別是在onDraw等函數中，以減少被掛起的 時間。另外可以通過去掉ListView ,ScrollView等控件的EdgeEffect效果，來減少內存分配和加快控件的創建時間。

2）利用本地緩存，主要界面緩存上次的數據，并且配合增量的更新和刪除，可以做到數據和服務端同步，這樣可以直接展示本地數據，不用等到網絡返回數據。

3）減少不必要的數據協議字段，減少名字長度等，并作壓縮。還可以通過分頁加載數據來加快傳輸解析時間。因為JSON越大，傳輸和解析時間也會越久，引發的內存對象分配也會越多。

4）注意線程的優先級，對于占用CPU較多時間的函數，也要判斷線程的優先級。

優化動畫細節

通過TraceView工具發現，一些Banner輪播廣告和文字動畫在移出可視區域后，仍然存在定時刷新，不僅耗電也影響幀率。優化措施是在移出可視區域后停止動畫輪播。

阻斷多余requestLayout

在ListView滑動，廣告動畫變化等過程中，圖片和文字有變化，經常會發現整個界面被重新布局，影響了性能。尤其布局復雜時，測量過程很費時 導致明顯卡頓。對于大小基本固定的控件和布局例如TextView，ImageView來說，這是多余的損耗。我們可以用自定義控件來阻斷，重寫方法 requestLayout、onSizeChanged，如果大小沒有變化就阻斷這次請求。對于ViewPager等廣告條，可以設置緩存子view的 數量為廣告的數量。

優化中間件

中間件的代碼被上層業務方調用的比較頻繁，容易有較多的高頻率函數，也容易產生細節上的問題。除了頻繁分配對象外，例如類初始化性能，同步鎖的額外開銷，接口的調用時間，枚舉的使用等等都是不能忽視的問題。

減少GC次數

安卓上的GC會引起性能卡頓，必須重點優化。除了第三章會詳細介紹對于圖片內存引起GC的優化，我們還做了如下工作：

1）減少對象分配，找出不必要的對象分配，如可以使用非包裝類型的時候，使用了包裝類型；字符串的+號和擴容；Handler.post(Runnable r)等頻繁使用。

2）對象的復用，對于頻繁分配的對象需要使用復用池。

3）盡早釋放無用對象的引用，特別是大對象和集合對象，通過置為NULL，及時回收。

4）防止泄露，除了最基本的文件、流、數據庫、網絡訪問等都要記得關閉以及unRegister自己注冊的一些事件外，還要盡量少的使用靜態變量和單例。

5）控制finalize方法的使用，在高頻率函數中使用重寫了finalize的類，會加重GC負擔，使得性能上有幾倍的差別。

6）合理選擇容器，在性能上優先考慮數組，即使我們現在習慣了使用容器，也要注意頻繁使用容器在性能上的隱患點：首先是擴容開銷， HashMap擴容時重新Hash的開銷較大。其次是內存開銷，HashMap需要額外的Map.Entry對象分配 ,需要額外內存，也容易產生更多的內存碎片。SparseArray和ArrayList等在內存方面更有優勢。再次是遍歷，對于實現了 RandomAccess接口的容器如ArryList的遍歷，不應該使用foreach循環。

7）用工具監控和精雕細琢：在頁面滑動過程中，通過Memory Monitor查看內存波動和GC情況，還可通過AlloCation Tracker工具觀察內存的分配，發現很多小對象的分配問題。

8）利用Trace For OpenGL工具找出界面上導致硬件加速耗時的點，例如一些圓角圖片的處理等。

通過多種工具和手段配合，手淘各個界面性能上有了較大的提高，平均幀率提高了20%，那么內存節省50%又是如何實現的哩，請看下文。

第三章 Android手機內存節省50%

Android上應用出現卡頓的核心原因之一是主線程完成繪制的周期過長引起丟幀。而影響主線程完成繪制時間的主要有兩方面，一方面是主線程處于運行狀態 時需要做的任務太多但CPU資源有限，另外一方面是GC時Suspend時直接掛起了所有線程包括主線程。GC對總體性能的影響在4.x的系統上尤為突 出，一部分是單次GC pause總時長，一部分是用戶操作過程中GC發生的次數。而決定這兩部分的因素就是Dalvik內存分配。那么在手淘這樣的大型應用中到底是誰占用了 內存大頭 呢？

誰占用了內存

基于雙11前的手淘Android版本，我們在魅藍note1（4.4 OS）上滑動完首頁后，dump出其Dalvik Heap，整體內存占用的分布情況如下圖。可以看出，byte數組（a）占用空間最大，絕大多數是用來存放Bitmap的 像素數據（Pixel Data） 。另外（c）與（d）一起占用了18.4%， byte數組加上Bitmap、BitmapDrawable總共占用了64.4%，成為內存占用的主體。這也從側面說明了手淘是以圖片為瀏覽主體內容的 大型應用。而往往圖片需要較大的內存塊，在分配時引起GC的可能性也往往最大。那我們能不能將圖片這部分需要的內存移走而不在Dalvik Heap分配呢？如果能，那么不單GC會明顯減少，同時Dalvik Heap總大小也會下降50%左右，對整體性能會有顯著的提升。

(點擊放大圖像)

何處安放的Pixel Data

Ashmem即匿名共享內存，使用的核心過程是創建一個/dev/ashmem設備文件，控制反轉設置文件的名字和大小，最終把設備符交給 mmap就得到了共享內存。在Android系統中Binder進程間通信的實現就是依賴Ashmem完成不同進程間的內存共享。但此處并不利用其共享特 性，而是使用它在Native Heap完成內存分配。圖片空間如何才能使用Ashmem，答案在非死book推出的Fresco中已有提及，那就是解碼時的purgeable標 記，這樣在系統底層解碼位圖時會走Ashmem空間分配，而非Dalvik Heap空間。這樣就解決了像素數據存放由Dalvik到Native的問題了嗎？

BitmapFactory.Options options = new BitmapFactory.Options();
  /*
   * inPurgeable can help avoid big Dalvik heap allocations (from API level 11 onward)
   */
  options.inPurgeable = true;
  Bitmap bitmap = BitmapFactory.decodeByteArray(inputByteArray, 0, inputLength, options);

小心Bitmap空包彈

事實并非那么簡單，最后實際解出來Bitmap沒有像素數據（沒有到Ashmem分配任何空間），根本沒有去完成jpeg或者png解碼。此時的 Bitmap是個空包彈！它所做的只是把輸入的解碼前數據拷貝到了native內存，如果把這個Bitmap交給ImageView渲染就糟了，在 View.draw()時Bitmap會在主線程進行圖片解碼。

而且不要天真的以為Bitmap解碼一次之后再多次使用都不會引起二次解碼，在系統內存緊張時底層可能回收Ashmem里這部分內存。回收后該Bitmap再次渲染時又將在主線程完成一次解碼。如果就這樣直接使用該機制，性能上無疑雪上加霜。

那么怎樣才能避免這個隱形炸彈呢？還好SDK預留了一個C層方法AndroidBitmap_lockPixels。而lockPixels底層 完成的工作大致如下圖所示。第一步是prepareBitmap完成真正的數據解碼，在工作線程調用AndroidBitmap_lockPixels避 免了在主線程進行數據解碼；第二步是完成對分配出來的Ashmem空間的鎖定，這樣即使在系統內存緊張時，也不會回收Bitmap像素數據，避免多次解 碼。

(點擊放大圖像)

貌似解決了Bitmap渲染的所有問題，但在手淘中則不然。為了兼容低版本系統以及提升webp解碼性能，我們使用了自己的解碼庫libwebp.so，怎樣把它解碼出來的數據也存放到Ashmem呢？

libwebp借雞生蛋

如果自有解碼庫libwebp.so要解碼到Ashmem，通過SkBitmap、ashmem_create_region實現一套類似的機制 是不太現實的。一方面Skia庫的源碼編譯兼容會存在很大問題，另一方面很多系統層面的核心接口并沒有對外。所以實現這點的關鍵還是要借助系統已經提供的 purgeable到Ashmem的機制，借雞生蛋，穩定性和成本上都能得到保證：

1. 依據圖片寬高生成空JPEG。
2. 走系統解碼接口完成Ashmem Bitmap生成。
3. 覆寫Pixel Data地址在libwebp

完成解碼。

更進一步，遷移解碼前數據

上面談到的內存遷移都是針對Decoded像素數據的，而Encoded圖像數據在解碼時會在Dalvik Heap保存一份，解碼完成后再釋放；Ashmem方式解碼時在底層又會拷貝一份到Native內存，這份數據直到整個Bitmap回收時才釋放。那能否 直接將網絡下載的Encoded數據存放到Native內存，省去Dalvik Heap上的開銷以及解碼時的內存拷貝呢？的確可以，將網絡流數據直接轉移到 MemoryFile 可實現，但遺憾的是真機測試中發現，小米及其他國產“神機”（自改ROM），多線程使用MemoryFile獲取fd到BitmapFactory解碼， 會出現系統死機，懷疑是在并發情況下系統代碼級別的死鎖造成。手機淘寶放棄了這種方案，改用ByteArrayPool復用池技術來減少Dalvik Heap針對Encoded Image的內存分配，效果也不錯。如果應用能接受單線程解碼，還是MemoryFile方案更具優勢。

是放手的時候了

上文提到Bitmap像素數據存放到Ashmem，有讀者可能擔心數據回收問題，其實還是由GC來觸發Ashmem內存的回收。在Dalvik層如果一個Bitmap已經不被任何地方引用，那么在下一次GC時該Bitmap就會從Ashmem中回收，大致流程示意如下圖。

(點擊放大圖像)

再看內存占用

我們再次在魅藍note1中dump出首頁滑動后的內存，如下圖可以看出，原來byte數組（k）大量占用已經不存在了，Bitmap（c）與BitmapDrawable（已不在前14名當中）的占用也急驟下降。應用的總體內存下降近60%。

(點擊放大圖像)

在雙11版本上，針對一些熱門機型在搜索結果頁不斷滾動使用，進行了不同版本的內存占用對比分析，如下圖。可以看出，除華為3c和vivo這類系統內存偏小使用上一直受到控制、內存較為緊張的外，大部分機型內存的下降幅度都達到45%以上。

(點擊放大圖像)

撓走GC之癢

內存下降不是最終目的，最終要將GC對性能的影響降到最低。仍然以魅藍note1打開首頁后滑動到底的內存堆積圖來做對比。可以看到舊版本內存占 用上升趨勢相當明顯，一路帶有各式“毛刺”直奔70MB，每形成一個毛刺就意味一次GC。而雙11版本中，內存只在初期有上升，而后很快下降到21MB左 右，后期也顯得平滑得多，沒有那么多的“毛刺”，就意味著GC發生的次數在明顯減少。

(點擊放大圖像)

舊版本

(點擊放大圖像)

雙11版本

同時使用一些熱門機型，針對雙十一版本在首頁不斷滑動，進行前后版本的GC_FOR_ALLOC次數對比。熱門機型GC次數下降了4~8倍，效果非常明顯。

通過上文描述的各個優化方案，手機淘寶于雙十一前在大部分機型上達到了521目標－Android手機內存節省50%，啟動時間和頁面幀率提升20%，H5頁面實現1s法則。

從持續不斷的優化中，我們也得到了一套優化的經驗閉環，由觀察問題現象到分析原因，建立監控，定下量化目標，執行優化方案，驗證結果數據再回到觀察新問題。每一次閉環只能解決部分問題，只有不斷抓住細微的優化點“啃”下去，才能得到螺旋上升的良好結果。

當然，隨著手機機型的日益碎片化，程序功能的復雜化多樣化，性能調優是沒有止境的，在部分低端機和低內存手機上手淘性能問題依然不容樂觀。欲窮千里目，還需更上一層樓，接下來我們還會努力通過更多更細致的優化方案來達到“如絲般順滑”。

手機淘寶技術團隊陳虹如（岑安）、倪天雪（曉田）、徐凱（鬼道）、王曜東 （雪鷺）、呂承飛（呂行）、趙密（正凡）、黎明（雷曼）等同學參與本文創作。