為什麼說它對 Android 未來的發展十分重要？
作者 / Dom Elliott, 產品經理, Google+Play/">Google Play
由於其開放性，Android 在其前十年取得了顯著的增長。有大量的裝置可供選擇，蓬勃發展的開發者生態系統提供了許多應用和遊戲，為這些裝置賦予了長久的生命力。作為開發者，您希望確保使用者儘可能獲得最佳體驗，並確保您的應用盡可能在所有這些裝置上執行。您還希望儘可能多的使用者安裝您的應用; 您也希望他們持續使用它; 並且您不希望他們因您無法控制的原因解除安裝您的應用。到目前為止，Android 應用的釋出和分發方式在所有這些方面都有待改進。我想觀察一下開發者面臨的一些挑戰，並告訴您 Google 正在採取哪些措施來提供幫助。
回首 Android 的第一個十年
十年來，在 Android 上釋出應用的流程如下：
-
第 1 步：在 IDE 中為您的應用編寫程式碼，例如 Android Studio。
-
第 2 步：當您準備好測試或釋出應用時，您可以將其構建為 APK，也就是 Android 的應用格式。作為構建 APK 的一部分，您可以使用應用簽名金鑰對其進行數字簽名。為應用簽名意味著安全地為其新增唯一證書。這種機制可以確保您是唯一可以繼續更新此應用的人。這種機制是這麼工作的：在更新應用之前，Android 始終會檢查更新的證書是否與裝置上應用的證書相匹配。稍後我會詳細闡明為什麼我要講這些。
-
第 3 步：使用 Google Play Console 將已簽名的 APK 上傳到測試軌道。待測試和調整就緒後，將應用正式釋出，並分發到世界各地。
-
第 4 步：Google Play 會將已經被您簽名的 APK (就是您上傳的那個) 在安裝時分發至每個使用者的裝置。
多年來，這種方法運作良好。實際上，人們每個月都會從 Google Play 安裝超過 80 億個應用！但是，正如您將看到的，這種模式為開發者帶來了難以忽視的挑戰。
難以忽視的 “大” 問題
挑戰在於： 應用的體積越來越大 了。事實上，自 2012 年以來，應用體積平均增長了 5 倍。這很好理解： 您希望為應用新增炫酷功能和新內容，以確保使用者留存/迴歸並保持業務增長。裝置效能越來越好，您希望能把那些閃亮的新功能利用起來。裝置生態系統變得更加多樣化了，因此您決定複製應用中的程式碼和資源，使其在大螢幕和小螢幕上都能流暢執行，在不同種類的 CPU 上都能流暢執行，等等。
如果每個使用者都擁有無限的儲存空間、無限的資料流量和永遠存在的快速連線，那麼應用越來越大並沒有什麼問題。遺憾的是，事實並非如此 (當然我們希望有一天能夠如此！)。通過檢視下圖，您可以看到 Google Play 上的應用大小與其安裝轉化率呈負相關關係。這意味著隨著應用變大，其安裝率會下降。出現這種情況有很多原因：許多使用者的裝置上沒有足夠的可用空間。使用者可能在使用儲存空間一般的入門級裝置，即使對於那些擁有高階裝置的使用者而言，他們的照片、視訊和其他媒體檔案的品質也在逐漸提升，從而佔據了越來越大的空間，裝置上的可用空間正在逐漸緊縮。使用者也不希望一邊用著昂貴的流量套餐，一邊等待大型應用去慢慢連線網路，在新興市場尤其如此。
。在 Google Play 去年進行的使用者調查中，人們解除安裝應用和遊戲的主要原因是為了騰出空間，即便這些應用和遊戲已經被使用了至少一個月。
針對上述問題，開發者們能採用的解決方案很有限。您可以在單個版本中為每個裝置配置構建多個 APK。但當您想要針對不同螢幕尺寸和 CPU 架構進行優化，同時針對 32 位和 64 位時，情況很快就會失控——您最終可能會為每個版本構建數百個 APK。這很痛苦，大多數開發者都不會這樣做。許多人只是將所有內容都放在一個“胖胖的” APK 中，最終導致使用者裝置上存在著大量未使用過的內容。而且，即使您使用多重 APK，也無法針對語言進行優化。即使使用者只需要一種或兩種語言，您也必須在每個 APK 中包含針對每個裝置的所有翻譯字串，這樣會浪費更多空間。
因此，開發者的困境就顯而易見了：增加應用的體積，但可能會導致較低的轉換率和較高的解除安裝風險；使用多重 APK，會降低您的版本迭代效率並導致您疲憊不堪，您還可能會花費大量的時間權衡不同的功能之間的取捨，以避免增加應用體積。
“小” 而 “巧” 的解決方案來了
Google 不希望開發者面臨這些困境，因此我們一直在努力改進。大致的想法是這樣的：如果您將所需的所有內容上傳到了 Google Play，讓 Play Store 為每個使用者和裝置按需提供相應的內容。這很簡單，不是嗎？這一過程可以減少您支援 Android 多樣化生態系統所需的工作量，並使使用者手中的應用體積更小。正如您稍後將在本文中發現的那樣，這個新方案還有助於改善使用者獲取過程：通過功能和更新，即時發現、安裝、吸引，以及保留使用者。
更小的安裝包
為實現這一願景，Google 於今年早些時候推出了一款 ofollow,noindex">新的應用釋出格式 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，我們很快就會向更多開發者推出。它適用於任何應用，因此您可以在切換到應用束時使用它。如果您想要獲得良好的更新率，最好向使用者明確說明更新的好處，如果有可能的話，讓他們在完成想做的事情後再進行更新，而不是在他們首次開啟您的應用時就詢問他們是否需要更新。當有人第一次開啟您的應用時，他們一定是帶有明確的使用目的的，這時的他們並不想等待應用更新。
所有的這些努力旨在幫助您通過更小、更高效的應用以及更快，更簡化的版本來促成更多的安裝量和更小的解除安裝率。Android App Bundle 還支援高度可配置的應用，它們擁有動態功能和即時試用體驗，從而增加轉換率。最後，想要讓使用者的應用保持最新也比以前更加容易了。