隨著今天凌晨 Apple 發(fā)布了***版的 Watch Kit 的 API，對于開發(fā)者來說，這款新設(shè)備的一些更詳細(xì)的信息也算是逐漸浮出水面?？梢哉f***版的 WatchKit 開放的功能總體還是令人滿意的。Apple 在承諾逐漸開放的方向上繼續(xù)前進(jìn)。本來在 WWDC 之后預(yù)期 Today Widget 會(huì)是各類新穎 app 的舞臺以及對 iOS 功能的極大擴(kuò)展，但是隨著像 Launcher 和 PCalc 這些創(chuàng)意型的 Today Widget 接連被下架事件，讓開發(fā)者也不得不下調(diào)對 WatchKit 的預(yù)期。但是至少從現(xiàn)在的資料來看，WatchKit 是允許進(jìn)行復(fù)雜交互以及完成一些獨(dú)立功能的。雖然需要依托于 iPhone app，但是至少能夠發(fā)揮的舞臺和空間要比我原先想象的大不少。

當(dāng)然，因?yàn)樵O(shè)備本身的無論是電量還是運(yùn)算能力的限制，在進(jìn)行 Watch app 開發(fā)的時(shí)候也還是有很多掣肘?，F(xiàn)在 Watch app 僅僅只是作為視圖顯示和回傳用戶交互的存在，但是考慮到這是這款設(shè)備的***版 SDK，另外 Apple 也有承諾之后會(huì)允許真正運(yùn)行在 Watch 上的 app 的出現(xiàn)，Apple Watch 和 WatchKit 的未來還是很值得期待的。

廢話不再多，我們來簡單看看 WatchKit 的一些基本信息吧。

我們能做什么

Watch app 架構(gòu)

首先需要明確的是，在 iOS 系統(tǒng)上，app 本體是核心。所有的運(yùn)行實(shí)體都是依托在本體上的：在 iOS 8 之前這是毋庸置疑的，而在 iOS 8 中添加的各種 Extension 也必須隨￥同 app 本體捆綁，作為 app 的功能的補(bǔ)充。Watch app 雖然也類似于此，我們要針對 Apple Watch 進(jìn)行開發(fā)，首先還是需要建立一個(gè)傳統(tǒng)的 iOS app，然后在其中添加 Watch App 的 target。在添加之后，會(huì)發(fā)現(xiàn)項(xiàng)目中多出兩個(gè) target：其中一個(gè)是 WatchKit 的擴(kuò)展，另一個(gè)是 Watch App。在項(xiàng)目相應(yīng)的 group 下可以看到，WatchKit Extension 中含有代碼 (InterfaceController.h/m 等)，而 Watch App 里只包含了 Interface.storyboard。不過暫時(shí)看來的好消息是 Apple 并沒有像對 iPhone Extension 那樣明確要求針對 Watch 開發(fā)的 app 必須還是以 iOS app 為核心。也就是說，將 iOS app 空殼化而專注提供 Watch 的 UI 和體驗(yàn)也許是被允許的。

在應(yīng)用安裝時(shí)，負(fù)責(zé)邏輯部分的 WatchKit Extension 將隨 iOS app 的主 target 被一同安裝到 iPhone 中，而負(fù)責(zé)界面部分的 WatchKit App 將會(huì)在主程序安裝后由 iPhone 檢測有沒有配對的 Apple Watch，并提示安裝到 Apple Watch 中。所以在實(shí)際使用時(shí)，所有的運(yùn)算、邏輯以及控制實(shí)際上都是在 iPhone 中完成的。在需要界面刷新時(shí)，由 iPhone 向 Watch 發(fā)送指令進(jìn)行描畫并在手表盤面上顯示。反過來，用戶觸摸手表交互時(shí)的信息也由手表傳回給 iPhone 并進(jìn)行處理。而這個(gè)過程 WatchKit 會(huì)在幕后為我們完成，并不需要開發(fā)者操心。我們需要知道的就是，原則上來說，我們應(yīng)該將界面相關(guān)的內(nèi)容放在 Watch App 的 target 中，而將所有代碼邏輯等放到 Extension 里。

在手表上點(diǎn)擊 app 圖標(biāo)運(yùn)行 Watch App 時(shí)，手表將會(huì)負(fù)責(zé)喚醒手機(jī)上的 WatchKit Extension。而 WatchKit Extension 和 iOS app 之間的數(shù)據(jù)交互需求則由 App Groups 來完成，這和 Today Widget 以及其他一些 Extension 是一樣的。如果你還沒有了解過相關(guān)內(nèi)容，可以參看我之前寫過的一篇 Today Extension 的教程。

主要類

WKInterfaceController 和生命周期

WKInterfaceController 是 WatchKit 中的 UIViewController 一樣的存在，也會(huì)是開發(fā) Watch App 時(shí)花時(shí)間最多的類。每個(gè)WKInterfaceController 或者其子類應(yīng)該對應(yīng)手表上的一個(gè)整屏內(nèi)容。但是需要記住整個(gè) WatchKit 是獨(dú)立于 UIKit 而存在的，WKInterfaceController 是一個(gè)直接繼承自 NSObject 的類，并沒有像 UIKit 中 UIResponser 那樣的對用戶交互的響應(yīng)功能和完備的回調(diào)。

不僅在功能上相對 UIViewController 簡單很多，在生命周期上也進(jìn)行了大幅簡化。每個(gè) WKInterfaceController 對象必然會(huì)被調(diào)用的生命周期方法有三個(gè)，分別是該對象被初始化時(shí)的 -initWithContext:，將要呈現(xiàn)時(shí)的 -willActivate 以及呈現(xiàn)結(jié)束后的-didDeactivate。同樣類比 UIViewController 的話，可以將它們理解為分別對應(yīng) -viewDidLoad，viewWillAppear: 以及 -viewDidDisappear:。雖然看方法名和實(shí)際使用上可能你會(huì)認(rèn)為 -initWithContext: 應(yīng)該對應(yīng) UIViewController 的 init 或者initWithCoder: 這樣的方法，但是事實(shí)上在 -initWithContext: 時(shí) WKInterfaceController 中的“視圖元素” (請注意這里我加上了引號，因?yàn)樗鼈儾皇钦嬲囊晥D，稍后會(huì)再說明) 都已經(jīng)初始化完畢可用，這其實(shí)和 -viewDidLoad 中的行為更加相似。

我們一般在 -initWithContext: 和 -willActivate 中配置“視圖元素”的屬性，在 -didDeactivate 中停用像是 NSTimer 之類的會(huì) hold 住 self 的對象。需要特別注意的是，在 -didDeactivate 中對“視圖元素”屬性進(jìn)行設(shè)置是無效的，因?yàn)楫?dāng)前的WKInterfaceController 已經(jīng)非活躍。

WKInterfaceObject 及其子類

WKInterfaceObject 負(fù)責(zé)具體的界面元素設(shè)置，包括像是 WKInterfaceButton，WKInterfaceLabel 或 WKInterfaceImage 這類物件，也就是我們上面所提到的“視圖元素”?？赡芤婚_始會(huì)產(chǎn)生錯(cuò)覺，覺得 WKInterfaceObject 應(yīng)該對應(yīng) UIView，但其實(shí)上并非如此。WKInterfaceObject 只是 WatchKit 的實(shí)際的 View 的一個(gè)在 Watch Extension 端的代理，而非 View 本身。Watch App 中實(shí)際展現(xiàn)和渲染在屏幕上的 view 對于代碼來說是非直接可見的，我們只能在 Extension target 中通過對應(yīng)的代理對象對屬性進(jìn)行設(shè)置，然后在每個(gè) run loop 需要刷新 UI 時(shí)由 WatchKit 將新的屬性值從手機(jī)中傳遞給手表中的 Watch App 并進(jìn)行界面刷新。

反過來，手表中的實(shí)際的 view 想要將用戶交互事件傳遞給 iPhone 也需要通過 WKInterfaceObject 代理進(jìn)行。每個(gè)可交互的WKInterfaceObject 子類都對應(yīng)了一個(gè) action，比如 button 對應(yīng)點(diǎn)擊事件，switch 對應(yīng)開或者關(guān)的狀態(tài)，slider 對應(yīng)一個(gè)浮點(diǎn)數(shù)值表明選取值等等。關(guān)聯(lián)這些事件也很簡單，直接從 StoryBoard 文件中 Ctrl 拖拽到實(shí)現(xiàn)中就能生成對應(yīng)的事件了。雖然 UI 資源文件和代碼實(shí)現(xiàn)是在不同的 target 中的，但是在 Xcode 中的協(xié)作已然天衣無縫。

Watch App 采取的布局方式和 iOS app 完全不同。你無法自由指定某個(gè)視圖的具體坐標(biāo)，當(dāng)然也不能使用像 AutoLayout 或者 Size Classes 這樣的靈活的界面布局方案。WatchKit 提供的布局可能性和靈活性相對較小，你只能在以“行”為基本單位的同時(shí)通過 group 來在行內(nèi)進(jìn)行“列”布局。這帶來了相對簡單的布局實(shí)現(xiàn)，當(dāng)然，同時(shí)也是對界面交互的設(shè)計(jì)的一種挑戰(zhàn)。

另外值得一提的是，隨著 WatchKit 的出現(xiàn)及其開發(fā)方式的轉(zhuǎn)變，代碼寫 UI 還是使用 StoryBoard 這個(gè)爭論了多年的話題可以暫時(shí)落下帷幕了。針對 Watch 的開發(fā)不能使用代碼的方式。首先，所有的 WKInterfaceObject 對象都必須要設(shè)計(jì)的時(shí)候經(jīng)由 StoryBoard 進(jìn)行添加，運(yùn)行時(shí)我們無法再向界面上添加或者移除元素 (如果有移除需要的，可以使用隱藏)；其次WKInterfaceObject 與布局相關(guān)的某些屬性，比如行高行數(shù)等，不能夠在運(yùn)行時(shí)進(jìn)行變更和設(shè)定?；緛碚f在運(yùn)行時(shí)我們只能夠改變視圖的內(nèi)容，以及通過隱藏某些視圖元素來達(dá)到有限地改變布局 (其他視圖元素會(huì)試圖填充被隱藏的元素)。

總之，代碼進(jìn)行 UI 編寫的傳統(tǒng)，在 Apple 的不斷努力下，于 WatchKit 發(fā)布的今天，被正式宣判了死刑。

Table 和 Context Menu

大部分 WKInterfaceObject 子類都很直接簡單，但是有兩個(gè)我想要單獨(dú)說一說，那就是 WKInterfaceTable 和WKInterfaceMenu。UITableView 大家都很熟悉了，在 WatchKit 中的 WKInterfaceTable 雖然也是用來展示一組數(shù)據(jù)，但是因?yàn)?WatchKit API 的數(shù)據(jù)傳輸?shù)奶攸c(diǎn)，使用上相較 UITableView 有很大不同和簡化。首先不存在 DataSource 和 Delegate，WKInterfaceTable 中需要呈現(xiàn)的數(shù)據(jù)數(shù)量直接由其實(shí)例方法 -setNumberOfRows:withRowType: 進(jìn)行設(shè)定。在進(jìn)行設(shè)定后，使用 -rowControllerAtIndex: 枚舉所有的 rowController 進(jìn)行設(shè)定。這里的 rowController 是在 StoryBoard 中所設(shè)定的相當(dāng)于 UITableViewCell 的東西，只不過和其他 WKInterfaceObject 一樣，它是直接繼承自 NSObject 的。你可以通過自定義 rowController 并連接 StoryBoard 的元素，并在取得 rowController 對其進(jìn)行設(shè)定，即可完成 table 的顯示。代碼大概是這樣的：

//  MyRowController.swift 
import Foundation   
import WatchKit 
class MyRowController: NSObject {   
    @IBOutlet weak var label: WKInterfaceLabel! 
} 
//  InterfaceController.swift 
import WatchKit   
import Foundation 
class InterfaceController: WKInterfaceController { 
    @IBOutlet weak var table: WKInterfaceTable! 
    let data = ["Index 0","Index 1","Index 2"] 
    override init(context: AnyObject?) { 
        // Initialize variables here. 
        super.init(context: context) 
        // Configure interface objects here. 
        NSLog("%@ init", self) 
        // 注意需要在 StoryBoard 中設(shè)置 myRowControllerType 
        // 類似 cell 的 reuse id 
        table.setNumberOfRows(data.count, withRowType: "myRowControllerType") 
        for (i, value) in enumerate(data) { 
            if let rowController = table.rowControllerAtIndex(i) as? MyRowController { 
                rowController.label.setText(value) 
            } 
        } 
    } 
} 

對于點(diǎn)擊事件，并沒有一個(gè)實(shí)際的 delegate 存在，而是類似于其他 WKInterfaceObject 那樣通過 action 將點(diǎn)擊了哪個(gè) row 作為參數(shù)發(fā)送回 WKInterfaceController 進(jìn)行處理

另一個(gè)比較好玩的是 Context Menu，這是 WatchKit 獨(dú)有的交互，在 iOS 中并不存在。在任意一個(gè) WKInterfaceController 界面中，長按手表屏幕，如果當(dāng)前 WKInterfaceController 中存在上下文菜單的話，就會(huì)嘗試呼出找這個(gè)界面對應(yīng)的 Context Menu。這個(gè)菜單最多可以提供四個(gè)按鈕，用來針對當(dāng)前環(huán)境向用戶征詢操作。因?yàn)槭直砥聊挥邢?，在信息顯示的同時(shí)再放一些交互按鈕是挺不現(xiàn)實(shí)的一件事情，也會(huì)很丑。而上下文菜單很好地解決了這個(gè)問題，相信長按呼出交互菜單這個(gè)操作會(huì)成為今后 Watch App 的一個(gè)很標(biāo)準(zhǔn)的交互操作。

添加 Context Menu 非常簡單，在 StoryBoard 里向 WKInterfaceController 中添加一個(gè) Menu，并在這個(gè) Menu 里添加對應(yīng)的 MenuItem 就行了。在 WKInterfaceController 我們也有對應(yīng)的 API 來在運(yùn)行時(shí)根據(jù)上下文環(huán)境進(jìn)行 MenuItem 的添加 (這是少數(shù)幾個(gè)允許我們在運(yùn)行時(shí)添加元素的方法之一)。

-addMenuItemWithItemIcon:title:action: 
-addMenuItemWithImageNamed:title:action: 
-addMenuItemWithImage:title:action: 
-clearAllMenuItems 

但是 Menu 和 MenuItem 對應(yīng)的類 WKInterfaceMenu 和 WKInterfaceMenuItem 我們是沒有辦法拿到的。沒錯(cuò)，它們甚至都沒有存在于文檔里 :(

基礎(chǔ)導(dǎo)航

WKInterfaceController 的內(nèi)建的導(dǎo)航關(guān)系基本上分為三類。首先是像 UINavigationController 控制的類似棧的導(dǎo)航方式。相關(guān)的 API 有 -pushControllerWithName:context:，-popController 以及 -popToRootController。后兩個(gè)我想不必太多解釋，對于***個(gè)方法，我們需要使用目標(biāo) controller 的 Identifier 字符串 (沒有你只能在 StoryBoard 里進(jìn)行設(shè)置) 進(jìn)行創(chuàng)建。context參數(shù)也會(huì)被傳遞到目標(biāo) controller 的 -initWithContext: 中，所以你可以以此來在 controller 中進(jìn)行數(shù)據(jù)傳遞。

另一種是我們大家熟悉的 modal 形式，對應(yīng) API 是 -presentControllerWithName:context: 和 -dismissController。對于這種導(dǎo)航，和 UIKit 中的不同之處就是在目標(biāo) controller 中會(huì)默認(rèn)在左上角加上一個(gè) Cancel 按鈕，點(diǎn)擊的話會(huì)直接關(guān)閉被 present 的 controller。我只想說 Apple 終于想通了，每個(gè) modal 出來的 controller 都是需要關(guān)閉的這個(gè)事實(shí)...

***一種導(dǎo)航方式是類似 UIPageController 的分頁式導(dǎo)航。在 iOS app 中，在應(yīng)用***次開始時(shí)的教學(xué)模塊中這種導(dǎo)航方式非常常見，而在 WatchKit 里可以說得到了發(fā)揚(yáng)光大。事實(shí)上我個(gè)人也認(rèn)為這會(huì)是 WatchKit 里***使用習(xí)慣的導(dǎo)航方式。在 WatchKit 上的 page 導(dǎo)航可能會(huì)和 iOS app 的 Tab 導(dǎo)航所提供的功能相對應(yīng)。

在實(shí)現(xiàn)上，page 導(dǎo)航需要在 StoryBoard 中用 segue 的方式將不同 page 進(jìn)行連接，新添加的 next page segue 就是干這個(gè)的：

另外 modal 導(dǎo)航的另一個(gè) API -presentControllerWithNames:contexts: 接受復(fù)數(shù)個(gè)的 names 和 context，通過這種方式 modal 呼出的復(fù)數(shù)個(gè) Controller 也將以 page 導(dǎo)航方式呈現(xiàn)。

當(dāng)然，作為 StoryBoard 的經(jīng)典使用方式，modal 和 push 的導(dǎo)航方式也是可以在 StoryBoard 中通過 segue 來實(shí)現(xiàn)的。同時(shí) WatchKit 也為 segue 的方式提供了必要的 API。

一些界面實(shí)踐

因?yàn)檎麄€(gè)架構(gòu)和 UIKit 完全不同，所以很多之前的實(shí)踐是無法直接搬到 WatchKit App 中的。

圖像處理

在 UIKit 中我們顯示圖片一般使用 UIImageView，然后為其 image 屬性設(shè)置一個(gè)創(chuàng)建好的 UIImage 對象。而對于 WatchKit 來說，***實(shí)踐是將圖片存放在 Watch App 的 target 中 (也就是 StoryBoard 的那個(gè) target)，在對 WKInterfaceImage 進(jìn)行圖像設(shè)置時(shí)，盡量使用它的 -setImageNamed: 方法。這個(gè)方法將只會(huì)把圖像名字通過手機(jī)傳遞到手表，然后由手表在自己的 bundle 中尋找圖片并加載，是最快的途徑。注意我們的代碼是運(yùn)行在于手表的 Watch App 不同的設(shè)備上的，雖然我們也可以先通過UIImage 的相關(guān)方法生成 UIImage 對象，然后再用 -setImage: 或者 -setImageData: 來設(shè)置手表上的圖片，但是這樣的話我們就需要將圖片放到 Extension 的 target 中，并且需要將圖片的數(shù)據(jù)通過藍(lán)牙傳到手表，一般來說這會(huì)造成不可忽視的延遲，會(huì)很影響體驗(yàn)。

如果對于某些情況下，我們只能在 Extension 的 target 中獲得圖片 (比如從網(wǎng)絡(luò)下載或者代碼動(dòng)態(tài)生成等)，并且需要重復(fù)使用的話，***用 WKInterfaceDevice 的 -addCachedImage:name: 方法將其緩存到手表中。這樣，當(dāng)我們之后再使用這張圖片的時(shí)候就可以直接通過 -setImageNamed: 來快速地從手表上生成并使用了。每個(gè) app 的 cache 的尺寸大約是 20M，超過的話 WatchKit 將會(huì)從最老的數(shù)據(jù)開始刪除，以騰出空間存儲新的數(shù)據(jù)。

動(dòng)畫

因?yàn)闊o法拿到實(shí)際的視圖元素，只有 WKInterfaceObject 這樣的代理對象，以及布局系統(tǒng)的限制，所以復(fù)雜的動(dòng)畫，尤其是UIView 系列或者是 CALayer 系列的動(dòng)畫是無法實(shí)現(xiàn)的?，F(xiàn)在看來唯一可行的是幀動(dòng)畫，通過為 WKInterfaceImage 設(shè)置包含多個(gè) image 的圖像，或者是通過計(jì)時(shí)器定時(shí)替換圖像的話，可以實(shí)現(xiàn)幀動(dòng)畫。雖然 Apple 自己的例子也通過這種方法實(shí)現(xiàn)了動(dòng)畫，但是對于設(shè)備的存儲空間和能耗都可能會(huì)是挑戰(zhàn)，還需要實(shí)際拿到設(shè)備以后進(jìn)行實(shí)驗(yàn)和觀察。

其他 Cocoa Touch 框架的使用

Apple 建議***不要使用那些需要 prompt 用戶許可的特性，比如 CoreLocation 定位等。因?yàn)閷?shí)際的代碼是在手機(jī)上運(yùn)行的，這類許可也會(huì)在手機(jī)上彈出，但是用戶并不一定正好在看手機(jī)，所以很可能造成體驗(yàn)下降。另外大部分后臺運(yùn)行權(quán)限也是不建議的。

對于要獲取這些數(shù)據(jù)和權(quán)限，Apple 建議還是在 iOS app 中完成，并通過 App Groups 進(jìn)行數(shù)據(jù)共享，從而在 Watch Extension 中拿到這些數(shù)據(jù)。

代碼分享

因?yàn)楝F(xiàn)在一個(gè)項(xiàng)目會(huì)有很多不同的 target，所以使用 framework 的方式封裝不同 target 的公用部分的代碼，而只在各 target 中實(shí)現(xiàn)界面相關(guān)的代碼應(yīng)該是必行的了。這么做的優(yōu)點(diǎn)不僅是可以減少代碼重復(fù)，也會(huì)使代碼測試和品質(zhì)得到提升。如果還沒有進(jìn)行邏輯部分的框架化和測試分離的話，在實(shí)現(xiàn)像各類 Extension 或者 Watch App 時(shí)可能會(huì)遇到非常多的麻煩。

因?yàn)槿绻?app 有計(jì)劃進(jìn)行擴(kuò)展推出各種 Extension 的話，將邏輯代碼抽離并封裝為 framework 應(yīng)該是優(yōu)先級***的工作。另外新開的項(xiàng)目如果沒有特殊原因，也強(qiáng)烈建議使用 framework 來組織通用代碼。

Glance 和 Notification

除了 Watch App 本體以外，Glance 和手表的 Notification 也是重要的使用情景。Notification 雖然概念上比較簡單，但是相對于 iOS 的通知來說是天差地別。WatchKit 的通知允許開發(fā)者自行構(gòu)建界面，我們可以通過 payload 設(shè)置比較復(fù)雜和帶有更多信息的通知，包括圖像，大段文字甚至可以交互的按鈕，而不是像 iOS 上那樣被限制在文字和一個(gè)對話框內(nèi)。首先無論是通過 Local 還是 Remote 進(jìn)行的通知發(fā)送會(huì)先到達(dá) iPhone，然后再由 iPhone 根據(jù)內(nèi)容判斷是否轉(zhuǎn)發(fā)到手表。WatchKit App 接收到通知后先會(huì)顯示一個(gè)簡短的通知，告訴用戶這個(gè) app 有一個(gè)通知。如果用戶對通知的內(nèi)容感興趣的話，可以點(diǎn)擊或者抬手觀看，這樣由開發(fā)者自定義的長版本的通知就會(huì)顯現(xiàn)。

Glance 是 WatchKit 的新概念，它允許 Watch App 展示一個(gè)布局固定的 WKInterfaceController 頁面。它和 Watch App 本體相對地位相當(dāng)于 iOS 上的 Today Widget 和 iOS app 本身的地位，是作為手表上的 app 的最重要的信息展示出現(xiàn)的。Glance 正如其名，是短時(shí)存在的提醒，不能存在可交互的元素。不過如果用戶點(diǎn)擊 Glance 頁面的話，是可以啟動(dòng)到 Watch App 的。現(xiàn)在關(guān)于 Glance 本身如何啟動(dòng)和呈現(xiàn)還不是很明確，猜測是某種類似 Today Widget 的呈現(xiàn)方式？(比如按下兩次表側(cè)面的旋鈕)

疑問和改進(jìn)方向

WatchKit 總體令人滿意，提供的 API 和開發(fā)環(huán)境已經(jīng)足夠開發(fā)者作出一些有趣的東西。但是有幾個(gè)現(xiàn)在看來很明顯的限制和希望能加強(qiáng)的方向。

首先是從現(xiàn)在來看 WatchKit 并沒有提供任何獲取設(shè)備傳感信息的 API。不論是心跳、計(jì)步或者是用戶是否正在佩戴 Watch 的信息我們都是拿不到的，這限制了很多數(shù)據(jù)收集和監(jiān)視的健康類 app 的制作。如果希望請求數(shù)據(jù)，還是不得不轉(zhuǎn)向使用 HealthKit。但是隨著 iPhone 6 和 6s 的大屏化，在運(yùn)動(dòng)時(shí)攜帶 iPhone 的人可以說是變少了。如果 Watch 不能在沒有 iPhone 配對的情況下收集記錄，并在之后和 iPhone 連接后將數(shù)據(jù)回傳的話，那 Apple 的健康牌就失敗了一大半。相信 Apple 不會(huì)放過這種把用戶捆綁的機(jī)會(huì)...不過如果第三方應(yīng)用能實(shí)時(shí)獲取用戶的佩戴狀況的話，相信會(huì)有很多有意思的應(yīng)用出現(xiàn)。

另外作為在發(fā)布會(huì)上鼓吹的交互革命的旋鈕和觸感屏幕，現(xiàn)在看來并沒有開放任何 API 供開發(fā)者使用，所以我們無法得知用戶旋轉(zhuǎn)了手表旋鈕這個(gè)重要的交互事件?，F(xiàn)在看來我們能獲取的操作僅只是用戶點(diǎn)擊屏幕上的按鈕或者拖動(dòng)滑條這個(gè)層級，從這個(gè)角度來說，現(xiàn)在的 WatchKit 還遠(yuǎn)沒達(dá)到可以顛覆移動(dòng)應(yīng)用的地步。

希望之后 Apple 會(huì)給我們帶來其他的好消息吧。

總之，舞臺已經(jīng)搭好，之后唱什么戲，就要看我們的了。