手淘 App 如何落地 Swift ？一边探索实践，一边“打怪升级”

嘉宾|姜沂（倾寒）

出品| InfoQ &阿里巴巴新零售淘系技术部

嘉宾简介：姜沂（花名：倾寒），阿里巴巴淘系技术部 iOS 端架构高级无线开发工程师，曾在链家网、美团点评从事 iOS 相关开发，目前就职于淘宝-淘系技术部。 在链家网架构组主要工作有：组件化工程、构建合理开发链路、基础库开发和客户端稳定性相关工作。在美团点评架构组所做工作主要有响应式架构设计落地、性能优化和基础库开发。目前在淘宝客户端架构组，具体负责的工作有基础库开发、性能优化、淘宝灰度能力、开发 工具 升级，以及 Swift 语言落地。

前言

自从 2014 年苹果发布 Swift 至今，历经多次迭代，Swift 终于迎来了 ABI 稳定，SwiftUI 的发布也引起无数 Apple 平台开发者的欢呼。

多年来广受关注而又备受争议的 Swift，终于开始被很多大型 App 坚定地采用。

在这其中，淘宝 App 就是一个典型：从 Swift 2.0 时代的浅尝辄止，到去年 3 月 ABI 稳定后充分调研并正式采用，这其间经历了什么样的考量过程？淘宝 App 落地 Swift 的最关键环节有哪些？如何解决落地 Swift 过程中的挑战？

近日阿里巴巴淘系技术部 iOS 端架构高级无线开发工程师姜沂 受 InfoQ 采访邀约 ，他对以上问题进行详细解答。

并且 在即将到来的 GMTC2020 全球大前端技术大会上，他也将带来《手淘航母级 App 恋上 Swift 之路》的主题分享。

为何要坚定地走 Swift 之路？ 

对于淘宝 App 来说，对 Swift 一点都不陌生。姜沂介绍：淘宝 App 早在 Swift 2.0 时代就曾经引入过 Swift，但受限于 Swift 2.0 时代语法的不稳定，以及较大的包大小压力，彼时引入 Swift 其实是一种负担。

直到 2018 年底也就是 Swift 4.x 时代，苹果宣布 Swift 5.0 ABI 会稳定，这时候 Swift 的优点才能被发挥出来，而不足则会逐步减弱。

“我们在 2019 年 6 月苹果 WWDC 发布 SwiftUI、Combine 等对于 Apple 平台颠覆式的产品后，才对 Swift 又燃起了信心，正式着手采用 Swift。”

不过据了解，那时候的淘宝全部是 Objective-C 代码和一些跨平台框架如 Weex ，其实没有任何的 Swift 环境经验，甚至有一些工程问题导致 Swift 代码无法直接引入淘宝工程。

对于采用 Swift 可能会遇到的困难，姜沂他们是有所准备的，毕竟在去年 3 月 ABI 稳定后，团队成员分工对 Swift 进行了一次充分的调研：Swift 性能与开发效率、Swift 流行度、工程改造，方方面面都考虑到了。

“一开始我们主要经历了比较久的预研阶段，在 2018 年 Swift 宣布将要 ABI 稳定的时候，我们就在持续关注 Swift 的进展，在此期间集团内部已经有零星 App 在使用 Swift。”

到了后来的充分调研阶段，Swift 在性能与开发效率上的调研结果其实已经不言而喻，这也是业界达成的共识： 一个熟悉 Swift 和 Objective-C 的工程师，开发效率主观评价至少有 30% 以上的提升。

在比较重要的 Swift 流行度分析中，经淘宝 App 团队的调研：国际区采用 Swift 的 App 占据 80% 份额，而中国区只有 20%。另外有一个现象值得关注：GitHub 和一些开发者社区对于 Objective-C 的关注度剧烈下降：

1. 知名 Objective-C 开源库如 AFNetworking 已经将近 2 年没有重大更新，距离最后一次 Bug Fix 也已经有 1 年时间，对比之下 Swift 社区则很活跃；

2. StackOverFlow 等社区对 Objective-C 的提问已经近乎停滞，淘宝 App 团队成员近两年找寻疑难问题的解答几乎没人关注；

3. WWCC17 后，苹果所有 Sample Code 皆用 Swift 展示。

姜沂告诉记者：“我们的初步结论就是：按照苹果历来的强硬态度，如果我们 还是坚守 Objective-C 阵营，如果未来苹果强制推进 Swift，或者只更新 Pure Swift Framework，或者社区出现大技术更新、比如 HTTP3 网络库，会对我们目前的社区研发环境造成比较大的冲击。我们很可能被动的付出较大成本来适应变化，比如需要自己造 Objective-C HTTP3 的网络库轮子。”

“简单来说就是：我们可能在未来一两年内因为 Objective-C 而造成技术踏空，这一后果会对我们的人员招聘、技术前瞻性、研发成本都会带来较大风险与负担。”

调研结果加之 Swift 随后的进展，更让淘宝 App 坚定了走 Swift 之路的决心：

1. 在调研一个月后 WWDC19 更新了 SwiftUI、Combine 等 Pure Swift 框架，初步的验证了之前的结论；

2. 苹果放开了 200M 蜂窝网络下 IPA 包大小的限制， 同时 iOS12.2 以下系统需要内置包大小的设备占比已经不足 10% 且会随着时间的推移，存量越来越少；

3. SwiftUI 的出现对 Native 研发生产力的指数级提升。

落地 Swift 过程中要如何持续“打怪升级”？ 

淘宝 App 落地 Swift 分为了 5 个阶段，分别是技术调研、基础设施建设、工具链升级、里程碑业务上线和社区培训。

姜沂介绍：其中最大的挑战应该是在基础建设阶段。“这一阶段主要工作是重写一个小模块，用于发现工程中的历史问题。其中我们发现的一个比较大的问题是，由于淘宝是一个迭代了将近 10 年的工程，苹果在管理二进制库的时候也经历了 .a +.h 结构和 Framework 结构的调整，在逐步的迭代过程中，大量的头文件管理不太规范，导致 Swift 代码无法在项目中使用已有的 SDK，这部分理论上简单，但是工作量巨大。”

在姜沂看来，此时公司对 Swift 的投入仍处于一个较初期阶段，并不适合投入大量人力，因为 ROI 上并不划算。所以他们的解决办法是：建立 Swift 爱好者社区，聚集几十名爱好者，梳理技术文档、方案思路、自动化脚本等，逐步去掉这些历史包袱。

“此时 Swift 5.1 仍旧是 Beta 阶段，这给了我们充分的时间去做适配。最终用了三个月，几十名爱好者每人只花费极少的时间就将这些历史包袱解决掉了，这里也要感谢下来自阿里巴巴集团的各位 Swift 爱好者的努力。”

在落地 Swift 过程中，淘宝 App 尝试实现了一套 Swift 版本 FaaS 的 Serverless 容器，给现在的迭代工作方式创造一些可能性。不过据姜沂介绍，目前只是用在了一些内部软件中，还在积极探索阶段。另外对于 SwiftUI ，淘宝 App 也 落地在了内部的 App 中，总结 SwiftUI 的优缺点，以及未来落地的可能性。

对于淘宝落地 Swift，姜沂称之为 “巨型项目” ，Swift 的落地也让姜沂他们梳理出了一个巨型项目的流程方法论。据他介绍，实际上阿里集团内部也已经有多个 App 参考淘宝 App 的落地路线在落地自己的 Swift 模块。这个过程真的需要一路持续“打怪升级”。

一两年内中国 Swift 生态是否会有大改善？ 

在落地 Swift 的几个月内，姜沂深刻感受到从不停地被各种同事咨询敢不敢用 Swift，到他们自己主动要写 Swift 代码的一个转变。“淘宝拥有近十年的迭代历史，以及近千的 SDK 和数百不同 BU 的开发者，对于 Swift 初期探索性落地来说，模块选型是一个难题，建议大家最好选择一个能充分说明 Swift 可用性（大流量）的业务，并且这个业务还不能被外部过于依赖。原因是底层的 SDK 过于复杂、对外部有很多依赖的话，推进风险和上线风险都会比较大。 大流量的代表性业务能让观望的开发者提升信心，但是要做好充分的降级能力，不能损伤到业务。”

在落地 Swift 的过程中，其实还有一个挑战，就是国内 Swift 应用不普及带给使用者的观望情绪。对于这个问题，姜沂认为要从两个方面来看。

首先是业务视角：

1. 在业务需要快速迭代的时候，现有的 iOS 工程师主要以 Objective-C 为主，转战 Swift 需要一定的学习曲线，而且采用 Swift 效率是否一定有提高也有待考证；

2. Swift 只能解决 iOS 侧 Native 研发问题，对于高迭代效率的跨平台技术，收益不足。

其次是技术视角：

1. Swift 早期由于 ABI 不稳定，只能将 Runtime 内置在 IPA 包里面，占用约 3M 的下载空间，苹果还有 150 M 的蜂窝网络下载大小的限制，且对启动性能有 150ms 的影响，在各家公司拼体验的时代，这些都会对公司的业务造成负担和损耗；

2. 由于语法不固定，每次升级都会造成源码级别的 Break Change，对开发者也会造成负担。淘宝、美团等巨型 App 都采用了二进制组建化研发模块，Swift 只能固定开发工具版本，对大型团队是一种负担和制约，反而极大的降低了研发效率。

不过姜沂认为未来一两年内国内 Swift 生态还是会有巨大改善的，主要有以下几个方面：

1. iOS 12.2 以上内置 Swift Runtime， 包大小随着存量旧版本操作系统升级后得到缓解；

2. iOS 12.2 以上也没有启动性能的影响；

3. Swift 语法不再大变，不会对开发者造成负担；

4. 苹果继续强势推进，Swift 社区热度持续提升。

对此他举了一个很生动的例子：相信生产力大幅提高后，没有人会放任好用的工具不用而去用一把快要锈掉的锤子（Objective-C ）。

我们选择的技术最终要为业务和商业服务

在采访最后，姜沂也向记者介绍了他近期比较关注的大前端领域技术——SwiftUI 和 Flutter 。

对于 Flutter，在姜沂看来：在近年来的移动开发领域，开发者和业务诉求一直在研发成本、灵活性、性能体验间来回偏移，本质上是因为不同业务在不同阶段有不同的诉求，有时候需要较快速的试错能力和研发效率，有时候又需要较高的性能。随着 Hybrid  RN/Weex 的出现，大家基本上有一种固化的判断：如果我要动态性和灵活性的话，我选择 RN/Weex；如果我要体验的话，我选择 Native。

但这并不是说 Native 开发者就不想拥有高动态性，也不是说他们就没有跨平台减少研发成本的诉求，所以 Flutter 的出现让大家有了一种崭新的思路：原来 Native 也可以做到跨端的同时有非常高的性能。

对于 Swift，姜沂着重提及了 SwiftUI。“iOS 开发多年来在布局技术上一直远远落后于前端和安卓，但是 SwiftUI 的出现让 Apple 平台开发者又充满了希望。不过我在落地一些内部 APP 的时候也发现了一些 SwiftUI 的不足，如框架成熟度不够，某天写的代码突然操作系统升级后就发现极大的布局不兼容问题；而且 SwiftUI 必须内置在操作系统中，又不能解决跨 Android 端的开发问题，这让我对 SwiftUI 充满了期待与担忧。”

不过姜沂个人的看法是，无论是 Weex、小程序，还是 Flutter、SwiftUI，他们解决的问题是不一样的，本质更不同。到底哪个更优其实没有标准答案，不同的业务场景和业务所处的时间点，造成选择会不一样。“我们是工程师，并不是 Swift 或者 Flutter 工程师，我们选择的技术最终要为我们的业务和商业服务。”

“拥有一把锤子可以敲一个钉子，拥有一个工具箱可以造一艘航母”。

One More Thing