IOS Executable File slimming method, ios Executable File slimming

IOS Executable File slimming method, ios Executable File slimming

Reducing the size of the iOS installation package is what many large and medium-sized apps need to do. Generally, they will first start with resource files, compress images/audios, and remove unnecessary resources. After optimizing these resources, we can also try to slim down the executable files. The larger the project, the larger the size of the executable files, because the AppStore encrypts the executable files, this results in a low compression rate for executable files. After compression, the size of the executable files in the entire APP installation package is approximately 80% ~ 90% is worth optimizing. The following describes the optimization points found during the study of executable files. Linkmap is used in the study. For details about linkmap and its generation, refer to the composition of iOS executable files.

Compilation Option 1. Compiler optimization level

Build Settings-> Optimization Level has several compilation Optimization Options. for release, Fastest and Smalllest should be selected. This option will enable all Optimization without increasing the code size, make the executable file as small as possible.

2. Remove Symbol Information

Strip Linked Product/Deployment Postprocessing/Symbols Hidden by Default should be set to yes in the release version to remove unnecessary debugging Symbols. Symbols Hidden by Default defines all Symbols as "private extern". For more information, see the official documentation.

These options are currently the default options for release in XCode, but the project generated by the old version of XCode may not. Check them. Other optimizations can also be referenced by the official document-codefootprint.pdf

Third-party library statistics

Many third-party static libraries will be introduced in the project. If you know the size of these third-party libraries in the executable files, you can evaluate whether it is worthwhile to find an alternative solution to remove this third-party library. We can calculate this information from linkmap and write a node for it. js script, you can use linkmap to count each. o volume of the target file and each. for the volume occupied by static database a, see here (FQ required ).

ARC-> MRC

Someone suggested that the executable files compiled using the code written by ARC would be larger than MRC, probably because the ARC Code will have more retain and release commands in some cases, for example, if a method is called, the returned object will be retain. After exiting the scope, it will be release. The MRC does not need it. The Assembly command increases, the machine code increases, and the executable file increases. There are also differences in implementation of other details.

How much will ARC increase? I think it is difficult to calculate the accuracy from the increase and decrease of Assembly commands. This involves too much details and must be calculated from the statistical perspective. Compare the size of the _ TEXT code segment of several open-source projects that support both ARC and MRC when enabling and disabling ARC. Only compare the _ TEXT code segment because:

Lab data:

	MBProgressHUD	SDWebImage	FMDB
Enable ARC	19532	24424	29056
Disable ARC	17648	22575	25848
Comparison	Limit 9.6%	Limit 7.5%	Limit 11%

The result is that ARC will increase the size of the code segment by 10%. Considering that the code segment accounts for about 80% of the executable files, it is estimated that the impact on the entire executable file will be 8%.

It can be evaluated whether it is worthwhile to change some modules of the project to MRC for a 8% reduction in volume, so that the maintenance cost of the program has increased. We generally do not recommend this in special cases.

Useless code

Create a class in the project and add several methods to it, but do not import it anywhere. After building the project, observe the linkmap. You will find that the class is still compiled into the executable file.

Based on the C ++ experience, the class and method compilers that are not used will be optimized and will not be compiled into the final executable file, but the object-c is different, because of the dynamic characteristics of object-c, it can obtain this class and method through class and method name reflection for calling, so even if a class is not used in the code, the compiler cannot guarantee that this class will not be called through reflection at runtime, so as long as it is a file in the project, whether or not it is used or not, it will be compiled into an executable file.

In this regard, we can use scripts to traverse the entire project file and find all class files that are not referenced and methods that are not called, remove them when there are no other dynamic calls. If the entire project lasts a long time and the Code remains a lot left behind, This cleanup will save a considerable amount of space for executable files.

Class/Method Name Length

By observing linkmap, we can find that each class and method name has a corresponding string value in the _ cstring segment, therefore, the length of the class and method names also affects the size of executable files. The reason is the dynamic characteristics of object-c, because you need to find this class/method for calling through class/method name reflection, the object-c object model will save the class/method name strings.

To solve this problem, we can consider obfuscation of all classes and method names before compilation. Like compressing js, we can replace long names with short names. In addition to reducing the size, security is also greatly improved. The results of the class-dump output from executable files obtained by others are obfuscated class and method names, you cannot guess what a method is doing from the class and method names, so it is difficult to hook the sub-Program for hack. However, there is a disadvantage in this process, that is, the stack method name obtained from the Reverse Solution of the crash stack will be obfuscated. You need to add a new layer of obfuscation-> original name conversion, which means the implementation and use costs are a bit high.

In fact, the length of this part is relatively small, and the medium-sized project is several hundred kb. You can try it if you have high security requirements.

Redundant string

All static strings defined in the Code are recorded in the _ cstring segment of the executable file. If there are many logs in the project, this space is also considerable, it also has a size of several hundred kb. You can consider clearing all redundant strings. In addition, if there is a particularly long string, it is recommended to extract and save it as a static file, because AppStore encrypts executable files, resulting in a low compression rate, the compression ratio of a particularly long string after being extracted from a static resource file is much higher than that of an executable file.

CheckList

Finally, we listed the methods to reduce the size of the iOS installation package as a CheckList chart: