集成第三方FrameWork导致App体积增长估算

工作中在接入一个网络安全防护sdk时，sdk方提供的是Framework压缩文件，里面包含的是编译后的二进制文件和头文件。当看到二进制文件有20M时，就会怀疑sdk太大，导致最终App的体积增长过多。后续分析后，虽然二进制文件有20M，但是实际造成的App体积增长应该只有2M左右。这个二进制文件其实就是一个静态库.a文件。下面解释下这个二进制文件有20M，但造成app实际的体积增长只有2M的原因。

BitCode

简单解释BitCode就是一种LLVm的中间编码，只要有BitCode，在没有源代码的情况下，我们都能直接生成最终的可对应于各个cpu架构可执行文件。
所以在上传到苹果商店时，如果我们同步上传了bitcode，后续如果iphone的cpu架构变更，譬如从arm变成其他架构，这个时候都不需要开发重新编译打包上传。apple可以用bitcode直接生成对应架构的app.
详情链接：https://juejin.cn/post/6968272595686785031

判断分析步骤

分析framework的体积主要是2部分，一个是bitcode，一个是支持的cpu架构数量。

Bitcode分析:假设Framework中的静态库文件名称为xxxx,在Mac下使用系统工具otool(用于查看object file的工具)

otool -l xxxx | grep __LLVM | wc -l 

如果输出的数字不为0，就表示带有Bitcode
CPU架构数量分析：
使用mac自带的命令行工具file来查看xxxx文件:

file xxxx

会输出如下：

xxxx: Mach-O universal binary with 4 architectures: [arm_v7:current ar archive] [i386] [x86_64] [arm64]
xxxx (for architecture armv7):	current ar archive
xxxx (for architecture i386):	current ar archive
xxxx (for architecture x86_64):	current ar archive
xxxx (for architecture arm64):	current ar archive

可以看到支持了4种cpu架构，自然体积就会比较大。
由于现在的手机cpu基本都是都是arm64的，以arm64架构的文件大小作为最终会导致的app体积增长大小。
首先需要单独取出arm64的文件，命令如下:

lipo -thin arm64 xxxx -output xxxx.arm64.a

这样就拿到了单一cpu架构的静态库二进制文件，这个时候该静态库还是包含bitcode，所以其大小肯定还是比真正集成到app后的体积大。那么有办法去除静态库中的bitcode吗？搜索了一圈，貌似没有办法。根据bitcode只是中间表示代码的原理，（不包含bitcode的二进制文件大小/包含bitcode的二进制文件大小）的值应该是比较稳定的。
后来sdk方提供了不包含bitcode的Framework，最终该比例值估算为0.383.
那么一个包含了bitcode的framework，集成到app后（假设app不开启bitcode编译），最终导致的app体积增长就是framework中的二进制文件大小*0.383/CPU架构数量