WEBVTT

00:00:00.500 --> 00:00:03.469
Mari luangkan waktu sejenak agar
semuanya benar-benar jelas.

00:00:03.469 --> 00:00:04.930
Kaitannya dengan baterai,

00:00:04.930 --> 00:00:09.820
jaringan adalah pelaku terbesar,
terburuk dan terkotor.

00:00:09.820 --> 00:00:13.080
Ingat kalau di dalam ponsel terdapat
potongan kecil perangkat keras

00:00:13.080 --> 00:00:16.290
yang secara efektif yaitu HAM radio,
bertujuan untuk berkomunikasi

00:00:16.290 --> 00:00:20.410
dengan menara seluler lokal,
dan mengirim data dengan volume tinggi.

00:00:20.410 --> 00:00:23.570
Tapi cip ini tidak selalu aktif,

00:00:23.570 --> 00:00:27.210
setelah mengirim paket data, cip radio
tetap tinggal sementara waktu

00:00:27.210 --> 00:00:30.780
untuk berjaga-jaga jika nanti
ada respon dari server.

00:00:30.780 --> 00:00:34.410
Jika tidak ada aktivitas, perangkat keras 
akan mati untuk menghemat daya baterai.

00:00:34.410 --> 00:00:37.493
Seperti tadi, terdapat lonjakan besar daya
saat pertama kali

00:00:37.493 --> 00:00:41.986
cip dinyalakan, dan juga
saat cip menunggu respon.

00:00:41.986 --> 00:00:44.380
Pada waktu yang sama
akan terus menyerap daya baterai.

00:00:44.380 --> 00:00:49.200
Ada dua jalan utama dimana kebanyakan
aplikasi berinteraksi dengan radio.

00:00:49.200 --> 00:00:52.290
Pertama-tama, ada kejadian
yang harus muncul sekarang ini.

00:00:52.290 --> 00:00:54.380
Kejadian ini adalah hasil
dari tindakan pengguna

00:00:54.380 --> 00:00:57.860
atau muncul dari kebutuhan mendesak
untuk memperbarui UI di aplikasi.

00:00:57.860 --> 00:01:00.158
Contohnya, bayangkan ketika
pengguna meminta

00:01:00.180 --> 00:01:02.653
memuat<i> batch tweet</i> baru untuk
tren <i>hashtag</i>, karena ini

00:01:02.653 --> 00:01:07.600
Anda harus cepat merespon
karena ini adalah langkah awal pengguna.

00:01:07.600 --> 00:01:10.480
Di sisi lain, seluruh tugas lain

00:01:10.480 --> 00:01:14.600
yang tidak mendesak,
misalnya, mengunggah data pengguna,

00:01:14.600 --> 00:01:18.330
menyinkronkan statistik latar belakang,
atau mengatur ukuran foto.

00:01:18.330 --> 00:01:21.490
Jadi, set tugas pertama
harus cepat dilaksanakan,

00:01:21.490 --> 00:01:25.160
untuk memberi umpan balik ke pengguna.
Set tugas kedua bisa ditunda dulu

00:01:25.160 --> 00:01:29.620
sampai nanti, dikerjakan saat
keadaan baterai efisien.

00:01:29.620 --> 00:01:32.390
Dan ada kemungkinan besar
jika sebagian besar permintaan

00:01:32.390 --> 00:01:35.585
jaringan di dalam aplikasi masuk
ke dalam kategori kedua.

00:01:35.585 --> 00:01:39.420
[Tertawa] Mengonversi tugas jaringan
berlebihan guna mengefisiensi

00:01:39.420 --> 00:01:41.380
adalah proses dua langkah.

00:01:41.380 --> 00:01:45.210
Pertama-tama, perhatikan baris <i>radio</i>
<i>mobile</i> di dalam <i>tool</i>

00:01:45.210 --> 00:01:46.890
<i>battery historian</i> aplikasi Anda.

00:01:46.890 --> 00:01:50.620
Setiap <i>bar</i> merah di sini
mewakili <i>radio mobile</i> yang aktif,

00:01:50.620 --> 00:01:53.620
celah apapun antara <i>bar</i> tersebut
mewakili ketika radio tertidur.

00:01:53.620 --> 00:01:55.180
Jika Anda lihat banyak
<i>bar</i> renggang

00:01:55.180 --> 00:01:58.160
dan celah antara grafik, ini menunjukkan
adanya masalah performa,

00:01:58.160 --> 00:02:01.850
artinya Anda banyak berputar-putar
pada siklus bangun dan tidur.

00:02:01.850 --> 00:02:06.820
Yang seharusnya Anda lihat adalah celah
besar di sebelah blok aktivitas besar.

00:02:06.820 --> 00:02:10.538
Dengan ini Anda mengurangi <i>overhead</i>
dengan meminimalisasi jumlah

00:02:10.538 --> 00:02:13.600
permintaan jaringan, dan yang terbaik
adalah tidak usah menyalakan radio.

00:02:13.600 --> 00:02:16.620
Tunggu sampai terhubung dengan WiFi,

00:02:16.620 --> 00:02:21.470
biarkan perangkat WiFi mengerjakan
semua tugas ini untuk menghemat baterai.

00:02:21.470 --> 00:02:24.400
Sekarang, masalahnya adalah
menulis kode ke <i>batch, cache,</i>

00:02:24.400 --> 00:02:28.190
dan menunda seluruh permintaan
jaringan ini sulit dilakukan,

00:02:28.190 --> 00:02:29.900
karenanya kami
selesaikan untuk Anda.

00:02:29.900 --> 00:02:33.840
<i>JobScheduler API</i> yang diluncurkan
dengan rilis L Android,

00:02:33.840 --> 00:02:36.173
menyediakan rangkaian penuh API
yang melaksanakan

00:02:36.173 --> 00:02:40.260
semua tugas manajemen permintaan jaringan
dan lainnya.

00:02:40.260 --> 00:02:43.140
Tapi daripada saya menjelaskan
tentang API,

00:02:43.140 --> 00:02:44.770
kenapa tidak coba mempraktikkannya?