Android应用优化之代码检测优化

前言

最近换了新的公司，面对新的代码大家都有不同的熟悉过程和方法。在我的角度来说，利用代码检测工具，可以更直接地去熟悉代码逻辑和业务逻辑，表现得自己去代码质量很有追求，最重要当然是在公司的任务管理工时上面显得自己积极向上啦。不过在修改代码之前，你要根据项目的分工、明确在公司的定位，不然会造成一些不愉快的事情，但是总的来说我们还是对代码质量有追求的！

我们首先要知道Android Studio安装插件步骤。

Android Lint

Lint是Android Studio提供的一个代码检测工具，开发者通过它不用写测试代码，就可以发现和纠正问题，优化代码结构。

Lint 的使用路径：
工具栏（或右击package）-> Analyze -> Inspect Code

待分析完毕后，我们可以在Inspection栏目中看到检查的结果

Lint被检测到的问题，都有描述基本信息并指明相应的严重性级别，我们可以根据问题的严重程度进行处理优化。Android Lint内置了很多lint规则，共可以分为以下几类：

• correctness 正确性
• Security 安全性
• Performance 性能
• Usability 可用性
• Accessibility 可访问性
• Internationalization 国际化

自定义Android Lint的检查提示

在xml编写布局的时候，例如TextView，我们常常会直接将text字符串值直接写在xml上面，还是在textSize属性上写上sp值，然而，IDE会有相关的提示：

看到这个提示，大家觉得级别过低不会太多理会，其实这并不是一个好的编码习惯，所以我们可以通过更改对应的severity等级来更改提示的等级，如： 默认hardcode的severity等级为warning，我们修改hardcode的severity等级为error，那么在存在硬编码时候将会以error等级提醒我们：

修改完成后，我们可以看到text提示使用红色错误的波浪线标记了，如下图，但是我们这个修改是提示，我们看上端文件并没有标错，所以是不会影响程序运行的。

Lint还有很多自定义的设置，大家有兴趣可以看一下这篇文章自定义 Lint 规则如何帮助开发者，然后去尝试一下。

另外由于lint的规则过多，我们没有必要每一个都要知道，我们需要在检测分析后，能区分出这个是属于什么类型的错误和严重程度，根据给出的错误提示，或直接使用搜索引擎/神器 *进行对应的错误搜索并解决。

FindBugs

FindBugs使用静态分析方法为出现bug模式检查Java字节码。FindBugs基本上只需要一个程序来做分析的字节码，所以这是非常容易使用。它能检测到常见的错误，如NullPointException,多线程同步问题等。

FindBugs 的使用路径：
工具栏（或右击package）-> FindBugs -> Analyze对应目标

FindBugs支持对包级别、项目级别、模块级别、单个文件级别、自定义范围的Bug分析。

代码缺陷分类：

• Bad practice：不好的做法；
• Malicious code vulnerbility：恶意的代码漏洞；
• Correctness：正确性问题；
• Performance：潜在的性能问题；
• Security：安全性问题；
• Dodgy code：糟糕的代码；
• Experimental：实验；
• Multithreaded correctness：多线程的正确性多线程编程时，可能导致错误的代码；
• Internationalization：国际化问题；

FindBugs检测之后，当我们选中的错误，在右方有十分详细的描述，我们可以根据给出的错误类对应的行数、方法、错误基础描述、优先级的信息进行优化解决。

当然大家对FindBugs的错误描述有兴趣，可以浏览一下FindBugs Bug Descriptions，而解决方案我们利用神器 *

Checkstyle

Checkstyle是一个开发工具用来帮助程序员编写符合代码规范的Java代码。这个工具能够帮助你在项目中定义和维持一个非常精确和灵活的代码规范形式。

相信大家做过几个不同的项目后，会发现不同的开发者有着不同的代码风格习惯，有的是教科书式规范，有的是像行外人般的随心所欲。所以好的代码风格对开发是事半功倍的。站在一个管理者的角度，Checkstyle对整一个开发的水平管理很有帮助，曾听说某项目管理在code review时发现代码不符合规范直接辞退开发。站在一个开发者的角度，一个规范的代码风格，看着代码就感觉舒畅，再听着小歌，写代码简直就能飞起来。现实一点就是，人家看你的代码风格就知道你是个大神。在最近的阿里出品的Java开发手册，得到了业内很好的响应。良好的代码风格让我们的水平不断向BAT靠近。下图值得你拥有。

Checkstyle检测范围：

• javadoc注释
• 命名规范
• 标题
• 导入包规范
• 体积大小
• 空格
• 修饰符
• 代码块
• 编码问题
• 类设计问题
• 重复、度量以及一些杂项

Checkstyle使用步骤

1.安装CheckStyle-IDE插件

2.添加检查规则文件

3.CheckStyle-IDE 插件使用

同样我们可以对项目级别、模块级别、单个文件级别进行检测。

4.CheckStyle扫描结果

5.根据Checkstyle扫描结果对应修改
重复3.~5.部，至修改完成。

Checkstyle定制

我觉得定制属于自己公司的checkstyle检测规则是十分重要的。我们可以看一下Google checkstyle 检查规则

Checkstyle检查规则是基于XML配置文件的，主要通过XML文件中的module 、property、message标签节点对检查规则进行配置。在XML文件中，被指定的module，都将被对应规则检查。

1.module节点
module 主要是指检查项，如MethodName （检查方法命名）

module中有两个比较重要的节点，它们分别是Checker（checkStyle配置文件的根节点，必须存在）、TreeWalker（树遍历器），TreeWalker会自动去检查指定范围内的每一个java源文件，TreeWalker内部会定义很多module。

module的根节点是Checker，一定要有；

2.property节点
对应module 检查项中具体检查属性，如果使用默认值，property节点可以省略；

3.message节点
checkStyle检查出来，是否打印出message消息，message节点可以省略.

4.Checkstyle-IDE进行扫描后,让Checkstyle不对部分代码进行规则检查.
在定制好的checkStyle.xml文件中，添加一个名为SuppressionFilter的moudle，在过滤规则文件suppressions.xml中添加相应的过滤规则。

Checkstyle有很多玩法，有兴趣的同学可以看一下Checkstyle官网资料和Github CheckStyle源码总而言之，Checkstyle助我们技（丧）术（心）升（病）华（狂）！

PMD

PMD（注意搜索的关键字用QAPlug - PMD）是一个很有用的工具，它跟Findbugs类似，但是它不同与FindBugs检测字节码，它是直接检测源代码。PMD也是使用静态分析方式来发现错误。因此根据它们的检测方式不同，我们可以将PMD和FindBugs结合一起使用。

PMD同样有好多rule,且适用多种语言。如Android目前有三个规则：

Android (java)

• CallSuperFirst: Super should be called at the start of the method（检查在Activity或Service里的子类里，是否在错误位轩调用父类onCreate等应该放在方法前的方法。）
• CallSuperLast: Super should be called at the end of the method（检查一些应该在方法结束时才调用父类实现的情况。）
• DoNotHardCodeSDCard: Use Environment.getExternalStorageDirectory() instead of “/sdcard”（你应该用Environment.getExternalStorageDirectory()而不是硬编码去取得扩展存储目录。）

PMD使用步骤

1.在build.gradle里加入plugin

apply plugin: 'pmd'

2.定义任务，ruleSets是需要检查的一些规则，有兴趣的同学可以看看官方定义的rule,按需来添加。

task pmd(type: Pmd) {
    source fileTree('src')

     ruleSets = [
            'java-android'
            ···
    ]
    reports {
        xml.enabled = false
        html.enabled = true
        xml {
            destination "$reportsDir/pmd/pmd.xml"  //这里是报告产生的路径
        }
        html {
            destination "$reportsDir/pmd/pmd.html"  //这里是报告产生的路径
        }
    }
}

3.Gradle运行自定义任务，在对用的路径下找到检测结果。

总结

其实工具和方法很多，而且很多工具和方法有重复功能，大家都可以根据需要修改和调整。另外同学觉得本篇并没有针对常用的问题，进行分析和贴出解决方案。我个人建议大家可以在*尽情翻阅，看看歪果仁是怎么去交流和解决问题的。

由于本人刚入职不久的小开发，通篇是站在一个开发员工角度来描述，使用的是插件的形式去描述使用，如果对一个公司的代码质量管理，可以利用Gradle配置，结合SonarQube等工具进行管理和code review。

个人习惯是，我首先用Lint应用于一些基础检测，再用FindBugs检测一些潜在的Bug，PMD较少用。然而Checkstyle是需要一直使用，对代码风格的规范。

我们一定要清楚我们的目的，制定规范和使用规范的是为了让团队能一起愉快的写代码，让其他同事能简单地对项目进行维护。