bazel 行動安裝

回報問題 查看來源 。 。 夜間。 。 7.3 。 。 7.2 。 。 7.1 。 。 7.0 。 。 6.5

快速進行 Android 的疊代開發

本頁說明 bazel mobile-install 如何進行疊代開發 大幅加快應用程式的開發速度它將說明這種方法的優點,以及 面臨了傳統應用程式安裝方式的難題

摘要

如要快速安裝對 Android 應用程式的小變更,請按照下列步驟操作:

  1. 找到要安裝的應用程式,找出 android_binary 規則。
  2. 移除 proguard_specs 屬性即可停用 Proguard。
  3. multidex 屬性設為 native
  4. dex_shards 屬性設為 10
  5. 透過 USB 連接執行 ART (而非 Dalvik) 的裝置,並啟用 USB 其中偵錯。
  6. 執行 bazel mobile-install :your_target。 應用程式啟動作業 比平常慢。
  7. 編輯程式碼或 Android 資源。
  8. 執行 bazel mobile-install --incremental :your_target
  9. 不用再等太多了,

以下為 Bazel 的指令列選項,或許能派上用場:

  • --adb 會告知 Bazel 要使用哪個 ADB 二進位檔
  • --adb_arg 可用於在 adb 的指令列中加入額外的引數。 選取要安裝的裝置 將多部裝置連線至工作站時: bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target
  • --start_app」會自動啟動應用程式

有疑問時, 範例與我們聯絡

簡介

開發人員工具鍊的一大特色是速度: 變更程式碼後,查看程式碼在 且須等待幾分鐘,有時甚至需要等數小時才能收到意見回饋 瞭解變更是否達到預期的效果

可惜的是,建構 .apk 所需的傳統 Android 工具鍊 必須完成許多單體式、循序步驟和所有步驟 建構 Android 應用程式在 Google,等待五分鐘建立一行 對 Google 地圖這類大型專案而言,變更是不尋常的。

bazel mobile-install 大幅加快 Android 應用程式的疊代開發速度 結合變更裁切、工作資料分割,以及精細操縱 Android 內部,完全不必變更應用程式的程式碼。

傳統應用程式安裝相關問題

建構 Android 應用程式有一些問題,包括:

  • Dex 處理。預設為「dx」。只會在建構中叫用一次 瞭解如何重複使用之前建構作業中的工作:會再次執行每個方法, 但只有一種方法會變更

  • 正在將資料上傳至裝置。ADB 未使用 USB 2.0 的完整頻寬 因此,上傳大型應用程式可能需要花費相當長的時間。整個應用程式 即使只有一小部分變動 (例如資源或 單一方法,因此造成相當嚴重的瓶頸。

  • 編譯至原生程式碼。Android L 推出了全新的 Android 執行階段 ART。 這項功能可以預先編譯應用程式,而不是像及時編譯應用程式一樣 Dalvik。這會加快應用程式安裝速度,但耗費較長時間 讓應用程式從可以最快做出回應的位置 回應使用者要求對使用者來說,這是個好的權衡方法,因為他們通常會安裝應用程式 但使用者多次使用這個方法 但會導致開發速度變慢 安裝多次,且每個版本可執行次數最多。

bazel mobile-install 的做法

bazel mobile-install進行下列改善:

  • 資料分割 dex 處理。Bazel 會在建構應用程式的 Java 程式碼後,對類別進行資料分割 然後將檔案分成大約相同大小的部分,並在以下位置分別叫用 dx 具體做法是指示 Kubernetes 建立並維護 一或多個代表這些 Pod 的物件系統不會在上次建構後未變更的資料分割上叫用 dx

  • 漸進式檔案傳輸。Android 資源、.dex 檔案和原生 程式庫會從主要 .apk 中移除,然後儲存在個別的 行動裝置安裝目錄。這樣您就能更新程式碼和 Android 不必重新安裝整個應用程式因此, 轉移檔案的程序較少,而且只會轉移含有設定檔資料的 .dex 檔案 而是會在裝置端重新編譯。

  • 從 .apk 外部載入應用程式的部分內容。小型虛設常式應用程式 放入載入 Android 資源、Java 程式碼和原生程式碼的 .apk 然後將控制權轉入 實際的應用程式。此資訊對應用程式公開,除了少數極少數情況下例外 。

資料分割 Dex 處理

分割的 DEX 檔案結構相當簡單明瞭:建立 .jar 檔案後, 工具 將這些檔案分割成大小相等大小的個別 .jar 檔案,然後叫用 dx解碼器的邏輯 判斷哪些資料分割是由 Android 所特有;它只會使用 Bazel 的一般變更縮減演算法

第一版的資料分割演算法只是排序 .class 檔案 再依字母順序將清單分割為相同大小的部分,不過這證明瞭 不理想:新增或移除類別 (即使是巢狀或匿名) 會導致所有類別依字母順序位移 即可再次將那些資料分割進行 DEX 處理因此,他們決定要分割 Java 而非個別類別當然,這仍會導致 新增或移除套件時,對許多資料分割進行 DEX 處理,但做法少很多 比起新增或移除單一類別的頻率更高

資料分割的數量是由 BUILD 檔案控制 (使用 android_binary.dex_shards 屬性)。在理想的世界中 會自動判斷最佳資料分割數量,但目前必須知道 一組動作 (例如,要在建構期間執行的指令) 其中任何 Pod 會在執行中,因此無法判斷最適合的資料分割數量 因為該函式不知道最終會在 應用程式。一般來說,資料分割越多,建構速度就越快 但應用程式啟動速度會變慢 連結器就會執行更多工作理想的位置通常介於 10 至 50 個資料分割之間。

檔案傳輸增量

建構應用程式後,下一步是安裝應用程式,最好使用 要花最少的工夫安裝程序包含下列步驟:

  1. 安裝 .apk (通常使用 adb install)
  2. 將 .dex 檔案、Android 資源和原生程式庫上傳到 行動裝置安裝目錄

第一個步驟的成效不大:應用程式已安裝應用程式 不一定。Bazel 目前仰賴使用者判斷是否應執行這個步驟 透過 --incremental 指令列選項判斷 或與所有案件通訊

在第二個步驟中,系統會將該版本的應用程式檔案與裝置端檔案進行比較 資訊清單檔案,列出裝置上有哪些應用程式檔案 和總和檢查碼系統會將任何新檔案上傳到裝置,包括發生變更的檔案 而所有遭移除的檔案都會從 裝置。如果資訊清單沒有資訊清單,系統會假設每個檔案都需 上傳。

請注意,如要強制安裝漸進式安裝演算法, 變更裝置上的檔案,但不變更資訊清單中的總和檢查碼。這麼做 已計算該網頁上檔案的總和檢查碼 但安裝時間不應增加。

Stub 應用程式

虛設常式應用程式是強大功能,可用來載入 dexe、原生程式碼 系統會執行裝置 mobile-install 目錄中的 Android 資源。

BaseDexClassLoader 設為子類別,即可實作實際載入, 合理記錄的技術。這項作業會發生在 因為系統已載入類別,因此 apk 中的任何應用程式類別皆可 放在裝置端的 mobile-install 目錄中,以便更新 沒有 adb install

這項作業必須在 應用程式的類別會載入,因此應用程式類別不需要位於 .apk,這表示變更這些類別需要完整的 重新安裝。

方法是將 Application 中的指定 Application 類別替換為 AndroidManifest.xml,其中包含 虛設常式應用程式。這個 能控制應用程式的啟動時間,並微調類別載入器和 在應用程式建構函式中正確使用資源管理工具 Android 架構內部的 Java 反思。

虛設常式應用程式的另一個功能是複製原生資料庫 安裝在其他位置的行動。這項資訊是必要的,因為 必須在檔案中設定 X 位元,但動態連接器 適用於非根 adb 存取的任何位置。

完成上述所有操作後,虛設常式應用程式 實際 Application 類別,將所有參照自身的參照變更為實際 套用負責任的 AI 技術做法

結果

成效

一般來說,bazel mobile-install 可使建築物的速度提升 4 至 10 倍 小幅變更及安裝大型應用程式

我們針對部分 Google 產品計算了下列數字:

當然,這取決於變更的本質:在 變更基礎程式庫需要更多時間

限制

並非所有情況都能使用虛設常式應用程式。 以下列舉幾個功能無法正常運作的情況:

  • Context 投放到 Application 類別時 ContentProvider#onCreate()。系統會在應用程式執行期間呼叫這個方法 我們尚未有機會替換 Application 的例項 因此,ContentProvider 仍會參照虛設常式應用程式 而不是真正的一個這並非錯誤,因為您沒有 應該要像這樣下降 Context,但這似乎在少數幾個發生 都值得信賴

  • bazel mobile-install」安裝的資源只能在以下位置使用: 應用程式如果其他應用程式透過 PackageManager#getApplicationResources(),這些資源會從 上次非增量安裝。

  • 並非執行 ART 的裝置。雖然虛設常式應用程式運作時 Froyo 和之後的 Dalvik 發生一項錯誤,導致系統判斷應用程式是 如果它的程式碼分散在多個 .dex 檔案中 例如,若在 特定 。只要您的應用程式不會造成這些錯誤,就能與 Dalvik 搭配運作 也提醒您 (請注意,支援舊版 Android,並非 重點)