If you look at today’s iPhones, with the exception of the high-end iPhone 13 Pro and Pro Max models that use high refresh rate screens, the rest of the models are still equipped with 60 Hz refresh rate screens, but it seems that they are still as smooth as Android phones with 120 Hz or even better.

So why is iOS so smooth?

Stuttering and slow responses used to be synonymous with Android, which was directly related to weak hardware performance at the time. Nowadays, the bottleneck for Android’s smooth operation is no longer the hardware, but most of the reasons lie in the ecology of Android development.

The native open-source Android code provided by Google contains only the basic framework, and when various phone manufacturers customize their own Android systems UI, they often focus on improving and integrating basic features. The formula for motion calculation, animation rendering and physics simulation that Android itself offers can only be described as just sufficient.

Achieving the animation effects of iOS also requires a lot of effort from third-party developers. Compared to the intuitive and quick improvement through direct hardware performance enhancement, few manufacturers focus on animation optimization. Therefore, in most Android systems UI, the animation speed is often only roughly improved, as long as my animation response is fast enough, then the user has no time to feel the delay.

The underlying operating logic of iOS is very different from that of Android

First of all, iOS differs significantly from Android in terms of the priority of the underlying logic. iOS gives the highest priority to the touch level, which is the level at which the user responds to the controls, followed by the media level, the service level, and the core architecture level. The system requires constant real-time parallel redirection to keep up with the user’s operations and speed of thought. This means that even if the app you click on is not fully open, you can still operate it in the middle.

In contrast, Android’s priority architecture (application- > framework- > library- > kernal) requires the system to wait until the application is fully open before the system can provide feedback. Although some customized Android UI systems can be implemented in the middle of forwarding, they must still be built on the premise that they have been fully opened.

If you compare the two systems, you will find that iOS seems to be more lively and responds whenever you need it, while Android is a bit rigid.

Apple relies on forced image completion, which means that within the limited 60 Hz, each frame provides additional elastic stretch detail animations and other content information to help the user blink and complete the image in disguise to make the system feel more fluid. While the overall load time is longer, visually it is more in line with the laws of natural physics and appears more fluid. At the same time, the extra load time can also make the app load and prepare better.

Similar Posts