请选择 进入手机版 | 继续访问电脑版

[Android] Android端内数据状态同步方案VM-Mapping详解

[复制链接]
查看58 | 回复4 | 2021-9-14 04:00:27 | 显示全部楼层 |阅读模式
目次

背景

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

比方 :

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

题目 拆解

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

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

此中 3、4点题目 更像是逻辑bug。

多个端的数据同步可以通过跨端变乱 ,每个端收到变乱 后更新本身 就行。以是 最复杂最难搞的题目 就是端内多场景下的数据状态同步题目 。

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

端内题目 聚焦在几个case:

  • case1:平凡 页面,如Activity or Fragment上的状态同步;
  • case2:feed卡片的状态同步;
  • case3:feed卡片内多个复杂层级之间的状态同步;
  • case4:以上的组合。

目标

  • 数据状态同步,是要保证两个划一 性:数据划一 性、UI划一 性;
  • 方案要利用 简单,明确 简单;
  • 尽大概 减少性能开销。

方案调研

EventBus

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

  • 对于case1:假如 是A页面发起,B页面被动吸收 ,只必要 在B页面吸收 变乱 ,更新B页面的Model对象+UI即可。但是在收到变乱 之后,肯定 要把当前页面的model对象更新,不然会有不划一 的题目 。
  • 对于case2
  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粘性变乱 很像。

  • k-v 粒度太细,不停 在内存中,非常轻易 膨胀,没有合适的开释 机遇 ,导致内存浪费;一旦移除,就大概 概率的数据同步失效。
  • k-v列表内的状态要利用 者在合适的机遇 同步到业务层数据Model。

全局共享数据Model实例

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

  • 对数据Model的要求很高。一个业务层数据Model范例 ,要全局同一 ,比如,一个视频卡片业务层的范例 是“ModelA”,那么全局场景不能有“ModelB”表示卡片。在很多场景下,业务层会对原始数据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是一种软件计划 典范,用一种业务逻辑、数据、界面表现 分离的方法构造 代码。

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

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

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

如许 ,就不再必要 额外一个担当 变乱 的“容器”,来控制数据和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,为它加上注解,就可以把数据库中的字段和我们的数据对应上。那么方案呼之欲出,注解是可以完成属性匹配的。

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

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

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

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

具体 计划

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

映射

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

  • Mappable注解 :

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

此中 mappingSpace是定名 空间,表示是“一类”数据,可以和数据库表名对比明确 ,mappingSpace就是tableName。

  • PrimaryKey注解:

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

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

  • MappableKey注解:

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

映射关系阐明 :

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

数据驱动UI

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

这个不过LiveData并不得当 用在这里,来由 是:

  • LiveData绑定的生命周期是LifecycleOwner,也就是Activity、Fragment维度,显着 我们的场景维度更细;
  • 直接observeForever也可以,但是由于View层级的多样,调用方通常必要 合适的机遇 移除;
  • LiveData 强引用了数据Data,这个“桥梁”本身对数据Data的生命周期造成了影响。

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

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

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

当映射发生时,会通过业务标识Key,查找全部 还没有被回收的数据Model实例,然后通过对应的XGViewModel关照 UI本身 的变更。

总体流程

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

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

由于 存在列表,那么会有一个列表的维护者,就是所谓的映射中央 。映射中央 有两个核心本领 :

  1. 网络 必要 被更新的数据Model列表;
  2. 查找匹配。

别的 细节

  • 由于 利用 了反射,为了减少性能消耗 ,会对网络 的数据Model范例 做class和相干 字段的缓存。
  • 列表存在膨胀征象 ,二级弱引用列表的key是数据Model实例本身,当它被假造 机回收的时间 ,会把一级列表中的该项移除,当一级列表某个key下没有内容时,也会把该key移除。
  • 移除的机遇 在每次添加数据Model到列表;
  • 移除的条件是一级列表长度达到阈值。

但是注意 ,这个移除并不会影响VM-Mapping的本领 ,由于 VM-Mapping关注的是数据本身,当数据被回收的时间 ,不会有任何场景会用到这个数据,天然 也不用关心是不是必要 关照 到它。

  • 为了避免影响主线程,和多线程竞争列表的题目 ,映射中央 操作都在单子线程中处理。

方案对比

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

方案收益

西瓜在之前遗留了大量的雷同 题目 ,不停 没有好的方案办理 ,要么存在根本性缺陷,要么实验 成本高。VM-Mapping支持了在西瓜中视频相干 的核心场景快速接入,实现了线上点赞数非常 题目 清零。

后续计划

  • 根据统计,由于利用 运行时注解+反射,一个操作的耗时均值在10ms左右。仍然 有可以优化的空间。可以思量 利用 编译时注解维护数据映射关系。
  • 如今 订阅数据的变化,维度是数据本身,而不是变化的字段,可以思量 通过kotlin delegate 细化监听维度。

到此这篇关于Android端内数据状态同步方案VM-Mapping详解的文章就先容 到这了,更多相干 Android端内数据状态同步方案VM-Mapping内容请搜刮 脚本之家从前 的文章或继续欣赏 下面的相干 文章渴望 大家以后多多支持脚本之家!


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

avatar 123457858 | 2021-9-14 06:49:17 | 显示全部楼层
看了这么多帖子,第一次看到这么有深度了!
回复

使用道具 举报

avatar 阿甘cx1982 | 2021-10-16 18:40:42 | 显示全部楼层
宇宙第一贴诞生了!
回复

使用道具 举报

admin楼主的文笔不错!
回复

使用道具 举报

帖子好乱!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则