Android 包大小优化总结
 
 
众所周知，尽量减少 APP 安装包的大小是非常必要的，减少安装包大小，不仅减少了用户下载时的网络流量消耗，而且还减少了用户的下载等待时间。更重要的是安装包大小也会影响下载转化率。
 
同时，APP 在安装运行过程中，越大的安装包，通常应用安装的时间也会更长，之后再运行时也会占用更大的内存空间。
 
通常，直观来看，减少程序安装包的大小有两条路径：
 
减少程序资源的大小。
减少程序的代码量。
 
1. 优化代码大小
 
开启代码压缩、混淆和优化来减少和优化代码。
 
作用
 
 
代码缩减：从应用及其库依赖项中检测并安全地移除不使用的类、字段、方法和属性。例如，如果你仅使用某个库依赖项的少数几个 API，那么缩减功能可以识别应用不使用的库代码并仅从应用中移除这部分代码。
 
 
混淆：缩短类和成员的名称，从而减小 DEX 文件的大小。
 
 
优化：检查并重写代码，以进一步减小应用的 DEX 文件的大小。例如，如果 R8 检测到从未采用过给定 if/else 语句的 else {} 分支，则会移除 else {} 分支的代码。
 
 
开启方法
 
在当前项目的 app 的 gradle 配置文件中，设置 minifyEnabled 的值为 true：
 
    buildTypes {
        release {
            minifyEnabled true
        }
    }
 
混淆配置文件说明
 
proguard-rules.pro ：ProGuard 规则文件用于添加自定义压缩规则。默认情况下，该文件位于模块根目录。
 
使用 Android Studio 创建新项目或模块时，IDE 会创建一个 /proguard-rules.pro 文件，以便我们添加自己的规则。此外，我们还可以通过将相应文件添加到模块的 build.gradle 文件的 proguardFiles 属性中，从其他文件添加额外的规则。
 
注意：使用 Android Gradle 插件 3.4.0 或更高版本构建项目时，默认不再使用 ProGuard 执行编译时代码优化，而是使用 R8 编译器。
 
2. 减小资源大小
 
开启资源缩减开关
 
从封装应用中移除不使用的资源，包括应用库依赖项中不使用的资源。此功能可与代码缩减功能结合使用，这样一来，移除不使用的代码后，也可以安全地移除不再引用的所有资源。
 
开启方法：
 
    buildTypes {
        release {
            shrinkResources true
        }
    }
 
删除国际化支持
 
如果你的应用的用户群体只是国内用户，则可以只支持中文即可（官方的 support library，默认是支持国际化的）。
 
defaultConfig {
    //strip other than english resources
    resConfigs "zh"
}
 
只提供一些必要的分辨率图片
 
只提供一些必要的分辨率图片，系统会自动匹配最合适分辨率的图片并执行拉伸或者压缩的处理。
 
 
使用 Vertor Drawable 替代 PNG/JPEG 图片
 
在符合条件的情况下，使用 Vertor Drawable 替代传统的 PNG/JPEG 图片，能够极大的减少图片资源的大小。传统模式下，针对不同 dpi 的手机都需要提供一套 PNG/JPEG 的图片，而如果使用 Vector Drawable 的话，只需要一个 XML 文件即可。
 
 
如果必须要使用图片，也应该尽量避免使用 PNG 图片，改为更小的 WebP 格式。
 
复用图片
 
尽量复用已经存在的资源图片，使用代码的方式对已有的资源进行复用，例如：
 
 
以上几点真正执行之后，能够显著减少安装包的资源大小。
 
使用矢量图（VectorDrawable）
 
可以使用矢量图替代位图（.png、.jpg等），来减少图片的大小，但要注意，矢量图不适合复杂色彩的图片。矢量图有一个优势，它可以任意放大，而不会丢失细节或影响清晰度，因此可以只使用一套来适配所有屏幕大小。
 
在 Android 中，矢量图（VectorDrawable）是用 .xml 文件来创建的，VectorDrawable 通过 XML 文件描述图片的形状，大小，样式。
 
 
使用 VectorDrawable 还可以避免因为使用帧动画导致的图片资源过多的情况，如下图所示：
 
 
所以，使用矢量图可以有效减小安装包大小，但是有没有缺点呢？
 
上面已经提到了，矢量图不能用于复杂的色彩图片，最佳使用场景是色彩、形状简单的图片。
Android 中，矢量图是用 .xml 表示的，在生成最终图片过程中，要经过解析、计算等操作，这个过程中，主要使用的是 CPU 资源，而非 GPU。
最后矢量图文件中关于 Path 的描述需要尽量简化，复杂冗余的 Path 信息不仅对得到想要的图片没有益处，还增加了加载渲染的难度。
 
 
**PS：更多精彩内容，请查看 --> 《Android 性能优化》
 **PS：更多精彩内容，请查看 --> 《Android 性能优化》
 **PS：更多精彩内容，请查看 --> 《Android 性能优化》

 
今天在用udt测试3G网络的时候，发现udt m_iss （也就是分包大小） udt 默认是1500 ，结果在3G上就是不能正常通信，在局域网里通信相当的棒，
 
后来发现是跟路由器有关，3G网络中超过1400KB的数据包就被阻挡了，kao ,郁了好久…   
 
udt 采用udp的发送和接收 ……最后我改成1300成功， 以下引用别人的知识：
 
 
 
udp最大发包大小：
 
65507 字节 = 65535 - 20 - 8，是一个理论值。
 
 我建议您在设计程序的时候选择小于 PMTU 的 IP 分组大小，因为大于这个数值的分组可能被分片（否则无法发送），而分组交换的网络是不可靠的，存在着丢包。

 IP 协议的发送方不做重传。接收方只有在收到全部的分片后才能 reassemble 并送至上层协议处理代码，否则在应用程序看来这些分组已经被丢弃。

 假定同一时刻网络丢包的概率是均等的，那么较大的 IP datagram 必然有更大的概率被丢弃，因为只要丢失了一个 fragment，就导致整个 IP datagram 接收不到。不超过 PMTU 的分组是没有这个问题的。

 一般地，在局域网中，UDP 分组的大小限制在 1472 字节内是安全的；在距离较近（100km 以内）的广域网中，1400 字节较为安全；距离较远的时候（如中美之间），我建议控制在 1300 字节，甚至 1200 字节。需要根据实际网络情况做出进一步的调整。

有过App Store提审经验的童鞋应该知道，App Store对iOS提审包有一个包体大小的限制，这个限制不仅仅是对Mach-O可执行文件大小限制，还有整包大小的限制，比如“80M”、“150M”，这些包体大小的限制会直接影响到你APP能否成功上传或者玩家方便下载。App Store官方文档中规定，对于整包大小超过150M的App包，可以上传到App Store并发布，但是无法在移动网络下下载，必须在Wifi网络下才能下载；而对于Mach-O可执行文件大小的限制则依据iOS版本有不同的要求，具体如下图：
 
 
简单理解就是：
 
对于iOS7.0以下版本的App，32位+64位指令集的可执行文件之和最大为80M；
对于iOS7.x-iOS8.x版本的App，32位或64位指令集的可执行文件大小都不超过60M；
对于iOS9.0以上版本的App，32位+64位指令集的可执行文件之和最大为500M。
那么怎么查看Mach-O可执行文件的大小呢？上图也给出了答案，解压ipa包，找到app_name.app/app_name就是可执行文件，使用size命令查看一下该文件，即可看到__TEXT部分的大小。
 
之前对项目Unity升级使支持iOS64位的时候就遇到了一次可执行文件大小超过80M的上传失败，查了下原因，原来是因为Unity4.6.2及之后的版本使用了新的IL2CPP技术，使得最终编译的可执行文件大小激增。测试发现，Unity4.6.2以及之后的几个版本IL2CPP技术还是有挺大的差异，这也导致生成出来的执行文件大小差异比较大，不过不管怎么样项目的可执行文件还是超过80M，不得不对可执行文件的大小进行优化，参考了Unity3D的官方文档和App Store官方优化文档，做了一些整理总结。
 
先讲下怎么优化iOS包可执行文件的大小：
 
使用Release版本打包最终发布包，并确保Release模式下的Optimization Level为 Fastest, Smallest [-Os]；
Unity的Build Player Setting中，把 Stripping Level 改为 Use micro mscorlib； Stripping Level 有三个等级选项：Strip assemblies，Strip ByteCode 和 Use micro mscorlib。Strip assemblies 等级下，在AOT编译阶段通过分析字节码将未被引用的类或者方法从dll中移除；Strip ByteCode 等级下，所有的.net dll将被剥离为元数据，因为所有代码在AOT阶段已经预编译并链接到主二进制文件中；Use micro mscorlib 等级下，一些组件将从此库中删除，例如Security、Reflection.Emit、Remoting等，内部组件之间的相互依赖性也将最小化。此优化减少了主二进制文件和mscorlib.dll的大小，但它与某些system和system.xml程序集类不兼容，因此请小心使用它。以上三种等级优化是相互累计叠加的，即等级2包含等级1，等级3包含等级2。
Unity的Build Player Setting中，当 Scripting backend 选择 IL2CPP 时，勾选Strip Engine Code；勾选该选项，本地Unity引擎中没有使用的模块和类将被剔除，这有可能导致某些第三方库使用到而该模块或类被删除而有可能导致App闪退。此时Unity有提供了一个配置方案，可以避免被剔除，只需要在Assets目录下添加link.xml，在里面添加不想被剔除的dll的名字。
Unity的Build Player Setting中，把 Api Compatibility Level 选择 .net 2.0 subset；
Unity的Build Player Setting中，把 Script call optimization level 选择成 Fast but no exceptions；
删除没用或重复引用的第三方库，或者使用轻量级的第三方库代替原先引用库，比如使用轻量级的json库，如LitJSON；
删除没用代码，比如一些第三方库的Example代码，废弃的系统代码等，通过分析LinkMap文件可以得到Mach-O可执行文件中各个类或库的大小（设置Project->Build Settings->Write Link Map File为YES，并设置Path to Link Map File，build完后就可以在设置的路径看到LinkMap文件了），使用这个工具可以检测无用的OC类，使用这个工具可以得到各个类或库的大小，然后着重优化相应的模块；
移除非必须使用的.net基础库，使用其它更精简的库代替，如System.xml可以用XMLParser或SecurityParser替代（可减少3-5M），System.Linq也尽量不用，其一是容量问题，其二是效率问题，其三是在iphone4s下面可能导致crash的问题。
分离代码和资源，将资源（如长字符串，表格等）从代码中剥离并将它们放在外部文件中，因为外部文件的压缩效率比将数据编译为二进制文件时要高；
少用或不用模板，如List，Dictionary这种泛型容器，因为他们会使得il2cpp产生大量代码，提取静态字段，可以把静态字段数组管理，再通过id映射，这个在XLua官方文档中的Hotfix Flag的IntKey标签上看到类似做法的，具体原因应该也是和il2cpp生成代码有关，具体原因如果有知道的小伙伴麻烦评论告知；
提升iOS的版本，移除不支持的指令集，如不支持armv7则不选择。
根据Unity官方文档描述，一个空Unity项目，如果没有开启包大小优化大概是22M，开启上述优化之后大概是12M，还是有比较大的优化效果的。
 
一个游戏App中，不用说资源的大小肯定占大头，接下来说下优化iOS包的资源：
 
剔除没有使用的图片，对于重复使用的图片新建公共图集；
使用8bit的png图片代替32bit的png图片或者pvrtc图片；这一步可以省下很大的包大小，因为游戏中很多资源都是32bit的png格式，而一张图片压缩后可以省下1/4的空间。但是也不是所有的png都能压缩成8bit格式，8bit的png图片只有256种不同的颜色，对于照片细节要求很高的就不能使用。png图片压缩可以考虑pngquant这一开源工具，可以使用命令行实现一键打包压缩。
压缩音效资源，可以使用 MP3格式压缩，这格式目前在Android和iOS上都可以支持，不然还需要处理不同平台的音频转换；
优化mesh文件，使得单个模型片面数<3000，材质数<3，骨骼数<50。
根据App Store官方文档可知，Xcode 提供可App包大小报告，你只需要：
 
创建App包档案（Archive），选择 Product > Archive；
导出App包，在档案管理器（Archives organizer）界面选择导出档案，点击发布；
选择“Export for specific devices”，在下拉菜单中选择“All compatible device variants”；
选择“Rebuild from bitcode”。
这样你就能在导出文件夹中找到“ App Thinning Size Report.txt”这样一个文件，里面包含了每个设备类型的压缩和未压缩包（加上必须资源）的大小。 这个文档的包大小只是一个估计的包在App Store上大小，因为发布过程中ipa包会被进一步加密，这个加密过程会导致包还会稍微再大一些。
 
参考：
 
Unity引擎IOS执行档大小优化
 
ipa包大小之linkMap文件分析
 
关于ios的ipa包的分析之link map 文件的分析
 
基于LinkMap分析iOSAPP各模块体积

    一般来说，我们都知道TS包的大小是188个字节。如下图所示：
 
 
 
   但有的资料也同时标识TS包的长度是204个字节。其实204字节的TS包就是在188字节的TS包的后面增加了16个字节的RS冗余校验信息。在QAM解调芯片输出TS流到解码芯片时候，可以设置输出的格式为188或者204，一般来说默认是188个字节的。
 
 
 
 
 
 http://blog.sina.com.cn/s/blog_5f84dc840100lvkj.html