ARM Community: Analysis of Airplay Android apps using ARM Streamline - ARM Community

On how many occasions have you engineered an application that works perfectly well on the Android SDK emulator, only to find that the performance is not quite the same when testing on a real device? My job in the ARM^® Development Studio 5 (DS-5^™) applications engineering team is to figure out ways in which the tools we produce can deliver quantifiable value for application developers by solving problems they face day to day.

I happened to see a partner presentation on Airplay SDK (see footnote^#), which is an Ideaworks product that makes cross platform application development easy. Airplay supports Android as a target OS for the SDK. This blog entry is about my attempt to explore a sensible, easy way of using Airplay and ARM Streamline performance analyzer, which is a part of DS-5, together to make application performance analysis easier for Android native development on target.

What tools and target configuration do you need?
I used my Windows XP laptop for this exercise. I started out by installing Android SDK tools, Airplay SDK and DS-5. DS-5 is based on Eclipse, so the Android SDK plugins can be installed into the DS-5 Eclipse environment (Step by step instructions for Android SDK installation here). Both Airplay and DS-5 offer evaluation licenses free of charge. See the above product pages links for trial downloads. Also, the target was configured for Streamline by building the Android Linux kernel with the right options for enabling profiling and tracing and by building the Streamline gator kernel module against this kernel. You also need to copy the Streamline gatord daemon binary for android to the target for performance data capture. The kernel module sources and daemon binary come with the DS-5 installer. You will find detailed information on target configuration for Streamline at ARM infocenter.

The next step was to pick an example application to run and analyze on an Android target. I decided to use a Beagleboard xM running Android Rowboat as the target and the Basic example that comes with Airplay SDK. It is a simple example which renders screens of different colours when executed. The target was wired to the laptop using a USB cable, so that the host machine could communicate over adb.

Steps for application performance analysis:






Timeline view
Streamline collects data for the charts including the timeline view from hardware and software performance counter resources on the target. These include data for the stats on cache, interrupts, disk IO, network usage etc which are shown in the top section of the timeline view (see image below) and that for the processes section at the bottom part of the view. You can see the different threads in the Basic application listed against the process com.mycompany.basic . The processes section is color coded with shades of red representing medium to high use of processing power at that point in time. You can also see the functions that were most active for a given time slice ( shown by the thin vertical bar in the figure ) in the Head Up Display dialog titled Samples.

More details on the timeline view can be seen here.



Call Paths view
The call paths view shows statistics for the whole system. The report presents data hierarchically with processes listed at the top level and their threads beneath them. The Total column shows that for the duration of profiling, 15.51% of processor time was used by the Basic application. Most of that time, 14.91%, is in one single thread, thread 5. i.e. 96% of the application time is spent in this thread which makes it the obvious candidate for optimization, if you are looking at optimizing the application performance.

You can see more details on the call paths view here.





Functions view
The functions view shows performance statistics for functions on a system wide basis. Where the function name itself cannot be resolved due to lack of symbols (see footnote*) , the shared library or executable name is listed in square brackets [] .



ARM Streamline gives a bird’s eye view of Android systems running Airplay applications, with insights into how the application performance affects system performance. This blog shows how combining different tools in new ways can enable useful workflows for Android development, which are not possible when using tools in isolation.


Footnotes:

^#This article was created with version 4.4 of the Airplay SDK. The Airplay SDK is now known as Marmalade - see www.madewithmarmalade.com for more details.

*The [unknown] entries show up in the different views instead of the actual function names because the Airplay runtime loader (libbasic.so) loads the Basic application's .s3e file in a way that Streamline cannot resolve. The load address is determined at runtime and Streamline is unaware of it. Hence Streamline cannot resolve symbolic information against the samples collected, in order to generate specific function name and source code level information in the different views. Normally Streamline would do this when you point it at an ELF file containing the debug symbols for the application, by computing the load address from the elf file.

Vinod Krishnamoni, Engineering Manager – DS-5 Applications and Validation, ARM. Vinod leads ARM's DS-5 Applications engineering team which creates product examples, demos and supporting documentation. The team also supports technical marketing and FAEs with product demos and workshops and acts as voice of the customer to other DS-5 engineering teams. Before joining ARM, Vinod worked for several years with companies in the mobile communication industry, including Motorola and Symbian Ltd, in various software roles.