作者：盧克

一.Handoff的基本常識

iOS 8以及Mac OS X Yosemite之後引入了一個新的功能特性：Handoff。Handoff也就是Continuity特性，連續互通，比如你用iPhone寫郵件寫到一半想在Mac上繼續寫，或者Mac上看到一個網頁想在手機上浏覽，這些便是Handoff的使用場景了。

Handoff的支持有一些硬性的要求：

• 互通的所有設備必須支持 Buletooth LE 4.0，Handoff使用BLE信號來傳遞用戶活動數據。

• 設備處於聯網狀態，有時候有些數據還是會通過互聯網來傳遞的，比如Mail App的郵件內容的同步。

• 所有設備必須連到同一個iCloud賬戶。

• 當然你還得保證當前設備的Handoff功能打開了(iOS:設置->通用->Handoff 與建議的應用程序。 Mac:系統偏好設置->通用,倒數第二欄有個選項,"允許這台Mac和iCloud設備之間使用Handoff")

BLE並不像傳統的藍牙，並不需要人工手動進行配對，只要打開就行了，所有的配對數據傳輸都是自動完成的；設備並不一定需要連在同一個WIFI網絡中，Handoff的活動數據通過BLE進行傳遞，保證及時性以及數據的安全性，你可以在使用過程中嘗試將WIFI或者網絡關閉，設備還是可以接受到Handoff的通知的。

蘋果已經對很多內置的App做了Handoff支持，如Safari浏覽器，郵件，電話，消息，提醒事項等都是支持的，在你開始Handoff編程之前可以先使用這些App進行Handoff功能的體驗。

二.iOS App 到 Web Browser

Handoff編程的核心類便是NSUserActivity了，代表著一個用戶的活動，每一個Activity都有一個activityType，用來標識Activity的類型。當App 到 App之間進行Handoff的話，那麼接受方需要滿足幾個條件

• App必須是通過發布證書或者開發者證書進行打包的

• 和發布Activity的App擁有相同的TeamID

• info.plist中聲明了接受的Activity的activityType(key 為 NSUserActivityTypes)

不過很多應用其實也只是在移動設備上有App，在Mac上絕大多數還是走的浏覽器，所以iOS App和浏覽器的Handoff的需求就變的很常見了。這個時候Activity的另一個叫做webpageURL的屬性便有用武之地了，當沒有合適的App能夠處理當前的Activity的話，系統會轉給默認的浏覽器進行處理（當然你的這個默認的浏覽器的info.plist的NSUserActivityTypes數組中必須聲明了 NSUserActivityTypeBrowsingWeb這個type，目前Mac版本的Chrome已經支持了）。

self.myActivity = [[NSUserActivity alloc] initWithActivityType: @"com.taobao.handoff.act.home"];
self.myActivity.webpageURL = [NSURL URLWithString:@"http://www.taobao.com"];
[self.myActivity becomeCurrent];

當上面的代碼執行之後，Activity便會進行分發，接受者接受後，若沒有App能夠處理當前類型的Activity的話便轉交給默認的浏覽器去處理了，這裡需要特別注意的就是activity的生命周期，當activity被invalidate或者被釋放了，那麼這個Handoff消息也就消失了，相關設備的Handoff消息就會消失。

關於Handoff的調試，由於到目前為止模擬器還是沒有支持Handoff的，所以你必須使用開發者證書進行真機調試。

三.Web Browser 到 iOS App

相比於App到Web Browser，Web Browser到iOS App的Handoff實現起來就復雜一些了。首先先描述下大體的流程：

1. 首先在Mac上使用Safari浏覽器浏覽目標網站，Handoff消息會通過BLE進行分發

2. iOS設備接收到Handoff消息後，檢查對應的webpageURL，看是否有某個App的associated-domains （entitlement中的一項）中包含了這個webpageURL, associated-domains對應的Handoff的配置URL樣式為 activitycontinuation:example.com

3. 如果某個App的associated-domains存在相應的webpageURL,那麼iOS會去這個網站的固定的一個URL（地址為https://example.com/apple-app-site-association）獲取一個簽名過的文件（源文件為一個JSON文件）,如果解密後文件中的App IDs中包含了 之前匹配的App的App ID，那麼這個Activity便交給這個匹配的App進行處理。

下面講解詳細的操作步驟

1.客戶端

首先當然還是折騰客戶端工程，當你創建好工程，創建好App ID，XCode中設置好自己的Developer賬戶之後，你便可以設置編譯的Code Sign的相關東西了，配置都得選自動的，這樣就可以通過XCode來管理配置 App ID 以及相應的 Provisioning Profiles了，當你通過developer後台網站就可以看到Provisioning Profiles中有一堆所謂的Managed by Xcode的條目了。

你需要在XCode工程對應的Target的Capabilities這個Tab中開啟Associated Domains，這個時候時候你可能會遇到錯誤提示“You must be a team admin or agent in order to enable this capability.”,其實即使賬戶是admin還是會報錯，這個可能是XCode的bug吧，你需要切換到General這個tab中將Team先選None，然後再切換到你對應的Team，這個時候Team下方顯示錯誤了，其實就是你更改了Entitlements，而這個和Provisioning Profiles有關聯，所以你的Provisioning Profiles也需要重新更新，點擊Team下方的Fix Issue按鈕，等待重新下載新的Provisioning Profiles，然後回到Capabilities這個tab你會發現剛才的錯誤已經不見了。

其實Capabilities中的操作除了會在本地生成entitlements文件，還會同步到developer後台去，會修改app對應的App ID的配置，以及在developer後台生成新的Provisioning Profiles。這些東西都和打包簽名息息相關。

接著在Associated Domains下加上所需要支持handoff的domains

activitycontinuation:taobao.com

activitycontinuation是服務名，taobao.com是支持的域名當Mac上的浏覽器訪問一個網站的時候，此網站的域名如果被某個App的Associated Domains包含了，那麼Handoff底層會去這個域名一個指定的路徑下訪問一個文件，這個指定的路徑便是 : https://taobao.com/apple-app-site-association ,這個路徑需要返回一個簽名過的文件數據，裡面指定了當前網站所支持Handoff的App ID們，這個下面會提及到

2.服務器端

需要進行Handoff的網站，需要在https的特定的路徑下放一個簽名過的文件，這個文件裡面指明了Handoff支持哪些App（Domain-approved apps IDs），這個文件的明文為JSON格式,在對JSON文件簽名前最好去掉所有無用的空格以及檢測下JSON格式的正確性，避免後面帶來問題

{"activitycontinuation":{"apps":["XN6U3EV979.com.taobao.handoff"]}}

簽名則是使用網站的ssl的私鑰以及證書進行簽名（如果不存在中級證書，那麼中級證書可以去掉）

cat json.txt | openssl smime -sign -inkey taobao.com.key
                             -signer taobao.com.pem
                             -certfile intermediate.pem
                             -noattr -nodetach
                             -outform DER > apple-app-site-association

生成的文件放到網站根目錄下以及確保可以通過指定的路徑進行訪問。

3.如何進行本機調試

要想在開發機器上進行網站的Handoff的調試則首先的問題就是SSL證書，你需要自己搞一個CA證書，在Mac上可以通過Keychain Access(鑰匙串訪問)這個App中的證書助理來生成 。

首先是CA證書,這裡生成的是自簽名的根證書，CA證書的作用就是給網站的SSL的證書進行簽名用的，然後創建網站的SSL證書,一步一步走下去，然後通過剛才的CA證書進行簽發，這樣生成的證書就可以直接用於網站的SSL證書了。

然後選擇一個Web Server，我這裡選用的Jetty，直接下載下來然後就可以直接使用自帶的demo了，主要是需要自己配置下SSL。

將默認的ssl配置拷貝到demo工程相應的目錄下 Luke@LukesMac:~/Workspace/jetty ? cp etc/jetty-ssl.xml demo-base/etc/ 

從Keychian Access中導出之前生成的證書文件，導出格式為p12，這樣就會包含私鑰了。假設導出文件為 lukesmac.p12,導出時候 需要你設置一個密碼，你就將其設置為 keypwd 然後需要將這個p12文件導入demo工程的keystore文件中，默認在demo工程的etc目錄下已經存在一個keystore文件，直接導入這個keystore

keytool -importkeystore -srckeystore lukesmac.p12 -srcstoretype PKCS12 -destkeystore keystore

默認keystore的密鑰庫口令為storepwd,導入的過程中你還需要輸入你上面設置的私鑰密碼（因為jetty-ssl.xml中配置的私鑰密碼以及默認keystore中的私鑰密碼默認為keypwd ,所以為了方便上面導出私鑰所設置的私鑰密碼保持一致為keypwd）。最後你還需要在demo工程的根目錄下的start.ini中加入一行

etc/jetty-ssl.xml

然後你就可以開開心心的啟動了，

Luke@LukesMac:~/Workspace/jetty/demo-base ? java -jar ../start.jar

然後我便可以通過 https://lukesmac.local:8443/ 進行訪問了

下面需要將json.txt進行簽名，

首先你需要從上面導出的p12文件中搞出私鑰文件，再從Keychain Access中導出一份證書的cer文件

openssl pkcs12 -in lukesmac.p12 -nocerts -out privateKey.pem
cat json.txt | openssl smime -sign -inkey privateKey.pem -signer lukesmac.cer -noattr -nodetach -outform DER > apple-app-site-association

將生成的apple-app-site-association文件放到 demo工程的ROOT目錄下，然後重啟以及在浏覽器中對這個文件進行訪問測試。

這個時候你以為一切就緒了，發現手機上handoff的圖標依然是safari，打開後發現，網頁根本無法打開，其原因就是自己生成的自簽名的CA證書不被信任，這個時候你可以講CA證書按照cer的格式導出，然後通過郵件發送，在iPhone上的郵箱App中點擊這個cer的附件，系統會跳轉到設置的描述文件的界面去，你需要進行安裝證書，之後這個CA證書簽發的SSL證書對於這台設備都是可信任的了。

最後就是客戶端添加處理邏輯了，可以在Appdelegate中添加如下方法，就可以對傳遞過來的userActivity進行處理

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray *restorableObjects))restorationHandler NS_AVAILABLE_IOS(8_0);