Android performance optimization: use Lint to optimize code and remove unnecessary resources

Preface

In addition to ensuring that the code has no functional problems and completes business development, ambitious programmers also pursue code standardization and maintainability.

Today, with the goal of "becoming an excellent programmer", Shixin will work with everyone to strive for excellence and learn to use Lint to optimize our code.

What is Lint

Lint is a code scanning and analysis tool provided by Android Studio. It can help us find code structure/quality problems and provide some solutions. This process does not require us to write test cases by hand.

Each problem found by Lint has a description and level (very similar to the bugs found by testing), so we can easily locate the problem and solve it according to the severity.

Of course, we can manually adjust this "severity". Some principles cannot be violated and must be elevated to error, while some individual issues can be ignored. After all, no one is perfect.

A brief introduction to how Lint works

Lint will check the source files of our Android project according to the pre-configured detection standards to find potential bugs or areas that can be optimized. The optimization content mainly includes the following aspects:

• Correctness: Incorrect coding, such as hard coding, use of outdated APIs, etc.
• Performance: Coding that affects performance, such as static references, circular references, etc.
• Internationalization: internationalization, direct use of Chinese characters, no resource references, etc.
• Security: Unsafe coding, such as allowing the use of JavaScriptInterface in WebView, etc.

The process of Lint detecting code is shown in the following figure:

• App source files: including Java code, XML code, icons, and ProGuard configuration files, etc.
• lint.xml: Lint detection execution standard configuration file, we can modify it to allow or prohibit reporting of some problems

Running Lint from the Command Line

The lint command is simple:

 lint [flags] <project directory>

Lint can also be run using Gradle:

Windows:

 gradlew lint

Mac:

 ./gradlew lint

I won't go into the specific command line operations here, because the process is too painful. Here's a screenshot of the XML file you get after running Lint on the command line:

Let's go directly into Lint's GUI operation.

Using Lint in Android Studio

Android Studio has built-in Lint, and we can use it directly with just a click.

Lint usage path:

Toolbar -> Analyze -> Inspect Code…

After clicking Inspect Code, a dialog box for checking the range will pop up:

The default is to check the entire project. We can click Custom scope to customize the inspection scope.

Click the drop-down box on the right and the following options will appear:

They are:

• Project Files: All project files
• Project Production Files: Project code files
• Project Test Files: Project test files
• OpenFiles: Currently opened files
• Module 'app': the main app module
• Current File: Current file

In addition to the built-in options, we can also select specific classes to check by clicking the red box in the image below:

A custom range selection box will pop up. It is empty by default. We can click the "+" sign in the upper left corner to add a new inspection range:

- Local: Only available for the current project

- Shared: Other Android Studio projects can also use it

We select Shared and give it a cool name "ShixinCuteLint". By default, it is displayed by project, and the number of files checked is 0:

The four buttons on the right in the above image indicate the type of operation to be performed:

• Include: Include files in the current folder, but not its subfolders
• Include Recursively: Include all folders in the current folder and its subfolders, recursively add
• Exclude: Remove the current folder, excluding subfolders
• Exclude Recursively : Remove the current folder and all subfolders

After we click the app folder on the left, click the Include Recursively button on the right to add all the files under the app to the check list:

You can see that all the files under the app have turned green, and there are a total of 689 folders to scan.

Click OK to test. After a while, the Inspection dialog box will pop up to show the inspection results. I didn’t expect that my code had 1769 warnings! This number is shocking:

We mainly focus on the warnings in the red box. Let’s first take a look at what is wrong with my code Performance:

Haha, I didn’t expect that I still have so much room for improvement!

As you can see from the picture above, Lint is really a magic tool that can help us discover problems that we have overlooked or are not aware of, especially in terms of performance. If you feel that you want to optimize your code but don’t know where to start, you might as well let Lint show you the way.

A powerful tool for establishing coding standards in the team: raising and lowering the level of problems

Although Lint can help us check code problems, when working with multiple people, we hope to find and solve problems while writing code.

Given that the levels of team members vary, it is sometimes difficult to ensure quality by relying on personal awareness. In this case, you can modify Lint's warning level for specific problems and alert team members with the most intuitive IDE prompts.

Lint warnings have the following severity levels:

• Unused Entry: unused attribute, gray, inconspicuous
• Typo: Spelling errors, green wavy underline, not very noticeable
• Server Problem: Server error? It seems not
• Info: annotated document, green, more conspicuous
• Weak Warning: A relatively weak warning, indicating a relatively weak
• Warning: Warning, slightly more conspicuous
• Error: Error, the most conspicuous one

In daily development, better programmers will pay attention to Warnings and optimize the code based on the warnings, but that is only a small part. But the red Error is different. Basically, you want to eliminate it when you see it.

Let’s take the example of misspellings in names.

Class, object, and traversal spelling errors may not seem like a problem, but if you have seen a lot of meaningless or wrong naming, you will definitely agree with what I am going to do next.

The default spelling error is Typo, which has a very weak hint and is often ignored:

[[182197]]

In the above example, the string variable login is written as logn. By default, Lint will mark the spelling error with a downward wavy line, which is not very noticeable. Let's modify it.

Open Preferences/Settings, search for Inspections, and the Lint detection configuration page will appear:

To change the warning level for spelling, search for "spelling":

Then select the Typo that appears, and click Severity on the right, change it to Error, and click OK.

[[182198]]

As you can see, now a red error warning will appear for spelling errors, preventing you from writing variable names carefully!

Although Lint is good, you can't drink too much.

Lint is like a mysophobia patient. Although it can make our code much cleaner, if we really want to solve all its prompts, I am afraid that the boss will be angry: I pay you to play on the computer every day, why don’t you do any work?!

Some warnings reported by Lint are indeed unnecessary. We can choose to ignore these warnings. There are two types of warnings to ignore:

1. In Java code
2. In the XML folder

Ignore Lint warnings in Java code:

The annotation for ignoring Lint warnings is very similar to @SuppressWarnings, @SuppressLint("ignore warning name").

The following code demonstrates how to ignore Lint warnings about using new APIs:

 @SuppressLint( "NewApi" )
 @Override
 public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
 }

If you don't know the specific name of the warning you want to ignore, just ignore all, of course, for the current class/method/object:

 @SuppressLint( "all" )

Ignore Lint warnings in XML code:

Just two steps:

1. Declare the tools namespace in xml
2. Use tools:ignore="ignore warning name"

For example:

 <LinearLayout xmlns:android= "http://schemas.android.com/apk/res/android"  
              xmlns:tools= "http://schemas.android.com/tools"  
              tools: ignore = "all"  
              android:layout_width= "match_parent"  
              android:layout_height= "match_parent"  
              android:orientation= "vertical"  
              android:background= "@color/white" >

Configure Lint in Gradle

Gradle can also configure key Lint operations, such as whether to enable Lint warnings or disable specified warnings.

Add lintOptions{…} to build.gradle under module. The sample code is as follows:

 android {
 ...
 lintOptions {
    // Turns off checks for the issue IDs you specify.
    disable 'TypographyFractions' , 'TypographyQuotes'  
    // Turns on checks for the issue IDs you specify. These checks are in  
    // addition to the default lint checks.
    enable 'RtlHardcoded' , 'RtlCompat' , 'RtlEnabled'  
 // To enable checks for   only a subset of issue IDs and   ignore   all others,
    // list the issue IDs with the 'check' property instead . This property overrides
    // any issue IDs you enable or disable using the properties above.
 check   'NewApi' , 'InlinedApi'  
 // If set   to   true , turns off analysis progress reporting by lint.
 quiet true  
 // if set   to   true ( default ), stops the build if errors are found.
 abortOnError false  
    // if true , only report errors.
 ignoreWarnings true  
 }
 }
 ...

Automatically delete useless resource files found

When there are many code iteration versions, it is easy to leave some useless code and resource files. We can use Lint to clear them.

Click Android Studio toolbar -> Analyze -> Run Inspection By Name.., enter the content to be inspected, here are useless resources:

Then select Unused resources, select the scope and start detection.

So many useless files were detected:

Note that there is a solution on the right: Remove All Unused Resources. Let’s put a larger picture to make it more visible:

After clicking, boom, the world is quiet from then on.

Lint is the friend of good programmers. I examine myself three times a day. Have I linted today?!