iOS builds a smooth interface--cpu,gpu causes and solutions for resource consumption

 CPU resource consumption reasons and solutions
object creation
Lightweight objects instead of weight objects
* Controls that do not need to respond to touch events: Calayer Displays
* objects that do not involve UI actions, try to place them in a background thread creation
* Controls containing Calayer can only be created and manipulated in the main thread
* When you create a View object through storyboard, its resource consumption is much larger than creating objects directly from the code, and in a performance-sensitive interface, storyboard is not a good technology choice
* Postpone the creation of objects as much as possible and spread the creation of objects across multiple tasks.
* objects are more expensive to reuse than free to create new objects, and such objects should be placed in a cache pool as much as possible to reuse
object Adjustment
* There is no property inside Calayer:calayer, and when the property method is called, it is internally added by the runtime Resolveinstancemethod to the object temporarily, and the corresponding attribute value is saved to a dictionary inside, It also notifies delegate, creates animations, and so on, and consumes resources very much. The
* UIView about display related properties (Frame/bound/transform) are actually calayer attribute mappings, so when adjusting these properties for UIView, the resources consumed are much larger than the general properties, so Minimize unnecessary property Modifications
* When the view hierarchy is adjusted, there are many method calls and notifications between Uiview,calayer, so you should try to avoid adjusting the view hierarchy, adding and removing views.
object destroys
captures the object into the block and then throws it to the background queue to send a message to avoid a compiler warning. You can have the object destroyed in the background thread.

Nsarray *tmp == nil;dispatch_async (queue,^{    class];});

Layout calculation
* View layout calculation is the most common place in the app that consumes CPU resources
* The view layout is calculated in advance in the background thread, and the views layout is cached
* Using any technology to layout the view, will eventually fall to the Uiview.frame/bounds/center and other properties of the adjustment on the object adjustment: Very consumption of resources, so as far as possible to calculate the layout in advance, when necessary to adjust the corresponding properties, not many times, These properties are calculated and adjusted frequently.

AutoLayout
You can use common shortcut properties, such as left/right/top/bottom/width/height, or using frames such as componentkit,asyncdisplaykit, without manually adjusting properties such as frame

Text rendering
* All text content controls, at the bottom, are drawn as bitmap display by Coretext typesetting.
* Common text controls (Uilabel,uitextview), which are typeset and drawn on the main thread, can be very stressful when large amounts of text are displayed.
* Solution: Custom text control, drawing text asynchronously with Textkit or the underlying coretext
* Coretext object is created, can directly obtain the width of the text of the information, to avoid multiple calculations (adjust the size of the Uilabel once again, Uilabel drawing when the internal calculation again), Coretext objects occupy less memory, can be cached for several times later rendered.

Decoding of pictures
* When creating a picture with UIImage or cgimagesource, the image data is not decoded immediately. The image is set to Uiimageview or calayer.contents, and the data in the Cgimage is decoded before Calayer is submitted to the GPU. _ occurs in the main thread, inevitably. _
* The background thread will first know the picture in Cgbitmapcontext and then create the image directly from the bitmap.

Drawing of images

* Image drawing: The method that starts with CG draws the image to the canvas, then creates a picture from the canvas and displays it as: [UIView DrawRect:]
* The Coregraphic method is usually thread-safe, and the drawing of the image can be placed in a background thread

-(void) display{    dispatch_async (backgroundqueue,^{        =  Cgbitmapcontextcreate (...)        ; // Draw in context ...        Cgimageref img = cgbitmapcontextcreateimage (CTX);        Cfrelease (CTX);        Dispatch_async (mainqueue,^{            = img;        });});

GPU resource consumption reasons and solutions
> GPU: Receive submitted textures and vertex descriptions (triangles), apply transformations (transform), mix and render, and output to the screen.

What > See: Textures and shapes (vector graphics with triangular simulations)

Rendering of textures
* All bitmap, including images, text, rasterized content, will eventually be submitted by memory to the video, bound to GPU Texture.
* The process of submitting to the video memory, GPU tuning and rendering texture, consumes a lot of GPU resources
* When displaying a large number of pictures in a short time (tableview there are so many pictures and sliding quickly), the CPU occupancy is very low, the GPU occupies very high, the interface will still drop frames.
* Minimize the display of a large number of images in a short period of time, as many pictures as possible to be a picture to display.
* The picture is too large to exceed the maximum texture size of the GPU, and the picture needs to be pre-preprocessed by the CPU, which brings additional resource consumption to both the CPU and the GPU. Iphone4s above model, maximum texture size 4096*4096

Blending of views
* When multiple Views (calayer) overlap together, the GPU will first mix them together. If the view structure is too complex, the blending process consumes a lot of GPU resources.
* Applications should minimize the number and level of views and mark the opaque attribute in an opaque view to avoid useless alpha channel compositing.
* Render multiple views pre-rendered as a single image to display.

Generation of graphs
* Calayer's border, fillets, shadows, masks, Casharplayer vector graphics display, usually trigger off-screen rendering (offscreen rendering), while off-screen rendering unobstructed occurs in the GPU.
* When a large number of fillet calayer appear in a list view, and a quick swipe, you can observe that the GPU resources are already full, and CPU resource consumption is low. The interface still slides normally, but the average number of frames drops to a very low
* To avoid this, you can try to turn on the calayer.shouldrasterize (rasterize) attribute, but this will pass the original off-screen rendering to the CPU.
* Fillet picture occlusion
* Draw graphics that need to be displayed in the background thread as pictures, avoid using attributes such as fillets, shadows, masks, etc.

iOS builds a smooth interface--cpu,gpu causes and solutions for resource consumption