1

Experiencing a strange phenomenon. My app is built around a vertical UIScrollView (i.e. "the feed") that is essentially an activity timeline much like Facebook's. When the user scrolls to the bottom, the feed can load older items in blocks of 20.

The first 0-20 items (default load) scroll fast and it continues to scroll fast when items 20-40 are added, but performance significantly degrades when items 40-60 are added and the app becomes essentially unusable when 60-80 are added.

What's extremely odd is the CPU usage during this entire scenario:

  • 20 feed items (default): CPU 65%
  • 40 feed items: CPU 40%, Thread 1 activity down about 25% (eyeballing)
  • 60 feed items: CPU 18%, Thread 1 down 50% from previous
  • 80 feed items: CPU 7%, Thread 1 down 50% from previous again

This is leading me to believe that the lack of performance is not the size of the scroll view but something else causing the CPU to disengage itself in some strange way. You'd expect CPU utilization to increase, not decrease.

I thought perhaps I was inadvertently adding the new feed items not on the main thread and somehow screwing it up, but that's not the case.

Any thoughts?

FYI (iPhone 5 running iOS8, app built with iOS 8 SDK, I don't think I was experiencing this when building with iOS 7 SDK running on iOS 7. Performance degraded, but, IIRC, predictably with UIScrollView size - I will attempt to confirm).

Update I just built and ran the app with both 7 SDK and 8 SDK on an iPhone 4S running iOS 7.0.6. It is not showing the same issue. ScrollView performance degrades more predictably and the CPU usage does not drop as the UIScrollView increases in size. Bug in iOS 8??

chickeneye
  • 43
  • 1
  • 4

2 Answers2

1

You should consider switching to a UITableView. They are designed to avoid this exact problem. When cells go off view, they get re-used for the cells that are now being used. This avoids allocating so many of them. This is why your contact list, iPod songs, facebook feed, etc don't degrade when the table grows bigger.

Rob
  • 1,025
  • 2
  • 10
  • 27
  • Hmm.. good point. Would be a pretty big refactor, but might be worth exploring. – chickeneye Sep 23 '14 at 21:10
  • I swapped this out with a subclassed UITableView instead of the UIScrollView. I was intercepting delegate messages for UIScrollView to have some special scrolling behavior and never considered that I could still intercept them using a UITableView as well. Performance problem fixed - though I still believe there is some strange behavior with UIScrollView in iOS 8. Thanks! – chickeneye Oct 16 '14 at 18:56
  • Yes. UITableView inherits from UIScrollView so you can do a lot of cool stuff with the scrolling. I've seen some issues with buttons inside UIScrollViews in iOS8, so you might be right. – Rob Oct 17 '14 at 19:02
1

I have run into same problem. Basically I developed with a scrollview with lots of subviews inside it, before iOS8 came out, it works perfectly smooth on iOS 7, but when I tested with new iOS8 device (with XCode5 as XCode6 is way bugger), the scrollview became very slow and less responsive comparing to iOS7.

Note I haven't changed any code, it is so bizzare. So I decide to give a demo try to see what's going on iOS7 and iOS8. It turns out it looks like iOS8 is using more memory than iOS7 does, even thought the code/asset is exactly the same. So performance degrades from iOS7 to iOS8, which theoretically performance should just get better on newer iOS.

For me, it seems like apple just kinda rush to release iOS8 but without ensure that everything is polished and well tested

Tuo
  • 209
  • 2
  • 4