亲宝软件园·资讯

展开

Android端内数据状态同步方案VM-Mapping

冬天的毛毛雨 人气:0

背景

西瓜在feed、详情页、个人主页有一块功能区,包括了点赞、收藏、关注等功能。这些功能长久以来都是孤立的:多个场景下点赞、收藏、关注等状态或数量不一致。在以往的业务迭代中,都是业务A有了需求,就加个点赞的请求,把自己业务模块的UI更新下就完事了,业务B也自己搞一下。当西瓜开始从切面发力互动业务的时候,这些问题就凸显出来了。线上出现了很多在页面A点赞/收藏完一个视频到页面B点赞/收藏状态或者点赞/收藏数不对的case。

例如:

问题拆解

在分析这块业务时,梳理出几种问题:

  1. 业务上场景太分散,体现到代码上就是在activity、scene、viewholder、自定义view等各种个样的容器,多个业务模块、多个端(web、flutter)上都有很相似的操作,代码跨度很大。
  2. 存量的代码中有些场景是处理过同步问题的,但是处理的又不彻底,方案也不一样,比如有的情况用了全局注册callback,来通知所有对结果敏感的场景;有的情况用了Eventbus;有的情况是更新内存,但是却只是个别几个模块通用。
  3. 一部分问题是原来的业务逻辑,比如,使用更新后的内存变量在多个页面或者模块传递引用,由于层次比较深引用值被中间的流程篡改。
  4. 一部分问题是服务端数据逻辑问题。

其中3、4点问题更像是逻辑bug。

多个端的数据同步可以通过跨端事件,每个端收到事件后更新自己就行。所以最复杂最难搞的问题就是端内多场景下的数据状态同步问题。

端内问题聚焦在几个case:

目标

方案调研

EventBus

这个方案的本质是:监听者收到事件->更新UI/更新数据Model

  1. eventbus注册在ViewHolder 上:由于ViewHolder的复用,ViewHolder的数量是少于“ListData”的,那么意味着,只在ViewHolder上监听,会出现那些没有和ViewHolder 建立联系的数据无法被更新到。如果使用黏性事件,该事件会一直在内存中,粘性事件的膨胀不可控,很可能会造成严重的内存问题。
  2. eventbus注册在Activity or 其它页面上,收到事件后,遍历数据列表,更新,然后通过RecyclerView的onDataItemChanged方法局部更新。但是在很多场景,比如西瓜feed,feed框架之下的view层次非常深。很多时候Rd只关注某类卡片下的某个UI组件,Feed框架和顶层页面容器离的很远,修改成本高,容易出错,对feed框架或者顶层容器的侵入比较大。另外,onDataItemChanged的局部更新是ViewHolder 对应的itemView的,这个维度比较大,并不能刷新单独的一个点赞按钮。

基于k-v的监听、通知

以对象id为key,某个属性值如点赞数为value。事件发生时,将修改值写入k-v列表,监听者全部监听这个变化。当新进入一个场景时,查询k-v列表作为最新值。这个方案和Eventbus粘性事件很像。

全局共享数据Model实例

同一个数据Model对象,比如一个卡片Model,每次更新都是全局可见的。但是很明显,

基于注解的对象映射方案VM-Mapping

特点

  1. 以命名空间+指定字段值 为key,匹配相同注解名的字段的映射,打平了Model类型的不同、层级嵌套的约束;
  2. 直接更新结果到数据model(如article),与数据model视角的同步;
  3. 打平了多个页面、复杂view层级嵌套的差异;
  4. 自动处理更新,使用者仅需要关心怎么更新UI,不需要考虑数据Model的一致性;
  5. 任意场景的支持。

思考

  1. 数据状态同步,到底同步的是什么?
  2. 上述的方案中大致有几个角色:事件、监听者、数据Model、UI。到底谁应该是主导者?
  3. 基于事件的方案都需要把状态同步给数据Model,能简化吗?

图片

这个过程中有四个角色,三个操作。

突破View层级的限制

从MVVM说起。

MVVM是一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码。

MVVM本质上是一种数据驱动UI的理念。从这个理念看,数据状态同步,同步的是数据Model,UI的变更是由数据的变更引起的,真正关注的点应该在数据本身上。

这样,就不再需要额外一个接受事件的“容器”,来控制数据和UI了。到现在,只有三个角色,两个操作了。

再回过头看,为什么跨页面、跨多View层级很难找到一个通用方案,是因为总在找一个“容器”来承载事件的接受,然后再做双份(数据和View)的同步。而且这个“容器”通常本身就是一个页面,或者其它不同层级上的view,本身就存在很多样化,为这种多样化适配,就会让事情变得复杂。

假如不再找额外的“容器”,直接把监听绑定在数据上,那么View层级的限制也就不存在了。因为不管在什么场景,什么层级,真正的逻辑中心都是数据,View也是通过数据渲染出来的,View不关心自己在什么层级,只关心数据的变化。

突破类型的限制

这里有几个类型的限制:

  1. 数据Model的类型是否只能一成不变,假如网络请求的原始数据是A类型,在场景1直接用了A类型,在场景2为了适配UI对A做了包装:

虽然类型不同,但是对A、B来说,都是要更新diggStatus的;

  1. 在Android,数据Model的类型是强类型,是从网络由二进制流反序列化出来的,那么同一个二进流,既可以反序列化成A类型,又可以反序列化成B类型,只要满足反序列化规则就行。但是事实上,他们的业务本质还是一个东西。
  2. 事件本身也是一个数据,只是它是用户操作发起的,表象看和数据Model无关,但是一个事件既然能更新某个数据Model,那他们一定存在着对应关系。

这个问题的本质是,类型约束是语言特性,但是和业务属性无关,只要他们能确认是一个业务含义,不管他们怎么换“马甲”,他们总是能匹配上的。

这样就演变成了:

  1. 怎么确定两个类型是一个业务含义;
  2. 怎么确定属性的对应关系(字段匹配)。

第一个好说,主要能有唯一的业务标识,就能确定是一个业务含义;怎么确定属性的对应关系呢?

现有的技术体系里就有可以借鉴的思想:数据库的使用。像jetpack 的Room组件:

可以看到,我们只要要在应用层这么定义一个数据Model叫User,为它加上注解,就可以把数据库中的字段和我们的数据对应上。那么方案呼之欲出,注解是可以完成属性匹配的。

于是乎整个流程就简化成了:

这个流程可以看到,只剩下了两个角色,和两个操作了。

所谓数据更新UI,就是View-Model;数据映射数据,就是Data-Mapping,于是这个方案的名称就是VM-Mapping。

详细设计

需要对上述抽象流程做实现。

映射

前面说到,映射关系由注解维护,一个有三个注解:

标注在class上,用来识别这个类是不是可以被处理。

其中mappingSpace是命名空间,表示是“一类”数据,可以和数据库表名对比理解,mappingSpace就是tableName。

标记在字段上,被标记的字段作为Model对象的唯一标识。

mappingSpace+PrimaryKey的值,就是在映射关系中的唯一业务标识。

标注在字段上,需要被映射对应的字段

映射关系说明:

数据驱动UI

Android里有很多类似理念的东西,比如LiveData,就是数据更新通知到UI上。本质上数据驱动UI,就是在数据Data<->UI 之间建一个“桥梁”。

这个不过LiveData并不适合用在这里,理由是:

VM-Mapping做了个简单方案。用了两级HashMap,一级HashMap使用业务唯一标识(mappingSpace+PrimaryKey的值)为KEY,二级使用WeakHashMap,以数据Model实例为KEY,XGViewModel为VALUE。维护数据Data 和 UI回调之间的关系:

XGViewModel维护了通知给UI的弱引用回调合集。一个数据Model实例对应了一个XGViewModel。

当映射发生时,会通过业务标识Key,查找所有还没有被回收的数据Model实例,然后通过对应的XGViewModel通知UI自己的变更。

总体流程

在这个流程中,业务使用只需要关心发起映射数据和更新视图。

因为存在列表,那么会有一个列表的维护者,就是所谓的映射中心。映射中心有两个核心能力:

  1. 收集需要被更新的数据Model列表;
  2. 查找匹配。

其它细节

但是注意,这个移除并不会影响VM-Mapping的能力,因为VM-Mapping关注的是数据本身,当数据被回收的时候,不会有任何场景会用到这个数据,自然也不用关心是不是需要通知到它。

方案对比

方案 优势 劣势
Eventbus 理解成本低 事件、UI、数据Model三个角色都要保持一致,适配各种场景的成本高,不通用。
全局共享数据Model实例 使用简单 条件苛刻;占用内存,膨胀不可控制。
基于k-v的监听、通知 各场景通用 粒度太细导致内存不可控制,移除策略会导致同步失效。事件需要手动同步数据Model。
VM-Mapping 使用简单,不需要手动同步回数据Model,在所有场景下通用。 用到了反射,有一部分性能损耗。

方案收益

西瓜在之前遗留了大量的类似问题,一直没有好的方案解决,要么存在根本性缺陷,要么实施成本高。VM-Mapping支持了在西瓜中视频相关的核心场景快速接入,实现了线上点赞数异常问题清零。

后续计划

加载全部内容

相关教程
猜你喜欢
用户评论