跳到主要內容

Android Debug 之 Log 最佳實踐

本文微信公眾號「AndroidTraveler」首發。


背景


在開發過程中,調試是必不可少的一項工作。


當我們要確定項目的邏輯時,當我們要了解界面的生命周期時,當我們發現新寫的邏輯與期望效果不一致時,當我們覺得數據有問題時......


而調試有兩種方式:


第一種就是使用 debug 模式運行 APP,然後通過斷點讓程序運行到指定位置進行分析。


第二種就是打日誌的方式,通過觀察輸出來確定程序是否運行到該位置以及此時的數據。


本篇文章主要聚焦在第二種方式上面。


在 Android 裏面,打日誌使用的系統 API 是 Log,你以為直接使用就完了嗎?


封裝


假設你在需要打印日誌的地方直接使用系統的 API,那麼當遇到下面情況時,會「牽一發而動全身」。


場景一:如果我打印日誌要用三方庫的日誌 API,那麼我要查找項目所有使用位置,並一一替換。


場景二:如果我希望在開發環境下打印日誌,release 環境不打印,這個時候每個位置都需要單獨做處理。


因此我們需要在使用 Log 進行日誌打印之前,做一層封裝。


假設我們的類名字為 ZLog,代碼如下:


import android.util.Log;

/**
* Created on 2019-10-26
*
* @author Zengyu.Zhan
*/
public class ZLog {
public static int v(String tag, String msg) {
return Log.v(tag, msg);
}

public static int d(String tag, String msg) {
return Log.d(tag, msg);
}

public static int i(String tag, String msg) {
return Log.i(tag, msg);
}

public static int w(String tag, String msg) {
return Log.w(tag, msg);
}

public static int e(String tag, String msg) {
return Log.e(tag, msg);
}
}

這樣處理之後,對於場景一和場景二,我們需要修改的只是 ZLog 這個類,而不需要到具體使用 ZLog 的所有地方去修改。


提供日誌打印控制


我們知道,日誌打印可能包含敏感信息,而且過多的日誌打印可能影響 APP 的性能,因此我們一般是在開發時候打開日誌,在發布 APP 之前關閉。


因此我們這邊需要提供一個標誌位來控制日誌的打印與否。


import android.util.Log;

/**
* Created on 2019-10-26
*
* @author Zengyu.Zhan
*/
public class ZLog {
private static boolean isDebugMode = false;
public static void setDebugMode(boolean debugMode) {
isDebugMode = debugMode;
}

public static int v(String tag, String msg) {
return isDebugMode ? Log.v(tag, msg) : -1;
}

public static int d(String tag, String msg) {
return isDebugMode ? Log.d(tag, msg) : -1;
}

public static int i(String tag, String msg) {
return isDebugMode ? Log.i(tag, msg) : -1;
}

public static int w(String tag, String msg) {
return isDebugMode ? Log.w(tag, msg) : -1;
}

public static int e(String tag, String msg) {
return isDebugMode ? Log.e(tag, msg) : -1;
}
}

默認是不開啟日誌打印,避免開發者忘記設置。


普通日誌和奔潰棧系統日誌在控制台的輸出對比


現在我們在 APP 裏面使用 ZLog 打印日誌,代碼為:


ZLog.setDebugMode(true);
ZLog.e("ZLog", "just test");

輸出如下:



我們現在增加如下代碼:


String nullString = null;
if (nullString.equals("null")) {
}

運行之後控制台會显示空指針異常奔潰棧,如下:



可以看到奔潰棧信息會显示具體是哪個文件出現了空指針,以及具體哪一行。在我們這個例子裏面就是 MainActivity.java24 行。


而且點擊藍色鏈接光標會直接定位到錯誤位置。


如果我們普通的日誌也可以點擊就跳轉到對應位置,對於我們開發來說效率是有很大提升的。



ZLogHelper


既然奔潰棧裏面有鏈接可以跳轉,那麼我們可以通過棧信息來獲取日誌的打印位置。


我們直接上代碼:


public class ZLogHelper {
private static final int CALL_STACK_INDEX = 1;
private static final Pattern ANONYMOUS_CLASS = Pattern.compile("(\\$\\d+)+$");

public static String wrapMessage(int stackIndex, String message) {
// DO NOT switch this to Thread.getCurrentThread().getStackTrace().
if (stackIndex < 0) {
stackIndex = CALL_STACK_INDEX;
}
StackTraceElement[] stackTrace = new Throwable().getStackTrace();
if (stackTrace.length <= stackIndex) {
throw new IllegalStateException(
"Synthetic stacktrace didn't have enough elements: are you using proguard?");
}
String clazz = extractClassName(stackTrace[stackIndex]);
int lineNumber = stackTrace[stackIndex].getLineNumber();
message = ".(" + clazz + ".java:" + lineNumber + ") - " + message;
return message;
}

/**
* Extract the class name without any anonymous class suffixes (e.g., {@code Foo$1}
* becomes {@code Foo}).
*/
private static String extractClassName(StackTraceElement element) {
String tag = element.getClassName();
Matcher m = ANONYMOUS_CLASS.matcher(tag);
if (m.find()) {
tag = m.replaceAll("");
}
return tag.substring(tag.lastIndexOf('.') + 1);
}
}

這裏我們對外提供一個 wrapMessage 方法,看名字就知道是對 Message 進行包裝。


方法裏面也是對 StackTraceElement 進行分析。


這邊還做了一個控制,避免 stackIndex 出現負數情況。


可能有小夥伴會好奇,為什麼要把 stackIndex 對外開放呢?


因為你打印日誌的地方不一樣,這裏的 stackIndex 也需要對應調整。


方法裏面是對 StackTraceElement 做處理,而 StackTraceElement 跟你的方法層級有關係。


我們以最常用的兩種日誌打印形式為例,來說明這裏的 stackIndex 要怎麼傳遞,以及這個 ZLogHelper 的用法。


直接代碼使用


我們在 MainActivity.java 中直接使用,stackIndex 傳入 1 即可。


Log.e("ZLog", ZLogHelper.wrapMessage(1, "just test"));

控制台輸出如下:

可以看到代碼所在的類和行數到显示為鏈接文本,點擊會定位到具體的位置。


做了封裝的情況


一般我們對 Log 都會做封裝,因此假設我們有一個 LogUtils 類,我們在 MainActivity.java 裏面調用。


LogUtils.java:


class LogUtils {
public static void loge() {
Log.e("ZLog", ZLogHelper.wrapMessage(2, "just test"));
}
}

MainActivity.java:


LogUtils.loge();

我們先看下結果,再來分析。控制台輸出如下:


可以看到確實定位到了 MainActivity.java 中的具體使用地方。


那麼為什麼這裏傳入的 stackIndex 跟第一種不一樣,是 2 而不是 1 呢?


其實答案很簡單,你改為 1 之後,輸出的控制台显示的會定位到 LogUtils 裏面的日誌打印語句處。在這裏就是:


Log.e("ZLog", ZLogHelper.wrapMessage(2, "just test"));

所以其實你可以看出一個規律,而這個從代碼也可以發現。


因為代碼裏面解析調用位置是根據棧來的,對 StackTraceElement 進行分析,因此情況一直接使用,傳入 1。而情況二多了一層函數調用,通過 loge 方法做了一層包裝。因此需要傳入 2。如果你再套一層,那麼需要傳入 3。了解了這一點,我們下面的工具類相信你就看得懂了。


ZLog


如果你不想自己手動傳入 stackIndex,可以直接使用我們提供的工具類 ZLog。


public class ZLog {
private static boolean isDebugMode = false;
public static void setDebugMode(boolean debugMode) {
isDebugMode = debugMode;
}

private static boolean isLinkMode = true;
public static void setLinkMode(boolean linkMode) {
isLinkMode = linkMode;
}

private static final int CALL_STACK_INDEX = 3;

public static int v(String tag, String msg) {
return isDebugMode ? Log.v(tag, mapMsg(msg)) : -1;
}

public static int d(String tag, String msg) {
return isDebugMode ? Log.d(tag, mapMsg(msg)) : -1;
}

public static int i(String tag, String msg) {
return isDebugMode ? Log.i(tag, mapMsg(msg)) : -1;
}

public static int w(String tag, String msg) {
return isDebugMode ? Log.w(tag, mapMsg(msg)) : -1;
}

public static int e(String tag, String msg) {
return isDebugMode ? Log.e(tag, mapMsg(msg)) : -1;
}

private static String mapMsg(String msg) {
return isLinkMode ? ZLogHelper.wrapMessage(CALL_STACK_INDEX, msg) : msg;
}
}

相信有了前面的知識,小夥伴對於這裏為什麼傳入 3 應該了解了。


1 的話會定位到


return isLinkMode ? ZLogHelper.wrapMessage(CALL_STACK_INDEX, msg) : msg;

2 的話(以 e 為例)會定位到


return isDebugMode ? Log.e(tag, mapMsg(msg)) : -1;

3 的話才能夠定位到外面具體的調用處。


優化


我們知道,雖然 ZLog 做了封裝,但是我們每次打日誌都要傳入 ZLog,有點麻煩?


能否提供一個默認的 TAG,允許對外設置。


可以的,我們修改如下(以 e 為例):


private static String tag = "ZLOG";
public static void setTag(String tag) {
if (!TextUtils.isEmpty(tag)) {
ZLog.tag = tag;
}
}

public static int e(String tag, String msg) {
return isDebugMode ? Log.e(mapTag(tag), mapMsg(msg)) : -1;
}

public static int e(String msg) {
return isDebugMode ? Log.e(tag, mapMsg(msg)) : -1;
}

private static String mapTag(String tag) {
return TextUtils.isEmpty(tag) ? ZLog.tag : tag;
}

項目實戰


按照下面兩步引入開源庫。


Step 1. Add the JitPack repository to your build file
Add it in your root build.gradle at the end of repositories:


allprojects {
repositories {
...
maven { url 'https://jitpack.io' }
}
}

Step 2. Add the dependency


dependencies {
implementation 'com.github.nesger:AndroidWheel:1.0.0'
}

使用時先打開開關:


ZLog.setDebugMode(true);

然後就可以直接使用了。


溫馨提示


由於帶鏈接的 debug 對性能有一定影響,因此建議開發使用,上線關閉。


結語


這邊在完善一個開源倉庫 ,跟名字一樣,避免重複造輪子。


目前 1.0.0 版本提供日誌相關工具類,1.0.1 增加了防抖動 EditText。


後續會繼續更新迭代,功能會更完善更全面。


覺得不錯,歡迎給個 star 哈~


參考鏈接:


本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計



※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務



※Google地圖已可更新顯示潭子電動車充電站設置地點!!



※帶您來看台北網站建置台北網頁設計,各種案例分享



Orignal From: Android Debug 之 Log 最佳實踐

留言

這個網誌中的熱門文章

有了四步解題法模板,再也不害怕動態規劃!(看不懂算我輸)

導言 動態規劃問題一直是算法面試當中的重點和難點,並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到,這篇文章的目的主要是解釋清楚 什麼是動態規劃 ,還有就是面對一道動態規劃問題,一般的 思考步驟 以及其中的注意事項等等,最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃,或者僅僅只有耳聞,或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 ",如果更準確些,其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中,大家經常會遇到一些系統配置的問題,配置不對,系統就會報錯,這個時候一般都會去 Google 或者是查閱相關的文檔,花了一定的時間將配置修改好。 過了一段時間,去到另一個系統,遇到類似的問題,這個時候已經記不清之前修改過的配置文件長什麼樣,這個時候有兩種方案,一種方案還是去 Google 或者查閱文檔,另一種方案是借鑒之前修改過的配置,第一種做法其實是萬金油,因為你遇到的任何問題其實都可以去 Google,去查閱相關文件找答案,但是這會花費一定的時間,相比之下,第二種方案肯定會更加地節約時間,但是這個方案是有條件的,條件如下: 之前的問題和當前的問題有着關聯性,換句話說,之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中,可以看到的是,上面這兩個條件均滿足,大可去到之前配置過的文件中,將配置拷貝過來,然後做些細微的調整即可解決當前問題,節約了大量的時間。 不知道你是否從這些描述中發現,對於一個動態規劃問題,我們只需要從兩個方面考慮,那就是 找出問題之間的聯繫 ,以及 記錄答案 ,這裏的難點其實是找出問題之間的聯繫,記錄答案只是順帶的事情,利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話,接    動態規劃 算法是通過拆分問題,定義問題狀態和狀態之間的關係,使得問題能夠以遞推(或者說分治)的方式去解決。它的幾個重要概念如下所述。    階段: 對於一個完整的問題過程,適當的切分為若干個相互聯繫的子問題,每次在求解一個子問題...

程序員需要了解的硬核知識之操作系統入門

對於程序員來說,最莫大的榮耀莫過於自己的軟件被大多數人使用了吧。 歷史文章請戳 本篇文章作為操作系統的入門文章,可能入門都算不上吧,畢竟操作系統太龐大和複雜了。本篇文章主要帶你了解一下我們常用的操作系統環境。 操作系統環境 程序中包含着 運行環境 這一內容,可以說 運行環境 = 操作系統 + 硬件 ,操作系統又可以被稱為軟件,它是由一系列的指令組成的。我們不介紹操作系統,我們主要來介紹一下硬件的識別。 我們肯定都玩兒過遊戲,你玩兒遊戲前需要干什麼?是不是需要先看一下自己的筆記本或者電腦是不是能肝的起遊戲?下面是一個遊戲的配置(懷念一下 wow) 圖中的主要配置如下 操作系統版本:說的就是應用程序運行在何種系統環境,現在市面上主要有三種操作系統環境,Windows 、Linux 和 Unix ,一般我們玩兒的大型遊戲幾乎都是在 Windows 上運行,可以說 Windows 是遊戲的天堂。Windows 操作系統也會有區分,分為32位操作系統和64位操作系統,互不兼容。 處理器:處理器指的就是 CPU,你的電腦的計算能力,通俗來講就是每秒鐘能處理的指令數,如果你的電腦覺得卡帶不起來的話,很可能就是 CPU 的計算能力不足導致的。想要加深理解,請閱讀博主的另一篇文章: 顯卡:顯卡承擔圖形的輸出任務,因此又被稱為圖形處理器(Graphic Processing Unit,GPU),顯卡也非常重要,比如我之前玩兒的 劍靈 開五檔(其實就是圖像變得更清晰)會卡,其實就是顯卡显示不出來的原因。 內存:內存即主存,就是你的應用程序在運行時能夠動態分析指令的這部分存儲空間,它的大小也能決定你電腦的運行速度,想要加深理解,請閱讀博主的另一篇文章 存儲空間:存儲空間指的就是應用程序安裝所佔用的磁盤空間,由圖中可知,此遊戲的最低存儲空間必須要大於 5GB,其實我們都會遺留很大一部分用來安裝遊戲。 從程序的運行環境這一角度來考量的話,CPU 的種類是特別重要的參數,為了使程序能夠正常運行,必須滿足 CPU 所需的最低配置。 CPU 只能解釋其自身固有的語言。不同的 CPU 能解釋的機器語言的種類也是不同的。機器語言的程序稱為 本地代碼(native code) ,程序員用 C 等高級語言編寫的程...

步伐密集 易事特再建江蘇充電樁專案

易事特今日發佈公告稱,與江蘇高淳經濟開發區開發總公司就新能源汽車充電樁設備研發製造、IDC整體機房研發製造、智慧微電網等項目投資達成一致意見並簽署協議書。易事特承諾新辦企業固定資產投資總額為6億元人民幣(約新臺幣30億),畝均稅收不低於20萬元(約新臺幣101萬),首期建築面積不低於30000平方米。高淳經濟開發區將供地約120畝,使用年限為50年。   易事特佈局充電樁可謂步伐密集。今年8月13日,易事特與馬鞍山經濟技術開發區管理委員會簽訂了《投資框架協議書》,擬在對方區域內投資建設資料中心、分散式發電設備與系統集成和新能源汽車充電站(樁)項目。 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※ USB CONNECTOR 掌控什麼技術要點? 帶您認識其相關發展及效能 ※ 台北網頁設計 公司這麼多該如何選擇? ※智慧手機時代的來臨,RWD 網頁設計 為架站首選 ※評比 南投搬家公司費用 收費行情懶人包大公開 ※幫你省時又省力, 新北清潔 一流服務好口碑 ※回頭車 貨運 收費標準 Orignal From: 步伐密集 易事特再建江蘇充電樁專案