ENERGY_GUIDE_DEV.md
1 --- 2 id: ENERGY_GUIDE_DEV 3 title: 4 sidebar_label: Energy Guide 5 --- 6 7 ## What impacts battery performance? 8 9 ### 1. CPU 10 That one is obvious, if the app consumes too much CPU, it won't be energy efficient. 11 12 Is's important to test this data *on a device*. 13 14 1. Desktop CPUs have different architecture and some algorithms that are hardware accelerated on a desktop-class CPU might cause bottlenecks in a mobile processor. 15 16 2. Mobile operating systems might have different syscalls implemented with different efficency. 17 18 Hence, everything should be profiled and optimized in an environment as close to what an end user will have. 19 20 **Instruments to triage CPU bottlenecks** 21 iOS: Instruments (Time Profiler) 22 23 ### 2. Networking 24 25 One important trick that allows devices to live that long from a battery is that they try to switch to a low-power mode as soon as it is possible. 26 27 That relates not only to CPU but also to the networking stack. Radios that are used in the wireless connections are very resource-hungry. To workaround that limitation, system tries to turn them on fully only when it absolutely has to. That is usually some timeout after the network packets were sent or received. 28 29 One important consequence of that fact is that if the packets are all sent and 30 received randomly, the radio will never have a chance to switch into a low 31 power mode. 32 33 To avoid that, networking should happen in "bursts", when during a short period of time a lots of packets are sent/received. 34 35  36 *source: [Apple: Energy & Networking](https://developer.apple.com/library/content/documentation/Performance/Conceptual/EnergyGuide-iOS/EnergyandNetworking.html)* 37 38 #### 2.1. Networking, Energy and open sockets. 39 If socket connection is open, but isn't active (no reads or writes happening) that doesn't prevent radios to go into a low-power mode. 40 Even if there is a read operation from a socket, if a server doesn't write anything, it still helps with energy preservation. 41 That way, by grouping socket messages, we can improve the battery performance. 42 43 *The way how energy efficient networking can be controlled by a server* 44 45 Client code (no specific optimizations) 46 ```go 47 for { 48 tcpAddr, _ := net.ResolveTCPAddr("tcp4", address) 49 conn, _ := net.DialTCP("tcp", nil, tcpAddr) 50 for { 51 result := make([]byte, 10) 52 io.ReadFull(conn, result) 53 fmt.Println(string(result)) 54 } 55 } 56 57 ``` 58 59 Server code (energy efficient). 60 61 ```python 62 import socket 63 import time 64 import sys 65 66 TCP_IP = '0.0.0.0' 67 TCP_PORT = 5008 68 MESSAGE = "1234567890" 69 70 BUFFER_SIZE = 20 # Normally 1024, but we want fast response 71 72 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 73 s.bind((TCP_IP, TCP_PORT)) 74 s.listen(1) 75 76 conn, addr = s.accept() 77 print 'Connection address:', addr 78 try: 79 while 1: 80 print 'Sending', MESSAGE 81 for i in range(500): 82 conn.send(MESSAGE) 83 print "sleeping" 84 for i in range(30): 85 print i, 86 sys.stdout.flush() 87 time.sleep(1) # seconds 88 finally: 89 conn.close() 90 print 'Closed' 91 ``` 92 93 #### 2.2 The Tradeoff 94 95 There is a tradeoff between having energy efficient networking and real-time communications. The time that is needed for the radio to go to the low-power mode is quite substantal (>= 10 seconds). That can easily be seen in "overhead" graph in Xcode. 96 That rate means that any app that requires real-time communication (a messsenger) will not be energy efficient in foreground. 97 98 What is possible to do, is to reduce energy consumption is background. There, we can sync data more rarely, or only by a signal of a silent push notification. 99 100 101 102 103 **Instruments to triage networking issues** 104 105 iOS: Xcode (Energy Efficiency, Network), Instruments (Network) 106 107 Android: TBD 108 109 110 111 112 ## Profiling Process: iOS 113 114 **‼️** Instrument's "Energy Usage Log" [**seems to be broken** on iOS 10/11](https://forums.developer.apple.com/thread/70540) **‼️** 115 116 1. Profiling should happen using Wi-Fi debugging feature. 117 Otherwise, the device will be charging during the measuring process and that will skew the data. 118 119 2. Profiling should happen only on a device. 120 121 3. Profiling should happen on a **release** build configuration. 122 Different debugging mechanisms can add much additional overhead, hiding the 123 actual reasons on why something isn't efficient. 124 125 #### Tools 126 **Xcode: Debug Navigator** 127  128 129 What is "Overhead"? That is energy impact of "other system resources". 130 An example of that is a radio that is in high-power mode after networking data exchange. 131 132 **Instruments: Time Profiler, Network** 133 134 135 136 137 138 139 ## Profiling Process: Android 140 141 TBD 142 143 144 145 146 # Read further 147 148 ## iOS 149 150 151 - [Energy Efficiency Guide for iOS Apps](https://developer.apple.com/library/content/documentation/Performance/Conceptual/EnergyGuide-iOS/index.html#//apple_ref/doc/uid/TP40015243-CH3-SW1) 152 153 - WWDC sessions 154 - 2017: 238 155 - 2015: 708 156 - 2014: 710, 712