传统APP与服务端交互架构
- 服务器只负责返回简单的数据
- APP端对服务端提供的数据进行加工(复杂),例,可能根据2,3字段来判断一个控件是否显示
- 把加工的数据和布局好的控件进行渲染
服务端:
负责把业务逻辑数据提供出来
客户端:
对数据加工,渲染出想要的界面
缺点:
界面的控制完全APP来控制,对一些简单的界面修改也要APP进行发版的操作
简单服务器下发架构
- 服务端在提供数据后进行了一个初步转换,具体如果对应具体页面,例,可能根据2,3字段来判断一个控件是否显示,归节到一个字段中
- APP端对服务端提供的数据进行简单加工(甚至不用加工)
- 数据和布局好的控件进行渲染
服务端:
不仅负责把业务逻辑数据提供出来,还要针对界面进行加工
客户端:
对简单数据加工或者不加工,渲染出想要的界面
缺点:
虽然服务端对界面的控制得到了增强,但对服务端的工作量增加巨大,相同数据,不同交互,不同VO
代理服务器下发架构
- 服务器只负责返回简单的数据
- 加工server对服务端提供的数据进行加工(复杂),例,可能根据2,3字段来判断一个控件是否显示,归节到一个字段中
- APP端对加工server提供的数据进行简单加工(甚至不用加工)
- 数据和布局好的控件进行渲染
服务端:
负责把业务逻辑数据提供出来
客户端:
在加工server对数据加工,APP渲染出想要的界面
缺点:
客户端要进一步控撑服务端的技术,学习成本增加。对下发内容及下发结构有进一步的要求----下发内容组件化。
组件下发架构
- 减少APP端CPU的利用率,单纯的对界面渲染
- 加强服务端对APP的控制力,减少APP的发布频率
简单组件下发架构
- 一个页面有多个控件, 他们分别对应右边数组中的不同type的数据。
- 我们可以轻松的对右边的json增加属性来控制页面的展示,把hidden设置为1,界面上对应组件会进行隐藏
- 对于每一次控件的设置,要保持界面控制和数据分离方式。
缺点:
每次返回除了所需数据外,还需要更多的额外数据,如果一分页数据会更难。。。。
异步组件下发架构
更优下发解决仍在探索中。。。。