PERFORMANCE FOR ANDROID RUNTIMES
The first gen translators to convert assembly code to machine code were Assemblers. Since the translation was without any intermediate step, assemblers were fast. Then came the generation of compilers, which translates the high level code into assembly codes, then use assemblers to translate that assembly code into machine code. However the execution of the program was almost as fast as assembly code, the compiler was slower than assemblers for obvious reasons. C compiler is from this generation. In this approach, the problem was the code not being cross platform. The next generation was interpreters which translates the code while executing it. It reads a line and converts it into a binary command and executes it, then jump to the next line. The execution was slow, since the translation happens at runtime.However, Java uses a different approach. It uses a virtual machine (JVM) to make the apps cross-platform. These Virtual machines are specific to every platform. First, Javacompiler converts the .Java files into .class files or .jar files called byte code. JVM, further converts this byte code intomachine code. Since the byte code is same on any machine for some program, Java is cross platform. However it’s not exactly true when 32 bit and 64 bit byte codes are considered. This is still slower than C compilation but faster than interpretation.Android uses similar approach. Virtual machine on android converts the java files into byte code and put it into an apk file. The virtual machine used by android is Dalvik VM (until lollipop) which works similarly and uses JIT (Just in time) compilation. C/C++ code can also be implemented on Android using NDK (Native Development Kit) and integrated with Java using JNI (Java native interface), which is even slower.The reason that iOS apps are mostly faster than android apps is they use compiled native codes in ipa files (.a & .o files) as all of iOS devices follow the same architecture. Android can’t because android devices have a lot of variation in architecture.codeshoppy
ART uses different approach. ART compiles the apk into machine code during the process of installation of apk file. The compiled file, with the help of ART can be run directly by the device. The trade-off is, installation duration will increase because the compilation takes some time. Since compilation is done during installation itself, the apk will work as fast as Native C++ code. The compilation will follow device-specific architecture as it is done on device.Main features of ART as described below: (i)Ahead-of-time (AOT) compilation:ART compiles apps using the on-device ‘dex2oat’ during installation. This utility inputs dex files and generates a compiled app executable in the output for the target device. Some post-processing tools generates invalid files which cannot be compiled by ART, however may be tolerated by Dalvikmproved garbage collection:Garbage collection (GC) can also determines an app’s performance to an extent. Bad garbage collection may result in choppy display and poor user interface responsiveness etc. ART improves the garbage collection in ways like One Garbage Collection pause instead of two, Parallelized processing during remaining GC pause. ART makes concurrent garbage collections timelier. Collector are provided lower pause time to clean up of recently allocated and short-lived objects.(iii)Development and debugging improvements:Features like Support for sampling profiler etc. are offered by ART to improve app development and debugging.(iv)Improved diagnostic detail in exceptions and crash reports:ART provides deeper context and details when runtime exceptions occur. Classes like java.lang.ClassCastException, java.lang.ClassNotFoundException, and java.lang. NullPointerException are provided with expanded exception details in ART.ART completely replaces Dalvik in Android 5.0 lollipop. ART uses the same input bytecode as Dalvik to maintain backward compatibility which is supplied through standard .dex files as part of apk file, while ELF (Executable and Linkable Format) executables replaces .odex files. Once an application is compiled by dex2oat, it is run solely from the compiled ELF executable. This approach eliminates many overheads of JIT compilation, but it requires more installation time and applications uses more of the local storage to store the compiled code.
For finding an efficient runtime between the two, the lower demands on the hardware has been considered while doing the normal activities unlike the traditional methods of performance testing. Below is a list of three scenarios where a runtime should prove itself more efficient than the other: (i)Shorter Wakelocks: When a device sit idle, it wakes up often to perform the background tasks and consuming more power. An efficient runtime should complete the background executions quickly and get the device back to sleep again.(ii)Lower CPU Clock Cycles:An efficient runtime will allow the processor to do a particular job at the lower clock speeds. As a result, the beneficiaries like animations, scrolling and app switching will have very low lags or no lag at all.(iii)Better Use of Hardware:For a deeper optimization, lower demands also have to be considered. An efficient use of cores available on the devices make a runtime efficient. For example, if ARM’s big.LITTLE architecture is targeted, it will help in less power consumption and higher performance. In this architecture, high performance cores are paired with lower power cores where former is used for intense processing and the latter is used for simple tasks. A. Testing Setup A moto G (1st generation) device was used for running the benchmark testing which runs android on 4.4.2 (KitKat version). Wi-Fi and cellular networks were switched on during the testing, Bluetooth remained off the whole time. No apps were allowed to update during the testing. However there were 3rd party apps installed and running. This was to match it with real-world scenario. Benchmark testing app used was AnTuTu. Here are the results of thtesting.