Plaster动态化布局——下载篇

Plaster动态化布局——下载篇

Android小彩虹2021-07-13 16:43:44110A+A-

一、为什么要有布局文件管理方案

Plaster的布局引擎和支持的控件数量(合称布局组件)一直在变化中,低版本的布局组件不一定支持在高版本组件下写的布局文件,所以不能将刚编写好的布局文件直接下发给所有客户端,要考虑布局文件和客户端现有布局组件的兼容关系。解决这个问题需要一套行之有效的布局管理方案。通过前期的摸索和调研,起初我们有两个选项:

二、知乎的全量下发方案

知乎对开发了一套专门的管理平台(zhuanlan.zhihu.com/p/64968076)…

云端/本地样式数据库的设计如下:

样式下发接口的参数设计如下:

经过考察后发现该方案有以下难以解决的问题

  • 随着客户端的运营会逐渐积累越来越多的布局文件。如果某个用户是中途下载了App,那他只能全量下载所有布局文件,这会导致用户可能下载很大的布局包。
  • 即使是增量下载,在一个组件版本升级周期内也不能添加太多的布局文件,否则一样导致用户下载很大的布局包。
  • 如果客户端要使用组件进行动态下发,需要提前开发好管理端,同时后台数据返回要同步实现匹配逻辑。即使开发者只是处于技术选型的预研阶段,没有管理端也没法全流程实施。当然这个缺点只是增加了动态下发技术实施的难度。

三、基于数据绑定的按需下发方案

为了解决全量下发时布局包过大的问题,可以将布局下发分布到各个布局页面,按照客户端所处页面按需下发。为了实施这个想法,起初想到的方法是将布局信息绑定到后台数据,后台数据下发时根据客户端的组件版本下发合理的数据和布局信息,客户端校验本地布局的有效性觉得是不是要更新布局。流程如下:

这个方案虽然解决了布局包过大的问题,但是也进一步加重后台的复杂度,后台返回数据时需要根据客户端的组件版本,查询管理端并返回兼容的布局信息,同时会延迟接口的响应时间。

四、基于CDN的xml配置按需下载方案

通过上述方案的探索,我们发现动态下发需要解决以下几个关键问题:

  • 布局包在任何情况下都不能完整下发,否则会限制组件的使用范围。
  • 后台逻辑不宜过于复杂,最好不给后台增加额外工作量。
  • 不用开发管理平台时也能实施动态布局,降低实施难度。

4.1 CDN升级配置

为了解决该问题,我们提出一种基于CDN的xml配置按需下载方案。其实施要点如下:

1、布局文件layout按照页面分成不同的page,每个page对应一个包含其所有layout的升级配置文件,比如im_chatroom.xml。

2、一个page对应一个版本好,所有page配置到包含所有page的升级配置文件,名为page_upgrade.xml。

3、layout修改后,要修改对应page的layout升级配置;page修改后,要修改xml内对应的page升级配置。

总体的目录文件组织结构如下:

4.2 客户端更新配置

客户端升级layout分为两个阶段,app启动阶段拉取page升级关系,判断哪些page有修改。对应page打开时下载对应page的layout升级配置,判断哪些layout需要升级。

App启动阶段拉取,page升级的流程:

页面打开时,layout的升级流程:

4.3 PageInfo和LayoutInfo的定义

PageInfo描述了每个page的升级配置关系,具体定义如下:

LayoutInfo是每个布局文件的描述信息,以K-V的形式缓存在客户端,具体定义如下:

其中需要关注的重点字段:

name:字段是是每个布局的唯一标识,也会K-V存储的Key。

url:布局文件以zip包的方式托管在cdn,cdn地址保存在url字段。

strategy:升级策略配置,主要用于布局文件的灰度下发,符合条件的客户端才会下载当前布局文件,具体策略可以由开发者自己定义,比如:

  • 按照userId的尾号命中,
  • 按照白名单等方式。

upgradeVersion:升级配置版本号,由布局版本号和strategy修改过程决定,相同布局版本下修改strategy则最后两位加1。比如当前布局版本为1010127001,strategy为尾号命中方式,则upgradeVersion为101012700101,相同布局的strategy改为全量升级后upgradeVersion为101012700102。upgradeVersion连同needUpgrade只在预下载升级配置的方式下有用。

从layoutInfo的定义可以看出,每个layoutInfo开发完成后,都会绑定到当前的组件版本。因为低版本的组件可能不支持高版本的布局文件的某些特性,所以我们规定:

  • 低版本组件不能兼容比自己高的布局文件。
  • 客户端只能兼容比自己组件版本小的布局文件,并尽量下载可兼容的最大版本布局文件;
  • 相同name的布局文件修改后,如果是在新组件版修改,也要升级新布局文件的组件版本。

4.4 小结

该方案通过分页按需加载的方式,解决了全量下载布局文件的问题。通过xml配置升级的方式,解决了必须开发升级管理端和加重后台逻辑的问题,其架构如下:

五、实施重点细节建议

5.1 一种layout升级的简化方式

除了上述在app启动时,通过下载page升级配置感知layout配置修改的方案,还有一种更直接的方式。

这是方式直接去掉App启动时拉取Page升级配置的流程,直接在App的单次运行过程中,判断如果page没有拉取过layout升级配置,则拉取layout升级配置,已拉取过的page用一个Hash字段标识已拉取。下次启动App时清空Hash字段,重新拉取page配置。

这种方案的缺点时如果某个page没有更新,也要重新layout升级配置。目前这两种方式都已实现,由开发者在初始化时自行决定采用哪种方式。

5.2 后台数据过滤或客户端提示升级

按照这种方式实现的升级配置不需要后台再处理繁琐的版本适配逻辑,大大降低了后台逻辑的复杂度。后台只需要根据组件版本过滤不支持的数据;或者后台不过滤,由客户端对不兼容的数据提示升级即可。

5.3 过期数据清理

设置过期时间,在合理的app运行过程时段清理长期不用的layoutInfo,保证K-V存储和布局文件的有效性。

5.4 关键布局下载

对于关键页面,比如App一打开就可以看到的首页布局文件,可以在App启动的时候就异步检查升级配置,预加载布局文件,加快首页的加载速度。

5.5 管理平台配置升级xml

目前的这种升级方式完全通过人工配置的方式修改xml配置文件,虽然主体流程没问题,但是人工配置毕竟容易出错。一种更优的方式是基于当前方案,开发自动配置管理平台。当然这种管理平台和知乎的布局管理平台不同,它只需要维护xml更新,是一种特别轻量的平台。

点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1

联系我们