1. 程式人生 > >AS3.+自定義lint

AS3.+自定義lint

概述

lint是程式碼風格和語法規則的檢查工具,不限於android平臺,其他例如jslint,eslint… 在最新的穩定版本中,官方提供了342個定義好的lint規則,基本滿足開發中的需要,基本介紹和使用方法參照官方教程

此外我們還需要某些特殊的場景下的檢查,例如 序列化的內部類也需要序列化,如果沒有序列化,我們要給出相應的提示 image 網上的demo大部分是3.0之前基於lamlok,使用aar依賴的,已經不適用於AS3.0 自己基於AS3.2, lint-checks版本26.2.0定義了一些lint, demo請參考https://github.com/ukyo6/cuslint

下面介紹自定義lint的基本配置

Lint parser

Lint從第一個版本就選擇了lombok-ast作為自己的AST Parser,並且用了很久。但是Java語言本身在不斷更新,Android也在不斷迭代出新,lombok-ast慢慢跟不上發展,所以Lint在25.2.0版增加了IntelliJ的PSI(Program Structure Interface)作為新的AST Parser。但是PSI於IntelliJ、於Lint也只是個過渡性方案,事實上IntelliJ早已開始了新一代AST Parser,UAST(Unified AST)的開發,而Lint也將於即將釋出的25.4.0版中將PSI更新為UAST。

更多的介紹請參考這篇部落格

LintParser具體介紹, 簡單的說從lambok->PSI->UAST,官方一直在優化lint的執行效率和擴充套件性,本文使用的是Lint26.2.0版本

配置

1. 建立java-library

在專案中新建java library, 新增最新穩定版lint依賴26.2.0

dependencies {
    compileOnly 'com.android.tools.lint:lint-api:26.2.0'
    compileOnly 'com.android.tools.lint:lint-checks:26.2.0'
}

2. 實現自定義的detector

detector是lint的核心, 每個規則都先繼承抽象類 Detector,然後實現Detector.Scanner介面,詳細的步驟會在接下來說明

3. 建立自定義的IssueRegistry, 在app中使用該Registry

繼承IssueRegistry,新增自定義的detector

```
public class IssuesRegister extends IssueRegistry {
    @NotNull
    @Override
    public List<Issue> getIssues() {
        return new ArrayList<Issue>() {{
            //新增自定義的Detector
            add(SelfLogDetector.ISSUE);  
            add(NewThreadDetector.ISSUE);
            add(MessageObtainDetector.ISSUE);
            add(ViewIdCorrectnessDetector.ISSUE);
            add(LayoutNameDetector.ACTIVITY_LAYOUT_NAME_ISSUE);
            add(LayoutNameDetector.FRAGMENT_LAYOUT_NAME_ISSUE);
        }};
    }
}
```

在java moudle的build.gradle中宣告自定義的IssueRegistry

```
jar {
    manifest {
        attributes("Lint-Registry-v2": "com.lintrules.IssuesRegister")
    }
}
```

app中引入自定義的lint

  • Gradle Plugin3.0之前,用的是包裝aar的方式引入自定義的lint, 參照 linkedIn方案

  • 3.0後增加 lintChecks, 無需再使用包裝aar的方式

    New lintChecks dependency configuration allows you to build a JAR that defines custom lint rules, and package it into your AAR and APK projects. Your custom lint rules must belong to a separate project that outputs a single JAR and includes only compileOnly dependencies. Other app and library modules can then depend on your lint project using the lintChecks configuration:

    我們可以直接在專案的build.gradle裡新增

    dependencies {
        lintChecks project(':lintrules') //這裡新增java library
    }
    

實現Detector

detector是lint的核心,主要分為下面幾步

  1. 每個規則都先繼承抽象類Detector,然後實現Detector.Scanner介面
  2. 定義ISSUE的內容,嚴重級別,提示資訊,提示位置
  3. 實現getApplicableXX和visitXX方法; 在getApplicableXX中定義檢查的域,visitXX中定義檢查的規則
  4. 呼叫JavaContext.reportIssue()提示異常

1.實現Scanner介面

Scanner包括以下幾種

  • SourceCodeScanner 掃描 Java 或符合JVM規範的原始碼檔案(如 kotlin)
  • ClassScanner 掃描編譯後的 class 檔案
  • BinaryResourceScanner 掃描二進位制資原始檔(如.png)
  • ResourceFloderScanner 掃描資源目錄
  • XmlScanner 掃描 xml 檔案
  • GradleScanner 掃描 Gradle 檔案
  • OtherFileScanner 掃描其他檔案

每個Scanner都實現了很多getApplicableXX和visitXX方法,這些方法都是成對使用的

2.定義ISSUE

ISSUE在每個Detector中定義,lint檢查到相關項將ISSUE報告出來,示例:

public static final Issue ISSUE = Issue.create(
    "InnerClassSerializable", //問題 Id
    "內部類需要實現Serializable介面", //問題的簡單描述
    "內部類需要實現Serializable介面",//問題的詳細描述
    Category.SECURITY, //問題型別  
    5, // 0-10嚴重級別
    Severity.ERROR, //問題嚴重程度
    new Implementation(SerializableDetector.class,
    Scope.JAVA_FILE_SCOPE); //Detector 和 Scope 的對應關係

3.實現getApplicableXX和visitXX方法方法

  • 例如實現SourceCodeScanner介面,我們applicableSuperClasses()中指定需要檢查的父類名列表,visitClass()當檢測到你指定的父類名列表時,就會進入該方法, 根據引數JavaContext, Uclass可以很方便的獲取Class的繼承關係,名字等資訊
    @Nullable
    @Override
    public List<String> applicableSuperClasses() {
        //指定檢查"java.io.Serializable"
        return Collections.singletonList(CLASS_SERIALIZABLE);
    }

    /**
     * 掃描到applicableSuperClasses()指定的list時,回撥該方法
     */
    @Override
    public void visitClass(JavaContext context, UClass declaration) {
        //只從最外部開始向內部類遞迴檢查
        if (declaration instanceof UAnonymousClass) {
            return;
        }
        sortClass(context, declaration);
    }
  • 再比如XmlScanner, 可以利用getApplicableElements()和visitElement()方法來進行xml中節點的掃描
@Override
    public Collection<String> getApplicableElements() {
        return Arrays.asList( //指定檢查這幾個控制元件的命名規範,可自行擴充套件
                TEXT_VIEW,
                IMAGE_VIEW,
                BUTTON,
                EDIT_TEXT,
                CHECK_BOX
        );
    }
    
    /**
     * 掃描到getApplicableElements()指定的xml節點時,回撥該方法
     */
    @Override
    public void visitElement(XmlContext context, Element element) {
        //這個detector只掃描android:id屬性,其他屬性跳過
        if (!element.hasAttributeNS(ANDROID_URI, ATTR_ID)) return;

        Attr attr = element.getAttributeNodeNS(ANDROID_URI, ATTR_ID);
        String value = attr.getValue();
        if (value.startsWith(NEW_ID_PREFIX)) {
        ....
        }
    }

4.報告ISSUE

在需要報告ISSUE的地方呼叫context.report()

context.report(ISSUE, //定義好的ISSUE
            uClass.getNameIdentifier(), //ISSUE對應的AST節點
            context.getLocation(uClass.getNameIdentifier()), //ISSUE提示的位置
            String.format("內部類 `%1$s` 需要實現Serializable介面", uClass.getName())); //ISSUE的描述

使用

除了在程式碼中的靜態waring,error提示,還可以輸出報告來檢視 輸入 gradlew 工程名:lintDebug 可以在build/reports目錄下檢視lint報告,demo中檢測到的問題

image 也可以檢視詳細的資訊

image

lint除錯

開發完自定義lint規則後,可能需要對程式碼進行驗證,除錯方式如下

  • 在自定義的lint程式碼中打好斷點
  • 選擇 Run -> Eidt Configurations, 在Android Studio的執行引數(Run Configurations)中新增一個Remote型別,都取預設值即可(埠號5005) image
  • 在Teminal視窗中輸入gradlew lintDebug -Dorg.gradle.daemon=false -Dorg.gradle.debug=true image
  • 選擇剛才配置的remote引數,點選debug的console看到以下輸出: Connected to the target VM, address: ‘localhost:5005’, transport: ‘socket’ 就可以進行除錯了

Lint構建優化

隨著官方lint-checks的更新,detector的數量越來越多,構建一次linttask的速度肯定是很慢的(即使每個detector指定了scope,都需要掃描專案內所有該scope的檔案…) lint的開發者也在google論壇上給出了lint構建的建議 Lint Performance Tips,大概是以下幾點:

  1. 使用graldew lintDebug, gradlew lintRelease代替gradlew lint, 因為後者會執行lint lintDebug lintRelease,造成成倍的開銷
  2. 使用gradlew 模組名:lintDebug可以檢查指定的模組
  3. lintOptions配置checkTestSources和ignoreTestSources
  4. 不要使用checkAllWarnings,因為有一些lint檢查,特別是id為“WrongThreadInterprocedural”的,非常慢

參考資料