Ditulis oleh Vlad Radu, Product Manager, Play dan Diana Wong, Product Manager, Android
CPU 64-bit memberikan pengalaman yang lebih cepat dan lebih kaya bagi pengguna Anda. Menambahkan versi 64-bit pada aplikasi akan meningkatkan kinerja, memberi jalan bagi inovasi pada masa depan, dan mempersiapkan Anda untuk perangkat dengan hardware 64-bit saja.
Kami ingin membantu Anda bersiap-siap dan memberi tahu bahwa Anda perlu waktu untuk merencanakan. Kami telah mendukung CPU 64-bit sejak Android 5.0 Lollipop, dan pada tahun 2017 kami pertama kali mengumumkan bahwa aplikasi yang menggunakan kode native harus menyediakan versi 64-bit (selain versi 32-bit). Hari ini, kami memberikan informasi dan jadwal yang lebih terperinci untuk semakin mempermudah transisi pada tahun 2019.

Persyaratan 64-bit: apa artinya bagi developer

Mulai 1 Agustus 2019:

• Semua aplikasi dan update aplikasi baru yang menyertakan kode native harus menyediakan versi 64-bit selain versi 32-bit saat memublikasikan ke Google Play.
• Ekstensi: Google Play akan terus menerima update 32-bit saja untuk game yang menggunakan Unity 5.6 atau versi lebih lama hingga Agustus 2021.

Mulai 1 Agustus 2021:

• Google Play akan berhenti menyajikan aplikasi tanpa versi 64-bit pada perangkat berkemampuan 64-bit, yang berarti mereka tidak akan lagi tersedia di Play Store pada perangkat tersebut.
• Ini termasuk game yang dibangun dengan Unity 5.6 atau versi lebih lama.

Persyaratan ini tidak berlaku untuk:

• APK atau paket aplikasi yang secara eksplisit menargetkan Wear OS atau Android TV, yang merupakan platform yang saat ini tidak mendukung kode 64-bit.
• APK atau paket aplikasi yang tidak didistribusikan ke perangkat yang menjalankan Android 9 Pie atau yang lebih baru.

Kami tidak mengubah kebijakan kami tentang dukungan 32-bit. Play akan terus menghadirkan aplikasi untuk perangkat 32-bit. Persyaratan ini berarti bahwa aplikasi dengan kode native 32-bit juga harus memiliki versi 64-bit tambahan.

Mempersiapkan persyaratan 64-bit

Kami berharap bahwa untuk sebagian besar developer, perpindahan ke 64-bit semestinya mudah dilakukan. Banyak aplikasi yang seluruhnya ditulis dalam kode non-native (mis. bahasa pemrograman Java atau Kotlin) dan tidak memerlukan perubahan kode.
Semua developer: Berikut adalah ringkasan langkah-langkah yang perlu Anda lakukan agar menjadi sesuai 64-bit. Untuk ringkasan yang lebih detail tentang proses ini, lihat dokumentasi mendalam kami.
Periksa paket aplikasi atau APK Anda untuk kode native. Anda bisa memeriksa file .so menggunakan APK Analyzer. Identifikasi apakah mereka dibuat dari kode Anda sendiri atau diimpor oleh SDK atau library yang Anda gunakan. Jika Anda tidak memiliki file .so dalam APK, Anda sudah sesuai 64-bit.
Aktifkan arsitektur 64-bit dan bangun kembali kode native (file .so) yang diimpor oleh kode Anda sendiri. Lihat dokumentasi untuk detail selengkapnya.

• Upgrade semua SDK dan library ke versi yang sesuai 64-bit, bila perlu. Hubungi pemilik library atau SDK jika tidak tersedia. Kami bekerja sama dengan pemilik library utama untuk kompatibilitas 64-bit mereka.
• Uji untuk mengidentifikasi masalah secara lokal setelah Anda membangun kembali aplikasi.
• Luncurkan ke penguji Anda menggunakan jalur pengujian untuk pengujian secara menyeluruh.

Developer game: Tiga engine yang paling banyak digunakan saat ini mendukung 64-bit (Unreal & Cocos2d sejak 2015, Unity sejak 2018). Kami mengerti bahwa melakukan migrasi engine game pihak ketiga adalah proses intensif dengan waktu proses yang lama.
Karena Unity baru-baru ini mulai menyediakan dukungan 64-bit di versi 2017.4 dan 2018.2, kami memberikan perpanjangan otomatis untuk game saat ini yang menggunakan versi 5.6 atau lebih lama hingga Agustus 2021. Unity menyediakan panduan yang bisa membantu Anda melakukan proses upgrade ke versi yang sesuai 64-bit.
Pemilik library dan SDK: Lakukan update untuk kesesuaian 64-bit sesegera mungkin guna memberikan waktu kepada developer aplikasi untuk beradaptasi, dan beri tahu developer Anda. Register dan daftarkan SDK Anda untuk menerima update tentang fitur dan informasi terbaru yang bisa membantu Anda melayani pelanggan.

Menatap ke depan

Bagi Anda yang sudah mendukung 64-bit - terima kasih dan kerja bagus! Jika Anda belum mendukung, kami mendorong Anda untuk sesegera mungkin memulai pekerjaan apa pun untuk memenuhi persyaratan 64-bit. Seiring dengan tenggat waktu yang semakin mendekat, kami akan memperbarui dokumentasi developer dengan lebih banyak informasi tentang cara memeriksa apakah aplikasi Anda sudah sesuai.
Kami sangat optimis dengan masa depan yang bisa dihadirkan CPU 64-bit dalam berbagai bidang, seperti kecerdasan buatan, machine learning, dan seluler imersif. Mendukung 64-bit menyiapkan ekosistem untuk inovasi yang diaktifkan oleh kemampuan komputasi canggih perangkat 64-bit, dan untuk perangkat Android di masa mendatang yang hanya mendukung kode 64-bit.
Menurut Anda seberapa bermanfaatkah entri blog ini?
★ ★ ★ ★ ★





Data Binding Library (yang selanjutnya akan kami sebut ‘DB library’ dalam postingan ini) menawarkan cara yang fleksibel dan kuat untuk mengikat data ke UI Anda, tetapi seperti pepatah lama: ‘kekuatan yang besar diikuti tanggung jawab yang besar’. Hanya karena Anda menggunakan pengikatan data, bukan berarti Anda bisa menghindar dari menjadi pelaku UI yang baik.
Saya telah menggunakan pengikatan data di Android selama beberapa tahun terakhir dan postingan ini merinci beberapa hal yang telah saya pelajari selama ini.

Gunakan pengikatan standar bila memungkinkan

Adapter pengikat khusus adalah cara terbaik untuk menambahkan fungsionalitas khusus ke View dengan mudah. Seperti banyak developer, saya bertindak agak jauh dengan adapter pengikatan dan berakhir dengan class yang penuh berisi 15 adapter dengan kualitas yang berbeda-beda.
Penyebabnya adalah sejumlah adapter yang menghasilkan string terformat dan menyetelnya di TextViews. Adapter biasanya dirujuk hanya dalam satu layout:

Meskipun ini mungkin terlihat pintar, tetapi ada tiga kelemahan besar:

1. Sulit mengaturnya. Kecuali jika Anda adalah seorang yang sangat teratur, Anda cenderung memiliki satu file besar yang berisi semua metode adapter Anda. Antitesis yang kohesif dan terpisah.
2. Anda harus menggunakan instrumentasi untuk pengujian. Menurut definisi, adapter pengikatan tidak menampilkan nilai, mereka mengambil input kemudian menetapkan properti pada tampilan. Ini berarti Anda harus menggunakan instrumentasi untuk menguji logika khusus Anda, yang membuat pengujian menjadi lebih lambat dan mungkin lebih sulit dijaga.
3. Kode adapter pengikatan khusus (biasanya) tidak optimal. Jika Anda memperhatikan pengikatan teks bawaan [di sini], Anda akan melihat bahwa ia melakukan banyak pemeriksaan untuk menghindari pemanggilan TextView.setText(), sehingga mengefisienkan pemberian layout yang tidak terpakai. Saya jatuh ke dalam perangkap berpikir bahwa DB Library akan secara otomatis mengoptimalkan update tampilan. Dan itu benar, tetapi hanya jika Anda menggunakan adapter pengikat bawaan yang dioptimalkan dengan cermat.

Sebagai gantinya, pisahkan logika metode Anda menjadi class yang kohesif (saya menyebutnya kreator teks), kemudian teruskan ke pengikatan. Dari sana Anda bisa memanggil kreator teks dan menggunakan pengikatan tampilan bawaan: Dengan cara ini, kita mendapatkan semua efisiensi dari pengikatan bawaan, dan kita bisa dengan mudah menguji unit kode yang menciptakan string terformat.

Menjadikan adapter pengikatan khusus Anda lebih efisien

Jika Anda benar-benar perlu menggunakan adapter khusus, karena fungsionalitas yang Anda inginkan tidak tersedia, maka cobalah membuatnya seefisien mungkin. Maksud saya adalah dengan menggunakan semua optimalisasi UI Android standar: hindari memicu perubahan ukuran/layout bila memungkinkan.
Hal ini bisa hal yang sederhana seperti memeriksa apa yang sedang digunakan oleh tampilan vs. apa yang Anda setel. Berikut adalah contoh di mana kita menerapkan kembali adapter ImageView standar untuk android:drawable: Sayangnya, tampilan tidak selalu bisa mengekspos status mengenai apa yang perlu kita periksa. Berikut adalah contoh dengan setelan toggle max-lines pada TextView. Ia memfungsikan toggle dengan mengubah properti maxLines TextView, bersama dengan transisi layout tertunda.

Sebelumnya, adapter pengikatan berformat sederhana dan selalu menyetel properti maxLines, bersama dengan listener klik. TextView akan selalu memicu layout ketika setMaxLines() dipanggil, yang berarti bahwa setiap kali adapter pengikatan dijalankan, layout akan terpicu.

Jadi mari kita perbaiki. Karena fungsionalitas ini sepenuhnya terpisah dari TextView (kita hanya memanggil setMaxLines() dengan nilai yang berbeda saat diklik), kita perlu menyimpan sendiri status ‘current’. Untungnya, View memberikan kita cara praktis untuk melakukannya melalui mekanisme tag. Di sini, kita hanya menyimpan nilai collapsedMaxLines yang saat ini disetel dalam tag, dan ketika adapter dijalankan, kita memanggil setMaxLines(), dll. hanya jika nilainya berbeda.

Hati-hati dengan apa yang Anda berikan sebagai variabel

Saya perlahan-lahan merancang-ulang Tivi menggunakan sesuatu yang mirip MVI, menggunakan MvRx library istimewa untuk menyusunnya. Artinya dalam praktik adalah bahwa fragmen/tampilan saya menganut ke ViewModel, dan menerima instance ViewState. Instance tersebut berisi semua kondisi yang diperlukan untuk menampilkan UI.
Berikut adalah contoh class status dari Tivi (link): Anda bisa melihat bahwa ini hanyalah class data sederhana yang berisi semua hal yang diperlukan UI untuk menampilkan UI detail tentang acara TV.
Kedengarannya seperti kandidat yang sempurna untuk diberikan ke instance pengikatan data, dan mengizinkan ekspresi pengikatan kita mengupdate UI, bukan? Ya, ia memang bekerja dengan baik, tetapi ada beberapa hal yang harus diperhatikan, dan itu dikarenakan cara kerja ‘DB Library’.
Dalam pengikatan data, Anda mendeklarasikan input, melalui tag <variable>, dan kemudian menuliskan ekspresi pengikatan yang merujuk variabel-variabel tersebut pada tampilan (atribut). Ketika salah satu variabel dependen berubah, ‘DB Library’ akan menjalankan ekspresi pengikatan Anda (sehingga mengupdate tampilan). Deteksi perubahan ini adalah pengoptimalan hebat yang Anda dapatkan secara gratis.
Jadi kembali ke skenario saya. Layout saya menjadi seperti ini:

Jadi saya akhirnya memiliki instance ViewState global berukuran besar yang berisi seluruh status UI, dan seperti yang bisa Anda bayangkan, perubahannya cukup banyak. Setiap perubahan kecil di status UI menghasilkan ViewState baru yang dihasilkan dan diteruskan ke instance pengikatan data kita.
Jadi apa masalahnya? Nah, karena kita hanya memiliki satu variabel input, semua ekspresi pengikatan akan merujuk ke variabel tersebut, yang berarti bahwa ‘DB Library’ tidak bisa lagi secara selektif memilih ekspresi yang akan dijalankan. Dalam praktiknya, ini berarti bahwa setiap kali variabel berubah (tidak peduli seberapa kecil), setiap ekspresi pengikatan akan dijalankan.
Masalah ini tidak terkait secara khusus dengan MVI, ini hanyalah sebuah artefak dari penggabungan status dan penggunaannya dengan pengikatan data.

Jadi, apa yang bisa Anda lakukan?

Alternatifnya adalah dengan mendeklarasikan secara eksplisit setiap variabel dari ViewState di layout Anda, kemudian secara eksplisit meneruskan nilai-nilainya dari instance status gabungan Anda, seperti:
Terdapat lebih banyak kode yang harus dijaga dan disinkronkan bagi Anda sebagai developer, tetapi hal ini berarti bahwa ‘DB Library’ bisa mengoptimalkan ekspresi mana yang akan dijalankan. Saya akan menggunakan pola ini jika status UI Anda tidak sering berubah (mungkin beberapa kali saat dibuat) dan jumlah variabelnya tidak banyak.
Secara pribadi, saya terus menggunakan variabel tunggal di layout, memberikan instance ViewState saya, dan mengandalkan fakta bahwa pengikatan tampilan kami melakukan hal yang benar. Inilah sebabnya mengapa mengefisienkan pengikatan tampilan adalah hal yang sangat penting.
Hal lain yang perlu diperhatikan adalah bahwa Tivi adalah pengguna berat RecyclerView, dengan Epoxy + Data Binding, yang berarti bahwa terdapat tataran kalkulasi perubahan tambahan yang terjadi di DiffUtil. Jadi jika UI Anda sebagian besar juga terdiri dari RecyclerViews, Anda tetap mendapatkan pengoptimalan serupa secara gratis.

Sedikit demi sedikit, lama-lama menjadi bukit

Semoga postingan ini memperjelas beberapa hal kecil yang bisa Anda lakukan untuk mengoptimalkan implementasi pengikatan data. Mengetahui sedikit tentang bagaimana ‘DB Library’ bekerja secara internal bisa membantu Anda mengefisienkan pengikatan data, dan meningkatkan kinerja UI Anda.


An update, WorkManager 1.0.0-beta02 is now available. Untuk info lebih lanjut silahkan klik link ini.

Ada banyak pertimbangan dan praktik terbaik untuk menangani pekerjaan latar belakang, yang diuraikan dalam seri entri blog Google Power. Salah satu hal yang berulang kali disebut adalah library Android Jetpack yang disebut WorkManager, yang memperluas kemampuan API framework JobScheduler dan mendukung Android 4.0+ (API 14+). WorkManager beta baru saja dirilis hari ini!
Entri blog ini adalah yang pertama dari seri baru WorkManager. Kita akan menjelajahi dasar-dasar WorkManager, bagaimana dan kapan waktu yang tepat menggunakannya, dan apa yang terjadi di balik layar. Kemudian kita akan membahas kasus penggunaan yang lebih kompleks.

Apa yang dimaksud dengan WorkManager?

WorkManager adalah salah satu Komponen Arsitektur Android dan merupakan bagian dari Android Jetpack, sebuah cara baru dan ringkas dalam cara membangun aplikasi Android modern.

WorkManager adalah library Android yang menjalankan pekerjaan latar belakang yang dapat ditangguhkan saat batasan pekerjaan terpenuhi.

WorkManager ditujukan untuk tugas-tugas yang membutuhkan jaminan bahwa sistem akan menjalankannya bahkan bila aplikasi ditutup.

Dengan kata lain, WorkManager menyediakan API ramah-baterai yang merangkum evolusi bertahun-tahun dari pembatasan perilaku latar belakang Android. Ini sangat penting untuk aplikasi Android yang perlu menjalankan tugas latar belakang!

Kapan waktu yang tepat menggunakan WorkManager

WorkManager menangani pekerjaan latar belakang yang perlu dijalankan ketika berbagai batasan terpenuhi, terlepas dari apakah proses aplikasi tersebut aktif atau tidak. Pekerjaan latar belakang bisa dimulai saat aplikasi berada di latar belakang, saat aplikasi berada di latar depan, atau saat aplikasi dimulai di latar depan tetapi beralih ke latar belakang. Apa pun yang dilakukan aplikasi, pekerjaan latar belakang harus terus dijalankan, atau dimulai ulang bila Android mematikan prosesnya.
Salah satu kekeliruan umum tentang WorkManager adalah bahwa ia diperuntukkan bagi tugas yang perlu dijalankan di thread “latar belakang” tetapi tidak perlu bertahan dari penutupan prosesnya. Bukan itu masalahnya. Ada solusi lain untuk kasus penggunaan ini seperti coroutines Kotlin, ThreadPools, atau library seperti RxJava. Anda bisa menemukan informasi selengkapnya tentang kasus penggunaan ini dalam panduan pemrosesan latar belakang.
Ada banyak situasi berbeda ketika Anda perlu menjalankan pekerjaan latar belakang, dan karena itu Anda membutuhkan solusi berbeda untuk menjalankan pekerjaan latar belakang. Entri blog tentang pemrosesan latar belakang ini menyediakan banyak informasi keren tentang kapan waktu yang tepat menggunakan WorkManager. Lihatlah diagram berikut yang bersumber dari blog:

Dalam kasus WorkManager, ia cocok digunakan untuk pekerjaan latar belakang yang harus diselesaikan dan dapat ditangguhkan.
Untuk memulai, tanyakan pada diri Anda sendiri:

• Apakah tugas ini harus diselesaikan?
  Jika aplikasi ditutup pengguna, apakah ia masih harus menyelesaikan tugas? Contohnya adalah aplikasi catatan dengan sinkronisasi jarak jauh; setelah Anda selesai menulis catatan, Anda tentu berharap aplikasi akan menyinkronkan catatan dengan server backend. Semuanya ini tetap berjalan bahkan bila Anda beralih ke aplikasi lain dan OS harus menutup aplikasi tersebut untuk mendapatkan kembali sebagian memori. Ini juga harus tetap berjalan bahkan bila Anda memulai ulang perangkat. WorkManager memastikan tugas diselesaikan.

• Apakah tugas ini dapat ditangguhkan?
  Bisakah kita menjalankannya nanti, atau ini hanya berguna jika tugas dijalankan sekarang? Jika tugas bisa dijalankan nanti, berarti tugasnya dapat ditangguhkan. Kembali ke contoh sebelumnya, tentu sangat menyenangkan jika catatan Anda langsung segera diupload, tetapi bila ini tidak memungkinkan dan sinkronisasi terjadi belakangan, itu bukanlah masalah besar. WorkManager menghormati pembatasan latar belakang OS dan mencoba menjalankan pekerjaan Anda dengan penggunaan baterai seefisien mungkin.

Jadi, sebagai panduan, WorkManager ditujukan untuk tugas-tugas yang membutuhkan jaminan bahwa sistem akan menjalankannya, bahkan bila aplikasi ditutup. WorkManager tidak ditujukan untuk pekerjaan latar belakang yang membutuhkan eksekusi segera atau pada waktu yang tepat. Jika Anda membutuhkan agar sebuah pekerjaan dieksekusi pada waktu yang tepat (seperti jam alarm, atau pengingat acara), gunakan AlarmManager. Untuk pekerjaan yang harus dieksekusi dengan segera tetapi berjalan lama, sering kali Anda harus memastikan bahwa pekerjaan dieksekusi saat berada di latar depan; apakah itu dengan membatasi eksekusi ke latar depan (dalam hal ini, pekerjaan tersebut tidak lagi berjalan sebagai pekerjaan latar belakang) atau menggunakan Foreground Service.
WorkManager bisa dan sebaiknya dipasangkan dengan API lain saat Anda perlu memicu beberapa pekerjaan latar belakang dalam skenario yang lebih kompleks:

• Jika server Anda memicu pekerjaan, WorkManager bisa dipasangkan dengan Firebase Cloud Messaging.
• Jika Anda mendengarkan siaran menggunakan penerima siaran dan kemudian perlu memicu pekerjaan yang berjalan lama, Anda bisa menggunakan WorkManager. Perhatikan bahwa WorkManager menyediakan dukungan untuk banyak Constraints umum yang biasanya datang sebagai siaran — dalam kasus ini, Anda tidak perlu mendaftarkan penerima siaran Anda sendiri.

Mengapa menggunakan WorkManager?

WorkManager menjalankan pekerjaan latar belakang sembari menangani masalah kompatibilitas dan menjalankan praktik terbaik bagi baterai dan kesehatan sistem untuk Anda.
Selain itu, dengan menggunakan WorkManager, Anda bisa menjadwalkan tugas periodik dan rantai tugas dependen yang kompleks: pekerjaan latar belakang dapat dieksekusi secara paralel atau berurutan, dan Anda bisa menetapkan urutan eksekusi. WorkManager menangani input dan output antar tugas dengan lancar.
Anda juga bisa menetapkan kriteria mengenai kapan tugas latar belakang harus dijalankan. Misalnya, tidak ada alasan untuk membuat permintaan HTTP ke server jarak jauh jika perangkat tidak memiliki sambungan jaringan. Jadi, Anda bisa menetapkan Constraint bahwa suatu tugas hanya dapat dijalankan ketika terdapat sambungan jaringan.
Sebagai bagian dari eksekusi terjamin, WorkManager mengelola seluruh pekerjaan Anda bila perangkat dimulai ulang dan proses dihentikan secara paksa. Anda juga bisa dengan mudah menentukan strategi coba lagi jika pekerjaan Anda dihentikan dan Anda ingin mencobanya lagi nanti.
Yang terakhir, WorkManager memungkinkan Anda mengawasi status permintaan pekerjaan sehingga Anda bisa mengupdate UI.
Sebagai ringkasan, WorkManager menawarkan keuntungan berikut:

• Menangani kompatibilitas dengan berbagai versi OS
• Mengikuti praktik terbaik kesehatan sistem
• Mendukung tugas tidak bersamaan dan tugas periodik
• Mendukung tugas berantai dengan input/output
• Anda bisa menyetel batasan kapan tugas dijalankan
• Menjamin eksekusi tugas, bahkan bila aplikasi atau perangkat dimulai ulang

Mari kita lihat contoh konkretnya di mana kita membangun pipeline tugas bersamaan yang menerapkan filter ke sebuah gambar. Hasilnya kemudian dikirim ke tugas compress dan kemudian ke tugas upload.
Kita bisa menetapkan serangkaian batasan untuk tugas-tugas ini dan menentukan kapan mereka dapat dieksekusi:

Semua pekerja ini menetapkan urutan yang tepat: mis. kita tidak tahu urutan pemfilteran gambar, tetapi kita tahu bahwa pekerja Compress hanya akan mulai setelah semua pekerja Filter selesai.

Cara kerja penjadwal WorkManager

Untuk memastikan kompatibilitas mundur ke API level 14, WorkManager memilih cara yang tepat untuk menjadwalkan tugas latar belakang bergantung pada API level perangkat. WorkManager bisa menggunakan JobScheduler atau kombinasi dari BroadcastReceiver dan AlarmManager.

Apakah WorkManager siap digunakan untuk produksi?

WorkManager sekarang dalam versi beta. Ini berarti bahwa tidak akan ada perubahan yang merusak API dalam revisi utama ini.
Ketika WorkManager versi stabil sudah dirilis, WorkManager akan menjadi cara yang disukai untuk menjalankan tugas latar belakang. Karena alasan ini, sekaranglah saat yang tepat untuk mulai menggunakan WorkManager dan membantu mengembangkannya!
Terimakasih kepada Lyla Fujiwara.

Sumber Daya WorkManager

• Dokumentasi
• Panduan referensi
• Catatan Rilis WorkManager 1.0.0-beta01
• Codelab
• Kode Sumber (bagian dari AOSP)
• IssueTracker
• Pertanyaan WorkManager di StackOverflow
• Seri entri blog Google Power


Saat ini, banyak pilihan dan banyak hal bisa dipelajari saat kita mengembangkan aplikasi, baik ketika Anda menjelajahi komputasi tanpa server maupun mengelola banyak API. Dalam postingan hari ini, kami membagikan beberapa video teratas tentang semua yang baru dalam pengembangan aplikasi di Google Cloud Platform (GCP) untuk menemukan tips dan trik yang bisa Anda gunakan.


1. One Platform untuk Functions, Aplikasi, dan Containers Anda
Sesi demo ini akan memandu Anda dalam penggunaan Knative, platform berbasis Kubernetes untuk membangun dan menerapkan aplikasi tanpa server. Sesi ini membahas cara memulai penggunaan Knative untuk meraih tujuan lebih lanjut dalam fokus penulisan kode. Anda akan melihat bagaimana ia menggunakan API yang familier dari GKE, dan auto-scale serta auto-build untuk menghapus tugas dan overhead tambahan. Demo ini menunjukkan bagaimana Knative memutar container prebuilt, membangun gambar khusus, menampilkan pratinjau versi baru aplikasi, melakukan migrasi traffic ke versi tersebut, dan melakukan auto-scale untuk mencukupi pola penggunaan yang tidak terduga, selain langkah-langkah lainnya dalam pipeline pembangunan dan penerapan. Anda akan melihat pengalaman cold start, bersama dengan dasbor pemantauan yang telah dikonfigurasi sebelumnya dan bagaimana auto-termination bekerja.

Intinya: Dapatkan pemahaman mendetail tentang bagaimana platform tanpa server seperti Knative bekerja, dan bagaimana cara untuk lebih lanjut memisahkan kode dari infrastruktur yang mendasarinya.


2. Di mana Saya Harus Menjalankan Kode? Tanpa Server, Container, VM, dan Lainnya
Anda memiliki banyak pilihan kunci yang bisa diambil ketika memutuskan bagaimana dan teknologi mana yang harus diadopsi untuk memenuhi kebutuhan pengembangan aplikasi Anda. Dalam sesi ini, Anda akan mendengar tentang berbagai opsi untuk menjalankan kode dan kompromi yang mungkin harus dilakukan bersamaan dengan keputusan Anda. Pertimbangan-pertimbangan tersebut meliputi tujuan penggunaan kode Anda: Apakah itu terhubung ke internet? Adakah pertimbangan lisensi? Apakah kode itu merupakan bagian dari dorongan menuju CI/CD? Apakah kode tergantung-bahasa atau terbatas-kernel? Anda juga harus mempertimbangkan keterampilan dan animo tim saat memutuskan di mana Anda ingin berfokus, dan di mana Anda ingin menjalankan kode.

Intinya: Pahami gambaran penuh model komputasi (dan produk Google Cloud yang terkait) terlebih dahulu, kemudian pertimbangkan fitur yang tepat bagi tugas tersebut ketika memilih tempat untuk menjalankan kode Anda.


3. Memulai dengan Kubernetes Engine: Strategi Penerapan yang Menguntungkan Developer dan Mempersiapkan Pertumbuhan
Kubernetes memberdayakan developer dengan membuat tugas-tugas sulit menjadi mungkin untuk dikerjakan. Dalam sesi ini, kami memperkenalkan Kubernetes sebagai abstraksi tingkat beban kerja yang memungkinkan Anda membangun pipeline penerapan Anda sendiri, dan memulai dengan premis tersebut alih-alih memudahkan tugas-tugas sederhana. Sesi ini membahas cara menerapkan container dengan Kubernetes, dan mengonfigurasi pipeline penerapan dengan Cloud Build. Saran strategi penerapan meliputi penggunaan probe untuk memeriksa integritas dan keterhubungan container, menggunakan konfigurasi sebagai kode untuk lingkungan penerapan produksi yang kuat, menyiapkan pipeline CI/CD, dan meminta agar penjadwal menyediakan sumber daya yang tepat untuk container Anda. Ini diakhiri dengan beberapa tips tentang cara mempersiapkan pertumbuhan dengan mengonfigurasi penskalaan otomatis menggunakan metrik requests per section (RPS) atau permintaan per bagian

Intinya: Kubernetes bisa membantu Anda mengotomatiskan operasi penerapan dengan cara yang sangat fleksibel dan dapat dikustomisasi, tetapi perlu dikonfigurasi dengan benar untuk keuntungan maksimal. Bantuan Kubernetes membantu Anda untuk meraih hasil terbaik.


4. Merancang API Berkualitas
Ada banyak saran di luar sana tentang API, jadi sesi ini merekomendasikan agar berfokus pada tujuan Anda untuk setiap API yang Anda buat. Hal ini antara lain bisa berupa update atau pengintegrasian software. Pilih masalah penting yang perlu dipecahkan dengan API, dan pertimbangkan prioritas khusus tim dan organisasi Anda saat membuat API tersebut. Sesi ini juga menunjukkan beberapa area tempat kesalahan API biasanya terjadi, seperti kontrol versi atau penamaan, dan merekomendasikan penggunaan struktur API yang seragam. Jika ragu, buatlah tetap sederhana dan jangan mengacaukan bagaimana HTTP seharusnya digunakan.

Intinya: Saat ini, API-lah yang harus melakukan banyak tugas berat. Rancang API yang tepat untuk tugas tersebut dan optimalkan agar bisa dipakai seterusnya untuk orang-orang dan organisasi yang akan menggunakannya.


5. Kehidupan Event Tanpa Server: Menyelami Sistem Tanpa Server di Google Cloud Platform
Sesi ini membahas secara menyeluruh tentang cara kami menetapkan dan menjalankan sistem tanpa server di Google. Platform komputasi tanpa server memudahkan pembangunan aplikasi dengan cepat, tetapi terkadang identifikasi dan diagnosis masalah bisa saja sulit dilakukan bila kita belum memahami dengan baik tentang cara kerja mesin dasarnya. Dalam sesi ini, Anda akan mempelajari bagaimana Google menjalankan kode tidak tepercaya dalam infrastruktur komputasi bersama, dan apa artinya hal tersebut bagi Anda dan aplikasi Anda. Anda akan belajar cara membangun aplikasi tanpa server yang dioptimalkan untuk kinerja tinggi dalam skala tertentu, mempelajari tips dan kesulitan yang terkait dengan hal ini, dan melihat demo langsung pengoptimalan di Cloud Functions.

Intinya: Saat menjalankan aplikasi pada platform tanpa server, Anda berfokus untuk mengelola hal-hal yang bisa meningkatkan bisnis Anda. Lihat bagaimana ini benar-benar berfungsi sehingga Anda siap untuk stage cloud computing ini.


6. Tanpa Server Semuanya: Membangun Sistem Tanpa Server dengan Compute, Data, dan ML
Berikut adalah apa yang dimaksud dengan tanpa server, dan apakah itu khususnya di GCP. Intinya adalah bahwa tanpa server menghadirkan infrastruktur tak terlihat yang secara otomatis disesuaikan, di mana Anda hanya dikenakan biaya untuk apa yang Anda gunakan. Fitur tanpa server dari GCP dirancang untuk aktif saat dibutuhkan, dan disesuaikan secara tepat dengan kebutuhan penggunaan. Dalam sesi ini, Anda akan melihat bagaimana potongan-potongan tanpa server disatukan dengan machine learning dalam beberapa kasus penggunaan yang menarik, termasuk transkripsi data medis dan pembangunan mesin pemberi saran e-commerce yang berfungsi bahkan ketika tidak tersedia data historis. Pastikan untuk mengikuti demo keren dari CEO Smart Parking, yang menunjukkan sistem IoT real-time kelas industri yang memudahkan parkir untuk pengemudi di kota—tanpa menggunakan server.

Intinya: Tanpa server mampu mengurangi lebih banyak beban kerja dari sekadar komputasi: pelajari caranya, mengapa, dan kapan Anda bisa menggunakannya untuk aplikasi Anda sendiri.



Kami semua di kantor Firebase menikmati waktu-waktu bermain dengan project "CoreML-in-ARKit" Hanley Weng. Ia menampilkan label 3D di atas gambar yang terdeteksi dalam adegan dibawah ini. Meskipun deteksi pada-perangkat memberikan respons cepat, kami ingin membangun solusi yang memberikan kecepatan model pada-perangkat dengan akurasi yang bisa Anda dapatkan dari solusi berbasis-cloud. Nah, itulah sebenarnya yang kami bangun dengan project MLKit-ARKit kami. Baca terus untuk mengetahui selengkapnya tentang bagaimana kami melakukannya!

Bagaimana cara kerjanya

ML Kit for Firebase adalah SDK seluler yang memperluas kemampuan machine learning (ML) Google Cloud ke dalam aplikasi Android dan iOS dalam paket yang kuat tetapi mudah digunakan. Ini memuat Base API yang mudah digunakan dan menawarkan kemampuan untuk menghadirkan model TFLite kustom Anda sendiri.
ARKit adalah framework Apple yang menggabungkan pelacakan gerak perangkat, tangkapan layar kamera, pemrosesan adegan lanjutan, dan kemudahan tampilan untuk menyederhanakan tugas membangun pengalaman AR. Anda bisa menggunakan teknologi ini untuk membuat berbagai jenis pengalaman AR menggunakan kamera belakang atau pun depan pada perangkat iOS.
Dalam project ini kami mendorong bingkai ARKit dari kamera belakang ke dalam antrean. ML Kit memprosesnya untuk mengetahui objek dalam bingkai tersebut.
Ketika pengguna menge-tap layar, ML Kit menampilkan label yang terdeteksi dengan keyakinan tinggi. Kami kemudian membuat teks balon 3D dan menambahkannya ke dalam adegan pengguna.

Bagaimana cara kerja ML Kit

ML Kit mempermudah pemanfaatan ML untuk semua developer seluler, baik bagi Anda yang sudah berpengalaman dalam ML maupun yang baru mengenalnya. Bagi mereka yang menghadapi lebih banyak kasus penggunaan lanjutan, ML Kit memungkinkan Anda membawa model TFLite Anda sendiri, tetapi untuk kasus penggunaan yang lebih umum, Anda bisa menerapkan salah satu dari Base API yang mudah digunakan. API ini mencakup kasus penggunaan seperti pengenalan teks, pelabelan gambar, deteksi wajah dan lebih banyak lagi, dan didukung oleh model yang dilatih Google Cloud. Kami akan menggunakan pelabelan gambar dalam contoh kami.
Base API tersedia dalam dua jenis: Pada-perangkat dan berbasis-cloud. API pada-perangkat gratis digunakan dan berjalan secara lokal, sedangkan API berbasis-cloud memberikan akurasi yang lebih tinggi dan respons yang lebih tepat. Vision API berbasis-cloud gratis untuk 1.000/panggilan API pertama dan berbayar setelahnya. Mereka memberikan kemampuan model berukuran penuh dari Google Cloud Vision API.

Pendekatan hibrid

Kami menggunakan API pelabelan gambar pada-perangkat ML Kit untuk mendapatkan input hasil langsung sembari mempertahankan laju bingkai stabil pada 60fps. Saat pengguna menge-tap layar, kami menjalankan panggilan async ke API pelabelan gambar Cloud dengan gambar saat ini. Ketika mendapat respons dari model berakurasi lebih tinggi ini, kami mengupdate label 3D dengan segera. Jadi, selagi kami terus menjalankan API pada-perangkat dan menggunakan hasilnya sebagai sumber informasi awal, Cloud API yang berakurasi lebih tinggi akan dipanggil saat dibutuhkan dan hasilnya nanti menggantikan label pada-perangkat.

Hasil mana yang ditampilkan?

Meskipun API pada-perangkat bersifat real-time dengan semua pemrosesan terjadi secara lokal, Cloud Vision API membuat permintaan jaringan ke backend Google Cloud, sehingga memanfaatkan model dengan akurasi yang lebih tinggi dan besar. Dengan mempertimbangkan bahwa kami menganggapnya sebagai respons yang lebih tepat, di aplikasi kami, kami mengganti label yang diberikan oleh API pada-perangkat dengan hasil dari Cloud Vision API saat diterima.

Cobalah sendiri!

1. Meng-clone project

$ git clone https://github.com/FirebaseExtended/MLKit-ARKit.git

2. Instal pod dan buka file .xcworkspace untuk melihat project di Xcode.

1. $ cd MLKit-ARKit
2. $ pod install --repo-update
3. $ open MLKit-ARKit.xcworkspace

3. Untuk menyiapkan Firebase ML Kit di aplikasi contoh:

1. Ikuti petunjuk ini untuk menambahkan Firebase ke aplikasi Anda.
2. Pastikan untuk menetapkan "com.google.firebaseextended.MLKit-ARKit" sebagai ID paket project iOS.
3. Download file GoogleService-Info.plist yang dihasilkan sebagai bagian dari penambahan Firebase ke aplikasi Anda.
4. Dalam Xcode, tambahkan file GoogleService-Info.plist ke aplikasi Anda, di sebelah Info.plist.

Pada titik ini, aplikasi seharusnya sudah bisa menggunakan pengenalan pada-perangkat.

4. (Opsional) Untuk menyiapkan Cloud Vision API di aplikasi contoh:

1. Alihkan project Firebase Anda ke paket Blaze

   Hanya project level Blaze yang bisa menggunakan Cloud Vision API. Ikuti langkah-langkah berikut untuk mengalihkan project Anda ke paket Blaze dan mengaktifkan tagihan pay-as-you-go.

   1. Buka project Anda di Firebase console.
   2. Klik link MODIFY di sudut kiri bawah di sebelah paket Spark yang saat ini dipilih.
   3. Pilih paket Blaze dan ikuti petunjuk di Firebase Console untuk menambahkan akun penagihan.
      ★ Fitur deteksi label cloud masih tetap gratis untuk 1.000 penggunaan pertama per bulan. Klik di sini untuk melihat detail harga tambahan.
2. Masuklah ke bagian ML Kit dari Firebase console dan aktifkan tombol "Cloud Based APIs" di bagian atas.

Sekarang, aplikasi seharusnya mengupdate label dengan hasil yang lebih tepat dari Cloud Vision API.