如何减小ios安装包大小

Posted 2023-05-11

　　首先是检查.app bundle，看一下程序包里面哪些文件占的空间最大。

　　在做任何相关优化之前，我们需要做一些权衡。通过权衡，可以知道把优化的重点集中在什么地方。本文提到的一些技术缺点我们也需要做出考虑，我们必须考虑相关影响，以确保做出正确的决定。如果不做权衡的话，我们无法知道需要对程序做出什么样的改变。

　　当第一安装ios程序时，需要下载完整的一个.ipa文件。(注意这不同于升级)。实际上.ipa文件就是一个.zip结构。

　　*找出程序的.ipa文件方法：

　　1、从App Store下载应用，然后利用iTunes对iOS设备做同步处理，接着查看目录：
　　~/Music/iTunes/iTunes Music/Mobile Applications，就能找到.ipa文件了。

　　2、当然我们也可以通过使用: Xcode的Archive命令来构造出.ipa文件——该文件与提交到App Store上的格式基本一致。

　　检查.ipa文件

　　简单的将后缀为.ipa文件修改为.zip，然后利用Finder将其解压出来。右键单击解压出来的.app bundle，选择显示包内容，以查看里面的资源文件。通过该方法我们可以看到哪些文件占的空间最大。

　　*注意：.app bundle是经过压缩的，并且有些文件的压缩效果要比别的文件好，所以压缩后的效果才是才是最重要的。不过一般情况下在压缩前最大的文件，在压缩后依旧是最大的文件。我们可以将某个文件删除，然后在Finder中右键单击，选择压缩，这样可以更加精确的测量文件压缩效果。

　　Build Settings

　　编译选项

　　将build setting中的Optimization Level设置为Fastest, Smallest [-Os]; 将build setting 中的Strip Debug Symbols During Copy设置为YES(COPY_PHASE_STRIP = YES)，这样可以减小编译出二进制文件的尺寸。这里提到的这些设置在Xcode工程中对于Release的配置是默认的。

　　*警告：这些设置会让你的程序很难debug。在一般开发环境build中不建议这样设置

　　Target针对较少的CPUs

　　默认情况下，Xcode工程都配置为：对程序指定的特定CPU类型做优化处理，以生成相对于的可执行文件。不同的硬件，将运行不同的可执行代码。虽然这样优化后的程序，只能针对某些设备运行，但是这大大减小可执行程序的大小。

　　要想只设定特定类型的CPUs，可以修改build setting中的Architectures，将其从Standard $(ARCHS_STANDARD)修改为你希望支持的列表中对应的特定类型CPU。有效的CPU名称列在Valid Architectures (VALID_ARCHS) build setting中。请不要修改Valid Architectures设置项，最好由Xcode管理。

　　Assets

　　对应用程序做一个完整性检查

　　利用Inspecting Your App中介绍的流程，对.app bundle做一个全面的检查，以了解那些是真正需要用到的。在程序中，经常会包含一些额外的文件，例如readme之类的，这些从来都不会被用到。

　　将数据从代码中剥离出来

　　将所有的资源(例如很长的字符串)从代码中剥离出来，并存入外部文件，这样会减小最终文件下载的大小，因为这些文件的压缩效果更好。(参考iOS App Store Specific Considerations中的完整介绍。)

　　Image Assets

　　尽量使用8-bit图片

　　使用8-bit的PNG图片，比32-bit的图片能减少4倍的压缩率。由于8-bit的图片支持最多256种不同的颜色，所以8-bit的图片一般只应该用于一小部分的颜色图片。例如灰度图片最好使用8-bit。

　　针对32-bit的图片尽量使用高压缩的比率

　　利用Adobe Photoshop的Save For Web可以减小JPEG和PNG的图片大小。在Xcode中，默认情况下，会自动的使用pngcrush来压缩.png图片。

　　Audio Assets

　　音频的压缩

　　参考WWDC中的Audio Development for Games，里面介绍了如何有效的处理音频。常规来说，我们要使用AAC或MP3来压缩音频，并且可以尝试降低一下音频的比特率。有时候44.1khz的采样是没有必要的，稍微低一点的比特率也不会降低音频的质量。

　　*温馨提示：以上这些方法仅供参考，而且仅适用于对程序占用空间特别在意又对自己的耐心非常有信息的同学们，要不然，头疼呵呵了什么的，只好自己忍着啦~

　　iOS App Store相关因素

　　作为提交到App Store中app里的可执行文件是被加过密的。加密的副作用是可执行文件的压缩效果没有之前的好了，因为加密会隐藏一些细节问题。因此，从App Store下载下来的.ipa文件大小要比从本地build出来的.ipa文件大。

　　注意：将长文本内容和表数据等从代码中移除，并添加到外部文件中，这样可以减小最终安装包下载的大小——因为这些文件的压缩效果更好。

　　如果你选择Organizer window中的某个archived，然后点击Estimate Size，Xcode可以对最终分发的程序尺寸做出一个评估。这里并不考虑Mac App Store上面的和企业级部署的iOS程序。 参考技术A 首先是检查.app bundle，看一下程序包里面哪些文件占的空间最大。

　　在做任何相关优化之前，我们需要做一些权衡。通过权衡，可以知道把优化的重点集中在什么地方。本文提到的一些技术缺点我们也需要做出考虑，我们必须考虑相关影响，以确保做出正确的决定。如果不做权衡的话，我们无法知道需要对程序做出什么样的改变。

　　当第一安装iOS程序时，需要下载完整的一个.ipa文件。(注意这不同于升级)。实际上.ipa文件就是一个.zip结构。

　　*找出程序的.ipa文件方法：

　　1、从App Store下载应用，然后利用iTunes对iOS设备做同步处理，接着查看目录：
　　~/Music/iTunes/iTunes Music/Mobile Applications，就能找到.ipa文件了。

　　2、当然我们也可以通过使用: Xcode的Archive命令来构造出.ipa文件——该文件与提交到App Store上的格式基本一致。

　　检查.ipa文件

　　简单的将后缀为.ipa文件修改为.zip，然后利用Finder将其解压出来。右键单击解压出来的.app bundle，选择显示包内容，以查看里面的资源文件。通过该方法我们可以看到哪些文件占的空间最大。

　　*注意：.app bundle是经过压缩的，并且有些文件的压缩效果要比别的文件好，所以压缩后的效果才是才是最重要的。不过一般情况下在压缩前最大的文件，在压缩后依旧是最大的文件。我们可以将某个文件删除，然后在Finder中右键单击，选择压缩，这样可以更加精确的测量文件压缩效果。

　　Build Settings

　　编译选项

　　将build setting中的Optimization Level设置为Fastest, Smallest [-Os]; 将build setting 中的Strip Debug Symbols During Copy设置为YES(COPY_PHASE_STRIP = YES)，这样可以减小编译出二进制文件的尺寸。这里提到的这些设置在Xcode工程中对于Release的配置是默认的。

　　*警告：这些设置会让你的程序很难debug。在一般开发环境build中不建议这样设置

　　Target针对较少的CPUs

　　默认情况下，Xcode工程都配置为：对程序指定的特定CPU类型做优化处理，以生成相对于的可执行文件。不同的硬件，将运行不同的可执行代码。虽然这样优化后的程序，只能针对某些设备运行，但是这大大减小可执行程序的大小。

　　要想只设定特定类型的CPUs，可以修改build setting中的Architectures，将其从Standard $(ARCHS_STANDARD)修改为你希望支持的列表中对应的特定类型CPU。有效的CPU名称列在Valid Architectures (VALID_ARCHS) build setting中。请不要修改Valid Architectures设置项，最好由Xcode管理。

　　Assets

　　对应用程序做一个完整性检查

　　利用Inspecting Your App中介绍的流程，对.app bundle做一个全面的检查，以了解那些是真正需要用到的。在程序中，经常会包含一些额外的文件，例如readme之类的，这些从来都不会被用到。

　　将数据从代码中剥离出来

　　将所有的资源(例如很长的字符串)从代码中剥离出来，并存入外部文件，这样会减小最终文件下载的大小，因为这些文件的压缩效果更好。(参考iOS App Store Specific Considerations中的完整介绍。)

　　Image Assets

　　尽量使用8-bit图片

　　使用8-bit的PNG图片，比32-bit的图片能减少4倍的压缩率。由于8-bit的图片支持最多256种不同的颜色，所以8-bit的图片一般只应该用于一小部分的颜色图片。例如灰度图片最好使用8-bit。

　　针对32-bit的图片尽量使用高压缩的比率

　　利用Adobe Photoshop的Save For Web可以减小JPEG和PNG的图片大小。在Xcode中，默认情况下，会自动的使用pngcrush来压缩.png图片。

　　Audio Assets

　　音频的压缩

　　参考WWDC中的Audio Development for Games，里面介绍了如何有效的处理音频。常规来说，我们要使用AAC或MP3来压缩音频，并且可以尝试降低一下音频的比特率。有时候44.1khz的采样是没有必要的，稍微低一点的比特率也不会降低音频的质量。

　　*温馨提示：以上这些方法仅供参考，而且仅适用于对程序占用空间特别在意又对自己的耐心非常有信息的同学们，要不然，头疼呵呵了什么的，只好自己忍着啦~

　　iOS App Store相关因素

　　作为提交到App Store中app里的可执行文件是被加过密的。加密的副作用是可执行文件的压缩效果没有之前的好了，因为加密会隐藏一些细节问题。因此，从App Store下载下来的.ipa文件大小要比从本地build出来的.ipa文件大。

　　注意：将长文本内容和表数据等从代码中移除，并添加到外部文件中，这样可以减小最终安装包下载的大小——因为这些文件的压缩效果更好。

　　如果你选择Organizer window中的某个archived，然后点击Estimate Size，Xcode可以对最终分发的程序尺寸做出一个评估。这里并不考虑Mac App Store上面的和企业级部署的iOS程序。 参考技术B 首先是检查.app bundle，看一下程序包里面哪些文件占的空间最大。

　　在做任何相关优化之前，我们需要做一些权衡。通过权衡，可以知道把优化的重点集中在什么地方。本文提到的一些技术缺点我们也需要做出考虑，我们必须考虑相关影响，以确保做出正确的决定。如果不做权衡的话，我们无法知道需要对程序做出什么样的改变。

　　当第一安装iOS程序时，需要下载完整的一个.ipa文件。(注意这不同于升级)。实际上.ipa文件就是一个.zip结构。

　　*找出程序的.ipa文件方法：

　　1、从App Store下载应用，然后利用iTunes对iOS设备做同步处理，接着查看目录：
　　~/Music/iTunes/iTunes Music/Mobile Applications，就能找到.ipa文件了。

　　2、当然我们也可以通过使用: Xcode的Archive命令来构造出.ipa文件——该文件与提交到App Store上的格式基本一致。

　　检查.ipa文件

　　简单的将后缀为.ipa文件修改为.zip，然后利用Finder将其解压出来。右键单击解压出来的.app bundle，选择显示包内容，以查看里面的资源文件。通过该方法我们可以看到哪些文件占的空间最大。

　　*注意：.app bundle是经过压缩的，并且有些文件的压缩效果要比别的文件好，所以压缩后的效果才是才是最重要的。不过一般情况下在压缩前最大的文件，在压缩后依旧是最大的文件。我们可以将某个文件删除，然后在Finder中右键单击，选择压缩，这样可以更加精确的测量文件压缩效果。

　　Build Settings

　　编译选项

　　将build setting中的Optimization Level设置为Fastest, Smallest [-Os]; 将build setting 中的Strip Debug Symbols During Copy设置为YES(COPY_PHASE_STRIP = YES)，这样可以减小编译出二进制文件的尺寸。这里提到的这些设置在Xcode工程中对于Release的配置是默认的。

　　*警告：这些设置会让你的程序很难debug。在一般开发环境build中不建议这样设置

　　Target针对较少的CPUs

　　默认情况下，Xcode工程都配置为：对程序指定的特定CPU类型做优化处理，以生成相对于的可执行文件。不同的硬件，将运行不同的可执行代码。虽然这样优化后的程序，只能针对某些设备运行，但是这大大减小可执行程序的大小。

　　要想只设定特定类型的CPUs，可以修改build setting中的Architectures，将其从Standard $(ARCHS_STANDARD)修改为你希望支持的列表中对应的特定类型CPU。有效的CPU名称列在Valid Architectures (VALID_ARCHS) build setting中。请不要修改Valid Architectures设置项，最好由Xcode管理。

　　Assets

　　对应用程序做一个完整性检查

　　利用Inspecting Your App中介绍的流程，对.app bundle做一个全面的检查，以了解那些是真正需要用到的。在程序中，经常会包含一些额外的文件，例如readme之类的，这些从来都不会被用到。

　　将数据从代码中剥离出来

　　将所有的资源(例如很长的字符串)从代码中剥离出来，并存入外部文件，这样会减小最终文件下载的大小，因为这些文件的压缩效果更好。(参考iOS App Store Specific Considerations中的完整介绍。)

　　Image Assets

　　尽量使用8-bit图片

　　使用8-bit的PNG图片，比32-bit的图片能减少4倍的压缩率。由于8-bit的图片支持最多256种不同的颜色，所以8-bit的图片一般只应该用于一小部分的颜色图片。例如灰度图片最好使用8-bit。

　　针对32-bit的图片尽量使用高压缩的比率

　　利用Adobe Photoshop的Save For Web可以减小JPEG和PNG的图片大小。在Xcode中，默认情况下，会自动的使用pngcrush来压缩.png图片。

　　Audio Assets

　　音频的压缩

　　参考WWDC中的Audio Development for Games，里面介绍了如何有效的处理音频。常规来说，我们要使用AAC或MP3来压缩音频，并且可以尝试降低一下音频的比特率。有时候44.1khz的采样是没有必要的，稍微低一点的比特率也不会降低音频的质量。

　　*温馨提示：以上这些方法仅供参考，而且仅适用于对程序占用空间特别在意又对自己的耐心非常有信息的同学们，要不然，头疼呵呵了什么的，只好自己忍着啦~

　　iOS App Store相关因素

　　作为提交到App Store中app里的可执行文件是被加过密的。加密的副作用是可执行文件的压缩效果没有之前的好了，因为加密会隐藏一些细节问题。因此，从App Store下载下来的.ipa文件大小要比从本地build出来的.ipa文件大。

　　注意：将长文本内容和表数据等从代码中移除，并添加到外部文件中，这样可以减小最终安装包下载的大小——因为这些文件的压缩效果更好。

　　如果你选择Organizer window中的某个archived，然后点击Estimate Size，Xcode可以对最终分发的程序尺寸做出一个评估。这里并不考虑Mac App Store上面的和企业级部署的iOS程序。 参考技术C 删除不必要的图片资源呗

浅析如何减小iOS版微信安装包的大小

引用资源“减肥”

资源瘦身主要是去掉无用资源和压缩资源，资源包括图片、音视频文件、配置文件以及多语言wording。无用资源是指资源在工程文件里，但没有被代码引用。检查方法是，用资源关键字（通常是文件名，图片资源需要去掉@2x @3x），搜索代码，搜不到就是没有被引用。当然，有些资源在使用过程中是拼接而成的（如loading_xxx.png），需要手工过滤。

 

资源压缩主要对png进行无损压缩，用的是ImageOptim工具和compress命令（需要安装XQuartz-2.7.5.dm插件）。不建议对资源做有损压缩，有损压缩需要设计一个个检查，通常压缩后效果不尽人意。

可执行文件减肥

可执行文件瘦身问题，LinkMap文件可以帮助我们寻找优化点，关于“Xcode's Link Map File”的说明请参考附录哦。

1找出无用的selector

以往C++在链接时，没有被用到的类和方法是不会编进可执行文件里。但Objctive-C不同，由于它的动态性，它可以通过类名和方法名获取这个类和方法进行调用，所以编译器会把项目里所有OC源文件编进可执行文件里，哪怕该类和方法没有被使用到。

结合LinkMap文件的__TEXT.__text，通过正则表达式([+|-][.+\\s(.+)])，我们可以提取当前可执行文件里所有objc类方法和实例方法（SelectorsAll）。再使用otool命令otool -v -s __DATA __objc_selrefs逆向__DATA.__objc_selrefs段，提取可执行文件里引用到的方法名（UsedSelectorsAll），我们可以大致分析出SelectorsAll里哪些方法是没有被引用的（SelectorsAll-UsedSelectorsAll）。注意，系统API的Protocol可能被列入无用方法名单里，如UITableViewDelegate的方法，我们只需要对这些Protocol里的方法加入白名单过滤即可。

另外第三方库的无用selector也可以这样扫出来的。

2找出无用Objective-C类

查找无用oc类有两种方式，一种是类似于查找无用资源，通过搜索"[ClassName alloc/new"、"ClassName *"、"[ClassName class]"等关键字在代码里是否出现。另一种是通过otool命令逆向__DATA.__objc_classlist段和__DATA.__objc_classrefs段来获取当前所有oc类和被引用的oc类，两个集合相减就是无用oc类。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

3Protobuf优化

protobuf是Google推出的一种轻量高效的结构化数据存储格式，在微信用于网络协议和本地文件序列化。但google默认工具生成的代码比较冗余，像序列化、反序列化、计算序列化大小等方法都生成在具体的pb类里，每个类的实现大同小异。通过代码分析以及结合protobuf原理，要想把这些方法抽象到基类，派生类提供每个字段相关信息就够了：

field number

field label, optional, required or repeated

wire type, double, float, int, etc

是否packed

repeated的数据类型

另外通过无用selector列表，发现不少pb类属性的getter或setter没有被使用。原先的pb类属性是用@synthesize修饰，编译器会自动生成getter和setter。如果不想编译器生成，则要用@dynamic。甚至我们可以把pb类的成员变量去掉。做法如下：

基类增加id类型数组ivarValues（参考了objc_class结构体ivars做法），用于存放对象的属性值。对象属性值统一用oc对象表示，如果类型是基础类型（primitive，如int、float等），则用NSValue存

重载methodSignatureForSelector:方法，返回属性getter、setter的方法签名

重载forwardInvocation:方法，分析invocation.selector类型。如果是getter，从ivarValues获取属性值并设置为invocation的returnValue；如果是setter，从invocation第二个argument获取属性值，并存放到ivarValues里

重载setValue:forUndefinedKey:、valueForUndefinedKey:，防止通过KVO访问属性Crash

做下性能优化，如pb类在initialize做一次初始化，缓存属性名的hash值，属性的getter、setter方法的objcType等；属性值不用std::map（属性名->属性值），而是改用数组；MRC代替ARC（有些时候ARC自动添加的retain/release挺影响性能的）；等等

把冗余代码去掉后，整个类清爽多了。像GameResourceReq只有3个属性的proto结构体，类方法代码行数由以前的127行变成现在的8行。protobuf精简改造中，精简类方法减少了可执行文件8.8M，去掉类成员变量和类属性改用@dynamic减少了2.5M。

4选择合理的编译设置

Strip Link Product设成YES，WeChatWatch可执行文件减少0.3M

Make Strings Read-Only设为YES，也许是因为微信工程从低版本Xcode升级过来，这个编译选项之前一直为NO，设为YES后可执行文件减少了3M

去掉异常支持，Enable C++ Exceptions和Enable Objective-C Exceptions设为NO，并且Other C Flags添加-fno-exceptions，可执行文件减少了27M，其中__gcc_except_tab段减少了17.3M，__text减少了9.7M，效果特别明显。可以对某些文件单独支持异常，编译选项加上-fexceptions即可。但有个问题，假如ABC三个文件，AC文件支持了异常，B不支持，如果C抛了异常，在模拟器下A还是能捕获异常不至于Crash，但真机下捕获不了（有知道原因可以在下面留言：）。去掉异常后，Appstore后续几个版本Crash率没有明显上升。个人认为关键路径支持异常处理就好，像启动时NSCoder读取setting配置文件得要支持捕获异常，等等

5其他可能的优化

iOS8 Embed-Framework：提取WeChatWatch、ShareExtention和微信主工程的公共代码，可执行文件可以减少5M+，不过这特性需要最低版本iOS8才能用，iOS7设备启动会crash

iOS9

App Thinning：严格来说App

Thinning不会让安装包变小，但用户安装应用时，苹果会根据用户的机型自动选择合适的资源和对应CPU架构的二进制执行文件（也就是说用户本地可执行文件不会同时存在armv7和arm64），安装后空间占用更小

6建立版本增量日志

通过对LinkMap文件的分析，可以得知每个模块可执行文件占用大小。再对比两个版本，就知道业务模块的增量大小。