I have this problem with performance of my iPad app..
For developing, I use MonoDevelop, which takes care of Garbage collecting. Still my questions are rather generic, I'd say.
OK, I use TabBarController with 5 NavigationControllers. Inside nav controllers there are some controllers, whose views are TableViews or ScrollViews. Next child is always just regular view.
I have a few questions:
1) TableViews never scroll smoothly. I have some alpha transparency, but since I did my graphics in Photoshop and not programmatically, this transparency should not cause much problems. It doesn't matter whether I have few or many results in table.
On the other hand, I have ScrollView which serves same purpose, i.e. to be a table with different layout and buttons have Photoshop generated transparency as well. It works perfectly.
For tables I applied DequeueReusableCell() which works fine (I see that memory usage is not increasing after scrolling). So why would tables scroll so jerky?
2) My app supports rotation. When I scroll table or scrollView and simultaneously tilt the device a bit, I get maybe 1 or 2 FPS. What is the best way to implement rotation? As I understand, ShouldAutorotateToInterfaceOrientation has to be overridden in all controllers in NavigationController chain. Also, I need to add observer in View I want some changes to happen. Do I have to use BeginGeneratingDeviceOrientationNotifications() in all views or is it enough to do it in Main.cs? Maybe this slows it down?
3) After some time app starts getting memory warnings and then crashes eventually. I tried to read logs and run app with Instruments, but can't find the cause of crash.
4) What exactly happens to a View popped from NavigationController stack? I can't reuse it. But could it be that Monotouch (or me) doesn't dispose it correctly?
I have almost same app for iPhone without support for rotation which never crashes. I think I'm doing something wrong with this rotation, but I'm not sure what.
Any help will be appreciated the most. So, thank you in advance.
Regards
1 - transparencies are always a problem. Even if you're not rendering the images in code, the phone still needs to do the compositing of the image, and that may take a lot of time. UITableViews have to calculate the final composite image every time a new cell is displayed, or the table is scrolled, while UIScrollViews can calculate only once, since the image won't change. So be very careful about it, turn the transparency off, and check if performance improves.
2 - You shouldn't need to notify every uiview in your application. Receive the notification in the controllers that you want to update only, like for example if you want to rearrange items in the UIViewControllers view.
3 - you have one (or many) memory leaks. My guess is that MonoTouch probably can't garbage collect UIViews or UIViewControllers, because they're still being linked from somewhere in UIKit, like a UINavigationController
4 - UIViews are not disposed by UIKit until the app gets a memory warning notification.
Like Eduardo said, alpha transparency in Views comes at a price. There are some tools that you can use to identify the bottlenecks discussed in these WWDC 2011 talks from:
https://developer.apple.com/videos/wwdc/2011/
iOS Performance and Power Optimization with Instruments
Understanding UIKit Rendering
In the "Debug" menu of the iOS simulator you can find various debugging tools that will color different regions of the screen indicating where some problematic rendering is taking place. The WWDC 2011 talks show what you can do to fix those problems.
For your memory problems, it is very likely that you have something pointing out to your objects around, so you need to make sure those objects are gone. While we currently are not shipping our new profiler for MonoTouch that can show the source of the problem, I wrote a "poor man's" debug utility that will help you narrow down which objects are alive. It is available here:
http://tirania.org/tmp/HttpDebug.cs
Call HttpDebug.Start () from your application and as you run, connect with a web browser to http://localhost:5000 to get a list of live Objective-C objects surfaced to C#. The tool is not perfect and shows a lot of irrelevant data, but it would at least give you an idea of what is going on.
Related
I'm concerned about tiny lags and memory issues, and how they might scale.
My app is programmed using Swift and I've been doing everything in the app programmatically, including page navigation using presentViewController and dismissViewControllerAnimated.
Note: the app's page hierarchy can be several pages deep and each page contains quite a number of images.
I started experiencing tiny, occasional, lags which could appear more often on older phones; I can only test on iPhone 6 right now. I also noticed a small increase in memory while navigating through pages. Of course the memory level on the app (as observed in XCode) is not the same as opening the app in fresh state compared to going back to the first page after navigating through tens of pages, I'm expecting the memory level comparison could come at least close.
Now, my question: is there a proper way to "destruct" my page views (including UIKit elements, images, etc.) when such page view is dismissed?
I assume that by "page" you mean a viewController: There is no way to directly destroy objects with ARC (automatic reference counting), as they are deallocated automatically when their strong reference counter is zero. Since you experience unusual memory increase, it might be that you have some strong reference cycles in your code. Make sure to declare properties as weak wherever necessary. You should check out the ARC Guide for detailed explanation. I hope this helps.
I am building a UITableView-based Unity plugin which will be embedded by game developers into their Unity app. I am using the standard approach with dequeueing reusable cells, and the UITableViewCells contain simple UILabels and a UIImageView. The image inside the UIImageView is loaded via an asynchronous request.
There are no usability issues at all when launching the plugin as a standalone Objective-C app (in particular, scrolling works well with no lag) but when inside Unity, there is a "sticky" scrolling issue which arises randomly, i.e. the view scrolls but without inertia. I have not been able to pinpoint the exact actions which cause this behavior, but it happens usually when I scroll very quickly in one direction, or in short movements back and forth. The bug disappears when I scroll the view past the top or bottom (trigger the "bounce" effect, I am guessing this causes some hard refresh).
There is a very similar issue described here. The fix they suggest is to put
#define USE_DISPLAY_LINK_IF_AVAILABLE 0
inside the Unity-generated AppController.mm file. Unfortunately, this fix is unfeasible for the game developer who will be integrating our plugin, since it turns off the fastest and most reliable timing solution, and would require a fallback to other timing systems which would cause the game itself to lag or miss a portion of touch and accelerometer events.
I will most likely override drawRect for the UITableViewCells to reduce rendering time and memory usage, and if that fails, write a version of the plugin in OpenGL. However, I was wondering if anyone had a similar issue and knows a quicker fix, either in Objective-C or inside Unity, that is non-destructive (like the timing fix described above). Thanks very much.
I had the same trouble that you have described. I've fixed it by commenting the line
//#define USE_DISPLAY_LINK_IF_AVAILABLE 0
While profiling my iOS app I perform a simple task multiple times where I push and pop a view from the stack, and then take a heapshot. The same code is executed each time and the pushed view just contains some images which get removed as soon as the view gets popped.
Now because the persistent count is 0 for almost half of the heapshots, would it be safe to assume there is no abandoned memory?
I've heard that the rows with a persistent count greater than zero could be because of some internal caching.
I am using Xcode 4.2.1 and the app is using ARC.
Edit:
Thanks to Kendall Helmstetter Gelner I've managed to debug this problem further. I probably shouldn't have been using the simulator for debugging this. I've now run it on the device and it now looks like there is one object which isn't getting released:
After looking through the extended detail view I think I've just about found the cause of the problem.
It's hard to say from just that screenshot what might be cached or not - UIImage will cache things, possibly some other system elements too. It looks like you might be running that in the simulator, have you tried heapshot on a device?
You could also select "Hide System Libraries" to the side and get a better idea how much of your own code is involved.
I'm looking for a technique to progressively load in the contents of a UIViewController to make an app feel "snappier". I noticed this issue when pushing a viewcontroller onto the stack there's a noticeable delay while waiting for it to push in. The UIViewController's View has some complex subviews with transparency. I'm wondering if I create them after viewDidAppear and 'fade' them in, then the transition will appear much smoother.
I noticed a similar effect in Apple's Trailers app. When tapping a movie in that app the detail view pushes in and the contents load after the fact. Granted part of that delay is because they are downloading the details before showing them, but it seems like they always fadein that large image whether it's been downloaded already or not.
Has anyone had much success with this or with improving UIViewController loads in general.
Before you start making changes in an effort to improve performance, use Instruments to profile your app and find out where the problem really is. Is it in drawing the complex subviews? Is it in loading the data? The only way to know is to measure.
There's no reason you couldn't do as you propose -- have the view controller create/load its main view and then add the complex subviews afterward. Your view controller can add and remove subviews at will. Will that make the app feel snappier? It might -- it's similar to the default image strategy Apple built into iOS, where the OS loads a picture of your interface to make the device seem responsive, and then substitutes the real interface once that's ready. On the other hand, if the user still has to wait for the complex subviews to be created before the view is useful, seeing the rest of the view might not help much.
Another possibility (again, after measuring) might be to create the views before the user needs them. This runs counter to the lazy initialization that iOS apps commonly use to conserve memory and power, but if you know that you're going to need the views and you can expect a lull in user activity before they're needed, it could be a good way to increase the app's apparent speed. All you need to do to get a view controller to create/load its view is to access its view property.
When using the Ti.UI.iPad.SplitWindow what is the best(cleanest looking) way to update the detailView?
The options I can think of are changing the positions of elements in the detailView event or to show()/hide() vs open()/close() on an orientationchange event. I know that using the native UI components on the iPad should dynamically update to the layout width/height of the iPad but in my case the content on each detailView will have it's child objects positions updated on orientationchange. I'm just trying to get the smoothest from your all experiences. Even if I have to build custom animations I just want to start this correct from the beginning so no current code exists yet. Thus none included.
I'm hoping this isn't a duplicate as I searched before I ask but there are no Titanium based questions on this topic I can find. Possible but still different to what I'm asking.
The smoothest experience will be delivered by changing the least. I don't know what animations you are envisioning, but I would nudge you towards keeping it simple.
Here's a quick example of an orientation change in an iPad app I built recently. I had a bunch of images in a view with layout: 'horizontal'. Due to a nice bug, the images wrapped automatically. When the user reoriented the device, I animated the width of the view, and the images automatically and animatedly resorted themselves.
I've also had some clients at a large corporation get their hearts set on really complicated changes to the layout whenever the user reoriented the device. This resulted in a really unsatisfactory app that took 10-20 seconds to reorient. We made a lot of optimizations, and a lot of improvements in both their code and the underlying framework, but the heart of the problem was the complex design.
Take the time to consider if you really need complicated changes every time the user reorients, and how much benefit you are offering to your users. Also consider the cost to the user (not just to the device) of presenting them with a new UI.
Past that, you're probably not going to get too many answers until you put some experimentation in to this. If you come back with some code and some questions to go along with it, I can reformulate my answer to better pinpoint your situation.
Hope this helps! -Dawson