Android 性能優化（十二）之我爲何寫性能優化

從1月10號第一篇文章開始，到如今過去了4個月又20天，陸續寫下了性能優化系列文章共計十二篇，大概一個月三篇的節奏。本篇文章是性能系列文章的最後一篇，沒有新的大方向優化，講一下寫性能優化系列文章的些許事情：初心，過程，所得。

一、 初心

1.1 爲何要作全方位、深刻的性能優化？

故事發生在去年年末：某版本上線前當我打開App，惟一的體驗就是那如同烏龜爬行般的啓動速度。不只被競品碾壓，更是碾壓了個人技術榮辱心：本身作出的App表現差，就是本身差！這是我下定決心要對項目作性能優化的原由。

1.2 爲何寫系列文章？

既然要實踐性能優化，而我本身也有知識整理的習慣，那麼寫系列文章天然是水到渠成，順即是對本身的一個督促。但還有一個緣由：

• 翻閱各類資料，我發現，官方文檔做爲性能優化過程當中最佳的參考資料，而國內開發者的翻譯水平不敢過於恭維以及不少開發者關注的角度不一，致使不多有優秀而且全面的參考文章。

那既然我要作性能優化，就挑戰下這個優秀且全面。也留下好的參考文章給後來的人！

二、 過程

2.1 性能優化不是舒適的請客吃飯

性能優化的過程是一個很是困難的過程，須要你對優化的方向不只有知識上的充足儲備還要有對現存業務上的瞭解。拿第一篇App啓動優化來舉例：

1. 查看官方文檔對啓動優化的概述；
2. 梳理App啓動的邏輯；
3. 使用工具對啓動邏輯代碼進行準確的度量；
4. 針對瓶頸肯定優化方案；
5. 優化、測試。

難點在於中間三步：

• App多人開發，又歷經多個版本，沒人說得清App啓動有多少邏輯以及補償邏輯；
• 不一樣風格的代碼讀起來，那感受絕對是一個酸爽；
• 確認了問題點，如何優化？重構仍是重作？

而整理文章的過程更是難上加難，發佈出來文章就是本身的一種承諾，既要具有專業性、又要通俗易懂；既要有深度，優化的招數又要儘量的全面。所以查文檔、翻源碼是屢見不鮮。而平時工做也較忙，所以對於一個月三篇的節奏我甚至以爲有點高產（捂臉）。

2.2 對優化，其實你只是只知其一;不知其二

談到性能優化，相信各位開發Android的老司機和新司機，都能說上幾句。而在面試過程當中性能優化也是必問的姿式。但人人都能說幾句並不表明對性能優化的理解有多少，不信看幾個問題：

1. Android的內存管理在Dalvik和ART上有什麼區別？經過adb獲取內存信息時，哪一個值是真正可回收的內存佔用量？
2. 如何計算資源圖片所佔的內存？
3. 線程的優先級和進程有關嗎？

相信很多司機確定說不全，但這條估計要讓崇尚「背誦記憶準則」的小夥伴們笑了：我不理解原理，但也能說出幾條優化的規則，你安能說我不懂性能優化？誠然性能優化有不少經驗、準則能夠參考借鑑，可是性能優化卻不該該是背誦記憶的機械動做。若是不理解原理，對性能優化的認識、理解不足，任何場景都拿統一的套路生搬硬套，那優化的深度、全面性、適用性必定會大打折扣。

三、 所得

那麼在這個並不輕鬆的性能優化過程當中，我獲得了什麼？

3.1 對產品業務的熟悉

性能優化看似是個純技術的事情，可是實際上和業務密不可分，畢竟任何技術都是在具體的業務場景下實踐應用。所以不熟悉模塊業務、具體實現而生搬硬套的話，性能優化工做每每無從下手。

3.2 對性能優化的深刻理解

性能優化不是一塊孤立的知識，對性能優化的深刻理解須要方方面面的技術爲輔助，此處仍然以第一篇啓動優化爲例。

• 應用啓動分類及過程；
• 啓動優化方式；
• Heavy app initialization（包含線程使用、網絡請求、IO、佈局嵌套等）。

尤爲是第三點：每一項都有可能致使性能的瓶頸，而每一項均可以展開闡述，這個過程使你的技術能力得以強化。

3.3 知識整理和文檔能力

大多數狀況下，咱們都不創造知識而只是知識的搬運工，通常作的就是對知識的蒐集和整合。那對咱們決勝就是快速的汲取知識以及完成對知識的判斷及整合，知道什麼地方會有權威、靠譜的資料，判斷知識的使用場景等。

而寫文章過程當中的各類痛苦也不是無用功，經歷過不知道怎麼寫文章的窘迫，纔會知道怎麼肯定文章主題、主線、豐富文章，纔會鍛鍊到本身的表達能力、文字組織能力。

四、 其它

4.1 爲何要重視性能優化？

• 性能優化的學習與實踐是技術人員成長進步的一條途徑，同時也是改善代碼質量的一次機會。
• 伴隨着App功能的增多，性能問題隨之而來，不誇張的說任何App都有性能問題，只是程度不一樣。任由性能問題存在卻視而不見最終一點會有集中式的爆發，那後果不只僅是技術上的失責，更會影響產品及用戶。
• 性能優化的過程自己也是一個精益求精的過程，表明了你對代碼的重視，對高質量應用的追求。

4.2 性能優化有哪些好的資料推薦？

1. Android性能優化典範，官方推出，必屬精品。不只僅告訴你哪裏有問題，更告訴你爲何！
2. 胡凱的博客，翻譯了關於Android性能優化典範的內容，不想看視頻的話能夠參考博客。不過官方的典範及翻譯都是偏理論性，須要本身去實踐。
3. 官方文檔，不論是Training模塊仍是API模塊，都藏了不少乾貨。
4. 《移動App性能評測與優化》，騰訊TMQ專項測試團隊的大做，深刻底層，追本溯源，精益求精，帶給人技術上提高的同時更端正作技術的態度，強烈推薦！

4.3 對性能優化，平時怎麼作？

四個字：防微杜漸。不少性能方面的問題都不是一朝一夕產生的，例如OOM，致使OOM發生的代碼可能只是壓死駱駝的最後一根稻草，前面不少地方已經埋下了隱患，只等最後一個地方點燃。還有不少代碼自己並無錯，確實實現了功能，可是放錯了位置。

模塊開發以前最好對技術方案進行評審，從實現上（源頭）儘早規避低性能的實現方式；最好在功能完成以後，使用工具進行性能的分析，進行鍼對性的優化。

4.4 其它

• 優化完成以後務必充分測試，不然雖然性能是高了可是出現Bug也是不能接受的；
• 推薦你們寫博客，或者整理、總結也好；
• 不忘初心，方得始終。

歡迎關注微信公衆號：按期分享Java、Android乾貨！

歡迎關注