ios-Memory Analysis

I. Memory analysis

1. Static Analysis (Analyze)

Do not run the program, directly detect the code in the potential memory problems (not necessarily hundred accurate, only to provide recommendations)

Combined with the actual situation to analyze whether there is really a memory problem

2. Dynamic Analysis (Profile = = Instruments)

1> Run the program to view memory allocations by using the app (allocations)

* You can see if there is a surge in memory (sudden change) after you have made an action (such as clicking a button \ show a controller)

2> run the program to see if there is a memory leak (Leaks) by using the app

* Red area represents where memory leaks occur

Two. Memory Usage note

1. Load small pictures \ Use higher frequency pictures

1> using imagenamed: Method loaded images, always have cache, this cache is managed by the system and cannot be destroyed by code cache

2. Load large pictures \ Use less frequent images (one-time images, such as a new feature of the version of the image)

1> using Initwithcontentsoffile:\imagewithcontentsoffile:\imagewithdata: such as the loading of images, no cache, as long as the run out, will automatically destroy

2> basically, except for the imagenamed: methods, other ways to load pictures, are not cached

Three. 2 Professional terms

1. Memory leaks

1> the object that was freed, not freed (objects that are no longer being used, are not freed)

2 overflow (out of memory)

1> memory is not enough.

2> data types that have a relatively small size store data with large data lengths

Four. The presence of the picture in the sandbox

1. If the project deployment Target <= 6.x (image compression is not supported)

1> all images are exposed directly to the sandbox resource bundle (main Bundle) and are not compressed into the Assets.car file

2. If the project deployment Target >= 7.x (image compression supported)

1> all images placed inside the images.xcassets are compressed into assets.car files, not directly exposed to the sandbox resource bundle (main bundle)

2> all images that are not placed inside the images.xcassets will be exposed directly to the sandbox resource bundle (main Bundle) and will not be compressed into the Assets.car file

3. Summary

1> compressed to Assets.car file, no resource bundle directly exposed to sandbox (main Bundle)

* Condition: "Deployment Target >= 7.x" and "all pictures placed in Images.xcassets"

* Impact: Can not get the full path of the picture, only through the picture name (imagenamed: method) to load the picture, there will always be a cache

2> does not compress the resource bundle to the Assets.car file directly exposed in the sandbox (main Bundle)

* Conditions: In all cases except 1>

* Impact: You can get the full path of the picture, you can load the picture through the full path (Imagewithcontentsoffile: Method), there will be no cache

4. Conclusion

1> small pictures \ Use high frequency pictures

* Put it inside the images.xcassets

2> large pictures \ Use lower frequency pictures (one-time pictures, such as the version of the new features of the picture)

* Don't put it inside the images.xcassets

Five. Device information related development (non-private API, underlying API)

1. Model of the device

2. CPU model \ Usage of the device

3. Memory capacity \ Usage of the device

4. HDD capacity \ Usage of the device

5 .....

6. Recommended third-party libraries

Uidevice-extension

* Address: Https://github.com/erica/uidevice-extension

* Realization idea: Using classification to extend the Uidevice

* Ease of use: very simple

Six. How to minimize memory leaks in your program

1. Non-arc

* Foundation Object (OC Object): As long as the method contains Alloc\new\copy\mutablecopy\retain and other keywords, then the objects produced by these methods, You must call 1 release or 1 times when no longer in use Autorelease

* Corefoundation Object (C object): As long as the function contains keywords such as Create\new\copy\retain, then the objects produced by these methods must be called 1 times cfrelease or other release functions when they are no longer in use.

2.ARC (automatically manages OC objects only, does not automatically manage C-language objects)

* Corefoundation Object (C object): As long as the function contains keywords such as Create\new\copy\retain, then the objects produced by these methods must be called 1 times cfrelease or other release functions when they are no longer in use.

3.block's attention

Block memory defaults to the stack (System auto-management)

void (^test) () = ^{

};

If the block is copied, the block's memory is migrated to the heap (the memory needs to be managed by code)

Block_copy (test);

You should do 1 release operations when you do not need to use block

Block_release (test);

[Test release];

ios-Memory Analysis