导航知识梳理2

上次大概分析了不同的导航app 代码结构，接下来看下app内部各模块如何设计

我们这里一共有三种模式下的项目，但都不是标准的某个模式。

一 mvc模式

一开始我们是基于activity + 多view 来管理，通过栈（Stack）来管理view的跳转和关闭 ，由于没有分层，各个模块之间没法完全独立，也就混在了一起
这种形式显然不好维护，view对应的生命周期太少，需要管理栈来虚拟出回调来实现，创建和删除在一些特殊情况下也会频繁出问题
当然这个项目还在维护，问题很多，不过那个时候 fragment 刚提出来，还不稳定，这个框架当时也算是不错的了
没有模块划分，略过。

二 mvp模式

再看高德demo的项目，activity + 多fragment ，也是通过Stack来管理，但好在将这个放到了底层，且fragment天然就支持分栈管理，支持动态的添加，替换删除
（官方支持 会使得项目面对异常情况很稳定。）
我只看一个引导模块，因为都是一样的（basemap 对应主页，search对应 搜索，user 对应设置，用户中心 。。。）
我们项目也是，只是比他更乱。
其实我觉得这个应该是起了个mvp名字的mvc结构。
fragment 就是把 presenter 和 view 关联起来
presenter 对 view 是强引用，view对 presenter是强引用。
presenter 并没有通过接口和 fragment 或view 建立抽象层
view 也没有通过接口和presenter建立抽象层。
那显然这个presenter就是mvc里面的c
没有层，就没有稳定性，大家还是交互在一起，不过mvp结构动不动就要加新接口这一点确实麻烦
只能说高德demo是一个多层抽象的mvc模式，这样也挺好把，适合小团队敏捷开发。

其实我也不是很喜欢mvp，我的理解是 这个抽象层本身就不稳定，你抽象他干啥，毕竟改动较大的就是view层，咋可能稳定呢

三 mvvm
再看下后来的mvvm模式，这个我到觉得不错，这个是从别处拿到的第三方代码，我一开始看了下，就觉得不错，改进了不少。
哪里好呢，view的事情自己处理，view的异步操作或包含model的代码交给viewmodel，viewmodel处理好了后，数据自身直接通过底层机制（livedata,ObservableField）通知到view层
没有接口层，也能隔离部分view的操作。
但是viewmodel直接控制view，是不是不是很好。这个，这样的话，不又退化到mvc了吗。
但这个改造下还是不错的。viewmodel中的view移出来，还是不错的。如果有空的话，我倒是可以搞下，基于这个搞个最终版，再加上我之前的一些想法都可以放进来。
好了，模块的代码结构就先写道这。已经星期四了，进度有点慢了，接下来要进一步细化到业务流程的代码块了。