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.java 的 24 行。
而且點選藍色連結游標會直接定位到錯誤位置。
如果我們普通的日誌也可以點選就跳轉到對應位置,對於我們開發來說效率是有很大提升的。
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 對效能有一定影響,因此建議開發使用,上線關閉。
結語
這邊在完善一個開源倉庫 AndroidWheel,跟名字一樣,避免重複造輪子。
目前 1.0.0 版本提供日誌相關工具類,1.0.1 增加了防抖動 EditText。
後續會繼續更新迭代,功能會更完善更全面。
覺得不錯,歡迎給個 star 哈~
參考連結:
Android Studio Pro Tip: go to source from logcat output
相關推薦
Android Debug 之 Log 最佳實踐
本文微信公眾號「AndroidTraveler」首發。 背景 在開發過程中,除錯是必不可少的一項工作。 當我們要確定專案的邏輯時,當我們要了解介面的生命週期時,當我們發現新寫的邏輯與期望效果不一致時,當我們覺得資料有問題時...... 而除錯有兩種方式: 第一種就是使用 debug 模式執行 APP,然後通過
Android ORM系列之GreenDao最佳實踐
GreenDAO是一個可以幫助Android開發者快速將Java物件對映到SQLite資料庫的表單中的ORM解決方案,通過使用一個簡單的面向物件API,開發者可以對Java物件進行儲存、更新、刪除和查詢。 GreenDao有兩個專案,一個是生成dao和
Android UI自動化測試最佳實踐
轉載地址:http://qa.baidu.com/blog/?p=985 一. 概述 Android系統測試和Web的測試類似,有兩類自動化的方式:錄製回放與基於頁面元素操作的手工開發。由於錄製回放在長期維護與程式碼重用方面存在問題,這裡主要的方式還是後者,這也是Web
TensorFlow入門之MNIST最佳實踐-深度學習
模型保存 tro 網絡 選擇 手寫 找到 default 輸入 自定義 在上一篇《TensorFlow入門之MNIST樣例代碼分析》中,我們講解了如果來用一個三層全連接網絡實現手寫數字識別。但是在實際運用中我們需要更有效率,更加靈活的代碼。在TensorFlow實戰這本書中
Android最佳實踐之性能 - 多線程
ndt andro 單位 多線程 same Coding amount other err 在單獨線程執行代碼 參考地址:http://developer.andr
Android學習之基礎知識七—碎片的最佳實踐
一、Android碎片(Fragment)的最佳實踐——簡易版新聞應用 第一步:新建FragmentBestPractice專案,在app/build.gradle當中新增:RecyclerView 依賴庫,注意:新增完成後,一定要記住點選右上角的:Sync now 第二步:建立新聞實體類 第三
安卓專案實戰之Gif圖片載入的最佳實踐android-gif-drawable開源庫的使用
前言 在平時的專案開發中,我們或多或少會遇到載入gif圖片這樣的需求,但是Android的ImageView又無法直接載入Gif圖片,面對這樣的需求我們一般都會想到使用支援載入gif動圖的Glide第三方庫來進行實現,但是使用過程中發現Glide在載入大的gif
Android最佳實踐之SystemBar狀態列全版本適配方案
前言 自從MD設計規範出來後,關於系統狀態列的適配越受到關注,因為MD在5.0以後把系統狀態列的顏色改為可由開發者配置的,而在5.0之前則無法指定狀態列的顏色,所以這篇就說說使用Toolbar對系統狀態列的適配策略 主流App的適配效果 手Q在這方面適
Android最佳實踐之觸控手勢
普通手勢 為Activity 或View捕捉觸控事件 使用getActionMasked()來提取event中的action。 public class MainActivity extends Activity { ... // This e
Android學習筆記——UI基礎之編寫介面最佳實踐
參考書籍:Android第一行程式碼(第二版).郭霖著 1、製作Nine-Patch圖片 一種被特殊處理過的png圖片,能夠指定那些區域可以被拉伸、哪些不可以。在Android sdk目錄下有一個tools資料夾,找到draw9patch.bat檔案來製作N
Android最佳實踐之流暢(Seamlessness)設計
即使你的應用程式是快速且響應靈敏的,但一些設計仍然會給使用者造成問題——與其它應用程式或對話方塊未事先計劃的互動,意外的資料丟失,意料之外的阻塞等等。避免這些問題,有助於理解應用程式執行的上下文和系統的互動過程,而這些又正影響著你的應用程式。簡而言之,你應該竭盡全力去開發一個與系統和其它應用程式流暢
Android最佳實踐之效能
Doze和App Standby的優化(API23) 參考地址:http://developer.android.com/training/monitoring-device-state/doze-standby.html 從Android 6.0 (API
[轉]Android最佳實踐之:StrictMode介紹
【IT168技術】最新的Android平臺中(Android 2.3起),新增加了一個新的類,叫StrictMode(android.os.StrictMode)。這個類可以用來幫助開發者改進他們編寫的應用,並且提供了各種的策略,這些策略能隨時檢查和報告開發者開發應用中存在的問題,比如可以監視那些本不應
Android學習之活動的最佳實踐
•問題的起源 先來模擬一個場景:開啟一個 App,最先映入眼簾的是主活動(MainActivity),在該活動中給使用者提供了一個 Button, 使用者點選該 Button 實現由 MainActivity 跳轉到 FirstActivity,在 FirstActivity 中,又提供了
Android開發中有用工具之--Log工具類
util lena 日誌 日誌信息 stat 們的 常常 我們 imp 在開發的過程中。我們常常會使用Log來輸出日誌,幫助我們來調試程序 可是有時候並不能全然滿足我們的須要 ,比方我想知道這個日誌信息是來自於哪一個包 哪一個類 所以我們封裝一個這個Log類。方便我們的
Android關於Task的一些實踐之SingleTask, SingleInstance和TaskAffinity
conda tag 我們 創建 真理 enter 設置 com lms 上一篇文章粗略地介紹了一下關於Android中Task的基本知識。只是實踐才是檢驗真理的唯一標準,所以。今天就來試驗一下Task中的launchMode是否真的實現了文檔所說的那樣。 首先。定義三個
遊戲運維的最佳實踐:搜狐暢遊自動化運維之旅!
運維 遊戲 搜狐暢遊 搜狐黎誌剛見證了暢遊遊戲自動化運維平臺的從無到有,通過在其中踩過的坑、解過的結,他向大家來闡述遊戲運維的進階之路。本文主要圍繞暢遊遊戲管理體系與運維自動化的演變歷程、運維自動化的實現及未來運維四方面展開。暢遊運維管理體系與運維自動化的演變歷程暢遊運維管理體系演變歷程從 200
Mongo實戰之數據空洞的最佳實踐
journal 初始 beat objectid use bpa 沒有 lda replica 問題背景: 某天,開發部的同事跑過來反映: mongodb數據文件太大,快把磁盤撐爆了!其中某個db占用最大(運營環境這個db的數據量其實很小) 分析: 開發環境有大量測試的增/
git最佳實踐之feature和hotfix分支
我們 width style git最佳實踐 圖片 技術 功能 就是 因此 先來復習一波,git的最佳分支管理流程: 再簡單復習各個分支: master: 主分支,主要用來版本發布。 develop:日常開發分支,該分支正常保存了開發的最新代碼。 feature
智能合約最佳實踐 之 Solidity 編碼規範
Solidity 區塊鏈 智能合約 每一門語言都有其相應的編碼規範, Solidity 也一樣, 下面官方推薦的規範及我的總結,供大家參考,希望可以幫助大家寫出更好規範的智能合約。 命名規範 避免使用 小寫的l,大寫的I,大寫的O 應該避免在命名中單獨出現,因為很容易產生混淆。 合約、庫、事件、枚