轉載請注明出處：https://blog.csdn.net/weixin_42072033/article/details/109622923
大家好，今天給大家帶來Android系統ANR錯誤實戰分析，在開始之前請允許我說幾句不相干的話，
我叫麻錦榮，你們叫我錦榮就好了，在深圳從接觸Android到現在已經有7個年頭了，從最早的ADT（那會兒還沒有AS）開發app，到后來定制手機ROM，再到智能家居，智能硬體，車載產品，電視機，商顯等Android開發作業，一路走來深感Android的發展迅速，對于Android程式員的要求也從APP開發提高到系統Framework層，機器學習，機器視覺等更廣的領域，一路上，我碰到過無數的難題，相信以后也一樣會碰到，但是互聯網的知識共享給了我力量，成為了我前進道路上的好幫手，但是我卻以作業太忙或者其他的借口，其實就是自己的懶散為由從來沒有把自己開發中的心得分享給大家，共同學習，共同進步，這是我第一篇博客，很多表達或許詞不達意，但是我相信萬事開頭難，以后一定會漸入佳境，
好了，廢話就說這么多，下面開始進入今天的主題吧，相信看完這篇文章的你對ANR問題的解決又會更加充滿信心，
Android開發中經常碰到一個叫做ANR（Application Not Responding）的問題，如果這個apk是你們自己開發的，報ANR，有經驗的程式員自己肯定會較為容易的檢查出代碼哪里出了問題，好，那么問題來了，如果是原廠（MTK，全志，RK，amlogic等）系統報出ANR，我們怎么解決？下面就用我公司實際碰到的問題為例，為大家實戰講解，
相信大家都知道有個東西叫小部件Widget，我們手機上的時鐘小部件可以選擇大小，開機的時候加載到我們的桌面上顯示時間，前幾天公司發現一個bug，直接上圖，
如圖，時鐘Widget一直顯示正在加載，幾分鐘后依然不顯示時間，抓取log，發現ANR錯誤，如下：
使用的板子和原始碼均為amlogic平臺，Android版本為9.0 ， 由于是編譯完直接燒錄，可以100%確定是由原始碼引起ANR，從log資訊看，似乎是com.android.phone 這個應用包下的VvmSimStateTracker這個類引起的，那是這樣么？我們找到這個類
可以看出，VvmSimStateTracker就是一個廣播接收器，就是用來監聽一些sim卡熱插拔的工具類，從剛才的log中看，是由于開機廣播的處理出現了問題導致ANR，好，那么我們把這個android.intent.action.BOOT_COMPLETED給它注釋掉，編譯，看下結果，結果發現竟然正常了，時鐘部件開機5秒內正常顯示時間，好多人有疑問了，為什么只是簡單接收了一個開機廣播，就報ANR了呢？我們又不是第一天接收它了，留個疑問在這里，
Android中，主執行緒(UI執行緒)如果在規定時內沒有處理完相應作業，就會出現ANR，具體來說，ANR會在以下幾種情況中出現：
- 輸入事件(按鍵和觸摸事件)5s內沒被處理: Input event dispatching timed out
- BroadcastReceiver的事件(onRecieve方法)在規定時間內沒處理完(前臺廣播為10s，后臺廣播為60s)：Timeout of broadcast BroadcastRecord
07-27 19:18:47.448 1707 1766 W BroadcastQueue: Receiver during timeout: ResolveInfo{ccd831e com.example.qintong.myapplication/.MyBroadCastReciever m=0x108000}
07-27 19:18:47.502 3513 3728 I WtEventController: ANR com.example.qintong.myapplication 7573 - service 前臺20s后臺200s未完成啟動 Timeout executing service
- ContentProvider的publish在10s內沒進行完：timeout publishing content providers
看完這個很多人就會恍然大悟，第二條這個報的錯和上面日志的那個不是一樣么
那這下原因找到了，就是因為UI執行緒阻塞導致了VvmSimStateTracker類沒有在規定時間內處理完BroadcastReceiver事件，^_^ 那問題又來了，UI執行緒為什么會阻塞？誰把它搞阻塞了？這里我就要告訴大家怎么分析解決系統ANR，
首先，adb shell 進入 data/system 目錄下會看到一個叫做dropbox 的檔案夾（adb操作我就不多贅述了，可以查看其他博客）
只要你的Android系統出現ANR或者Crash等，系統就會保存日志到這個檔案夾中，對你分析問題的產生有巨大幫助，話不多說，我們把這個dropbox拷出來，看看里面的內容
好家伙，東西還挺多，可以看到里面有很多的日志，那么我們所需要分析ANR的日志正是 system_app_anr@*******.txt.gz，不同平臺的命名規則可能大同小異，總之大家看anr這幾個關鍵字就可以了，解壓，打開看看，
前面幾行我們剛才見過了，下面紅色標注的這里就是系統在發生ANR時CPU的實時使用情況
可以看到，我們的CPU在發生ANR 的時候總共才使用了12%左右的性能，這里要注意了，
1.如果發生ANR的行程CPU占用較高，如到了80%或90%以上，則可以懷疑是應用內一些代碼不合理消耗掉了CPU資源，比如死回圈或者一些演算法庫進行大量高精度復雜運算導致CPU長期占用較高，這就要結合trace和ANR前后的log進一步分析了，
2.如果某些行程的CPU占用百分比較高，幾乎占用了所有CPU資源，而發生ANR的行程CPU占用為0%或非常低，則認為CPU資源被占用，行程沒有被分配足夠的資源，從而發生了ANR，這種情況多數可以認為是系統狀態的問題，并不是由本應用造成的，
3.如果CPU總用量不高，那么很有可能是一些耗時操作或者鎖的問題使主執行緒被阻塞 ，導致ANR，
4.如果iowait 占用率過高，很可能是系統等待I/O耗時操作，導致ANR，
這里我們明顯看到CPU使用情況在各項指標中都表現正常，那么我們懷疑是第三條，也就是一些耗時操作或者鎖的問題使主執行緒被阻塞 ，既然懷疑是主執行緒阻塞，那么我們往下看，找到主執行緒的相關日志，
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 flags=1 obj=0x75429ee0 self=0xaea49000
| sysTid=4078 nice=0 cgrp=default sched=0/0 handle=0xb2d34494
| state=S schedstat=( 168928298 466851782 531 ) utm=6 stm=10 core=0 HZ=100
| stack=0xbb365000-0xbb367000 stackSize=8MB
| held mutexes=
native: #00 pc 00019d58 /system/lib/libc.so (syscall+32)
native: #01 pc 0001d215 /system/lib/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+88)
native: #02 pc 000633b1 /system/lib/libc.so (pthread_cond_timedwait+84)
native: #03 pc 0004a005 /system/lib/libc++.so (_ZNSt3__118condition_variable15__do_timed_waitERNS_11unique_lockINS_5mutexEEENS_6chrono10time_pointINS5_12system_clockENS5_8durationIxNS_5ratioILx1ELx1000000000EEEEEEE+124)
native: #04 pc 0001ebf1 /system/lib/libhidltransport.so (android::hardware::details::Waiter::wait()+224)
native: #05 pc 0001f31f /system/lib/libhidltransport.so (android::hardware::details::getRawServiceInternal(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, bool, bool)+826)
native: #06 pc 000b07c5 /system/lib/libandroid_runtime.so (JHwBinder_native_getService(_JNIEnv*, _jclass*, _jstring*, _jstring*, unsigned char)+168)
at android.os.HwBinder.getService(Native method)
at android.hardware.radio.V1_0.IRadio.getService(IRadio.java:40)
at com.android.internal.telephony.RIL.getRadioProxy(RIL.java:369)
at com.android.internal.telephony.RIL.getHardwareConfig(RIL.java:3367)
at com.android.internal.telephony.TelephonyDevController.registerRIL(TelephonyDevController.java:112)
at com.android.internal.telephony.RIL.<init>(RIL.java:484)
at com.android.internal.telephony.PhoneFactory.makeDefaultPhone(PhoneFactory.java:172)
- locked <0x051877b9> (a java.lang.Object)
at com.android.internal.telephony.PhoneFactory.makeDefaultPhones(PhoneFactory.java:99)
at com.android.phone.PhoneGlobals.onCreate(PhoneGlobals.java:286)
at com.android.phone.PhoneApp.onCreate(PhoneApp.java:41)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1154)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5871)
at android.app.ActivityThread.access$1100(ActivityThread.java:199)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1650)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)"main" 這個標志就代表主執行緒的相關日志，我們看到在 PhoneFactory 類中 makeDefaultPhone方法是有Object物件鎖的，不急，我們找到日志中顯示的幾個類看看，
PhoneApp類 onCreate 時會呼叫 PhoneGlobals的 onCreate
public class PhoneApp extends Application {
PhoneGlobals mPhoneGlobals;
TelephonyGlobals mTelephonyGlobals;
public PhoneApp() {
}
@Override
public void onCreate() {
if (UserHandle.myUserId() == 0) {
// We are running as the primary user, so should bring up the
// global phone state.
mPhoneGlobals = new PhoneGlobals(this);
mPhoneGlobals.onCreate();
mTelephonyGlobals = new TelephonyGlobals(this);
mTelephonyGlobals.onCreate();
}
}
}
PhoneGlobals類 onCreate時會呼叫 PhoneFactory類的 makeDefaultPhones
public void onCreate() {
if (VDBG) Log.v(LOG_TAG, "onCreate()...");
ContentResolver resolver = getContentResolver();
// Cache the "voice capable" flag.
// This flag currently comes from a resource (which is
// overrideable on a per-product basis):
sVoiceCapable =
getResources().getBoolean(com.android.internal.R.bool.config_voice_capable);
// ...but this might eventually become a PackageManager "system
// feature" instead, in which case we'd do something like:
// sVoiceCapable =
// getPackageManager().hasSystemFeature(PackageManager.FEATURE_TELEPHONY_VOICE_CALLS);
if (mCM == null) {
// Initialize the telephony framework
PhoneFactory.makeDefaultPhones(this);
// Start TelephonyDebugService After the default phone is created.
Intent intent = new Intent(this, TelephonyDebugService.class);
startService(intent);
mCM = CallManager.getInstance();
for (Phone phone : PhoneFactory.getPhones()) {
mCM.registerPhone(phone);
}而PhoneFactory類的 makeDefaultPhones方法是有物件鎖的
那么問題迎刃而解，就是由于開機啟動的時候，PhoneApp類呼叫PhoneFactory類的makeDefaultPhones 方法，而makeDefaultPhones還是被物件鎖住的狀態，導致主執行緒阻塞，進而導致VvmSimStateTracker類沒有在規定時間內處理完開機廣播，發生ANR，那么我們試試解決這個問題，把PhoneAPP初始化操作放在一個子執行緒中去進行，
@Override
public void onCreate() {
if (UserHandle.myUserId() == 0) {
// We are running as the primary user, so should bring up the
// global phone state.
/* mPhoneGlobals = new PhoneGlobals(this);
mPhoneGlobals.onCreate();
mTelephonyGlobals = new TelephonyGlobals(this);
mTelephonyGlobals.onCreate(); */
new Thread(new Runnable() {
@Override
public void run() {
mPhoneGlobals = new PhoneGlobals(PhoneApp.this);
mPhoneGlobals.onCreate();
mTelephonyGlobals = new TelephonyGlobals(PhoneApp.this);
mTelephonyGlobals.onCreate();
}
}).start();
}
}編譯下，試試效果
開機5秒內時鐘部件正常顯示了時間，沒有ANR錯誤報出，問題解決，（這里篇幅過大就不做動圖了，后面的博客我盡量把動態圖加進去，使大家閱讀體驗更加好）
至此，我的第一篇博客就結束了，后續會給大家分享一些APK開發或者系統Framework層的一些問題，而且也會把代碼或者專案開源，放在GitHub上與大家一起分享，共同進步，希望我的文章對你們有所幫助，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/212199.html
標籤：其他
上一篇：面試必備：Android Activity啟動流程原始碼分析
下一篇：一個簡易的音頻播放器實作