作者：張紹文

今年年初，我去上海參加一個(gè)移動(dòng)技術(shù)會(huì)議，問(wèn)了很多開(kāi)發(fā)者最近在忙啥。令我非常驚訝的是，大家講的最多的還是用戶體驗(yàn)和應(yīng)用質(zhì)量。特別是出海東南亞的同學(xué)，面對(duì)一堆512MB內(nèi)存的設(shè)備、無(wú)處不在的弱網(wǎng)絡(luò)流下了無(wú)助的眼淚。

除了內(nèi)存優(yōu)化、弱網(wǎng)絡(luò)優(yōu)化，想做一款高質(zhì)量的應(yīng)用還遠(yuǎn)遠(yuǎn)不止這些。一方面，我們面對(duì)的環(huán)境越來(lái)越復(fù)雜。過(guò)去的iOS開(kāi)發(fā)者可能做夢(mèng)也想不到，現(xiàn)在也要開(kāi)始適配屏幕和雙卡雙待了，更不用說(shuō)Android那多如繁星的機(jī)型、廠家和系統(tǒng)。如果你的應(yīng)用也要出海，那么還要面對(duì)幾十個(gè)國(guó)家不同的語(yǔ)言、環(huán)境。

另一方面，我們的代碼跟業(yè)務(wù)也越來(lái)越復(fù)雜了。先不說(shuō)大量“年久失修”的歷史代碼，業(yè)務(wù)越來(lái)越復(fù)雜，如何管理好幾十上百個(gè)模塊？還要面對(duì)React Native、Flutter、TensorFlow等各種語(yǔ)言跟框架堆積在一起的情況，再加上復(fù)雜的環(huán)境和龐大的系統(tǒng)，想想做一款高質(zhì)量的應(yīng)用真的不容易。

從應(yīng)用交付的流程說(shuō)起

既然打造一款高質(zhì)量的應(yīng)用那么困難，我們可以先從哪里入手做些什么呢？我的方法是把應(yīng)用當(dāng)成一件商品，想象一下商品在流水線生產(chǎn)的過(guò)程，那么怎樣在每個(gè)步驟做好“質(zhì)檢”呢？這就要從應(yīng)用交付的流程說(shuō)起。

在我看來(lái)，一個(gè)應(yīng)用至少會(huì)經(jīng)過(guò)開(kāi)發(fā)、編譯CI、測(cè)試、灰度和發(fā)布這幾個(gè)階段。每個(gè)階段需要關(guān)注什么問(wèn)題呢？

1、開(kāi)發(fā)階段。在面試的時(shí)候，常常有人說(shuō)自己熟練掌握各種開(kāi)發(fā)工具。但是，我們真的懂嗎？就拿我們比較熟悉的耗時(shí)分析工具Traceview來(lái)說(shuō)，它背后的實(shí)現(xiàn)原理是什么？能不能做一個(gè)完全沒(méi)有性能損耗的Traceview？或者怎么樣將它移植到線上使用？

2、編譯CI階段。如何防止代碼不斷地惡化？怎樣進(jìn)一步優(yōu)化性能？d8與ReDex有什么神奇的黑科技？如何利用好Coverity、Infer這些靜態(tài)分析工具？這部分可能需要一些編譯原理的知識(shí)，你會(huì)發(fā)現(xiàn)移動(dòng)開(kāi)發(fā)也有很多值得深入研究的東西。

3、測(cè)試階段。我們常說(shuō)敏捷開(kāi)發(fā)，用戶是最好的測(cè)試。遇到問(wèn)題在線上反復(fù)試錯(cuò)，對(duì)自己、對(duì)用戶都十分痛苦。我們希望可以做到測(cè)試“左移”，盡可能早地發(fā)現(xiàn)問(wèn)題。但是很多時(shí)候我們不是不想測(cè)試，而是發(fā)現(xiàn)測(cè)不出什么問(wèn)題。那么怎樣提升實(shí)驗(yàn)室發(fā)現(xiàn)問(wèn)題的能力呢？如何盡可能地模擬用戶的操作路徑？做好測(cè)試并不容易，自動(dòng)化測(cè)試結(jié)合AI或許可以幫助我們解決一些痛點(diǎn)。

4、灰度和發(fā)布階段。動(dòng)態(tài)部署流行起來(lái)之后，很多開(kāi)發(fā)變得松懈起來(lái)。有問(wèn)題發(fā)補(bǔ)丁，一個(gè)不行就兩個(gè)，兩個(gè)不行就十個(gè)。怎樣去保證產(chǎn)品質(zhì)量？很多線上問(wèn)題概率很低，基本很難復(fù)現(xiàn)，比如對(duì)于一個(gè)印度的用戶，我們希望有一個(gè)遠(yuǎn)程的聽(tīng)診器，而不需要把用戶拉到我們的手術(shù)臺(tái)上。

對(duì)照應(yīng)用的交付流程，我來(lái)介紹一下專(zhuān)欄的學(xué)習(xí)方法。專(zhuān)欄“高質(zhì)量開(kāi)發(fā)”模塊主要對(duì)應(yīng)的是開(kāi)發(fā)階段，你可以帶著實(shí)踐過(guò)程的困惑去深入學(xué)習(xí)開(kāi)發(fā)需要的各種武器。專(zhuān)欄“高效開(kāi)發(fā)”模塊主要對(duì)應(yīng)編譯CI、測(cè)試、灰度和發(fā)布階段，你可以結(jié)合實(shí)際工作全面提升整個(gè)應(yīng)用交付的效率。另外，我認(rèn)為一個(gè)好的架構(gòu)可以減少甚至避免團(tuán)隊(duì)出錯(cuò)，也是打造一款高質(zhì)量應(yīng)用非常重要的一環(huán)，因此我會(huì)在最后的“架構(gòu)演進(jìn)”模塊和你聊聊如何設(shè)計(jì)一個(gè)好的架構(gòu)，以及架構(gòu)該如何選型。

移動(dòng)APM質(zhì)量平臺(tái)

請(qǐng)你思考一下，在應(yīng)用交付的這幾個(gè)階段中，我們對(duì)高質(zhì)量的目標(biāo)和實(shí)現(xiàn)方式是否一樣呢？開(kāi)發(fā)階段有開(kāi)發(fā)人員，可能希望采集盡可能多的數(shù)據(jù)；測(cè)試階段有測(cè)試人員，可能更針對(duì)實(shí)驗(yàn)室環(huán)境或與競(jìng)品對(duì)比進(jìn)行測(cè)試；灰度和發(fā)布階段可能也有專(zhuān)門(mén)的運(yùn)維人員，策略會(huì)相對(duì)保守一些。很明顯，不同階段我們對(duì)高質(zhì)量的目標(biāo)跟手段可能不太一樣。

一個(gè)公司有多套質(zhì)量系統(tǒng)，這在大公司是非常普遍的現(xiàn)象。我們希望有一個(gè)統(tǒng)一的平臺(tái)，整合應(yīng)用的人員和開(kāi)發(fā)流程，這就是我們常說(shuō)APM質(zhì)量平臺(tái)。

APM的全稱(chēng)是“Application Performance Management”，即應(yīng)用性能管理。據(jù)我了解，國(guó)內(nèi)像阿里、騰訊、美團(tuán)點(diǎn)評(píng)、餓了么、愛(ài)奇藝這些公司都在大力投入。Google今年也發(fā)力Android Vitals監(jiān)控，新增了耗電、權(quán)限管理模塊。那么APM質(zhì)量平臺(tái)究竟有著什么樣的魅力呢？

1、統(tǒng)一管理。A同學(xué)寫(xiě)了一個(gè)耗時(shí)監(jiān)控工具，B同學(xué)寫(xiě)了一個(gè)內(nèi)存監(jiān)控工具，它們?cè)诓煌膫}(cāng)庫(kù)，上報(bào)格式可能不太一樣，各自都搭了一個(gè)簡(jiǎn)單的頁(yè)面。如果想評(píng)估一個(gè)應(yīng)用的質(zhì)量，總是要去幾個(gè)系統(tǒng)匯總數(shù)據(jù)，想想都費(fèi)勁。

2、統(tǒng)一三端。一個(gè)公司可能有多個(gè)應(yīng)用，一個(gè)應(yīng)用也可能有H5、iOS、Android多個(gè)端。我們希望它們只是采集數(shù)據(jù)方式有所不同，上報(bào)、后臺(tái)分析、展示、報(bào)警都是共用的。隨著技術(shù)的發(fā)展，我們可能會(huì)增加React Native、Flutter這些新模塊的監(jiān)控，這個(gè)平臺(tái)應(yīng)該是統(tǒng)一演進(jìn)的。當(dāng)然我們非常希望業(yè)界有一套開(kāi)源的方案，大家可以一起優(yōu)化。

那這個(gè)質(zhì)量平臺(tái)需要關(guān)注哪些問(wèn)題呢？這需要看我們用戶關(guān)心什么問(wèn)題。有的問(wèn)題可能是致命的，像崩潰、卡死、白屏。另一大類(lèi)問(wèn)題就是性能問(wèn)題，安裝包大小、啟動(dòng)、耗時(shí)、內(nèi)存、耗電、流量都是這一個(gè)范疇。在這個(gè)專(zhuān)欄里，我并不會(huì)教你如何從頭搭建一個(gè)APM平臺(tái)，我會(huì)更期待你掌握背后所需要的知識(shí)，它們主要包括：

由于Android版本的碎片化和國(guó)內(nèi)Android生態(tài)的亂象，“Android開(kāi)發(fā)者很苦，國(guó)內(nèi)的Android開(kāi)發(fā)者更苦”。11月16日，第一屆安卓綠色聯(lián)盟開(kāi)發(fā)者大會(huì)在北京召開(kāi)，會(huì)議上推出了應(yīng)用體驗(yàn)標(biāo)準(zhǔn)V2.0，里面也對(duì)應(yīng)用的兼容性、穩(wěn)定性、性能、功能和安全做了詳細(xì)的定義。

在極致性能的同時(shí)，我們希望能更進(jìn)一步地打造“綠色應(yīng)用”。在這個(gè)過(guò)程中，一個(gè)全面而強(qiáng)大的APM質(zhì)量平臺(tái)會(huì)是我們堅(jiān)實(shí)的后盾。當(dāng)然對(duì)于大多數(shù)中小開(kāi)發(fā)者來(lái)說(shuō)，我們更建議選擇成熟的第三方服務(wù)。但深入了解它們背后的原理，無(wú)論是對(duì)我們?nèi)绾芜x擇合適的服務(wù)，還是日常開(kāi)發(fā)工作都會(huì)有很大的幫助。在學(xué)習(xí)完上面的這些內(nèi)容之后，你也會(huì)覺(jué)得其實(shí)“性能優(yōu)化”并不是那么“高不可攀”，我們也可以慢慢地邁向“性能優(yōu)化專(zhuān)家”之路。

不過(guò)我們需要明確一點(diǎn)，雖然移動(dòng)APM質(zhì)量平臺(tái)可以幫助我們快速發(fā)現(xiàn)和定位問(wèn)題，但是監(jiān)控并不能保證實(shí)現(xiàn)高質(zhì)量，這里最關(guān)鍵的永遠(yuǎn)是人，而不是系統(tǒng)。為什么呢？我舉兩個(gè)小例子。

你在工作中可能總能遇到這樣的場(chǎng)景，我管它叫反饋問(wèn)題三連擊：“是我的問(wèn)題嗎？”“能復(fù)現(xiàn)嗎？”“你的測(cè)試靠譜嗎？”。雖然通過(guò)APM質(zhì)量平臺(tái)可以減少推卸責(zé)任，但有些人的做法通常還是發(fā)現(xiàn)空指針加一個(gè)判空，發(fā)現(xiàn)并發(fā)問(wèn)題加一個(gè)鎖。這里的空指針真正原因是什么？這里判空了后面的邏輯是否還會(huì)運(yùn)行正常？有沒(méi)有更加好的方法或架構(gòu)可以避免這個(gè)問(wèn)題？我們真正應(yīng)該反問(wèn)的是這三個(gè)問(wèn)題，把“質(zhì)量觀”深入骨髓，真正去想要得到個(gè)人成長(zhǎng)，深挖背后的原因。

第二個(gè)例子是，我發(fā)現(xiàn)許多人都在問(wèn)題無(wú)法忍受，或者說(shuō)是老板無(wú)法忍受的時(shí)候才去開(kāi)啟各種優(yōu)化專(zhuān)項(xiàng)，但事后又不了了之。我們很多時(shí)候都在用戰(zhàn)術(shù)的勤奮掩蓋戰(zhàn)略的懶惰，性能優(yōu)化的關(guān)鍵在于如何解決存量問(wèn)題，同時(shí)快速發(fā)現(xiàn)增量問(wèn)題。APM質(zhì)量平臺(tái)只可以協(xié)助我們，并不能解決組織內(nèi)部的心態(tài)問(wèn)題。

總結(jié)

看到這里可能你會(huì)有這樣的疑問(wèn)，我們?cè)谛」靖緵](méi)有機(jī)會(huì)學(xué)習(xí)到這些東西呀？確實(shí)如此，個(gè)人與公司一起成長(zhǎng)是最快速，也是非常難得的事情，但并不一定人人都會(huì)有這樣的機(jī)會(huì)。從我自己的經(jīng)驗(yàn)來(lái)看，在搜狗、微信會(huì)遇到各種各樣的疑難問(wèn)題，也可以有很多時(shí)間去研究，讓我在解決過(guò)程中獲得成長(zhǎng)。

幸運(yùn)的是現(xiàn)在大家都更加樂(lè)于去分享，在專(zhuān)欄和技術(shù)會(huì)議中，我們可以看到很多成熟的解決問(wèn)題的經(jīng)驗(yàn)和思路，在GitHub我們可以找到很多優(yōu)秀的源代碼。在這個(gè)環(huán)境下，我們需要耐得住寂寞，多摳一些細(xì)節(jié)，多深入研究，多停下來(lái)總結(jié)。

我來(lái)分享一個(gè)我的故事，2013年初我去面試微信，前面都不太理想，最后還是通過(guò)了。后來(lái)有一次跟面試官閑聊說(shuō)起這個(gè)事情，他們認(rèn)為有一件事情打動(dòng)了他們。2012年的時(shí)候，LeakCanary還沒(méi)開(kāi)源，我在使用MAT做內(nèi)存泄漏分析的時(shí)候總覺(jué)得很不爽。為什么不能做自動(dòng)化？為什么看不到Bitmap的圖片？我當(dāng)時(shí)深入研究了內(nèi)存文件Hprof的格式，做了幾個(gè)小創(chuàng)新：

實(shí)現(xiàn)內(nèi)存的自動(dòng)化測(cè)試。在自動(dòng)化測(cè)試后回到首頁(yè)，這個(gè)時(shí)候獲取應(yīng)用的內(nèi)存快照。自動(dòng)分析內(nèi)存中Activity實(shí)例，正常情況應(yīng)該只存在一個(gè)，其他都認(rèn)為是泄漏。為了支持正式包，還做了通過(guò)mapping文件反混淆Hprof文件的功能。

查看圖片。自動(dòng)將內(nèi)存中重復(fù)的圖片、比較大的圖片轉(zhuǎn)換成PNG格式輸出到文件。

現(xiàn)在看起來(lái)這些功能并不是太難，但如果放到六年前，想到而且能做到的人相信并不多。講這個(gè)故事還是希望你能在工作和實(shí)踐中多停下來(lái)思考，多深入研究一些細(xì)節(jié)，很多看似不經(jīng)意的思考和創(chuàng)新，可能在日后發(fā)揮更大的價(jià)值。

內(nèi)容選自：極客時(shí)間《Android開(kāi)發(fā)高手課》