如何解决IOS可执行文件TEXT段超标

最近要做IOS测试,提交的时候不幸发现提交失败,可执行文件的TEXT段超过了80M。因为当时是出测试包,就强行修改成APP只支持9.0以上来解决。但是正式版可不能这么干,必须做一些优化。

Unity的IL2CPP技术会将C#代码的编译结果翻译成C++代码,这个翻译过程中会产生大量的代码。尽管Unity的新版本已经比早起版本优化很多了,但是很不幸,我们还是超标了。

解决问题的思路还是提出问题,分析问题,解决问题。其实我对这块也不是很熟悉,查阅了一些资料之后就开始优化,以下记录了优化过程。

查看可执行文件段大小

首先进行Archives。Mac系统使用XCode生成项目之后,生成的执行文件都在DerivedData目录下。可以使用Command
+ Shift + G跳转,目标地址:~/资源库/Developer/Xcode/DerivedData/

进入生成的目录,找到包CN,查看包内容,找到同名的可执行文件。打开终端,进入对应目录,使用命令size即可显示可执行文件的各段的大小:

MacBook-Pro:WorkS hanyufei$ size ./cn

__TEXT __DATA __OBJC others dec hex

40370176 3932160 0 1884160 46186496 2c0c000 ./cn (for
architecture armv7)

47300608 5947392 0 4296228864 4349476864 1033fc000
./cn (for architecture arm64)

第一列是TEXT段的大小,上下分别对应Armv7和Arm64,可见两者之和超过了80M。


使用MachOView分析端大小

如果想要看到更具体一些的信息,还可以使用MachOView。下载之后运行,使用Open打开可执行文件,然后可以看到更详细的信息:

可以看到主要的空间还是代码,常量,字符串,方法名等占用的并不多。


分析LinkMap

如果更进一步想要看到更具体的每个文件的信息可以使用LinkMap。首先需要开启LinkMap,记录LinkMap文件的位置。

  • 在Archives的同级目录下,找到LinkMap文件

/Users/hanyufei/Library/Developer/Xcode/DerivedData/Unity-iPhone-ffsoehaumctgaoadknrgjgvfcbsc/Build/Intermediates.noindex/Unity-iPhone.build/ReleaseForRunning-iphoneos/Unity-iPhone.build

可以看到一些第三方的库比较大,但是代码部分还是得不到比较明确的结果。那干脆直接一点,去看生成工程的Native文件的大小。


分析Native目录

在导出的XCode工程目录下的Classes目录下可以找到到Native目录,可以看到它的大小是非常大的,占用了369.4M。推算一下只要超过了300M就有可能导致超标。

进行一些更详细的分析:

可见一些库占和一些导表相关的功能占用的比较大,相关同事做了优化和精简。

另外一个同事找了github.com/terryyin/liz的分析工具做了一下排序,可以更清晰的看到类的大小:


优化方案:

  • 找到了瓶颈之后,我们开始进行优化,在优化的过程中又接了SDK导致可执行文件更大,又进行多次优化。
  • Unity的一些优化设置,这部分基本已经是最优了。
  • 删除无用代码,减少了Lua的导出文件(可以尝试自动化的工具,但是会有些风险)。
  • 删除无用库和插件,一些必须使用的库使用更轻量的库
  • 反射和泛型
  • 把TEXT段中不用的数据移到RODATA只读数据段

-Wl,-rename_section,__TEXT,__cstring,__RODATA,__cstring

-Wl,-rename_section,__TEXT,__gcc_except_tab,__RODATA,__gcc_except_tab

-Wl,-rename_section,__TEXT,__const,__RODATA,__const

-Wl,-rename_section,__TEXT,__objc_methname,__RODATA,__objc_methname

-Wl,-rename_section,__TEXT,__objc_classname,__RODATA,__objc_classname

-Wl,-rename_section,__TEXT,__objc_methtype,__RODATA,__objc_methtype

  • 其他

优化结果:

__TEXT __DATA __OBJC others dec hex

35323904 4276224 0 6946816 46546944 2c64000 ./cn (for
architecture armv7)

39469056 6733824 0 4303519744 4349722624 103438000
./cn (for architecture arm64)

可见优化成果喜人。经过以上简单优化后,Native容量大幅减少,部分代码段的内容也移到了只读段,最终通过了检测。因为后续集成了58M的SDK,所以TEXT的大小看上去只减少了一点,如果SDK再做一些优化的话包体可以更小。因为测试时间比较紧迫,此次优化还是非常保守的。


参考资料:

cnblogs.com/bodong/p/48

blog.csdn.net/wm9028/ar

everettjf.com/2016/08/1

编辑于 2018-01-12

文章被以下专栏收录