快速進行 Android 的疊代開發
本頁說明 bazel mobile-install 如何進行疊代開發
大幅加快應用程式的開發速度它將說明這種方法的優點，以及
面臨了傳統應用程式安裝方式的難題
摘要
如要快速安裝對 Android 應用程式的小變更，請按照下列步驟操作：
- 找到要安裝的應用程式，找出
android_binary規則。 - 移除
proguard_specs屬性即可停用 Proguard。 - 將
multidex屬性設為native。 - 將
dex_shards屬性設為10。 - 透過 USB 連接執行 ART (而非 Dalvik) 的裝置，並啟用 USB 其中偵錯。
- 執行
bazel mobile-install :your_target。 應用程式啟動作業 比平常慢。 - 編輯程式碼或 Android 資源。
- 執行
bazel mobile-install --incremental :your_target。 - 不用再等太多了，
以下為 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 個資料分割之間。
檔案傳輸增量
建構應用程式後，下一步是安裝應用程式，最好使用 要花最少的工夫安裝程序包含下列步驟：
- 安裝 .apk (通常使用
adb install) - 將 .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，並非 重點)