计算性能优化参考
- 低效率函数
第1种是相对执行时间长的方法，我们可以很轻松的找到这些方法并做一定的优化。第2种是执行时间短，但是执行频次很高的方法，因为执行次数多，累积效应下就会对性能产生很大的影响
- 计算性能优化
(1). 批处理与缓存
(2). 异步操作
(3). 容器性能
(4). 数据结构
电量优化
- 电量消耗分析：
Battery Historian(电量使用记录分析工具)
- 电量优化的一些建议：
- 充电时执行任务
- 连接wifi后执行任务
- wake_lock
- 大量高频次的CPU唤醒及操作集中处理
- 定位
- 网络优化
网络优化
- 网络分析工具
Network Monitor(网络监控工具)
代理工具（Fiddler）,分析网络请求
模拟弱网（使用Fiddler）
- 网络优化方案
（一）任务集中处理（使用JobScheduler）
（二）传输数据优化
- gzip压缩
static class GzipRequestInterceptor implements Interceptor {
@Override
public Response intercept(Chain chain) throws IOException {
okhttp3.Request originalRequest = chain.request();
if (originalRequest.body() == null || originalRequest.header("Content-Encoding") != null) {
return chain.proceed(originalRequest);
}
okhttp3.Request compressedRequest = originalRequest.newBuilder()
.header("Content-Encoding", "gzip")
.method(originalRequest.method(), gzip(originalRequest.body()))
.build();
return chain.proceed(compressedRequest);
}
private RequestBody gzip(final okhttp3.RequestBody body) {
return new RequestBody() {
@Override
public MediaType contentType() {
return body.contentType();
}
@Override
public long contentLength() {
return -1; // 无法知道压缩后的数据大小
}
@Override
public void writeTo(BufferedSink sink) throws IOException {
BufferedSink gzipSink = Okio.buffer(new GzipSink(sink));
body.writeTo(gzipSink);
gzipSink.close();
}
};
}
}
> > 2. 代替JSON（使用Protocal Buffers，Nano-Proto-Buffers，FlatBuffer来减小序列化的数据的大小
）
- 缓存
- 图片压缩
(三)不同网络状况，处理不同的任务
(四)弱网情况下我们应该做些什么？
(1).压缩/减少数据传输量
(2).利用缓存减少网络传输
(3).针对弱网(移动网络), 不自动加载图片
(4).界面先反馈, 请求延迟提交****
数据传输优化
序列化、反序列化传输
- Parcelable相对于Serializable效率要高
- GSON处理序列化问题，速度更快
可优化的数据序列化方案：
Protocal Buffers：强大，灵活，但是对内存的消耗会比较大，并不是移动终端上的最佳选择。
Nano-Proto-Buffers：基于Protocal，为移动终端做了特殊的优化，代码执行效率更高，内存使用效率更佳。
FlatBuffers：这个开源库最开始是由Google研发的，专注于提供更优秀的性能。
启动优化
- APP的启动方式：
(1). 冷启动（应用从桌面上启动，且后台没有进程的缓存，这是系统就需要新创建一个进程并且分配资源。）
(2). 热启动 （app在后台有进程缓存）
- 查看启动过程消耗时间的工具
- Loacat输出的display time
- Traceview
- adb shell
- 启动优化方案
流程中很多步骤是系统控制的，我们能够控制的和关注的点有以下几个：
(1).Application的onCreate,一般应用中通用主件和初始化都放在这里(耗时主因)
(2).Activity的onCreate，UI布局和渲染(耗时主因)
(3).显示启动窗口到窗口替换之间，会出现白屏的过度画面，体验太差（视主题而定，必须优化）
**(1).Application中初始化优化的方案有两种**
- 不需要立刻初始化的，延迟加载
- 需要初始化的，开启线程初始化
**(2).Activity的onCreate中优化**
- 优化布局耗时：一个布局层级越深，里面包含需要加载的元素越多，就会耗费更多的初始化时间。关于布局性能的优化，在渲染优化的文章中已经讲过。
- 异步延迟加载：一开始只初始化最需要的布局，异步加载图片，非立即需要的组件可以做延迟加载。
- 预加载：在前一个显示时预加载下一个显示页面中需要用到的数据（常常用到Spalsh调整主页面时使用）
包体优化
- 清理无用资源
(1).使用Refactor->Remove unused Resource
(2).使用Lint工具
(3).开启shrinkResources去除无用资源
(4).删除无用的语言资源
(5).清理第三方库中冗余代码
- 图片资源优化
(1)使用压缩过的图片
(2)只用一套图片
(3)使用不带alpha值的jpg图片
（4）使用tinypng有损压缩
（5）使用webp格式
（6）使用svg
（7）使用shape
（8）使用着色方案
（9）对打包后的图片进行压缩
- 资源动态加载
（1）在线化素材库
（2）动态加载皮肤
（3）插件化
-
lib库优化
只提供对主流架构的支持，比如arm，对于mips和x86架构可以考虑不支 持，这样可以大大减小APK的体积.
-
7zip压缩资源
对于assets或者raw文件夹中的资源，可以使用7zip压缩，使用时进行解压。
代码混淆
资源混淆
资源混淆简单来说希望实现将res/drawable/icon,png变成res/drawable/a.png,或我们甚至可以将文件路径也同时混淆，改成r/s/a.png。
建议使用微信的AndResGuard
- 使用微信AndResGuard
- Facebook的redex优化字节码
