Optimization of Android applications for x86. 2GIS Experience

Probably, it makes no sense for Habra readers to submit 2GIS - Russian geoservice, which has become the most important source of information for residents of many cities of our (and not only) country. Service developers pay great attention to mobile applications - the product is available for various mobile operating systems and is among the best free applications in the “map” and “navigation” categories on Google Play and the App Store.
Mobile devices with Android OS based on x86 are possible, while a little less than 2GIS are known, but with a constant increase in the range, their popularity is growing.
We invited 2GIS to visit the Intel blog to ask them a few questions about optimizing the mobile version of the program for the x86 architecture. Answers prepared by Sergey Galin - Head of the 2GIS mobile development team.

How does your application work in terms of using native code? Those. How big is his percentage, what exactly is being done natively and why?
Our Android app works in 99% native code - i.e. absolutely everything except the process of starting the application and working with the Android API. Including rendering the entire user interface "in-house", without using the functions of the operating system for rendering. This is a cross-platform application based on Qt 4.8 (the port on Android is our own). It happened historically, since the development began for Symbian and Windows Mobile, then I wanted to add Android (at that time, Android 2.2). However, taking into account the “gravity” of our application, which in real time draws a 3D map and works with a huge offline database, the Android “default” approach with Java development simply would not “take out” - neither in speed, nor in terms of volume. random access memory. In the native code, we can do almost the same functional application as on a regular desktop computer, and run it even on a budget phone sample of 2011.

Are you and your users satisfied with the performance of existing ARM versions of applications? Is there a performance margin to extend the functionality?
Yes, it does, for modern devices and tops of 2012 :) Budget phones of the past years and even older flagships, unfortunately, work on the verge of possibilities, and the performance in some places really leaves much to be desired. At the same time, there are practically no opportunities for optimization with this application functionality for many obsolete devices.
It will be very good for us if Intel really strengthens the competition and accelerates the expansion of the user audience towards more powerful devices!

Why was it decided to release the x86 version?
Because it was really easy to do! And it was not cool that the application works bad on excellent devices with Intel processors.
We are now busy, among other things, with a systematic expansion of support for devices and platforms, so it fits well with our plans.
And thanks to Intel for providing the devices, without them it would have been more difficult to get the subject off the ground :)
')
What exactly was the addition of x86 support - how many files / lines of code did you need to change?
Code in the application - almost at all. The Qt build configuration has been modified to enable it to support x86. I had to patch the macros in a pair of third-party libraries, which until then had been convinced that “Android means ARM”. Then our build scripts for the x86 build were modified - this took most of the time. Proof-of-concept was made in 1 day, and in general, about 1 man-week was spent on embedding x86 into the process, not counting testing. For such a huge project it is very fast!
The fact is that our codebase is used both on desktops and servers, and the development of the mobile version itself is mainly done under normal Linux and Windows desktops (not in the emulator, but in the usual build for these OS - thanks to Qt, we can do this very easily), so all the code is initially debugged for x86.

How technically implemented support for x86 and ARM versions = i.e. you have separate apk or one general, how is the compilation going on (are both versions automatically compiled or is there a choice?) The same question about testing.
Separate APK. By the way, since we switched to such a scheme, then at the same time we implemented packages optimized for ARMv7, so we got 3 packages: ARMv5, ARMv7 and x86.
The auto-assembly system assembles either one version of your choice (to quickly get a fresh build), or all three at once (for acceptance testing and publishing).
Acceptance testing must be carried out on at least two platforms, and the third can then be checked quickly ("smk-testing"). In fact, we have never faced the fact that some bugs were specific for some CPU ABI :) Android on x86 behaves the same way as on ARM, no incompatibilities have been found yet.

What does the comparison of x86 performance and power consumption with an ARM version running on the same device through a binary translator show?
We did not make a numerical comparison, because the difference is too great. Since our application even draws the UI from the native code itself, in the broadcast mode everything worked just barely, and the power consumption just went off scale - the phone warmed up like a stove. After compilation, 2GIS "flew", as it should - the program "rests" already in reading data from memory and screen frames (vsync), and there is now even a margin for processor power. The gain in speed and energy consumption compared to the translator is about an order of magnitude.