I am optimizing a transition that seems to be slow on my device. I am pushing one UIViewController from another when a UITableView's row is selected. There is a noticeable pause after row selection and before the new view is pushed.
Some logging indicates that all of my code is reasonably quick, from row selection until the pushed controller's viewWillAppear. But then the time between viewWillAppear and viewDidAppear is logged at around 0.7 seconds.
The transition itself (I believe) should only take 0.3 seconds. What could be accounting for the remainder?
I am testing on an iPhone 4, so I'm not expecting the snappiest performance. But I should be able to match the same performance of other similar apps on the same device, no?
I had a similar question a few weeks ago, and I wrote a blog post about what I found:
http://bradbambara.wordpress.com/2014/07/31/object-life-cycle-uiviewcontroller/
The TL;DR version is that iOS will:
perform the layout of your new scene
perform the transition to your new scene (if it's an animated transition)
...so my guess is the delay could be caused by an especially long transition, or if you're doing any performance-intensive work in your layout code.
The transition itself (I believe) should only take 0.3 seconds. What could be accounting for the remainder?
Resources are usually consumed in the following methods: drawRect:, layoutSubviews, viewDidLoad, viewWillAppear:. Also, loading from NIB may require quite much time.
After viewWillAppear:, iOS will make a snapshot of the new (and probably current) view to perform smooth animation between two screens. So make sure that drawing and layout code for both controller views is fast enough.
Related
This question seems to get asked a lot but I have never found a definitive answer as to whether or not it's possible to have custom transitions the same way UIKit does.
I know you can do tricks like take a screenshot of the current view and the upcoming view, and then animate those while you change view controllers under the animation. However, this takes quite a bit of memory, as you have basically 2 full extra screens worth of drawing (because of the screenshots).
I'm looking for a more elegant way of presenting view controllers with a custom animation. Or, is there a more memory-efficient way of doing the above approach?
There are several ways to accomplish this, depending on how you want to transition, whether your controllers are embedded in a container controller, etc. In the simplest case, where you have a single controller, and you want to transition to another controller, you can do it with the following steps:
instantiate the new controller (lets call it B, and the original one A)
add B's view as a subview of the window (gotten from self.view.window)
set B's frame to be off screen in which ever direction you want or make its alpha 0, or make it have zero size, depending on what kind of transition you want.
do what ever transition you want with animateWithDuration:animations:completion:
remove A's view (in the completion block)
in the completion block, make B the root view controller of the window
Essentially you're having the system automatically retain and release, along with do whatever is happening below the calls rdelmar's answer outlined. Transitioning a view controller is just animating a view while having the system keep your controller in memory.
But, to answer more of your questions, UIView animations create duplicates and cache the images, too. (Btw, the system cache doesn't unload its memory, so avoid UIImage imageNamed.
You will probably want to code it yourself using a timer if you want efficiency, and drum up all the graphics tricks you can think of.
And never, ever trust iOS to work the same way it did the last version. Everything I said is subject to being wrong the same way iOS 6 broke retain on annotating, and the manuals stated iOS 3 animations will become obsolete (and are now replaced instead?) gah, just saying be careful with efficiency, it may be broken or updated in the somewhat distant future if you try it.
I'm using a UIScrollView to display a custom UIView. When the user drags a finger across the UIScrollView, there is a noticeable delay before the display begins updating. If the user keeps touching the screen, the UIScrollView becomes very responsive after a short time. Subsequent attempts to scroll result in the same initial delay, followed by high responsiveness. This delay seriously affects the usability of the view and I would like to get rid of it.
In a test project I have written to try to get to the bottom of this issue, I have only been able to partially replicate the behaviour. The first time that the user scrolls is exactly the same - however any subsequent attempts to scroll are responsive straight away.
I have tried both setting delaysContentTouches = NO and subclassing UIScrollView so that touchesShouldBegin returns NO as suggested in multiple places online, but neither has worked.
I'm using MonoTouch on iOS 4.3, but Objective-C answers are fine. I would post code to help illustrate the issue, but since I have been unable to narrow down the problem this would be well over 1000 lines. Hopefully this is enough info to get a solution.
Does anyone know what might be causing this delay, and how I can get rid of it?
Some general suggestions for improving scrolling performance.
Have your scrolling views rasterize offscreen:
myView.layer.shouldRasterize = YES;
Set that property for each sub-view on the scrollview - do not set it for the children of those sub-views or you just eat up memory that way.
If your scrolling views do not need compositing, make sure you turn that blending off:
myView.opaque = YES;
Test using the simulator by leveraging these two features that appear on the Debug menu of the iOS Simulator:
Color Off-screen Rendered
Color Blended Layers
If that doesn't address your problem, and you have implemented UIScrollViewDelegate, double-check to make sure you are not doing anything time consuming in those methods - for example, based on your description, you might be doing something in scrollViewDidScroll, scrollViewWillBeginDragging, or scrollViewWillBeginZooming and if you are, optimize that so it happens before scrolling even begins. Also, make sure you're not doing anything in touchesBegan.
I suspect what is happening is there is some kind of interaction enabled in the content of your scroll view.
The system does not know if the initial touch down is going to be a tap on one of the subviews or a drag on the scroll view, therefore is causing a delay while it waits to see if you are going to lift your finger.
What are the subviews of the UIScroll view?
As an experiment set all the subviews of the UIScrollView to have userInteractionEnabled = NO, this will not be what you want, but its just a test. Is should scroll fine after this, otherwise I am wrong.
I am working on an App built with Xcode 4.1 and linked against iOS 4.0. Today I have started testing on iOS5 to get it ready by the time the new OS launches.
We have an interesting issue where almost every UIView subclass animates when they are redrawn. The views returned as section headers of a table view are animated every time the user scrolls for instance. But practically almost any UIView update is animated. The effect on the screen is very disorienting.
I can't find anything on this issue. But I must be missing out on some big changes or doing something very wrong.
Anybody experiencing similar issues?
Based on what I've seen of iOS 5 this isn't normal behavior.
It sounds like you are wrapping some call to that TableView inside of a UIView animation block, so any call the UITableView makes (Such as LayoutSubviews) is also in that animation block. Another possibility is that you forgot to properly commit an animation, so all UIView changes past that are also included.
There have been some changes to UIView animations and the way they are run. Just anecdotally, I've had some trouble with Animations that used to run sequentially running on top of each other. So, maybe this is a bug in your code that was just never noticeable before.
I'm looking for advice about a nib that's very slow to load. It's big and complex, with lots of subviews and doodads. When I fire my UINavController to push it, it's noticeably laggy (maybe almost a second) on my 3G. It sits there with the table cell selected and nothing else happening for long enough to make you wonder if it's broken.
I wonder about pre-loading it in another thread while the user is on the previous view. I could probably fire the selector in the background with a delay in the previous view's viewDidAppear, and then keep it in a property until push time comes.
Thoughts?
Can you split the subviews and doodads into their own, smaller nibs? Then you don't have to load everything at the same time, just what you need for when you need it.
I am working on a project, which is so full of the same, it would be unusable in NIB form. I choose to start creating my own sub-views in code, and then in performance concern areas, did my own drawing (like you would in a complex/custom UITableViewCell implementation).
It isn't really that hard to create some or all of your elements in code, or roll areas of them up to something that can be drawn by hand.
Just a thought.
I would be careful about assuming that it is the loading of the NIB file which is slowing you down. Run Instruments and / or Shark against your application, focusing on sampling what happens when you tap on the table to bring up your new view. You might be surprised at where the bottleneck is. In particular, it might not be loading the NIB itself, but something in the initialization methods of one or more of the subviews.
I have an iPhone app that displays a modal view controller. The modal view controller shows two instances of a custom subclass of UITextView called RoundedTextView, an MKMapView, and a UIToolbar. I construct the viewController only once, and reset its data and present it each time the user summons it.
When showing this view controller with presentModalViewController, I noticed that the animation to show the view was choppy on the 3G. So, to speed it up, I set the alpha of the MKMapView and the two RoundedTextView objects to 0 on viewWillDisappear and back to 1 on viewDidAppear. This made it nice and fast. I also presume that I could remove the views from the superview to speed it up as well.
Does anyone else jump through these kind of hoops on the iPhone. Is there something else I should be doing to avoid this hack?
It's not a hack to simplify drawing during animation in order to make the animation more smooth. It is indeed a very valid technique.
You may be able to achieve similar performance improvements by setting all UI elements to Opaque, a technique also used to fix table view cell performance issues. You just have to make sure background colors match.
The main problem I had was I subclassed UIButton to make gradient buttons and I had the boundary mask enabled. This made the performance terrible. I removed that option and made my buttons square and it's blazin now.