隨著項目的擴大,依靠人工codereview來保證項目的質量,越來越不現實,這時就有必要藉助於一種自動化的代碼審查工具:程式靜態分析。 程式靜態分析(Program Static Analysis)是指在不運行代碼的方式下,通過詞法分析、語法分析、控制流、數據流分析等技術對程式代碼進行掃描,驗證代碼 ...
隨著項目的擴大,依靠人工codereview來保證項目的質量,越來越不現實,這時就有必要藉助於一種自動化的代碼審查工具:程式靜態分析。
程式靜態分析(Program Static Analysis)是指在不運行代碼的方式下,通過詞法分析、語法分析、控制流、數據流分析等技術對程式代碼進行掃描,驗證代碼是否滿足規範性、安全性、可靠性、可維護性等指標的一種代碼分析技術。(來自百度百科)
詞法分析,語法分析等工作是由編譯器進行的,所以對iOS項目為了完成靜態分析,我們需要藉助於編譯器。對於OC語言的靜態分析可以完全通過Clang,對於Swift的靜態分析除了Clange還需要藉助於SourceKit。
Swift語言對應的靜態分析工具是SwiftLint,OC語言對應的靜態分析工具有Infer和OCLitn。以下會是對各個靜態分析工具的安裝和使用做一個介紹。
SwiftLint
對於Swift項目的靜態分析可以使用SwiftLint。SwiftLint 是一個用於強制檢查 Swift 代碼風格和規定的一個工具。它的實現是 Hook 了 Clang 和 SourceKit 從而能夠使用 AST 來表示源代碼文件的更多精確結果。Clange我們瞭解了,那SourceKit是乾什麼用的?
SourceKit包含在Swift項目的主倉庫,它是一套工具集,支持Swift的大多數源代碼操作特性:源代碼解析、語法突出顯示、排版、自動完成、跨語言頭生成等工作。
安裝
安裝有兩種方式,任選其一: 方式一:通過Homebrew
$ brew install swiftlint
這種是全局安裝,各個應用都可以使用。 方式二:通過CocoaPods
pod 'SwiftLint', :configurations => ['Debug']
這種方式相當於把SwiftLint作為一個三方庫集成進了項目,因為它只是調試工具,所以我們應該將其指定為僅Debug環境下生效。
集成進Xcode
我們需要在項目中的Build Phases
,添加一個Run Script Phase
。如果是通過homebrew安裝的,你的腳本應該是這樣的。
if which swiftlint >/dev/null; then
swiftlint
else
echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi
如果是通過cocoapods安裝的,你得腳本應該是這樣的:
"${PODS_ROOT}/SwiftLint/swiftlint"
運行SwiftLint
鍵入CMD + B
編譯項目,在編譯完後會運行我們剛纔加入的腳本,之後我們就能看到項目中大片的警告信息。有時候build信息並不能填入項目代碼中,我們可以在編譯的log日誌里查看。
定製
SwiftLint規則太多了,如果我們不想執行某一規則,或者想要濾掉對Pods庫的分析,我們可以對SwfitLint進行配置。
在項目根目錄新建一個.swiftlint.yml
文件,然後填入如下內容:
disabled_rules: # rule identifiers to exclude from running
- colon
- trailing_whitespace
- vertical_whitespace
- function_body_length
opt_in_rules: # some rules are only opt-in
- empty_count
# Find all the available rules by running:
# swiftlint rules
included: # paths to include during linting. `--path` is ignored if present.
- Source
excluded: # paths to ignore during linting. Takes precedence over `included`.
- Carthage
- Pods
- Source/ExcludedFolder
- Source/ExcludedFile.swift
- Source/*/ExcludedFile.swift # Exclude files with a wildcard
analyzer_rules: # Rules run by `swiftlint analyze` (experimental)
- explicit_self
# configurable rules can be customized from this configuration file
# binary rules can set their severity level
force_cast: warning # implicitly
force_try:
severity: warning # explicitly
# rules that have both warning and error levels, can set just the warning level
# implicitly
line_length: 110
# they can set both implicitly with an array
type_body_length:
- 300 # warning
- 400 # error
# or they can set both explicitly
file_length:
warning: 500
error: 1200
# naming rules can set warnings/errors for min_length and max_length
# additionally they can set excluded names
type_name:
min_length: 4 # only warning
max_length: # warning and error
warning: 40
error: 50
excluded: iPhone # excluded via string
allowed_symbols: ["_"] # these are allowed in type names
identifier_name:
min_length: # only min_length
error: 4 # only error
excluded: # excluded via string array
- id
- URL
- GlobalAPIKey
reporter: "xcode" # reporter type (xcode, json, csv, checkstyle, junit, html, emoji, sonarqube, markdown)
一條rules提示如下,其對應的rules名就是function_body_length
。
! Function Body Length Violation: Function body should span 40 lines or less excluding comments and whitespace: currently spans 43 lines (function_body_length)
disabled_rules
下填入我們不想遵循的規則。
excluded
設置我們想跳過檢查的目錄,Carthage、Pod、SubModule這些一般可以過濾掉。
其他的一些像是文件長度(file_length),類型名長度(type_name),我們可以通過設置具體的數值來調節。
另外SwiftLint也支持自定義規則,我們可以根據自己的需求,定義自己的rule
。
生成報告
如果我們想將此次分析生成一份報告,也是可以的(該命令是通過homebrew安裝的swiftlint):
# reporter type (xcode, json, csv, checkstyle, junit, html, emoji, sonarqube, markdown)
$ swiftlint lint --reporter html > swiftlint.html
xcodebuild
xcodebuild是xcode內置的編譯命令,我們可以用它來編譯打包我們的iOS項目,接下來介紹的Infer和OCLint都是基於xcodebuild的編譯產物進行分析的,所以有必要簡單介紹一下它。
一般編譯一個項目,我們需要指定項目名,configuration,scheme,sdk等信息以下是幾個簡單的命令及說明。
# 不帶pod的項目,target名為TargetName,在Debug下,指定模擬器sdk環境進行編譯
xcodebuild -target TargetName -configuration Debug -sdk iphonesimulator
# 帶pod的項目,workspace名為TargetName.xcworkspace,在Release下,scheme為TargetName,指定真機環境進行編譯。不指定模擬器環境會驗證證書
xcodebuild -workspace WorkspaceName.xcworkspace -scheme SchemeName Release
# 清楚項目的編譯產物
xcodebuild -workspace WorkspaceName.xcworkspace -scheme SchemeName Release clean
之後對xcodebuild命令的使用都需要將這些參數替換為自己項目的參數。
Infer
Infer是Facebook開發的針對C、OC、Java語言的靜態分析工具,它同時支持對iOS和Android應用的分析。對於Facebook內部的應用像是 Messenger、Instagram 和其他一些應用均是有它進行靜態分析的。它主要檢測隱含的問題,主要包括以下幾條:
- 資源泄露,記憶體泄露
- 變數和參數的非空檢測
- 迴圈引用
- 過早的nil操作
暫不支持自定義規則。
安裝及使用
$ brew install infer
運行infer
$ cd projectDir
# 跳過對Pods的分析
$ infer run --skip-analysis-in-path Pods -- xcodebuild -workspace "Project.xcworkspace" -scheme "Scheme" -configuration Debug -sdk iphonesimulator
我們會得到一個infer-out
的文件夾,裡面是各種代碼分析的文件,有txt,json等文件格式,當這樣不方便查看,我們可以將其轉成html格式:
$ infer explore --html
點擊trace,我們會看到該問題代碼的上下文。
因為Infer預設是增量編譯,只會分析變動的代碼,如果我們想整體編譯的話,需要clean一下項目:
$ xcodebuild -workspace "Project.xcworkspace" -scheme "Scheme" -configuration Debug -sdk iphonesimulator clean
再次運行Infer去編譯。
$ infer run --skip-analysis-in-path Pods -- xcodebuild -workspace "Project.xcworkspace" -scheme "Scheme" -configuration Debug -sdk iphonesimulator
Infer的大致原理
Infer的靜態分析主要分兩個階段:
1、捕獲階段
Infer 捕獲編譯命令,將文件翻譯成 Infer 內部的中間語言。
這種翻譯和編譯類似,Infer 從編譯過程獲取信息,併進行翻譯。這就是我們調用 Infer 時帶上一個編譯命令的原因了,比如: infer -- clang -c file.c
, infer -- javac File.java
。結果就是文件照常編譯,同時被 Infer 翻譯成中間語言,留作第二階段處理。特別註意的就是,如果沒有文件被編譯,那麼也沒有任何文件會被分析。
Infer 把中間文件存儲在結果文件夾中,一般來說,這個文件夾會在運行 infer
的目錄下創建,命名是 infer-out/
。
2、分析階段
在分析階段,Infer 分析 infer-out/
下的所有文件。分析時,會單獨分析每個方法和函數。
在分析一個函數的時候,如果發現錯誤,將會停止分析,但這不影響其他函數的繼續分析。
所以你在檢查問題的時候,修複輸出的錯誤之後,需要繼續運行 Infer 進行檢查,知道確認所有問題都已經修複。
錯誤除了會顯示在標準輸出之外,還會輸出到文件 infer-out/bug.txt
中,我們過濾這些問題,僅顯示最有可能存在的。
在結果文件夾中(infer-out
),同時還有一個 csv 文件 report.csv
,這裡包含了所有 Infer 產生的信息,包括:錯誤,警告和信息。
OCLint
OCLint是基於Clange Tooling編寫的庫,它支持擴展,檢測的範圍比Infer要大。不光是隱藏bug,一些代碼規範性的問題,例如命名和函數複雜度也均在檢測範圍之內。
安裝OCLint
OCLint一般通過Homebrew安裝
$ brew tap oclint/formulae
$ brew install oclint
通過Hombrew安裝的版本為0.13。
$ oclint --version
LLVM (http://llvm.org/):
LLVM version 5.0.0svn-r313528
Optimized build.
Default target: x86_64-apple-darwin19.0.0
Host CPU: skylake
OCLint (http://oclint.org/):
OCLint version 0.13.
Built Sep 18 2017 (08:58:40).
我分別用Xcode11在兩個項目上運行過OCLint,一個實例項目可以正常運行,另一個複雜的項目卻運行失敗,報如下錯誤:
1 error generated
1 error generated
...
oclint: error: cannot open report output file ..../onlintReport.html
我並不清楚原因,如果你想試試0.13能否使用的話,直接跳到安裝xcpretty。如果你也遇到了這個問題,可以回來安裝oclint0.15版本。
OCLint0.15
我在oclint issuse #547這裡找到了這個問題和對應的解決方案。
我們需要更新oclint至0.15版本。brew上的最新版本是0.13,github上的最新版本是0.15。我下載github上的release0.15版本,但是這個包並不是編譯過的,不清楚是不是官方自己搞錯了,只能手動編譯了。因為編譯要下載llvm和clange,這兩個包較大,所以我將編譯過後的包直接傳到了這裡CodeChecker。
如果不關心編譯過程,可以下載編譯好的包,跳到設置環境變數那一步。
編譯OCLint
$ brew install cmake ninja
2、clone OCLint項目
$ git clone https://github.com/oclint/oclint
3、進入oclint-scripts目錄,執行make命令
$ ./make
成功之後會出現build文件夾,裡面有個oclint-release就是編譯成功的oclint工具。
設置oclint工具的環境變數
設置環境變數的目的是為了我們能夠快捷訪問。然後我們需要配置PATH環境變數,註意OCLint_PATH的路徑為你存放oclint-release的路徑。將其添加到.zshrc
,或者.bash_profile
文件末尾:
OCLint_PATH=/Users/zhangferry/oclint/build/oclint-release
export PATH=$OCLint_PATH/bin:$PATH
執行source .zshrc
,刷新環境變數,然後驗證oclint是否安裝成功:
$ oclint --version
OCLint (http://oclint.org/):
OCLint version 0.15.
Built May 19 2020 (11:48:49).
出現這個介紹就說明我們已經完成了安裝。
安裝xcpretty
xcpretty是一個格式化xcodebuild輸出內容的腳本工具,oclint的解析依賴於它的輸出。它的安裝方式為:
$ gem install xcpretty
OCLint的使用
在使用OCLint之前還需要一些準備工作,需要將編譯項COMPILER_INDEX_STORE_ENABLE
設置為NO。
- 將 Project 和 Targets 中 Building Settings 下的
COMPILER_INDEX_STORE_ENABLE
設置為 NO - 在 podfile 中 target 'target' do 前面添加下麵的腳本,將各個pod的編譯配置也改為此選項
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['COMPILER_INDEX_STORE_ENABLE'] = "NO"
end
end
end
使用方式
1、進入項目根目錄,運行如下腳本:
$ xcodebuild -workspace ProjectName.xcworkspace -scheme ProjectScheme -configuration Debug -sdk iphonesimulator | xcpretty -r json-compilation-database -o compile_commands.json
會將xcodebuild編譯過程中的一些信息記錄成一個文件compile_commands.json
,如果我們在項目根目錄看到了該文件,且裡面是有內容的,證明我們完成了第一步。
2、我們將這個json文件轉成方便查看的html,過濾掉對Pods文件的分析,為了防止行數上限,我們加上行數的限制:
$ oclint-json-compilation-database -e Pods -- -report-type html -o oclintReport.html -rc LONG_LINE=9999 -max-priority-1=9999 -max-priority-2=9999 -max-priority-3=9999
最終會產生一個oclintReport.html
文件。
OCLint支持自定義規則,因為其本身規則已經很豐富了,自定義規則的需求應該很小,也就沒有嘗試。
封裝腳本
OCLint跟Infer一樣都是通過運行幾個腳本語言進行執行的,我們可以將這幾個命令封裝成一個腳本文件,以OCLint為例,Infer也類似:
#!/bin/bash
# mark sure you had install the oclint and xcpretty
# You need to replace these values with your own project configuration
workspace_name="WorkSpaceName.xcworkspace"
scheme_name="SchemeName"
# remove history
rm compile_commands.json
rm oclint_result.xml
# clean project
# -sdk iphonesimulator means run simulator
xcodebuild -workspace $workspace_name -scheme $scheme_name -configuration Debug -sdk iphonesimulator clean || (echo "command failed"; exit 1);
# export compile_commands.json
xcodebuild -workspace $workspace_name -scheme $scheme_name -configuration Debug -sdk iphonesimulator \
| xcpretty -r json-compilation-database -o compile_commands.json \
|| (echo "command failed"; exit 1);
# export report html
# you can run `oclint -help` to see all USAGE
oclint-json-compilation-database -e Pods -- -report-type html -o oclintReport.html \
-disable-rule ShortVariableName \
-rc LONG_LINE=1000 \
|| (echo "command failed"; exit 1);
open -a "/Applications/Safari.app" oclintReport.html
oclint-json-compilation-database
命令的幾個參數說明:
-e
需要忽略分析的文件,這些文件的警告不會出現在報告中
-rc
需要覆蓋的規則的閥值,這裡可以自定義項目的閥值,預設閥值
-enable-rule
支持的規則,預設是oclint提供的都支持,可以組合-disable-rule來過濾掉一些規則 規則列表
-disable-rule
需要忽略的規則,根據項目需求設置
在Xcode中使用OCLint
因為OCLint提供了xcode格式的輸出樣式,所以我們可以將它作為一個腳本放在Xcode中。
1、在項目的 TARGETS 下麵,點擊下方的 "+" ,選擇 cross-platform 下麵的 Aggregate。輸入名字,這裡命名為 OCLint
2、選中該Target,進入Build Phases,添加Run Script,寫入下麵腳本:
# Type a script or drag a script file from your workspace to insert its path.
# 內置變數
cd ${SRCROOT}
xcodebuild clean
xcodebuild | xcpretty -r json-compilation-database
oclint-json-compilation-database -e Pods -- -report-type xcode
可以看出該腳本跟上面的腳本一樣,只不過 將oclint-json-compilation-database
命令的-report-type
由html
改為了xcode
。而OCLint作為一個target本身就運行在特定的環境下,所以xcodebuild可以省去配置參數。
3、通過CMD + B
我們編譯一下項目,執行腳本任務,會得到能夠定位到代碼的warning信息:
總結
以下是對這幾種靜態分析方案的對比,我們可以根據需求選擇適合自己的靜態分析方案。
SwiftLint | Infer | OCLint | |
---|---|---|---|
支持語言 | Swift | C、C++、OC、Java | C、C++、OC |
易用性 | 簡單 | 較簡單 | 較簡單 |
能否集成進Xcode | 可以 | 不能集成進xcode | 可以 |
自帶規則豐富度 | 較多,包含代碼規範 | 相對較少,主要檢測潛在問題 | 較多,包含代碼規範 |
規則擴展性 | 可以 | 不可以 | 可以 |
參考
OCLint 實現 Code Review - 給你的代碼提提質量