Android 优化
一.启动优化
1.主题不启用透明背景(不然会有透明卡顿),设置背景图。
2.Appllication 中起启动服务来启动优化(将耗时和复杂的操作放到服务当中),保证onCreate()方法快速启动:
3.尽量使用热启动和温启动(8.0之前应用保活,9.0统统枪毙),和手机厂商谈才能做到,以后就是用dex分包,插件化,热启动。
Application启动
LuancherActivity 》 AMS(ActivityManganerServices) 》 Zygote (受精卵) 》 ActivityThread main 方法。
参考:https://www.cnblogs.com/lixiansheng/p/11381951.html
traceView工具的使用:
使用方法:
开始: Debug.startMethodTracing("fileName"); 参数 文件名字
停止: Debug.stopMethodTracing("");
二.体积优化:
缺点:
Google等市场限制。包越大,推广价格越高,安装时间越长,
1.图片的优化:
使用webP编码图片优于哈夫曼压缩(微信压缩) 哈夫曼压缩变频是压缩,对rgb进行变频压缩 ,webP压缩是帧内压缩,是对多余的空间进行压缩
Android12以上支持有损的,Android18以上无损的。12以下要导入包
2.Grade压缩:
不存在国际化去掉。v7包中存在国际化资源 grade配置 参数reconfigs "en"
ndk 支持 v7a就好了 x86机器都能支持v7a 去除ABI
混淆:(反射和JNI不能混淆)
功能:1.裁剪,优化,混淆。
Grade增加参数打包,去除没有引用的文件(由于R文件的引用,不会删除文件,只会将内容去掉),如果想不去除,反射的一些文件。增加keep文件,进行文件保留。
shrinkResources true
minifyEnabled true
apk包中,只有accets 文件夹不会处理。其余都会被处理,赋予一个id.
release会进行资源文件混淆,所以比debug包小
3.Dex 压缩
每个Dex持有65536个方法 ,由于classe1.dex 调用 classes2.dex 的方法,所以classe1.dex 中存在class2.dex方法。 将多余的classe1.dex 中class2.dex方法去掉就是减少体积了(没有试过)。
三.UI优化:
Android 界面绘制过程 BUTTON 》 CPU 》 OPENGL 》 GPU对图形进行栅格化,过程必须在16ms以内完成 FPS说明原因
FPS
12fps,每秒12帧
24fps,每秒24帧
。。。
60FPS,让人的肉眼看不出来,每秒必须要有60帧
1000ms/60=16ms 平均必须每隔16刷新一次
Android 系统每个16ms就会刷新一次 只能手机耗电的原因,屏幕最耗电
卡顿原理:
当一帧画面渲染超过16ms,垂直同步机制会让显示器等待GPU完成栅格化渲染操作。
这样会让这一帧的画面,多停留16ms,甚至更多,这样就让用户看起来卡顿(LOL游戏,网速慢时,团战过几秒才会显示上一个画面)。
16ms内所做的工作
1. cpu,将UI对象转成多边形和纹理。
2. cpu传递数据到GPU,GPU进行绘制。
16ms必须处理上面的两步,否则会丢帧或者显示到下一帧造成卡顿。
自己理解:也就是16ms内必须将前面16毫秒改变的屏幕数据处理完成,并且完美的绘制到屏幕上。
解决卡顿
减少时间
1.CPU减少XML转换成对象时间。
2.GPU减少重复绘制(CUP)。
1.布局层级太深,用户看不到的区域也会被绘制,会被绘制两次。
2.自定义控件中,onDraw方法过多的绘制。
GPU 过度绘制分析工具 1.代表绘制两层,2.三层 ,3x 四层, 4x 5层
总结:
1.布局中的背景是否有必要
2.自定义VIew是否进行裁剪
3.布局是否能够扁平化(删除多余布局)
附件:
4.当前页面是否有非常耗内存代码存在 (耗内存代码会内存抖动》gc频繁的回收内存》回收会暂停其他线程(当中包括UI线程)UI线程16ms不能重新绘制界面)
5.webView 通过单开进程方法 (web内存极度不稳定,会造成内存抖动或者内存溢出)
6.关于图片的计算是否需要动用代码 (通过UI来处理)
界面太过复杂 可以使用ConstraintLayout ,减少绘制层级
简历亮点:
负责整体UI优化,代码review,负责安全优化,启动优化,内存优化,卡顿优化,网络优化,存储优化。
本文地址:https://blog.csdn.net/liweicai137/article/details/107467620