以数据驱动页面为展现系统设计的思考

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/yuyuanhuang/article/details/78204056

以数据驱动页面为展现的思考:

对于客户端开发来说,版本发出去之后,再要修改代码,是一件成本比较高的事情,针对线上实时调整比较多的地方,往往就采用了H5的方式上线。由于H5的体验相对Native欠缺一些,就有了后来Facebook的ReactNative(RN),以及阿里的解决方案Weex,以Native的方式实现页面动态调整的能力。在种种现有框架不成熟的时候,对于首页这种重量级的页面,我们还是希望以一种更加纯粹的Native开发模式来支撑业务。

在设计理念上,我们希望的动态能力体现在无须做代码改动,提供足够多的动态可配置的能力,通过在后台做样式的调整来达到页面调整的目的。


鉴于这样的设计目标,在这个框架里,重点四个方面:

  1. 页面布局动态化,意思是页面的排版布局,可以通过后端数据的下发来调整。
  2. 组件业务化,这里的组件不是指基本的文本、图片、按钮等基本UI控件,而是指能承担一定业务能力的最小复用单元,因此它可能是一个文本和一个图片的组合这样子的一种形式。
  3. 动态能力粗粒度化,通过布局+组件的形式搭建整个页面,有多少种布局能力是内置在框架里的,有多少组件也是业务接入的时候注册到框架里的,后端下发的数据声明了用哪些布局、用哪些组件,通过布局嵌套组件的形式渲染整个页面。所以这个动态能力比较粗,不像H5或者Weex从基本的UI元素开始搭建整个页面。
  4. 组件的复用,为了承载那些个超长页面,需要对同类型的组件具备回收复用的能力,就像ListViewRecyclerView那样。

规范与协议的统一,框架支撑了多个业务,不同业务、不同平台之间,只有规范统一,才能尽可能支撑多的业务,否则不同业务接入,要做转换,是一件成本很高的事情。在不同平台之间统一规范,也可以让一份数据在多端使用。

在客户端上开发,稳定性是一个非常重要的指标,整个应用应该有自己的保护模式,对于框架来说,也要有防御性编程的思维,特别是是动态化方案,往往根据数据来执行代码,访问数据本身要足够小心,像空字段、类型转换、数组越界都是场景的问题,通过安全方法的使用,可以在一个地方保证数据访问的安全性。

组件库,也是一个非常重要的建设,不同业务之间可以复用相同的组件,减少组件开发。

容器化是实现页面在线拼装的一个必要的建设,客户端需要有一个容器页面,就像webview一样,给一个url,就可以加载页面,后端也也需要做数据的容器化接入,能导入业务数据,按照标准协议输出。再利用组件库里的现有组件,就可以完成一个页面搭建。

解耦也是一个老生常谈的问题,在实现扩展能力的时候,解耦这一方面就得特别考虑,像脚本动画、Weex都是其他人的成果,但是我们可希望以很方便的插入到框架里,而且可以热插拔,业务方不想使用就可以不接入。




展开阅读全文

没有更多推荐了,返回首页