前言
從剛開始接觸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 則會被呼叫,我們可以借助它來間接捕獲程式例外,并進行例外資訊的記錄作業,或者給出更友好的例外提示資訊,
自定義例外處理類
自定義例外處理類
自定義類實作 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 簡單使用
感覺教程亂的可以自己去上文找Bugle檔案自己集成,很簡單的,
庫檔案匯入
自動集成(推薦)
plugins {
id 'com.android.application'
}
android {
compileSdkVersion 30//專案的編譯版本
defaultConfig {
applicationId "com.scc.demo"//包名
minSdkVersion 23//最低的兼容的Android系統版本
targetSdkVersion 30//目標版本,表示你在該Android系統版本已經做過充分的測驗
versionCode 1//版本號
versionName "1.0.0"//版本名稱
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 {
//其中latest.release指代最新Bugly SDK版本號,也可以指定明確的版本號,例如2.1.9
implementation 'com.tencent.bugly:crashreport:latest.release'
//其中latest.release指代最新Bugly NDK版本號,也可以指定明確的版本號,例如3.0
//集成Bugly NDK時,需要同時集成Bugly SDK,
implementation 'com.tencent.bugly:nativecrashreport:latest.release'
}
注意:自動集成時會自動包含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
初始化
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<String, String> 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<String,String> hashMap = new HashMap<>();
hashMap.put("name","scc001");
hashMap.put("pass","111111");
String returnData = "哈哈哈哈哈";
setCrashReport("loin/register","Main",hashMap,returnData);
效果
錯誤串列

錯誤詳情

出錯堆疊

跟蹤資料

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

?
本文內容到這里就算結束了,希望能幫你快速鎖定 bug 并解決,讓應用更完美,讓你的老板更放心,票票來的更多一些,
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/300281.html
標籤:其他
