Google新技術：Instant App全拆解（2）——剖析

時間 2019-11-09

標籤 google 新技術 instant app 拆解剖析欄目 Google 简体版

原文原文鏈接

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

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

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

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

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

若有描述不正確的地方，請及時聯繫我，我將吸收意見並改正。shell

1.爲什麼引入Deep Links和App Links的概念

確定有不少童鞋不理解，爲何我要在講Instant App技術以前，要說起這個「看似不相關」的概念呢？實則真正在進行Instant App程序開發時，是必然涉及到這標題所述的兩個概念的。應該先搞清這兩個概念的區別，再來進行程序開發，就會變得易如反掌了。json

Google爲咱們提供了一個很是好的操做體驗：好比當個人好朋友給我發了一個定位的連接信息，這個信息咱們看上去好像不那麼直觀得看出，個人好朋友在什麼具體位置。可是若是我一旦點擊了這個連接，若是我直接能在某個地圖應用裏看到具體圖像位置的話，那麼這個體驗就會變得更好了。segmentfault

對於一個連接，當點擊後，Google爲咱們預留了兩種的處理方式，這就是Deep Links和App Links。這兩種方式，在體驗上是大相徑庭的。因此想要採用哪一種處理方式，這就取決於咱們本身的決定。api

注意，我這裏只是在處理連接的角度上講，如何處理是取決於用戶本身。可是對於Instant App技術來說，是要採用App Links的處理方式。因此這裏同窗們須要注意。瀏覽器

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

2.Deep Links的做用

要想明白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；

這個判斷的過程，徹底有系統來進行。因此要懂得它的判斷過程，尤其重要。

2.1進行Deep Links的配置

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

那麼這裏咱們要區分出來，咱們須要在VideoActivity上呈現。這段連接對於intent-filter過濾器來講，scheme部分爲「http」，而host部分爲「doncc.org」，考慮到個人程序可能應對這個連接下面不少其餘的視頻，因此我能夠選定pathPrefix的過濾方式，這樣能包括其餘視頻的連接一併過濾出來（固然你也能夠要求更爲嚴格的過濾）。

對於支持Deep Links的程序的配置，非常簡單。或許咱們來段manifest文件的過濾器配置更爲直觀：

<activity android:name=".VideoActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:host="doncc.org"
            android:pathPrefix="/video"
            android:scheme="http" />
    </intent-filter>
</activity>

好，當咱們的配置配好以後，就能夠將程序運行在模擬器上了。而後將程序退出。

2.2進行Deep Links的驗證

驗證部分須要打開terminal，並輸入命令以下：

$ adb shell am start
        -W -a android.intent.action.VIEW
        -d <URI> <PACKAGE>

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

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

說了這麼多，若是仍是沒太清楚，能夠參考我錄製的視頻：Android 如何使用 Deep Links 處理URL連接

3.App Links的做用

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

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

咱們以前知道了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。

3.1App Links的配置

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

對manifest過濾器的編寫
數字資產連接文件的生成

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

3.1.1對manifest過濾器的編寫

對於過濾器的編寫，咱們再來一段代碼更爲直接：

<activity android:name=".BlogActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />

         <category android:name="android.intent.category.DEFAULT" />
             <category android:name="android.intent.category.BROWSABLE" />

             <data
                android:scheme="http"
                android:host="doncc.github.io"
                android:pathPrefix="/2017/" />
    </intent-filter>
</activity>

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

<intent-filter android:autoVerify="true">
    ...
</intent-filter>

經過android:autoVerify="true"這個屬性，就能讓系統知道，這個程序是屬於能夠自動進行驗證的。也就爲後續進行數字資產連接文件的驗證作好了鋪墊。

3.1.2數字資產連接文件的生成

對於數字資產連接，實際上是一個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文件，也就是剛配置過的數字資產連接文件，來肯定你的網址是可信的。

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

3.2App Links的驗證

一樣，對於App Links的驗證，整體也能夠分爲兩部分：

對數字資產連接文件配置合法性的驗證
經過Shell命令驗證

一樣，咱們詳細說明每一個部分。

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

在進行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 *********************\nNone!\n********************* INFO MESSAGES *********************\n* Info: The following statements were considered when processing the request:\n\n---\nSource: Web asset with site https://doncc.github.io. (which is equivalent to 'https://doncc.github.io')\nRelation: delegate_permission/common.handle_all_urls\nTarget: 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\nWhere this statement came from:\n  Origin of the statement: Web asset with site https://doncc.github.io. (which is equivalent to 'https://doncc.github.io')\n  Include directives followed (in order):\n    \u003cNone\u003e\nMatches source query: Yes\nMatches relation query: Yes\nMatches target query: Yes\n\n--- End of statement list. ---\n\n\n"
}

藉助Google Digital Asset Links工具驗證

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

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

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

事實上仍是有其餘方法進行驗證，藉助App Links Assistant的測試工具進行驗證。這部分咱們會在後部分講到。

3.2.2經過Shell命令驗證

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連接

4.經過App Links Assistant來協助配置

不難發現，實則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

5.Deep Links和App Links的對比

這裏咱們引自官方的對比表格更爲直接。（來自：the-difference）

	Deep Links	App Links
Intent URL scheme	`http`, `https`, or a custom scheme	Requires `http` or `https`
Intent action	Any action	Requires `android.intent.action.VIEW`
Intent category	Any category	Requires `android.intent.category.BROWSABLE` and `android.intent.category.DEFAULT`
Link verification	None	Requires a Digital Asset Links file served on you website with HTTPS
User experience	May show a disambiguation dialog for the user to select which app to open the link	No dialog; your app opens to handle your website links
Compatiblity	All Android versions	Android 6.0 and higher

咱們不難看出，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連接處理方式了。