摘要：如有描述不正確的地方，請及時聯系我，我將吸取意見并改正。但是對于技術來講，是要采用的處理方式。然后將程序退出。說明此時已奏效。當然這樣開放，勢必會帶來安全的隱患。

作者：Darkbug
原文標題：Google新技術：Instant App全拆解（2）——剖析
原文鏈接：https://segmentfault.com/a/11...
首發地址：http://www.doncc.org
轉發請注明轉載地址，請尊重原創作者權益！

《Google新技術：Instant App全拆解》系列預告：

第三篇：Google新技術：Instant App全拆解（3）——著手

《Google新技術：Instant App全拆解》系列回顧：
第一篇：Google新技術：Instant App全拆解（1）——初探

本文著重介紹在進行Instant App程序開發時，所涉及的Android周邊技術，其目的是更好的進行Instant App程序開發。

如有描述不正確的地方，請及時聯系我，我將吸取意見并改正。

肯定有很多童鞋不理解，為什么我要在講Instant App技術之前，要提及這個“看似不相關”的概念呢？實則真正在進行Instant App程序開發時，是必然涉及到這標題所述的兩個概念的。應該先搞清這兩個概念的區別，再來進行程序開發，就會變得易如反掌了。

Google為我們提供了一個非常好的操作體驗：比如當我的好朋友給我發了一個定位的鏈接信息，這個信息我們看上去好像不那么直觀得看出，我的好朋友在什么具體位置。但是如果我一旦點擊了這個鏈接，如果我直接能在某個地圖應用里看到具體圖像位置的話，那么這個體驗就會變得更好了。

對于一個鏈接，當點擊后，Google為我們預留了兩種的處理方式，這就是Deep Links和App Links。這兩種方式，在體驗上是截然不同的。所以想要采用哪種處理方式，這就取決于我們自己的決定。

注意，我這里只是在處理鏈接的角度上講，如何處理是取決于用戶自己。但是對于Instant App技術來講，是要采用App Links的處理方式。所以這里同學們需要注意。

那么好，接下來我要著重講解Deep Links和App Links這兩個處理URL的方式。

要想明白Instant App中的精髓，首先要了解Deep Links是什么東西，以及其本身的作用。

我們來回想一個場景。假如你的手機內安裝了UC瀏覽器（UC瀏覽器并沒有給我充值，先聲明），并且還同時存在其他瀏覽器，當你在一個應用程序內點擊一個鏈接，系統會彈出一個對話框，說明的是讓你選擇一個可以打開鏈接的應用或方式。你可以選擇系統瀏覽器，也可以選擇UC瀏覽器；如果你的手機內只有一個可以打開鏈接的程序（比如只有一個瀏覽器程序），那么系統就會用這個應用程序直接打開這個鏈接。

那么結果來了，Deep Links是可以來讓用戶，通過一段類似URL的鏈接，達到快速用某個應用打開的作用。當然這也需要用戶確認，到底是用哪個程序打開。

好，接下來我們再看下官方對于Deep Links工作的闡述。當用戶點擊一個鏈接，或者有一個web URI的請求調用，安卓系統會嘗試幾個操作，直到操作請求成功：

Open the user"s preferred app that can handle the URI, if one is designated.
Open the only available app that can handle the URI.
Allow the user to select an app from a dialog.

將上述的操作放入剛剛我們舉得例子里，不難發現，系統內部執行了如下的判斷過程：

首先系統判斷出哪些程序開放了可以處理URL的程序配置；

其次來看下是不是只有這一個應用程序能處理這個URL；

再次來看下有哪些應用可以處理這個URL；

這個判斷的過程，完全有系統來進行。所以要懂得它的判斷過程，尤為重要。

我們來設定一個情景。當我的朋友給我發來一段鏈接，內容是這樣的：

那么這里我們要區分出來，我們需要在VideoActivity上呈現。這段鏈接對于intent-filter過濾器來說，scheme部分為“http”，而host部分為“doncc.org”，考慮到我的程序可能應對這個鏈接下面很多其他的視頻，所以我可以選定pathPrefix的過濾方式，這樣能包括其他視頻的鏈接一并過濾出來（當然你也可以要求更為嚴格的過濾）。

對于支持Deep Links的程序的配置，很是簡單。或許我們來段manifest文件的過濾器配置更為直觀：

好，當我們的配置配好之后，就可以將程序運行在模擬器上了。然后將程序退出。

驗證部分需要打開terminal，并輸入命令如下：

$ adb shell am start
        -W -a android.intent.action.VIEW
        -d  

注意這里的，指的是你在程序內指定的地址。那么應對上述文中，指定的就是http://doncc.org/video/1.mp4（或者尾部為其他的視頻資源），而指的是你的程序的package包名。所以當你輸入正確的命令并執行后，你的模擬器就會直接看到執行后的頁面。說明此時Deep Links已奏效。

特別強調一點。這里我們是直接驗證Deep Links是否奏效。然而設置支持此Deep Links的Activity，在第一次呈現時，會有一個選擇對話框，因為此Activity添加了其他的過濾器，同樣系統內也有跟它一致的過濾器，系統默認是不知道你要用哪個程序打開此鏈接頁面的。所以在提示框內呈現提示用什么應用方式打開。

說了這么多，如果還是沒太清楚，可以參考我錄制的視頻：Android 如何使用 Deep Links 處理URL鏈接

我們再來看一個應用場景。

或許我們有過這樣的體驗。當你的朋友用短信的形式，給你發了一篇知乎的文章鏈接給你，如果你點擊了鏈接，假設你的手機內沒有安裝知乎程序，那么手機會自動通過瀏覽器，顯示出來這個文章的頁面信息；如果你的手機內安裝了知乎的程序，那么會直接打開知乎程序，顯示出這個文章的信息。

我們之前知道了Deep Links的作用，實則你可以理解成App Links是一個特殊的Deep Links。因為Deep Links在第一次使用時，是需要用戶主動進行授權的，而App Links的作用是無需這第一次的主動授權，是足夠信任這個鏈接地址的。當然這樣開放，勢必會帶來安全的隱患。沒有關系，Google大大已經為我們想到了這一點了，在Android 6.0以后，程序可以支持App Links來讓程序處理默認指定的鏈接。

相比Deep Links而言，App Links具有一定的優勢的：

更安全、更嚴格：相比Deep Links我們不難發現，在制定具體你的域名地址時，如果指定的條件過于寬泛，勢必會可能其他的鏈接地址后綴也可以訪問到你應用程序。如果過于嚴格的約束，那么所制定的業務有太過于麻煩。所以App Links的出現，就為我們更好的解決這一問題；

更為無縫的用戶體驗：當你點擊一個鏈接的時候，可能會有一個URL鏈接到你的網站。如果你的手機內沒有安裝這個應用，那么鏈接可以很輕松的重定向到你的網站，不至于頁面會彈出一個404 not found的錯誤，給用戶帶來非常不好的體驗；

可支持Android Instant App瞬時加載技術：可以支持瞬時加載技術。用戶無需安裝應用，憑一個URL鏈接，就可以體驗到同App一樣的用戶體驗。這一點也是至關重要的，我們也會在后續課程內詳細介紹。

可從Google Search中搜到你的應用：同上條一樣，我們可以通過Google Search來找到你的應用。這一點也是對我們Instant App有所幫助的一點。

從諸多關于App Links的優點來看，我們可以總結出，想要掌握Instant App技術，首先必須掌握App Links是如何配置的，且App Links是基于Deep Links的。所以我們就知道了該如何去學習了。

好，接下來我們要深入學習關于App Links。

對于支持App Links的程序的配置，要比支持Deep Links的配置稍加復雜一步。總共可分為兩個部分：

對manifest過濾器的編寫

數字資產鏈接文件的生成

接下來我們詳細說明每個部分。

對于過濾器的編寫，我們再來一段代碼更為直接：

事實上我們不難發現，這個過濾器的編寫，要比之前Deep Links的編寫內容，只多了一個屬性。那就是：

    ...

通過android:autoVerify="true"這個屬性，就能讓系統知道，這個程序是屬于可以自動進行驗證的。也就為后續進行數字資產鏈接文件的驗證做好了鋪墊。

對于數字資產鏈接，其實是一個json文件，里面包括了一些應用程序的信息，而這個文件需要放置在你的網站的特定路徑內。

那么數字資產鏈接文件該如何寫呢？下面來看個例子：

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "org.doncc.learnapplinks",
    "sha256_cert_fingerprints":
    ["01:CD:30:56:A8:5E:EC:18:64:3D:8B:F2:AF:3F:B6:02:85:33:79:13:97:23:E3:FF:99:59:14:E5:03:FC:57:78"]
  }
}]

從上面的例子可以得出結論，數字資產鏈接文件配置的要求，有如下內容：

需知道你應用的包名（package_name）

需知道你發布程序的sha256指紋簽名證書（sha256_cert_fingerprints）

對于包名，我們肯定知道該如何獲得。而對于sha256指紋簽名證書，我們可以通過命令來獲取到。比如我發布的程序是用release.keystore來簽名的，那么你在用命令行獲得sha256簽名時，就要指定你的key來獲得：

$ keytool -list -v -keystore release.keystore

當生成完畢后，需要把這個文件重命名為assetlinks.json，并上傳到你的網站的特定目錄內：

https://domain.name/.well-known/assetlinks.json

其中domain.name部分為你的具體的網站地址。而需要在你的網站下面的.well-known目錄下，新建assetlinks.json文件，也就是剛配置過的數字資產鏈接文件，來確定你的網址是可信的。

如果我們的網站會忽略隱藏文件，那么強烈建議你寫一個取消忽略的配置文件。這個過程就不需要我講了吧。。。

同樣，對于App Links的驗證，總體也可以分為兩部分：

對數字資產鏈接文件配置合法性的驗證

通過Shell命令驗證

同樣，我們詳細說明每個部分。

在進行App Links的驗證過程要注意一點，根據官方說明，在程序安裝完畢后，至少等待20秒后再進行鏈接的驗證是最為好的。并且要保證你的網絡足夠好，因為在驗證過程，系統識別一旦超過5秒，那么就會驗證失敗，以至于會出現和Deep Links同樣的用戶效果了。

Note: Make sure you wait at least 20 seconds after installation of your app to allow for the system to complete the verification process.

通過網頁的驗證鏈接進行驗證

我們可以首先來通過網頁訪問的形式，來確定我們自己的數字資產鏈接文件是否已經被網站關聯上。這里我們給出官方的網頁URL：

https://digitalassetlinks.googleapis.com/v1/statements:list?
   source.web.site=https://domain.name:optional_port&
   relation=delegate_permission/common.handle_all_urls

這里source.web.site是需要替換成我們自己的網站地址的。然后點擊回車，如果出現類似下面頁面，就說明當前數字資產鏈接文件已經被網站關聯上了：

{
  "statements": [
    {
      "source": {
        "web": {
          "site": "https://doncc.github.io."
        }
      },
      "relation": "delegate_permission/common.handle_all_urls",
      "target": {
        "androidApp": {
          "packageName": "org.doncc.l02learnapplinks",
          "certificate": {
            "sha256Fingerprint": "01:CD:30:56:A8:5E:EC:18:64:3D:8B:F2:AF:3F:B6:02:85:33:79:13:97:23:E3:FF:99:59:14:E5:03:FC:57:78"
          }
        }
      }
    }
  ],
  "maxAge": "599.298570247s",
  "debugString": "********************* ERRORS *********************
None!
********************* INFO MESSAGES *********************
* Info: The following statements were considered when processing the request:

---
Source: Web asset with site https://doncc.github.io. (which is equivalent to "https://doncc.github.io")
Relation: delegate_permission/common.handle_all_urls
Target: Android app asset with package name org.doncc.l02learnapplinks and certificate fingerprint 01:CD:30:56:A8:5E:EC:18:64:3D:8B:F2:AF:3F:B6:02:85:33:79:13:97:23:E3:FF:99:59:14:E5:03:FC:57:78
Where this statement came from:
  Origin of the statement: Web asset with site https://doncc.github.io. (which is equivalent to "https://doncc.github.io")
  Include directives followed (in order):
    u003cNoneu003e
Matches source query: Yes
Matches relation query: Yes
Matches target query: Yes

--- End of statement list. ---


"
}

借助Google Digital Asset Links工具驗證

還有一種驗證方法，借助Google Digital Asset Links這個工具，就能進行驗證。

文中所填寫的內容，正是你在配置前面assetlinks.json數字資產鏈接文件的信息。填寫進去，進行驗證。如果驗證通過，說明你的網站已通過安全驗證，可以愉快的使用App Links了。

借助App Links Assistant的測試工具驗證

事實上還是有其他方法進行驗證，借助App Links Assistant的測試工具進行驗證。這部分我們會在后部分講到。

adb命令構建URL Intent：

驗證的過程和驗證Deep Links類似。我們可以用構建URL Intent的方式來進行模擬鏈接的驗證：

adb shell am start -a android.intent.action.VIEW 
    -c android.intent.category.BROWSABLE 
    -d "http://domain.name:optional_port"

注意，這里-d的內容需要替換成我們自己的網站地址。

如果成功，那么立即就會在模擬器上看到執行后的效果，直接的跳轉到所在的Activity，而無需經過用戶點擊彈出框的確認過程。

這里我貼出關于App Links在開發時的視頻：如何使用 App Links 處理URL鏈接

不難發現，實則Deep Links和App Links都有異曲同工之妙。我們從上面的內容來看，確實配置過程有點繁瑣。幸好Google大大們已經為我們著想了這一點，在Android Studio 2.3版本及以上版本，內置了一個App Links Assistant的鏈接生成助手。根據這個助手的指引，我們就能很快的配置出屬于我們自己程序的App Links，甚至是Deep Links。

那么這個助手該如何找到呢？在你的Tools > App Links Assistant，就可以找到了。

這里具體有一些如何使用App Links Assistant進行配置的文章描述，我們就不再贅述了，官方的文檔已經很詳盡的說明了這一點。如需參考請異步地址：Add Android App Links

這里我們引自官方的對比表格更為直接。（來自：the-difference）

我們不難看出，App Links的出現是彌補了Deep Links的一些不足。當然使用起來也應該酌情而定，畢竟Deep Links的超高自由度，也是后者望塵莫及的。說了這么多，再結合Instant App，我們就可以總結出以下幾點：

在Instant App內使用App Links，具有更為安全的通信協議，也為協議的驗證做好鋪墊；

因為使用即時應用的前提，是點擊一個鏈接直接跳轉到界面，所以在Intent處理上，嚴格要求處理動作是android.intent.action.VIEW；

同上面描述的，Instant App也需要可以在網絡上搜索到，并打開程序，比如Google搜索結果頁面上打開。固然需要Intent的種類是android.intent.category.BROWSABLE 和 android.intent.category.DEFAULT；

App Links是可以對URL鏈接進行安全驗證的，而Deep Links是不具有驗證功能的。其目的是為了能讓Android程序足夠信任其URL鏈接地址，減少讓用戶選擇“xxx方式打開”這種動作歧義的對話框出現，在用戶體驗上能更讓用戶覺得是“無縫”的感覺；

對于鏈接點擊處理功能的兼容，Deep Links能兼容所有Android版本，而App Links只兼容Android 6.0及更高的版本。

但是話有說回來，不難發現，在App Links與Deep Links的處理場景是很受局限的。大多數的程序是不經過系統處理的，而是直接內置方式處理。比如某聊天工具?。。。這就給其推廣造成很大的阻礙，而能實現處理的地方有短信、內置瀏覽器內等一些原生App內。真是心塞。

好，這回我們就能徹底的了解了這兩種URL鏈接處理方式了。

對于Instant App程序開發，是依賴于App Links處理URL的方式，并且App Links又是一種特殊的Deep Links，也就是必須先知道Deep Links的作用，才能知道App Links的作用。

Deep Links的出現，是為了能讓用戶在不同應用見體驗到App級的用戶體驗，而App Links的出現，是為了讓這種體驗更加“無縫銜接”；

對于App Links，需要一個數字資產鏈接文件的驗證，這個文件是必須放在網站根目錄/.well-known/assetlinks.json這個路徑下，才能生效；

對于數字資產鏈接文件，其內部注意你的程序的簽名，如果程序是released版本，那么你的簽名指紋也需要換成對應的指紋；

對于App Links，需要在過濾器內添加android:autoVerify="true"屬性，保證系統能識別到。

講到這里，我們就可以初步了解了有關于制作Instant App的周邊技術了。接下來我還會有更多的文章來持續講解Instant App程序開發。

《Google新技術：Instant App全拆解》系列預告：

第三篇：Google新技術：Instant App全拆解（3）——著手

《Google新技術：Instant App全拆解》系列回顧：

第一篇：Google新技術：Instant App全拆解（1）——初探