作者 ｜ Derek Yang，攜程資深研發(fā)經(jīng)理，專注于iOS開發(fā)&跨端技術(shù)研究，熱衷于新技術(shù)探索。

一、前言

2020年9月蘋果發(fā)布了iOS 14.0，相較之前有了很大的功能改觀，很重要的一點(diǎn)是用戶可以更加個(gè)性化的定義自己的桌面，Widget就是這項(xiàng)功能的主角。

近期接到一項(xiàng)產(chǎn)品需求，需要實(shí)現(xiàn)若干機(jī)票業(yè)務(wù)相關(guān)的Widget，此文總結(jié)該需求開發(fā)上線過程中的踩坑填坑經(jīng)驗(yàn)。

Widget俗稱小組件，是蘋果推出的眾多App Extension中的一款。因此在介紹Widget之前，需要先了解App Extension及其工作原理。

二、App Extension簡(jiǎn)介

iOS 8.0開始，就支持了App Extension的開發(fā)來滿足豐富App的需要。

2.1 什么是App Extension?

App Extension顧名思義是應(yīng)用擴(kuò)展。所以它不是一個(gè)應(yīng)用程序，而是實(shí)現(xiàn)一個(gè)特定的、范圍明確的自定義任務(wù)。

這個(gè)任務(wù)由開發(fā)人員自定義，并遵循系統(tǒng)規(guī)范的擴(kuò)展策略，在用戶與其他應(yīng)用或者系統(tǒng)交互時(shí)將其提供給用戶。

App Extension編譯后是一個(gè)后綴名為.appex的二進(jìn)制文件，無法獨(dú)立分發(fā)和安裝，必須依附于App。

一個(gè) App 可以掛載多個(gè)種類的App Extension。截止目前為止，蘋果已經(jīng)陸續(xù)推出33款A(yù)pp Extension，常見的有照片編輯(Photo Editing)、共享(Share)、自定義鍵盤(Custom Keyboard)，小組件(Widget)。如下圖：

2.2 App Extension工作原理

App Extension的生命周期與常規(guī)App不同，需要一個(gè)包含Extension的App(Containing App)，以及喚起Extension的App(Host App)。

當(dāng)用戶通過Host App喚起Extension時(shí)，系統(tǒng)實(shí)例化Extension，從此Extension的生命周期開始，Extension開始執(zhí)行自己的任務(wù)。之后當(dāng)任務(wù)執(zhí)行結(jié)束或者用戶通過Host app結(jié)束任務(wù)時(shí)，或者系統(tǒng)由于某種原因?qū)⑵溥M(jìn)程結(jié)束，Extension的生命周期到此結(jié)束。

官方簡(jiǎn)介圖：

Extension、Containing App和Host App三者之間的通信關(guān)系，如下官網(wǎng)圖示：

由圖可知App Extension與Host App可以直接通信，而App Extension和Containing App之間并不直接通信。

這樣設(shè)計(jì)可以保證App Extension在運(yùn)行時(shí)與Containing App隔離，不依賴于App，甚至在Extension在運(yùn)行時(shí)，Containing App都不會(huì)主動(dòng)運(yùn)行，Containing App和Host App兩者間沒有通信。

但是在實(shí)際應(yīng)用場(chǎng)景中，仍然會(huì)有和Containing App通信的需求，這里系統(tǒng)給出的方案是在兩者之間使用共有存儲(chǔ)來解決數(shù)據(jù)通信的問題，App Extension需要打開Containing App 并附帶一些參數(shù)，則可以通過Open Url的方式來實(shí)現(xiàn)。

如下官方圖示說明：

詳細(xì)的數(shù)據(jù)共享方式將在后續(xù)Widget的篇幅中詳細(xì)介紹。初步了解App Extension后，接下來詳細(xì)分析Widget。

三、Widget簡(jiǎn)介

Widget是能添加到用戶桌面或者在“今日視圖"中獨(dú)立運(yùn)行的程序。

Widget前身是Today Extension，其在iOS 8.0第一次推出，在iOS 14.0被廢棄，Widget于iOS 14.0推出。實(shí)際兩者有較大的區(qū)別：

外觀上Today Extension只能添加到負(fù)一屏，只有展開和收起兩種尺寸，開發(fā)人員可以自定義這部分區(qū)域的布局大小。Widget不僅可以添加到負(fù)一屏，還可以添加到桌面，和App并列，同時(shí)支持三種樣式(小:2x2、中:4x2、大:4x4)，這三種樣式不支持自定義尺寸。

Widget開發(fā)使用蘋果新推出的WidgetKit，UI開發(fā)只能使用SwiftUI，而Today Extension則使用UIKit。因此進(jìn)行Widget開發(fā)，需要Swift和SwiftUI的技術(shù)知識(shí)。

Xcode12不再提供Today Extension的添加，對(duì)于已有Today Extension的App，系統(tǒng)仍然在負(fù)一屏保留的區(qū)域展示，并且不能像Widget一樣隨意拖動(dòng)移動(dòng)位置和刪除等操作，僅保留最初的規(guī)則

小中大三種樣式的展示效果：

圓角為系統(tǒng)自帶

三種尺寸在不同設(shè)備上的實(shí)際渲染尺寸，如下官網(wǎng)數(shù)據(jù)截圖：

iPhone

iPad

機(jī)票當(dāng)前需求僅需支持小卡、中卡兩種樣式。

四、Widget的開發(fā)框架簡(jiǎn)介

4.1 單/多個(gè)widget配置

單個(gè)和多個(gè)Widget在實(shí)際代碼中的入口不同。

單個(gè) widget 需要實(shí)現(xiàn) Widget protocol

@main
struct Widget1: Widget {
    let kind: String = "widgetTag"
    var body: some WidgetConfiguration {
        ...
    }
}

多個(gè) Widget 需要實(shí)現(xiàn) WidgetBundle protocol

@main
struct TripWidgets: WidgetBundle {
    @WidgetBundleBuilder
    var body: some Widget {
        Widget1()
        Widget2()
        Widget3()
        ...
    }
}

Widget的添加操作需要用戶在系統(tǒng)添加小組件頁(yè)面進(jìn)行，該頁(yè)面會(huì)展示一些簡(jiǎn)單信息供用戶查看。

展示信息的具體配置如下：

struct Widget1: Widget {
    let kind: String = "widgetTag"
    var body: some WidgetConfiguration {
        StaticConfiguration(kind: kind, provider: Provider()) { entry in
            Widget1View(entry: entry)
        }
        .configurationDisplayName("旅行靈感")
        .description("下段旅程，即刻啟程")
        .supportedFamilies([WidgetFamily.systemSmall,WidgetFamily.systemMedium])
    }
}

4.2 Widget整體結(jié)構(gòu)

1)每個(gè)Widget都需要返回一個(gè)WidgetConfiguration，分為兩種：

• 可編輯的小組件 IntentConfiguration
• 不可編輯 StaticConfiguration2) 每個(gè)WidgetConfiguration都需要一個(gè)Provider和一個(gè)ViewContent。

Provider用于做數(shù)據(jù)層刷新，主要有三個(gè)function：

• placeholder (用于返回默認(rèn)展示的數(shù)據(jù)Model)
• getSnapshot(用于渲染呼出添加小組件時(shí)的UI展示)
• getTimeline(用于添加到用戶桌面后的數(shù)據(jù)和UI刷新)

ViewContent用于UI展示，分三種大?。?x2(Small)、4x2(Medium)、4x4(Large)

API整體架構(gòu)串聯(lián)圖：

4.3 Widget刷新策略

由于Widget是用戶添加到用戶桌面的，刷新也需要系統(tǒng)管理，系統(tǒng)為此定義了一個(gè)刷新規(guī)則。通過Provider的getTimeline來實(shí)現(xiàn)，基本原理是給系統(tǒng)提交一組未來時(shí)間內(nèi)用于刷新UI的數(shù)據(jù)，每個(gè)數(shù)據(jù)與時(shí)間綁定，然后系統(tǒng)根據(jù)時(shí)間點(diǎn)，將預(yù)設(shè)的數(shù)據(jù)渲染給到用戶。

Provider定義如下：

public protocol TimelineProvider {
    associatedtype Entry : TimelineEntry
    typealias Context = TimelineProviderContext
    func placeholder(in context: Self.Context) -> Self.Entry
    func getSnapshot(in context: Self.Context, completion: @escaping (Self.Entry) -> Void)
    func getTimeline(in context: Self.Context, completion: @escaping (Timeline<Self.Entry>) -> Void)
}

Timeline結(jié)構(gòu)如下:

public struct Timeline<EntryType> where EntryType : TimelineEntry {

    public let entries: [EntryType]

    public let policy: TimelineReloadPolicy
  
    public init(entries: [EntryType], policy: TimelineReloadPolicy)
}

構(gòu)建Timeline的參數(shù)

entries: [EntryType] 做數(shù)據(jù)和時(shí)間綁定，自定義的數(shù)據(jù)實(shí)體需要遵守TimelineEntry的協(xié)議。

TimelineEntry的具體實(shí)現(xiàn)均需要一個(gè)date和一個(gè)數(shù)據(jù)。

TimelineEntry定義如下：

public protocol TimelineEntry {
    var date: Date { get }
    var relevance: TimelineEntryRelevance? { get }
}

policy: TimelineReloadPolicy 刷新策略

TimelineReloadPolicy是負(fù)責(zé)決定下一次更新策略的配置對(duì)象。

系統(tǒng)通過Provider的getTimeline來做數(shù)據(jù)刷新操作的回調(diào)，開發(fā)者在此方法中將獲取的數(shù)據(jù)提交封裝成TimelineEntry，并加上Timeline的刷新策略提交給系統(tǒng)，最終實(shí)現(xiàn)刷新。

此處刷新策略，系統(tǒng)給出了下面三種方式：

1)atEnd，按照entries中給到的所有日期和數(shù)據(jù)執(zhí)行刷新操作后，再一次調(diào)用getTimeline來更新刷新策略。

2)after，用于指定未來的一個(gè)時(shí)間，調(diào)用getTimeline就更新刷新策略。

3)never，添加之后執(zhí)行一次后，不再執(zhí)行做策略刷新。

4.4 App和Widget關(guān)聯(lián)&互操作

1)Widget和App的數(shù)據(jù)關(guān)聯(lián)，遵循App Extension的規(guī)范，系統(tǒng)提供了NSUserDefaults和NSFileManger兩種方式來做數(shù)據(jù)共享。前提都需要開啟App Groups的功能。

NSUserDefaults方式

//存
NSUserDefaults *userDefaults = [[NSUserDefaults alloc] initWithSuiteName:@"group.xxx.xxx.xx"];
[userDefaults setObject:@"test_content" forKey:@"test"];
[userDefaults synchronize];
//取
NSUserDefaults *userDefaults = [[NSUserDefaults alloc] initWithSuiteName:@"group.xxx.xxx.xx"];
NSString *content = [userDefaults objectForKey:@"test"];

NSFileManger

// 存
NSURL *containerURL = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:@"group.xxx.xxx.xx"];
containerURL = [containerURL URLByAppendingPathComponent:@"testfile"];
[data writeToURL:containerURL atomically:YES];

//取
NSURL *containerURL = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:@"group.xxx.xxx.xx"];
containerURL = [containerURL URLByAppendingPathComponent:@"testfile"];
NSData *value = [NSData dataWithContentsOfURL:containerURL];

2)App的信息改變主動(dòng)刷新Widget，系統(tǒng)提供了如下方式實(shí)現(xiàn)：

WidgetCenter.shared.reloadTimelines(ofKind: "widgetTag")

3)Widget喚醒App

以Unviersal Links /URL Schema跳轉(zhuǎn)，控件采用如下兩種配置即可實(shí)現(xiàn)：

• widgetURL(小卡只支持整個(gè)區(qū)域的點(diǎn)擊)
• Link(小卡不支持，中卡和大卡可以支持局部區(qū)域的跳轉(zhuǎn))

卡片打開會(huì)調(diào)用App的如下生命周期方法，如需跳轉(zhuǎn)到具體頁(yè)面此處做路由即可。

func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    //URLContexts.first?.url.absoluteString
    ....
}

五、項(xiàng)目開發(fā)經(jīng)驗(yàn)總結(jié)

總體來講按照官方開發(fā)文檔就能快速實(shí)現(xiàn)一個(gè)Widget，但是實(shí)際開發(fā)中總會(huì)遇到一些限制和問題。下面是我們?cè)陧?xiàng)目開發(fā)中遇到的一些問題和限制的總結(jié)。

5.1 Widget的數(shù)量限制

官方文檔表明每個(gè)App最多配置5種Widget，可以是App添加多個(gè)WidgetExtension的target，也可以是一個(gè)WidgetExtension的target中添加多種Widget，每種Widget最多支持三種樣式：systemSmall,systemMedium,systemLarge，總共最多可添加15種Widget到桌面。

每種Widget可以被添加多次，這個(gè)取決于用戶的操作。(實(shí)測(cè)本地模擬器環(huán)境可超過5種，實(shí)際發(fā)布上線未驗(yàn)證)

5.2 不是所有的SwiftUI組件都可用

WidgetKit限制Widget UI需由SwiftUI實(shí)現(xiàn)，但并不是所有SwiftUI的組件都可供Widget使用。如果遇到不支持的組件，WidgetKit渲染時(shí)會(huì)忽略。

具體可使用的組件參見官方文檔。

5.3 圖片加載問題

由于系統(tǒng)提供的機(jī)制是需要提前預(yù)設(shè)數(shù)據(jù)，我們最初嘗試用像App一樣的方式去加載圖片控件，結(jié)果發(fā)現(xiàn)圖片并不加載。原因是這里不能做異步，需要同步獲取Image。

另外此處圖片不易過大，也會(huì)影響加載，具體size取決于當(dāng)時(shí)系統(tǒng)的處理能力。(實(shí)測(cè)遇到200k的圖片無法加載的情況)

5.4 Widget點(diǎn)擊事件

小卡只支持widgetURL，整個(gè)卡片區(qū)域只能做一個(gè)事件響應(yīng)。中卡和大卡可支持Link，可支持多個(gè)區(qū)域的點(diǎn)擊。點(diǎn)擊未設(shè)置widgetURL和Link的區(qū)域，都會(huì)默認(rèn)喚起Containing App。

點(diǎn)擊Widget的Widget和Link方式，只能打開主Containing App，即使URL維護(hù)的是其他App的Schema，也是無法打開其他App的。

5.5 代碼共享注意點(diǎn)

官方介紹在共享代碼時(shí)強(qiáng)調(diào)引入的API必須是AppExtension支持的，否則在審核時(shí)會(huì)被拒。

• SharedApplication的相關(guān)API
• 帶有NS_EXTENSION_UNAVAILABLE標(biāo)記的(iOS 8.0中的HealthKit、EventKit UI)
• 訪問攝像頭/麥克風(fēng)(iMessage除外)
• 執(zhí)行長(zhǎng)時(shí)間的后臺(tái)任務(wù)
• 用AirDrop接受數(shù)據(jù)(可發(fā)送數(shù)據(jù))

具體參見 Using an Embedded Framework to Share Code

5.6 刷新次數(shù)的限制

雖然系統(tǒng)給出了這些刷新方案，但是在實(shí)際運(yùn)行時(shí)次數(shù)上會(huì)有一定的限制和出入。

• 策略刷新頻率至少相隔5分鐘(少于這個(gè)間隔可能會(huì)不準(zhǔn)確，刷新機(jī)制雖然提供了API支持，但是實(shí)際刷新還是由系統(tǒng)掌控，并不是你添加的每次刷新都能準(zhǔn)確的奏效)。
• 系統(tǒng)為了減負(fù)，在這個(gè)基礎(chǔ)上做了一層機(jī)器學(xué)習(xí)，實(shí)際的刷新會(huì)根據(jù)用戶手機(jī)上小組件的可見頻率時(shí)間、上次重新加載的時(shí)間以及主app的活動(dòng)狀態(tài)做動(dòng)態(tài)分配。

5.7 系統(tǒng)主動(dòng)刷新機(jī)制

同時(shí)系統(tǒng)以下這些行為導(dǎo)致的刷新，將不會(huì)被統(tǒng)計(jì)到到刷新次數(shù)中：

• Widget對(duì)應(yīng)的應(yīng)用程序在前臺(tái)
• Widget對(duì)應(yīng)的應(yīng)用程序具有活動(dòng)的音頻或?qū)Ш綍?huì)話
• 手機(jī)系統(tǒng)區(qū)域更改
• 動(dòng)態(tài)類型或輔助功能設(shè)置更改

5.8 Size問題

Widget最終編譯為后綴名為.appex的二進(jìn)制文件，這一點(diǎn)同AppExtension一樣，并在ipa內(nèi)部，故size和主App共享。

5.9 熱修復(fù)問題

暫無熱修方案，故需要做好上線的測(cè)試以及兜底邏輯的處理。