1. 真實世界的需求
如果是在Web世界中，要跨越好幾個的網站服務其實是很簡單的，一個href就搞定了。但對於手持裝置中的APP，其實是很困難的，例如您要從A應用服務呼叫B應用服務起來，甚至要達成Deep link，您就必須了解對方程式的呼叫方式，甚至連相關參數的呼叫方式都需要很清楚，但世界上有幾億個應用程式，我怎麼可能知道每一個應用服務的呼叫方式?而這就是APPLinks想達成的目的，讓用戶可以在各應用程式間相互呼叫，就如同網頁一樣好用，於是他們推出APPLinks
2. APPLinks 幾個重要觀念
(1) APPLinks是一個標準，這個標準說明了如何打開其他應用程式的方式，基本上您只要遵守這個標準，理論上所有應用程式都可以相互呼叫
(2) APPLinks的標準定義在網頁上，但這不代表您一定需要對映的網頁服務，您所需要的只是要有一個網頁去定義APPLinks所需要的標準內容即可，而非真的需要這個內容服務，因為目前Facebook有提供此服務，您可以省略網站設計的步驟
(3) APPLinks並沒有替代現有的 URL Scheme技術，他只是在URL Scheme這個技術之上，定義了互相呼叫的溝通標準
(4) APPLinks目前有一些Open Source SDK可以用，可以直接套用在APP中
3. APPLinks 的運作邏輯
(1) 在網頁或Facebook提供的網站服務上定義APPLinks所需要的Meta Data
(2) 在APP服務上加入APPLinks SDK
(3) 當用戶在某個已安裝的應用服務上點即某個APPLinks支援的連結，該APP會送出內容請求至(1)中的網頁(SDK有支援)，這個請求稱為APPLinks In
(4) 若APPLinks In成功，將取回該網頁內容中的Meta Data，並進行解析(SDK有支援)
(5) 解析成功後，將解析出來的URL Scheme拼湊出來，並觸發URL Scheme(SDK有支援)
(6) 若此URL Scheme無誤，就可以順利將呼叫對方的APP起來，並完成必要的Deep link(Optional)
4. 個人想法
(1) 目前這只是Facebook一廂情願在推動的標準，就技術的角度來看，是可行的，因為他們根植於現有的URL Scheme技術之上，並沒有推翻過去的技術
(2) 除了配合Facebook之外，我仍懷疑這個技術是否會被普遍支援，主要原因是目前APP很難完全避免閃退，如果您想在多個APP內切換，個人認為閃退機率只會提高，這可能會嚴重影響使用者體驗
(3) 另外就是，在多個APP內跳躍，在使用者體驗上其實也是很奇怪的，網頁之所以可以，因為在操作上只是在多個頁籤間切換而已，但APP卻難以如此連續，再怎麼樣都會有跳離感，而造成操作上的不便
5. 結論
(1) 如果您的APP服務，高度依賴Facebook，由於Facebook目前有支援APPLinks，建議可以採用APPLinks + URL Scheme，應該會有幫助
(2) 但若您的目的不在於將Facebook APP的流量引入您的APP，甚至希望未來可以走向大同世界，各APP可以自由的相互串連，我建議您還是觀望為佳
另外一個很相近的技術是Google App Indexing，目前也在測試中，有空再跟各位分享
留言列表
