如何打造高質量的應用？

內容來源：極客時間「Android開發高手課」

做者；張紹文

今年年初，我去上海蔘加一個移動技術會議，問了不少開發者最近在忙啥。令我很是驚訝的是，你們講的最多的仍是用戶體驗和應用質量。特別是出海東南亞的同窗，面對一堆512MB內存的設備、無處不在的弱網絡流下了無助的眼淚。

除了內存優化、弱網絡優化，想作一款高質量的應用還遠遠不止這些。一方面，咱們面對的環境愈來愈複雜。過去的iOS開發者可能作夢也想不到，如今也要開始適配屏幕和雙卡雙待了，更不用說Android那多如繁星的機型、廠家和系統。若是你的應用也要出海，那麼還要面對幾十個國家不一樣的語言、環境。

另外一方面，咱們的代碼跟業務也愈來愈複雜了。先不說大量「年久失修」的歷史代碼，業務愈來愈複雜，如何管理好幾十上百個模塊？還要面對React Native、Flutter、TensorFlow等各類語言跟框架堆積在一塊兒的狀況，再加上覆雜的環境和龐大的系統，想一想作一款高質量的應用真的不容易。

從應用交付的流程提及

既然打造一款高質量的應用那麼困難，咱們能夠先從哪裏入手作些什麼呢？個人方法是把應用當成一件商品，想象一下商品在流水線生產的過程，那麼怎樣在每一個步驟作好「質檢」呢？這就要從應用交付的流程提及。

在我看來，一個應用至少會通過開發、編譯CI、測試、灰度和發佈這幾個階段。每一個階段須要關注什麼問題呢？

1. 開發階段。在面試的時候，經常有人說本身熟練掌握各類開發工具。可是，咱們真的懂嗎？就拿咱們比較熟悉的耗時分析工具Traceview來講，它背後的實現原理是什麼？能不能作一個徹底沒有性能損耗的Traceview？或者怎麼樣將它移植到線上使用？
   
2. 編譯CI階段。如何防止代碼不斷地惡化？怎樣進一步優化性能？d8與ReDex有什麼神奇的黑科技？如何利用好Coverity、Infer這些靜態分析工具？這部分可能須要一些編譯原理的知識，你會發現移動開發也有不少值得深刻研究的東西。
   
3. 測試階段。咱們常說敏捷開發，用戶是最好的測試。遇到問題在線上反覆試錯，對本身、對用戶都十分痛苦。咱們但願能夠作到測試「左移」，儘量早地發現問題。可是不少時候咱們不是不想測試，而是發現測不出什麼問題。那麼怎樣提高實驗室發現問題的能力呢？如何儘量地模擬用戶的操做路徑？作好測試並不容易，自動化測試結合AI或許能夠幫助咱們解決一些痛點。
   
4. 灰度和發佈階段。動態部署流行起來以後，不少開發變得鬆懈起來。有問題發補丁，一個不行就兩個，兩個不行就十個。怎樣去保證產品質量？不少線上問題機率很低，基本很難復現，好比對於一個印度的用戶，咱們但願有一個遠程的聽診器，而不須要把用戶拉到咱們的手術檯上。
   

對照應用的交付流程，我來介紹一下專欄的學習方法。專欄「高質量開發」模塊主要對應的是開發階段，你能夠帶着實踐過程的困惑去深刻學習開發須要的各類武器。專欄「高效開發」模塊主要對應編譯CI、測試、灰度和發佈階段，你能夠結合實際工做全面提高整個應用交付的效率。另外，我認爲一個好的架構能夠減小甚至避免團隊出錯，也是打造一款高質量應用很是重要的一環，所以我會在最後的「架構演進」模塊和你聊聊如何設計一個好的架構，以及架構該如何選型。

移動APM質量平臺

請你思考一下，在應用交付的這幾個階段中，咱們對高質量的目標和實現方式是否同樣呢？開發階段有開發人員，可能但願採集儘量多的數據；測試階段有測試人員，可能更針對實驗室環境或與競品對比進行測試；灰度和發佈階段可能也有專門的運維人員，策略會相對保守一些。很明顯，不一樣階段咱們對高質量的目標跟手段可能不太同樣。

一個公司有多套質量系統，這在大公司是很是廣泛的現象。咱們但願有一個統一的平臺，整合應用的人員和開發流程，這就是咱們常說APM質量平臺。

APM的全稱是「Application Performance Management」，即應用性能管理。據我瞭解，國內像阿里、騰訊、美團點評、餓了麼、愛奇藝這些公司都在大力投入。Google今年也發力Android Vitals監控，新增了耗電、權限管理模塊。那麼APM質量平臺究竟有着什麼樣的魅力呢？

1. 統一管理。A同窗寫了一個耗時監控工具，B同窗寫了一個內存監控工具，它們在不一樣的倉庫，上報格式可能不太同樣，各自都搭了一個簡單的頁面。若是想評估一個應用的質量，老是要去幾個系統彙總數據，想一想都費勁。
   
2. 統一三端。一個公司可能有多個應用，一個應用也可能有H五、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的格式，作了幾個小創新：

1. 實現內存的自動化測試。在自動化測試後回到首頁，這個時候獲取應用的內存快照。自動分析內存中Activity實例，正常狀況應該只存在一個，其餘都認爲是泄漏。爲了支持正式包，還作了經過mapping文件反混淆Hprof文件的功能。
   
2. 查看圖片。自動將內存中重複的圖片、比較大的圖片轉換成PNG格式輸出到文件。
   

如今看起來這些功能並非太難，但若是放到六年前，想到並且能作到的人相信並很少。講這個故事仍是但願你能在工做和實踐中多停下來思考，多深刻研究一些細節，不少看似不經意的思考和創新，可能在往後發揮更大的價值。

更多內容可看個人專欄「Android開發高手課」，也可加我運營Monica的微信：imonica1010，得到更多技術技能圖譜。