Pengurangan 60% dalam ukuran aplikasi Bereaksi Asli dalam beberapa langkah sederhana

Saya bekerja di Mutual . Dia bekerja di Brasil, di bidang kredit yang sama. Kami membantu peminjam dan pemberi pinjaman untuk terhubung satu sama lain. Yang pertama mencari taruhan yang baik, sedangkan yang kedua mencari pendapatan yang melebihi apa yang bisa ditawarkan pasar kepada mereka. Produk kami digunakan oleh berbagai pengguna, kami bekerja di negara besar. Akibatnya, aplikasi iOS dan Android berbasis React Native kami mengunduh ke perangkat yang sangat berbeda.



Perlu dicatat bahwa sebagian besar pengguna kami menginstal aplikasi pada perangkat anggaran. Kita bisa menarik kesimpulan seperti itu menggunakan data dari pustaka kelas perangkat Facebook Facebook.. Pustaka ini, setelah menerima informasi tentang model perangkat, melaporkan tahun mana perangkat ini akan dianggap sebagai ponsel unggulan kelas atas. Misalnya, ponsel paling populer di kalangan pengguna kami adalah Samsung Galaxy A10. Ponsel ini, meskipun dirilis pada tahun 2019, dapat dianggap sebagai unggulan hanya pada tahun 2013. Menganalisis data pada perangkat pengguna, dapat dikatakan bahwa 85% dari perangkat ini dapat dikenali sebagai perangkat kelas atas hanya pada tahun 2015 atau sebelumnya. Karena itu, kami memiliki persyaratan khusus untuk mengoptimalkan aplikasi seluler kami. Tujuan pengoptimalan adalah agar pengguna dengan perangkat yang lemah sekalipun dapat dengan nyaman menggunakan aplikasi kami.


Persentase perangkat yang dapat dikenali sebagai unggulan di tahun tertentu

Dalam hal ini, kami memperhatikan ukuran aplikasi. Dalam hal versi Android-nya, itu 26,8 MB. Meskipun ini bukan ukuran besar, itu pasti lebih dari ukuran median aplikasi pengguna kami. Angka ini, menurut Google Play Console, adalah 16,3 MB. Ukuran aplikasi dapat menjadi faktor penentu bagi pengguna dengan paket tarif terbatas, atau bagi mereka yang memiliki perangkat dengan memori rendah, yang memaksa pengguna untuk dengan hati-hati memilih aplikasi yang akan mereka instal. Akibatnya, beberapa aplikasi harus dihapus instalasinya. Ini sangat penting dalam kasus aplikasi Reksa, karena peminjam membayar cicilan bulanan melalui aplikasi ini. Ketika peminjam mencopot pemasangan aplikasi kita, kemungkinan dia akan melakukan pembayaran tepat waktu sangat berkurang.Dan ini secara langsung mempengaruhi pendapatan investor yang menggunakan platform kami.


Ukuran aplikasi Saling jauh lebih besar dari ukuran median

aplikasi pengguna kami . Ukuran aplikasi tidak hanya mempengaruhi tingkat penghapusan instalasi. Ukuran juga memengaruhi tingkat konversi pengaturan aplikasi. Inilah artikel bagus tentang ini yang ditulis oleh tim Google Play. Artikel ini membahas pentingnya ukuran aplikasi. Secara khusus, dikatakan bahwa setiap tambahan 6 MB dari ukuran file APK mengurangi tingkat konversi instalasi sebesar 1%.

Mereka juga berbicara tentang fakta bahwa di negara-negara berkembang di mana perangkat anggaran adalah norma, efek ini bahkan lebih kuat. Yaitu, mengurangi ukuran file APK sebesar 10 MB di pasar negara berkembang sesuai dengan peningkatan tingkat konversi instalasi sekitar 2,5%.


Meningkatkan tingkat konversi instalasi untuk setiap 10 Mb untuk mengurangi ukuran file APK di berbagai negara (menurut data internal Google)

Kami sangat termotivasi oleh bagaimana mengurangi ukuran aplikasi dapat memengaruhi tingkat penghapusan instalasi dan tingkat konversi pengaturan aplikasi. Sebagai hasilnya, kami mulai bekerja yang bertujuan mengurangi ukuran aplikasi sebanyak mungkin, dengan mempertimbangkan kenyamanannya bagi pengguna. Langkah pertama dalam proyek ini adalah menganalisis rekomendasi resmiGoogle untuk pengembang Android.

Bundel Aplikasi Android


Membaca rekomendasi, kami belajar bahwa cara termudah untuk mengurangi ukuran aplikasi adalah dengan menggunakan metode distribusi aplikasi baru yang disebut Android App Bundle (AAB). Hingga saat ini, kami mendistribusikan aplikasi, mengumpulkan file Android Package (APK) lama yang baik , yang dapat dijalankan di sebagian besar perangkat Android, dan mengunggahnya ke Google Play Console. Tetapi bundel AAB hanya berisi kode dan sumber daya yang dikompilasi. Akibatnya, ketika diunduh, Google bertanggung jawab untuk menghasilkan file APK yang dioptimalkan untuk berbagai jenis perangkat, dengan mempertimbangkan spesifikasi dan arsitektur CPU mereka.

Ternyata dengan melakukan perubahan sederhana pada proses pembangunan proyek, dapatkah kita mendapatkan pengurangan serius dalam ukuran aplikasi tanpa melakukan upaya lagi? Ini terlalu bagus untuk kebenaran!

Setelah kami membaca dokumentasi, kami baru saja mengubah skrip build React Native Gradle sehingga itu assembleReleaseakan berjalan alih-alih yang sekarang bundleRelease. Hanya itu yang kami butuhkan untuk membuat file AAB. Setelah beberapa modifikasi dilakukan pada supplykonfigurasi Fastlane mengenai pengunggahan otomatis bahan langsung ke Play Store, kami beralih ke AAB, dan versi baru aplikasi kami muncul di Google Play Console.

Perubahan ini saja telah menyebabkan pengurangan ukuran file APK yang ditransfer ke perangkat pengguna. Penurunan berkisar antara 9,1 hingga 12,4 Mb. Ternyata, penggunaan Bundel Aplikasi Android adalah teknik yang efektif yang memang memungkinkan Anda untuk mengurangi ukuran aplikasi.


File APK lama dan bundel AAB baru, yang penggunaannya mengarah pada fakta bahwa ukuran aplikasi pada perangkat yang berbeda dapat dari 14,4 hingga 17,7 MB

Benar, Anda harus berhati-hati di sini. Jika Anda menggunakan Bereaksi Asli dengan Hermes , maka Anda mungkin perlu memperbarui ketergantungan Andasoloader(lihat detailnya di sini ). Jika tidak, ada risiko memberi pengguna aplikasi yang akan mengandung kesalahan kritis. Kami beruntung, kami dapat mengidentifikasi masalah ini selama pengujian rilis alpha proyek. Tetapi kesalahan bisa dengan mudah masuk ke dalam produksi, karena tidak muncul selama pengujian lokal atau ketika membangun file APK.

Mengoptimalkan sumber daya aplikasi menggunakan Android Size Analyzer


Saran berikutnya untuk mengoptimalkan aplikasi yang kami temukan dalam dokumentasi adalah penggunaan Android Size Analyzer . Ini adalah alat baris perintah yang menganalisis aplikasi Android dan mencari cara untuk mengurangi ukurannya. Kami meluncurkan alat ini menggunakan perintah dari formulir berikut:

size-analyzer check-bundle [BUNDLE].aab

Hasilnya, kami mendapat daftar sumber daya aplikasi dan gambar yang bagus yang dapat kami optimalkan. Kami juga disarankan untuk mengatur ProGuard.


Laporan penganalisa ukuran

▍ProGuard


ProGuard adalah alat untuk mengompresi, mengaburkan, dan mengoptimalkan bytecode Java. Kami belum menjelajahi kemungkinan menggunakan alat ini, karena kami tahu bahwa itu mungkin tidak kompatibel dengan beberapa perpustakaan Android. Karena kami berupaya mengurangi ukuran aplikasi kami secepat mungkin, dan menjadikannya sesederhana mungkin, kami memutuskan untuk meninggalkan metode pengoptimalan ini di masa mendatang.

▍Sumber daya aplikasi yang besar


Menjalankannya size-analyzerlagi, dengan kunci -d, kami mendapat daftar sumber daya aplikasi, diurutkan berdasarkan ukurannya. Karena alat ini tidak tahu apa-apa tentang bagaimana pengguna bekerja dengan aplikasi, itu memberi kami kesempatan untuk secara mandiri memutuskan sumber daya mana yang harus dihapus dan mana yang harus dimuat ke dalam aplikasi secara dinamis.


Daftar sumber daya aplikasi besar yang diurutkan berdasarkan ukuran

Sumber daya pertama dan terbesar dalam daftar ini adalah bundel JavaScript Bereaksi Asli. Sekarang kita tidak dapat memisahkan bundel ini dan memuatnya secara dinamis. Tetapi nanti kita akan memikirkannya. Lebih jauh ke bawah daftar adalah file font besar (TTF) dan file gambar (JPG dan PNG).

▍ Gambar yang tidak perlu


Perhatian kami segera tertuju pada gambar-gambar JPG besar yang digunakan dalam Storybook . Kami menggunakan sistem ini untuk mengembangkan dan menguji komponen. Ini adalah 2 MB sampah yang masuk ke versi produksi proyek. Kesalahan memalukan! Ketika sesuatu seperti ini terjadi, kita merasa telah melakukan kebodohan yang serius. Namun dalam dunia pengembangan perangkat lunak yang kompleks, semua orang membuat kesalahan. Saya percaya bahwa jika Anda berbicara tentang kesalahan Anda di depan umum, itu akan membantu pengembang lain belajar dari kesalahan ini. Ada kemungkinan bahwa Anda membuat kesalahan yang sama jika Anda tidak menganalisis struktur sumber daya aplikasi, yang ukurannya secara bertahap meningkat.

▍ Font


Setelah kami dengan cepat menyingkirkan gambar yang tidak perlu, kami melanjutkan untuk menganalisis elemen lain dari daftar sumber daya. Jelas bahwa ada banyak font bawaan di dalamnya. Setelah kami membicarakan hal ini dengan para desainer kami, mereka memberi tahu kami bahwa banyak komponen lama tidak berbeda dalam kepatuhan ketat terhadap manual tipografi. Oleh karena itu, kami menemukan komponen mana yang dapat dihapus, dan di mana Anda dapat menggunakan font terbaru yang sesuai. Berkat ini, kami dapat mengurangi jumlah font yang digunakan dari enam menjadi empat.

Hal lain yang kami perhatikan adalah ukuran file font itu sendiri. Ukuran masing-masing sekitar 670 Kb. Ini berarti bahwa empat font dalam bundel terkompresi menempati 2,7 Mb yang menakjubkan. Tapi, untungnya, ada alat bernama FontForge yang memungkinkan Anda untuk menganalisis dan memodifikasi file font secara mendalam. Dengan menggunakan alat ini, kami dapat menemukan bahwa alasan utama untuk ukuran besar file font adalah karakter Cyrillic yang diperluas dan mesin terbang yang tidak perlu. Kita dapat menghapus semua ini dengan aman, karena bagian teks dari aplikasi kita sepenuhnya ditulis dalam bahasa Portugis. Berkat perubahan ini, kami dapat mengurangi ukuran file font dari 670 Kb menjadi 70 Kb - hingga 90%.


Contoh beberapa mesin terbang termasuk dalam font kami

Karena fakta bahwa kami menyingkirkan font yang tidak perlu dan mengoptimalkan yang tersisa, kami dapat mengurangi ukuran aplikasi sebesar 3,8 Mb. Ini menyebabkan pengurangan yang menyenangkan dalam ukuran total file APK sebesar 2 MB.


Daftar font dan ukurannya sebelum optimasi


Daftar font dan ukurannya setelah optimasi

PtOptimasi gambar


Setelah menganalisis gambar yang masih tersisa di aplikasi, kami perhatikan bahwa beberapa di antaranya cukup besar. Kami memproses beberapa gambar ini dengan alat optimisasi grafis TinyPNG dan melihat pengurangan yang signifikan dalam ukuran gambar-gambar ini. Setelah itu, kami memutuskan untuk mengoptimalkan semua gambar JPG dan PNG yang digunakan dalam aplikasi. Ada 41 dari mereka.


Gambar sebelum dan sesudah optimasi

Ini memberi kami kesempatan untuk mengurangi ukuran gambar dari 2,5 MB menjadi 756 KB, yaitu sebesar 70%. Namun, karena fakta bahwa gambar sebelumnya tidak dioptimalkan, mereka dikompresi selama pembuatan file APK akhir. Ternyata pengoptimalan kami menyebabkan penurunan ukuran aplikasi yang diunduh oleh pengguna hanya 500 Kb.

Setelah itu, kami menyadari bahwa kami telah kehabisan semua kemungkinan optimasi cepat. Melanjutkan optimalisasi sumber daya akan membutuhkan upaya besar atau hanya perbaikan kecil.

Bereaksi Optimasi Bundel JavaScript Asli


Setelah kami menemukan sumber daya aplikasi khusus untuk platform Android, sekarang saatnya untuk menganalisis bundel JavaScript. Optimasi bundel dapat dianggap sebagai ide yang bagus karena tiga alasan. Pertama, ini mengurangi ukuran file APK jadi. Kedua, ini mengarah pada peluncuran aplikasi yang lebih cepat, karena mesin virtual JS harus memproses lebih sedikit kode. Akhirnya, dan yang paling penting, ini mempercepat pembaruan OTA yang kami lakukan beberapa kali seminggu menggunakan CodePush .

▍ Penganalisis bundel dan optimisasi kode


Untuk membuat keputusan tentang cara mengurangi ukuran bundel, pertama, Anda harus mencari tahu apa yang paling banyak terjadi di bundel. Untuk melakukan ini, kami menggunakan alat open source yang sangat baik react-native-bundle-visualizer . Setelah menganalisis proyek dengan bantuannya, kami mendapat visualisasi di mana setiap folder dan setiap ketergantungan aplikasi hadir, menunjukkan ukuran entitas yang sesuai.


Jepretan pustaka dan folder basis kode dari frontend aplikasi Mutual dengan indikasi ukuran.

Kami menemukan bahwa ukuran total bundel adalah 5,49 Mb. 57,8% dari volume ini diwakili oleh dependensi dari foldernode_modules, 27,5% - kode aplikasi. Yang tersisa, alat yang kami gunakan tidak bisa diidentifikasi. Selama proses perakitan bundel, kode yang tidak digunakan sudah dihapus, jadi yang kami lihat adalah kode yang sebenarnya digunakan oleh aplikasi. Tetapi, meskipun mempertimbangkan ini, dalam bundel Anda selalu dapat menemukan sesuatu yang dapat ditingkatkan.

Ketergantungan proyek terbesar adalahmath.js. Perpustakaan ini, seperti namanya, mengimplementasikan banyak operasi matematika. Kami tidak memiliki kebutuhan khusus untuk perpustakaan ini karena fakta bahwa kami melakukan semua perhitungan penting di server, setelah itu kami cukup mengirimkan hasilnya ke aplikasi. Ketika kami melihat kode aplikasi, ternyata perpustakaan hanya digunakan untuk melakukan beberapa operasi sederhana. Kemungkinan besar digunakan oleh pengembang yang bekerja pada kode server hanya berdasarkan kebiasaan. Kami dengan cepat mengekstrak metode yang sesuai dari pustaka dan memasukkannya ke dalam basis kode kami, sepenuhnya menghilangkan ketergantungan ini. Ini memungkinkan untuk mengurangi ukuran bundel menjadi 4,64 Mb. Penolakan hanya satu perpustakaan yang diizinkan untuk mengurangi ukuran bundel sebesar 15,5%!

Seperti yang telah disebutkan, kami menggunakan Storybook untuk mengembangkan dan menguji komponen. Benar, kemampuan yang sesuai harus tersedia hanya di lingkungan lokal dan menengah. Pengguna akhir tidak membutuhkan ini. Berkat ini, kami menggunakan variabel ENVIRONMENTuntuk mengontrol masuknya bagian yang sesuai dari aplikasi. Meskipun ini cocok untuk membatasi akses, bundler tidak dapat mengetahui nilai apa yang ditulis untuk variabel ini. Karena keterbatasan ini, semua kode Storybook masuk ke dalam bundel produksi.

Untuk memperbaiki masalah, kami mengisolasi impor bagian ini dalam satu file. Lalu kami membuat dua versi file ini: satu yang menyertakan Storybook, dan yang lain untuk produksi, yang hanya berisi tata letak komponen. Untuk beralih di antara file-file ini ketika menyiapkan versi produksi bundel, kami menulis skrip yang dijalankan sebelum proyek dibuat dan mengubah satu file ke yang lain. Berkat metode ini, kami dapat sepenuhnya menghapus kode Storybook dari versi produksi aplikasi, menghapus ketergantungan node_modulesdan kode biasa mengenai konfigurasi "story" Storybook.


Folder Storybook yang diperbarui dengan dua versi file indeks.

Kedua perubahan ini mengurangi ukuran bundel dari 5,49 MB menjadi 4,2 MB. Ini berarti, antara lain, aplikasi akan memuat lebih cepat dan memperbarui lebih cepat.


Ukuran bundel terakhir adalah 4,2 MB.

Setelah semua perbaikan ini, kami kembali mengunduh aplikasi di Play Store. Sekarang kami diberitahu bahwa ukuran file APK yang sudah selesai akan berada dalam kisaran 10,5 hingga 13,7 Mb. Ini, mengingat fakta bahwa aplikasi awalnya memiliki ukuran 26,8 MB, berarti pengurangan yang luar biasa dalam ukuran proyek sekitar 60%! Jadi, seperti yang kami katakan dalam sebuah artikel oleh tim Google Play, kami dapat sepenuhnya berharap bahwa tingkat konversi instalasi akan meningkat sebesar 3,75%.


Perbandingan versi APK asli dari aplikasi dengan versi AAB akhir, di mana semua perbaikan yang dijelaskan di atas dibuat

Ringkasan


Kami, sebagai programmer yang berorientasi bisnis, tahu bahwa kadang-kadang perusahaan, demi pengembangan proyek yang lebih cepat, dapat terus meningkatkan utang teknisnya. Ini terutama berlaku untuk startup muda seperti Mutual, yang mencoba mencari tempat mereka di pasar. Tetapi jika Anda tidak melihat hutang ini, Anda dapat membuat kesalahan yang mengganggu, seperti mengirim 2 MB gambar uji untuk produksi dan penggunaan perpustakaan besar yang tidak dapat dibenarkan. Hutang teknis seharusnya tidak boleh di luar kendali dan menyebabkan masalah.

Selain itu, sering terjadi bahwa pengembang hanya kehilangan peluang yang tersedia bagi mereka untuk mengoptimalkan proyek. Karena itu, kadang-kadang disarankan untuk menganalisis secara kritis proyek Anda. Hanya untuk memeriksa apakah Anda melewatkan beberapa peluang untuk dengan cepat mengoptimalkan ukuran, kecepatan, atau aspek lain dari aplikasi. Kami hanya membutuhkan dua hari untuk menganalisis aplikasi, merencanakan pekerjaan, dan melakukan perbaikan pada proyek, yang memungkinkan kami untuk mengurangi ukuran aplikasi hingga 60%. Sulit untuk menghasilkan sesuatu yang lain yang dapat menghasilkan hasil yang sama dalam waktu yang singkat.

Bagaimana Anda mengoptimalkan proyek Asli Bereaksi Anda?


All Articles