English subtitles

← Network & Battery Drain

Get Embed Code
13 Languages

Showing Revision 4 created 05/24/2016 by Udacity Robot.

  1. Let's take a moment to make
    something insanely clear.
  2. As far as battery is concerned,
  3. networking is the biggest, baddest,
    dirtiest offender that there is.
  4. Remember that inside of your phone
    is a small piece of hardware that's
  5. effectively a HAM radio,
    its whole purpose it to communicate with
  6. local cell phone towers and
    transmit data to them at high volumes.
  7. But the trick is that this chip,
    isn't always active, you see,
  8. once you send a packet of data the radio
    chip will stay on for a certain amount
  9. of time, just in case there's a response
    from the server that it's expecting.
  10. But if there's no activity, the hardware
    will shut down to save battery life.
  11. And as we've seen before, there's a
    large battery spike when this chip first
  12. turns on, and as long as it's
    keeping itself awake to wait for
  13. responses, it's going to keep on
    draining the battery at the same time.
  14. Now it's worth pointing out that there's
    two primary ways in which most apps
  15. interact with the radio.
  16. Firstly, there are events
    that need to occur right now.
  17. These events are the result
    of some user action, or
  18. they arise from the immediate need
    to update the UI of your app.
  19. For example, imagine when the user
    asks to load a new batch of tweets for
  20. a trending hashtag,
  21. since this is a user initiated action,
    your app should respond ASAP.
  22. On the other side of this coin are all
    the networking jobs that don't need
  23. to happen in a time critical manner for
    example, uploading user data,
  24. synchronizing background statistics, or
    re-sizing all of your social photos.
  25. So while the first set of tasks happen,
    has to happen immediately,
  26. in order to provide feedback to the
    user, the second set of tasks can easily
  27. be put off until later, when they can be
    performed in a battery efficient manner.
  28. And there's a high probability,
    that the majority of your
  29. network requests in your application
    fall into this second category.
  30. [LAUGH] Converting networking jobs
    over to being more efficient is
  31. a two step process.
  32. Firstly, take a hard look at the mobile
    radio row in your battery historian
  33. tool for your application.
  34. Each of those red bars that you see
    here represent an active mobile radio,
  35. any gaps between those bars
    represent when the radio is asleep.
  36. If you see lots of narrow bars and
  37. gaps in your graph, this can point to
    your performance problems, since it
  38. means that you're churning through
    lots of wake up and sleep cycles.
  39. What you want instead, is to see large
    gaps next to large blocks of activity.
  40. This way you've reduced overhead by
    minimizing the number of network
  41. requests, and even better,
    don't use the radio at all.
  42. I mean you can wait until
    the phone is connected to WiFi and
  43. then let the WiFi hardware do all this
    work with much less battery train.
  44. Now, the problem is that writing
    the code to batch, cache,
  45. and defer all these networking requests
    is really difficult to get right,
  46. which is why we've done the work for
  47. The JobScheduler API that rolled out
    with the L release of Android provides
  48. a full suite of API's that do all of
    this network request management work and
  49. more, on your behalf.
  50. But rather than telling you
    about this wonderful API,
  51. why don't you take a swing
    at it in practice?