Lagging in RecyclerView at very first scrolling

Question

I display a list of device's contacts. In my Samsung Galaxy S8 with Android version 9, when I scroll the recyclerView for very first time, it is not smooth and lagging a little bit. But then it start to scroll smoothly very well. If I close the app using back button and start the app again, it scrolls smoothly again, but If I destroy instance of app from recent history, and start the app again, it is not smooth and lagging a little bit just at first scroll. ( I have tested in Google Pixel2, and when there is low buttery, I feel the same lag as I explained. )

Here is a recorded screen from the issue in Galaxy s8 : https://drive.google.com/file/d/1szfF1oKEYZK3LIqQHC-MsapRxdJ85bFy/view?usp=sharing

I optimized recyclerView adapter as much as possible, and it seems issue is not related to my Adapter. You can check the source code here : https://github.com/AliRezaeiii/DignityContacts

I have a customized CoordinatorLayout.Behavior to hide/show AppBarLayout as well as bottomBar. I am sure that it is not related to that since when there is not CoordinatorLayout behavior, it shows lagging again as I explained above.

Here is my recyclerView item layout :

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" 
    android:layout_height="wrap_content" 
    android:background="@android:color/white" 
    android:orientation="vertical">
    
    <include layout="@layout/contact_separator" />
    
    <include layout="@layout/contact_detail" />
    
    <LinearLayout
        android:id="@+id/subItem"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:orientation="vertical" />
    
    </LinearLayout>

contact_separator and contact_detail are both ConstaintLayouts.

Here is how I setup recyclerView :

mAdapter = new ContactsAdapter();
binding.recyclerView.setHasFixedSize(true);
binding.recyclerView.setAdapter(mAdapter);

final Observer<Resource<List<Contact>>> contactsObserver = resource -> {
            if (resource instanceof Resource.Success) {
                mContacts = ((Resource.Success<List<Contact>>) resource).getData();
                mAdapter.setItems(mContacts, true);
            }
        };

What could be the reason of that?

Answer 1

It's difficult to tell without the project running, but a very quick look (as quick as 2-3 minutes browsing through your Adapter code), there are some "smells".

1. You're using a plain RecyclerView.Adapter, you should/could be using ListAdapter<T, K> with a DiffUtilCallback to avoid using notifyDataSetChanged() when you do setList(...) (instead you only have to do submitList(...) and let the Adapter resolve the problem for you.

2. Your bind(...) method is quite complex and long; there's two potential loops and view-param change (widget dimensions), this would cause at least a measure pass (which would be followed by a layout pass), all this happens for each item in the view holder, when you submit list. When the app is created (after it was being destroyed), all this must be computed (again) so the recycler view, which has a setFixedSize = true (why do you need this, this is not true given your adapter). If fixed Size is true, then a requestLayout() call is avoided but this means you're telling your adapter its size is constant (meaning it can grow/shrink based on item count, but all the items have the same size). It's an optimization, but it can bite you back and it's most likely not what you want.

3. Your flagItems is a LinearLayout, you add/remove views to this linear layout dynamically at runtime, inside the bind method.

4. You do the same for subItem (another LinearLayout).

5. Then there's again the possibility of another loop (Contact numbers) where the layout is potentially modified again (Constraint sets are changed).

All this (there are some other details) but this would do for now... are "red flags" when it comes to Adapters.

The fun part is that all this should happen in less time that it takes android to render a frame (60ms?). So you are asking the code to do a lot of work and triggering a lot of side-effects, and expect it to do it in 60ms or less. This for EACH view that is getting bound (depending on the device's screen size), so imagine 5 items fit on screen; the RecyclerView will bind a few more in advance to be prepared for when you scroll.

What can you do?

I'd start by taking a step back at your List<Contact> contacts. These Contacts could be better transformed for presentation on a RecyclerView. All the logic about what/how to show it, should be resolved ahead of time, and presented to the adapter (Which already has other work to do) in the flattest/simplest possible form. You could use the type of ViewHolders to your advantage, by dissecting your data into different types and letting the adapter simply bind the correct viewHolder for each view type.

So instead of a List<Contact> you'd supply a List<SomeOtherObject> which is better suited for the viewHolder, and only contains the data you'd need to later re-obtain the original Contact (if needed), or to reconstruct it.

Then you can simplify and remove all that logic/decision making from the viewHolder#bind method, since a lot of that is resolved when you determine which type of data you are going to bind.

I'd start there, because you can try to optimize all you want, but you're still asking the Adapter to do all this work for you.

Why does this NOT happen when you "don't kill the app"?

That's because (I estimate) the things are cached and pre-calculated (they already took time the 1st time), so because you have FixedSize = true, the RecyclerView knows (has been told to) that the size of each ViewHolder will not change, so there's no need to re-calculate it.

In short, you didn't make your adapter more performant, you simply told him to spend that amount of time once. ;)

Answer 2

You should initialize adapter with a list, currently you're setting an observer and when it gets observed then the list is initialised that why it's lagging.