本文會不定期更新，推薦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類褒颈。
二柒巫、需求
- 我才不要每次打log都去想tag叫什么名字呢
- 通常情況下請自動把當(dāng)前類名作為默認的tag，但也允許我自由指定
- 我希望我寫的模板式代碼越少越好谷丸，一個
logd就能打印一切 - 我要打印出list堡掏，map，json刨疼，pojo這樣的對象
- 我的log絕對不要和其余的雜亂log混在一起
- log信息過長后應(yīng)該要自動換行泉唁，我不允許我的log打印不全
- 我要我的log變的好看，直觀揩慕，就是美
- log中還要能顯示我當(dāng)前的線程名亭畜，方便我調(diào)試多線程
- 我打出的log后面要根上這個log的地址，可以直接外鏈到log的位置
- release包中不能泄漏我高傲的log迎卤，但只要我想讓它顯示拴鸵，release版本也阻擋不了我
- 在release版本中殘留的log代碼應(yīng)該對app運行效率影響極低
- 它能自動將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
默認情況下可以把當(dāng)前類名作為TAG的默認值，我們可以通過下面代碼來得到當(dāng)前類名：
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呢船庇？
在這種情況下我們可以采用如下兩種方案：
- 自行調(diào)試時關(guān)閉無關(guān)部門的log輸出
- 每個部門有自定義的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的模板提示的功能：
我們可以模仿原有的模板來做自己的代碼模板造虏，簡化模板式代碼的輸入御吞。至于具體模仿的方式我就不手把手教了，相當(dāng)簡單漓藕。下面僅展示下自帶的log模板的使用：
生成TAG：
自動填寫參數(shù)和方法名：
顯示篇
讓log更加美觀
讓log的輸出直觀陶珠、美觀其實很簡單，就是在輸出前做點字符串拼接的工作,比如加上下面這行橫線享钞。
private static final String BOTTOM_BORDER = "╚═══════════════════════════";
因為做了很多拼接的工作揍诽，所以好看的log也是消耗性能的。我的習(xí)慣是調(diào)試完畢后立刻刪除無用的log栗竖，這樣既能減少性能影響暑脆，也能減少同事的閱讀代碼的負擔(dān)。采用輕量級美化后效果如下：
顯示當(dāng)前方法名狐肢、所在類并加超鏈
這個功能其實ide是原生支持的添吗，不相信的話你隨便用原生的log打印出onCreate: (MainActivity.java:31)試試。
我們可以通過下面的方法來做到更好的效果：
private static String callMethodAndLine() {
String result = "at ";
StackTraceElement thisMethodStack = (new Exception()).getStackTrace()[1];
result += thisMethodStack.getClassName()+ "."; // 當(dāng)前的類名（全名）
result += thisMethodStack.getMethodName();
result += "(" + thisMethodStack.getFileName();
result += ":" + thisMethodStack.getLineNumber() + ") ";
return result;
}
這里同樣需要注意的是類在混淆后是得不到正確的名稱的份名，所以可以酌情讓activity碟联、fragment妓美、view不被混淆，具體方案還是看自己的取舍鲤孵。
增加當(dāng)前線程的信息
當(dāng)你調(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ī)則
當(dāng)崩潰出現(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();
// 把崩潰的異常和當(dāng)前的上下文通過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)變：
- 盡量用as的debug模式下的log系統(tǒng)，無入侵测垛。不用寫代碼就能打log捏膨，十分方便。
- 如果真的要打log做調(diào)試，先用debug和error級別号涯，提交代碼時務(wù)必記得清除目胡。
- 如果提交的代碼中需要在某個關(guān)鍵點打log，或者要持續(xù)調(diào)試链快，可以用info以上的log誉己。
- 在realse中用自己的log包裝類的開關(guān)做處理，這樣方便在公司內(nèi)部測試時可以查看到log域蜗。
- 如果一些信息需要在用戶版本中保留巨双，優(yōu)先考慮數(shù)據(jù)統(tǒng)計的方式進行關(guān)鍵點的打點。
- 如果真的要在發(fā)布出去的apk中帶著log霉祸，只保留info級別以上的筑累，不輕易把info級別之下的信息漏出去。
通過在線工具瀏覽log
開發(fā)們都會遇到測試在測試的時候出現(xiàn)了崩潰但是當(dāng)時忘記抓到log了丝蹭，我們拿到手機的時候已經(jīng)沒有了當(dā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這個庫。當(dāng)然帆离，我知道還是有很多人不喜歡蔬蕊，那么不妨提出更好的解決方案來一起討論，不滿意可以提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é)合理卑。這當(dāng)然還要感謝logUtils的作者，讓log支持了object類型蔽氨。
有朋友問，你為什么不自己實現(xiàn)log框架帆疟，而是依賴于timber做呢鹉究，這樣會不會太重？其實logger的1.1.6版本中踪宠，我確實是自己實現(xiàn)了所有的功能自赔，沒有依賴于任何庫。當(dāng)我看到了timber后柳琢，我發(fā)現(xiàn)我做的工作和這個庫的重疊性太高了绍妨，而且它的設(shè)計也很值得學(xué)習(xí)。于是我直接依賴于它做了重構(gòu)柬脸，我現(xiàn)在只關(guān)心log的美化和功能的擴展他去，log分發(fā)的事情就交給timber了。
參考文章：
