安卓App穩(wěn)定性之旅--記Crash率 <=0.1% 實踐

穩(wěn)定性的意義

在移動應(yīng)用性能方面捕发，崩潰帶來的影響是最為嚴(yán)重的锁右。

移動應(yīng)用崩潰主要是由操作系統(tǒng)引發(fā)失受，是指應(yīng)用在運(yùn)行過程中出現(xiàn)的強(qiáng)制關(guān)閉(Force Closing)現(xiàn)象，從而打斷用戶正在進(jìn)行的操作體驗咏瑟。

應(yīng)用崩潰可以造成關(guān)鍵業(yè)務(wù)中斷拂到、用戶留存率下降、品牌口碑變差码泞、生命周期價值下降等影響兄旬。

根據(jù)統(tǒng)計數(shù)據(jù)顯示，當(dāng)iOS的崩潰率超過0.8%余寥，Android的崩潰率超過0.4%的時候辖试，活躍用戶有明顯下降態(tài)勢。

行業(yè)標(biāo)準(zhǔn)

image

Android行業(yè)標(biāo)準(zhǔn)：

• 優(yōu)秀App：0%-0.2%
• 標(biāo)準(zhǔn)App：0.2%-0.4%

而作為一個有追求的技術(shù)團(tuán)隊劈狐，我們追求一個有挑戰(zhàn)的標(biāo)準(zhǔn)：Crash Session<=0.1% 或者說Crash Free Session>=99.9%

：）

改進(jìn)前

image

分析：

• Crash平均在0.3%
• 偶爾觸達(dá)0.2%
• 某時間段一度高于0.8%（不穩(wěn)定）
• 從未達(dá)到過0.1%

評價：處于行業(yè)標(biāo)準(zhǔn)水平罐孝，偶爾有隱患版本發(fā)布

三板斧

1. 磨刀不誤砍柴工：改進(jìn)Crash上報系統(tǒng)

   每個app都有Crash上報系統(tǒng)，手機(jī)證券采用的是百度SDK肥缔。而它不能將線上混淆后的代碼映射成開發(fā)代碼莲兢，因此很難定位問題。

   因此我們將百度SDK替換成Fabric续膳。

   百度SDK：

   image

   Fabric：

   image

2. 第一板斧：解決Crash問題

   現(xiàn)在的當(dāng)務(wù)之急當(dāng)然是解決已有Crash問題了改艇。

   image

3. 第二板斧：提高編碼質(zhì)量

   高質(zhì)量代碼是穩(wěn)定性的基石，在當(dāng)前背景下（較多需求開發(fā)）坟岔，我們有沒有工具能高效地幫助我們提高代碼質(zhì)量呢谒兄？，能有立竿見影效果呢社付？

   靜態(tài)掃描工具：Lint承疲、Findbugs

   • Lint：安卓自帶的代碼掃描工具

     通過它對Android工程源代碼進(jìn)行掃描和檢查邻耕，可發(fā)現(xiàn)潛在的問題。

     主要包括：xml文件中是否存在hardcode燕鸽、unused resources兄世、probable bug等等。

   • Findbugs是java的靜態(tài)分析工具

     它檢查類或者JAR 文件啊研，將字節(jié)碼與一組缺陷模式進(jìn)行對比以發(fā)現(xiàn)可能的問題御滩。

     Findbugs自帶檢測器，其中有60余種Bad practice党远，80余種Correctness削解，1種 Internationalization，12種Malicious code vulnerability沟娱，27種Multithreaded correctness氛驮，23種Performance，43種Dodgy花沉。

   通過這兩個工具的掃描報告柳爽，可以找到很多代碼的邏輯錯誤媳握、隱藏問題碱屁、性能問題等一般共性問題。

   同時我們也要認(rèn)識到這類工具的局限性蛾找。并通過自定義配置來避免“噪音”娩脾。

   lint：

   image
   image

   findbugs：

   image
   image

4. 第三板斧：灰度

   測試遺漏問題就這樣放出去嗎？有隱藏bug怎么辦打毛？

   祭出王牌：灰度發(fā)布

   所謂的灰度發(fā)布柿赊，簡單來講，就是不要一開始就讓所有用戶下載安裝應(yīng)用幻枉，而是先覆蓋一小部分用戶碰声！

   發(fā)布不是簡單的從0到1，不是非黑即白熬甫，在中間有一個緩沖的灰色地帶胰挑。

   通過灰度發(fā)布，真實用戶的真實場景測試椿肩，我們可以更全面瞻颂、更深入的收集問題，修復(fù)問題郑象。
   隨著灰度覆蓋范圍的增加贡这，暴露的問題也越來越充分，而當(dāng)全量發(fā)布的時候厂榛，一定是一個穩(wěn)定的版本盖矫！

   目前的策略：先在某一個渠道灰度丽惭，當(dāng)問題暴露的足夠多時，再發(fā)布全量版本炼彪。

改進(jìn)后

image

Never Stop

目標(biāo)：長期穩(wěn)定在<=0.1%

后續(xù)規(guī)劃的實踐

1. 編程維度：

   • 持續(xù)解決收集到的Crash問題

   • OOM和內(nèi)存泄漏問題：

     • 通過LeakCancary來檢測內(nèi)存泄漏問題吐根，并解決問題。
     • 通過內(nèi)存檢測工具來檢測內(nèi)存占用情況辐马，并優(yōu)化問題拷橘。
     • 通過技術(shù)選型，尋找更好的圖片管理框架喜爷。

   • 編碼規(guī)范：編碼規(guī)范的重要性我就不闡述了

     1. 統(tǒng)一團(tuán)隊內(nèi)編碼規(guī)范冗疮，這里可以參考：阿里巴巴的Java開發(fā)手冊，站在巨人的肩膀上檩帐。
     2. 生成編碼規(guī)范的IDE（Android Studio）配置术幔，工程師導(dǎo)入配置之后，可以非常方便的用快捷鍵 Reformate Code
     3. 使用靜態(tài)掃描工具CheckStyle和Lint來檢查代碼規(guī)范湃密。

   • 代碼重復(fù)度：

     1. 通過靜態(tài)掃描工具檢測重復(fù)代碼诅挑。
     2. 抽取重復(fù)代碼，提供工具類及底層基礎(chǔ)類泛源。

   • 復(fù)雜度：

     • 框架升級：一個好的框架可以減少工程師的代碼量拔妥，提高效率。
     • Kotlin：語言級的改進(jìn)达箍。簡潔的語法没龙，以及NullSafty特性都是非常好的特性。

2. 流程化及工具維度：

   • 結(jié)對編程：主要是在前期設(shè)計和疑難模塊編寫時使用缎玫，希望取長補(bǔ)短硬纤，尋求更高質(zhì)量的代碼。
   • CodeReview：在代碼提交的流程上使用CodeReview機(jī)制赃磨。
   • 在Jenkins中集成靜態(tài)掃描插件：findbug筝家、lint、CheckStyle邻辉、PMD等溪王。

3. 測試維度：

   • 充分的開發(fā)自測：自己寫的代碼，自己最清楚會有什么問題恩沛，開發(fā)自測發(fā)現(xiàn)問題的效率最高在扰。
   • 單元測試：
     • 引入單元測試框架：junit、mockito雷客、robolectric
     • 靜態(tài)掃描工具：單元測試覆蓋率
   • 兼容性測試
   • monkey測試

4. 發(fā)布維度：

   • 灰度2.0

     當(dāng)前灰度策略其實還不完善芒珠，后續(xù)我們會提供一種更完善的灰度機(jī)制：根據(jù)用戶的應(yīng)用版本號，手機(jī)型號搅裙，UUID等信息來選擇灰度的用戶皱卓，通過彈對話框的方式提示用戶升級裹芝。

     這樣我們就能很方便的從多個維度來灰度，比如：Android7.0里面5%的用戶娜汁。

   • 終極殺招：熱修復(fù)

     通過熱修復(fù)技術(shù)嫂易，客戶端可以發(fā)布補(bǔ)丁來解決線上版本的穩(wěn)定性問題，而無需發(fā)版本掐禁。

     熱修復(fù)作為當(dāng)下熱門的技術(shù)怜械，在業(yè)界內(nèi)比較著名的有阿里巴巴的AndFix、Dexposed傅事，騰訊QQ空間的超級補(bǔ)丁和微信的Tinker缕允。