mobx的优点
1，使用@observer的组件真正实现按需更新，只有监听的数据发生变化，它才会re-render，尽管父组件发生更新，但是子组件只要有@observer，则不会触发更新，类似于实现了shouldComponentUpdate的效果，而同样的场景，如果是redux，子组件通过connect绑定了store里部分数据，但是如果父组件发生更新，子组件绑定的数据源并未发生变化，因此子组件不应该更新，然而却强制更新。
mobx耦合性更低。
mobx的缺点
1，store过多导致无法统一数据源，在多人开发的情况下会比较混乱，如果需要公用某个store，唯有在特定组件注入该store，那如果有多个store里有多个数据源需要公用呢，那就要同时注入多个store，项目复杂了，store的管理又是一个问题。
2，mobx对于数组的处理，会将它转换成observableArray，它不是一个数组类型，需要进行数组转换（如slice）。
3，mobx在forceupdate时，并没有像setState那样处理多个更新合并的操作，这就带来个问题就是，在同一个event loop中，如果多次通过action去引起同一个观察者的更新，那么它就会连续更新多次，但是如果是setState，它会进行一次合并，不会有这种负担。（这里的解决方案就是人为的去控制，避免这种多次同时更新，可以将多个action手动合并为1个action）；
4，对于某个公共组件，可能多个页面需要用到，但是组件内状态较多，并且不同页面，状态差异较多，此时如果用mobx的store来管理，会存在一个问题，组件虽然unmount了，但是store并未消失，导致需要手动reset store里所有的状态，否则会混乱
mobx的思想
将响应式编程和部分函数式编程相结合，取缔传统React的命令式编程，分而治之，将组件都变成可响应的，React提供了渲染的最优方式，通过对比虚拟DOM的diff算法来减少不必要的渲染耗费，而mobx则给React提供了响应式的状态管理。
关于mobx细粒度拆分
是否所有的state我都交给mobx来管理，其实类似于redux，只有当某个状态需要多个组件（这里默认为2个及以上）公用，则将该状态放到store里去监听，然后需要引用该状态的组件通过mobx-react的inject来进行监听。
关于mobx的优化
这里我参考redux的优化，将容器组件通过mobx-react来连接需要监听的store，然后展示组件就还是通过PureComponent来进行优化，避免重复re-render。这里其实有一点考虑是，我们可以利用@observer来对展示组件需要更新的状态进行一个监听，免去shouldComponentUpdate的步骤，但是如果多挂一层监听，性能未必更优，相当于要多处理一个监听器，所以还是减少监听的个数会好些。
为什么选择mobx而不是redux
这个标题不是为了贬低redux，而是解释为什么在某些项目环境中，我不使用redux，而是使用mobx，能否使用redux？可以，只不过mobx会更让开发者舒服一些。
项目场景分析：
（待续）