Introduction to iOS instruments

Introduction to iOS instruments
Introduction to iOS instruments

When writing code, we often need some tools to help us analyze and locate problems to adapt and optimize the code. In terms of iOS development, XCode provides a series of tools to help us solve the problem. This is instruments.

The apple documentation introduces instruments as follows:

Instruments is a powerful and flexible performance-analysis and testing tool that's part of the Xcode tool set. it's designed to help you profile your OS X and iOS apps, processes, and devices in order to better understand and optimize their behavior and performance. inconfigurating Instruments into your workflow from the beginning of the app development process can save you time later by helping you find issues early in the development cycle.

This article mainly introduces instruments and several common tools.

Interface Introduction

Instruments workflow:

Method for enabling instruments: <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Authorization + authorization + aW5zdHJ1bWVudHPW973nw + bNvKO6PC9zdHJvbmc + PGJyIC8 + DQo8aW1nIGFsdD0 = "instruents Main Interface" src = "http://www.bkjia.com/uploads/allimg/160415/041U53033-1.png" title = "\"/>

Core Animation

The Core Animation instrument captures information on selected animation statistics. It can record information from a single process or from all processes running on the system.

Core Animation must be debugged on a real machine.

The most important debugging options are as follows:

Refer to link 2 below:

Important:

"Color Blended Layers": Layer Mixing

The Blended Layer (marked in red) is displayed. The Blended Layer is Transparent ), when rendering these views, the system needs to mix the view and the lower view to calculate the actual color of the pixel. So the less red, the better.

"Color Hits Green and Misses Red": layer Cache

Many view layers are highly rendered due to Shadow, Mask, Gradient, and other reasons. Therefore, UIKit provides APIs for caching these layers: [Layer setShouldRasterize: YES], the system caches these layers into Bitmap bitmaps for rendering. If the Layer fails, the Bitmap is discarded and regenerated. So the more green the less red the better

"Color Offscreen-Rendered Yellow": Off-screen Rendering

Offscreen-Rendering off-screen Rendering means that when iOS wants to display a view, it needs to calculate the Bitmap of the view with CPU in the background, and then give it to the GPU for Onscreen-Rendering to display on the screen, because it takes two computations to display a view, this Offscreen-Rendering will cause the image performance of the app to decline. So the less yellow the better.

Secondary:

"Color Misaligned Images": Image Scaling

Misaligned Image indicates that the points to be drawn cannot be directly mapped to the pixels on the Frequency Screen. In this case, the system needs to perform anti-aliasing on adjacent pixels, increasing the Image burden, this problem usually occurs when the Frame of some views is re-computed and set.

"Color Copied images": indicates the image "Color Immediately" Copied by Core Animation when the application is drawn ": instruments cancels the 10-millisecond delay "color Compositing Fast-Path Blue" when performing the Color-flush operation: marking the Path "Flash Updated Regions" drawn by hardware: repainted Area

Graph performance analysis is of little significance and is generally used as a reference only.

Timer Profiler

The Time Profiler instrument captures stack trace information at prescribed intervals. It can record information from a single process or from all processes running on the system.

Explanation of the Call Tree setting parameters:

Refer to link 4 below:

Separate by Thread: Each Thread should be considered separately. Only in this way can you find the "heavy" thread Invert Call Tree that occupies a large number of CPU resources: trace the stack from the top down, which means that the method in the table you see will have been sampled from 0th frames, this is usually what you want. Only in this way can you see the method with the deepest CPU charges. that is to say, after checking this option in FuncA {FunB {FunC}, the stack displays the C with the deepest calling level in the C-> B-A in the outermost Hide Missing Symbols: if dSYM cannot find your app or System framework, you cannot see the method name in the table but only hexadecimal values. If you check this line, you can Hide these symbols to simplify the Hide System Libraries: if you select this option, your app code is displayed, which is very useful. because generally, you Only care about the time that the cpu spends on your code, not the Show Obj-C Only on the system: Only Show oc code. If your program is a program like OpenGl, do not select the lateral check because it may be the Flatten Recursion of C ++: a recursive function. Each stack traces an entry.

The call time of each method is displayed.

Double-click the corresponding method to view the entire running time:

Leaks

The Leaks instrument captures information about leaked memory. It can record information from a single process only.

The red tag of Leaks indicates Memory leakage.
Stop the program running in the upper left corner and switch the detailed Leaks to the Call Tree,
On the setting page, select "invert Call Tree" and "Hide System Libraries" to view the corresponding Call function:

Double-click the relevant function to jump to the problematic code and modify it: