作者：徐寅（博客,微博）

又是一年的WWDC，如同朝聖一般的大家又是早早就在舊金山 Moscone Center 門前排起了長隊。作為第二年參加WWDC的我已經不如其他開發者呢麼激動，提早一天就來排隊（其實只是懶而已￣口￣）。但托肅羽大神的福（前一天晚上9點就來排隊的大牛人，雖然他也是第二年參加，但熱情不減當年），得到了非常靠前的位置。我自己凌晨四點半到了現場，排到10點。最後在Keynote坐到了第四排，基本就在舞台底下看了這一場開發者的盛宴。

總的來說今年iOS9 和 El Capitan 對用戶們來說的驚喜並不太多，可能分屏是讓我覺得最有用的新功能（也有不少朋友說晃鼠標那個是最有用的。。哈哈）。但是其實作為iOS工程師來說新的內容真的還不少，而且很多都是讓人挺期待和興奮的。這裡就把幾個我個人認為很Cool的新內容做一個簡單的介紹。可能等WWDC結束後有時間再把其中幾個點拿出來仔細的講解下。（估計會因為得了一種叫做懶的病而賴掉不寫）

App Thinning

我把這個放在第一個是因為，在3，4個版本之前Gogobot才給自己的iOS App做了減肥工作，去除所有不必要的Assets和Library，刪除了大量的legacy code，把所有能Minify的JPG和PNG文件全部做mini處理，不同顏色的icons基本只留一個用Code來上色，等等等等。做了很多努力才把，已經肥胖到直逼“非WIFI網絡下可下載的臨界點的“App從94mb減肥到43mb左右。所以我深知App體積已經成為App開發者的麻煩。

在iOS設備碎片化日趨嚴重的情況下，App裡的Assets需要支持各種分辨率，還要為新舊設備的32bit和64bit做准備。也許Apple自己也意識到App的體積普遍變得臃腫，總算是時候給所有App減減肥了。

1. App Slicing

如同上面提到的，現在App中的Assets必須支持1x 2x 3x的分辨率，但其實每種設備能用到的分辨率就只有一種，為什麼要讓只需要3x分辨率的設備去下載2x和1x的Assets？為什麼要讓只能run 32bit的設備下載64bit的Architecture？

有了App Slicing，只要開發者在開發的過程中使用了Asset Catelog並且在裡面加入了正確的Asssets。 比如：

新的Xcode7和App submit之後會對這些1x 2x 3x分辨率的Assets做一定的處理，讓用戶在下載的時候只下載自己所需要的Assets，這樣至少可以在Assets上減掉很大一部分的體積。同時用戶下載的時候只會下載到自己設備所需要的Architecture，32bit或者64bit。這樣又能減小App的實際體積。

其實還有一個方法可以近一步減小體積，但並不是每個App都會用到。就是在Asset catalog中的內容可以按照不同的設備來決定是否下載。 

這個可能沒有比前一條來的適用面廣，但是也提供了一個很好的選擇。比如一些大型的游戲或者有3d模型的軟件。完全可以根據用戶設備的性能來提供內容。

2. On Demand Resource

這一條就相對容易理解一些，目前大部分App都是把需要的內容和數據全部封裝在App裡面，讓用戶一次下載到所有需要的內容。我相信很多做游戲的朋友已經知道，這個完全是沒有必要的。很多游戲在初期下載只會下載游戲必要的內容，在游戲進行的過程中才會動態的下載更多的內容。

但是在以前的setup裡面，一般我們都需要自己建立server去host那些以後需要用到的resource，然後在用戶到一定的階段就開始多線程下載所需要的resources，然後做一定的處理。而現在Apple用他們自己的server來幫助App實現這個功能，不再需要繁瑣的server端的設置，只需要簡單的在Asset catelog裡面把內容加上各種tag，就可以簡單的實現這個功能。提交App的時候可以全部打包一起提交，剩下的工作Apple會幫你完成。

並且在target界面多了一個Resource Tag。可以簡單的管理所有Tag過的Resources。

我因為目前還沒有時間去仔細測試這個功能，但是從很多WWDC Session裡的Demo看來非常promising。

不論最後采用什麼方法，讓App的體積變小是一個非常有必要的工作。可以從一定程度上提高App的質量。雖然不是所有用戶都會在他們下載App之前去仔細看一個App的體積，但是一個App的體積決定了下載所需要的時間。根據不是特別完全的調查，如果下載時間過長，會讓用戶失去立刻打開這個App的興趣。這樣你在不知不覺中就損失了潛在的pro用戶。

App Deep Linking

不知道現在還有多少開發者對Deep linking陌生的，因為“不約而同”的Facebook, Google, Twitter, Apple都開始關注和推行App Deep linking。從之前公布的Facebook的App linking，Twitter的Twitter cards，到最近Google公布的App index，然後到WWDC上Apple公布的Spotlight search。都是Deep linking的一種形勢。

從幾個版本之前Gogobot已經開始對Deep linking做很多處理，從邀請朋友加入App，到分享Postcard，Place of Interet，weekly recommendation，等等。

這次WWDC公布的iOS9中的Spotlight和Safari搜索可以直接搜到App內部的內容，Apple提供了讓用戶更容易找到他們想要的內容，哪怕這個內容是在某個App內部的，從而提高App的使用度和曝光度。根據WWDC上Apple自己公布的數據，用戶有86%的時間花在App中，僅有14%的時間花在Web上。所以提高App的曝光度和使用度可以大大的提高用戶的粘度。

從目前公布的內容上看，他們公布了幾個實現這個功能的API，比如“Core Spotlight”，“NSUserActivity”，"Web markup"。

1. NSUserActivity

其實NSUserActivity並不是一個新的概念，在iOS8中就已經使用它來做Handoff，在iOS9講User Activities變的可以搜索，並且可以在每個Activity裡加上Index用的Metadata。但是只能用在用戶訪問過的或者看見過的內容中。

一旦某些內容被記錄進NSUserActivity，就可以在Spotlight和Safari中同時被搜索到。而且還能通過設置'Eligible For Public Indexing'來讓這些被Index的內容傳到Apple的雲端Cloud Index裡，從而實現每個用戶都能搜索到這個內容。同時Apple也強調了隱私的保護。並不是所有內容都是Public的，同一個內容需要在雲端被Index超過一個限額（具體多少沒有公布），才會最後成為Public的內容。所以用戶不用擔心自己看到的內容成為公眾都能搜索的內容。

更好的是，一旦App中的內容被越來越多的Index之後，能夠獲得Siri Suggestion和Siri smart reminder功能，當然還有iOS8目前就有的Handoff功能。可謂是一舉多得的一個做法。

2. Core Spotlight

Core Spotlight是iOS9全新的一個Api。這是一個相對簡單的概念，允許App在Device本地Index大量的可搜索的內容，類似一個數據庫一樣。可以添加/修改/刪除Index的內容。一般會是推薦App內用戶的文檔，圖片，信息，等等內容。

通常可以在內容生成的時候就應該Index，而且Apple還為數據量較大的內容提供了batching的index方法。

3. Web Markup

最後是Web markup，比如網站上的內容，如果在App中也有的話，在搜索中可以直接顯示App的信息。

Smart banner

Apple推薦在每個相關網頁中都加入一個Smart banner，比如： 

因為Apple已經建立了一個叫做Apple bot的爬蟲在識別的各個網站內的內容，如果同時有Smart banner的話，Apple就會記錄下這個Banner內的信息，當用戶搜索相關內容時就能直接看到這個Banner。

Standards-based Markup

除了Smart banner還可以使用Apple認可的標准格式Markup，比如schema.org或者Open grahp的結構。這樣的好處是可以在每個頁面顯示更豐富的內容，讓用戶更直觀的看到App中的內容。

Universal Link

在iOS9中，開發者可以在自己的App裡加入一個App相關的域名'com.apple.developer.associated-domains'，然後在網站中的'apple-app-site-association'文件中加入一個相關的JSON（詳細信息參見：Apple iOS9 Search Universal Link Documentation）。

這樣用戶在打開某個鏈接時，如果他已經裝有相對應的App，會利用App中設置過的Handoff機制自動打開App中的內容。即使他沒有裝App，也會順利的進入Safari打開原本應該看到的網站。也是一個通過原本打開網頁，而現在可以直接打開App的方法，給用戶更好的體驗，從而提高App使用度和曝光度。

Apple在WWDC關於搜索的Session裡面最後還推薦了幾點去完善搜索體驗

• 在NSUserActivity和Core Spotlight的兩種Index方法中，不論哪種，開發者都會需要提供一定的Keyword，Apple推薦每個Index的內容至少需要2-5個Keyword。並且要關注縮寫和別稱等等。

• 在兩種不用Index方法裡，相同的內容要使用相同的Unique ID。

• 在Deep linking 到App裡面之後盡量直接顯示內容，Apple會分析用戶點擊鏈接後點擊次數和內容來提高和降低搜索結果的評分

• 在搜索的結果中加入必要的action，比如電話，路線，短信等

• 在搜索額結果中加入合適而且好看的圖片，詳細的信息，等。

由於篇幅關系，決定把內容分為兩塊，下一篇中將介紹新的Watch OS，UI Test，和Swift 2.0。