Let's take a moment to make
something insanely clear.
As far as battery is concerned,
networking is the biggest, baddest,
dirtiest offender that there is.
Remember that inside of your phone
is a small piece of hardware that's
effectively a HAM radio,
its whole purpose it to communicate with
local cell phone towers and
transmit data to them at high volumes.
But the trick is that this chip,
isn't always active, you see,
once you send a packet of data the radio
chip will stay on for a certain amount
of time, just in case there's a response
from the server that it's expecting.
But if there's no activity, the hardware
will shut down to save battery life.
And as we've seen before, there's a
large battery spike when this chip first
turns on, and as long as it's
keeping itself awake to wait for
responses, it's going to keep on
draining the battery at the same time.
Now it's worth pointing out that there's
two primary ways in which most apps
interact with the radio.
Firstly, there are events
that need to occur right now.
These events are the result
of some user action, or
they arise from the immediate need
to update the UI of your app.
For example, imagine when the user
asks to load a new batch of tweets for
a trending hashtag,
since this is a user initiated action,
your app should respond ASAP.
On the other side of this coin are all
the networking jobs that don't need
to happen in a time critical manner for
example, uploading user data,
synchronizing background statistics, or
re-sizing all of your social photos.
So while the first set of tasks happen,
has to happen immediately,
in order to provide feedback to the
user, the second set of tasks can easily
be put off until later, when they can be
performed in a battery efficient manner.
And there's a high probability,
that the majority of your
network requests in your application
fall into this second category.
[LAUGH] Converting networking jobs
over to being more efficient is
a two step process.
Firstly, take a hard look at the mobile
radio row in your battery historian
tool for your application.
Each of those red bars that you see
here represent an active mobile radio,
any gaps between those bars
represent when the radio is asleep.
If you see lots of narrow bars and
gaps in your graph, this can point to
your performance problems, since it
means that you're churning through
lots of wake up and sleep cycles.
What you want instead, is to see large
gaps next to large blocks of activity.
This way you've reduced overhead by
minimizing the number of network
requests, and even better,
don't use the radio at all.
I mean you can wait until
the phone is connected to WiFi and
then let the WiFi hardware do all this
work with much less battery train.
Now, the problem is that writing
the code to batch, cache,
and defer all these networking requests
is really difficult to get right,
which is why we've done the work for
you.
The JobScheduler API that rolled out
with the L release of Android provides
a full suite of API's that do all of
this network request management work and
more, on your behalf.
But rather than telling you
about this wonderful API,
why don't you take a swing
at it in practice?
دعونا نتوقف لحظة لنوضح شيئاً بشكل تام.
عندما يتعلق الأمر بالبطارية،
الشبكات هي أكبر وأسوأ وأقذر جاني موجود.
تذكر أن داخل هاتفك يوجد جهاز صغير
يعتبر جهاز موجات بث HAM فعال،
الغرض الوحيد منه هو التواصل
مع أبراج الهاتف الخليوي المحلية
ونقل البيانات لها بكميات كبيرة.
ولكن الحيلة هي أن هذه الرقاقة،
ليست دائما نشطة،
لاحظ، عندما تقوم بإرسال حزمة من البيانات
ستبقى رقاقة موجات البث الخليوية نشطة
لفترة معينة من الوقت،
في حال كانت تتوقع استجابة من الخادم.
لكن إذا كان هناك أي نشاط،
سوف سيتوقف الجهاز لتوفير حياة البطارية.
وكما رأينا من قبل،
هناك ارتفاع كبير في استهلاك البطارية
عندما تنشط هذه الشريحة أولاً،
وطالما أنها نشطة بانتظار الاستجابات،
سوف تستمر باستنزاف البطارية في نفس الوقت.
الآن، تجدر الإشارة
إلى أن هناك طريقتان رئيسيتان
التي تتفاعل فيهما معظم التطبيقات
مع موجات البث الخليوية.
أولاً، هناك أحداث يجب أن تحدث بنفس اللحظة.
هذه الأحداث هي نتيجة
لقيام المستخدم بعمل ما،
أو تنشأ من الحاجة الملحة لتحديث
واجهة المستخدم في التطبيق.
على سبيل المثال، تخيل عندما يطلب المستخدم
تحميل دفعة جديدة من التغريدات
أو علامات ربط التحديثات الرائجة،
وحيث أن هذا هو عمل بُدأ من قبل المستخدم،
يجب أن يستجيب التطبيق في أسرع وقت ممكن.
من ناحية أخرى، نجد جميع وظائف الشبكات
التي لا تحتاج التنفيذ في وقت حاسم،
على سبيل المثال، رفع بيانات المستخدم،
أو مزامنة إحصاءات الخلفية، أو إعادة تحجيم
جميع صورك من مواقع التواصل الاجتماعية.
ذلك عندما تحدث أول مجموعة من المهام،
فيجب أن تنفذ على الفور،
من أجل تقديم التغذية الراجعة للمستخدم،
ويمكن تأجيل المجموعة الثانية من المهام
عندما يمكن أن تنفذ بطريقة فعالة للبطارية.
هناك احتمال كبير،
أن غالبية طلبات الشبكة في التطبيق
تندرج تحت هذه الفئة الثانية.
تحويل وظائف الشبكة لتكون أكثر كفاءة
هي عملية تتألف من خطوتين.
أولاً، ألق نظرة فاحصة على سطر موجات البث
الخليوية في أداة مؤرخ البطارية في تطبيقك.
كل واحد من تلك القضبان الحمراء
التي تراها هنا تمثل موجة بث خليوية نشطة
أي فجوات بين تلك القضبان
تمثل حالة سكون موجات البث الخليوية.
إذا كنت ترى الكثير من القضبان
والثغرات الضيقة في رسمك البياني
هذا يمكن أن يشير إلى مشاكل في الأداء لديك،
يعني أنك تستنزف الكثير من الطاقة
من خلال الكثير من دورات النشاط والسكون.
ما تريد رؤيته بدلاً من ذلك،
ثغرات كبيرة بجوار كتل كبيرة من النشاط.
بهذه الطريقة تخفض الاستهلاك
عن طريق تقليل عدد طلبات الشبكة
والأفضل من ذلك، أن لا تستخدم
إشارات البث الخليوية على الإطلاق.
أعني يمكنك الانتظار
حتى يتم توصيل الهاتف بالواي فاي
ثم السماح لأجهزة الواي فاي أن تقوم
بكل هذا العمل لاستهلاك أقل بكثير للبطارية.
الآن، المشكلة هي أن كتابة كود
لتوزيع، و تخرين، وتأجيل كل طلبات الشبكات
من الصعب إكماله بشكل صحيح،
ولهذا السبب قمنا بالعمل من أجلك.
JobScheduler API
الذي أُصدر مع النسخة L من أندرويد
يوفر مجموعة كاملة من API
التي تقوم بكل هذا العمل من إدارة
طلبات الشبكة وأكثر من ذلك نيابة عنك.
ولكن بدلاً من أخبرك عن هذا الـ API الرائع،
لماذا لا تستكشفها من الناحية العملية؟
Dediquemos un momento
a algo muy evidente.
En consumo de batería,
las redes de contactos son los peores
y más grandes culpables que hay.
Recuerda que dentro de tu teléfono
hay una pequeña pieza de hardware,
una radio HAM,
cuyo único objetivo
es comunicarse con las torres de telefonía
y transmitirles información
a altos volúmenes.
Pero la clave está en que este chip
no siempre está activo.
Al enviar un paquete de datos,
el chip con radiofrecuencia
estará activo durante un tiempo,
en caso de que haya
una respuesta del servidor.
Si no hay actividad, el hardware
se desactivará para ahorrar batería.
Como hemos visto,
hay muchísima batería la primera vez
que se activa el chip,
y mientras se mantenga activo
esperando una respuesta
la batería se irá consumiendo.
Cabe señalar que hay dos formas básicas
en las que la mayoría de aplicaciones
interactúan con la radio.
En primer lugar,
hay hechos que deben ser inmediatos.
Son el resultado de la acción del usuario,
o surgen de la necesidad
de actualizar la UI de tu aplicación.
Imagina que un usuario pide cargar
unos tuits para una "trending hashtag".
Como es una acción
iniciada por un usuario,
tu aplicación debería
responder al momento.
Por otro lado,
hay tareas de redes sociales
que no tienen por qué ocurrir
de una forma tan puntual, por ejemplo:
subir datos de usuario,
sincronizar información estadística
o reajustar el tamaño de tus fotos.
Mientras se producen las primeras tareas,
que deben realizarse al momento
para proporcionar feedback al usuario,
las siguientes pueden dejarse para luego,
para que se realicen
de un modo más eficiente para la batería.
Hay una gran posibilidad de que la mayoría
de solicitudes de red en tu aplicación
caigan a esta segunda categoría.
Hacer más eficientes
las tareas de redes sociales
es un proceso de dos pasos.
Echa un ojo a la línea "mobile_radio"
de la herramienta "Battery Historian"
de tu aplicación.
Cada barra roja de aquí representa
una radiotransmisión móvil activa.
Los huecos entre las barras representan
la inactividad de la radio.
Ver muchas barras estrechas
y huecos en tu gráfico
apunta a problemas de rendimiento,
porque representa que te mueves
entre muchos ciclos activos e inactivos.
Lo que te interesa es ver huecos grandes
junto a grandes bloques de actividad.
Así reduces gastos minimizando
el número de solicitudes de red
y, lo que es mejor,
no utilizas del todo la radio.
Puedes esperar
a que el teléfono se conecte al WiFi
y dejar que el hardware WiFi
haga ese trabajo
con mucha menos consumo de batería.
Pero escribir el código para agrupar,
almacenar y aplazar
todas las solicitudes de red es difícil.
Por eso hemos hecho el trabajo por ti.
La API JobScheduler que se dio a conocer
con el lanzamiento de Android
proporciona una serie de APIs
que hacen todo el trabajo
de administración de solicitudes de red
y más por ti.
Pero en lugar de hablarte
de esta maravillosa API,
¿por qué no la entrenas
a base de práctica?
Prenons un moment
pour rendre les choses très claires.
En ce qui concerne la batterie,
le réseautage est le plus grand, mauvais,
sale coupable qu'il puisse y avoir.
À l'intérieur de votre téléphone,
il y a un petit composant de hardware,
pour une radio amateur.
Son objectif est de communiquer
avec les relais locaux de réseau mobile
et de leur transmettre plein de données.
Mais le truc, c'est que cette puce
n'est pas toujours active.
Une fois que vous enverrez
un paquet de données,
la puce de radio restera
allumée un certain temps,
juste au cas où il y aurait
une réponse du serveur.
Mais s'il n'y a pas d'activité,
le hardware s'éteindra
pour économiser la batterie.
Et comme nous avons vu précédemment,
il y a une grande pointe de batterie,
quand cette puce s'allume, et tant
qu'elle reste hors veille à attendre
des réponses, elle va continuer
à vider la batterie en même temps.
Il faut noter
qu'il y a deux grandes façons
par lesquelles
la plupart des applications
interagissent avec la radio.
D'abord, il y a des événements
qui doivent se dérouler immédiatement.
Ces événements sont le résultat
de certaines actions de l'utilisateur,
ou ils se produisent
suite au besoin immédiat
de mettre à jour l'UI
de votre application.
Par exemple, imaginez
quand l'utilisateur demande
de charger un nouvel
ensemble de tweets,
pour un hashtag à la mode,
comme c'est une action
initiée par l'utilisateur,
votre application
devrait répondre ASAP.
D'un autre côté, nous avons tous les jobs
de réseautage qui n'ont pas besoin
de se dérouler de
façon urgente,
comme mettre en ligne des
données d'utilisateur,
synchroniser des
statistiques de fond,
ou redimensionner toutes
vos photos sociales.
Donc, alors que le premier
ensemble de tâches
doit se dérouler immédiatement,
afin de fournir un
feedback à l'utilisateur,
le second ensemble de tâches
peut facilement
être reporté à plus tard,
elles pourront être menées
de manière plus économe
pour la batterie.
Et il y a une grande probabilité
que la majorité
de vos demandes de réseaux
dans votre application
tombe dans cette seconde catégorie.
Convertir les jobs de réseautage
pour être plus efficaces
est un processus en deux étapes.
D'abord, regardez bien la rangée
de votre radio mobile dans l'outil
d'historique de batterie
de votre application.
Chacune de ces barres
rouges que vous voyez ici
représente une
radio mobile active,
tous les trous entre ces barres
représentent quand la radio est en veille.
Si vous voyez beaucoup
de barres et de trous fins
dans votre graphique, cela peut indiquer
des problèmes de performance,
vu que cela signifie que
vous passez à travers
beaucoup de cycles
veille-sortie de veille.
Il vaut mieux voir de larges trous
à côté de larges blocs d'activité.
De cette façon, vous avez largement
réduit les frais,
en minimisant
le nombre de demandes
de réseaux, et mieux, en n'utilisant
plus la radio du tout.
Vous pouvez attendre que le téléphone
soit connecté au Wifi,
puis laisser le hardware
du Wifi faire tout ce travail,
en utilisant beaucoup
moins la batterie.
Alors, le problème, c'est qu'écrire
le code pour regrouper, mettre en cache
et reporter
toutes ces demandes de réseautage
est très difficile
à bien réussir,
ce pourquoi nous avons fait
le travail pour vous.
L'API JobScheduler qui a été lancée
avec la version L d'Android, offre
une suite complète d'API,
qui fait tout ce travail
de gestion des demandes de réseautage
et plus, pour vous.
Mais au lieu de vous parler
de cette API géniale,
pourquoi ne pas l'essayer vous-même ?
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 batch tweet baru untuk
tren hashtag, 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 radio
mobile di dalam tool
battery historian aplikasi Anda.
Setiap bar merah di sini
mewakili radio mobile yang aktif,
celah apapun antara bar tersebut
mewakili ketika radio tertidur.
Jika Anda lihat banyak
bar 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 overhead
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 batch, cache,
dan menunda seluruh permintaan
jaringan ini sulit dilakukan,
karenanya kami
selesaikan untuk Anda.
JobScheduler API 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?
ここで一つはっきりさせましょう
バッテリーに関する限り
ネットでの作業はこの世に存在する
最大で最悪の敵です
思い出してください
あなたの携帯の中は小さなハードウェアで
実質上 ハム（アマチュア無線）であり
その目的は電波に繋がり
大量のデータを送受信することです
ですがこの無線チップはいつも
作動しているわけではなく
一旦データのパケットが送られた後
サーバーからの応答があったときの為に
一定時間 作動状態のままになります
ですが作業がないときは
ハードウェアが電力温存のためオフになります
以前ご覧になったように
このチップが活動を始める時に
多大な電力を消費します
応対を待つ為に活動をし持続する間
同時にバッテリーも消費しています
ここでアプリの多くが無線と交信する方法は
主に二つあることを指摘しておきましょう
一つ目は即座に行われなければ
ならない作業がある場合
この作業はユーザー自身の
行為の結果であるか
アプリの UI の更新が
即座に必要な場合に起こります
例えばユーザーがトレンドのハッシュタグで
新しいツイートのバッチ読み込みを要求したら
これはユーザー側から行った行為なので
アプリは即座に対応しなければなりません
一方で 即座に行われなくてもよい
ネットワークでの作業があります
例えばユーザーデータのアップロードや
背景スタッツの同期化 又はあなたの
ソーシャル写真のサイズ変更などです
最初に説明した方ではユーザーに
返答を即座に与える必要がありますが
後者は電力的に効率よく実行できるとき
あとで返答できるのです
あなたのアプリに対する
ネット上のリクエストの大半は
この後者に当てはまる可能性が高いのです
ネットでの作業を効率化するのは
二つのステップのプロセスです
まずはあなたのアプリ用の
バッテリーヒストリアンツールの中の
mobile_radio の行をよく見てください
各々の赤い棒が活発な無線機能を示しています
これらの隙間が無線機能が
スリープ状態の時を表しています
グラフに無数の細い棒と隙間があったら
パフォーマンスに問題が出ていると言う事で
スリープ状態と起動状態を
何度も繰り返しているという事です
代わりに望ましいのは大きな間隔が
大きな活動の塊の隣にある状態で
ネットのリクエスト数を最小化して
オーバーヘッドを削減したという事です
更に良いのは無線通信を使わない事です
携帯が WiFi に接続されるまで待ち
WiFi ハードウェアに全ての作業をさせ
電池の消耗を削減最小化できます
ここで問題となるのは
バッチ処理やキャッシュのためコードを書いて
これら数々のネット作業要求を延期するのを
正しく行うのが難しいということです
そのために我々が一仕事済ませました
Android L と共に展開した
JobScheduler API は
API のフルセットで
ネット作業要求の管理やその他の仕事をします
あなたの代わりにです
ですがこの素晴らしい API の事を
私たちがお話しするより
貴方が実践で試してみてはいかがでしょう？
시작하기 전에 한가지 짚고 넘어갈게요
배터리의 관점에서 네트워킹은
가장 크고, 나쁘고, 지저분한 악당이에요
여러분의 스마트폰에는 사실상 HAM 라디오와 같은 하드웨어가 있어요
이 하드웨어의 역할은 주변 기지국과 연결해
대량 데이터를 전송하는 겁니다
하지만 이 칩은 항상 켜져 있지 않아요
데이터 패킷을 보낸 후에
라디오 칩은 짧은 시간 동안 작동상태를 유지합니다
서버에서 보내는 답장을 기다리기 위해서 말이죠
하지만 들어오는 데이터가 없다면 배터리를 아끼기 위해 종료돼요
보셨듯이 칩이 켜지면 배터리 사용량이 급등하고
응답을 기다리기 위해 켜진 상태를 유지하면
계속 전력을 소모하게 됩니다
애플리케이션이 라디오와 소통하는 방법은 크게 2가지로 나뉩니다
첫째로는 당장 처리해야 하는 작업들이 있어요
이런 작업들은 사용자의 입력에 반응하거나
애플리케이션의 UI를 업데이트해야 하는 상황이에요
예를 들어 사용자가 트윗을 요청했다고 생각해보세요
트렌드 중인 해시태그 관련 트윗들을 말이죠
이건 사용자가 실행한 작업이기 때문에
애플리케이션은 최대한 빨리 반응을 해야 해요
반면 타이밍이 중요하지 않은 네트워크 작업들도 있어요
예를 들어 사용자 정보 업로드,
백그라운드 통계정보 동기화,
소셜 미디어 사진 크기 조절 등이 있죠
첫 번째 종류의 작업들은 바로 수행되어야 하지만
사용자에게 반응을 보여주기 위해 말이죠
두 번째 종류의 작업은 나중으로 미뤄도 돼요
배터리를 효율적으로 사용할 수 있게 말이죠
여러분이 사용하는 애플리케이션의 네트워크 요청 대부분은
두 번째 종류일 가능성이 매우 커요
네트워크 작업을 더 효율적으로 처리하는 방법은
2가지 단계로 나눌 수 있어요
우선 Battery Historian 툴에서
여러분 애플리케이션의 mobile_radio 열을 자세히 보세요
보이시는 빨간 막대들은 라디오가 켜진 상태를 나타내요
막대 사이의 빈 공간은 라디오가 꺼져있는 상태를 의미합니다
그래프에서 얇은 막대와 빈 공간이 많이 보인다면
이는 성능 문제를 의미해요
라디오 시작과 종료를 반복해 churn이 발생한다는 뜻이기 때문이죠
대신 저희가 원하는 그래프 모양은 두꺼운 막대와 빈 공간이에요
이런 형태는 네트워크 요청을 최소화해 오버헤드를 줄일 수 있어요
아니면 라디오를 전혀 사용하지 않으면 가장 좋겠죠
스마트폰이 와이파이에 연결될 때까지 기다렸다
전력 소모가 적은 와이파이 하드웨어로 작업을 처리하는 거예요
문제는 네트워크 요청을 배칭, 캐싱, 그리고 미루는
코드는 작성하기 무지 어려워요
그래서 저희가 대신해드렸어요
안드로이드의 L 버젼 출시와 함께 제공된 JobScheduler API는
네트워크 요청 관리를 포함한 많은 작업을
여러분 대신해줘요
하지만 제가 JobScheduler API에 대해서 설명해드리는 것보다
여러분께서 직접 사용해 보시는 건 어떨까요?
Vamos, tomar um tempo para
deixar algo incrivelmente claro.
No que diz respeito à bateria,
o uso de redes é o maior,
pior e mais obsceno agressor que existe.
Lembre-se que dentro do seu
celular há uma pequena peça
que é efetivamente um rádio amador,
seu único propósito é comunicar-se
com as torres de celular locais
e transmitir dados em altos volumes.
Mas o truque é que esse chip
não está sempre ativo.
Quando você envia um pacote de dados
o chip do rádio permanecerá ligado
por um certo período,
no caso de haver uma resposta
do servidor que ele está esperando.
Mas se não há atividade,
o hardware se desligará
para economizar bateria.
E como vimos antes,
há um grande pico de bateria
quando o chip é ligado.
E enquanto se mantiver ligado
aguardando respostas,
ele continuará drenando a bateria.
Agora é importante salientar
que existem dois jeitos primários
em que a maioria dos apps
interagem com o rádio.
Primeiro, existem eventos que precisam
correr neste exato momento.
Estes eventos são resultado
de uma ação do usuário
ou surgem de uma necessidade imediata
de atualizar a IU de seu app.
Por exemplo, imagine quando o usuário
quer carregar um novo pacote de tweets
de uma hashtag na moda.
Como é uma ação iniciada pelo usuário,
seu app responde o mais rápido possível.
Do outro lado da moeda
estão todos os trabalhos de rede
que não precisam ocorrer de forma crítica,
por exemplo, uploading dados do usuário,
sincronizando estatísticas de fundo,
ou redimensionando todas suas fotos.
Então enquanto o primeiro conjunto
de tarefas tem de ocorrer imediatamente,
a fim de fornecer feedback ao usuário,
o segundo conjunto de tarefas
pode ser facilmente adiado,
para quando puderem ser feitas
de uma maneira energeticamente eficaz.
E há uma alta probabilidade
de que a maioria das suas
solicitações de rede,
no seu aplicativo, se enquadrem
na segunda categoria.
Transformar o uso de redes
em algo mais eficiente
é um processo de duas etapas.
Primeiro observe atentamente
a linha de rádio móvel
na ferramenta battery historian
do seu aplicativo.
Cada uma dessas barras vermelhas que você
vê aqui representam um rádio móvel ativo.
Um intervalo entre as barras
representa quando o rádio está inativo.
Se você vê muitas barras estreitas
e intervalos no gráfico,
isso pode apontar problemas de desempenho,
já que você está usando muitos
ciclos de atividade e inatividade.
O que você quer é ver grandes espaços
próximos a grandes blocos de atividade.
Assim reduz a sobrecarga minimizando
o número de requisições de rede,
e, ainda melhor, sequer usa o rádio.
Você pode esperar até que
o aparelho esteja conectado ao Wi-Fi
e então deixar o hardware de Wi-Fi
realizar todo este trabalho,
drenando menos bateria.
O problema é que desenvolver código
para sequenciar, armazenar em cache,
e protelar todas as solicitações
de rede é algo muito difícil,
por isso fizemos o trabalho pra você.
A API JobScheduler que foi lançada
juntamente com o L do Android
fornece um conjunto completo de APIs
que administra todas as
solicitações de rede e mais, a seu favor.
Mas ao invés de falar
sobre essa maravilhosa API,
porque você não experimenta na prática?
Давайте потратим немного времени,
чтобы прояснить один момент.
Для аккумулятора работа в сети —
самый большой, злой и страшный враг.
Вы знаете, что внутри вашего телефона
есть крохотное устройство,
в реальности представляющее
собой радиоприемник.
Его задача — соединяться
с местными вышками мобильной связи
и передавать им большие объемы данных.
Хитрость в том, что этот датчик
не всегда активен.
После того, как вы отправили данные,
приемник продолжает работать
какое-то время на случай появления ответа
с сервера, которого он ожидает.
Если активность отсутствует,
оборудование отключится,
чтобы сохранить заряд аккумулятора.
Как мы уже знаем, происходит сильный
скачок в работе аккумулятора,
когда чип включается в первый раз,
и пока он включен для ожидания ответов,
он продолжает использовать
ресурсы аккумулятора.
Важно подчеркнуть,
что существует два способа,
используемых большинством приложений
для связи с радио.
В первую очередь есть события,
которые должны произойти
именно в данный момент.
Эти события являются результатом
определенного действия пользователя
или созданы необходимостью
срочно обновить вид вашего приложения.
Например, представьте, что пользователь
просит загрузить новую порцию твитов
с модным хештегом.
Это действие инициировал пользователь,
поэтому приложение должно быстро ответить.
С другой стороны, все работы с сетью,
которые необязательно должны происходить
в срочном режиме,
например загрузка данных пользователя,
синхронизация фоновой статистики
или уменьшение фото для соцсетей.
То есть первая группа заданий
должна быть выполнена сразу же,
чтобы предоставить ответ пользователю,
вторую можно отложить
и выполнить в режиме
эффективного использования аккумулятора.
Высока вероятность того,
что большинство сетевых запросов
в вашем приложении
относятся ко второй категории.
Изменение сетевых задач
для более эффективного выполнения —
процесс из двух шагов.
В первую очередь посмотрите
на строку мобильного радио
в истории аккумулятора
по вашему приложению.
Красные полосы здесь отражают
периоды активности мобильного радио,
любые промежутки между ними —
работу радио в спящем режиме.
Если вы видите много узких полос
и промежутков между ними, возможно,
у вас есть проблемы с производительностью,
так как это свидетельство
множества циклов сна и пробуждения.
Ваша же цель — большие промежутки
с длительными блоками активности.
Так вы сократите затраты ресурсов,
минимизируя число сетевых запросов,
и, возможно,
не будете использовать радио совсем.
Я имею в виду, что можно подождать,
когда телефон подключится к Wi-Fi,
позволив устройствам выполнить всю работу
с меньшим расходом аккумулятора.
Написание кода специально
для групп и кеша,
откладывание этих сетевых запросов
действительно сложно выполнить,
именно поэтому мы сделали все это за вас.
Приложение JobScheduler API,
выпущенное с релизом L Android,
предлагает полный комплект API,
управляющий сетевыми запросами
и многим другим, если вы захотите.
Но вместо того, чтобы слушать
мой рассказ об этом потрясающем API,
ощутите все его преимущества
прямо сейчас на практике.
Şimdi bir şeyi
iyice açıklığa kavuşturalım.
Şarj söz konusu olduğunda,
ağ işleri olabilecek en büyük kabahatlidir.
Telefonunuzun içinde
HAM radyosu işlevi gören,
küçük bir donanım vardır.
Bunun tüm amacı yerel telefon kuleleriyle
iletişim kurmak ve bunlara
yüksek seviyede veri iletmektir.
Ama işin sırrı, bu çipin
daima aktif olmamasıdır.
Yani bir veri paketi gönderdiğinizde,
sunucudan cevap gelme ihtimali nedeniyle
radyo çipi bir süre
açık kalacaktır.
Ama etkinlik yoksa, şarj ömründen
tasarruf için donanım kapanır.
Daha önce gördüğümüz gibi,
bu çip ilk açıldığında
Enerji yükselişi olur ve cevap beklerken
açık kaldığı sürece,
şarjı da tüketmeye devam eder.
Çoğu uygulamanın radyo ile
etkileşime geçtiği iki yol
olduğunu belirtmekte fayda var.
İlki, hemen anında olması gereken
eylemler vardır.
Bu eylemler, kullanıcı
faaliyetinin sonucudur veya
uygulamanızınn UI'sini hemen
güncelleme ihtiyacından doğar.
Örneğin, trend bir hashtag için kullanıcı
bir tweet grubu yüklemek istiyor.
Eylemi kullanıcı başlattığı için
uygulamanız hemen cevap verir.
Diğer yandan, hemen olması gerekmeyen
diğer ağ işlemlerinin
zaman bakımından acil bir şekilde
olması gerekmez.
Örneğin, veri yüklemek, arka veri iletimi
sosyal fotoğrafların boyutlandırılması.
Yani ilk görev dizisinin,
kullanıcıya geri bildirim için
hemen olması gerekirken
ikinci görev dizisi,
sonra şarj açısından verimli bir şekilde
yapılması için ertelenebilir.
Ve büyük ihtimalle, uygulamanızdaki
ağ isteklerinizin çoğu,
bu ikinci kategoriye düşer.
Ağ görevlerini
daha verimli hâle getirmek,
iki adımlı bir süreçtir.
Öncelikle, uygulamanız için
Şarj tarihçisi aracındaki
mobil radyo dizisine
dikkatli bakın.
Burada gördüğünüz o kırmızı barlar
aktif mobil radyoları temsil eder,
aradaki boşluklar ise radyonun
uykuda olduğu zamanı gösterir.
Grafiğinizde çok sayıda dar çubuk ve boşluk
performans probleminizin nedeni
bu olabilir.
Çünkü bu bir çok uyandırma ve uyku,
döngüsünden geçitiğiniz anlamına gelir.
Görmek isteyeceğiniz şey ise
dev etkinlik blokları ve dev boşluklardır.
Bu şekilde ağ isteyi sayısını
en aza düşürüp genel giderleri azaltmış
hatta daha da iyisi radyoyu
hiç kullanmamış olursunuz.
Yani telefon WiFi'ye
bağlanana kadar bekler ve
sonra WiFi donanımı tüm bunları,
çok daha az şarj harcayarak yapabilir.
Ancak sorun ağ isteklerini
toplayıp saklayacak ve erteleyecek
şekilde yazmanın çok güç olmasıdır.
O yüzden sizin için bu işi biz yaptık.
Android'in L'i piyasaya sürmesiyle
çıkan JobScheduler API,
ağ isteği yönetimi işi ve fazlasını
sizin için yapan tam bir API takımı sunar.
Fakat bu harika API'yi
anlatmak yerine,
neden siz kendiniz girip denemiyorsunuz?
Hãy tạm dừng, để làm
thật rõ điều này.
Nếu liên quan đến pin,
mạng là kẻ tấn công lớn nhất,
tồi tệ nhất, xấu xa nhất.
Hãy nhớ rằng trong điện thoại
có một phần cứng nhỏ
thật ra là một bộ đàm,
mục đích của nó chỉ là kết nối
với trạm di động địa phương gần nhất
và truyền đi
lượng lớn thông tin.
Cái bẫy ở đây là con chip này,
không phải lúc nào cũng chạy,
sau khi bạn gửi
một gói dữ liệu,
con chip sẽ bật
trong một thời gian
trong trường hợp có
phản hồi từ máy chủ.
Nhưng nếu không có hoạt động gì,
nó sẽ tắt để tiết kiệm pin.
Như ta đã thấy trước đó,
có một pic năng lượng lớn
khi chip được bật lên,
và khi nó vẫn thức
để chờ phản hồi,
nó sẽ tiếp tục tiêu hao
pin trong thời gian đó.
Bây giờ, cần phải chỉ ra rằng
hai cách chính
mà hầu hết các ứng dụng
tương tác với sóng radio.
Đầu tiên, có những sự kiện
cần phải diễn ra ngay.
Những sự kiện này là kết quả
hoạt động người dùng
hoặc phát sinh từ nhu cầu cập nhật UI
của ứng dụng ngay lập tức.
Ví dụ, khi người dùng yêu cầu
tải một gói mới các tweet
của một hashtag được yêu thích.
Vì đây là hoạt động từ người dùng,
ứng dụng của bạn cần phản hồi ASAP ngay.
Mặt khác, ở góc này là các
đầu việc hệ thống
không cần phải xảy ra
vào cùng thời điểm
ví dụ, tải dữ liệu người dùng,
đồng hóa số liệu nền,
hoặc
thay đổi kích thước ảnh từ mạng.
Vậy, trong khi gói nhiệm vụ
thứ nhất cần diễn ra ngay,
để cung cấp phản hồi
cho người dùng,
gói nhiệm vụ thứ hai
có thể đẩy ra sau,
khi có thể thực hiện
mà vẫn tiết kiệm pin.
Và, có nhiều khả năng
là phần lớn các yêu cầu
từ mạng đến ứng dụng
sẽ nằm trong gói thứ hai.
chuyển việc hệ thống để tăng
hiệu quả pin là một quy trình hai bước
Đầu tiên, hãy nhìn kỹ
dòng sóng di động
cho ứng dụng của bạn
trên battery historian.
Mỗi thanh đỏ ở đây đại diện cho
một sóng di động đang bật,
các khoản trống giữa các thanh này
là khoảng thời gian sóng tắt đi.
Nếu bạn thấy rất nhiều
thanh hẹp và khoảng trống
điều này thể hiện
vấn đề về hiệu quả,
vì nó có nghĩa là đã có rất nhiều
chuỗi bật tắt liên tục.
Ngược lại, những khoảng trống, rồi
hoạt động rộng sẽ tốt hơn.
Như vậy, bạn đã giảm bớt tiêu hao
bằng cách giảm số yêu cầu từ hệ thống,
và thậm chí tốt hơn,
không dùng sóng chút nào.
Ý tôi là bạn có thể chờ đến
khi điện thoại kết nối WiFi
và để phần cứng của Wifi làm
việc này, ít tốn pin hơn nhiều.
Bây giờ, vấn đề là viết mã
để gom thành khối, lưu trữ
và hoãn tất cả các yêu cầu
hệ thống là cực kỳ khó,
vì vậy chúng tôi
đã làm điều này cho bạn.
JobScheduler API có thể tráo đổi
với L release của Android cung cấp
một gói đầy đủ các API
sẽ làm tất cả việc quản lý
yêu cầu hệ thống thay cho bạn.
Nhưng, thay vì nói cho bạn
về API tuyệt vời này,
sao bạn không tìm hiểu kỹ
nó qua thực hành nhỉ?
让我们来强调一点。
对于电池来说，
网络连接是最最最耗电的工作。
你的手机里有一个小小的硬件，
HAM无线电，
它的功能就是连接当地的电话信号塔，
和它们进行大量数据传输。
但是这个芯片并不是一直活跃的，
一旦你发送了部分数据，
无线芯片在一定的时间内，
会保持开启状态来接收潜在的返回数据。
但是如果一直没有活动，
这个硬件就会休眠，节省电量。
之前看过了，这个芯片开启初期 ，
会消耗大量的电量，
而且只要保持开启状态，
就会持续耗电。
还要指出的是，应用与无线电互动，
有2种基本方式。
第一种，出现必须立即执行的任务。
这些任务是用户行为的结果，
或者是应用用户界面升级的即时需求。
例如，用户根据流行标签来
刷新推特界面 。
这是用户自主行为，所以应用必须立即执行。
另一方面，部分不需要立即执行的网络工作，
比如上传用户数据，
同步背景数据，或者更改全部图片大小。
所以，第一类任务需要即时执行，
需要给用户即刻反馈，而第二种任务可以延迟，
可以在电池方便时进行操作。
应用的大部分网络请求都属于第二类，
这种可能性非常高。
转换网络任务，提高效率，
可以分为2步。
首先，仔细查看应用工具电池历史里，
移动无线网(mobile_radio)这一栏。
每一个红色的栏都代表一个活跃的移动无线网，
红色栏的空隙代表无线网休眠。
如果你看到很多窄窄的栏，
这代表出现了问题，
代表这里反复，频繁出现的唤醒和休眠。
你应该期待看到大段的红栏和大段的空隙。
这代表你已经通过降低网络连接，提高了性能，
甚至没有使用任何网络连接。
你可以等手机接入WIFI后，
让WIFI硬件来处理，这样节约了大量电量。
现在的问题是，
用编写代码来分批处理，缓存并延迟，
这些网络连接工作非常困难，
所以我们已经帮你们编写完成了。
任务调度API结合安卓L release，
可以替你们完成所有的
网络连接工作。
与其不断介绍这个超级实用的API,
不如你亲自操作一下吧。
讓我們來強調一點。
對於電池來說，
網路連接是最最最耗電的工作。
你的手機裏有一個小小的硬體，
HAM無線電，
它的功能就是連接當地的電話信號塔，
和它們進行大量數據傳輸。
但是這個晶片並不是一直活躍的，
一旦你發送了部分數據，
無線晶片在一定的時間內，
會保持開啟狀態來接收潛在的返回數據。
但是如果一直沒有活動，
這個硬體就會休眠，節省電量。
之前看過了，這個晶片開啟初期 ，
會消耗大量的電量，
而且只要保持開啟狀態，
就會持續耗電。
還要指出的是，應用與無線電互動，
有2種基本方式。
第一種，出現必須立即執行的任務。
這些任務是用戶行為的結果，
或者是應用用戶介面升級的即時需求。
例如，用戶要求按照流行標籤來
加載推特介面的內容 。
這是用戶自主行為，所以應用必須立即執行。
另一方面，部分不需要立即執行的網路工作，
比如上傳用戶數據，
同步背景數據，或者更改全部圖片大小。
所以，第一類任務需要即時執行，
需要給用戶即刻回饋，而第二種任務可以延遲，
可以在電池方便時進行操作。
應用的大部分網路請求都屬於第二類，
這種可能性非常高。
轉換網路任務，提高效率，
可以分為2步。
首先，仔細查看應用工具電池歷史裏，
移動無線網(mobile_radio)這一欄。
每一個紅色的欄都代表一個活躍的移動無線網，
紅色欄的空隙代表無線網休眠。
如果你看到很多窄窄的欄，
這代表出現了問題，
代表這裏反復，頻繁出現的喚醒和休眠。
你應該期待看到大段的紅欄和大段的空隙。
這代表你已經通過降低網路連接，提高了性能，
甚至沒有使用任何網路連接。
你可以等手機接入WIFI後，
讓WIFI硬體來處理，這樣節約了大量電量。
現在的問題是，
用編寫代碼來分批處理，緩存並延遲，
這些網路連接工作非常困難，
所以我們已經幫你們編寫完成了。
任務調度API結合安卓L release，
可以替你們完成所有的
網路連接工作。
與其不斷介紹這個超級實用的API,
不如你親自操作一下吧。