Apple's Instruments application is a handy tool for monitoring and discovering memory leaks. Here's how you can use it for this purpose:
In more recent versions of Xcode, to run an Ti app from the XCode build, you will need to change your workspace setting:
Xcode Preferences > Locations > Derived Data > Advanced > Select custom and "Relative to workspace".
1. Open your app in the iOS simulator.
2. Open Instruments:
• For Xcode 4.4 and later, start Xcode and from the menu, select Xcode -> Open Developer Tools -> Instruments.
• For Xcode 4.3 and earlier, open /Developer/Applications/Instruments.
3. In the Choose a Template window, click Allocations and click Choose.
4. Attach your application to Instruments. a. For Xcode 6.x and later, click Choose Target, click More... under System, then scroll down and click your app's name.
b. For Xcode 5.x and earlier, click Choose Target, Attach to Process, then scroll down under System and click your app's name.
5. Click Record. Wait a moment till data begins recording.
6. In the Instrument Detail filter box, enter a filter string, such as TiUI to show only relevant allocation information. Note: ONLY For Xcode 6.x, target simulator, the objects are squashed in All Heap Allocations so you have to expand this by clicking on the right detail arrow button, before you can see the relevant allocation information. This is not necessary if you are targeting device. Xcode 7.x and greater has fixed this as well.
7. Click and use your app while watching these values in Instruments:
Column
Shows
Notes
Persistent Bytes (or Live Bytes)
Memory currently being used by active instances of the object in memory
You may have a leak if this number continues to grow as you use your app.
#Persistent (or #Living)
Number of active instances of the object in memory
You may have a leak if this number continues to grow as you use your app.
#Transient (or #Transitory)
Number of ready-to-be-garbage-collected instances of the object
Transitory objects might or might not be in memory. It doesn't matter if this value grows over time. JavaScriptCore will garbage collect periodically; any transitory objects will be destroyed when it does so.
Total Bytes (or Overall Bytes)
Bytes used by Living and Transitory objects
This number will grow until garbage collection runs.
#Total (or #Overall)
Sum of Living and Transitory
This number will grow over time.
Transient / Total Bytes [or # Allocations (Net / Overall)]
A histogram of the current and total accounts.
If you make a change to your app, the most reliable way to gather new statistics in Instruments is to close it and start over.
Tracking memory more accurately
On iOS, the runtime and other systems may frequently allocate (or deallocate) objects which can't be managed directly through your javascript code. In general, when checking your app for memory leaks, you should be filtering for objects with the "Ti" prefix.
Also note that by attaching the profiler after the app has started, you do not get any information on already-created objects until they are touched by the memory management system. To get more accurate information, you may need to open the xcode project generated in your project's build/iphone folder, and choose Product -> Profile, then configure the resulting Instruments launch as described here.
Android's DDMS tool can show you memory leaks – both memory allocations that are not freed and objects that aren't garbage collected. Following the procedure shown here, you can watch as memory use and object allocations grow. You'll need to pair that information, with knowledge of your app to determine where within your app the cause might be.
1. Build your app for the Android emulator at least once.
2. In your text editor, open /build/android/AndroidManifest.xml.
3. Copy the node, a sample of which is shown here (your app name would vary, of course):
4. Paste that into your app's TiApp.xml file, modifying the node as shown:
Notice that we've set debuggable to true and added and completed a couple of the nodes.
5. Save and build your app for the Android emulator again.
6. Open DDMS.
7. As shown in the screenshot below, click to select your app in the list of processes. Then, click the Show Heap Updates button (labeled #2 in the graphic).
8. On the VM Heap tab, click Cause GC to force garbage collection. Note the values listed in the Allocated and # Objects columns.
9. Here's where you'll exercise your app and watch for memory leaks. For example, if you're using the AppLeak sample app linked to below, click the Test 1 button, click Back, and repeat. Memory and the object count in DDMS will grow, though that number includes objects that are ready to be garbage collected.
10. Click Cause GC to force garbage collection. If there's a leak, the values of Allocated and # Objects won't return to their former values.
These steps don't tell you exactly what is causing the leak in your app. Unlike Instruments, DDMS doesn't clearly show which objects are remaining in memory rather than being collected. You will need to test your app and watch the memory values to infer the potential causes of the leak.
Monitoring allocations on iOS
ReplyDeleteApple's Instruments application is a handy tool for monitoring and discovering memory leaks. Here's how you can use it for this purpose:
In more recent versions of Xcode, to run an Ti app from the XCode build, you will need to change your workspace setting:
Xcode Preferences > Locations > Derived Data > Advanced > Select custom and "Relative to workspace".
1. Open your app in the iOS simulator.
2. Open Instruments:
• For Xcode 4.4 and later, start Xcode and from the menu, select Xcode -> Open Developer Tools -> Instruments.
• For Xcode 4.3 and earlier, open /Developer/Applications/Instruments.
3. In the Choose a Template window, click Allocations and click Choose.
4. Attach your application to Instruments.
a.
For Xcode 6.x and later, click Choose Target, click More... under System, then scroll down and click your app's name.
b.
For Xcode 5.x and earlier, click Choose Target, Attach to Process, then scroll down under System and click your app's name.
5. Click Record. Wait a moment till data begins recording.
6. In the Instrument Detail filter box, enter a filter string, such as TiUI to show only relevant allocation information. Note: ONLY For Xcode 6.x, target simulator, the objects
are squashed in All Heap Allocations so you have to expand this by clicking on the right detail arrow button, before you can see the relevant allocation information. This is not
necessary if you are targeting device. Xcode 7.x and greater has fixed this as well.
7. Click and use your app while watching these values in Instruments:
Column
Shows
Notes
Persistent Bytes
(or Live Bytes)
Memory currently being used by active instances of the object in memory
You may have a leak if this number continues to grow as you use your app.
#Persistent
(or #Living)
Number of active instances of the object in memory
You may have a leak if this number continues to grow as you use your app.
#Transient
(or #Transitory)
Number of ready-to-be-garbage-collected instances of the object
Transitory objects might or might not be in memory. It doesn't matter if this value grows over time. JavaScriptCore will garbage collect periodically; any transitory objects will be destroyed when it does so.
Total Bytes
(or Overall Bytes)
Bytes used by Living and Transitory objects
This number will grow until garbage collection runs.
#Total
(or #Overall)
Sum of Living and Transitory
This number will grow over time.
Transient / Total Bytes
[or # Allocations (Net / Overall)]
A histogram of the current and total accounts.
If you make a change to your app, the most reliable way to gather new statistics in Instruments is to close it and start over.
Tracking memory more accurately
On iOS, the runtime and other systems may frequently allocate (or deallocate) objects which can't be managed directly through your javascript code. In general, when checking your app for memory leaks, you should be filtering for objects with the "Ti" prefix.
Also note that by attaching the profiler after the app has started, you do not get any information on already-created objects until they are touched by the memory management system. To get more accurate information, you may need to open the xcode project generated in your project's build/iphone folder, and choose Product -> Profile, then configure the resulting Instruments launch as described here.
images/download/attachments/29004941/instruments.png
Monitoring allocations on Android
ReplyDeleteAndroid's DDMS tool can show you memory leaks – both memory allocations that are not freed and objects that aren't garbage collected. Following the procedure shown here, you can watch as memory use and object allocations grow. You'll need to pair that information, with knowledge of your app to determine where within your app the cause might be.
1. Build your app for the Android emulator at least once.
2. In your text editor, open /build/android/AndroidManifest.xml.
3. Copy the node, a sample of which is shown here (your app name would vary, of course):
4. Paste that into your app's TiApp.xml file, modifying the node as shown:
Notice that we've set debuggable to true and added and completed a couple of the nodes.
5. Save and build your app for the Android emulator again.
6. Open DDMS.
7. As shown in the screenshot below, click to select your app in the list of processes. Then, click the Show Heap Updates button (labeled #2 in the graphic).
8. On the VM Heap tab, click Cause GC to force garbage collection. Note the values listed in the Allocated and # Objects columns.
9. Here's where you'll exercise your app and watch for memory leaks. For example, if you're using the AppLeak sample app linked to below, click the Test 1 button, click Back, and repeat. Memory and the object count in DDMS will grow, though that number includes objects that are ready to be garbage collected.
10. Click Cause GC to force garbage collection. If there's a leak, the values of Allocated and # Objects won't return to their former values.
These steps don't tell you exactly what is causing the leak in your app. Unlike Instruments, DDMS doesn't clearly show which objects are remaining in memory rather than being collected. You will need to test your app and watch the memory values to infer the potential causes of the leak.
images/download/attachments/29004941/ddms.png
Great post , Thanks for sharing
ReplyDeleteAndroid Online Course Bangalore