Flutter for Jetpack Compose Developers: Panduan Praktikal Lengkap

Utama » Python » Flutter for Jetpack Compose Developers: Panduan Praktikal Lengkap

Jika anda sudah berasa selesa menulis UI dengan Jetpack Compose dan anda tertanya-tanya betapa sukarnya untuk berpindah ke Flutter, anda berada dalam kedudukan yang baik. Kedua-dua kit alat adalah deklaratif, reaktif dan dibina oleh Google, jadi sebahagian besar model mental anda membawa hampir satu-dengan-satu. Perbezaan utama wujud dalam bahasa (Kotlin vs Dart), struktur projek dan cara setiap rangka kerja bercakap dengan lapisan Android (dan, dalam kes Flutter, iOS, web dan desktop).

Panduan ini ditulis khusus untuk pembangun Jetpack Compose yang ingin memahami Flutter secara mendalam, tanpa gangguan pemasaran. Anda akan melihat bagaimana konsep teras memetakan antara dua dunia: boleh gubah lwn widget, pengubah suai lwn parameter pembina, Lazy layout lwn ListView/GridView, Canvas lwn CustomPainter, Navigation Compose lwn Navigator, remember lwn StatefulWidget dan banyak lagi. Kami juga akan menyambungkan latar belakang Android anda yang lebih luas (Paparan, kitaran hayat, sumber, niat, kerja latar belakang) dengan setara Flutternya supaya lengkung pembelajaran terasa lebih seperti langkah ke tepi daripada pendakian.

Daripada Jetpack Compose ke Flutter: tempat pemindahan kemahiran anda

Flutter ialah rangka kerja UI Google untuk membina apl merentas platform menggunakan bahasa Dart, manakala Jetpack Compose ialah kit alat UI moden Google untuk Android asli menggunakan Kotlin. Di bawah tudung mereka menyasarkan masa jalan yang berbeza, tetapi dari segi seni bina mereka berkongsi idea besar yang sama: huraikan UI sebagai fungsi keadaan, biarkan rangka kerja mengetahui masa dan cara melukis semula.

Dalam Jetpack Compose anda berfikir dari segi fungsi boleh gubah, pengubah suai dan gubahan semula; dalam Flutter anda fikir dari segi widget, parameter pembina dan bina semula. Walaupun penamaan yang berbeza, tingkah lakunya sangat serupa: anda membina pepohon elemen UI, setiap nod tidak boleh diubah, dan apabila keadaan menukar rangka kerja itu berjalan semula pokok itu untuk menghasilkan antara muka yang dikemas kini.

Satu perbezaan utama ialah Flutter adalah merentas platform mengikut reka bentuk. Pangkalan kod Dart yang sama boleh menyasarkan Android, iOS, web, Windows, macOS dan Linux. Karang berkembang melangkaui Android (contohnya dengan Compose Multiplatform), tetapi cerita berbilang peranti Flutter jauh lebih matang dan padat sekarang, itulah sebabnya banyak pasukan Android-first melihatnya apabila mereka mahu menghantar ke iOS atau desktop.

Pemahaman anda tentang platform Android itu sendiri masih sangat berharga dalam projek Flutter. Walaupun lapisan UI adalah Dart dan widget tulen, Flutter bergantung pada Android (dan iOS) untuk kebenaran, konfigurasi sistem, API platform, pemberitahuan, kerja latar belakang dan banyak lagi keupayaan lain, diakses melalui pemalam dan saluran platform. Ini bermakna semua intuisi yang telah anda bina tentang cara Android berkelakuan tidak sia-sia—ia hanya menggerakkan satu lapisan ke bawah.

Model UI Perisytiharan: boleh gubah vs widget

Kedua-dua Jetpack Compose dan Flutter melaksanakan model UI perisytiharan: anda menerangkan "bagaimana" rupa UI untuk keadaan tertentu, bukan "bagaimana" untuk mengubah pandangan langkah demi langkah. Daripada memanggil penetap pada paparan, anda membina semula pepohon anda apabila keadaan berubah dan membiarkan rangka kerja berbeza dan melukis semula dengan cekap.

Dalam Jetpack Compose, elemen UI ialah fungsi boleh gubah yang dianotasikan @Composable, sering dikonfigurasikan dengan a Modifier. Satu butang mungkin Button(onClick = ..., modifier = Modifier.padding(16.dp)). Rantaian pengubah suai menghiasi atau meletakkan kompos tanpa mengubah jenis asasnya dan Compose menggunakan gubahan semula untuk menyegarkan hanya bahagian pokok yang inputnya berubah.

Dalam Flutter, elemen UI ialah widget—objek Dart biasa yang menerangkan konfigurasi. Ia juga tidak boleh diubah dan disusun dalam pokok, tetapi bukannya menghantar pengubah suai, anda biasanya menghantar reka letak atau penggayaan hujah terus melalui parameter pembina, atau anda membungkus widget dalam widget susun atur lain. Sebagai contoh, anda mungkin menulis Padding(padding: EdgeInsets.all(16), child: ElevatedButton(...)) untuk mencapai hasil yang serupa.

Kitaran hayat kedua-dua kompos dan widget sengaja berumur pendek dan tidak boleh diubah. Mereka hidup hanya sehingga input baharu memerlukannya untuk diganti; tidak cuba menguruskan hayatnya sendiri atau mengubah dirinya secara langsung. Itulah peralihan konsep daripada dunia Android View yang lama di mana paparan ialah objek yang berumur panjang, digunakan semula dan bermutasi dari semasa ke semasa, dan itulah sebabnya pemikiran Karang anda terasa begitu semula jadi dalam Flutter.

Di bawah tudung, reka letak dalam kedua-dua rangka kerja mengikut corak berasaskan kekangan yang didorong oleh induk yang sama. Ibu bapa mengukur dirinya sendiri, melepasi kekangan, kanak-kanak memilih saiz yang sesuai dengan kekangan tersebut, dan ibu bapa meletakkan anak-anaknya. Dalam Flutter anda akan melihat ini muncul secara langsung sebagai BoxConstraints; dalam Compose ia dikendalikan dalam pelaksanaan MeasurePolicy. Dalam kedua-dua kes, ibu bapa boleh menyekat kanak-kanak—widget tidak boleh memilih sebarang saiz atau kedudukan yang mereka suka.

Menstruktur apl: pintu masuk, perancah dan reka letak

Pada Android dengan Karang, titik masuk anda biasanya adalah Activity (selalunya a ComponentActivity) tempat anda memanggil setContent untuk menjadi hos bahan komposit anda. Dari situ anda membina pokok boleh gubah, biasanya bermula dengan a MaterialTheme dan permukaan atau perancah yang mentakrifkan reka letak aras tinggi anda.

Dalam Flutter, titik masuk ialah Dart main fungsi yang memanggil runApp dengan widget akar aplikasi anda. Akar itu biasanya a MaterialApp or WidgetsApp widget, yang menyediakan penghalaan, tema, penyetempatan dan pengemudi asas. “Skrin” pertama yang anda tunjukkan selalunya menggunakan a Scaffold widget, yang memainkan peranan yang hampir sama dengan Scaffold dalam Bahan 3 Karang: ia memberikan anda bar apl, badan, butang tindakan terapung, laci dan sebagainya.

Untuk teks ringkas dan kandungan statik, Karang mungkin lalai untuk membungkus kandungan—saiz yang sepadan dengan kandungan intrinsik—manakala banyak widget Flutter lalai untuk mengambil lebih banyak ruang yang tersedia melainkan dikekang. Sebagai contoh, jika anda meletakkan a Text boleh digubah di dalam lajur, ia tidak akan mengisi lebar secara automatik. Dalam Flutter, a Text di dalam a Column boleh berkelakuan berbeza bergantung pada kekangan induknya. Untuk memusatkan kandungan dalam Flutter, anda akan kerap membungkus sesuatu dalam a Center widget, atau gunakan widget susun atur seperti Align, Row, Column, dan Expanded digabungkan dengan sifat penjajaran.

Peta susun atur linear hampir sempurna: Karang mempunyai Row and Column, dan begitu juga Flutter. Dalam Flutter anda lulus kanak-kanak sebagai a List<Widget> dan mengawal jarak dan penjajaran dengan sifat seperti MainAxisAlignment and CrossAxisAlignment. Dalam Karang, anda bergantung pada horizontalArrangement, verticalArrangement, horizontalAlignment and verticalAlignment. Cara yang berguna untuk memikirkannya: sifat yang berakhir dengan peta "Susunan" ke paksi utama Flutter, dan yang berakhir dengan "Penjajaran" memetakan ke paksi silang.

Apabila anda memerlukan reka letak relatif atau bertindih, pendekatan juga diselaraskan secara konsep. Dalam Android XML anda mungkin mencapai RelativeLayout atau campuran bersarang LinearLayout and FrameLayout. Dalam Karang anda akan karang Row, Column and Box (atau tulis susun atur tersuai). Dalam Flutter analognya ialah Row, Column and Stack digabungkan dengan kanak-kanak diposisikan dan pilihan penjajaran. Model mental anda untuk menyusun elemen relatif antara satu sama lain bergerak merentasi hampir tidak berubah.

Butang, input dan interaksi

Dalam Jetpack Compose, membina butang biasanya bermaksud menggunakan Button atau salah satu daripada varian Bahannya, yang di bawah Bahan 3 menyelesaikan kepada pelaksanaan tertentu seperti FilledTonalButton. Anda menyediakan satu onClick lambda dan penggayaan pilihan, selalunya melalui parameter seperti colors atau pengubah suai untuk pelapik, lebar dan penjajaran.

Dalam Flutter, yang setara adalah menggunakan widget seperti FilledButton, ElevatedButton, TextButton or OutlinedButton. Masing-masing mengambil satu onPressed panggil balik dan a child widget—paling kerap a Text. Anda boleh menyesuaikannya dengan melepasi a style melalui ButtonStyle atau menggunakan penggantian tema global, yang membolehkan anda melaraskan warna, bentuk, ketinggian dan saiz secara berpusat untuk seluruh keluarga butang.

Untuk mengendalikan gerak isyarat, Karang bergantung pada pengubah suai seperti Modifier.clickable dalam banyak kes, tetapi anda juga boleh turun ke pengesan gerak isyarat khusus apabila diperlukan. Tekan lama, seret dan gerak isyarat tersuai biasanya digubah melalui API pengubah suai khusus dan sumber interaksi.

Flutter mendedahkan yang eksplisit GestureDetector widget yang anda lilitkan pada apa-apa yang tidak mempunyai sokongan gerak isyarat terbina dalam. Ia menawarkan pelbagai panggilan balik: onTap, onDoubleTap, onLongPress, onVerticalDragStart, onVerticalDragUpdate, onHorizontalDragEnd dan lain-lain lagi. Widget suka ElevatedButton sudah mendedahkan an onPressed harta, tetapi untuk elemen UI tersuai sepenuhnya yang anda boleh gunakan GestureDetector atau widget peringkat lebih tinggi seperti InkWell untuk maklum balas riak Bahan.

Input teks dalam Flutter diurus dengan TextField or TextFormField, yang penggayaannya selari dengan Compose TextField and OutlinedTextField bahan boleh gubah. Anda mengkonfigurasi pembayang, label, ralat dan sempadan menggunakan a InputDecoration serupa dengan cara anda menggunakan TextFieldDefaults atau parameter pada medan teks Karang. Seperti dalam Karang, anda biasanya menunjukkan mesej ralat secara reaktif dengan menukar keadaan dan membina semula hiasan dan bukannya memanipulasi paparan secara manual.

Senarai, grid dan kandungan menatal

Jetpack Compose menawarkan dua strategi utama untuk senarai: mudah Column/Row dengan lelaran untuk koleksi kecil, dan LazyColumn/LazyRow/LazyVerticalGrid/LazyHorizontalGrid untuk senarai besar atau dinamik. Bekas malas hanya mengarang apa yang kelihatan, yang mengekalkan prestasi tinggi apabila berurusan dengan beribu-ribu item.

Flutter mengikut pendekatan kecil-vs-besar yang sama tetapi dengan widget berbeza. Untuk senarai kecil yang muat pada skrin anda boleh gunakan a Column dan petakan data anda ke children. Untuk apa sahaja yang menatal, anda capai ListView or GridView, dengan pembina pembina yang malas mencipta kanak-kanak hanya apabila diperlukan.

Corak biasa dalam Flutter ialah ListView.builder, yang mencerminkan DSL item senarai malas Compose. Anda membekalkan sebuah itemCount dan itemBuilder panggil balik; Flutter memanggil pembina itu dengan indeks dari 0 hingga itemCount - 1 setiap kali item baru kelihatan. Di dalam pembina anda boleh mengembalikan hampir semua widget—daripada yang mudah ListTile dengan teks dan ikon ke baris senarai tersuai yang kompleks.

Untuk grid, Compose's LazyVerticalGrid and LazyHorizontalGrid peta ke Flutter's GridView widget. Daripada menghantar kiraan lajur terus ke grid, Flutter sering menggunakan perwakilan seperti SliverGridDelegateWithFixedCrossAxisCount or SliverGridDelegateWithMaxCrossAxisExtent untuk mengawal bagaimana sel diletakkan. Perwakilan ini merangkum peraturan seperti "bilangan lajur" atau "lebar sel maks," serupa dengan semangat parameter saiz grid yang anda gunakan dalam Karang.

Tingkah laku tatal juga serupa merentas kedua-dua kit alat. Senarai malas Karang disertakan dengan tatal yang dipanggang; anda tidak membungkusnya dalam bekas skrol tambahan. Dalam Flutter, banyak senarai dan widget grid sendiri boleh ditatal, tetapi untuk kandungan tunggal yang tidak berulang yang sepatutnya ditatal, anda boleh gunakan SingleChildScrollView. Membina halaman boleh tatal tersuai kemudian menjadi masalah bersarang atau mengarang kepingan untuk kes penggunaan yang lebih maju.

Corak UI adaptif dan responsif

Karang memberi anda beberapa strategi untuk reka bentuk responsif: reka letak tersuai, BoxWithConstraints, WindowSizeClass dan perpustakaan adaptif Bahan 3. Ini membolehkan anda menukar komposisi anda berdasarkan ruang, postur dan kategori peranti yang tersedia, dan anda boleh mencampurkannya bergantung pada kerumitan projek.

Flutter tidak cuba untuk mencerminkan API tersebut secara langsung, tetapi idea asasnya adalah sama: periksa kekangan dan ciri skrin, kemudian cabang reka letak anda. Dua alat utama ialah LayoutBuilder and MediaQuery. LayoutBuilder pas BoxConstraints bawah supaya anda boleh menukar atau menyusun semula widget di atas lebar atau ketinggian tertentu. MediaQuery mendedahkan saiz skrin, orientasi, padding dan ketumpatan piksel untuk titik putus tahap tinggi.

Daripada menyasarkan pemetaan satu-dengan-satu antara penyelesaian penyesuaian Compose dan Flutter, lebih berkesan untuk berfikir dari segi keperluan reka bentuk anda. Sebaik sahaja anda mengetahui cara UI anda harus menyesuaikan diri merentas telefon, tablet dan desktop, anda boleh menyatakan logik itu sama ada melalui Compose's WindowSizeClass dan susun atur penyesuaian atau percabangan dipacu kekangan dan media oleh Flutter. Pemikiran reka bentuk yang sama—API yang berbeza.

Pengurusan negeri: ingat vs StatefulWidget dan seterusnya

Jetpack Compose menyimpan keadaan UI fana menggunakan remember dan pemegang negeri seperti mutableStateOf, sering digabungkan dengan ViewModel dan komponen seni bina untuk keadaan hidup lebih lama. Apabila keadaan berubah, gubahan semula berlaku dan komposit yang berkaitan mendapat nilai baharu.

Cerita keadaan peringkat rendah Flutter berkisar StatefulWidget dan yang berkaitan State objek. Anda menentukan widget yang ingin mengekalkan keadaan dengan melanjutkan StatefulWidget, kemudian laksanakan yang berasingan State<MyWidget> kelas untuk menyimpan medan boleh ubah. Setiap kali anda mengemas kini medan tersebut, anda memanggil setState(), yang menandakan bahagian pokok widget itu sebagai kotor dan mencetuskan pembinaan semula. Pada tahap ini ia sangat serupa dengan menyimpan keadaan Karang dengan remember dan tidak sah komposit apabila nilai berubah.

Untuk apl yang lebih kompleks, Flutter sangat bergantung pada corak komuniti dan pihak pertama: Provider, Riverpod, Bloc, kedai gaya Redux dan banyak lagi. Ini bertindak sebagai analog tindanan seni bina Android anda: ViewModel + LiveData/Flow + repositori dalam projek Compose. Mereka memusatkan logik perniagaan dan mendedahkan aliran data reaktif yang mendorong pembinaan semula widget. Daripada latar belakang Karang, anda akan mendapati banyak corak ini biasa walaupun API berbeza.

Satu perkara yang sering mengejutkan pembangun Android ialah widget tanpa kewarganegaraan dan berstatus dalam Flutter kerap membina semula—berpotensi setiap bingkai semasa animasi. Perbezaannya bukan tentang kekerapan membina semula tetapi tentang tempat keadaan boleh ubah disimpan: StatefulWidget memberi anda teman State objek yang bertahan dibina semula, sama seperti bagaimana remember membolehkan nilai bertahan dalam gubahan semula dalam Karang.

Lukisan, animasi dan pengilat visual

Jika anda pernah bekerja secara langsung dengan Android Canvas and Drawable, Karang Canvas boleh digubah mungkin terasa mudah. Ia menyediakan cara deklaratif untuk melukis bentuk, imej dan teks dalam Kotlin, menyembunyikan banyak upacara penting pandangan adat tradisional.

Flutter mendedahkan permukaan lukisan yang serupa melalui Canvas API, diakses melalui CustomPaint and CustomPainter. Anda melaksanakan a CustomPainter kelas di mana anda mengatasi paint kaedah untuk melukis ke atas kanvas menggunakan Paint objek, laluan, perubahan dan sebagainya. Anda kemudian melampirkan pelukis itu pada a CustomPaint widget. Di bawah hud, Compose dan Flutter bersandar pada enjin Skia, jadi primitif—garisan, laluan, shader—kelihatan sangat biasa daripada pemaparan 2D Android.

Untuk animasi, Flutter bersandar pada sistem animasi eksplisit yang dibina AnimationController, Animation<T> dan Tweens, serta set widget animasi yang kaya. Anda membuat instantiate pengawal (biasanya dengan SingleTickerProviderStateMixin untuk vsync), tentukan CurvedAnimations atau Tweens yang memetakan kemajuan 0-1 ke dalam nilai domain, dan kemudian menyambungkannya ke dalam widget seperti FadeTransition, ScaleTransition, AnimatedBuilder atau widget tersirat seperti AnimatedContainer. Sistem animasi juga mendedahkan AnimationStatus panggilan balik untuk bertindak balas untuk memulakan, menyelesaikan atau membalikkan.

API animasi Jetpack Compose adalah deklaratif dari atas ke bawah, dengan fungsi seperti animate*AsState, peralihan dan keterlihatan animasi. Daripada mengurus pengawal secara manual dalam kebanyakan kes biasa, anda menerangkan keadaan sasaran dan rangka kerja mendorong interpolasi dari semasa ke semasa. Apabila anda memerlukan kawalan yang lebih khusus, anda masih mempunyai akses kepada primitif peringkat rendah, tetapi laluan biasa adalah lebih ringkas daripada XML Android klasik atau kod animasi penting.

Dari segi konsep, anda menggunakan kedua-dua kit alat dengan cara yang sama: memastikan widget/komponen ringan dan tulen, menolak nilai masa yang berbeza-beza melaluinya dan biarkan rangka kerja mengendalikan interpolasi dan ketidaksahihan. Sebagai pembangun Compose, kejelasan tambahan Flutter's AnimationController mungkin berasa agak lama pada mulanya, tetapi ia memberi anda kawalan yang sangat halus ke atas pemasaan, lengkung dan orkestrasi.

Penggayaan, tema, fon dan aset

Apl moden hidup atau mati pada pengilat, jadi Flutter dan Compose memberi banyak penekanan pada tema dan penggayaan. Karang kegunaan MaterialTheme dengan skema warna, tipografi dan takrifan bentuk, dan anda boleh menyusun tema untuk mengatasi nilai bagi subpokok—termasuk memaksa permukaan terang atau gelap untuk kawasan tertentu.

Dalam Flutter, yang setara ialah ThemeData berlalu ke MaterialApp or Theme widget. Anda menentukan warna utama, kecerahan, tipografi dan tema khusus komponen seperti elevatedButtonTheme, textButtonTheme, appBarTheme dan banyak lagi. Anda boleh mengatasi tema secara setempat dengan membungkus subpohon Theme widget yang menyalin induk dan mengubah suai medan tertentu. Mod terang dan gelap boleh ditogol pada peringkat apl dengan menyediakan theme and darkTheme dan mengawal themeMode.

Penggayaan teks adalah wilayah yang biasa: dalam Karang anda sama ada menghantar sifat mudah terus ke Text atau bekalan a TextStyle objek. Flutter mencerminkan ini dengan a Text widget yang menerima a TextStyle melaluinya style parameter. TextStyle meliputi keluarga fon, saiz, berat, jarak huruf, ketinggian baris, hiasan dan banyak lagi. Anda boleh menentukan tema teks global dalam ThemeData.textTheme dan rujuk mereka di mana-mana, sama seperti anda menggunakan tipografi dari MaterialTheme dalam Karang.

Fon dan imej dikendalikan melalui aset dan bukannya tradisional Android /res pokok direktori. Flutter tidak menguatkuasakan susun atur folder tertentu; anda mengisytiharkan aset dalam pubspec.yaml dan kemudian merujuknya daripada kod. Imej biasanya dimuatkan dengan Image.asset(), yang menyelesaikan kepada baldi ketumpatan yang betul berdasarkan devicePixelRatio. Piksel logik memainkan peranan yang sama seperti dp pada Android, menghilangkan ketumpatan piksel fizikal.

Untuk fon tersuai, Karang membenarkan anda sama ada membungkus sumber fon atau menariknya pada masa jalan melalui pembekal seperti Google Font, kemudian menyambungkannya ke FontFamily dan tipografi. Flutter menggunakan corak yang hampir sama: letakkan fail fon dalam folder aset, senaraikannya pubspec.yaml, dan kemudian rujuk keluarga fon dengan nama dalam TextStyle. Jika anda mahukan fon yang diambil masa jalan, ada yang popular google_fonts pemalam yang mendedahkan fungsi Dart yang dinamakan sempena fon—cth GoogleFonts.robotoTextTheme()—untuk menyambungkannya dengan cepat ke dalam tema anda.

Kedua-dua ekosistem menganggap rentetan dan penyetempatan sebagai kebimbangan kelas pertama, walaupun Flutter tidak mempunyai persamaan langsung dengan sumber rentetan XML Android. Sebaliknya, amalan terbaik ialah menyimpan terjemahan .arb fail dan menyambungkannya dengan rantai alat penyetempatan Flutter. Akses kemudiannya berlaku melalui kelas Dart yang dijana, lebih kurang sama dengan penggunaan R.string pengecam dalam kod Android.

Konsep platform Android melalui kanta Flutter

Di luar UI, salah satu soalan terbesar yang ditanya oleh pembangun Compose ialah bagaimana pengetahuan Android mereka memetakan kepada seni bina Flutter. Nasib baik, kebanyakan idea teras—aktiviti, kitaran hayat, niat, kerja latar belakang, sumber, rangkaian—mempunyai rakan yang jelas, walaupun API permukaan kelihatan berbeza.

Dalam Android, Activity and Fragment ialah skrin dan bekas utama anda; dalam Flutter semuanya adalah widget, dan navigasi berlaku melalui Navigator and Route objek. Laluan secara kasarnya sepadan dengan aktiviti atau serpihan, tetapi biasanya hanya terdapat satu pengehosan Activity pada Android yang membenamkan enjin Flutter. Anda menolak dan meletuskan laluan pada timbunan Navigator, sama ada melalui laluan bernama yang ditakrifkan dalam MaterialApp atau melalui pembinaan terus PageRoute contoh seperti MaterialPageRoute.

Panggilan balik kitaran hayat Android (onCreate, onStart, onResume, dsb.) tidak mempunyai cangkuk satu-dengan-satu dalam kod Flutter, tetapi anda boleh melihat kitaran hayat apl dengan WidgetsBindingObserver. Ia mendedahkan keadaan seperti resumed, inactive, paused and detached, yang sepadan secara kasar dengan fasa kelihatan, latar belakang dan musnah Android. Apabila anda benar-benar memerlukan cangkuk kitaran hayat peringkat rendah untuk pengurusan sumber, anda biasanya melaksanakannya pada bahagian Android asli dalam FlutterActivity atau pemalam, bukan dalam Dart.

Niat memainkan dua peranan pada Android: navigasi dalam apl dan komunikasi merentas aplikasi. Seperti yang dinyatakan, Flutter tidak mempunyai API navigasi berasaskan niat—Navigator menggantikannya sepenuhnya di dalam dunia Dart. Untuk tugasan silang apl (kamera pelancaran, pemilih fail, mengendalikan niat berkongsi), anda biasanya menggunakan pemalam yang membungkus panggilan Android (dan iOS) yang diperlukan. Jika tiada pemalam wujud, anda boleh menulis sendiri menggunakan MethodChannels untuk bercakap antara Dart dan kod asli, memajukan niat dan hasil sebagai mesej.

Pemahaman anda tentang kerja latar belakang dan threading juga dipindahkan, tetapi primitif kelihatan berbeza. Android mendorong anda untuk mengalihkan rangkaian dan cakera I/O keluar dari utas utama menggunakan coroutine, AsyncTask (warisan), WorkManager, JobScheduler, RxJava dan sebagainya. Dart, sebaliknya, menggunakan gelung acara berbenang tunggal setiap pengasing, dengan async/menunggu untuk I/O dan pengasingan berasingan untuk kerja berat CPU. Untuk apa-apa sahaja I/O‑terikat, hanya tandai fungsi anda async, await operasi dan biarkan gelung acara memastikan UI responsif; untuk tugas CPU yang berat, anda memutarkan pengasingan dan berkomunikasi melalui penghantaran mesej dan bukannya memori yang dikongsi.

Dari segi rangkaian, Flutter's popular http pakej memainkan peranan yang serupa dengan OkHttp + Retrofit untuk kes penggunaan asas. Ia menyembunyikan kebanyakan kerja soket peringkat rendah dan menyepadukan secara semula jadi dengan async/menunggu. Untuk keperluan kompleks anda boleh meningkatkan pakej seperti dio, tetapi corak asas kekal: buat panggilan tak segerak, tunggu hasilnya, kemas kini keadaan dengan setState() atau pengurus negeri pilihan anda, dan bina semula widget yang terjejas.

Pemalam, storan, Firebase dan alatan

Pada Android anda sudah biasa mengisytiharkan kebergantungan dalam Gradle; dalam Flutter anda mengisytiharkan mereka masuk pubspec.yaml dan ambilnya dari pub.dev. Fail Gradle di bawah android/ folder projek Flutter kebanyakannya untuk penyepaduan khusus platform atau apabila anda memerlukan perpustakaan asli tersuai—pengembangan aplikasi sehari-hari kekal di Dart land.

Pilihan yang dikongsi dan SQLite juga mempunyai persamaan sedia dibuat. Di mana Android menawarkan SharedPreferences untuk storan nilai kunci kecil dan SQLite (atau Bilik) untuk data berstruktur, Flutter membungkusnya melalui pemalam seperti shared_preferences and sqflite. Pemalam ini menyatukan gelagat Android dan iOS supaya anda boleh menggunakan API Dart tunggal tanpa mengira platform, sambil masih bergantung pada pelaksanaan asli yang mendasari.

Penyepaduan Firebase adalah sama mudah dan kelas pertama. Kebanyakan perkhidmatan Firebase—Pengesahan, Firestore, Pangkalan Data Masa Nyata, Pemesejan Awan, Analitis, Konfigurasi Jauh dan banyak lagi—mempunyai pemalam Flutter rasmi yang diselenggara oleh pasukan Firebase dan Flutter. Ia mencerminkan model konsep daripada SDK Firebase Android tetapi dengan API Dart‑idiomatik. Untuk lebih banyak ciri Firebase khusus yang tidak dilindungi secara langsung, terdapat ekosistem pemalam pihak ketiga yang sihat pada pub.dev.

Untuk penyahpepijatan dan pemprofilan, suite DevTools Flutter memberikan anda kotak alat yang kaya setanding terus dengan pemprofil Android Studio dan Pemeriksa Reka Letak. Anda boleh memeriksa pepohon widget, menjejaki pembinaan semula, menonton peruntukan memori, mendiagnosis kebocoran dan pemecahan, dan melangkah melalui kod Dart. Digabungkan dengan sokongan IDE dalam Android Studio dan Kod VS, muat semula panas dan mula semula panas, kitaran maklum balas dalam pembangunan Flutter terasa sekurang-kurangnya sama ketat—dan selalunya lebih ketat—berbanding yang biasa anda lakukan dengan Compose.

Pemberitahuan tolak, satu lagi kebimbangan Android biasa, dikendalikan dalam Flutter melalui pemalam seperti firebase_messaging. Di bawah tudung ini bercakap dengan Firebase Cloud Messaging dan rangka kerja pemberitahuan asli pada Android dan iOS, tetapi logik apl anda hidup dalam API Dart bersatu. Konfigurasi dan gelagat khusus platform (seperti saluran pemberitahuan pada Android) masih penting dan pengalaman sedia ada anda dengan butiran platform tersebut terus menjadi sangat relevan.

Malah widget skrin utama pada Android, yang tidak boleh dilaksanakan semata-mata dalam Flutter, masih boleh disepadukan dengan kod Flutter. Anda biasanya membinanya dengan Jetpack Glance atau susun atur XML dan kemudian menggunakan pakej seperti home_widget untuk berkomunikasi dengan apl Flutter anda, berkongsi data dan juga membenamkan UI Flutter yang diraster sebagai imej di dalam widget asli. Pendekatan hibrid itu membolehkan anda mengekalkan pengalaman utama anda dalam Flutter sambil menghormati kekangan platform.

Melihat semua persamaan ini, pembangun Jetpack Compose yang melangkah ke Flutter tidak bermula dari sifar sama sekali. Pemahaman anda tentang UI pengisytiharan, kitaran hayat Android, navigasi, keadaan, sumber dan peta kerja asinkron secara semulajadi kepada dunia Flutter; perkara yang paling berubah ialah nama, bahasa (Dart) dan minda berbilang platform. Sebaik sahaja anda menghayati widget dan Navigator sebagai konsep asas, susunan yang lain cenderung untuk mengklik pada tempatnya dengan cepat.