接上篇《Android App体积优化篇 》IOS的App的体积过大达到了ipa安装包达到了84.1M的体积，提出要减小体积（其实就是想和Android一起都进行减小），一开始是想抽点点时间来进行这个需求不想花太多时间，开会的时候召集IOS工程师以及Android工程师一起提了几个思路包括：
- 1.查看无用的第三方库；
- 2.查看无用的图片；
- 3.查看是否有过大的图片；
因为App经过了几波开发和设计所以可能里面会有些乱，先让工程师先去查找并且报上来，隔了2天左右报上来的IOS 这边没有无用的第三方库，无用图片已经去掉，似乎没有过大的图片，整体体积优化几M都不到后来赶项目就做项目去了没有继续跟踪，最近刚刚解决完Android体积过大的问题于是马不停蹄的我又亲自来到IOS项目去一窥究竟
“老三样”：
- 0.查看是否有无用的资源；
- 1.查看无用的第三方库；
- 2.查看无用的图片；
- 3.查看是否有过大的图片；
首先利用git 把代码pull到发布分支最新代码，利用Xcode Archive项目出ipa包查看了原有体积84.1M，确实不小，在优化之前我查阅了不少IOS App的优化方案我摘选出几个比较有效的列出来：
1.更改Xcode Build Settings里面的配置包括：
- Build Setting > Asset Catalog Compiler - Options 设置为space
- Flatten Compiles XIB Files设置为YES
- Strip Linked Product 的默认设置为YES 并且 Deployment Postprocessing也设置为 YES
- Build Settings -> Optimization Level 设置为Fastest, Smalllest
然后Archive归档出ipa包查看体积这几个我都试了结果不像网络说的那样效果明显，老实话我这边项目效果很不明显就小了0.1M左右
然后继续思考直到发现第一条（怎么老是和鱼🐟相关···）就是Valid Architectures
当然首先要是 Architectures = $(ARCHS_STANDARD)，Valid Architectures
这里面包含了ARMV7指令集的设备（ARMV7包括的是4S及其以下的老设备）我们是做智能家居产品的App所以可以忽略这部分手机
配置解释如下：
Architectures：
指定工程被编译成可支持哪些指令集类型，而支持的指令集越多，就会编译
出包含多个指令集代码的数据包，对应生成二进制包就越大，也就是ipa包会
变大(Space-separated list of identifiers. Specifies the architectures (ABIs,
processor models) to which the binary is targeted. When this build setting
specifies more than one architecture, the generated binary may contain
object code for each of the specified architectures. )。
Valid Architectures：
限制可能被支持的指令集的范围，也就是Xcode编译出来的二进制包类型最终
从这些类型产生，而编译出哪种指令集的包，将由Architectures与Valid
Architectures（因此这个不能为空）的交集来确定(Space-separated list of
identifiers. Specifies the architectures for which the binary may be built.
During the build, this list is intersected with the value of ARCHS build setting;
the resulting list specifies the architectures the binary can run on. If the
resulting architecture list is empty, the target generates no binary.)。
Build Active Architecture Only：
指定是否只对当前连接设备所支持的指令集编译
当其值设置为YES，这个属性设置为yes，是为了debug的时候编译速度更快，
它只编译当前的architecture版本，而设置为no时，会编译所有的版本。 所以，
一般debug的时候可以选择设置为yes，release的时候要改为no，以适应不同设备。
**所以删除ARMV7架构作用就是指定工程被编译成不支持ARMV7指令集类型（主要是剔除了第三方库里面包含的ARMV7架构
2.按照自己项目架构分离第三方库的架构：
这个方案在网上很少被提到，其实这个对于你的项目压缩提交有很明显的效果，稍稍提一下很多的库都是一个.a或者一个.framework其实用里面是包含好几个ARM架构的包合成一起的，特别是第三方的SDK更是如此，你可以利用lipo -info 命令查看就可以知道），例如：
XXX:IDOBlueUpdate.framework XXX$ lipo -info libName
Architectures in the fat file: libName are: armv7 arm64
所以我们可以利用lipo -thin命令来对于这些库进行分离
XXX:IDOBlueUpdate.framework XXX$ lipo libName -thin arm64 -output ./libName_arm64
XXX:IDOBlueUpdate.framework XXX$ lipo libName -thin armv7 -output ./libName_armv7
利用该命令来进行分离库只取你想要的库，每个库几乎能减少的一半体积
3.查看第三方无用的库：
接上篇Android体积篇优化，这次是从项目中发现排序发现了些端倪就是Assets文件夹里面有个fonts的发现体积比较大14M左右，心想难道是和Android一样不用的字体吗，打开一开果然是这样直接去掉（不同平台工程师们还分享资源，不容易啊），另外发现了一个第三方公司的.so库里面体积比较大几十M，打开进去看看发现一些有意思的现象里面不紧包含了他们自己的东西还包含了Fabric.framework，Crashlytics.framework这两个库加起来近20M，熟悉的朋友都知道这两个库是记录App日志以及奔溃的，我们App有自己的崩溃统计没必要用这个所以直接去掉，所以还是那个问题大家在包含第三方库的时候一定要搞清楚每个库的功能以及作用，马上归档查看ipa的情况体积又小了13.6M
4.查看无用的图片以及资源
这里需要用到一个工具来查看，推荐给大家名字叫做：LSUnusedResources 这个工具可以查询项目里面无用的图片资源
需要自己下载编译运行，使用还是很简单的，速度很快使用很方便，于是扫描然后分别去查看对应删除
PS：还是要记住扫描出来的无用资源要让相关工程师一个个去看再删除，因为有些资源如果是动态引用的被删了就麻烦了
5.查看无用的类
这里再次介绍一个工具给大家：WHC_Scan软件可以分析项目里面没有使用到的类，该项目需要自己下载源码自己编译运行
界面如下：
PS: 对于扫描出来的类一定要进行编译运行去验证该方案，避免扫描出现的问题，对于要删除的类要做内部小组核对，以免项目出现问题，工具只是辅助并不是万能的
6.查看过大的图片
经过发现这一步其实很重要而且是往往会被忽略的重要步骤，IOS项目的文件夹的格式没有Android那么直接不好直接从文件夹分析大小，干脆来个直接的直接在图片文件夹里面搜索.png然后按照大小排个序发现还是有很多图片有问题的，首先就是开机启动图过于大了3X居然达到了2.4M夸张，于是像Android排查那样把大于10K的图片全部择出来那个UI重新审核然后该压缩的压缩然后重新导出
