應(yīng)用系統(tǒng)Bugly崩潰分析

1、應(yīng)用系統(tǒng)Bugly崩潰分析產(chǎn)品介紹騰訊Bugly（）Crash、ANR、卡頓等異常監(jiān)控內(nèi)測(cè)分發(fā)服務(wù)、應(yīng)用更新SDK、熱補(bǔ) 丁SDK騰訊優(yōu)測(cè)（）自動(dòng)化測(cè)試云真機(jī)租用、云真機(jī)調(diào)試、崩潰捕獲原理懷疑崩潰是否真的發(fā)生？誤報(bào)？漏報(bào)？JAVA崩潰捕獲方式注冊(cè)異常處器:Thread. setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler)線程旦崩潰，異常處理器的方法被調(diào)用：Thread.UncaughtExceptionHandler.uncaughtException(Thread t, Throwable e)uncaugh

2、tException方法中實(shí)現(xiàn)Java異常的捕獲及上報(bào)系統(tǒng)的默認(rèn)處理崩潰背后的處理Pthread_Create(,interpThreadStart);創(chuàng)建dvmDetachCurrentThread()VM Thread結(jié)束后PThreadVM ThreadJava.lang.Thread.run()XXX當(dāng)前執(zhí)行的方法interpThreadStart()XXXdvmcallMethod(self,run.)Native棧Java 棧Pthread棧UncaughtExceptionHandler_defaultHandlerPending Exception: java.lang.Thr

3、owable崩潰發(fā)生threadExitUncaughtException (Thread*,jThrowable)發(fā)現(xiàn)Pending ExceptionJNI回調(diào)NATIVE崩潰捕獲方式注冊(cè)信號(hào)處理函數(shù)int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);struct sigaction /異常處理就在這些方法里void (*sa_handler)(int);void (*sa_sigaction)(int, siginfo_t *, void *);sigset_t sa_mask;

4、 int sa_flags;void (*sa_restorer)(void);信號(hào)的背后PThreadinterpThreadStart()XXX當(dāng)前執(zhí)行的方法Native棧struct sigaction * handlerPending Signal Array出錯(cuò)了，產(chǎn)生錯(cuò)誤信號(hào)信號(hào)處理 函數(shù)回調(diào)注冊(cè)信號(hào) 處理函數(shù)信號(hào)名信號(hào)值SIGILL4SIGSEGV11SIGBUS7SIGABRT6SIGSTKFLT16Bugly處理的錯(cuò)誤信號(hào)豆目下異常捕獲消耗資源大嗎？NO，發(fā)生異常時(shí)才會(huì)被執(zhí)行哦，且APP已經(jīng)處千崩潰狀態(tài)哦！存在誤報(bào)嗎？NO，異常與否是由系統(tǒng)API直接回調(diào)，不存在Bugly誤判

5、的空間！存在漏報(bào)嗎？YES，不同類(lèi)型的崩潰差異很大，有些崩潰發(fā)生時(shí)可能當(dāng)前無(wú)法上報(bào)，只能等待第二次 啟動(dòng)上報(bào)（SIGABRT）二、BUGLY讓你全面了解產(chǎn)品的質(zhì)量Java Crash、C/C+ Crash、ANR個(gè)都不應(yīng)該漏崩潰、CrashANR(無(wú)晌應(yīng)）要等用戶(hù)投訴才發(fā)現(xiàn)？要用戶(hù)協(xié)助才能定位？平均設(shè)備Crash率3.0%3.5%平均設(shè)備Crash次數(shù)2.3次1.9次6.32%6.08%4.21%3.01%1.78%1千以下1千-1萬(wàn)1萬(wàn)-10萬(wàn)10萬(wàn)-100萬(wàn)大于100萬(wàn)不同DAU級(jí)別應(yīng)用的平均崩潰率整體崩潰率崩潰率越低，用戶(hù)越多！3.04%2.38%1.69%2.37%2.90%2.56%

6、3.46%8.95%3.87%3.26%2.04%1.61%2.44%4.32%3.29%3.23%3.78%4.06%4.11%7.57%實(shí)用工具生活?yuàn)蕵?lè)購(gòu)物時(shí)尚兒童親子影音視聽(tīng)出行地圖閱讀學(xué)習(xí)聊天通訊辦公商務(wù)游戲Android行業(yè)崩潰率iOS行業(yè)崩潰率行業(yè)細(xì)分崩潰率騰訊精品游戲平均CRASH率不到2%崩潰與機(jī)型相關(guān)2.70%2.40%1.90%1.80%2.40%3.10%2.00%2.60%3.00%2.30%小米M4紅米Note華為榮耀6華為Mate7 三星Galaxy 三星Galaxy魅藍(lán) Note3S6魅族Notevivo X5Pro OPPO R7Android主流機(jī)型上的應(yīng)用崩

7、潰率崩潰跟機(jī)型相關(guān)，適配問(wèn)題依然嚴(yán)重48%的崩潰在啟動(dòng)階段15%21%52%閃退 崩潰發(fā)生在啟動(dòng)后05秒啟動(dòng)階段的崩潰 崩潰發(fā)生在啟動(dòng)后530秒 運(yùn)行初期的崩潰 崩潰發(fā)生在啟動(dòng)后3060秒 運(yùn)行時(shí)的崩潰 崩潰發(fā)生在啟動(dòng)后60秒后閃退問(wèn)題，上線前跑下騰訊優(yōu)測(cè)，就能避免帶到 線上。12%TOP崩潰30%8%5%5% 5%47%java.lang.NullPointerExceptionjava.lang.ClassNotFoundExceptionjava.lang.IllegalArgumentExceptionandroid.view.WindowManager$BadTokenExcepti

8、onjava.lang.IllegalStateException其他10.00%9.00%8.00%7.00%6.00%5.00%4.00%3.00%2.00%1.00%0.00%1112131415161718191 101 111 121 131 141 151 161 171接入Bugly后，崩潰率下降的趨勢(shì)接入天數(shù)大產(chǎn)品（DAU1萬(wàn)）中小產(chǎn)品（DAU1萬(wàn)）崩潰有救二、崩潰分析實(shí)戰(zhàn)優(yōu)先修復(fù)Top問(wèn)題、不要對(duì)ANR視而不見(jiàn)、善用輔助信息和高級(jí)搜索看懂問(wèn)題ISSUEBugly自動(dòng)把相似的Crash歸類(lèi)為同個(gè)issueCRASH歸類(lèi)并不容易只考慮堆棧是否樣的歸類(lèi)算法是遠(yuǎn)遠(yuǎn)不夠的修復(fù)TOP的問(wèn)題迅速降低CRASH率迅速降低Crash率的竅門(mén)：修復(fù)每個(gè)版本的Top Issue（Top 100 issue 歸類(lèi)了80% Crash）看懂BUGLY的JAVA?？炊瓸UGLY的NATIVE棧不好定位的崩潰實(shí)戰(zhàn)OOM錯(cuò)誤堆棧幫不上忙的時(shí)候OOMSOF全系統(tǒng)棧.通過(guò)輔助信息進(jìn)行定位通過(guò)其它線程的堆棧進(jìn)行定位把它當(dāng)崩潰來(lái)分析你就錯(cuò)了它是ANR誘導(dǎo)的系統(tǒng)代碼的崩潰，想解決它必須去解決ANR把它當(dāng)崩潰來(lái)分析就錯(cuò)了既然是ANR，那就看看main線程在干啥？