性能优化之电量和网络

电量

电量的分析工具 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倍）、更为简单
  • 扩展性、兼容性好。你可以更新数据结构，而不影响和破坏原有的旧程序