近期，著手對(duì)bugly上的anr 處理，記錄下優(yōu)化的方向。
借用網(wǎng)上的一張圖：
這里的anr 問(wèn)題是屬于主線程的call 耗時(shí)操作。需要使用trace 來(lái)獲取發(fā)生anr前一些列的耗時(shí)方法調(diào)用時(shí)間，再次梳理業(yè)務(wù)，才可能解決。
問(wèn)題1
java 調(diào)用棧：
從調(diào)用棧中發(fā)現(xiàn)onActivityResult()執(zhí)行對(duì)游戲側(cè)的初始化會(huì)造成anr。
因靠打印是不準(zhǔn)確，存在多線程搶占cpu的緣故，因此考慮通過(guò)獲取trace來(lái)記錄方法的真正執(zhí)行時(shí)間。
記錄oppo渠道包的冷啟動(dòng)到登錄頁(yè)面的sample trace文件，總覽trace中存在的耗時(shí)點(diǎn)：這里查看主線程中執(zhí)行方法。
淡綠色是app中的代碼，長(zhǎng)方形占用面積越大，越耗時(shí)。
查看onActvityResult的邏輯執(zhí)行時(shí)間：
發(fā)現(xiàn)Show_GLView()執(zhí)行耗時(shí)最多，其中NativeInit（）函數(shù)中調(diào)用若干方法，游戲C++層初始化了一大堆的邏輯。
問(wèn)題2
anr發(fā)生的調(diào)用棧
通過(guò)調(diào)用棧oppo渠道中發(fā)現(xiàn)onResume執(zhí)行對(duì)渠道初始化發(fā)生anr。
通過(guò)trace,來(lái)看下onResume中執(zhí)行時(shí)間：
發(fā)現(xiàn)，onResume中初始化聚合渠道任務(wù)初始化，耗時(shí)100多毫秒。該任務(wù)可能并不是真正引起anr的真兇，可能是onActivityResult（）耗時(shí)過(guò)多，間接導(dǎo)致onResume()過(guò)程中被系統(tǒng)判定anr。
方案優(yōu)化
耗時(shí)任務(wù)的解決有三種方式：
- 將耗時(shí)任務(wù)放到異步線程中執(zhí)行
- 將耗時(shí)任務(wù) lazy延后策略執(zhí)行或者 提前選擇空閑時(shí)間執(zhí)行。
當(dāng)界面1 跳轉(zhuǎn)其他界面2后，當(dāng)界面2調(diào)用finish（）銷(xiāo)毀時(shí):
先執(zhí)行界面2的onStop()–>界面1的onActivityResult()->界面1的onResume()–>界面2的onstop()–>界面2的onDestroy()。
嘗試將nativeInit（）和Show_GLView_Two() 放到onActvivityResult()和onResume（）之后執(zhí)行。為了不阻塞onResume（）執(zhí)行，利用hanlde的空閑機(jī)制：
在onActivityResult之后執(zhí)行空閑任務(wù)：
Onresume 之后添加延遲任務(wù)：
按照以上調(diào)整邏輯，再次編譯渠道包，來(lái)看下優(yōu)化效果
優(yōu)化效果
查看onActivityResult（）中onResume（）執(zhí)行時(shí)間：
同時(shí)也反饋給游戲側(cè)c++層的同事，初始化根據(jù)業(yè)務(wù)，進(jìn)行延遲、異步等操作細(xì)分調(diào)用時(shí)間。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-611100.html
資料借鑒：文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-611100.html
- https://www.zhihu.com/tardis/bd/art/552305686?source_id=1001
到了這里，關(guān)于Android性能優(yōu)化之游戲引擎初始化ANR的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
