跳到主要內容

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 對性能有一定影響，因此建議開發使用，上線關閉。


結語


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


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


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


覺得不錯，歡迎給個 star 哈～


參考鏈接：


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

【其他文章推薦】

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



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



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



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


Orignal From: Android Debug 之 Log 最佳實踐

留言

張貼留言

這個網誌中的熱門文章

架構設計 | 異步處理流程，多種實現模式詳解

本文源碼：GitHub·點這裏 || GitEE·點這裏 一、異步處理 1、異步概念 異步處理不用阻塞當前線程來等待處理完成，而是允許後續操作，直至其它線程將處理完成，並回調通知此線程。 必須強調一個基礎邏輯，異步是一種設計理念，異步操作不等於多線程，MQ中間件，或者消息廣播，這些是可以實現異步處理的方式。 同步處理和異步處理相對，需要實時處理並響應，一旦超過時間會結束會話，在該過程中調用方一直在等待響應方處理完成並返回。同步類似電話溝通，需要實時對話，異步則類似短信交流，發送消息之後無需保持等待狀態。 2、異步處理優點 雖然異步處理不能實時響應，但是處理複雜業務場景，多數情況都會使用異步處理。 異步可以解耦業務間的流程關聯，降低耦合度； 降低接口響應時間，例如用戶註冊，異步生成相關信息表； 異步可以提高系統性能，提升吞吐量； 流量削峰即把請求先承接下來，然後在異步處理； 異步用在不同服務間，可以隔離服務，避免雪崩； 異步處理的實現方式有很多種，常見多線程，消息中間件，發布訂閱的廣播模式，其根據邏輯在於先把請求承接下來，放入容器中，在從容器中把請求取出，統一調度處理。 注意 ：一定要監控任務是否產生積壓過度情況，任務如果積壓到雪崩之勢的地步，你會感覺每一片雪花都想勇闖天涯。 3、異步處理模式 異步流程處理的實現有好多方式，但是實際開發中常用的就那麼幾種，例如： 基於接口異步響應，常用在第三方對接流程； 基於消息生產和消費模式，解耦複雜流程； 基於發布和訂閱的廣播模式，常見系統通知 異步適用的業務場景，對數據強一致性的要求不高，異步處理的數據更多時候追求的是最終一致性。 二、接口響應異步 1、流程描述 基於接口異步響應的方式，有一個本地業務服務，第三方接口服務，流程如下： 本地服務發起請求，調用第三方服務接口； 請求包含業務參數，和成功或失敗的回調地址； 第三方服務實時響應流水號，作為該調用的標識； 之後第三方服務處理請求，得到最終處理結果； 如果處理成功，回調本地服務的成功通知接口； 如果處理失敗，回調本地服務的失敗通知接口； 整個流程基於部分異步和部分實時的模式，完整處理； 注意 ：如...
張貼留言
閱讀完整內容

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue)

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue) 目錄 引言 時間真快，轉眼今年又要過去了。回想今年，依次開源發布了 Colder.Fx.Net.AdminLTE(254Star) 、 Colder.Fx.Core.AdminLTE(335Star) 、 DotNettySocket(82Star) 、 IdHelper(47Star) ，這些框架及組件都是本着以實際出發，實事求是的態度，力求提高開發效率（我自己都是第一個使用者），目前來看反響不錯。但是隨着前端和後端技術的不斷變革，尤其是前端，目前大環境已經是前後端完全分離為主的開發模式，在這樣的大環境和必然趨勢之下，傳統的MVC就顯得有些落伍了。在這樣的背景下，一款前後端分離的.NET開發框架就顯得尤為必要，由此便定了框架的升級目標： 前後端分離 。 首先後端技術的選擇，從目前的數據來看，.NET Core的發展遠遠快於.NET Framework，最簡單的分析就是Colder.Fx.Core.AdminLTE發布比Colder.Fx.Net.AdminLTE晚，但是星星卻後來居上而且比前者多30%，並且這個差距在不斷擴大，由點及面的分析可以看出我們廣大.NET開發人員學習的熱情和积極向上的態度，並不是某些人所認為的那麼不堪（ 走自己的路，讓別人說去吧 ）。大環境上微軟积極擁抱開源，大力發展.NET Core， 可以說前途一片光明。因此後端決定採用 .NET Core3.0 ，不再浪費精力去支持.NET Framework。 然後是前端技術選擇，首選是三大js框架選擇，也是從實際出發，Vue相對其它而言更加容易上手，並且功能也毫不遜色，深得各種大小公司喜歡，如果偏要說缺點的話，那就是對TS支持不行，但是即將發布Vue3.0肯定會改變這一缺陷。選擇了Vue之後，然後就是UI框架的選擇了，這裏的選擇更多了，我選擇了Ant Design Vue，理由便是簡潔方便，十分符合我的設計理念。 技術選型完畢之後便...
張貼留言
閱讀完整內容

台北市住宅、社區建創儲能設備 最高可獲600萬元補助

為了推廣分散式發電，台北市環保局預計補助1億元供住宅社區設置創能、儲能設備，計有3種方案可供選擇。環保局說明，每案補助額度不超過建制總經費49％，社區每案最高可獲200萬至600萬元補助，住宅每案補助上限100萬元，5月1日起開放申請。 環保局說明，台北市溫室氣體排放量7成以上來自住商部門，其中以使用電力造成間接溫室氣體排放為大宗，台北市平均年用電量約159.86億度，1度電約等同排放0.5公斤二氧化碳，若想達成2050年淨零排放目標，僅靠節能減碳無法達成，必須發展綠色創能、儲能，並且參考歐洲、日本的做法，採分散式發電方式，推廣到社區、住家、商辦，達到供電自給自足目標。 因此，環保局推出「台北市住宅社區創能儲能及節能補助計畫」，補助對象為台北市轄內房屋所有權人及社區管理委員會，補助方案共計3種，每一申請人或每一場址僅能獲1次補助，每案補助額度不超過建置總經費49％為限，5月1日到7月31日開放申請，但補助經費用完即停止申請。 環保局說明，方案A補助對象以社區為主，公共區域申請創能儲能及節能項目，每案補助上限新台幣600萬元；方案B分為住宅或社區公共區域申請創能搭配儲能項目（創能或儲能方案不得單獨申請），社區每案補助上限新台幣400萬元，住宅每案補助上限100萬元。方案C補助對象也是社區，公共區域申請節能項目，每案補助上限新台幣200萬元。 網頁設計 最專業,超強功能平台可客製,窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸，為每一位客戶客製建立行銷脈絡及洞燭市場先機,請問 台中電動車 哪裡在賣比較便宜可以到台中景泰電動車門市去看看總店：臺中市潭子區潭秀里雅潭路一段102-1號。 電動車補助 推薦評價好的 iphone維修 中心擁有專業的維修技術團隊，同時聘請資深iphone手機維修專家，現場說明手機問題，快速修理，沒修好不收錢住家的頂樓裝 太陽光電 聽說可發揮隔熱功效一線推薦東陽能源擁有核心技術、產品研發、系統規劃設置、專業團隊的太陽能發電廠商。 網頁設計 一頭霧水該從何著手呢? 回頭車 貨運收費標準宇安交通關係企業，自成立迄今，即秉持著「以誠待人」、「以實處事」的企業信念 台中搬家公司 教你幾個打包小技巧,輕鬆整理裝箱!還在煩惱搬家費用要多少哪？台中大展搬家線上試算搬家費用，從此不再擔心「物品怎麼計費」、「多...
張貼留言
閱讀完整內容