APP服务端组件下布架构演化

传统APP与服务端交互架构

1. 服务器只负责返回简单的数据
2. APP端对服务端提供的数据进行加工（复杂），例，可能根据2，3字段来判断一个控件是否显示
3. 把加工的数据和布局好的控件进行渲染

服务端：

    负责把业务逻辑数据提供出来

客户端：

    对数据加工，渲染出想要的界面

缺点：

     界面的控制完全APP来控制，对一些简单的界面修改也要APP进行发版的操作

 

简单服务器下发架构

1. 服务端在提供数据后进行了一个初步转换，具体如果对应具体页面，例，可能根据2，3字段来判断一个控件是否显示，归节到一个字段中
2. APP端对服务端提供的数据进行简单加工（甚至不用加工）
3. 数据和布局好的控件进行渲染

服务端：

    不仅负责把业务逻辑数据提供出来，还要针对界面进行加工

客户端：

    对简单数据加工或者不加工，渲染出想要的界面

缺点：

     虽然服务端对界面的控制得到了增强，但对服务端的工作量增加巨大，相同数据，不同交互，不同VO

 

代理服务器下发架构

1. 服务器只负责返回简单的数据
2. 加工server对服务端提供的数据进行加工（复杂），例，可能根据2，3字段来判断一个控件是否显示,归节到一个字段中
3. APP端对加工server提供的数据进行简单加工（甚至不用加工）
4. 数据和布局好的控件进行渲染

服务端：

    负责把业务逻辑数据提供出来

客户端：

   在加工server对数据加工，APP渲染出想要的界面

缺点：

    客户端要进一步控撑服务端的技术，学习成本增加。对下发内容及下发结构有进一步的要求----下发内容组件化。

 

组件下发架构

•         减少APP端CPU的利用率，单纯的对界面渲染
•         加强服务端对APP的控制力，减少APP的发布频率

 

简单组件下发架构

1.  一个页面有多个控件， 他们分别对应右边数组中的不同type的数据。
2. 我们可以轻松的对右边的json增加属性来控制页面的展示，把hidden设置为1，界面上对应组件会进行隐藏
3. 对于每一次控件的设置，要保持界面控制和数据分离方式。

缺点：

     每次返回除了所需数据外，还需要更多的额外数据，如果一分页数据会更难。。。。

 

异步组件下发架构

 

   更优下发解决仍在探索中。。。。