instal seluler bazel

Laporkan masalah Lihat sumber Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Pengembangan iteratif yang cepat untuk Android

Halaman ini menjelaskan cara bazel mobile-install membuat pengembangan iteratif untuk Android menjadi jauh lebih cepat. Bagian ini menjelaskan manfaat pendekatan ini dibandingkan dengan tantangan metode penginstalan aplikasi tradisional.

Ringkasan

Untuk menginstal perubahan kecil pada aplikasi Android dengan sangat cepat, lakukan hal berikut:

  1. Temukan aturan android_binary aplikasi yang ingin Anda instal.
  2. Nonaktifkan Proguard dengan menghapus atribut proguard_specs.
  3. Tetapkan atribut multidex ke native.
  4. Tetapkan atribut dex_shards ke 10.
  5. Hubungkan perangkat Anda yang menjalankan ART (bukan Dalvik) melalui USB dan aktifkan proses debug USB di perangkat tersebut.
  6. Jalankan bazel mobile-install :your_target. Peluncuran aplikasi akan sedikit lebih lambat dari biasanya.
  7. Edit kode atau resource Android.
  8. Jalankan bazel mobile-install --incremental :your_target.
  9. Nikmati waktu tunggu yang singkat.

Beberapa opsi command line untuk Bazel yang mungkin berguna:

  • --adb memberi tahu Bazel biner adb mana yang akan digunakan
  • --adb_arg dapat digunakan untuk menambahkan argumen tambahan ke command line adb. Salah satu aplikasi yang berguna dari hal ini adalah memilih perangkat yang ingin Anda instal jika Anda memiliki beberapa perangkat yang terhubung ke workstation Anda: bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target
  • --start_app otomatis memulai aplikasi

Jika ragu, lihat contoh atau hubungi kami.

Pengantar

Salah satu atribut terpenting dari toolchain developer adalah kecepatan: ada perbedaan besar antara mengubah kode dan melihatnya berjalan dalam waktu satu detik dan harus menunggu beberapa menit, terkadang berjam-jam, sebelum Anda mendapatkan masukan tentang apakah perubahan Anda melakukan apa yang Anda harapkan.

Sayangnya, toolchain Android tradisional untuk membangun .apk memerlukan banyak langkah monolitik dan berurutan, dan semua langkah ini harus dilakukan untuk membangun aplikasi Android. Di Google, menunggu lima menit untuk membangun perubahan satu baris bukanlah hal yang aneh dalam project yang lebih besar seperti Google Maps.

bazel mobile-install membuat pengembangan iteratif untuk Android jauh lebih cepat dengan menggunakan kombinasi penghapusan perubahan, pembagian tugas, dan manipulasi cerdas internal Android, semuanya tanpa mengubah kode aplikasi Anda.

Masalah pada penginstalan aplikasi tradisional

Membangun aplikasi Android memiliki beberapa masalah, termasuk:

  • Dexing. Secara default, "dx" dipanggil tepat satu kali dalam build dan tidak tahu cara menggunakan kembali pekerjaan dari build sebelumnya: "dx" akan melakukan dexing setiap metode lagi, meskipun hanya satu metode yang diubah.

  • Mengupload data ke perangkat. ADB tidak menggunakan bandwidth penuh koneksi USB 2.0, dan aplikasi yang lebih besar dapat memerlukan waktu yang lama untuk diupload. Seluruh aplikasi diupload, meskipun hanya sebagian kecil yang berubah, misalnya, resource atau satu metode, sehingga hal ini dapat menjadi hambatan besar.

  • Kompilasi ke kode native. Android L memperkenalkan ART, runtime Android baru, yang mengompilasi aplikasi ahead-of-time, bukan mengompilasinya just-in-time seperti Dalvik. Hal ini membuat aplikasi jauh lebih cepat dengan biaya waktu penginstalan yang lebih lama. Hal ini merupakan kompromi yang baik bagi pengguna karena mereka biasanya menginstal aplikasi sekali dan menggunakannya berkali-kali, tetapi menghasilkan pengembangan yang lebih lambat jika aplikasi diinstal berkali-kali dan setiap versi dijalankan paling banyak beberapa kali.

Pendekatan bazel mobile-install

bazel mobile-installmelakukan peningkatan berikut:

  • Dexing dengan sharding. Setelah membuat kode Java aplikasi, Bazel akan membagi file class menjadi beberapa bagian yang ukurannya hampir sama dan memanggil dx secara terpisah pada bagian tersebut. dx tidak dipanggil pada shard yang tidak berubah sejak build terakhir.

  • Transfer file inkremental. Resource Android, file .dex, dan library native dihapus dari .apk utama dan disimpan di direktori penginstalan seluler terpisah. Hal ini memungkinkan Anda mengupdate kode dan resource Android secara terpisah tanpa menginstal ulang seluruh aplikasi. Dengan demikian, transfer file membutuhkan waktu lebih sedikit dan hanya file .dex yang telah berubah yang dikompilasi ulang di perangkat.

  • Memuat bagian aplikasi dari luar .apk. Aplikasi stub kecil dimasukkan ke dalam .apk yang memuat resource Android, kode Java, dan kode native dari direktori penginstalan seluler di perangkat, lalu mentransfer kontrol ke aplikasi sebenarnya. Semua ini transparan bagi aplikasi, kecuali dalam beberapa kasus ekstrem yang dijelaskan di bawah.

Dexing dengan Sharding

Pengindeksan DEX yang di-shard cukup mudah: setelah file .jar dibuat, alat akan membagi file tersebut menjadi file .jar terpisah dengan ukuran yang hampir sama, lalu memanggil dx pada file yang diubah sejak build sebelumnya. Logika yang menentukan shard mana yang akan di-dex tidak khusus untuk Android: logika ini hanya menggunakan algoritma penghapusan perubahan umum Bazel.

Versi pertama algoritma sharding hanya mengurutkan file .class secara alfabetis, lalu membagi daftar menjadi beberapa bagian berukuran sama, tetapi hal ini terbukti kurang optimal: jika suatu class ditambahkan atau dihapus (bahkan yang bertingkat atau anonim), semua class setelahnya secara alfabetis akan bergeser satu, sehingga menyebabkan sharding tersebut di-dex lagi. Oleh karena itu, diputuskan untuk membagi paket Java, bukan class individual. Tentu saja, hal ini masih menghasilkan pengindeksan banyak shard jika paket baru ditambahkan atau dihapus, tetapi hal itu jauh lebih jarang terjadi daripada menambahkan atau menghapus satu class.

Jumlah shard dikontrol oleh file BUILD (menggunakan atribut android_binary.dex_shards). Dalam kondisi ideal, Bazel akan menentukan secara otomatis jumlah shard yang terbaik, tetapi saat ini Bazel harus mengetahui kumpulan tindakan (misalnya, perintah yang akan dieksekusi selama build) sebelum mengeksekusi salah satunya, sehingga Bazel tidak dapat menentukan jumlah shard yang optimal karena tidak mengetahui jumlah class Java yang akan ada di aplikasi. Secara umum, semakin banyak shard, semakin cepat build dan penginstalan, tetapi semakin lambat startup aplikasi, karena linker dinamis harus melakukan lebih banyak pekerjaan. Titik idealnya biasanya antara 10 dan 50 shard.

Transfer file inkremental

Setelah mem-build aplikasi, langkah selanjutnya adalah menginstalnya, sebaiknya dengan upaya sesedikit mungkin. Penginstalan terdiri dari langkah-langkah berikut:

  1. Menginstal .apk (biasanya menggunakan adb install)
  2. Mengupload file .dex, resource Android, dan library native ke direktori mobile-install

Tidak banyak inkrementalitas pada langkah pertama: aplikasi diinstal atau tidak. Saat ini, Bazel mengandalkan pengguna untuk menunjukkan apakah langkah ini harus dilakukan melalui opsi command line --incremental karena Bazel tidak dapat menentukan dalam semua kasus apakah langkah ini diperlukan.

Pada langkah kedua, file aplikasi dari build dibandingkan dengan file manifes di perangkat yang mencantumkan file aplikasi yang ada di perangkat dan checksum-nya. File baru akan diupload ke perangkat, file yang telah berubah akan diperbarui, dan file yang telah dihapus akan dihapus dari perangkat. Jika manifes tidak ada, diasumsikan bahwa setiap file perlu diupload.

Perhatikan bahwa algoritma penginstalan inkremental dapat ditipu dengan mengubah file di perangkat, tetapi tidak mengubah checksum-nya dalam manifes. Hal ini dapat dicegah dengan menghitung checksum file di perangkat, tetapi hal ini dianggap tidak sebanding dengan peningkatan waktu penginstalan.

Aplikasi Stub

Aplikasi stub adalah tempat terjadinya keajaiban untuk memuat dex, kode native, dan resource Android dari direktori mobile-install di perangkat.

Pemuatan sebenarnya diimplementasikan dengan membuat subclass BaseDexClassLoader dan merupakan teknik yang didokumentasikan dengan cukup baik. Hal ini terjadi sebelum class aplikasi dimuat, sehingga class aplikasi apa pun yang ada di APK dapat ditempatkan di direktori mobile-install pada perangkat agar dapat diupdate tanpa adb install.

Hal ini harus terjadi sebelum class aplikasi dimuat, sehingga tidak ada class aplikasi yang perlu ada di .apk, yang berarti perubahan pada class tersebut akan memerlukan penginstalan ulang penuh.

Hal ini dilakukan dengan mengganti class Application yang ditentukan dalam AndroidManifest.xml dengan aplikasi stub. Hal ini mengambil kontrol saat aplikasi dimulai, dan menyesuaikan pemuat class dan pengelola resource dengan tepat pada saat paling awal (konstruktornya) menggunakan refleksi Java pada internal framework Android.

Hal lain yang dilakukan aplikasi stub adalah menyalin library native yang diinstal oleh mobile-install ke lokasi lain. Hal ini diperlukan karena linker dinamis memerlukan bit X untuk disetel pada file, yang tidak dapat dilakukan untuk lokasi mana pun yang dapat diakses oleh adb non-root.

Setelah semua hal ini dilakukan, aplikasi stub kemudian membuat instance kelas Application yang sebenarnya, mengubah semua referensi ke dirinya sendiri menjadi aplikasi yang sebenarnya dalam framework Android.

Hasil

Performa

Secara umum, bazel mobile-install menghasilkan peningkatan kecepatan 4x hingga 10x dalam membangun dan menginstal aplikasi besar setelah perubahan kecil.

Angka berikut dihitung untuk beberapa produk Google:

Tentu saja, hal ini bergantung pada sifat perubahannya: kompilasi ulang setelah mengubah library dasar memerlukan waktu lebih lama.

Batasan

Trik yang dimainkan aplikasi stub tidak berfungsi dalam setiap kasus. Kasus berikut menunjukkan saat fitur ini tidak berfungsi seperti yang diharapkan:

  • Saat Context ditransmisikan ke class Application di ContentProvider#onCreate(). Metode ini dipanggil selama startup aplikasi sebelum kita memiliki kesempatan untuk mengganti instance class Application, oleh karena itu, ContentProvider akan tetap mereferensikan aplikasi stub bukan aplikasi yang sebenarnya. Mungkin ini bukan bug karena Anda tidak seharusnya melakukan downcast Context seperti ini, tetapi hal ini tampaknya terjadi di beberapa aplikasi di Google.

  • Resource yang diinstal oleh bazel mobile-install hanya tersedia dari dalam aplikasi. Jika resource diakses oleh aplikasi lain melalui PackageManager#getApplicationResources(), resource ini akan berasal dari penginstalan non-inkremental terakhir.

  • Perangkat yang tidak menjalankan ART. Meskipun aplikasi stub berfungsi dengan baik di Froyo dan yang lebih baru, Dalvik memiliki bug yang membuatnya mengira bahwa aplikasi salah jika kodenya didistribusikan melalui beberapa file .dex dalam kasus tertentu, misalnya, saat anotasi Java digunakan dengan cara tertentu. Selama aplikasi Anda tidak memicu bug ini, aplikasi tersebut akan berfungsi dengan Dalvik, (namun, perhatikan bahwa dukungan untuk Android versi lama bukanlah fokus kami)