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

季度活躍設(shè)備增長趨勢

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

APM的雛形發(fā)展

在1996年時，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年，移動設(shè)備的普及和APP應(yīng)用市場的爆發(fā)，讓大家對移動端的性能體驗要求也越來越苛刻。

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

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

APM可用性度量體系

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

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

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

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

1、 可用性度量

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

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

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

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

2、 APP體驗度量

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

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

在性能優(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ā)者無需對所有的URL進行關(guān)注，不同的開發(fā)者關(guān)注的核心業(yè)務(wù)不同，大家關(guān)注的URL也不一樣。比如，在電商的場景，一個關(guān)鍵的路徑是用戶通過登錄，打開商品，進入詳情，然后下單到支付，通過把對應(yīng)的關(guān)鍵路徑所有的URL整合在一起，保障這條關(guān)鍵鏈路的性能，才能夠強化核心業(yè)務(wù)的服務(wù)以及穩(wěn)定性。

APM的可用性檢測方式

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

對于加強應(yīng)用的可用性，APM一般都采取應(yīng)用監(jiān)控結(jié)合服務(wù)監(jiān)控的形式，使得開發(fā)者實現(xiàn)端到端的全鏈路性能管理。在碼力APM監(jiān)控體系中，阿里巴巴技術(shù)專家熊奇介紹了碼力APM在監(jiān)控體系里面的應(yīng)用監(jiān)控、服務(wù)監(jiān)控、數(shù)據(jù)庫以及消息推送等性能監(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等框架的性能檢測；

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

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

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

可用性的度量檢測方式-性能

[[174377]]

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

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

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

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

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

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

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

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

同時，為了過濾因為電量耗盡導(dǎo)致的關(guān)機，碼力APM還增加了電量檢測，在低電量時，清除標(biāo)志位，避免中止誤報。

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

[[174378]]

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

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

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

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

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

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

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

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

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

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

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

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

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

2、系統(tǒng)降級

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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