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

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

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

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

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

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

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

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

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

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

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