scenario

In most Android development, for project management reasons, application performance issues are often overlooked. For example, an N×N UI control might load a 2N×2N image behind it.

The memory utilization in this scenario is extremely low.

Is there a way to better identify these scenarios and optimize them one by one?

The answer is yes.

Scheme comparison

ArtHook scheme

The scheme adopts Epic library written by Weishu. Through hook, hook ImageView and setImageBitmap of ART virtual machine, the width and height of bitmap and the width and height of ImageView instance in the method parameters are analyzed and compared

Add the dependent

Implementation 'me. Weishu: epic: 0.11.0'Copy the code

Hook code

public class ImageHook extends XC_MethodHook {
 
    @Override
    protected void afterHookedMethod(MethodHookParam param) throws Throwable {
        super.afterHookedMethod(param);
 
        // Make the test logic
        checkBitmap(...)
    }
 
    @Override
    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
        super.beforeHookedMethod(param); }}Copy the code

advantages

  • Very low intrusion, once initial configuration can hook the global target View control
  • Can get the code call stack, convenient developers quickly locate

disadvantages

  • Compatibility problems exist, hook system API is used, the performance of different models, different virtual machines may be different

BaseActivity scheme

In the process of business development, most application projects will settle and encapsulate their own BaseActivity. Through dynamically detecting each View control in BaseActivity, the picture loading situation can be learned


class BaseActivity : Activity() {fun onCreate(a){
        //codes
    }
    
    fun onDestory(a){
        if(isOpenCheckBitmap){
            checkBitmapFromView()
        }
    }
    
    fun checkBitmapFromView(a){
        //1. Iterate over each View control in the activity
        //2, obtain the Bitmap loaded by the View control
        //3. Compare the Bitmap width and the View width and height}}Copy the code

advantages

  • Strong compatibility, without any reflection
  • If the application itself has onDestory to release each View control image resources and other logic, you can reuse the activity View traversal process

disadvantages

  • It is too intrusive and BaseActvity itself has the risk of tampering, which increases the cost of code management

Glide solutions

Glide is a well-known image loading component that can load images on demand depending on the size of the control itself

advantages

  • The business layer can focus on business development without too much attention to the image loading process

disadvantages

  • You cannot manage View controls declared with properties such as background in XML files

ASM scheme

In this scheme, piles are inserted in the compilation process, and Bitmap size detection logic is inserted by matching key methods such as setImageBitmap and setBackground

advantages

  • Pile insertion at compile time is non-intrusive to the development process

disadvantages

  • Late maintenance costs are high

The birth of BitmapCanary

From the previous comparison, is there a non-invasive, highly compatible solution? Here’s BitmapCanary.

Introduction to the

The big picture detection tool written by me is non-invasive, strong compatibility, can timely notify developers of performance problems when loading big pictures.

Probably the best big-picture detection tool in the Old World.

How to use

In one step, add the following dependencies

debugImplementation(name: 'BitmapCanary-debug', ext: 'aar')
Copy the code

Check the record

Toast prompt

When the page where the large image is loaded is skipped or destroyed, the toast can be triggered. You can clearly know the name of the page, the name of the View control class, the corresponding ID name in the XML file

Logcat prompt

Logcat search for the keyword BitmapCanary

The 2021-04-28 15:12:33. 313, 26939-26939 / com. Pengyeah. Bitmapcanarydemo I/BitmapCanary: Bitmap size too large!!!!!! Activity Name:(com.pengyeah.bitmapcanarydemo.TwoActivity) View Id Name:(null) View Class Name:(MaterialButton) real width: (640) real height: (360) desired width: (30) desired height: (30)Copy the code

The log file

Log files are recorded in /data/user/0/[packageName]/files/ bitmapcanary_YYYYMmdD. log For example:

/data/user/0/com.pengyeah.performancetooldemo/files/BitmapCanary_20210606.log
Copy the code

Configuration items

By default, a warning is triggered when the width of the image loaded by the View control is 1.2 times larger than the View control itself. You can modify the following configurations

Warning ratio

The default 1.2 F

BitmapCanary.rate = 2F
Copy the code

Whether to output logcat

The default output

BitmapCanary.isOpenLog = false
Copy the code

Output file or not

The default output

BitmapCanary.isWriteLog = false
Copy the code

Architecture diagram

The source address

Am I

issue

Am I

Afterword.

Third – rate applications in a hurry, second – rate applications heap business, first-class applications to see the experience.

After second-rate applications are completed, only high performance can support excellent user experience.

But the reality that users see is often second – and third-rate applications, even the head app experience is often unsatisfactory, lag, high memory usage, white screen and so on are still common phenomena.

Why is that? Because there is no market for first-class apps. One is because of frequent business turnover, and the other is because users have no choice, or users can only make passive choices.

There are too many “user privacy” abuses under the guise of “user experience”. If it’s really about user experience, why can’t unified push alliance work? Why not reduce background memory usage to improve memory utilization? Why is the ROM given all permissions by default after installing the application without the user knowing?

The environment is so, I did not know is the manufacturer’s sorrow, or the user’s sorrow.