As it's clear from the title, I have a scrolling performance issue in a table view.
Since I have read nearly every question that is posted online in this regard, and I assume all of you have much more experience with UITableView and its techniques, I won't bother with general stuff, and I just wanna point out some key things in my code that may help you help me spot where I'm doing wrong.
The UI in each cell is very very basic, so rendering each doesn't take considerable time. No shadows, no rounded corners, no extra effect, nothing. Just a few labels and two images, that's all.
The datasource is an NSArray which is already fetched from CoreData. The data of the labels are set from the content of the array, without much calculations or process required.
The height is each cell is a static integer, so the tableView:HeightForRowAtIndexPath: will immediately return the result as fast as possible. No calculations required.
The tableView:CellForRowAtIndexPath: dequeues and reuses cell with reusable identifiers so any re-creation is avoided.
So far everything is perfectly smooth. The issue is where items in Core Data are fetched from a server (Which is extremely fast) as user scrolls down. Data binding is done inside tableView:willDisplayCell:atIndexPath: to prevent tableView:CellForRowAtIndexPath: from becoming slow, as data needs to be loaded just before the cell goes live on the screen. I also fetch new items from server inside this method whenever there're some cells remaining till the last item fetched. So for example when there are totally 50 cells data fetched and put in the CoreData already and this method is called for cell number let's say 40, I request another 50 cell data from server, so that it will be ready whenever user reaches the end of the table.
As I expect this should only be called for the cells that go live on the screen. But putting some NSLogs shows that it is called multiple times until next 200 cells data are fetched (I guess the amount changes depending on device or simulator and the memory available on them and also OS limits). For example, I'm testing on an iPhone 7+, and I start the app and I go the page in which the table is. It fetches first 50 items and only first 4 items are shown on the screen, But I see that tableView:willDisplayCell:atIndexPath: is also called for cell #25, so another 50 is fetched immediately, and then it is called for cell #75, so another 50 is fetched, and this goes on for like first 200-300 cells, and then when fetching is stopped, scrolling is extremely fast and optimized until next 200-300 cells are fetched.
What can I do? Shouldn't tableView:willDisplayCell:atIndexPath: fire whenever a cell is about to be displayed? Where else should I fetch data as user scrolls?
Any ideas or suggestions is REALLY and GREATLY appreciated.
Related
I have thousands of sections in TableView,and I use titleForHeaderInsection to give each of them a title.But I find that when the TableView is initialized, this method will be called thousands times to give every sections a title. Is that means I should set several sections each time?
No, you don't have to.
A memory is optimised for such occasions, so if your data source is properly set and contains data regardless its size, UI should handle it safely.
UITableView in iOS app, for example, is rendering just those cells, that are displayed at current time. So for example the common tableview on the iPhone 6 is displaying about 15 rows at a time.
And as a user, when you are scrolling down (or up) the table view, each time before the certain cell is displayed, the method cellForRow is called and takes data from your data source.
This also works for sections.
But, if your data don't have to be stored in the App bundle, the best way would be to get source data asynchronously, so for example you get 30 rows from data from server, after launching the app. Then if you reach (by scrolling) 30th row, your app will request more data from server and updates the table.
So user, that won't scroll your tableView, will not download all data and will not use big data transfer.
As a conclusion I would mention, that for all situations, the smaller data source, the better for performance of your app.
Tableview works on concept of reusability so only few which are visible are created and after that rest all are reused so no need to bother about it .
Rest refer to this link : Apple official link : https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/TableView_iPhone/TableViewCells/TableViewCells.html
Go through life cycle of Uitableview datasource methods as each and every method will get called for each section and row. So it is completely fine if section method is called thousand times. If you have any issue for it then add a paging like load first 10 sections and then other 10 sections and go on.
Actually I want to show records in UITableView, total number of records may exceed 100 Thousand. So I am loading these records in chunks of 100 records every time when users reaches scrolling upto 70% records(row no.70).
I don't want to keep existing chunk of records in memory, So initially I am loading 2 chunks of 100 records, and when user scroll reaches to Row no.170, I remove first 100 records and loading 1 chunk of 100 records.
But my problem is how do I reset value of indexPath? as currently its value is 170, but after loading new chunk of 100 records and removing first 100 records, I want its value to be 70.
I have found workaround to above problem by using following line of code.
[tableView scrollToRowAtIndexPath:[NSIndexPath indexPathForRow:70 inSection:indexPath.section] atScrollPosition:UITableViewScrollPositionBottom animated:NO];
But above line of code stops scroll suddenly. So it appears like scroll is stopped suddenly at Row no.70.
Is there any other solution to implement above problem, Thanks in advance.
Why not allow the user to access the data in some other way, such as:
Search functionality
Subcategorisation of data
It's perhaps worth asking, since it's such a large amount of data, is it really likely your user will scroll that far down, and if they have to, will it impact user experience negatively?
For arguments sake, if you wanted to protect your memory use, you would have to dynamically add and remove cells depending on offset. The standard UITableview methods do a pretty good job of doing that for you.
In any case, the number of cells you have allocated at any one time should take into consideration what you are putting into your cells, e.g. images vs. text. If it's images, then 100k is going to lead to a massive application bundle (unless you pull them from your server as needed). If it's text, just go with Apple's own UITableView methods, as they will be more efficient.
But if you're adamant about this approach, and wanted to roll your own custom fix, you could layout a load of UIViews in a UIScrollView, and use the contentOffset of the UIScrollView to know when to add and remove cells. The actual adding of the cells should be done off-screen.
A. In scrollViewDidScroll, watch for specific offsets aligned with cellHeights, e.g.
if(fabsf(y)%200==0){
//add new cells below, drop old cells at the top
}
as in, if your cells were 50px in height, it would hit this method every 4 cells.
B. Update your dynamic indexPath each time new cells are added / old ones are removed. It would be the indexPath of the uppermost cell. Based on that, you can calculate the number of cells currently 'allocated' and the points at which you should pull your cell data from an array:
for (int n = dynamicIndexPath; n<dynamicIndexPath+numberOfCells; n++){
//this is the window onto your data.
}
When adding e.g. 4 new cells:
for (int n = dynamicIndexPath + numberOfCells-4; n<4; n++){
//[self layoutNewCellWithData:massiveArray[n] atOffset:y];
}
This would be a sort of homegrown UITableview (UIViews in a UIScrollView) where you handle the dequeuing yourself.
But, if it were me, I would look at an alternative way to attack the data, such as via search or some way of splitting the data up into smaller groups. Failing that I would use Apple's UITableView methods, failing that roll my own.
All,
I hope most of you know that with ios7 there is not need to do a null check for tableview reuse
if (cell == nil) {
But unfortunately, because of that the cells are always reinitialized, as we put the code in the same method for initializing values. The problem is only with text fields inside the tableview though.
Let me explain the scenario. I have a table view with multiple rows, and some rows contain multiple text boxes. I populate the textboxes with data from server when the page is loaded. Since the cells are always re-initialized as i explained above, whatever I enter in the field goes away and the server data is re populated once i scroll down and come back to the initial stage. This is because the populating the data code is also in the same place. After fetching a reusable cell it populates the data.
Previously till ios6, we used if(cell==nil) and hence we loaded server data inside the cell and when reusing the cell, this piece of code will never be called.
I have other dirty solutions, but would like to know if someone else has a graceful way of dealing this. Please help.
You just don't store any data in the table view cell but in the model that fills the table cell. This is always the way it should be done.
Looking from the MVC standpoint than the UITableViewCell is a view. Since it is reused by iOS you should use a model to the view.
Yes, this is the expected behavior of UITableView. For performance reasons, cells are reused. Thus, it is your responsibility to populate the views in a Table View Cell every time tableView:cellForRowAtIndexPath: is called.
The thing I don't understand from your question - are you making a network call every single time a cell comes into view? If so, cache the results somewhere. Or, if it's a small amount of data, consider just doing it all in one shot at the beginning (still need to be asynchronous though).
One thing I see a lot of developers do is move a lot of code into UITableViewCell subclasses, which sounds like a good idea because it's modular, but makes solutions for problems like this more difficult. Have the Table View Data Source manage the network calls.
If you need some inspiration, look at Apple's LazyTableImages sample.
Right now my table view presents 5 cells at the same time. I load them all up into an array so the "flow" of the UITableView is easier. But since there quite a few objects, the initial load can take quite a bit.
So my question is, is there a way to present the initial 5-7 cells while the rest are loading? Or what would be the practice for this?
The idea: for the first few cells to come up as fast possible, even while we are loading a bunch in the background so the user isn't sitting there waiting for 100+ cells to load.
Also, I am loading this cells with parse (I am getting the user's info including an image).
Thanks!
This may not work depending on where your data comes from and when it gets into your app, but this is what I would do. Allow your array to fill up with the first 5-7 items. Then call reloadData on your table view. Assuming your datasource is hooked up to your array properly, it will load the first few items. Then let your array continue to load until it's complete, and call reloadData again. You could even use this strategy repetitively to continually load new data. Good luck!
I have a UITableView that collects data from a database. What I would like to know is if there is some way I can iterate in the UITableView collection and check the values of the cell? The reason I ask is because I would like to update each cell based on the current value that it has (change font, size, color, etc.). I've seen in another SO post regarding this topic, but since the cells are already created and their values are changed it is a bit harder for me. I was thinking of iterating through the UITableView before I call reloadData, but any other suggestions are welcome.
You should not iterate over the cells of UITableView, because some of them (in fact, most of them) may not be present until you request them. UITableView aggressively recycles its cells, so if a cell is not visible, it is very likely that you would be creating it from scratch only to put it back into recycle queue moments later.
Changing your model and calling reloadData the way your post suggests would be the right solution. iOS will ensure that it runs the update in a smallest number of CPU cycles possible, so you do not need to worry about the cells that are already created. This is also the easiest approach in terms of your coding effort.
A table view is for displaying data. The properties of your table cells should only be written to, not read from. The appropriate way of handling this situation would be to update your underlying model objects -- the objects that you use to populate the table view -- as the data changes, and then reload the affected rows.
The issue you'll encounter is that UITableView reuses table cells. Once a table cell scrolls off the screen, it's quite likely that the table view will reuse the same cell to display a different row.
This means it's fundamentally not possible to iterate over the table cells. When you need to refresh a row because its data has changed, you should call reloadRowsAtIndexPaths:withRowAnimation: (or reloadData if all rows have changed) and if the row is visible on screen, UITableView will call your data source methods and give you an opportunity to configure the cell for display.