湖南做网站问磐石网络专业/搜狗推广登录

背景

        项目上线一段时间后,回顾重要页面 保证更好用户体验及生产效率，做了内存优化和下载导出优化，具体效果如最后的一节的表格所示。

下面针对拍摄流程的两个页面 预览页 导出页优化实例进行介绍：

一.拍摄前预览页面优化

预览效果问题 存在内存回收不及时情况

问题描述

在预览页面两分钟的情况时： 内存回收不及时 会持续上涨到阈值 才会触发回收情况

对比图

处理前 AddCaptureActivity

处理后 AddCaptureActivity

原因

预览图未及时清除 到达阈值的时候才会回收

解决方案

对临时预览图不光置空 还要对其标记回收

效果

减少40%常驻值

后续提升

针对低性能设备可以降低预览视频 帧率及分辨率

二.拍摄保存页面

目标

业务目标：在减少导出时间 减少预览加载时间

技术目标：兼顾效率的情况下内存优化

现状

进入页面会加载预览图（全屏可滑动的全景图 ）,点击下方保存按钮会下载图片。

需要导出的图片规格 6720x3360

预览组件

在compose下用个webview实现 下载好了图片转为base64通过js桥传到web中 web中负责渲染

组件布局

加载的具体实现

下载组件

通过网络请求对数据下载 默认重试时间10s 失败有toast提示 成功返回房源编辑页面

内存情况

内存常驻值为628 峰值780

内存情况

现状总结

现状情况总结:预览组件和下载导出是独立的组件

优点:独立进行加载 保证了两个业务相互独立 可以在没有预览的情况下 仍能够正常导出

缺点:导出时间长 且没有及时反馈,10s重试、占用内存峰值高

整改

第一步 打通两个组件的加载逻辑 实现缓存共用

打通两个组件的加载逻辑 实现缓存共用 实现以空间换时间实现速度提升,就是将预览组件的缓存 在导出的时候使用。

措施

通过图片缓存框架进行通过控制图片加载、缓存机制，减少无用开销、提升图片复用情况。

效果

导出速度显著提升,但是内存波动大、处在此页面时内存一直处于高位。

第二步 针对内存情况进行优化

分析

经过分析：

内存高位： 导出后bitmap在内存中并没有及时回收、缓存数据缓存了原始数据及对应UI组件大小的缩放资源

内存波动大：导出时io操作 读取bitmap 且本身io操作就会占用一定量的内存

措施

1. 导出时 将从glide中读取bitmap保存文件后临时变量标记回收，改为获取flie形式直接copy到指定目录中。
2. 不再缓存解码后的数据、避免浪费资源。

   diskCacheStrategy(DiskCacheStrategy.DATA)

3. 减少预览渲染的图片大小 不展示原始图片、降低分辨率。、
4. 在compose中及时销毁webview

   DisposableEffect(webView) { onDispose { webView?.destroy() // 销毁WebView } }

glide 磁盘缓存描述

总体流程改造后的效果

拍摄数量大于40张+，

时期	内存	效果	导出时间
优化前	内存常驻值为628 峰值780		z1 3s SC2 弱信号下导出23.36s 正常导出 5s内
优化中	导出速度显著提升,但是内存波动大、处在此页面时内存一直处于高位。		7ms
优化后	房源编辑页常驻值为530~550 拍摄预览页为550~560 拍摄保存页内存为588~600 峰值670		7ms