作者|鄒迪飛（之羲）
編輯|橙子君
出品|阿裡巴巴新零售淘系技術
大促一直是技術和産品的練兵場，每到大促，各種豐富的富媒體，如直播，視訊，3D，遊戲互動，AR等競相上線，在淘寶的大航母戰略下，都集中在萬千寵愛于一身的淘寶App上，在這樣的大促場景下，開始觸碰到端側系統資源上限的天花闆。在17年雙11大促期間，端側的記憶體問題尤為突顯，OOM的高居所有問題的榜首。記憶體問題成為了這幾年大促端側穩定性最大的挑戰。
17年雙11 Crash問題分類
17年雙11 Crash走勢與業務上線關系
放飛業務
兩年後的今天，通過我們持續的技術挖掘與治理，記憶體問題不再是影響大促穩定性的最主要的因素，本次618大促前所未有的支援了猜你喜歡無限坑位，支援了豐富的直播和小視訊玩法，支援了會場上百個營運坑位，支援了互動業務的不降級政策，各種業務花式上線的同時，我們的端側穩定性還進一步提升，crash率遠好于去年同期。
618期間今年與去年對比crash走勢
迎難而上，各顯神通
面對記憶體帶來的挑戰，我們2年以來，一直在摸索中前行，沉澱一套記憶體治理的經驗。
面向大促，當出現了問題後，我們要去思考目前的機制與規範，于是我們制定了記憶體标準與業務的上線驗收。同時，提供了記憶體分析的一套工具，友善很快很準找到問題。同時，我們制定了三套記憶體優化政策：
**1. 精打細算，提升記憶體的使用率
- 兜底容災，盡量讓應用延長生命
- 提升記憶體上限，突破系統的天花闆**
驗收标準-----一夫當關
由于記憶體天花闆的存在，從穩定性角度綜合考慮，引入了大促的驗收标準。标準的制定過程中，我們統計了發生OOM時的水位内位，分析出了高危，危險，正常水位線，以此為記憶體标準的制定指引。
記憶體問題之是以複雜，是因為記憶體是一個全局共享池子，當出現溢出問題時，在沒有明顯問題時，很難去界定哪個業務存在問題，是以，在考慮标準的時候，我們定義了兩種場景。單頁面及鍊路。
單頁面場景主要是為了減少單個業務過多的占用記憶體引發的風險。前面提到記憶體池子是全局且有限的，當單頁面占據記憶體過多，就會導緻系統整體可用的記憶體大幅減少，在浏覽相同頁面次數的情況，增加整體記憶體風險。
鍊路場景是對常見浏覽鍊路的記憶體檢測，比如從首頁-會場-互動-店鋪-詳情-下單這樣的正常玩法進行多頁面疊加檢測，判斷使用者正常場景下的記憶體風險。
同時，在制度記憶體标準時，也考慮了不同技術棧之間的差異。比如H5,weex,native，包括多tab的會場形式及直播，3D等。
測試同學研發的TMQ自動化測試工具
記憶體優化三闆斧
前面提到記憶體優化主要有三種政策，這裡分開詳述。
▐ 精打細算-提升記憶體的使用率
在業務屢屢觸及記憶體天花闆的情況下，每1KB的記憶體，都顯得非常珍貴。
在實際對記憶體占用的分析中，我們偶爾會發現有些場景加載的圖檔遠大于視圖的大小，造成記憶體的浪費。或者在某些場景下，圖檔在記憶體中持有過久，比如在背景或是壓棧很久後，圖檔所持有的空間仍不能釋放出來給目前界面使用，面對這樣的場景，我們在高可用體系中引用了對應的功能，能夠檢測出這些case，以便把記憶體交給使用者正在使用的元件，以此來提升記憶體的使用率。
從圖檔庫的資料流轉以及View生命周期出發，來設計圖檔自動回收和恢複的實作，即當View不可見的時候，自動釋放圖檔到圖檔庫緩存，隻保留圖檔的key值；當View可見的時候，又通過key恢複圖檔。圖檔片自帶三級緩存政策，回收後的圖檔如果還在緩存，能立馬恢複，對體驗幾乎無損。
同時，針對一些記憶體大戶，也和各業務方約定一些執行個體數限制，比如詳情頁，有大圖，還帶視訊，webview等，記憶體使用相對較大，這種情況下會對執行個體數做要求。目前有限制包括詳情頁，播放器執行個體等。
為了更好的體驗，在降級政策上我們也做了一些優化，不再一刀切，而是根據各裝置自身的能力，有選擇的進行降級。要更好的達成目标，我們首先對裝置進行分級，依賴于建立的智能分級。
統一降級在裝置評分的基礎上，提供預設的高中低端機型的裝置分級能力，增加了配置化能力，為每個核心業務配置設定一個orange，支援業務對系統、品牌、機型、裝置分、應用版本、生效時間等多個次元進行配置化降級。
依賴于統一降級，可以做到精準的體驗分級，高端機型，可以采用各種特效和高清圖檔，能保障最優體驗。中端機型，降級掉一部分特效，可以獲得較好效果，低端機型，保障穩定性和基礎體驗。實作 “高端裝置最炫體驗，低端裝置流暢優先，緊急問題快速降級”
統一降級後的效果
▐ 兜底容災--盡量延長生命周期
在應用記憶體最危險的時候，也許下一次的記憶體申請即面臨崩潰，在這最危險的時候，我們是否有能力緩解一下，讓使用者多下一單呢，為此我們設計了記憶體容災SDK。
具體原理是基于gc和lowmemorykiller原理實作（Android的OOM要區分jvm heap記憶體不足和native的記憶體不足），通過監聽系統的gc和lowmemorykiller，去計算系統目前所處的記憶體狀态，當記憶體不足的時候，銷毀掉優先級較低的Activity，進而保障使用者可見面Activity能盡可能多的使用記憶體而不出現穩定性問題。
記憶體容災基本原理
▐ 擴充上限-突破系統天花闆
手淘的戰略一直是航母戰略，前面的打法隻能緩解目前的穩定性問題，隻能治标，不能治本。業務技術對記憶體的需求有增無減，無限坑位，會場上的直播視訊等，都帶來進一步的壓力。隻有提升端内的記憶體容量，才是解決記憶體問題的最終解法。
多程序
多程序的使用是突破系統天花闆的方法之一。由于大促态的變化新增以H5的頁面居多，是以我們重點希望在webview上能有一些突破。這時蘋果的WKWebivew被納入到研究範圍，關于WKWebview在記憶體的優勢，經過我們的分析結論如下：
WKWebView的記憶體并不計算在主應用的記憶體中，而是作為獨立程序單獨進行計算，是以對于應用來說使用WKWebView相比UIWebView，應用整體可以使用更多的記憶體，因為Web的記憶體都在WKWewbView的Web程序中，并不影響主應用的記憶體上限。
對于Android來說，平台本身則支援的多程序方式，是以，我們最初的設計中，是依賴于Activity的獨立程序方式，即使BrowserActivity獨立出來。
在99大促的AB實驗中，對比對照組，在通路過淘金币/互動的使用者中，主程序native crash率下降15%-18%，Crash計數(主+子) 下降1萬次以上。在所有使用者中，下降3%-5%，對記憶體的優化效果還是比較明顯。
但是考慮到很多基礎SDK在設計之初并沒有考慮到多程序的方式，且多程序下應用的生命周期也有一些變化，整體方案不确認的風險較大。最終采用的是UC核心的多程序方案，它将整個H5頁面的解析、排版、js執行等實作抽離封裝到一個獨立的程序中，分擔了主程序一部分記憶體壓力，進而實作突破單程序記憶體容量天花闆的目标。
UC多程序示意圖
uc多程序對crash率的影響
根據嚴格AB實驗的結果評估，手淘開啟UC多程序之後，Crash率能有30-40%的下降收益。
64位更新
一般說來，現在使用的程式，都是在32位的指令集下編譯出來的結果，在32位子系統下，記憶體位址的大小隻有4個位元組，理論上的最大尋址空間隻有4G。前面提到，在目前手淘的業務容量下，4G的記憶體位址已經不能滿足，在今年開始力推手淘andorid架構從32位更新到64位。
說到64位，在硬體上，arm v8及以後的cpu都更新到了64位的架構，在軟體上，android 5.0以後的系統開始支援了64位子系統。我們做過比較準确統計埋點，在市面上的手機，約有95%是支援64位運算的，也就是說64位更新帶來的收益可以覆寫到絕大多數的使用者。另一方面，我們也要看到64位更新帶來的風險，所有的C/C++代碼都需要重新編譯到64位指令集，可能的風險點包括：
- 指針長度是從32位升到64位，對一些HardCode的寫法可能計算出錯，産生穩定性問題。
- 自定義so的加載邏輯（如服務端遠端下載下傳）可能沒有考慮多cpu abi的情況，加載錯誤so，産生穩定性問題。
- 儲存的資料，看看有沒有因為64位和32位不同導緻不相容，特别是一些二進制資料，導緻覆寫安裝或更新後原資料不可用
為了應對這些風險，自3月份起就開始針對手淘中的120多個so進行回歸，包括看32位與64位互相覆寫的更新場景，另一方面，針對so的加載邏輯，進行全手淘代碼掃描，分析和檢視自定義加載so的場景确認是否支援多cpuabi。經過幾個月的灰階和疊代，最終在618版本前，完成了64位的上線。
在本次的618大促中，可以明顯看到，以往大促中，OOM的占比，最高的時候，可以占到近40%，經過64位更新與多程序手段疊加後，可以看到看大促态的OOM占比，已經降到了10%左右。這裡面還包括了5%的32位使用者，對OOM的治理效果非常顯著。
展望
新技術形态的挑戰
記憶體問題一直是大促端側穩定性最大的挑戰，在今天已經得到比較好的解決，當然，系統資源終歸是有限的，我們仍然需要有效合理的使用系統資源。更重要的是，面向未來，新的技術形态像flutter等入淘，多個虛似機的并存，對系統資源仍然會有較大的挑戰。
從穩定性到流暢體驗
對使用者來說，穩定性隻是最基礎要求，後續我們會在體驗上持續優化，帶給手淘使用者真正的如絲般順滑的體驗。
手淘用戶端團隊
一年一度的應屆生秋招正式開始，崗位豐富，歡迎掃描下面二維碼了解詳情。同時大量移動端社招崗位opening
履歷投放位址📮：[email protected]
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~