在開發Android的過程當中,會出現一些比較不容易發現的Bug
,好比沒有對null
作判斷,會出現'NullPointException'的崩潰,下面的代碼就會出現崩潰:javascript
if (ta != null) {
mPanelHeight = ta.getDimensionPixelSize(R.styleable.SlidingUpPanelLayout_umanoPanelHeight, -1);
mShadowHeight = ta.getDimensionPixelSize(R.styleable.SlidingUpPanelLayout_umanoShadowHeight, -1);
mParallaxOffset = ta.getDimensionPixelSize(R.styleable.SlidingUpPanelLayout_umanoParalaxOffset, -1);
.......
}
ta.recycle();複製代碼
開頭的時候判斷ta不爲null
,可是在調用ta.recycle()
的時候是在if以後,在使用的時候,若是傳入的參數ta爲null
的話就會出現NullPointException
的Bug,固然好的代碼編寫習慣,以及進行code review
,還有充分的測試均可以免這種Bug的出現。若是換一種思路可以經過工具檢查出這種潛在的Bug
就最好不過的。還好有一種工具能夠解決這個問題:FindBugs
。html
FindBugs
是一個Java靜態分析工具,用來檢查類或者jar文件,查找代碼可能存在的問題。FindBugs官網地址:findbugs.sourceforge.net/。
檢測完成以後會生成一份詳細的報告,藉助這份報告能夠找到潛在的Bug
,好比前面說到的NullPointException
,還能夠檢查特定的資源沒有關閉
,例如:查詢數據庫沒有調用Cursor.close()
等。
若是採用人工的方式很難發現相似的bug,或者有一些Bug
不會發現,直到運行時纔出現,還有多是一直沒有出現,別人調用的時候沒有作檢查就直接使用了.....FindBugs
能夠自動化化的分析代碼,幫助開發者提升代碼質量,固然它能夠無難度的在Android
上面運行,經過FindBugs
的檢查可讓App的運行更加的穩定。java
FindBugs
在Gradle中作一個插件存在的,能夠在Android Studio中直接使用:數據庫
apply plugin: "findbugs"
task findbugs(type: FindBugs,dependsOn:'assembleDebug') {
ignoreFailures= true
effort= "default"
reportLevel= "high"
println( "$project.buildDir")
classes = files("$project.buildDir/intermediates/classes")
source= fileTree("src/main/java/")
classpath= files()
reports{
xml.enabled=false
html.enabled=true
xml {
destination "$project.buildDir/findbugs.xml"
}
html{
destination "$project.buildDir/findbugs.html"
}
}
}複製代碼
代碼解釋:app
FindBugs
的插件:apply plugin: "findbugs"
。task
任務,這個任務的類型是FindBugs
,指定依賴assembleDebug
是爲了先生成.classe文件,才能對代碼進行靜態分析。ignoreFailures
:有警告錯誤的時候也是容許構建。reportLevel
:報告的級別,Low
,Medium
,High
通常來講咱們首先關注的是高級別的報告,再關注低一級別的報告。classes
和source
分別是對應的.classe文件夾地址,和源代碼文件地址。repoets
指定報告類型,有兩種方式xml
和html
,只容許一種輸出格式。定義完成以後,同步下Gradle
,以後在右側的Gradle
的菜單中找到對於的Module
,就能夠在Tasks中找到對應的findBugs任務,點擊便可運行。工具
運行完成以後,會獲得對應的一個相似下圖的報告:測試
FindBugs
的警告:
Possible null pointer dereference
,可能出現null的代碼。何時運行是一個問題,通常狀況下在原有的項目中加入FindBugs
以後,能夠檢測出一些之前的代碼存在的問題,因此在剛剛使用FindBugs
的時候應該作一次全面的檢查,解決掉對應的問題。
以後的運行,通常能夠在完成一個版本對應功能開發完成以後能夠檢查一次,防止新修改的代碼有潛在的bug,另外一個時間點就是在每次修復完Bug
以後,再運行一次,防止修復Bug
的時候,形成了新的Bug
。gradle