Android 性能優化-ANR 的原因和解決方案

1、出現 ANR 的情況

滿足下面的一種情況系統就會彈出 ANR 提示

輸入事件(按鍵和觸摸事件) 5s 内沒被處理；
BroadcastReceiver 的事件 ( onRecieve() 方法) 在規定時間内沒處理完 (前台廣播為 10s，背景廣播為 60s)；
Service 前台 20s 背景 200s 未完成啟動；
ContentProvider 的 publish() 在 10s 内沒進行完。

通常情況下就是主線程被阻塞造成的。

2、ANR 的實作原理

以輸入無響應的過程為例（基于 9.0 代碼）：

最終彈出 ANR 對話框的位置是與 AMS 同目錄的類

AppErrors

的

handleShowAnrUi()

方法。這個類用來處理程式中出現的各種錯誤，不隻 ANR，強行 Crash 也在這個類中處理。

// base/core/java/com/android/server/am/AppErrors.java
    void handleShowAnrUi(Message msg) {
        Dialog dialogToShow = null;
        synchronized (mService) {
            AppNotRespondingDialog.Data data = (AppNotRespondingDialog.Data) msg.obj;
            // ...

            Intent intent = new Intent("android.intent.action.ANR");
            if (!mService.mProcessesReady) {
                intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY
                        | Intent.FLAG_RECEIVER_FOREGROUND);
            }
            mService.broadcastIntentLocked(null, null, intent,
                    null, null, 0, null, null, null, AppOpsManager.OP_NONE,
                    null, false, false, MY_PID, Process.SYSTEM_UID, 0 /* TODO: Verify */);

            boolean showBackground = Settings.Secure.getInt(mContext.getContentResolver(),
                    Settings.Secure.ANR_SHOW_BACKGROUND, 0) != 0;
            if (mService.canShowErrorDialogs() || showBackground) {
                dialogToShow = new AppNotRespondingDialog(mService, mContext, data);
                proc.anrDialog = dialogToShow;
            } else {
                MetricsLogger.action(mContext, MetricsProto.MetricsEvent.ACTION_APP_ANR,
                        AppNotRespondingDialog.CANT_SHOW);
                // Just kill the app if there is no dialog to be shown.
                mService.killAppAtUsersRequest(proc, null);
            }
        }
        // If we've created a crash dialog, show it without the lock held
        if (dialogToShow != null) {
            dialogToShow.show();
        }
    }

不過從發生 ANR 的地方調用到這裡要經過很多的類和方法。最初抛出 ANR 是在

InputDispatcher.cpp

中。我們可以通過其中定義的常量來尋找最初觸發的位置：

// native/services/inputflinger/InputDispatcher.cpp
constexpr nsecs_t DEFAULT_INPUT_DISPATCHING_TIMEOUT = 5000 * 1000000LL; // 5 sec

從這個類觸發的位置會經過層層傳遞達到

InputManagerService

中

// base/services/core/java/com/android/server/input/InputManagerService.java
    private long notifyANR(InputApplicationHandle inputApplicationHandle,
            InputWindowHandle inputWindowHandle, String reason) {
        return mWindowManagerCallbacks.notifyANR(
                inputApplicationHandle, inputWindowHandle, reason);
    }

這裡的

mWindowManagerCallbacks

就是

InputMonitor

：

// base/services/core/java/com/android/server/wm/InputMonitor.java
    public long notifyANR(InputApplicationHandle inputApplicationHandle,
            InputWindowHandle inputWindowHandle, String reason) {
        // ... 略

        if (appWindowToken != null && appWindowToken.appToken != null) {
            final AppWindowContainerController controller = appWindowToken.getController();
            final boolean abort = controller != null
                    && controller.keyDispatchingTimedOut(reason,
                            (windowState != null) ? windowState.mSession.mPid : -1);
            if (!abort) {
                return appWindowToken.mInputDispatchingTimeoutNanos;
            }
        } else if (windowState != null) {
            try {
                // 使用 AMS 的方法
                long timeout = ActivityManager.getService().inputDispatchingTimedOut(
                        windowState.mSession.mPid, aboveSystem, reason);
                if (timeout >= 0) {
                    return timeout * 1000000L; // nanoseconds
                }
            } catch (RemoteException ex) {
            }
        }
        return 0; // abort dispatching
    }

然後回在上述方法調用 AMS 的

inputDispatchingTimedOut()

方法繼續處理，并最終在

inputDispatchingTimedOut()

方法中将事件傳遞給

AppErrors

// base/services/core/java/com/android/server/am/ActivityManagerService.java
    public boolean inputDispatchingTimedOut(final ProcessRecord proc,
            final ActivityRecord activity, final ActivityRecord parent,
            final boolean aboveSystem, String reason) {
        // ...

        if (proc != null) {
            synchronized (this) {
                if (proc.debugging) {
                    return false;
                }

                if (proc.instr != null) {
                    Bundle info = new Bundle();
                    info.putString("shortMsg", "keyDispatchingTimedOut");
                    info.putString("longMsg", annotation);
                    finishInstrumentationLocked(proc, Activity.RESULT_CANCELED, info);
                    return true;
                }
            }
            mHandler.post(new Runnable() {
                @Override
                public void run() {
                    // 使用 AppErrors 繼續處理
                    mAppErrors.appNotResponding(proc, activity, parent, aboveSystem, annotation);
                }
            });
        }

        return true;
    }

當事件傳遞到了

AppErrors

之後，它會借助 Handler 處理消息也就調用了最初的那個方法并彈出對話框。

參考：《Android ANR原理分析》

3、ANR 的解決辦法

上面分析了 ANR 的成因和原理，下面我們分析下如何解決 ANR.

1. 使用 adb 導出 ANR 日志并進行分析

發生 ANR的時候系統會記錄 ANR 的資訊并将其存儲到

/data/anr/traces.txt

檔案中（在比較新的系統中會被存儲都

/data/anr/anr_*

檔案中）。我們可以使用下面的方式來将其導出到電腦中以便對 ANR 産生的原因進行分析：

adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>

在筆者分析 ANR 的時候使用上述指令嘗試導出 ANR 日志的時候都出現了 Permission Denied。此時，你可以将手機 Root 之後導出，或者嘗試修改檔案的讀寫權限，或者在開發者模式中選擇将日志導出到 sdcard 之後再從 sdcard 将日志發送到電腦端進行檢視

2. 使用 DDMS 的 traceview 進行分析

在 AS 中打開 DDMS，或者到 SDK 安裝目錄的 tools 目錄下面使用

monitor.bat

打開 DDMS。

TraceView 工具的使用可以參考這篇文章：《Android 性能分析之TraceView使用(應用耗時分析)》

這種定位 ANR 的思路是：使用 TraceView 來通過耗時方法調用的資訊定位耗時操作的位置。

資料：

《ANR 官方文檔》
《Android 性能分析之TraceView使用(應用耗時分析)》

3. 使用開源項目 ANR-WatchDog 來檢測 ANR

項目位址是 Github-ANR-WatchDog

該項目的實作原理：建立一個檢測線程，該線程不斷往 UI 線程 post 一個任務，然後睡眠固定時間，等該線程又一次起來後檢測之前 post 的任務是否運作了，假設任務未被運作，則生成 ANRError，并終止程序。

4. 常見的 ANR 場景

I/O 阻塞
網絡阻塞
多線程死鎖
由于響應式程式設計等導緻的方法死循環
由于某個業務邏輯執行的時間太長

5. 避免 ANR 的方法

UI 線程盡量隻做跟 UI 相關的工作；
耗時的工作 (比如資料庫操作，I/O，網絡操作等)，采用單獨的工作線程處理；
用 Handler 來處理 UI 線程和工作線程的互動；
使用 RxJava 等來處理異步消息。

總之，一個原則就是：不在主線程做耗時操作。

附錄

新版的 AS 中移除了一些工具，并且給出了一些替代性的方案，可以參考下面的?進行了解：https://developer.android.com/studio/profile/monitor

Android 性能優化-ANR 的原因和解決方案

1、出現 ANR 的情況

2、ANR 的實作原理

3、ANR 的解決辦法

1. 使用 adb 導出 ANR 日志并進行分析

2. 使用 DDMS 的 traceview 進行分析

3. 使用開源項目 ANR-WatchDog 來檢測 ANR

4. 常見的 ANR 場景

5. 避免 ANR 的方法

附錄

繼續閱讀

與專家面對面：Android開發入門問與答

Android MVP架構MVCMVP

mvp初探

Android常用工具類簡介目錄

android常用工具類轉載自：http://www.trinea.cn/android/android-common-utils/Android常用工具類

Android常用工具類ToastUtilsSizeUtilsLogUtilsRetrofitManagerAnimUtil

php的運作模式

Android Studio 0.8.0解決 Failure [INSTALL_FAILED_OLDER_SDK] 問題

Android – ListView 中添加按鈕，動态删除添加ItemView的操作

Kotlin的ListView與RecyclerView的簡單應用

關于公司的那些坑：Android Studio篇

android SQLite事務和kotlin協程

無法正常編譯錯誤Compilation failed to complete

關于Gradle配置的小結

AOP程式設計_Android優雅權限架構(1)概念基礎，2021金三銀四前言正文大綱正文

Android APK檔案反編譯Android APK檔案反編譯