Google I/O 2015大會上提到的App Links到底是什麼鬼？

科技

2015-06-01 |

2006

Google I/O 2015 都看了吧？

我所期待的Chromecast的硬體更新和Google Cast協議的新特性都沒有看到，有點小失望。但是，我注意到了Android M支持了一個新特性：App Links。

在大會中現場演示了這個協議的應用場景：點擊電子郵件中的 Twitter 鏈接，會自動調用 Twitter 應用。也許有人根本沒有注意到這個feature，但是這個小feature對優化安卓生態上的用戶體驗，對Google做移動App的應用內搜索來說，都有著巨大的意義。

App Links是什麼？

說App Links，就不得不先說一些背景知識。

在PC瀏覽器時代，由於HTML標準的存在，不同網站的內容相互鏈接是一件非常簡單的事情。進入移動互聯時代後，PC瀏覽器的使用逐漸減少，瀏覽器不再做為主要的資訊傳遞和交換的方式，人們停留在移動App上的時間越來越多，內容在App內產生和消費的比例也越來越大。但是，每個App都是獨立的，你必須打開不同的客戶端消費不同的資訊類型，否則就只能跳轉到體驗非常不好的Web頁上（我能說有些心胸狹隘的廠商甚至連跳轉到web都不允許嘛……）。

這就像一個個「中世紀的古堡」，資訊被圈在「城堡」內，各自獨立，難以相互流通交換。最噁心的是，做不同的事情要去不同的「古堡」，甚至，做相同的事情也要去不同的「古堡」，比如看視頻。有沒有能夠在不同「古堡」間瞬間移動的」隨意門」呢？

有需求就有解決方案，無論是大公司還是創業團隊很早就注意到了這個問題，各自拿出了自己的「隨意門」方案。筆者2014年時瞭解到的就有：

Google的App Indexing；

Facebook的App Links（於2014年的F8開發者大會上發布）；

Apple的smart app banners（僅支持web到app）；

URX的OmniLinks；

Quixey的AppURL（僅支持web到app）；

Tapstream的Defferd deep links；

百度的應用內搜索；

豌豆莢的應用內搜索。

可以看得出來，雖然方案很多，但是還沒有形成統一的標準，處於跑馬圈地階段。直到這次Google把App Links作為Android M的內置標準，再加上親爹Facebook的全力支持，這個行業的標準事實上也就形成了。

怎樣支持App Links？

App Links的原理很簡單，就是App把自己在不同平臺下的跳轉規則一併告訴對方，對方是什麼平臺就按什麼平臺的規則去處理。如果對方沒裝我們的App，那我就告訴它一個安裝地址。如果對方平臺的電子市場裡死活就是沒有我們的App（你說的是WP麼），那麼就只能跳轉到Web了。

怎麼告訴呢？當然是利用HTML標準裡的標籤。一個實現了 App Links 的網頁大致是這樣：

注：以下代碼引用自知乎

Hello, world!

上面的代碼只是幫助讀者建立簡單概念，App Links遠遠不止於此，Facebook還制定了更詳細的標準，比如fallback、數據傳遞、UX 建議等等。

如果想深入瞭解，請移步這裡。

App Links的意義

App Links最大的意義當然就是用戶體驗的改善了，這個不言自明。

但我想說的是，App Links其實是應用內深鏈的標準，有了這個標準，封閉在App孤島內的資訊會重新被聯繫起來，並且被搜尋引擎檢索利用。可見它對於搜尋引擎巨頭有多麼重要，所以Google制定了自己的App Indexing。新的Android M決定向Facebook的App Links開放相容，表明Google拆除了這道籬笆，擁抱開放。