I have a scrolling grid of photos that looks and functions pretty much exactly like the photo picker on the iPhone. It is constructed from a UITableView that uses a custom UITableViewCell which displays a row of photos (very similar to how Three20 implements it).
It works great except that scrolling performance is poor. I'm already following most of the best practices for fast UITableView scrolling (à la Tweetie).
The images are all bundled with the app. I load them on the UI thread, on demand. I use UIImage's imageNamed: so that the images will be cached after they're first loaded. Once I've scrolled through the table view once, it scrolls very smoothly.
The problem is, the first time scrolling through the table view, scrolling is jittery. I've profiled the app and found that the majority of the time is spent loading the images from the file system. They are JPEG images, already sized correctly (small). I tried using PNG images instead, but performance doesn't improve very much.
The iPhone photo picker exhibits much better loading performance. I'm wondering if combining all the photos into a single image, which I load once and then split into smaller images would be faster. It certainly works in games, but I know that's really a totally different story. Has anyone had experience doing that?
Any other ideas for how I can improve performance?
Incidentally, I'm having a similar, albeit less, performance problem for another UITableView that just uses standard UITableViewCells with one image assigned to the imageView per row.
One thing to try could be pre-caching all the images when the view loads. Beyond that, perhaps loading the images in the background (even though it's loading from the filesystem and not the web). I haven't tried this myself, but perhaps you could use something like https://github.com/rs/SDWebImage and have the URLs point to the filesystem. Users might see some placeholder images at first, but then the UI wouldn't stutter while images are loading.
Setting the PagingEnabled property to off improves the scrolling performance.
I had a similar issue using a UITableView to display information parsed from an RSS Feed. I ran into scrolling performance issues when there was a significant amount of data. Though I'm still working on it I suspend the parsing when the table is being scrolled. It resumes when scrolling stops. I am not at my computer, but I believe I used tableViewDidScroll and tableViewDidEndDecelerating. You can check these tableview delegates. In any case it works very well, I just need a more elegant way to pause my parsing.
Fantastic. That does work like a charm! So efficiently I ended up using insertRowAtIndexPath rather that reloading the table. Now it behaves the way it
Thanks so much!
Joe
Related
I have several local html files and I want to show them in a table with static(for now) cells.
Each UIWebView would have a different height (I dont want to have any scrolls in the UIWebView) so obviously each cell has a different height. Most of the comments i read discourage the usage of UIWebView in table cells. What do you think : is this applicable ? will it be slow and need time to load?
UIWebview in tableview cells will affect the performance for sure. To display Html content in tableview cells you can use NSAttributedString.
I used a UIWebView in an app to display content coming from the web as rows in a table view.
I know that doing that is discouraged, due to the high memory use of UIWebView, but in my case it was not only a matter of displaying rich text: I had to display HTML loaded from the web, so I give that option a try. In short, I tried it and it worked fine.
The app got memory warnings from time to time, but it was also able to recover memory effectively and run unaffected even on an ipod touch (just 256MB of memory). Performance was possibly affected, but due to the fact that the app was doing just that (loading text from the web and displaying it in the table), the app was perfectly responsive.
One important notice: pages were pretty simple, just text, and each table did not contain more than 15 elements. Furthermore, one thing you have to consider is that the UIWebView introduces a small delay in the rendering, so you will have to deal with it and accept it in your app (there is no way to get rid of it that I know of).
In a later project, I used a different approach: using just one UIWebView and creating the table using HTML/js inside of it. Well, it also worked, but I could not see any big improvement as to peak memory usage nor performance (I checked with instruments).
This is just my experience, I am not trying to say that this will work or that is good practice to do. In any case, I hope it helps.
I know this is kind of a vague question, but does anyone know how to get rid of choppy scrolling on a tableview?
Thanks
I suggest reading up on the subject but a few main things are:
Don't do heavy calculations in your GetCell function (it is calculated several times per second as each row appears.
Make sure as many elements in the cell are "opaque" as possible. Read about red/green transparency checking with instruments / simulator. Transparent areas require compositing which causes a performance hit with the hardware (especially on iPhone/3G).
Make sure you are using a constant cell identifier so dequeueReusableCellWithIdentifier isn't creating a new cell every time one is needed.
Have you tried Apple's suggestions for Cells and Table-View Performance yet?
You might also want to look at the TableViewSuite sample code for different techniques for creating fast scrolling table views.
Try Atebit's fast scrolling table cells:
http://news.atebits.com/post/197580827/fast-scrolling-in-tweetie-with-uitableview
The idea is that instead of a deep hierarchy of subviews you draw everything flat to the content view so that rendering doesn't have to composite lots of transparency.
Another possible problem may be background web calls - if you are using asynchronous calls to servers, try moving them into background threads. That can really improve UI performance.
So I've seen this question asked before and in fact I asked it last night but I thought I'd give it another go just to see if I could get any other unique views on the problem.
The Problem — I have an app with a large number of uiimageviews (with image downloaded to disk) in a scrollview which of course has two large problems facing it: Memory use, and performance. In my app memory use isn't so much a problem because I am employing techniques such as dequeuing and reusing imageviews and such. But performance is another thing entirely. Right now, as a memory saving procedure, I only store image filepaths in memory because it would be ridiculous to store images in memory. But the problem with this is that reading from the disk takes more time than from memory and slows down scrolling on the scrollview immensely.
So, what kind of techniques do any of you suggest for something like this? I've seen three20 but don't want to use it because I need high customizability in my view and that just won't do. Image files are not large, but just thumbnail size so there is no scaling or excess size. There's got to be an intuitive way to handle this. The built in photos app handles up to thousands of photos perfectly with low memory and slick and smooth scrolling performance.
Fundamentally, the problem is that you're probably doing a bunch of disk I/O on your UI thread, which is basically guaranteed to cause performance problems.
You should consider loading your images on a background thread and updating the image views on the main thread when the images are loaded. Depending on your use case you can get more or less clever about how far you preload in advance, etc, so you can have images ready. (There might be some usable source code or even Apple sample code out there that does something like this, but I don't know of it off the top of my head.)
You may notice that some applications (not sure about the Photos app) have an intermediate stage where they load a very small thumb size image for all images, and scale it up to the render size, which acts as a placeholder until the full size version is loaded-- if the user scrolls past that image before the full size is loaded, the visible effect is nearly the same as if the image was there all along.
In my application I use lots of images based in interface builder. The problem with this is that it uses large amounts of memory because interface builder caches it much liked "imageNamed" so I've begun removing the image from imageViews in interface builder and instead adding them once the view starts using "imageWithContentsOfFile". After several hours I have made little progress because I have literally hundreds of images. I'm just wondering if there is a more straightforward way to do this?
Yes, don't do it. UIImage and the whole xib business pretty much delay loading until things are needed, as well as drop cached images where possible and needed. You can even see this happening in Instruments. It helps to split your design over several xibs, so they can be loaded when needed.
What you can do however, is to make sure that you don't scale images but display them 1:1, and that you save them in the lowest acceptable quality. For photo's, take JPEG. For other images, take PNG.
I have around 20 tableview cells that each contain a number (2-5) thumbnail sized pictures (they are VERY small Facebook profile pictures, ex. http://profile.ak.fbcdn.net/hprofile-ak-sf2p/hs254.snc3/23133_201668_2989_q.jpg). Each picture is an UIImageView added to the cell's contentview.
Scrolling performance is poor, and measuring the draw time I've found the UIImage rendering is the bottleneck.
I've researched/thought of some solutions but as I am new to iphone development I am not sure which strategy to pursue:
preload all the images and retrieve
them from disk instead of URL when
drawing cells (I'm not sure if cell
drawing will still be slow, so I want
to hold off on the time investment
here)
Have the cells display a placeholder
image from disk, while the picture is
asynchronously loaded (this seems to
be the best solution, but I'm
currently not sure exactly how to do
best do this)
There's the fast drawing
recommendation from Tweetie, but I
don't know that will have much affect
if it turns out my overhead is in network loading
(http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/)
Thoughts/implementation advice? Thanks!
Suggest you do a search in the XCode help docs for LazyTableImages. It's a sample app provided by Apple that asynchronously loads images into a table cell. It should be a good starting point.
You'll probably want to add a local cache to save the images so you don't have to keep downloading them each time, and a way to prune out old images out of the cache.