【51CTO.com原創(chuàng)稿件】在《黑客帝國(guó)》電影中較為經(jīng)典的一幕是讓Neo在紅藥丸和藍(lán)藥丸中做出選擇。紅藥丸作為一個(gè)跟蹤程序，幫助Neo定位物理身體位置，無論在哪里，出現(xiàn)任何問題都能夠第一時(shí)間定位并解決。而開發(fā)者基本都知道，想解決大部分的功能性問題的難點(diǎn)基本就在定位上，而電影里面出現(xiàn)的一些人工智能、機(jī)器學(xué)習(xí)、虛擬現(xiàn)實(shí)的技術(shù)，也只能夠在科幻電影中才能看到。

季度活躍設(shè)備增長(zhǎng)趨勢(shì)

今天，在移動(dòng)終端爆發(fā)以及用戶需求的推動(dòng)下，移動(dòng)應(yīng)用的“數(shù)量”和“體量”急速擴(kuò)大，APP性能數(shù)據(jù)在優(yōu)化產(chǎn)品上變得越來越重要，國(guó)內(nèi)大批APM廠商仿佛一夜間遍地開花，整個(gè)監(jiān)控體系也從服務(wù)端到APP端再到H5端不斷的加強(qiáng)和改變策略來適應(yīng)不同的場(chǎng)景需求，使得監(jiān)控和優(yōu)化的本質(zhì)上已經(jīng)發(fā)生了變化。

APM的雛形發(fā)展

在1996年時(shí)，Tivo與HP公司就從應(yīng)用程序?qū)用娉霭l(fā)，他們認(rèn)為網(wǎng)絡(luò)無疑就是應(yīng)用的速度。直至1998年，面向以組件為中心基礎(chǔ)建設(shè)監(jiān)控的APM產(chǎn)品出現(xiàn)，直到2011年，移動(dòng)設(shè)備的普及和APP應(yīng)用市場(chǎng)的爆發(fā)，讓大家對(duì)移動(dòng)端的性能體驗(yàn)要求也越來越苛刻。

在這個(gè)時(shí)候，國(guó)外的APM行業(yè)New Relic和AppDynamics已經(jīng)在APM領(lǐng)域拔得頭籌，國(guó)內(nèi)一些APM廠商看準(zhǔn)移動(dòng)的這個(gè)趨勢(shì)，APM仿佛一夜之間遍地開花，直至今日，作為國(guó)內(nèi)比較具有代表性的APM廠商有：聽云、OneAPM、云智慧、博睿等，當(dāng)前BAT領(lǐng)域也躋身這一領(lǐng)域，阿里百川碼力APM（簡(jiǎn)稱“碼力APM”）也在云棲大會(huì)中發(fā)布公測(cè)。開發(fā)者無需從零開始構(gòu)建性能探針、數(shù)據(jù)平臺(tái)和控制臺(tái)，就可以通過可視化、可運(yùn)維的方式長(zhǎng)期監(jiān)控應(yīng)用性能、及時(shí)解決應(yīng)用中存在的問題。  

▲ APM 業(yè)務(wù)與 IT 發(fā)展關(guān)系變遷

APM可用性度量體系

如今，國(guó)內(nèi)APM業(yè)務(wù)競(jìng)爭(zhēng)越來越激烈，大家紛紛在可用性、用戶體驗(yàn)上發(fā)力。比如，大家用手機(jī)淘寶，明顯感覺穩(wěn)定性和流暢度比國(guó)內(nèi)其他電商APP好很多，這不僅僅是因?yàn)樗麄冇幸欢褍?yōu)秀的開發(fā)工程師，更關(guān)鍵是其背后那一套完善的性能監(jiān)控度量體系。

通過性能監(jiān)控體系，app上發(fā)生的性能指標(biāo)都會(huì)被實(shí)時(shí)上報(bào)，而碼力APM服務(wù)端會(huì)基于這些指標(biāo)進(jìn)行聚類和分析，聚合出問題和性能瓶頸，同時(shí)完善的日志信息也將支持開發(fā)工程師及時(shí)修復(fù)和優(yōu)化。

阿里技術(shù)專家陳武認(rèn)為，在性能優(yōu)化方面，以往的度量是通過APP的打開率來進(jìn)行對(duì)比，很多都是非常主觀。而度量體系里面面臨的一個(gè)很大的問題是常態(tài)化。那么，應(yīng)該如何建立起這一套可視化的性能度量的體系呢？

阿里百川將影響用戶使用的性能指標(biāo)分為可用性度量和體驗(yàn)度量。

1、 可用性度量

可用性包含app可用性和服務(wù)可用性。app可用性問題中最常見的就是crash，而用戶遇到crash之后，大部分會(huì)選擇直接卸載app；服務(wù)可用性問題則包含網(wǎng)絡(luò)連接和服務(wù)端錯(cuò)誤，這類問題往往可能造成用戶購(gòu)買、訂閱等關(guān)鍵操作不可用，從而導(dǎo)致資損，而這類問題若長(zhǎng)期未能解決，也會(huì)導(dǎo)致用戶流失。

這類問題需要第一時(shí)間被修復(fù)，越早修復(fù)，止損的效果就越好。

這需要客戶端探針具有強(qiáng)大的采集能力。探針SDK將負(fù)責(zé)采集用戶由于線程異常、內(nèi)存溢出、手機(jī)殺進(jìn)程等各種原因?qū)е碌谋罎?，并捕獲到盡量全面的環(huán)境信息，和用戶操作軌跡來幫助開發(fā)者還原用戶操作，定位問題。同時(shí)，對(duì)網(wǎng)絡(luò)請(qǐng)求部分也是同樣，探針SDK需要支持自動(dòng)采集網(wǎng)絡(luò)性能指標(biāo)，并捕獲錯(cuò)誤網(wǎng)絡(luò)請(qǐng)求的日志，來輔助開發(fā)工程師解決問題。

但是探針在用戶app端采集的均是單一的事件，若有1000個(gè)用戶出現(xiàn)可用性問題，那么服務(wù)端接收到的可能就是1000份日志。讓開發(fā)工程師在海量的日志中排查問題，顯然可行性不高。這就需要APM服務(wù)端實(shí)時(shí)對(duì)這些日志進(jìn)行語義分析以及高效的聚類，比如，將1000條用戶日志聚合為3個(gè)問題，通過控制臺(tái)反饋給開發(fā)者。這將大大提升開發(fā)工程師排查和解決問題的效率。

2、 APP體驗(yàn)度量

APP體驗(yàn)是影響用戶留存和活躍的關(guān)鍵，大家對(duì)APP使用過程中“如絲般順滑”都具有天然的好感。但是目前市場(chǎng)大部分APP的體驗(yàn)依舊非常差，用戶常會(huì)面對(duì)卡頓、圖片加載失敗、頁(yè)面長(zhǎng)時(shí)間等待等各種不良體驗(yàn)。這個(gè)時(shí)候，非常需要有一個(gè)系統(tǒng)體系化的去陳列和度量這些體驗(yàn)類問題。

APM控制臺(tái)對(duì)卡頓的處理方式和崩潰類似，同類型的卡頓將被聚類在一起，發(fā)生該卡頓的用戶詳細(xì)日志也聚合在一起可以翻頁(yè)查閱。而對(duì)圖片加載失敗等，頁(yè)面元素?zé)o法正常顯示的問題，則可以關(guān)注該圖片所在靜態(tài)資源的服務(wù)主機(jī)是否異常（單分鐘請(qǐng)求量過多、圖片過大等）。若該靜態(tài)資源服務(wù)正常，則可以關(guān)注請(qǐng)求該圖片的URL的錯(cuò)誤率，可以反推是否為圖片本身的問題。

在性能優(yōu)化的量化方面，如何幫助企業(yè)去做定制？陳武認(rèn)為，應(yīng)該串聯(lián)關(guān)鍵路徑所需要的全部URL，從關(guān)鍵路徑整體來看服務(wù)的健康度指標(biāo)，而非關(guān)注全部的URL。比如通過網(wǎng)絡(luò)性能監(jiān)控，開發(fā)者無需對(duì)所有的URL進(jìn)行關(guān)注，不同的開發(fā)者關(guān)注的核心業(yè)務(wù)不同，大家關(guān)注的URL也不一樣。比如，在電商的場(chǎng)景，一個(gè)關(guān)鍵的路徑是用戶通過登錄，打開商品，進(jìn)入詳情，然后下單到支付，通過把對(duì)應(yīng)的關(guān)鍵路徑所有的URL整合在一起，保障這條關(guān)鍵鏈路的性能，才能夠強(qiáng)化核心業(yè)務(wù)的服務(wù)以及穩(wěn)定性。

APM的可用性檢測(cè)方式

▲ 阿里百川碼力APM的監(jiān)控體系

對(duì)于加強(qiáng)應(yīng)用的可用性，APM一般都采取應(yīng)用監(jiān)控結(jié)合服務(wù)監(jiān)控的形式，使得開發(fā)者實(shí)現(xiàn)端到端的全鏈路性能管理。在碼力APM監(jiān)控體系中，阿里巴巴技術(shù)專家熊奇介紹了碼力APM在監(jiān)控體系里面的應(yīng)用監(jiān)控、服務(wù)監(jiān)控、數(shù)據(jù)庫(kù)以及消息推送等性能監(jiān)控，主要通過以下方式來完成：

★ 在應(yīng)用監(jiān)控上，采集了iOS、Android應(yīng)用的內(nèi)存、CPU、崩潰、網(wǎng)絡(luò)等方面的性能數(shù)據(jù)；

★ 在服務(wù)監(jiān)控上，支持Tomcat、Jetty、JBoss容器和Spring、Struts等框架的性能檢測(cè)；

★ 支持MySQL等SQL數(shù)據(jù)庫(kù)和Redis、Mem cache等NoSQL數(shù)據(jù)庫(kù)的性能檢測(cè)；

★ 碼力APM還提供了支持淘寶消息服務(wù)TMC、分布式框架Dubbo、淘寶API調(diào)用的性能檢測(cè)。

對(duì)于數(shù)據(jù)采集之后會(huì)統(tǒng)一進(jìn)入可以承載海量數(shù)據(jù)的存儲(chǔ)系統(tǒng)和日志系統(tǒng)，統(tǒng)計(jì)系統(tǒng)會(huì)利用落地的數(shù)據(jù)完成數(shù)據(jù)的計(jì)算處理、生成報(bào)表，幫助開發(fā)者長(zhǎng)期跟蹤應(yīng)用和服務(wù)的性能，而告警系統(tǒng)則會(huì)根據(jù)規(guī)則在問題發(fā)生時(shí)發(fā)出短信、郵件等即時(shí)告警，從而幫助開發(fā)者及時(shí)解決問題，降低損失。

可用性的度量檢測(cè)方式-性能

[[174377]]

在應(yīng)用開發(fā)時(shí)，程序錯(cuò)誤、主線程卡頓和資源使用超過系統(tǒng)限制導(dǎo)致的崩潰，是最嚴(yán)重、也是需要首先解決的問題。

通常開發(fā)者會(huì)借助模擬器、Instrument或者自動(dòng)化測(cè)試發(fā)現(xiàn)一部分問題，但是測(cè)試往往難以覆蓋用戶使用場(chǎng)景下的設(shè)備、網(wǎng)絡(luò)等環(huán)境。如果借助于社交媒體或者郵件反饋渠道，雖然可以有限地拿到真實(shí)的用戶反饋，但是用戶往往不能清楚的描述出復(fù)現(xiàn)問題所需的信息，往復(fù)溝通成本極高。所以，在客戶端上，碼力APM通過以下檢測(cè)方式來收集應(yīng)用崩潰信息。

碼力APM在信號(hào)捕獲方式中，通過sigaction設(shè)置信號(hào)中斷時(shí)的回調(diào)，這樣，就可以在回調(diào)中根據(jù)程序運(yùn)行狀態(tài)生成對(duì)應(yīng)的崩潰日志。此外，對(duì)于SIGARBT(abnormal termination)，我們還需要通過NSSetUncaughtExceptionHandler來獲取未捕獲異常的堆棧，來補(bǔ)全崩潰信息。

而后，把崩潰日志上報(bào)到碼力APM，會(huì)依據(jù)崩潰日志的堆棧信息，聚合同一類型的崩潰后寫入數(shù)據(jù)存儲(chǔ)。同時(shí)，告警系統(tǒng)可以依據(jù)崩潰次數(shù)、崩潰率等規(guī)則，即時(shí)發(fā)出告警。

此外，碼力Apm提供了dSYM上報(bào)腳本，在Xcode的build phrase中添加腳本，就可以在編譯成功后自動(dòng)上報(bào)dSYM文件。通過對(duì)dSYM文件的解析，重新聚合后寫入數(shù)據(jù)存儲(chǔ)，聚合可以減少高達(dá)90%數(shù)據(jù)庫(kù)行數(shù)；同時(shí)，也實(shí)現(xiàn)了崩潰日志符號(hào)化。不依賴mac環(huán)境符號(hào)化，更好地利用云計(jì)算平臺(tái)服務(wù)更多開發(fā)者。

第二種技術(shù)是卡頓檢測(cè)，卡頓檢測(cè)的基礎(chǔ)是RunLoop，通過RunLoop Observer監(jiān)聽主線程RunLoop狀態(tài)的變更。在這里，把RunLoop當(dāng)作在操場(chǎng)上跑圈的運(yùn)動(dòng)員，把Before Sources當(dāng)做每圈的起點(diǎn)，同時(shí)另外開啟一條線程作為計(jì)時(shí)員，每5秒判斷一次RunLoop是否跑過一圈。如果5秒內(nèi)RunLoop沒有完成一次RunLoop，則視為主線程卡頓。在發(fā)現(xiàn)主線程卡頓后，會(huì)生成卡頓日志，如果是復(fù)現(xiàn)的卡頓，可以選擇不重復(fù)上報(bào)。

此外，針對(duì)設(shè)備不同的運(yùn)行時(shí)期，如啟動(dòng)階段、后臺(tái)階段、空閑階段，我們會(huì)動(dòng)態(tài)調(diào)整閾值，降低檢測(cè)的開銷。

對(duì)于無法通過信號(hào)捕獲、卡頓檢測(cè)的崩潰，碼力APM引入了應(yīng)用中止檢測(cè)，中止檢測(cè)雖然不能還原崩潰現(xiàn)場(chǎng)，但是可以揭示問題的存在。在應(yīng)用進(jìn)入active狀態(tài)時(shí)，碼力APM在持久存儲(chǔ)上設(shè)立一個(gè)標(biāo)志位，表示程序在正常運(yùn)行。在應(yīng)用退出active狀態(tài)或檢測(cè)到崩潰時(shí)，碼力APM就清除持久存儲(chǔ)上的標(biāo)志位，表示程序在已知的情況下退出。這樣，在下一次應(yīng)用啟動(dòng)時(shí)，如果持久存儲(chǔ)上的標(biāo)志位為真，則說明應(yīng)用上一次運(yùn)行在未知情況下退出，這種情況碼力APM就計(jì)為應(yīng)用非正常中止上報(bào)。

同時(shí)，為了過濾因?yàn)殡娏亢谋M導(dǎo)致的關(guān)機(jī)，碼力APM還增加了電量檢測(cè)，在低電量時(shí)，清除標(biāo)志位，避免中止誤報(bào)。

可用性的度量檢測(cè)方式-網(wǎng)絡(luò)

[[174378]]

請(qǐng)求錯(cuò)誤、流量開銷高、被運(yùn)營(yíng)商劫持等網(wǎng)絡(luò)問題是應(yīng)用開發(fā)時(shí)另一類棘手的問題。當(dāng)然我們也可以借助模擬器、Instrument或者自動(dòng)化測(cè)試發(fā)現(xiàn)簡(jiǎn)單的網(wǎng)絡(luò)問題，但是測(cè)試難以覆蓋復(fù)雜的用戶網(wǎng)絡(luò)環(huán)境，也難以導(dǎo)出網(wǎng)絡(luò)性能數(shù)據(jù)進(jìn)行長(zhǎng)期比對(duì)監(jiān)控。如果使用手工埋點(diǎn)的方式記錄網(wǎng)絡(luò)性能，一方面，我們需要應(yīng)對(duì)多種系統(tǒng)網(wǎng)絡(luò)接口，另一方面，我們需要同步應(yīng)用網(wǎng)絡(luò)代碼和埋點(diǎn)代碼，維護(hù)成本將會(huì)居高不下。

為了監(jiān)控應(yīng)用在真實(shí)網(wǎng)絡(luò)環(huán)境中的性能，碼力APM中引入了無痕埋點(diǎn)的網(wǎng)絡(luò)性能監(jiān)控，在網(wǎng)絡(luò)檢測(cè)中引入三種注入技術(shù)，幫助開發(fā)者長(zhǎng)期監(jiān)控應(yīng)用的網(wǎng)絡(luò)性能，優(yōu)化產(chǎn)品用戶體驗(yàn)。

第一種是Method Swizzling。每一個(gè)NSObject類都包含一個(gè)isa指針，指向objc_class結(jié)構(gòu)體，而每一個(gè)objc_class結(jié)構(gòu)體又包含一個(gè)methodLists指針，指向objc_method_list結(jié)構(gòu)體數(shù)組，在objc_method_list里又包含一個(gè)objc_method結(jié)構(gòu)體成員，且每一個(gè)objc_method包含一個(gè)method_imp指針，指向方法實(shí)現(xiàn)。

因此，只要能修改method_imp的值，我們就能替換原有的實(shí)現(xiàn)。在<objc/runtime>中，通過class_getClassMethod和class_getInstanceMethod取得objc_method結(jié)構(gòu)體指針，而后通過method_getImplementation取得方法的原始實(shí)現(xiàn)地址originIMP，之后在imp_implementationWithBlock生成新實(shí)現(xiàn)imp的參數(shù)block里，調(diào)用原始實(shí)現(xiàn)，就可以原有行為前后加入網(wǎng)絡(luò)性能埋點(diǎn)行為。最后調(diào)用method_setImplementation替換方法實(shí)現(xiàn)。這樣，任何調(diào)用都將使用新的實(shí)現(xiàn)。

第二種技術(shù)是Proxy。在Objective-C里，NSProxy是除NSObject外唯一的根類。NSProxy是一個(gè)實(shí)現(xiàn)了NSObject協(xié)議的抽象類，它的正常運(yùn)作需要子類override -methodSignatureForSelector:方法為sel提供方法簽名，以及-forwardInvocation:方法來完成調(diào)用的轉(zhuǎn)發(fā)。

使用Proxy來注入NSURLConnection、NSURLSession等對(duì)delegate的回調(diào)。具體來說，在delegate proxy收到消息時(shí)，如果不是目標(biāo)協(xié)議方法，則通過消息轉(zhuǎn)發(fā)機(jī)制，轉(zhuǎn)發(fā)給原delegate；如果是目標(biāo)協(xié)議方法，則直接調(diào)用proxy實(shí)現(xiàn)，在proxy實(shí)現(xiàn)中委托調(diào)用原delegate；此外，多數(shù)協(xié)議和協(xié)議方法都是可選的，因此，在proxy的實(shí)現(xiàn)中需要實(shí)現(xiàn)-conformsToProtocol:和-respondsToSelector:方法來聲明proxy額外加入的協(xié)議和方法。這樣，我們就能在不影響原有回調(diào)的同時(shí)，增加網(wǎng)絡(luò)性能埋點(diǎn)邏輯。

第三種技術(shù)是fishhook。使用fishhook來替換動(dòng)態(tài)鏈接庫(kù)中的C函數(shù)實(shí)現(xiàn)，具體來說是CFNetwork和CoreFoundation中的相關(guān)函數(shù)。這里，以開車的模型來解釋動(dòng)態(tài)鏈接。設(shè)想一名新手司機(jī)開車從巴黎到羅馬，因?yàn)樗恢缆肪€，于是他先去咨詢老司機(jī)；老司機(jī)告訴他正確的線路，這一次他可能還會(huì)繞點(diǎn)路，但下一次，他就會(huì)按照老司機(jī)的建議直接開到羅馬。

相應(yīng)的，在程序運(yùn)行時(shí)，動(dòng)態(tài)鏈接的C函數(shù)dynamic(...)地址記錄在__DATA segment下的__la_symbol_ptr中；初始時(shí)，程序只知道dynamic函數(shù)的符號(hào)名而不知道函數(shù)的實(shí)現(xiàn)地址；首次調(diào)用時(shí)，程序通過__TEXT segment中的__stub_helper取得綁定信息，通過dyld_stub_binder來更新__la_symbol_ptr中的符號(hào)實(shí)現(xiàn)地址；這樣，再次調(diào)用時(shí)，就可以通過__la_symbol_ptr直接找到dynamic函數(shù)的實(shí)現(xiàn)；如果我們需要替換dynamic函數(shù)的實(shí)現(xiàn)，只需要修改__la_symbol_ptr即可。具體的實(shí)現(xiàn)方式，可以參閱Facebook的開源框架fishhook。

加強(qiáng)可用性的優(yōu)化手段

通過以上兩種檢測(cè)方式，基本能夠大部分的性能和網(wǎng)絡(luò)需求，使得開發(fā)者能夠滿足如今移動(dòng)互聯(lián)網(wǎng)下用戶的苛刻的需求，那么，建立起來的度量體系后，了解的具體的問題后，我們應(yīng)該如何去解決這些問題來提升可用性呢？

1、網(wǎng)絡(luò)安全

運(yùn)營(yíng)商、DNS被劫持問題是應(yīng)用開發(fā)時(shí)一類棘手的問題， 解決方案也比較多。51信用卡技術(shù)總監(jiān)汪睿認(rèn)為，51信用卡作為金融屬性的產(chǎn)品，基于安全考慮會(huì)放在第一位。解決方案主要是基于全棧HTTPS的方案來處理，但會(huì)帶來一些成本和性能上的損耗。甚至可以像FaceBook、google等一些解決方案，使用HTTP2.0方式，這取決于公司和開發(fā)者自身去評(píng)估實(shí)現(xiàn)的成本。汪睿還介紹了早起的一個(gè)過渡方案，那就是HTTP的DNS方式，通過獲取一個(gè)IP表通過IP來直接連接，可以避免HTTP劫持的問題。

而網(wǎng)絡(luò)是一個(gè)端到端的技術(shù)，阿里高級(jí)技術(shù)專家陳武認(rèn)為，從電商的場(chǎng)景看，首先要保證服務(wù)端的穩(wěn)定性，服務(wù)端可以有反刷，限流，單元化，異地容災(zāi)，服務(wù)降級(jí)等策略保證連接的穩(wěn)定性。另外，客戶端的角度主要看連接鏈路和數(shù)據(jù)量。鏈路里面資源可以做多CDN的備份，通過HTTP DNS或者HTTPS，HTTP2.0來反劫持。在鏈路穩(wěn)定的基礎(chǔ)上，接著去保證傳輸?shù)男剩@里面可以通過就近接入，連接復(fù)用，提升壓縮率，使用二進(jìn)制協(xié)議等技術(shù)來減少包大小。當(dāng)然，這里面最重要的是端到端的網(wǎng)絡(luò)監(jiān)控體系，這樣在網(wǎng)絡(luò)服務(wù)治理上會(huì)更有抓手。

2、系統(tǒng)降級(jí)

降級(jí)的解決方案，是系統(tǒng)性能保障的最后一道防線，從性能優(yōu)化的角度上說，沒有100%完善的設(shè)計(jì)，總會(huì)有一些意料突發(fā)的情況導(dǎo)致性能惡化。所以，在系統(tǒng)設(shè)計(jì)時(shí)，必須做好降級(jí)設(shè)計(jì)。

餓了么移動(dòng)首席架構(gòu)師王朝成認(rèn)為，在餓了么517大促活動(dòng)上，服務(wù)器端承受非常大的壓力，這個(gè)時(shí)候會(huì)通過降級(jí)部分服務(wù)的方式，來確保大促秒殺這種場(chǎng)景得以正常運(yùn)行。但是，在用戶端上，以及APP，還在不斷積極的發(fā)送用戶請(qǐng)求和數(shù)據(jù)，反而增加服務(wù)器集群的壓力。這個(gè)時(shí)候，王朝成表示，他們會(huì)考慮把一部分的SDK或者APP上的服務(wù)也進(jìn)行降級(jí)，來減少服務(wù)端在分析數(shù)據(jù)上的壓力。

降級(jí)分為手動(dòng)降級(jí)和智能降級(jí)，在策略上分為流量降級(jí)、效果降級(jí)、功能性降級(jí)。流量降級(jí)主要表現(xiàn)在通過主動(dòng)拒絕處理部分流量早餐部分用戶服務(wù)不可用。而效果降級(jí)和功能性降級(jí)都表現(xiàn)為服務(wù)質(zhì)量的降級(jí)，一個(gè)是通過在流量高峰時(shí)期用相對(duì)低質(zhì)量、低延時(shí)的服務(wù)來保障所有用戶的服務(wù)可用性，另外一個(gè)是通過減少功能的方式來提高用戶的服務(wù)可用性。

3、網(wǎng)絡(luò)性能

從數(shù)據(jù)結(jié)構(gòu)上，需要根據(jù)不同的業(yè)務(wù)場(chǎng)景來選擇合適的數(shù)據(jù)結(jié)構(gòu)，在數(shù)據(jù)流量較少的情況可能客戶端上表現(xiàn)不出什么區(qū)別，當(dāng)在數(shù)據(jù)流量過大，且數(shù)據(jù)結(jié)構(gòu)復(fù)雜的時(shí)候很可能就是直接影響到APP的性能。

類似餐飲領(lǐng)域“餓了么”這樣的應(yīng)用，數(shù)據(jù)發(fā)送的頻率使得據(jù)量會(huì)非常大，對(duì)用戶來說可能沒有什么感知，但是商家接收大量的訂單，數(shù)據(jù)量影響很大，感知比較明顯。王朝成認(rèn)為，可以考慮一些新的協(xié)議（Protobuf, Flatbuf）來優(yōu)化數(shù)據(jù)量，比如HTTP2.0可以壓縮http協(xié)議的header，使用encoder來減少需要傳輸?shù)膆eader大小，通過通訊雙方各自cache一份header fields表，對(duì)于相同的數(shù)據(jù)不再通過每次請(qǐng)求和響應(yīng)發(fā)送，又減少了需要傳輸?shù)拇笮?。再一個(gè)是采取二進(jìn)制的協(xié)議，只認(rèn)0和1的組合，通過把原來http1.x的header和body部分用frame重新封裝，實(shí)現(xiàn)方便且健壯。通過內(nèi)容壓縮與并發(fā)傳輸機(jī)制，在低速、不穩(wěn)定的無線條件下，較少其http body的發(fā)送大小，改善用戶體驗(yàn)和資源效率。

▲ http1.x和http2.0協(xié)議關(guān)系

同時(shí)，阿里高級(jí)技術(shù)專家陳武也表示，如果在鏈路沒有問題的情況下，那么必須在整個(gè)網(wǎng)絡(luò)傳輸層要盡量快，不然很容易出現(xiàn)timeout。所以，第一要從協(xié)議層，在協(xié)議層里面通過http2.0來減少包頭的壓縮，同時(shí)支持服務(wù)端push消息，且通過雙通通道，對(duì)通道復(fù)用更快。第二是從數(shù)據(jù)層，數(shù)據(jù)可以通過二進(jìn)制壓縮。在整個(gè)網(wǎng)絡(luò)連通率較低的時(shí)候，將打包拆成小包，達(dá)到很好的傳輸效果。

4、動(dòng)態(tài)熱修復(fù)

所謂熱修復(fù)，就是使用熱補(bǔ)丁動(dòng)態(tài)修復(fù)技術(shù)，通過向用戶發(fā)送Patch，在用戶無感知的情況下完成一些致命bug的修復(fù)。51信用卡客戶端負(fù)責(zé)人汪睿認(rèn)為，在移動(dòng)客戶端上最大的一個(gè)問題是發(fā)版，對(duì)于iOS的用戶來說，整個(gè)修復(fù)流程比較漫長(zhǎng)。需要提交審核，但是在這段時(shí)間有可能已經(jīng)錯(cuò)過很多用戶。他認(rèn)為，熱修復(fù)技術(shù)能夠很快并及時(shí)的在線進(jìn)行修復(fù)，通常在使用的過程中就完成的修復(fù)過程。

在熱修復(fù)技術(shù)上，Android常用的是基于Android dex分包方案，而iOS可以利用JSPatch，它可以使得你用JavaScript書寫原生iOS APP，只需要在項(xiàng)目中引入極小的引擎，就可以用JavaScript調(diào)用任何的Objective-C的原生接口。

總結(jié)

以上所談到的性能優(yōu)化手段基本是為了解決三種情況所造成的問題：1. 日漸復(fù)雜的業(yè)務(wù)導(dǎo)致功能不斷迭代所突發(fā)的致命bug修復(fù)方式，2. 日益增長(zhǎng)的用戶和膨脹的數(shù)據(jù)導(dǎo)致流量過大，3.網(wǎng)絡(luò)安全和內(nèi)存開銷的問題。

本文通過不同的場(chǎng)景來分析移動(dòng)性能優(yōu)化的模式，可以通過確定場(chǎng)景下解決某一類型的問題。當(dāng)然，我們不能僅僅通過了解性能優(yōu)化所解決的問題以及手段，更重要的是需要清楚該問題所發(fā)生的場(chǎng)景、原因需要的成本。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】