热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

iOS安装包瘦身(上篇)

本文来自网易云社区作者:饶梦云1.安装包组成谈到App瘦身,最直接的想法莫过于分析一个安装包内部结构,了解其每一部分的来源。解压一个ipa包,拿到其payload中app

本文来自网易云社区


作者:饶梦云

1. 安装包组成


谈到 App 瘦身,最直接的想法莫过于分析一个安装包内部结构,了解其每一部分的来源。解压一个 ipa 包,拿到其 payload 中 app 文件的数据,整理归类后其大致如下:

  • Exectutable: 可执行文件

  • Resources:资源文件

    • 图片资源:Assets.car/bundle/png/jpg 等

    • 视频/音频资源:mp4/mp3 等

    • 静态网页资源:html/css/js 等

    • 视图资源:xib/storyboard 等

    • 其他:文本/字体/证书 等

  • Framework:项目中使用的动态库

    • SwiftSupport: libSwiftxxx 等一系列 Swift 库

    • 其他依赖库:Embeded Framework

  • Pulgins:Application Extensions

    • appex:其组成大致与 ipa 包组成一致

从以上结构中可以看出一个 ipa 包大致由 Executable, Resources, Framework,Plugins 四大模块组成,接下来我们就从这四个方向来探讨 App 瘦身的具体方案。

2. 可执行文件瘦身

可执行文件就是我们源代码(.m/.h/.swift ...)的编译结果。在 iOS 或者 macOS 中称之为 Mach-O executable,它是程序的入口。

2.1. 编译器优化

Xcode 支持编译器层面的一些优化优化选项,可以让我们介于更快的编译速度和更小的二进制大小并且更快的执行速度之间自由选择想要进行的优化粒度。

2.1.1. Clang/LLVM 编译器优化选项

我们都知道 Xcode 是使用 Clang 来编译 Objective-C 语言的,Clang 的优化选项在其文档 clang - Code Generation Options 中可以查阅得到。我们的 IDE-Xcode 只提供给我们 6 个等级的编译选项,在 Xcode -> Build Setting -> Apple LLVM 9.0 - Code Generation -> Optimization Level 中进行设置,每个等级的说明,可以参考官方文档:

xcode-clang-optimization

  • None[-O0]: 编译器不会优化代码,意味着更快的编译速度和更多的调试信息,默认在 Debug 模式下开启。

  • Fast[-O,O1]: 编译器会优化代码性能并且最小限度影响编译时间,此选项在编译时会占用更多的内存。

  • Faster[-O2]:编译器会开启不依赖空间/时间折衷所有优化选项。在此,编译器不会展开循环或者函数内联。此选项会增加编译时间并且提高代码执行效率。

  • Fastest[-O3]:编译器会开启所有的优化选项来提升代码执行效率。此模式编译器会执行函数内联使得生成的可执行文件会变得更大。一般不推荐使用此模式。

  • Fastest Smallest[-Os]:编译器会开启除了会明显增加包大小以外的所有优化选项。默认在 Release 模式下开启。

  • Fastest, Aggressive Optimization[-Ofast]:启动 -O3 中的所有优化,可能会开启一些违反语言标准的一些优化选项。一般不推荐使用此模式。

Fastest Smallest[-Os] 极小限度会影响到包大小,而且也保证了代码的执行效率,是最佳的发布选项,一般 Xcode 会在 Release 下默认选择 Fastest Smallest[-Os] 选项,较老的项目可能没有自动勾选。

XCode 中设置的选项最终会反应在 Clang 命令上面,打开 build log 可以看到此选项最终的表现形式:

clang/llvm-optimization-level-command

如果你还需要 clang 的其他选项来编译你的项目,可以在 Other C Flag 中直接添加其参数。举例来说,在 Optimization Level 中设置 Fastest Smallest[-Os] 和在 Other C Flags 中添加 -Os 效果是一样的。

2.1.2. Swift Complier/LLVM 编译优化选项

Swift 语言的编译器是 swiftlang,同时也是基于 LLVM 后端的。Xcode 9.3 版本之后 Swift 编译器会提供新的选项来帮助减少 Swift 可执行文件的大小:

xcode-swift-llvm-optimization

  • No optimization[-Onone]:不进行优化,能保证较快的编译速度。

  • Optimize for Speed[-O]:编译器将会对代码的执行效率进行优化,一定程度上会增加包大小。

  • Optimize for Size[-Osize]:编译器会尽可能减少包的大小并且最小限度影响代码的执行效率。

Xcode 9.3 以前和优化选项混杂在一起的编译模式可以独立设置了:

xcode-swift-compilation

  • Single File:单个文件优化,可以减少增量编译的时间,并且可以充分利用多核 CPU,并行优化多个文件,提高编译速度。但是对于交叉引用无能为力。

  • Whole Module:模块优化,最大限度优化整个模块,能处理交叉引用。缺点不能利用多核 CPU 的优势,每次编译都会重新编译整个 Module。

在 Relese 模式下 -Osize 和 Whole Module 同时开启效果会发挥的最好,从现有的案例中可以看到它会减少 5%~30% 的可执行文件大小,并且对性能的影响也微乎其微(大约 5%)。参考官方文档 和 SwiftCafe。

此选项虽然是 Xcode 9.3 支持的,但是我们发现 Xcode 9.2 对应的 Swift Compiler 也是支持 Osize 的。所以 Xcode 9.2 版本中可以在 Build Settings -> Other Swift Flags 中添加 -Osize 提前获取编译器优化的好处。

xcode9.2-swiftc-Osize

虽然 Xcode 9.3/Swift4.1 已经发布,但是其编译器不是特别稳定,特别是开启 Osize 选项之后,编译器很多情况下会莫名其妙的崩溃(Segmentation fault),我们在 bugs.swift.org 上面也找到了很多同类的崩溃。所以假如你使开启 Osize 之后遇到了同类的崩溃,你可以选择放弃 Osize,或者想办法修改代码绕开编译器崩溃。

2.2. 去除符号信息

可执行文件中的符号)是指程序中的所有的变量、类、函数、枚举、变量和地址映射关系,以及一些在调试的时候使用到的用于定位代码在源码中的位置的调试符号,符号和断点定位以及堆栈符号化有很重要的关系。

2.2.1. Strip Style

Strip Style 表示的是我们需要去除的符号的类型的选项,其分为三个选择项:

  • All Symbols: 去除所有符号,一般是在主工程中开启。

  • Non-Global Symbols: 去除一些非全局的 Symbol(保留全局符号,Debug Symbols 同样会被去除),链接时会被重定向的那些符号不会被去除,此选项是静态库/动态库的建议选项。

  • Debug Symbols: 去除调试符号,去除之后将无法断点调试。

iOS 的调试符号是 DWARF 格式的,相关概念如下:

  • Mach-O: 可执行文件,源文件编译链接的结果。包含映射调试信息(对象文件)具体存储位置的 Debug Map。

  • DWARF:一种通用的调试文件格式,支持源码级别的调试,调试信息存在于 对象文件 中,一般都比较大。Xcode 调试模式下一般都是使用 DWARF 来进行符号化的。

  • dSYM:独立的符号表文件,主要用来做发布产品的崩溃符号化。dSYM 是一个压缩包,里面包含了 DWARF 文件。

dwarf_dsym_executable

使用 Xcode 编译打包的时候会先通过可执行文件的 Debug Map 获取到所有对象文件的位置,然后使用 dsymutil 来将对象文件中的 DWARF 提取出来生成 dSYM 文件。

2.2.2. Strip Linked Product

If enabled, the linked product of the build will be stripped of symbols when performing deployment postprocessing.

并不是所有的符号都是必须的,比如 Debug Map,所以 Xcode 提供给我们 Strip Linked Product 来去除不需要的符号信息(Strip Style 中选择的选项相应的符号),去除了符号信息之后我们就只能使用 dSYM 来进行符号化了,所以需要将 Debug Information Format 修改为 DWARF with dSYM file。

我之前一直疑惑没有 DWARF 调试信息之后 Xcode 是靠什么来生成 dSYM 的,答案其实还是 DWARF,因为 Xcode 编译实际的操作步骤是:生成带有 DWARF 调试信息的可执行文件 -> 提取可执行文件中的调试信息打包成 dSYM -> 去除符号化信息。去除符号是单独的步骤,使用的是 strip 命令。

另外一个问题是,去除符号化信息之后我们只能使用 dSYM 来进行符号化,那我们使用 Xcode 来进行调试的时候会不会太麻烦了?其实我们完全不用担心这个问题:Strip Linked Product 选项在 Deployment Postprocessing 设置为 YES 的时候才生效,而在 Archive 的时候 Xcode 总是会把 Deployment Postprocessing 设置为 YES 。所以我们可以打开 Strip Linked Product 并且把 Deployment Postprocessing 设置为 NO,而不用担心调试的时候会影响断点和符号化,同时打包的时候又会自动去除符号信息。这个选项也是默认打开的,较老的项目可以选择手动开启。

2.2.3. Strip Debug Symbols During Copy

Specifies whether binary files that are copied during the build, such as in a Copy Bundle Resources or Copy Files build phase, should be stripped of debugging symbols. It does not cause the linked product of a target to be stripped—use Strip Linked Product (STRIP_INSTALLED_PRODUCT) for that.

与 Strip Linked Product 类似,但是这个是将那些拷贝进项目包的三方库、资源或者 Extension 的  Debug Symbol 去除掉,同样也是使用的 strip 命令。这个选项没有前置条件,所以我们只需要在 Release 模式下开启,不然就不能对三方库进行断点调试和符号化了。

如果依赖的 Target 是独立签名的(比如 App Extension),strip 操作就会失效,并伴随着 Warning:warning: skipping copy phase strip, binary is code signed: xxxx。此情况将依赖的 Target 中的 Strip Linked Product 修改为 YES,保证依赖的 Target 是已经去除了符号即可,Waning 忽略掉就可以了。

Cocoapods 管理的动态库(use_framework!)的情况就相对要特殊一点,因为 Cocoapods 中的的动态库是使用自己实现的脚本 Pods-xxx-frameworks.sh 来实现拷贝的,所以并不会走 Xcode 的流程,当然也就不受 Strip Debug Symbols During Copy 的影响。当然 Cocoapods 是源码管理的,所以只需要将源码 Target 中的 Strip Linked Product 设置为 YES 即可。

2.2.4. Strip Swift Symbols

Adjust the level of symbol stripping specified by the STRIP_STYLE setting so that when the linked product of the build is stripped, all Swift symbols will be removed.

开启 Strip Swift Symbols 能帮助我们移除相应 Target 中的所有的 Swift 符号,这个选项也是默认打开的。

补充一点:Swift ABI 稳定之前,Swift 标准库是会打进目标文件的,想要同时移除 Swift 标准库里面的符号的话需要在发布选项中勾选 Strip Swift symbols,如下图所示:

distribution_strip_swift_symbols

2.3. BitCode

BitCode 是 iOS 9 引入的新特性,官方文档解释 BitCode 是一种程序中间码,其实就是 LLVM IR 的一种编码形式 - BitCodeFormart。

bitcode-architecture

上图表示了 IR 和 BitCode 在编译器架构中所在的位置,需要说明的是 BitCode 是以 section 形式保存在可执行文件中。当我们把携带 BitCode 的 App 提交到 AppStore 后,苹果会提取出可执行文件中的 BitCode 段,然后针对不同的 CPU 架构编译和链接成不同的可执行文件变体(Variant),不同 CPU 架构的设备会自动选择合适的架构的变体进行下载。而在 BitCode 之前没我们都是把所有需要的 CPU 架构集合打包成一个 Fat Binary,结果就是用户最终下载的安装包之中有很多冗余的 CPU 架构支持代码。

从以上编译器架构中我们也可以得出一个结论:开启 BitCode 之后编译器后端(Backend)的工作都由 Apple 接管了。所以假如以后苹果推出了新的 CPU 架构或者以后 LLVM 推出了一系列优化,我们也不再需要为其发布新的安装包了。

2.3.1. BitCode 一致性要求

一致性要求意味着工程开启 BitCode 之后必须要求所有打进 Bundle 的 Binary 都需要支持 BitCode,也就是说我们依赖的静态库和动态库都是含有 BitCode 的,不然就会打包失败。对于 Cocoapods 等源码管理工具来管理的依赖库来说操作会比较简单,我们只需要开启 Pods 工程中的 BitCode 就行。但是对于一些三方的闭源库,我们就无能为力了。

2.3.2. BitCode 的崩溃定位

开启 BitCode 之后需要特别注意崩溃定位的问题:由于最终的可执行文件是 Apple 自动生成的,同时产生新的符号表文件,所以我们使用原本打包生成的 dSYM 符号化文件是无法完成符号化的。所以我们需要在上传至 App Store 时需要勾选 Include app symbols for your application to receive symboilcated crash logs from Apple:

Include app symbols

勾选之后 Apple 会给我们生成 dSYM,然后就可以在 Xcode -> Organizer 或者 iTunes Connect 中下载对应的 dSYM 来进行符号化了。

2.3.3. BitCode 的编译选项优化

上面所说的编译器优化是在编译器前端完成的,所以提交的 BitCode 应该是经过优化的。但是 去除符号信息,是在编译生成可执行文件之后完成的, 苹果在生成可执行文件之后是否给我们去除了符号也不得而知。


本文来自网易云社区,经作者饶梦云授权发布

网易云免费体验馆,0成本体验20+款云产品!

更多网易研发、产品、运营经验分享请访问网易云社区。


相关文章:
【推荐】 不再任人欺负!手游安全的进阶之路


推荐阅读
  • 解决Only fullscreen opaque activities can request orientation错误的方法
    本文介绍了在使用PictureSelectorLight第三方框架时遇到的Only fullscreen opaque activities can request orientation错误,并提供了一种有效的解决方案。 ... [详细]
  • MySQL 5.7 学习指南:SQLyog 中的主键、列属性和数据类型
    本文介绍了 MySQL 5.7 中主键(Primary Key)和自增(Auto-Increment)的概念,以及如何在 SQLyog 中设置这些属性。同时,还探讨了数据类型的分类和选择,以及列属性的设置方法。 ... [详细]
  • 在《Cocos2d-x学习笔记:基础概念解析与内存管理机制深入探讨》中,详细介绍了Cocos2d-x的基础概念,并深入分析了其内存管理机制。特别是针对Boost库引入的智能指针管理方法进行了详细的讲解,例如在处理鱼的运动过程中,可以通过编写自定义函数来动态计算角度变化,利用CallFunc回调机制实现高效的游戏逻辑控制。此外,文章还探讨了如何通过智能指针优化资源管理和避免内存泄漏,为开发者提供了实用的编程技巧和最佳实践。 ... [详细]
  • javascript分页类支持页码格式
    前端时间因为项目需要,要对一个产品下所有的附属图片进行分页显示,没考虑ajax一张张请求,所以干脆一次性全部把图片out,然 ... [详细]
  • 解决Bootstrap DataTable Ajax请求重复问题
    在最近的一个项目中,我们使用了JQuery DataTable进行数据展示,虽然使用起来非常方便,但在测试过程中发现了一个问题:当查询条件改变时,有时查询结果的数据不正确。通过FireBug调试发现,点击搜索按钮时,会发送两次Ajax请求,一次是原条件的请求,一次是新条件的请求。 ... [详细]
  • 开发技巧:在Interface Builder中实现UIButton文本居中对齐的方法与步骤
    开发技巧:在Interface Builder中实现UIButton文本居中对齐的方法与步骤 ... [详细]
  • 您的数据库配置是否安全?DBSAT工具助您一臂之力!
    本文探讨了Oracle提供的免费工具DBSAT,该工具能够有效协助用户检测和优化数据库配置的安全性。通过全面的分析和报告,DBSAT帮助用户识别潜在的安全漏洞,并提供针对性的改进建议,确保数据库系统的稳定性和安全性。 ... [详细]
  • 优化Vite 1.0至2.0升级过程中遇到的某些代码块过大问题解决方案
    本文详细探讨了在将项目从 Vite 1.0 升级到 2.0 的过程中,如何解决某些代码块过大的问题。通过具体的编码示例,文章提供了全面的解决方案,帮助开发者有效优化打包性能。 ... [详细]
  • 浏览器作为我们日常不可或缺的软件工具,其背后的运作机制却鲜为人知。本文将深入探讨浏览器内核及其版本的演变历程,帮助读者更好地理解这一关键技术组件,揭示其内部运作的奥秘。 ... [详细]
  • 如何将TS文件转换为M3U8直播流:HLS与M3U8格式详解
    在视频传输领域,MP4虽然常见,但在直播场景中直接使用MP4格式存在诸多问题。例如,MP4文件的头部信息(如ftyp、moov)较大,导致初始加载时间较长,影响用户体验。相比之下,HLS(HTTP Live Streaming)协议及其M3U8格式更具优势。HLS通过将视频切分成多个小片段,并生成一个M3U8播放列表文件,实现低延迟和高稳定性。本文详细介绍了如何将TS文件转换为M3U8直播流,包括技术原理和具体操作步骤,帮助读者更好地理解和应用这一技术。 ... [详细]
  • 基于Net Core 3.0与Web API的前后端分离开发:Vue.js在前端的应用
    本文介绍了如何使用Net Core 3.0和Web API进行前后端分离开发,并重点探讨了Vue.js在前端的应用。后端采用MySQL数据库和EF Core框架进行数据操作,开发环境为Windows 10和Visual Studio 2019,MySQL服务器版本为8.0.16。文章详细描述了API项目的创建过程、启动步骤以及必要的插件安装,为开发者提供了一套完整的开发指南。 ... [详细]
  • 提升视觉效果:Unity3D中的HDR与Bloom技术(高动态范围成像与光线散射)
    提升视觉效果:Unity3D中的HDR与Bloom技术(高动态范围成像与光线散射) ... [详细]
  • 深入解析Linux内核中的进程上下文切换机制
    在现代操作系统中,进程作为核心概念之一,负责管理和分配系统资源,如CPU和内存。深入了解Linux内核中的进程上下文切换机制,需要首先明确进程与程序的区别。进程是一个动态的执行流,而程序则是静态的数据和指令集合。进程上下文切换涉及保存当前进程的状态信息,并加载下一个进程的状态,以实现多任务处理。这一过程不仅影响系统的性能,还关系到资源的有效利用。通过分析Linux内核中的具体实现,可以更好地理解其背后的原理和技术细节。 ... [详细]
  • iOS 设备唯一标识获取的高效解决方案与实践
    在iOS 7中,苹果公司再次禁止了对MAC地址的访问,使得开发者无法直接获取设备的物理地址。为了在开发过程中实现设备的唯一标识,苹果推荐使用Keychain服务来存储和管理唯一的标识符。此外,还可以结合其他技术手段,如UUID和广告标识符(IDFA),以确保设备的唯一性和安全性。这些方法不仅能够满足应用的需求,还能保护用户的隐私。 ... [详细]
  • 在CentOS 7上部署WebRTC网关Janus
    在CentOS 7上部署WebRTC网关Janus ... [详细]
author-avatar
给力的饼干_235
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有