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 the optimization of these resources, we can also try to thin the executable file, the larger the project, the larger 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 installation 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 Linked product/deployment postprocessing/symbols Hidden by Default the release version should be set to Yes to remove unnecessary debug symbols. Symbols Hidden By default will define all symbols as "private extern" with details in the official documentation (https://developer.apple.com/library/mac/ Documentation/developertools/conceptual/machotopics/1-articles/executing_files.html#//apple_ref/doc/uid/ tp40001829-97021-tpxref121).

These options are currently the default for Xcode release, but the older version of Xcode may not be able to be checked.

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 and write a node. js script that can be counted by Linkmap. O the volume occupied by the target file and the volume occupied by each. a static library.

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 the executable file is almost in the code snippet;

2, the executable will be some kind of alignment, for example, some segments in less than 32K fill 0 until the alignment of 32K, if the size of the executable file comparison may be aligned, not accurate.

Experimental data:

	Mbprogresshud	Sdwebimage	FMDB
Open Arc	19532	24424	29056
Turn off 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/method name string.

We can consider this before compiling all the class and method names to confuse, with the same compression JS, the long name to replace the short name, the benefits in addition to reduce the volume, but also a great improvement in security, others get the executable file on it class-dump out 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, that is, the stack crash stack method name will be confused, need to add a layer of confusion----the original conversion, implementation and use of the cost is a bit high.

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, the various ways to reduce the size of the iOS installation package are listed to make a checklist diagram:

iOS executable Slimming method