Brief introduction
Apple has a clear limit on the size of the iOS file, where the size of the text can not exceed 80M, or the arraignment will be rejected by Apple, and if the text segment is too large, then after the Apple encryption, it is easy to extract the failure and other anomalies, and eventually cause the game will not function properly. So theoretically we should as far as possible keep our execution file size less than 80M, according to experience, always keep under 60-70m is relatively more insured. Note that the 80M here is the sum of the text segments of the ARMV7 and arm64 two architectures, rather than a single schema, where the text segment size of a single schema cannot exceed 40M.
iOS's execution file format is Mach-o format, about which can look at Apple's documents or Wikipedia. There are also tools Mach-o Viewer to help you review this information.
Ways to view the size of a text segment
The first step is to look at the method of viewing the text segment size of the file. Under Mac System, after using Xcode to build the project, the generated execution files are in the Deriveddata directory, this directory can use COMMAND + Shift + G to jump past, the target address:
~/Resource Library/developer/xcode/deriveddata/
You can simply parse the subdirectory's timestamp to find out which directory the nearest build is located in, and then go forward to locate the generated execution file, which is a package. View the contents of the package, there will be an executable file with the same name, this file can be equivalent to the EXE file under Windows. It can be copied to the desktop or anywhere else, or it can not be copied. Open the terminal and enter the corresponding directory. Use the command size to display the size data for each segment of the execution file, such as:
bodong-imac:documents bodong$ size./xxgame
__text __data __OBJC others Dec hex
34373632 10518528 0 2179072 47071232 2ce4000./xxgame (for Architecture armv7)
39534592 17203200 0 4296835072 4353572864 1037e4000./xxgame (for Architecture arm64)
The bold data is the size of the text segment, and the final text segment size is the sum of two schema sizes. If they are greater than 80M, your executable file may be rejected by Apple.
Why should you emphasize unity
If we use C + + development directly, there is generally no problem with the text segment being too big, but unity is not the same, Unity uses mono C # development, which translates C # code compilation results into C + + code at build, by Il2cpp, because Il2cpp translates C + + The code needs to emulate the behavior of many C #, so it itself generates much more code than the number of C + + code needed to implement these features. The result of the huge volume of code is that the text segment size will be exceeded, which will have a huge impact on game publishing.
Here I have chosen a very simple project of my own to do the demonstration, the code is very small, so does not cause the text paragraph too big problem, but when your project is large enough, there will be problems. This is used for demonstration, the principle is the same.
The result of Unity's build on iOS is a Xcode project. In the classes/native below, is the code we generated, if the total size of this folder exceeds 300M, then please note that your execution file text paragraph may be exceeded. Therefore, most of the optimization purpose is to reduce the total size of the native folder, according to experience, here to reduce about 5m, the execution of the text section can reduce 1m.
Specific technical details
There are many ways to reduce the size of the native folder, which is listed here. Another part of the optimization of the specific data due to time problems have been unclear, can only remember the approximate data.
1. Be sure to use release compile, must use non-development build.
2. In project build Player setting, API compatibility level must use. NET 2.0 subset. Can be reduced by several m.
3.strip must be open, Unity4 inside select strip level select strip by byte code, select Micro mscorlib may lead to crash, can not be considered; unity5 on strip Engine code. Can be reduced by several m.
4. Remove the. NET base libraries that you must use, such as System.Xml, to use other, more streamlined libraries instead. such as System.Xml's replacement securityparser. After removing this large module, you can reduce the text segment 3-5m. Similarly, System.Linq should also try not to use, one is the capacity problem, the other is the efficiency problem, the third is in the iphone4s below may lead to crash problems.
5. Use less or no templates. This was especially true in earlier versions of Unity (prior to 4.6.6). Templates can cause the code to swell dramatically, and to see how much of the C + + code your template code has contributed in total, search for generic in the native folder, where most of the C + + code is the template's contribution.
If your template generates more than 40m of C + + code, you should be vigilant. The main culprit for these spikes is the System.Collection.Generic of the following containers, such as List,dictionary, whose solution is to type attenuation for class type. I have provided new ListView and Dictionaryview,dictionaryobjectview containers that do not cause the template generation code to skyrocket. The relevant code can be found in one of my open source project Cheatconsole, Address: Https://github.com/sczybt/CheatConsole.
6. Unified use of C #, do not use JavaScript or boo, even if there is only one JavaScript or boo code file, will cause unity to refer to two libraries you do not need Unity.lang and Boo.lang. This can be verified by searching the native folder under the C + + file whose name contains Lang. This requirement also includes third-party libraries, which can cause problems if the code is in the third library.
7. Remove the code that is no longer in use. For example, some of the example code of the three-party library, components that will never be used, and so on.
8. Try to upgrade to a new version of unity, in general, the new version of the older version will do some optimizations in this area. 4.6.6, for example, optimizes about 30% of the generated code capacity compared to 4.6.5.
Summarize
After using the above strategy, our project's execution size decreased from the initial 300m to the 90m,text segment size from 190M to 70M. You can verify these methods and do preventive work ahead of time.
Unity engine iOS execution File size optimization