新建一个SwiftUI的项目
项目结构
我们发现图2中，项目结构变得非常的简单，只有两个文件#AppName#App.swift和ContentView.swift
我们先看一下相对简单的ContentView.swift这个文件。
代码并不多，创建一个结构体遵循了View协议，重写了body变量的get方法这时候我们发现一个比较让人疑惑的事情，这个View类型用一个some来修饰。
some关键字是什么？
被some关键字修饰的类型被成为不透明类型（opaque return types）。
它的语义可以简单的理解为“返回符合这个协议的具体类型，但不指明具体类型”。
它相当于一个反向范型。通常的范型，我们是需要使用协议本身，并不关心子类是什么，需要被调用者指定。而反向范型正好相反，反范型函数需要使用协议的子类来处理，但是返回一个遵循协议的不透明类型。
范型：具体类型由调用者指定
some：具体类型由被调用者指定
//Protocol 'View' can only be used as a generic constraint because it has Self or associated type requirements
//代码提示以上错误，无法编译通过
//（1）
func someView() -> View {
Text("Hello World")
}
//（2）
func someView2() -> Text {
Text("Hello World")
}
//（3）
func someView3() -> some View {
Text("Hello World")
}
函数（1）无法编译通过，因为View协议内部定义了Self范型,我们可以看下View协议的定义。
public protocol View {
associatedtype Body : View
@ViewBuilder var body: Self.Body { get }
}
这里使用了Self范型，以及Body范型。Swift语法中，这不符合语法规范。因为编译器只能知道View的接口情况，而并不知道associatedtype的具体情况。
函数（2）虽然可以编译通过，但是我们可能用任意视图去渲染，如果每次视图不一样，都要改方法的返回值，那就太麻烦了。some关键字就解决了这个问题。它可以有被调用者指定具体类型，而不用透明出来。
接下来我们看一下有一个struct叫ContentView_Previews它遵循了PreviewProvider协议。以下是PreviewProvider的定义
public protocol PreviewProvider : _PreviewProvider {
associatedtype Previews : View
@ViewBuilder static var previews: Self.Previews { get }
static var platform: PreviewPlatform? { get }
}
跟View的定义类似，只不过preivews是statics变量。这个类对应右手边Canvas窗口。可以进行实时预览。previews可以返回多个View，每个View都会生成一个预览窗口。我们可以结合不同的参数，测试各种case。
不同参数的测试
struct ContentView: View {
private var content:String = "test"
init(aContent: String) {
content = aContent
}
var body: some View {
Text(content)
.lineLimit(2)
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView(aContent: "Hello")
ContentView(aContent: "Hello\nHello")
ContentView(aContent: "Hello\nHello\nHello")
}
}
以上代码在Content中绘制了一个Text，通过init传入的参数展示内容。Text被设定为最多展示两行。
预览窗口分别显示了一行文本，两行文本，三行文本展示的样式。
不同机型的测试
View协议定义了previewDevice的方法，可以传入一个PreviewDevice对象，测试不同机型的展示
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView(aContent: "Hello")
.previewDevice(PreviewDevice(rawValue: "iPhone 8"))
ContentView(aContent: "Hello")
.previewDevice(PreviewDevice(rawValue: "iPhone 8Plus"))
ContentView(aContent: "Hello")
.previewDevice(PreviewDevice(rawValue: "iPhone X"))
ContentView(aContent: "Hello")
.previewDevice(PreviewDevice(rawValue: "iPhone 11"))
}
}
以上代码就可以根据不同机型预览视图
如果是支持多平台的项目，还可以根据不同平台预览 ，重写PreviewProvider的platform方法
static var platform: PreviewPlatform? { get }
PreviewPlatfrom是一个枚举，定义如下
public enum PreviewPlatform {
case iOS
case macOS
case tvOS
case watchOS
}
预览代码对原有的业务逻辑无入侵，而且可以事实预览非常方便，调试阶段可以把各种UI的case写入预览类里面，每个View创建时，默认都会创建预览类。
是源代码也是样式表
var body: some View {
VStack {
HStack {
Text(content)
.lineLimit(2)
.background(Color.blue)
.foregroundColor(.green)
.lineSpacing(5)
Text("right")
.background(Color.red)
}
Text("bottom")
.font(.none)
}.colorScheme(.light)
}
这是一个简单的视图布局，我们可以看到它特别像Android里面的布局文件xml。但由于它确实也是源代码，所以在代码风格上尤为特殊，要避免过于混乱导致的维护困难。xml是通过节点对齐的方式书写，SwiftUI也有自己的书写样式。上面的代码我给Text设定了很多属性。我们可以看到它是以链式方式调用的。也有一些容器组件。自动生成的代码样式就是如上面所以，不同属性之间通过【换行】+【Tab缩进】方式排列，容易组件于基本组件之间也用【Tab缩进】方式排列。同一层级多个组件对齐。这可能是苹果官方推荐的一种代码样式，建议所有人都按照这种风格书写，由于属性太多导致很多行，同一层级的多个组件之间建议增加空行。
@ViewBuilder
在上述代码我们看到SwiftUI的布局代码跟Xml或者json有点类似。VStack是个节点里面有HStack和Text节点，HStack又有两个Text。这其中每个节点都可以作为一个完整独立的视图。包括单纯的Text里面的一串属性，多一个，少一个也并不影响其完整性，其最终结果都返回一个View。而@ViewBuilder，可以理解为一种语法糖或者宏，其有点类似于闭包，把一段布局代码封装成一个特殊的对象，这个对象作为参数和返回值传递到各种地方进行复用。
struct RedBackGroundCornerRadius<Content: View>: View {
let content: Content
init(@ViewBuilder content: () -> Content) {
self.content = content()
}
var body: some View {
content
.background(Color.red)
.cornerRadius(5)
}
}
struct FontColorGreen<Content: View>: View {
let content: Content
init(@ViewBuilder content: () -> Content) {
self.content = content()
}
var body: some View {
content.foregroundColor(.green)
}
}
struct MyView: View {
var body: some View {
RedBackGroundCornerRadius {
FontColorGreen {
Text("Hello World!")
}
}
}
}
我们可以看到@ViewBuilder可以把我们既定的样式进行封装，把我们的样式封装成一种容器类的视图。这样我们就可以复用我们定义的一些通用的样式，并且以一种装饰器的方式构建页面。代码变得简洁易懂，复用性强。
接下来我们看另外一个文件##AppName##App.swift文件
import SwiftUI
@main
struct SwiftUIFirstAppApp: App {
var body: some Scene {
WindowGroup {
ContentView(aContent: "Hello World")
}
}
}
struct SwiftUIFirstAppApp_Previews: PreviewProvider {
static var previews: some View {
Text("Hello, World!")
}
}
全部的代码也非常少。首先说一下@main这个写法。
这个写法有点像Java的注解。实际上有点类似，它定义了程序的入口点。它后面必须跟一个struct，后面的类必须提供一个static void main方法，否则会报错，说实话者跟J2SE的main函数有点像。App启动后会调用这个main方法。
假如你尝试再搞一个遵循App的struct，前面加上@main，程序完全可以正常运行，而你原来的App struct就没有用了。我也尝试自己随便写一个struct，不遵循App定义，也实现了static void main方法，程序编译通过，并且也可以启动，只不过后面直接崩溃了。
再说一下App，App是一个协议（protocol）,其定义如下。
public protocol App {
associatedtype Body : Scene
@SceneBuilder var body: Self.Body { get }
init()
}
显而易见，Scene也是一个协议，App有一个body属性遵循Scene协议。每个Scene有一个包含一个视图层级树的根视图，并由系统管理其生命周期。SwiftUI提供了一些具体的场景类型来处理常见的一些场景。例如文档和设置，你也可以自定义一些Scene。
同样显而易见，从代码我们也知道，WindowGroup是实现了Scene的一个具体struct。WindowGroup是作为视图层级的一个容器，我们可以简单看下WindowGroup的定义。
public struct WindowGroup<Content> : Scene where Content : View {
public init(@ViewBuilder content: () -> Content)
}
容器通常有一个Content范型，其实现View协议，并且再初始化的时候传入一个闭包，闭包返回一个View。WindowGroup是一个既有的，SwiftUI提供的Scene。Content就是WindowGroup的根视图。
如果我们想要自定义Scene，可以进行如下代码。
struct MyScene: Scene {
var body: some Scene {
WindowGroup {
MyRootView()
}
}
}
系统根据程序状态，以适合平台特性的方式显示WindowGroup的视图。例如，系统允许用户在macOS和iPadOS等平台上创建或删除包含MyRootView的窗口。在其他平台上，就会全屏展示。
