關注公號：阿風的架構筆記 第一時間閱讀
前言
現在都在談效能優化或者在面試的時候被問到效能優化相關問題，那麼我們為什麼要做效能優化呢？以及效能優化的難點是什麼？在整個專案週期中不同的階段該做什麼？優化效果如何長期保持？作為一名Android高階工程師或者架構師，我們看待問題的角度不能單一而是要學會從多個維度來仔細考量 ，這樣才能更全面的認識以及解決問題！下文會從多個視角來學習效能優化工作當中 我們可能會遇到哪些難題！
效能優化有哪些難題
難點一：效能表現差
效能優化的第一個難題是APP的自身效能表現差，這是從APP自身效能使用來說的：
- 第一種問題是使用者可以直觀的感受到，比如說：APP啟動慢、卡頓、丟楨等，使用者肯定會報怨手機太卡了！
- 第二種問題是使用者雖然不會直觀的感受到，比如說：記憶體佔用高，抖動頻繁，但是這種隱藏的問題可能會導致記憶體溢位，從而影響程式的正常執行
- 此外效能問題還有應用耗電、網路請求慢、崩潰率和異常率高
其中崩潰率和異常率屬於穩定性的範疇，崩潰率比較好理解需要注意的是應用異常率。異常是指APP不能正常的作出反應，比如說我們點選了一個按鈕，它並沒有正確的跳轉到下一個介面，此時APP並沒有崩潰，但是同樣它也處於不可用的狀態，帶來的非常不好的使用者體驗。
難點二：線上問題無法排查
線上問題排查困難對於很多Android程式設計師來說就是個燒（tuo）腦（fa）的問題，下面來說說線上問題排查的主要難點！
效能優化的第一個難題是線上問題無從排查，這是從排查問題的視角來說， 通俗來講的是耽誤線上出現了異常時我們如何才能夠保證較高的異常感知靈敏度。
當我們釋出了一個新版本或者上線了一個新功能沒有使用者反饋，我們也千萬不能夠認為已經成功上線了，因為僅僅依賴於使用者反饋這個單一的渠道非常容易錯過異常出現的第一時間，等到有使用者不堪忍受來反饋造成的損失已經太大，而且也已經錯過最好的處理時機。
線上問題排查的第二個難點：如何復原案發現場， 假設使用者給了我們反饋但是此刻我們也不能夠高興過早。因為使用者有反饋不代表我們一定能夠復現，很多問題並不是所有使用者都會發生，發生了這種特殊問題的使用者，他可能是使用了特殊的裝置或者是他的賬戶處於特定的異常狀態。等到我們在公司用自己的裝置和自己的賬戶去復現他的問題的時候很有可能會因為條件不足而無法復現，自然也就沒有辦法快速解決。
線上問題的第三個難點：如何快速修復成功， 針對線上問題而言時間就是生命必須儘早的成功修復。在我們修復之後，為了保險起見一般都會開放部分小流量使用者或者找特定使用者來進行測試。但是如果說我們的手段是連續使用者重新安裝然後等待結果，這樣的解決方案它的週期實在是太長，而且多次下來後使用者也會有些反感，最終可能找不到配合你要使用者。
難點三：效能優化的長期開銷大
效能優化的第三個難題是效能優化的長期開銷大，這是從團隊管理者的視角來說。如果我們在每個版本當中都需要花費大量的精力來跟蹤關於效能的問題，長期來看說團隊的資源消耗非常大，團隊的產出的也就變少，於是我們就要思考如何才能將問題扼殺在萌芽之中，儘可能的在上線之前將問題解決。
效能優化的長期開銷大難點在於效能優化的效果不能夠得到長期的保持，我們優化完成了之後的程式，如果沒有措施那麼很可能在接下來的版本當中會再次到了破壞，出現效能問題還是需要我們優化 ，這樣長期的重複肯定會導致開銷變大。
總結
通過上文所說效能優化工作當中遇到難題，我們反推也很容易總結出來我們對效能工作優化的要求指標：
- 效能表現好
- 線上問題容易排查
- 長期投入成本小
看完三件事❤️
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
- 點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。
- 關注公眾號 『 阿風的架構筆記 』，不定期分享原創知識。
- 同時可以期待後續文章ing?
- 關注後回覆【666】掃碼即可獲取架構進階學習資料包