Android 技巧-Debug 判斷不再用 BuildConfig
Android 開發(fā)中一般會通過 BuildConfig.DEBUG 判斷是否是 Debug 模式，從而做一些在 Debug 模式才開啟的特殊操作，比如打印日志。這樣好處是不用在發(fā)布前去主動修改，因為這個值在 Debug 模式下為 true，Release 模式下為 false。
1. 問題
如果應(yīng)用只有一個 Module 沒有問題，Debug 模式下 BuildConfig.DEBUG 會始終為 false。如果現(xiàn)在有兩個 Module，分別為 App 和 Lib，且 App 依賴 Lib，在 Lib 內(nèi)有工具類 LogUtils，代碼如下：
當(dāng)我們在 App Module 內(nèi)調(diào)用 LogUtils 時我們會發(fā)現(xiàn)始終無法打印日志，因為上面的 BuildConfig.DEBUG 會始終為 false。為什么呢?
2. 原因
BuildConfig.java 是編譯時自動生成的，并且每個 Module 都會生成一份，以該 Module 的 packageName 為 BuildConfig.java 的 packageName。所以如果你的應(yīng)用有多個 Module 就會有多個 BuildConfig.java 生成，而上面的 Lib Module import 的是自己的 BuildConfig.java，編譯時被依賴的 Module 默認(rèn)會提供 Release 版給其他 Module 或工程使用，這就導(dǎo)致該 BuildConfig.DEBUG 會始終為 true。
3. 解決方案
根據(jù)上面分析的原因，目前我們有兩個思路:
(1) 始終調(diào)用最終運(yùn)行的 Module 的 BuildConfig，因為它沒有被任何其他 Module 依賴，所以 BuildConfig.DEBUG 值會準(zhǔn)確。
(2) 讓被依賴的 Module 提供除 Release 版以外的其他版本。
3.1 解決方案一：使用其他的 BuildConfig.java
如果 Lib Module 中能夠 import 到外層真正運(yùn)行 App 的 BuildConfig 就 ok 了，如下：
通過反射得到真正執(zhí)行的 Module 的 BuildConfig，在自己的 Application 內(nèi)調(diào)用：
AppUtils.syncIsDebug(getApplicationContext());
這樣看起來達(dá)到目的了。
但仔細(xì)看看會發(fā)現(xiàn)這種解決方案還是有問題，因為 BuildConfig.java 的 packageName 是 Module 的 Package Name，即 AndroidManifest.xml 中的 package 屬性，而 context.getPackageName() 得到的是應(yīng)用的 applicationId，這個 applicationId 通過 build.gradle 是可以修改的。所以當(dāng) build.gradle 中的 applicationId 與 AndroidManifest.xml 中的 package 屬性不一致時，上面的反射查找類路徑便會出錯。
PS：這種方案還有個變種就是通過 android.app.ActivityThread.currentPackageName 得到包名，從而省去傳遞 Context 初始化的步驟，但依然有 applicationId 被修改后類查找不到類似的問題。
3.2 解決方案二：Lib publishNonDefault
讓被依賴的 Module 提供除 Release 版以外的其他版本，這種方案需要將所有被依賴 library 中添加：
- android {
- publishNonDefault true
- }
表示該 Module 不使用默認(rèn)配置，這樣會同時打包其他版本，包括 Debug 版。另外需要在 App Module 中將其依賴的 library 如下逐個添加：
- dependencies {
- releaseCompile project(path: ':library', configuration: 'release')
- debugCompile project(path: ':library', configuration: 'debug')
- }
表示依賴不同版本的依賴 Module。
然而這種方式所有 Module 配置都需要修改，侵入性太強(qiáng)。
3.3 最終解決方案：使用 ApplicationInfo.FLAG_DEBUGGABLE
既然 BuildConfig 的方式行不通，我們反編譯 Debug 包和 Release 包對比看看有沒有其他的區(qū)別，會發(fā)現(xiàn)他們 AndroidManifest.xml 中 application 節(jié)點(diǎn)的 android:debuggable 值是不同的。Debug 包值為 false，Release 包值為 true，這是編譯自動修改的。所以我們考慮通過 ApplicationInfo 的這個屬性去判斷是否是 Debug 版本，如下：
在自己的 Application 內(nèi)調(diào)用進(jìn)行初始化，
AppUtils.syncIsDebug(getApplicationContext());
這樣以后調(diào)用 AppUtils.isDebug() 即可判斷是否是 Debug 版本，比如在上面的 LogUtils 中。同時適用于 Module 是 Lib 和 applicationId 被修改的情況，比 BuildConfig.DEBUG 靠譜的多。
這個方案有個注意事項就是自己 App Module 中不能主動設(shè)置 android:debuggable，否則無論 Debug 還是 Release 版會始終是設(shè)置的值。當(dāng)然本身就沒有自動設(shè)置的必要。
【本文是51CTO專欄作者Trinea的原創(chuàng)文章，轉(zhuǎn)載聯(lián)系作者本人獲取授權(quán)】
