We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Power optimization for Android

00:00

Formale Metadaten

Titel
Power optimization for Android
Serientitel
Anzahl der Teile
46
Autor
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Android devices running on battery need to be optimized for power. If just take a look on the CPU this optimization starts typically with the race to idle, meaning to go to finish the workload as fast as possible. However typical Android devices are running on a SoC with many parts included like CPU, GPU or Audio and Video decoder. All the parts need to be optimized to reduce the power consumption. The Android API provides a number of APIs to help with this and also a power profiling tool can help the developer to understand what hardware parts are active and where he needs to start optimization. In the session we will discuss typical causes of high power consumption, how to debug them and provide possible solutions.
18
ProgrammierungExpertensystemMereologieMultiplikationsoperatorTwitter <Softwareplattform>SoftwareentwicklerExpertensystemGoogolSoftwareentwicklerVorlesung/Konferenz
Komplexes SystemLeistung <Physik>MultiplikationsoperatorGlobale OptimierungLeistung <Physik>Humanoider RoboterComputeranimationBesprechung/Interview
HardwareMaschinenschreibenProgrammierungGrenzschichtablösungBildschirmmaskeLeistung <Physik>DatensichtgerätInformationsspeicherungUmwandlungsenthalpieDifferenteNeuroinformatikBefehlsprozessorEinfach zusammenhängender RaumKomplex <Algebra>Physikalisches SystemDatensichtgerätCASE <Informatik>Ein-AusgabeInformationsspeicherungKanalkapazitätGraphikprozessorHumanoider RoboterComputeranimation
SoftwareLeistung <Physik>Physikalisches SystemSoftwareentwicklerBesprechung/Interview
Gesetz <Physik>TouchscreenMultiplikationsoperatorMooresches GesetzHumanoider RoboterVorlesung/KonferenzBesprechung/Interview
ComputerspielNatürliche ZahlMAPGlobale OptimierungBefehlsprozessorLeistung <Physik>Kartesische KoordinatenMultiplikationsoperatorDienst <Informatik>NetzbetriebssystemApp <Programm>Konforme AbbildungLeistung <Physik>Physikalisches SystemProjektive EbeneOvalHypermediaKartesische KoordinatenMapping <Computergraphik>Computeranimation
Globale OptimierungProjektive EbeneKernel <Informatik>Framework <Informatik>Humanoider RoboterSoftwareentwicklerBesprechung/Interview
Kartesische KoordinatenVorlesung/KonferenzBesprechung/Interview
CodeDatenstrukturSoftwareArithmetisches MittelLeistung <Physik>WärmeübergangZahlenbereichCoxeter-GruppeVererbungshierarchieAutomatische DifferentiationPixelKartesische KoordinatenSystemplattformTouchscreenObjekt <Kategorie>MultiplikationsoperatorURLEinsCodeDatenstrukturSoftwareSynchronisierungAnalytische MengeLokales MinimumWärmeübergangDatensichtgerätRandomisierungBitrateURLMapping <Computergraphik>Computeranimation
DatenerfassungHardwareSoftwareBitLeistung <Physik>MereologieZahlenbereichGüte der AnpassungZusammenhängender GraphKartesische KoordinatenMultiplikationsoperatorDienst <Informatik>SoftwareentwicklerApp <Programm>RelativitätstheorieSoftwareDigitale SignalverarbeitungAggregatzustandLeistung <Physik>MultiplikationPhysikalisches SystemZahlenbereichEinflussgrößeZusammenhängender GraphApp <Programm>ComputeranimationVorlesung/Konferenz
MereologieZahlenbereichProzess <Informatik>SystemplattformEnergiedichteVorlesung/KonferenzBesprechung/Interview
MereologieOpen SourceSystemplattformSoftwareentwicklerHardwareInformationStatistikProfil <Aerodynamik>BefehlsprozessorIntelMereologiePhysikalisches SystemSpeicherabzugEnergiedichteNabel <Mathematik>Kernel <Informatik>BimodulSkriptspracheQuellcodeUniversal product codeGraphikprozessorInterrupt <Informatik>SoftwareentwicklerComputeranimation
BitMereologieProgrammfehlerKartesische KoordinatenSkriptspracheVerkehrsinformationGoogolHumanoider RoboterVorlesung/KonferenzBesprechung/Interview
Physikalisches SystemProgrammfehlerSkriptspracheVerkehrsinformationApp <Programm>StatistikSpeicherabzugNabel <Mathematik>SkriptspracheComputeranimation
ProgrammbibliothekAlgebraisch abgeschlossener KörperCompilerMetrisches SystemStellenringVersionsverwaltungServerInternetworkingKartesische KoordinatenSkriptspracheDemo <Programm>BenutzerbeteiligungAlgebraisch abgeschlossener KörperCompilerGeradeStellenringServerInternetworkingSchraubenlinieComputeranimationVorlesung/Konferenz
BildschirmfensterServerSkriptspracheElektronischer ProgrammführerBenutzerbeteiligungHumanoider RoboterVorlesung/Konferenz
BildschirmfensterBefehlsprozessorMereologieRechenschieberServerProgrammfehlerCoxeter-GruppeDatentransferKartesische KoordinatenMailing-ListeVerkehrsinformationBitrateTouchscreenObjekt <Kategorie>MultiplikationsoperatorDienst <Informatik>BenutzerbeteiligungDatenverwaltungSimulationGebäude <Mathematik>SynchronisierungGeradeHill-DifferentialgleichungLokales MinimumPhysikalisches SystemMenütechnikProzess <Informatik>VierRankingSpezielle unitäre GruppeKartesische KoordinatenGoogolElektronische PublikationSCI <Informatik>TouchscreenMultiplikationsoperatorCase-ModdingDemo <Programm>PortscannerComputeranimationVorlesung/KonferenzBesprechung/Interview
CodeStatistikSynchronisierungBefehlsprozessorMereologieZahlenbereichProzess <Informatik>Kartesische KoordinatenService providerVerkehrsinformationMultiplikationsoperatorZweiDienst <Informatik>App <Programm>CodeInformationSoftwareSynchronisierungPhasenumwandlungAlgebraisch abgeschlossener KörperMarketinginformationssystemCompilerGeradeInhalt <Mathematik>IntelSinusfunktionStellenringTUNIS <Programm>WärmeübergangZahlenbereichServerInternetworkingProzess <Informatik>Dämon <Informatik>Kartesische KoordinatenService providerBimodulSCI <Informatik>Trennschärfe <Statistik>Dienst <Informatik>Humanoider RoboterMobiles InternetURNComputeranimation
SoftwareModemAggregatzustandMultiplikationsoperatorApp <Programm>SoftwareGlobale OptimierungSystemaufrufVorlesung/KonferenzBesprechung/Interview
ModemAggregatzustandLeistung <Physik>WärmeübergangCASE <Informatik>ATMService providerMultiplikationsoperatorZweiDatumsgrenzeDatenverwaltungSoftwareSynchronisierungPhysikalischer EffektEinfach zusammenhängender RaumSchedulingSystemaufrufInternetworkingSchnittmengeGoogolDienst <Informatik>App <Programm>Computeranimation
DatenverwaltungModemLeistung <Physik>Kartesische KoordinatenSystemplattformMultiplikationsoperatorApp <Programm>Besprechung/Interview
DatenverwaltungMAPAnpassung <Mathematik>SystemplattformMultiplikationsoperatorGlobale OptimierungVorlesung/KonferenzBesprechung/Interview
SoftwareBildschirmfensterSynchronisierungPhysikalisches SystemGüte der AnpassungAnpassung <Mathematik>SchnittmengeUmwandlungsenthalpieMultiplikationsoperatorHumanoider RoboterDatenverwaltungSoftwareSynchronisierungPhysikalischer EffektEinfach zusammenhängender RaumSchedulingSystemaufrufInternetworkingSchnittmengeGoogolDienst <Informatik>App <Programm>Computeranimation
Leistung <Physik>NetzwerkverwaltungDatentransferSoftwareVorlesung/Konferenz
CodeDatenstrukturProfil <Aerodynamik>Globale OptimierungAggregatzustandInnere EnergieLeistung <Physik>Lokales MinimumMereologiePhysikalisches SystemStellenringTabelleStapeldateiCASE <Informatik>DatentransferService providerMultiplikationsoperatorZweiCachingApp <Programm>AlgorithmusDatenverwaltungHardwareSoftwareProfil <Aerodynamik>VideokonferenzGlobale OptimierungBefehlsprozessorEinfach zusammenhängender RaumLeistung <Physik>Lokales MinimumPhysikalisches SystemSchedulingStellenringWärmeübergangStapeldateiSystemaufrufEinflussgrößeZusammenhängender GraphEnergiedichteGoogolMixed RealityKontextbezogenes SystemURLCachingDatumsgrenzeMusterspracheHumanoider RoboterComputeranimation
VideokonferenzVerschlingungVorlesung/Konferenz
Coxeter-GruppeVorlesung/Konferenz
Transkript: English(automatisch erzeugt)
Thanks for the introduction. So, hi everyone. I'm Cyril Xavier. He's already said everything. If you want my Twitter handle, it's right here. I'm also part of the Google Developer Experts program from Google. So that doesn't mean I've actually sold my soul to Google.
I'm not speaking in Google's name, but it's a really cool program from Google that allows me to speak at such conferences and recognize our expertise. So you also have some of our Google Developer Experts here. I see actually one here. He doesn't want to be named yet. It's morning for him.
So how about pro-optimization? So here's a short agenda. I mean, we've got 20 minutes, so enough time to read it. First time you need to understand how your devices are consuming power. And so today's Android devices are really complex systems.
They are not like a simple big computer. You just run a program on it. It's alone on it. I mean, there is barely an OS. Now here with Android, you've got display into devices, sensors, touch screens,
several layers of connectivity, 3G, 4G, Wi-Fi, Bluetooth. You've got cameras. You've got CPU, GPU, and RAM as usual. And you also have different forms of storage. And you have hardware decoders, and you have specific power subsystems, so battery and charging system.
So it's not as easy as it could be to understand what is happening on your device and what is actually consuming power. And it's even harder to see what software is actually causing power consumption. But battery life is really one of the main complaints from users,
as said here, but it's a complaint for everyone, developers too. And so we need to do things for it, and it's complicated to see what we should do. And plus, we always want better devices that runs faster, with a brighter screen.
Basically, we want better battery, but we want to ruin the battery life at the same time by wanting thinner devices. That's just crazy. And no one could apply Moore's law to battery capacity yet. Far from it. The only law we managed to get into battery is like, yeah, make larger batteries.
That's why we invented 6-inch phones, just to fit a bigger battery and keep it thinner. So there is already a lot of power optimization done at the operating system level.
So if you look at the application's life cycle, if your application is not in the foreground, it will be paused. You can still have background services. And then in background services, you need to acquire wake locks, so to be able to use the CPU for a long time, even if your app isn't used.
So that already saves battery, because not all your apps are running at the same time by nature. There are already also initiatives from Google, so they called Project Volta. They mentioned it at least one year ago. So, battery optimization for the Android developers at Google, it's Project Volta.
That means it's not just something you would put on top of Android and that would fix all the things. It's really a project that needs to work across all the ecosystem of what Android is.
So the framework needs to be optimized, the kernel needs to be optimized. And finally, all this isn't enough. Applications have to be optimized too. And you can always find an application that will ruin the whole experience you have on your device. I will not tell any name.
So applications have to be optimized for power as well. But what's using power? Of course, the screen is using power, but there isn't much things you can do about it. There are technologies like OLED that allows only the pixels you use to be lightened up.
But in any case, that's not really on the application side that you can fix a lot there. I'll try to find some numbers. I think it can vary between devices and so on, but still gives you a rough idea.
Usually what consumes the most is network. So anytime you transfer data or big chunks or not, if it's just for ads or even analytics, in any case, all this is consuming power. Then goes location and sensors, of course.
Obvious when you use the GPS, it consumes power. If you use some sensors, some sensors are consuming more power than others. I'll tell you which ones later in this presentation. And lastly, CPU is consuming power. But it's really not as much as network or other stuff.
It's less important, but still. So to optimize on the CPU side, your code has to be more efficient. And to do some actual useful work, like avoid to copy and sort ten times the same structures. It's not good.
So you can also fix what you're doing on the CPU side. Even if your code is beautiful, that doesn't mean it will necessarily work well on the platforms. That's quite a sad story, actually. That's why on Android, for example, when you're optimized, you don't have big object-oriented aberrations with seven inheritance on the object and so on.
You need to keep things simple. But if you want to optimize, you need to measure first. So you can measure with wall plug.
Now, in fact, you can't really do that with an Android device. Hardware data acquisition on power is just complicated, expensive, and plus, we're software developers. How can we know what exact part of our software is actually using the power
if we are just measuring the throughput on the board? It's really hard. But luckily, we've got good software solutions. It's a bit indirect, so it's really hard to get actual power consumption numbers. But honestly, you don't really need these numbers. You need to monitor many components.
So what's going on on the CPU, what's going on on kernel, the interrupts, so on. And what your app is doing at the same time. So when you do measurements, you measure on the actual device with over apps on it. At least the frameworks, apps, and so on.
So when your applications are not sitting alone on Android devices, they are integrated with the system, you've got content providers, you've got service running in background, you've got a lot of stuff going on. Plus, over apps also using the device and may impact how your applications perform.
So actual numbers are hard to get, but you can always go and optimize and see what you are doing wrong using tools. So of course at Intel we've got some cool tools. They are mainly targeting OEMs. One is Intel Energy Profiler. So it allows you to see what process is using what part of the platform.
It's part of Intel System Studio. It's not free for everyone. For open source projects, usually it's okay. For academic research, usually it's okay. In any case, you need specific devices. You can rebuild the OS 4 or simply Intel development platforms.
You also get other tools. So the most useful tool has been released with Lollipop. It's called Battery Historian. Who used Battery Historian in the room once? Not many. That's a shame. Because you should really use it at least once with your applications.
That's the tool that allows you to understand that your application is doing something that is wrong. So one year ago it was released 1.0. And it's maybe not well known because there have been not that many advertisements on it.
So if you look, it's not part of Android Studio itself or whatsoever. It's on Google's GitHub account. And in 1.0 release it was just a Python script. No README. So maybe that's why you didn't use it. It was maybe a little bit too minimalistic. In any case, to use Battery Historian, you just get a bug report from your device using ADB bug report.
So after you run your app on your device for like some time, 30 minutes, 1 hour, 3 hours for us to see how it interacts with the system. And then you run the Python script giving your bug report and it will generate an HTML report.
You can see one on the right side. Anyway, last week, because Google IO, there is a 2.0 version. Big improvement. They put a README. And however, it's not just a Python script anymore. It has dependency on Go, Python, Git, Closure Compiler and basically the internet.
Because yes, it creates a local web server but you need access to resources that are remote like jQuery and many libs. So yeah, it's a bit painful to install all of it but it's worth the pain.
Because from previous Battery Historian, the metrics are easier to read. You can filter on your application which is more than useful. And let's do a quick demo. So get a script to launch the web server, actual web server.
It should pop up soon-ish. In the meantime, who is using Windows here in the room for Android development? Quite many people. So they released the Getting Started Guide only for Linux. And you have to do some fix to make it work on Windows.
I'll publish a post later and I'll include a slide at the end of my presentation to tell you how you can install it and run it on Windows. It's not that complicated. So here's the web server. So we can upload a bug report.
Add submit. And here's Battery Historian. So it will give you stats on the overall behavior of your device. On that time, it has been running. It was sleeping.
It has been charging, discharging. What consumes the most? Wi-Fi, screen and so on. A list of wake locks from various applications. And the most interesting part of course is Historian 2.0. So it's much better than the previous Battery Historian if you used it.
So you see the rate of discharging of your device over time. So if it's changing at one point, you can look down and to see what was running. If it was because of CPU use or maybe the screen was on or Wi-Fi was on or reception was bad, you can see our signal strength.
So if you're in an area, you're always switching between 3G and GSM. It just ruins the battery life. You can't do much about it. And you can see the list of wake locks at any time.
So wake locks are objects applications and services are using to keep the CPU awake to do some work while the user is actually not using your application. So that's what basically ruins battery life along with all the data transfers. And then you can go on application statistics and then you need to choose an application.
I need to decide again which one I want to show. So there is an app for example. I hope Siri who developed the app will not blame me for choosing him. So we can see how much data has been transferred by the app over the time it has been used.
How many times it requested syncs, so using a sync provider. So two times and it lasted seven seconds, which is quite much actually seven seconds. And you see all the wake locks when they've been acquired and the duration of them.
So it kept the CPU awake for like nine milliseconds sometimes, hundred milliseconds over time. And the sync part was the most battery consuming part with more than two seconds. That's quite alright but the sync could be improved.
And you see the services and finally the processes. So if any number here goes too big, that means there is a problem here. But here it's quite fine. It's very good to have such an overview from the report of the amount of data that is transferred and so on.
Anyway, we go back to it. So I invite you really to use it on your app at least once to get an idea of what's going on with your app. Because it's not just by looking at your code that you can guess what's happening and if it's problematic for battery life.
Anyway, so you should get an overview of your app and so on. But what wrong stuff have you done so it consumes battery? So first of all you need to understand how the network layer works on Android, especially on 3G and 4G.
So for example on 3G and 4G, each time you do a request, like I want data, then the modem of your phone will go in a high state. Do a transfer and once the transfer is done it will not go to idle instantaneously.
It will wait just in case. And it doesn't matter if your transfer was huge or just small. In any case it will have put the modem into high power state and it will stay in still quite high power state
for at least 15 seconds and maybe more. It depends on the providers. And that's a lot to keep your device modem awake because it consumes at least 10 times the power it needs when it's in idle mode. Even more than that.
So it's like sleep deprivation. If you wake up every 10 minutes as a human, you'll become crazy quite quick. And yeah, you need to really have a good sleep some day. So the things you can use on your apps to avoid waking up the old platforms just for one small packet all the time
and cause a sleep deprivation are first of all alarm manager. So if you just set an alarm now if you're targeting OS later than KitKat, that's okay, your timer will be aligned with other timers from other applications.
So it will naturally optimize so it will coalesce the timers so it will consume less power. Because all the apps will get the data at the same time. So the useless idle time from the modem will be shorter. It will happen less times, less often.
On alarm manager you can also set inexact repeating, so the same. Since it's inexact, it will again be able to be aligned with other timers from other platforms. And this API has been available for a long time. I don't remember the exact API level but should be able to use it.
You can also use sync adapters. So sync adapters are Android specific sync adapters and they are woken up by the system. They can be woken up by the system so the system will choose to wake these up at the right time. And there is even better that you can use, it's the JobScheduler. So JobScheduler API is only available starting with Lollipop.
But it allows you to do really good things for battery because you can set an alarm. But you can ask for this alarm to require charging. So it's just awesome to be able to do work only when the device is actually plugged into anywhere.
You can set request idols also on network or also an ejection window. And if you want to use JobScheduler style API from before, API Lovet 21, you can use GCM network manager that provides fallback.
There is GCM in the name but it doesn't require GCM. It only requires Google Play Services. Anyway, overall there is a chart of how much power is consumed by data transfers. And it depends on the technologies and also the amount of data.
But in any case it's better to prefetch to get maximum of data but still not too much from time to time than just asking for new data all the time. And yeah, batch data transfers as much as you can. And if you can schedule all your work at times, the device is just sitting up on the table plugged in.
That's perfect. I'll just go slightly faster. We'll be late. So for sensors, try not to use them at their maximum. The gyroscope consumes like 10 times more power than the accelerometer. So prefer use of accelerometer if you can just use only an accelerometer.
Avoid using the GPS if you can afford it. So by, for example, using passive providers. So you'll get data used by other apps or network provider. And you can also disable receivers when you don't need them. So the system will be not woken up if no one is asking for some intent.
And finally to optimize CPU usage. So raise to idle is the main concept. So do a maximum of work and then go to idle. Don't do work like every second. And maximize data locality. So have efficient data structures to maximize cache locality.
Some of these things are hard to measure. But you can use, for example, vtune amplifier. That's also part of system studio. It's like an internal energy profiler. And it tells you what the CPU said about your code. Like, it sucks. I had to use so many clocks for executing instructions.
Because your data structures are wrong. You can use it this way. So I know you don't get that many magic APIs that will do all the work for you. But there is a battery historian you can use to really analyze what your app is doing on the system.
And the main concept with battery optimization is to batch when you can, to cache when you can, to avoid work when you can. That's also a good way to don't waste battery. And to optimize and schedule everything you do properly. So it's really a state of mind. So you need to think about the impact of battery when you do something.
And you need to measure it. So we have a link to battery historian tools. If you want more material, there is Colmack Enlis who is doing many videos. They're called Android Performance Patterns. So that's the guy here looking unhappy. It's because his device is depleted, I guess. So you can follow this link.
I don't speak German, but I think that means that the end of the presentation is overrated.
It didn't mean anything. Thank you. It was a little irritating and also annoying. I'm sorry about that.