Shulou(Shulou.com)06/02 Report--

This article mainly analyzes the relevant knowledge of the tools to improve the quality of Android code, the content is detailed and easy to understand, the operation details are reasonable, and has a certain reference value. If you are interested, you might as well follow the editor and learn more about the tools to improve the quality of Android code.

In this article, I will introduce how to improve the quality of your Android code through different automation tools such as CheckStyle,FindBugs,PMD and Android Lint. Checking your code in an automated way is very useful, especially if you are working in a team, in order to maintain a strict syntax format in your code and to avoid a lot of bad habits and errors. I'll show you in detail how to use these tools directly to build scripts through Gradle in your spare time and how to configure them.

Fork the example

I strongly recommend that you copy this project, although all the cases I will introduce are from it. In the meantime, you will be able to test your knowledge of these tools.

About Gradle tasks

The concept of Gradle tasks (what they mean in Gradle) is the basis for understanding this article (and how to write Gradle scripts in a general way). I strongly recommend that you take a look at these two documents on Gradle tasks (this one and this one). This document contains a large number of examples, so it is very easy to start learning. Now, I assume that you have copied my Repo, you import this project into your Android Studio, and you are familiar with the Gradle task. If not, don't worry, I will try my best to make my explanation more meaningful.

About the hierarchy of the sample project

You can split the gradle script file into many files. I now have three gradle files:

The files in the root folder are more or less about the configuration of the project (which Maven Repos is used and which version of Gradle is used).

Files in the App subfolder, which are typical gradle files used to create Android applications.

The files in the config subfolder, where the files are the focus of our relationship, because I use the files here to save and configure all the tools in the project.

Checkstyle

Brief introduction

"Checkstyle is a development tool used to help programmers write Java code that conforms to the code specification. It automatically checks Java code for idle people to perform this boring (but important) task."

As the developers of Checkstyle have said, this tool can help you define and maintain a very precise and flexible code specification form in your project. When you start CheckStyle, it will analyze your Java code according to the configuration file provided and tell you all the errors found.

The form of Gradle

The following code shows you the most basic configuration for using Checkstyle in your project (such as Gradle tasks):

Task checkstyle (type: Checkstyle) {configFile file ("${project.rootDir} / config/quality/checkstyle/checkstyle.xml") / / Where my checkstyle config is... ConfigProperties.checkstyleSuppressionsPath = file ("${project.rootDir} / config/quality/checkstyle/suppressions.xml") .absolutePath / / Where is my suppressions file for checkstyle is... Source 'src' include' * * / * .java 'exclude' * * / gen/**' classpath = files ()}

So, basically this task will analyze your code based on checkstyle.xml and suppressions.xml. To execute it through Android Studio, you just need to launch it from the CheckStyle on the tool side.

After starting CheckStyle, you will receive a report showing every error found in your project. This is a very direct way.

If you want to do more configuration on checkstyle, you can refer to this document.

The skills of using Checkstyle

Checkstyle will find a lot of problems, especially if you use a lot of rule configurations, just as you set up a very precise syntax. Although I use checkstyle through Gradle, for example, before I push, I still recommend that you use the checkstyle plug-in for IntellJ/Android Studio (you can install the plug-in directly from Android Studio's work panel file / settings / plug-in). In this way, you can use checkstyle in your project according to the same files configured for Gradle, but far more than that, you can get the results with hyperlinks directly in Android Studio, which corresponds to your code through hyperlinks, which is very useful (Gradle this way is still important, because you can use it to automatically build systems, such as Jenkins).

Findbugs

Brief introduction

Does Findbugs need a profile? I think its name is already as its name implies. "FindBugs uses static analysis to check the Java bytecode for the occurrence of the bug pattern." FindBugs basically only needs a program to analyze the bytecode, so it is very easy to use. It can detect common errors, such as the wrong Boolean operator. FindBugs can also detect errors due to misunderstood language features, such as Java parameter tuning (which is not really possible because its parameters are passed values).

The form of Gradle

The following code shows you the most basic configuration for using Findbugs in your project (take the Gradle task as an example):

Task findbugs (type: FindBugs) {ignoreFailures = false effort = "max" reportLevel = "high" excludeFilter = new File ("${project.rootDir} / config/quality/findbugs/findbugs-filter.xml") classes = files ("${project.rootDir} / app/build/classes") source 'src' include' * / * .java 'exclude' * / gen/**' reports {xml.enabled = false html.enabled = true xml {destination "$project.buildDir/reports/findbugs/findbugs.xml" } html {destination "$project.buildDir/reports/findbugs/findbugs.html"}} classpath = files ()}

It's so much like a Checkstyle task. Although Findbugs supports both HTML and XML reporting forms, I choose HTML because it is more readable. Also, you only need to set the location of the report as a bookmark to quickly access its location. This task will also fail if a Findbgus error is found (also generate a report). Executing a FindBugs task is like executing a CheckStyle task (except that the name of the task is "FindBugs").

The skills of using Findbugs

Since the Android project is slightly different from the Java project, I highly recommend using the FindBugs filter (rule configuration). You can do this in this example (for example, one of the projects). It basically ignores the R file and your Manifest file. By the way, since you use FindBugs to analyze your code, you need to compile your code at least once before you can test it.

PMD

Brief introduction

This tool has an interesting fact: PMD does not have an exact name. You can find interesting names on the official website, such as:

Pretty Much Done

Project Meets Deadline

In fact, PMD is a powerful tool that works a bit like Findbugs, but (PMD) directly examines the source code instead of bytecode (PMD, by the way, works in many languages). The core goal of (PMD and Findbugs) is the same, using static analysis to find out which patterns cause bug. So why use both Findbugs and PMD? Okay! Although Findbugs and PMD share the same goals, their inspection methods are different. So PMD sometimes detects bug but Findbugs doesn't, and vice versa.

The form of Gradle

The following code shows you the most basic configuration for using PMD in your project (take the Gradle task as an example):

Task pmd (type: Pmd) {ruleSetFiles = files ("${project.rootDir} / config/quality/pmd/pmd-ruleset.xml") ignoreFailures = false ruleSets = [] source 'src' include' * / * .java 'exclude' * / gen/**' reports {xml.enabled = false html.enabled = true xml {destination "$project.buildDir/reports/pmd/pmd.xml"} html {destination "$project.buildDir/reports/pmd/pmd.html"}

As far as PMD is concerned, it is almost the same as Findbugs. PMD supports both HTML and XML reports, so I chose HTML again. I strongly recommend that you use your own generic configuration set file, as I did in this example (check this file). So, of course, you should take a look at these generic configuration set files. I suggest you, because PMD is more controversial than FindBugs, for example, if you don't declare "if statement" or "if statement" empty, it will basically give you a warning message. If these rules are correct, or if this is correct for your project, I really recognize the work of you and your teammates. I don't want the program to crash because of "if statement". I think the readability of the program is poor. Executing a PMD task is like a CheckStyle task (except that the name of the task is "PMD").

The skills of using PMD

I recommend that you do not use the default rule configuration set, you need to add this line of code (already added):

RuleSets = []

Otherwise, because the default value is these basic rule configuration sets, the basic rule configuration set is executed together with the rule set you define. So, if your custom rule set is not in those basic configuration sets, they will still execute.

Android Lint

Brief introduction

"the Android lint tool is a static code analysis tool that checks Android project source files for potential defects and optimization improvements for correctness, security, performance, availability, accessibility and internationalization." As stated on the official website, Android Lint is another static analysis tool dedicated to Android. It is very powerful and can give you a lot of advice to improve the quality of your code.

The form of Gradle

Android {lintOptions {abortOnError true lintConfig file ("${project.rootDir} / config/quality/lint/lint.xml") / / if true, generate an HTML report (with issue explanations, sourcecode, etc) htmlReport true / / optional path to report (default will be lint-results.html in the builddir) htmlOutput file ("$project.buildDir/reports/lint/lint.html")}

I recommend that you use a separate file to define which configurations need to be used and which are not. This site defines all the configurations based on the ADT version of *. The lint file in my demo project contains all these rules (ADT 21), including "severity" with a level of "ignore":

IconDensities: this rule configuration ensures that you define the density (except ldpi) in each image resource.

IconDipSize: this rule configuration ensures that you define the appropriate resource for each dip (in other words, if you don't set the same image resource for each density, you don't need to resize the image).

So you can reuse the lint file and activate all the rules you want. Executing an Android Lint task is like executing a CheckStyle task (except that the name of the task is "lint").

The skills of using Android Lint

There are no special tricks for Android Lint, just keep in mind that Android Lint tests all configuration rules, except for "severity" configurations with a level of "ignore". So if new configuration rules are released under the new version of ADT, they will be checked rather than ignored.

Example demonstration

Now you have all the ways to use these four tools for your project. Obviously, it would be better if we could use these four tools at the same time. You can add dependencies between your gradle tasks, such as when you perform one task, other tasks are executed first. When performing the "check" task, Checkstyle, Findbugs, PMD, and Android Lint will be executed at the same time. It's a great way to do a quality check before you execute / commiting / pushing / ask merge request.

You can find a complete example of all tasks in this Gradle file. You can separate all the quality profiles and Gradle files from the demo examples you see, which are all put together in the "config/quality" folder.

About "what are the tools to improve the quality of Android code" here, more related content can be searched for previous articles, hope to help you answer questions, please support the website!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.