SwiftUI【0】

cena1001發表於2020-10-28
SwiftUI

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

參考

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

相關文章