Performance optimizations for jumps between iOS pages (ii)

Continuation of the statement

In the performance optimization of the jump between pages (a) introduced a number of basic knowledge, described the situation and the situation of the two optimization methods and principles, but there are many people on the two final treatment of the situation of the principle of interpretation does not understand the process, the next step in detail to tell the principle of the two ways, If you haven't seen the performance optimization of jump between pages (i), please read it first.

Click to download demo, or Https://github.com/IOSDelpan/SmoothTransitionDemo.

The jump between pages is roughly divided into several tasks: 1. Generate the page view that will be displayed; 2. Generate the UI elements we need; 3. Generate animations for page jumps; these tasks are performed in the same loop. We know that each loop detects if the layer tree is updated, and if the layer tree is updated, Runloop will be in the Observer's callback function _zn2ca11transaction17observer_callbackep19__ CFRUNLOOPOBSERVERMPV () When execution is complete, send updates from the layer tree to the render service process for rendering, and if the time of the loop is too long, this will delay the update of the layer tree, which is what we call the screen lag (CPU level lag). To solve the page jump delay, we decomposed the tasks that we had to perform in one loop and split them into loops to execute, so that it didn't affect the smoothness of the app or the UI updates.

In the demo, we use the GCD approach to "load the UI in Runloop next time."

The call to the Dispatch_async () function submits the task [self loadalllabels] that generates the UI element to the GCD master queue, which executes the tasks in the Runloop home column when the main thread of the application enters the next loop gcd The entire page jumps to the process, that is, two loops work as follows.

In the first loop, the time-consuming task [self loadalllabels] is submitted to the main queue to generate a transition animation of the Page view and page jumps that will be displayed and sent to the render service process for rendering, at the same time, because the main queue has a task to be processed, GCD sends the message mach_msg () to the Mach message Server, the destination port is application Main Runloop dispatch port.

Due to port events pending processing, Runloop is awakened and enters the next Loop,runloop by sending dispatch port to Mach message server to receive dispatch port messages. When Runloop receives the dispatch port message, it gets the main queue pending task [self loadalllabels] and processes, and after processing completes, sends the update of the layer tree to the render service process for rendering.

The principle of timer processing is roughly the same as the principle of "the next cycle of loading the UI in Runloop", but loops are more frequently.

Main Runloop Port event sources are basically divided into three categories, GCD events, timing source events, input source events (Source1), and these three types of events correspond to three different ports, dispatch Port,timer port and source port. Each loop has two checks to see if there is a chance that the port event needs to be processed, but once the loop has only one chance to handle the port event, the processing port event is triggered at step 5 or Step 7. Runloop in purely processing the dispatch port event or timer port event, the Runloop can be run completely once from being awakened to entering hibernation, returning from step 8 to step 7 (sequential 8,9,2,3,4,5,6,7), so The same effect as a timer can be achieved with GCD asynchronous nesting.

When main Runloop handles the dispatch port event, it gets all of the pending tasks for the main queue and processes it, noting that the following two ways of actually executing the process are different.

One is to submit one task at a time to the main queue, that is, one loop to process a task, and the other is to submit three tasks at a time to the main queue, that is, processing three tasks at a time.

So, the two ways are the same as the following.

The above is the implementation principle of the "next cyclic loading UI in Runloop" processing mode.

Scenario Three

Does it feel like déjà vu to see a gif? Right, this situation is the most common, in most of the apps, including some of the major manufacturers of the app (for this person is more curious, may be written by temporary workers, as the most grassroots people in the kingdom, I can accept this explanation??). From the general extent of this situation also reflects that, in fact, the vast majority of the team will not do the performance optimization of the view, not to say what in-depth optimization, but still can understand, the performance optimization of the view is not the team of one or two people, to carry out all kinds of difficulties, spit noisy finished??, enter the subject situation three.

Situation one and scenario two describes the CPU page jump delay, in addition to CPU performance will cause page jump delay, GPU pressure is too large, the same performance problems, resulting in the face page jumps when the scene animation is not smooth, slow and so on. From the GIF we can see that the whole jump animation dropped frame is very serious, because we have assumed that this situation is due to the GPU pressure is too large, so no longer detect the CPU situation.

Using bit graphics to force the GPU to take off-screen rendering, in the demo (according to your machine situation, adjust the number of bits to achieve the effect), there are 30 bitmaps have been deformed, the GPU needs to be 30 off-screen rendering, and due to the need for off-screen rendering of the bitmap inches larger, so greatly increased the pressure of the GPU , so that the whole animation has a serious drop frame situation, we need a method, both can quickly solve the animation dropped frames and do not need to do page optimization.

From the GIF graph we can see that the whole process of the optimized page jump does not appear the transition animation is not smooth, slow and so on, that is, there is no drop frame situation. Because the layer is the data source that draws the rendering, we need to know what has changed in the layer tree after optimization.

The optimization principle is to make a layer of the view controller once, set the result to the new layer's homestay map, and add the new layer to the layer tree (no layers associated with the layer tree will not be sent to the rendering engine). This process from the CPU level, the Core animation can discard all the completely obscured layers, reduce the CPU calculation, from the GPU level, the GPU does not need any further compositing, directly copy the top texture as the target pixel, reduce the GPU computational capacity, This improves performance in general. Each processing method is difficult to achieve the best of both worlds, many times we need to choose between time density and space density, the disadvantage of this processing method is to increase the memory loss (this I think can be ignored, create full-screen glass when there is no heartache memory, now pour heartache memory come??), So this approach is suitable for emergency use. For application how to maintain a high number of frames, or to start with the View performance optimization, this section will be described in the Page Performance optimization chapter.

Summarize

The diagram used to tell the rendering module to WWDC2014 (First,second,third I added). This diagram is very clear about the entire rendering process, application package submits the layer tree and sent to the render service process, the rendering service process deserializes the layer tree to get the render tree, draws the bitmap with the render tree, and the GPU composite bitmap is eventually displayed. By knowing that the entire rendering process is divided into three steps, each step is in a separate space, that is, each step is in a separate frame, iOS is at 60 times per second to refresh the screen, that is, a second 60 frames (fps), Each frame of time is 16.67ms, so the rendering process for each step of the ideal processing time of 16.67ms, if one of the steps of processing time more than 16.67ms, will cause screen refresh failure, that is, drop frame or screen lag, drop frame mainly occurs in the first step or the second step.

The key point of the first step is whether each loop and delay of the application Main Runloop, and the key point of the second step is the GPU pressure. From the previous narrative we can be informed that the situation one, two, three of the bottleneck is in that step, the situation one, two bottlenecks in the first step, and the situation three of the bottleneck is in the second step.

Scenario two mainly describes how to block the main thread of the UI task decomposition, to resolve the page jump delay problem. When the UI task blocks the main thread, but the blocking time is not long, you can choose to "load the UI in Runloop next time" to resolve, if the UI task will block the main thread and the time is longer, you can choose to use "GCD nested load UI" to further decompose the UI task If the UI task blocks the main thread and wants the UI to appear in an orderly fashion, you can choose to resolve it in a "Timer loading UI".

Scenario three mainly describes how to lazy to solve the page jump when the transition animation is not smooth, slow and so on, and the processing method is suitable for emergency, want to application to maintain high frame number, or to start from the View performance optimization.

Most of this article is about basics, because the process is based on these basics, and without the basics, you can't find the direction even if you want to optimize. If the text is wrong, also hope to point out.

Performance optimizations for jumps between iOS pages (ii)