I have a program based on UITableView (the user can edit the contents of the cells). After a long time open (mostly in the background) it will sometimes suddenly stop allowing you to fully scroll to the bottom of the list. The scroll is set to bounce, so it will bounce up and you can see the last few rows, but it will bounce right back down and hide them again.
I am using the navigation controller's toolbar, so in some ways it seems like the toolbar hides the last few items, but I think that's not really what's going on. (I think the last item or two would be off the screen anyway.)
Again, there is no problem scrolling most of the time.
It happens so rarely that I haven't been able to get very close to identifying the cause. It seems like it might happen after rotating to landscape mode, but many many rotations can occur without causing the problem. It also seems to show up after my phone has gone well below 10% battery before being recharged (I notice the problem after the battery is back to full, but it could be it starts before that, or that the battery status is totally unrelated).
Since it happens after the program has been running for days (mostly in the background) and is fixed by restarting the phone, I have suspected a memory leak, but I don't get any memory warnings and the program runs normally otherwise, even when the scrolling stops behaving correctly.
I have run Leaks a few times, and only once found a 16 byte leak on exiting the program, which I haven't been able to reproduce.
Any thoughts would be deeply appreciated.
Leaks wouldn't cause such problems by themselves. Sounds like your table gets resized, either automatically with UIViewAutoresizingFlexibleBottomMargin/UIViewAutoresizingFlexibleHeight resizing mask or manually.
Related
I'm having a memory issue with one specific ViewController and memory. When I launch my app in debug mode, it launches with 40mb memory usage. (I have no idea if this is already a lot or not -- what is common?). Then, when I open this specific view, it spikes up to about 120mb. The issue is, when I pop this view (with the navigationController popViewController), the memory stays up at 120mb. And then, when I re-open it, it spikes to 200mb (a 80mb increase every time).
With other similar ViewController it spikes up to 120mb too, but when I close the view, it goes back down to more or less 40mb.
The problem is that this specific view contains quite a bit of code (about 1000 lines...) and it's impossible for me to post everything here.
What methods should I use to specifically locate the issue in xCode?
For anyone I might be able to help with this:
use the tools in xCode as recommended. There are some great tutorials online.
In my case it was an issue with an [NSTimer] which kept a strong reference to my view, so it never got released afterwards, thus stacking up memory. Make sure to stop your time when you pop a view.
Long story here, so bear with me...
I have a view controller which, when presented more than three times throughout the life of an application session, will hang and lock and freeze my entire application. Even the Springboard locks up until my app's fully backgrounded! In Xcode's inspector, I noticed rather alarmingly that the memory footprint would jump a good 5-8 MB every time I presented that view, and it wouldn't go down again after dismissal. By the time the fourth invocation rolls around, the app's already using 40 MB of memory.
My first thought was, "OMG, itz a memry leek!" The second one told me to hop into Instruments and track it down.
While the Leaks tool did help some, it only told me that the app was leaking like crazy. All it would tell me was that, somewhere in these four second intervals, I had gained between "4 new leaks" and "17 new leaks." They did correspond to my opening that view, though, and once I started commenting random stuff (and following the sometimes helpful guidance of the Allocations tool), I tracked most of them down to three extra lines of code. "Oh well, I don't need those views anyway!" Those three lines no longer exist, and Instruments no longer complains.
My only complaint here is that my UI still behaves the same! On the fourth presentation, the entire app slows down. Upon further inspection of Xcode's instruments, I see that not only is the memory still going up (only to 30 rather than 40 MB this time), but the CPU activity has tanked!
Ok, granted I should have looked there in the first place, but I ain't perfect!
I ran the app again, and found that the overall CPU activity rose consistently the more I presented that view controller. By the third one, it was up to 40-60%. The main thread seemed pretty clear, and most of the activity was spread between eight other background threads (who knows what all those do).
The fourth time I opened that view, I had expected everything to block like crazy. It didn't. The CPU just... stopped. It was running at around 50-ish% when, by the time my finger had left the screen, it was down at 1%. All of the thread graphs shrunk from spiked stalagmites to tiny waves in a puddle. According to the pie chart, the vast majority of the processor was free to do as it liked. It doesn't like me.
I literally have no clue why it does this. I've been stuck in a room for days now trying to figure this out. Any help or advice would be much appreciated.
Does anyone have any idea why this happens, how this happens, or what I can do to make this not happen?? I'm drawing a blank here...
Thank you so much!
It should be noted that I got these by running the app on my iPhone 5s. Yes, I did try on the simulator, but my little MacBook Air took it like a champ, and was no help in figuring this out, except to tell me that the problem happened on iPhones.
I've run into this before, and the following is my general approach that usually allows me to fix these types of memory leaks.
First I would put a print statement into you viewController to see if your VC is being deallocated when it is being popped.
deinit {
print(self.description)
}
The next step, in the case that the ViewController is not being deallocated, I would start by removing core pieces, bottom up, commenting them out chunks one step at a time, yet leaving the back control that hides the view controller visible. Usually you can isolate the memory leak once you see the deInit get called after removing some code, you may have hit the part that made a strong cycle reference.
One more thing, ensure that all your delegates are declared weak, and search through your code for closures, and check that the closures aren't holding hard references within, especially to self.
Also, checkout this article to see the about using unowned or weak, when passing in instances into a closure, could be helpful.
http://krakendev.io/blog/weak-and-unowned-references-in-swift
I've been asked to help fix a bug for a client, who is an inexperienced developer. However, I'm absolutely stumped by this one.
The problem is that after a string of opening and closing a view controller, which is being pushed onto a navigation controller, all of the subviews will disappear (including the navigation bar items) and show straight through to the window. After this happens, I can still press the buttons on the navigation bar, but they will immediately disappear on touch-up, and restoring a stable UI state is impossible without a quit & relaunch. Another obscure side effect is that after closing the app, Springboard will flash as I swipe between screens. My initial thoughts were that this was a memory issue (e.g. subviews getting released on memory warning), but I have since cleaned all the leaks & checked all the viewDidLoad/viewDidUnload handling of outlets and the problem is still happening. So now I think that with the Springboard effect, that the code is somehow messing up the state of core animation entirely.
Has anyone seen anything like this before? Or have any idea how it would be possible to make this much of a mess? I would attach some screenshots, but trying to take a screenshot with the phone when the app is in this state causes a system crash.
I've not experienced this, but maybe a memory warning is eating some of your views?
I know that iOS is free to unload view controllers that aren't visible.
I'd stick a breakpoint in viewdidunload or similar and see if that triggers.
As it turned out, this bug was caused by a UIView being deallocated while it had a superview.
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.
I have an iOS app that, in one view, makes a toolbar in code. Nothing fancy here; just a bunch of standard UIBarButtonItems (initialized with initWithImage, and each one invoking a different selector), added (along with spacers) to the toolbar using UIToolbar setItems:animated (with no animation).
This works fine most of the time... but sometimes, after going to another view and back to this one many times, the toolbar's touch-handling appears to be off. It highlights and invokes the wrong button. It's not always the same wrong button, either; sometimes it's one right next to the one I actually tapped, but other times it is further away, even clear over on the other side of the toolbar.
There is no pattern to it, but if you try long enough (switching to another view and then back to this one), it always happens. It seems to happen more often when the other view is at a different screen orientation (forced by its shouldAutorotateToInterfaceOrientation implementation), but even when all views have the same orientation, it still happens now and then. When it happens, my selector gets invoked with a sender that matches the button that was actually highlighted, rather than the one I touched. So it really seems to be a matter of something in iOS not processing the touch correctly.
My google-fu has utterly failed to turn up any other reports of this issue... seems like it must be an Apple bug, since none of my code is involved in the toolbar touch handling. This happens both in the simulator and on the device, under iOS 4.3 (haven't tried other versions yet).
Has anyone else run into this issue? Any suggestions on how to avoid it?
OK, I found the problem. It wasn't the code that creates the toolbar itself; it was where (and how often!) it was being called.
This was legacy code, and we hadn't noticed that the create-the-toolbar code was being called from the view's didRotateFromInterfaceOrientation method (for reasons we can't imagine). That method gets invoked quite frequently, and the old toolbar wasn't being torn down, so it was creating toolbars on top of toolbars. Not too surprising that the touch handling went wonky in that situation.
Deleting the call there (and putting it in viewDidLoad like one would expect) solved the problem. Sorry for wasting everybody's time... but maybe the next person to stumble across screwy toolbar behavior will find this helpful.