“This is the 24th day of my participation in the November Gwen Challenge. See details of the event: The Last Gwen Challenge 2021”.
We know that the rendering process is collaborative between the CPU and GPU. You have to speed up the CPU’s computing layout and optimize the CPU’s rendering to make the interface smooth. Let’s look at some specific optimizations:
CPU
1. Object creation
- 1. Try to replace heavy objects with lightweight objects. CALayer is lighter than UIView, because everything that’s displayed with UIView ends up being displayed with CALayer, so it’s better to just display it with CALayer. However, there is another difference here. CALayer is used to display content, and it is not interactive. UIView manages events, so we can only use CALayer when we don’t need to intertouch.
- 2. Use pure code. While I don’t like to write in pure code (it’s a bit slow, after all), pure code is really manageable for multiple developers. If you have a conflict with the XIB or the Storyboard, it’s hard to fix. And the pure code loading interface is faster. For example, the most intuitive, you click xib is not half a day to come out.
- 3. Lazy loading
2. Object adjustment
- CALayer does not have attributes. When the attribute method is called, it temporarily adds methods to the object through the runtime resolveInstanceMethod and saves the corresponding attribute values in the internal dictionary, which is very resource-consuming. And when we modify UIView properties, it’s actually mapped by CALayer.
- 2. It is also very time consuming when a large number of objects are released.
NSArray *tmp = self.array;
self.array = nil;
dispatch_async(queue, ^{
[tmp class];
});
Copy the code
3. Pre-typesetting
- 1, minimize the view’s rush calculation, which makes sense, I have to calculate things less CPU since the fast.
- To tell you the truth, I have always used Autolayout to draw, it is a block to use, and very intuitive. But as the number of views increases, Autolayout can seriously impact CPU performance.
- 3, text computing height cache these two are now used less, because they are adaptive, set up and down constraints. But that’s how you calculate the width and height
[NSAttributedString boundingRectWithSize:options:context:]
[NSAttributedString drawWithRect:options:context:]
Copy the code
You can use FDTemplateLayoutCell if you want to put it in a background thread to avoid blocking the main thread height cache
4. Pre-render
-
1. Picture decoding + drawing
When drawing an image to a canvas using the CG method and then creating a picture from the canvas, you can draw the image in a child thread.
-
2. Image optimization
- Use PNG images whenever possible
- Optimize image size to avoid dynamic scaling
-
3 Load as required
-
4. Use AddView less to dynamically add views to cells
GPU layer optimization
- 1, as far as possible to reduce the realization of a large number of pictures in a short time, rendering is very time-consuming is likely to drop frames
- 2. Try to avoid the size of the picture exceeding 4096×4096, because when the size of the picture exceeds this size, the existing CPU will fish hammer and then submit it to GPU for processing, resulting in additional CPU resource consumption
- 3, minimize the number and level of views, because the view is too many and overlapping, the CPU will mix them, the mixing process is very time-consuming
- 4. Asynchronous rendering can combine all the controls and views in the cell into a picture to display Graver tripartite frame
- 5. Avoid off-screen rendering as discussed earlier