本文會不定期更新，推薦watch下項目。
如果喜歡請star，如果覺得有紕漏請?zhí)峤籭ssue，如果你有更好的點子可以提交pull request。
本文的示例代碼主要是基于logger、LogUtils和timber進行編寫的，如果想了解更多請查看他們的詳細解釋。
我很推薦大家多多進行對比，選擇適合你自己的庫來使用。

本文固定連接：https://github.com/tianzhijiexian/Android-Best-Practices

一、背景

Android中的log是這么寫的：

Log.d(TAG, "This is a debug log");

android.util.Log類做的事情很簡單，符合kiss原則，但是隨著業(yè)務(wù)的不斷發(fā)展，logcat中就會有多個部門的各種log，不同手機系統(tǒng)自己的一些log也會參雜進來，逼迫我們要擴展log類。

二、需求

1. 我才不要每次打log都去想tag叫什么名字呢
2. 通常情況下請自動把當前類名作為默認的tag，但也允許我自由指定
3. 我希望我寫的模板式代碼越少越好，一個logd就能打印一切
4. 我要打印出list，map，json，pojo這樣的對象
5. 我的log絕對不要和其余的雜亂log混在一起
6. log信息過長后應(yīng)該要自動換行，我不允許我的log打印不全
7. 我要我的log變的好看，直觀，就是美
8. log中還要能顯示我當前的線程名，方便我調(diào)試多線程
9. 我打出的log后面要根上這個log的地址，可以直接外鏈到log的位置
10. release包中不能泄漏我高傲的log，但只要我想讓它顯示，release版本也阻擋不了我
11. 在release版本中殘留的log代碼應(yīng)該對app運行效率影響極低
12. 它能自動將try-catch住的crash通過log上傳到Crashlytics

回看這些需求，不合理么？其實很合理，我們的宗旨就是讓無意義的重復(fù)代碼去死，如果死不掉就交給機器來做。我們應(yīng)該做那些真正需要我們做的事情，而不是像一個沒思想的猿猴一般整天寫模板式代碼。這才是程序員思維，而不是程序猿思維！

注意：我希望只要寫真正有意義的內(nèi)容！

三、實現(xiàn)

分析上述的需求后，我將其分為四類： 使用、顯示和擴展。

使用篇

建立包裝類

無論一個第三方庫有多好，我還是推薦不直接使用它，因為你很有可能會去替換這個第三方庫，而且一個第三方庫肯定無法滿足各種奇葩需求。所以，對于網(wǎng)絡(luò)庫、圖片庫和log庫來說，我們應(yīng)該事先考慮在上面封裝一層。

我們建立一個包裝類，用這個包裝類用來包裹Logger（logger是本文介紹的一個log庫），下面是包裝類的代碼片段：

public static void d(@Nullable String info, Object... args) {
    if (!mIsOpen) { // 如果把開關(guān)關(guān)閉了，那么就不進行打印
        return;
    }
    Logger.d(info, args);
}

對于包裝類的起名最好不要和“Log”這個類似，能有明顯的區(qū)別最好，一是防止自己手抖寫錯了，二是方便review的時候能快速檢查出有沒有誤用原始的Log。

自動打tag

默認情況下可以把當前類名作為TAG的默認值，我們可以通過下面代碼來得到當前類名：

private static String getClassName() {
    // 這里的數(shù)組的index，即2，是根據(jù)你工具類的層級取的值，可根據(jù)需求改變
    StackTraceElement thisMethodStack = (new Exception()).getStackTrace()[2]; 
    String result = thisMethodStack.getClassName();
    int lastIndex = result.lastIndexOf(".");
    result = result.substring(lastIndex + 1, result.length());
    return result;
}

這樣我們就輕易的擺脫了tag的糾纏。
需要注意的是，獲取堆棧的方法是有性能消耗的，所以在主線程的log可能會引起一些卡頓，所以強烈建議在release版本中不要使用這個方法。

這個方法來自于豪哥的建議，這里感謝豪哥的意見。

自定義tag

除了自動打tag外，我們肯定要讓其支持自定義tag：

public static void d(@NonNull String tag, String info, Object... args) {
    Logger.t(tag).d(info, args);
}

這個d(tag, info, args...)是上面d(info, args...)的擴展，這里要注意的是tag的選取。

常用的做法是用getSimpleName的方式來得到tag，但如果你加了混淆，很多類（Activity、View不一定會被混淆）就會被混淆為a/b/c這樣的單詞。因此，如果你的log要出現(xiàn)在混淆的包里的，我強烈建議去手動設(shè)置tag值，否則打出來的log就是很難過濾的了。

至于如何手動設(shè)置tag的值，下面會講到logt這個快捷命令。

自定義全局tag和tag前綴

如果你的項目很龐大或者采用了插件化和組件化方案，那么你肯定會涉及到多人開發(fā)的問題。底層平臺是暴露統(tǒng)一的log接口，但是上層開發(fā)人員種類繁多，如何在繁雜的log中找到自己部門的自己關(guān)心的log呢？

在這種情況下我們可以采用如下兩種方案：

1. 自行調(diào)試時關(guān)閉無關(guān)部門的log輸出
2. 每個部門有自定義的tag前綴

對于方案一，我們本身的log系統(tǒng)底層采用的是timber，它本身就是通過“種樹”的方式進行l(wèi)og分發(fā)的，我們只需要在我們項目的最開始調(diào)用

Logger.uprootAll();
// or
Timber.uprootAll();

將所有之前的log通道移除，這樣就清空了無用的log了。

相比起方案一的簡單粗暴，方案二倒是溫和實用的多。我們通過在logger初始化設(shè)置一個tagPrefix，這個前綴就會伴隨著我們私有項目的所有l(wèi)og了，以后直接搜索這個前綴就可以過濾出想要的信息了。

開啟和關(guān)閉log

有時候在調(diào)試過程中可能會要支持測試同學(xué)的動態(tài)關(guān)閉和開啟log的功能。

Logger.closeLog();
Logger.openLog(Log.INFO);

這個操作可以支持在應(yīng)用運行的時的任何時候進行開關(guān)。

將Log代碼快捷模板

有人說我們IDE不都有代碼提示了么，你還想怎么簡化log的輸入呢？這里可以利用as的模板提示的功能：

我們可以模仿原有的模板來做自己的代碼模板，簡化模板式代碼的輸入。至于具體模仿的方式我就不手把手教了，相當簡單。下面僅展示下自帶的log模板的使用：

生成TAG：

顯示篇

讓log更加美觀

讓log的輸出直觀、美觀其實很簡單，就是在輸出前做點字符串拼接的工作,比如加上下面這行橫線。

private static final String BOTTOM_BORDER = "╚═══════════════════════════";

因為做了很多拼接的工作，所以好看的log也是消耗性能的。我的習(xí)慣是調(diào)試完畢后立刻刪除無用的log，這樣既能減少性能影響，也能減少同事的閱讀代碼的負擔。采用輕量級美化后效果如下：

顯示當前方法名、所在類并加超鏈

這個功能其實ide是原生支持的，不相信的話你隨便用原生的log打印出onCreate: (MainActivity.java:31)試試。

我們可以通過下面的方法來做到更好的效果：

    private static String callMethodAndLine() {
        String result = "at ";
        StackTraceElement thisMethodStack = (new Exception()).getStackTrace()[1];
        result += thisMethodStack.getClassName()+ "."; //  當前的類名（全名）
        result += thisMethodStack.getMethodName();
        result += "(" + thisMethodStack.getFileName();
        result += ":" + thisMethodStack.getLineNumber() + ")  ";
        return result;
    }

這里同樣需要注意的是類在混淆后是得不到正確的名稱的，所以可以酌情讓activity、fragment、view不被混淆，具體方案還是看自己的取舍。

增加當前線程的信息

當你調(diào)試過多線程，你就會發(fā)現(xiàn)log中帶有線程的信息是很方便的。

Thread.currentThread().getName()

Logger的尾巴上會帶有線程的名字，方便大家進行調(diào)試。

支持POJO、Map、Collection、jsonStr、Array

這個需求實現(xiàn)起來也比較容易：

• 如果是POJO，我們可用反射得到對象的類變量，通過字符串拼接的方式最終輸出值
• 如果是map等數(shù)組結(jié)構(gòu)，那么就用其內(nèi)部的遍歷依次輸出值和內(nèi)容
• 如果是json的字符串，就需要判斷json的{},[]這樣的特殊字符進行換行處理

至于具體是如何實現(xiàn)的，大家移步去看源碼就好，這個不是重點，重點是結(jié)果：

不推薦打印每次網(wǎng)絡(luò)請求的json，只推薦在調(diào)試某個數(shù)據(jù)的時候進行打印，否則信息太多，而且效率很低，不實用。

自定義輸出樣式

我們看到了orhanobut/logger和elvishew/xLog都十分好看，但是tianzhijiexian/logger的log看起來就沒那么美觀了，所以這個庫支持了自定的style，讓使用者可以自定義輸出樣式。

PrintStyle.java

public abstract class PrintStyle {

    @Nullable
    protected abstract String beforePrint();

    @NonNull
    protected abstract String printLog(String message, int line, int wholeLineCount);

    @Nullable
    protected abstract String afterPrint();
}

這個抽象類提供了三個方法，用來得到log打印前，打印時，打印后的內(nèi)容，我們可以通過它來實現(xiàn)自定義的樣式。

**使用XLog樣式后的輸出： **

PS：Logger的不美觀其實是折衷的結(jié)果。美觀必然會帶來數(shù)據(jù)的冗余，但原始的log卻又不足夠清晰。Logger最終選擇了一個輕量的log樣式，既保證了清晰易辨認又不會帶來過多的冗余信息。

支持超長的log信息

有時候網(wǎng)絡(luò)的返回值是很長的，android.util.Log類是有最大長度限制的。為了解決這個問題，我們只需要判斷這個字符串的長度，然后手動讓其換行即可。

private static final int CHUNK_SIZE = 4000;

if (length <= CHUNK_SIZE) {
    logContent(logType, tag, msg);
} else {
    for (int i = 0; i < length; i += CHUNK_SIZE) {
        int count = Math.min(length - i, CHUNK_SIZE);
        //create a new String with system's default charset (which is UTF-8 for Android)
        logContent(logType, tag, new String(bytes, i, count));
    }
}

自定義過濾規(guī)則

當崩潰出現(xiàn)的時候，有時候會將我們的log清屏，大大影響了我們的調(diào)試工作。所以我們可以在合適的時候利用Edit Filter Configuration這個功能。

Edit Filter Configuration十分強大，并且支持正則。一般情況下使用Show only selected application就搞定了，是否使用Edit Filter Configuration就看你的具體場景了。

擴展篇

增加自動化或強制開關(guān)

要區(qū)分release和debug版本，可以用自帶的BuildConfig.DEBUG變量，用這個也就可以控制是否顯示log了。做個強制開關(guān)也很簡單，在log初始化的最后判斷強制開關(guān)是否打開，如果打開那么就覆蓋之前的顯示設(shè)置，直接顯示log。轉(zhuǎn)為代碼就是這樣：

public class BaseApplication extends Application {

    // 定義是否是強制顯示log的模式
    protected static final boolean LOG = false;

    @Override
    public void onCreate() {
        Logger.initialize(
            new Settings()
                    .setLogPriority(BuildConfig.DEBUG ? Log.VERBOSE : Log.ASSERT)
        );
        
        // 如果是強制顯示log，那么無論在什么模式下都顯示log
        if (LOG) {
            Logger.getSettings().setLogPriority(Log.VERBOSE)
        }
    }
}

以后要是需要做log的開關(guān)，那么只需要通過settings重設(shè)log級別即可：

Logger.getSettings().setLogPriority(Log.ASSERT); // close log

解決log字符拼接的效率影響

多參數(shù)log信息應(yīng)該利用占位符進行打印，盡量避免手動拼接字符串。這樣好處是：在關(guān)閉log后就不會進行字符串的拼接工作了，減少log語句在release版本中的性能影響。

封裝類.d("test %s%s", "v", 5); // test v5

public static void d(@Nullable String info, Object... args) {
    if (!mIsOpen) { // 如果把開關(guān)關(guān)閉了，自然就不進行字符串拼接
        return;
    }
    Logger.d(info, args); // 內(nèi)部會做String.format()
}

這條來自朋友helder的建議，感謝！

通過混淆剔除log代碼

如果你確定你的log代碼在release版本中是無需存在的，那么我分享一個方案來幫你干掉它。

比如你的混淆配置文件叫proguard-rules.pro，里面有如下代碼：

-assumenosideeffects class kale.log.LL { // 假設(shè)我們的log類是LL
    public static *** d(...); // public static void d(...);
    public static *** i(...);
    public static *** v(...);
}

然后在build.gradlez中啟用混淆：

buildTypes {
        release {
            minifyEnabled true
            shrinkResources true // 是否去除無效的資源文件
            // 注意是用proguard-android-optimize.txt而不是proguard-android.txt
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
    }

要令assumenosideeffects生效，就需要開啟混淆中的優(yōu)化選項，而默認的proguard-android.txt是不會開啟優(yōu)化選項的。如果我們需要開啟混淆的話，那么建議我們采用 proguard-android-optimize.txt。

proguard-android-optimize的全部內(nèi)容如下：

# This is a configuration file for ProGuard.
# http://proguard.sourceforge.net/index.html#manual/usage.html

# Optimizations: If you don't want to optimize, use the
# proguard-android.txt configuration file instead of this one, which
# turns off the optimization flags.  Adding optimization introduces
# certain risks, since for example not all optimizations performed by
# ProGuard works on all versions of Dalvik.  The following flags turn
# off various optimizations known to have issues, but the list may not
# be complete or up to date. (The "arithmetic" optimization can be
# used if you are only targeting Android 2.0 or later.)  Make sure you
# test thoroughly if you go this route.
-optimizations !code/simplification/arithmetic,!code/simplification/cast,!field/*,!class/merging/*
-optimizationpasses 5
-allowaccessmodification
-dontpreverify

# The remainder of this file is identical to the non-optimized version
# of the Proguard configuration file (except that the other file has
# flags to turn off optimization).

-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-verbose

-keepattributes *Annotation*
-keep public class com.google.vending.licensing.ILicensingService
-keep public class com.android.vending.licensing.ILicensingService

# For native methods, see http://proguard.sourceforge.net/manual/examples.html#native
-keepclasseswithmembernames class * {
    native <methods>;
}

# keep setters in Views so that animations can still work.
# see http://proguard.sourceforge.net/manual/examples.html#beans
-keepclassmembers public class * extends android.view.View {
   void set*(***);
   *** get*();
}

# We want to keep methods in Activity that could be used in the XML attribute onClick
-keepclassmembers class * extends android.app.Activity {
   public void *(android.view.View);
}

# For enumeration classes, see http://proguard.sourceforge.net/manual/examples.html#enumerations
-keepclassmembers enum * {
    public static **[] values();
    public static ** valueOf(java.lang.String);
}

-keepclassmembers class * implements android.os.Parcelable {
  public static final android.os.Parcelable$Creator CREATOR;
}

-keepclassmembers class **.R$* {
    public static <fields>;
}

# The support library contains references to newer platform versions.
# Don't warn about those in case this app is linking against an older
# platform version.  We know about them, and they are safe.
-dontwarn android.support.**

# Understand the @Keep support annotation.
-keep class android.support.annotation.Keep

-keep @android.support.annotation.Keep class * {*;}

-keepclasseswithmembers class * {
    @android.support.annotation.Keep <methods>;
}

-keepclasseswithmembers class * {
    @android.support.annotation.Keep <fields>;
}

-keepclasseswithmembers class * {
    @android.support.annotation.Keep <init>(...);
}

上面的注釋就是采用優(yōu)化方案來剔除log的風(fēng)險點，所以要慎重使用！！！

這里也提到了一般推薦用proguard-android.txt來做混淆方案，如果你要是用了proguard-android-optimize.txt的話，請一定要測試充分在發(fā)布app。

將try-catch的信息通過log上傳到Crashlytics

我們有時候為了防御某個未知原因的崩潰，經(jīng)常會進行try-catch。這樣雖然讓其沒崩潰，但是也隱藏了錯誤，以至于我們始終沒有辦法弄懂錯誤出現(xiàn)的原因。
我希望可以通過把catch的異常通過log系統(tǒng)分發(fā)到崩潰分析網(wǎng)站上（如：Crashlytics），這樣既能防御問題，又可以幫助開發(fā)者知道崩潰產(chǎn)生的原因，方便以后針對性的進行處理。

代碼參考自：https://blog.xmartlabs.com/2015/07/09/Android-logging-with-Crashlytics-and-Timber/

模擬

    /**
     * 這里模擬后端給客戶端傳值的情況。
     *
     * 這里的id來自外部輸入，如果外部輸入的值有問題，那么就可能崩潰。
     * 但理論上是不會有數(shù)據(jù)異常的，為了不崩潰，這里加try-catch
     */
    private void setRes(@StringRes int resId) {
        TextView view = new TextView(this);

        try {
            view.setText(resId); // 如果出現(xiàn)了崩潰，那么就會調(diào)用崩潰處理機制
        } catch (Exception e) {
            // 防御了崩潰
            e.printStackTrace();
            
            // 把崩潰的異常和當前的上下文通過log系統(tǒng)分發(fā)
            Logger.e(e, "res id = " + resId);
        }
    }

接下來，我們建立一個crash分發(fā)tree：

public class CrashlyticsTree extends Timber.Tree {

    @Override
    protected void log(int priority, @Nullable String tag, @Nullable String message, @Nullable Throwable t) {
        if (priority == Log.VERBOSE || priority == Log.DEBUG || priority == Log.INFO) {
            // 只分發(fā)異常
            return;
        }

        if (t == null && message != null) {
            Crashlytics.logException(new Exception(message));
        } else if (t != null && message != null) {
            Crashlytics.logException(new Exception(message, t));
        } else if (t != null) {
            Crashlytics.logException(t);
        }
    }
}

// ---------------

if (!BuildConfig.DEBUG) {    // for release    
    Logger.plant(new CrashlyticsTree()); // plant a tree
}

一旦用戶發(fā)生了崩潰，我們現(xiàn)在就可以通過Crashlytics進行分析，這樣的錯誤會自動歸檔在Crashlytics報表的non-fatals中。通過這樣的方式，可以方便我們排查出真正的問題，解決后就可以真正去掉這個try-catch了。

注意：
因為我們有些錯誤是不希望上傳的，有些是希望上傳的，所以我建議在使用Logger.e()的時候，通過你的包裝類來做個處理（加參數(shù)或加方法），讓使用者明確這個log將通向何方，不希望引起理解混亂。

增加log的擴展性

正如上面提到的，我們的log可能需要分發(fā)到不同的系統(tǒng)，這也是我采用timber的原因。我們除了將線上的錯誤分發(fā)到崩潰統(tǒng)計系統(tǒng)外，也可能要將log保存到sd卡或是做其他的處理，所以目前l(fā)ogger利用timber的tree實現(xiàn)了分發(fā)的功能。

Logger內(nèi)部的實現(xiàn)：

public static void plant(Timber.Tree tree) {
    Timber.plant(tree);
}

關(guān)于如何plant可以參考下Timber的具體代碼。

通過自定義lint來規(guī)范log

大多數(shù)團隊會定義自己的log類來進行l(wèi)og的打印，我們最好可以通過自定義的lint來在代碼編寫時防止開發(fā)者錯用log類。

詳細的內(nèi)容可以參考：《Android自定義Lint實踐》

利用IDEA的debug工具打log

上文中我就提到了可以利用as的調(diào)試模式來加速debug，下面分享下兩個和log有關(guān)的經(jīng)驗。

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "MainActivity";
    
    private int index = 0;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
        Button button = (Button) findViewById(R.id.button);
        button.setOnClickListener(v-> {
                index = 123;
                Log.d(TAG, "onClick: index = " + index);
                index++;
            }
        );
    ｝
｝

1.通過斷點來代替log
如果你的目的僅僅是進行調(diào)試，那么以我的經(jīng)驗來看，我推薦通過斷點進行操作而不是log。

斷點的好處是隨時熱部署不用重新跑一次代碼，而且完全無入侵。如果你要調(diào)試的是再某個場景下的情況，你也可以通過條件斷點進行處理：

2.通過console熱部署打印log信息
我通過debug工具，可以在任意位置打印出任意對象的值，通過這種方式就可以精準調(diào)試一些信息了。
下圖是我讓其在不中斷運行的情況下打印index的值。

3.動態(tài)設(shè)置值
有時候某種分支需要在某個情況下才能走到，我可以利用debug的setValue（F12）方法動態(tài)設(shè)置值，比如我把下面的123改成了520，最終在終端打印出的信息也會變成520。整個過程對原本代碼完全屏蔽，無入侵。

PS：更多的調(diào)試技巧可以查看Android-Best-Practices中的推薦的調(diào)試技巧的文章。

因地制宜的使用log

雖然我提出了上面的思路和方案，但我并不能確保可以滿足所有的需求，我給出下面的思維流程，方便大家隨機應(yīng)變：

1. 盡量用as的debug模式下的log系統(tǒng)，無入侵。不用寫代碼就能打log，十分方便。
2. 如果真的要打log做調(diào)試，先用debug和error級別，提交代碼時務(wù)必記得清除。
3. 如果提交的代碼中需要在某個關(guān)鍵點打log，或者要持續(xù)調(diào)試，可以用info以上的log。
4. 在realse中用自己的log包裝類的開關(guān)做處理，這樣方便在公司內(nèi)部測試時可以查看到log。
5. 如果一些信息需要在用戶版本中保留，優(yōu)先考慮數(shù)據(jù)統(tǒng)計的方式進行關(guān)鍵點的打點。
6. 如果真的要在發(fā)布出去的apk中帶著log，只保留info級別以上的，不輕易把info級別之下的信息漏出去。

通過在線工具瀏覽log

開發(fā)們都會遇到測試在測試的時候出現(xiàn)了崩潰但是當時忘記抓到log了，我們拿到手機的時候已經(jīng)沒有了當時的現(xiàn)場信息。一般的做法是拿到手機進入adb shell，然后dump出log信息。
tianzhijiexian/Logcat利用了公司內(nèi)網(wǎng)和手機作服務(wù)器的能力，讓開發(fā)者或測試可以遠程看到log信息。這種方式不用進行usb鏈接，而且對于測試人員無學(xué)習(xí)成本，同樣也適合于遠程和用戶一對一進行調(diào)式的情形。

四、總結(jié)

我們可以看到即使一行代碼的log都有很多點是可優(yōu)化的，還明白了我們之前一直寫的模板式代碼是多么的枯燥乏味。
通過這篇文章，希望大家可以看到一個優(yōu)化編碼的思維過程，也希望大家去嘗試下logger這個庫。當然，我知道還是有很多人不喜歡，那么不妨提出更好的解決方案來一起討論，不滿意可以提issue。
要知道精品永遠是個位數(shù)，而中庸的東西永遠是層出不窮的。我希望大家多提意見齊心協(xié)力優(yōu)化出一個精品，而不是花時間去在平庸的選項中做著選擇難題。

五、尾聲

在文章中我給出了通過idea的debug模式下打印log的方法，目的是即使你有了這個log庫，但我仍舊希望你可以能找到更好的方法來達到調(diào)試的目的。擁有技巧，使用技巧，最終化為無形才是最高境界。相信我們的最終目的是一致的，那就是讓開發(fā)越來越簡便，越來越優(yōu)雅~

最后說下我沒直接用文章開頭那幾個庫的原因，logger的庫很漂亮，但是冗余行數(shù)過多，調(diào)試多行的數(shù)據(jù)就會受到信息干擾。timber的本身設(shè)計就是一個log的框架，打印是交給開發(fā)者自定義的，所以我將timber的框架和logger的美觀實現(xiàn)進行了結(jié)合。這當然還要感謝logUtils的作者，讓log支持了object類型。

有朋友問，你為什么不自己實現(xiàn)log框架，而是依賴于timber做呢，這樣會不會太重？其實logger的1.1.6版本中，我確實是自己實現(xiàn)了所有的功能，沒有依賴于任何庫。當我看到了timber后，我發(fā)現(xiàn)我做的工作和這個庫的重疊性太高了，而且它的設(shè)計也很值得學(xué)習(xí)。于是我直接依賴于它做了重構(gòu)，我現(xiàn)在只關(guān)心log的美化和功能的擴展，log分發(fā)的事情就交給timber了。

developer-kale@foxmail.com

微博：@天之界線2010

參考文章：

• 如何優(yōu)雅正確地使用Log

• 關(guān)于Android Log的一些思考

• Android自定義Lint實踐

• ANDROID LOGGING WITH CRASHLYTICS AND TIMBER

• Code Style for Contributors-log-sparingly