I know about iOS Automatic Reference Counting, which is compiler based feature. But, i have been going through many sites and confused with whether Garbage collection is also there or not on iOS program development? I know, ARC and GC is different each other. Some links says, GC is available for iOS and some links says GC is available only for Mac OS X development. But, i couldn't conclude saying whether the GC is there or not on iOS development? Please direct me the right path or link so that i can understand about it and try programming.
Thanks!
iOS has no method of Garbage Collection. Even so, Garbage Collection is entirely unnecessary (for all practical purposes) when ARC is used. ARC works its magic at compile time to do the reference counting for you thereby making it unnecessary (and actually non-allowed) to use any other sort of memory management.
Edit:
To clarify, OS X does currently support garbage collection, but it is deprecated (unbeknown to me until a few minutes ago) as of OS X Mountain Lion. iOS never has and never will support garbage collection. Any advantages of garbage collection are moot when compared to those of ARC, and Apple has made the move to (forcefully) nudge us in the right direction.
iOS does not have garbage collection
Related
How can I search for specific static memory address in iOS games some thing like amount of damege and other Thing that don't have vaule in Gameing
I use Ida put its not helpful cause it not show you the statice memory address
Assuming you're trying to hack existing games by twiddling bytes similar to what Game Genie did on old video game systems, good luck with that. Besides the fact that iOS apps use dynamic memory allocation for pretty much everything, iOS also incorporates address space layout randomization, which means even ostensibly static storage probably won't be in the same location in consecutive launches.
The only approach that would even stand a chance of working would involve injecting code that performs introspection of the classes using Objective-c runtime calls. And even if you do that, there's no guarantee that such hacks will be possible or practical in iOS.
I just start using Appcelerator and I seek some information about it and I have read that Appcelerator has a huge problem with memory management and memory leaks. I would like to know if that is true before I decide to use it. Does Appcelerator have problems to manage memory?
In one word: No
It's up to you. If you code clean and reusable, Appcelerator will not have memory leaks.
I also ran into memory problems. And in 95% it was my fault.
Appcelerator had memory leaks in the past. But since SDK 4.0 the most things are done and the SDK only gets better.
Give it a try and build the example apps to have a feeling how fast Appcelerator can be.
As a titanium developer for quite a while now I haven't seen any memory problems that are caused by titanium (except for some minor issues on Android with the older versions). Available memory on mobile devices can be relatively small and with Titanium, although they work hard on reducing this, there is always an extra framework layer consuming extra memory. It's just a matter of keeping this into account and writing clean javascript with as few unneeded variables as possible left open.
There is a great guide about Titanium, Memory management and Javascript garbage collection on the Appcelerator Documentation website with good tips on how to monitor with Xcode as well.
There is also a must read article about this topic on TiDev which you should also definitely check out!
I haven't found an issue with the Titanium SDK leaking memory. Any issues have been my fault, not cleaning up a reference, not nulling, or forgetting to remove an event listener. The guides mentioned above are an excellent resource. As stated clean JavaScript keeps the maximum memory released.
Note: I apologize if there are similar questions, but they are more specific like "UIMapView Kit Memory Leak issues", I am more concerned and really want to know in General Swift and ARC and the memory Management Issues with it.
I have done a couple of apps now in Xcode, however it was all done in Objective-C.
The memory management of UIKit objects(including UIViews and UIViewControllers) and any other object for that matter was easy to handle in Objective-C, and by easy I mean getting used to it after battling with it at some point in the Learning curve.
Now I am working with Swift trying to keep up with the "Cutting-Edge" technology. however I have noticed a slight issue with what I was able to pin down and control in Objective-C, Memory Management.
Swift comes in saying how easy is going to be for us to focus more on Code Development and not on memory management like its predecessor or soon-to-be predecessor.
However I have not yet found this benefit. I have been having a horrible time with memory management of my new app. Just creating a simple UIViewController with a few views can stack up memory that I don't longer need, few Mb's at a time.
keep in mind, I have been using deconstructor(Deinit in Swift), been assigning nil to values I no longer need to use, removing SubViews from Super Views manually thinking this was the problem, even using AutoReleasePool code segment.
autoreleasepool{
//Code looping through Swift Native Objects that potentially might lead to leaking
//But AutoReleasePool helps with this, supposedly.
}
Now the Question: Anyone here would know exactly what is the problem? Is it me doing something terrible with my code? or is there really a bug in Xcode and swift memory management? Have anyone else had this issue, have you solved it?
Here is a link explaining a bit this situation.
Problems of ARC in Swift?
ARC in Swift Apple Docs
Update:
You are right, I should post more about my situation: so here it goes.
I have memory starting at ~5mb as as soon as the app starts.
Once I start navigating around the app. I notice how memory starts to pile up little by little.
but the biggest spike of memory start to pile up when I use UIMapView of about 25+ Mbs.
when using just a regular UITableViewController it just piles up ~2mbs every time I push(to NavController) the same UITableViewController. When I tab that TableViewCell it opens another ViewController with a UIMapView, this is where the memory starts to pile up really good.
Rememeber I am just going back and forth navigating through the app. Just a total of 4 UIViewControllers including My Menu.
But here is the thing... All these memory SnapShots you see are after I stop navigating and go back to the main menu, the Root ViewController of my Navigation Controller.
Swift uses ARC in exactly the same way that ObjC does. If you're seeing a leak, you're probably creating a retain loop somewhere, and you would avoid those in almost exactly the same way as in ObjC (with the additional option of using unowned, but those are very similar to unsafe_unretained, so even that isn't a major change). If you're familiar with memory management in Cocoa, then you understand memory management in Swift. But we can't help based on the information you've given here (which mostly seems just commentary on Cocoa).
autoreleasepool{
//Code looping through Swift Native Objects that potentially might lead to leaking
//But AutoReleasePool helps with this, supposedly.
}
All that said, this comment hints at your mistake. The autorelease pool needs to go inside a loop where you are rapdly creating and destroying objects, not around it. Autoreleased objects are not released until the end of the pool block, or the end of the event loop. The latter is generally sufficient, but if you're generating and releasing lots of objects, then you sometimes have to drain the pool sooner. Autorelease pools are explained in the Advanced Memory Management Programming Guide. That said, they are not commonly needed for UIKit objects.
As a side note, the "Problems of ARC in Swift?" link you give seems to be unaware of the history of Garbage Collection in Cocoa. GC was tried by Apple on Mac and rejected by Cocoa devs. Apple deprecated GC and has subsequently removed it (I was at WWDC when they announced it was being deprecated; we applauded). It is even less applicable to iOS. An excellent discussion of this issue is in Why mobile web apps are slow. I'm not saying that GC is a bad thing. I'm saying that Apple is well aware of it, and actively chose not to incorporate it. They didn't just miss an opportunity.
EDIT: Your updated info looks like a pretty standard retain loop. I'd start with heap shot analysis to figure out what kinds of objects are involved. Make sure you're following the rules. And go from there, mostly with Instruments (especially the Allocations and Leaks instruments). One key is that view controllers should generally not retain other view controllers at all. They should talk to each other through the model. You must be careful using self in blocks. The normal rules. They're the same in ObjC and in Swift. But heap shot is definitely the place to start. Find out what is leaking; then figure out why.
I am trying to understand the inner workings of XCode's Instruments. On MacOS, it can rely on DTrace to gather all kinds of profiling data. On iOS, it is also capable of lots of things, but I have read repeatedly that DTrace has not been ported to iOS.
So how does that work?
The Apple documentation on DTrace isn't telling me much about the inner workings here. I have noticed, however, that when profiling my own App from XCode using Instruments, XCode seems to build it differently. Could that mean it links some standalone DTrace providers with my code?
Thanks in advance!
/e: I would bounty this question with my ENTIRE 6 REPUTATION POINTS if only i could...
For iOS apps running inside the Simulator, obviously the Simulator is a Mac OS X program, so it can use DTrace to monitor everything the Simulator does.
For iOS apps running on an iPhone, I agree the documentation provides little insight into what's happening. It's probably either loading monitoring code into the target process on iOS (either by adding the code at compile time or by linking it in at runtime) or there is an "traditional debugger" running on iOS against the target process to implement the tracing. Those are pretty much the only options if there is no kernel-level support for using DTrace.
I've never used Instruments, but the main thing that jumps out at me is that they're able to collect seemingly-OS-level statistics about I/O, which would not normally be measurable without DTrace. I'm not sure because I haven't used it, but it's possible these statistics are only tracking I/O from easy-to-detect entrypoints (ie I/O-related syscalls from the specific target process), or that there are other iOS-specific statistic sources which are published by the OS. For instance, many system statistics can be gotten from Mac OS X by calling sysctl. Depending on what statistics are actually being collected, Instruments could just be using simple counters like these to do most of the work.
If you're really determined to find the answer, it would be a fun DTrace challenge to figure this problem out by DTracing Instruments itself. Good luck :-)
I'm working on a custom PDF library for iOS and noticed that there are explicit functions for retaining and releasing CGPDFDocumentRefs andPageRefs. Does ARC handle the retain/release of such opaque types?
No. ARC does not currently handle the memory management for anything except Obj-C objects (which CGPDF things aren't).
I had the same problem when I recently converted to ARC in PSPDFKit 1.8. After considering a lot of tricks, like bringing ARC to autorelease an item, or using associated values, I finally use a container class that manages the references on the CoreFoundation-Level.
It's tricky, as if you have a CGPDFPage and you release the CGPDFDocument, further calls to the CGPDFPage will crash, even if that one's retained. So be careful with the references.
Related, it's not a good idea to keep many CGPDFDocumentRefs open - they may need A LOT of memory, malloc's of 15MB are not unusual. So in my library I took great care that things get released fast when there's a memory warning.