In my app, I am using Core-plot library to plot Vertical bar chart. When user taps on bar it should navigate to the another View-controller. (It will be off same view-controller's instance). When i push like this only for example 12-15 times i receiving memory warning & App crashes.
Did anyone faced same issue while using Core-plot library?
Thanks
Naveen.
Check your app by memory tools in Instruments.app. Maybe you can find some memory leaks. Memory warnings appears when your project use a lot of memory. And there is no reason to think that problem is in CorePlot. (as you said you creates more than 10 view controllers. Do you release them?)
Related
I am having problem on memory leak tracking, i did try profiling but the instrument shows firapb_decode_repeated_user_attribute as as responsible object. And while i try to track code it takes me to assembly code which is more painful. Do anybody have similar issue or have some clue to track this issue, It will be a lot for me.
Leaked Object # Address Size Responsible Library Responsible Frame Malloc 32 Bytes 1 0x600000231ba0 32 Bytes appName firapb_decode_repeated_user_attribute
The Assembly code
Yes as Larme said it was the Firebase leaking the memory.
I am still not knowing the exact cause (line of code) but disabling firebase app analytics from firebase plist solved the problem,
Even you are not using firebase app analytics with setting IS_ANALYTICS_ENABLED = NO on GoogleService-Info.plist. fire base SDK seem executing the app analytic codes by default.
Solution:- Adding FIREBASE_ANALYTICS_COLLECTION_ENABLED = NO on GoogleService-Info.plist, wipe out the leak problem.
This is only my perception and observation, this topic may need more information and expiations.
If you want to find the area of your code where the leak occurs, switch to the call tree view. The jump bar is at the top of your first screenshot. Click the Leaks item in the jump bar and choose Call Tree to switch to the call tree view.
When you're in the call tree view, selecting the Invert Call Tree and Hide System Libraries checkboxes will make it easier to find your code in the call tree view. Starting with Xcode 8.3, the checkboxes are in a popover that you open by clicking the Call Tree button at the bottom of the window.
Earlier Instruments versions have a display settings section with a Call Tree collection of checkboxes.
I've developed an iOS application. There is a main screen which is displaying a google map and there are many markers, polygons etc in it.
At the beginning app was using around 120MB of memory.
- I touched settings button of my app and went to the settings page. there is no code. only segue connection in the storyboard (red line on the image)
- then I came back to the map screen (white line on the image)
You can see the memory allocation. every time when I open the map screen memory usage is increasing
What is the problem. What should I do?
The graph you have captured in Xcode is a decent overview of your memory consumption, but I'm afraid you are going to have to use more specific tools to diagnose this leak: Instruments comes shipped with Xcode and will help you track memory leaks; you will have to research (at least) the Leaks and Allocations instruments to figure out why your View Controller isn't being released.
While it is impossible to diagnose without seeing your code, that graph heavily suggests that your map view controller is not being released (hence the steady growth each time you create a new one)
To hazard a guess, I'd imagine you are creating a new mapView in viewDidAppear rather than viewDidLoad
I just started learning the instruments tool, and I'm pretty sure what I am seeing is not good. When I look at allocations, specifically the column "Live Bytes" and "Overall Bytes", I see the number continually increases as the app runs...
My app has two view controllers. A table view, and the second view controller displays detailed information about the row they selected in the table view, downloaded from the internet.
I kept clicking a row in the table view, followed by clicking the back button in the navigation bar... and LiveBytes continued to increase.
I'm guessing this means that my objects aren't being released from memory... but please correct me if I'm wrong.
MY QUESTION IS: How do I use the data in instruments/allocations to track down this memory issue? How do I find the objects not being released from memory?
I'm looking for tips on how to use these tools to clean up any memory problems my app has.
Thanks!
XCODE 4.2.1, deploying to iOS 5.0+
EDIT: I'm looking at the #living column and seeing objects like UIScrollView continuously increase... and never decrease. When I click the back button in a navigation bar, are objects automatically released from memory? When are objects released, or do I need to do it manually? Or could I be running into an issue due to using strong pointers, causing objects to not be released?
Whenever you want to observe memory usage in a cyclic pattern, there's the wonderful Heapshot analysis in the "Allocations" instrument.
Start your app and go to a default state.
In Instruments, press the "Mark Heap" button to create the "Baseline".
Do something in your app like pushing a view controller.
Return to the default state.
Press the "Mark Heap" button again to create a heapshot.
Repeat about five times from step 3.
This will result in a list of heapshots, each showing the objects that are still alive from that cycle. If your app has no leaks there will be no objects left in the middle heapshots.
The first one or two cycles might have warmed up some caches, the last two might not have cleaned up some reused resources. That's why it's usually a good idea to make four to six heapshots.
The magic in the heapshot analysis lies in the fact that the heapshots show you the leaked objects from previous cycles and remove them automatically when the objects are released later. In contrary to the "Leaks" instrument it also finds abandoned memory, not only leaks.
Most Probably you have discarded the arm64 and are running your app with armv7 only. Add both arm64 and armv7 as architectures
I think one of the best ways to solve memory issues is to use ARC.
Edit -> Refactor -> Upgrade to Objective-C ARC.
ARC will handle the majority of memory management in your app. Especially sice your app doesn't sound too complex, it might totally eliminate your problem. You still need to watch out for retain cycles and listen to memory warnings though. If you don't want to use ARC (which you should) at least run the static analyzer. Your problem might be something simple that the static analyzer can show you how to fix.
Edit:
You mentioned scroll views- this might be your problem: Memory leak every time UIScrollView is released
The profile tool has an instrument called 'Leaks'. It is similar to the 'Allocations' instrument but it shows you the object that was not released. May be you can use the 'Leaks' tool to find what is the object that was retained and release these object.
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 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.