最近项目要求用umi，dva还没特别熟…又要换，本来打算过段时间再用umi试试，哎，卑微。
放一张看不懂的架构图
从源码到上线的生命周期管理
市面上的框架基本都是从源码到构建产物，很少会考虑到各种发布流程，而 umi 则多走了这一步。
用户配置的参数和插件会影响流程里的每个环节
为什么要使用umi
和dva、loadhog的关系
roadhog 是基于 webpack 的封装工具，目的是简化 webpack 的配置。
dva 首先是一个基于 redux和redux-saga 的数据流方案，然后为了简化开发体验，dva 还额外内置了 react-router和 fetch，所以也可以理解为一个轻量级的应用框架。
dva 目前是纯粹的数据流，和 umi 以及 roadhog 之间并没有相互的依赖关系，可以分开使用也可以一起使用。dva和umi官网都建议dva+umi。
umi 可以简单地理解为 roadhog + 路由，思路类似 next.js/nuxt.js，辅以一套插件机制，目的是通过框架的方式简化 React 开发。
那为什么不用next.js呢？
next.js 的功能相对比较简单，比如他的路由配置并不支持一些高级的用法，比如布局、嵌套路由、权限路由等等，而这些在企业级的应用中是很常见的。