####1、手动整理
#####(1) 手动整理图片资源
之前对图片的管理很混乱，不仅每个控制器的文件夹的统计目录都有images文件夹，每个子模块的控制器同级目录下也有iamges文件夹。同时由于管理理念的变迁，以前的/TKApp/images和/TKApp/resource/images目录下还存放着图片。右键点击show in Finder查看，还可以看到有些图片没有引入工程但是在目录下还存在着。
#####(2)把没有使用的代码文件删除
有一部分代码是之前的模块文件，但是现在没有在用这些代码了。所以也要把他们找出来并删除掉。特别注意的是，有些模块可能没有引入到工程，所以真实目录下也要检查。
####2、工具分析来整理图片资源
对于不能立即找到在工程中没有用的图片，我们可以用【LSUnusedResources】开源软件(下载地址：传送门)来快速找出没被使用的资源文件。
使用方法如下：
- 输入
Xcode project path; - 在
Code Suffix把工程用存在的文件格式打上勾，同时取消Ignore右旁的勾； - 点击右下方的
Search开始查找； - 查找完成后，选中要删除的资源后，点击右下方的
Delete可以删除对应目录下的该资源文件；
查找到的结果截图如下：
由于工程是由各负责人开发完成的，虽然代码在这里，可以每张全局搜索来查看有没有使用，但是未免工作量太大。同时也不是真正清楚这些找到的图片有没有间接使用到。还有就是源头修改才是正道，不然下次工程覆盖后，删除的图片就又回来了。
所以找到这些没有使用的资源文件后，把各个模块的资源图片整理出来，然后考虑告知经理，让各个模块的负责人去检查各自的代码，把没有使用的图片删除之，有间接使用的图片，说明一下。
下图是删除了行情、ygt、trade、open的无用图片后的安装包对比，减小了0.4MB:
具体整理的文件可以看《华安没有用到的图片统计》
####3、对图片进行无损压缩
清理完没有使用的图片资源后，可以进一步地，对工程中使用到的图片进行无损压缩，减小图片的总大小。
3.1、使用【ImageOptim】
【ImageOptim】的下载地址为：传送门
具体使用，就是直接把要压缩的图片拖到【ImageOptim】窗口里面，ImageOptim机会对图片进行压缩。截图如下：
对拖进去先后坐下对比，图片确实变小了：
3.2、使用【tinyPNG】网站在线无损压缩(或者使用tinyPNG的开元软件【TinyPNG4Mac】进行无损压缩)
【tinyPNG】网站的地址为(传送门)
【TinyPNG4Mac】的下载地址在:传送门。这个
鉴于【LaunchImage】的图片用【ImageOptim】无损压缩不理想，于是把这组图片都拖到【TinyPNG】网址去压缩，压缩效果如下：
打包后的前后对比如下：
####4、使用.xcassets来管理图片以减小安装包大小
为了说明使用.xcassets来管理可以有效减小安装包大小，我备份了一份【华安徽赢】的工程，主工程保持不变，备份工程把所有的.png图片都放在Images.xcassets下
从上一张图可以看出，苹果确实会为放在.xcassets里面的图片进行压缩，安装包减小了0.2MB。
####5、编译器的优化
1、Build Settngs中的配置项
Build Settings->Optimization Level有几个编译优化选项，release版应该选择Fastest, Smalllest，这个选项会开启那些不增加代码大小的全部优化，并让可执行文件尽可能小。
项目已经设置了这个选项。
2、去除符号信息
Build Settings中的Strip Linked Product、Strip Debug Symbols During Copy 和 Symbols Hidden by Default在release版本应该设为YES，可以去除不必要的调试符号。Symbols Hidden by Default会把所有符号都定义成”private extern”。这些选项目前都是XCode里release的默认选项，但旧版XCode生成的项目可能不是，可以检查一下。
项目之前已经设置Strip Linked Product、Strip Debug Symbols During Copy为Yes了。设置Symbols Hidden by Default为Yes解压ipa包后可以减小0.1MB：
3、配置App Thinning为包瘦身
App Thinning是伴随iOS9一起出现的，因此该功能也仅对iOS9以上设备生效。App Thinning主要包含以下3个方面：App Slicing(应用程序的划分)、On Demand Resources(按需加载资源) 和 Bitcode。
3.1、App Slicing
根据苹果官方文献的描述「Slicing 是为应用捆绑包创建、分发不同变体以适应不同目标设备的过程。一个变体只包含针对某个目标设备的可执行架构与资源。」 换句话说，App Slicing仅向设备传送与之相关的资源（取决于屏幕分辨率，架构等等）。事实上，App Slicing 负责处理 App Thinning 的主要流程。
当你准备好提交 app 时，通常会（但必须使用 Xcode7，因为它包含支持 App Thinning 的 iOS9 SDK）向 iTtunes Connect 上传 .IPA 或 .App 文件。然后，应用商店分割该应用，创建特定的变体以适应性能不同设备。
3.2、On Demand Resources
按需加载资源是在 app 第一次安装后可下载的文件。举例说明，当玩家解锁游戏的特定关卡后可以下载新关卡（和这个关卡相关的特定内容）。此外，玩家已经通过的关卡可以被移除以便节约设备上的存储空间。
开启按需加载资源功能涉及改变 Xcode 中的设置：在Build Settings下，将Enable On Demand Resources设置为Yes。
3.3、Bitcode
本质上Bitcode也是苹果在用户下载前优化app的新方式。Bitcode 使得 app 无论在何设备上都能快速高效地运行。Bitcode 使用最新的编译器自动编译app并且针对特定架构进行优化。（例如，针对 iPhone 6s和 iPad Air 2等 64 位处理器的 arm64）
Bitcode 不会下载应用针对不同架构的优化，而仅下载与特定设备相关的优化，使得下载量更小，同时与前文所述的 App Thinning 技术紧密合作。
Bitcode 是 iOS 上较新的功能，对于新的项目需要手动开启。在Build Settings下，将Enable Bitcode设置为Yes来完成。
设置后打包，报错，提示IM的XMPPRoomHybridStorage类还支持bitcode：
4、设置Make Strings Read-Only为Yes
工程已设置。
5、去掉异常支持，Enable C++ Exceptions 和 Enable Objective-C Exceptions设为NO，并且Other C Flags添加-fno-exceptions。
Archive后报错，原因是关闭Enable Objective-C Exceptions后@try{//...} @catch() {//...}不能使用了。
Enable Objective-C Exceptions设置回去后，打包，发现包大小没有变化：
####6、代码优化
