I have a memory leak that is very puzzling! It happens when I tap the section Index and then scroll manually in a UITableView. It appears to be related to NSIndexPath, which I only read in didSelectRowAtIndexPath:indexPath. I don't create or store any NSIndexPath structures otherwise.
Other users had similar problem in earlier SDK versions and only within the simulator. I use the latest 4.2 and this leak appears both in the simulator and the device.
Below is a screenshot link. Any idea as to what causes this problem, or any tips on how to narrow it down without looking at assembly code?
http://www.maani.us/temp/Screenshot1.png
http://www.maani.us/temp/Screenshot2.png
Thank you.
I don't have an answer (yet), but I was wondering if you're still seeing this behavior. I randomly see the same thing as described here. I also realize that the Profiler isn't perfect, so I'm considering that too.
Related
I am writing my whole app from code and i am not using storyboard.But My app is using much memory. I have some view controller,TableViewController, collectionView and some webview in my apps.
And I am pushing all viewController and instantiating navigationViewController from RootviewController to it's childviewController.
And I am think that the ARC is not working is enable in my project.And When the memory reaches maximum my app is kill by iPhone.
wow, that's a lot of memory!
I don't have much experience with webviews, but I might be able to help with the other components.
As a suggestion: Make use of the debugger to go through your code step by step and keep an eye on the memory inside XCode.
You might be able to find out which part of your code generates so much memory usage that way.
If you can't find the problem: It is very hard to tell where this effect comes from. It might be a little easier if your post your code (preferably commented) so we can dig deeper into what might be causing this problem.
Cheers,
Ferdinand
check if there are any memory retain cycles, when refrencing self inside closure always use weak reference.
I'm developing Keyboard Extension on iOS 8.3
While developing there is a memory leak somewhere after calling advanceToNextInputMode.
And the Responsible Frame and leaked Object are looks like totally out of my control.
Can anybody meet anything similar problem?
I have this exact problem. It is Apple's fault. The total amount of memory leaked is pretty tiny though. File a bug report so they'll take it more seriously (I've already filed, but more always help).
So here's the issue i'm currently running into.
I have an app that shows a Facebook/Path like feed with a UITableView. Let's say that my datasource has about 200 items and not all cells have the same content and cell height. Some have images and some don't. I was able to overcome the scrolling performance issue by initializing my cells with a reusable identifier in the following format: [NSString stringWithFormat:"entry_%d", some_id]. Things were going really well up until I started using the UIImagePickerViewController. As you can imagine I've been receiving a lot of memory warnings due to my large datasource/table.
When playing with the Path's app and trying to load as many data into a single view; they do a really good job at both the scrolling performance and memory management. Their app also doesn't crash whenever I go into the camera mode.
Any thoughts or theories?
Thanks! :)
I highly suggest you check out the Facebook iOS framework which reimplements the table view. The name of the framework is Three20, and you can find it on github here.
With that said, if you have a very large table, you need to be careful to only load resources for those things that are in view, and release resources for items once they go out of view. The delegate method tableView:didEndDisplayingCell:forRowAtIndexPath: (available iOS 6 and later) is your friend for that. Here is another question related to this topic.
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 have been following a iOS tutorial on raywenderlich.com, called "How To Create a Simple Magazine App with Core Text" LINK
The App works great on the simulator, but when i build it for my iPad 1G, the scroll view is not fluent at all, the performance goes down, and the view becomes useless.
I have been trying to get help at the raywenderlich.com forum, but with no luck.
Is it a general problem with Core Text or what do you think?
Thansk
When trying to debug lag issues, try and find similar apps on the Store that are doing similar drawing. If your performance does not equal that level, then your code can obviously be improved.
For instance today, I was coding a UITableView, but when I ran it - it was not fluid in scrolling. I just knew that something wasn't right as the hardware could obviously handle it; looking at scrolling performance in the Music app for instance. So I used the profiler tools and eventually tracked down my error.