导读
6 月 23 日凌晨 1 点，苹果 WWDC20 开发者大会在线上以主题演讲的形式，在 Apple Park 进行直播。
23-26 日，苹果公开了 100 多个面向开发者的视频，内容涵盖 Swift / SwiftUI、App Clips、Widgets、Privacy & Security 等等方面。
对于开发者和程序员来说，咱们有哪些新发现和新思考？
淘系技术客户端团队，将给大家带来一系列对于新零碎背地的启发，欢送交换探讨。
本篇内容来自于阿里巴巴淘系技术部，淘宝客户端 iOS 架构组，高级开发工程师倾寒。
前言
SwiftUI 是苹果公司于 2019 年推出的 Apple Platform 的新一代申明式布局引擎，笔者于去年第一工夫降级 Beta 尝鲜全家庭，并在短时间内迅速落地了基于 SwiftUI 的外部 APP，也分享了几篇对于 SwiftUI 的文章，但 SwiftUI 1.0 根本没有任何公司敢用在正式上线的主 APP 上，API 在 Beta 版本之间各种废除，UI 款式常常不兼容，大列表性能差，彼时都标识着 SwiftUI 还称为一个 Toy Framewrok.
随着 WWDC 20 相干新个性和介绍视频的释出，都明确的宣告着 SwiftUI 元年曾经到了，SwiftUI 曾经成长为新时代的布局引擎。
以下从几个方面分享对于 SwiftUI 的重大扭转及外围劣势。
PS: 须要读者对 Swift 及 SwiftUI 1.0 有肯定相熟。
SwiftUI Apps
苹果在最近几年的动作中始终在搞 Apple Platform 对立的事件，从最近几年的 iPad 多任务 多窗口，到 Mac Catalyst 再到往年更进一步间接推出了 Apple silicon 芯片更是从硬件上做到了真正对立（话外音：你们在软件上玩的那些跨平台的都是小玩意，硬件才是王道）。
还提供了 Rosetta2 Universal2 帮忙开发者根本无老本的迁徙到新平台上。然而作为软件工程师还是要更多的关注软件生态的变动。首先理解下创立 APP 时的变动
能够看到创立新工程时有了一套全新的模板基于 SwiftUI App Lifecycle 的跨平台我的项目。
代码也从本来的基于 UI/NS HostViewController 变成了基于 APP 的申明式形容，上面是代码的前后比照
- Before
- After
其中@main 是 Swift 5.1 新增的 Attribute 标记了应用程序的入口点，更多请参看 SE-0281-main-attribute.md
乍看如同只有代码精简了不少，很多人会认为这个简洁水平还不如 Flutter 的 main() => runApp(MyApp());.
但最重要的变动是这是第一次跨平台代码，齐全无需引入任何 UIKit APPKit WatckKit 等相干 Framewok, 即可间接运行在不同平台上。这意味着咱们后续在 UI 布局零碎上能够逐步解脱对传统命令式 UI 编程的依赖。达到真正的平台无关。
SwiftUI 将整个原有的平台差别局部形象为 App 和 Scene，对于一个 mac/iOS/iPad/watch/tv/.. 利用，来说 App 代表了整个利用，Scene 代表了与 Window 相干的多窗口，有些设施只有一个 Scene 有些则有多个，尽管不同的 OS 的确存在差别，然而在语义层面达到了统一。
其次一个没有历史包袱的 APP，也能够残缺的从 Swift APP lifecycle 格调式的模板开始，无需再和传统的 UIKit/APPKit 等混合。这也意味着能够达到 APP 齐全 Declared and State-Driven。
Viusal Editing
Preview
在传统的利用 DSL 可视编程框架或者平台，诸如 Web Flutter 等技术，都是开发者编写好对应的代码，运行在对应的平台或者调试工具上。SwiftUI 作为苹果最重要的软件层策略框架，更是和 Xcode 深度联合，在运行之前就能够残缺的预览你所编写的界面。
弱小的 Preview 能够让你既能够从编写 DSL 到立刻预览成果，也可从预览的 Canvas 画布中间接批改成果在代码编辑器中生成代码，这对于日常开发的效率有十分大的进步，尤其是在 UI 微调时，成果尤为突出。
Xcode12 能够在 Canvas 上同时预览多个不同设施环境的界面, 也能够间接投射到实在的设施上来预览。
对于日常开发来说，编写一个 UI 界面通常依赖内部的网络 / 磁盘 / 其余数据，能力失常的构建，这也造成了 UI 开发尽管是开发中较为简单的一步，但同时也是最耗时的一步，有了预览性能，能够把很多繁琐的工作前置解决掉，对于研发效率会有十分大的进步。
Xcode Library
在编写实在我的项目中，一个公司的 APP UI 蕴含成千盈百种格调的 View 组件，对于 UI 组件丰盛的产品，如果一个新需要能够由现有的组件组合，那么需要交付的工夫也会大大缩短。
然而对于一个大型的开发团队而言，一个开发同学是很难晓得公司内到底有多少种组件库，而且即使晓得有某种组件库，开发同学初期看到的也是代码，个别须要书写肯定的 Demo 才能够用眼睛感知到这个组件到底是否是我想要的。
在 Xcode 12 中提供了更弱小的工具，一个自定义组件，只须要恪守一个 LiberyContentProvider 协定就可被 Xcode 辨认，能够像零碎控件一样间接从 Xcode 外面辨认并预览。对于一个大型团队来说，此性能能够大大提高找寻组件和查看组件款式的效率。
DSL
随着 Swift5.3 和 SwiftUI2.0 的推出，SwiftUI 在 DSL 上也更富裕表现力，Swift 反对了多重尾闭包语法和在 ViewBuilde 外面反对 Switch Case 语句。
Multiple Trailing Closures
尽管社区对多重尾闭包的探讨上始终存在争议问题，但最终 Swift5.3 还是承受并实现了，在一般命令式编程的中央应用会有肯定的困惑性，然而在 SwiftUI 中
DSL 也更有申明式的滋味。
Switch Case Support
在 SwiftUI 的 ViewBuilder DSL 体系中也反对了 Switch case 语法。
Data Flow
在应用传统命令式编程编写 UI 代码时，开发者须要手动解决 UIView 和 数据之间的依赖关系，每当一个 UIView 应用了内部的数据源，就表明了 UIView 对外部的数据产生了依赖，当一个数据产生变动时，如果意外的没有同步 UIView 的状态，那么 Bug 就产生了。
解决简略的依赖关系是可控的，然而在实在我的项目中，视图之间的依赖关系是非常复杂的，假如一个视图只有 4 种状态，组合起来就有 16 种，再加上时序的不同，状况就更加简单。
人脑解决状态的复杂度是无限的，状态的复杂度一旦超过人脑的复杂度，就会产生大量的 Bug，并且修掉了这个产生了新的 Bug。
那么 SwiftUI 是如何解决这个问题的？
SwiftUI 的框架提供了几个外围概念：
- 对立的 body 属性，SwiftUI 主动从以后 App 状态集主动生成基于以后状态的快照 View。
- 对立的数据流动原语。
对于 SwiftUI 中的 Data Flow 是如何打消视图和状态不统一的，请参考去年撰写的文档 系列文章深度解读 SwiftUI 背地那些事儿，
往年 SwiftUI 2.0 新增的 StateObject 数据流原语让 SwiftUI 在反复创立 View 时防止反复创立 ObservedObject 从而进步 View 重建的性能。
SceneStorage 和 APPStorgae 让一些可长久化的数据变得更加简略且具备语义化。
New Controls
后面提到的，新增的 DSL 语法 SwiftUI App Lifecycle，以及 Xcode Library Preview 其实实质上都是对去年 SwiftUI 1.0 精益求精的新扩大
真正重要的是往年新增的各类新控件，其中通过导出来自 Xcode11.5 和 Xcode12.0 beta 版本的 Swift 申明文件，能够察看到整个申明文件从原来的 10769 行减少到 20564 行。
新增了约 87 个 struct 16 个 protocol。有了这些丰盛的组件才能够更好的构建咱们的 APP。
大列表组件
在任何一款 APP 中都会存在相似大列表组件，如淘宝 APP 外面的某家店铺外面商品列表流，首页的信息流，都是具备超长内容的列表页数据。对于长列表页来说，过长的 UI 页面会导致过多的内存占用，在用户的设施中，内存是最为重要的指标，对于目前国内的 APP 市场，低端手机依然占据大量的市场，对于这些设施来说，一旦内存超标，APP 就很容易 OOM，这会导致用户体验十分差，在现有竞争关系强烈的市场环境下，体验差意味着会失去用户。
对于传统的命令式编程来说，咱们能够被动管制 UITableViewCell 的重用，自建缓冲池等一系列伎俩去优化咱们的 APP 内存占用，然而对于 SwiftUI 1.0 来说，零碎提供的控件并没有无效的方法去让咱们管制页面的渲染，对于大列表页面就容易呈现内存占用过高的问题。
SwiftUI 2.0 推出了 LazyHStack 和 lazyVStack 加上 List 渲染模式默认就是 Lazy 的间接解决了最大的性能问题，
笔者以去年应用 SwiftUI 编写的 Emas App 为例，当列表页（并无大图）加载到 500 个时，APP 应用内存曾经达到了将近 360MB。而只须要切换到 Xcode12 API 调整为到 LazyVStack 内存占用间接升高 300MB。
Widget and Clips
苹果与 WWDC 20 推出的 WidgetKit 反对的 API 是 SwiftUI Only，尽管曾经能够混合局部 UIkit 外面的 View，但置信没有历史包袱 最低反对版本为 iOS14 的 Widget 没有人会抉择轻便的命令式 API。
同理 Clips 也一样。这里因为篇幅起因就不做开展，后续会有专门的文章剖析相干技术。
Swift & SwiftUI 的机会在哪里？
笔者已经在公司推动团体降级了基建，反对了 Swift 开发环境也在淘宝落地了一些场景，然而团体内始终有一些质疑的声音，引入 Swift 到底有什么用？
SwiftUI 又是 N 年后才能够用上的小玩意，Objective-C 不够用吗？当初笔者能够答复这些质疑的声音，Swift 将来的机会在 效率 和 体验。
效率
从研发效率上来说，Swift 比照 Objective-C 的精简水平显而易见，笔者在淘宝 APP 上线的模块代码量降落了 40 %
但更进一步，如果编写 UI 界面从 UIKit 转向了 SwiftUI 代码量间接少了不止一倍。更少的代码意味着更快的交付，在目前竞争强烈的市场会有更多的试错场景。
对于应用 UIKit 编写代码转向 SwiftUI 的代码量比照，读者能够参考开源 APP MovieSwiftUI 直观理解
体验
读者可能比拟困惑对于切换语言和框架，对体验看上去没有任何帮忙，但事实真是这样吗？
首先引入 Swift 后，因为 Swift 语言设计之初便对安全性列为最重要的指标，Swift 的引入会让代码尽可能的缩小未定义的行为，缩小 Crash 意味着 APP 的稳定性进步，体验天然更佳。
其次尽管 Swift 同样的语言出于对安全性思考编译解决的指令会比 Objective-C 更多，然而如果 UI 局部都用 SwiftUI 来写呢？
更少的代码象征者更小的包大小，目前国内巨头 APP iOS 端 APP 包大小都朝着 200 MB 奔去，如果能缩小更多的代码对包大小也能够在 200MB 的限度下承载更多而业务。对用户的体验也有较大的晋升。
更进一步因为 Swift 抉择应用值类型构建整个 APP，值类型的有点在于更扁平化的内联数据结构去分配内存，而不是应用更多间接指针援用，缩小了大量不必要的堆内存耗费，意味着整体内存使用量的升高
对整个 APP 的稳定性也有较大的进步。
苹果的抉择
Swift 做为苹果的策略语言曾经倒退的越来越壮大，自 2019 年 Swift ABI 稳固后，苹果在 Swift 的投入越来越大。咱们能够进入 /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/swift , /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks , https://github.com/apple 和 https://github.com/swift-server 看到，自 iOS 13 以来 苹果新增了约 10+ Pure Swift Library , 10+ Open Source Swift Library, 以及针对 144 个公开 Framework，依据 Swift Style 从新设计了 57 个 Framework 的 API。
从以下数据
- 从 WWDC17 后 苹果曾经不再应用 Objective-C 做 Sample Code 演示
-
https://developer.apple.com/不再更新 Objective-C 相干的文档 - WidgetKit 是 SwiftUI only。
- App Clips 10M 的包大小，SwiftUI 是最合适的框架
- 开源社区逐渐放弃 Objecive-C 如 Lottie。
能够判断，Swift 是将来 Apple 平台的惟一抉择，越是有包袱的大厂 APP，从当初还不尽早储备，在将来越会举步维艰。
咱们须要做些什么？
Swift
咱们曾经做了什么
- 一套反对 Swift 二进制的研发环境
- 300+ 反对了混编的淘系 SDK。
- 手淘落地了 6 个模块。
- 团体新增了约 20 个 反对 Swift 的 APP。
- 10 多场技术培训。
- 169+ 语雀常识积淀。
- 300+ 工程师的团体 Swift 官网组织。
- 2 个 技术创新产品
通过去年横向组织大家独特的致力，咱们曾经曾经反对了横向大基建。包含研发环境，工具撑持，积淀了大量的文档，还有相干的技术课程。
要朝什么方向去致力
目前团体对于 Swift 的呼声越来越高，咱们大量的工程师心愿的去应用 Swift。目前首先要做的事件是依靠 Swift 和 SPM 晋升咱们的开发体验，降级咱们的中间件，使业务能够大量的用起来 Swift，进步咱们的研发效率和代码品质。
- 降级基于 SPM 的新的包管理体系
- 降级老旧根底库，打磨新一代基建。
- 引入新的 Swift 特有库 赋能业务。
SwiftUI
尽管前文提到了 SwiftUI 的泛滥长处，包含研发效率，体验的进步，然而在国内的环境中 SwiftUI 也有它致命的弊病
- iOS 14 才可释怀的应用。
- 只反对 Apple Platform，这和国内的要反对 Mobile Platform 从理念上抵触。
大型 APP 要解决的是如何部署到低版本操作系统上和安卓平台上，毕竟很多公司还在反对 iOS 9 对于降级到最低反对 iOS 14 如同还须要一个世纪那么漫长，而且国内的设施占比大头还是以 Android 巨多。
尽管能够看到 Swift 语言也在逐步反对 Android 平台，然而也看到苹果对于安卓平台的 SwiftUI 并没有太大趣味。
从体验上 Flutter 远不如 SwiftUI 这种亲儿子成果好，但对于国内跨端欲望旺盛的市场来说 SwiftUI 还是比不过 Flutter，不过既然 SwiftUI DSL 层曾经根本固定，那么也有可能投入人力间接在低版本操作系统上实现一套自建的 SwiftUI 引擎，或者将 SwiftUI 引擎移植到安卓平台，比方对接 Flutter 或者间接对接 Android Native。
比起 Flutter 引入双端带来的包大小增量和体验不统一的状况，SwiftUI 保留 iOS 平台体验，只侵入一端的抉择显然要更好一点。
招人啦！
欢送投递简历~ 手淘客户端架构组，负责淘宝客户端的根底框架包含组件化容器、启动器、路由、UI 框架等，负责高可用包含 Crash、卡顿、内存、耗电等监控，负责全局性能、体验优化，负责重点技术包含存储、日志、修复等，负责零碎新个性、新技术、新设施摸索，在这里你会面临海量用户、大规模业务、双十一大促带来的微小技术挑战，你能与资深大牛并肩作战，深刻零碎内核钻研解决简单问题，迅速成长为业界优良工程师！
简历投递：qinghan.jy@alibaba-inc.com
参考
- SwiftUI 背地那些事儿
- MovieSwiftUI
- SE-0281-main-attribute.md
- Add custom views and modifiers to the Xcode Library
- Structure your app for SwiftUI previews
- Introduction to SwiftUI
- What’s new in SwiftUI
- App essentials in SwiftUI
- Visually edit SwiftUI views
- Stacks, Grids, and Outlines in SwiftUI
- Build document-based apps in SwiftUI
- Data Essentials in SwiftUI
- Build a SwiftUI view in Swift Playground
- Build SwiftUI apps for tvOS
- Build SwiftUI views for widgets
- Build complications in SwiftUI
- What’s new in Swift
- Swift packages: Resources and localization
- Distribute binary frameworks as Swift packages
- Explore logging in Swift
- Create Swift Playgrounds content for iPad and Mac
- Embrace Swift type inference
- Explore numerical computing in Swift
- Unsafe Swift
- Safely manage pointers in Swift
- Explore numerical computing in Swift [
- Explore Packages and Projects with Xcode Playgrounds
- Use Swift on AWS Lambda with Xcode