Android 程序崩潰之快速鎖定!

前言

從剛開始接觸Android開發，第一次發版，遇到程序崩潰，那就一個慌張。好幾年過去了，現在的聽到程序崩潰？嗯，稍等我看看什么問題，然后該鎖定該鎖定該解決解決。

發版前減少bug、崩潰等，發版后遇到bug、崩潰也不要慌張，畢竟 bug不 會因為你的慌張而自動修復對吧？要以最快的速度解決(解決問題同樣是能力的體現)，并說明問題輕重，看看是直接發版還是坐等下次。同時，吸取教訓避免同樣問題發生。

今天咱們就聊聊Android程序閃退。一個應用的崩潰率高低，決定了這個應用的質量。

為了解決崩潰問題，Android 系統會輸出各種相應的 log 日志，當然還各式各樣的三方庫，大程度上降低了工程師鎖定崩潰問題的難度。

如果要給 crash 日志進行分類，可以分成 2 大類：

JVM 異常（Exception）堆棧信息，如下：

native 代碼崩潰日志，如下：

JVM 異常堆棧信息

Java 中異常（Exception）分兩種:

檢查異常 checked Exception。

非檢查異常 unchecked Exception。

檢查異常：就是在代碼編譯時期，Android Studio 就會提示代碼有錯誤，無法通過編譯，比如 InterruptedException。如果我們沒有在代碼中將這些異常 catch，而是直接拋出，最終也有可能導致程序崩潰。

try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } 復制代碼

非檢查異常：包括 error 和運行時異常(RuntimeException)，Android Studio 并不會在編譯時期提示這些異常信息，而是在程序運行時期因為代碼錯誤而直接導致程序崩潰，比如 OOM 或者空指針異常（NullPointerException）。

2021-09-13 11:50:27.327 19984-19984/com.scc.demo E/AndroidRuntime: FATAL EXCEPTION: main Process: com.scc.demo, PID: 19984 java.lang.RuntimeException: Unable to start activity ComponentInfo{com.scc.demo/com.scc.demo.actvitiy.HandlerActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.widget.Button.setOnClickListener(android.view.View$OnClickListener)' on a null object reference ... Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.widget.Button.setOnClickListener(android.view.View$OnClickListener)' on a null object reference at com.scc.demo.actvitiy.HandlerActivity.onCreate(HandlerActivity.java:41) at android.app.Activity.performCreate(Activity.java:8000) ... 復制代碼

Java 異常

對于上述兩種異常我們都可以使用 UncaughtExceptionHandler 來進行捕獲操作，它是 Thread 的一個內部接口，定義如下：

public interface UncaughtExceptionHandler { /** * 當給定Thread由于給定的Throwable而終止時調用的方法。 * 此方法拋出的任何異常都將被 Java 虛擬機忽略。 * @param t Thread * @param e Throwable */ void uncaughtException(Thread t, Throwable e); } 復制代碼

從官方對其介紹能夠看出，對于傳入的 Thread，如果因為"未捕獲"異常而導致被終止，uncaughtException 則會被調用。我們可以借助它來間接捕獲程序異常，并進行異常信息的記錄工作，或者給出更友好的異常提示信息。

自定義異常處理類

1.收集 crash 現場的相關信息，如當前 App 的版本信息，設備的相關信息以及異常信息。

2.日志的記錄工作(如保存在本地)，等開發人員排查問題或等下次啟動APP上傳至服務器。

自定義異常處理類

自定義類實現 UncaughtExceptionHandler 接口，并實現 uncaughtException 方法：

public class SccExceptionHandler implements Thread.UncaughtExceptionHandler { private Thread.UncaughtExceptionHandler mDefaultHandler; private static SccExceptionHandler sccExceptionHandler; private Context mContext; public static SccExceptionHandler getInstence() { if (sccExceptionHandler == null) { synchronized (SccExceptionHandler.class) { sccExceptionHandler = new SccExceptionHandler(); } } return sccExceptionHandler; } public void init(Context context) { mContext = context; //系統默認未捕獲異常handler //the default uncaught exception handler for all threads mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler(); //將當前Handler設為系統默認 Thread.setDefaultUncaughtExceptionHandler(this); } @Override public void uncaughtException(@NonNull @NotNull Thread t, @NonNull @NotNull Throwable e) { if (!handlerUncaughtException(e) && mDefaultHandler != null) { //注釋1:系統處理 mDefaultHandler.uncaughtException(t, e); } else { //注釋2:自己處理 Intent intent = new Intent(mContext, ImageViewActivity.class); intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK|Intent.FLAG_ACTIVITY_CLEAR_TASK); mContext.startActivity(intent); //終止進程 android.os.Process.killProcess(android.os.Process.myPid()); //終止當前運行的 Java 虛擬機。 //參數用作狀態代碼； 按照慣例，非零狀態代碼表示異常終止。 System.exit(0); } } //處理程序未捕獲異常 private boolean handlerUncaughtException(Throwable e) { //1.收集 crash 現場的相關信息，如當前 App 的版本信息，設備的相關信息以及異常信息。 //2.日志的記錄工作(如保存在本地)，等開發人員排查問題或等下次啟動APP上傳至服務器。 return true; //不想處理 return false; } } 復制代碼

注釋1：在自定義異常處理類中需要持有線程默認異常處理類。這樣做的目的是在自定義異常處理類無法處理或者處理異常失敗時，還可以將異常交給系統做默認處理。

注釋2：如果自定義異常處理類成功處理異常，需要進行頁面跳轉，或者將程序進程"殺死"。否則程序會一直卡死在崩潰界面，并彈出無響應對話框。

android.os.Process.myPid()：返回此進程的標識符，可與 killProcess 和 sendSignal 一起使用。

android.os.Process.killProcess(android.os.Process.myPid())：使用給定的 PID 終止進程。 請注意，盡管此 API 允許我們根據其 PID 請求終止任何進程，但內核仍會對您實際能夠終止的 PID 施加標準限制。 通常這意味著只有運行調用者的包/應用程序的進程和由該應用程序創建的任何其他進程； 共享一個通用 UID 的包也將能夠殺死彼此的進程。

使用自定義異常處理類

SccExceptionHandler 定義好之后，就可以將其初始化，并將主線程注冊到 SccExceptionHandler 中。如下：

public class SccApp extends Application { @Override public void onCreate() { super.onCreate(); SccExceptionHandler.getInstence().init(this); } } 復制代碼

native 異常

當程序中的 native 代碼發生崩潰時，系統會在 /data/tombstones/ 目錄下保存一份詳細的崩潰日志信息。由于對 native 還不是很熟悉就不誤導大家，感興趣的自己玩玩。

對于程序崩潰信號機制的介紹，可以參考騰訊的這篇文章：Android 平臺 Native 代碼的崩潰捕獲機制及實現

線上崩潰日志獲取

上面介紹的 Java 和 Native 崩潰的捕獲都是基于自己能夠復現 bug 的前提下。但是對于線上的用戶，這種操作方式是不太現實的。

對于大多數公司來說，針對線上版本，沒有必要自己實現一個抓取 log 的平臺系統。最快速的實現方式就是集成第三方 SDK。目前比較成熟，采用也比較多的就是騰訊的 Bugly。

Bugly

Bugly 基本能夠滿足線上版本捕獲 crash 的所有需求，包括 Java 層和 Native 層的 crash 都可以獲取相應的日志。并且每天 Bugly 都會郵件通知上一天的崩潰日志，方便測試和開發統計 bug 的分布以及崩潰率。

接入文檔

異常概括

崩潰分析

程序崩潰分析這塊我沒做調整，這個是bugly自動抓取的。

錯誤分析

這里我用來存放去服務端請求接口時的參數和返回的數據。，下面看看具體效果。

使用起來相當方便，而且錯誤還提供解決方案，美滋滋。

xCrash

xCrash 能為安卓 app 提供捕獲 java 崩潰，native 崩潰和 ANR 的能力。不需要 root 權限或任何系統權限。

xCrash 能在 app 進程崩潰或 ANR 時，在你指定的目錄中生成一個 tombstone 文件（格式與安卓系統的 tombstone 文件類似）。

xCrash 已經在 愛奇藝 的不同平臺（手機，平板，電視）的很多安卓 app（包括愛奇藝視頻）中被使用了很多年。

xCrash傳送門

Sentry

Sentry 是一項可幫助您實時監控和修復崩潰的服務。 服務器使用 Python，但它包含一個完整的 API，用于在任何應用程序中從任何語言發送事件。

Sentry傳送門

XCrash 和 Sentry，這兩者比 Bugly 好的地方就是除了自動攔截界面崩潰事件，還可以主動上報錯誤信息。

可以看出 XCrash 的使用更加靈活，工程師的掌控性更高。可以通過設置不同的過濾方式，針對性地上報相應的 crash 日志。并且在捕獲到 crash 之后，可以加入自定義的操作，比如本地保存日志或者直接進行網絡上傳等。

另外：Sentry 還有一個好處就是可以通過設置過濾，來判斷是否上報 crash 日志。這對于 SDK 的開發人員是很有用的。比如一些 SDK 的開發商只是想收集自身 SDK 引入的 crash，對于用戶的其他操作導致的 crash 進行過濾，這種情況就可以考慮集成 Sentry。

Bugly 簡單使用

感覺教程亂的可以自己去上文找Buyle文檔自己集成，很簡單的。

庫文件導入

自動集成（推薦）

plugins { id 'com.android.application' } android { compileSdkVersion 30//項目的編譯版本 defaultConfig { applicationId "com.scc.demo"http://包名 minSdkVersion 23//最低的兼容的Android系統版本 targetSdkVersion 30//目標版本，表示你在該Android系統版本已經做過充分的測試 versionCode 1//版本號 versionName "1.0.0"http://版本名稱 ndk { abiFilters 'armeabi-v7a', 'arm64-v8a','x86' //運行環境，要上傳Google Play必須兼容64位，這里僅兼容ARM架構 //對于ARM架構，32 位庫位于armeabi-v7a 中。64 位等效項是arm64-v8a。 //對于x86體系結構，查找x86（用于 32 位）和 x86_64（用于 64 位）。 } } } dependencies { implementation 'com.tencent.bugly:crashreport:3.4.4' //集成Bugly NDK時，需要同時集成Bugly SDK。 implementation 'com.tencent.bugly:nativecrashreport:3.9.2' } 復制代碼

注意：自動集成時會自動包含Bugly SO庫，建議在Module的build.gradle文件中使用NDK的"abiFilter"配置，設置支持的SO庫架構。

如果在添加"abiFilter"之后Android Studio出現以下提示：

NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin.

則在項目根目錄的gradle.properties文件中添加：

android.useDeprecatedNdk=true

參數配置

在AndroidManifest.xml中添加權限：

復制代碼

注意：如果您的App需要上傳到Google Play Store，您需要將READ_PHONE_STATE權限屏蔽掉或者移除，否則可能會被下架。

請避免混淆Bugly，在Proguard混淆文件中增加以下配置：

-dontwarn com.tencent.bugly.** -keep public class com.tencent.bugly.**{*;} 復制代碼

初始化

public class SccApp extends Application { @Override public void onCreate() { super.onCreate(); //70594a1ff8 Bugly新建產品的 App ID CrashReport.initCrashReport(getApplicationContext(), "70594a1ff8", false); } } 復制代碼

錯誤分析

private void setCrashReport(String url, String name, Map params, String message) { try { if (params != null && !MStringUtils.isNullOrEmpty(url) && !MStringUtils.isNullOrEmpty(name) && !MStringUtils.isNullOrEmpty(params.toString()) && !MStringUtils.isNullOrEmpty(message)) { CrashReport.putUserData(AppGlobalUtils.getApplication(), "SccParams", params.toString()); CrashReport.putUserData(AppGlobalUtils.getApplication(), "Data", "LoginName-Scc001:" + message); CrashReport.postCatchedException(new RuntimeException(name + ":" + url + ":" + message)); } } catch (Exception e) { } } 復制代碼

HashMap hashMap = new HashMap<>(); hashMap.put("name","scc001"); hashMap.put("pass","111111"); String returnData = "哈哈哈哈哈"; setCrashReport("loin/register","Main",hashMap,returnData); 復制代碼

錯誤列表

錯誤詳情

出錯堆棧

跟蹤數據

崩潰分析

這個不用咱自己設置，Bugly自動抓取，下面提供跟錯誤分析類似功能這里就不多描述了。

本文內容到這里就算結束了。希望能幫你快速鎖定 bug 并解決，讓應用更完美，讓你的老板更放心，票票來的更多一些。

Android iOS 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。