Why Android does not have a deep comparison of iOS fast--ios and Android technology angles

First of all, this explanation is not my own writing, but I found the relevant information to sort out, but also for the jar to make some contribution, Wen also analyzed the Google three son and Samsung I9100, I hope this article on the technical level to provide a scientific evaluation of Android and iOS. If you can solve the confusion in our hearts, I would like to add a bit to the younger brother, in this first thank you. Andorid has updated one version to the next, with hardware ranging from single-core to dual-core to four-core, and the system's smoothness is basically flat with IOS.

But one wonders why the two systems are so different based on Linux. Why is the IPhone 4 with a single-core processor to achieve the smoothness of Android to high-end dual-core to guarantee?

Recently, Android development team engineer Dianne Hackborn A semi-official answer one of the reasons. Dianne Hackborn says, from the rendering of the interface UI itself,

First of all, Android from the first version of the use of graphics hardware acceleration, such as the Notification Bar drag, dialog box display and switch, and so on. Only versions prior to 3.0 were not fully accelerated with graphics hardware. Because Android is not a unified platform, each terminal has hardware differences, the system automatically adjusts the number of frames in the animation. A typical example is that the Nexus S can be rendered to 60fps, so it will be smooth enough. But with the same resolution milestone, because of hardware (GPU) performance problems, it will not be able to provide enough frame number to ensure smooth. In this way, its interface renders less than 60 frames, and we occasionally feel "cards" when used. And, even if hardware acceleration is turned on for the UI, the memory overhead of OpenGL technology can be very large, such as the PowerVR graphics chip, which consumes 8MB of memory, and the UI program itself is just 2MB of memory, which is too hard to draw. So, in order to ensure the smooth operation of different models, many times Android will use CPU graphics instead of hardware acceleration-note that the CPU has to do something else, so that the CPU to draw only slow speed. Prior to Android 4.0, hardware acceleration was present as an optional parameter (considering that some apps are not supported). However, starting with 4.0, this option will be enabled by default, and the development team is optimized for it, even if the hardware acceleration program is not supported. Dianne Hackborn finally said that hardware acceleration was not the only means of improving fluency. In fact, the Android development team has used a lot of technology such as improved rendering technology to improve the smoothness, the typical example is Android 3.0 browser compared to 2.2 has great progress. And with 4.0 spread out, more users can feel this. Dianne Hackborn did not evaluate how IOS was fluent. However, it is important to note that starting from the iphone 3GS, each generation of iphone graphics chip (GPU) is quite powerful (iphone 3GS, iphone 4, iphone 4S graphics processing chips are the same generation of mobile phones the highest level), and Apple IOS is a closed systems, we guess, Apple doesn't have much of a problem with Android in this regard. The Apple A5 Processor's integrated PowerVR SGX543MP2 graphics processor is quite powerful, killing almost every opponent in the Android faction, and another software engineer and former Google intern Andrew Munn explained that the Android system UI box The problem of frame design. In IOS The UI rendering process has an absolute priority, and when the user touches the IPhone's touchscreen, all the processes in IOS stop and all resources are used to render the UI process. In the Android system, the UI rendering process is not that high priority, that is, when you touch the Android phone screen, the system backstage program does not stop, still continue to run, such as downloading and checking text messages, so that the system UI access to resources is not enough, this is The reason why the Android system is not fluent. For this reason, the newly released Galaxy Nexus, even with a four-core processor, says that the EeePad Transformer Prime tablet does not guarantee a smooth operating experience that can only be compared with the 3-year-old IPhone's smooth-sliding levelSo why didn't the Android team solve the problem from the root? In fact, Android's development work began before the first IPhone was released, and the original Android prototype was designed to be used as a device for using a keyboard phone, the BlackBerry's competitor. UI rendering priority is not that important on a phone with a keyboard. But after the iphone was released, the Android team quickly turned Android into a touchscreen phone system to quickly launch products that could compete with the iphone, but it was impossible to rewrite the UI framework at that time. Because if all the apps in the Android app market become unusable, the relationship will always be in a vicious circle. No wonder Steve Jobs said in his biography that Android is a stolen product, even if Apple is bankrupt and wiped out. After Apple bought Steve Jobs's NeXT, it took six years to polish it into Mac OS x. It took another 2005 years or so to spend 2.5 of the time, based on which IOS was built. In a variety of sense, is a traditional technology operating system. IOS It has a micro-kernel Mach-based Darwin kernel, with a runtime called Cocoa Touch, with a superset of the C language of Objective-c. Android, on top of the Linux kernel, integrates a Java Virtual machine Dalvik, the entire application layer running on the virtual machine, and the development language is java. In fact, the choice between the two sides is very reasonable. Apple has the Mac OS X Decade Foundation, of course will choose its most proficient technology, IOS to create a traditional system, or can not sew the link to Mac OS X developer Resources. And Google has no operating system experience, in order to strive for the largest developer resources, they chose the world's largest Java community. Although the starting point is the same, the first step out of the direction has been diametrically opposed. The bottom of the problem is that Java only has automatic memory recycling, and objective-c is automatically and manually recovered (note that IOS only has manual memory recycling). The small difference is that Google can only do a Java virtual machine, and Apple could continue their experience on MAC OS X.This behavior leads to the greatest difference in system fluency between the two. Java because only automatic memory recycling, the system will stop at any time all processes start to reclaim memory, this process is human can feel the hundreds of milliseconds. While IOS can manually manage memory, it can be recycled by the programmer at the interval of user action, and users will not feel the pause during frequent use. In the daily use of this pause can be tolerated, but in the course of the game this pause is not to endure, for example, imagine an angry bird in the air paused for fraction seconds to continue to fly. Google was actually aware of the problem, so it overhauled the issue in Android 2.3 and particularize it as a feature. And aside from the popularity of 2.3, the behavior of this overhaul has not been fixed. So Google throws a second patch on development: the introduction of the C + + NDK. Can say this step, Android entire kernel up to the application layer to compete with IOS strength, but the time has passed nearly four years, IOS accumulated 15 years, Android just started. And under the kernel? Darwin based on micro-core Mach What about today's server mainstream Linux? The Linux founders once argued with a bull about a famous rack, and it is about microkernel and kernel contrast, Linus until now that the micro-core is just a paper and in the reality of the solution No practical problems. In the years after this quarrel, the mainstream system of sticking to the kernel is only a Linux one, and the microkernel system has been extended to SVR4-based IBM Aix/hp-ux, Gnu/hurd, Mac OS X, Blackberry QNX, Windows (yes, you didn't See the wrong). Time will tell, this sentence has never been wrong. Android three-party ROM is plagued by the drive problem, is the biggest limitation of the Linux kernel, rooted in bones disease is not good.

Here are some ideas from the third Google internal engineer about the Android graphics system.

1. Android has been using hardware acceleration. In fact, from the 1.0 version, all of the window elements of the composition and display are done by hardware.

2. This means that many of the animations you see are accelerated: The display of the button, the drop shadow in the notification bar, the toggle animation between different Activity, the popup window and the display and hiding of the cue box, and so on.

3.Android previously used software (as opposed to hardware acceleration) to control the rendering of individual window elements, such as the UI, which includes four window components: status bar, wallpaper, launcher on the desktop, and menus. If one of the elements changes its content, such as highlighting a menu entry, for versions prior to 3.0, the system uses software to draw new content, but not all elements need to be redrawn, and the stitching of the various window elements is done by hardware. Similarly, the Movement of any window: for example, the top and bottom motion of a menu is completely rendered by hardware.

4. Now let's focus on the internal rendering of the window elements, and in fact you don't necessarily need hardware acceleration in order to reach FPS at 60 frames per second. The frame rate depends on the number of pixels to display and the speed of the CPU. For example, the second son can complete any normal native UI animation at a 60FPS speed on its 800*480 resolution screen, such as scrolling the list, without any problems at all. and the original Droid series was hard to reach at that rate.

5. The "full" hardware-accelerated drawing of Windows can be achieved in Android3.0. And no more features were introduced in Android 4.0. Starting with 3.0, if you set a flag in your app to allow hardware acceleration, all of the windows will be drawn to the GPU at this point. The main change in Android 4.0 is that hardware acceleration is turned on by default in applications that target Android4.0 or later, and no longer need to set android:handwareaccelerated= "true" in the configuration file. (And we don't allow the previous app to turn on hardware acceleration by default, because hardware acceleration is not good for some special drawing operations, and some of its performance is affected when the app needs some UI updates.) For many existing applications, forcing hardware acceleration will significantly disrupt the operation of the application.

6. Hardware acceleration is not as perfect as everyone thinks. For example, on a PVR-driven device (such as two sons and three sons), it takes 8M of RAM to open OpenGL in the process. The overhead of 2M compared to the average process is huge. With a limited amount of RAM and a large portion being drawn, other running processes are having problems with missing memory, such as reducing the speed of switching between applications.

7. Because of the extra overhead of OpenGL, we'd better not use it too much for drawing. For example, some of the work we're doing now is for Android 4.0 to be able to run smoothly on the second son without using hardware acceleration: So we don't need to waste 8MB of memory in the system process, or waste an extra 8 m of memory in the phone process, or in the system UI process 8MB of memory and so on. Trust me, you won't notice that using OpenGL to draw something like a status bar or a gorgeous animation is no good at all.

8. Hardware acceleration is not a "cure" for a smooth UI. We have tried many different methods for the smooth UI, such as the scheduling strategy of the foreground/background process introduced in 1.6, the rewrite of the input system in 2.3, the use of "severe mode", the garbage collection mechanism, the loader and so on. If you want to achieve a frame rate of 60fps, you have only 20 milliseconds to process the contents of each frame. This is not a long time, just the delay in reading the memory card in the UI process will be greater than that, especially when writing.

9. Some recent examples that affect the smoothness of the UI: we note that on the second son, the use of 4.0-time list scrolling is not as smooth as using 2.3. The reason for this is the slight drift of the timer: Sometimes the application is receiving a touch event and drawing on the screen, and when the previous action is not completed, it accepts the next event and starts drawing, causing it to lose the current frame. Despite this phenomenon, the frame rate can reach a stable 60FPS. (Of course, this issue has been fixed)

10. When people compare the scrolling smoothness of Android with the browser on IOS, the difference they see is not caused by hardware acceleration without opening. Initially, Android used a completely different rendering strategy and made some compromises: the Web page was converted to a "display list", which was continuously drawn on the screen rather than in the form of a block (Tiles). It has one advantage: that is, when scrolling or zooming, it does not happen that some blocks have not yet been rendered (the translator notes: This phenomenon is very obvious on early IOS, and when you scroll quickly to the bottom, you will have to wait for a piece of the page to be drawn). The point of this method is that when the page is complex, the frame rate is significantly lower. For example Android3.0, the browser now begins to render using blocks, so it can maintain a stable frame rate when scrolling or zooming in, and there will naturally be cases where new blocks are not rendered immediately. and each block is drawn in software, and I believe it is the same in IOS. (In versions prior to 3.0, hardware acceleration was not turned on, and block-based policies were also available.) And as I mentioned before, the second son can easily reach 60FPS)

11. Hardware acceleration does not magically make the drawing problem disappear as you would expect. The performance of the GPU is a very important limitation. A very interesting example: the Nvidia-based TEGRA2 tablet makes it easy to access any one pixel in a screen at a speed of up to 60FPS with a resolution of 2.5 1280*800. Now consider the case of switching to all apps list in Android 3.0: you need to draw the background (1x all pixels), then the shortcut and desktop gadget (assuming the content is not much, it costs 0.5x), then the black background (1x) for all the apps, then the ICON for all apps (0.5x )。 Obviously, we have surpassed the original budget, and at this point we have not completed the concatenation of individual window elements and made the final display. To get 60FPS animations, Android 3.0 and subsequent versions use a series of tips. One of the main things is that it tiles all the window elements in one layer, rather than copying them into the CPU cache. But even so, we are already over budget, fortunately we use another trick: because the background of Android is a separate window element, we can set it larger than the screen to place the entire bitmap, now, the user began to slide, the background with the movement, at this time do not need any special drawing, Just move the window, and since this window is on a tiled layer, we don't even need to use the GPU to organize this window element into the screen output.

12. As the screen resolution continues to rise, the ability to reach 60FPS is closely related to GPU speed, especially memory bus bandwidth. In fact, if you want to improve the effectiveness of your hardware, pay particular attention to increasing the bandwidth of the memory bus. Many times the CPU (especially the CPU with the perfect NEON instruction set) is more than the memory bus block. Some people think that the rabbit has a very fluent UI and that they have gone beyond the three sons and made a lot of improvements. In fact, we ignore a lot of equipment differences, the 480*800 Rabbit's screen is the three sons are 720*1280. If the second son can reach 60FPS on its 480*800 screen, the rabbit with the more NB CPU must have the same fluency. The biggest difference between the two is that the three sons need to draw 2.4 times times as many pixels as the rabbit. This is equivalent to 2.4 times times faster on a single core. (It is important to point out that multicore is meaningless in UI rendering, because rendering must be done in one process and not in parallel) that's why hardware acceleration is essential: with the increase in pixels, the GPU is generally better able to handle the operation of the image. In fact, this is the biggest power we've introduced to hardware acceleration in Android. On the 720*1280 screen, the existing ARM CPU reaches 60FPS very hard, but the GPU rendering is different. Similarly, in the comparison with the Furious rabbit, while opening an application without hardware acceleration, the same 60FPS was not achieved in the three sons, because it had to render 2.4 times times the pixel of the rabbit. In the end, there is another advantage of the GPU: many of the effects of drawing are made easier. For example, if you want to draw a bitmap in software form, you can't do anything but set a displacement. It takes a considerable amount of time to render just to zoom out. In the GPU, this type of conversion is fairly easy. This is the new default theme for God horse Holo uses hardware acceleration to draw the background. In applications where hardware acceleration is not enabled, such backgrounds are automatically removed from the ~

Why Android does not have a deep comparison of iOS fast--ios and Android technology angles