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

1. Title:
   Network & Battery Drain
2. Description:

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