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