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

Original author: Andrew Munn
  • Transfer


Good afternoon, Habr!

My previous translation of an 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 all over 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 am proud to be the first to share it with the habrasociety.



Why is Android slowing down while iOS, Windows Phone 7, QNX and WebOS are so smooth?


This post is intended to answer this question.

However, before moving on to the point, a few reservations. Firstly, I am a third-year student with a degree in software engineering. I was interned in the Android team, and Romain Guy, who was responsible for most of the hardware acceleration work at Honeycomb, reviewed some areas of my code, but I was not in the team developing the framework itself, and I never read the source code for the rendering code in Android. I don’t have any serious authority on knowing Android and I can’t guarantee that I’m talking here, it’s 100% accurate, but I did everything possible to argue my words.

Secondly, I’ve been on an internship in the Windows Phone team since January, so it’s possible that this position could unconsciously set me up 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 rather give away my Macbook than my Nexus S. Googlplex is like a second home. In any case, my interests are perhaps biased in favor of Android.

So, let's start the analysis of the previous article on myths (we are talking about the full version of Diana Hackborn's post).

Diana begins her post with an amazing revelation:

“Looking at the rendering inside the window, we don’t have to use hardware acceleration to achieve full 60FPS. This 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 in 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 for everything except perhaps simple ListViews. And forget about any semblance of decent performance, if something happens in the background, for example, installing an application or updating the user interface from an 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 through bytecode, but iOS runs on native code. This is because in iOS, the rendering of the entire interface takes place in a separate user interface thread in real-time priority mode. On the other hand, Android follows the traditional PC model, in which the main rendering occurs with normal priority.

This is not an abstract or academic difference. You can see it for yourself. Grab your nearest iPad or iPhone and open Safari. Start downloading a complex web page such as Facebook. In the middle of loading, place your finger on the screen and move them around. All rendering instantly stops. The site will simply not load until you remove your finger. This is because the user interface thread intercepts all events and the user interface 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 render HTML, i.e. make "excellent" as one or the other. For Android, this is the case when an efficient dual-core processor really helps, that's 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 the rendering is complete. Android tries to do this and that 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 the Android phone. Why is scrolling slow in the Movies app? Since movie thumbnails are dynamically added to the movie list when you scroll down, but on iOS, they are quietly added only when the scroll stops.

Several people undertook to explain the errors that I made in a simplified description of the rendering process in iOS. In particular:

1) Compositing and pre-setting animations - all that includes Core Animation and rendering of companion layers really happens in the background stream.

2) Rendering of new content in the Core Animation layer and setting up their animation takes place in the main stream. This is the same stream 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-driven 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 drawn until you finish scrolling through the list, the page rendering in WebKit stops when the system monitors the touch on the screen, this is an initially built-in mechanism that pauses the whole world while the finger is on the screen.
(Actually, this is not entirely 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 loading 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 explicitly indicate delays for these things). This intentional behavior is carefully implemented by the developer of each individual application.

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

Other reasons


The main reason why Android slows down is the structure of the UI threads and their priority, but this is not the only reason. First, hardware acceleration, despite the reservations of Diana, 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 like the home screen and Android Market. The help provided by the GPU also increases battery life, because GPUs are equipment 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 in conjunction with GC in Dalvik. For example, if you have ever used the photo gallery application in Honeycomb or ICS, you may wonder why the frame rate is so low. It turns out that the frame rate is limited to 30 frames per second, and photo scrolling is possible at 60 FPS in most cases, but sometimes pauses in the garbage collector lead to a noticeable “stutter”. Limiting the frame rate to 30 corrects stuttering and ensures smooth animation all the time.

Thirdly, there are problems with the equipment, which is also mentioned by Diana. Tegra 2, despite the grand claims from the Nvidia marketing department, is detrimental to low memory bandwidth and does not have support for the NEON instruction set (NEON instructions in ARM are the equivalent of Intel SSE, which allow faster calculation of matrices on the 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 tablet released, the Tab Galaxy 7.7, is running an Exynos processor with the Galaxy S II.

Fourth, Android has a way to switch to more efficient user interface compositing. in iOS, each kind 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 hierarchy of the user interface is flattened to rendering, so the animation requires redrawing each sector of the screen in which it occurs.

Fifthly, Dalvik VM is not as developed as desktop JVM. Java is notorious for the terrible desktop GUI performance. However, many issues are not carried forward 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. Microsoft finally decided that in order to give the interface the necessary performance, the code should be native. It is 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 mitigated this problem and Silverlight interfaces are usually very smooth now).

Fortunately, each of the five issues listed above can be resolved without radical changes to Android. Hardware acceleration will be on all phones running Android ICS, Dalvik continues to improve the efficiency of its garbage collector, Tegra 2 is finally outdated, there are workarounds for existing interface composition problems, and Dalvik VM is becoming faster with each release. I recently asked Jason Kincaid with TechCrunch how smooth the Galaxy Nexus was and it answered:

“In general, I found the ICS on the Galaxy Nexus fairly smooth in operation. There are random stuttering - one place where I can get funk on the Galaxy Nexus sequentially is when I press the multitasking button, where it often pauses 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 access to the general search for applications (where you swipe to the left of the main screen). ”

So there you go, the Android brakes problem is basically resolved, right? Not so fast.

Forward to the future


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

- The interface is rendered on the main thread of the application;
- Interface rendering occurs with normal priority;

Even with the Galaxy Nexus, or the EeePad Transformer Prime quad-core processor, there is no way to guarantee smoothness and an acceptable frame rate if these two design restrictions remain in effect. This says that the power of the Galaxy Nexus is enough to compare in smooth operation 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 compete with Blackberry. The original Android prototype did not have a touch screen. Android compromises make sense with 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 already 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 touch screen performance. Like Android, they were not intended to “prioritize” user interface rendering. After the release of the iPhone, RIM, Microsoft, and Nokia abandoned their mobile OS and started development from scratch. Android is the only mobile OS that existed before the "iPhone era."

So why the Android team has not changed the current state of affairs? I will let Romain Guy explain:

"… Много работы, которую мы должны сделать сегодня, существует из-за определенного выбора, сделанного много лет назад…… С анимацией пользовательского интерфейса самая большая проблема. Мы работаем над другими решениями, чтобы попытаться улучшить её (возможность использования отдельный поток рендеринга, и т.д.). Простое решение, конечно, это создание нового графического инструментария но есть много минусов в этом подходе. "

Ромен не уточняет какие минусы и недостатки в этом решении, но это не сложно предположить:

— Все приложения должны быть переписаны для поддержки новой структуры;
— Android должен будет обеспечить режим поддержки для старых приложений;
— Работа на другие особенностями Android будет приостановлена, до то времени как новая система будет разработана;

However, I believe that writing “from scratch” should happen, despite these minuses and disadvantages. As a novice manager, I find Android slowness to be completely unacceptable. This issue should be made # 1 priority for the Android team.

When the Android theme is raised by both tech-savvy and non-tech-educated friends, I hear over and over that Android is slow and slow. The reality is that Android can open applications and display web pages as fast or even faster than iOS, but perception is all. Fix braking UI this will be the beginning of a long journey to restore the reputation and image of Android.

Perception of the problem, brakes - this is a violation of the philosophy of Google. Google believes everything should be fast. Here is the leading philosophy of Google Search, Gmail, and Chrome. That's why Google created SPDY - to improve HTTP. This is why Google is creating tools to help optimize your site. That is why Google is launching 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 lag in the Android interface is unacceptably coming from the field of human-machine interaction (HCI). Modern touch screens assume a one-to-one relationship between the finger and the animation on the screen. That is why the scrolling effect in iOS (elastic band) is so cool, fun, and intuitive. And that's why Virgin America Flights’s touchscreens are so frustrating: they are incredibly slow and very inaccurate.

User interface brakes interrupt the connection between the person and the touch screen. Communication with the device ceases to be natural. It loses magic. The user is excluded from interacting with them and must unconditionally acknowledge that they are using imperfect computer modeling. I often get lost in the iPad, but I am already cringing when the Xoom stutters between screens. 200 million Android users deserve the best.

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

I hope this post will reduce confusion around Android brakes.
A bit of luck, and Android 5.0 will bring us the smooth Android we've all dreamed about since the launch of 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.

Also popular now: