：## 為什么
為什么要尋找單獨的logger庫？用Andorid原生的Log不好嗎？原生Log長得這樣：
先分級，再打上TAG，然后直接輸出。功能很基礎，平時基本夠用。但是在長期的Android開發實踐中，我們會發現，這個功能太基礎了，當：
- 每次打TAG都要寫下雷同的代碼，太不DRY了。
- 想打印的數據各種打不出，要么就是打出來一長串看的發暈。
- 為了找某條log是從哪里打出來的，還要花點功夫。
- 即使找到了，怎么知道運行時是在哪個線程？
- 日志去了不再來。在未連接調試的手機上，或者調試中不小心重啟App了，日志就沒了。
不多說了，光這幾個問題就夠我們有充分的理由去尋找一個新的Log系統了。先從最常用的下手，從網上能搜到最常用的Android logger有兩個。
- https://github.com/orhanobut/logger ：簡單、漂亮、強大的Android logger，github上3000+ Star
- https://github.com/JakeWharton/timber ：基于Android原生Log的logger，小巧易擴展。
看簡介幫助不大，我們還是真刀真槍用一下，看看這兩個開源庫為什么這么受歡迎，有沒有解決我們的問題。
好Logger應該長什么樣？
動手分析之前，我們要先想想清楚，我們要的好Logger，應該是什么樣的？
打印日志是一門傳統藝術，歷史悠久，打從有編程那年就開始有了。它與單步調試并稱程序調試兩大神技，程序員們因為擁護不同的調試方法，分裂成了兩大陣營：日志派和調試派，兩派互相看不起。調試派說打印日志太沒技術含量，還要到處做標記，看我們調試派，想停哪里點哪里，想看什么看什么，調試器能帶我飛。日志派也不服氣，你能離線調試嗎？你能調試多線程錯誤嗎？你能xxx調試嗎？
好程序員兩種技能都要掌握，現在調試工具越來越好用，單步調試沒有任何困難。但是打印日志仍然是不可或缺的必殺技，尤其是查活系統(運行中軟件)的問題時，如果沒有后臺日志或者用戶手機日志，真是打死也不知道哪里出了問題。
扯完日志的重要性，認真說說我們對日志系統的需求：
- 容易打印：無論什么格式的數據，上到自定義類，下到字節流，都能單行代碼給打出來，不用為了打日志寫一堆額外的代碼邏輯。
- 格式漂亮：對格式化數據做打印美化，必要時適當做點排版。
- 容易篩選：給日志分級和打標簽，就是為了達到這個目的。
- 立即定位：每條日志都有兩個位置，代碼中的位置和運行時位置(所在線程)。這兩個位置對快速定位問題很重要。
- 靈活設置：日志數量和日志詳細程度是一對矛盾體。大多數情況下，普通的日志就夠我們分析問題了。但是某些情況下，如多線程問題，異步問題，需要打印盡量詳細的信息，這個要能靈活設置。
- 日志留存：日志打到屏幕上，說沒就沒。有沒有辦法屏幕上打一份，SD卡上存一份，崩潰信息網站上留一份？這有點類似linux上的tee命令。
- 容易上手：本來沒想寫這條，也沒想到上面會列出這么多特性，沒辦法，還是加上個容易上手的指標吧。就是說上邊這些特性，
能做到上面幾點，我們就認為這個日志系統非常好了。注意，我為什么沒提性能要求？因為正式發布版本里，是不會有日志的，起碼不會大量存在，所以性能也就無所謂了，別太差就行。尺子有了，我們就用它來衡量一下Timber和Logger。
Logger分析
這個項目在github上有3000+ star，必有過人之處。
- 容易打印：除了普通字符串和含變量字符串，還能直接打印json、xml、異常，通過。
- 格式漂亮：的確漂亮，但是過分漂亮了。本來一行的日志給打成了8行，真超值。結果贈品太多，都找不到我想看的那條了。
- 容易篩選：能分級，能自動打tag，能自定義tag。等等，為什么tag不是類名？難道用類名當tag不是普世價值觀嗎？明白了，它的類名和方法名都在日志內容中有了，tag中不用再放一個了。但是有Android Monitor依賴癥的我表示，這讓我怎么篩選一眼望不到頭的日志呀，差評。
- 立即定位：能跳轉到文件位置，能看函數名、線程號，通過。
- 靈活設置：可以設置，但是設置項似乎不太豐富呀。
- 日志留存：不支持。
- 容易上手：一行代碼就能用，通過。
Timber分析
這個庫非常簡潔，準確講，它只有一個文件，是Jake Wharton大神自己用的。大神說嫌拷貝來拷貝去太麻煩，才開源成一個庫。
- 容易打印：支持普通字符串和含變量字符串。
- 格式漂亮：不支持。
- 容易篩選：自動用類名當tag，也可以自定義。
- 立即定位：不支持。
- 靈活設置：支持，但沒什么設置項。
- 日志留存：支持。
- 容易上手：還是吐槽一下，這個庫的tree和plant是什么鬼？我是讀完它的代碼才明白的。其實跟樹、種樹、木頭沒一毛錢關系，大神只是借種樹這個形象的方法，說日志可以寫到各種地方去。想寫哪里寫哪里，自己plant一個自己實現的Tree就可以了。不種樹就沒有日志。大神太幽默了。
總結
從總評價看，顯然Logger更好，特性更豐富。但是它的排版我實在接受不了。所以項目實踐中，我還是會用Timber。全劇終。
我去，這個結局太不能讓人滿意了，選了半天選了個不好用的，這世界怎么了？
改進
權衡之下，還是改造一下Logger吧。在github上fork了Logger的代碼，針對Logger不滿的地方，加入我的改動。為了保持Logger自身的特點，新改動通過Settings的形式加入，我給Settings加入mode設置。默認是pretty模式，一切用法與輸出結果與原Logger保持一致，可以通過單元測試。如果對PRETTY模式下日志過多有意見，可以啟用brief模式，去除無用的分割線，把默認日志從8行減為4行，保持可讀性和所有信息。如果還嫌多，可以啟動single模式，默認日志從8行壓縮到1行，保持必要信息。代碼庫見https://github.com/oreofish/logger
對這個改進的版本重新評估如下：
- 容易打印：同原作。
- 格式漂亮：可以方便的在8行的pretty模式，和4行的簡潔模式，和1行的單行模式中切換。
- 容易篩選：能分級，能自動打tag，能自定義tag。單行模式下用Android Monitor過濾日志很方便。通過。
- 立即定位：同原作，而且重點保持了"能跳轉到文件位置"這個特性，通過。
- 靈活設置：可以設置。
- 日志留存：暫不支持(我很喜歡這個特性，有空要加上)。
- 容易上手：一行代碼就能用，通過。
- 彩蛋：寫代碼時經常會加上一些臨時的日志，例如一大串相同的字符，只是為了在日志堆里容易看到。改進版本中加入了預定義的表情字符串IAMHERE1到IAMHERE6，就是為了容易看到。
開源大法好。這，就是我想要的日志系統。我會嘗試提交代碼給Logger官方，雖然由于思路不同，他們可能不會合并我的代碼:)
結論
- 如果對日志要求不高，簡單用用而已，Android自帶的Log就不錯。
- 如果厭煩了Android Log，覺得用著不方便，Timber和Logger都是好選擇，Timber只要一個文件。
- 如果你覺得日志很重要，特別推薦的我的改進版Logger。
- 還覺得不好？把你的需求說出來，或者自己動手改進，都歡迎。
