The cache

RecyclerView cache (tryGetViewHolderForPositionByDeadline this method)

  • MAttachedScrap Level 1 cache for quickly recreating ViewHolder on screen. This level of cache is used to store arrayLists implemented by the ViewHolder. There is no capacity limit on this level of cache. The data is not modified and the Binding methods of the Adapter are not repeated (the ViewHolder view is still on the screen).

  • The mChangedScrap variable is the same as the mAttachedScrap variable above, except that the Viewholder has been changed, If you use the ViewHolder that changed here you need to retrace the Adapter’s binding data method (the ViewHolder view is still on screen)

  • MCacheViews is also an ArrayList that stores ViewHolder views, which stores dettach removed views, which stores removed views (roll off the screen), and RecyclerView views that have separate relationships with RecyclerView. However, the ViewHolder still holds the previous information, and this level of cache is two by default (capacity is limited).

You can change the capacity using the setItemViewCacheSize(5) method

  • MViewCacheExtension is an abstract static class used to act as an additional cache pool. It is not officially implemented and defaults to NULL

  • RecyclerViewPool Viewholder cache pool, where the Viewholder stored is not only removed views, but also restored to factory Settings, any traces of white to you are removed. ViewHolder who wants to use the cache here is bound to go back to the binding method caused by the collapse of A. Moreover, because RecyclerView supports multiple layouts, the cache here is stored separately according to itemType, and the default storage quantity of each type is 5

  • The item that slides off the screen is stored in mCacheView first. If mCacheViews is full, that is, there are two ViewHolder views, mCacheViews will move the ViewHolder cached to RecyclerViewpool according to FIFO. If RecyclerViewPool is also stored to its maximum value, it will be abandoned

  • Note: The ViewHolder cached in mCacheView does not purge information (powholder, state, etc.), so a ViewHolder that has just been removed from the screen can be looked up and displayed in the CacheView without rebinding. The ViewHolder cached in RecyclerViewPool will clear state and location information, so the ViewHolder searched from RecyclerViewPool needs to call bindViewHolder binding data again

The ListView cache

  • MActiveViews first level cache. These views are the views on the screen at the beginning of the layout process, layout starts the array is filled, Layout ends, mActiveViews are moved to mScrapView, The point is to quickly reproduce the list item ViewItem on the screen without having to re-select createView and bindView
  • MScrapView is the second level cache. MScrapView is a List of data, the length of the array is viewTypeCount, each List cache different types of Item layout View, the purpose of the cache is to cache off screen ItemView. The purpose is to reuse the itemView that is about to enter the screen. When the mAdapter is replaced, the mScrapViewsze is cleared

RecyclerView optimization

  • Data processing and video loading are separated

    • The time-consuming data processing logic should be placed in asynchronous processing so that the ViewHolder can manipulate the data-view binding logic while the Adaoter notify changes the data

  • Data optimization

    • When data is pulled in pages, the remote data is cached to improve the secondary loading speed
    • For newly added and deleted data, DiffUtil is used to refresh data locally rather than refresh data all the time

  • Reduce layout hierarchy and overdrawing

    • You can use custom views or better layouts to reduce levels, remove unnecessary backgrounds and reduce overdrawing

  • Reduce the time of the XML file inflate

    • The XML file synchronized out of the itemView is damaged by a time-consuming IO operation, especially if the item reuse rate is low. As the Type increases, the loss caused by this inflate is very large. At this point you can use code to generate the layout

  • Reduce object creation

    • A slightly complex Item will contain a large number of views, and creating a large number of views will take a lot of time, so try to simplify ItemView as much as possible
    • When designing itenType, the parts that can be shared by multiple viewTypes should be designed as custom View, fried View structure and nesting

  • Use the prefetch function of RecyclerView (prefetch function), process the data in advance, and then cache the obtained Itemholder, wait until you really need to use it directly from the cache, the default is enabled

  • If the item is fixed, you can use RecyclerView. SetHasFixedSize (true) to avoid requestLayout waste of resources

  • Stop loading data and images while sliding

  • Animation is not required, turn off the default animation to improve efficiency, animation is a large overhead in the Android system

  • Through RecyclerView. SetItemViewCacheSize (size) to increase the cache RecyclerView, with controls in time to improve rolling fluency

  • If multiple RecyclerView Adapter is the same, such as nested RecyclerView exist the same Adapter, you can set RecyclerView. SetRecyclerViewPool

RecyclerViewPool method to share a RecyclerViewPool

  • In onBindView, just do the binding, don’t create the object

  • Listen to recyclerView slide, realize the list slide stop loading pictures, stop loading, Glide has two methods: With (mContext).resumerequests (), Glide. With (mContext).pauserequests () Picasso.get().resumeTag(tag),Picasso.get().pauseTag(tag);