Android 項目代碼質量保證實踐

針對 EmpytActivity 這里需要定義的文件有：
< >globals.xml.ftl：定義當前模板的一些全局變量recipe.xml.ftl：定義模板拷貝的邏輯等template.xml：定義模板對話框的樣式template_blank_activity.png：定義模板的圖標root/src/app_package/SimpleActivity.java.ftl：具體的模板文件

圖片來自：http://www.slideshare.net/murphonic/custom-android-code-templates-15537501

• 自定義模板
  而針對我們需要自定義的模板，可以在模板定義路徑下新建文件夾和文件即可，細節內容可查看 Tutorial How To Create Custom Android Code Templates
  項目的模板文件內容：
  
   

  

  image17
  設置完模板文件之后，重啟 Android Studio，可以生效模板文件，使用模板文件如下：
  
   

  

  image18

4 編碼后期 - 靜態代碼檢查

由上，我們定義了編碼規范，定義了 Live Template 和 Android Studio Template 方便程序猿更好的準守我們的項目編碼規范。然后編碼規范畢竟只是軟規范，而提供編碼模板更多的解決大量 util 的使用問題和便利小伙伴完成機械編碼，并不能完全保證程序猿嚴格按照全部的規范來編碼。
為此，我們需要一套靜態代碼檢查機制能檢查已有的代碼是否遵守規范?？偨Y已有的規范，可以將規范類型歸納為普通 Java 規范、普通 Android 規范、具體項目規范等。而這些檢查點，可以配合不同的檢查工具進行檢查。

4.1 檢查 java 代碼風格 - CheckStyle

對于 java 規范，checkstyle 幫助開發者實現常用的檢查。這里 CheckStyle 能檢查的內容有：

1. Javadoc 注釋
2. 命名約定
3. 標題
4. Import 語句
5. 體積大小
6. 空白
7. 修飾符
8. 塊
9. 代碼問題
10. 類設計
11. 混合檢查（包活一些有用的比如非必須的System.out和printstackTrace）

檢查內容很多，而檢查項需要和具體的項目規范做結合。如，每行代碼字符數控制在 80，單頁代碼行數控制在 800 等。因此需要結合配置文件，來檢查項目中的 java 代碼。在 Android Studio 上配置 CheckStyle 流程如下：

1. 在 Android Studio 中添加 gradle Plugin
   

   apply plugin: 'checkstyle' 

2. 設置 CheckStyle 版本
   

   checkstyle { toolVersion '6.1.1' showViolations true } 

3. 配置 CheckStyle 檢查項
   

   task checkstyle(type: Checkstyle) { configFile file("$configDir/checkstyle/checkstyle.xml") configProperties.checkstyleSuppressionsPath = file("$configDir/checkstyle/suppressions.xml").absolutePath source 'src' include '**/*.java' // 檢查 java 代碼 exclude '**/gen/**' // 排除生成的代碼 classpath = files() ignoreFailures true // 忽略檢查失敗的情況，避免gradle命令執行中止 } 

4. 配置自定義的檢查項：
   checkstyle.xml：
   

   <!--單個文件方法數上限最多為 30--> <module name="MethodCount"> <property name="maxTotal" value="30"/> </module> <!--方法名的首字母是小寫--> <module name="MethodName"> <property name="format" value="^[a-z][a-zA-Z0-9]*$"/> </module> <!--靜態變量名的首字符是 s--> <module name="StaticVariableName"> <property name="format" value="^[a-z][a-zA-Z0-9]*$"/> <property name="applyToPublic" value="true"/> <property name="applyToProtected" value="true"/> <property name="applyToPackage" value="true"/> <property name="applyToPrivate" value="true"/> </module> <!--只有私有構造函數的類需要定義成 final 類型--> <module name="FinalClass"/> ... 

   具體其他的檢查項配置可以查看 檢查配置鏈接
5. 執行 checkstyle 檢查
   

   ./gradlew checkstyle 

6. 查看檢查結果
   命令執行結束，查看檢查結果文件：${project}/app/build/reports/checkstyle/checkstyle.html
   
    

   

   image

4.2 檢查 java 代碼質量 - FindBugs

與 CheckStyle 工具不同的是，FindBugs 不注重樣式或者格式，而是試圖尋找出真正的缺陷或者現在的性能問題。FindBugs 檢查類和 Jar 文件，不是通過分析類文件的形式或結構來分析程序，而是使用 Visitor 模式，將字節碼與一組缺陷模式進行對比以發現可能的問題。而這些問題比如如下：

1. 忽略返回值
   
    

   

   image
   上述代碼執行結束之后，并沒有什么意義，變量 a 的值也不會變成 dddbbbccc。因此，上述代碼很可能是程序猿的 bug。為此 FindBugs 能找出這種問題
2. 空指針示例
   
    

   

   image
   上述最后一行代碼，很明顯在執行的時候會發生空指針異常，這里因為 FindBugs 無法知道變量 strMaps 是否確實有 aaa 這個 key，為此這里會檢查出錯誤。
3. 未初始化的成員變量使用
   
    

   

   image
   這里由于類成員變量 actions 并未初始化，因此當 actions.add("TEST") 被執行的時候會發生異常。

Android Studio 上 FindBugs 的集成如下：

1. 在 gradle 中引入插件
   

   apply plugin: 'findbugs' 

2. 在 gradle 中配置 findbugs task
   

   task findbugs(type: FindBugs, dependsOn: "assembleDebug") { ignoreFailures = false effort = "max" reportLevel = "high" excludeFilter = new File("$configDir/findbugs/findbugs-filter.xml") classes = files("${project.rootDir}/app/build/intermediates/classes") source 'src' include '**/*.java' exclude '**/gen/**' reports { xml.enabled = false html.enabled = true xml { destination "$reportsDir/findbugs/findbugs.xml" } html { destination "$reportsDir/findbugs/findbugs.html" } } classpath = files() ignoreFailures true // 避免檢查失敗 gradle 執行中止 } 

3. 執行 findbugs 檢查
   

   ./gradlew findbugs 

4. 查看檢查結果
   查看檢查結果文件：${project}/app/build/reports/findbugs/findbugs.html
   
    

   

   image

4.3 檢查 Android 代碼質量 - Lint

4.3.1 基本介紹

前面 FindBugs 的檢查實例(忽略返回值, 未初始化的成員變量使用)，可以發現在 Android Studio IDE 上，已經出現了標黃提示，我們把光標放上去，就能看到具體的提示了：
按 cmd + F1 可以看到具體的錯誤提示：
這就原生 Lint 給我們提供的錯誤提示功能。除了和 FindBugs 重復的純 java 代碼檢查之外，Lint 能檢查很多其他工具無法檢查的內容，也更貼合 Android：

在 Activity 內定義非靜態內部類 Handler 的報警

在 AndroidManifest.xml 中定義 export 為 true 的廣播接受器，但沒有定義權限，Lint 檢查認為是不安全的

build.gradle 文件中引用的 support 包的版本低的提示

Android Lint 是一個靜態代碼檢查工具，能夠對潛在的 bug，可能的安全性、性能、可用性、可訪問性、國際化等優化內容做出監測：

來自官方文檔 Improve Your Code with Lint

1. App Source Files：工程中的源文件，包括 java 代碼、資源 xml 代碼、gradle 文件，圖片資源文件以及 progroud 等文件
2. lint.xml：配置文件，配置哪些 lint 檢查可以排除，自定義問題的嚴重級別
3. lint Tool：靜態代碼檢查工具，可以是命令行或者集成在 Android Studio 上
4. lint Output：代碼檢查結果，可以直接顯示在 Console 上，也可以是 lint-result.html

4.3.2 原生 Lint 檢查

在 Android SDK Tools 16 及更高的版本中，Lint 工具會自動安裝。原生 Lint 的檢查項已經有 200 多項 (包括前面示例的 5 項內容)，因此使用原生的功能點，就能檢查開發中的大部分通用問題。

1. Android Studio IDE 上配置 Lint 檢查偏好設置
   (Mac 下) Preferences → Editor → Inspections 進入 Android Studio 的 Lint 配置界面
   
    

   

   image
   • A：配置 Profile，方便不同項目或者不同情況下使用不同的 Profile 進行檢查
   • B：Lint 檢查點 Group
   • C：Lint 檢查點具體描述
   • D：Lint 檢查點警告級別設置
   • E：Lint 檢查點開關
2. lint.xml 上配置 Lint
   除了可以通過 IDE 配置 Lint，還可以通過直接 lint.xml 為單個項目配置檢查規則
   

   <?xml version="1.0" encoding="UTF-8"?> <lint> <!-- Disable the given check in this project --> <issue id="IconMissingDensityFolder" severity="ignore" /> <!-- Ignore the ObsoleteLayoutParam issue in the specified files --> <issue id="ObsoleteLayoutParam"> <ignore path="res/layout/activation.xml" /> <ignore path="res/layout-xlarge/activation.xml" /> </issue> <!-- Ignore the UselessLeaf issue in the specified file --> <issue id="UselessLeaf"> <ignore path="res/layout/main.xml" /> </issue> <!-- Change the severity of hardcoded strings to "error" --> <issue id="HardcodedText" severity="error" /> </lint> 

   來源 Android Develop 文檔 Improve Your Code with Lint

3. gradle 中配置 Lint task
   

   android { lintOptions { abortOnError false // 配置 lint 過程中出錯，不中止 gradle 任務 xmlReport false htmlReport true lintConfig file("$configDir/lint/lint.xml") // 配置 lint 檢查規則 htmlOutput file("$reportsDir/lint/lint-result.html") // 配置 lint 輸出文件 xmlOutput file("$reportsDir/lint/lint-result.xml") // 配置 lint 輸出文件 } } 

4. 執行檢查
   在工程根目錄執行以下命令 (Mac)，以執行檢查任務
   

   ./gradlew lint 

5. 檢查結果
   生成的檢查結果在 ${項目工程}/app/build/reports/lint/lint-result.html
   
    

   

   image

4.3.3 自定義 Lint 檢查

雖然原生的 Lint 檢查已經很強大了，檢查項也已經很多，然而還是無法滿足項目中的特有需求：

1. log 統一使用 LogUtil
2. 對應 Activity 的 layout 命名為 activity_XXX
3. 對應 Fragment 的 layout 命名為 fragment_XXX
4. Activity 必須派生自 BaseBlankActivity 或 BaseActionBarActivity

對于以上這些需求，原生 Lint 檢查（包括 CheckStyle，FindBugs）就已經無能為力了，我們必須編碼支持自定義檢查。以項目中集成的 Lint 檢查為例，講述流程：

4.3.3.1 配置 Gradle，引入 lint 庫

dependencies { ... compile 'com.android.tools.lint:lint-api:24.5.0' compile 'com.android.tools.lint:lint-checks:24.5.0' } 

• lint-api: 官方給出的API，API并不是最終版，官方提醒隨時有可能會更改API接口。
• lint-checks：已有的檢查。

4.3.3.2 定義 IssueRegistry 類

新建一個 MyIssueRegistry 類，繼承自 IssueRegistry。用來注冊我們自定義的全部 issue

public class MyIssueRegistry extends IssueRegistry { @Override public List<Issue> getIssues() { System.out.println("********YXLint rules works!!!********"); return Arrays.asList( LogUsageDetector.ISSUE, ToastUsageDetector.ISSUE, ActivitySuperClassDetector.ACTIVITY_SUPER_CLASS_ISSUE, ... BuildGradleVersionDetector.ISSUE); } } 

其中：

• LogUsageDetector.ISSUE：用于檢查不允許直接使用 Log.* 方式輸出本地日志的代碼
• ToastUsageDetector.ISSUE：用于檢查直接用 Toast 方式顯示 toast 的代碼
• ActivitySuperClassDetector.ACTIVITY_SUPER_CLASS_ISSUE：用于檢查 Activity 的基類
• BuildGradleVersionDetector.ISSUE：用于檢查 gradle 文件中不允許直接寫數字版本號的代碼

4.3.3.3 gradle 清單項中注冊前面定義的 IssueRegistry 類

jar { manifest { attributes('Lint-Registry': 'com.netease.htlint.lintrules.MyIssueRegistry') } } 

4.3.3.4 定義 Detector

MyIssueRegistry 類中聲明注冊了各個 Detector 的 Issue。Issue 由 Detector 發現并報告，是 Android 程序代碼可能存在的風險。而這里就需要真正實現這些 Detector，以檢查 Activity 的基類為例。
ACTIVITY_SUPER_CLASS_ISSUE 這個 Issue 的定義需要使用 Issue.create(...) 方式實現，同時需要傳入 6 個參數分別如下：

• A：一個固定的唯一的 id 代表這個 Issue
• B：對于問題的簡短總結，描述問題而不是修復措施
• C：完整的問題解釋和修復建議
• D：問題類別，現在已有的問題類別有如下
  • Lint
  • Correctness (incl. Messages)
  • Security
  • Performance
  • Usability (incl. Icons, Typography)
  • Accessibility
  • Internationalization
  • Bi-directional text
• E：優先級，必須在1到10之間，10為最重要/最嚴重。
• F：嚴重級別，可選值有 Fatal, Error, Warning, Informational, Ignore
• G：為 Issue 和 Detector 提供映射關系，Detector 就是當前類。聲明掃描檢測的范圍 Scope，描述 Detector 需要分析時需要考慮的文件集，包括：Resource 文件或目錄、Java 文件、Class 文件

ActivitySuperClassDetector 繼承自 Detector，并實現 Detector.JavaScaner。這里主要自定義實現的方法如上圖 H，I

• H：檢查類的基類是 "android.support.v4.app.Activity" 或 "android.app.Activity"
• I：具體檢查類的方法，這里需要排除非 yanxuan 包名下的代碼，判斷當前類的基類是否是 BaseBlankActivity 或 BaseActionBarActivity？如果都不是的話，則報告錯誤
• J：報出問題的方法：該方法中指定參數有：
  • 需要報錯的 Issue
  • 發生問題的代碼在語法樹上的節點
  • 發生問題的代碼位置
  • 警告的信息

4.3.3.5 生成 jar 包

完成上述步驟，可以在控制臺中通過命令 ../../gradlew assemble 來執行編譯任務，就可以輸出我們需要的 jar 文件 (htlintrules_jar-0.0.1.jar) 了

4.3.3.6 jar 的使用

按照 Google 方法，可以將 htlintrules_jar-0.0.1.jar 拷貝到 ~/.android/lint 中，但缺點是針對會影響一臺機器其他的工程。很明顯，我們的自定義 Lint 檢查有很多是項目中特有的一些編碼規范。
為此，我們采用 LinkedIn 方案：將 jar 放到一個 aar 中。這樣我們就可以針對工程進行自定義 Lint，lint.jar 只對當前工程有效。
在現有的 htlintrules_jar 工程的 build.gradle 中添加代碼，整體看起來如下：

apply plugin: 'java' apply plugin: 'maven' dependencies { compile 'com.android.tools.lint:lint-api:24.5.0' compile 'com.android.tools.lint:lint-checks:24.5.0' } jar { manifest { attributes('Lint-Registry': 'com.netease.htlint.lintrules.MyIssueRegistry') } } configurations { lintJarOutput } dependencies { lintJarOutput files(jar) } defaultTasks 'assemble' 

同時新建另一個工程 htlint，在其 build.gradle 文件中添加如下代碼：

/* * rules for including "lint.jar" in aar */ configurations { lintJarImport } dependencies { lintJarImport project(path: ':htlintrules_jar', configuration: "lintJarOutput") } task copyLintJar(type: Copy) { from (configurations.lintJarImport) { rename { String fileName -> 'lint.jar' } } into 'build/intermediates/lint/' } project.afterEvaluate { def compileLintTask = project.tasks.find { it.name == 'compileLint' } compileLintTask.dependsOn(copyLintJar) } 

最后在 app 工程的 build.gradle 中添加 htlint 引用，配置完成

dependencies { compile project(':htlint') // lint 檢查庫 ... } 

4.3.3.7 自定義 Lint 檢查執行及結果檢查

在 ${項目工程}/app/ 目錄下執行 ../gradlew lint：
根據提示查看 lint-result.html 文件，可以查看到前面編寫的 ActivitySuperClassDetector.ACTIVITY_SUPER_CLASS_ISSUE 已經生效，并且檢查出了相關的非規范代碼。

4.3.3.8 排除錯誤的檢查結果

前面很好的給出了檢查結果了，然而我們會發現，FullScreenVideoActivity 確實是需要的錯誤檢查結果，而 WXEntryActivity 卻不是，這個類是有集成微信分享時需要的，并且按照微信開放平臺的文檔來編寫，因此并不需要按照項目規范，繼承 BaseBlankActivity 或 BaseActionBarActivity。為此，我們期望 WXEntryActivity 不應該被檢查出 WrongActivitySuperClass 錯誤
為此，我們可以在 WXEntryActivity 類名簽名添加 SuppressLint 注解：

@SuppressLint("WrongActivitySuperClass") public class WXEntryActivity extends Activity implements IWXAPIEventHandler{ ... } 

1. 排除 java 類或者方法的 Lint 檢查
   若需要抑制某個 Issue 檢查，可以在類定義簽名或者方法定義簽名，添加注解 @SuppressLint(${IssueId})。這里設置的就是具體某個 Issue 的 id 值
   若需要抑制全部的 Issue 檢查，可以使用 all 關鍵字，比如：@SuppressLint("all")
2. 排除 xml 資源的 Lint 檢查
   如項目中引入微博分享 sdk，按照官方文檔，需要在 AndroidManifest 中聲明 com.sina.weibo.sdk.net.DownloadService 這個 Service，而這個 Service 會被 Lint 檢查為未定義，為此需要 xml 文件中也過濾部分代碼的 Lint 的檢查：
   

   <manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" package="com.netease.yanxuan"> ... <service android:name="com.sina.weibo.sdk.net.DownloadService" android:exported="false" tools:ignore="MissingRegistered" /> </manifest> 

   這里對于單個 Issue 過濾的規則為：tools:ignore=${IssueId}
   如果需要過濾全部的 Issue，可以使用 all 關鍵字：tools:ignore="all"

4.4 其他代碼檢查工具

4.4.1 360 火線

360 火線 是 360 公司和信息安全部門深度合作，定制的適用于 360 公司產品的安卓 APP 安全檢查規則?？偣哺采w 61 項代碼檢查。使用也非常方便，細節看 使用文檔，可以直接使用 jar 包并執行命令或集成 Android Studio Plugin 執行檢查

4.4.2 pmd

pmd 代碼檢查工具，包含 16 個規則集，涵蓋了 Java 的各種常見問題。其中規則集包含 基本（rulesets/basic.xml），終結函數（finalizer），未使用的代碼（rulesets/unusedcode.xml），設計（rulesets/design.xml） 等。
相比 FindBugs，pmd 的一些規則更具爭議，但 pmd 支持我們構建自己的規則集

<?xml version="1.0"?> <ruleset name="customruleset"> <description> Sample ruleset for developerWorks article </description> <rule ref="rulesets/design.xml"/> <rule ref="rulesets/naming.xml"/> <rule ref="rulesets/basic.xml"/> </ruleset> 

4.5 代碼檢查工具整合及集成 jenkins

為整合這些檢查工具，在 gradle 中自定義 check 命名，并依賴其他的 task。在執行檢查的時候，可以通過 ./gradlew check 來執行全部的檢查命令。

check.dependsOn 'checkstyle', 'findbugs', 'pmd', 'lint' 

另一方面，這種代碼檢查，如果等到開發完成的時候再去執行，很可能問題積累了很多，甚至導致產品上線前，開發并不能來得及修正全部的問題。為此，可以將代碼檢查的命令集成 jenkins，保證開發每天都能看到當前的代碼的缺陷，能及時的修改

5 總結

我們從編碼前的編碼規范，編碼進行中的編碼模板，編碼結束后的代碼靜態檢查，保障了程序小伙伴們的代碼。除此之外，還有很多不完善的地方需要我們做進一步處理：

1. 和特定項目相關的自定義 Lint 檢查項，僅支持了一部分的編碼規范，自定義 Lint 檢查項需要后續完成
2. 雖然檢查工具很多，檢查的結果內容也很多，而很明顯，這些檢查工具相互之間是有重復的情況（主要是純 java 代碼部分的檢查），因此如果整理檢查結果，并過濾出我們真正關心的問題，也是后續需要完成的內容

原文轉自：https://www.jianshu.com/p/6a38e9dcc0d9