從1月10號第一篇文章開始，到現在過去了4個月又20天，陸續寫下了效能優化系列文章共計十二篇，大概一個月三篇的節奏。本篇文章是效能系列文章的最後一篇，沒有新的大方向優化，講一下寫效能優化系列文章的些許事情：初心，過程，所得。
1、 初心
1.1 為什麼要做全方位、深入的效能優化？
故事發生在去年年底：某版本上線前當我開啟App，唯一的體驗就是那如同烏龜爬行般的啟動速度。不僅被競品碾壓，更是碾壓了我的技術榮辱心：自己做出的App表現差，就是自己差！這是我下定決心要對專案做效能優化的起因。
1.2 為什麼寫系列文章？
既然要實踐效能優化，而我自己也有知識整理的習慣，那麼寫系列文章自然是水到渠成，順便是對自己的一個督促。但還有一個原因：
- 翻閱各種資料，我發現，官方文件作為效能優化過程中最佳的參考資料，而國內開發者的翻譯水平不敢過於恭維以及很多開發者關注的角度不一，導致很少有優秀並且全面的參考文章。
那既然我要做效能優化，就挑戰下這個優秀且全面。也留下好的參考文章給後來的人！
2、 過程
2.1 效能優化不是溫馨的請客吃飯
效能優化的過程是一個非常困難的過程，需要你對優化的方向不僅有知識上的充足儲備還要有對現存業務上的瞭解。拿第一篇App啟動優化來舉例：
- 檢視官方文件對啟動優化的概述；
- 梳理App啟動的邏輯；
- 使用工具對啟動邏輯程式碼進行準確的度量；
- 針對瓶頸確定優化方案；
- 優化、測試。
難點在於中間三步：
- App多人開發，又歷經多個版本，沒人說得清App啟動有多少邏輯以及補償邏輯；
- 不同風格的程式碼讀起來，那感覺絕對是一個酸爽；
- 確認了問題點，如何優化？重構還是重做？
而整理文章的過程更是難上加難，釋出出來文章就是自己的一種承諾，既要具備專業性、又要通俗易懂；既要有深度，優化的招數又要儘可能的全面。因此查文件、翻原始碼是家常便飯。而平時工作也較忙，因此對於一個月三篇的節奏我甚至覺得有點高產（捂臉）。
2.2 對優化，其實你只是一知半解
談到效能優化，相信各位開發Android的老司機和新司機，都能說上幾句。而在面試過程中效能優化也是必問的姿勢。但人人都能說幾句並不代表對效能優化的理解有多少，不信看幾個問題：
- Android的記憶體管理在Dalvik和ART上有什麼區別？通過adb獲取記憶體資訊時，哪個值是真正可回收的記憶體佔用量？
- 如何計算資源圖片所佔的記憶體？
- 執行緒的優先順序和程式有關嗎？
相信不少司機肯定說不全，但這條估計要讓崇尚“背誦記憶準則”的小夥伴們笑了：我不理解原理，但也能說出幾條優化的規則，你安能說我不懂效能優化？誠然效能優化有很多經驗、準則可以參考借鑑，但是效能優化卻不應該是背誦記憶的機械動作。如果不理解原理，對效能優化的認識、理解不足，任何場景都拿統一的套路生搬硬套，那優化的深度、全面性、適用性一定會大打折扣。
3、 所得
那麼在這個並不輕鬆的效能優化過程中，我得到了什麼？
3.1 對產品業務的熟悉
效能優化看似是個純技術的事情，但是實際上和業務密不可分，畢竟任何技術都是在具體的業務場景下實踐應用。因此不熟悉模組業務、具體實現而生搬硬套的話，效能優化工作往往無從下手。
3.2 對效能優化的深入理解
效能優化不是一塊孤立的知識，對效能優化的深入理解需要方方面面的技術為輔助，此處仍然以第一篇啟動優化為例。
- 應用啟動分類及過程；
- 啟動優化方式；
- Heavy app initialization（包含執行緒使用、網路請求、IO、佈局巢狀等）。
尤其是第三點：每一項都有可能導致效能的瓶頸，而每一項都可以展開闡述，這個過程使你的技術能力得以強化。
3.3 知識整理和文件能力
大多數情況下，我們都不創造知識而只是知識的搬運工，一般做的就是對知識的蒐集和整合。那對我們決勝就是快速的汲取知識以及完成對知識的判斷及整合，知道什麼地方會有權威、靠譜的資料，判斷知識的使用場景等。
而寫文章過程中的各種痛苦也不是無用功，經歷過不知道怎麼寫文章的窘迫，才會知道怎麼確定文章主題、主線、豐富文章，才會鍛鍊到自己的表達能力、文字組織能力。
4、 其它
4.1 為什麼要重視效能優化？
- 效能優化的學習與實踐是技術人員成長進步的一條途徑，同時也是改善程式碼質量的一次機會。
- 伴隨著App功能的增多，效能問題隨之而來，不誇張的說任何App都有效能問題，只是程度不同。任由效能問題存在卻視而不見最終一點會有集中式的爆發，那後果不僅僅是技術上的失責，更會影響產品及使用者。
- 效能優化的過程本身也是一個精益求精的過程，代表了你對程式碼的重視，對高質量應用的追求。
4.2 效能優化有哪些好的資料推薦？
- Android效能優化典範，官方推出，必屬精品。不僅僅告訴你哪裡有問題，更告訴你為什麼！
- 胡凱的部落格，翻譯了關於Android效能優化典範的內容，不想看視訊的話可以參考部落格。不過官方的典範及翻譯都是偏理論性，需要自己去實踐。
- 官方文件，不管是Training模組還是API模組，都藏了很多幹貨。
- 《移動App效能評測與優化》，騰訊TMQ專項測試團隊的大作，深入底層，追本溯源，精益求精，帶給人技術上提升的同時更端正做技術的態度，強烈推薦！
4.3 對效能優化，平時怎麼做？
四個字：防微杜漸。很多效能方面的問題都不是一朝一夕產生的，例如OOM，導致OOM發生的程式碼可能只是壓死駱駝的最後一根稻草，前面很多地方已經埋下了隱患，只等最後一個地方點燃。還有很多程式碼本身並沒有錯，確實實現了功能，但是放錯了位置。
模組開發之前最好對技術方案進行評審，從實現上（源頭）儘早規避低效能的實現方式；最好在功能完成之後，使用工具進行效能的分析，進行鍼對性的優化。
4.4 其它
- 優化完成之後務必充分測試，否則雖然效能是高了但是出現Bug也是不能接受的；
- 推薦大家寫部落格，或者整理、總結也好；
- 不忘初心，方得始終。
歡迎關注微信公眾號：定期分享Java、Android乾貨！
