验证当前数据加载方案的可行性
- 当前的设计是否满足交互流畅度。流畅度是否能达到京东首页的体感？设计数据只加载文字；
- 加载文字后再加载静态图片；测试验证当前布局、数据逻辑加载的交互体感情况。如不满足那基本就能确定是布局和数据加载逻辑有缺陷，则需要进行重构或重写
- 在第1条满足的基础上，测试同一个网络图片加载到所以列表子项里展示。记录交互体感和京东首页进行对比分析 测试单列动态图片加载效果并记录
- 再次测试双列动态图片加载效果并记录
只加载文字
这个过程渲染正常
加载文字后再加载静态图片
这个也没有问题；静态图片为webp 1kb
本来想都录制成GIF，但发现信息不能暴露蛤！看那个图柱就好了。大致上就是这么一个渲染耗时情况
同一个网络图片加载到所以列表子项里展示
- 在动态图片没有加载渲染时：上下滑动耗时基本相当
- 在动态图加载渲染图片时：上下滑动耗时增加明显，不过这个时间段比较短，影响不明显
单列动态图片加载
- 在动态图片没有加载渲染时：上下滑动耗时基本相当
- 在动态图加载渲染图片时：上下滑动耗时增加明显，不过这个时间段比较短，影响不明显
- 在新增一页数据时渲染耗时增加明显、上下滑动卡顿感明显，在数据加载到第3页之后每页新数据渲染耗时图柱明显增多，几乎是有增加一倍多趋势。这个时候进行上下滑动会很明显的卡住不动了
双列动态图片加载
- 在动态图片进行加载渲染时耗时比较大，上下滑动反应慢，甚至画面不动
- 新增一页数据加载渲染时耗时比较大，上下滑动几乎没有反应，画面停止没有交互响应
基本定位问题再动态图片加载上：
仔细查看了各个网络图片的大致大小，惊人的发现网络图片大部分都是100kb以上，而且有400kb和500kb的情况。无语问他妈给无语开门，无语到家了。几千个数据加载的列表，这图片太重了
大部分都是这样的网络图片情况。唉！这太惊人了，在某些机型上是真带不动了。但领导还是让想想办法解决。
问题找到，但要进行解决
更多优化记录如下：
【Android】画面卡顿优化列表流畅度三之RecyclerView刷新机制notifyItemRangeInserted
smartApi接口开发工具推荐
历时一年半多开发终于smartApi-v1.0.0版本在2023-09-15晚十点正式上线
smartApi是一款对标国外的postman的api调试开发工具，由于开发人力就作者一个所以人力有限，因此v1.0.0版本功能进行精简，大功能项有：
- api参数填写
- api请求响应数据展示
- PDF形式的分享文档
- Mock本地化解决方案
- api列表数据本地化处理
- 再加上UI方面的打磨
下面是一段smartApi使用介绍：
下载地址：
https://pan.baidu.com/s/1kFAGbsFIk3dDR64NwM5y2A?pwd=csdn