前言成為一名優秀的Android開發，需要一份完備的知識體系，在這裡，讓我們一起成長為自己所想的那樣~。

眾所周知，移動開發已經來到了後半場，為了能夠在眾多開發者中脫穎而出，我們需要對某一個領域有深入地研究與心得，對於Android開發者來說，目前，有幾個好的細分領域值得我們去建立自己的技術壁壘，如下所示：

1、效能最佳化專家：具備深度效能最佳化與體系化APM建設的能力。2、架構師：具有豐富的應用架構設計經驗與心得，對Android Framework層與熱門三方庫的實現原理與架構設計瞭如指掌。3、音影片/影象處理專家：毫無疑問，掌握NDK，深入音影片與影象處理領域能讓我們在未來幾年大放異彩。4、大前端專家：深入掌握Flutter及其設計原理與思想，可以讓我們具有快速學習前端知識的能力。

在上述幾個細分領域中，最難也最具技術壁壘的莫過於效能最佳化，要想成為一個頂尖的效能最佳化專家，需要對許多領域的深度知識及廣度知識有深入的瞭解與研究，其中不乏需要掌握架構師、NDK、Flutter所涉及的眾多技能。從這篇文章開始，筆者將會帶領大家一步一步深入探索Android的效能最佳化。

為了能夠全面地瞭解Android的效能最佳化知識體系，我們先看看我總結的下面思維導圖大綱，如下所示：

在建設APM和對App進行效能最佳化的過程中，我們必須首先解決的是App的穩定性問題，現在，讓我們搭乘航班，來深入探索Android穩定性最佳化的疆域。

一、正確認識

首先，我們必須對App的穩定性有正確的認識，它是App質量構建體系中最基本和最關鍵的一環。如果我們的App不穩定，並且經常不能正常地提供服務，那麼使用者大機率會解除安裝掉它。所以穩定性很重要，並且Crash是P0優先順序，需要優先解決。 而且，穩定性可最佳化的面很廣，它不僅僅只包含Crash這一部分，也包括卡頓、耗電等最佳化範疇。

1、穩定性緯度

應用的穩定性可以分為三個緯度，如下所示：

1、Crash緯度：最重要的指標就是應用的Crash率。2、效能緯度：包括啟動速度、記憶體、繪製等等最佳化方向，相對於Crash來說是次要的，在做應用效能體系化建設之前，我們必須要確保應用的功能穩定可用。3、業務高可用緯度：它是非常關鍵的一步，我們需要採用多種手段來保證我們App的主流程以及核心路徑的穩定性，只有使用者經常使用我們的App，它才有可能發現別的方面的問題。2、穩定性最佳化注意事項

我們在做應用的穩定性最佳化的時候，需要注意三個要點，如下所示：

1、重在預防、監控必不可少

對於穩定性來說，如果App已經到了線上才發現異常，那其實已經造成了損失，所以，對於穩定性的最佳化，其重點在於預防。從開發同學的編碼環節，到測試同學的測試環節，以及到上線前的釋出環節、上線後的運維環節，這些環節都需要來預防異常情況的發生。如果異常真的發生了，也需要將想方設法將損失降到最低，爭取用最小的代價來暴露儘可能多的問題。

此外，監控也是必不可少的一步，預防做的再好，到了線上，總會有各種各樣的異常發生。所以，無論如何，我們都需要有全面的監控手段來更加靈敏地發現問題。

2、思考更深一層、重視隱含資訊：如解決Crash問題時思考是否會引發同一類問題

當我們看到了一個Crash的時候，不能簡單地只處理這一個Crash，而是需要思考更深一層，要考慮會不會在其它地方會有一樣的Crash型別發生。如果有這樣的情況，我們必須對其統一處理和預防。

此外，我們還要關注Crash相關的隱含資訊，比如，在面試過程當中，面試官問你，你們應用的Crash率是多少，這個問題表明上問的是Crash率，但是實際上它是問你一些隱含資訊的，過高的Crash率就代表開發人員的水平不行，leader的架構能力不行，專案的各個階段中最佳化的空間非常大，這樣一來，面試官對你的印象和評價也不會好。

3、長效保持需要科學流程

應用穩定性的建設過程是一個細活，所以很容易出現這個版本最佳化好了，但是在接下來的版本中如果我們不管它，它就會發生持續惡化的情況，因此，我們必須從專案研發的每一個流程入手，建立科學完善的相關規範，才能保證長效的最佳化效果。

3、Crash相關指標

要對應用的穩定性進行最佳化，我們就必須先了解與Crash相關的一些指標。

1、UV、PVPV（Page View）：訪問量UV（Unique Visitor）：獨立訪客，0 - 24小時內的同一終端只計算一次2、UV、PV、啟動、增量、存量 Crash率UV Crash率（Crash UV / DAU）：針對使用者使用量的統計，統計一段時間內所有使用者發生崩潰的佔比，用於評估Crash率的影響範圍，結合PV。需要注意的是，需要確保一直使用同一種衡量方式。PV Crash率：評估相關Crash影響的嚴重程度。啟動Crash率：啟動階段，使用者還沒有完全開啟App而發生的Crash，它是影響最嚴重的Crash，對使用者傷害最大，無法透過熱修復拯救，需結合客戶端容災，以進行App的自主修復。（這塊後面會講）增量、存量Crash率：增量Crash是指的新增的Crash，而存量Crash則表示一些歷史遺留bug。增量Crash是新版本重點，存量Crash是需要持續啃的硬骨頭，我們需要優先解決增量、持續跟進存量問題。4、Crash率評價

那麼，我們App的Crash率降低多少才能算是一個正常水平或優秀的水平呢？

Java與Native的總崩潰率必須在千分之二以下。Crash率萬分位為優秀：需要注意90%的Crash都是比較容易解決的，但是要解決最後的10%需要付出巨大的努力。5、Crash關鍵問題

這裡我們還需要關注Crash相關的關鍵問題，如果應用發生了Crash，我們應該儘可能還原Crash現場。因此，我們需要全面地採集應用發生Crash時的相關資訊，如下所示：

堆疊、裝置、OS版本、程序、執行緒名、Logcat前後臺、使用時長、App版本、小版本、渠道CPU架構、記憶體資訊、執行緒數、資源包資訊、使用者行為日誌

接著，採集完上述資訊並上報到後臺後，我們會在APM後臺進行聚合展示，具體的展示資訊如下所示：

Crash現場資訊Crash Top機型、OS版本、分佈版本、區域Crash起始版本、上報趨勢、是否新增、持續、量級

最後，我們可以根據以上資訊決定Crash是否需要立馬解決以及在哪個版本進行解決，關於APM聚合展示這塊可以參考 Bugly平臺 的APM後臺聚合展示。

然後，我們再來看看與Crash相關的整體架構。

6、APM Crash部分整體架構

APM Crash部分的整體架構從上至下分為採集層、處理層、展示層、報警層。下面，我們來詳細講解一下每一層所做的處理。

1）、採集層

首先，我們需要在採集層這一層去獲取足夠多的Crash相關資訊，以確保能夠精確定位到問題。需要採集的資訊主要為如下幾種：

錯誤堆疊裝置資訊行為日誌其它資訊2）、處理層

然後，在處理層，我們會對App採集到的資料進行處理。

資料清洗：將一些不符合條件的資料過濾掉，比如說，因為一些特殊情況，一些App採集到的資料不完整，或者由於上傳資料失敗而導致的資料不完整，這些資料在APM平臺上肯定是無法全面地展示的，所以，首先我們需要把這些資訊進行過濾。資料聚合：在這一層，我們會把Crash相關的資料進行聚合。緯度分類：如Top機型下的Crash、使用者Crash率的前10%等等維度。趨勢對比3）、展示層

經過處理層之後，就會來到展示層，展示的資訊為如下幾類：

資料還原緯度資訊起始版本其它資訊4）、報警層

最後，就會來到報警層，當發生嚴重異常的時候，會通知相關的同學進行緊急處理。報警的規則我們可以自定義，例如整體的Crash率，其環比（與上一期進行對比）或同比（如本月10號與上月10號）抖動超過5%，或者是單個Crash突然間激增。報警的方式可以透過 郵件、IM、電話、簡訊 等等方式。

7、責任歸屬

最後，我們來看下Crash相關的非技術問題，需要注意的是，我們要解決的是如何長期保持較低的Crash率這個問題。我們需要保證能夠迅速找到相關bug的相關責任人並讓開發同學能夠及時地處理線上的bug。具體的解決方法為如下幾種：

設立專項小組輪值：成立一個虛擬的專項小組，來專門跟蹤每個版本線上的Crash率，組內的成員可以輪流跟蹤線上的Crash，這樣，就可以從源頭來保證所有Crash一定會有人跟進。自動匹配責任人：將APM平臺與bug單系統打通，這樣APM後臺一旦發現緊急bug就能第一時間下發到bug單系統給相關責任人發提醒。處理流程全紀錄：我們需要記錄Crash處理流程的每一步，確保緊急Crash的處理不會被延誤。

這次就先分享到這裡，我也同大家分享一下我自己平時閒暇還會反覆翻閱的精品資料。裡面對近幾年的大廠面試高頻知識點都有詳細的講解。相信可以有效地幫助大家掌握知識、理解原理