性能优化之电量和网络

电量

电量的分析工具 energy profiler

使用 Android 8.0 及以上版本的设备时，使用Energy Profiler 可以了解应用在哪里耗用了不必要的电量。 Energy Profiler 会监控 CPU、网络无线装置和 GPS 传感器的使用情况，并直观地显示其中每个组件消耗的电量。还会显示可能会影响耗电量的系统事件（唤醒锁定、闹钟、作业和位置信息请求）的发生次数
使用Profile 运行App。

下面红框的时间段,我打开了定位功能的页面,就显示除了location高亮

可以选择这段定位的区域,进行分析

上面的系统事件说明：

**WakeLock（唤醒锁定）：**是一种机制，可在设备进入休眠模式时使 CPU或屏幕保持开启状态。例如，播放视频的应用可以使用唤醒锁定，以便在用户未与设备交互时使屏幕保持开启状态。请求唤醒锁定不是一项耗电量很高的操作，但未撤消唤醒锁定会导致屏幕或CPU 保持开启状态的时间超过必要时间，从而加快电池耗电速度。
**Alarms（闹钟）：**您可以使用闹钟定期在应用上下文之外运行后台任务。当闹钟触发时，它可能会唤醒设备并运行耗电量很高的代码。
**Jobs（作业）：**您可以使用作业在指定条件下（例如恢复网络连接时）执行相关操作。您可以使用 JobBuilder 创建作业，并使用JobScheduler 对这些作业进行调度。在许多情况下，建议您使用 JobScheduler对作业进行调度，而不是使用闹钟或唤醒锁定。
**Location（位置）：**位置信息请求使用 GPS 传感器，这会消耗大量电量。

电量的优化

电池续航时间是移动用户体验中最重要的一个方面。没电的设备完全无法使用。因此，对于应用来说，尽可能地考虑电池续航时间是至关重要的。在我们开发时对于单个APP应该注意能够：

**减少操作：**您的应用是否存在可删减的多余操作？例如，是否可以缓存已下载的数据，而不是每次重新下载数据？
**推迟操作：**应用是否需要立即执行某项操作？例如，是否可以等到设备充电后或者Wifi连接时（通常情况下使用移动网络要比WIFI更耗电）再将数据备份到云端？
**合并操作：**工作是否可以批处理，而不是多次将设备置于活动状态？比如和服务器请求不同的接口获取数据，部分接口是否可以合并为一个？

监控电池电量和充电状态

为了减少电池续航被我们软件的影响，我们可以通过检查电池状态以及电量来判断是否进行某些操作。比如我们可以在充电时才进行一些数据上报之类的操作。

获取充电状态

IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
Intent batteryStatus = registerReceiver(null, ifilter);
// 是否正在充电
int status = batteryStatus.getIntExtra(BatteryManager.EXTRA_STATUS, -1);
boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || status == BatteryManager.BATTERY_STATUS_FULL;
// 什么方式充电？
int chargePlug = batteryStatus.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1);
//usb
boolean usbCharge = chargePlug == BatteryManager.BATTERY_PLUGGED_USB;
//充电器
boolean acCharge = chargePlug == BatteryManager.BATTERY_PLUGGED_AC;
Log.e(TAG, "isCharging: " + isCharging + " usbCharge: " + usbCharge + " acCharge:" + acCharge);

监控充电状态变化

//注册广播
IntentFilter ifilter = new IntentFilter();
//充电状态
ifilter.addAction(Intent.ACTION_POWER_CONNECTED);
ifilter.addAction(Intent.ACTION_POWER_DISCONNECTED);
//电量显著变化
ifilter.addAction(Intent.ACTION_BATTERY_LOW);
//电量不足
ifilter.addAction(Intent.ACTION_BATTERY_OKAY);
//电量从低变回高
powerConnectionReceiver = new PowerConnectionReceiver();
registerReceiver(powerConnectionReceiver, ifilter);public class PowerConnectionReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if(intent.getAction().equals(Intent.ACTION_POWER_CONNECTED)) { Toast.makeText(context, "充电状态：CONNECTED", Toast.LENGTH_SHORT).show(); } else if (intent.getAction().equals(Intent.ACTION_POWER_DISCONNECTED)) { Toast.makeText(context, "充电状态：DISCONNECTED", Toast.LENGTH_SHORT).show(); } else if (intent.getAction().equals(Intent.ACTION_BATTERY_LOW)) {Toast.makeText(context, "电量过低", Toast.LENGTH_SHORT).show(); } else if (intent.getAction().equals(Intent.ACTION_BATTERY_OKAY)) { Toast.makeText(context, "电量从低变回高", Toast.LENGTH_SHORT).show(); }}
}

WorkManager

如果设备在 API 级别 23 或更高级别上运行，系统会使用 JobScheduler。在 API 级别 14-22 上，系统会使用GcmNetworkManager（如果可用），否则会使用自定义 AlarmManager 和 BroadcastReciever 实现作为备用。

Constraints constraints = new Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) //Wi-Fi  .setRequiresCharging(true) //在设备充电时运行 .setRequiresBatteryNotLow(true) //电量不足不会运行 .build();
OneTimeWorkRequest uploadWorkRequest = new OneTimeWorkRequest.Builder(UploadWorker.class) .setConstraints(constraints) .build();
WorkManager.getInstance(this) .enqueueUniqueWork("upload", ExistingWorkPolicy.KEEP,uploadWorkRequest);

网络优化

正常一条网络请求需要经过的流程是这样：

DNS 解析，请求DNS服务器，获取域名对应的 IP 地址；
与服务端建立连接，包括 tcp 三次握手，安全协议同步流程；
连接建立完成，发送和接收数据，解码数据。

这里有明显的三个优化点：

直接使用 IP 地址，去除 DNS 解析步骤；
不要每次请求都重新建立连接，复用连接或一直使用同一条连接(长连接)；
压缩数据，减小传输的数据大小。

DNS 优化

DNS（Domain Name System），它的作用是根据域名查出IP地址，它是HTTP协议的前提，只有将域名正确的解析成IP地址后，后面的HTTP流程才能进行。
DNS 完整的解析流程很长，会先从本地系统缓存取，若没有就到最近的 DNS 服务器取，若没有再到主域名服务器取，每一层都有缓存，但为了域名解析的实时性，每一层缓存都有过期时间。
传统的DNS解析机制有几个缺点：

缓存时间设置得长，域名更新不及时，设置得短，大量 DNS 解析请求影响请求速度；
域名劫持，容易被中间人攻击，或被运营商劫持，把域名解析到第三方 IP 地址，据统计劫持率会达到7%；
DNS 解析过程不受控制，无法保证解析到最快的IP；一次请求只能解析一个域名。

为了解决这些问题，就有了 HTTPDNS，原理很简单，就是自己做域名解析的工作，通过 HTTP 请求后台去拿到域名对应的 IP 地址，直接解决上述所有问题。
HTTPDNS的好处总结就是：

Local DNS 劫持：由于 HttpDns 是通过 IP 直接请求 HTTP 获取服务器 A记录地址，不存在向本地运营商询问domain 解析过程，所以从根本避免了劫持问题。
DNS 解析由自己控制，可以确保根据用户所在地返回就近的 IP 地址，或根据客户端测速结果使用速度最快的 IP；
一次请求可以解析多个域名。

HTTPDNS 几乎成为中大型 APP 的标配。解决了第一个问题， DNS 解析耗时的问题，顺便把DNS 劫持也解决了。
httpdns

连接优化

第二个问题，连接建立耗时的问题，这里主要的优化思路是复用连接，不用每次请求都重新建立连接，如何更有效率地复用连接，可以说是网络请求速度优化里最主要的点了。
【keep-alive】： HTTP 协议里有个 keep-alive，HTTP1.1默认开启，一定程度上缓解了每次请求都要进行TCP三次握手建立连接的耗时。原理是请求完成后不立即释放连接，而是放入连接池中，若这时有另一个请求要发出，请求的域名和端口是一样的，就直接拿出连接池中的连接进行发送和接收数据，少了建立连接的耗时。实际上现在无论是客户端还是浏览器都默认开启了keep-alive，对同个域名不会再有每发一个请求就进行一次建连的情况，纯短连接已经不存在了。
但有 keep-alive 的连接一次只能发送接收一个请求，在上一个请求处理完成之前，无法接受新的请求。若同时发起多个请求，就有两种情况：

若串行发送请求，可以一直复用一个连接，但速度很慢，每个请求都要等待上个请求完成再进行发送。
若并行发送请求，那么只能每个请求都要进行tcp三次握手建立新的连接

对并行请求的问题，新一代协议 HTTP2 提出了多路复用去解决。 HTTP2 的多路复用机制一样是复用连接，但它复用的这条连接支持同时处理多条请求，所有请求都可以并发在这条连接上进行，也就解决了上面说的并发请求需要建立多条连接带来的问题。

多路复用把在连接里传输的数据都封装成一个个stream，每个stream都有标识，stream的发送和接收可以是乱序的，不依赖顺序，也就不会有阻塞的问题，接收端可以根据stream的标识去区分属于哪个请求，再进行数据拼接，得到最终数据。
Android 的开源网络库OKhttp默认就会开启 keep-alive ，并且在Okhttp3以上版本也支持了 HTTP2。

数据压缩

第三个问题，传输数据大小的问题。数据对请求速度的影响分两方面，一是压缩率，二是解压序列化反序列化的速度。目前最流行的两种数据格式是 json 和 protobuf，json 是字符串，protobuf 是二进制，即使用各种压缩算法压缩后，protobuf 仍会比 json 小，数据量上 protobuf 有优势，序列化速度 protobuf 也有一些优势。

protobuf

除了选择不同的序列化方式（数据格式）之外，Http可以对内容（也就是body部分）进行编码，可以采用gzip这样的编码，从而达到压缩的目的。在OKhttp的 BridgeInterceptor 中会自动为我们开启gzip解压的支持。

boolean transparentGzip = false;
if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) { transparentGzip = true; requestBuilder.header("Accept-Encoding", "gzip");
}

如果服务器响应头存在： Content-Encodin:gzip

//服务器响应 Content-Encodin:gzip 并且有响应body数据
if (transparentGzip && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding")) && HttpHeaders.hasBody(networkResponse)) { GzipSource responseBody = new GzipSource(networkResponse.body().source()); Headers strippedHeaders = networkResponse.headers().newBuilder().removeAll("Content-Encoding") .removeAll("Content-Length") .build(); responseBuilder.headers(strippedHeaders); String contentType = networkResponse.header("Content-          Type"); responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody)));
}

客户端也可以发送压缩数据给服务端，通过代码将请求数据压缩，并在请求中加入 Content-Encodin:gzip 即可。

private RequestBody gzip(final RequestBody body) {
return new RequestBody() { @Override public MediaType contentType() { return body.contentType(); }@Override public long contentLength() { return -1; // We don't know the compressed length in advance! } @Override public void writeTo(BufferedSink sink) throws IOException { BufferedSink gzipSink = Okio.buffer(new GzipSink(sink)); body.writeTo(gzipSink); gzipSink.close(); }
};public RequestBody getGzipRequest(String body) { RequestBody request = null; try {request = RequestBody.create( MediaType.parse("application/octet-stream"),compress(body) ); } catch (IOException e) {e.printStackTrace(); }return request;
}

其他

1、使用webp代替png/jpg
2、不同网络的不同图片下发，如（对于原图是300x300的图片）：
2/3G使用低清晰度图片：使用100X100的图片;
4G再判断信号强度为强则使用使用300X300的图片，为中等则使用200x200，信号弱则使用100x100图片;
WiFi网络：直接下发300X300的图片
3、http开启缓存 / 首页数据加入缓存

总结:

使用protobuf替换json,需要后端也使用protobuf;同时替换的工作量有点大
对数据进行压缩

protobuf

Protobuf是一种平台无关、语言无关、可扩展且轻便高效的序列化数据结构的协议，可以用于网络通信和数据存储。可简单类比于 XML ，其具有以下特点：

语言无关、平台无关。即 ProtoBuf 支持 Java、C++、Python 等多种语言，支持多个平台
高效。即比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更为简单
扩展性、兼容性好。你可以更新数据结构，而不影响和破坏原有的旧程序