This video demonstrates the issue I am having
UITableView screen lag
I am loading a xib file with a fair bit of stackView and UIViews into my tableview cell. Each cell takes up about 80% of the screen so you would see two cells at max.
I am experiencing a small lag when I am scrolling to the third cell. If I scroll back up again and scroll down like what I did, the lag does not appear to be there anymore and the tableView scrolls smoothly for the remaining cell. If I reload the table and repeat the above step, I will get that lag again when third cell is just about to appear.
It "feels" like the program takes longer to load the xib file in cellForRowAtIndexPath for the very first time. And once it is loaded, it could be loaded nice and fast for any other cell. (That is just a feel though)
All my views have static data. I am finding that this small lag decrease as I removed more view from the xib file.
Is this pattern normal?
Note. In the video when I pull to refresh, the table is reloaded. I have reloaded the table just before the video starts. You will see that at the beginning and whenever third cell is just about to appear (or half way through scrolling second cell) there is a small jump in the table. And after that, everything scrolls butter smooth.
Xib file
XibFile screen shot
Related
I have custom UICollectionViewCell in xib. When ViewController is loaded - awakeFromNib() in cell subclass called 6 times (the screen initially placed 6 cells, ok), BUT when i start to scroll, awakeFromNib() is called six times more, causing lag. But after this "re-load" scrolling begins to work smoothly. This happens only the first time at scroll start. dequeueReusableCell, obviously, is used.With UITableView instead collection the situation is similar.
Feel like the next 6 cells are loaded from the xib again (in the collection of just 100+ cells), ignoring reuse. What could be the problem?
For clarity:
UIColectionView with Vertical scroll direction, two cells in line. When ViewController loaded i see 6 cells on screen and 6 awakeFromNib calls in console.
I start scroll down to 7-8 cells, before their appearance on the screen i see lag and 2 calls of awakeFromNib method.
Similarly for the following two pairs of cells.
After this scroll begins work fine, until cells 99-100+, and awakeFromNib is never invoked.
Added:
OK, here's what I found out:
I have a subView inside a collectionView (header like in UITableView), and, accordingly, collectionViewLayout set sectionInsets top = height of header. If I remove the header, and make the top insets, for example: -180 (about excluding the height of NavigationBar, so the screen initially fit 12 cells and the scroll lag is gone.
Ie, the system needs to load from the xib at all the cells that will be one-time visible on the screen and reuse them in future. (But why not one time load xib and reuse it immediately for all other initially cells?)
And now the question - how to fix it?
Added.2
Working solution - add header in viewDidAppear method of ViewController, but this... hm.. not good.
This is actually a known side effect (or purposeful design?) of UICollectionView & UITableView. Here's a related question (talking about NSTableView, but the concepts/issues are the same):
awakeFromNib method called multiple times
Your collection view initially displays six cells to start with, but it sounds like iOS is allocating six more cells to allow for scrolling left & right. So there are at least 12 (reuseable) cells in memory.
If you're doing a lot of work in awakeFromNib (which is what's contributing to the lag), you might want to try to determine how to optimize things.
You can also find some additional helpful hints in this related question:
UITableViewCell - Best place to set up the cell
I'm working on developing a newsfeed where most cells have different heights from each other. So I'm using Apple's new built-in system to calculate the height of the rows dynamically in iOS8.
The problem happens when I have to load a new page. When I do that, then scroll back towards the top, the content size of the table appears to be smaller than it should and the loading of the cells is really choppy. So when I start scrolling upwards, I'll be at the 5th cell and then all of the sudden the 4th cell will jump down. I attached the project if you guys want to see my code: https://github.com/KhanFu/TableView-Dynamic-Cell-Height-Pagination
If you keep an eye when you're scrolling the table view, you'll see it jumps upwards. To re-create the bug, first scroll all the way to the bottom, so it loads the next page (11, 12, and 13). Then start scrolling upwards. For the clearest version of this, keep your eye on the number 7. Watch how it almost instantaneously becomes 6.
Essentially, when the content offset of the table reaches the bottom of the table, I adds an object to the table's data, then I add a row with insertRowsAtIndexPaths.
I've been banging my head against this problem for awhile now. Let me know if you need more information. Thanks!
I'm trying to set up a particularly large UICollectionView, and I'm embedding it within a UIScrollView (as per this answer to another question on SO) in order to support scrolling in both directions. I've got it up and running, everything is working perfectly, except that performance takes a HUGE hit as the size of the CollectionView grows.
After some hunting around, I was able to figure out the problem: because that SO answer calls for the CollectionView to be resized so that all the cells are visible at once, "dequeuing" isn't a thing anymore. The CollectionView within the ScrollView has dimensions of 2000x2000 (or whatever), so even though the ScrollView is just the size of the screen and only shows 20 cells or so at a time, the CollectionView thinks all cells are visible and needed right now. Thus, every cell in the CollectionView is generated at once, meaning the page takes a ludicrously long time to appear.
Is there a way to communicate to the CollectionView which cells are currently visible through the ScrollView, so it doesn't generate unnecessary cells and dequeues them as normal? Or if not, is there a way to make a CollectionView that scrolls diagonally, but that doesn't have this problem?
Context:
Building an app that populates a table that takes in data from a asyc json dump.
The cells are of a custom class (I defined). The main label in the cell can be very long.
It is "placed" in storyboard within a prototype cell but customized via code (pretty standard stuff).
Labels are resized in cellForRowAtIndexPath and rows are resized via heightForRowAtIndexPath -- rows are resized by forcing a call to cellForRowAtIndex like Massimo's answer here
So per the question at hand - I've noticed some interesting (bad) things that happen.
First issue: When the table loads, the rows and labels are dynamically resized correctly! Great! However, when I scroll down and then scroll back up, the label heights will be incorrect -- (for example) the first row was correct at loading. Then when I scroll down and then scroll back up to see it again, it will be truncated. Specifically, the row size will be fine but the label height will change and become truncated to 2 lines only. Wondering if this is because I did both storyboard and coding to customize the cell. Anybody see this before?
Second issue: When I scroll down, while the rows are sized correctly (large), the labels are short (truncated.) Wondering if it's some reverse of the above "potential answer".
"potential answer" is that the rows are all calculated and stored "up front" so that scrolling down/then back up doesn't affect it. However, when cells go "out of view" and are dequeued then when they re-viewed (scroll down/then back up) it will rely on the storyboard.(inappropriately?)
All three of your issues are symptomatic of returning the wrong height in heightForRowAtIndexPath. In my data model classes I have a calculateHeight method that I call in heightForRowAtIndexPath. The model also caches the answer so it doesn't have to recalculate it after the first call. The cell class uses the model's calculated height to layout its subviews.
"ANSWERED" by deleting the prototype cell from the storyboard and making them fully in code, the issue went away. The fundamental workings are still not understood (ie. the interactions between storyboard vs. code when cells are put queued and then viewed again)
There are about 100 cells displayed in UITableView. So , when I scroll down or up too fast I see a flicker effect over UITableView.
I have also re-used the cells and I am not using reloadData in my code, but still I see flicker effect.
The content that I am displaying in each cell is only text.
I have also gone through this thread but did not found useful UITableView section headers are blank and flickering.
I think with a number of cells I noticed my old iphone 3g struggle every now and then when i was flicking for a quick scroll to the bottom.