照片墙10w以上张照片梳理,照片列表、多选上优化设计及实践

1. 背景

第一期优化了加载效率,比如合理增加并发线程数,提升快速滑动缩略图等待,因为使用测试账号数据比较少(不超过1W),只对当前测试出现的问题进行点对点上的优化。对大数据的照片,出现新上传的照片显示很慢,多选照片操作卡顿。缺少没有专门针对大数据照片测试,没能发现旧的代码上及加载机制上的问题,导致这块优化缺失,本期专项对大数据照片进行分析及优化,优化前后的效果见末尾屏幕录制的视频所示。

2. 照片墙原有业务流程

  整体的业务流程比较多,交互比较繁琐。

3.优化措施

具体优化措施主要从业务逻辑设计及代码上进行优化

3.1 业务层优化

3.1.1 图片加控件加载逻辑优化

图片加控件加载前取消加载任务,原因view会被复用,而之前的加载的任务并未取消。

 

加载前取消任务,可以使得当前缩率图加载的任务不会因为队列等待导致加载时间长的问题,网络好的情况下,基本是秒内即可加载显示。

3.1.2 可视区域列表部分加载

原来是顺序全部加载,优化为仅加载可见区间部分列表,实现快速加载显示可见区域的照片列表

原来的流程图:

 

优化后的主要流程图:

 

数据测试下,存在启动卡顿黑屏现象、上传新照片后很久才能显示新的照片都是顺序加载导致。

优化后,入口进入启动时间400ms以内,新上传上面秒内显示。

3.1.3 多选设计

原设计:

 

优化后的设计:

 

3.1.4 日月索引转换

背景是照片墙有效率模式(按月浏览,图1)和标准模式(按日浏览图2):

图1

 

 图2

 

平台获取照片列表的整个时间段的总数不能超过2W张,而在月模式下的时间段请求极有可能超过2W张。

解决方法是月模式下,也使用日模式列表加载请求,因此在月模式下,列表可见区域的索引需要设计个日月模式转换:

 

3.2代码优化

3.2.1 集合优化:同是浅拷贝,尽量不用枚举再添加,直接使用addAll,底层调用的是System.arraycopy()要高效点

优化前:

 

优化后:

数据测试:

枚举耗时:5~14ms

 

AddAll:1~8ms

 

3.2.2 耗时方法比避免重复多次调用

 

优化前:

 

优化后:

mListWorker.getSelectedFiles( )为耗时方法,应尽可能减少调用的次数。

3.2.3 空间换时间

优化前:

3.2.3.1 流程图

3.2.3.2 代码

 

数据(实际加载57026)耗时:

1128ms~1284ms

时间复杂度:0个选择O(1), 其他O(N1*N2)

空间复杂度:O(1)

注:N1为索引集合数量,N2为缓存列表的数量

优化后:

 

 

测试耗时:

 全选:17~24ms

0个选择:8~10ms

时间复杂度:O(N1)+O(N2)

空间复杂度:O(N3)

注:N1为索引集合数量,N2为缓存列表的数量,N3为缓存里列表中每个日期对应下列表数的总和

3.2.4 特殊情况下的特殊处理

优化前:

 

 

测试耗时:

 全选:17~24ms

0个选择:8~10ms

 

优化后:

 

 

 

耗时测试:

全选:4~21ms

0个选择:0ms

全选-1条:11~67ms

时间复杂度:0个选择O(1),全选O(N2),其他:O(N1)+O(N2)

空间复杂度:O(N3)

注:N1为索引集合数量,N2为缓存列表的数量,N3为缓存里列表中每个日期对应下列表数的总和

3.2.5 算法上优化

有序集合查找尽量使用二分法,而不是暴力枚举查找法。照片墙的的排序是倒序的,因为数据结构是有序的,因此可以采用二分法来高效查找数据,比如删除,替换等场景

删除中查找:

列表部分加载,在时间轴上查找某天所处的索引:

 

暴力查找的时间复杂度为O(N)

二分法时间的复杂度为O(logn)

3.2.6 控件使用技巧

3.2.6.1 图片加载控件缓存本地已上传照片

 以前为了快速显示本地已有的照片,解决方法glide控件中内部每个访问都会先去枚举上传下载传输列表,传输列表数据大的情况下,必然查找中损耗时间。

另外并不是所有照片大概都会由本地原图。

因此,如何生成本地照片缩率图到Glide的缓存中,并且下次访问使用基本相同的url访问:

主要思路是生成时url参数带上照片的本地路径,然后生成key时,移除这个参数,这样保持访问的统一,里面拦截有本地路径的url则从本地读取数据而不是网络中获取。

3.2.7 耗时工作子线程执行等等...

4.优化效果

以下使用vivo Y73s Android10机型上,测试账号的照片墙有107542张照片测试数据

测试版本是优化后的版本与9.0.2版本对比

4.1点击入口启动(生命周期函数回调onCreate到onStart)耗时对比

优化前:

第一个次启动耗时494ms

后面启动耗时4s以上

见图1

优化后:

启动耗时不大于400ms,见图2

图1

图2

4.2日期全选全流程耗时对比

优化前:

点击全选到到显示:5s多

优化后:

点击全选到到显示:86~282ms

4.3 时间轴快速滑动显示对比

优化前:

标准模式,时间轴快速滑动,

a. 缩率图会短暂显示其他照片,然后再刷新现在的照片的多次闪烁显示其他照片的现象

b . 在第一次进来,快速滑动较长距离,等待很久(5s以上)没有显示当前缩率图

效率模式,时间轴快速滑动,

a. 列表界面乱抖动,需要5S以上才能显示缩略图

b. 切换其他模式卡顿(3s以上才响应)

优化后:

标准模式,时间轴快速滑动

不管是否是第一次进入,缩率图不会有闪烁其他照片,平均秒内显示缩略图

效率模式,时间轴快速滑动

a. 列表滑动正常,缩率图基本2s以内显示

b. 切换其他模式如丝般顺畅

4.4 新上传照片显示速度对比

优化前:

多次刷新,很缓慢(4s以上)才能显示新上传照片

优化后:

上传新照片,下拉刷新,相对以前版本,显示新上传照片有明显提升,秒内显示新上传的缩略图

4.5 列表缓存及显示列表缩率图

优化前:

这个功能有问题,不能正常使用

优化后:

在上次已成功加载照片列表及照片情况下,再次进入下次无网情况下,可显示上次部分(避免数据库膨胀过大,预设缓存不超过2w条)已加载的图片

6. 优化前后录制视频效果对比

测试版本是优化后的版本与线上9.0.2版本对比

6.1优化前视频:

https://cloud.189.cn/web/share?code=Br2A7fNF3AZb

6.2优化后视频:

https://cloud.189.cn/web/share?code=vMNFru7baEnq

6.3优化前上传新照片,刷新显示:

https://cloud.189.cn/web/share?code=jiMzmiIFbiIj

6.4优化后上传新照片,刷新显示:

https://cloud.189.cn/t/r2A3uuQ7b2Ar

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值