Pendahuluan
Di tempat kerja, saya berulang kali harus berurusan dengan pilihan teknologi yang cocok untuk pengembangan ponsel. Di bawah ini saya mencoba mengumpulkan dan mengklasifikasikan kerangka kerja utama sesuai dengan pendekatan yang digunakan, kelebihan dan kekurangan.
Jika beberapa informasi saya salah atau ketinggalan zaman - komentar dipersilahkan.
Kerangka kerja lintas platform apa pun adalah lapisan abstraksi di atas platform asli dan memungkinkan Anda untuk mengakses hanya fitur-fitur yang secara langsung didukung oleh kerangka tersebut.
Dalam kebanyakan kasus, dimungkinkan untuk memperluas dukungan untuk platform dengan menulis plugin asli untuk framework, tetapi dalam beberapa kasus ini dapat secara signifikan mempersulit pengembangan. Contoh baru dari artikel AirBnb yang sensasional adalah React Native, yang saat ini tidak tahu cara bekerja di luar kotak dengan pustaka Android 64-bit.
Anda juga perlu memperhatikan bahwa plugin asli dan kode utama aplikasi lintas-platform, sebagai aturan, dijalankan dalam proses yang berbeda dan interaksi di antara mereka dapat menyebabkan masalah kinerja. Untuk bekerja dengan sensor, atau SQLite, ini biasanya bukan masalah, tetapi jika Anda menggunakan, katakanlah, perpustakaan OpenCV sebagai plugin asli dan mulai melempar video di antara itu dan aplikasi utama, perlambatan bisa signifikan.
Pasokan terbatas di pasar tenaga kerja
Pertama, keberadaan pengembang tergantung pada prevalensi kerangka kerja. Menemukan orang di bawah React Native bahkan bisa lebih mudah daripada pengembang asli, tetapi, misalnya, dengan Flutter itu jauh lebih sulit.
Seberapa banyak faktor ini perlu diperhitungkan tergantung pada tugasnya. Sebagian besar startup mungkin tidak memperhatikannya, karena mempelajari teknologi baru kemungkinan besar merupakan bonus bagi karyawan yang ada dan potensial. Di sisi lain, bisnis besar terpaksa memperhitungkan pasar tenaga kerja.
Mendukung risiko
Dipercaya bahwa kemungkinan bahwa dukungan untuk kerangka kerja lintas platform akan berakhir jauh lebih tinggi daripada kemungkinan peristiwa yang sama terkait dengan OS seluler.
Padahal, pertanyaannya cukup rumit. OS dapat ditutup seperti kerangka kerja (contoh Windows Phone benar-benar segar). Selain itu, dalam pengembangan asli, teknologi tertentu juga dapat ditutup, dan kadang-kadang kode pada kerangka kerja lintas-platform lebih dapat bertahan.
Contoh dari ini adalah di bidang permainan dan multimedia - Apple akan mengirim teknologi OpenGL untuk bersandar pada OS-nya dan semua orang yang menulis aplikasi 3D asli harus sepenuhnya menulis ulang mereka untuk merilis versi baru. Pada saat yang sama, bagi mereka yang menggunakan mesin permainan lintas platform (misalnya, Unity), memperbarui tidak akan memerlukan upaya tambahan.
Petunjuk utama
Pengembangan Hibrida, HTML + JavaScript
Secara teknis, aplikasi tipe hybrid adalah halaman HTML yang ditampilkan di browser yang disematkan. Secara umum, kerangka kerja tidak diperlukan untuk pendekatan ini, tetapi Cordova menyediakan satu set plugin untuk mengakses fitur platform, itulah sebabnya mereka biasanya digunakan.
Keuntungan utama
Biaya pengembangan minimum
Pendekatan hybrid memungkinkan Anda untuk menggunakan kembali tidak hanya keterampilan pengembang, tetapi juga kode yang ditulis untuk situs web.
Kemampuan untuk mengintegrasikan elemen web
Jumlah perpustakaan untuk HTML / JS secara signifikan melebihi jumlah perpustakaan untuk aplikasi asli. Yang menarik, ini termasuk, misalnya, Google Analytics, atau berbagai pilihan jaringan iklan.
Kekurangan utama
Produktivitas rendah
Modern JavaScript sendiri menggunakan kompilasi JIT, dioptimalkan dengan baik dan bekerja dengan cepat, tetapi membangun antarmuka berdasarkan pohon DOM bukanlah proses yang sangat efisien. Penggunaan kerangka kerja JS modern menyediakan tingkat beban tambahan. Untuk ponsel yang lemah dan / atau dengan penggunaan elemen interaktif yang aktif, ini bisa menjadi masalah.
“Perasaan asli”
Ini adalah hal yang agak informal, tetapi sangat penting. Situs di browser merespons gerakan dan tampilan yang sedikit berbeda dari aplikasi seluler. Elemen yang paling mencolok dari perasaan ini, penundaan 300 ms saat ditekan, Cordova memutuskan, tetapi masih banyak detail lainnya.
Masalah kompatibilitas browser
Pada versi Android yang lebih lama (sebelum versi 5), WebView adalah bagian dari platform dan tidak diperbarui secara otomatis. Karenanya, tidak akan mungkin untuk menggunakan kapabilitas peramban modern dalam aplikasi hibrid pada perangkat ini.
Akibatnya, aplikasi hibrida membatasi versi Android minimum (meninggalkan sekitar 13% perangkat saat ini) atau memasukkan WebView dalam kode aplikasi (proyek CrossWalk), meningkatkan ukuran aplikasi beberapa puluh megabyte.
Tujuan
Buat aplikasi satu kali dengan cepat. Jika ada anggaran pembangunan yang substansial, pendekatan hibrida biasanya diremehkan.
Kerangka dasar
Inti dari semua kerangka kerja hybrid utama adalah Cordova, yang menyediakan akses ke plugin asli. PhoneGap menyediakan alat untuk membangun di atas Cordova, sementara Ionic adalah kerangka kerja dan seperangkat komponen untuk membangun antarmuka pengguna di dalamnya.
UI asli, kode umum
Penting untuk dicatat bahwa dengan pendekatan ini, antarmuka pengguna dan logika bisnis dijalankan dalam berbagai proses yang berinteraksi melalui jembatan. Sejumlah kelemahan pendekatan terkait dengan ini.
Pendekatan ini memiliki beberapa opsi implementasi.
Klasifikasi kode yang dapat dieksekusi
Kode yang dikompilasi
Xamarin menggunakan bahasa C #, mengkompilasinya menjadi kode platform asli. Secara umum, pendekatan ini memberikan ukuran aplikasi yang cukup kecil dan kecepatan yang cukup tinggi.
Bahasa yang ditafsirkan dengan kompilasi JIT
Sebagian besar kerangka kerja dalam pendekatan ini menggunakan JavaScript untuk memproses logika bisnis.
Klasifikasi dengan metode deskripsi antarmuka
Alat asli
Xamarin tidak hanya menggunakan komponen antarmuka asli, tetapi juga menjelaskannya dalam format yang diterima untuk setiap platform.
Elemen antarmuka universal
Formulir dan Appcelerator Xamarin menggunakan set widget mereka sendiri, yang dikonversi ke komponen antarmuka yang sesuai dari setiap platform.
Bereaksi Asli menggunakan pembungkus di sekitar komponen antarmuka asli. Dengan demikian, antarmuka dijelaskan untuk setiap platform secara terpisah, tetapi metode deskripsinya sama.
Keuntungan utama
Antarmuka yang sepenuhnya asli
Pertama, penampilan dan "rasa" aplikasi sepenuhnya bertepatan dengan aplikasi asli.
Kedua, memungkinkan menggunakan pustaka antarmuka asli dalam aplikasi. Menggunakan iklan asli (Native Ads), berfokus pada aplikasi seluler, dalam pendekatan lain tidak akan berfungsi. Benar, untuk pendekatan ini, himpunan perpustakaan yang relevan sangat terbatas. Saya hanya tahu tentang dukungan Iklan Native Facebook di React Native.
Kemampuan untuk menggunakan kembali keterampilan pengembang
Banyak kerangka kerja kelompok ini dirancang sehingga pengembang dari daerah lain dapat belajar cara membuat aplikasi seluler dengan biaya minimal. Untuk Bereaksi, Asli adalah Bereaksi, untuk Xamarin, .NET, dll.
Kekurangan utama
Batasan kemampuan antarmuka, atau biaya tambahan untuk pengembangan terpisah
Format minus ini tergantung pada klasifikasi kerangka menurut cara antarmuka dijelaskan:
Xamarin memungkinkan Anda untuk menggunakan hampir semua fitur platform, tetapi Anda harus menghabiskan banyak waktu pada antarmuka untuk setiap platform. Akibatnya, biaya tenaga kerja tidak kalah dengan pembangunan asli.
Formulir dan Appcelerator Xamarin memungkinkan Anda untuk mendeskripsikan antarmuka hanya sekali, tetapi mereka bekerja dengan subset fungsionalitas asli yang sangat terbatas (tidak lebih dari persimpangan minimum dari set fitur setiap platform, menjadi formal).
Bereaksi Asli ada di tengah, menggabungkan kedua kekurangan, tetapi dalam bentuk yang kurang jelas.
Kinerja Interaksi Antarmuka
Di sini muncul faktor pelaksanaan antarmuka dan logika bisnis dalam proses yang berbeda. Ketika perlu untuk bertukar informasi dalam volume besar melalui jembatan dengan kecepatan tinggi (animasi kompleks dengan frekuensi tinggi), kesulitan mungkin muncul dalam pendekatan ini.
Memori bocor
Kebocoran memori dapat terjadi dalam aplikasi apa pun, tetapi sebagian besar situasi standar ditangani oleh pemulung.
Masalah dengan aplikasi lintas platform dengan antarmuka asli adalah sekali lagi bahwa mereka berjalan dalam dua proses yang memiliki pengumpul sampah terpisah. Jika objek logika bisnis merujuk ke objek antarmuka, objek antarmuka ini bukan sampah, karena ada tautan ke sana dari jembatan. Jika objek antarmuka referensi kembali ke objek logika bisnis, mereka tidak akan dianggap sampah bahkan jika tidak ada lagi referensi ke mereka.
Peluang menghadapi masalah dan skalanya tergantung langsung pada aplikasi. Jika objek yang terkait dengan antarmuka secara aktif dibuat dan dihapus di dalamnya (seperti dalam pengguliran tanpa akhir), kemungkinan kebocoran meningkat. Jika benda-benda ini besar (misalnya, gambar), efek kebocoran meningkat.
Sebenarnya, masalah ini juga muncul ketika bekerja dengan plugin asli, yang juga dieksekusi dalam proses terpisah. Tetapi di sana, dalam banyak kasus, tidak ada manipulasi intensif dari objek besar, atau interaksi terjadi dalam pendekatan prosedural yang ketat, tanpa referensi silang.
Tujuan
Aplikasi dengan antarmuka yang sepenuhnya asli, terutama jika ada spesialis dalam teknologi terkait.
Kerangka dasar
Bereaksi asli
Ini memiliki dukungan Facebook dan menggunakan pendekatan kerangka JS Bereaksi paling populer, karena itu sangat populer. Sebuah artikel baru-baru ini tentang pengabaian AirBnb terhadap React Native membuat banyak kebisingan, tetapi jika menyadari risikonya, ini bisa menjadi solusi yang sangat efektif.
Xamarin
Selain pendekatan utama, ia memiliki perpustakaan Xamarin.Forms, yang memungkinkan Anda untuk mendesain antarmuka antarmuka sederhana secara efisien dan lintas platform. Didukung secara aktif oleh Microsoft. Saat bekerja dengan ASP.NET di server, ini memungkinkan Anda untuk menyimpan sejumlah pekerjaan melalui penggunaan kelas logika bisnis umum di server dan di aplikasi seluler.
Nativecript
Ini dimodelkan pada React Native untuk pengembang yang memiliki kerangka kerja JS lainnya (Angular dan Vue.js). Kurang populer, tetapi memiliki sejumlah solusi yang lebih modern dalam arsitektur.
UI asli, kode umum
Hampir semua mesin game menggunakan pendekatan ini, tetapi mereka berada di luar cakupan artikel ini.
Prinsip pendekatan ini adalah bahwa aplikasi menggunakan kode sendiri dan rendering antarmuka pengguna sendiri.
Keuntungan utama
Antarmuka kinerja tinggi
Bahkan, sebuah aplikasi yang menggambar antarmuka sendiri dengan sendirinya melakukan operasi yang sama dengan OS di antarmuka asli. Secara teori, itu bisa lebih cepat, karena tidak ada peralihan antara proses dan kernel, tetapi dalam praktiknya, faktor-faktor lain memengaruhi kecepatan rendering antarmuka tertentu, memainkan peran yang jauh lebih besar.
"Antarmuka Desain"
Aplikasi asli menggunakan komponen antarmuka yang sudah jadi dan memiliki beberapa batasan pada apa yang dapat dilakukan dengannya. Pada gilirannya, aplikasi yang menggambar antarmuka mereka sendiri tidak memiliki batasan seperti itu dan dapat dengan bebas mencampurkan elemen yang sudah jadi dengan rendering individual.
Kekurangan utama
Kerugian ini hanya relevan untuk aplikasi yang meniru antarmuka OS standar. Seperti yang telah disebutkan, untuk antarmuka desain dan permainan pendekatan ini optimal.
Ukuran aplikasi
Aplikasi dengan pendekatan ini dipaksa untuk membawa kode untuk merender semua elemen antarmuka, termasuk yang bersyarat standar. Ini mempengaruhi ukuran aplikasi selama instalasi dan RAM selama operasi.
Jika masalah pertama dapat diminimalkan dengan Tree Shaking yang efektif (seperti yang dilakukan Flutter versi terbaru), maka aplikasi ini secara stabil kehilangan memori asalnya oleh RAM. Namun, masalah ini juga merupakan karakteristik dari kerangka kerja lintas platform lainnya.
Antarmuka asli
Secara default, aplikasi ini terlihat sama di semua platform, yang dapat menciptakan ketidaknyamanan bagi pengguna. Tema digunakan untuk menyelesaikan masalah ini, tetapi mereka tidak dapat menciptakan perasaan aplikasi yang sepenuhnya asli.
Tetapi ada minus yang lebih besar - dengan pendekatan ini, paling sulit untuk menggunakan elemen antarmuka pihak ketiga yang dibuat untuk aplikasi asli (termasuk Iklan Asli yang disebutkan sebelumnya).
Tujuan
Aplikasi publik, terutama dengan antarmuka desain.
Kerangka dasar
Bergetar
Flutter sedang dipromosikan oleh Google sebagai kerangka pengembangan dan platform inti lintas platform untuk OS Fuscia masa depan mereka. Meskipun kerangka kerja ini sangat muda (dalam tahap Pratinjau Siaran) dan tidak terlalu umum, kerangka kerja ini dengan cepat mendapatkan popularitas. Menggunakan bahasa Dart (dengan kompilasi ke dalam kode asli).
Ini memiliki semua pro dan kontra dari pemuda - arsitektur dipikirkan dengan baik, dengan mempertimbangkan kesalahan pendahulunya, tetapi ekosistem yang agak terbatas.
QT Mobile
Ini populer di kalangan pengembang desktop QT. JavaScript dapat digunakan dalam pengembangan. Tanpa dukungan perusahaan besar tidak terlalu populer.
Kivy
Kerangka kerja lain yang tidak terlalu populer yang menarik, terutama karena kerangka kerja satu-satunya dalam daftar yang menggunakan Python. Untuk pengembang yang hanya terbiasa dengan bahasa ini (dan ada banyak di beberapa bidang teknologi informasi), ini bisa sangat penting.
Materi Terkait
Pada memori di Xamarin dan kerangka kerja serupa
Perbandingan kinerja aplikasi asli, Flutter dan React Native