自定義常量
開發階段利用 Log 日志方便代碼調試是再常見不過的事情。出于安全考慮，這種做法僅限于 Debug 模式，Release 模式下打包發布時一定要關掉。所以在我們的項目中，一定會有一個工具類或者方法來控制 Log 日志的使用，比如：
public class LogUtils {
public static final Boolean DEBUG_MODE = true;
public static void d(String message) {
if (DEBUG_MODE) {
Log.d("TAG", message);
}
}
}
常見的做法便是像上面這樣，自定義一個布爾類型的常量作為開關來控制是否打印日志。但是這種做法有一個弊端，那就是每次發布 Release 包時都需要手動修改這個常量的值為 false，然后下一次開發階段再手動修改為 true。
雖然是很簡單的手動修改操作，但是也很容易忘記。那么有沒有一種辦法實現自動化管理呢？答案當然是有的，使用 BuildConfig 類。
BuildConfig
類似 R 資源文件，BuildConfig 也是在編譯階段，Gradle 插件自動生成的一個 class 文件。該文件包含一些幫助開發人員辨別當前 build 類型的常量信息。當然你也可以通過 Gradle 提供的定制功能向該文件里面添加其他輔助內容。這里我們看一下默認情況下，BuildConfig 文件都包含有哪些內容：
public final class BuildConfig {
public static final boolean DEBUG = Boolean.parseBoolean("true");
public static final String APPLICATION_ID = "com.yifeng.sample";
public static final String BUILD_TYPE = "debug";
public static final String FLAVOR = "";
public static final int VERSION_CODE = 1;
public static final String VERSION_NAME = "1.0";
}
能夠看出，都是一些大家很熟悉的信息。其中包括一個 DEBUG 常量，其值便可用于判斷當前 build 類型。debug 模式下為 true，release 模式下為 false。所以，使用 BuildConfig.DEBUG 可以替代前面我們自定義的常量，實現自動管理 Log 日志的打印：
public static void d(String message) {
if (BuildConfig.DEBUG) {
Log.d("TAG", message);
}
}
看上去貌似已經很完美了，但其實還是有瑕疵的。BuildConfig 類文件的生成依據于 Module，也就是說每一個 Module 編譯時都會產生自己的這個文件。如果你的主 app module 使用其他依賴 module 中 BuildConfig 文件里面的 DEBUG 值，就需要多加注意。
默認情況下，Library 的構建永遠是以 Release 模式執行的，所以其 BuildConfig.DEBUG 值一定是 false！即使主 Module 使用 Debug 模式構建，也是如此。
那么，有沒有辦法修改 Library Module 的默認構建方式呢？答案也是肯定的。打開對應 Library 的 build.gradle 文件，添加這樣一行配置代碼：
android {
// 這里省略其他內容
publishNonDefault true
}
即表示不使用默認構建方式，編譯時也會自動生成其他 build 類型的 BuildConfig 類文件。你可以在相應 Library 路徑下查看配置該命令前后 BuildConfig 文件的生成情況，目錄地址為：
libraryName/build/generated/source/buildConfig/ + debug/release
然后在我們的主 Module 依賴的時候同時引入 debug 和 release 兩種配置，這里以 extras/PullToRefresh 作為 Library 為例，看下依賴代碼：
dependencies {
releaseCompile project(path: ':extras:PullToRefresh', configuration: 'release')
debugCompile project(path: ':extras:PullToRefresh', configuration: 'debug')
}
如此這般，便可以解決前面提到的依賴 Module 問題。當然，如果你的項目比較簡單，只是單一 Module，也就不存在這個問題。
但是如果項目中的依賴 Module 比較多的話，這種處理方式還是略顯麻煩。你需要在用到的地方針對每個 Module 逐一處理。其實還有一種更好的解決方案，那就是使用 Manifest 清單文件中 application 標簽里的 debuggable 屬性。
ApplicationInfo
application 標簽里有個 android:debuggable 屬性，表示當前應用是否可以被調試（一般不建議手動設置這個屬性）。這個屬性也會隨著 build 類型自動改變。所以，利用這個特性也能判定應用是否處于 Debug 模式，比如：
public static boolean isDebug(Context context) {
return (context.getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;
}
控制 Log 日志打印的開關，除了上面講到的這些方式，其實還有別的方式。比如利用 Gradle 的靈活性在 build.gradle 文件中自定義一個 Boolean 變量，根據 build 類型動態賦值，也能達到我們的目的。
更安全的 Log 用法
前面所有這些做法都只是使 release 包不去顯示 Log 日志，從而提高安全性。但是，有沒有想過，如果 apk 被反編譯的話，這些 Log 相關的代碼還是能夠別識別出來，別人只需要稍作修改，重新打包，依舊能夠使 Log 重現。
當然，使用常量作為 LogUtils 中的判斷條件的話，根據 proguard 的優化規則，在 Release 包中是不包含條件體中的 Log.d 等操作代碼的。關于這一點，可以自己反編譯 apk 嘗試看下。
然而，在其他調用 LogUtils 工具類的地方依舊暴露了我們的意圖。所以，定義一個 LogUtils 類雖然提高了使用 Log 的效率，依舊解決不了 Log 安全的問題。相比而言，我們做了這么多努力只是稍微提高了一些安全的門檻而已。
所以，最好的辦法就是，Release 包中不包含任何用于調試的 Log 代碼（如果使用 LogUtils 的話，也包括 該類的調用）。也就是說，不使用 LogUtils 工具類封裝，在任何需要的地方，不嫌麻煩的逐一添加判斷條件：（可以使用 Live Template 提高效率）
if (BuildConfig.DEBUG) {
Log.d("TAG", message);
}
這樣，打包時，開啟 proguard 后，Release 包會自動刪除上面的代碼，徹底根絕 Log 引發的安全問題。關于這一部分的細節操作，可以參考這兩篇文章：
（END）
