赞
踩
项目上线一段时间后,回顾重要页面 保证更好用户体验及生产效率,做了内存优化和下载导出优化,具体效果如最后的一节的表格所示。
下面针对拍摄流程的两个页面 预览页 导出页优化实例进行介绍:
在预览页面两分钟的情况时: 内存回收不及时 会持续上涨到阈值 才会触发回收情况
处理前 AddCaptureActivity
处理后 AddCaptureActivity
预览图未及时清除 到达阈值的时候才会回收
对临时预览图不光置空 还要对其标记回收
减少40%常驻值
针对低性能设备可以降低预览视频 帧率及分辨率
业务目标:在减少导出时间 减少预览加载时间
技术目标:兼顾效率的情况下内存优化
进入页面会加载预览图(全屏可滑动的全景图 ),点击下方保存按钮会下载图片。
在compose下用个webview实现 下载好了图片转为base64通过js桥传到web中 web中负责渲染
通过网络请求对数据下载 默认重试时间10s 失败有toast提示 成功返回房源编辑页面
内存常驻值为628 峰值780
现状情况总结:预览组件和下载导出是独立的组件
优点:独立进行加载 保证了两个业务相互独立 可以在没有预览的情况下 仍能够正常导出
缺点:导出时间长 且没有及时反馈,10s重试、占用内存峰值高
打通两个组件的加载逻辑 实现缓存共用 实现以空间换时间实现速度提升,就是将预览组件的缓存 在导出的时候使用。
通过图片缓存框架进行通过控制图片加载、缓存机制,减少无用开销、提升图片复用情况。
导出速度显著提升,但是内存波动大、处在此页面时内存一直处于高位。
经过分析:
内存高位: 导出后bitmap在内存中并没有及时回收、缓存数据缓存了原始数据及对应UI组件大小的缩放资源
内存波动大:导出时io操作 读取bitmap 且本身io操作就会占用一定量的内存
diskCacheStrategy(DiskCacheStrategy.DATA)
DisposableEffect(webView) { onDispose { webView?.destroy() // 销毁WebView } }
拍摄数量大于40张+,
时期 | 内存 | 效果 | 导出时间 |
优化前 | 内存常驻值为628 峰值780 | z1 3s SC2 弱信号下导出23.36s 正常导出 5s内 | |
优化中 | 导出速度显著提升,但是内存波动大、处在此页面时内存一直处于高位。 | 7ms | |
优化后 | 房源编辑页常驻值为530~550 拍摄预览页为550~560 拍摄保存页内存为588~600 峰值670 | 7ms |
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。