关于 SwiftUI 的介绍

SwiftUI 是一种非常简单的创新方法,可以利用 Swift 的强大能力在所有苹果设备平台上构建用户界面。因对 Swift 水平有限,这里不会深入的讨论 Swift 语法特性和 Combine 的使用及实现原理,而主要介绍 SwiftUI 一些情况。

一、SwiftUI 诞生

2019 年 WWDC 现场,苹果宣布推出 SwiftUI,SwiftUI 是基于开发语言 Swift 建立的框架,可以用于 watchOS、tvOS、macOS 等苹果旗下系统。开发者可以通过命令或拖拽等方式,轻松编辑语言。目前,SwiftUI 只支持 Xcode 11、iOS 13 版本及以上,SwiftUI 将于秋季正式推出,因此采用 SwiftUI 开发的 APP 可能还需要一些时间。

因为声明式 UI已经成为主流,声明式编程是未来

  • 代码是描述程序在做什么,可阅读性会大大提高;
  • 组件状态更容易维护在内部,减少副作用;
  • 组件之间的边界更明显,从而让组件复用更灵活。

二、SwiftUI 设计目标

SwiftUI 的愿景是降低开发 iOS 门槛,吸引更多开发者、丰富 iOS 的业态。为了达到这个目的,苹果一直在尝试 所见即所得 的理念,从早期 xib 到 stroyboard。这么多年了,这几项技术发展不尽如人意,并没有在生产环境中流行起来,但苹果一直在动这方面的心思。

随着整个软件开发领域的演进,近年来涌现的 React,Vue,Flutter 技术,逐渐证明了一个事实;在 UI 开发领域,描述性语言是最佳方式

这催生了 SwiftUI 全新的 UI framework 的诞生,在开发 SwiftUI 伊始,SwiftUI 团队就确认了基本的原则:

  • 用原生语言的编写描述性界面
  • 数据驱动,A Single Source Of Truth

为什么 SwiftUI 对于开发者那么重要呢?原因其实很简单,因为新的 SwiftUI 框架利用了苹果自定义创建的 Swift 语言的特性,使开发人员更容易、更快地构建更好的用户界面代码,同时错误会更少,也能创造更多的功能。SwiftUI 让苹果开发者专注于打造自己的原创内容,同时可开发出更统一、更强大、外观更现代的软件,影响将是巨大的。

三、界面描述语言(DSL)

先抛开 xml 语言,再看看下面的描述语言:

  • HTML,界面描述能力最好,和实际节点真·一一对应(::before 除外),但是缺乏编程能力
  • Flutter,具有很强的编程能力,但使用代码函数调用、入参、形参、代码缩进来模拟界面的层级结构的方式,不够优雅,层次不精确,而且函数调用里的 ,、{}的符号的存在,导致布局代码观感很差,神似型不似,这点很致命。加上不区分 UI 结构和 UI 属性,以及一套代码到处跑的理念和我们苹果承认设备差异性是相左的
  • JSP、jQote、php,这些模板技术既有编程语言,又可以输出 UI 模板,但是太灵活,不可控,原始,不利于做封装和优化
  • JSX、Pug、Vue,Pug 脱胎自 html,拥有极其简洁的界面描述语法;JSX、Vue 的编程能力和界面描述能力平衡的很好,但是他们需要对模板编译然后再用 JS 渲染,Pug 式简洁的语法 + 受限的编程能力。最重要,不能引入编译过程

也就是说他必须是 100 % 的 Swift 源码—— 不需要引入新的布局语言,而是用 Swift 语言自身来实现界面描述语法,这才是真正的挑战。

四、SwiftUI 的组件

有了布局的 DSL 语法,我们还需要内置的 SwiftUI 组件,支撑快速开发能力。有两个原则:

  • 提供最朴素的组件集
  • 提供扩展能力

4.1 组件定制原则

SwiftUI 自带 Design System。Design System 遵循的是基本的Human Interface Guidelines – Design的条款。在一定程度上,你必须遵守这些设计原则,这样产出来的 App UI,自动符合 Human Interface Guidelines – Design 的要求,比如:

  • List 必须有 seperator
  • 元素之间默认拥有符合苹果美感的间距
  • 容器元素布局符合 Guidelines
  • 无处不在的留白等

有些属性你甚至没有开放接口可以定制,如 Scrollview 你甚至不能设置 is PageEnabled。定制参数以初始化参数的形式存在,额外行为通过 view modifier 来实现。我们认为在 apple-style 里,你只需要关心这些参数就够了,如果有已有的样式行为不能满足,你需要通过适配自定义 UIView 到 SwiftUI 的方式实现。

4.2 更简化的布局系统

在 React-Native 身上,可以看到了 css 的一个子集完成可以满足日常的布局需要,复杂如 float, 在 Web 领域甚至都没有在用 float 的本意使用, native 里更不需要。而 iOS 上的 Autolayout 用来解决适配问题的方式,多少有些繁琐,以进一步简化:

  • flex
  • position 、offset
  • 盒子模型,既不是 content-box 也不是 border-box,和设置 padding 顺序有关、只有 padding 没有 margin

上面的设计要素是完备的,布局系统简化带来运行效率和开发效率的双提升,对 SwiftUI 的运行时实现也是个很大的简化。

4.3 SwiftUI 的扩展能力

在 SwiftUI 的封装里不容许暴露潜在的危险。考虑:

自定义组件的标签也不容许包含 SwiftUI 组件作为子元素

考虑到还要支持组件的 preview,要求我们实现一切 View 都可以被单独展示,在 SwiftUI 里所有的 View 都是相同的,都可以被 present 和 push。只是在考虑到和 UIKit 协同时,我们单独在 UIViewRepresentable 的基础上封装了 UIViewControllerRepresentable,记住 万物皆为 View(对标 Flutter:一切都是 widget)

除了 UI 组件的扩展性,当一个 View 内部因为异步网络数据或者复杂的事件交互变多时,我们参考了 iOS 里比较流行的 MVVM、VIPER 架构,解决传统的 MVC 框架下 ViewController 过于膨胀的问题 —— 引入Coordinater 机制。

UIViewRepresentable 负责单纯的 UI 数据刷新逻辑, Coordinater 加工数据和内部事件更新数据;并且严格限制在 View 实例里,被 @State 标记的变量只在 var body: some View {} 只读属性里被改变,强制 View 和 BindableObject 实例的职责分离,首先是加工数据然后是使用数据渲染,不许混杂。

至此,涉及对 UI 静态部分的 SwiftUI 设计基本成型。

五、SwiftUI 的开发范式

日常开发工作,项目业务类型和项目体量形态差异会导致用相同的 API,产出迥异的项目代码结构和分层,有必要给出我们推荐的开发规范。让普通的开发者能够快速上手 SwiftUI,使用 SwiftUI 的设计思路来开发 APP。

SwiftUI 现在还在 beta,这后面也依赖苹果对 Swift 的控制,所以在 Swift 语言层面对 SwiftUI 这个 UI 库,进行了极大的支持,寄希望于 SwiftUI 的品质和 Apple 产品给用户的体验一样 — 简洁、优雅,背后又蕴藏玄机。

SwiftUI官方教程