Solution to the Caton problem of Android recyclerview

Why does recyclerview get stuck

As a new control of V7 package, recyclerview has been widely welcomed by Android developers since its launch. In fact, it has replaced listview and GridView. However, many parents must have found that the performance of recycler without optimization is poor. The item used by bloggers in the last article is just a picture and two strings of words. As a result, it gets stuck as soon as it slides. I can't bear it!

So why? Recall that when using listview and GridView adapters, we use a custom class (container) called viewholder to achieve optimization, and one of the features of recyclerview is to force you to use its recyclerview.viewholder. However, recyclerview.viewholder is much more complex than the simple container we wrote (there are about 500 lines of comments in the source code), and the connection with recyclerview.adapter is also inextricably linked.

According to the popular explanation of stackoverflow above: the oncreateviewholder () method and onbindviewholder () method in recyclerview. Adapter are very time sensitive. Time consuming operations such as I / O read / write and bitmap decoding should not be carried out in them.

How to solve this problem

First of all, of course, you have to optimize your item and make rational use of tags such as < include >, < merge >, < viewstub >, so as to minimize the layout level - in fact, you should do the same in listview and GridView, which should be regarded as a habit of writing UI.

The second is to flexibly use various third-party libraries to complete various time-consuming operations, such as loading pictures through glass or Picasso. Excellent open source libraries often take performance very carefully.

The last question is, what if you just want to write a small demo and don't want to make a big fuss? If even ordinary third-party libraries cannot solve the problem, for example, the damned loadicon () method in the previous article returns a drawable object, which neither glide nor Picasso can handle directly, and transcoding is tantamount to adding a time-consuming task, what should we do? For a real app management application, a loading library such as UIL or Picasso should be introduced to load icons

The answer is that the idea completes the task before you setadapter.

Demo

Yo, come on! The code in this article is completely based on the previous article and does not need to be deleted or reconstructed.

The main thing is to add an entity bean object. All the data to be transferred during setadapter () is preloaded into memory through it! In this way, the two sensitive methods only need a simple get.

Entity class appbean.java

Main interface mainactivity.java

Adapter appadapter.java

Done! Because bloggers use mobile phones to record videos directly and then transfer them to GIF, in order to make the clicks look effective, they add a background layer to the item, which is also common in actual combat~~

Color resource file colors.xml

This pink is actually very ugly. It's just used to distinguish......

If there is no art work in actual combat development, we must carefully consider the selection and try to make our own aesthetics better!

Selector item_ selector.xml

Item layout item_ app.xml

Final operation effect

The screenshot can't feel the card, and the real machine runs more smoothly!

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.