[go: up one dir, main page]


Pada tahun 2016, layanan perbandingan asuransi mobil Australia Greenslips.com.au, memulai desain ulang situsnya. Setelah melihat framework web yang mampu memenuhi kebutuhannya, mereka memilih untuk mem-build kembali situs webnya dengan AMP. Ini memungkinkan tim developer mereka mempertahankan basis kode tunggal yang memastikan pengalaman hebat dan cepat di desktop dan seluler. Sejak meluncurkan situs “AMP-pertama” mereka awal tahun ini, Greenslips.com.au telah melihat peningkatan 12-15% (tergantung perangkat) dalam tingkat konversi di atas peningkatan kecepatan yang diharapkan sebesar 15%.

greenslips_graphic
Greenslips.com.au melihat peningkatan 12-15% dalam rasio konversi

Greenslips.com.au tidak sendirian Kami telah melihat banyak contoh bisnis terkini dalam bidang publikasi dan e-commerce meraih keberhasilan dengan menerapkan AMP di situs mereka. Pada bulan lalu, kami memublikasikan 5 studi kasus baru di AMPproject.org — dan lebih banyak lagi akan segera menyusul. Meskipun masing-masing kasus ini unik, kami berharap bahwa dengan membagikannya, bisnis dan developer bisa lebih memahami bagaimana memanfaatkan AMP dapat menguntungkan bagi situs mereka.
Penayang India seperti The Tribune dan Jagran New Media telah melihat peningkatan pendapatan pada halaman AMP, yang disambungkan dengan situs tradisional mereka. Secara khusus, Jagran New Media melihat peningkatan pendapatan 4,5 kali dari seluler, bersama dengan peningkatan traffic. Readwhere, provider CMS yang digunakan oleh The Tribune, melihat pendapatan seluler dan keterlihatan iklan yang lebih tinggi di halaman AMP mereka.

jagran_graphic
Jagran New Media melihat peningkatan 4,5 kali dalam pendapatan seluler

Kami juga melihat situs e-commerce mendapatkan manfaat dari kecepatan dan keuntungan pengguna yang disediakan oleh AMP. E-retailer Indonesia Tokopedia melihat peningkatan 5 kali dalam konversi dan penurunan bounce rate dari implementasi AMP mereka. Dan ketika AMP digunakan dengan solusi periklanan seperti AdWords, bisnis ini sering kali meraih keuntungan dari campaign mereka. DiscoverCarHire.com secara khusus melihat peningkatan 22% dalam kunjungan seluler dan 29% lebih banyak konversi dari perangkat seluler melalui Google Ads-nya.

tokopedia_graphic
Tokopedia melihat rasio konversi seluler 5 kali lebih tinggi

Lihat studi kasus AMP baru di bawah dan berlangganan newsletter kami untuk mendapatkan update AMP Project terbaru di kotak masuk Anda.
Apakah Anda sudah berhasil dengan AMP? Beri tahu kami dengan menghubungi di Twitter atau dengan memberikan catatan dalam formulir ini!
Ditulis oleh Matt Ludwig, AMP Project marketing lead di Google

Ditulis oleh James Lau (@jmslau), Product Manager

Hari ini menandai awal KotlinConf 2018 - pertemuan tatap muka tahunan terbesar komunitas Kotlin. 2018 menjadi tahun yang besar bagi Kotlin, karena bahasa ini semakin banyak diadopsi dan disukai developer. Bahkan, 27% dari 1.000 aplikasi Android teratas di Google Play sudah menggunakan Kotlin. Yang lebih penting lagi, developer Android sangat menyukai bahasa ini dengan tingkat kepuasan lebih dari 97% dalam survei terbaru kami. Tidaklah mengherankan sehingga Kotlin terpilih sebagai bahasa #2 yang paling disukai dalam survei StackOverflow 2018.
Google mendukung Kotlin sebagai bahasa pemrograman kelas-satu untuk pengembangan Android. Dalam 12 bulan terakhir, kami telah memberikan sejumlah perbaikan penting untuk pengalaman developer Kotlin. Ini termasuk SDK ramah-Kotlin, Android KTX, pemeriksaan Lint baru dan berbagai perbaikan dukungan Kotlin di Android Studio. Kami juga telah meluncurkan dukungan Kotlin dalam dokumentasi resmi kami, contoh-contoh unggulan baru di Kotlin, kursus Kotlin Bootcamp Udacity baru, #31DaysOfKotlin dan konten mendalam lainnya. Kami berkomitmen untuk terus meningkatkan pengalaman developer Kotlin.
Seiring dengan terus berkembangnya bahasa, semakin banyak developer yang menemukan keunggulan Kotlin di seluruh dunia. Baru-baru ini, kami melakukan perjalanan ke India dan bekerja dengan developer lokal seperti Zomato untuk lebih memahami bagaimana adopsi Kotlin telah menguntungkan pengembangan Android mereka. Zomato adalah layanan penelusuran & penemuan restoran terkemuka yang beroperasi di 24 negara, dengan lebih dari 150 juta pengguna setiap bulan. Kotlin membantu Zomato mengurangi jumlah baris kode di aplikasi mereka secara signifikan, dan Kotlin juga membantu mereka menemukan cacat penting dalam aplikasi mereka pada waktu kompilasi. Anda bisa menonton kisah adopsi Kotlin mereka dalam video di bawah ini.
Android Developer Story: Zomato uses Kotlin to write safer, more concise code.
Melampaui Android, dengan senang hati kami umumkan bahwa tim Google Cloud Platform meluncurkan portal Kotlin khusus hari ini. Ini akan mempermudah developer dalam menemukan sumber daya yang terkait dengan Kotlin di Google Cloud. Kami ingin membuat penggunaan Kotlin semudah mungkin bagi Anda, baik di seluler atau di Cloud.

Halaman beranda Kotlin di Google Cloud Platform
Mengadopsi bahasa baru adalah keputusan yang besar bagi kebanyakan perusahaan, dan Anda harus yakin bahwa bahasa yang Anda pilih memiliki masa depan cerah. Itulah sebabnya Google bergabung dengan JetBrains dan mendirikan Kotlin Foundation. Kotlin Foundation akan memastikan bahwa Kotlin terus berkembang pesat, tetap bebas dan terbuka. Anda bisa mempelajari lebih lanjut tentang Kotlin Foundation di sini.
Sangat menarik menjadi developer Kotlin. Jika Anda belum mencoba Kotlin, kami mendorong Anda untuk bergabung dengan komunitas global yang sedang berkembang ini. Anda bisa memulai dengan mengunjungi kotlinlang.org atau halaman Kotlin Developer Android.


Ditulis oleh Luiz Gustavo Martins, Partner Developer Advocate, Partner DevRel
Ini adalah seri entri blog ketiga yang menguraikan strategi dan panduan di Android berkenaan dengan daya.
Selama bertahun-tahun, menjalankan tugas-tugas latar belakang di Android telah berkembang. Untuk menulis aplikasi modern, kita harus mempelajari cara menjalankan tugas latar belakang dengan gaya modern.

Kapan aplikasi berada di latar belakang?

Sebelum memahami apa itu eksekusi latar belakang, kita harus memiliki pandangan yang jelas tentang bagaimana Android memahami aplikasi berada di latar depan. Aplikasi dianggap berada di latar depan jika salah satu dari pernyataan berikut terpenuhi:
Jika tidak satu pun dari ketentuan ini yang terpenuhi, aplikasi akan dianggap berada di latar belakang.

Perubahan eksekusi latar belakang

Menjalankan tugas di latar belakang menghabiskan sumber daya perangkat yang terbatas, seperti RAM dan baterai. Hal ini mungkin mengakibatkan pengalaman pengguna yang buruk. Misalnya, tugas latar belakang dapat menurunkan masa pakai baterai perangkat atau pengguna mungkin mengalami kinerja perangkat yang buruk saat menonton video, bermain game, dan menggunakan kamera.
Untuk meningkatkan masa pakai baterai dan memberikan pengalaman pengguna yang lebih baik, Android telah berkembang selama beberapa rilis untuk menetapkan batas eksekusi latar belakang. Batasan ini meliputi:

Kasus penggunaan dan solusi

Memutuskan fitur mana yang akan digunakan untuk mengimplementasikan eksekusi latar belakang mengharuskan developer untuk memiliki pemahaman yang jelas mengenai apa yang ingin mereka capai, dan dalam batasan apa. Diagram alir ini bisa membantu Anda membuat keputusan:

  • WorkManager adalah solusi yang disarankan untuk eksekusi latar belakang, dengan mempertimbangkan semua batasan eksekusi latar belakang OS. Jika Anda perlu menjamin bahwa tugas akan berjalan bahkan ketika ditunda, Anda harus menggunakan WorkManager. API ini memungkinkan Anda menjadwalkan tugas (satu kali atau berulang) serta menggabungkan dan menyatukan tugas. Anda juga bisa menerapkan batasan eksekusi ke sini seperti memicu ketika perangkat sedang tidak aktif atau mengisi daya, atau mengeksekusi ketika penyedia konten berubah. Salah satu contohnya adalah bila Anda perlu mengompresi log untuk menguploadnya ke server Anda. Untuk melakukannya, Anda bisa membuat dua permintaan kerja:
    • Pertama: kompresikan file. Pada langkah ini Anda bisa menambahkan suatu batasan sehingga perangkat harus mengisi daya.
    • Kedua: upload ke server. Untuk permintaan ini Anda harus menambahkan batasan konektivitas jaringan sehingga pekerjaan hanya terpicu ketika Anda memiliki koneksi yang valid.
    Setelah mengantre kedua tugas, WorkManager akan berhati-hati mengeksekusi mereka ketika aplikasi Anda memiliki akses ke sumber daya yang dibutuhkan.
    Fitur lain yang menarik dari WorkManager adalah bahwa ia mematuhi fitur manajemen-daya, sehingga jika tugas dijadwalkan untuk berjalan pada waktu yang sudah ditentukan dan perangkat berada dalam mode Istirahatkan pada waktu itu, WorkManager akan mencoba menjalankan tugas selama jendela pemeliharaan jika batasan terpenuhi atau setelah Istirahatkan dicabut.
  • Jika tugas yang berjalan lama dijadwalkan sebagai respons terhadap event eksternal seperti menyinkronkan konten online baru, gunakan Firebase Cloud Messaging untuk memberi tahu aplikasi Anda dan kemudian membuat permintaan kerja dengan WorkManager untuk menyinkronkan konten. Anda bisa mempelajari lebih lanjut tentang hal ini di "Notifying your users with FCM".
  • Jika aplikasi perlu menyelesaikan tugas yang dimulai pengguna tanpa menunda meskipun pengguna meninggalkan aplikasi atau mematikan layar, seperti ketika navigasi atau memutar musik/video, Anda harus menggunakan Layanan Latar Depan. (Entri blog berikutnya dalam seri ini akan lebih mendalami kasus penggunaan ini.)
  • Jika Anda perlu menjalankan tugas pada waktu yang tepat yang memicu tindakan, melibatkan interaksi pengguna, dan tidak bisa ditunda, gunakan AlarmManager (lebih spesifik lagi metode setExactAndAllowWhileIdle). Contoh-contoh alarm waktu meliputi:
    • pengingat minum obat
    • notifikasi bahwa acara TV akan dimulai.
    Ketika alarm terpicu, Anda memiliki beberapa detik untuk menyelesaikan pekerjaan dan aplikasi Anda mungkin tidak memiliki akses ke jaringan (misalnya selama Istirahatkan atau karena Bucket Aplikasi Standby). Jika Anda benar-benar membutuhkan jaringan atau perlu melakukan tugas yang lama, gunakan WorkManager. Setiap kali alarm bangun terpicu, perangkat keluar dari mode daya-rendah dan menahan jam bangun parsial yang bisa secara signifikan memengaruhi masa pakai baterai dari waktu ke waktu. Ini bisa dimonitor melalui statistik alarm bangun eksesif yang ditandai pada Android Vitals, yang disediakan melalui Konsol Google Play.
Rangkuman:
Kasus Penggunaan Contoh Solusi
Jaminan eksekusi dari pekerjaan yang dapat ditangguhkan
  • Mengupload log ke server Anda
  • Mengenkripsi/Mendekripsi konten untuk upload/download
WorkManager
Tugas dimulai sebagai respons terhadap event eksternal
  • Menyinkronkan konten online baru seperti email
FCM + WorkManager
Melanjutkan pekerjaan yang dimulai pengguna yang harus segera dijalankan bahkan bila pengguna meninggalkan aplikasi
  • Pemutar musik
  • Melacak aktivitas
  • Navigasi transit
Layanan Latar Depan
Memicu tindakan yang melibatkan interaksi pengguna, seperti notifikasi pada waktu yang tepat.
  • Jam alarm
  • Pengingat obat
  • Notifikasi tentang acara TV akan dimulai
AlarmManager
Gunakan eksekusi latar belakang dengan bijaksana sehingga Anda bisa mem-build aplikasi keren yang memesona pengguna sembari menghemat baterai mereka. Jika Anda memerlukan informasi selengkapnya tentang mengeksekusi tugas latar belakang di Android, ada konten yang sangat bagus di situs developer Android.
Catatan: WorkManager masih dalam pratinjau publik. Jika Anda memerlukan solusi alternatif sekarang, Anda harus menggunakan JobScheduler, meskipun ini memiliki batasan yang tidak berlaku untuk WorkManager. JobScheduler adalah bagian dari Android Framework, dan hanya tersedia untuk Android API 21 ke atas; WorkManager berfungsi pada API 14 ke atas.
Ucapan Terima Kasih: Seri entri blog ini bisa diproduksi berkat kolaborasi tim DevRel dan Android Framework


Kami baru saja memublikasikan panduan baru di ampproject.org: “Mengoptimalkan halaman AMP yang dihosting” menjelaskan cara mengoptimalkan dokumen AMP sehingga memuat lebih cepat.
Anda mungkin berpikir: tunggu dulu – bukankah AMP seharusnya sudah cepat? Dan Anda memang benar: waktu proses AMP dioptimalkan untuk kecepatan dan semua halaman AMP yang valid dimuat dengan cepat. Namun, ada tambahan optimalisasi kinerja yang bisa Anda terapkan untuk membantu browser memuat halaman AMP lebih cepat lagi. Perubahannya sedikit, tetapi secara signifikan bisa meningkatkan kinerja pemuatan tanpa merusak validitas AMP.
Misalnya, plugin AMP WordPress, yang dikembangkan oleh XWP, sudah menerapkan beberapa teknik yang dijelaskan dalam panduan ini. Ini mengakibatkan waktu pemuatan xwp.co meningkat sebesar 12,6%.
Contoh lainnya adalah Evening Standard, mereka selangkah lebih jauh lagi dan memublikasikan AMP yang dioptimalkan dengan server-side-rendering (SSR). Ini mengakibatkan FCP mereka meningkat sebesar 69% dibandingkan versi AMP valid.


Kenapa Anda harus peduli?

Mari mundur selangkah. Apakah ini penting? Bukankah dokumen AMP selalu ditayangkan oleh AMP cache yang secara otomatis melakukan semua optimalisasi ini? Hal itu benar untuk beberapa kasus, seperti ketika dokumen AMP ditampilkan di hasil penelusuran Google atau Bing. Namun ada kasus lain ketika dokumen AMP ditayangkan dari halaman asalnya:
  1. Ketika halaman web seluler atau resmi Anda di-build dengan AMP, seperti https://tasty.co.
  2. Platform lain menautkan ke dokumen AMP di halaman asalnya. Misalnya, Twitter mulai menautkan ke halaman AMP sebagai ganti mengirimkan versi seluler standar. Ini berarti bahwa jika pengguna mengklik link di salah satu aplikasi seluler Twitter, link akan mengarah ke versi AMP halaman Anda di server Anda sendiri.
Untuk kasus-kasus ini, ketika Anda menayangkan halaman AMP dari server Anda sendiri, harap pastikan halaman AMP Anda menawarkan kinerja pemuatan optimal.


Bagaimana cara membantu browser memuat halaman AMP lebih cepat?

Mari kita lihat sekilas bagaimana cara mengoptimalkan kinerja pemuatan AMP. Waktu proses AMP harus dimuat untuk elemen khusus AMP seperti amp-img atau amp-video agar berfungsi. Ini berarti amp-img baru akan mulai mendownload gambar setelah waktu proses AMP dimuat.
Ini memberi kita dua peluang untuk membuat halaman AMP memuat lebih cepat:
  1. Pastikan browser mendownload waktu proses AMP secepat mungkin.
  2. Beri tahu browser agar mulai mendownload aset penting seperti gambar bahkan sebelum waktu proses AMP tersedia.
Kunci untuk mencapai ini adalah menggunakan petunjuk sumber daya seperti rel=preload untuk memprioritaskan sumber daya penting yang telah didownload. Panduan optimalisasi AMP menjelaskan berbagai cara bagaimana Anda bisa menggunakan petunjuk sumber daya untuk mengoptimalkan halaman AMP. Ada baiknya juga mempertimbangkan AMP Boilerplate Generator yang memungkinkan Anda membuat template AMP yang dioptimalkan dengan cepat.


Bagaimana cara meningkatkan first-contentful-paint?

Kita juga bisa melakukan optimalisasi kinerja selangkah lebih maju. Waktu proses AMP mengimplementasikan sistem layout halaman statis untuk mengurangi rendering dan scroll sampah. Cara kerjanya adalah kode AMP Boilerplate akan terlebih dahulu menyembunyikan dokumen hingga waktu proses AMP dimuat. Setelah dimuat, waktu proses melakukan kalkulasi layout dan menampilkan konten. Kelemahan dari pendekatan ini menyebabkan pengguna melihat halaman kosong hingga waktu proses AMP dimuat dan ia tidak mendukung rendering progresif.
Untuk menutup kelemahan tersebut, waktu first-contentful-paint (FCP) bisa ditingkatkan dengan menggunakan server-side-rendering AMP. Dengan cara ini, Anda bisa menghapus AMP boilerplate sehingga dokumen AMP dapat ditayangkan tanpa menjalankan JavaScript waktu proses AMP. Sebagai contoh, versi server-side-rendering AMP Boilerplate Generator merender dua kali lebih cepat daripada versi AMP normal:

blog-how-to-make-amp-faster-filmstrip
Lihat AMP Optimizer untuk mempelajari cara mengoptimalkan dokumen AMP di server Anda.

Apa yang dimaksud dengan peningkatan kinerja?

Untuk mengetahui bagaimana pengoptimalan memengaruhi kinerja pemuatan, saya telah membuat tiga versi berbeda dari halaman landing template AMP Start Bike Shop:
    1. Tanpa Gambar: untuk menyimulasikan skenario kejadian terbaik ketika tidak ada konten visual yang bergantung pada waktu proses AMP yang dimuat.
    2. Dengan Gambar: untuk menampilkan waktu pemuatan saat konten bergantung pada waktu proses AMP yang dimuat.
    3. Font yang di-host sendiri: untuk menunjukkan dampak pemuatan font khusus.
Untuk masing-masing halaman, saya menguji empat varian berbeda:
  1. Asli: versi AMP valid yang asli.
  2. Dioptimalkan: versi AMP valid yang dioptimalkan, yang mengimplementasikan optimalisasi berikut:
    1. pengoptimalan pemuatan waktu proses
    2. pramuat gambar tokoh (bila relevan)
    3. pengoptimalan font khusus (bila relevan).
  3. Dioptimalkan + SSR: mengimplementasikan optimalisasi yang sama seperti versi sebelumnya, tetapi menggunakan server-side-rendering melalui AMP Optimizer. Catatan: versi ini bukan AMP valid.
  4. Cache: sebagai referensi versi yang ditayangkan oleh Google AMP Cache.
Semua pengujian dijalankan tiga kali dengan Webpagetest di Chrome pada Motorola G (gen 4) dengan koneksi 3G 1,6 Mbps dengan latensi 300ms. Anda bisa melihat hasil lengkapnya termasuk link ke Webpagetest di dokumen ini. Karena pengujian dijalankan di perangkat sungguhan, waktu eksekusi dapat bervariasi.
Sekarang, mari kita lihat hasilnya:

Tanpa Gambar

Waktu Muat Mulai Render Interaktif Pertama
Asli 4,569 4,569 4,424
Dioptimalkan 4,564 -0,11% 4,564 -0,11% 4,423 -0,02%
Dioptimalkan + SSR 2,233 -51,13% 2,233 -51,13% 4,48 1,27%
AMP Cache 2,039 -55,37% 2,039 -55,37% 3,508 -20,71%
Waktu pemuatan yang >50% lebih cepat untuk versi server-side-rendering dengan jelas menunjukkan keuntungan dari AMP server-side-rendering. Namun, waktu interaksi tidak berubah karena masih bergantung pada waktu proses AMP yang dimuat.

Gambar 

Waktu Muat Mulai Render Interaktif Pertama
Asli 5,435 4,591 5,367
Dioptimalkan 4,591 -15,53% 4,566 -0,54% 5,094 -5,09%
Dioptimalkan + SSR 4,095 -24,66% 1,892 -58,79% 4,818 -10,23%
AMP Cache 3,827 -29,59% 1,834 -60,05% 4,13 -23,05%
Di sini kita bisa melihat bahwa melakukan pramuat gambar akan secara signifikan mempercepat waktu pemuatan. Versi AMP dioptimalkan yang valid memuat 15% lebih cepat, sedangkan versi Dioptimalkan + SSR "hanya" memuat 24% lebih cepat. Ini karena rendering gambar bergantung pada waktu proses AMP yang dimuat.


Font yang di-host sendiri

Waktu Muat Mulai Render Interaktif Pertama
Asli 5,509 4,609 5,424
Dioptimalkan 4,55 -17,41% 4,53 -1,71% 5,112 -5,75%
Dioptimalkan + SSR 4,478 -18,71% 1,989 -56,85% 5,203 -4,07%
AMP Cache 3,978 -27,79% 1,847 -59,93% 4,317 -20,41%
Dalam kasus ini, perbedaan waktu muat keseluruhan antara Dioptimalkan dan Dioptimalkan + SSR menjadi sangat kecil karena versi server-side-rendering tertahan oleh download font tambahan. Namun, rendering masih dimulai jauh lebih cepat dengan server-side-rendering.
Catatan: AMP Cache lebih cepat dalam semua kasus. Ada dua alasan utama:
  1. ia melakukan optimalisasi gambar tambahan
  2. ia tidak perlu membuat koneksi https kedua untuk mendownload waktu proses AMP karena waktu proses ditayangkan dari domain yang sama.

Kesimpulan

Kami melihat kemungkinan untuk membuat halaman AMP yang memuat lebih cepat lagi di server Anda sendiri. Kunci untuk semua pengguna yang ingin memublikasikan halaman AMP adalah:
  1. Situs web yang melakukan hosting AMP tersambung harus mengimplementasikan rekomendasi dalam panduan optimalisasi AMP untuk memastikan kinerja pemuatan terbaik dari Twitter dan platform lain yang terhubung ke dokumen AMP non-cache. Sedikit perubahan bisa berarti bahwa halaman AMP memuat 1 detik lebih cepat.
  2. Situs web yang di-build dengan AMP harus mempertimbangkan penggunaan AMP Optimizer karena ia mengaktifkan rendering progresif dan meningkatkan waktu FCP secara signifikan.
Kami secara aktif berupaya menemukan optimalisasi baru dan meningkatkan pengalaman pemuatan AMP.
Ditulis oleh Sebastian Benz, Partner Developer Advocate, Google

Ditulis oleh Don Turner, Developer Advocate, Android Audio Framework

Minggu ini kami merilis versi produksi Oboe yang pertama - library C++ untuk membangun aplikasi audio real-time. Oboe menyediakan latensi audio terendah di rentang perangkat Android terluas, serta beberapa keuntungan lainnya.

API Tunggal

Oboe memanfaatkan peningkatan kinerja dan fitur AAudio pada Oreo MR1 (API 27+) sembari mempertahankan kompatibilitas mundur (menggunakan OpenSL ES) pada API 16+. Ini semacam AndroidX untuk audio bawaan.
Diagram yang menunjukkan API audio dasar yang akan digunakan Oboe

Lebih sedikit kode yang harus ditulis dan dikelola

Dengan menggunakan Oboe, Anda bisa membuat streaming audio hanya dalam 3 baris kode (vs 50+ baris di OpenSL ES):
AudioStreamBuilder builder;
AudioStream *stream = nullptr;
Result result = builder.openStream(&stream);

Keuntungan lainnya

  • C++ API yang mudah digunakan (menggunakan standar C++11)
  • Proses rilis yang cepat: disediakan sebagai library sumber, perbaikan bug bisa diluncurkan dalam beberapa hari, sedikit lebih cepat daripada siklus rilis platform Android
  • Lebih sedikit menebak: Menyediakan solusi untuk bug audio yang dikenal dan memiliki perilaku default yang bagus untuk properti streaming, seperti frekuensi sampel dan format data audio
  • Open source dan dikelola oleh engineer Google (meskipun kami menerima kontribusi pihak luar)

Memulai

Lihatlah pengantar video singkat berikut:
Lihat dokumentasi, contoh kode dan referensi API. Bahkan ada codelab yang menunjukkan kepada Anda cara mem-build game berbasis ritme.
Jika Anda memiliki masalah apa pun, silakan laporkan di sini, kami ingin mendengar masukan Anda.

Ditulis oleh Matt Henderson, Product Manager, Google Play

Hari ini kami memulai Playtime, rangkaian event global tahunan kami, yang menjadi tuan rumah lebih dari 800 peserta di Berlin dan San Francisco untuk berbagi analisis dari para ahli di seluruh dunia dan update terkini mengenai produk kami. Kegiatan ini akan diikuti dengan event di Sao Paulo, Singapura, Taipei, Seoul, dan Tokyo.
Di Google Play, kami terus berinvestasi dalam fitur yang memudahkan Anda dalam mengembangkan dan mendistribusikan aplikasi ke audience global. Berikut adalah beberapa update menarik yang kami umumkan hari ini:

Membangun aplikasi yang lebih kecil

Android App Bundle adalah format publikasi baru Android, dengan ini Anda bisa lebih mudah menghadirkan pengalaman menakjubkan dalam ukuran aplikasi yang lebih kecil. Aplikasi yang lebih kecil memiliki rasio konversi yang lebih tinggi dan penelitian pengguna kami menunjukkan bahwa ukuran aplikasi adalah motivator utama yang mendorong uninstal. Dengan modularisasi Android App Bundle, Anda juga bisa memberikan fitur sesuai permintaan, bukan pada waktu penginstalan, sehingga semakin mengurangi ukuran aplikasi.
Ribuan paket aplikasi sudah diproduksi, dengan pengurangan ukuran rata-rata 35%. Hari ini, kami mengumumkan update yang menawarkan alasan tambahan bagi Anda untuk beralih ke paket ini.
  • Penghematan ukuran yang semakin banyak: paket aplikasi sekarang rata-rata berukuran 8% lebih kecil saat didownload dan 16% lebih kecil pada perangkat di perangkat M+ tanpa kerja tambahan dari developer. Penghematan baru ini berasal dari dukungan library bawaan tidak terkompresi, yang menghilangkan kebutuhan untuk menyimpan banyak salinan di perangkat.
  • Lebih mudah beralih: Anda sekarang bisa mem-build paket aplikasi di rilis stabil Android Studio 3.2 dan Unity 2018.3 beta.
  • Dukungan yang ditingkatkan untuk aplikasi besar: Anda sekarang bisa mengupload paket aplikasi besar dengan ukuran APK terinstal hingga 500MB tanpa perlu menggunakan file ekspansi. Fitur ini masih dalam akses awal dan kami akan meluncurkannya ke semua developer pada masa mendatang.
Untuk mempelajari lebih lanjut tentang Android App Bundle, fitur dinamis, dan semua keuntungan yang Anda terima dari mem-build aplikasi modular yang lebih kecil, baca postingan Medium kami.

Membangun pengalaman instant terpadu


Kami telah mendengarkan masukan Anda untuk mempermudah mem-build instant app, dan kami baru-baru ini meningkatkan batas ukuran hingga 10MB untuk mengaktifkan TRY NOW di Play Store dan menghapus persyaratan URL. Untuk developer game, kami telah bermitra dengan Unity pada plugin Google Play Instant dan telah mem-build instant langsung ke Cocos Creator yang baru.
Kami sekarang menggunakan Android App Bundle untuk memecahkan salah satu titik kesulitan utama dalam mem-build instant app. Sebelumnya, Anda harus memublikasikan instant app dan aplikasi yang dapat diinstal. Dengan Android Studio 3.2, Anda bisa memublikasikan paket yang diaktifkan-instant tetapi Anda masih harus memublikasikan paket aplikasi utama.
Sekarang, Anda tidak perlu mengelola kode terpisah. Dengan rilis versi beta Android Studio 3.3, developer bisa memublikasikan satu paket aplikasi dan mengklasifikasikannya atau modul tertentu untuk diaktifkan dengan instant. Paket aplikasi terpadu adalah masa depan pengalaman instant app dan kami berharap Anda akan mencobanya.

Memperluas uji coba instant

Google Play Instant kini tersedia untuk judul premium dan campaign pra-registrasi, sehingga orang-orang bisa mencoba game Anda sebelum diluncurkan dan menghasilkan buzz tambahan. Aplikasi dan game baru bergabung dengan Google Play Instant setiap hari, dan kami sangat gembira menyambut Umiro, dari Devolver Digital, dan Looney Tunes World of Mayhem, dari Scopely, sebagai beberapa mitra pertama yang memanfaatkan fitur-fitur terbaru ini.

Mengurangi tingkat error dan meningkatkan kualitas

Konsol Play menawarkan dua fitur untuk membantu Anda memantau kinerja dan meningkatkan kualitas aplikasi Anda. Laporan pra-peluncuran menjalankan aplikasi Anda di perangkat sungguhan yang terletak di Firebase Test Lab dan menghasilkan metadata yang berguna untuk membantu Anda mengidentifikasi dan memperbaiki masalah sebelum mendorong aplikasi ke produksi. Android vitals membantu Anda melacak kinerja dan kualitas aplikasi di perangkat pengguna di dunia nyata.
Sekarang, kami menghubungkannya bersama untuk memberikan lebih banyak analisis yang dapat ditindaklanjuti. Setiap kali error dunia nyata di Android vitals terlihat selama eksekusi laporan pra-peluncuran, Anda akan mendapatkan semua metadata tambahan dari laporan pra-peluncuran yang tersedia bagi Anda di dasbor Android vitals sehingga Anda bisa melakukan debug dengan lebih efektif. Ini juga tersambung di kedua arah, sehingga jika terjadi error dalam laporan pra-peluncuran yang sudah terjadi di dunia nyata, Anda akan dapat melihat dampaknya saat ini di Android vitals yang akan membantu Anda memprioritaskan masalah yang ditandai oleh laporan pra-peluncuran dengan lebih baik.

Mengoptimalkan aplikasi dan bisnis Anda

Kami telah membuat beberapa update untuk mempermudah pengelolaan aplikasi dan bisnis Anda dengan Play.
  • Fitur untuk mempertahankan pelanggan: di I/O kami memperkenalkan survei pembatalan, di sini Anda bisa mendapatkan analisis tentang mengapa pelanggan Anda membatalkan langganan. Sekarang kami menguji kemampuan bagi pengguna untuk menghentikan sementara langganan mereka sebagai ganti membatalkannya, dan memberikan Anda kesempatan untuk memberikan promosi guna mengajak kembali pelanggan yang membatalkan.
  • Penetapan harga langganan yang lebih fleksibel: Anda sekarang bisa mengubah harga langganan saat ini tanpa perlu membuat SKU baru di Play Billing Library versi 1.2. Anda juga bisa menawarkan perubahan paket dan mengefektifkan perubahan pada tanggal perpanjangan saat ini.
  • Metrik yang lebih kuat: kami telah menambahkan fitur baru di Konsol Play untuk membantu Anda mengevaluasi metrik inti. Penambahannya meliputi data kumulatif, metrik rata-rata 30 hari berjalan, dan naik dalam periode waktu yang berbeda agar lebih sesuai dengan kondisi bisnis Anda. Anda juga bisa mendownload setiap laporan yang dikonfigurasi sebagai file CSV.
  • Update aplikasi yang lebih mudah: Anda sekarang bisa meminta pengguna untuk melakukan update tanpa meninggalkan aplikasi dengan API baru yang disebut In-App Updates. Developer bisa menunjukkan pengalaman selayar penuh untuk pengguna dari download hingga mulai ulang, atau membantu pengguna mendownload dan menginstal di latar belakang dengan pemantauan status yang apik. Program ini sekarang masih dalam akses awal dan akan diluncurkan dalam beberapa bulan ke depan.

Cara baru untuk mempelajari Play

Kami sama-sama bersemangat dalam meluncurkan Academy for App Success dengan kursus interaktif baru untuk membantu developer memanfaatkan Konsol Play, memahami kebijakan Play, dan memanfaatkan praktik terbaik untuk meningkatkan kualitas dan kinerja bisnis. Program baru yang gratis ini memungkinkan Anda untuk melacak kemajuan belajar Anda dengan kuis dan pencapaian untuk menunjukkan keahlian Anda. Tersedia dalam bahasa Inggris hari ini, konten baru dan kursus yang diterjemahkan akan ditambahkan dalam waktu dekat.
Kami terus terinspirasi oleh apa yang Anda build dan dampaknya terhadap orang-orang di seluruh dunia. Lihat koleksi #IMakeApps kami untuk menghargai beberapa orang luar biasa yang membuat aplikasi serta game dan bagikan kisah #IMakeApps Anda.


Catatan editor: Artikel berikut awalnya diposting di Medium oleh Vamsee Jasti, AMP Product Manager di Google. Postingan ini adalah bagian dari seri monetisasi AMP yang lebih besar.
Saya tidak habis-habisnya terpesona bahwa pengiklan mau membayar untuk tayangan iklan yang tidak pernah dilihat pengguna. Namun, begitulah sebagian besar isi default kontrak iklan. Banyak merek mengubah cara mereka menegosiasikan kontrak atau mendefinisikan ulang apa yang mereka sebut keterlihatan. Ditambah lagi, terminologi itu sendiri bisa membingungkan.

Menyeimbangkan tingkat keterlihatan halaman dengan iklan yang ditayangkan

Tingkat keterlihatan (juga dikenal sebagai % keterlihatan) didefinisikan sebagai (jumlah iklan yang dilihat / jumlah total iklan yang ditayangkan) X 100. Bergantung pada pengiklan bermitra, penayang secara unik mengonfigurasi situsnya untuk tingkat keterlihatan yang lebih tinggi atau meningkatkan jumlah iklan yang ditayangkan karena mereka berkorelasi terbalik.
Di AMP, menyesuaikan halaman Anda untuk mendorong tingkat keterlihatan atau penayangan yang lebih tinggi bukanlah hal sulit bagi penayang dengan menggunakan atribut ‘data-loading-strategy’ pada komponen `amp-ad`.

Data Loading Strategy pada amp-ad

Atribut data loading strategy mengambil nilai float antara [0,3]. Nilai ini merepresentasikan jumlah viewport antara pengguna dan iklan di halaman. Semakin kecil angkanya, semakin lama waktu proses harus menunggu untuk melakukan permintaan iklan dan sebaliknya. Jika Anda adalah penayang yang ingin meningkatkan tingkat keterlihatan, maka Anda harus menjaga nilai ini sekecil mungkin dan jika Anda menetapkannya ke nilai yang lebih besar (mis. 3), Anda menginstruksikan waktu proses untuk mulai memuat iklan selama ia berada dalam 3 viewport dari lokasi pengguna di halaman.
<amp-ad width="300"
  height="250"
  type="a9"
  data-loading-strategy=1
  data-aax_size="300x250"
  data-aax_pubname="test123"
  data-aax_src="302">
</amp-ad>
Jika penayang tidak mengonfigurasi nilai ini atau nilainya ditetapkan ke ‘prefer-viewability-over-views’, maka waktu proses menyetel nilai float ke nilai default 1,25, yang merupakan nilai yang telah teruji untuk memberikan nilai keterlihatan tinggi tanpa secara drastis memengaruhi total iklan yang ditayangkan.
data-loading-strategy="prefer-viewability-over-views"

Efek Render on Idle

Tahun lalu, ekstensi DoubleClick Fast Fetch memperkenalkan mekanisme yang disebut ‘Render on Idle’, dengan waktu proses akan mulai meminta iklan yang sangat jauh di bawah viewport jika waktu proses mendeteksi bahwa viewport telah selesai memuat semua komponen lain di halaman dan sedang idle. Akibatnya, ini akan menyebabkan penurunan dalam tingkat keterlihatan tetapi akan meningkatkan jumlah iklan yang ditayangkan sehingga meningkatkan kemungkinan pemuatan pada waktunya untuk dilihat pengguna. Karena itu, perhatikan bahwa jika Anda mengonfigurasi ‘data-load-strategy’, maka render on idle akan dinonaktifkan di halaman.
Karena industri bergeser dari tampilan ke arah keterlihatan, penayang bisa dengan mudah mengonfigurasi dan menguji strategi berbeda untuk memuat iklan dengan mengubah satu baris kode di halaman AMP.
Penayang bahkan bisa mempertimbangkan konfigurasi pada tingkat CMS untuk fleksibilitas tambahan.
Terima kasih kepada Rudy Galfi dan Maggie Shiels untuk postingan ini.


Ditulis oleh Clayton Wilkinson, Developer Platforms Engineer
Hari ini, kami merilis update untuk ARCore, platform Google untuk mem-build pengalaman augmented reality, dan untuk Sceneform, library rendering 3D untuk mem-build aplikasi AR di Android. Update ini meliputi penyempurnaan algoritme yang memungkinkan aplikasi Anda menggunakan lebih sedikit memori dan CPU dalam sesi yang lebih lama. Update ini juga menyertakan fungsionalitas baru yang memberi Anda lebih banyak fleksibilitas atas pengelolaan konten.
Berikut ini adalah yang kami tambahkan:

Mendukung pemuatan glTF waktu proses di Sceneform

Sceneform sekarang menyertakan API yang memungkinkan aplikasi memuat model gITF pada saat waktu proses. Anda tidak perlu lagi mengonversi file gITF ke format SFB sebelum rendering. Ini akan sangat berguna untuk aplikasi yang memiliki banyak model gITF (seperti pengalaman berbelanja).
Untuk memanfaatkan fungsi baru ini -- dan memuat model dari cloud atau penyimpanan lokal saat waktu proses -- gunakan RenderableSource sebagai sumber saat mem-build ModelRenderable.
 private static final String GLTF_ASSET = "https://github.com/KhronosGroup/glTF-Sample-Models/raw/master/2.0/Duck/glTF/Duck.gltf";

  // When you build a Renderable, Sceneform loads its resources in the background while returning
    // a CompletableFuture. Call thenAccept(), handle(), or check isDone() before calling get().
    ModelRenderable.builder()
        .setSource(this, RenderableSource.builder().setSource(
                this,
                Uri.parse(GLTF_ASSET),
                RenderableSource.SourceType.GLTF2).build())
        .setRegistryId(GLTF_ASSET)
        .build()
        .thenAccept(renderable -> duckRenderable = renderable)
        .exceptionally(
            throwable -> {
              Toast toast =
                  Toast.makeText(this, "Unable to load renderable", Toast.LENGTH_LONG);
              toast.setGravity(Gravity.CENTER, 0, 0);
              toast.show();
              return null;
            });

Memublikasikan kode sumber Sceneform UX Library

Sceneform memiliki library UX elemen umum seperti deteksi bidang dan transformasi objek. Sebagai ganti membuat ulang elemen-elemen ini dari awal setiap kali mem-build aplikasi, Anda bisa mempercepat waktu pengembangan dengan mengambilnya dari library. Akan tetapi bagaimana jika Anda perlu menyesuaikan elemen-elemen ini dengan kebutuhan aplikasi khusus? Hari ini kami memublikasikan kode sumber library UX sehingga Anda bisa menyesuaikan elemen apa pun yang Anda butuhkan.

Contoh transformasi objek interaktif, yang didukung oleh elemen di Sceneform UX Library.

Menambahkan ID titik cloud ke ARCore

Beberapa developer mengatakan kepada kami bahwa ketika bekerja dengan titik cloud, mereka ingin bisa menghubungkan titik-titik antar bingkai. Mengapa? Karena ketika sebuah titik terdapat dalam banyak bingkai, ia kemungkinan besar menjadi bagian dari struktur yang kokoh dan stabil dibandingkan objek yang bergerak.
Untuk memungkinkan hal ini, kami menambahkan API ke ARCore yang akan menetapkan ID ke setiap titik di titik cloud.
ID titik baru ini memiliki elemen-elemen berikut:
  • Setiap ID unik. Oleh karena itu, ketika nilai yang sama muncul di lebih dari satu bingkai, Anda tahu bahwa nilai ini terkait dengan titik yang sama.
  • Titik-titik yang keluar dari tampilan hilang selamanya. Bahkan jika bidang fisik itu kembali terlihat, sebuah titik akan diberi ID baru.

Perangkat baru

Yang terakhir tetapi tidak kalah pentingnya, kami terus menambahkan dukungan ARCore ke lebih banyak perangkat sehingga pengalaman AR Anda bisa menjangkau lebih banyak pengguna di lebih banyak platform. Ini meliputi smartphone dan -- untuk pertama kalinya -- perangkat Chrome OS, Acer Chromebook Tab 10.

Di mana menemukan kami

Anda bisa mendapatkan informasi terbaru tentang ARCore dan Sceneform di https://developers.google.com/ar/develop
Sudah siap untuk mencoba contoh atau memiliki masalah, kunjungi project kami yang dihosting di GitHub:

Ditulis oleh Tim Flutter di Google

Flutter adalah toolkit aplikasi seluler Google yang baru untuk membuat antarmuka bawaan yang indah di iOS dan Android dalam waktu singkat. Hari ini, selagi keynote Google Developer Days di Shanghai, kami mengumumkan Flutter Release Preview 2: tonggak penting terakhir kami sebelum Flutter 1.0.

Rilis ini melanjutkan pekerjaan penyelesaian skenario inti dan peningkatan kualitas, dimulai dengan rilis versi beta awal pada bulan Februari hingga ketersediaan Release Preview pertama kami awal musim panas ini. Tim sekarang sepenuhnya fokus untuk menyelesaikan rilis 1.0 kami.

Apa yang Baru di Release Preview 2

Tema untuk rilis ini adalah Aplikasi iOS pixel-perfect. Meskipun kami merancang Flutter dengan pengalaman yang disesuaikan dan sangat berorientasi pada merek, kami mendengar beberapa masukan dari Anda yang ingin mem-build aplikasi dengan mengikuti panduan antarmuka Apple. Jadi dalam rilis ini kami sangat memperluas dukungan kami untuk kontrol bertema "Cupertino" di Flutter, dengan library widget dan class yang ekstensif sehingga semakin mempermudah mem-build yang terfokus ke iOS.

Reproduksi halaman beranda Setelan iOS, di-build dengan Flutter
Berikut adalah beberapa widget bertema iOS baru yang ditambahkan di Flutter Release Preview 2:
Dan lebih banyak lagi yang diupdate:
Seperti biasa, dokumentasi Flutter adalah tempat untuk mencari informasi mendetail tentang class Cupertino*. (Perhatikan bahwa pada saat penulisan, kami masih bekerja untuk menambahkan beberapa widget Cupertino baru ini ke katalog widget visual).
Kami juga telah membuat kemajuan untuk menyelesaikan skenario lain. Intinya, dukungan telah ditambahkan untuk mengeksekusi kode Dart di latar belakang, bahkan saat aplikasi ditangguhkan. Pembuat plugin bisa memanfaatkan hal ini untuk membuat plugin baru yang mengeksekusi kode pada saat event terpicu, seperti menjalankan timer, atau menerima update lokasi. Untuk pengantar yang lebih detail, silakan baca artikel Medium ini, yang menunjukkan cara menggunakan eksekusi latar belakang untuk membuat plugin pembatasan wilayah.
Peningkatan lainnya adalah pengurangan ukuran paket aplikasi kami hingga 30% di Android dan iOS. Aplikasi Flutter minimal kami di Android kini hanya berukuran 4,7 MB ketika di-build dalam mode rilis, 2 MB lebih kecil sejak kami memulai upaya ini — dan kami terus mengidentifikasi potensi optimalisasi lanjutan. (Perhatikan bahwa meskipun penyempurnaan ini memengaruhi iOS dan Android, Anda mungkin melihat hasil yang berbeda di iOS karena cara paket iOS di-build).

Momentum yang Meningkat

Seiring dengan banyaknya developer baru yang terus menemukan Flutter, kami merasa tersanjung karena melihat bahwa Flutter kini menjadi salah satu dari 50 repositori software teraktif di GitHub:

Kami mengumumkan Flutter "siap produksi" di Google I/O tahun ini; dengan Flutter semakin dekat ke rilis 1.0 stabil, banyak aplikasi Flutter baru yang dirilis, dengan ribuan aplikasi berbasis Flutter sudah muncul di Apple App Store dan Google Play store. Ini termasuk beberapa aplikasi terbesar di planet ini menurut penggunaan, seperti Alibaba (Android, iOS), Tencent Now (Android, iOS), dan Google Ads (Android, iOS). Berikut adalah video tentang bagaimana Alibaba menggunakan Flutter untuk mem-build aplikasi Xianyu (Android, iOS), yang saat ini digunakan oleh lebih dari 50 juta pelanggan di China:
Kami sangat memperhatikan kepuasan pelanggan dan secara rutin menyurvei pengguna kami. Kami berjanji untuk membagikan hasilnya kembali dengan komunitas, dan survei terbaru kami menunjukkan bahwa 92% developer merasa puas atau sangat puas dengan Flutter dan akan merekomendasikan Flutter kepada orang lain. Ketika berhubungan dengan pengembangan yang cepat dan UI yang indah, 79% developer menemukan bahwa Flutter sangat membantu sekali atau sangat membantu dalam mencapai kecepatan engineering maksimum dan mengimplementasikan UI yang ideal. Dan 82% developer Flutter merasa puas atau sangat puas dengan bahasa pemrograman Dart, yang baru saja merayakan pencapaian tonggak penting rilis untuk Dart 2.
Pertumbuhan komunitas Flutter yang kuat juga bisa dirasakan dengan cara lain. Di StackOverflow, kami melihat ketertarikan yang tumbuh cepat terhadap Flutter, dengan banyak pertanyaan baru yang diposting, dijawab dan dilihat, seperti yang ditunjukkan bagan berikut:

Jumlah tampilan pertanyaan StackOverflow yang di-tag dengan masing-masing dari empat framework UI populer dari waktu ke waktu
Flutter telah dirancang open source sejak hari pertama. Itulah desainnya. Tujuan kami adalah untuk transparan tentang kemajuan kami dan mendorong kontribusi dari individu dan perusahaan lain yang memiliki hasrat yang sama dengan kami untuk melihat pengalaman pengguna yang indah di semua platform.

Memulai

Bagaimana Anda mengupgrade ke Flutter Release Preview 2? Jika Anda sudah menggunakan saluran versi beta, Anda hanya membutuhkan satu perintah:
$ flutter upgrade
Anda bisa memeriksa apakah Anda sudah menginstal Release Preview 2 dengan menjalankan flutter --version dari baris perintah. Jika Anda memiliki versi 0.8.2 atau yang lebih baru, Anda sudah memiliki semua yang dijelaskan dalam postingan ini.
Jika Anda belum mencoba Flutter, sekarang adalah waktu yang tepat, dan flutter.io memiliki semua detail yang diperlukan untuk mendownload Flutter dan memulai dengan aplikasi pertama Anda.
Saat Anda siap, ada ekosistem aplikasi contoh dan cuplikan kode lengkap untuk membantu Anda memulai. Anda bisa menemukan contoh dari tim Flutter di repo flutter/samples di GitHub, yang mencakup hal-hal seperti cara menggunakan Material dan Cupertino, pendekatan untuk melakukan deserialisasi data yang dienkode di JSON, dan banyak lagi. Ada juga daftar contoh yang dikelola yang menautkan beberapa contoh terbaik yang dibuat oleh komunitas Flutter.
Anda juga bisa mempelajari dan mengikuti informasi terkini Flutter melalui video praktik, newsletter, artikel komunitas, dan acara developer kami. Ada grup diskusi, ruang chat, dukungan komunitas, dan tempat berkumpul online mingguan yang tersedia untuk membantu Anda selama mem-build aplikasi. Release Preview 2 adalah pratinjau rilis terakhir kami. Pemberhentian berikutnya: 1.0!

Ditulis oleh Jamal Eason, Product Manager, Android

Hari ini, Android Studio 3.2 sudah bisa didownload. Android Studio 3.2 adalah cara terbaik bagi developer aplikasi untuk langsung menuju rilis Android 9 Pie terbaru dan mem-build Android App bundle baru. Sejak mengumumkan update Android Studio di Google I/O '18, kami telah menyempurnakan dan memoles lebih dari 20 fitur baru dan memfokuskan upaya kami pada peningkatan kualitas rilis Android Studio 3.2 yang stabil ini.
Semua developer sebaiknya menggunakan Android Studio 3.2 untuk bertransisi menggunakan Android App Bundle, format publikasi aplikasi yang baru. Dengan usaha yang sangat minim, Anda bisa menghasilkan paket aplikasi dengan Android Studio. Setelah mengupload paket aplikasi ke Google Play, Anda bisa mendistribusikan aplikasi yang berukuran lebih kecil dan dioptimalkan bagi pengguna. Pengguna awal telah merasakan penghematan ukuran aplikasi antara 11% - 64% dengan paket aplikasi dibandingkan ukuran aplikasi APK lama.
Fitur lain yang tidak boleh Anda lewatkan adalah Energy Profiler. Profiler baru ini memberi Anda serangkaian fitur yang akan membantu Anda mendiagnosis dan meningkatkan dampak energi aplikasi. Masa pakai baterai perangkat yang lebih baik adalah salah satu yang paling sering diminta pengguna, dan dengan Energy Profiler di Android Studio 3.2, Anda bisa melakukan bagian Anda dalam meningkatkan masa pakai baterai perangkat dengan memastikan aplikasi Anda menggunakan jumlah energi yang tepat pada saat yang tepat.
Yang terakhir, Anda juga harus memeriksa fitur Android Emulator Snapshots yang baru. Dengan menggunakan fitur ini, Anda bisa dengan cepat mengambil snapshot status emulator saat ini yang mencakup status layar, aplikasi, dan setelan saat ini. Anda bisa melanjutkan atau booting ke snapshot emulator Anda dalam waktu kurang dari 2 detik. Untuk developer aplikasi yang mencari waktu booting super cepat, atau ingin menjalankan pengujian di lingkungan Android terprediksi, Android Emulator Snapshots adalah fitur pengubah permainan bagi pengembangan aplikasi
Selain fitur-fitur utama ini, ada 20 fitur baru ditambah dengan banyak penyempurnaan kualitas yang tersembunyi dalam Android Studio 3.2. Dengan menggunakan Android Studio 3.2, Anda juga bisa mengembangkan bagi teknologi terbaru mulai dari Android Jetpack, hingga yang terbaru dalam Google Artificial Intelligence (AI) API dengan Android Slices.
Terima kasih kepada semua yang telah memberikan masukan awal pada versi rilis terbatas dan beta. Masukan Anda membantu kami meningkatkan kualitas dan fitur di Android Studio 3.2. Jika Anda siap untuk rilis stabil berikutnya, dan ingin menggunakan seperangkat fitur produktivitas baru, Android Studio 3.2 siap didownload untuk Anda memulai.
Berikut adalah daftar lengkap fitur baru di Android Studio 3.2, yang disusun menurut alur developer kunci.

Pengembangan

  • Dukungan Slices - Slices adalah cara baru untuk memanfaatkan kemampuan AI Android bawaan dengan menampilkan konten aplikasi di saran Google Penelusuran dan Asisten Google. Android Studio 3.2 memiliki template bawaan untuk membantu Anda memperluas aplikasi dengan Slice Provider API baru serta pemeriksaan lint baru untuk memastikan bahwa Anda mengikuti praktik terbaik saat menyusun slices. Untuk menggunakannya, klik kanan folder project, dan buka NewOtherSlice Provider. Pelajari lebih lanjut.

Template Slices Provider
  • Data Contoh - Fitur ini memungkinkan Anda menggunakan data placeholder untuk membantu mendesain aplikasi Anda. Ini akan membantu Anda memvisualisasikan layout yang bergantung pada data waktu proses. Anda bisa menambahkan data contoh bawaan untuk mengisi tampilan seperti RecyclerViews, ImageViews, dan TextViews melalui jendela pop-up di Layout Editor. Pelajari lebih lanjut.
  • Update Desain Material - Ketika Anda mulai bermigrasi dari library dukungan Desain Android ke library dan tema aplikasi MaterialComponents baru, Android Studio 3.2 akan menawarkan akses ke widget baru dan terupdate seperti BottomAppBar, tombol, kartu, kolom teks, gaya font baru, dan banyak lagi. Pelajari lebih lanjut.
  • Dukungan Pengeditan CMakeList - Bagi mereka yang menggunakan C/C++ dalam aplikasinya, Android Studio memiliki dukungan yang lebih baik untuk CMake. Dengan rilis Android Studio 3.2 ini, penyelesaian kode dan penyorotan sintaks sekarang bisa digunakan pada perintah skrip build CMakeList biasa.
  • Apa yang Baru di Asisten - Android Studio 3.2 memiliki panel asisten baru yang terbuka secara otomatis setelah update untuk memberi tahu Anda tentang perubahan terbaru pada IDE. Anda juga bisa membuka panel dengan memilih Help → What's New in Android Studio.
  • Dukungan Optimalisasi AndroidX - Salah satu komponen Android Jetpack adalah pengenalan library ekstensi Android (AndroidX) sebagai pengganti Pustaka Dukungan Android. Untuk menambahkan AndroidX ke project baru, Anda hanya perlu menambahkan android.useAndroidX=true ke file gradle.properties Anda. Selain itu, Android Studio 3.2 memiliki aksi optimalisasi bawaan yang baru untuk membantu migrasi project Anda ke ruang nama dan dependensi baru. Dan, jika Anda memiliki dependensi Maven apa pun yang belum bermigrasi ke ruang nama AndroidX, sistem build Android Studio juga akan secara otomatis mengonversikan dependensi project tersebut. Pelajari lebih lanjut.
  • Update Platform IntelliJ - Android Studio 3.2 menyertakan rilis platform IntelliJ 2018.1.6. Rilis IntelliJ ini menambahkan banyak perbaikan pada analisis aliran data, proses debug, inspeksi baru, anotasi eksternal inline, Git commit parsial, dan masih banyak lagi. Pelajari lebih lanjut.
  • Update Kotlin - Android Studio 3.2 memaketkan Kotlin 1.2.61, dengan dukungan bagi Android 9 Pie SDK yang ramah-Kotlin. Pelajari lebih lanjut.

Build

  • Android App Bundle - Android App Bundle adalah format publikasi aplikasi baru yang dirancang untuk membantu Anda memberikan APK yang lebih kecil kepada pengguna dan mengurangi ukuran download aplikasi Anda. Model penyajian aplikasi baru Google Play, yang disebut Dynamic Delivery, memproses paket aplikasi Anda untuk menghasilkan dan menayangkan APK yang dioptimalkan untuk setiap konfigurasi perangkat pengguna, jadi mereka hanya perlu mendownload kode dan sumber daya yang diperlukan untuk menjalankan aplikasi Anda. Dengan Android Studio 3.2 atau melalui baris perintah, Anda bisa dengan mudah mem-build kode sebagai paket aplikasi dan mendapatkan keuntungan APK yang berukuran lebih kecil berdasarkan bahasa, kepadatan layar, dan ABI tanpa perubahan pada kode aplikasi Anda. Pelajari lebih lanjut.

Build Android App Bundle
  • D8 Desugaring - Dalam beberapa kasus, fitur Bahasa Java yang baru membutuhkan bytecode dan API bahasa baru. Namun, perangkat Android lama mungkin tidak mendukung fitur ini. Desugaring memungkinkan Anda untuk menggunakan fitur ini pada perangkat lama dengan mengganti bytecode dan API bahasa baru dengan yang lama selama proses build. D8 desugaring diaktifkan secara default untuk Android Studio 3.2 dan Anda sekarang bisa menggunakan sebagian besar perubahan bahasa terbaru saat menargetkan perangkat lama.
  • R8 Optimizer - Dimulai dengan Android Studio 3.2, kami memulai transisi untuk menggunakan R8 sebagai pengganti ProGuard untuk mengoptimalkan dan mengecilkan bytecode bahasa Java. R8 masih bersifat eksperimental, jadi kami tidak menyarankan untuk memublikasikan aplikasi Anda menggunakan R8, tetapi ini adalah saat yang tepat untuk memberikan masukan awal kepada tim Android Studio sehingga kami bisa melakukan penyesuaian sebelum R8 sepenuhnya menggantikan ProGuard. Pelajari lebih lanjut.

Pengujian

  • Emulator Snapshots - Rilis terbaru Android Emulator memungkinkan Anda membuat snapshot status emulator Anda saat ini serta melakukan booting dan beralih ke snapshot apa pun dalam waktu kurang dari 2 detik. Di-build berbasis fitur Android Emulator Quickboot, Android Snapshots bahkan lebih cepat disimpan dan dimuat dengan rilis stabil ini karena peningkatan kecepatan yang tersembunyi. Saat menguji dan mengembangkan aplikasi Anda, Android snapshots memungkinkan Anda untuk melakukan pra-konfigurasi snapshot Android Virtual Device (AVD) dengan preset, aplikasi, data, dan setelan yang Anda inginkan, dan berulang kali kembali ke snapshot yang sama. Pelajari lebih lanjut.

Android Emulator Snapshots
  • Dukungan Microsoft® Hyper-V™ - Anda sekarang bisa menjalankan Android Emulator di komputer Windows® 10 yang mengaktifkan Hyper-V. Intel HAXM masih menjadi hypervisor default untuk pengalaman Android Emulator tercepat. Namun, berkat kontribusi open source baru-baru ini oleh Microsoft, dan penambahan Windows Hypervisor Platform (WHPX) API baru, Android Emulator bisa bekerja berdampingan dengan aplikasi berbasis Hyper-V lainnya, seperti Mesin Virtual lokal, menggunakan Dukungan Hyper-V yang baru. Pelajari lebih lanjut.
  • Dukungan Prosesor AMD® - Prosesor AMD kini didukung oleh Android Emulator di Windows 10. Sebelumnya, menjalankan Android Emulator terbatas pada emulasi software yang lambat saat menjalankan Windows, tetapi developer yang memiliki prosesor AMD sekarang bisa memiliki kinerja akselerasi hardware. Pelajari lebih lanjut.
  • Screen Record di Android Emulator - Anda sekarang bisa merekam layar dan audio pada semua API level Android dengan fitur perekaman layar baru di Android Emulator. Dahulu, perekaman layar pada perangkat Android fisik hanya bekerja pada Android 4.4 KitKat (API 19) dan di atasnya tanpa audio, dengan dukungan Android Emulator yang terbatas. Dengan Android Emulator terbaru (v28.0.+) Anda tidak lagi terkena batasan ini. Sebagai bonus tambahan, terdapat konversi bawaan untuk menghasilkan keluaran GIF dan WebM. Anda bisa memicu fitur perekaman layar baru melalui panel Android Emulator Extended Controls, baris perintah, dan dari Android Studio. Pelajari lebih lanjut
  • Kamera Virtual Scene untuk Android Emulator - Kamera Virtual Scene baru di Android Emulator membantu Anda mengembangkan ARCore, platform Google untuk mem-build pengalaman augmented reality. Emulator ini dikalibrasi untuk bekerja dengan ARCore API untuk aplikasi AR dan juga memungkinkan Anda memasukkan gambar bitmap adegan virtual. Kamera adegan virtual juga bisa digunakan sebagai kamera kompatibel HAL3 reguler. Pelajari lebih lanjut.
  • Asisten Koneksi ADB - Android Studio 3.2 memiliki sistem asisten baru untuk membantu memecahkan masalah koneksi perangkat ADB Android Anda. Asisten Koneksi ADB mengarahkan Anda melalui langkah pemecahan masalah umum untuk menghubungkan perangkat Android ke komputer pengembangan Anda. Anda bisa memicu asisten dari kotak dialog Run atau dengan membuka ToolsConnection Assistant . Pelajari lebih lanjut.

Pengoptimalan

  • Energy Profiler - Masa pakai baterai adalah perhatian utama bagi banyak pengguna ponsel, dan aplikasi Anda bisa berdampak pada masa pakai baterai lebih dari yang Anda sadari. Energy Profiler yang baru dalam suite profiler kinerja Android Studio bisa membantu Anda memahami dampak energi aplikasi pada perangkat Android. Anda sekarang bisa memvisualisasikan perkiraan penggunaan energi komponen sistem, dan memeriksa event latar belakang yang mungkin menguras baterai. Untuk menggunakan energy profiler, pastikan Anda terhubung ke perangkat atau emulator Android yang menjalankan Android 8.0 Oreo (API 26) atau yang lebih tinggi. Pelajari lebih lanjut.

Energy Profiler
  • Pelacakan Sistem - Fitur Pelacakan Sistem baru di CPU Profiler memungkinkan Anda untuk memeriksa cara aplikasi Anda berinteraksi dengan sumber daya sistem dalam detail yang terperinci. Periksa pengaturan waktu dan durasi yang tepat dari status thread Anda, visualisasikan bottleneck CPU pada semua core, dan tambahkan event pelacakan khusus untuk dianalisis. Untuk menggunakan pelacakan sistem, mulai pembuatan profil aplikasi Anda, klik CPU Profiler, lalu pilih System Trace recording configuration. Pelajari lebih lanjut.
  • Sesi Profiler - Kami sekarang secara otomatis menyimpan data Profiler sebagai "sesi" untuk kunjungan ulang dan pemeriksaan lanjutan saat Anda membuka Android Studio. Kami juga menambahkan kemampuan untuk mengimpor dan mengekspor heap-dump dan rekaman CPU Anda untuk analisis atau pemeriksaan lanjutan dengan fitur lain. Pelajari lebih lanjut.
  • Perekaman CPU Otomatis - Anda sekarang bisa secara otomatis merekam aktivitas CPU menggunakan Debug API. Setelah Anda menerapkan aplikasi ke perangkat, profiler akan secara otomatis memulai perekaman aktivitas CPU ketika aplikasi Anda memanggil startMethodTracing(String tracePath), dan berhenti merekam ketika aplikasi memanggil stopMethodTracing(). Demikian juga, sekarang Anda bisa secara otomatis memulai perekaman aktivitas CPU pada awal aplikasi dijalankan dengan mengaktifkan opsi Start Recording a Method Trace on Startup dalam konfigurasi untuk menjalankan. Pelajari lebih lanjut.
  • Pelacakan Referensi JNI - Bagi Anda yang memiliki kode C/C++ dalam aplikasi Android, sekarang Android Studio 3.2 memungkinkan Anda untuk memeriksa alokasi memori kode JNI di Memory Profiler. Selama Anda menerapkan aplikasi ke perangkat yang menjalankan Android 8.0 Oreo (API 26) dan yang lebih tinggi, Anda bisa menelaah ke dalam tumpukan panggilan alokasi dari referensi JNI. Untuk menggunakan fitur ini, jalankan sesi memory profiler, dan pilih JNI Heap dari menu drop-down Live Allocation. Pelajari lebih lanjut.
Sebagai rangkuman, rilis terbatas terbaru Android Studio 3.2 menyertakan beberapa fitur utama baru berikut ini:
Pengembangan
  • Optimalisasi AndroidX
  • Data Contoh
  • Update Desain Material
  • Android Slices
  • Pengeditan CMakeList
  • Apa yang Baru di Asisten
  • Pemeriksaan Lint Baru
  • Update Platform IntelliJ
  • Update Kotlin
Build
  • Android App Bundle
  • D8 Desugaring
  • R8 Optimizer

Pengujian
  • Android Emulator Snapshots
  • Screen Record di Android Emulator
  • Kamera Adegan Virtual Android Emulator
  • Dukungan Prosesor AMD
  • Dukungan Hyper-V
  • Asisten Koneksi ADB
Pengoptimalan
  • Energy Profiler
  • Pelacakan Sistem
  • Sesi Profiler
  • Perekaman CPU Otomatis
  • Pelacakan Referensi JNI

Lihat catatan rilis untuk detail selengkapnya.

Memulai


Download versi terbaru Android Studio 3.2 dari halaman download. Bila Anda menggunakan Android Studio rilis terbatas versi sebelumnya, pastikan Anda mengupdate ke Android Studio Canary 14 atau yang lebih tinggi. Bila Anda ingin mempertahankan versi stabil Android Studio, Anda bisa menjalankan versi rilis stabil dan versi rilis terbatas Android Studio secara bersamaan. Pelajari lebih lanjut.
Untuk menggunakan fitur Android Emulator yang disebutkan, pastikan Anda menjalankan setidaknya Android Emulator v28.0.7+ yang didownload melalui Android Studio SDK Manager.
Kami menghargai setiap masukan tentang hal-hal yang Anda sukai, dan masalah atau fitur yang ingin Anda lihat. Harap perhatikan, untuk menjaga kualitas produk tetap tinggi, beberapa fitur (mis. Navigation Editor) yang Anda lihat di saluran rilis sebelumnya tidak diaktifkan secara default di saluran rilis stabil. Jika Anda menemukan bug atau masalah, silakan melaporkan masalah. Hubungi kami -- tim pengembangan Android Studio ‐ di halaman Google+ atau di Twitter kami.