mvp是不是给大家印象，接口设计要设计好久？我就业务代码挪个地方，你让我想这么久？我就一个按钮的页面也设计接口？但是一些复杂复用场景确实需要接口设计啊，听说dataBinding不错，但是我舍不得现在butterknife用法啊，有没有一种架构设计让这些统统可以简单向前向后都可以实现兼容呢，有！项目github地址在文章末尾
这里讲讲代码由来的思考：
通常View层为Activity或Fragment，那也可能是任意的View，抽取IView吧，那View交互的业务逻辑需要挪个地方有几种办法，新建一个Presenter类，然后在View引用并且实例化，实例化时将View传入，让presenter与View互相持有引用，操作手法有用dagger、用泛型传递presenter，然后反射，进一步有个HashMap<ScreenId，Presenter>容器缓存与View绑定的Presenter，横竖屏之后Presenter是可以复用的，到这为止建立了View与Presenter的关系，View本身就是寻找元素，用DataBinding或者Butterknife仅是用法不同，不影响Presenter
接下来我们说说Presenter与View层的交互，我们通常在网络请求前后有个动画加载、文字提示，snackBar，toast显示什么的，每次都要调用View的显示逻辑太乏味，Presenter与View不是互相持有引用么，我们把引用抽象，之前抽取到了IView，现在在抽取，让IView 继承 BaseView，BaseView包含一些Activity或Fragment常用的交互显示的方法，譬如加载网络前的加载动画、加载错误后的消息提示，因为Presenter引用的是View层的接口约束，但是传进来的却是某个实现类，所以就不用写乏味代码了，那么网络错误分发、业务有关的自定义View交互约束是不是也可以这样做呢？
所以其实，主体就是View与Presenter互相持有接口引用，接口按照业务扩展（交互、功能），在各处持有不同类型的引用，不多说，看项目吧
视频运行效果在下方：
