在 Android 開發(fā)過程中狭姨，BuildConfig.Debug 這個變量用來判斷當前運行環(huán)境是不是支持調(diào)試模式宰啦。我們常常利用這個變量的判斷在開發(fā)或者測試包中做一些代碼追蹤、測試工具開啟饼拍、調(diào)試信息等工作赡模。不過在 Android 依賴庫中默認編譯出來的包并不會像編譯應(yīng)用一樣默認會自動生成 release 和 debug 兩種包，它只會默認生成 release 一個版本的包师抄，可以參考這里漓柑。在 release 版本的包里面，除非你有做過改動，不然默認 debuggable 這個值是 false辆布。
常見的依賴庫的使用方式有兩種瞬矩，一種是把依賴庫的作為一個模塊和主項目一起編譯，也就是文件依賴锋玲；另一種是使用 aar 的方式引用景用，下面分別針對兩種不同的提供對應(yīng)得解決方案。
文件依賴方式
其實 這個問題 早在 2013 年就有人在 Google Group 上提出來惭蹂。根據(jù) 官方文檔伞插，我們可以通過控制 publishNonDefault 這個變量的配置來使得依賴庫在編譯的時候默認生成所有變種的包，而不是僅僅生成 release 一種盾碗。
在依賴項目中添加這個配置：
android {
publishNonDefault true
...
}
這樣在編譯完成后媚污，默認情況下我們可以在輸出目錄看到兩個 aar 文件（之前只有一個）。然后在項目中聲明依賴的時候置尔，區(qū)分不同的編譯類型進行依賴：
dependencies {
debugCompile project(path: ':myLocalLibrary', configuration: 'debug')
releaseCompile project(path: ':myLocalLibrary', configuration: 'release')
}
這樣在調(diào)試應(yīng)用的過程中會使用依賴庫的 debug 版本杠步，而在正式發(fā)布應(yīng)用的時候就會用 release 版本。
AAR 依賴方式
Library 還有一種更為常見的依賴方式——aar 依賴榜轿。當然如果是正式發(fā)布的依賴庫幽歼，不支持 debug 功能是很合理并且應(yīng)該鼓勵的。但是谬盐，不能忽視的是在我們開發(fā)過程頻繁使用的 snapshot 版本甸私，這是開發(fā)過程中的測試版本，在這個版本中支持調(diào)試功能即合理也很有必要飞傀。
在前面官方文檔中皇型，我們發(fā)現(xiàn)還有一個配置信息可以利用 defaultPublishConfig。這個變量用于指定使用哪個變種的包作為默認編譯的版本砸烦。默認這個值是 release弃鸦。你可以在項目的配置添加：
android {
defaultPublishConfig "debug"
...
}
這個配置項后面的值是編譯變種的全稱，如果對于變種（variants）的概念不是很熟悉的話幢痘，可以回去再看看 Google 的 定義唬格。
如果沒有定義針對變種做過配置的話，默認支持
release和debug兩種颜说，這是根據(jù)這兩種默認編譯類型自動生成的购岗。
這里有一個明顯的 bug，必須在發(fā)布正式包和 snapshot 包的時候手動切換配置項的值门粪。在我的項目中喊积，我在發(fā)布 aar 包的時候，是通過在 gradle.properties 這個文件添加 isRelease 這個變量來區(qū)分的玄妈。當這個值是 true 的時候則會發(fā)布正式包乾吻，反之則發(fā)布 snapshot 版本髓梅。于是我也利用這個值來控制這個配置項的配置：
android {
defaultPublishConfig System.properties['isRelease'].toBoolean() ? "release" : "debug"
...
}
在 Groovy 中看到熟悉的三目運算好親切啊，想到在 Kotlin 中沒有三目運算就心塞溶弟。
這樣在發(fā)布依賴包時女淑，就能自動實現(xiàn)在 snapshot 包支持調(diào)試功能，而不影響正式包辜御。
其他方案
代碼注入
如果不使用這種方式鸭你，在代碼層面想辦法繞過這個限制也不是特別困難。比如我們可以在依賴庫中提供接口擒权，然后在項目中將是否支持 Debug 狀態(tài)的判斷注入到依賴庫中袱巨，從而實現(xiàn)依賴庫和主項目之間的 Debug 狀態(tài)保持一致。
雖然這種方案也可以解決問題碳抄，但是我個人不是很推薦愉老。這種配置方式本身和依賴庫的功能沒有關(guān)聯(lián)性，而且無形增加了依賴庫的接入成本剖效。
手動修改
還有一種方案嫉入，是在依賴庫編譯完成之后，通過判斷當前編譯變種的類型璧尸，手動去修改 BuildConfig 里面的值咒林。這種方案無形增加了解決問題的復(fù)雜度，和前面利用官方配置項沒有本質(zhì)區(qū)別爷光。根據(jù)這種方案的提出的時間垫竞，我猜測這應(yīng)該是在官方支持如上描述的配置方案之前的方案。
原文鏈接：Library 不支持調(diào)試模式蛀序，不能忍
歡迎關(guān)注 Kotlin Three
