Mari luangkan waktu sejenak agar
semuanya benar-benar jelas.

Kaitannya dengan baterai,

jaringan adalah pelaku terbesar,
terburuk dan terkotor.

Ingat kalau di dalam ponsel terdapat
potongan kecil perangkat keras

yang secara efektif yaitu HAM radio,
bertujuan untuk berkomunikasi

dengan menara seluler lokal,
dan mengirim data dengan volume tinggi.

Tapi cip ini tidak selalu aktif,

setelah mengirim paket data, cip radio
tetap tinggal sementara waktu

untuk berjaga-jaga jika nanti
ada respon dari server.

Jika tidak ada aktivitas, perangkat keras 
akan mati untuk menghemat daya baterai.

Seperti tadi, terdapat lonjakan besar daya
saat pertama kali

cip dinyalakan, dan juga
saat cip menunggu respon.

Pada waktu yang sama
akan terus menyerap daya baterai.

Ada dua jalan utama dimana kebanyakan
aplikasi berinteraksi dengan radio.

Pertama-tama, ada kejadian
yang harus muncul sekarang ini.

Kejadian ini adalah hasil
dari tindakan pengguna

atau muncul dari kebutuhan mendesak
untuk memperbarui UI di aplikasi.

Contohnya, bayangkan ketika
pengguna meminta

memuat<i> batch tweet</i> baru untuk
tren <i>hashtag</i>, karena ini

Anda harus cepat merespon
karena ini adalah langkah awal pengguna.

Di sisi lain, seluruh tugas lain

yang tidak mendesak,
misalnya, mengunggah data pengguna,

menyinkronkan statistik latar belakang,
atau mengatur ukuran foto.

Jadi, set tugas pertama
harus cepat dilaksanakan,

untuk memberi umpan balik ke pengguna.
Set tugas kedua bisa ditunda dulu

sampai nanti, dikerjakan saat
keadaan baterai efisien.

Dan ada kemungkinan besar
jika sebagian besar permintaan

jaringan di dalam aplikasi masuk
ke dalam kategori kedua.

[Tertawa] Mengonversi tugas jaringan
berlebihan guna mengefisiensi

adalah proses dua langkah.

Pertama-tama, perhatikan baris <i>radio</i>
<i>mobile</i> di dalam <i>tool</i>

<i>battery historian</i> aplikasi Anda.

Setiap <i>bar</i> merah di sini
mewakili <i>radio mobile</i> yang aktif,

celah apapun antara <i>bar</i> tersebut
mewakili ketika radio tertidur.

Jika Anda lihat banyak
<i>bar</i> renggang

dan celah antara grafik, ini menunjukkan
adanya masalah performa,

artinya Anda banyak berputar-putar
pada siklus bangun dan tidur.

Yang seharusnya Anda lihat adalah celah
besar di sebelah blok aktivitas besar.

Dengan ini Anda mengurangi <i>overhead</i>
dengan meminimalisasi jumlah

permintaan jaringan, dan yang terbaik
adalah tidak usah menyalakan radio.

Tunggu sampai terhubung dengan WiFi,

biarkan perangkat WiFi mengerjakan
semua tugas ini untuk menghemat baterai.

Sekarang, masalahnya adalah
menulis kode ke <i>batch, cache,</i>

dan menunda seluruh permintaan
jaringan ini sulit dilakukan,

karenanya kami
selesaikan untuk Anda.

<i>JobScheduler API</i> yang diluncurkan
dengan rilis L Android,

menyediakan rangkaian penuh API
yang melaksanakan

semua tugas manajemen permintaan jaringan
dan lainnya.

Tapi daripada saya menjelaskan
tentang API,

kenapa tidak coba mempraktikkannya?