背景

技术群里的朋友发了一条微博，有博主发现Mate 30 Pro有一个很特殊的现象（建议先看视频）

视频描述和下面的猜测都是不正确的。 我在这里总结一下这个现象：

华为手机上的微博App在首页列表上下滑动时依然可以流畅加载图片。 但是，当其他手机上安装同版本的微博客户端时，在主页列表上下滑动时，必须等到滑动停止后才能加载图片。

这种现象有何特别之处？

从技术上来说，滑动列表停止后加载图片是目前列表滑动优化中比较常见的优化项。 许多主流应用程序也这样做。 这样处理主要是因为如果列表滑动的话，图片和视频一到就加载，会加载很多无用的图片&&视频，不仅浪费资源，还可能影响真实用户看到的图片加载速度（加载一般有并行限制和队列，队列中的无效图片太大，后续图片就得排队等待）。 这里比较特别的是，同一版本的微博APK在华为机型和其他机型上表现不一致。 作为系统优化工程师，这是值得弄清楚的（大胆猜测是微博针对华为的机型进行了优化），那么这个优化的内容是什么呢？

从用户体验的角度来说，通过在列表滑动的同时加载图片，可以让用户更早的看到图片，减少白色图片占用图片的显示时间，提升滑动体验。

第三个现象需要仔细体验才能感受到：华为手机上微博放开后的滑动曲线与其他手机上微博放开后的滑动曲线不同。 放手后的华为微博列表滑动曲线更慢更柔和，结束也不算太突兀。 与系统默认的列表滑动曲线明显不同。

以上三者都是基于现象，下面将从技术上进行验证。 从最终的结果来看，华为与微博的合作无疑是非常成功的，可以作为案例向其他头部应用进行推广。 同时，作为一名开发者，我非常佩服华为非常细致的体验优化。

背景说明

由于“列表滑动时加载图片”功能由微博官方服务器控制，可以随时开启或关闭，因此文章称“在其他手机上安装相同版本的微博客户端，首页上的列表显示在列表的顶部和底部，滑动的情况下，必须等到滑动停止后再加载图片。 开启“列表滑动时加载图片”功能后，这种现象就会变成“首页列表列表上下滑动时会加载图片”。

2020年6月左右分析这个问题时，“列表滑动时加载图片”的功能还是关闭的。 只有华为手机经过优化才有效果。 对于其他手机，“直到滑动停止后才会加载图片”。

2020年8月再次看到这个问题时，其他手机上已经开启了“列表滑动时加载图片”的功能。

华为的产品还有效吗？ 答案是肯定的。 详细分析请看下文，因为有了这个SDK，不仅对微博有好处（减少加载图片数量），对华为也有好处（改善华为手机上微博首页列表的滑动体验） ，即Fling Curve优化）； 而其他粗暴开启“滑动列表加载图片”的手机，如果性能不足的话，开启后卡顿的概率会加大（微博官方应该有性能监测数据可以看）

反编译微博版本：10.8.1

先结论

“华为手机上的微博App即使在首页列表上下滑动的情况下，依然可以流畅加载图片。”这种现象是华为与微博联合优化的结果，主要是针对微博列表的滑动进行了优化。 用户体验，其优化点如下

华为提供了一个简单的接口，封装成SDK，提供给微博。 该接口可以让微博列表监控列表当前的速度()。 当速度高于阈值或低于阈值时，App会及时通知。

微博拿到这个速度回调后，可以根据列表的滑动速度来决定滑动过程中是否加载图片。 一旦列表的滑动速度低于设定的阈值，就会开始图片加载； 一旦列表滑动速度较高，超过阈值，就会关闭图片加载。

华为检测到该应用程序使用了该SDK后，可以将优化后的滑动曲线应用到该应用程序的列表Fling阶段，以提高用户体验。

对细节感兴趣的同学可以继续阅读。 有能力的同学可以看完之后修改相关代码，编译成一个SDK，然后自己写一个demo，插入到SDK中。 那么你就可以看完我下面提到的所有内容了。 我自己已经在AOSP代码上实现了，demo可以正常运行。 如果有兴趣可以私聊我。

微博+华为如何优化？

现象分析

当我们滑动微博列表时，一次滑动操作主要由以下三个部分组成：

用手指触摸屏幕，无需离开屏幕即可在微博首页列表中上下滑动。 这个阶段称为第一阶段，专业术语是CROLL。

当手指上下滑动时，离开屏幕（必须有向上或向下滑动的速度）。 微博列表有一个惯性，按照惯性的方向不断滑动。 这个阶段称为第二阶段，专业术语是

惯性滑动后列表停止。 这个阶段称为第三阶段，专业术语是DLE。

华为和微博的优化主要是一、二阶段。

第一阶段优化

优化前：只要手指不离开屏幕，图片加载功能就会关闭

优化后：只要手指不离开屏幕，列表滑动就不会太快。 此时图片加载功能开启。

第二阶段优化

滑动图片加载优化

列表滑动太快，此时关闭图片加载功能。

列表滑动速度下降到阈值，开启图片加载功能

优化前：只要列表滑动不停，图片加载功能就关闭

优化后：是否开启图片加载功能取决于当前列表的滑动速度

List Fling 曲线优化

优化前：列表滑动曲线为默认值，滑动时间较短，停止时突然且不平缓。

优化后：列表滑动曲线经过华为优化。 滑动时间比较长。 停下来的时候比较柔和，并不突兀。 比较接近列表滑动曲线。

技术分析

技术分析的代码主要来自微博apk的反编译，微博版本10.8.1。 从反编译的代码中我们可以看到，微博主页在初始化时，会访问华为提供的，从而获得监控列表滑动速度的能力。

第一阶段优化技术分析

列表是一个标识列表状态的回调。 在这个回调中，微博会根据当前状态决定是否加载图片。 由以下代码逻辑可知：

滑动图片加载优化生效时，如果State != 2，则允许加载图片，State为2。也就是熟悉列表滑动的同学应该知道，是列表所在的部分滑动列表时松开手指后继续滑动。 这叫飞掷。 毕竟，它只在投掷时存在。 放手后，会根据该值计算滑动曲线和滑动时长。

当滑动图片加载优化不生效时，达到常规列表滑动优化：即列表停止后才加载图片：State !=0, 0 即

第二阶段优化技术分析

微博主页初始化时，会为微博主页注册一个ck。 从名字就可以看出，这个回调是监听的，就是滑动速度。 有两个回调：

：当速度降低到阈值时，开启图片加载功能

：当速度增加到阈值时，关闭图片加载功能

下图为反编译后的源码

至于滑动曲线，需要查看华为的代码。 由于代码量比较大，所以这里只贴出.java中的方法。 如果你特别感兴趣，可以自己翻一下华为的代码：

计算代码

计算代码

关于滑动曲线的解释，可以看这个知乎回答，里面对比了iOS和iOS的滑动曲线的区别：为什么iOS的过渡动画看起来那么舒服？

由其他厂家加工

上图中最后一段代码还有一个判断开关。 如果 a = . 这里返回false，说明可能关闭了华为的优化，而且可能是非华为的机器，那么会判断版本号和全局开关：

对应的是一个管理者，可以在线切换某些任务

实现如下

可以看到这里还有一个全局配置：This is可配置在服务器端。

这是与其他厂商打交道的逻辑。

最后一题：滑动点击

滑动点击有什么问题？ 在列表滑动的过程中，如果用户点击了列表中的某个项目，那么根据事件分发机制，此时列表中的项目不会被点击，而是整个列表都会先收到点击事件，而然后触发列表停止滑动。 ; 当列表停止时单击该项目将触发对该项目的单击。

在上面第二阶段的优化中，优化滑动曲线后，列表处于Fling状态的时间变长了。 如果用户想点击某项查看详细信息，需要先点击停止列表，然后再次点击进入。 这就是本节的主题：滑动点击问题。

滑动（Fling状态）和点击其实需要一个平衡，而这个平衡需要开发者自己来控制：

滑动（Fling状态）时间越短，列表就越容易停止，用户点击列表就越容易触发Item的点击。 然而，轻松停车带来的问题是不够温和。 想象一下，您正在粗糙的混凝土地板上滑动一块石头。 石头滑动一小段时间后就会停止。 不管是扔石头的你，还是看着你扔石头的我，都不会觉得美观，但别无选择。 这方面的代表其实就是原生的Fling曲线。

滑动（Fling状态）时间越长，滑动（Fling状态）时间越长，列表停止的可能性就越小，用户点击列表触发点击的可能性也就越小。物品。 如果曲线优化得好的话，会给人一种非常好的感觉。 柔软且符合物理定律，想象一下您正在光滑的冰面上滑动一块冰。 冰面越滑，冰块滑动的时间就越长，也就越难停下来。 这方面的极端代表就是iOS的Fling曲线。

我说iOS极端是因为iOS的滑动曲线调节起来太麻烦。 需要很长时间并且停止得非常缓慢。 很多时候你需要先点击列表停止，然后再进行下一个点击动作。 小米也对此做出了调整，效果比iOS更好。 如果我们和华为、微博这样的三方合作的话，体验会更好。

事实上，滑动点击问题也可以通过厂商与App的合作来解决。 例如，滑动到整个滑动距离的98%（或95%）后，用户点击列表不再停止列表，而是列表中的项目响应这次点击。

这个想法来自于代码。 每个页面左右滑动时，如果滑动尚未停止，但用户快速点击某个图标想要启动，那么此时不会触发页面停止，而是直接响应该图标。 单击开始应用程序操作。