项目规范性检测工具Lint

项目规范性检测工具lint.bat

 

一、Lint基本概念介绍

  Android Lint是SDK Tools 16 (ADT 16)之后才引入的工具,通过它对Android工程源代码进行扫描和检查,可发现潜在的问题,以便程序员及早修正这个问题。Android Lint提供了命令行方式执行,还可与IDE(如Eclipse)集成,并提供了html形式的输出报告。

  由于Android Lint在最初设计时就考虑到了independent于IDE,所以它可以很方便的与项目中的其他自动系统(配置/ Build / 测试等)集成。Android Lint主要用于检查以下这些错误:

  1、Missing translations (and unused translations)
2、Layout performance problems (all the issues the old layoutopt tool used to find, and more)
3、Unused resources
4、Inconsistent array sizes (when arrays are defined in multiple configurations)
5、Accessibility and internationalization problems (hardcoded strings, missing contentDescription, etc)
6、Icon problems (like missing densities, duplicate icons, wrong sizes, etc)
7、Usability problems (like not specifying an input type on a text field)
8、Manifest errors

  当然Android Lint远远不只检查以上列出的8中错误,这里不一一给出,想了解更多的小伙伴可以参考相关文档。

  在Eclipse中可以在菜单Window->Preference->“Lint Error Checking”中设置规则的检查级别,如图1所示。

  点开界面上的Severity下拉箭头,可以看到Lint的检查级别从高到低分别是:

  Default

  Fatal

  Errro

  Waring

  Information

  Ingore(即不检查)

 

二、Lint命令行使用方法

  命令行的操作,自然是先从路径说起了。

  Lint的命令名称为lint.bat,完整路径为SDK安装目录下的tools文件夹中,比如我的为:“E:\Android\Android Eclipse\sdk\tools\lint.bat”。为了以后能够快速使用该命令,建议将路径“E:\Android\Android Eclipse\sdk\tools”加入系统环境变量中。

  常规的用法格式为:lint.bat Project_Full_Path --xml Project_Result.xml --html Project_Result.html。其中:

  Project_Full_Path为项目完整的路径名,也可以先定位到项目上一级目录然后在此写上项目名即可。如先定位于目录“E:\Android\Project”,工程名为LoginUMQQ,那么具体的命令为:lint.bat LoginUMQQ --xml LoginUMQQ_Result.xml --html LoginUMQQ_Result.html。

  --xml和--html指定项目检测内容的输出格式,而Project_Result.xml和Project_Result.html为对应的结果输出文件。

  一般来说,项目越大,检测过程耗时越长,不过速度是非常快的。下面给出检测命令及结果图:

  此时,在指定目录下就可以看到生成的文件了:

  这里说明一下,文件夹LoginUMQQ_Result_files中给出了error(红色圆形感叹号)、warning(灰色三角形感叹号)、run(一般不用理会)的图标,还有一个css格式文件。如下图:

  通过这三个图标在html文件中浏览检测结果时可以清楚地知道某条信息是对应哪个类别,打开html文件后,有各种信息的分类和数目:

  以图中2条未使用的属性为例(UnusedAttribute),直接点击会跳转到对应说明:

  可以发现,Lint工具真的非常给力。对于未使用的属性资源,细化到了真实的代码(包括目录、文件名、代码块)。当然,经过测试,检测结果中的其他资源也类似地方便定位与修改。注意图中下半部分给出的解释信息,分析结果还会给出warnings或errors的修改优先级,数字越大,优先级越高,最高为10;最后一段会针对当前的警告信息做一个详细的解释,还包括推荐做法。

  虽然,检测结果中的错误并不等同于Eclipse等工具在进行工程编译时的错误(会让程序终止运行),但是根据检测信息对项目进行响应的修改绝对是一个好习惯。这样做的好处有很多,如删除冗余不用的图片、xml等资源文件会让项目变得整洁,减小整体容量;注释(或删除)文件中多余的变量定义可以让文件易读、易维护。

  其实,在实际的项目管理中,若像图片这样的整体资源(或整个xml文件)是用不到的,那么可以直接删除,保险起见、也可以在其他地方进行备份。而如果要在某个文件中对部分不用的变量进行剔除,一般采用的专业做法是进行注释,而不是简单粗暴的删除,以防以后需要重新使用这些变量,而且留下痕迹也便于查看谁对该文件做过修改。

posted @ 2015-08-05 21:56  路上的脚印  阅读(3018)  评论(2编辑  收藏  举报