Optimization of Android applications for x86. 2GIS Experience

    Probably, it doesn't make sense to readers of Habra to present 2GIS - the Russian geoservice, which has become the most important source of information for residents of many cities of our (and not only) country. The developers of the service pay great attention to mobile applications - the product is available for various mobile OS and is one of the best free applications in the categories of “maps”, “navigation” on Google Play and the App Store.
    Mobile devices with Android OS based on x86 may be known for a little less than 2GIS, but with a constant increase in assortment, their fame is growing.
    We invited 2GIS to visit Intel's blog to ask them a few questions about optimizing the mobile version of the program for x86 architecture. Answers prepared by Sergey Galin - Head of the mobile 2GIS development team.

    How does your application work in terms of using native code? Those. how big is its percentage, what is being done natively and why?
    Our Android application runs 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 on its own, without using the operating system for rendering functions. This is a cross-platform application based on Qt 4.8 (the port on Android is our own). This happened historically, since 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 draws a 3D map in real time and works with a huge offline database, the “default” approach of Android with Java development would simply not “take out” - neither in terms of speed, nor in the amount required random access memory.

    Are you and your users comfortable with the performance of existing ARM versions of applications? Is there a margin of performance left for expanding functionality?
    Yes, it suits for modern devices and tops of 2012 :) The budget phones of 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 outdated devices.
    It will be very good for us if Intel really intensifies 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 wasn’t cool that on excellent devices with Intel processors the application does not work well.
    We are now busy, among other things, with the systematic expansion of support for devices and platforms, so this fits well with our plans.
    And thanks to Intel for the provided devices, without them it would be more difficult to move the topic off the ground :)

    What exactly was the addition of x86 support - how many files / lines of code did you need to change?
    The code in the application is practically not at all. The configuration of the Qt assembly was improved so that it could support x86. I had to patch macros in a couple of third-party libraries, which before that were sure that “Android means ARM”. Then our assembly scripts for assembling x86 were modified - this took most of the time. Proof-of-concept was done in 1 day, and in general, it took about 1 person-week to integrate x86 into the process, not including testing. For such a huge project, this is very fast!
    The thing is that our code base is used both on desktops and on servers, and the development of the most mobile version is mainly carried out under ordinary desktop Linux and Windows (not in the emulator, but in the usual assembly for these OSs - 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 common one, how does the compilation happen (both versions are automatically collected or is there a choice?) The same question about testing.
    Separate APKs. By the way, since we switched to such a scheme, at the same time we implemented packages optimized for ARMv7, so we have 3 packages: ARMv5, ARMv7 and x86.
    The auto assembly system collects either one version to choose from (to quickly get a fresh build), or all three at once (for acceptance testing and publication).
    Acceptance testing must be carried out on at least two platforms, and the third can then be checked accelerated (“smok testing”). In fact, we have never once encountered any bugs specific to any CPU ABI :) Android on x86 behaves the same as on ARM, no incompatibilities have been detected so far.

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

    Also popular now: