前言
Apple 在今年的 WWDC 釋出了 iOS 14 上新的小元件方案，可以說是一次對 iOS 桌面的大手術，也是使用者能感知的大變化之一。
作為一名從 iOS 8 開始就在給 iOS 寫各種小元件的開發者，我想透過這篇文章來給大家介紹一下 iOS 14 的小元件有什麼不同，以及自己的一些想法。
注：本文寫作時 iOS 14 的最新測試版為 Beta 2，之後的版本可能會有變化。
iOS 14 小元件
心理落差
今年的 WWDC 我全程觀看了 Keynote，並且在第一時間嘗試了新的小元件，包括使用者層面和技術層面的嘗試。以我個人角度來評價這件事的話，我覺得 Apple 給我造成了極大的心理落差。
在觀看 WWDC 的時候，我的心情是這樣的：
以後小元件可以直接拖到桌面上了
，這很方便哦。
可是在升級 iOS 14 之後卻發現，已有的第三方小元件並不能直接拖到桌面上。在閱讀相關的技術文件之後，我發現今年這個小元件和之前放在通知中心那個小元件完全是兩種東西，這意味著開發者必須單獨為 iOS 14 開發小元件才行。
再然後，我發現新小元件只能使用 SwiftUI 製作。這是一件有好有壞的事情，而且也是 Apple 第一次這麼幹。
經過幾天的研究和體驗之後，我確定了一件事情：
iOS 14 的小元件本質上就是 watchOS 的 complications
，這樣理解能解釋很多問題。
好的方面
先聊點高興的，新的小元件相較之前有很多有趣的地方。
在桌面顯示
相比於之前的在下拉通知中心或者滑到桌面最左邊，新的小元件可以直接放到桌面上。
拖放至桌面
放到桌面上的小元件可以很好地和應用圖示結合在一起，大大地增加了小元件被使用的機率。
可多次新增
雖然 iOS 14 之前，一個應用也可以建立多個小元件，也可以多個小元件之間只是有細微的差異，但 iOS 14 的方式顯然更方便。
在 iOS 14 裡面，同一個小元件可以被新增到桌面多次：
同個小元件新增多次
並且，你可以直接在桌面完成對每個小元件例項的配置，這可以做到多個小元件使用同一個樣式，但資料不同。並且，在桌面完成配置也大大簡化了配置的流程。
在桌面完成配置
作為 JSBox 應用的開發者，我收到過很多增加小元件個數的請求，這件事在 iOS 14 就不復存在了，因為小元件可以無限新增。
多種尺寸
iOS 13 的小元件寬度是固定的，高度可以由開發者掌控，可以在「展開」和「摺疊兩種狀態切換」：
iOS 13 樣式小元件
而在 iOS 14 裡面，同一個應用可以提供幾個不同尺寸的小元件，分別是
2 * 2
、
2 * 4
和
4 * 4
圖示大小的規格。
多種規格
根據應用的需求，不同尺寸的小元件可以用來展示不同複雜程度的資訊，應用也不一定提供所有尺寸的小元件。
疊放
系統提供了「智慧疊放」小元件，他可以將多個小元件疊放在一起，使用者可以上下滑動來切換當前展示的內容。另外，iOS 會盡可能地為使用者展示合適的當前內容。
智慧疊放
除此之外，你也可以手動將兩個元件疊放在一起，只要他們的尺寸相同即可：
手動疊放小元件
SwiftUI
新的小元件框架是 SwiftUI only 的，這意味著你不能使用 SwiftUI 以外的介面技術進行構建，這是歷史性的第一次。
從好的方面看，除了讓構建介面的成本降低以外，SwiftUI 有個額外的好處：
跨平臺
，當然這裡指的是 Apple 的平臺。
使用 SwiftUI 構建的小元件可以原生支援 iOS 和 macOS，並且 iOS 14 和 macOS Big Sur 上有同樣的設計語言，這是構建 iOS 和 macOS 融合的應用裡面很重要的一環。
關於推動 iOS 應用執行在 macOS 上，可以看出 Apple 花了巨大的精力，不過這個是另一個很大的話題，在這裡就不展開了。
不好的方面
俗話說天下沒有免費的午餐，Apple 提供了這麼多有趣的特性，想必新的小元件一定有什麼坑吧？你猜對了。
更弱的互動能力
在 iOS 14 之前，Apple 也不建議在小元件做複雜的互動，很多操作是被禁止的，例如列表滾動和文字輸入。而在 iOS 14 的小元件裡面，Apple 將這個限制推到了極限：幾乎做不了互動。
為了避免陷入過於難懂的技術討論，我將這件事儘可能簡單化地描述：
在以前，小元件可以「就地」處理一些工作，例如使用 AutoSleep 的「熄燈」功能告訴應用開始睡覺了。
在之後，點選小元件一定會開啟相應的主應用，可以傳遞資訊給主應用進行處理，例如導航到應用內的某個頁面。
這樣的改動對於依賴小元件互動的應用是一個毀滅性的打擊，例如著名的 PCalc，則無法在 iOS 14 實現一個小元件計算器，因為你點了按鈕之後就開啟應用了。還有啟動器一類的應用，處理 URL 跳轉的時候需要跳兩次，這是你期待的體驗麼？
PCalc 小元件計算器
點選後開啟應用
所以其實 iOS 14 小元件就是
資訊展示
加上
連結導航
的一些方塊，這樣理解就不會期待過高。
另外，實際上在 iOS 13 的幾個版本里面，桌面小元件已經出現了不能響應點選事件的問題，當時開發者們普遍認為是 Bug，現在回過頭來看可能是故意的。
無法主動更新資料
當你看到一個 iOS 13 的小元件時，小元件可以主動獲取最新的資料，但 iOS 14 的小元件卻不是這樣工作的。
在 iOS 14 上，系統會向小元件詢問一系列的資料，並根據當前的時間將獲取到的資料展示出來。
由於程式碼並不是主動執行的，小元件更偏向於「靜態的」資訊展示（連動畫和影片也都是被禁止的），儘管資訊可以透過某種方式更新。舉個簡單的例子，你甚至無法透過小元件記錄剪貼簿，剪貼簿工具必須提供一個按鈕，點了之後跳到應用內去完成記錄。
iOS 13 中 Pin 的剪貼簿小元件
更弱的頁面動態性
這是 SwiftUI 雙刃劍的反面，由於無法使用常規的介面構建方式，iOS 14 小元件的介面必須預先定義好，然後透過資料來填充其內容。
這對很多應用來說不是什麼大問題，但對能夠動態構建小元件的 JSBox 而言是一次削弱。
使用指令碼構建的 JSBox 小元件
我可以想象在 JSBox 之後的版本里面，構建小元件會是一件更容易的事情，像是搭積木一樣。但是構建出來的頁面，可能不會具有 iOS 13 那樣的靈活性，而是一些模板化的樣式。
一點想法
“Widgets are not mini-apps”
（小元件不是應用的迷你版本），這是 Apple 在相關課程反覆提到的概念，這也是 Apple 對開發者做出的設計指引：不要把小元件做成一個小應用，他有自己的應用場景。
Widgets are not mini-apps
Apple 做這些限制有他的考慮，某種程度上也是剋制的體現。但直接剝奪使用者的現有習慣這件事，作為開發者我很難表示認同。
另外令人唏噓的是，快捷指令是一個例外，它不受上述任何一條所限制，也沒有遵循 Apple 自己給出的設計指引。當然了，這從來都不是什麼新鮮事，甚至 iOS 14 自帶的小元件也不是用 SwiftUI 寫的。作為開發者，可以參考自帶的小元件來獲得一些靈感，但是不要奇怪為什麼你不能做到第一方小元件那樣的效果。
老的小元件何去何從
透過上文我們已經瞭解到，一個應用可以同時擁有 iOS 13 和 iOS 14 的兩種小元件。那麼在推行新的小元件之餘，老的小元件何去何從？
答案應該是會被廢棄，理由有三點。
使用體驗被降級
在 iOS 14 新增一個老的元件到通知中心極為困難（而長按桌面圖示使用小元件的方式則被去除），需要進入桌面編輯模式之後滑到最左側，再點最下方的編輯按鈕。在展示方面，老元件會被新元件擠到最底下，可以說是完全沒人權了。另外在 Beta 2 裡面，老的元件寬度被調整成和新的元件一樣寬，看上去極為彆扭。
小元件寬度過窄
開發介面被標註為過時
在 iOS 14 的開發套件裡面，老的小元件開發方式已經被標註為過時，也即不推薦、隨時會被廢棄的內容。
按以往的經驗，標註為過時的方法是作為過渡時期的方案，並終將會被移除的。
Deprecated
Apple 透露的資訊
有開發者朋友從 Apple 的 WWDC 實驗室瞭解到，在 iOS 14 之後的版本里面，應用如果提供了新的元件，使用者則看不到老的元件了。
如果這個證據還不夠充分的話，macOS Big Sur 裡面已經沒有老的小元件了，這是最直接的證據。
後記
作為在 iOS 8 引入，又在 iOS 14 徹底改版的功能，小元件伴隨了 iOS 發展路線中很重要的一段路程。但我作為開發者來看小元件的話，總感覺腦子裡浮現兩個字：
雞肋
。
正所謂食之無味棄之可惜，看小元件的時候也總是覺得缺少靈魂，沒有做到真正的實用。在 iOS 14 上面的變化也一樣，對於一部分簡單的小元件來說可能是個好事，但卻直接殺死了另外一批開發者現有的成果，同時也剝奪了使用者現有的體驗。
當然了，希望這番話可以被 iOS 14 上出彩的第三方小元件打臉，很期待看到開發者們的創造。
全文完。
