Firebase App Indexing--谷歌的應用內搜索
在上一篇文章中，介紹了 AppleSearch API，分別是：
- NSUserActivity API：索引應用的某一頁，默認為僅可本機檢索，可設置為public
- Core Spotlight API：索引應用的內容，僅可本機檢索
- Web Markup API：索引網頁內容，默認所有用戶都可檢索
移動領域Apps的流行，讓信息被分散在不同的地方，用戶不再像PC時代那樣，把搜索作為互聯網生活的入口。這些被分散的內容，有必要重新『彙集』起來嗎？蘋果給出了肯定的答案，那Google呢？
同樣是肯定的答案，作為傳統的搜索引擎，Google 的思路很簡單，就是增強Google搜索的能力，讓它不僅僅能檢索到傳統的網頁內容，還能檢索到應用內的內容，甚至能檢索你產生的內容，核心的理念就是：Indexingapps just like websites. 基於這個理念，Google 推出的應用內搜索方案是 FirebaseApp Indexing（前身為Google App Indexing）。
Firebase App Indexing 簡介
Firebase是Google I/O 2016 推出的一個應用開發套件（含iOS和Android），包含統計、雲推送、託管、廣告等一系列功能，AppIndexing是其中一項。
AppIndexing的作用就是『可將您的應用納入Google 搜索』，如果用戶安裝了你的應用，點擊搜索結果就可以直接打開你的應用；如果沒有安裝，開發者可以指定接下來的行為（依賴於 Firebase Dynamic Links）：1.去對應的web頁面，2.打開應用商店，3.出現一個小卡片介紹應用，然後再導到應用商店。
這裡有個關鍵詞『納入Google搜索』，意味著，它是跨平台的，在iOS和Android 都有完整的解決方案，開發者只需要適配一次。其次，應用所獲得的流量依賴於在搜索結果中的排位。
和蘋果類似，Firebase App Indexing 也能索引網頁數據、應用頁面和個人數據，按同樣的方式簡要說明。
索引應用的網頁數據：
一個應用支持 App Indexing，需要幾步：
1. 如果你的應用內容和網頁內容是相似的（如Twitter、知乎、豆瓣），讓Google知道你的應用和網頁鏈接的對應關係 ( Declarea website association )
2. 配置你的應用，讓它能處理系統傳過來的URL (SupportHTTP URLs in your App) 。也就是讓應用支持Deep Linking，但對系統版本有要求，得是Android6.0 或iOS 9.0以上。另外Google 的方案兼容蘋果的Universal Links。
3.如果你的應用內容沒有對應的網頁，也可以直接調用AppIndexing API，將希望被索引的內容告訴Google.
附上官方視頻，解釋得非常好：
Introducing Firebase App Indexing—在線播放—優酷網，視頻高清在線觀看 http://v.youku.com/v_show/id_XMTU4NDMzODAyMA==.html
索引應用的某一頁
在Android 中，開發者可以通過 App Indexing API 將用戶當前所在的頁面信息告訴系統，這些信息包括頁面標題（title）、摘要(description)、網址（URL）、頁面類型（ActivityType）等等。然後Android 就可以搜索到用戶瀏覽過的應用頁面（AppIndexing API：將您的 Android 應用納入搜索自動填充）
索引應用的個人數據
今年8月30日，Google團隊推出了『In Apps』搜索，初期支持直接搜索Gmail,Spotify and YouTube的內容。現在相關的內容還很少，我也沒找到開發者適配的方法。可能還只是在測試階段，但願不會跳票…
與 Apple Search API 對比
兩個方案實現的能力基本一致，但從開發者文檔來看，Apple Search API 顯得更加完備和成熟。那對於開發者來說，哪個方案更有吸引力呢？我們不妨列舉一下雙方的優勢：
Apple 的優勢： 1. 更完善的方案，兼顧用戶隱私和內容豐富度 2. 遠高於Android 的系統更新率3. 更優質的用戶質量和生態環境
Google 的優勢： 1. 巨大的搜索流量 2. 更完善的排序演算法 3. 跨平台對於國外開發者來說，若非得二選一，似乎 Google 的方案更有吸引力，畢竟Google搜索的流量是現成的，而 Apple Spotlight 還不成氣候。好在，兩個方案並不衝突，開發者也可以考慮同時適配這兩個方案。
結語
應用內搜索是趨勢嗎？你可能會不假思索地回答：是的。我也一樣相信這是趨勢，但我擔憂的是，它是不是來得太晚了？
我們早就習慣了沒有它存在的日子，我們也早就習慣了找美食去美團，看電影去貓眼、糯米，找影評去豆瓣，買東西去京東淘寶，作為用戶，我們真的會像在PC時代一樣，在一個搜索框解決所有搜索需求嗎？其次，無論是iOS還是Google的方案，開發者都需要做不小的適配工作，儘管Apple和Google都用更靠前的排序位置、更多的流量等空頭支票來吸引開發者適配，但真實效果如何呢？有多少人會主動適配，又有多少人會持觀望態度。
再次，什麼內容能被索引，什麼不能，全由開發者決定。所以，系統通用的搜索框暫時還不能完全取代每個應用內的搜索框，那麼，作為用戶，我會一直用一個可能搜不到東西的搜索框嗎？
但上述的擔憂都是站在「搜索」這個角度來說的，假如把『應用內搜索』理解為『應用內的內容能被發現和調起』，那麼可應用的場景就多了，搜索只是其中一個場景。想像一下：
- 你的好朋友在朋友圈轉發了豆瓣的影評，你點擊後調起了豆瓣app。
- 或者，你在知乎上看到一本感興趣的書，於是你點擊鏈接之後直接打開豆瓣查看相應評論和價格，感覺還不錯，再點擊鏈接直接調起了亞馬遜或京東買下了這本書。
當有越來越多的應用支持DeepLinking，也就不用老看見煩人的web頁面了。
我們不妨再換一個角度：
應用內搜索要解決的問題，其實是應用信息的孤島化，但移動網路發展到今天，互聯網的內容和服務已經越來越集中於某幾個應用，打車是滴滴，社交是微信QQ，吃喝玩樂是美團大眾點評，購物是淘寶京東，新聞閱讀是今日頭條。用戶安裝的應用本來就不多了，所謂的信息孤島化是否還有必要解決？
再假如，這些內容和服務進一步集中，集中到一個App里。是不是想到了微信、Facebook這樣的超級App ? 如果所有的島嶼都被吞併了，也就不需要煞費苦心構建聯通的網路。如今你可以在微信聊天、社交、購物、閱讀，甚至後面依賴『小程序』可以完成更多更多的互聯網服務，而且它跨越平台和設備。未來微信首頁的搜索框將會承載更多能力，恐怕會逐漸成為移動互聯網服務的入口，正好就是張小龍口中的『用完即走』。類似的事情也在Facebook上發生，這也是Google不想看到的事情。
回到前面的問題，所謂『應用內搜索』是否來得太晚了？恐怕是的，但作為移動互聯網遲到的基礎設施，我希望它來得更快一些。
推薦閱讀：