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.
Related
I'm trying to figure out which parts of my app consumes the most RAM on a device.
If I use the memory graph in Xcode I see many objects and their sizes, but is there a way to somehow sort them by size? Or is there another tool that can show me this?
Edit:
I am familiar with Instruments, but for some reason the Allocations and Leaks instruments give me very odd numbers and most of the allocations appear as just mallocs. It probably has to do with the fact that I'm using Intel Multi OS Engine and most of my logic code is actually written in Java. I dumped an hprof of the java heap and watched it in Android Studio, so it gave me a good picture about the memory usage in the java side. But I wanted something for the obj-c/swift side too. Instruments is not very useful in my case.
Thanks.
You can run your program using profiler (CMD+I).
Choose "Leaks" and "Allocations" inside menu.
This tool could help you to know how much memory and which objects/processes waste the most.
These articles could help:
Working with Instruments - Allocations
Profiling Memory Allocations In iOS With Instruments
I can see some memory leaks in my code, if i run from the instruments. But in call tree, I'm not getting proper information about memory leak.
How can we identify and solve those kind of memory leaks .
You should look into the memory graph tool for debugging which XCode 8.x contains. There is a WWDC talk which includes it (along with other debugging elements) that is located here.
You can also search "memory graph debugger xcode" in your favorite search engine to learn more (I could include links but they are not guaranteed to be around).
iOS provides a lot of frameworks, I am new to iOS but there's one concept I am not sure of:
If I minimise the number of frameworks my app depends on, I assume that is a performance boost, am I correct? or does it not matter?
For example, am I saving on memory footprint, or optimizing performance if I do not iOS frameworks ( like core data or core graphics ) if I really don't need the functionality in them? in my app the code is too simple that I can write it myself without core data ( very basic functionality ) .
I couldn;t find good articles that discuss this concept, do all frameworks released by apple get deployed on the device irrelevant of your project using them or not?
It's generally best not to link to frameworks you're not using. To answer your more specific questions:
do all frameworks released by apple get deployed on the device irrelevant of your project using them or not?
Essentially yes -- they're provided as part of iOS, so they're already loaded onto the device (and always present).
If I minimise the number of frameworks my app depends on, I assume that is a performance boost, am I correct?
Perhaps -- the linker/loader won't have to load the frameworks into memory and link your app to them, but the performance cost for doing so is so minuscule that avoiding linking/loading a framework isn't a good reason to not use it if you otherwise would find it to be useful.
am I saving on memory footprint
Maybe. When you load a shared library, the contents of the library get loaded into your app's memory space, so it will increase the memory footprint. However, if the library is already loaded by another app (or by the OS), it'll be shared amongst all apps using it.
Even so, a possibly increased memory footprint is a bad reason to avoid using a framework you might otherwise find helpful.
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 recently started trying to develop apps using titanium.
When i ran one basic app containing two table views and some static data, it showed me 80 memory leaks and about 15 warnings - i think coming from the frameworks.
As an iOS developer, i'm used to seeing less than 5 memory leaks in complex apps too.
So, I'd like to know whether applications are getting accepted by apple when developed through titanium.
Also, I'd like to know whether,looking at the state of the titanium frameworks,its worth learning it right now.
Thanks in advance!
Your First Question, Yes! they are being accepted by Apple App Store.
And For your second question, its relative to likings of individual. I started mobile application development with titanium, but soon I realized that there is no better way to create an application then to create it natively. I would say if the applications you are developing are not scaled at enterprise level magnitude (means thousands of lines of code), better develop apps natively.
Titanium is increasing support and improving frameworks rapidly, its also reduces lines of code by third! and the best thing about it is, its cross-platform! but to my personal liking i always prefer native development. The power, the iOS gives you, Titanium wont!
One more thing i would like to add, despite all, you should learn it! :)