開源的語音辨識WIT.ai

    今年的2015元旦剛過不了一個星期，Facebook便宣佈收購了語音辨識公司WIT.ai，這家公　司為一新創公司，成立雖僅18個月，但其語音技術根據百度（Baidu Inc.）的測試結果，比起蘋果的Siri、微軟的Cortana還要更加精確，相當接近百度（自家作的調查，當然要充胖一下）或 Google Google now語音助手的表現，無怪乎祖克伯要以迅雷不及掩耳的速度收購這家剛誔生的公司，作為與Apple和Google在語音AI領域相對抗的武器。

WIT.ai強調的是開放與免費使用，並利用使用者回饋的數據作為改善的參考；截至目前統計，已經有6000多位開發者透過WIT.ai所免費提供的API，在其程式中加入語音辨識的功能，以便開發出各式類型的App與應用環境，而其語音識別技術與資料庫在免費提供user使用的情況下，利用使用者與開發者自主回饋的資訊，作為WIT.ai自我改良的方式、並使其語音識別效率更加精確。

WIT.ai能作什麼？

    在WIT.ai首頁上，直接開宗明義的列出它能協助完成的事：

1. Mobile apps：如果你是App開發者，可以使用WIT.ai的語音服務，讓你的App具有語音控制的功能，讓使用者能夠透過手機發送或執行語音相關命令。
2. Home automation：當WIT.ai成功解析了你所送出的語音命令，那麼就可以透過智慧家居設備來執行相對應的動作。
3. Wearable devices：穿戴式設備由於體積小，與使用者的輸出入介面受到限制，因此高度依賴語音命令的動作方式。
4. Robots：無論是在工廠生產線或家庭、娛樂用的機器人，皆可透過語音方式讓機器人去執行相對應的行為，讓人感覺機器人似乎擁有聽覺與智慧的能力。
5. Messenger Agents：目前各科技大廠皆推出語音助手的服務，透過對話的方式處理部份help desk的工作，並提供即時性的協助；只要在個人的console上建立完善的語音命令資料庫，WIT.ai也可以作到這點。

WIT.ai為何免費？

　　最可貴的一點：WIT.ai是免費的，想想看，一般人若要建置一套自有的語音識別系統，往往要從零開始搜集龐大的語音樣本資料庫，並進行後續的處理、分析訓練、建置模型等等，這些都需要龐大的時間與人力門檻，因此限制住了像個人開發者、中小型企業等對於語音相關領域的開發與投入。

然而透過免費提供給眾多開發者應用在各種領域的專案，並將結果集中維護到線上的資料庫，這樣大量透過開發者在console對於語音識別結果的回饋，WIT.ai經由這樣集體智慧的概念，具備了自我學習並自動改良語音識別的能力，因此其辨識的準確度不下於諸如Google now、Apple Siri、Microsot Cortana、Amazon Echo等等科技大廠語音助手的識別能力。

　　它的作法是，使用者（開發人員）需要先收集一系列希望讓電腦能夠識別的字串和口語，集中在一個稱為「Expressions」的資料夾中，然後提供眾多的語音樣本訓練電腦讓它知道這些語音都是屬於該「Expressions」，因為不同人有不同的腔調發音與口吻，因此，愈多的樣本與「Expressions」資料愈能讓識別結果更精確。因此和GitHub 這類的程式分享平台相同，WIT.ai亦充分的利用了網路的分享功能，藉由免費提供語音識別功能給開發者，同步的要求開發人員必須分享彼此的「grammar」和樣本以增進識別精確度，而達到一舉兩得的效果。

　　不過，由於需要回到線上的資料庫分析取用並回饋，因此，我們可以預想到WIT.ai的一大缺點，就是必須要先連網才能使用相關的語音控制功能，如果沒有網路連線或設備不具連網功能，那麼就無法使用WIT.ai了，坦白說，這是一個致命的缺點，也是WIT.ai目前無法廣泛流行的原因，因為若需要設備在使用時必須先連網、或者必須持續的連網，那麼，它的使用範疇和應用環境就會大大的受限，而且也增加了開發的成本與功能複雜性。事實上，如果WIT.ai考量的是為了維護一套集中的資料庫、避免被自由散發利用、或者可立即更新、資料回饋等等，其實可考慮將龐大的語音資料庫預先分門別類，各別開放讓使用者依需求類型下載，且其下載的語音資料庫是經過加密無法反解譯的，或者乾脆考慮下載資料庫不連網使用者需付費等方式，應該都是可行的方向。

開始試用看看

1. 登入GitHub帳號：WIT.ai使用GitHub來認證並建立個人專屬的控制平台（Wit console），因此必須要先擁有GitHub帳號才行，若您還沒有GitHub帳號可以到https://github.com申請，成功登入後，您便擁有專屬的Wit console（網址https://wit.ai/{您的GitHub帳號}）。

下方是我的Wit console，點擊右上方的帳號名稱可新增一個instance。

2. 建立Instance和Expression：這是比較複雜的部份，在建立所有的expression之前，我們必須先思考，想要用聲音來啟動什麼命令？

有兩個方式：

1. 想像一下一個人應該說什麼話，然後將這個話語對應到什麼設備應作出什麼反映。
2. 看看設備上的功能，能用什麼適當的指令來啟動它？要用什麼口語聲音來啟用這些指令？

例如，我們想要控制溫度，所以我們可能會說：

        「What's the current temperature?」

        「I want to set the temperature to 71 degrees.」

        「Is it me or it is hot here?」

        「Set the temperature to 64 degrees at 10pm.」

        「I am hot!」

    以上這些都可算是口語上想要控制溫度的指令，所以我們把它們都輸入到expression當中，Intent則輸入：Temperature。

然後，我們可以先用keyin文字的方式來測試WIT.ai可否辨識；請在Console中的文字欄，輸入剛剛expressions中的任一句，例如「It’s cold」，你會發現WIT.ai告訴我們這句話的意圖是”Temperature”，由於透過文字而省略了語音的因此，如果是透過語音方式，我們必須提供愈多的樣本愈好，才能抓到正確的意圖。

另外要注意的是，這些我們自己透過語音來測訓並訓練的結果是會自動提供給其它WIT.ai會員使用的，如果你不想公開，那麼就必須付費才不會公開給外界。

WIT.ai支援那些開發工具？

1. WEB API：我們可以透過cURL，使用HTTP URL語法、或以JQuery來傳送命令並接收回傳結果，這種方式可用於大部份的環境，如網站、WEB App、iOS、Android、Windows…等等。

Ex：JQuery+JSON的範例，送出” set an alarm in 10min”的命令，此段亦可為一個語音物件.

收到的回應亦是json格式，intent是”alarm_set”，”entities”的值是”on”，有一個”datetime”的值是”2015-03-16T23:22:13.000-07:00 ~ 2015-03-16T23:22:14.000-07:00 “，因此，我們會發現，當我們告訴WIT.ai ” set an alarm in 10min”這句話，它能夠正確的告訴我們詳細的資訊：alarm_set、on以及一組相距十分鐘的時間值，我們就可以在程式中依使用者的語音作出正確的人工智慧行為，而且個人開發者或小公司就可以作到。

2. 其它分別針對不同平台的API或SDK：如iOS API、Android SDK、Windows API、WEB API、Raspberry Pi API、Node.js API、Ruby SDK、Python SDK、C API、Rust API等等。

從希拉蕊的電郵門事件談起

還記得2007年11月，雅虎總裁楊致遠以及副總卡拉漢在美國眾議院的聽證會應議員們的要求，高調地向師濤母親鞠躬道歉的新聞嗎？

這位無助的母親，在利益至上的科技新貴背後痛哭失聲的畫面另人動容，事件起因是當初任職於「當代商報」編輯部主任的師濤，透過雅虎信箱將當局嚴禁六四15周年相關活動的指示傳給了國外網站，事後他萬萬想不到，這家標榜安全隱私與正義人權的美國科技巨擘，在面對利益與商機時卻變成道德的侏儒…  這些私人的電郵記錄被雅虎提供給中國當局作為叛亂定罪的佐證。

電子郵件的安全性

電子郵件的發明人據稱是Ray Tomlinson（雷·湯姆林森），1971年底時（距今有44年了）他在所屬BBN科技公司劍橋研究室裡，把世界第一封電子郵件從一台電腦發送到毗鄰的另一台電腦，這可算是最早e-mail的雛型了；直至今天，各式各樣的協作工具以及傳訊軟體風起雲湧，但仍難以撼動電子郵件的地位，e-mail仍然是企業內最主要的辦公工具，不過，它卻也是駭客最愛的工具之一。

事實上，根據趨勢TrendLabs的研究，有91％的目標攻擊是利用電子郵件作為開始的進入點，其中則約有78％是利用嵌入在e-mail附件的惡意軟體來作後續的攻擊，顯然電子郵件是阻力最小成本最低的一種攻擊路徑，可以用來規避現有的安全防禦，藉由不知情的第三者點擊執行進而滲透網路、感染更多電腦，因此，電子郵件的風險，除了人為的有意洩漏（收發信的雙方、攔截信件的第三者、伺服器的管理者、猜測破解信箱密碼、窺覬郵件內容），還有木馬屠城的危險（附加惡意附件或釣魚網址披著郵件外衣繞過防火牆直達位於內部網路的信箱），所以比起直接擂門叫陣地在防火牆前苦思破解，以電子郵件方式駭入企業內部可說是門檻較低成功率又高的方式。

布拉蕊的電郵門事件

以下新聞為經濟學人的報導（原文網址在http://www.economist.com/blogs/democracyinamerica/2015/03/hillary-clintons-e-mails）。

　　如果你身為美國政府雇員、或正替美國政府工作，那麼使用高科技可能是件痛苦的事，光是一封單純公事上的郵件，可不是隨便一支手機或筆電輕彈一下手指就能寄出去，得要透過一台認證過的機器才行，所以想要如使用Gmail那樣隨時隨地在任何裝置方便迅速的收發e-mail是不可能的事，所以希拉蕊就承認，她沒有使用官方信箱而用個人信箱來寄送公務相關的信件，只是圖個方便而已。

　　如果只是一般公務員就罷了，但問題在於希拉蕊可不是普通的公務員，而是堂堂的國務卿（其地位比一般的內閣部長還要高，堪稱所有內閣成員中的首席，是除了總統歐巴馬之外，繼美國副總統後的第二號人物），在這次事件中，據稱她除了使用Gmail之外，還在紐約郊區的家裏架設了一台私人的郵件伺服器。

　　這樣的作法明顯違反了聯邦政府必須將所有公務相關郵件儲存在官方伺服器的規定，也讓希拉蕊身陷在公務授權與私人雜務不分的麻煩之中，各方的指責聲浪，尤其是來自眾議院的共和黨紛至沓來，逼得希拉蕊昨天在聯合國女性事務發表了主題演講之後，立即舉行一個記者會說明，她認為自己僅是像其他的公務員一樣，用Gmail來收發個人相關的郵件。

　　她堅信自己並沒有逾越相關的法令，此外，她也交付了所有工作相關的e-mails（55,000張的影印紙本），至於其它牽涉到隱私的個人郵件則排除在外，因為她認為有權不公開這些個人資料。

　　這就是為何這個e-mail事件令人感到難堪的地方，因為隱私所以沒有直接證據能顯示有任何不法隱藏在希拉蕊家中的伺服器中，不過她所犯的這個錯誤已經明顯的告訴我們，問題在於她的是非判斷問題，以及一種寬以律己的一種態度。

　　很明顯的，希拉蕊不能也不願公開她所有的個人郵件內容給那些虎視耽耽，企欲將這個事件和2012年駐利比亞外交官被殺害事件牽連在一起的共和黨們，當然或許她的這些私人郵件內容都是無關痛癢沒有害處的，但卻只要她一天不公開就無法證明這點，反而給人一種傲慢的態度：她憑什麼可以不同於其他的公務人員？

　　但對於希拉蕊來說，幸運的是，目前民主黨內尚沒有能與她匹敵的人選，她暫且不會因此事件而損失太大，且很少有專業的政治討論會關心到那些她私人的電子郵件問題，因此這個現在爆發的醜聞對明年2016大選和她的票數影響應該不太大，但是她這種草率的行事作風非但顯露出一種對於政府法規傲慢無視的態度，更另我們對未來感到不安。

─────────────────────────────────────────

　　這篇新聞是相關目前美國熱門的總統候選人希拉蕊在擔任國務卿期間，因為使用私人郵件收發公務信件，而使得她正深陷於不當使用電子郵件的泥沼之中，文章「Poor judgment」直接以標題點出希拉蕊在此郵件事件中的問題，就是她本人缺乏判斷力，雖然目前尚未有直接的證據顯示出這樣的漫不經心造成國家的危害，但透過這篇專欄，讓我們對於此事件有如下的省思：

1.    政府相關人員應意識並體會到，在內部環境工作不比個人領域，為了整體國家安全考量，在資訊科技的使用上都會受到更嚴格要求與限制。

2.    在工作上求方便，是為了圖利自己還是為了公務著想？

3.    身為公務員卻沒有遵循相關法規與準則，違法時間更長達數年，在這期間沒有任何人提醒與處理。

4.    我們對於高官與普通公務員行事準則的拿捏，其差異遠比想像中的還要巨大，殊不知同樣的郵件疏忽，高級官員所造成的危害更甚於下層的公務人員。

　　同樣的，若我們把上面的政府替代為企業也適用，就在去年2014年底發生的Sony影業駭客入侵事件中，少數高層管理者的郵件內容和硬碟檔案成了駭客們折磨羞辱Sony的寶貝，因此，我們需要思考的是，目前金字塔的階層架構是組織內部最常見的類型，然而資訊風險程度卻是與其相反，尤如其下所映射出的三角形倒影，有時縮小、有時巨大、有時清晰、有時隱諱，造成危害最大的往往是頂層少數的階層，資訊人員如何明查這金字塔倒影的真實形像與堅守原則，反而是最大的課題。

談談Apple HomeKit

　　昨天3/9，是全球引領期盼Apple Watch發佈的日子，副總裁Kevin Lynch在即時轉播的現場用Apple Watch示範了如何遠端開啟家中車庫的門鎖，甚至能即時的看見車門開啟狀況，執行這段作業的App是由alarm.com（一間居家安全及自動化的公司）所開發，它結合了Apple Watch與智慧家居平台HomeKit， 勾畫出一個充滿科技與想像力的未來世界，這也讓我們想到發佈已半年多，卻仍猶抱琵琶半遮面的HomeKit。

　　因此讓我們來看看Elyse Betters的文章「Apple HomeKit explained: What is it, and how does it work?」，他在文章中對於HomeKit作了簡要的介紹。

本文內容譯自Elyse Betters 2015/1/22發表於pocket-lint.com網站的文章
「Apple HomeKit explained: What is it, and how does it work?」，並佐以部份其它來源的資訊及圖表。

　　隨著智慧家居的潮流，蘋果也推出了稱為「HomeKit」的智慧家庭平台，期望透過無線方式針對各式家居設備進行遠端控制。

　　雖然蘋果在之前的全球開發者大會上曾揭露了一些相關訊息，但實際上，目前消費者還無法購買到HomeKit的相關產品，不過我們仍期待並且想知道它是如何工作並進行控制的。

HomeKit是什麼？

　　HomeKit不是一個硬體，它是一個平台規範和開發工具框架，因此，它面向的不是消費者而是製造商和開發者，它主要針對的市場是家居自動化這塊領域。

　　蘋果藉由發展HomeKit希望能簡化並統一目前雜亂的家庭自動化市場，方式是建立一個通用的平台讓所有來自不同廠商的智慧物件彼此都能相互溝通支援，同時搭配蘋果的另一項功能「Siri」（語音助手），透過語音操控的方式來控制所有設備。

　　想像一個房子裏頭塞滿了來自不同廠商（如Honeywell或奇異）的智能物件（如燈泡或煙霧偵測器），它們彼此間正進行溝通和合作，而你可以透過iOS設備上的Siri功能告訴它們要作什麼。

HomeKit想要作的便是讓這樣的使用情境更加的友善化。

製造商的支援

　　製造商必須在它們的智能設備中加入對HomeKit的支援，才能被視為HomeKit-enabled產品，此類的認證稱為Made For iPhone（MFi）；當初蘋果在2014六月首度公開HomeKit之後，就已經知會了大部份的製造商，如iHome、海爾、Withings、菲利浦、iDevices、、Kwikset.、貝爾金、Kwikset等等公司相關訊息。

　　第一批HomeKit認證產品剛剛在今年度的CES 2015發表，從智能插座到智能門鎖都有，例如Chamberlain公司的MyQ Smart Garage、Elgato的系列smart sensors、iHome的iSP5 SmartPlug、以及Insteon公司的Insteon Hub。

iOS 8

　　iOS 8內建的HomeKit系統可以引導你從設定和更名所有家中的HomeKit設備以及房間編號，以家庭自動化為前提之下，提供您能夠從遠端來控制每個房間設備的能力，如此一來，就不需要切換不同的APP來操控不同的智能設備，因為iPhone預設就能夠控制所有HomeKit認證的設備。

Apple TV

　　蘋果悄悄的在iOS 8.1和Apple TV 7.0.1版本中加入了HomeKit的支援，因此一些報導皆認為Apple TV將作為Hub的居中角色，讓所有的HomeKit認證設備皆透過Apple TV控管，正如同Google將Nest的智能恒溫器作為智能設備的控制中心一樣。

當我們出門在外時，使用Siri發送命令回家時，它會先經過家中的Apple TV再告知被控的HomeKit設備，不過完整的HomeKit生態一定需要Apple TV作為中介或者是控制中心嗎？目前我們尚無法確認，不過看來，Apple TV若在HomeKit中參一腳，那麼它的角色不僅會像是一個集中所有智能設備的Hub，更像是一個智慧居家網路的入口，負責將指令轉送到各個HomeKit設備，因此這台Apple TV需要擁有個人的認證，也就是你的Apple ID要事先提供給它。

HomeKit如何工作？

定義名稱

　　在HomeKit中的任何物件，例如房子、房間、設備、功能、設定等等，都必須擁有獨立的名稱並儲存在一個共用可被Siri讀取的資料庫中，讓Siri能夠識別使用者語音所要控制的對象。

　　例如，若你分別同時擁有一獨棟透天和一間公寓，那麼這兩間房子必須被指定不同的名稱（例如就叫作房子和公寓，從上表中位於Zone此層中），但不能都同樣被命名為「家」，同樣的，每個房間也必須賦予不同的名稱，注意，在不同的房子名稱下可各有相同的「廚房」名稱，但是，同一個房子名稱下則不能有兩個相同的「廚房」名稱。

　　因此在同一個房子下，這些HomeKit設備會透過您的iOS設備來同步和設定，它們不僅擁有獨一無二的名稱，每項啟用在設備上的功能服務（Service）也需有特定的名稱，舉例來說，當你想要煮一杯咖啡，你可以將咖啡機命名為「Coffee pot」，煮咖啡的功能則為「Brew」。只要Siri能夠識別並匹配您口中的指令和資料庫中預先定義好的各項名稱，它就能夠替你操控相關的設備。

群組

　　可以想像得到，未來對於一些智慧家居的愛好者，他們的HomeKit名稱定義可能會高達數百項，包含了房間、設備以及各項服務功能定義，為了能夠更方便的管理，蘋果的HomeKit提供群組功能，最上層的群組稱為Zones。

　　群組可以讓你透過一個命令便關閉房子裏全部的電燈，換句話說， Siri不需要一個個命令每棟房子裏的燈泡逐一關閉，此外，群組也包含了功能動作群組，稱為「動作集（Action Sets）」或「場景（Scenes）」，所以我們可以分開控制相同或不同種類物件所組成的群體。

　　想像你建立了一個稱為「睡覺時間到了」的場景，並且設定了一些裝置和動作到此場景中（例如房間門上鎖、關閉電燈、設定鬧鈴等等），當你告訴Siri「睡覺時間到了！」時，HomeKit的群組功能將會知會你的智慧門鎖、智慧燈泡、以及鬧鐘去作設定的動作（注意此群組功能並沒有特定的順序）。

安全性

　　依蘋果的說法，HomeKit有提供穩私及安全性的設置，以預防並避免裝置被誤用。

　　具體來說，HomeKit在裝置與iOS設備之間具有點對點的加密（end-to-end encryption），而它所釋放給開發人員的HomeKit API中也要求，針對智慧型設備所開發的App，除了蘋果原廠，其它第三方廠商皆必須限制App僅能在前景執行，也就是說，它不能偷偷摸摸的在背景執行，必須讓使用者明確的知道目前那一個App正在控制家中的設備。

網路協定內容

　　HomeKit的協定稱為「HAP」(HomeKit Accessory Protocol)，它主要是運作在BLE/Bluetooth Smart藍牙協定之上，但也可支援HTTP/TCP/IP，如果一個設備不支援HAP，那麼它就需要一個橋接設備的支援（後文會提到）。

HomeKit何時會正式開始？

　　HomeKit在去年（2014）秋天隨著iOS8在發表會上亮相，但它一直沒有被正式的推出過，蘋果僅先釋出相關資料給一些相關的合作夥伴，如HomeKit配件製造商或晶片開發商，讓他們在這段等待期間可以先開發或升級相關支援HomeKit的產品。

　　在剛剛結束的CES展上，大部份HomeKit認證的產品尚未開始販售，因此蘋果的HomeKit居家智慧平台其實還沒正式開始，我們也不確定那一家廠商會先量產搶先進入市場，大部份他們的說法都是「快了」、或者是「今年春季左右」。

有官方正式的App出現了嗎？

　　目前還看不到任何的HomeKit App。HomeKit看來會是一個iOS 8的背景服務，透過Siri或點擊地圖上裝置的所在位置，就能直接或間接的來控制它們。

關於橋接設備

　　蘋果宣稱將會開放那些使用ZigBee或Z-Wave的非HomeKit認證設備也能相容於HomeKit。

　　在去年蘋果提到，那些非HomeKit認證的產品也有機會透過Bridge方式連到HomeKit，但截至目前為止尚未有更明確的說明，但我們猜想，這種橋接設備應可協助非HomeKit設備連到iOS平台，讓它們也能接受HomeKit的Siri命令。

　　這類的HomeKit橋接硬體會使用HAP協定與iOS連線，然後再透過非蘋果官方的其它協定（如ZigBee或Z-Wave等）與其它非HomeKit設備溝通，不過蘋果對於這種透過橋接硬體的方式還是給了一些限制，例如它僅接受Bluetooth LE的設備，卻排除使用Wi-Fi連線的裝置，像是Google旗下的Nest Thermostat（恒溫器）。

　　蘋果排除對於Wi-Fi設備的橋接很明顯的是出於安全的考量（因為駭客很容易透過Wi-Fi侵入）；此外值得一提的是，這些橋接器可以堆疊，也就是橋接到另一台橋接器讓它可以支援更多數量的設備，每一部橋接器能夠同時連線到100個被控裝置。

除了HomeKit還有其它的選擇嗎？

　　蘋果的HomeKit目前來說沒有明顯的對手，Samsung有一個稱為「Samsung Smart Home」的家居自動化平台，但也是在2014上旬剛推出，它有一個極為漂亮的平台外觀，和一個稱為SmartThings的App（SmartThings於2014/8被三星以2億美元收購），可以把你的手機變成家居智能設備的遠端遙控器。

　　除了Samsung的SmartThings之外，蘋果也需要注意一下Google，這家來自山景城的公司在購併了Nest Labs之後，有極大的潛力顛覆HomeKit並且一統智慧家居市場：

Nest Labs

Nest Labs被Google以32億美元購併是去年（2014）物聯網的大事，也讓Google擠身跨入了智能家居市場的賽局，雖然這家公司的產品不多僅僅只有兩種：智慧型恒溫器和智慧型煙霧偵測器，但光這兩樣智能設備就已讓它名聞國際，像這個智慧型恒溫器，它標榜能省下5%不必要的能源浪費，而且隨著時日前進，它會自動記下你所喜歡的溫度、在什麼時間點會想要什麼樣的溫度，並且會注意到您外出旅遊之類長時間不在家的情況。

　　2014年六月，Google隨即發表了「Works with Nest」的開發者計劃，提供一系列的API給製造商讓他們應用在智慧型產品中，讓使用者能夠透過Android遠端連接及控制，並且與Nest和Google相關的產品整合。

不過，如果我們有注意YouTube上相關Nest產品的影片，或者連上Nest開發者頁面，都看不到Google或Android的相關資訊，這是因為Google希望把Nest這個品牌獨立區隔，讓它能夠單獨的面對客戶（因此相信Nest最終也會支援蘋果的HomeKit）。

Swift Auto Layout

    目前蘋果最新的機型是4.7吋的iPhone 6以及5.5吋的iPhone 6 Plus，如果再加上舊的機型如3.5吋的iPhone 4（含更舊的3, 3GS等）、4吋的iPhone 5，再加上原本9.4吋的iPad系列機型，隨著蘋果逐漸導入更大螢幕的手機，似乎長期以來一直困擾著Android開發者的螢幕尺寸問題也開始漫延到iOS，成為開發者的夢魘之一。

    不過如果我們攤開iPhone歷屆的機型來比較，會發現從型號5開始是一個分水嶺，iPhone 4S（含）之前的舊機型螢幕尺寸都是3:2，而從iPhone 5開始則都是接近16:9的比例，因此對於iPhone來說，雖然螢幕愈來愈大，但其實只有兩種尺寸大小：舊型的3:2與新型的16:9。

　　至於iPad，則無論是從最舊的第一代iPad到最新的iPad Air 或iPad Mini Retina，它們的螢幕尺寸比例皆維持在4:3，因此，對於iOS開發者來說，要開發同時適用於iPhone與iPad的APP，要應付的螢幕只有三種：3:2、16:9、4:3，這比起Android開發者來說輕鬆了不少。

點（Points）與像素（Pixels）

    App開發者在設計與溝通時應該要用的是「點」概念，而非「像素」，每個點單獨對映到一個像素（非Retina）或二個像素（Retina）視設備的解析度而定，例如，對於320點x480點這個2:3的螢幕尺寸而言，它適用於前述的4S（含）以下的機型，320點x568點（接近9:16）則適用於5（含）更新的機型，而我們在編排畫面物件時，只要考量「點」的比例即可，像素的轉換則由iOS替我們處理，若為Retina螢幕自動將點以及圖片顯示長寬乘上2。

所以，在設計iOS APP時，我們只要針對兩種規格比例，並且加上「點」的概念去設計畫面佈局，就可以讓程式同時適用於iPhone與iPad（這類的App稱為Universal），而不同尺寸圖片無法無中生有，所以在開發App時我們還是必須分別提供不同的解析度圖片（例如在檔名後方加上「@2X」代表for Retina使用），Android也是採用類似的方法，但是更為複雜，因為它有六種不同的解析度定義：dpi、mdpi、hdpi、xhdpi、xxhdpi以及xxxhdpi，開發者若想支援全部的解析度，就必須將不同大小的圖片放置於該六個資料夾下。

關於Auto Layout

    為了因應未來尺寸的多樣化（可能是考慮到Apple Watch、TV、HomeKit…?），從Xcode 6開始有了Auto Layout這個功能，它是一種以約束條件（Constraints）為基礎的佈局系統，目的是讓開發者能夠方便快速的建立適用於不同尺寸、橫向或直向等螢幕的APP，就像目前網站所流行的Responsive Design一樣，能夠自動適應不同尺寸的裝置。

　　那什麼是「以約束條件為基礎的佈局」呢？就是我們給予佈局中的元件設下各種條件與限制而非固定的像素值，這樣可使得它們依照著這些限制呈現出理想的相對排列，而非絕對的固定顯示於某一處，因此，舉例來說，如果我們要將一個按鈕擺在螢幕正中央，那麼它的兩個約束條件就是：水平置中與垂直置中。

    對於一個元件來說，它會有15種約束條件，即三種尺寸 x 五種位置：

    三種元件的尺寸

以約束條件方式來思考一個元件在螢幕上的尺寸，它會有三種情況：

• 固定尺寸的長和寬
• 固定尺寸的長和彈性縮放的寬
• 彈性縮放的長和固定尺寸的寬
• 彈性縮放的長和彈性縮放的寬（不列入）

最後的「彈性縮放的長和彈性縮放的寬」不列入的原因是這樣的尺寸比較特殊，它代表了無論放置在任何母元件中，它都會自動會伸展到跟母元件一樣大，因此它只適用於Scrollview元件（一種滾動不定長度的view，可用來收納其它元件）。

五種元件的位置

• 在母元件的正中心
• 靠上方排列
• 靠下方排列
• 靠左側排列
• 靠右側排列

想像一下，當下方的藍色元件的限制是：「彈性縮放的長和固定尺寸的寬」加上「靠右側排列」，那麼它會排列如下，無論螢幕尺寸大小或直擺橫放，佈局結果皆相同：

　　

在Swift中使用Auto Layout

當我們在Xcode中開啟了一個新專案，預設便已經把Auto Layout和Size Classes選項打開了，因此你會注意到StoryBoard 的編輯畫面尺寸接近正方形，與以往接近iPhone尺寸的長方形不同，代表開發出的APP將適用於所有的Apple裝置。

尺寸類別（Size Classes）是iOS8新導入的類別，它可以讓開發者使用統一的Storyboard來開發不同的APP UI，如果我們改為不選取而disable它，那麼，Xcode就會要求我們選擇一種裝置型號（iPhone或iPad），並將Storyboard變更為其大小。

在右下方如紅圈所示，就是Auto Layout選單，所有的layout設置都收納在這選單中。

• Align：建立對齊的約束條件，像是對齊兩個元件的左側
• Pin：建立間隔的約束條件，像是訂出UI控制的寬度
• Issues：解決佈局的問題。（Xcode發現有問題的佈局時，會自動提示）
• Resizing：指出尺寸如何影響約束條件。

不錯的Auto Layout教學

    我推薦可以先看看http://www.raywenderlich.com/83276/beginning-adaptive-layout-tutorial這篇基礎的實作教學，再看這兩篇：http://www.raywenderlich.com/83129/beginning-auto-layout-tutorial-swift-part-1與http://www.raywenderlich.com/83130/beginning-auto-layout-tutorial-swift-part-2。

　　在第一篇作者首先演示了傳統不使用Auto Layout會造成的問題，造成必須額外加入指令來修正，之後再透過Auto Layout功能實作則能夠完美的排列。

    作者提到這種以約束條件進行的佈局稱為「Designing by intent」（依意圖來設計），意指考慮的不是物件的實際位置，而是以物件相對於其它物件的位置的限制條件，例如以往我們會如此設計：在左側的(20, 230)的位置，若改以限制條件的設計，就應改為：在母元件中垂直置中，距離母元件左側邊緣20點的距離。

    另一個Auto Layout的好處是，它對於App的國際化設計有幫助，舉例來說，不同的語言詮釋一樣的文字時會有不同的長度，以「加入」這個詞彙來說，用中文與英文（Join）可能只需要15點寬度的Label就夠了，但改為德文（beitreten）就需要兩倍30點的寬度，此時，Auto Layout就發揮作用了，它會在不影響佈局的情況下自動擴展排列。