mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-25 04:17:17 +00:00
docs: refine
This commit is contained in:
LiuBinPeng
@@ -1,7 +1,5 @@
|
||||
# App 瘦身之道
|
||||
|
||||
|
||||
|
||||
App 的包大小做优化的目的就是为了节省用户流量，提高用户的下载速度，也是为了用户手机节省更多的空间。另外 App Store 官方规定 App 安装包如果超过 150MB，那么不可以使 OTA（over-the-air）环境下载，也就是只可以在 WiFi 环境下载，企业或者独立开发者万万不想看到这一点。免得失去大量的用户。
|
||||
|
||||
同时如果你的 App 需要适配 iOS7、iOS8 那么官方规定主二进制 text 段的大小不能超过 60MB。如果不能满足这个标准，则无法上架 App Store。
|
||||
@@ -12,16 +10,26 @@ App 的包大小做优化的目的就是为了节省用户流量，提高用户
|
||||
|
||||
|
||||
|
||||
App 瘦身一般指的是安装包（IPA），主要由可执行文件、资源组成。
|
||||
|
||||
对于产物的分析，可以查看可执行文件的具体组成。
|
||||
|
||||
Xcode - Build Setting - Write Link Map File 设置为 YES。修改 Path to Link Map File 即可。
|
||||
|
||||
可借助第三方工具解析LinkMap文件： [GitHub - huanxsd/LinkMap: 检查每个类占用空间大小工具](https://github.com/huanxsd/LinkMap)
|
||||
|
||||
|
||||
|
||||
## 1. App Thinning
|
||||
|
||||
App Thinning 是指 iOS9 以后引入的一项优化，官方描述如下
|
||||
|
||||
> The App Store and operating system optimize the installation of iOS, tvOS, and watchOS apps by tailoring app delivery to the capabilities of the user’s particular device, with minimal footprint. This optimization, called app thinning, lets you create apps that use the most device features, occupy minimum disk space, and accommodate future updates that can be applied by Apple. Faster downloads and more space for other apps and content provides a better user experience.
|
||||
|
||||
Apple 会尽可能，自动降低分发到具体用户时，所需要下载的 App 大小。其中包含三项主要功能：Slicing、Bitcode、On-Demand Resources。
|
||||
|
||||
App Thinning 是苹果公司推出的一项改善 App 下载进程的新技术，主要为了解决用户下载 App 耗费过高流量的问题，同时还可以节省用户设备存储空间。
|
||||
|
||||
|
||||
### 1.1 Slicing
|
||||
|
||||
|
||||
@@ -36,7 +44,6 @@ App Thinning 是苹果公司推出的一项改善 App 下载进程的新技术
|
||||
|
||||
|
||||
|
||||
|
||||
### 1.2 Bitcode
|
||||
|
||||
> Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the App Store.
|
||||
@@ -47,8 +54,8 @@ Bitcode 是一种程序`中间码`。包含 Bitcode 配置的程序将会在 App
|
||||
|
||||
开启位置：Build Settings -> Enable Bitcode -> 设置为 YES
|
||||
|
||||
|
||||
开启 Bitcode，有这么2点需要注意：
|
||||
|
||||
- 全部都要支持。我们所依赖的静态库、动态库、Cocoapods 管理的第三方库，都需要开启 Bitcode。否则会编译失败
|
||||
|
||||
- 奔溃定位。开启 Bitcode 后最终生成的可执行文件是 Apple 自动生成的，同时会产生新的符号表文件，所以我们无法使用自己包生成的 dYSM 符号化文件来进行符号化。
|
||||
@@ -59,12 +66,10 @@ Bitcode 是一种程序`中间码`。包含 Bitcode 配置的程序将会在 App
|
||||
|
||||
在上传到 App Store 时需勾选“Includ app symbols for your application...”。勾选之后 Apple 会自动生成对应的 dYSM，然后可以在 Xcode -> Window -> Organizer 中，或者在 Apple Store Connect 中下载对应的 dYSM 来进行符号化
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
那么 Bitcode 会对 App Thining 有什么作用？
|
||||
|
||||
在 New Features in Xcode7 中有这么一段描述：
|
||||
@@ -74,8 +79,7 @@ Bitcode 是一种程序`中间码`。包含 Bitcode 配置的程序将会在 App
|
||||
即，App Store 会再按需将这个 bitcode 编译进 32/64 位的可执行文件。
|
||||
所以网上铺天盖地地说 Bitcode 完成了具体架构的拆分，从而实现瘦包
|
||||
|
||||
|
||||
### 1.3 on-Demand Resources
|
||||
### 1.3 on-Demand Resources
|
||||
|
||||
on-Demand Resource 即一部分图片可以被放置在苹果的服务器上，不随着 App 的下载而下载，直到用户真正进入到某个页面时才下载这些资源文件。
|
||||
|
||||
@@ -85,8 +89,6 @@ on-Demand Resource 即一部分图片可以被放置在苹果的服务器上，
|
||||
|
||||
如需支持 iOS9 以下系统，那么无法使用这个功能，否则上传会失败
|
||||
|
||||
|
||||
|
||||
## 2 包体积
|
||||
|
||||
2个概念
|
||||
@@ -106,21 +108,17 @@ Universal 指通用设备，即未应用 App slicing 优化，同时包含了所
|
||||
|
||||
观察 .ipa 的大小和 Universal 对应的包大小相当，稍微小一点，因为 App Store 对 .ipa 做了加密处理
|
||||
|
||||
|
||||
有时候下载 App 会提示“此项目大于 150MB，除非此项目支持增量下载，否则您必须连接至 WiFi 才能下载”。150MB 针对的是下载大小。
|
||||
|
||||
|
||||
- 下载大小：通过 WiFi 下载的压缩 App 大小
|
||||
- 安装大小：此 App 将在用户设备上占用磁盘空间的大小
|
||||
|
||||
所以我们要瘦包，关键在于减小 .app 文件的大小。
|
||||
|
||||
|
||||
### 2.1 Architectures
|
||||
|
||||
如果不支持32位以及 iOS8 ，去掉 armv7 ，可执行文件以及库会减小，即本地 .ipa 也会减小
|
||||
|
||||
|
||||
### 2.2 Resources
|
||||
|
||||
资源的优化也就是平时的细心与审查。
|
||||
@@ -138,23 +136,20 @@ Bundle: 非放在 Asset Catlog 中管理的图片资源。包括 Bundle，散落
|
||||
- 图片管理方式规范
|
||||
- on-Demand Resource（游戏的、前置关卡依赖、滤镜App 等的依赖资源，建议用这种方式动态下载图片资源）
|
||||
|
||||
|
||||
#### 2.2.1 无用文件的删除
|
||||
|
||||
|
||||
无用文件主要包含：无用图片、无用非图片部分。
|
||||
|
||||
非图片部分：资源较少，使用方式固定。比如音频、字体。需要手动排查
|
||||
图片部分：主要使用一个开源的 Mac App [LSUnusedResources](https://github.com/tinymind/LSUnusedResources) 进行冗余图片的排查。
|
||||
|
||||
|
||||
删除无用的图片过程，可以概括为下面6步：
|
||||
|
||||
1. 通过 find 命令获取 App 安装包中的所有资源文件
|
||||
2. 设置用到的资源类型。比如 gif、jpg、jpeg、png、webp
|
||||
3. 使用正则匹配出在源码中使用到的资源名，比如 pattern = @"@"(.+?)""
|
||||
4. 使用 find 命令找到篇所有资源文件，再去源码中找到使用到的资源文件，2个集合的差集就是无用资源了。
|
||||
5. 确认无用资源后可以使用 NSFileManager 进行文件的删除。
|
||||
|
||||
|
||||
如果不想重新写一个工具，那么可以直接使用开源的工具 LSUnusedResources
|
||||
|
||||
@@ -168,14 +163,15 @@ Bundle: 非放在 Asset Catlog 中管理的图片资源。包括 Bundle，散落
|
||||
//...
|
||||
}
|
||||
```
|
||||
源码中的正则表达式处理的情况并不是很准确。可以根据自己的情况修改正则即可
|
||||
|
||||
源码中的正则表达式处理的情况并不是很准确。可以根据自己的情况修改正则即可
|
||||
|
||||
#### 2.2.2 图片资源的压缩
|
||||
|
||||
删除了无用的资源，那么对于资源这块还是有操作的空间的，比如图片资源的压缩。目前压缩比较好的方案就是 WebP，它是谷歌公司的一个开源项目。
|
||||
|
||||
WebP 的优势：
|
||||
|
||||
- 压缩率高。支持有损和无损2种方式，比如将 Gif 图可以转换为 Animated WebP，有损模式下可以减小 64%，无损模式下可以减小 19%
|
||||
- WebP 支持 Alpha 透明和 24-bit 颜色数，不会像 PNG8 那样因为色彩不够出现毛边。
|
||||
|
||||
@@ -184,7 +180,6 @@ Google 公司在开源 WebP 的同时，还提供了一个图片压缩工具 [cw
|
||||
|
||||
缺点：WebP 在 CUP 消耗和解码时间上会比 PNG 高2倍，所以我们做选择的时候需要取舍。
|
||||
|
||||
|
||||
#### 2.2.3 重复文件删除
|
||||
|
||||
重复文件，即两个内容完全一致的文件。但是文件命名不一样。
|
||||
@@ -198,7 +193,6 @@ fdupes 是 Linux 下的一个工具，它由 Adrian Lopez 用 C 语言编写并
|
||||
|
||||
执行结束后会在命令行展示出来，所以需要我们人工将这些文件确认对比后删除掉。
|
||||
|
||||
|
||||
#### 2.2.4 大文件压缩
|
||||
|
||||
图片本身的压缩，建议使用 ImageOptim。它整合了 Win、Linux 上诸多著名图片处理工具的特色，比如 PNGOUT、AdvPNG、Pngcrush、OptiPNG、JpegOptim、Gifsicle 等。
|
||||
@@ -209,10 +203,8 @@ Xcode 提供给我们2个编译选项来帮助压缩图像：
|
||||
- Compress PNG Files: 打包的时候自动对图片进行无损压缩。使用的工具为 pngcrush，压缩比蛮高。
|
||||
- Remove Text Medadata From PNG Files：移除 PNG 资源的文本字符，比如图像名称、作者、版权、创作时间、注释等信息
|
||||
|
||||
|
||||
#### 2.2.5 图片管理方式规范
|
||||
|
||||
|
||||
##### 2.2.5.1 主工程中的图片管理
|
||||
|
||||
工程中所有使用的 Asset Catlog 管理的图片（在 .xcassets 文件夹下）最终都会输出到 Asset.car 内。不在 Asset.car 内的都归为 Bundle 管理。
|
||||
@@ -249,6 +241,7 @@ for (NSInteger index = 0; index < 10; index++) {
|
||||
}
|
||||
self.imageView.image = images.lastObject;
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Timeprofile-imageNamedFromAssets
|
||||
@@ -260,52 +253,57 @@ TimeProfile-imageWithContentsOfFile
|
||||
Timeprofile-UIImageNamedFromFolder
|
||||
|
||||
|
||||
|
||||
Images.xcassets ：
|
||||
|
||||
- 图片大小要精确，不要出现图片太大的情况
|
||||
- 不要存放大图，不然会产生缓存
|
||||
- 不要存 jpg 图片，打包会变大
|
||||
- 图片不需要额外压缩（有人做过实验，对放入 assets 里面的图片进行压缩后打包发现包体积反而增大，怀疑是 Xcode 的编译选项 Compress PNG Files 自动对图片进行压缩，2种压缩起了冲突反而增大）
|
||||
|
||||
|
||||
##### 2.2.5.2 各个 pod 库中的图片管理
|
||||
|
||||
CocoPods 中两种资源引用方式介绍下：
|
||||
|
||||
- resource_bundles
|
||||
> We strongly recommend library developers to adopt resource bundles as there can be name collisions using the resources attribute.
|
||||
允许定义当前的 pod 库的最远包的名称和文件。用 hash 形式声明，key 是 bundle 的名称，value 是需要包含文件的通配 patterns
|
||||
CocoPods 官方强烈推荐该方法引用资源，因为 key-value 可以避免相同资源的名称冲突
|
||||
|
||||
> We strongly recommend library developers to adopt resource bundles as there can be name collisions using the resources attribute.
|
||||
> 允许定义当前的 pod 库的最远包的名称和文件。用 hash 形式声明，key 是 bundle 的名称，value 是需要包含文件的通配 patterns
|
||||
> CocoPods 官方强烈推荐该方法引用资源，因为 key-value 可以避免相同资源的名称冲突
|
||||
- resources
|
||||
> We strongly recommend library developers to adopt resource bundles as there can be name collisions using the resources attribute. Moreover, resources specified with this attribute are copied directly to the client target and therefore they are not optimised by Xcode.
|
||||
使用该方法引用资源，被指定的资源会被拷贝进 target 工程的 main bundle 中。
|
||||
|
||||
|
||||
|
||||
> We strongly recommend library developers to adopt resource bundles as there can be name collisions using the resources attribute. Moreover, resources specified with this attribute are copied directly to the client target and therefore they are not optimised by Xcode.
|
||||
> 使用该方法引用资源，被指定的资源会被拷贝进 target 工程的 main bundle 中。
|
||||
|
||||
说说项目中的情况吧：在工程中之前是通过 resource_bundles 引用资源的。资源是放在 Resources 目录下的图片引用。查询资料后说「如果图片资源放到 .xcasset 里面 Xcode 会帮我们自动优化、可以使用 Slicing 等（这里不仅仅指的是 resource_bundle 下的 xcassets」。所以动手将各个 Pod 库里面的图片全都通过 Assets Catalog 的方式进行处理。
|
||||
|
||||
|
||||
|
||||
步骤：
|
||||
|
||||
- 在各个 Pod 组件库里面的 Resources 目录下新建 Asset Catalog 文件，命名为 Images.xcassets
|
||||
|
||||
- 将 Resources 里面零散的图片资源拖进 Images.xcassets 里面
|
||||
|
||||
- 修改每个组件库的 podspec 文件
|
||||
<details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>点击展开</summary>
|
||||
|
||||
```
|
||||
s.resource_bundles = {
|
||||
'XQ_UI' => ['XQ_UI/Assets/*.xcassets']
|
||||
}
|
||||
</details>
|
||||
```
|
||||
|
||||
<summary>点击展开</summary>
|
||||
|
||||
```
|
||||
s.resource_bundles = {
|
||||
'XQ_UI' => ['XQ_UI/Assets/*.xcassets']
|
||||
}
|
||||
</details>
|
||||
```
|
||||
- 主工程执行 pod install
|
||||
|
||||
话说 `resources` 和 `resource_bundles` 都可以使用 Asset Catalog，那么有何区别？
|
||||
|
||||
- resources 只会将资源文件 copy 到 target 工程，最后和 target 工程的图片资源以及同样使用该方式的 Pod 库的图片资源共同打包到一个 `Assets.car` 中。因此图片资源会有混乱的可能。
|
||||
- resource_bundles 会生成一个你在 `podspec` 中指定名称的 bundle，且在 bundle 中也会生成一个 Assets.car。所以图片是肯定不会混乱的，但是图片的访问方式需要注意。
|
||||
|
||||
|
||||
解决方法：为每个 pod 新建一个图片的分类，比如 UIImage+XQUIModule。然后访问图片的时候通过 `[UIImage xquiModuleImageNamed:@"pull"]` 访问。
|
||||
|
||||
<details>
|
||||
@@ -334,18 +332,15 @@ CocoPods 中两种资源引用方式介绍下：
|
||||
}
|
||||
@end
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
||||
#### 2.2.6 矢量图的使用
|
||||
|
||||
事实上，对于 App 里面的单色图标，比如左上角的返回按钮、底部的 tabBar等，只要是单色的纯色图标都是可以使用矢量图代替的，比如 PDF、ttf 字体图标等。这样就不需要添加 @2x、@3x 图标，节省了空间。
|
||||
|
||||
iOS 中如何使用 ttf 矢量图，可以查看这个 [Repo](https://github.com/FantasticLBP/IconFont_Demo)
|
||||
|
||||
|
||||
|
||||
## 3. Executable file
|
||||
|
||||
### 3.1 编译选项优化
|
||||
@@ -365,7 +360,6 @@ optimization 选项设置为 space 可以减少包大小
|
||||
|
||||
> For statically linked executables, dead-code stripping is the process of removing unreferenced code from the executable file. If the code is unreferenced, it must not be used and therefore is not needed in the executable file. Removing dead code reduces the size of your executable and can help reduce paging.
|
||||
|
||||
|
||||
删除静态链接的可执行文件中未引用的代码
|
||||
|
||||
Debug 设置为 NO， Release 设置为 YES 可减少可执行文件大小。
|
||||
@@ -394,7 +388,6 @@ Build Settings -> code Generation -> Optimization Level
|
||||
|
||||
默认选项，不做修改。
|
||||
|
||||
|
||||
#### 3.1.5 Swift Compiler - Code Generation
|
||||
|
||||
Xcode 9.3 版本之后 Swift 编译器提供了新的 Optimization Level 选项来帮助减少 Swift 可执行文件的大小：
|
||||
@@ -409,7 +402,6 @@ Xcode 9.3 版本之后 Swift 编译器提供了新的 Optimization Level 选项
|
||||
|
||||
除了 -O 和 -Osize， 还有另外一个概念也值得说一下。 就是 Single File 和 Whole Module 。 在之前的 XCode 版本，这两个选项和 -O 是连在一起设置的，Xcode 9.3 中，将他们分离出来，可以独立设置：
|
||||
|
||||
|
||||
Single File 和 Whole Module 这两个模式分别对应编译器以什么方式处理优化操作。
|
||||
|
||||
- Single File：逐个文件进行优化，它的好处是对于增量编译的项目来说，它可以减少编译时间，对没有更改的源文件，不用每次都重新编译。并且可以充分利用多核 CPU，并行优化多个文件，提高编译速度。但它的缺点就是对于一些需要跨文件的优化操作，它没办法处理。如果某个文件被多次引用，那么对这些引用方文件进行优化的时候，会反复的重新处理这个被引用的文件，如果你项目中类似的交叉引用比较多，就会影响性能。
|
||||
@@ -420,7 +412,6 @@ Single File 和 Whole Module 这两个模式分别对应编译器以什么方式
|
||||
|
||||
故，在 Relese 模式下 -Osize 和 Whole Module 同时开启效果会最好！
|
||||
|
||||
|
||||
#### 3.1.6 Strip Symbol Information
|
||||
|
||||
1、Deployment Postprocessing
|
||||
@@ -434,7 +425,6 @@ Symbols Hidden by Default 会把所有符号都定义成”private extern”，
|
||||
|
||||
故，Release 设置为 YES，Debug 设置为 NO。
|
||||
|
||||
|
||||
#### 3.1.7 Exceptions
|
||||
|
||||
在 iOS微信安装包瘦身 一文中，有提到：
|
||||
@@ -447,7 +437,6 @@ Symbols Hidden by Default 会把所有符号都定义成”private extern”，
|
||||
|
||||
可能和项目中用到比较少有关系。故保持开启状态。
|
||||
|
||||
|
||||
#### 3.1.8 Link-Time Optimization
|
||||
|
||||
Link-Time Optimization 是 LLVM 编译器的一个特性，用于在 link 中间代码时，对全局代码进行优化。这个优化是自动完成的，因此不需要修改现有的代码；这个优化也是高效的，因为可以在全局视角下优化代码。
|
||||
@@ -464,10 +453,8 @@ Link-Time Optimization 是 LLVM 编译器的一个特性，用于在 link 中间
|
||||
|
||||
在新的版本中，苹果使用了新的优化方式 Incremental，大大减少了链接的时间。建议开启。
|
||||
|
||||
|
||||
总结，开启这个优化后，一方面减少了汇编代码的体积，一方面提高了代码的运行效率。
|
||||
|
||||
|
||||
### 3.2 代码瘦身
|
||||
|
||||
代码的优化，即通过删除无用类、无用方法、重复方法等，来达到可执行文件大小的减小。
|
||||
@@ -478,35 +465,32 @@ Link-Time Optimization 是 LLVM 编译器的一个特性，用于在 link 中间
|
||||
- 基于 Clang 扫描
|
||||
- 基于可执行文件扫描
|
||||
- 基于源码扫描
|
||||
|
||||
|
||||
先谈几个概念。
|
||||
|
||||
可执行文件就是 **Mach-O** 文件，其大小是油代码量决定的，通常情况下，对可执行文件进行瘦身，就是找到并删除无用代码的过程。找到无用代码的过程类比找到无用图片的思路。
|
||||
|
||||
- 找到类和方法的全集
|
||||
- 找到使用过的类和方法集合
|
||||
- 取2者差集得到无用代码集合
|
||||
- 工程师确认后，删除即可
|
||||
|
||||
|
||||
LinkMap 文件分为3部分：Object File、Section、Symbols。
|
||||
|
||||
|
||||
- Object File：包含了代码工程的所有文件
|
||||
- Section：描述了代码段在生成的 Mach-O 里的偏移位置和大小
|
||||
- Symbols：会列出每个方法、类、Block，以及它们的大小
|
||||
|
||||
先说说如何快速找到方法和类的全集？
|
||||
|
||||
|
||||
我们可以通过 **LinkMap** 来获得所有的代码类和方法的信息。获取 LinkMap 可以通过将 Build Setting 里面的 **Write Link Map File** 设置为 YES，然后指定 **Path to Link Map File** 的路径就可以得到每次编译后的 LinkMap 文件了。
|
||||
|
||||
|
||||
|
||||
#### 3.2.1 基于 clang 扫描
|
||||
|
||||
基本思路是基于 clang AST。追溯到函数的调用层级，记录所有定义的方法/类和所有调用的方法/类，再取差集。具体原理参考 如何使用 Clang Plugin 找到项目中的无用代码，目前只有思路没有现成的工具。
|
||||
|
||||
|
||||
#### 3.2.2 基于可执行文件扫描（LinkMap 结合 Mach-O 找无用代码）
|
||||
|
||||
上面我们得知可以通过 LinkMap 统计出所有的类和方法，还可以清晰地看到代码所占包大小的具体分布，进而有针对性地进行代码优化。
|
||||
@@ -517,7 +501,6 @@ LinkMap 文件分为3部分：Object File、Section、Symbols。
|
||||
|
||||
|
||||
|
||||
|
||||
得到了代码的全集信息后，我们还需要找到已经使用过的方法和类，这样才可以获取差集，找到无用代码。所以接下来就谈谈如何通过 Mach-O 取到使用过的类和方法。
|
||||
|
||||
Objective-C 中的方法都会通过 **objc_msgSend** 来调用，而 objc_msgSend 在 Mach-O 文件里是通过 **_objc_selrefs** 这个 **section** 来获取 selector 这个参数的。
|
||||
@@ -526,7 +509,6 @@ Objective-C 中的方法都会通过 **objc_msgSend** 来调用，而 objc_msgSe
|
||||
|
||||
那么，Mach-O 文件中的 _objc_selrefs、_objc_classrefs、_objc_superrefs 如何查看呢？
|
||||
|
||||
|
||||
1. 使用 otool 等命令逆向可执行文件中引用到的类/方法和所有定义的类/方法，然后计算差集。具体参考iOS微信安装包瘦身，目前只有思路没有现成的工具。
|
||||
2. 使用 [MachOView](https://github.com/gdbinit/MachOView) 查看。但是这个项目运行不起来，这个新的 [Repo](https://github.com/fangshufeng/MachOView) 可以运行起来。
|
||||
|
||||
@@ -538,14 +520,12 @@ Objective-C 中的方法都会通过 **objc_msgSend** 来调用，而 objc_msgSe
|
||||
|
||||
由于 Objective-C 是一门动态语言，所以检测出的结果仍旧需要我们2次确认。
|
||||
|
||||
|
||||
#### 3.2.3 基于源码扫描
|
||||
|
||||
一般都是对源码文件进行字符串匹配。例如将 A *a、[A xxx]、NSStringFromClass("A")、objc_getClass("A") 等归类为使用的类，@interface A : B 归类为定义的类，然后计算差集。
|
||||
|
||||
基于源码扫描 有个已经实现的工具 - fui，但是它的实现原理是查找所有 #import "A" 和所有的文件进行比对，所以结果相对于上面的思路来说可能更不准确。
|
||||
|
||||
|
||||
#### 3.2.4 通过 AppCode 查找无用代码
|
||||
|
||||
AppCode 提供了 Inspect Code 来诊断代码，其中含有查找无用代码的功能。它可以帮助我们查找出 AppCode 中无用的类、无用的方法甚至是无用的 import ，但是无法扫描通过字符串拼接方式来创建的类和调用的方法，所以说还是上面所说的 基于源码扫描 更加准确和安全。
|
||||
@@ -559,7 +539,6 @@ AppCode 提供了 Inspect Code 来诊断代码，其中含有查找无用代码
|
||||
- 无用宏：Unused macro 是无用的宏。
|
||||
- 无用全局：Unused global declaration 是无用全局声明。
|
||||
|
||||
|
||||
#### 3.2.5 运行时真正检测类是否用过
|
||||
|
||||
通过上述手段找到并删除了无用代码。App 不断上线迭代蛮多代码都不会被调用了（业务被砍掉了）。这种方式下这些无用的代码也是可以被删除的。
|
||||
@@ -603,8 +582,6 @@ isInitialized 的结果会保存到元类的 class_rw_t 结构体的 flags 信
|
||||
|
||||
既然可以在运行的期间知道类是否初始化了，那么就可以找出哪些类未初始化，即可以找到在真实环境里面没有用到的类并删除掉。
|
||||
|
||||
|
||||
|
||||
## 4. App Extension
|
||||
|
||||
App Extension 的占用，都放在 Plugin 文件夹内。它是独立打包签名，然后再拷贝进 Target App Bundle 的。
|
||||
@@ -616,12 +593,11 @@ App Extension 的占用，都放在 Plugin 文件夹内。它是独立打包签
|
||||
|
||||
所以，如果可能的话，把相关的依赖改成动态库方式，达到共享。
|
||||
|
||||
|
||||
|
||||
## 5. 静态库瘦身
|
||||
|
||||
项目中都会引入第三方静态库。通过 lipo 工具可以查看支持的指令集，比如查看微博 SDK
|
||||
终端切换到微博 SDK 的目录下执行下面命令
|
||||
|
||||
- 静态库指令集信息查看：`lipo -info libname.a(或者libname.framework/libname)`
|
||||
|
||||
```Shell
|
||||
@@ -634,7 +610,6 @@ lipo -info libWeiboSDK.a
|
||||
- 静态库拆分：`lipo 静态库文件路径 -thin CPU架构 -output 拆分后的静态库文件路径`
|
||||
- 静态库合并：`lipo -create 静态库1文件路径 静态库2文件路径... 静态库n文件路径 -output 合并后的静态库文件径`
|
||||
|
||||
|
||||
```Shell
|
||||
lipo libWeiboSDK.a -thin armv7 -output libWeiboSDK-armv7.a
|
||||
lipo libWeiboSDK.a -thin arm64 -output libWeiboSDK-arm64.a
|
||||
@@ -646,35 +621,33 @@ lipo create libWeiboSDK-armv7.a libWeiboSDK-arm64.a -output libWeiboSDK.device.a
|
||||
1. 平时使用包含模拟器指令集的静态库，在 App 发布的时候去掉
|
||||
2. 如果使用 Cocoapods 管理可以使用2份 Podfile 文件。一份包含指令集一份不包含，发布的时候切换 Podfile 文件即可。或者一份 Podfile 文件，但是配置不同的环境设置
|
||||
|
||||
|
||||
补充2个说明：
|
||||
|
||||
1. dSYM 文件
|
||||
符号表文件 .dSYM 文件是从 Mach-O 文件中抽取调试信息而得到的文件目录，实际用于保存调试信息的是 DWARF 文件
|
||||
|
||||
- 自动生成。Xcode 会在工程编译或者归档的时候自动生成 .dSYM 文件，在 Buld setting 设置中有开关可以设置去关掉 .dSYM 文件
|
||||
- 手动生成。通过脚本从 Mach-O 文件中提取出来。
|
||||
```
|
||||
$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil /Users/wangzz/Library/Developer/Xcode/DerivedData/YourApp-cqvijavqbptjyhbwewgpdmzbmwzk/Build/Products/Debug-iphonesimulator/YourApp.app/YourApp -o YourApp.dSYM
|
||||
```
|
||||
该方式通过 dsymutil 工具，从项目编译结果 .app 目录下的 Mach-O 文件中提取出调试符号表文件。Xcode 在归档的时候是通过它生辰的 .dSYM 文件
|
||||
|
||||
- 手动生成。通过脚本从 Mach-O 文件中提取出来。
|
||||
|
||||
```
|
||||
$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil /Users/wangzz/Library/Developer/Xcode/DerivedData/YourApp-cqvijavqbptjyhbwewgpdmzbmwzk/Build/Products/Debug-iphonesimulator/YourApp.app/YourApp -o YourApp.dSYM
|
||||
```
|
||||
|
||||
该方式通过 dsymutil 工具，从项目编译结果 .app 目录下的 Mach-O 文件中提取出调试符号表文件。Xcode 在归档的时候是通过它生辰的 .dSYM 文件
|
||||
2. DWARF 文件
|
||||
DebuggingWith Arbitrary Record Formats 是 ELF 和 Mach-O 等文件格式中用来存储和处理调试信息的标准格式，.dSYM 文件中真正保存符号表数据的是 DWARF 文件。DWARF 文件中不同的数据都保存在相应的 section 中。
|
||||
|
||||
|
||||
最后的一个对比效果图：
|
||||
|
||||
|
||||
|
||||
总结：瘦身技术常见操作就这些，但是维持应用包体积的瘦身却是一个观念，从日常开发到线上发布都需要有这个意识。这样当你在写代码的时候就会考虑同样一个效果，你的具体实现手段是怎么样的。比如为了一个稍微炫酷的效果就要引入一个很大的三方库，有了“瘦身”的意识，你很大可能就是自己动手撸一个代码。比如一些无用资源的管理方式、有用的图片资源的高效管理方式等等。有了意识，行动自然会往这个方面去靠。（😂大道理一套一套的。我也不想的，毕竟是playboy）
|
||||
|
||||
其中遇到了一个神奇的问题。lint 的时候看到一些未使用的依赖库。见 [问题](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.53.md)
|
||||
|
||||
|
||||
**By the way：**
|
||||
如果在应用包瘦身方面有其他的做法，请告知，完善文章。
|
||||
|
||||
参考文章：
|
||||
|
||||
- [Humble Assets Catalog](http://lingyuncxb.com/2019/04/14/HumbleAssetCatalog/)
|
||||
- [关于 Pod 库的资源引用 resource_bundles or resources](http://zhoulingyu.com/2018/02/02/pod-resource-reference/)
|
||||
Reference in New Issue
Block a user