I'm using core-plot in my iPhone app to display datas in plots from NSMutableArrays.
I display 10 values on the screen and I allowed horizontal scroll only like that I can see all the values when I'm scrolling.
I've got something like 100-200 values in total to load.
I use differents tabBars to handle my differents needs.
Everything works fine, but when I launch my app on the iPhone I have some monstrous laggs when scrolling. Something like 2 seconds after the graph move (on the simulator there is no laggs).
I reload graph when I shake the iPhone.
I work on a 3GS, and there is no other app running in background.
Did someone had and resolved something like that?
Do you need more info?
UITable (and UIScrollView) has a bug in which it causes it to call layoutSubviews on its parent. Check to make sure this isn't causing your trouble. If it is, you may be able to solve it by wrapping the table in another UIView. I do this routinely to avoid this problem.
Another thing that can cause really slow scrolling is a lot of masks, transparencies, etc in your cells. For this, you might try setting the views to rasterize, which means they'll draw themselves once into a buffer, rather than draw themselves every time.
Related
I have a UIView in which I display a movie if a particular chapter demands it. This view is resized via constraints in Main.storyboard to adapt to iPhone. All works fine on iPad. It also works fine on iPhone unless the app is asked to reload when a movie containing chapter was last active meaning that a movie will be first-up on loading. In this scenario, the movie is loaded into the iPad dimensions instead of the smaller iPhone specs.
It appears that the constraints on the movie's view are not engaged in a timely manner. The issue centers on a query of the the view's bounds. If I insert a delay before using the bounds the issue goes away. In fact, a delay of 0.0 seconds does the job!
Using a kludge that relies on a delay seems pretty funky to me. I can also move the call that uses the bounds to viewDidLoad to resolve the issue but then I see some underlying “garbage” when reloading the app, the launch image seemingly not in effect. Any suggestions?
It sounds like you're using bounds before your views have been lain out. Without actually seeing your code, I would suggest executing your described code inside of viewDidLayoutSubViews().
I have a NavigationController that stacks UIViewcontrollers that have UITableView among other UI elmeents. The tables I use are actually custom tables that use custom cell views. With this arrangement those tables don't show scrollbars of any kind even though I have configured in IB the Shows Vertical Scrollers to show them.
I've tried several ways of debugging this without success. If I print to console the value of this property (showsVerticalScrollers), it prints 1, so the property is properly set, and no, my table is not wider than its parent view, actually it's way more narrow than its parent view.
Are there reasons why a table won't show it's scrolls?... btw, this happens in iOS5 running in simulator. I'm using xcode 4.2 with SLeopard. I don't have access to an iPad to test it in the hardware but other tables I have in the same project, show their scroll bars without a problem.
EDIT
thanks for the answer... I did one last test and found that one of the causes for not showing a scrollbar is the number of elements shown in the table, when they fit in it without the need to actually scroll. Say if you have a table with 1 row and the vertical size of the table is too big for just one row?, then iOS won't show the scrollbar when bouncing.
It's hard to provide a possible solution without seeing any code, but the advice I can offer is to update your code to the bare minimum needed code to implement a UITableView and see if scrolling works, if it does, add in functionality in small increments, testing the scrolling with each new code addition till you reach the point that scrolling breaks. Incremental testing in this fashion helps to avoid issues like this where you are unable to effectively debug your application.
I released the first beta version of my iPhone app on TestFlightApp today. Everything is going really well until I notice that the responsiveness of the application is pretty cruddy. Certainly doesn't have a "nice" native feel that I'm going for.
I've been particularly fastidious concerning my memory allocation/deallocation, so I don't think this is the issue. Basically, I don't know where to turn to next in order to improve the performance of my app.
Here's where I think some of my slowdown can be attributed to:
Using UIAppearance to customize the looks of most (if not all) UI elements. I use a brand new font, lots of CAGradientLayers, and lots of edits to CALayer in order to draw nice Shadows.
Grouped UITableViewCells that display pictures of a map and itemized lists.
UITableViewCells whose layouts are updated every time I call layoutSubviews.
UITableViewCells with customized heights. For each call of heightForRowAtIndexPath, I need to reconstruct and re-layout the view, returning the exact height each time.
Because I programmatically created views, controllers with longer viewDidLoad calls tend to load slower. What code can I offset in the init call?
Does anyone have any hints or tips for dealing with these problems? Or perhaps people have stories about how they dealt with a slowdown in performance when they released their first app?
My answer won't address all of your points, but here are a couple:
1) Make sure you are using Shadow Paths. Paths are much, much more performant.
2) Are you using transparency or corner rounding? If so, try and reduce transparency as much as possible and do not round corners using CALayer cornerRadius. Instead, use a clipping mask in the drawRect of the view that needs to be rounded.
4) Perhaps you can cache the height in an array and not have to repeat the calculation, each and every time. This may/may not scale well depending on the potential number of items, but may be acceptable depending on the use case.
5) Are there views you can reuse? For example, when I have a custom selection view on a UITableViewCell, I only create a single instance held by the controller and reference it in all the cells.
Did you run Instruments (or other profiling methodology) to determine where you app is spending most of it's time. It would be a good idea to do this before optimizing the wrong thing.
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
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.