Delay in loading Recyclerview

Asked

Viewed 488 times

0

It is normal to take 3 seconds to load a recyclerview with data of 16 thousand records in sqlite?

Is there any way to optimize the load?

Code here

2 answers

1

It is normal yes. and not even need to be so many records. Much of this time is the feature assembly in the device’s memory. The options are:

  1. Improve query. Why load 16,000 records at once?

  2. Use content provider and loader to take care of the loading of the recycler view... And improve the query.

Grounds of the Contentprovider

EDIT: in response to your comments, I expand the response.

It is necessary to understand that the filosofia of a mobile app is different from a desktop system. On the desktop, it might even make sense to load a lot of data, but on the mobile, the user opens and closes the app in seconds. If your app uses these seconds to load thousands of logs, before the load ends, the user has already closed.

As for your idea of uploading a few data to the list, it may be a solution, but I’ll suggest you the Google model.

No information shows it until you start typing, when a list of suggestions appears.

You will find the answer to your matching dilemma content provider, loader and auto complete

  • I actually upload the data and then the user searches between the codes. Perhaps it would not be necessary to load all the data at once, as the user was scrolling the screen this data could be loaded, but I do not know how it does it. .

  • What Content Provider has to do with performance?

  • It has to do with what I explained in my reply. You can use the benefits of a Cursorloader to keep data management in a background thread and you don’t have to carry the entire database in memory.

  • What I want to point out is that "do not need to carry the whole base in memory" nothing has to do with using Contented Provider or not.

  • There really has to be. Not loading the whole base is simply a "good practice". The use of content Provider + Loader is suggested to take care of data loading.

1


As the friend above quoted and looking at your code, you do not need to make that entire base load at once, it will only burden performance and device memory.

Recyclerview was made precisely to work with large amount of data precisely because it only carries in memory the data that are visible on the screen, while the Adapter of the same makes all this management during a scroll to discard the data leaving the screen or search for new data from the base when appear on the screen.

To do this you have to implement a Content Provider in your app to intermediate access to the database (and allow you to search for specific data you mentioned in a comment above) and implement a Cursorloader in your Activity to keep Recyclerview automatically updated when the database is modified.

Take a look at this free. Explain very well everything I just said:

https://www.udacity.com/course/new-android-fundamentals--ud851

  • What Content Provider has to do with performance?

  • Content Provider is not about performance. It has to do with good practices of data layer abstraction and code maintenance, as well as working well with Loaders.

  • Yes I know that, but you say: "For this you have to implement a Content Provider". What I meant is that it is not because using a Content Provider that will solve the performance problem, the problem is in the query.

  • I don’t understand, what’s wrong with the query?

  • The AP problem is "It takes time to load Recyclerview" that has to do with the fact that it is loading(query) 16,000 records at once. Switching to a Content Provider will not solve the problem by continuing to load (query) 16,000 records.

  • @ramaral his query has no problem. The problem is how he is using it. He’s loading all 16,000 records at once into an Arraylist and moving on to the Recyclerview Adapter. With Content Provider implemented, it could use a Cursorloader (which passes a URI to Contentprovider, so it is necessary) in place of a common Loader, with this, the Adapter would access a Cursor that will return from the BD only the data referring to the position of the list that is in display and no longer the 16 thousand data at once. Cursorloader also keeps Recycler up to date.

  • What you say is true and the solution is to use an Adapter that uses a Cursor. The use of Content Provider is optional. I think implementing a Content Provider just to fill a Listview is a bit of an exaggeration. But that’s a matter of opinion.

  • I already think otherwise, rs. My feeling is that Contentprovider / Cursorloader was created thinking of Listviews. For example, if the app base is updated by a Service in the background, you wouldn’t need to worry about any extra implementation in the UI if you already have a Cursorloader to manage Listview.

  • I have never said that there are no advantages to using Content Provider. See what the documantation says: (...)content providers are primarily intended for use by other applications, which access the provider using a provider’s client object.(...)

  • I know the documentation. I studied recently. I just said it was a feeling of mine.

  • Actually, I was referring to Cursorloader (which requires a Contentprovider), so I end up treating the 2 as one thing only as a solution to work with Listviews. This reply in the English OS gives a good explanation of the benefits of a Cursorloader: https://stackoverflow.com/questions/7182920/what-are-the-benefits-of-cursorloaders

Show 6 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.