專案背景
本APP為面向使用者的一款LBS產品。使用者反饋APP使用過程中存在啟動慢等問題。本文主要針對該原生Android APP啟動慢的問題進行分析及解決方案的介紹。
所遇到的挑戰
使用者反饋的啟動慢問題偏主觀使用評價，對於專業的技術人員來說，這些反饋評價不夠量化，無法為為我們解決問題提供有效的資料支撐。當然使用者的負面評價也暴露了我們APP存在的兩大問題。
1.監控體系不完善
無論後端服務還是移動端，我們均沒有引入全鏈路追蹤框架，導致應用缺乏全面的監控覆蓋。當時的情況，我們僅埋點記錄了少量系統級監控指標，關鍵程式碼路徑監控嚴重不足。
2.程式碼質量較差
我們的專案歷經多代開發維護，隨著業務複雜性的升高及人員流動的影響，程式碼質量參差不齊，程式碼腐化問題嚴重，有的子系統程式碼閱讀性極差，程式碼風格不統一。
解決問題的步驟
我們針對啟動慢的問題進行分析後，對兩大挑戰對症下藥，主要的解決步驟如下。
1.完善監控體系
我們經過討論總結後，面臨兩個選擇，一個是基於開源的Skywalking等APM系統進行定製開發，存在的問題是現有工程師不熟悉該系統，短期內很難短時間補足相關知識等問題；二是採用成熟的APM系統，但這會帶來較大的短期資金壓力。鑑於我們專案的緊迫性，我們選擇了方案二，引入了友盟+應用效能監控平臺U-APM。
引入U-APM後，我們能對應用端進行非常詳細的監控，比如下圖的概覽監控。結合U-APM的啟動分析能力，我們第一次較為精確地明確了使用者啟動的耗時及分佈。
此外，我們還為服務端引入了ELK套件（ElasticSearch，Logstash，Kibana）和結構化日誌，將關鍵程式碼路徑引數及耗時等資訊進行高效輸出並匯聚展示。
2.加強程式碼質量管控
我們以前的程式碼開發過於注重速度，忽略了質量，雖然有CR（Code Review），但多流於形式，質量把控不嚴。我們借鑑業界工程效能最佳實踐，對程式碼提交及評審打回率等關鍵指標進行監控並定期發出報表，對不合格的專案進行通報，並召開專題會議介紹程式碼質量提升實踐。
3.動手解決
有了監控體系後，我們就擁有了明亮的眼睛去觀察我們的系統。我們通過對量化後的耗時進行分析，初步判斷出瓶頸所在，優先解決主要矛盾。理論上，每個請求都有優化空間，那是不是每個都需要優化呢？答案當然是否定的，因為服務間介面數以千計，如果消耗太多精力在非關鍵介面上，很容易事倍功半。我們採用的ROI(Return On Investment)的思想，優先解決耗時佔比較大、請求頻繁的函式呼叫以取得最大收益。具體來講有如下幾點。
1)安卓應用端問題
初次啟動app耗時長，針對Application和Activity的同步內容進行優化，將核心內容頁面儘快渲染返回給使用者，使用非同步任務載入耗時和非核心頁面內容。安卓具體的api及原理，詳見官網描述https://developer.android.goo...
2)服務端問題
通過監控，我們發現個別後端服務GC（Garbage Collection）頻繁，隔一段時間就會導致Stop the World，引發耗時波動。我們通過對關鍵程式碼路徑進行監控，結合記憶體使用情況等進行專項整治，發現問題主要是應用內的本地快取使用不當導致，大量的臨時快取擠佔記憶體引發了應用波動。
專案總結
在應用U-APM、豐富監控及程式碼質量提升後，該安卓APP的後期表現漸佳，使用者的啟動慢的吐槽量已經大幅減少。總的來說，安卓APP啟動慢主要有兩方面原因，一是APP自身在手機端的程式碼設計不夠合理，常見的問題在官網均勻最佳實踐https://developer.android.goo...；二是APP訪問的後臺服務質量存在優化空間。
針對安卓應用端的優化，Google也有許多實踐案例，比如
PLAY ALL
Android Performance Patterns
個人簡介：
麼廣忠，開源技術愛好者，全棧研發工程師，參與過多個開源專案並主導過多款APP設計開發。