开场：两年前刚刚开始接手火掌柜的时候，作为的面向商家的APP，有非常多的设置页面，但是每个页面的设置控件又逃不出那么几个类型。就在想是否可以通过一些配置下发给客户端，告诉我们这些页面具体要展示哪些控件，保存要调用什么接口，和一些相关的跳转页面。 那么客户就可以关注基础组件的开发，从业务中抽出来，做一些平台化的事情。

当时这个想法也跟一些同事提起过。现在看来当时是有点愣头青了。因为我们花了两年时间才能做这次分享，虽然我们现在还是有很多问题要去解决。两年中我们通过一次一次的整个App的架构改造才有了动态化的基础。

• 1. 逻辑后移。
• 2. 整个app通过原来在一个控制器上通过显示、隐藏子view的方式改成了Navication controller控制的方式。
• 3. 整个app建立了每个页面建立的一套路由映射机制（这样才能通过接口告诉客户需要跳转哪个页面）
• 4. 模块化拆分
• 5. 页面组件添加抽象成数据模型
• 6. 处理页面组件之间的联动

按照石胆的话说这都叫做”还债“

然后在去年四月份，掌柜首页迎来了一次重大的改版。当时跟大米决定趁着这次首页改造先把首页动态化做了。万幸的是当时把这件事情做掉了。随后的天气、广告、功能大全都是通过这个架构实现的。

今天聊的动态化更加侧重于内部列表、设置表单页面的动态化。由于跟首页的场景区别比较大，所以我们通过两个方案提供，但是整体的思路还是一样的。

为什么叫香港记者呢。传说中“香港记者”跑的最快。所以我们希望随着动态化的完善。我们的业务可以跟香港记者跑的一样快.

我们的动态化方案稳定，并且基础组件库丰富后，产品的同学在设计App的时候就可以通过后台拖拽的方式生成出需要的页面。并且可以在app上可以展示（后面的演示可以看到）

我们乐观的认为我们的系统确实能够带来开发效率上面的提升，那么产品就愿意通过我们的平台来创建新的页面。换句话说组件都是通过根据交互规范开发的标准组件库出来的。那么app的交互应该是统一的。 这会带来另一个好处是，以后app整理风格的改变会变得很容易。

理所当然的，因为页面元素和动作都是下发的，没有新的组件就不需要客户端参与开发了。

cover掉80%的需求当然只是我的乐观估计。这个要看我们的组件库能丰富到什么程度。

因为能颗粒度细到每一个组件。所以这个也不是问题。