Things about memory optimization in Android - a record of image optimization

The customer service group was shouting: This user's picture is not showing, that user's picture is not showing. I was holding a test machine that was working fine, what the hell...

Open bugly silently.

The spring scenery in the garden cannot be contained, and the memory is overflowing everywhere! Yes, I am in trouble again!

Memory problems are always a topic that is both strange and familiar, and most of them happen on a mobile phone called the user's home. The Android system itself is constantly being optimized, the third-party framework is gradually maturing, and with the large memory support from mobile phone manufacturers, it seems that memory problems have become less common, but they still cannot be ignored.

Taking advantage of this record of fixing the memory problem, I would like to share some "self-proclaimed" solutions for your reference. Ok, let's go!

The three steps to fix the problem are to reproduce it, locate it, and finally fix it.

Reproduction

Some people might say that the abnormal phenomena are all there, so there is no point in reproducing them and they can just jump into the code and start working on it.

Fixing a bug is always a thrilling experience. If you are not careful, it may lead to a huge disaster. Either the fix is ​​incomplete or new problems are introduced. Understanding the whole cause from the beginning can not only deepen the understanding of the problem, but also ensure that you can verify whether the problem has been fixed in the end.

Memory problems often occur in some special environments, and they are not necessarily present in many cases. They often occur in some low-end and mid-range models. So starting with the model may be a good choice.

Finally, we found the corresponding problematic machine model and system version through Bugly, and found the Taiyun test machine on various cloud testing platforms. We followed several fixed processes to enter the problem page, executed them repeatedly, and finally locked the recurrence process.

position

Now that you know how to reproduce the problem, the next step is to locate where the problem is. Usually, memory problems will occur in two situations:

1. Memory accumulation: Due to special circumstances, the page is closed but the resources are still left in the memory.
2. High memory usage: The memory usage is too high due to business needs or improper use.

Let’s first take a look at what kind of situation this problem belongs to.

In the Android monitor that comes with Android Studio 2.3 and earlier versions, you can intuitively reflect the overall memory usage level of the current application. [I guess everyone is tired of sharing how to use the tool, so I won’t repeat it this time.

142MB!!!! So much memory was occupied before entering the accident scene. No wonder there was memory abnormality afterwards. It seems that we have to solve the problem of high memory usage first. We must first understand the specific situation of memory in detail, so that we know where to start to solve it, whether it is to avoid meaningless use or optimize necessary usage.

First force GC, then dump the Java heap to see the overall memory situation and sort by shallow size.

The first thing that comes into view is the byte array. As we all know, bitmap has always been a big customer. Let's analyze the various objects in byte[].

From the data, there are a lot of memory usage with the same size. Theoretically, there should be a lot of pictures with the same size. But why are there so many? Is it the same picture repeated? Or something else?

As the saying goes, seeing is believing. If you can see what these pictures look like, would it be easier to make corresponding judgments? Come on, start taking action:

Android memory optimization from Gracker 3: Open the original Bitmap image in MAT | Performance.

Thanks to Gracker for sharing, I got a new skill. For the specific process, please refer to the portal. The main idea is to save the corresponding byte array as an original image file through MAT, and then use the corresponding tool to open the preview. However, I remember that Android Studio could view it directly before, but I don’t know where it is now.

Step 1:

Because the file mat dumped by Android Studio cannot be opened directly, it needs to be converted. Find the prof file just dumped in Captures. Right-click -> Export to standar .hprof.

Step 2:

Opened by the MAT Eclipse Memory Analyzer Open Source Project.

Step 3:

Right click the object you want to view -> Copy -> Save Value To File. Save as xxx.data. He recommended using gimp from Gracker. Photoshop I'm not sure if there is something wrong with my usage, it couldn't display properly during verification.

Step 4:

Check the relevant properties of the corresponding image, mainly the width and height. Because the original format file of the image was saved in the previous step, which does not contain the corresponding parameter information, the corresponding parameters need to be specified when importing into gimp.

Step 5:

Open GIMP - Downloads. Then open the image you just exported. The image type depends on the actual image, usually 8888 or 565, select RGB Alpha or RGB565. Then fill in the width and height with the parameters you just queried. ***Click open to see the actual image.

In this way, we can intuitively view the actual situation of the images in the memory, and then we can further analyze the actual cause of the problem.

Through the above methods, three problems were located:

1. There are a lot of picture resources occupied, and there are indeed a lot of pictures on the homepage.
2. There are image resources that are not currently in use (gone state).
3. There are a lot of mask images occupied because of the effect required by the designer.

Solution - Large number of images occupying

Regarding the problem of large number of images, we can actually think about it from the following perspectives.

1. From the perspective of effect design, we should avoid using full-screen images as little as possible to handle the needs. But in this regard, I personally advocate respecting designers and leaving professional matters to professionals.
2. For image resources themselves, RGB565 should be used as much as possible while satisfying the effect. Maybe it is not obvious for a small number of images, but in the case of a large number of images, the saved memory resources are still substantial.
3. Image resources are released in time when not in use.

Combined with the above directions, let's look at the problems we encountered. The design angle cannot be adjusted at present. The reason is too complicated to explain here. The resource itself is already RGB565. The release of pictures should be the strength of fresco, but it seems that it is not. It seems that the problem may lie here. Go back to the UI page and take a look, and you will understand.

viewpager + fragment + recyclerview, which is equivalent to a large number of pictures being in use, so fresco will not release the corresponding resources.

Temporary solution:

In order to ensure the smooth operation of the core logic, Event events are sent through RxBus when entering and exiting the core page, and then register to receive this series of events on pages that use a large number of images, traverse all SimpleDraweeViews, and call onDetach or onAttach of their Controllers to achieve temporary release and loading recovery of image resource references.

Why is it a temporary solution? Because I always feel that it is a tricky way. In theory, you should not directly call methods to interfere with the management process of Fresco. So I leave a pit here, and fill it back after I have a deeper understanding of the principles of Fresco. I also hope that you can give some suggestions or opinions.

Solution - Unused image resources are occupied

Each page has tips for handling network exceptions and related data loading exceptions. The original handling method was to hide them after unified import through include, and only display them when an exception occurs. The problem lies here. These exception prompts themselves have a small probability of being triggered, but if they are imported through the include tag, they will be directly instantiated and occupy memory resources.

Temporary solution:

Use ViewStub tag to load on demand.

Why is it a temporary solution? Because some models cut off the WiFi when the screen is black. When re-entering the application, they will go through a networking process, so the network exception will be triggered first. ViewStub can only be loaded once, and it will occupy memory after loading.

Solution - Mask Image

In order to display text on an image without being affected by the pattern, a shadow mask was added to ensure the display effect of the font. This was usually achieved using the fresco:overlayImage method. However, this implementation method would cause the mask itself to be an independent memory resource.

Solution:

Try to use Processor to pre-combine the mask with the image to be displayed so that only one resource is kept in memory.

result

Through the above optimization methods, the same model was tested again and the memory usage was reduced....

Summarize

This time, we started with the high memory usage and solved the memory overflow caused by excessive memory usage. I will add more to the following when I encounter memory legacy problems later.

The troubleshooting and resolution of memory issues is a common topic, because adaptation and other issues are often a difficult problem. It is difficult to find during development, so it is recommended to routinely check the memory status after completing a requirement to see if there are any problems or parts that need to be adjusted.