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

當(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 的未來還是很值得期待的。

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

我們能做什么

Watch app 架構(gòu)

首先需要明確的是，在 iOS 系統(tǒng)上，app 本體是核心。所有的運(yùn)行實(shí)體都是依托在本體上的：在 iOS 8 之前這是毋庸置疑的，而在 iOS 8 中添加的各種 Extension 也必須隨￥同 app 本體捆綁，作為 app 的功能的補(bǔ)充。Watch app 雖然也類似于此，我們要針對(duì) 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 并沒有像對(duì) iPhone Extension 那樣明確要求針對(duì) 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 檢測(cè)有沒有配對(duì)的 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)該對(duì)應(yīng)手表上的一個(gè)整屏內(nèi)容。但是需要記住整個(gè) WatchKit 是獨(dú)立于 UIKit 而存在的，WKInterfaceController 是一個(gè)直接繼承自 NSObject 的類，并沒有像 UIKit 中 UIResponser 那樣的對(duì)用戶交互的響應(yīng)功能和完備的回調(diào)。

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

我們一般在 -initWithContext: 和 -willActivate 中配置“視圖元素”的屬性，在 -didDeactivate 中停用像是 NSTimer 之類的會(huì) hold 住 self 的對(duì)象。需要特別注意的是，在 -didDeactivate 中對(duì)“視圖元素”屬性進(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)該對(duì)應(yīng) UIView，但其實(shí)上并非如此。WKInterfaceObject 只是 WatchKit 的實(shí)際的 View 的一個(gè)在 Watch Extension 端的代理，而非 View 本身。Watch App 中實(shí)際展現(xiàn)和渲染在屏幕上的 view 對(duì)于代碼來說是非直接可見的，我們只能在 Extension target 中通過對(duì)應(yīng)的代理對(duì)象對(duì)屬性進(jìn)行設(shè)置，然后在每個(gè) run loop 需要刷新 UI 時(shí)由 WatchKit 將新的屬性值從手機(jī)中傳遞給手表中的 Watch App 并進(jìn)行界面刷新。

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

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

另外值得一提的是，隨著 WatchKit 的出現(xiàn)及其開發(fā)方式的轉(zhuǎn)變，代碼寫 UI 還是使用 StoryBoard 這個(gè)爭(zhēng)論了多年的話題可以暫時(shí)落下帷幕了。針對(duì) Watch 的開發(fā)不能使用代碼的方式。首先，所有的 WKInterfaceObject 對(duì)象都必須要設(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 子類都很直接簡(jiǎn)單，但是有兩個(gè)我想要單獨(dú)說一說，那就是 WKInterfaceTable 和WKInterfaceMenu。UITableView 大家都很熟悉了，在 WatchKit 中的 WKInterfaceTable 雖然也是用來展示一組數(shù)據(jù)，但是因?yàn)?WatchKit API 的數(shù)據(jù)傳輸?shù)奶攸c(diǎn)，使用上相較 UITableView 有很大不同和簡(jiǎn)化。首先不存在 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 對(duì)其進(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) 
            } 
        } 
    } 
} 

對(duì)于點(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è)界面對(duì)應(yīng)的 Context Menu。這個(gè)菜單最多可以提供四個(gè)按鈕，用來針對(duì)當(dāng)前環(huán)境向用戶征詢操作。因?yàn)槭直砥聊挥邢?，在信息顯示的同時(shí)再放一些交互按鈕是挺不現(xiàn)實(shí)的一件事情，也會(huì)很丑。而上下文菜單很好地解決了這個(gè)問題，相信長按呼出交互菜單這個(gè)操作會(huì)成為今后 Watch App 的一個(gè)很標(biāo)準(zhǔn)的交互操作。

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

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

但是 Menu 和 MenuItem 對(duì)應(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è)我想不必太多解釋，對(duì)于***個(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 形式，對(duì)應(yīng) API 是 -presentControllerWithName:context: 和 -dismissController。對(duì)于這種導(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)航所提供的功能相對(duì)應(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 對(duì)象。而對(duì)于 WatchKit 來說，***實(shí)踐是將圖片存放在 Watch App 的 target 中 (也就是 StoryBoard 的那個(gè) target)，在對(duì) WKInterfaceImage 進(jìn)行圖像設(shè)置時(shí)，盡量使用它的 -setImageNamed: 方法。這個(gè)方法將只會(huì)把圖像名字通過手機(jī)傳遞到手表，然后由手表在自己的 bundle 中尋找圖片并加載，是最快的途徑。注意我們的代碼是運(yùn)行在于手表的 Watch App 不同的設(shè)備上的，雖然我們也可以先通過UIImage 的相關(guān)方法生成 UIImage 對(duì)象，然后再用 -setImage: 或者 -setImageData: 來設(shè)置手表上的圖片，但是這樣的話我們就需要將圖片放到 Extension 的 target 中，并且需要將圖片的數(shù)據(jù)通過藍(lán)牙傳到手表，一般來說這會(huì)造成不可忽視的延遲，會(huì)很影響體驗(yàn)。

如果對(duì)于某些情況下，我們只能在 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ù)開始刪除，以騰出空間存儲(chǔ)新的數(shù)據(jù)。

動(dòng)畫

因?yàn)闊o法拿到實(shí)際的視圖元素，只有 WKInterfaceObject 這樣的代理對(duì)象，以及布局系統(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)畫，但是對(duì)于設(shè)備的存儲(chǔ)空間和能耗都可能會(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)下降。另外大部分后臺(tái)運(yùn)行權(quán)限也是不建議的。

對(duì)于要獲取這些數(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ì)使代碼測(cè)試和品質(zhì)得到提升。如果還沒有進(jìn)行邏輯部分的框架化和測(cè)試分離的話，在實(shí)現(xiàn)像各類 Extension 或者 Watch App 時(shí)可能會(huì)遇到非常多的麻煩。

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

Glance 和 Notification

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

Glance 是 WatchKit 的新概念，它允許 Watch App 展示一個(gè)布局固定的 WKInterfaceController 頁面。它和 Watch App 本體相對(duì)地位相當(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)還不是很明確，猜測(cè)是某種類似 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 的制作。如果希望請(qǐng)求數(shù)據(jù)，還是不得不轉(zhuǎn)向使用 HealthKit。但是隨著 iPhone 6 和 6s 的大屏化，在運(yùn)動(dòng)時(shí)攜帶 iPhone 的人可以說是變少了。如果 Watch 不能在沒有 iPhone 配對(duì)的情況下收集記錄，并在之后和 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è)層級(jí)，從這個(gè)角度來說，現(xiàn)在的 WatchKit 還遠(yuǎn)沒達(dá)到可以顛覆移動(dòng)應(yīng)用的地步。

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

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