爲何說它對 Android 將來的發展十分重要？

時間 2019-11-17

原文原文鏈接

做者 / Dom Elliott, 產品經理, Google Playandroid

因爲其開放性，Android 在其前十年取得了顯著的增加。有大量的設備可供選擇，蓬勃發展的開發者生態系統提供了許多應用和遊戲，爲這些設備賦予了長久的生命力。做爲開發者，您但願確保用戶儘量得到最佳體驗，並確保您的應用盡量在全部這些設備上運行。您還但願儘量多的用戶安裝您的應用; 您也但願他們持續使用它; 而且您不但願他們因您沒法控制的緣由卸載您的應用。到目前爲止，Android 應用的發佈和分發方式在全部這些方面都有待改進。我想觀察一下開發者面臨的一些挑戰，並告訴您 Google 正在採起哪些措施來提供幫助。web

回首 Android 的第一個十年

十年來，在 Android 上發佈應用的流程以下：安全

第 1 步：在 IDE 中爲您的應用編寫代碼，例如 Android Studio。網絡
第 2 步：當您準備好測試或發佈應用時，您能夠將其構建爲 APK，也就是 Android 的應用格式。做爲構建 APK 的一部分，您可使用應用簽名密鑰對其進行數字簽名。爲應用簽名意味着安全地爲其添加惟一證書。這種機制能夠確保您是惟一能夠繼續更新此應用的人。這種機制是這麼工做的：在更新應用以前，Android 始終會檢查更新的證書是否與設備上應用的證書相匹配。稍後我會詳細闡明爲何我要講這些。架構
第 3 步：使用 Google Play Console 將已簽名的 APK 上傳到測試軌道。待測試和調整就緒後，將應用正式發佈，並分發到世界各地。app
第 4 步：Google Play 會將已經被您簽名的 APK (就是您上傳的那個) 在安裝時分發至每一個用戶的設備。ide

多年來，這種方法運做良好。實際上，人們每月都會從 Google Play 安裝超過 80 億個應用！可是，正如您將看到的，這種模式爲開發者帶來了難以忽視的挑戰。模塊化

難以忽視的「大」問題

挑戰在於：應用的體積愈來愈大了。事實上，自 2012 年以來，應用體積平均增加了 5 倍。這很好理解：您但願爲應用添加炫酷功能和新內容，以確保用戶留存/迴歸並保持業務增加。設備性能愈來愈好，您但願能把那些閃亮的新功能利用起來。設備生態系統變得更加多樣化了，所以您決定複製應用中的代碼和資源，使其在大屏幕和小屏幕上都能流暢運行，在不一樣種類的 CPU 上都能流暢運行，等等。性能

若是每一個用戶都擁有無限的存儲空間、無限的數據流量和永遠存在的快速鏈接，那麼應用愈來愈大並無什麼問題。遺憾的是，事實並不是如此 (固然咱們但願有一天可以如此！)。經過查看下圖，您能夠看到 Google Play 上的應用大小與其安裝轉化率呈負相關關係。這意味着隨着應用變大，其安裝率會降低。出現這種狀況有不少緣由：許多用戶的設備上沒有足夠的可用空間。用戶可能在使用存儲空間通常的入門級設備，即便對於那些擁有高端設備的用戶而言，他們的照片、視頻和其餘媒體文件的品質也在逐漸提高，從而佔據了愈來愈大的空間，設備上的可用空間正在逐漸緊縮。用戶也不但願一邊用着昂貴的流量套餐，一邊等待大型應用去慢慢鏈接網絡，在新興市場尤爲如此。測試

咱們知道，較大致積應用的安裝率會降低。咱們的用戶研究還代表，應用大小是推進卸載的主要動力，這使得應用大小成爲提高保留率的一個愈來愈重要的因素。想一想您本身的經歷吧。當您嘗試安裝應用時，您是否曾經看到 Google Play 發出警告，提示您須要卸載部分不常用的應用，釋放空間來安裝新的應用？數以百萬計的人們天天都會看到這些警告，在接到這個警告時， 他們常常會卸載體積最大的應用和遊戲。在 Google Play 去年進行的用戶調查中，人們卸載應用和遊戲的主要緣由是爲了騰出空間，即使這些應用和遊戲已經被使用了至少一個月。

針對上述問題，開發者們能採用的解決方案頗有限。您能夠在單個版本中爲每一個設備配置構建多個 APK。但當您想要針對不一樣屏幕尺寸和 CPU 架構進行優化，同時針對 32 位和 64 位時，狀況很快就會失控——您最終可能會爲每一個版本構建數百個 APK。這很痛苦，大多數開發者都不會這樣作。許多人只是將全部內容都放在一個「胖胖的」 APK 中，最終致使用戶設備上存在着大量未使用過的內容。並且，即便您使用多重 APK，也沒法針對語言進行優化。即便用戶只須要一種或兩種語言，您也必須在每一個 APK 中包含針對每一個設備的全部翻譯字符串，這樣會浪費更多空間。

所以，開發者的困境就顯而易見了：增長應用的體積，但可能會致使較低的轉換率和較高的卸載風險；使用多重 APK，會下降您的版本迭代效率並致使您疲憊不堪，您還可能會花費大量的時間權衡不一樣的功能之間的取捨，以免增長應用體積。

「小」而「巧」的解決方案來了

Google 不但願開發者面臨這些困境，所以咱們一直在努力改進。大體的想法是這樣的：若是您將所需的全部內容上傳到了 Google Play，讓 Play Store 爲每一個用戶和設備按需提供相應的內容。這很簡單，不是嗎？這一過程能夠減小您支持 Android 多樣化生態系統所需的工做量，並使用戶手中的應用體積更小。正如您稍後將在本文中發現的那樣，這個新方案還有助於改善用戶獲取過程：經過功能和更新，即時發現、安裝、吸引，以及保留用戶。

更小的安裝包

爲實現這一願景，Google 於今年早些時候推出了一款新的應用發佈格式 Android App Bundle。如下是它的詳細工做原理：

第 1 步：您能夠在 IDE (如 Android Studio) 或 Unity 等遊戲引擎中編寫應用的全部代碼。
第 2 步：如今，當您準備好測試或發佈應用時，您能夠將其構建爲 Android App Bundle，也就是新的 Android 應用發佈格式。您仍然要對應用進行簽名，以便 Google Play 驗證您的身份。
第 3 步：若是您尚未簽名，則能夠選擇經過 Google Play 進行應用簽名。若是您要發佈新應用，則能夠在上傳應用時經過一鍵式過程執行此操做。當您決定這樣去作時，Play 會將您用於簽署應用束的第一個密鑰指定爲上傳密鑰。它僅用於安全識別目的，若是您丟失了它，能夠與 Google 聯繫，驗證您的身份並重置它。對於現有應用，您須要訪問 Play Console 中的應用簽名頁面，並將您的應用簽名密鑰安全地轉移到 Google Play。您爲何須要這樣作？繼續查看第4步就能發現答案。
第 4 步：當您將應用束上傳到 Google Play 時，Play 會對其進行處理，並生成使用應用簽名密鑰簽名的分拆 APK，以支持各類設備配置和語言。分拆 APK 是 Android Lollipop 中引入的 Android 平臺功能。只要每一個分拆 APK 都使用相同的密鑰簽名，Android 平臺就會將它們視爲一個應用。您能夠將各個分拆 APK 視爲一個完整 APK 的各個「部件」：爲了運行應用，設備會將全體部件整合起來，視爲單個應用。
第 5 步：當用戶安裝該應用時， Play 會提供基礎 APK (每臺設備上都須要用到的代碼)，語言 APK (用於用戶使用的語言)，以及配置 APK (用於適配設備的屏幕大小和 CPU 架構)。這意味着設備能夠在不浪費空間的狀況下得到所需的功能。要讓設備接受更新，必須使用與原始應用相同的應用簽名密鑰對每一個版本的分拆 APK 進行簽名。
第 6 步：在您的應用安裝在設備上後，Play 也會根據須要提供額外的分拆 APK，例如，當用戶更改設備語言或是想要使用動態功能時。更具體的細節將在稍後詳述。

這個新分發模式能夠顯著縮小應用體積，減小下載時間，減小對存儲空間的佔用。您爲用戶提供了一個更高效的應用，其中不包含用戶不會用到的代碼和資源。對於大多數開發者來講，切換到這個新分發模式也很簡單。在 Android Studio 中構建 App Bundle 與構建 APK 的過程大體相同。使用 Unity 的遊戲開發者也能夠在 Unity 的 2018.3 測試版及更高版本中構建應用束。Android App Bundle 是開源和向下兼容的 (對於 Android L 以前的版本，Play 會自動使用多 APK——即 Play 爲每一個設備配置生成一個 APK，包含全部語言資源，而不是使用分拆 APK)。

咱們切換到 App Bundle，並在一小時內就上傳了咱們的第一個內部版本。 Swiggy ~使用 Apple Bundle 減小了 23% 的應用體積

成千上萬的熱門應用開發者正在使用 App Bundle 打包其應用。使用 Android App Bundle 的開發者的 APK 大小平均比以前採用的「完整 APK」小 3.5％ (「完整 APK」是指一個 APK 包含了 Android App Bundle 支持的全部設備配置和語言所需的一切）。更重要的是，對於那些必須管理每一個版本的人來講，新格式意味着您再也不須要使用多 APK 來進行設備配置。Google Play 會爲您解決此問題，讓您的生活輕鬆一點。Play Console 即將開始容許您上傳大型 App Bundle，其對應的 APK 大小爲500MB。在提高過尺寸上限後，咱們相信在大多數狀況下您也不須要使用額外的擴展文件了。

如今咱們沒必要使用多 APK 了，App Bundle 節省了咱們的時間。 redBus ~使用 App Bundle 減小了 22% 的應用體積

新分發模型和新發布格式的好處是， Google Play 能夠在 APK 生成過程當中引入優化，從而節省您的時間和精力。剛剛公佈的一個例子是：支持未壓縮的本地代碼庫，這是 Android Marshmallow 中引入的一個不多使用的平臺功能。使用 App Bundle 的開發者無需額外的工做便可得到此功能。

在 Android M 以前，您的應用中包含的任何本地代碼庫都必須從 APK 中解壓縮。這意味着每一個設備上都安裝了兩個代碼庫副本：APK 中的壓縮副本和未壓縮的副本。這會致使空間浪費。從 Android M 開始，您能夠直接以未壓縮的狀態從 APK 中讀取代碼庫。Play 在下載過程當中對 APK 的壓縮一般比壓縮 APK 中的本地代碼庫更有效，所以總體下載體積也更小。爲了讓您能夠從中受益而沒必要擔憂上傳大小，Play Console 的大小限制正在發生變化，它們基於用戶下載的壓縮 APK 大小，而不是您上傳到 Play Console 的應用大小。平均來說，僅此一項優化就足以將使用本地代碼庫的應用的文件下載量減小 8％，將設備上的安裝大小減小 16％。只要切換到應用束，就能夠享受到如此驚人的文件體積縮減！

20 多種語言的資源文件增長了咱們的應用體積，並顯著拉低了咱們的訪問安裝轉化率。咱們使用 Android App Bundle 後狀況大爲改觀。 Riafy ~使用 Apple Bundle 減小了 37% 的應用體積

正如我所提到的，應用必須選擇經過 Google Play 進行應用簽名才能使用應用束。應用簽名密鑰是一種機制，它能夠確保在安裝應用後，更新始終來自同一個開發者。Google 沒法經過此密鑰得到額外的訪問權限，也沒法識別有關開發者的信息。它僅用於簽署拆分 APK 以進行安裝和更新。Google 很是重視安全性，Google 擁有一支工程師團隊以及高級的基礎架構，使用與 Google 用來保護自用應用密鑰相同的安全密鑰存儲來保護開發者的密鑰。事實上，對於大多數開發者來講，選擇進行應用簽名而後使用上傳密鑰簽署每一個版本比本身持有密鑰更安全，由於密鑰可能會丟失或暴露。若是您決定不採用這種機制，並丟失了您的應用簽名密鑰，您將沒法更新您的應用，很遺憾，一旦發生這種狀況咱們就沒法提供任何幫助了。

動態功能

Android App Bundle 的另外一個重要創新是模塊化設計。這意味着您能夠嚮應用添加模塊，其中包含可以按需加載的其餘應用功能。這就是我以前提到的應用變大的一個重要緣由：功能的增加。如今，您能夠添加更多功能，而無需在安裝時增長應用的大小。使用動態功能也是在 Android 上動態加載代碼的安全作法，由於動態功能模塊的掃描和檢查方式與 Google Play Protect 掃描和檢查應用自己的方式相同。

任何應用功能均可以包含在動態功能模塊中，並按需提供。您能夠像編寫應用同樣對動態功能進行編碼。適用的功能包括：

安裝時不須要的大型功能：您能夠按需加載這些功能，或者告訴 Google Play 推遲安裝它們，即在後檯安裝它們。您能夠經過這種方式加載高達 100MB 的功能。在發佈時，不屬於核心應用體驗範疇的高級功能或附加組件很適合進行這樣的處理，例如付費高級功能、個性化選項、AR 功能等。
針對特定受衆羣體的功能：您能夠將其做爲動態功能進行建立，而不是爲每一個受衆羣體添加功能。例如，商業應用能夠隔離動態功能模塊中的銷售功能，所以只有購買功能在安裝時纔會分發給每一個用戶。須要銷售功能的小部分用戶羣體 (即銷售人員) 能夠在須要時下載和訪問這個功能。一些開發者還在探索動態功能，避免爲僅僅是略有不一樣的用戶羣體提供爲數過多的不一樣應用變體。
不多使用的功能：動態功能模塊的另外一個用武之地是，用於那些不多使用或僅使用一次的功能。例如，若是您的應用包含有一次性身份驗證或信用卡掃描功能，那麼若是您可以根據用戶須要加載此功能，並在使用後當即將其卸載，就能夠有效避免增長應用體積。它還能夠避免佔用應用生命週期內未使用的空間——再次強調，更大的應用更有可能被卸載。

即時發現

我已經講過了 Android App Bundle 如何幫助您保持應用的小巧，並經過動態功能實現應用的高度配置化。Android App Bundle 還支持免安裝應用 (Instant Apps)。Google Play Instant 容許用戶在安裝完整應用或遊戲以前，經過 Play Store 中的「當即試用」按鈕、廣告和連接試用應用和遊戲。Instant 如今安裝在 13 億臺設備上，而且被證實是驅動應用發現和安裝的極佳方法，從而爭取到那些可能還沒有安裝應用的用戶。Vimeo 是利用 Google Play Instant 取得成功的衆多合做夥伴之一，他們的報告顯示，15％的新安裝量都來自他們的試用功能。

過去，因爲構建和發佈過程都是獨立的，有些開發者並非很容易採用免安裝應用。可是隨着 Android App Bundles 的到來，您沒必要再去構建和維護單獨的免安裝應用。切換到應用束後，您能夠添加一個模塊做爲免安裝應用的入口點，若是您的應用足夠小的話，只需啓用基本模塊便可。應用基本模塊和免安裝應用模塊的大小限制爲 10MB，這樣就能夠啓用 Play Store 和 Web 橫幅上的「當即試用」按鈕。免安裝應用只能請求受到支持的權限。若是您安裝的應用須要使用其餘權限，請在免安裝應用中妥善地進行提示，以確保用戶可以得到良好的體驗。

這並不意味着每一個應用都很容易知足 10MB 的體積限制。使用動態功能模塊逐步加載功能是大幅減小應用體積的衆多方法之一。10MB 的大小限制僅適用於將啓用了免安裝功能的應用束推送到生產環境的時候，因此在此以前您能夠在超出大小限制的狀況下對其進行測試。若是您可以將基本模塊和免安裝入口模塊進一步減小到 4MB 如下，則可激活更多免安裝體驗的曝光機會，例如 Google Search 以及經過電子郵件或社交媒體等渠道共享的任何 Web 連接。想建立支持免安裝的或者正常安裝的應用束的話，您也可使用 Android Studio 3.3 beta 版。

更快的更新速度

我想談的最後一件事是，讓用戶手中的應用保持在最新狀態。吸引和留住受衆的最後一步是，確保他們擁有您全部的最新功能和最新補丁。雖然許多 Google Play 用戶已經啓用了自動更新功能，但許多用戶還還沒有啓用，還有些用戶沒法頻繁鏈接到高速的 Wi-Fi 鏈接並保持全部應用的正常更新。新的應用內更新 API (In-app Updates API) 可以讓您檢測什麼時候有可用的更新，並集成可定製的在線更新流程，它的外觀和感受就像是應用的一部分。檢測到更新時，您能夠經過提示通知用戶當即更新，也能夠按照您選擇的方式進行提示，從而更靈活地通知用戶進行更新。

咱們專門爲關鍵的更新設計了即刻更新流程，例如安全修復程序或隱私加強功能，從而確保用戶儘快應用這些更新。當用戶在您的應用中接受此更新時，系統會下載並應用此更新，並會自動從新啓動應用。有些應用已經爲此實現了本身的解決方案，不過新的 API 經過一種更簡單的標準化方式，在您的應用在運行中執行此操做。另外，更新的時機也更加靈活，只要用戶接受了更新，它將在後臺開始下載。下載完成後，您能夠提示用戶從新啓動應用，也能夠在應用進入後臺時對其進行更新。

Google Chrome 如今正在測試應用內更新API，咱們很快就會向更多開發者推出。它適用於任何應用，所以您能夠在切換到應用束時使用它。若是您想要得到良好的更新率，最好向用戶明確說明更新的好處，若是有可能的話，讓他們在完成想作的事情後再進行更新，而不是在他們首次打開您的應用時就詢問他們是否須要更新。當有人第一次打開您的應用時，他們必定是帶有明確的使用目的的，這時的他們並不想等待應用更新。