iOS Performance Tuning series (full)

Summary:Three types of tools

• The base tool (NSLog) records the run time.
• Performance tools. Detect performance of individual parts and identify performance bottlenecks
• Memory tools. Check memory correctness and memory usage efficiency

Performance Tools:can measure CPU usage, time consumption, battery consumptionOne, time profile

Start time profile:xcode--> product--> profile--> Time profile

Using the time Profiler debugger, you can get the temporal distribution and percentage consumed in the entire application run

There are two points to note before using time profile:

1, must use the real machine debugging

Be sure to use the real machine when you start your application performance analysis. Because the emulator runs on your Mac, the CPU on your Mac tends to be faster than your iOS device. Instead, the GPU on the Mac is completely different from the iOS device, and the emulator has to emulate the device's GPU at the software level (CPU), which means that GPU-related operations run slower on the emulator, especially when using Caeagllayer to write some OpenGL code. This results in a far cry from emulator performance data and user real-life performance data

2, the application must use the Release configuration

When the release environment is packaged, the compiler introduces a series of optimizations that improve performance, such as removing debug symbols or removing and re-organizing the code. Another iOS introduces a "Watch dog" [watchdog] mechanism, in which the watchdog monitors the performance of the application, and if it exceeds the run time specified by the scenario, the watchdog forces the process to end the application. Developers can crashlog see the corresponding log, but Xcode disables "Watch Dog" under Debug Configuration

After startup

Click the red button in the top left corner to start debugging

Pay attention to the lower right option when debugging

Separate by thread: each thread should be considered separately so that you can pull out the "heavy" threads that are heavily CPU intensive

Invert call Tree: From the top down the trace stack, which means that the method you see in the table will have been sampled from frame No. 0, which is usually what you want, so you can see the most time-out method in the CPU, which means funca{funb{func}} Tick the stack with c->b-a to show the deepest C at the outermost level of the call

Hide System Libraries: Check this to show your app's code, which is very useful. Because you usually only care about the time the CPU spends on the code you write yourself, not on the system code.

Flatten recursion: Recursive function, one entry per stack trace

Top Functions: The sum of the time that a function spends directly in the function, and the total time it takes for the function to call the function. So, if function A calls B, then A's time is reported in a time spent plus B time spent, which is very useful, because it allows you to pick the maximum number of times each time you go down to the call stack, zeroing in on your most-time-consuming method

Final Debug Interface

Double-click the selected line to view the code

UIImage *image = [UIImage imagenamed:imagename] in the discovery Loop; The time consumption of the statement is the longest, the degree Niang:

There are two types of uiimage initialization methods

A:imagednamed initialization

B:imagewithcontentsoffile initialization

The difference is that imagenamed default loading of the image will cache the image in memory, this method with a specified name in the system cache to find and return a picture object, if the cache does not find the corresponding Picture object, the image is loaded from the specified place and then cache the object, and return the picture object

and imagewithcontentsoffile only loads the picture, not the cache

A lot of use of the imagenamed way will add extra overhead CPU time to do this without needing the cache, when the application needs to load a larger picture and use one-off, then there is no need to cache this image, Using Imagewithcontentsoffile is the most economical way to do this, so that the CPU will be wasted too much time on the unnecessary cache 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

Memory Tools:care about memory leaks and memory garbage issues

First, analyze static analysis

I. Static memory analysis

1. The so-called static memory analysis means that the code is analyzed directly by the tool when the program is not running.

   • Let the compiler analyze the memory situation and check for memory leaks based on the syntax structure of the code context

2. Role

   • Logic error: Access uninitialized variable or wild pointer
   • Declaration error: An object has been declared, but has never been used
   • Memory management error: Memory leak
   • Cons: Static memory analysis because it is the compiler based on the judgment of the Code, make the judgment is not necessarily accurate, so if you encounter a hint, you should go to the code above to check

3. Static memory analysis in OC:

   • Once in the MRC environment, OC code need to manually manage memory, any object reference, will be accompanied by a release operation, otherwise it is prone to memory leaks, so in the MRC environment, the use of static memory analysis is necessary
   • In the current ARC environment, memory leaks are rare, but there are a few cases where memory leaks can occur.
     • If the foundation object and the Corefoundation object are transformed, the Corefoundation object can enjoy the arc mechanism, so it is prone to memory leaks.

4. Static memory analysis for Swift

   • Swift, which uses a type remapping mechanism, can convert objects into objects that can automatically manage memory without our manual release, so Swift is more secure in memory management

Two. Memory allocation

2. Role

   • View memory allocations for the current run
   • See if the used memory has been released

3. Notes on loading images in app

   • -imagenamed:

     • This method is used to load small images/images with high frequency
     • This method loads the picture and always retains the cache while the app is running, the cache is managed by the system and cannot be destroyed by code

     • When the system detects that memory consumption is too high, it will automatically release this part of the memory

         Searchfor an object whose name was set explicitly using the setname:method and currently resides in the image cache. The method first looks from the image memory search the App ' s main bundle for a file whose name matches the specified string. If not found, in search the application  Kit Framework for a shared image with the specified name. If not in the bundle, look for the library in the framework to find            

   • -imagewithcontentsoffile:

     • This method is used to load large pictures/low-usage pictures
     • It just loads the picture once and does not cache, and when the object is released, the memory is freed.
     • So you should use this method for infrequently used images.

5. The presence of a picture in a sandbox

   1. If the current project is deployed in version <= 6.x: Then all images will be exposed directly to the sandbox's resource bundle (main bundle) and will not be compressed into the Assets.car file
   2. If the current project deployment version >= 7.x
      • All images placed in the images.xcassets will be compressed into assets.car files and will not be exposed directly to the sandbox resource bundle.
      • Images that are not placed in Images.xcassets are exposed directly to the sandbox's resource bundle
   3. Use contrast
      • Files that are compressed to Assets.car:
        • These images will not be exposed, but cannot or get the paths of these images, can only be loaded by the picture name -imagename , and will produce the cache
        • Small Pictures/high frequency of use, placed in the Image.xcassets
      • Uncompressed Pictures:
        • Picture is exposed, can be imagewithcontentoffile to get the path of the picture, there is no cache
        • Big picture/low frequency, such as new feature interface, put it outside

Second, leaks dynamic memory analysis

For some memory leaks that cannot be solved by static analysis, it can be discovered by dynamic analysis, which is more pertinent to analysis.

Click the Xcode Product menu profile to start instruments:

Selecting leaks will automatically start the leaks tool and the iOS emulator:

Leaks starts recording when it starts, and you can see the memory footprint in leaks as you work with the app running on the emulator.

The top of the leaks is divided into two columns: allocations and leaks

Allocations records memory allocations that are used to optimize memory usage.

Leaks is used to analyze memory leaks. The reason for the memory leak caused by arc is the reference ring.

Look down.

At first glance is also good ah, tableview very smooth, images can be lazy download (cell screen and then download), this is what I want to prototype. But, curiously, analyze it with leaks.

I Rub

Then we open the leaks and see where the error appears.

First select leaks and leaks by backtrace. Here you can see the memory leaks of those objects, how many leaks, this is a simple look, there is not much debugging significance.

Then look at the call tree, because it gives us a ballpark position and sometimes gives us a precise location, but it depends on luck.

Then, choose invert call tree and hide System Library again

Then we know that the location of the memory leak is here in the Nsoperation subclass.

Then double-click on any line in the picture above to jump to where the memory leaks are in the code (in fact, many of the memory leaks will be discovered by this step)

So what do we do? If there is a problem looking at the document, we see that the reference count plus one in the picture is

+ (nsurlsession*) Sessionwithconfiguration: (nsurlsessionconfiguration*) Configurationdelegate: (ID) Delegatedelegatequeue: (nsoperationqueue*) Queue:

Look at the file below and find this place.

So, we have to manually remove the strong reference, so we manually go to disconnect

-(void) setoperationfinished{

[Self.sessioninvalidateandcancel];

[selfwillchangevalueforkey:@ "isfinished"];

[selfwillchangevalueforkey:@ "isexecuting"];

Executing =no; Finished =yes;

[selfdidchangevalueforkey:@ "isexecuting"];

[selfdidchangevalueforkey:@ "isfinished"];

}

Let's run it and see if it's normal to dealloc.

2015-06-0510:28:36.814asyncimagetableviewdemo[1245:83664]dealloc2015-06-0510:28:36.954asyncimagetableviewdemo[ 1245:83664]dealloc

With leaks analysis, there's no memory leak.

Summary: In fact, most of the problems can be solved by double-clicking the Code section above, a few questions need detailed analysis of ARC reference process

third, zombie memory garbage

The problem with the program hanging is much more serious than the performance issue.
can open zombie function in instrument, make memory crash when, can see crash on which object.
Or some of the pros and cons.
This thing is usually used when receiving exec_bad_access. This is a memory access issue.

iOS Performance Tuning series (full)