作为产品经理，是非常不希望产品需求是以下载安装的方式进行迭代的，即使是一个很小的需求如果没有赶上版本发布，就不得不放入下个迭代周期中。然而，即使赶上了版本发布，如果特性被用户排斥，甚至需要紧急发布新版本。新特性的验证也是需要一个一个版本周期去试错。总之，应用下载更新安装的方式不仅慢，动静也大，如果能动态更新就好了。

动态更新是指在用户没有感知的情况下对用户消费的内容进行更新，用户消费的内容可以以APP形式存在，也可以以网页的形式存在。如果以网页为内容的承载体，要做到动态更新是十分容易的，更新时，只需要将新的网页重新部署到后台就可以让用户看到最新的内容了。但是以APP形式为内容承载体时，就不免涉及到下载安装的问题了，如果程序也能和网页一样动态更新不触发安装就太棒了。

程序的动态更新其实就是动态的替换其中的部分代码。程序员写的终端代码最终会以某种实体形式静静的躺在宿主平台的某个角落等待被唤醒。宿主平台并不知道这个程序有多庞大，多复杂，它只认识这个程序的入口，通过这个入口，它可以唤起程序的主体部分。在一些高耦合度的APP中，程序主体部分就是程序的全部，这也是很多APP的初始形态。这种形态的APP无法动态更新，因为所有的代码都在程序的主体中，如果要替换其中的代码，则必须更新程序的主体，而替换程序主体则免不了更新安装的流程。

如果将程序按照模块拆散，代码分散到各个模块当中，那么，只需要保证程序的主体是一个足够健壮的模块加载器（负责加载各个模块），当需要更新时，只需要找到需要更新的的模块，下载并替换掉，下次程序主体启动后就可以直接加载更新后的模块。只要主体程序不用更新，就可以避免平台限制的安装的过程，而且这种做法是一劳永逸的。

这种程序拆分组合的思想跟组合大屏幕很相似，一个程序承载的需求越来越多，就跟屏幕越做越大一样。

看看上面的组合大屏幕，如果其中某处被熊孩子给砸了呢，我们只需要找到被砸坏的那块屏幕，换掉那一块就够了。如果这是一块完整的大屏幕呢，恐怕不得不头痛了。

程序是可以拆散再拼接起来的，如果一个功能的有着频繁迭代的可能，那么在提需求的初期加上动态更新的要求，那么能够很大程度上缓解版本迭代周期的烦恼。如果你在后期提出动态更新要求，恐怕程序员会皱起眉头了（如何在一块完整显示的屏幕中挖出一块可以独立显示小屏幕还能正常显示呢）。