iOS executable Slimming method

Reducing the size of iOS installation package is a lot of large and medium-sized apps to do, usually start with the resource files, Compress Pictures/audio, remove unnecessary resources. After these resource optimizations are done, we can also try to thin the executable file, the larger the project, the size of the executable file, and because the AppStore will encrypt the executable file, resulting in low compression of the executable file, compressed executable file for the entire app package volume ratio of about 80%~ 90%, it's still worth the optimization. Here's a look at the points that can be optimized during the study of the executable file. The process of the study uses the Linkmap,linkmap introduction and generation can refer to another article-ios the composition of the executable file.

Compilation options 1. Compiler optimization Level

Build Settings->optimization level has several compile optimization options, release version should choose Fastest, smalllest, this option will open those without adding code size of all optimizations, and make the executable file as small as possible.

2. Removing symbol information

Strip Debug Symbols During Copy and Symbols Hidden by Default the release version should be set to Yes to remove unnecessary debug symbols. Symbols Hidden By default will define all the symbols as "private extern", the specific meaning and role I am not clear, pending research, but set up will reduce the volume. These options are currently the Xcode default option, but the artifacts generated by older Xcode may not be, and can be checked.

Other optimizations can also refer to Apple's official documentation-codefootprint.pdf

Third-party library statistics

Many third-party static libraries are introduced in the project, and if you know the size of these third-party libraries in the executable file, you can evaluate whether it is worth looking for alternatives to get rid of this third-party library. We can count this information from Linkmap, I wrote a node. js script that can be counted by linkmap each. o The volume occupied by the target file and the volume occupied by each. A static library and sorted. See here (Requires FQ).

Arc->mrc

It has been suggested that the code compiled with ARC will be larger than the MRC, because the ARC code will have some retain and release instructions in some cases, such as calling a method, the object it returns will be retain, the exit scope will be released, The MRC does not need, the assembly instruction becomes many, the machine code becomes many, the executable file becomes bigger. There are other details to realize the difference, first not tangled.

How much volume will it increase with arc? I think that from the increase in the number of assembly instructions is very difficult to be accurate, this thing involves too much detail, or from a statistical point of view. Several contrast tests were conducted, and several open source projects that supported ARC/MRC were counted to compare the size of the __text code snippet in the case of opening/closing arc. Only the __text code snippet is compared because:

1. The impact of arc on the size of executable files is almost always in the code snippet

2. The executable will have some sort of alignment, for example, some segments are padded at less than 32K until the 32K is aligned, and the result of the executable file size comparison may be misaligned and inaccurate.

Experimental data:

",	Mbprogresshud	Sdwebimage	FMDB
Open arc	195	24424	29056
Close arc	17648	22575	25848
contrast	↓9.6%	↓7.5%	↓11%

The result is that arc will probably increase the code snippet by a size of 10%, considering that the code snippet occupies approximately 80% of the executable file, and the estimated impact on the entire executable is 8%.

It is worthwhile to assess whether a 8% drop in volume is worth changing some of the modules in the project to MRC, which increases the maintenance costs of the program and is generally not recommended for special situations.

Useless code

Create a new class in the project, add a few methods to it, but do not import it anywhere, after you build the project and observe Linkmap, you will find that the class is still compiled into the executable file.

In the C + + experience, classes and methods that are not used by the compiler are optimized and not compiled into the final executable, but Object-c is not the same, because the dynamic nature of object-c, which can be called by class and method name reflection to get this class and method, So even if a class is not used in the code, the compiler cannot guarantee that the class will not be invoked at runtime by reflection, so as long as the file is in the project, whether or not it is used, it will be compiled into the executable.

In this case, we can pass the script, traverse the whole project's file, find all the non-referenced class files and methods that have not been called, and remove them without the guarantee of dynamic calls elsewhere. If the entire project lasted a long time, and the elapsed code left more, this cleanup will save the executable file space is quite impressive.

Class/Method name length

Observing Linkmap can find that each class and method name has a corresponding string value stored in the __cstring segment, so the length of the class and method names is also affected by the size of the executable file, because of the dynamic nature of the object-c, because the class/method name reflection is needed to find the method, the Object-c object model will save the class name and the list of method names.

It is possible to consider confusing all classes and method names before compiling, replacing long names with short names, and the benefits of doing so in addition to reducing the volume, there is a great improvement in security, and others get the executable to class-dump it out of the results are confused class and method name, You can't guess what a method is doing from the class and method names, and it's hard to hook up the hack. However, there is a drawback is that the crash stack back to the stack method name will be confused, need to add a layer of confusion-----the original conversion, implementation and use of a bit high cost.

In fact, this part occupies a relatively small length, medium-sized projects are also hundreds of k, the security requirements of high conditions can be tried.

Redundant strings

All static strings defined on the code are recorded in the __cstring segment of the executable, and if there is a lot of log in the project, the footprint is considerable and the size is hundreds of k, you can consider cleaning up all the redundant strings. In addition, if there is a particularly long string, it is recommended to save to a static file, because AppStore to the executable file encryption results in a low compression rate, particularly long string extraction into a static resource file after the compression rate is much higher than in the executable file.

Checklist

Finally, simply list the various ways to reduce the size of the iOS installation package as checklist:

Via:bang's Blog

iOS executable Slimming method