作者：張紹文

今年年初翅溺，我去上海參加一個(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)介紹一下專欄的學(xué)習(xí)方法。專欄“高質(zhì)量開(kāi)發(fā)”模塊主要對(duì)應(yīng)的是開(kāi)發(fā)階段谋竖，你可以帶著實(shí)踐過(guò)程的困惑去深入學(xué)習(xí)開(kāi)發(fā)需要的各種武器承匣。專欄“高效開(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ā)布階段可能也有專門的運(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的全稱是“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é)寫了一個(gè)耗時(shí)監(jiān)控工具等太，B同學(xué)寫了一個(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)題可能是致命的障般，像崩潰、卡死藐石、白屏定拟。另一大類問(wèn)題就是性能問(wèn)題，安裝包大小株依、啟動(dòng)延窜、耗時(shí)、內(nèi)存荠藤、耗電获高、流量都是這一個(gè)范疇。在這個(gè)專欄里念秧，我并不會(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)化專家”之路哈雏。

不過(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)化專項(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è)于去分享，在專欄和技術(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ā)高手課》