跳到主要內容

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 最佳實踐

留言

這個網誌中的熱門文章

Python 併發總結,多線程,多進程,異步IO

1 測量函數運行時間 import time def profile(func): def wrapper(*args, ** kwargs): import time start = time.time() func( *args, ** kwargs) end = time.time() print ' COST: {} ' .format(end - start) return wrapper @profile def fib(n): if n<= 2 : return 1 return fib(n-1) + fib(n-2 ) fib( 35 )   2 啟動多個線程,並等待完成   2.1 使用threading.enumerate() import threading for i in range(2 ): t = threading.Thread(target=fib, args=(35 ,)) t.start() main_thread = threading.currentThread() for t in threading.enumerate(): if t is main_thread: continue t.join()   2.2 先保存啟動的線程 threads = [] for i in range(5 ): t = Thread(target=foo, args= (i,)) threads.append(t) t.start() for t in threads: t.join()   3 使用信號量,限制同時能有幾個線程訪問臨界區 from threading import Semaphore import time sema = Semaphor...

高雄十大包子名店出爐

, 圖文:吳恩文 高雄包子大賽落幕了,我只能就我個人意見, 介紹一下前十名這些包子,但是不能代表其他四位評審的意見,雖然身為評審長,我通常不會第一個表示意見,以免影響其他評審, 我主要工作是負責發問。   這次參賽的素包子很少,而且都不夠細致,又偏油,我不愛, 但是第一名的甜芝麻包-熔岩黑金包,竟然是素食得名- 漢來蔬食巨蛋店。   這包子賣相太好,竹炭粉的黑色外皮刷上金粉,一上桌,眾人驚呼, 搶拍照,內餡是芝麻餡,混一點花生醬增稠,加入白糖芝麻油, 熔岩爆漿的程度剛剛好,我一直以為芝麻要配豬油才行、 但是選到好的黑芝麻油一樣不減香醇, 當下有二位評審就想宅配回家。   尤其特別的是,黑芝麻餡室溫易化,師傅必須要輪班躲在冷藏室內, 穿著大外套才能包,一天包不了多少,我笑說,漢來美食,集團餐廳那麼多,實力雄厚,根本是「 奧運選手報名參加村裡運動會」嘛,其他都是小包子店啊, 但是沒辦法,顯然大家都覺得它好看又好吃, 目前限定漢來蔬食高雄巨蛋店,二顆88元,可以冷凍宅配, 但是要排一陣子,因為供不應求,聽說,四月份, 台北sogo店開始會賣。   第二名的包子,左營寬來順早餐店,顯然平易近人的多,一顆肉包, 十塊錢,是所有參賽者中最便宜的,當然,個頭也小, 它的包子皮明顯和其他不同,灰灰的老麵,薄但紮實有嚼勁, 肉餡新鮮帶汁,因為打了些水,味道極其簡單,就是蔥薑,塩, 香油,薑味尤其明顯,是老眷村的味道, 而特別的是老闆娘是台灣本省人, 當年完全是依據眷村老兵的口味一步一步調整而來,沒有加什麼糖、 五香粉,胡椒粉,油蔥酥。就是蔥薑豬肉和老麵香,能得名, 應該是它的平實無華,鮮美簡單,打動人心。   這是標準的心靈美食,可以撫慰人心,得名之前,寛來順已經天天排隊,現在,恐怕要排更久了, 建議大家六七點早點上門。   第三名,「專十一」很神奇,我記得比賽最後, 大家連吃了幾家不能引起共鳴的包子,有些累,到了專十一, 就坐著等包子,其他評審一吃,就催我趕快試,我一吃, 也醒了大半。   它的包子皮厚薄適中,但是高筋麵粉高些,老麵加一點點酵母, 我心中,它的皮屬一屬二,至於餡又多又好吃,蛋黃還是切丁拌入, 不是整顆放,吃起來「美味、均衡、飽滿」。一顆二十元。   老闆是陸軍專科十一期畢業取名專十一,...

韋伯連續劇終於更新 期待第一季順利完結

  地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (James Webb Space Telescope,縮寫為 JWST)自 1996 年以來斷斷續續不按劇本演出的連續劇終於讓焦慮的觀眾們又等到了一次更新:五層遮陽罩測試順利完成。 裝配完成的韋伯望遠鏡與好夥伴遮陽罩同框啦。Credit: NASA   嚴格的測試是任何空間任務順利成功的重中之重。遮陽罩,這個韋伯望遠鏡異常重要的親密夥伴,要是無法正常運轉的話,韋伯的這一季天文界連續劇說不準就要一直拖更了。   詹姆斯·韋伯空間望遠鏡是歷史上造出的最先進的空間望遠鏡。它不僅是一架紅外望遠鏡,還具有特別高的靈敏度。但想要達到辣么高的靈敏度來研究系外行星和遙遠的宇宙童年,韋伯童鞋必須非常"冷靜",體溫升高的話,靈敏度會大大折損。這個時候,遮陽罩就要大顯身手啦。   遮陽罩在韋伯的設計中至關重要。韋伯望遠鏡會被發射到拉格朗日 L2 點,運行軌道很高,遠離太陽、地球與月球。太陽是韋伯的主要熱量干擾的來源,其次是地球與月球。遮陽罩會有效阻斷來自這三大熱源的能量並保護韋伯維持在工作溫度正常運轉。這個工作溫度指的是零下 220 攝氏度(-370 華氏度;50 開爾文)。 上圖中我們可以看出,韋伯望遠鏡的配置大致可分為兩部分:紅色較熱的一面溫度為 85 攝氏度,藍色較冷的一面溫度達到零下 233 攝氏度。紅色的這部分中,儀器包括太陽能板、通信設備、計算機、以及轉向裝置。藍色部分的主要裝置包括鏡面、探測器、濾光片等。Credit: STSci.   遮陽罩的那一部分和望遠鏡的鏡面這部分可以產生非常極端的溫差。遮陽的這面溫度可以達到 110 攝氏度,足以煮熟雞蛋,而背陰處的部分溫度極低,足以凍結氧氣。   工程師們剛剛完成了五層遮陽罩的測試,按照韋伯在 L2 時的運行狀態安裝了遮陽罩。L2 距離地球約 160 萬公里。NASA 表示這些測試使用了航天器的自帶系統來展開遮陽罩,測試目前都已成功完成。韋伯望遠鏡遮陽罩負責人 James Cooper 介紹說這是遮陽罩"第一次在望遠鏡系統的电子設備的控制下展開。儘管這個任務非常艱巨,難度高,但測試順利完成,遮陽罩展開時的狀態非常驚艷"。   遮陽罩由五層 Kapton 製成。Kapton 是一種聚酰亞胺薄膜材料, 耐高溫絕...