前言

本文主要給大家介紹了關(guān)于Android中能夠作為L(zhǎng)og開關(guān)的一些操作及安全性的相關(guān)內(nèi)容，分享出來供大家參考學(xué)習(xí)，下面話不多說了，來一起看看詳細(xì)的介紹吧。

自定義常量

開發(fā)階段利用 Log 日志方便代碼調(diào)試是再常見不過的事情。出于安全考慮，這種做法僅限于 Debug 模式，Release 模式下打包發(fā)布時(shí)一定要關(guān)掉。所以在我們的項(xiàng)目中，一定會(huì)有一個(gè)工具類或者方法來控制 Log 日志的使用，比如：

public class LogUtils {
 
 public static final Boolean DEBUG_MODE = true;
 
 public static void d(String message) {
  if (DEBUG_MODE) {
   Log.d("TAG", message);  
  }
 }
 
}

常見的做法便是像上面這樣，自定義一個(gè)布爾類型的常量作為開關(guān)來控制是否打印日志。但是這種做法有一個(gè)弊端，那就是每次發(fā)布 Release 包時(shí)都需要手動(dòng)修改這個(gè)常量的值為 false，然后下一次開發(fā)階段再手動(dòng)修改為 true。

雖然是很簡(jiǎn)單的手動(dòng)修改操作，但是也很容易忘記。那么有沒有一種辦法實(shí)現(xiàn)自動(dòng)化管理呢？答案當(dāng)然是有的，使用 BuildConfig 類。

BuildConfig

類似 R 資源文件，BuildConfig 也是在編譯階段，Gradle 插件自動(dòng)生成的一個(gè) class 文件。該文件包含一些幫助開發(fā)人員辨別當(dāng)前 build 類型的常量信息。當(dāng)然你也可以通過 Gradle 提供的定制功能向該文件里面添加其他輔助內(nèi)容。這里我們看一下默認(rèn)情況下，BuildConfig 文件都包含有哪些內(nèi)容：

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";
}

能夠看出，都是一些大家很熟悉的信息。其中包括一個(gè) DEBUG 常量，其值便可用于判斷當(dāng)前 build 類型。debug 模式下為 true，release 模式下為 false。所以，使用 BuildConfig.DEBUG 可以替代前面我們自定義的常量，實(shí)現(xiàn)自動(dòng)管理 Log 日志的打?。?/p>

public static void d(String message) {
 if (BuildConfig.DEBUG) {
  Log.d("TAG", message);
 }
}

看上去貌似已經(jīng)很完美了，但其實(shí)還是有瑕疵的。BuildConfig 類文件的生成依據(jù)于 Module，也就是說每一個(gè) Module 編譯時(shí)都會(huì)產(chǎn)生自己的這個(gè)文件。如果你的主 app module 使用其他依賴 module 中 BuildConfig 文件里面的 DEBUG 值，就需要多加注意。

默認(rèn)情況下，Library 的構(gòu)建永遠(yuǎn)是以 Release 模式執(zhí)行的，所以其 BuildConfig.DEBUG 值一定是 false！即使主 Module 使用 Debug 模式構(gòu)建，也是如此。

那么，有沒有辦法修改 Library Module 的默認(rèn)構(gòu)建方式呢？答案也是肯定的。打開對(duì)應(yīng) Library 的 build.gradle 文件，添加這樣一行配置代碼：

android {
 // 這里省略其他內(nèi)容
 publishNonDefault true
}

即表示不使用默認(rèn)構(gòu)建方式，編譯時(shí)也會(huì)自動(dòng)生成其他 build 類型的 BuildConfig 類文件。你可以在相應(yīng) Library 路徑下查看配置該命令前后 BuildConfig 文件的生成情況，目錄地址為：

libraryName/build/generated/source/buildConfig/ + debug/release

然后在我們的主 Module 依賴的時(shí)候同時(shí)引入 debug 和 release 兩種配置，這里以 extras/PullToRefresh 作為 Library 為例，看下依賴代碼：

dependencies {
 releaseCompile project(path: ':extras:PullToRefresh', configuration: 'release')
 debugCompile project(path: ':extras:PullToRefresh', configuration: 'debug')
}

如此這般，便可以解決前面提到的依賴 Module 問題。當(dāng)然，如果你的項(xiàng)目比較簡(jiǎn)單，只是單一 Module，也就不存在這個(gè)問題。

但是如果項(xiàng)目中的依賴 Module 比較多的話，這種處理方式還是略顯麻煩。你需要在用到的地方針對(duì)每個(gè) Module 逐一處理。其實(shí)還有一種更好的解決方案，那就是使用 Manifest 清單文件中 application 標(biāo)簽里的 debuggable 屬性。

ApplicationInfo

application 標(biāo)簽里有個(gè) android:debuggable 屬性，表示當(dāng)前應(yīng)用是否可以被調(diào)試（一般不建議手動(dòng)設(shè)置這個(gè)屬性）。這個(gè)屬性也會(huì)隨著 build 類型自動(dòng)改變。所以，利用這個(gè)特性也能判定應(yīng)用是否處于 Debug 模式，比如：

public static boolean isDebug(Context context) {
 return (context.getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;
}

控制 Log 日志打印的開關(guān)，除了上面講到的這些方式，其實(shí)還有別的方式。比如利用 Gradle 的靈活性在 build.gradle 文件中自定義一個(gè) Boolean 變量，根據(jù) build 類型動(dòng)態(tài)賦值，也能達(dá)到我們的目的。

Android自定義Log開關(guān)

有時(shí)Log太多會(huì)影響速度，需要根據(jù)需要開關(guān)Log，而Android IDE環(huán)境沒有這個(gè)功能，起碼Eclipse沒有，那么我們可以寫一個(gè)類將Log封裝，通過調(diào)用這個(gè)類設(shè)置boolean變量，控制Log是否有效。

public class MLog
{
public static final boolean DEBUG = true；//開關(guān)控制
public static void i(String tag,String msg)
{
if(DEBUG)
{
Log.i(tag,msg);
}
public static void e(String tag,String msg)
{
if(DEBUG)
{
Log.e(tag,msg);
}
//其它級(jí)別的同上...
}

使用的時(shí)候直接調(diào)用MLog替換Log即可。

更安全的 Log 用法

前面所有這些做法都只是使 release 包不去顯示 Log 日志，從而提高安全性。但是，有沒有想過，如果 apk 被反編譯的話，這些 Log 相關(guān)的代碼還是能夠別識(shí)別出來，別人只需要稍作修改，重新打包，依舊能夠使 Log 重現(xiàn)。

當(dāng)然，使用常量作為 LogUtils 中的判斷條件的話，根據(jù) proguard 的優(yōu)化規(guī)則，在 Release 包中是不包含條件體中的 Log.d 等操作代碼的。關(guān)于這一點(diǎn)，可以自己反編譯 apk 嘗試看下。

然而，在其他調(diào)用 LogUtils 工具類的地方依舊暴露了我們的意圖。所以，定義一個(gè) LogUtils 類雖然提高了使用 Log 的效率，依舊解決不了 Log 安全的問題。相比而言，我們做了這么多努力只是稍微提高了一些安全的門檻而已。

所以，最好的辦法就是，Release 包中不包含任何用于調(diào)試的 Log 代碼（如果使用 LogUtils 的話，也包括 該類的調(diào)用）。也就是說，不使用 LogUtils 工具類封裝，在任何需要的地方，不嫌麻煩的逐一添加判斷條件：（可以使用 Live Template 提高效率）

if (BuildConfig.DEBUG) {
 Log.d("TAG", message);  
}

這樣，打包時(shí)，開啟 proguard 后，Release 包會(huì)自動(dòng)刪除上面的代碼，徹底根絕 Log 引發(fā)的安全問題。關(guān)于這一部分的細(xì)節(jié)操作，可以參考這兩篇文章：

• Android Apk 文件反編譯和重新打包的過程分析
• 如何安全地打印日志

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論