iOS Application Thin Static Library Solution
Why Give Weight-Loss Program?
In today’s mobile app development, applications are becoming increasingly complex, with more and more functionality being added. As a result, the amount of code is growing exponentially, leading to a significant increase in the size of the application package. This, in turn, causes problems such as slower build times, performance issues, and increased app downloads, consuming the user’s mobile network traffic. To address these issues, we need to slim down our applications.
A Thin Case!
An application consists of multiple resource files and executable files. While optimizing resource files is not within the scope of this article, we will focus on methods for slimming down executable program code. The main executable program code slimming is to find ways to make source code program not involved in compiling or linking. We can achieve this by using source code analysis tools to identify unused functions or classes and removing them from the code.
Application Engineering Construction Rules
To build an application in accordance with the rules, we need to understand the source code compiled and linked rules. We can do this by creating a project in the form of a static library to reduce the size of the executable program code. A static library is a collection of object files that can be linked into an executable program.
A Sample Project
To verify and concrete practice, we created a project on GitHub: YSAppSizeTest. This project consists of two applications, ThinApp and FatApp, which achieve the same function. The two applications are defined in the CA, CB, CC, CD, and CE classes, as well as a UIView (Test) classification and two functions, libFoo1 and libFoo2. However, the two applications have different distribution strategies, resulting in different executable code sizes.
Define and Document Distribution Strategy in FatApp
In the FatApp project, the CA and CB classes are defined in the main project, while the CC, CD, and CE classes, as well as the UIView (Test) classification and libFoo1 and libFoo2 functions, are defined in the FatAppLib static library project.
Define and Document Distribution Strategy in ThinApp
In the ThinApp project, the CA, CB, CC, CD, and CE classes, as well as the UIView (Test) classification and libFoo1 and libFoo2 functions, are defined in the ThinAppLib static library project. The main program is a shell construction project.
Optimization
After the two applications are archived, the size of the FatApp executable program is 367KB, while the size of the ThinApp executable program is 334KB. By using tools such as Mach-O View or IDA, we can see that the code in the FatApp application includes all five classes and the OC libFoo1 function, while the code in the ThinApp application only includes the CA and CC classes and the libFoo1 function.
Application Engineering Construction Rules
According to the project document definitions and references related strategies and theoretical foundation, we can build our application in accordance with the following rules:
- Try to transplant all codes into a static library, while the main program is reserved for a housing program.
- Create a Workspace, then the main program code that works on the project only when creating default, all the newly added code to establish and place the static library project to go.
- Leave only the main project AppDelegate code, other codes are consistent to a static library.
- The relevant code at the AppDelegate call business code statically defined in the library.
- Components of the project by business decouple each component is a static library project.
- Each file in a static library in a class that implements only the best and classification of class and class implementation to achieve the best writing in the same file, the code the same functionality and will be called the code may be stored in a file as possible.
- Do not use -force_load and instead to specify individual to perform a static library loads and use -ObjC -all_load two options in the main project.
- Minimize the classification method defined in a static library OC class, if we must define the classification may be classification method defined in the same and the class definition file, or the classification method defined in one will be called and implementation referenced file in.
- Because according to the rules of static link library classification is not linked into an executable program, unless the link above three options.
- If the classification codes defined separately, then in a file is by defining an inline function in the header file classification, the inline function calls classification implementation file a dumy function, so long as the first document in this category is include or the import will achieve the overall classification of the link to the executable program to go.
Conclusion
In conclusion, to keep our weight-loss program, we should try to put the code in a static library, do not use -ObjC and -all_load options. By following the application engineering construction rules, we can achieve a significant reduction in the size of the executable program code.