前言
現在都在談性能優化或者在面試的時候被問到性能優化相關問題，那麼我們為什麼要做性能優化呢？以及性能優化的難點是什麼？在整個項目周期中不同的階段該做什麼？優化效果如何長期保持？作為一名Android進階工程師或者架構師，我們看待問題的角度不能單一而是要學會從多個次元來仔細考量 ，這樣才能更全面的認識以及解決問題！下文會從多個視角來學習性能優化工作當中 我們可能會遇到哪些難題！
性能優化有哪些難題
性能優化的第一個難題是APP的自身性能表現差，這是從APP自身性能使用來說的：
第一種問題是使用者可以直覺的感受到，比如說：APP啟動慢、卡頓、丢桢等，使用者肯定會報怨手機太卡了！
第二種問題是使用者雖然不會直覺的感受到，比如說：記憶體占用高，抖動頻繁，但是這種隐藏的問題可能會導緻記憶體溢出，進而影響程式的正常運作
此外性能問題還有應用耗電、網絡請求慢、崩潰率和異常率高
其中崩潰率和異常率屬于穩定性的範疇，崩潰率比較好了解需要注意的是應用異常率。異常是指APP不能正常的作出反應，比如說我們點選了一個按鈕，它并沒有正确的跳轉到下一個界面，此時APP并沒有崩潰，但是同樣它也處于不可用的狀态，帶來的非常不好的使用者體驗。
線上問題排查困難對于很多Android程式員來說就是個燒（tuo）腦（fa）的問題，下面來說說線上問題排查的主要難點！
性能優化的第一個難題是線上問題無從排查，這是從排查問題的視角來說， 通俗來講的是耽誤線上出現了異常時我們如何才能夠保證較高的異常感覺靈敏度。
當我們釋出了一個新版本或者上線了一個新功能沒有使用者回報，我們也千萬不能夠認為已經成功上線了，因為僅僅依賴于使用者回報這個單一的管道非常容易錯過異常出現的第一時間，等到有使用者不堪忍受來回報造成的損失已經太大，而且也已經錯過最好的處理時機。
線上問題排查的第二個難點：如何複原案發現場， 假設使用者給了我們回報但是此刻我們也不能夠高興過早。因為使用者有回報不代表我們一定能夠複現，很多問題并不是所有使用者都會發生，發生了這種特殊問題的使用者，他可能是使用了特殊的裝置或者是他的賬戶處于特定的異常狀态。等到我們在公司用自己的裝置和自己的賬戶去複現他的問題的時候很有可能會因為條件不足而無法複現，自然也就沒有辦法快速解決。
線上問題的第三個難點：如何快速修複成功， 針對線上問題而言時間就是生命必須盡早的成功修複。在我們修複之後，為了保險起見一般都會開放部分小流量使用者或者找特定使用者來進行測試。但是如果說我們的手段是連續使用者重新安裝然後等待結果，這樣的解決方案它的周期實在是太長，而且多次下來後使用者也會有些反感，最終可能找不到配合你要使用者。
性能優化的第三個難題是性能優化的長期開銷大，這是從團隊管理者的視角來說。如果我們在每個版本當中都需要花費大量的精力來跟蹤關于性能的問題，長期來看說團隊的資源消耗非常大，團隊的産出的也就變少，于是我們就要思考如何才能将問題扼殺在萌芽之中，盡可能的在上線之前将問題解決。
性能優化的長期開銷大難點在于性能優化的效果不能夠得到長期的保持，我們優化完成了之後的程式，如果沒有措施那麼很可能在接下來的版本當中會再次到了破壞，出現性能問題還是需要我們優化 ，這樣長期的重複肯定會導緻開銷變大。
總結
通過上文所說性能優化工作當中遇到難題，我們反推也很容易總結出來我們對性能工作優化的要求名額：
性能表現好
線上問題容易排查
長期投入成本小