Tahun lalu, saya telah menulis aplikasi Flutter untuk iOS dan Android. Sebelum itu, saya memiliki dan memiliki 5 tahun pengalaman dengan Xamarin. Sudah 5 tahun yang luar biasa. Terima kasih kepada Xamarin dan cintaku pada kerangka ini, saya, pada prinsipnya, pindah ke kamp pengembang, alat ini membantu saya menghasilkan banyak uang, pengetahuan, dan menemukan kolega yang luar biasa. Jadi mengapa saya menulis di Flutter sekarang? Jawaban singkat, karena Flutter mencakup semua kebutuhan pengembangan lintas platform.Sedikit sejarah
Koreksi saya jika saya salah, tetapi 2009 dalam banyak hal adalah kunci untuk pengembangan ponsel pada umumnya dan pengembangan lintas platform pada khususnya. Pada tahun 2009, iPhone 3gs dirilis, yang memungkinkan Anda menjalankan aplikasi pihak ketiga dari AppStore. Untuk pertama kalinya kesempatan ini muncul setahun sebelumnya di iPhone 3g, tetapi 3gs telah menjadi iPhone yang benar-benar "populer". Sekali lagi, setahun sebelumnya, pada bulan September 2008, Android diperkenalkan kepada publik dan pada tahun 2009 banyak produsen ponsel mulai mencoba Android untuk model ponsel baru mereka. Pada musim semi 2009, Nitobi memperkenalkan PhoneGap, kerangka kerja baru untuk membuat aplikasi lintas platform berbasis HTML5, CSS dan JS. Di tahun yang sama, di bulan SeptemberXimian merilis MonoTouch, yang memungkinkan Anda menulis aplikasi iOS menggunakan Mono dan C #. Pada tahun 2009 yang sama, pada bulan Desember, Rovio Entertainment merilis game untuk iOS dan, untuk sesaat, Maemo, yang dalam banyak hal menandai awal dari industri game mobile - Angry Birds. Contoh terakhir di sini bukan kebetulan.Kerangka kerja lintas platform pertama "untuk rakyat" dapat dianggap PhoneGap (pengembang Qt, jangan melempar batu). Itu adalah ide yang luar biasa dan sangat jelas - untuk membawa web ke dunia pengembangan ponsel. Pada 2009, kemampuan web sudah mulai melampaui browser ( halo node.js), sementara menulis aplikasi web di JS cukup mudah. Poin kedua, yang tidak kalah pentingnya adalah rendering UI. Cara rendering terjadi terletak pada mesin browser dan semua mesin ini kurang lebih mengikuti standar W3C untuk HTML, CSS dan DOM. Setiap pengembang web yang telah membuat situs mengharapkan situsnya akan terlihat hampiridentik di browser apa pun, di platform apa pun. Ini, menurut saya, adalah aspek terpenting dari web sebagai platform terbuka. Mengapa saya harus belajar bahasa / kerangka kerja baru untuk menggambar UI untuk setiap platform, jika untuk waktu yang lama ada standar untuk pemodelan UI untuk browser yang berbeda.Setelah itu, Cordova berputar dari PhoneGap, dan darinya Ionic. Tampaknya ini adalah kerangka kerja yang ideal, tetapi ada 2 poin: kinerja dan integrasi OS. Salah satu tujuan utama atau, jika Anda mau, tolok ukur aplikasi, ditulis pada solusi lintas platform adalah "keaslian" mereka. Itu Idealnya, 100% pengguna harus mempertimbangkan bahwa aplikasi lintas platform Anda adalah asli. Dan ini berarti harus seperti asli, berfungsi seperti asli dan memiliki semua kemungkinan integrasi dengan OS. Pada awalnya, semua poin untuk PhoneGap tidak dapat dicapai, kapasitas smartphone 10 tahun yang lalu tidak cukup untuk rendering UI 60 fps, integrasi dengan OS sangat minim. Sekarang ada beberapa aplikasi pada Ionic yang sulit dibedakan dari yang asli, tetapi meniru aplikasi asli masih merupakan tugas.dan tidak diberikan seperti itu. Mari kita rangkum sedikit. Menulis aplikasi web, atau lebih tepatnya aplikasi hybrid di iOS dan Android, adalah mungkin dan nyaman. Lebih mudah karena mekanisme rendering UI sepenuhnya terletak pada platform WebView, plus ada lapisan programmer yang sudah terlatih yang berpengalaman dalam web.Namun, dalam aplikasi hybrid, kinerja dan integrasi OS mungkin timpang.Pada saat yang sama dengan PhoneGap, MonoTouch diluncurkan pada 2009, yang kemudian dinamai Xamarin.iOS. Juga, pada tahun yang sama, Titanium dirilis, yang pada gilirannya juga memungkinkan penulisan aplikasi iOS pada javascript. Pada awalnya, Titanium bekerja dengan paradigma yang persis sama dengan PhoneGap - mengandalkan WebView. Tapi kemudian mereka mengadopsi pendekatan Xamarin. Apa pendekatan ini? Itu bisa dilihat sebagai sesuatu di tengah. Pendekatan Xamarin / Titanium / React.Native adalah bahwa alih-alih mencoba membuat / memigrasikan render UI yang ada / yang ada, kerangka kerja hanya berintegrasi dengan yang asli, yang ada.Alih-alih menggambar formulir dalam HTML, Xamarin memanggil elemen UI asli untuk ini (UITextField, TextEdit, dll). Memang, mengapa menciptakan kembali kemudi? Semua elemen UI yang diperlukan ada di SDK dan runtime asli, Anda hanya perlu belajar cara berkomunikasi dengan mereka dari VM Anda (mono, v8, dll). Pada saat yang sama, seperti yang sudah Anda tebak, Anda dapat menggunakan C #, JS, TS, F #, Kotlin, dll, dan pada saat yang sama kode yang tidak secara langsung berinteraksi dengan UI adalah 100% lintas-platform. Anda bisa melangkah lebih jauh. UITextField dan TextEdit yang sama adalah entitas yang identik secara konseptual, mereka memiliki beberapa properti yang mirip dan antarmuka interaksi, dan oleh karena itu, Anda dapat membuat Entri abstrak (halo Xamarin.Forms) dan hanya bekerja dengannya, untuk jarang ( tidak terlalu) pengecualian turun ke elemen UI platform. Saya tidak menyebutkan bahwa jika vm Anda dapat bekerja dengan UI secara native, kemungkinan besar vm Anda dapat memanggil API platform apa pun. Ini sepertinya pilihan yang sempurna. UI asli, kinerja asli (hi Bridges in React.Native), 100% integrasi OS. Apakah ini benar-benar sempurna? Kemungkinan besar - tidak, dan masalahnya adalah bahwa pada kenyataannya solusi ini tidak menyelesaikan masalah pengembangan lintas platform - UI tunggal. Mereka menyamarkannya. Saya ingin menulis sekali, jalankan di mana-mana. Ini jauh dari moto terbaik untuk semua jenis program dan masalah, tetapi cocok dengan UI. Saya ingin menulis UI yang sama untuk semua orang, terlepas dari platform. Mengapa pengembang web dapat membiarkan dirinya menggunakan HTML dan CSS untuk menulis situs yang kemudian akan ditampilkan dengan cara yang sama di Safari di iOS dan Chrome di Android, tetapi tidak ada pengembang asli?Faktanya, programmer telah lama menulis UI berkinerja tinggi dengan basis kode umum untuk iOS dan Android. Programmer ini disebut pengembang game. Angry Birds ditulis pada mesin Cocos2d-x, Cuphead on Unity, dan Fortnite on Unreal Engine. Jika mesin gim dapat menampilkan adegan menakjubkan di ponsel Anda, maka tombol dan daftar dengan animasi yang halus pasti akan bisa. Jadi mengapa tidak ada yang menggunakannya dalam nada ini? Jawabannya sederhana dan dangkal, mereka tidak dimaksudkan untuk ini. Saat Anda membuka gim, sepenuhnya tergantung pada senter seberapa mirip UI itu dengan yang asli, Anda hampir tidak perlu berinteraksi dengan geolokasi, tombol, kamera video, dll. Saat Anda bermain, Anda menjalani kehidupan yang berbeda di dunia kecil Anda yang ditampilkan melalui Canvas di UIViewController / Activity Anda. karena itumesin game memiliki integrasi yang relatif buruk dengan OS , sehingga tidak ada (atau saya belum melihat) meniru mesin top UI asli.Subtotal
Untuk kerangka kerja lintas platform yang ideal, kita perlu:- Pemetaan UI asli
- Kinerja UI Asli
- Kemampuan 100% untuk memanggil API OS apa saja, seolah-olah itu adalah aplikasi asli
Anda sekarang berpikir bahwa saya akan mulai gagal di bawah Flutter, tetapi saya sudah mendengar komentar marah: "Di mana Qt!? Dia bisa melakukan semua ini! " Memang, Qt sampai tingkat tertentu cocok dengan kriteria ini. Meskipun saya sangat meragukan yang pertama dari mereka. Tapi masalah utama Qt bukanlah kesulitan menulis UI asli, masalah utama adalah C ++. Lalu aku sudah menyeka wajahku dari ludah penyandera persalinan di plus. Pro adalah pisau Swiss pada steroid anabolik, pada pro Anda dapat melakukan segalanya. Tapi saya, sebagai pengembang frontend, tidak perlu ini semua. Saya membutuhkan bahasa yang sederhana dan dapat dimengerti yang bekerja dengan UI dan I / O. Jadi, tiga poin kami di atas ditambahkan:- Mudah dipelajari dan bahasa yang cukup ekspresif
- Rantime yang cocok dengan paradigma pembangunan frontend
Nah, sekarang setelah kami menyoroti beberapa metrik alat lintas platform yang baik untuk mengembangkan aplikasi seluler, kita dapat membahas masing-masing dari mereka dan melihat bagaimana itu diterapkan di Flutter.Pemetaan UI asli
Seperti yang kami ketahui sebelumnya, ada dua pendekatan yang berlawanan untuk bekerja dengan UI dalam kerangka kerja lintas platform. Ini adalah render UI menggunakan WebView atau panggilan elemen UI asli di setiap platform. Setiap pendekatan memiliki kelebihan dan kekurangan. Tetapi mereka tidak mencakup seluruh kebutuhan pengembang: terlihat tidak dapat dibedakan dari UI asli + kinerja asli. Flutter menutupi semua kebutuhan ini dengan kepala. Tim Flutter menghabiskan sejumlah sumber daya untuk menciptakan elemen “asli” dalam kerangka itu sendiri. Semua widget di Flutter dibagi menjadi tiga kategori besar:Jika Anda pergi ke bagian cupertino, Anda akan melihat bahwa widget ini tidak dapat dibedakan dari elemen iOS asli. Sebagai pengembang yang telah menggunakan Flutter untuk sementara waktu, saya dapat mengonfirmasi bahwa mereka tidak dapat dibedakan. Jika Anda menggunakan CupertinoDatePicker, misalnya, saat menggulir Anda akan merasakan hal yang persis sama, umpan balik yang bagus dari mesin Taptic / Haptic di iPhone Anda seolah-olah itu adalah elemen asli dari aplikasi asli. Saya akan mengatakan lebih banyak, secara berkala saya membuka aplikasi situs realtor.com di iPhone saya dan sampai saat ini saya tidak tahu bahwa itu ditulis dalam Flutter (atau pada sesuatu yang bukan asli).Flutter tidak hanya memungkinkan Anda untuk menggunakan widget "asli" untuk 2 platform, tetapi juga membuatnya sendiri, dan itu sangat mudah! Seluruh paradigma adalah bahwa semuanya berfungsi widget. Anda dapat membuat elemen UI dan animasi yang luar biasa kompleks dalam waktu singkat. Pesona dan kebijaksanaan pendekatan untuk bekerja dengan UI di Flutter baru-baru ini dijelaskan dalam artikel ini di Habr, saya sarankan membaca. Karena semua ini bekerja pada mesin grafis tunggal yang secara langsung merender semua ini untuk setiap platform (kita akan membicarakannya nanti), Anda dapat yakin bahwa semuanya akan ditampilkan sesuai rencana.Hal lain yang cukup menakjubkan. Flutter mendukung platform yang dimulai dengan iOS 8 dan Android API v16. Dari perspektif rendering UI, Flutter tidak terlalu masalah API mana yang tersedia pada platform tertentu. Dia akan memiliki kesempatan untuk bekerja dengan Canvas dan semacam interaksi dengan subsistem grafis. Dan ini berarti kita dapat menggambar elemen UI terbaru dari AndroidX, misalnya, pada ponsel yang berusia 8 tahun. Tentu saja ada pertanyaan tentang kinerja pendekatan ini pada platform tertua yang didukung, tetapi ini adalah pertanyaan lain.Kinerja UI Asli
Seperti yang Anda lihat, pendekatan Flutter pada rendering UI lebih dekat dengan aplikasi hybrid seperti Ionic. Kami memiliki satu mesin untuk rendering UI di semua platform, ini adalah Perpustakaan Grafik Skia . Google membeli Skia sebagai produk pada tahun 2005 dan mengubahnya menjadi proyek Open Source. Ini setidaknya menunjukkan bahwa ini adalah produk yang cukup matang. Beberapa fitur kinerja Skia:- Copy-on-write untuk elemen grafik dan tipe data lainnya
- Gunakan memori tumpukan sedapat mungkin untuk mengurangi fragmentasi
- Keamanan benang, untuk paralelisasi yang lebih baik
Saya tidak menemukan tes kinerja Skia yang meyakinkan dibandingkan dengan perpustakaan serupa (lihat Kairo ), tetapi beberapa tes menunjukkan kenaikan kinerja 50% rata-rata, kecuali dalam beberapa situasi tertentu. Ya, ini tidak terlalu penting, karena tes ini didasarkan pada penggunaan OpenGL pada desktop, dan ...Skia dapat berinteraksi dengan banyak backend GPU. Sejak baru-baru iniwaktu di iOS, sejak versi 11, Flutter menggunakan Metal sebagai GPU backend secara default. Di Android, dimulai dengan API 24 - Vulkan. Untuk versi di bawah ini - OpenGL. Semua ini memberi kita keuntungan yang nyata dalam produktivitas. Pada platform "perangkat keras" lainnya, seperti yang saya pahami, Skia / Flutter menggunakan OpenGL, yang pada prinsipnya tidak menghalangi kita untuk menulis aplikasi dengan kinerja grafis yang memadai.Web terpisah. Saat ini, seluruh tampilan UI masih ada di bundel Canvas / HTML. Karena itu, Skia sama sekali tidak terlibat dalam proses ini. Plus, Dart VM tidak berinteraksi langsung dengan DOM. Pertama adalah konversi ke js. Semua ini tidak memiliki efek terbaik pada produktivitas dan langsung terlihat oleh mata telanjang. Namun, pekerjaan sedang dilakukan untuk mengimplementasikan CanvasKitdi Flutter, yang pada gilirannya akan memungkinkan Skia untuk digunakan di browser melalui WebGL.Akhirnya, programmer C # telah menggunakan SkiaSharp untuk waktu yang relatif lama - pembungkus atas Skia untuk Mono / .Net x. Dan komunitas Xamarin menggunakan lib ini untuk menggambar elemen UI khusus dan ini adalah perpustakaan yang sangat populer. Jika ini bukan kemenangan, maka saya tidak tahu apa itu.Kemampuan 100% untuk memanggil OS API apa pun
Dalam Flutter ada 2 prinsip interaksi dengan dunia "luar":Saluran Platform memungkinkan Anda untuk berinteraksi dengan runtime / API asli melalui sistem pengiriman pesan. Dari sudut pandang arsitektur, ini dapat dilihat sebagai berikut. Secara visual, Flutter hanyalah Kanvas, yang direntangkan ke layar penuh di satu-satunya Activity / UIViewController aplikasi asli Anda. Ini persis pendekatan yang sama yang saya gunakan pengembang game (mesin game). Itu Anda dapat membuka proyek iOS / Android dari aplikasi Anda dan menambahkan fungsionalitas lain ke Swift / Kotlin / dll. Masalahnya adalah bahwa runtime asli dan Dart VM tidak akan tahu apa-apa tentang satu sama lain (selain fakta bahwa runtime asli akan tahu bahwa aplikasi memiliki Canvas dan ada sesuatu yang ditampilkan di sana). Lebih lanjut, jika Anda, misalnya, membuka file MainActivity.kt proyek Android Anda, Anda akan melihat sesuatu seperti ini:class MainActivity: FlutterActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
GeneratedPluginRegistrant.registerWith(this)
}
}
Pernahkah Anda memperhatikan bahwa Aktivitas Anda mewarisi dari FlutterActivity? Ini memberi kami peluang untuk mengonfigurasi mekanisme pengiriman pesan langsung ke Flutter / DartVM. Untuk melakukan ini, kita perlu mengganti metode configureFlutterEnginedan itu akan menentukan nama metode yang dipanggil dan nama saluran untuk mengirim pesan asinkron. Semua. Ini memungkinkan untuk menulis kode asli apa pun kepada kami dan memanggil API asli apa pun! Pada saat yang sama, sudah ada sejumlah besar plugin (paket) yang menyelamatkan Anda dari penulisan kode asli, Anda hanya dapat menggunakan Dart. Ini luar biasa! Anda menulis UI secara terpisah dan sekali untuk platform apa pun, gunakan DartVM untuk bekerja dengan UI, I / O dan hanya sebagai komponen komputasi, gunakan plugin yang mengimplementasikan fitur asli dan yang mencakup 99% dari semua fungsionalitas. Dan jika ini tidak cukup, Anda menulis secara asli dan berkomunikasi melalui mekanisme pesan. Cerita.Mekanisme kedua adalah antarmuka fungsi Asing atau FFI. Ini adalah istilah yang cukup umum untuk mekanisme iterope dengan bahasa lain, terutama C. Di dunia .Net, mekanisme ini disebut P / Invoke, untuk JVM itu adalah JNI. Singkatnya, ini adalah kemampuan untuk berinteraksi dengan perpustakaan yang ditulis dalam C / C ++ / etc. Pada saat .Net Framework, misalnya, tidak ada perangkat lunak yang ditulis dalam C # dan sebagian besar perangkat lunak ditulis dalam C / C ++, sehingga diperlukan mekanisme untuk bekerja dengan perpustakaan ini. Hal yang sama berlaku untuk JVM, Python, sebut saja. FFI adalah satu atau lain cara yang digunakan dalam semua kerangka kerja lintas platform. Baru-baru ini, DartVM juga mulai mendukung FFI untuk interoperasi dengan C dan JavaScript! Meskipun fitur ini dalam cabang beta, tetapi sudah tersedia untuk digunakan (dengan risiko dan risiko Anda sendiri).Seperti yang Anda lihat, Flutter dan DartVM mencakup 100% kemungkinan pada platform asli, dan bahkan lebih banyak lagi.Mudah dipelajari dan bahasa yang cukup ekspresif
Saya mengakui dengan jujur, sementara Dart bagi saya tetap bukan bahasa terbaik di dunia. Tidak ada sistem tipe yang ketat, tidak ada roti fungsional, seperti Pattern Matching atau fitur Immutability (seperti mereka akan dikirimkan segera), dll. Tentang sistem tipe, Dart pada awalnya dipahami sebagai bahasa "tanpa tipikal", ala JS, tetapi untuk dukungan normal untuk kompilasi AOT, tetap diperlukan untuk membawa sistem tipe ke yang lebih ketat, meskipun tidak sepenuhnya, menurut saya. Masih mengganggu saya untuk bekerja dengan tanda tangan metode, yaitu dengan argumen. Semua tanda kurung ini, @requireduntuk beberapa alasan , mengamuk . Tapi panah adalah bahasa yang sangat mudah dipelajari. Dalam sintaksis, ini adalah persilangan antara Java dan JS untuk saya. Dart banyak memaafkan, seperti JS. Secara umum, ini adalah bahasa yang cukup mudah dipelajari, saya belum mengalami masalah berarti.Rantime yang cocok dengan paradigma pembangunan frontend
Sekarang mari kita bicara tentang Dart VM. Secara umum, Dart VM mencakup banyak hal, dari GC ke Profiler dan Observatory. Di sini saya ingin berbicara hanya tentang GC dan runtime bersyarat. Anda dapat membiasakan diri dengan cara kerja runtime dan terdiri dari apa di sini . Saya bukan ahli dalam bidang ini, tetapi untuk diri saya sendiri, saya mencatat beberapa keuntungan dari Dart VM, yang akan saya coba gambarkan. Sebelum itu, saya ingin mencatat bahwa Dart dan VM yang sesuai pada awalnya dikembangkan sebagai pengganti JS, yang, seolah-olah, mengisyaratkan fokus pada pengembangan frontend.Isolat
Ringkasan
Jika Anda membaca hingga baris ini, maka, pertama, selamat, dan kedua, saya harus mengatakan bahwa saya tidak punya pengalaman menulis artikel, jadi saya tidak mengerti jika saya berhasil menyampaikan maksud saya. Dan idenya sederhana, ketika Anda menulis aplikasi seluler dengan Flutter, ternyata asli. Dan dalam bentuk bonus Anda mendapatkan kecepatan pengembangan aplikasi yang sangat baik. Hot Reload / Restart hanyalah hal yang sangat diperlukan dalam pengembangan Frontend. Bisakah Anda membayangkan beberapa penyetel yang perlu membangun / mengkompilasi seluruh proyek untuk setiap browser, misalnya, dengan setiap perubahan warna tombol? Tentu saja tidak. Secara umum, Hot Reload / Restart layak mendapatkan artikel terpisah. Tapi saya terganggu.Pengalaman saya dengan Flutter memberi tahu saya bahwa kerangka kerja ini akan dominan dalam waktu dekat. Secara berkala, saya melakukan wawancara untuk posisi pengembang Flutter dan dalam setengah kasus, perusahaan yang mencari pengembang Flutter sebenarnya memiliki staf pengembang asli seluler. Mereka hanya mencoba Flutter pada proyek interior / samping, puas / senang dan perlahan-lahan pindah ke Flutter. Bagi saya ini adalah kemenangan yang nyata. Apa yang tidak bisa dikatakan tentang Xamarin, sayangnya. Cukup sering, keputusan untuk memilih Xamarin semata-mata karena fakta bahwa sisa tumpukan ditulis dalam. Net, dan ini adalah lereng yang licin.Sebagai rangkuman, saya ingin mengatakan bahwa jika Anda berpikir tentang sisi mana yang harus didekati ketika mengembangkan aplikasi seluler baru Anda, lihat Flutter.