I have done significant research on the performance of UICollectionView. The conclusion is simple. Performance is poor for a large number of cells.
EDIT: Sorry, just re-read the message, the number of cells you should have in order (see the rest of my comment), so there may also be a problem with cell complexity.
If your design supports it, check:
Each cell is opaque.
Cell content clips are limited.
Cell coordinate positions do not contain fractional values (for example, they are always calculated as whole pixels)
Try to avoid overlapping cells.
Try to avoid shadows.
The reason for this is actually quite simple. Many people do not understand this, but it is worth understanding: UIScrollViews do not use Core Animation to scroll. My naive belief was that they used some kind of secret scrolling animation "sauce" and simply requested periodic updates from delegates from time to time to check the status. But in fact, scroll views are objects that do not use any drawing behavior at all. All that they actually are is a class that uses a mathematical function that abstracts the placement of the UIViews coordinates that they contain, so the Views coordinates are considered relative to the abstract plane of the contentView, and not relative to the origin of the containing view. In the scroll mode, the position of the abstract scroll plane will be updated in accordance with user input (for example, scrolling) and, of course, there is a physics algorithm that gives an “impulse” to the translated coordinates.
Now, if you created your own collection layout object, you could theoretically create one that 100% changes the mathematical translation used by the basic scrollview. It would be interesting, but useless, because then it would seem that the cells do not move at all when you sit down. But I raise this opportunity because it illustrates that a collection layout object working with a collection view object performs a very similar operation with a basic scrollview. For example. it simply provides the opportunity to apply an additional mathematical frame for the personnel translation of the attributes of the displayed representations, and basically it will just be a translation of the position attributes.
Only when new cells are inserted or deleted, moved, or reloaded does CoreAnimation participate at all; most often, causing:
- (void)performBatchUpdates:(void (^)(void))updates completion:(void (^)(BOOL finished))completion
UICollectionView requests a cell layout. Attributes for each scroll frame and each visible view is laid out for each frame. UIView are rich objects optimized for more flexibility than performance. Each time it is laid out, there are a number of tests that the system checks for alpha, zIndex, subViews, clipping attributes, etc. The list is long. These checks and any resulting changes in the view are maintained for each collection view item for each frame.
To ensure good performance, all HR operations must be completed within 17 ms. [It just won’t happen with the number of cells that you have] enclosed this item in brackets because I re-read your post and I understand that I misunderstood it. With the number of cells, there should be no performance issues. I personally found with a simplified test with vanilla cells containing only one cached image, the limit tested on iPad 3 is about 784 screen cells before performance starts to drop below 50 frames per second.
In practice, you will need less than that.
Personally, I use my own custom layout object and need better performance than the UICollectionView provides. Unfortunately, I did not miss the simple test above until I reached the development path, and I realized that there were performance problems. I'm so going to recycle the open source reverse port UICollectionView, PSTCollectionView. I think there is a workaround that can be implemented like this, just for general scrolling, each layer of a cell element is written using an operation that bypasses the layout of each cell of a UIView. This will work for me, since I have my own layout object, and I know when a layout is required, and I have a neat trick that will allow the PSTCollectionView to return to normal operation at this time. I checked the call sequence and it does not seem too complicated and does not seem absolutely impossible. But surely this is not trivial, and some additional tests must be performed before I can confirm that it will work.