ios--Tool--instruments

First, Leaks

Open the instrument in Xcode and open it in a way:

Select Product--profile to

Start instruments with Xcode (you must stop your current execution file before starting)

Choose the first way to start, build successfully out of the instruments tool, select the leaks option, the tool shows the effect as follows, explain why you choose Leaks template, but by default will add allocations template,

Click the red button to start running, (this runs for a minute until a memory leak can stop)

By observing, you can see that the red pillar indicates a memory leak, as shown in, select Leak, click Cross, select Call Tree

Select Call tree and the lower right corner tick Invert call tree (inverted call tree), hide system Libraries (hidden Systems tool)

The specific code for the memory leak is found, and the red box on the right specifies which method has a memory leak.

As long as you double-click on these methods, you will jump to the specific code to facilitate the programmer debugging

To select Leak, click Cross and select Cycles&roots to see the memory leak address:

Click the arrows to view the results and contact the developer to analyze the results

The Leaks Instrument tool checks the memory of the process heap for leaks. You can use the Instrument tool with the allocations instrument tool to get a history of memory addresses. The instrument tool requires you to load a process so that it can collect data from the process when it starts.

The Instrument tool captures the following information:

Z amount of memory leaks (the number of leaks)

Z size of each leaked memory block (that size of each leak)

Z The address of the memory block of the leaked block) Z leaks the type of object (type of the

Leadked object)

Each view mode of the detail panel displays the leaked data in a slightly different function. In list mode, the Instrument tool displays the percentage of each leak, and each memory leak helps to discover the total number of memory leaks. In outline mode, the data is reorganized so that you can see how much memory leaks are in the given symbol. For any of the schema entries, the Extended detail panel shows the deep stack trace information raised by the memory leak.

Second, Time Profiler

Select Time Profiler to start.

The time profiling tool is used to detect application CPU usage. You can see that the various methods in the application are consuming CPU time. Using a large number of CPUs is not necessarily a problem. The path of a weather animation [like heavy rain] in a different scenario in our client is very high on the CPU, Animation itself is also a very demanding and resource-intensive task.

Click Record to start running.

Time profile Analysis interface [via by Chenkai]

When we first got the analysis data, it was always like this:

performance data [via by Chenkai]

Here is the full path to the execution code, where the system and the application itself have some call paths that are completely pinched together. It's completely invisible. The actual code execution time in the application we care about and where the code path actually resides. Simple way to quickly tick the right call tree separate The thread and hide System libraries two options [explanation of option effect later]:

Post-split performance data [via by Chenkai]

You can see the direct path to the application's various method calls, eliminating the system-related methods and the reverse call tree path. A lot more refreshing. If this is not intuitive enough, choose any time-consuming method branch [here Select Weatherviewcontroller Viewdidload] Double-click Enter to see:

Code & Time-consuming details

You can directly navigate to the code of the Viewdidload, or you can visually see the change method to reduce the time spent in other ways. Similar to [self Loadcityweatherscroollerview] time is 121x, X is a time-consuming unit here for Ms milliseconds. Of course, if you find the problem directly in instrument, it is inconvenient to modify, You can directly click the Xcode button in the upper right to directly locate the Xcode corresponding call method entry. This makes it easy to quickly locate the most CPU-intensive method of code. You can also open Xcode to quickly modify and rerun the profile to see how the changes are time-consuming before and after comparison. Simple and convenient.

The right call Tree option here is necessary to explain [official User Guide translation]:

separateby thread: thread separation is the only way to clearly see the most CPU-consuming threads in the call path.

Invert Call Tree: keeps track of stack information from top to bottom. This option allows you to quickly see how the method invocation path takes CPU time, such as Funca{funb{func}}, and check the stack to c->b-> A the deepest c of the call is displayed at the outermost level.

Hide Missing Symbols: If dSYM can not find your app or call the system framework, then the table will see the call method name only see 16 binary values, check this option to hide these symbols, easy to simplify the analysis of data.

Hide System Libraries: This is even more useful, the time-consuming call path will only show the app's time-consuming code, Performance analysis Generally, we compare our own code with time-consuming rather than systematic. Basic is a must option. Note that some code time-consuming is also included in the system level, which can be useful for checking the execution path before and after a tick.

No further information on other methods.

Performance Analysis & Code optimization

Our performance optimization is mainly for the following two usage scenarios:

A: The first time the application starts to enter the weather first page.

B: From the backstage cut to the front desk weather page occupy time.

Until the performance analysis data has not yet been obtained, it has been thought that the first start-up time is mainly wasted appdelegate on the third-party framework initialization [similar to the Weibo&wechat-related SDK initialization call]. When we get the actual performance data time consuming ratio, we find that this is not the case:

Startup time-consuming

As can be seen on the application start initialization work is mainly in mjappdelegate the following two ways to expand:willfinishlaunchingwithoptions and Didfinishlaunchingwithoptions, in which the third-party framework initialization work is mainly done in willfinishlaunchingwithoptions. The actual time-consuming ratio is very small. Basic negligible.

And we want to optimize two start-up time scenarios, different. The first entry requires a beginner tutorial, adding cities, requesting city data, parsing data, initializing weather home UI elements, and loading scene animations. When entering from the background, the weather data is parsed from the local storage dt file, the weather first page UI element is initialized, and the weather animation is loaded.

1.NSDateFormatter Problem Highlights

Focus on this point to analyze application start-up & Weather page time-consuming. In AB Two scenarios all found loading the first page element found the following problem:

NSDate (Timeago) getdatestrbytimezone time-consuming

Continue tracking Discovery:

NSDate Time consuming

When loading Mjlinechartview and Tendencychartview in the AB two scenarios, it is time consuming to get the timezone corresponding times. And time consuming is mainly on Getdatestrbytimezone this method call.

Getdatestrbytimezone method

Where creating a NSDateFormatter object takes an average of about 33MS The 3 properties that are set NSDateFormatter average time is about 30ms. Because the first 24-hour weather and the next few days of forecast. It takes time to iterate through the data in the for loop, causing the method not to repeat the call multiple times.

For this issue:

The NSDateFormatter object itself is very slow to initialize, as is the case with Nscalendar. However, it is unavoidable to use them in some usage scenarios, such as JSON data parsing. Using this object while avoiding performance overhead is generally a good way to Add Property (recommended) or create a static variable to keep the object initialized only once, and be reused multiple times. It's worth mentioning that setting a NSDateFormatter property is almost as slow as creating a new instance Object!

Here's how to add attributes:

Attribute mode

For nsdateformatter time overhead out of reuse objects, try to avoid using them to handle multiple date formats. Of course, for date format processing if you need to increase speed, you can use C directly, you can use a third-party library to circumvent this problem.

2.UIImage Cache Trade-offs

You see a lot of code in the project code using the following:

UIImage use

In the main thread, it is found that the image IO overhead and time-consuming ratio in different animation scenes is mixed, and it takes a certain proportion to spend more time on uiimage elements. The memory overhead will also increase significantly.

uiimage loading pictures In general There are two ways :

A:imagednamed initialization

B:imagewithcontentsoffile initialization

The difference is that the imagenamed default loading of the image will cache the image in memory, and this method finds and returns a picture object in the system cache with a specified name. If the corresponding picture object is not found in the cache, load the picture from the specified place and then cache the object and return the picture object .

The Imagewithcontentsoffile only loads the picture, not the cache.

The large use of the Imagenamed method adds additional overhead to the CPU in places where it does not need to be cached. When the application needs to load a larger picture and use a one-time, then there is no need to cache this picture, with Imagewithcontentsoffile is the most economical way , so that the CPU will be wasted too much time on the unnecessary cache one by one because of the uiimage element.

When using the scene to be programmed, it should be differentiated according to the actual application scenario, although the uiimage is small, but the use of elements more problems will be highlighted.

3. Weather Homepage Loading Policy

Comparative analysis of performance data in AB Two scenarios reveals:

Weather Home Weatherview Update time-consuming

Weather Home Weatherview Initialization time has been 300ms-450ms between, occupy a large part of the home page time. And always fixed overhead. Occupy one of the main Thread3 points.

And the user enters first to see is the top half of the weather first part:

Upper part

The lower part requires scrolling to see the bottom half. And does not necessarily trigger:

Lower half

And now the entire home view of the initialization and update all put to the main thread to do. where Weatherinfoview The Updateallinfo method update takes the longest time. More view means more rendering, which means more CPU and memory consumption, for our weather home in Uiscrollview nested a lot of view more so

For this scenario, do not host too many operations on the main thread. Uikit rendering, the user input response needs to be completed on the main process. The main thread is affected by unexpected block or load response time too much will affect the user experience. And for resource consumption too large operation, the principle is to minimize the main thread of CPU consumption, will work " Move away from the main thread, and do not block the main thread. Similar to local some IO is completely moved to other threads to do.

During the commissioning of the time Profiler, it is possible to block the main thread even if it takes up a very few CPU times (if you see the data in the timing Profiler). disks, networks, Lock, Dispatch_sync, and sending messages to other processes/threads all block the main thread. Time Profiler can only detect stacks that consume too much CPU, but these IO problems are not detected. It's strange . In system trace, the CPU time is found to be very low, but the wait times high call, indicating that the main thread processing I/O has severely compromised the performance of the app, and this is considered to optimize the operation.

And for our application home page UI in multiple view, in the loading strategy can be fully multi-threaded synchronous loading, only the upper part of the main thread to load, You can open a thread at the same time to synchronize the load. This can greatly reduce the group thread initialization and update time, when the first page initialization has been rendered, the second half is actually another thread has finished processing.

Also for a single view try not to viewwillappear time-consuming operation, viewwillappear before the view display is called, for efficiency considerations, in this method do not deal with complex time-consuming things; You should only set the view in this method Simple things like background color, font, and so on. Otherwise, the user will obviously feel a dull view display.

4: Apply first load time

To apply the first boot load operation:

First load

The first load sits with the following actions:

A: Link and load: You can display the Dyld in time profile, the library is mapped to the address space, and the bindings and static initialization are completed.

B:uikit initialization: If the app's root View controller is implemented by Xib, it will also be initialized at startup.

C: Apply callback: Call Uiapplicationdeleagte callback: Application:didfinishlaunchingwithoptions.

D: First Core animation call: Call Ca::transaction::commit in the start-up method-[uiapplication _resportapplaunchfinished] to make the first frame drawing.

The first time the application is loaded in the Start method willfinishlaunchingwithoptions and Didfinishlaunchingwithoptions only do the applications that are required for the first start of the operation, and for _dyid_ Start operation in the Initialize Library framework function. Unnecessary framework do not link to avoid time-consuming first load.

Time Profiler function Source: http://www.jianshu.com/p/9e1f0b44935c.

ios--Tool--instruments