簡介：大促一直是技術和產品的練兵場，每到大促，各種豐富的富媒體，如直播，視頻，3D，游戲互動，AR等競相上線，在淘寶的大航母戰(zhàn)略下，都集中在萬千寵愛于一身的淘寶App上，在這樣的大促場景下，開始觸碰到端側系統(tǒng)資源上限的天花板。在17年雙11大促期間，端側的內存問題尤為突顯，OOM的高居所有問題的榜首。內存問題成為了這幾年大促端側穩(wěn)定性最大的挑戰(zhàn)。

作者|鄒迪飛（之羲）
編輯|橙子君
出品|阿里巴巴新零售淘系技術

大促一直是技術和產品的練兵場，每到大促，各種豐富的富媒體，如直播，視頻，3D，游戲互動，AR等競相上線，在淘寶的大航母戰(zhàn)略下，都集中在萬千寵愛于一身的淘寶App上，在這樣的大促場景下，開始觸碰到端側系統(tǒng)資源上限的天花板。在17年雙11大促期間，端側的內存問題尤為突顯，OOM的高居所有問題的榜首。內存問題成為了這幾年大促端側穩(wěn)定性最大的挑戰(zhàn)。

17年雙11 Crash問題分類

17年雙11 Crash走勢與業(yè)務上線關系

放飛業(yè)務

兩年后的今天，通過我們持續(xù)的技術挖掘與治理，內存問題不再是影響大促穩(wěn)定性的最主要的因素，本次618大促前所未有的支持了猜你喜歡無限坑位，支持了豐富的直播和小視頻玩法，支持了會場上百個運營坑位，支持了互動業(yè)務的不降級策略，各種業(yè)務花式上線的同時，我們的端側穩(wěn)定性還進一步提升，crash率遠好于去年同期。

618期間今年與去年對比crash走勢

迎難而上，各顯神通

面對內存帶來的挑戰(zhàn)，我們2年以來，一直在摸索中前行，沉淀一套內存治理的經驗。

面向大促，當出現了問題后，我們要去思考當前的機制與規(guī)范，于是我們制定了內存標準與業(yè)務的上線驗收。同時，提供了內存分析的一套工具，方便很快很準找到問題。同時，我們制定了三套內存優(yōu)化策略：

**1. 精打細算，提升內存的使用率

兜底容災，盡量讓應用延長生命

提升內存上限，突破系統(tǒng)的天花板**

驗收標準-----一夫當關

由于內存天花板的存在，從穩(wěn)定性角度綜合考慮，引入了大促的驗收標準。標準的制定過程中，我們統(tǒng)計了發(fā)生OOM時的水位內位，分析出了高危，危險，正常水位線，以此為內存標準的制定指引。

內存問題之所以復雜，是因為內存是一個全局共享池子，當出現溢出問題時，在沒有明顯問題時，很難去界定哪個業(yè)務存在問題，因此，在考慮標準的時候，我們定義了兩種場景。單頁面及鏈路。

單頁面場景主要是為了減少單個業(yè)務過多的占用內存引發(fā)的風險。前面提到內存池子是全局且有限的，當單頁面占據內存過多，就會導致系統(tǒng)整體可用的內存大幅減少，在瀏覽相同頁面次數的情況，增加整體內存風險。

鏈路場景是對常見瀏覽鏈路的內存檢測，比如從首頁-會場-互動-店鋪-詳情-下單這樣的常規(guī)玩法進行多頁面疊加檢測，判斷用戶正常場景下的內存風險。

同時，在制度內存標準時，也考慮了不同技術棧之間的差異。比如H5,weex,native，包括多tab的會場形式及直播，3D等。

內存優(yōu)化三板斧

前面提到內存優(yōu)化主要有三種策略，這里分開詳述。

? 精打細算-提升內存的利用率

在業(yè)務屢屢觸及內存天花板的情況下，每1KB的內存，都顯得非常珍貴。

在實際對內存占用的分析中，我們偶爾會發(fā)現有些場景加載的圖片遠大于視圖的大小，造成內存的浪費。或者在某些場景下，圖片在內存中持有過久，比如在后臺或是壓棧很久后，圖片所持有的空間仍不能釋放出來給當前界面使用，面對這樣的場景，我們在高可用體系中引用了對應的功能，能夠檢測出這些case，以便把內存交給用戶正在使用的組件，以此來提升內存的利用率。

從圖片庫的數據流轉以及View生命周期出發(fā)，來設計圖片自動回收和恢復的實現，即當View不可見的時候，自動釋放圖片到圖片庫緩存，只保留圖片的key值；當View可見的時候，又通過key恢復圖片。圖片片自帶三級緩存策略，回收后的圖片如果還在緩存，能立馬恢復，對體驗幾乎無損。

同時，針對一些內存大戶，也和各業(yè)務方約定一些實例數限制，比如詳情頁，有大圖，還帶視頻，webview等，內存使用相對較大，這種情況下會對實例數做要求。目前有限制包括詳情頁，播放器實例等。

為了更好的體驗，在降級策略上我們也做了一些優(yōu)化，不再一刀切，而是根據各設備自身的能力，有選擇的進行降級。要更好的達成目標，我們首先對設備進行分級，依賴于創(chuàng)建的智能分級。

統(tǒng)一降級在設備評分的基礎上，提供默認的高中低端機型的設備分級能力，增加了配置化能力，為每個核心業(yè)務分配一個orange，支持業(yè)務對系統(tǒng)、品牌、機型、設備分、應用版本、生效時間等多個維度進行配置化降級。

依賴于統(tǒng)一降級，可以做到精準的體驗分級，高端機型，可以采用各種特效和高清圖片，能保障最優(yōu)體驗。中端機型，降級掉一部分特效，可以獲得較好效果，低端機型，保障穩(wěn)定性和基礎體驗。實現 “高端設備最炫體驗，低端設備流暢優(yōu)先，緊急問題快速降級”

統(tǒng)一降級后的效果

? 兜底容災--盡量延長生命周期

在應用內存最危險的時候，也許下一次的內存申請即面臨崩潰，在這最危險的時候，我們是否有能力緩解一下，讓用戶多下一單呢，為此我們設計了內存容災SDK。

具體原理是基于gc和lowmemorykiller原理實現（Android的OOM要區(qū)分jvm heap內存不足和native的內存不足），通過監(jiān)聽系統(tǒng)的gc和lowmemorykiller，去計算系統(tǒng)當前所處的內存狀態(tài)，當內存不足的時候，銷毀掉優(yōu)先級較低的Activity，從而保障用戶可見面Activity能盡可能多的使用內存而不出現穩(wěn)定性問題。

內存容災基本原理

? 擴充上限-突破系統(tǒng)天花板

手淘的戰(zhàn)略一直是航母戰(zhàn)略，前面的打法只能緩解當前的穩(wěn)定性問題，只能治標，不能治本。業(yè)務技術對內存的需求有增無減，無限坑位，會場上的直播視頻等，都帶來進一步的壓力。只有提升端內的內存容量，才是解決內存問題的最終解法。

多進程

多進程的使用是突破系統(tǒng)天花板的方法之一。由于大促態(tài)的變化新增以H5的頁面居多，所以我們重點希望在webview上能有一些突破。這時蘋果的WKWebivew被納入到研究范圍，關于WKWebview在內存的優(yōu)勢，經過我們的分析結論如下：

WKWebView的內存并不計算在主應用的內存中，而是作為獨立進程單獨進行計算，因此對于應用來說使用WKWebView相比UIWebView，應用整體可以使用更多的內存，因為Web的內存都在WKWewbView的Web進程中，并不影響主應用的內存上限。

對于Android來說，平臺本身則支持的多進程方式，因此，我們最初的設計中，是依賴于Activity的獨立進程方式，即使BrowserActivity獨立出來。

在99大促的AB實驗中，對比對照組，在訪問過淘金幣/互動的用戶中，主進程native crash率下降15%-18%，Crash計數(主+子) 下降1萬次以上。在所有用戶中，下降3%-5%，對內存的優(yōu)化效果還是比較明顯。

但是考慮到很多基礎SDK在設計之初并沒有考慮到多進程的方式，且多進程下應用的生命周期也有一些變化，整體方案不確認的風險較大。最終采用的是UC內核的多進程方案，它將整個H5頁面的解析、排版、js執(zhí)行等實現抽離封裝到一個獨立的進程中，分擔了主進程一部分內存壓力，從而實現突破單進程內存容量天花板的目標。

UC多進程示意圖

uc多進程對crash率的影響

根據嚴格AB實驗的結果評估，手淘開啟UC多進程之后，Crash率能有30-40%的下降收益。

64位升級

一般說來，現在使用的程序，都是在32位的指令集下編譯出來的結果，在32位子系統(tǒng)下，內存地址的大小只有4個字節(jié)，理論上的最大尋址空間只有4G。前面提到，在當前手淘的業(yè)務容量下，4G的內存地址已經不能滿足，在今年開始力推手淘andorid架構從32位升級到64位。

說到64位，在硬件上，arm v8及以后的cpu都升級到了64位的架構，在軟件上，android 5.0以后的系統(tǒng)開始支持了64位子系統(tǒng)。我們做過比較準確統(tǒng)計埋點，在市面上的手機，約有95%是支持64位運算的，也就是說64位升級帶來的收益可以覆蓋到絕大多數的用戶。另一方面，我們也要看到64位升級帶來的風險，所有的C/C++代碼都需要重新編譯到64位指令集，可能的風險點包括：

• 指針長度是從32位升到64位，對一些HardCode的寫法可能計算出錯，產生穩(wěn)定性問題。
• 自定義so的加載邏輯（如服務端遠程下載）可能沒有考慮多cpu abi的情況，加載錯誤so，產生穩(wěn)定性問題。
• 儲存的數據，看看有沒有因為64位和32位不同導致不兼容，特別是一些二進制數據，導致覆蓋安裝或升級后原數據不可用

為了應對這些風險，自3月份起就開始針對手淘中的120多個so進行回歸，包括看32位與64位相互覆蓋的升級場景，另一方面，針對so的加載邏輯，進行全手淘代碼掃描，分析和查看自定義加載so的場景確認是否支持多cpuabi。經過幾個月的灰度和迭代，最終在618版本前，完成了64位的上線。

在本次的618大促中，可以明顯看到，以往大促中，OOM的占比，最高的時候，可以占到近40%，經過64位升級與多進程手段疊加后，可以看到看大促態(tài)的OOM占比，已經降到了10%左右。這里面還包括了5%的32位用戶，對OOM的治理效果非常顯著。

展望

新技術形態(tài)的挑戰(zhàn)
內存問題一直是大促端側穩(wěn)定性最大的挑戰(zhàn)，在今天已經得到比較好的解決，當然，系統(tǒng)資源終歸是有限的，我們仍然需要有效合理的使用系統(tǒng)資源。更重要的是，面向未來，新的技術形態(tài)像flutter等入淘，多個虛似機的并存，對系統(tǒng)資源仍然會有較大的挑戰(zhàn)。

從穩(wěn)定性到流暢體驗
對用戶來說，穩(wěn)定性只是最基礎要求，后續(xù)我們會在體驗上持續(xù)優(yōu)化，帶給手淘用戶真正的如絲般順滑的體驗。

手淘客戶端團隊

一年一度的應屆生秋招正式開始，崗位豐富，歡迎掃描下面二維碼了解詳情。同時大量移動端社招崗位opening
簡歷投放地址📮：difei.zdf@alibaba-inc.com

關注「淘系技術」微信公眾號，一個有溫度有內容的技術社區(qū)~

原文鏈接：https://developer.aliyun.com/article/769531?

版權聲明：本文內容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產權保護指引》。如果您發(fā)現本社區(qū)中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區(qū)將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的客户端稳定性优化实战，Crash率最高下降40%的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。