IOS應(yīng)用除了閃退問(wèn)題外，卡頓問(wèn)題也會(huì)對(duì)App帶來(lái)差評(píng)，甚至流失更多的用戶。卡頓是什么呢？卡頓就是應(yīng)用運(yùn)行不流暢的現(xiàn)象，給用戶的直觀感受就是點(diǎn)擊屏幕操作有停頓、響應(yīng)緩慢、界面卡死等。輕微的卡頓問(wèn)題會(huì)影響用戶體驗(yàn)，嚴(yán)重的情況更會(huì)造成應(yīng)用不可用。那么，針對(duì)iOS應(yīng)用卡頓可以使用友盟+U-APM來(lái)解決卡頓的問(wèn)題。
作為一名有態(tài)度、充滿情懷的開(kāi)發(fā)者，當(dāng)然就是立馬擼起袖子準(zhǔn)備修復(fù)了。那么問(wèn)題來(lái)了，我們要從哪下手呢?
俗話說(shuō)“治病先治根”，那么就要了解到卡頓是怎樣產(chǎn)生的了。
創(chuàng)建一個(gè)UI Button，當(dāng)用戶點(diǎn)擊的時(shí)候，主線程會(huì)響應(yīng)及處理點(diǎn)擊事件，這里是執(zhí)行handleButtonAction方法。handleButtonAction方法發(fā)起了一個(gè)網(wǎng)絡(luò)請(qǐng)求下載圖片。必然的，這是一個(gè)耗時(shí)的操作。
在iOS應(yīng)用中，所有的UI操作及更新都是在主線程完成，并且主線程的runloop是逐個(gè)處理用戶事件的(當(dāng)然其他的runloop也一樣)，所以主線程必須等待上一次事件處理完成后才能繼續(xù)響應(yīng)下一次事件。
由于在主線程內(nèi)發(fā)起耗時(shí)網(wǎng)絡(luò)請(qǐng)求，主線程只能停止響應(yīng)接下來(lái)的所有用戶事件，等待網(wǎng)絡(luò)請(qǐng)求結(jié)束。在等待的這個(gè)過(guò)程中，應(yīng)用就停止響應(yīng)了，也就是出現(xiàn)卡頓現(xiàn)象。
為了更好的理解主線程的runloop，我們來(lái)看看iOS應(yīng)用的運(yùn)行機(jī)制。
在 iOS 應(yīng)用啟動(dòng)后，系統(tǒng)會(huì)自動(dòng)創(chuàng)建主線程并開(kāi)始運(yùn)行它的 runloop，監(jiān)聽(tīng)處理分發(fā)事件，當(dāng)沒(méi)有事件發(fā)生時(shí)進(jìn)入休眠狀態(tài)，有事件發(fā)生時(shí)系統(tǒng)會(huì)將接收到的事件放在一個(gè)隊(duì)列里，然后喚醒 runloop 依次處理事件。
絕大部分用戶感知到的卡頓就是由于主線程阻塞了，在處理某次事件消耗了過(guò)長(zhǎng)的時(shí)間，導(dǎo)致主線程處于等待狀態(tài)，無(wú)法及時(shí)響應(yīng)用戶的下一次輸入事件。
由于iOS 上的 UIKit 只能在主線程進(jìn)行處理，導(dǎo)致開(kāi)發(fā)者在開(kāi)發(fā)過(guò)程中不經(jīng)意間在主線程做了一些消耗時(shí)間的工作，導(dǎo)致了應(yīng)用卡頓。
根據(jù)上述內(nèi)容我們了解到了是什么原因?qū)е驴D的，接下來(lái)就是如何避免卡頓的問(wèn)題了，友盟+u-apm監(jiān)控平臺(tái)可幫助到大家！
避免卡頓的黃金法則就是不要讓主線程干重活，例如網(wǎng)絡(luò)請(qǐng)求，讀寫(xiě)大文件，復(fù)雜的運(yùn)算等一些耗費(fèi)大量系統(tǒng)資源及時(shí)間的任務(wù)。
充分利用好 iOS 的多線程，如 NSThread、NSO peration Queue，GCD 等干臟活、累活，讓主線程能及時(shí)迅速的響應(yīng)用戶事件。
主線程輕松了，應(yīng)用就流暢了，用戶也就會(huì)越來(lái)越多，用戶的使用感爽了，就不用擔(dān)心差評(píng)的問(wèn)題了，五星評(píng)價(jià)也就越來(lái)越多嘍~
那么我們根據(jù)上面的黃金法則修改下handle Button Action方法，用GCD 來(lái)進(jìn)行網(wǎng)絡(luò)請(qǐng)求。經(jīng)過(guò)修改之后，現(xiàn)在主線程就不會(huì)發(fā)生阻塞了，迅速的執(zhí)行完用戶的點(diǎn)擊事件后，然后等待響應(yīng)用戶的下一次事件。
除了在開(kāi)發(fā)過(guò)程中開(kāi)發(fā)者需要時(shí)刻牢記黃金法則，避免寫(xiě)出阻塞主線程的代碼，我們還需要一套監(jiān)測(cè)機(jī)制，來(lái)幫助我們及時(shí)的發(fā)現(xiàn)應(yīng)用卡頓，第一時(shí)間定位并修復(fù)，給用戶如絲般順滑的操作體驗(yàn)。
應(yīng)用發(fā)布后如果碰到用戶反饋卡頓，我們又該如何去定位解決問(wèn)題?
一個(gè)比較常見(jiàn)的場(chǎng)景：用戶反饋應(yīng)用卡頓，客服人員反饋給開(kāi)發(fā)者，開(kāi)發(fā)者要求用戶提供更加詳細(xì)的信息以定位問(wèn)題，但是問(wèn)題又來(lái)了，很多時(shí)候我們聯(lián)系不上用戶啊！怎么辦？熬夜加班逐行檢查代碼，說(shuō)多了都是淚。
那么，友盟+U-APM作為一款應(yīng)用性能監(jiān)控平臺(tái)，這不就派到用場(chǎng)了嘛~不僅可以解決開(kāi)發(fā)者對(duì)iOS卡頓問(wèn)題的煩惱，還可以協(xié)助APP應(yīng)用，讓用戶體驗(yàn)到APP的流暢性。友盟+U-APM同時(shí)提供云真機(jī)測(cè)試能力，助力開(kāi)發(fā)者從研發(fā)測(cè)試質(zhì)量驗(yàn)收到線上問(wèn)題復(fù)現(xiàn)排查，保障應(yīng)用品質(zhì)，提升測(cè)試效率。在云真機(jī)測(cè)試期間自動(dòng)采集崩潰信息，提供詳盡的崩潰報(bào)告協(xié)助篩查，真正實(shí)現(xiàn)監(jiān)控測(cè)試全流程深度打通。
U-APM應(yīng)用性能監(jiān)控平臺(tái)，通過(guò)輕量級(jí)的集成接入即可擁有實(shí)時(shí)、可靠、全面的應(yīng)用崩潰、ANR、自定義異常等捕獲能力，及卡頓、啟動(dòng)分析、內(nèi)存分析、網(wǎng)絡(luò)分析等性能監(jiān)測(cè)能力，支持多場(chǎng)景、多通道智能告警監(jiān)測(cè)，幫助開(kāi)發(fā)者高效還原異常、卡頓用戶的訪問(wèn)路徑和業(yè)務(wù)現(xiàn)場(chǎng)，縮短故障排查時(shí)間。這一塊的功能是我比較喜歡的，建議各位開(kāi)開(kāi)者有以上這些煩惱時(shí)，都可以試試運(yùn)用上U-APM的功能，你會(huì)發(fā)現(xiàn)不一樣的使用和便捷。
