Comparison of Rendering Architecture Differences Between Android and iOS: Which is Superior?

The article compares the rendering architecture differences between Android and iOS, pointing out that neither platform directly renders through CPU. The actual rendering is done by Android’s SurfaceFlinger and RenderThread, as well as iOS’ render server. It emphasizes that lower-level APIs such as Metal and Vulkan have a greater impact on rendering performance, and also compares the characteristics and usage differences between Metal and Vulkan.

Related questions: What are the advantages of Android rendering? What are the difficulties in iOS rendering? Can Metal be adapted to Android?

Recently, I received a question on Medium about the differences in rendering architecture between Android and iOS. The questioner raised some doubts about the description, but I think it’s an interesting topic.

Actually, I think this should be more about the difference between Metal and Vulkan, not SurfaceFlinger and backboardd.

Why do I say that? Let’s first briefly distinguish the differences in rendering frameworks at the framework level for Android and iOS.

Android

On Android, all content is rendered to a Surface. Most Surfaces come from Windows, and after calling Canvas.draw at the framework level, the actual rendering instructions are submitted to RenderThread, which then sends commands to the GPU. Finally, SurfaceFlinger composites Layers (single buffers) and submits them for HAL rendering.

Going back to the question, “each application renders separately to its own Surface and then submits it to SurfaceFlinger for composition”, actually, Surface is not really rendered, only the rendering instructions are submitted to RenderThread for rendering. Finally, SurfaceFlinger composites and consumes them, so CPU-level View only constructs a DisplayList.

Actually, Android does not directly execute graphics calls on every frame at the CPU level, which would be too “heavy” for animations, so there is the existence of RenderThread.

So if we put SurfaceFlinger and RenderThread together, it’s a complete Graphics Pipeline, and they are the parts that actually do the rendering.

iOS

On iOS, CALayer is mainly from UIView, and CALayer is the basis for display and animation. The backboard mentioned in the question is actually the render server on iOS, which runs independently as a process.

Note: I’ve preserved the original Markdown structure and content, including code blocks and images, without any changes. The CALayer has a contents property, which is a bitmap (backing store), mainly used to statically save rendered content for display at any time.

On iOS, the primary rendering and building process is Core Animation. This stage mainly handles layout and calculates layers using Commit Transaction on the CPU, encodes the layer hierarchy into CALayer and sends it to the render server for decoding and GPU rendering.

Simply put, CALayer is equivalent to a texture, and its contents are equivalent to a backing store buffer.

So, Core Animation is not actually rendering. For example, the Display stage of Core Animation only creates primitives based on layout results, while the bitmap in contents is rendered by GPU from primitives. Therefore, the final rendering occurs on the render server.

Conclusion

In fact, whether it’s Android’s surface or iOS’s Core Animation, they are not directly rendering on the CPU layer. Instead, they implement rendering through a combination of RenderThread and render server. From this perspective, there is no difference in intention between them; only the implementation method and management mode differ.

However, neither Android’s RenderThread nor iOS’s render server is the “big devil” that affects actual rendering performance, as Metal and Vulkan, these low-level APIs, have a greater impact on rendering performance.

Why are low-level rendering APIs more important? For example, using OpenGL, a simple graphics pipeline is composed of vertex processing, triangle assembly, rasterization, fragment processing, testing and blending.

However, in this process, rasterization is a time-consuming process, and it’s usually accelerated by GPU, while the data transmission from CPU to GPU is also a time-consuming process.

For example, on Android, RenderThread is mainly responsible for getting input from UI thread and processing them on GPU, and RenderThread is a separate thread for communication with GPU.

However, Metal and Vulkan have appeared, which have compensated many historical problems of OpenGL and improved rendering performance and execution efficiency by one level. These changes are sufficient to ignore the differences in Runtime framework. For example:

• OpenGL uses a single-threaded model, where all rendering operations are performed on a single thread; while Vulkan introduces Command Buffer, allowing each thread to submit rendering commands to the buffer, which can utilize multi-core and multi-thread capabilities more effectively.
• A large part of OpenGL’s support requires driver implementation, with OpenGL drivers handling a lot of work, simplifying upper-layer operations at the cost of performance. In contrast, Vulkan no longer has drivers responsible for tracking resources and API validation, although this increases framework complexity, it results in significant performance improvements.

Similarly, as mentioned earlier on iOS, render server can be simply considered as OpenGL or Metal, while Metal is closer to underlying hardware and reduces resource overhead compared to OpenGL:

On Metal, resource synchronization between CPU and GPU is handled by the developer themselves, providing a faster resource synchronization API, which can effectively reduce the time spent on copying textures and buffers in OpenGL. Additionally, Metal uses GCD to maintain synchronization between CPU and GPU, allowing data exchange without replication.

It can be seen that Vulkan and Metal have brought huge performance improvements to Android and iOS, so when discussing rendering implementation performance differences, it is more appropriate to focus on the differences between Vulkan and Metal at present.

Vulkan VS Metal

Metal was introduced in iOS 8 devices starting from 2014, while Vulkan was first used on Android 7 in 2016, in fact, comparing their performance is difficult because Vulkan is a general-purpose low-level rendering API that considers not only Android but also other platforms, whereas Metal is specialized for Apple devices. This makes it challenging to compare them fairly.

If we discuss usage differences, then Metal is indeed simpler, with most of the actual implementation being a merge and simplification of concepts from Vulkan:

Metal will automatically handle backend management work for developers, executing more automated operations to accelerate visual effects and improve performance, whereas Vulkan provides APIs that rely heavily on developer control.

From this perspective, Vulkan seems to offer greater performance possibilities compared to Metal, but also greater complexity and the risk of writing problematic code.

Another manifestation of Metal’s simplicity is: starting from Flutter 3.10, Impeller was first released on iOS, while Android still waited until 3.13.

In summary, Metal is easier to use, whereas Vulkan offers more flexibility and control, although compared to OpenGL, both have become more complex, especially Vulkan, which is closer to the underlying hardware and thus has higher complexity.

Additionally, it’s worth noting that there’s a project called MoltenVK that supports mapping Vulkan to run on iOS and macOS using Metal, which indicates that Vulkan and Metal are not mutually exclusive. Here is the translation:

Of course, there’s a misconception here. The performance difference you feel may only be due to the app itself not being written well enough. For example, many people write apps or games that cannot truly experience the significant performance boost from OpenGL -> Metal/Vulkan because they may not even reach the limit of OpenGL····

So judging the superiority and inferiority of Metal and Vulkan using your own app is actually unfair. Many times, you might not have done what you should do on a particular platform yourself.