Android 性能优化实例分享-内存优化兼顾效率与性能

这次选左边

已于 2024-03-27 09:18:55 修改

阅读量1.3k

点赞数 13

文章标签： android 经验分享 androidx android studio

于 2024-03-24 21:59:41 首次发布

本文链接：https://blog.csdn.net/qq_36544007/article/details/136995383

版权

本文介绍了项目上线后针对预览和下载导出页面进行的内存优化，包括预览页面的内存回收改进和下载组件的缓存策略调整。通过优化，导出速度显著提升，但内存波动增大。后续措施关注内存释放和资源管理，以达到更好的用户体验。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

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

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

一.拍摄前预览页面优化

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

问题描述

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

对比图

处理前 AddCaptureActivity

处理后 AddCaptureActivity

原因

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

解决方案

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

效果

减少40%常驻值

后续提升

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

二.拍摄保存页面

目标

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

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

现状

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

预览组件

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

下载组件

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

内存情况

内存常驻值为628 峰值780

现状总结

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

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

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

整改

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

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

措施

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

效果

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

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

分析

经过分析：

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

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

措施

导出时将从glide中读取bitmap保存文件后临时变量标记回收，改为获取flie形式直接copy到指定目录中。
不再缓存解码后的数据、避免浪费资源。
```
diskCacheStrategy(DiskCacheStrategy.DATA)
```
减少预览渲染的图片大小不展示原始图片、降低分辨率。、

在compose中及时销毁webview

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

总体流程改造后的效果

拍摄数量大于40张+，

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