SwiftUI【0】
最近开始了解学习SwiftUI的相关内容。参考了简书、CSDN以及百度的一些文档，帮助自己有个更好的了解。
前言
苹果在2019年的WWDC的重头戏当然非SwiftUI莫属：全新的声明式语法、绑定式API、和响应式变成框架Combine。这一切的一切都预示着即将在Apple Native布局系统掀起一场革命。为此，苹果在很多方面都做了努力，这才促成了SwiftUI现在的样子。想要了解Swift的新特性、SwiftUI数据流和SwiftUI布局系统等新知识吗？一起来看吧。
快速入手
官方教学网站
可以进入了解相关概念，学习技术语法。
什么是SwiftUI？
苹果官方介绍
写更少的代码，打造更出色的 app。
SwiftUI 是一种创新、简洁的编程方式，通过 Swift 的强大功能，在所有 Apple 平台上构建用户界面。
借助它，您只需一套工具和 API，即可创建面向任何 Apple 设备的用户界面。
SwiftUI 采用简单易懂、编写方式自然的声明式 Swift 语法，可无缝支持新的 Xcode 设计工具，让您的代码与设计保持高度同步。
SwiftUI 原生支持“动态字体”、“深色模式”、本地化和辅助功能——第一行您写出的 SwiftUI 代码，就已经是您编写过的、功能最强大的 UI 代码。
苹果的官方介绍透露了大量的隐藏信息，例如通过SwiftUI打通所有苹果设备之间的壁垒，实现苹果世界的大一统。通过SwiftUI打通程序员与设计师之间的鸿沟，让App开发更具工匠精神。通过SwiftUI来提供你的代码的表达力，一句胜千言。
对于介绍的理解
SwiftUI是一个用户界面工具包，可让我们以声明的方式设计应用程序。这是一种奇特的方式，我们告诉SwiftUI我们希望UI的展示效果和工作方式，它知道如何在用户与之交互时实现这一点。
SwiftUI 是一种非常简单的创新方法，可以利用 Swift 的强大能力在所有苹果设备平台上构建用户界面。通过 SwiftUI，开发者仅使用一组工具和 API 就能为所有苹果设备构建用户界面。SwiftUI 使用易于阅读和编写的声明式 Swift 语法，可与新的 Xcode 设计工具无缝协作，使你的代码和设计完美同步。SwiftUI 自动支持动态类型、黑暗模式、本地化和可访问性，你的 SwiftUI 代码将成为你写过的最强大的 UI 代码。
SwiftUI还充当跨平台的用户界面层，可跨iOS，macOS，tvOS甚至watchOS运行。这意味着你现在可以学习一种语言和一种布局框架，然后将代码部署到任何地方。
SwiftUI 优点
- Apple says SwiftUI is the shortest path to building great apps on every device. 苹果说SwiftUI是制作跨平台伟大App的最短路径。
- SwiftUI满足了程序员复杂粘贴代码的需求，传统IB和storyboard编辑页面方式造成代码很难被复用
- 跨平台的便利性
Swift 5.1 新语法以及SwiftUI算法介绍
参考文章：
系列文章深度解读|SwiftUI 背后那些事儿
应用举例
示例1：
示例2：
基于SwiftUI的一个简单示例
介绍了通过声明和修改视图来布局UI，以及使用状态变量来更新UI。
示例3：
作者使用swiftui开发了一个记录习惯的APP，页面简洁，很有iOS的简洁味道，文章还有开源代码，可以进行查看；
APP的效果如下:
使用问题
- SwiftUI可以在哪里使用？
SwiftUI在iOS 13，macOS 10.15，tvOS 13和watchOS 6或这些平台的任何更高版本上运行。这意味着，如果您使用的应用程序必须支持iOS N-1甚至N-2（即当前版本和该版本之前的一两个版本），那么您甚至需要一两年的时间才能考虑迁移到SwiftUI 。
但是，重要的是不要将SwiftUI视为类似于Java的Swing或React Native的多平台框架。官方说法似乎是，SwiftUI不是一个多平台框架，而是一个用于在多个平台上创建应用程序的框架。
听起来可能是一样的，但是有一个重要的区别：Apple并不是说您可以在每个平台上使用相同的SwiftUI代码，因为有些事情是不可能的–无法在Mac上使用Apple Watch的数字王冠例如，并且类似地在watchOS应用上具有选项卡栏也将无法工作。
- SwiftUI会取代UIKit吗？
不会。SwiftUI的许多部分都直接建立在现有UIKit组件之上，例如UITableView。当然，许多其他部分则没有，它们是SwiftUI而非UIKit呈现的新控件。
但是重点不是UIKit涉及的程度。相反，关键是我们不在乎。SwiftUI或多或少完全掩盖了UIKit的行为，因此，如果您为SwiftUI编写应用程序，并且Apple在两年内用唱的大象代替了UIKit，那么您不必在乎–只要Apple使大象具有相同的方法和属性即可该UIKit暴露于SwiftUI，您的代码不变。
- SwiftUI是否使用自动布局？
尽管Auto Layout肯定会在幕后用于某些事情，但作为SwiftUI设计师并没有暴露给我们。取而代之的是，它使用了灵活的盒式布局系统，这对于来自Web的开发人员来说将是熟悉的。
- SwiftUI快吗？
SwiftUI是令人讶异的快-在所有我的测试中，到目前为止，似乎超越的UIKit。与做到这一点的团队交谈后，我开始明白为什么：首先，他们积极地扁平化图层层次结构，这样系统就不必做更多的绘制了，但是第二步，很多操作完全绕过了Core Animation，直接去了Metal进行了额外的处理。速度。
所以，是的：SwiftUI的速度非常快，而且所有这些都无需我们做任何额外的工作。
- 为什么看不到我的代码预览？
使用SwiftUI时，能够同时查看视图代码和视图预览（外观）非常有帮助。如果您可以看到代码而不是预览，则可能是您尚未升级到macOS 10.15；必须进行预览才能正常工作。
- 代码与预览的匹配程度如何？
对预览进行任何更改时，它也会更新生成的代码。同样，如果更改代码，它也会更新用户界面。因此，代码和预览是相同的，并且始终保持同步。
发展前景
作者：iOSer
来源：知乎
得益于swift的开源，以及苹果的号召力，swift发展的很好。已经得到了广大开发者的一致认可。苹果自己也很重视，新的一些lib和app已经用swift编写。国外大厂比如Uber、LinkedIn已经用swift开发了很长时间。这些行动证明了swift已经不是一门玩具语言可以大胆的在开发中使用。虽然眼下还有ABI不稳定，和Xcode索引会让人觉得慢等问题。但是相比OC的巨大进步，更多开发者选择了忍受，希望苹果能够持续优化。但是OC的runtime依然是无可取代，从商业角度看也没有理由取缔它。所以两者还会互相存在一段时间。但是我相信swift占有率超过OC的节点很快就会到来。我觉得很多人坚持OC是因为他们只会OC。移动市场已经饱和2008年苹果发布第一个SDK，同年年末安卓1.0发布。移动开发元年。移动开发从无到有，至今已经遍及生活各个方面。
从2019年手机的出货量和身边的观察很容易得到这样的结论：移动开发这块蛋糕的高速增长已经结束了。这意味着什么呢？在一个行业高速增长的时候，人才一定是供不应求。所以公司被迫接收很多新手，对新人很友好。相信大家也见证了过去一两年里的就业奇迹：是个人就能上。所以对于很多只是为了糊口的人而言：这扇门已经关闭了。你们继续去追下一个热潮吧。听说JavaScript要统一天下了，要不您去21天学个前端？言归正传，那移动开发是不是就要大势已去了呢？
朋友，恕我直言：不是移动开发不行，是你不行。在移动浪潮前，互联网流量全在桌面，问2008年的时候有条件坐在电脑前上网的人群有多少？再看现在，微信这个季度的活跃用户5亿多。虽然iOS的份额只有百分十几。但是这是无法被忽略的百分之十几，公司但凡有移动业务肯定会做iOS客户端。
所以iOS开发的市场依然存在，而且不是一块小蛋糕。在移动开发前几年的时间里，想在移动端做功能只有开发Native app这么一条路。但是商业就是如此，随着需求增大最后总是会有提高效率或者一些自动化的方案出来。相信很多人都有看到类似的文章：你不需要开发一个app只需要一个公众号就可以了。前阵子微信推出小程序没见过世面的吃瓜群众们也是激动了一番。其实这只是一笔经济账。现在对于产品而言，有了更多的选择。如果一个产品本身对native的能力要求就很低，当然会选择更便宜的方式了。
除了微信小程序这样嵌入在微信里的方案。由传统web端发起的新技术Progressive Web App也很值得关注。简单的说web也可以有一个方便的渠道生成一个本地的app，获得一些推送、本地存储等一些能力。稍微有一些无奈的是iOS目前还不支持pwa。苹果去年宣布5年内会支持这个标准，然而除apple外其他厂家已经全部支持，现在安卓上是支持的。所以虽然这件事现在还没发生，但是不久的将来应该会有新的进展。总而言之，很多移动产品不再需要开发一个native app了。
但是，凡事不要难过的太早，说不定还有更惨的呢？React Native VS Weex我觉得那些用RN的人最后都会哭。算了，我知道你们会选择倔强。先从感情上说。你是相信马云爸爸还是相信404伯格？RN现在的硬伤有：1、包无法增量更新2、长列表没有优化（灾难性tableview cell没有复用）3、不支持web当然了这些不是实现不了，是的，你完全可以自己实现上面的三个难题。但是如果已经有一个现成的方案呢？是的，阿里的weex已经走在RN的前面。我不知道是阿里的996更努力还是马爸爸砸的钱就是多，但是事实就是如此。RN是一个纯开源的项目，所以不可能将来RN有个杀手级的功能weex没有。比的就是谁走的更快，看的更远。大家要有自信，在移动开发上，我们的实力已经是世界一流了。所以，对于native不幸的消息来了：即便是native的app，很多功能也要交给前端实现了。这笔账是非常清楚的：原来需要一前端，一个iOS，一个安卓。现在只需要前端写一次。粗粗一算节省了三分二的成本。但是就像java一开始就吹的run anywhere。什么技术都有它的应用场景，不是能用大家就用这个技术。可是根据我的观察，在优化了性能问题后，一个app里有非常多的页面确实不需要native写了，用这种weex的方案就能解决了。而且开发效率的提升是如此的明显，将来会有大量的页面不再需要native写代码发版了。移动开发者的未来首先你要接受一个事实，我们生活在一个科技变革最快的时代。很不幸软件行业又是所有行业变化最剧烈的行业。
摩尔定律每18个月计算能力翻一倍。在其他行业什么东西能每两年增加一倍而且持续几十年？换句话说，选择了软件开发，过去二十年里除了C++，C，Java至今依然大量需求，选择其他技术或者语言都经历了潮起潮落。那么从开始有程序员至今有多少语言呢？所以说，一门技术兴起然后被冷落，如果用十年的尺度来看是非常正常的。我们的父辈在七十年代也不相信国企会下岗。你也不要抱有熟悉了一门技术可以养活你一辈子。
你怎么理解 iOS 编程？某门技术或者某个编程语言说到底只是工具罢了。原来你用筷子，后来你来到了西餐厅，只有刀叉你就吃不了饭了？活该你饿死。不是iOS没有人要，很多公司现在都在招iOS的开发者，主要是很多iOS的开发者已经没有那种创新的想法跟不上市场需求公司需求，但是自己也没有认清自己，所以被淘汰了才来怪这个行业 ，每个行业都是会饱和的，趋于平稳的，但是优胜劣汰是一直存在的，所以只要你的技术一直创新符合市场的需求，那就不存在没有人要 ，归根结底，还是自己淘汰了自己
参考
以下是本文的一些参考以及引用地址：