mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-25 04:17:17 +00:00
docs: image url
This commit is contained in:
FantasticLBP
@@ -32,7 +32,7 @@ App Thinning 是苹果公司推出的一项改善 App 下载进程的新技术
|
||||
|
||||
### 1.1 Slicing
|
||||
|
||||
|
||||
|
||||
|
||||
当向 App Store Connect 上传 .ipa 后，App Store Connect 构建过程中，会自动分割该 App，创建特定的变体（variant）以适配不同设备。然后用户从 App Store 中下载到的安装包，即这个特定的变体，这一过程叫做 Slicing。
|
||||
|
||||
@@ -42,7 +42,7 @@ App Thinning 是苹果公司推出的一项改善 App 下载进程的新技术
|
||||
|
||||
其中，2x 和 3x 的细分，要求图片在 **Assets** 中管理。Bundle 内的则会同时包含。
|
||||
|
||||
|
||||
|
||||
|
||||
### 1.2 Bitcode
|
||||
|
||||
@@ -66,9 +66,9 @@ Bitcode 是一种程序`中间码`。包含 Bitcode 配置的程序将会在 App
|
||||
|
||||
在上传到 App Store 时需勾选“Includ app symbols for your application...”。勾选之后 Apple 会自动生成对应的 dYSM，然后可以在 Xcode -> Window -> Organizer 中，或者在 Apple Store Connect 中下载对应的 dYSM 来进行符号化
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
那么 Bitcode 会对 App Thining 有什么作用？
|
||||
|
||||
@@ -83,7 +83,7 @@ Bitcode 是一种程序`中间码`。包含 Bitcode 配置的程序将会在 App
|
||||
|
||||
on-Demand Resource 即一部分图片可以被放置在苹果的服务器上，不随着 App 的下载而下载，直到用户真正进入到某个页面时才下载这些资源文件。
|
||||
|
||||
|
||||
|
||||
|
||||
应用场景：相机应用的贴纸或者滤镜、关卡游戏等
|
||||
|
||||
@@ -101,7 +101,7 @@ on-Demand Resource 即一部分图片可以被放置在苹果的服务器上，
|
||||
|
||||
包体积，评判标准是以 App Store 上看到的为准。但是上传到 App Store Connect 处理完后，会自动帮我们生成具体设备上看到的大小。如下：
|
||||
|
||||
|
||||
|
||||
|
||||
这其中：又可以分为2类： Universal 和具体设备
|
||||
Universal 指通用设备，即未应用 App slicing 优化，同时包含了所有架构、资源。所以包体积会比较大
|
||||
@@ -245,13 +245,13 @@ self.imageView.image = images.lastObject;
|
||||
</details>
|
||||
|
||||
Timeprofile-imageNamedFromAssets
|
||||
|
||||
|
||||
|
||||
TimeProfile-imageWithContentsOfFile
|
||||
|
||||
|
||||
|
||||
Timeprofile-UIImageNamedFromFolder
|
||||
|
||||
|
||||
|
||||
Images.xcassets ：
|
||||
|
||||
@@ -276,7 +276,7 @@ CocoPods 中两种资源引用方式介绍下：
|
||||
|
||||
说说项目中的情况吧：在工程中之前是通过 resource_bundles 引用资源的。资源是放在 Resources 目录下的图片引用。查询资料后说「如果图片资源放到 .xcasset 里面 Xcode 会帮我们自动优化、可以使用 Slicing 等（这里不仅仅指的是 resource_bundle 下的 xcassets」。所以动手将各个 Pod 库里面的图片全都通过 Assets Catalog 的方式进行处理。
|
||||
|
||||
|
||||
|
||||
|
||||
步骤：
|
||||
|
||||
@@ -520,7 +520,7 @@ Link-Time Optimization 是 LLVM 编译器的一个特性，用于在 link 中间
|
||||
|
||||
LinkMap 文件分为3部分：Object File、Section、Symbols。
|
||||
|
||||
<img src="./../assets/2019-05-06-LinkMap-Structure.png" style="zoom:50%"/>
|
||||
<img src="https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/assets/2019-05-06-LinkMap-Structure.png" style="zoom:50%"/>
|
||||
|
||||
- Object File：包含了代码工程的所有文件
|
||||
- Section：描述了代码段在生成的 Mach-O 里的偏移位置和大小
|
||||
@@ -529,7 +529,7 @@ LinkMap 文件分为3部分：Object File、Section、Symbols。
|
||||
先说说如何快速找到方法和类的全集？
|
||||
|
||||
我们可以通过 **LinkMap** 来获得所有的代码类和方法的信息。获取 LinkMap 可以通过将 Build Setting 里面的 **Write Link Map File** 设置为 YES，然后指定 **Path to Link Map File** 的路径就可以得到每次编译后的 LinkMap 文件了。
|
||||
|
||||
|
||||
|
||||
产出的 LinkMap 阅读起来比较累，github 有个[可视化项目](https://github.com/jayden320/LinkMap) 用来查看 LinkMap 文件。
|
||||
|
||||
@@ -541,11 +541,11 @@ LinkMap 文件分为3部分：Object File、Section、Symbols。
|
||||
|
||||
上面我们得知可以通过 LinkMap 统计出所有的类和方法，还可以清晰地看到代码所占包大小的具体分布，进而有针对性地进行代码优化。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
得到了代码的全集信息后，我们还需要找到已经使用过的方法和类，这样才可以获取差集，找到无用代码。所以接下来就谈谈如何通过 Mach-O 取到使用过的类和方法。
|
||||
|
||||
@@ -562,7 +562,7 @@ Objective-C 中的方法都会通过 **objc_msgSend** 来调用，而 objc_msgSe
|
||||
|
||||
前置条件：先运行项目，在生成的 Products 目录下的 BridgeLabiPhone.app 解压，取出对应的和工程同名的 BridgeLabiPhone。然后运行上面的 Github 项目。可以看到运行了一个 Mac App。点击顶部的菜单栏里面的 File->Open。选择电脑上的 BridgeLabiPhone.app 选择里面的 BridgeLabiPhone。见下图
|
||||
|
||||
|
||||
|
||||
|
||||
由于 Objective-C 是一门动态语言，所以检测出的结果仍旧需要我们2次确认。
|
||||
|
||||
@@ -576,7 +576,7 @@ Objective-C 中的方法都会通过 **objc_msgSend** 来调用，而 objc_msgSe
|
||||
|
||||
AppCode 提供了 Inspect Code 来诊断代码，其中含有查找无用代码的功能。它可以帮助我们查找出 AppCode 中无用的类、无用的方法甚至是无用的 import ，但是无法扫描通过字符串拼接方式来创建的类和调用的方法，所以说还是上面所说的 基于源码扫描 更加准确和安全。
|
||||
|
||||
|
||||
|
||||
|
||||
说明：AppCode检测出了实际上需要的大部分场景的问题，但是由于 Objective-C 是一门动态性语言，所以 AppCode 检测出无用的方法等都需要工程师自己再次确认后删除。（在我们的工程中有一些和 H5 交互的桥接方法，因此 AppCode 视为 Unused Method，但是你删除的话，那就自己哭去吧 😭）。实际经验告诉我，使用 AppCode 的时候如果工程比较大，则整个 code inspect 会非常耗时（给你打个预防针哦，笔芯）
|
||||
|
||||
@@ -684,7 +684,7 @@ lipo create libWeiboSDK-armv7.a libWeiboSDK-arm64.a -output libWeiboSDK.device.a
|
||||
DebuggingWith Arbitrary Record Formats 是 ELF 和 Mach-O 等文件格式中用来存储和处理调试信息的标准格式，.dSYM 文件中真正保存符号表数据的是 DWARF 文件。DWARF 文件中不同的数据都保存在相应的 section 中。
|
||||
|
||||
最后的一个对比效果图：
|
||||
|
||||
|
||||
|
||||
总结：瘦身技术常见操作就这些，但是维持应用包体积的瘦身却是一个观念，从日常开发到线上发布都需要有这个意识。这样当你在写代码的时候就会考虑同样一个效果，你的具体实现手段是怎么样的。比如为了一个稍微炫酷的效果就要引入一个很大的三方库，有了“瘦身”的意识，你很大可能就是自己动手撸一个代码。比如一些无用资源的管理方式、有用的图片资源的高效管理方式等等。有了意识，行动自然会往这个方面去靠。（😂大道理一套一套的。我也不想的，毕竟是playboy）
|
||||
|
||||
|
||||
Reference in New Issue
Block a user