內容來源：極客時間「Android開發高手課」
作者；張紹文
今年年初，我去上海蔘加一個移動技術會議，問了很多開發者最近在忙啥。令我非常驚訝的是，大家講的最多的還是用戶體驗和應用質量。特別是出海東南亞的同學，面對一堆512MB內存的設備、無處不在的弱網絡流下了無助的眼淚。
除了內存優化、弱網絡優化，想做一款高質量的應用還遠遠不止這些。一方面，我們面對的環境越來越複雜。過去的iOS開發者可能做夢也想不到，現在也要開始適配屏幕和雙卡雙待了，更不用說Android那多如繁星的機型、廠家和系統。如果你的應用也要出海，那麼還要面對幾十個國家不同的語言、環境。
另一方面，我們的代碼跟業務也越來越複雜了。先不說大量“年久失修”的歷史代碼，業務越來越複雜，如何管理好幾十上百個模塊？還要面對React Native、Flutter、TensorFlow等各種語言跟框架堆積在一起的情況，再加上覆雜的環境和龐大的系統，想想做一款高質量的應用真的不容易。
從應用交付的流程說起
既然打造一款高質量的應用那麼困難，我們可以先從哪裏入手做些什麼呢？我的方法是把應用當成一件商品，想象一下商品在流水線生產的過程，那麼怎樣在每個步驟做好“質檢”呢？這就要從應用交付的流程說起。
在我看來，一個應用至少會經過開發、編譯CI、測試、灰度和發佈這幾個階段。每個階段需要關注什麼問題呢？
-
開發階段。在面試的時候，常常有人說自己熟練掌握各種開發工具。但是，我們真的懂嗎？就拿我們比較熟悉的耗時分析工具Traceview來說，它背後的實現原理是什麼？能不能做一個完全沒有性能損耗的Traceview？或者怎麼樣將它移植到線上使用？
-
編譯CI階段。如何防止代碼不斷地惡化？怎樣進一步優化性能？d8與ReDex有什麼神奇的黑科技？如何利用好Coverity、Infer這些靜態分析工具？這部分可能需要一些編譯原理的知識，你會發現移動開發也有很多值得深入研究的東西。
-
測試階段。我們常說敏捷開發，用戶是最好的測試。遇到問題在線上反覆試錯，對自己、對用戶都十分痛苦。我們希望可以做到測試“左移”，儘可能早地發現問題。但是很多時候我們不是不想測試，而是發現測不出什麼問題。那麼怎樣提升實驗室發現問題的能力呢？如何儘可能地模擬用戶的操作路徑？做好測試並不容易，自動化測試結合AI或許可以幫助我們解決一些痛點。
-
灰度和發佈階段。動態部署流行起來之後，很多開發變得鬆懈起來。有問題發補丁，一個不行就兩個，兩個不行就十個。怎樣去保證產品質量？很多線上問題概率很低，基本很難復現，比如對於一個印度的用戶，我們希望有一個遠程的聽診器，而不需要把用戶拉到我們的手術檯上。
對照應用的交付流程，我來介紹一下專欄的學習方法。專欄“高質量開發”模塊主要對應的是開發階段，你可以帶着實踐過程的困惑去深入學習開發需要的各種武器。專欄“高效開發”模塊主要對應編譯CI、測試、灰度和發佈階段，你可以結合實際工作全面提升整個應用交付的效率。另外，我認爲一個好的架構可以減少甚至避免團隊出錯，也是打造一款高質量應用非常重要的一環，因此我會在最後的“架構演進”模塊和你聊聊如何設計一個好的架構，以及架構該如何選型。
移動APM質量平臺
請你思考一下，在應用交付的這幾個階段中，我們對高質量的目標和實現方式是否一樣呢？開發階段有開發人員，可能希望採集儘可能多的數據；測試階段有測試人員，可能更針對實驗室環境或與競品對比進行測試；灰度和發佈階段可能也有專門的運維人員，策略會相對保守一些。很明顯，不同階段我們對高質量的目標跟手段可能不太一樣。
一個公司有多套質量系統，這在大公司是非常普遍的現象。我們希望有一個統一的平臺，整合應用的人員和開發流程，這就是我們常說APM質量平臺。
APM的全稱是“Application Performance Management”，即應用性能管理。據我瞭解，國內像阿里、騰訊、美團點評、餓了麼、愛奇藝這些公司都在大力投入。Google今年也發力Android Vitals監控，新增了耗電、權限管理模塊。那麼APM質量平臺究竟有着什麼樣的魅力呢？
-
統一管理。A同學寫了一個耗時監控工具，B同學寫了一個內存監控工具，它們在不同的倉庫，上報格式可能不太一樣，各自都搭了一個簡單的頁面。如果想評估一個應用的質量，總是要去幾個系統彙總數據，想想都費勁。
-
統一三端。一個公司可能有多個應用，一個應用也可能有H5、iOS、Android多個端。我們希望它們只是採集數據方式有所不同，上報、後臺分析、展示、報警都是共用的。隨着技術的發展，我們可能會增加React Native、Flutter這些新模塊的監控，這個平臺應該是統一演進的。當然我們非常希望業界有一套開源的方案，大家可以一起優化。
那這個質量平臺需要關注哪些問題呢？這需要看我們用戶關心什麼問題。有的問題可能是致命的，像崩潰、卡死、白屏。另一大類問題就是性能問題，安裝包大小、啓動、耗時、內存、耗電、流量都是這一個範疇。在這個專欄裏，我並不會教你如何從頭搭建一個APM平臺，我會更期待你掌握背後所需要的知識，它們主要包括：
由於Android版本的碎片化和國內Android生態的亂象，“Android開發者很苦，國內的Android開發者更苦”。11月16日，第一屆安卓綠色聯盟開發者大會在北京召開，會議上推出了應用體驗標準V2.0，裏面也對應用的兼容性、穩定性、性能、功能和安全做了詳細的定義。
在極致性能的同時，我們希望能更進一步地打造“綠色應用”。在這個過程中，一個全面而強大的APM質量平臺會是我們堅實的後盾。當然對於大多數中小開發者來說，我們更建議選擇成熟的第三方服務。但深入瞭解它們背後的原理，無論是對我們如何選擇合適的服務，還是日常開發工作都會有很大的幫助。在學習完上面的這些內容之後，你也會覺得其實“性能優化”並不是那麼“高不可攀”，我們也可以慢慢地邁向“性能優化專家”之路。
不過我們需要明確一點，雖然移動APM質量平臺可以幫助我們快速發現和定位問題，但是監控並不能保證實現高質量，這裏最關鍵的永遠是人，而不是系統。爲什麼呢？我舉兩個小例子。
你在工作中可能總能遇到這樣的場景，我管它叫反饋問題三連擊：“是我的問題嗎？”“能復現嗎？”“你的測試靠譜嗎？”。雖然通過APM質量平臺可以減少推卸責任，但有些人的做法通常還是發現空指針加一個判空，發現併發問題加一個鎖。這裏的空指針真正原因是什麼？這裏判空了後面的邏輯是否還會運行正常？有沒有更加好的方法或架構可以避免這個問題？我們真正應該反問的是這三個問題，把“質量觀”深入骨髓，真正去想要得到個人成長，深挖背後的原因。
第二個例子是，我發現許多人都在問題無法忍受，或者說是老闆無法忍受的時候纔去開啓各種優化專項，但事後又不了了之。我們很多時候都在用戰術的勤奮掩蓋戰略的懶惰，性能優化的關鍵在於如何解決存量問題，同時快速發現增量問題。APM質量平臺只可以協助我們，並不能解決組織內部的心態問題。
總結
看到這裏可能你會有這樣的疑問，我們在小公司根本沒有機會學習到這些東西呀？確實如此，個人與公司一起成長是最快速，也是非常難得的事情，但並不一定人人都會有這樣的機會。從我自己的經驗來看，在搜狗、微信會遇到各種各樣的疑難問題，也可以有很多時間去研究，讓我在解決過程中獲得成長。
幸運的是現在大家都更加樂於去分享，在專欄和技術會議中，我們可以看到很多成熟的解決問題的經驗和思路，在GitHub我們可以找到很多優秀的源代碼。在這個環境下，我們需要耐得住寂寞，多摳一些細節，多深入研究，多停下來總結。
我來分享一個我的故事，2013年初我去面試微信，前面都不太理想，最後還是通過了。後來有一次跟面試官閒聊說起這個事情，他們認爲有一件事情打動了他們。2012年的時候，LeakCanary還沒開源，我在使用MAT做內存泄漏分析的時候總覺得很不爽。爲什麼不能做自動化？爲什麼看不到Bitmap的圖片？我當時深入研究了內存文件Hprof的格式，做了幾個小創新：
-
實現內存的自動化測試。在自動化測試後回到首頁，這個時候獲取應用的內存快照。自動分析內存中Activity實例，正常情況應該只存在一個，其他都認爲是泄漏。爲了支持正式包，還做了通過mapping文件反混淆Hprof文件的功能。
-
查看圖片。自動將內存中重複的圖片、比較大的圖片轉換成PNG格式輸出到文件。
現在看起來這些功能並不是太難，但如果放到六年前，想到而且能做到的人相信並不多。講這個故事還是希望你能在工作和實踐中多停下來思考，多深入研究一些細節，很多看似不經意的思考和創新，可能在日後發揮更大的價值。