今天 ant_design 因为在圣诞节当天的一个彩蛋被刷屏了，2个多小时一个 issues 被评论超过了 1000 次。关于 Ant Design 圣诞彩蛋及其修复方式，这是一个动态的 UI 更新组件。就这这个问题我们就讨论一些，界面/功能 动态更新的相关问题。
组件化方案中的热更新
虽然组件化方案的提出首先是为了解决各个类耦合的问题，但是基本上多数的组件化更新都提到了热更新这个功能，蘑菇街，美团的方案好像都是可以实现服务端配置组件之间跳转的。Swift组件化方案探究和实践 ,已经介绍了几种组件化方案：
组件化方案归根结底，底层是由3中方式实现的，本文主要讨论动态配置的可能性：
-
URLRoute注册
-
Protocol-Class注册
-
Target-Action方案
第一种采用注册跳转的方式解耦，可以从服务器更新下发 url 对应的组件，实现更新跳转模块；
第二种采用协议方式解耦，因为协议遍布各个地方，所以 不方便统一处理跳转更新；
第三种采用 tagget-action 解耦， 因为最终由中心处理类进行路由，所以也可以服务器下发更改动态实现。
缺点
很明显，使用组件层级上的动态化，最大的缺点就是太重：
-
如果是为了修复 bug， 采用一些 js 框架动态修复是个不错的选择，而如果框架实现：客户端有 bug，跳转到对应的 H5，动辄卸胳膊卸腿。
-
如果是组件功能的更换，好像发版比较合适。一般情况下，APP 的大部分基础功能应该是稳定的。
综合来说组件化虽然带来了动态配置，但是不够灵活，有动态需求的一版是活动页，个人页，或者首页的部分 view。
其他的轻量级更新方案
-
预埋代码
-
使用配置文件开关
-
单独下发类 css 文件，基础配置代码
预埋代码就像今天的 ant_design 圣诞节 彩蛋 的方式，优点就是代码书写简单，实现方便，可以配置活动的动作；对应的隐患就是，不可撤销，一旦打包到项目中，这个包必定会触发；容易忘记，当工作内容比较多，且没有第三方文档记录的时候，很容易忘记已经坐了这样一件事。
使用配置文件是一种更好的方式，通过配置开关，配置不同的活动，展现不同的页面，还 可以配置活动的动作；还是不够完美，随着活动数量增加，代码复杂度直线上升，每配置一个活动就需要相关的支持代码，最终项目的维护性将变得很差。
单独下发基础组件的样式是个不错的选择。可以更改整个 APP 的风格样式，非常适合节日活动。也有缺点，为样式而生的解决方案，没法定义事件，但是在一些场景下应用很完美。第三个方案源于 味精的一篇博客： iOS上的CSS样式协议 VKCssProtocol ,虽然框架还有很多局限性，还是列出来，有兴趣的可以了解一下。
三方的SDK / 成熟的框架
这两个框架更适用于解决某个组件内的动态设计（例如首页），通过这种方式可以对单个组件深度定制，非常方便。
-
Tangram，七巧板,这个也是 Alibaba 开源的一套通用动态活动页面动态配置的解决方案 Tangram-iOS
-
Jasonette,另外一套非常受欢迎的解决方案，iOS 项目在这里 JASONETTE-iOS
又是味精大神的一篇博客：动态界面：DSL&布局引擎, 分析了如何使用 json 生成界面，布局排版的一些知识。
学习这个博客，我也是第一次接触到 DSL 这个概念：
DSL 是 Domain Specific Language 的缩写，意思就是特定领域下的语言，与DSL对应的就是通用编程语言，比如Java/C/C++这种。换个通俗易懂的说法，DSL是为了解决某些特定场景下的任务而专门设计的语言。
两个解决方案都是通过下发 json 实现的
这让我想起很久之前做的一个项目，我们需要在个人中心页开辟出 80*375 宽高缩放的活动 View，当时看到天猫首页的更新就猜测是通过 json 配置的，当时没有深究，只是采用了简单的方式，配置按钮数组，配置显示行数，动态生成按钮来实现了。
关于 CSS 盒式布局，FlexBox
前段时间，深度优化 tableview 的时候 使用到的 Texture / ASDK 解决方案，中首次学习到了 盒式布局，首先说一下，学习曲线不算陡峭，而使用之后带来的收益是非常大的，可以方便的同时布局横屏，iPad 等。盒式布局熟练之后编码会更加快速，且结构清楚了。
总结一下
上边说了很多方案，但是各个方案基本都有其独特的使用场景：
-
只更改 UI： 下发UI组件 的样式
-
动态的活动页面：使用 Tangram / Jasonette 深度定制
-
一些涉及多个组件的活动：下发配置（建议产品设计的时候尽量避免）
-
组件化：组件化就做好 APP 架构的工作，这些业务上的需求不建议使用动态组件化方案。
还有一句话，不要抛开项目场景谈论方案，这都是耍流氓，采用 当下和预估最近 最适合的方案是比较理智的。
