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 背后那些事兒

關于swiftUI，看這一篇就夠了

應用舉例

示例1：

實作一個串列，點擊串列的item，跳轉到對應的詳情.

示例2：

基于SwiftUI的一個簡單示例
介紹了通過宣告和修改視圖來布局UI，以及使用狀態變數來更新UI，

示例3：

SwiftUI 實戰：從 0 到 1 研發一個 App

作者使用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；必須進行預覽才能正常作業，

• 代碼與預覽的匹配程度如何？

對預覽進行任何更改時，它也會更新生成的代碼，同樣，如果更改代碼，它也會更新用戶界面，因此，代碼和預覽是相同的，并且始終保持同步，

發展前景

Swift怎么樣？

作者：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的開發者已經沒有那種創新的想法跟不上市場需求公司需求，但是自己也沒有認清自己，所以被淘汰了才來怪這個行業 ，每個行業都是會飽和的，趨于平穩的，但是優勝劣汰是一直存在的，所以只要你的技術一直創新符合市場的需求，那就不存在沒有人要 ，歸根結底，還是自己淘汰了自己

參考

以下是本文的一些參考以及參考地址：

• 歷時五天用 SwiftUI 做了一款 APP，阿里工程師如何做的？
• @frozen Swift（SwiftUI中文檔案手冊）
• SwiftUI快速入門
• SwiftUI系列-起航
• SwiftUI是什么，聽聽大牛們如何說
• 如何評價 SwiftUI？
• 系列文章深度解讀|SwiftUI 背后那些事兒
• SwiftUI 初體驗
• 0