[[176407]]

LOG 是任何一種編程語言的***個API，通常被初學(xué)者用來打印 Hello, World!。 有研究顯示，

不使用 LOG 或者使用姿勢錯誤的人，感情路都走得很辛苦，有七成的比例會在 34 歲的時候跟自己不愛的人結(jié)婚，而其余三成的人***只能把遺產(chǎn)留給自己的貓。畢竟愛情需要書寫，不能是一整張白紙。

LogCat是Android開發(fā)者們最熟悉不過的日志打印工具，幾乎每一個Android項目里面都包含著大量的Log相關(guān)代碼。不過，或許是因為Log實在是太過于普通，所以許多人在使用它的時候就顯得非常隨意，這些錯誤的使用姿勢卻會在不經(jīng)意間給我們帶來不少的大坑。

Log相關(guān)的一些問題

沒有關(guān)閉調(diào)試用的LOG

許多同學(xué)喜歡在開發(fā)階段用Log輸出當(dāng)前的一些環(huán)境數(shù)據(jù)，用于調(diào)試代碼，但是在調(diào)試完成后卻忘了關(guān)閉這些Log，導(dǎo)致發(fā)版出去的應(yīng)用里面還會繼續(xù)輸出這些LOG，這樣不僅會造成不必要的性能丟失，也會暴露一些敏感的數(shù)據(jù)，這些都是我們不愿看到的。

首先，我們要給Log進(jìn)行分級，規(guī)定“DEBUG版本輸出哪一些級別的LOG并屏蔽哪一些級別的LOG，而RELEASE版本又輸出另一些級別的LOG并屏蔽另一些級別的LOG”，這樣在開發(fā)階段能夠輸出我們調(diào)試需要的LOG，而同時又能保證放送的版本能夠屏蔽這些敏感的LOG。但是在開發(fā)階段我們不應(yīng)該特意去注意這些細(xì)節(jié)，所以必須開發(fā)一個Log工具庫，在框架層級解決這個需求。

同時，需要注意的是，用于作為“開啟/關(guān)閉Log”的開關(guān)必須是一個常量，而不能是一個變量(使用常量的話，在編譯代碼的時候，如果常量為false)，編譯器會直接把調(diào)試部分的Log代碼直接去掉，而使用變量作為開關(guān)的話，這個判斷邏輯會繼續(xù)保留，一方面會造成性能丟失，另一方面在運行時也可以通過Hack手段強(qiáng)行開啟這部分Log代碼。

另外，“開啟/關(guān)閉Log”的開關(guān)必須寫在Log方法外部，也就是說必須先判斷“開啟/關(guān)閉Log”條件，再調(diào)用Log方法，因為在調(diào)用Log方法的時候已經(jīng)造成了性能丟失，而且調(diào)用方法的時候，會先構(gòu)造好改方法需要的參數(shù)(按照參數(shù)順序從右往左)，再調(diào)用方法，而許多人喜歡在調(diào)用Log方法的時候計算需要打印出來的內(nèi)容，這里是最容易造成性能丟失的地方。因此，如果為了圖方便，寫一個Log工具類，在工具類內(nèi)部去判斷是否應(yīng)該開啟或關(guān)閉Log，事實上已經(jīng)造成了不少的性能丟失。正確的使用姿勢應(yīng)該是：

public static final boolean DEBUG = true; 
 
if (DEBUG) { 
  Log.v(TAG, "log something"); 
}  

在循環(huán)體內(nèi)部打印LOG

盡管Log造成的性能損失很小，但是如果在循環(huán)體內(nèi)部循環(huán)調(diào)用Log方法的話，那總體的丟失的非?？捎^了，所以不應(yīng)該在循環(huán)體內(nèi)部使用Log，正確的做法是在循環(huán)體內(nèi)部拼接需要打印的內(nèi)容，等跳出循環(huán)體再一次打印出來。

除了常見的循環(huán)體外，還要一個需要注意的場景就是Adapter。ListView/RecyclerView是Android開發(fā)中最常用的控件，因此Adapter使用的情景也很多。滾動屏幕的時候，ListView/RecyclerView會在通過Adapter頻繁地綁定ItemView和數(shù)據(jù)，而且這些都是在UI線程里進(jìn)行的，所以如果在綁定的過程中調(diào)用Log，可能會造成明顯的卡頓。

至于Log到底會丟失多少性能，一般情況下，Log的性能丟失很小，畢竟是這么常見的系統(tǒng)Api，肯定是身經(jīng)百戰(zhàn)，早就是“best performance”了。不過我曾經(jīng)有個RecyclerView在MIUI上非?？?，一開始我是RecyclerView布局沒優(yōu)化好，最終定位到Adapter內(nèi)部的一處Log上，卡頓的地方出現(xiàn)在Log的Native實現(xiàn)。MIUI到底對用戶輸出的日志做了什么處理呢?非常神奇。

無法獲取重要LOG內(nèi)容

在調(diào)試代碼的時候，我們經(jīng)常通過LOG來定位Bug。同理，當(dāng)線上的版本出現(xiàn)問題的時候，我們也希望能通過LOG來定位問題所在。但是問題是用戶的設(shè)備上的打印出來的LOG我們根本沒有方法獲取，唯一的手段就是當(dāng)用戶設(shè)備出現(xiàn)問題的時候，把設(shè)備借過來連上IDE用LogCat查看輸出的LOG……顯然這是不可行的。

這種時候，我們可以在打印重要LOG(比如重要路徑的觸發(fā)點、或者一些異常類的信息)的時候，一并把這些信息記錄到文件里。在用戶反饋系統(tǒng)里面，一并將這些文件上傳到我們的用戶反饋服務(wù)器，這樣在處理反饋問題的時候，就能拿到重要的參考日志了。

BLog

BLog 是 Android SDK 的 LOG 工具 {@Link android.util.Log} 的加強(qiáng)版，以方便在開發(fā)時用來

操作調(diào)試日志。

特點

1. 簡單易用的API;
2. 支持輸出線程信息;
3. 支持設(shè)置LogLevel，方便在生產(chǎn)環(huán)境關(guān)閉調(diào)試用的LOG;
4. 支持將LOG內(nèi)容寫入文件，以便通過文件LOG定位用戶反饋的問題;

注意，盡管BLog支持關(guān)閉Log的輸出，但是在你調(diào)用 BLog.v(String) 的時候，其實已經(jīng)造成了性能

丟失，所以請盡量使用正確的姿勢來使用BLog，比如

if (BuildConfig.DEBUG) {   
  BLog.v(TAG, "log verbose"); 
}