跳到主要內容

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

留言

這個網誌中的熱門文章

旅館疑有臭蟲 北市府稽查找嘸

有民眾抱怨,日前投宿的北市某旅館疑似出現臭蟲,北市觀傳局與衛生局、環保局聯合稽查,但因為沒有發現蟲屍,無法確認該旅館是否真有臭蟲,市府下周將召開專家會議處理該案,市長蔣萬安則允諾會以最高規格防範臭蟲。 北市某旅館傳出疑有臭蟲,議員陳宥丞23日在市政總質詢詢問市府處理進度,並指出法國、澳洲、韓國的臭蟲,起初都現蹤公車或地鐵卻沒被發現,直到大規模爆發,才付出大量社會成本處理,而且一般殺蟲劑無法殺掉臭蟲,北市是否有因應措施? 觀傳局主任祕書蕭君杰表示,21日聯合環保局、衛生局到該旅館稽查,但沒有發現臭蟲,也沒有查到蟲卵跡象,只能檢查現場環境是否符合衛生相關規定,但環保局有指導業者如何針對臭蟲清潔消毒。觀傳局長王秋冬指出,下周會與專家學者召開會議,以最高規格處理此案。 想知道購買電動車哪裡補助最多? 台中電動車 補助資訊懶人包彙整 ;推薦評價好的 iphone維修 中心擁有專業的維修技術團隊,同時聘請資深iphone手機維修專家,現場說明手機問題,快速修理,沒修好不收錢住家的頂樓裝 太陽光電 聽說可發揮隔熱功效一線推薦東陽能源擁有核心技術、產品研發、系統規劃設置、專業團隊的太陽能發電廠商。 網頁設計 一頭霧水該從何著手呢? 回頭車 貨運收費標準宇安交通關係企業,自成立迄今,即秉持著「以誠待人」、「以實處事」的企業信念 台中搬家公司 教你幾個打包小技巧,輕鬆整理裝箱!還在煩惱搬家費用要多少哪?台中大展搬家線上試算搬家費用,從此不再擔心「物品怎麼計費」、「多少車才能裝完」 台中搬家 公司費用怎麼算?擁有20年純熟搬遷經驗,提供免費估價且流程透明更是5星評價的搬家公司好山好水 露營車 漫遊體驗露營車x公路旅行的十一個出遊特色。走到哪、玩到哪,彈性的出遊方案,行程跟出發地也可客製 廣告預算用在刀口上, 台北網頁設計 公司幫您達到更多曝光效益; 電動車補助 衛生局疾病管制科長張惠美表示,現場查到與臭蟲無關的多項衛生缺失,包含未提供從業人員體檢報告、簡易外傷藥品及器材超過有效期、紗窗有破損等,已要求業者2周內改善,將擇期複查,如果複查不合格,將依法裁罰3000元至2萬元罰鍰。 但陳宥丞批評,環保局未公告哪些藥劑能殺死臭蟲,很擔心北市會和韓國、法國一樣,把臭蟲防治交給民間恐造成大規模爆發,且北市內的廢棄傢俱回收廠也有可能成為臭蟲孳生的...

必知必會-存儲器層次結構

相信大家一定都用過各種存儲技術,比如mysql,mongodb,redis,mq等,這些存儲服務性能有非常大的區別,其中之一就是底層使用的存儲設備不同。作為一個程序員,你需要理解存儲器的層次結構,這樣才能對程序的性能差別瞭然於心。今天帶大家了解下計算機系統存儲器的層次結構。 存儲技術 首先了解下什麼是存儲器系統? 實質上就是一個具有不同容量、成本和訪問時間的存儲設備的層次結構。從快到慢依次為:CPU寄存器、高速緩存、主存、磁盤; 這裏給大家介紹一組數據,讓大家有一個更清晰的認識: 如果數據存儲在CPU寄存器,需要0個時鐘周期就能訪問到,存儲在高速緩存中需要4~75個時鐘周期。如果存儲在主存需要上百個周期,而如果存儲在磁盤上,大約需要幾千萬個周期! -- 出自 CSAPP 接下來一起深入了解下計算機系統涉及的幾個存儲設備: 隨機訪問存儲器 隨機訪問存儲器(RAM)分為靜態RAM (SRAM) 和動態RAM(DRAM)。SRAM的速度更快,但也貴很多,一般不會超過幾兆字節,通常用來做告訴緩存存儲器。DRAM就是就是我們常說的主存。 訪問主存 數據流是通過操作系統中的總線的共享电子電路在處理器和DRAM之間來來回回。每次CPU和主存之間的數據傳送都是通過一系列複雜的步驟完成,這些步驟成為總線事務。讀事務是將主存傳送數據到CPU。寫事務從CPU傳送數據到主存。 總線是一組并行的導線,能攜帶地址、數據和控制信號。下圖展示了CPU芯片是如何與主存DRAM連接的。 那麼我們在加載數據和存儲數據時,CPU和主存到底是怎樣交互實現的呢? 首先來看一個基本指令,加載內存數據到CPU寄存器中: movq A,%rax 將地址A的內容加載到寄存器%rax中,這個命令會使CPU芯片上稱為總線接口(bus interface)的電路在總線上發起讀事務,具體分為三個步驟: CPU將地址A放到系統總線上,I/O橋將信號傳遞到內存總線。詳情看下下圖a 主存感覺到內存總線上的地址信號,從內存總線讀地址,從DRAM取出數據字,將其寫到內存總線。I/O橋將內存總線信號翻譯成系統總線信號,沿着系統總線傳遞到CPU總線接口。下圖b CPU感覺到系統總線上的數據,從總線上讀數據,並將數據複製到寄存器%rax...

2016年電動車和插電式混合動力車銷量預計將超過70萬輛

中汽協日前預測,2016年全國電動汽車和插電式混合動力車的銷量預計將超過70萬輛,較2015年的銷量增長一倍。 2015年電動車和插電式混合動力車的合併銷量為331092輛,較2014年增長了340%。其中包括247482輛電動車和83610輛插電式混合動力車,在24萬輛多的電動汽車銷量中,包括146719輛乘用車,另有100763輛為商用車。插電式混合動力車的銷量中,60663輛為乘用車,22947輛為商用車。 根據2015年起草的藍圖,政府計畫到2020年在全國範圍內新建12000個充電站和480枚充電樁。2014年年底,全國共有780個充電站共31000枚充電樁。2015年政府還為27個省市自治區設定了電動車的最低銷量目標。 政府預計,這些措施到位後,自主品牌車企的電動車和插電式混合動力車銷量到2020年可達100萬輛,到2025年可達300萬輛。 本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※為什麼 USB CONNECTOR 是電子產業重要的元件? ※ 網頁設計 一頭霧水??該從何著手呢? 找到專業技術的 網頁設計公司 ,幫您輕鬆架站! ※想要讓你的商品成為最夯、最多人討論的話題? 網頁設計公司 讓你強力曝光 ※想知道最厲害的 台北網頁設計公司推薦 、 台中網頁設計公司推薦 專業設計師"嚨底家"!! Orignal From: 2016年電動車和插電式混合動力車銷量預計將超過70萬輛