一，IntelliJ 代碼檢查

IntelliJ IDEA的具有強大，快速，靈活的靜態代碼分析。它可以檢測編譯器和運行時錯誤，提出改進和完善，甚至在編譯之前。

代碼檢查基礎（Code analysis basics）

IntelliJ IDEA的具有強大，快速，靈活的靜態代碼分析。它可以檢測編譯器和運行時錯誤，提出改進和完善，你甚至編譯之前。

只要你有一些無效引用的代碼，未使用的代碼，非本地化的字符串，未完成的方法，內存洩漏，甚至拼寫問題 - 你都會很快找到它。

IntelliJ IDEA的代碼分析是靈活配置。您可以啟用/禁用每個代碼審查，並改變其嚴重程度, 創建自定義審查的配置文件，在不同的范圍適用於不同的審查，指定不審查的代碼塊等等.

可以以幾種方式進行的分析：

默認情況下，IntelliJ IDEA的分析所有打開的文件，並強調就在編輯器中檢測到的所有代碼問題。在編輯器的右側，可以看到整個文件（在右上角的圖標）的分析狀??態：
當檢測到錯誤時;在警告的情況下 ; 如果一切是正確的 vcnP0ru49qGjPC9wPg0KPGgyIGlkPQ=="inspection-severity嚴重程度">Inspection severity（嚴重程度）

審查嚴重性指示如何認真對待檢測有問題的代碼，並確定如何將檢測的問題在編輯器中突出顯示。默認情況下，每次檢查有以下嚴重性級別之一：

服務器問題
Typo
Info
Weak Warning
Warning
Error
還可以增加或減少每次檢查的嚴重性級別。也就是說，你可以強制IntelliJ IDEA的顯示一些警告視為錯誤或弱警告。以類似的方式，將最初考慮弱警告可以顯示為警告或錯誤，或者僅僅作為信息

您還可以配置用於顯示的每個級別的顏色和字體樣式。此外，你可以創建自定義的嚴重級別，並設置他們為專項檢查。.

如果有必要，可以設置在不同的范圍相同的檢查不同的嚴重程度。

所有修改上述檢查保存在目前在檢查設置中選擇的檢查信息和當使用該信息適用。

欲了解更多信息和程序的說明，請向下更多閱讀。

Inspection scope（范圍）

默認情況下，所有啟用的代碼檢查適用於所有項目文件。如果有必要，可以單獨為不同的范圍配置每個代碼檢查（啟用/禁用，改變它的嚴重程度和期權）。這樣的配置，像任何其他檢查設置，作為特定配置文件的一部分被保存並應用。
有可能是復雜的情況下，當檢查有不同的范圍相關聯的不同配置。當這樣的檢查在屬於部分或全部范圍的文件執行時，優先級最高的具體范圍配置的設置被應用。優先級由檢查的特定范圍的配置的檢驗設置的相對位置來定義：最上面的配置具有最高優先級。
了解更多信息和程序的說明，請參閱為不同的范圍配置檢測。

code inspections示例

通過代碼分析所涉及的最常見的任務是：

尋找可能的bugs.
檢測性能問題。
查找死代碼。
改進代碼結構和可維護性。
符合編碼規則和標准。
符合規格。
尋找可能的bugs
IntelliJ IDEA的分析您所鍵入的代碼，並能夠發現可能的即時非編譯錯誤。下面是這種情況的例子。

Example. 可以在運行時被拋出潛在NPE
Before

此處第一 if條件有可能導致一個空指針異常，在第二個 if處拋出，因為不是所有的情況下都包括在內。在這一點上，以避免一個空指針在運行時期間被拋出增加一個斷言將是一個好主意。

After

這樣，正是我們從意向行動得到的。

查找死代碼
IntelliJ IDEA的突出了所謂的死代碼編輯器件。這是應用程序運行期間從不執行的代碼。也許，在你的項目甚至不需要這部分代碼。視情況，這樣的代碼可被視為一個錯誤或作為冗余。反正它降低了應用性能和維護過程復雜化。下面是一個例子。

例如，所謂恆定的條件（ constant conditions） - 條件是從來沒有見過或總是真實的。在這種情況下，相關代碼不可達並且實際上是一個死代碼。

IntelliJ IDEA的突出if條件，因為它是總是true。所以代碼別的包圍的部分實際上是一個死代碼，因為從不執行它。

高亮顯示未使用的聲明（Unused declarations）

IntelliJ IDEA的也能即時突出顯示整個項目Unused declarations Java類，方法和通過未使用的聲明字段.
For more examples of code inspections use, refer tohttp://www.jetbrains.com/idea/documentation/static_code_analysis.html

訪問檢查設置（Accessing Inspection Settings）

檢查和檢查配置文件是在檢查設置頁面進行編輯。 IntelliJ IDEA的提供了多種方式來訪問檢查設置。

要訪問檢查和配置文件的設置，請執行下列操作之一

Open the Settings / Preferences Dialog by choosing File | Settings for Windows and Linux or IntelliJ IDEA | Preferences for OS X, and click Inspections underEditor.
在主工具欄，點擊 img, ，然後展開編輯器節點，然後單擊檢查。
點擊狀態欄上的當前配置文件的圖標

然後單擊配置檢查Configure inspection 鏈接 。

在編輯器中，打開建議列表中，單擊右箭頭，然後選擇在子菜單編輯檢查配置文件設置。

在檢查工具窗口中，單擊工具欄上的編輯設置 settings 或使用相應的快捷菜單命令。

Customizing Profiles（自定義配置）

通過Manage下拉列表選項可以復制，重命名，添加描述，導出，導入配置文件。

對於不同的作用域配置檢查（Configuring Inspection for Different Scopes）

定義范圍的順序

要定義范圍的順序，請按照下列步驟

在設置/首選項對話框的檢查頁面，點擊按鈕 In All Scopes:

從范圍下拉列表選擇. Edit Scopes Order…
在打開的作用域訂單對話框，選擇所需的范圍，然後單擊向上和向下箭頭

配置檢查嚴重程度

更改檢查嚴重程度

在檢查的設置，選擇所需的 profile. 與配置文件相關聯的檢查顯示在下拉列表中。
選擇所需的檢查。如果這個檢查是禁用的，選擇旁邊的復選框。
從檢查的，或從右邊的嚴重性選擇上下文菜單中選擇所需的嚴重性：

需要注意的是檢查，其狀態相對於默認值改變，所有的分組節點用藍色突出顯示。
Apply更改。修改後的檢查現在將有新的嚴重性級別時使用此配置文件。
為不同范圍的檢查更改嚴重程度

選擇所需的個人資料和檢查。
點擊下拉列表 In All Scopes, 並選擇要更改檢查嚴重程度范圍：

IntelliJ IDEA的顯示了兩個范圍嚴重性：選擇了的一個和在其他地方
點擊嚴重性下拉列表中選擇范圍，然後從下拉列表中選擇適當的嚴重性級別：

更改高亮風格為特定的嚴重性級別

請執行下列操作之一：
在設置/ Preferences對話框中，選擇 Editor | Colors & Fonts -> General, 然後選擇對應於期望級別的樣式。
在檢查的設置，選擇所需的檢查，然後從嚴重程度Severity 選擇Edit severities。
接著，在 Severities Editor 打開對話框中，選擇所需的級別，然後點擊Editor | Colors & Fonts.
無論哪種方式，你會看到與此嚴重性關聯的 Colors and Fonts。
配置的顏色和字體樣式是必要的並且apply更改。 與相應的嚴重性所檢測的問題現在將使用修改樣式編輯器時使用的當前輪廓被突出顯示。

定義自定義級別

在檢查的設置，選擇所需的檢查和從 Severity selector選擇 Edit severities . .
在打開的Severities Editor 對話框， 點擊 add.png:

在New Highlight Severity 對話框中輸入新的嚴重性鍵入名稱。

定制嚴重性加到嚴重性的列表。
使用控件嚴重性列表右側的新的嚴重性指定顏色和字體設置。
使用 Up arrowUp.png 和 Down arrowDown.png 改變新的嚴重性的優先級。
Apply變化. 新的級別現在可為當前配置文件中的所有檢查。您可以將其分配給特定的檢查，並得到相應的代碼問題凸顯，在編輯器中指定的樣式。
如果有必要，你可以通過在Severities Editor，然後點擊 delete.png.選擇稍後刪除自定義級別。

您不能更改預定義的嚴重性級別的優先級，或將其刪除。

二，代碼優化工具：Lint

除了通過滿足其功能要求測試代碼，它還有個重要的作用是確保代碼沒有結構方面的問題。結構不佳的代碼可以影響Andr??oid應用程序的可靠性和效率，使代碼更難維護。例如，如果XML資源文件包含未使用的命名空間，會占用空間，並會導致不必要的處理. 其他結構性問題，如使用未由目標API版本支持的或API調用棄用的元素，可能會導致代碼無法正確運行。

概述

Android Studio 提供一個代碼掃描工具， Lint，它可以幫助輕松識別並與糾正代碼的結構質量問題，而無需執行應用程序或寫任何測試用例。 該工具檢測到的每個問題會報道描述消息和嚴重程度，這樣就可以很快優先處理關鍵的改進。還可以配置問題的嚴重程度忽略不相關的項目的問題，或提高級別。該工具具有命令行端口，讓您可以輕松地將它集成到自動化測試過程。

Lint 工具檢查您的Andr??oid項目源文件的正確性，安全性，性能，可用性，可訪問性和國際化等相關潛在的bug並且優化改進 。您可以通過命令行或在Android Studio中運行lint。

Note:在Android Studio，為簡化代碼審查 附加IntelliJ代碼檢查。

Figure 1顯示了Lint工具如何處理應用程序源文件。
.

Android Studio運行lint

在 Android Studio 中，每次構建應用的時候，配置好的 lint 和 IDE 檢查會自動運行。因為 Android Studio 是 Intellij idea 社區版本上改的，所以 lint 會和 Intellij 的 IDE 檢查一起運行來精簡代碼審查。

Note: 如果想查看或者修改檢查的嚴格程度，打開設置頁面：

在 Android Studio 裡，你可以指定某個構建版本來運行 lint，也可以為所有的構建版本運行 lint 檢查，一切都在 build.grade 裡指定。你也可以在 build.grade 裡的 android 設置裡添加 lintOptions 屬性，比如：

android {
    lintOptions {
       // set to true to turn off analysis progress reporting by lint
       quiet true
       // if true, stop the gradle build if errors are found
       abortOnError false
       // if true, only report errors
       ignoreWarnings true
       }
       ...
    }

如果要手動運行檢查的話，選擇 Analyze > Inspect Code，按照彈出的對話框操作即可：

命令行運行lint

命令格式:

lint [flags] 

比如，你可以使用下面的命令，掃描 myproject 目錄以及子目錄。MissingPrefix 告訴 lint 只掃描那些沒加 Android 命名空間前綴的 XML 的屬性。

lint --check MissingPrefix myproject 

用 lint –help 查看所有的選項：

lint --help

lint輸出示例

 tag appears after  tag [ManifestOrder]
  
  ^
AndroidManifest.xml:23: Warning:  tag should specify a target API level (the highest verified version; when running on later versions, compatibility behaviors may be enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes]
  
  ^
res/layout/preferences.xml: Warning: The resource R.layout.preferences appears to be unused [UnusedResources]
res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 4 warnings." data-snippet-id="ext.39f4e5b263a9a709d13bd47f4302848e" data-snippet-saved="false" data-codota-status="done">$ lint Earthquake

Scanning Earthquake: ...............................................................................................................................
Scanning Earthquake (Phase 2): .......
AndroidManifest.xml:23: Warning:  tag appears after  tag [ManifestOrder]
  
  ^
AndroidManifest.xml:23: Warning:  tag should specify a target API level (the highest verified version; when running on later versions, compatibility behaviors may be enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes]
  
  ^
res/layout/preferences.xml: Warning: The resource R.layout.preferences appears to be unused [UnusedResources]
res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 4 warnings.

配置lint

lint 默認會把它支持的檢查都跑一遍。你可以自己配置哪些問題需要檢查，也可以自己指定這些問題的嚴重性。比如，你可以不檢查那些和項目無關的問題、降低那些不是很嚴重的問題的嚴重程度。

你可以配置 lint 檢查 ：

整個項目
按項目模塊
按產品模塊
按測試模塊
按打開的文件
按類的層級
從版本控制器的角度

Android Studio中配置Lint

有兩種方法可以看到Lint的warnings和errors 結果：
- 編輯器中提示文字。Lint會黃色高亮有問題的代碼，或使用紅色下劃線指示嚴重的問題：

- 手動Analyze > Inspect Code 之後，在檢查結果窗口中：

設置默認的Lint 檢查：
1. 打開項目，選擇 File > Other Settings > Default Settings，選擇 Editor > Inspections.
2. 在Profile 選項中,選擇 Default 或者 Project Default來選擇是全局作用域還是project作用域。
3. 在窗口中進行設置。

配置手動執行的Lint檢查：
1. 打開項目，選擇你要測試的目錄。使用Analyze > Inspect Code.
2. 在指定檢查范圍彈出框中，選擇檢查scope（區域）和profile（配置文件）。scope指定哪些文件你想要分析，profile指定你想要執行的Lint checks。

配置lint文件

在 Android 項目根目錄創建 lint.xml。如果你用 Android Studio 配置的，會自動放在你的 Android 項目下。lint.xml 使用如下格式：

    
        
" data-snippet-id="ext.542d2d446c97031d60cdca33268f10b4" data-snippet-saved="false" data-codota-status="done">
    
        

為根節點，然後包含了很多 子節點。每個 有一個唯一的 id 屬性。你可以通過修改 這個 tag 的 severity 屬性值，來決定是否要檢查這個問題或者改變它的嚴重程度。

Tip: 試試看 lint –list 命令，你會找到所有支持的 issue 和 他們的 ID。

.

Sample lint.xml file

    
    

    
    
        
        
    

    
    
        
    

    
    
" data-snippet-id="ext.f388c92b4b31e6c0790d13f87524b27b" data-snippet-saved="false" data-codota-status="done">

    
    

    
    
        
        
    

    
    
        
    

    
    

在Java和XML 源文件中關閉lint檢測

Java中配置

關閉lint：添加@SuppressLint 注解.

下面的例子就是告訴你，對於 onCreate 方法不需要做 NewApi 的檢查。lint 就會略過這個方法，但是這個類中的其他方法還是會做NewApi 的檢查。.

@SuppressLint("NewApi")
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

下面的例子是說，對於 FeedProvider 這個類不需要做 ParserError 的檢查：:

@SuppressLint("ParserError")
public class FeedProvider extends ContentProvider {

啥都不查:

@SuppressLint("all")

XML中配置

使用 tools:ignore 這個屬性關閉 lint 檢查。當然你必須包含下面這個命名空間:

namespace xmlns:tools="http://schemas.android.com/tools"

下面這個例子告訴你關閉 LinearLayout 這個元素的 UnusedResources 的檢查。 ignore 的屬性會被子元素繼承。所以這個例子中， 這個元素也不會去檢查 UnusedResources 的問題。

    
" data-snippet-id="ext.9c42c43c6f1c8b7be0245beb333a0377" data-snippet-saved="false" data-codota-status="done">

    

關閉多個檢查，以逗號分隔。

tools:ignore="NewApi,StringFormatInvalid"

都不檢查：

tools:ignore="all"

三，優化代碼檢查：注解

使用代碼檢查工具（例如Lint）能幫助我們找到一些問題並且可以提高我們代碼的質量，檢測工具只能做這麼多。Android的資源ID，例如，使用int引用字符串，圖形，顏色和其他資源類型，所以，當你是否指定你應該指定顏色的字符串資源檢測工具也說不清。這種情況意味著，你的應用程序可能會錯誤地呈現或無法正常運行，即使你使用代碼檢查。

這時就需要注解來提高優化代碼，它們作為附加數據添加到變量，參數和檢查方法的返回值，傳遞的參數和局部變量和范圍。

當注解與代碼檢查工具一塊使用，注解可以幫助您檢測這些問題，如空指針異常和資源類型的沖突。Android支持用於插入方法中，參數和返回值的各種注釋。
運行同Android Studio中配置Lint。

基礎

要想在代碼中添加注解，首先在項目中要添加有注解庫依賴:

如在 build.gradle文件添加有support-annotations 注解庫依賴.

dependencies {
    compile 'com.android.support:support-annotations:23.3.0'
}

Support-Annotations 定義有可以用來作為修飾的注解，所以使用這個庫的方法和資源會自動的檢查代碼潛在的問題 。

Nullness注解

添加 @Nullable 和 @NonNull 檢查變量，參數，返回值的空性

 tag. */
    @NonNull
    @Override
    public View onCreateView(String name, @NonNull Context context,
      @NonNull AttributeSet attrs) {
      ...
      }
...." data-snippet-id="ext.603e39e3037a837f1406ad615699dd3a" data-snippet-saved="false" data-codota-status="done">import android.support.annotation.NonNull;
...

    /** Add support for inflating the  tag. */
    @NonNull
    @Override
    public View onCreateView(String name, @NonNull Context context,
      @NonNull AttributeSet attrs) {
      ...
      }
....

資源注解

import android.support.annotation.StringRes;
...
    public abstract void setTitle(@StringRes int resId);
    ...

另外 @DrawableRes, @DimenRes, @ColorRes, and @InterpolatorRes 同樣用法

線程注解

調用的方法是否來自指定線程. 線程的注解有:

@UiThread
@MainThread
@WorkerThread
@BinderThread
注意：@MainThread和@UiThread注解是可以相互交換的，因此方法調用這些類型的注解是被允許的。

如果所有的方法要求使用同一個線程，你可以增加一個單例線程注解在類中所有方法來驗證相同類型的線程。

一個常見的線程注解是驗證是否在UI線程上進行異步任務類的方法重寫後台運行和發布結果。

值約束注解

使用 @IntRange, @FloatRange, and @Size 約束值的范圍.

public void setAlpha(@IntRange(from=0,to=255) int alpha) { … }
public void setAlpha(@FloatRange(from=0.0, to=1.0) float alpha) {...}

The @Size檢查 collection ， array, string的長度.例如可以使用 @Size(min=1)檢查是不是空, @Size(2) 約束有長度為2：

int[] location = new int[3];
button.getLocationOnScreen(@Size(min=1) location);

權限注解

使用 @RequiresPermission 檢查是否有某一個權限 ，使用 anyOf 檢查是否有某些權限中的一個. 使用 allOf 檢查是否有某些權限.

@RequiresPermission(Manifest.permission.SET_WALLPAPER)
public abstract void setWallpaper(Bitmap bitmap) throws IOException;
@RequiresPermission(allOf = {
    Manifest.permission.READ_EXTERNAL_STORAGE,
    Manifest.permission.WRITE_EXTERNAL_STORAGE})
public static final void copyFile(String dest, String source) {
    ...
}

檢查返回值

@CheckResults 校驗方法接口或者返回值是否真的被使用了。
下面的例子表示checkPermissions 方法確定返回值被使用了。如果沒使用，就會建議使用 enforcePermission方法來替代。

@CheckResult(suggest="#enforcePermission(String,int,int,String)")
public abstract int checkPermission(@NonNull String permission, int pid, int uid);

CallSuper注解

使用 @CallSuper 子類重寫的方法也需要調用父類方法（即此注解的方法）.

@CallSuper
protected void onCreate(Bundle savedInstanceState) {
}

枚舉注解

使用 @IntDef 和@StringDef 限制枚舉參數類型.

import android.support.annotation.IntDef;
...
public abstract class ActionBar {
    ...
    //聲明枚舉，數據接收的類型為int
    @IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS})

    //告訴編輯器不要在 .class文件中存儲注解數據
    @Retention(RetentionPolicy.SOURCE)

    //聲明NavigationMode注解
    public @interface NavigationMode {}

    //聲明常量
    public static final int NAVIGATION_MODE_STANDARD = 0;
    public static final int NAVIGATION_MODE_LIST = 1;
    public static final int NAVIGATION_MODE_TABS = 2;

    //使用這個注解聲明目標方法
    @NavigationMode
    public abstract int getNavigationMode();

    //關聯這個注解
    public abstract void setNavigationMode(@NavigationMode int mode);

當 build 這段代碼, 如果參數不是指向這些常量中的一個會警告 (NAVIGATION_MODE_STANDARD,NAVIGATION_MODE_LIST, or NAVIGATION_MODE_TABS).

也可以使用flag聲明一個注解，檢查參數或返回值是否指向一個可用的模式. 下面的例子創建DisplayOptions注解，通過一列 DISPLAY_ constants.

import android.support.annotation.IntDef;
...

@IntDef(flag=true, value={
        DISPLAY_USE_LOGO,
        DISPLAY_SHOW_HOME,
        DISPLAY_HOME_AS_UP,
        DISPLAY_SHOW_TITLE,
        DISPLAY_SHOW_CUSTOM
})
@Retention(RetentionPolicy.SOURCE)
public @interface DisplayOptions {}

...

當 build 這段代碼, 如果參數或返回值不是指向這些常量中的一個會警告