In the footsteps of myth destroyers or Why Android slows down, and% is not a mobile OS%?

Good afternoon, Habr!

My previous translation of the article about hardware acceleration in Android caused a heated discussion in the comments, the main motive of which was the question “so why does Android slow down?”. A similar situation is observed throughout the Internet, and therefore I give below another very interesting and fresh translation (again from Google+), where the author Andrew Munn (about him below) analyzes the real causes of Android brakes. I enjoyed reading this post myself and proud of the opportunity to be the first to share it with the habrasoobschestvom.
')

Why Android slows down, while iOS, Windows Phone 7, QNX and WebOS are so smooth in their work?

This post is designed to answer this question.

However, before moving on to the point, a few reservations. First of all, I am a third-year student in the field of software engineering. I was interned in the Android team, and Romain Guy, who was responsible for most of the hardware acceleration work in Honeycomb, reviewed some of the sections and my code, but I was not in the team developing the framework itself, and I never read the source code of the rendering code in Android. I do not have any serious authority on the knowledge of Android and I can not guarantee that I speak here, be sure to be 100% accurate, but I did my best to argue my words.

Secondly, I'm on an internship at the Windows Phone team starting in January, so it’s quite possible that this post could subconsciously turn me against Android, but if you ask any of my friends, it’s really difficult to ask me not to chat about Android I have more Android T-shirts than days a week, and I would prefer to give away my Macbook than my Nexus S. Googlplex is like a second home. In any case, my interests are probably biased in favor of Android.

So let's proceed to the analysis of the previous article on myths (this is the full version of Diana Hackborn's post).

Diana begins her post with an amazing revelation:

“Looking at the rendering inside the window, we do not have to use hardware acceleration to achieve the full 60FPS. It largely depends on the number of pixels in the display and the speed of your processor. For example, the Nexus S has no problems with 60 frames per second for all the normal things you see on the Android UI, such as scrolling through lists on its 800x480 screen. ”

Yah? How can this be? Anyone who has used the Nexus S knows that it slows down with everything except simple ListViews. And forget about any kind of decent performance, if in the background, something happens, such as installing an application or updating the user interface from the internal drive. On the other hand, iOS works 100% smoothly even when installing applications. But we know Diana is not lying about the potential performance of the CPU, so what happens?

The main reason

This is not a pause due to the garbage collector. This is not because Android works via bytecode, but iOS works on native code. This is because in iOS, the rendering of the entire interface occurs in a separate user interface stream in real-time priority mode. On the other hand, Android follows the traditional PC model, in which the main rendering takes place with normal priority.

This is not an abstract or academic difference. You can see it on your own. Grab the nearest iPad or iPhone and open Safari. Start downloading a complex webpage such as Facebook. In the middle of loading, put your finger on the screen and move it around. All rendering stops instantly. The site simply will not load until you remove your finger. This is because the UI thread intercepts all events and the UI is rendered in real time.

If you repeat this exercise on Android, you will notice that the browser will try to both render the page and display the HTML, i.e. do "perfectly well" both one and the other. For Android, this is the case when an effective dual-core processor really helps, which is why the Galaxy S II is famous for its smoothness.

On iOS, when the application is installed from the App Store, and you put your finger on the screen, the installation will instantly pause until rendering is complete. Android tries to do both with the same priority, so the frame rate suffers. As soon as you notice how this happens, you will see that it is everywhere on your Android phone. Why is scrolling slow in the Movies app? Because movie thumbnails are dynamically added to the movie list when you scroll down, but on iOS, they are quietly added only when the scrolling stops.

Several people undertook to explain the mistakes I made in the simplified description of the drawing process in iOS. In particular:

1) Compositing and pre-tuning of animation - everything that includes Core Animation and rendering of accompanying layers really occurs in the background thread.

2) Rendering of new content in the Core Animation layer and setting up their animation occurs in the main stream. This is the same thread in which the user interface is drawn.

3) In the native code, all the code created by the developer will occur in the main thread. However, Apple offers a very simple API (Grand Central Dispatch and NSOperation) to move these things into system-managed background threads. In iOS 5, you can even state that Core Data (object-relational databases) context cannot be used directly in the main thread.

What do we notice? The image is not rendered until you finish scrolling through the list, the page rendering in WebKit stops, when the system tracks the touch of the screen, this is the initially built-in mechanism that pauses the whole world while the finger is on the screen.
(Actually, this is not quite true: the main thread is placed in a special mode while monitoring the sensor, and by default, certain callbacks are delayed in this mode. However, many other things, such as booting from disk or network activity, are stored completely in the background thread, without stopping, none of this automatically pauses at the time of scrolling. The developer must clearly indicate the delay for these things). This deliberate behavior is carefully implemented by the developer of each individual application.

This is not a technical difference, it is a cultural difference. Good iOS developers do not release software until it works at about 60 frames per second when scrolling and tracks touches almost perfectly, as well as good Android developers do.

Other reasons

The main reason why Android slows down is the structure of UI threads and their priority, but this is not the only reason. First, hardware acceleration, despite Diana’s reservations, still helps. My Nexus S has never worked so smoothly since upgrading to ICS [note translation: Mine too! :)]. Hardware acceleration makes a huge difference in applications such as the home screen and the Android Market. Help provided by the GPU also increases battery life, because graphics processors are hardware with fixed functions, so they work with less power consumption.

Secondly, contrary to what I stated earlier, garbage collection is still a problem, even when working part-time with GC in Dalvik. For example, if you have ever used a photo gallery app in Honeycomb or ICS, you might wonder why the frame rate is so low. It turns out that the frame rate is limited to 30 frames per second, and scrolling of photos is possible at 60 FPS in most cases, but sometimes the garbage collector pauses lead to a noticeable “stutter”. Limiting the frame rate to 30 fixes "stuttering" and provides smooth animation all the time.

Thirdly, there are problems with the equipment, which is also mentioned by Diana. Tegra 2, despite the ambitious claims from the Nvidia marketing department, is detrimental to low memory bandwidth and does not support the NEON instruction set (the NEON instruction in ARM is the equivalent of Intel's SSE, which allow you to quickly calculate matrices per CPU). Honeycomb tablets would be better with different GPUs, even if they were theoretically less powerful in some respects than Tegra 2. For example, Samsung Hummingbird in Nexus S or Apple A4. This tells us that the fastest Honeycomb-released tablet, Tab Galaxy 7.7, runs on an Exynos processor with the Galaxy S II.

Fourth, Android has a way to switch to more efficient user interface compositing. in iOS, each type of user interface is displayed separately and stored in memory, so for many animations only a GPU is required to view the recomposition of the user interface. GPUs are very good at this. Unfortunately, on Android, the user interface hierarchy is flattened before rendering, so the animation requires redrawing every sector of the screen in which it occurs.

Fifth, the Dalvik VM is not as advanced as the desktop JVM. Java is notorious for the terrible performance of GUIs on desktops. However, many issues are not transferred to the implementation of Dalvik. Swing was terrible because it was a cross-platform layer on top of the native API. It is interesting to note that Windows Phone 7 in the main user interface is built on native code, although the original plan was to be based entirely on Silverlight. In the end, Microsoft decided that to give the interface the necessary performance, the code should be native. It's easy to see the difference between native and bytecode on Windows Phone 7, since third-party applications written in Silverlight are inferior in performance (Nodo and Mango have mitigated this problem and Silverlight interfaces are usually very smooth now).

Fortunately, each of the five questions listed above will be resolved without radical changes in Android. Hardware acceleration will be on all Android ICS phones, Dalvik continues to improve the efficiency of its garbage collector, Tegra 2 will finally become obsolete, there are workarounds for existing interface composition problems, and Dalvik VM becomes faster with each release. I recently asked Jason Kincaid with TechCrunch how smooth the Galaxy Nexus was and he responded:

“In general, I found the Galaxy Nexus ICS fairly smooth in operation. There are random stutters - one place where I can get consistently scared on the Galaxy Nexus, this is when I press the multitasking button, where it will often be suspended for a quarter of a second. However, I believe that the iPhone 4S also slowed down more than I expected, especially when I switched to accessing the general search for apps (where you swipe left from the main screen). ”

So, let's go, the Android brake problem is basically solved, isn't it? Not so fast.

Forward to the future

The Android UI will never be completely smooth due to the design constraints that we discussed at the very beginning:

- Rendering of the interface occurs on the main flow of the application;
- Rendering of the interface occurs with normal priority;

Even with the Galaxy Nexus, or EeePad Transformer Prime quad-core processor, there is no way to ensure smoothness and an acceptable frame rate if these two design constraints remain in force. This says that the power of the Galaxy Nexus will be enough to compare the smoothness of the work with the first iPhone three years ago. So why did the Android team use just such a rendering structure?

Work on Android began even before the release of the iPhone, and at that time the Android system was designed to be a competitor to the Blackberry. The original Android prototype did not have a touch screen. Android tradeoffs make sense of devices with a hardware keyboard and trackball. And when the iPhone came out, the Android team rushed to release a competitor to this product, but, unfortunately, it was too late to rewrite the entire user interface of the system.

This is the very reason why Windows Mobile 6.5, Blackberry OS, Symbian have terrible touchscreen performance. Like Android, they were not designed to “prioritize” the rendering of the user interface. After the release of the iPhone, RIM, Microsoft, and Nokia abandoned their mobile operating systems and started developing from scratch. Android is the only mobile OS that existed before the “iPhone era”.

So why didn't the Android team change the status quo? I will let Romain Guy explain:

"... A lot of the work that we have to do today exists because of a certain choice made many years ago ........ The animation of the user interface is the biggest problem. We are working on other solutions to try to improve it (the ability to use a separate rendering stream, and etc.). A simple solution, of course, is the creation of a new graphical toolkit, but there are many drawbacks to this approach. "

Romain does not specify what the disadvantages and disadvantages in this decision, but it is not difficult to assume:

- All applications must be rewritten to support the new structure;
- Android will have to provide support mode for older applications;
- Work on other features of Android will be suspended until the new system is developed;

However, I believe that writing from scratch should happen, despite these drawbacks and flaws. As a novice manager, I think Android’s sluggishness is absolutely unacceptable. You should make this question a priority number 1 for the Android team.

When the topic of Android rises as a technically savvy and non-technically educated friends, I hear again and again that Android slows down and works slowly. The reality is that Android can open applications and display web pages as quickly or even faster than iOS, but perception is everything. Fixing a braking UI this will be the beginning of a long journey to restore the reputation and image of Android.

The perception of a problem, a brake, is a violation of Google’s philosophy. Google thinks everything should be fast. Here is the leading philosophy of Google Search, Gmail, and Chrome. That’s why Google created SPDY to improve HTTP. That’s why Google creates tools to help optimize your site. That’s why Google launches its own CDN. That is why Google Maps is displayed using WebGL. That is why buffering on Youtube is something that most of us remember well, but see less and less.

But perhaps one of the most important reasons for the backlog in the Android interface unacceptably comes from the field of human-machine interaction (HCI). Modern touch screens assume a one-to-one correspondence between the finger and the animation on the screen. That is why the effect of re-scrolling in iOS (elastic) is so cool, fun, and intuitive. And that's why Virgin America Flights airline touchscreens are so frustrating: they are incredibly slow and very inaccurate.

The user interface brakes interrupt the connection between the person and the touchscreen. Communication with the device ceases to be natural. It loses magic. The user is excluded from interaction with them and must unconditionally recognize that they use imperfect computer modeling. I often “get lost” in the iPad, but it distorts me even more when Xoom stutters between the screens. 200 million Android users deserve the best.

And I know they will get it eventually. The Android team is one of the most dedicated and talented development teams in the world. With stars such as Diana Hackborn and Romain Guy Android is in good hands.

I hope that this post will reduce confusion around the Android brakes.
A bit of luck, and Android 5.0 will bring us the smooth Android we all dreamed about since the release of the HTC G1. At the same time, I will be working in Redmond on a beautiful and smooth mobile OS, and try to give her some of the recognition she deserves.