物聯(lián)網(wǎng)中的通信 - 即設(shè)備如何向網(wǎng)絡(luò)發(fā)送和接收數(shù)據(jù) - 可以以不同的方式處理，通信方式主要由應(yīng)用層中的協(xié)議來控制。了解數(shù)據(jù)在您服務(wù)中的設(shè)備周圍的流動(dòng)方式可以讓您了解其可能的響應(yīng)以及數(shù)據(jù)在設(shè)備之間的同步速度。

推（push），拉（pull）和輪詢（polling）

作為一名UX（用戶體驗(yàn)）設(shè)計(jì)師，您需要注意的關(guān)鍵因素包括：

?設(shè)備如何將消息傳輸?shù)骄W(wǎng)絡(luò)中：它是定期推送（push）還是滿足某些條件后再推送？還是僅當(dāng)客戶端設(shè)備（如智能手機(jī)應(yīng)用程序）或者服務(wù)請(qǐng)求（pull：拉）它時(shí)才會(huì)傳輸（即）？

?設(shè)備如何從網(wǎng)絡(luò)中接收消息：消息是否是從服務(wù)或者其他設(shè)備推送過來的，還是第一個(gè)設(shè)備根據(jù)需要請(qǐng)求它們接收的？

?設(shè)備連接頻率：它是不斷地持續(xù)連接，還是定期連接的，還是只有當(dāng)它知道它需要連接時(shí)才連接？

?指令或數(shù)據(jù)可能多快通過？這是一個(gè)組合的問題包括以下的問題：

->設(shè)備建立連接需要多長時(shí)間

->連接可能有多快

->需要發(fā)送多少數(shù)據(jù)

->它可以多直接地被路由（任何信息要通過Internet可能需要花更長的時(shí)間）

如圖1的例子所示，說明了您可能會(huì)遇到的一些問題：

電池供電加熱控制器使用ZigBee每?jī)煞昼娐?lián)系其網(wǎng)關(guān)登記注冊(cè)其狀態(tài)信息并尋求新的指令。這種方式稱為輪詢（polling）：控制器不知道什么時(shí)候會(huì)有新的指令，但必須定期地檢查更新。

用戶使用移動(dòng)應(yīng)用程序來加熱使溫度從19°C升高到21°C。該應(yīng)用程序?qū)⒃撝噶顐鬟f給Internet服務(wù)。網(wǎng)關(guān)設(shè)備定期輪詢（polls）Internet服務(wù)并接收指令。 （網(wǎng)關(guān)具有主電源供電，因此可能會(huì)相當(dāng)頻繁地進(jìn)行輪詢，也許每隔幾秒鐘就輪詢一次。）加熱控制器（polls）輪詢網(wǎng)關(guān)并接收指令。

圖1、加熱系統(tǒng)中的輪詢和推送

如果用戶在加熱控制器面前使用移動(dòng)應(yīng)用程序app時(shí)，則可能會(huì)看到控制器花費(fèi)長達(dá)兩分鐘的時(shí)間來響應(yīng)來自移動(dòng)設(shè)備的命令。

在此期間，手機(jī)UI（用戶接口）和控制器顯示器將顯示不同的狀態(tài)信息，并且可能會(huì)不同步。手機(jī)可能會(huì)說是21°C，控制器則可能顯示19°C?？刂破鞣从诚到y(tǒng)當(dāng)前的真實(shí)狀態(tài)。在連貫性方面，這是一個(gè)連續(xù)性問題。

它可以更快地將指令從Internet服務(wù)推送到網(wǎng)關(guān)和設(shè)備中。但這通常不太可能通過家庭路由器來實(shí)現(xiàn)。大多數(shù)路由器向世界呈現(xiàn)的是單個(gè)公共IP地址，并將本地網(wǎng)絡(luò)上的設(shè)備地址保留為私有（這種共享一個(gè)IP地址的技術(shù)稱為NAT：網(wǎng)絡(luò)地址轉(zhuǎn)換（network address translation））。因此，服務(wù)器難以推送（push）到本地家庭網(wǎng)絡(luò)上的設(shè)備或者從本地家庭網(wǎng)絡(luò)上的設(shè)備中拉出（pull）信息。另外，安全防火墻也可能是一個(gè)問題。

所以，設(shè)備必須通過輪詢來檢查新的指令，這可能需要更長的時(shí)間。

如果用戶使用安裝在加熱控制器設(shè)備上的控制來升溫，則延遲可能會(huì)較短?？刂破髦老到y(tǒng)發(fā)生了變化，并通過集線器（hub）將更新信息的消息推送（push）到Internet服務(wù)中。它知道它需要連接，所以它不會(huì)等待計(jì)劃的下一個(gè)輪詢。如果用戶的智能手機(jī)加熱控制應(yīng)用程序打開，那么它可能會(huì)每30秒向服務(wù)請(qǐng)求新的數(shù)據(jù)。所以如果用戶在同一時(shí)間看著他們的智能手機(jī)加熱應(yīng)用程序，他們可能仍然會(huì)觀察到不連續(xù)性，但可能只是一個(gè)短暫的延時(shí)。

智能手機(jī)和加熱控制器正在輪詢互聯(lián)網(wǎng)服務(wù)以進(jìn)行更新，這是一個(gè)拉（pull）的例子。當(dāng)他們知道他們有最新的信息或者命令要分享時(shí)，那么它們兩者都能夠推送消息。

智能手機(jī)和加熱控制器都不會(huì)保持與網(wǎng)絡(luò)的持續(xù)連接，因?yàn)檫@樣會(huì)耗盡電池的電量。但手機(jī)可以比控制器更頻繁地檢查更新，因?yàn)樗碾娫词艿降南拗戚^少。

雖然這種安排確實(shí)會(huì)暴露偶爾的不連續(xù)性，但是對(duì)于加熱系統(tǒng)的應(yīng)用情況，這些不會(huì)是災(zāi)難性的影響。大多數(shù)時(shí)候，用戶不會(huì)拿著智能手機(jī)站在加熱控制器的面前。另外在大多數(shù)時(shí)候，發(fā)出加熱指令和實(shí)際開啟指令之間的兩分鐘延遲滯后并不是一個(gè)問題：加熱器的工作時(shí)間是以小時(shí)為單位的而不是秒。

輪詢時(shí)間間隔太長可能會(huì)使服務(wù)感到反應(yīng)太遲鈍。例如，使用If This Then That（IFTTT）， 當(dāng)有電子郵件從特定收件人傳遞到您的Gmail帳號(hào)上時(shí)Philips Hue bulb可以配置為閃爍或者更改顏色。雖然這是一個(gè)好主意，但是IFTTT只能每15分鐘輪詢一次Gmail（這可能是由Gmail限制的，以避免輪詢太頻繁而導(dǎo)致其服務(wù)器過載）。這意味著在收到電子郵件后15分鐘內(nèi)，燈泡可能不會(huì)響應(yīng)。這是一個(gè)非常不及時(shí)響應(yīng)的通知系統(tǒng)。

如果您希望設(shè)備能夠快速響應(yīng)命令，則要么必須保持打開連接以監(jiān)聽推送的命令，或者更頻繁地進(jìn)行輪詢。給消費(fèi)者推送通知的一個(gè)很好的例子是Google通訊錄（Google Contacts）。如果您使用Web來更新Google聯(lián)系人（Google Contact），則幾秒鐘內(nèi)就會(huì)將更新推送到您的手機(jī)。手機(jī)不經(jīng)常輪詢：它只是收到從Google服務(wù)器發(fā)來的自發(fā)更新通知。

當(dāng)沒有什么新的東西可以分享時(shí)，頻繁的輪詢可能會(huì)導(dǎo)致服務(wù)器過載（以及會(huì)耗盡電池）。維持與許多不同設(shè)備之間的許多開放連接也是不切實(shí)際的。但是，你無法連接到一個(gè)沒有打開連接的設(shè)備上來告訴它進(jìn)行連接。當(dāng)您需要一個(gè)設(shè)備快速響應(yīng)時(shí)，您可能至少需要一個(gè)打開的連接。例如，如果氣體傳感器檢測(cè)到泄漏，則關(guān)閉家庭電源的開關(guān)將立即關(guān)閉。

控制設(shè)備發(fā)送命令的時(shí)間更容易。一個(gè)設(shè)備可以被配置為在滿足某些條件時(shí)向網(wǎng)絡(luò)發(fā)送數(shù)據(jù);例如，加熱時(shí)間表發(fā)生了改變，或者濕度傳感器檢測(cè)地下室中有水。它也可以配置為在某些條件下更頻繁地發(fā)送數(shù)據(jù)。如果一個(gè)檢測(cè)可能的火災(zāi)的熱探測(cè)器僅每2分鐘發(fā)送一次狀態(tài)信息，則可能會(huì)在接下來的20分鐘時(shí)間內(nèi)每隔一秒傳輸一次狀態(tài)信息。如果它不能聯(lián)系到其通常的網(wǎng)絡(luò)網(wǎng)關(guān)時(shí)，那么它可能通過網(wǎng)狀網(wǎng)絡(luò)上的替代節(jié)點(diǎn)來嘗試跳躍通過。使用靜態(tài)IP地址（例如IPv6）和適當(dāng)?shù)膽?yīng)用程序，那么從理論上也可以在緊急情況下嘗試使用相鄰的網(wǎng)絡(luò)。

當(dāng)消息沒有通過時(shí)，設(shè)備也可能需要有提醒用戶的方法。例如老年人的緊急警報(bào)按鈕需要盡可能的可靠，并提供如蜂窩數(shù)據(jù)這樣的備份連接。但是，該按鈕仍然應(yīng)該可以告訴用戶不僅是他們的幫助呼叫是否被發(fā)送出去，而且也要告訴用戶該呼叫是否已經(jīng)被另一端的系統(tǒng)所接收。

UX（用戶體驗(yàn)）的一個(gè)關(guān)鍵考慮是了解數(shù)據(jù)在系統(tǒng)周圍傳遞的速度，以及它是否適合在應(yīng)用的上下文環(huán)境中被使用。例如，用于家庭用電的家庭能源監(jiān)控系統(tǒng)可能會(huì)每隔幾分鐘或者更長時(shí)間將最近24小時(shí)的數(shù)據(jù)上傳到互聯(lián)網(wǎng)服務(wù)中。當(dāng)您請(qǐng)求此信息時(shí)，它將從Internet服務(wù)中發(fā)送過來而不會(huì)直接查詢能量監(jiān)視器。這樣做可能會(huì)更快，和/或降低與您的能源公司連接的蜂窩數(shù)據(jù)的成本。但是，如果您想知道您家的前門是否被鎖緊，那么知道該數(shù)據(jù)是否是2分鐘前的舊數(shù)據(jù)是非常重要的 - 因?yàn)橛腥丝赡茉谄淦陂g已經(jīng)打開它了。

物聯(lián)網(wǎng)（IOT）的應(yīng)用層協(xié)議

應(yīng)用層協(xié)議位于Internet網(wǎng)絡(luò)的最頂層。他們建立計(jì)算機(jī)進(jìn)程的通道來進(jìn)行交流。它們形成設(shè)備通過網(wǎng)絡(luò)并從網(wǎng)絡(luò)中獲取數(shù)據(jù)的連接模式。您的系統(tǒng)使用的應(yīng)用程序協(xié)議的選擇主要是一個(gè)技術(shù)設(shè)計(jì)問題，并不太可能對(duì)UX（用戶體驗(yàn)）產(chǎn)生重大的影響。但是，值得注意的是要留意您聽到的一些可能的選項(xiàng)，并了解您正在處理的系統(tǒng)如何傳遞數(shù)據(jù)的。

IoT應(yīng)用程序通常是使用超文本傳輸協(xié)議（HTTP）通過Internet來進(jìn)行通信的。

HTTP是一種可靠的方式來傳遞圍繞著少量設(shè)備的不需要立即更新的任何更改信息。但是它不是按照推送（ push）或者流式（streaming ）而設(shè)計(jì)的，因此通常需要輪詢。圍繞著很多設(shè)備來傳遞數(shù)據(jù)的也不是最流暢的方法，特別是對(duì)于電源和計(jì)算能力受限制的設(shè)備來說更是如此。它需要在需要共享數(shù)據(jù)的任何設(shè)備（點(diǎn)對(duì)點(diǎn)網(wǎng)絡(luò)，參見圖2）之間建立直接連接，并且消息占用了大量的字節(jié)。

其他協(xié)議，尤其是MQTT協(xié)議，是專為物聯(lián)網(wǎng)而設(shè)計(jì)的。這些優(yōu)先級(jí)更小的數(shù)據(jù)傳輸以及更有效的方式適合用來在低功耗設(shè)備的大型網(wǎng)絡(luò)上傳輸數(shù)據(jù)。MQTT沒有采用直接連接而是使用一種發(fā)布訂閱模型，其中的設(shè)備將數(shù)據(jù)推送到一個(gè)中央消息代理器中。其他設(shè)備可以訂閱他們想要的數(shù)據(jù)源（“主題（topics）”）（見圖2）。這種方式可以很快：Facebook Messenger就是運(yùn)行MQTT協(xié)議的。它也是管理大量設(shè)備之間的互連的一種更靈活的方式：每個(gè)設(shè)備只需調(diào)整到它們所需的主題上。

但HTTP得到廣泛的支持。它可以通過Web API以易于訪問和通用的方式利用傳感器網(wǎng)絡(luò)。它也通過使用防火墻來增加安全性，因?yàn)樗雌饋砭拖衿胀ǖ木W(wǎng)頁瀏覽。

圖2、像MQTT這樣的發(fā)布訂閱應(yīng)用程序協(xié)議可以提供一種比點(diǎn)對(duì)點(diǎn)協(xié)議（如HTTP）更有效的方式來傳遞大型設(shè)備網(wǎng)絡(luò)中的數(shù)據(jù)。在這種情況下，每個(gè)接收器從發(fā)送方1和2獲取數(shù)據(jù)，但并不都需要來自發(fā)送者3和4的數(shù)據(jù)。在這種發(fā)布預(yù)訂（Publish-subscribe）的網(wǎng)絡(luò)中，只需要較少的連接來正確地分發(fā)消息。

互聯(lián)網(wǎng)服務(wù)

在本節(jié)中，我們將介紹Internet服務(wù)在IoT系統(tǒng)中的作用，以及API（應(yīng)用程序編程接口）的設(shè)計(jì)與UX（用戶體驗(yàn)）設(shè)計(jì)之間的關(guān)系。

互聯(lián)網(wǎng)服務(wù)的作用

物聯(lián)網(wǎng)系統(tǒng)通常需要依靠某種的遠(yuǎn)程集中式互聯(lián)網(wǎng)服務(wù)來收集，處理和分發(fā)數(shù)據(jù)和指令（少數(shù)的連接設(shè)備可能沒有遠(yuǎn)程集中式Internet服務(wù)。例如，許多WiFi打印機(jī)都有自己的嵌入式Web服務(wù)器，從而可以托管它們自己的互聯(lián)網(wǎng)服務(wù)。但這在物聯(lián)網(wǎng)的應(yīng)用中就相對(duì)少見）；

互聯(lián)網(wǎng)服務(wù)通常包括一些存儲(chǔ)和處理方式：

?系統(tǒng)數(shù)據(jù)（例如，傳感器數(shù)據(jù)或者設(shè)備的當(dāng)前狀態(tài)）；

?運(yùn)行在頂層中的應(yīng)用（例如，健康監(jiān)控或者照明控制）；

該服務(wù)通過應(yīng)用程序編程接口（APIs）來使數(shù)據(jù)和系統(tǒng)命令可用于移動(dòng)或者Web應(yīng)用程序中。服務(wù)提供商越來越多地將APIs提供給第三方開發(fā)人員以使其他服務(wù)能夠與系統(tǒng)集成。

例如，從傳感器網(wǎng)絡(luò)獲取的數(shù)據(jù)由Internet服務(wù)器進(jìn)行匯聚和處理，然后因特網(wǎng)服務(wù)器發(fā)布數(shù)據(jù)總結(jié)。

系統(tǒng)設(shè)計(jì)人員可以選擇處理發(fā)生的位置：在遠(yuǎn)程服務(wù)中（“云”），網(wǎng)關(guān)中或者邊緣設(shè)備中。在云中進(jìn)行更多處理可以更容易地維護(hù)對(duì)系統(tǒng)的一個(gè)集中式視圖。但是當(dāng)設(shè)備丟失連接并且無法訪問云時(shí)，系統(tǒng)將無法正常工作。

對(duì)于非緊急的數(shù)據(jù)，例如空氣質(zhì)量監(jiān)測(cè)，這是可以接受的。如果傳感器暫時(shí)離線，他們可以存儲(chǔ)數(shù)據(jù)，并在重新連接時(shí)再將其上傳。發(fā)生的最糟糕的事情是一些數(shù)據(jù)可能是舊的。

但是，對(duì)于數(shù)據(jù)必須盡快完成這樣做是不行的。如果嬰兒監(jiān)視器沒有及時(shí)警告隔壁房間的父母導(dǎo)致孩子已經(jīng)停止了呼吸，那么這是不能接受的。這就是需要進(jìn)行本地處理的地方，因此設(shè)備可以在沒有互聯(lián)網(wǎng)的情況下工作（例如，具有設(shè)備上控制功能或者網(wǎng)關(guān)的恒溫器可以繼續(xù)控制家庭照明）。

互聯(lián)網(wǎng)服務(wù)可能是專有的（針對(duì)您的服務(wù)定制），也許使用API來與第三方服務(wù)共享數(shù)據(jù)?；蛘咚赡苁且环N開放式服務(wù)（例如，Thingspeak的開放數(shù)據(jù)平臺(tái)）。如果您依賴別人的服務(wù)，那么請(qǐng)記住，如果他們出現(xiàn)中斷，提高價(jià)格，丟失或者公布您的數(shù)據(jù)，或者它們破產(chǎn)了...，那么最終您也會(huì)如此。

平臺(tái)（在這種情況下）是一種可用于構(gòu)建多個(gè)遠(yuǎn)程服務(wù)應(yīng)用程序的軟件框架。 Thingspeak，Kaa，Xively，以及Thingworx是開發(fā)人員可以用來創(chuàng)建IoT服務(wù)的平臺(tái)例子。平臺(tái)可以使工程師更容易地讓系統(tǒng)運(yùn)行起來，但是可能也會(huì)限制您或者使您的服務(wù)缺乏靈活性。依靠第三方平臺(tái)需要承擔(dān)平臺(tái)提供商可能會(huì)停業(yè)的風(fēng)險(xiǎn)。與開放標(biāo)準(zhǔn)連接的獨(dú)立服務(wù)可能會(huì)提供更多的控制和選擇：如果需要，您可以用一個(gè)等效的服務(wù)來替換現(xiàn)有的服務(wù)。

APIs（應(yīng)用程序編程接口）

應(yīng)用程序編程接口（API： application programming interface）是開發(fā)人員的接口。API為開發(fā)人員提供了一些組件工具來構(gòu)建系統(tǒng)里的東西。它們可能是您自己的前端網(wǎng)絡(luò)或者移動(dòng)應(yīng)用apps或與您的系統(tǒng)交互的第三方服務(wù)。 API是創(chuàng)建可互操作的設(shè)備和服務(wù)生態(tài)系統(tǒng)的重要組成部分。

API使開發(fā)人員可以創(chuàng)建易于鏈接到其它服務(wù)的Web服務(wù)。因此，您無需為您的雨量預(yù)報(bào)設(shè)備而構(gòu)建自己的天氣預(yù)報(bào)服務(wù)：您可以輕松地呼叫第三方天氣服務(wù)的API。 “小件（small pieces），松散加盟（loosely joined）”的原則鼓勵(lì)開發(fā)商創(chuàng)造有針對(duì)性的服務(wù)：做好一件事，同時(shí)與其他服務(wù)進(jìn)行良好的互操作。這提供了將不同服務(wù)組合在一起來創(chuàng)建完全不同的應(yīng)用的靈活性。

UX（用戶體驗(yàn)）人員通常不負(fù)責(zé)設(shè)計(jì)API，但API設(shè)計(jì)可能會(huì)對(duì)您能夠創(chuàng)建的UX（用戶體驗(yàn)）產(chǎn)生重大的影響。您在APIs中提供的功能可以決定您可以使用自己的UX設(shè)計(jì)做什么以及其他（第三方）可以對(duì)您的服務(wù)做什么。

設(shè)計(jì)API非常像為內(nèi)容網(wǎng)站設(shè)計(jì)信息架構(gòu)。您需要了解您的用戶需要哪些信息，以及如何分塊和組織，以便使用戶輕松快捷地找到自己想要的內(nèi)容。

有時(shí)設(shè)計(jì)決策將涉及到權(quán)衡：您可能通過使一些任務(wù)變得更容易，而卻使別的任務(wù)變得更難。

如果您的UX（用戶體驗(yàn)）設(shè)計(jì)和您的API（應(yīng)用程序編程接口）設(shè)計(jì)相互不適合，其結(jié)果可能是導(dǎo)致長時(shí)間延遲，響應(yīng)速度差以及服務(wù)器過載。 API設(shè)計(jì)應(yīng)與產(chǎn)品定義和UX設(shè)計(jì)緊密相連。

web API是如何工作的？

API可以描述數(shù)據(jù)或者函數(shù)調(diào)用。它們可以用多種語言編寫，但在本章中我們將使用基于HTTP的標(biāo)準(zhǔn)Web API的示例。

Web API調(diào)用將操作應(yīng)用于URL。以下是一個(gè)連接的家庭系統(tǒng)的一種可能的API URL架構(gòu)的示例：http：// api.[服務(wù)供應(yīng)商的名字].com /屬性（property）/網(wǎng)關(guān)（gateway）/設(shè)備類型（devicetype）/設(shè)備（device）/信道（channel）。

·第一部分是服務(wù)提供商的公共域名。

·屬性（property）是系統(tǒng)所在的家（例如，克萊爾的房子）。

·網(wǎng)關(guān)（gateway）是網(wǎng)關(guān)設(shè)備的名稱（如果您有多個(gè)網(wǎng)關(guān)設(shè)備的話）。

·設(shè)備類型（devicetype）是設(shè)備的類型（例如，運(yùn)動(dòng)傳感器，接觸傳感器，燈開關(guān)）的名稱。

·設(shè)備（device）是由用戶分配的特定設(shè)備（例如餐廳運(yùn)動(dòng)傳感器或者后門接觸傳感器）的名稱。

·信道（channel）是來自該設(shè)備的數(shù)據(jù)饋源。設(shè)備可能有多個(gè)（例如，所有運(yùn)動(dòng)和接觸傳感器也可能感測(cè)溫度，因此將有兩個(gè)數(shù)據(jù)饋源：運(yùn)動(dòng)和溫度）。

您可以使用API檢索數(shù)據(jù)，或在某些情況下通過使用HTTP方法發(fā)送請(qǐng)求將命令發(fā)送給系統(tǒng)。

GET是最常見的，用于檢索數(shù)據(jù)的方法。使用下面的示例：如果您想從房間中的所有運(yùn)動(dòng)傳感器中檢索到狀態(tài)信息，那么就可以通過使用GET方法來發(fā)出請(qǐng)求：http：// api.[serviceprovidername] .com / claireshouse / gateway1 / motionsensors。

系統(tǒng)會(huì)回應(yīng)以下XML代碼：

<channel type="motion">

<events>

<event type="motion" detected="no" timestamp=""

location=""/>

<event type="motion" detected="no" timestamp=""

location=""/>

... (在房子里的每個(gè)運(yùn)動(dòng)傳感器的一個(gè)條目)...

</events>

</channel>

如果您有這樣做的授權(quán)，您也可以使用其他方法修改服務(wù)器上的數(shù)據(jù)。

在這個(gè)例子中，如果你想把飯廳的燈光調(diào)暗50％，你可以提出一個(gè)PUT請(qǐng)求：

/{ claireshouse/gateway1/lightswitches/diningroom

<light>

<state value="on"/>

<dimming percentage="50"

</light>

這些是非常簡(jiǎn)單的例子，但應(yīng)該可以幫助您了解以下部分中描述的設(shè)計(jì)問題。

APIs的關(guān)鍵設(shè)計(jì)問題

在設(shè)計(jì)API時(shí)要做出的關(guān)鍵決定是數(shù)據(jù)和控制的顆粒度，以及如何將其組織到層次結(jié)構(gòu)中去。

Granularity（顆粒度）：由連接到互聯(lián)網(wǎng)的一個(gè)設(shè)備組成的簡(jiǎn)單系統(tǒng)可以具有一個(gè)簡(jiǎn)單的API。該設(shè)備發(fā)布已收集的關(guān)鍵數(shù)據(jù)，如前面的例子所示您可以將簡(jiǎn)單的命令（控制）傳回給它。這是一種細(xì)粒度（或者面向端點(diǎn)的）設(shè)計(jì)，因?yàn)樗┞读嗽O(shè)備本身的底層數(shù)據(jù)。

端點(diǎn)/細(xì)粒度的APIs（圖3）允許控制特定設(shè)備或檢索特定的數(shù)據(jù)，這對(duì)于小型系統(tǒng)來說是足夠好的。但是，如果您想要同時(shí)從許多設(shè)備檢索數(shù)據(jù)，則細(xì)粒度的系統(tǒng)意味著需要大量單獨(dú)的API調(diào)用。這將是緩慢的：在3G連接上每個(gè)API調(diào)用每次往返可能需要1秒鐘。需要進(jìn)行20個(gè)API調(diào)用的網(wǎng)頁或移動(dòng)應(yīng)用程序屏幕的加載速度要比只有兩個(gè)或者三個(gè)API調(diào)用的速度要慢得多。

圖3、細(xì)粒度和粗粒度APIs的簡(jiǎn)單的例子

在具有大量設(shè)備的物聯(lián)網(wǎng)系統(tǒng)中，各個(gè)個(gè)體設(shè)備通常對(duì)用戶來說并不重要。如果您想知道您家客廳的溫度，您會(huì)關(guān)心您的房間而不是可以在房間監(jiān)測(cè)溫度的設(shè)備。系統(tǒng)應(yīng)該為您計(jì)算室溫，并通過單個(gè)的API調(diào)用就可以使其呈現(xiàn)給您。

這些是面向任務(wù)的（針對(duì)特定任務(wù)）或粗粒度（匯聚數(shù)據(jù)）API函數(shù)的示例。服務(wù)匯聚來自多個(gè)設(shè)備的數(shù)據(jù)，并在后端應(yīng)用一些算法處理。您的智能手機(jī)應(yīng)用程序只需要運(yùn)行一個(gè)API調(diào)用，來知道房子中哪些燈是開的或者哪些是關(guān)的。

面向任務(wù)的API使得更容易實(shí)現(xiàn)在多個(gè)設(shè)備上支持復(fù)雜功能。您可以將API緊密地綁定到您的UI（用戶接口）上，匯聚通過單個(gè)API調(diào)用訪問的特定屏幕或小部件所需的所有數(shù)據(jù)。這將是高度響應(yīng)的系統(tǒng)，但如果您想要更改您的UI，則需要重新設(shè)計(jì)。所有使用您的API的第三方都必須提供與您完全相同的屏幕/小部件塊數(shù)據(jù)。因此面向任務(wù)的APIs存在靈活性不夠的風(fēng)險(xiǎn)：UX設(shè)計(jì)人員和開發(fā)人員必須按照您設(shè)計(jì)API的方式來使用它們。

如果API的粗粒度過大，也可能會(huì)阻止您訪問單個(gè)設(shè)備或者數(shù)據(jù)。你可能有時(shí)候需要關(guān)掉所有的燈，但是你也有時(shí)候只想要關(guān)掉走廊上的燈。

來自Evrythng的Niall Murphy引用了現(xiàn)有使用單一API連接汽車的例子。這是為維修/制造商診斷而設(shè)計(jì)的，但對(duì)其它的用途來說是不切實(shí)際的：

“你可以打開汽車上的所有信息流，或者關(guān)閉它。當(dāng)你回家的時(shí)候，家里一直不需要車位置的信息流來打開車庫門。您需要將大小信息縮小到與特定應(yīng)用程序匹配的所需信息”。

有可能使用混合設(shè)計(jì)：一些聚合數(shù)據(jù)和面向任務(wù)的APIs以及一些端點(diǎn)（設(shè)備）APIs。這將使您能夠顯示家庭中所有電器的能源使用情況，也可以只跟蹤烘干機(jī)的使用情況。

結(jié)構(gòu)體。除了選擇正確的數(shù)據(jù)和控制的顆粒度之外，還需要對(duì)API中的單位（設(shè)備和數(shù)據(jù)點(diǎn)）進(jìn)行分組和組織，以使其他人能夠使用。當(dāng)您擁有更多的設(shè)備和數(shù)據(jù)點(diǎn)后這一點(diǎn)會(huì)變得越來越重要。

數(shù)據(jù)/設(shè)備在您的API中的組織方式可以使您更容易或者更難以從您想要的設(shè)備組合中檢索數(shù)據(jù)或者應(yīng)用控制。嘗試著從不適合的API設(shè)計(jì)中創(chuàng)建UX設(shè)計(jì)將會(huì)導(dǎo)致一個(gè)遲緩的，無響應(yīng)的UX。

家庭中的設(shè)備可以通過其感測(cè)能力（例如，溫度或運(yùn)動(dòng)），位置（例如在廚房里或者在樓上），它們支持的應(yīng)用（例如，安全性或者加熱）或者其它更多的方式來組織。有些設(shè)備可以做超過一件事情的 - 例如，一些設(shè)備既可以感測(cè)溫度又可以監(jiān)測(cè)運(yùn)動(dòng)，以及和/或可能被多個(gè)應(yīng)用程序所使用。如果您繪制了這些設(shè)備之間的相互關(guān)系的映射，那么它將看起來像一個(gè)網(wǎng)絡(luò)結(jié)構(gòu)（見圖4）。

圖4、設(shè)備之間的相互關(guān)系形成網(wǎng)絡(luò)結(jié)構(gòu)

用戶可能希望訪問不同的被組織起來的分組。例如，您可能想要看到房子周圍的溫度讀數(shù)。或者您可能想要查看所有安全設(shè)備。或者您可能想要檢查客廳中每個(gè)設(shè)備的當(dāng)前狀態(tài)。

對(duì)于復(fù)雜的多設(shè)備系統(tǒng)，網(wǎng)絡(luò)類型的UX通?？雌饋硐袷且环N直觀的方式來供用戶探索可用的內(nèi)容。從客廳運(yùn)動(dòng)傳感器，您可以瀏覽其它的安全設(shè)備，其他運(yùn)動(dòng)傳感器以及其它測(cè)量溫度的設(shè)備。

麻煩的是，在UX中提供這種靈活性不一定會(huì)很容易地使用APIs。特別是查找相關(guān)數(shù)據(jù)往往是一個(gè)挑戰(zhàn)。 URL是分級(jí)的，因此它們并不反映數(shù)據(jù)可以相互關(guān)聯(lián)的所有方式。

還是以我們前面看過的餐廳溫度為例。在與餐廳溫度相同的屏幕上，您還想顯示家中其他溫度傳感器的讀數(shù)。對(duì)用戶來說，這似乎是一件很明顯的事情：從一個(gè)溫度讀數(shù)，我可以查看其它的讀數(shù)。但是在這個(gè)架構(gòu)中，它們都位于樹結(jié)構(gòu)的底部，并且彼此之間的關(guān)系沒有被映射。所以您必須單獨(dú)調(diào)用每個(gè)其它溫度傳感器的數(shù)據(jù)。這將是緩慢而低效的，就像您不得不從上到下瀏覽網(wǎng)站的樹結(jié)構(gòu)以比較大量單獨(dú)的網(wǎng)頁頁面里的內(nèi)容。

如果您正在設(shè)計(jì)一個(gè)只有少量設(shè)備的小型系統(tǒng)，那么潛在的低效率就會(huì)很小。但是，您必須應(yīng)對(duì)的數(shù)據(jù)點(diǎn)和設(shè)備越多，那么讓您的API結(jié)構(gòu)很好地適應(yīng)UX就越重要。

作為一名UX設(shè)計(jì)師，重要的是確保您的工作與設(shè)計(jì)APIs的開發(fā)人員要緊密合作。

第三方API。您可以依賴于第三方例如Xively或Twitter的API。如果是這樣，您就受到他們的條款約束，您需要檢查您可以如何使用它們。供應(yīng)商通常對(duì)您可以進(jìn)行的調(diào)用頻率施加限制，或每天的API調(diào)用數(shù)量，以避免使他們的服務(wù)器過來。他們也可能收取API調(diào)用費(fèi)用，如天氣預(yù)報(bào)服務(wù)forecast.io所做的那樣，另外與第三方平臺(tái)提供商一樣，他們也可能會(huì)停業(yè)。

總結(jié)

網(wǎng)絡(luò)對(duì)物聯(lián)網(wǎng)（IoT）系統(tǒng)的UX（用戶體驗(yàn)）產(chǎn)生了根本的影響。許多連接的設(shè)備僅間歇地連接到網(wǎng)絡(luò)以輪詢新的指令。這可能會(huì)造成系統(tǒng)的部分相互不同步而產(chǎn)生較小的延遲。網(wǎng)絡(luò)延遲和可靠性問題可能意味著連接的設(shè)備的行為不與如我們期望的現(xiàn)實(shí)世界的對(duì)象所做的那樣。

系統(tǒng)架構(gòu)決定設(shè)備如何圍繞系統(tǒng)傳遞數(shù)據(jù)，處理發(fā)生的事情，以及系統(tǒng)的某些部分離線時(shí)將會(huì)或者將會(huì)不起作用。設(shè)備可以直接連接到Internet或者通過本地網(wǎng)絡(luò)連接到網(wǎng)關(guān)。許多設(shè)備只能支持低功率網(wǎng)絡(luò)，如藍(lán)牙和ZigBee。網(wǎng)關(guān)使這些設(shè)備間接連接到Internet中。未來，通過為低功率網(wǎng)絡(luò)提供I功能P將使更多的設(shè)備能夠直接連接到互聯(lián)網(wǎng)中。這種互聯(lián)網(wǎng)標(biāo)準(zhǔn)的使用將使不同的系統(tǒng)能夠更容易的合作。

應(yīng)用協(xié)議塑造了設(shè)備通過網(wǎng)絡(luò)并從網(wǎng)絡(luò)中獲取數(shù)據(jù)的連接模式。數(shù)據(jù)可能被推送（push）或者被拉到（pull）設(shè)備上;該設(shè)備可以不間斷連接或者以規(guī)則間隔來輪詢指令。 HTTP是常用的;而專門的IoT協(xié)議（如MQTT）針對(duì)具有有限帶寬的低功率設(shè)備進(jìn)行了優(yōu)化。

所有IoT系統(tǒng)都依賴某種遠(yuǎn)程集中式Internet服務(wù)來收集，處理和分發(fā)數(shù)據(jù)和指令。該服務(wù)通過應(yīng)用程序編程接口（APIs）使數(shù)據(jù)和系統(tǒng)命令可用于移動(dòng)或者Web應(yīng)用程序中。

應(yīng)用程序編程接口（APIs）是開發(fā)人員的界面。它為他們提供了使用系統(tǒng)數(shù)據(jù)來制作最終用戶應(yīng)用程序和其他系統(tǒng)的基本模塊。如果API設(shè)計(jì)不適合UX的要求，那么可能會(huì)導(dǎo)致緩慢的，無響應(yīng)的體驗(yàn)或者會(huì)過度限制您所提供的功能。

應(yīng)用舉例

Proteus數(shù)字健康（Proteus Digital Health）：連接的藥丸

藥物是20世紀(jì)的一個(gè)驚人的創(chuàng)新，但它們只有在正確使用時(shí)才能奏效。來自世界衛(wèi)生組織的專家估計(jì)，一半的藥物沒有按規(guī)定服用，意思是劑量不足，劑量不正確或藥物不正確.由于這些依從性的挑戰(zhàn)，大多數(shù)人不能從藥物中獲得最大的價(jià)值。 Proteus Digital Health正在通過在口服藥物中添加傳感器并將其連接到物聯(lián)網(wǎng)中來解決這個(gè)問題。

這些連接的藥物正在為患者，護(hù)理人員和醫(yī)護(hù)人員提供新的數(shù)據(jù)流。 Proteus的系統(tǒng)在人們服用藥物時(shí)，不可思議地捕捉到數(shù)據(jù)，并將數(shù)據(jù)與其他生理和行為數(shù)據(jù)（如心率，活動(dòng)和睡眠模式）進(jìn)行比較。這些信息匯聚在一起可以實(shí)現(xiàn)新的自我管理方法，并產(chǎn)生新的見解以便臨床決策。

技術(shù)

該系統(tǒng)的核心創(chuàng)新是在藥物制造的過程中可以藥丸中放入的一個(gè)小型，低成本的1mm×1mm可攝取傳感器（見圖5）。這種一次性傳感器被設(shè)計(jì)為從根本上安全的，由通常可以在人類飲食中發(fā)現(xiàn)的元素制成的。用戶也不可見，完全封閉在藥丸內(nèi)，所以“連接”藥丸看上去與標(biāo)準(zhǔn)藥物沒有任何區(qū)別。

在設(shè)計(jì)物理傳感器時(shí)，我們認(rèn)為保持人們對(duì)熟悉使用的藥物的習(xí)慣方式非常重要，因此拒絕使用傳感器對(duì)用戶可見的設(shè)計(jì)方法。

圖5、 Proteus的可攝入傳感器

可攝入傳感器通過專有的傳輸技術(shù)與由Proteus開發(fā)包含在佩戴在身體上并每周更換的小貼片內(nèi)的小型穿戴式傳感器進(jìn)行通信。佩戴設(shè)備可以收集其他數(shù)據(jù)，例如活動(dòng)和心率，并將所有的內(nèi)容傳送到手機(jī)中（參見圖6）。然后，手機(jī)將數(shù)據(jù)發(fā)送到云端，可以通過安全的門戶網(wǎng)站和應(yīng)用程序?qū)@些數(shù)據(jù)進(jìn)行分析和訪問。這些應(yīng)用可以針對(duì)不同的用例進(jìn)行定制，并可以針對(duì)不同的用戶進(jìn)行優(yōu)化。人們對(duì)信息有不同的用途：患者管理日常護(hù)理，個(gè)人護(hù)理人員獲得對(duì)親人的保證，護(hù)士可以立即關(guān)注需要分診的病人，醫(yī)生參考它們來做臨床決策，醫(yī)護(hù)人員通過它們來了解其人群趨勢(shì)等。

設(shè)計(jì)一項(xiàng)使該技術(shù)成功推出的服務(wù)也很重要。最初這種系統(tǒng)有兩個(gè)服務(wù)設(shè)計(jì)目標(biāo)：（1）降低使用不熟悉產(chǎn)品的障礙，（2）加快學(xué)習(xí)可以如何改進(jìn)產(chǎn)品。為了達(dá)到這些目標(biāo)，Proteus投資雇用了全職的“教練”，他們負(fù)責(zé)訪問家中早期的客戶，幫助他們使用系統(tǒng)，并報(bào)告他們所面臨的挑戰(zhàn)。這項(xiàng)投資至關(guān)重要，因?yàn)檫@使Proteus能夠快速識(shí)別和修復(fù)產(chǎn)品痛點(diǎn)。隨著產(chǎn)品變得更容易使用，客戶對(duì)新技術(shù)的信心越來越高，Proteus預(yù)計(jì)將其轉(zhuǎn)變?yōu)楦叱杀拘б婧透儋Y源密集型服務(wù)模式。

圖6、 Proteus系統(tǒng)

Proteus早期的設(shè)計(jì)任務(wù)之一是找出誰需要訪問什么數(shù)據(jù)以及如何訪問。由Proteus生成的數(shù)據(jù)可以用于各種各樣原因下的上下文環(huán)境中?？s小并集中在幾個(gè)用例上來開始是關(guān)鍵。

Proteus的業(yè)務(wù)團(tuán)隊(duì)確定了一套潛在的市場(chǎng)。然后，為了定義產(chǎn)品，Proteus的設(shè)計(jì)研究團(tuán)隊(duì)訪問了家庭或診所市場(chǎng)上的潛在客戶，并仔細(xì)觀察了最嚴(yán)峻的挑戰(zhàn)，傾聽了Proteus可以直接回答的具體問題。通過這些學(xué)習(xí)，Proteus的交互設(shè)計(jì)師以靜態(tài)截圖的形式創(chuàng)建了潛在的信息可視化，然后將其帶回到現(xiàn)場(chǎng)進(jìn)行反饋（見圖7）。雖然Proteus早期的原型展示了大量的數(shù)據(jù) - 展示了廣泛的系統(tǒng)功能 - Proteus收集的反饋意見促使他們更直接地實(shí)施信息可視化，更直接地關(guān)注所提問題，留下大量的原始數(shù)據(jù)。我們發(fā)現(xiàn)，提供太多的數(shù)據(jù)產(chǎn)生的噪音對(duì)幫助人們最大限度地利用系統(tǒng)的利益起到了適得其反的作用，特別是在用新技術(shù)建立“應(yīng)用文化”的早期階段。

圖7、用戶測(cè)試可視化

早期用例1：護(hù)理

該技術(shù)非常適合幫助護(hù)理人員遠(yuǎn)離脆弱的家庭成員。Proteus的員工和家人見面，聽了他們的故事。從護(hù)理者那里聽到的主要訴求是需要知道媽媽是否早上服用藥物，是否會(huì)在下午2點(diǎn)做她的三明治。媽媽的主要需求是要保持尊嚴(yán)。Proteus對(duì)這種用例的信息可視化涉及可以利用藥物治療和活動(dòng)數(shù)據(jù)的一個(gè)簡(jiǎn)單的功能區(qū)，允許家庭成員來看到親人全天的高級(jí)概述模式（參見圖CS1-4）。可視化可以避免諸如心率之類的臨床數(shù)據(jù)，這些數(shù)據(jù)并沒有為家庭成員提供有意義的洞察力，并且有可能在這種個(gè)人用例中侵犯媽媽的隱私。

圖8、顯示功能區(qū)的平板電腦應(yīng)用程序

早期用例2：通知高血壓治療

第二個(gè)用例涉及幫助醫(yī)生確定為什么高血壓患者會(huì)出現(xiàn)不受控制的癥狀。醫(yī)生對(duì)于不服用藥物或由于處方藥物不當(dāng)而導(dǎo)致病人不受控制的了解甚微。使用Proteus系統(tǒng)兩周后，醫(yī)師可以訪問回答了兩個(gè)關(guān)鍵問題的簡(jiǎn)明報(bào)告：病人是否服用藥物，現(xiàn)在是否處于控制狀態(tài)？報(bào)告中沒有列出活動(dòng)數(shù)據(jù)，因?yàn)樗鼈冊(cè)诨卮疳t(yī)生的關(guān)鍵問題時(shí)沒有用處。大多數(shù)患者由于霍桑效應(yīng)（Hawthorne effect）而在觀察期間按照規(guī)定服用藥物 - 意識(shí)在被觀察會(huì)在短時(shí)間內(nèi)改變?nèi)说男袨?- 因此臨床醫(yī)生現(xiàn)在已經(jīng)驗(yàn)證了遵守情況，并指出藥物是否正在起作用。這種組合提供可操作的洞察力，幫助臨床醫(yī)生作出決定是堅(jiān)持治療還是要升級(jí)到下一療程。