android MVP架构

换了一家公司，又开始开发android，原始版本的代码很是麻烦。查阅了新的MVP架构，有了一些想法

1、先思考下什么时候MVC，已经MVC在android项目中的使用场景

Activity在整个android应用里面代表一个用户的对接接口，包含View的显示以及人性的交互。所以一般来说分离了数据石化以及用户交互的特殊UI是我很长一段时间设计的基础。而业务上的逻辑一般耦合在Activity中。这样做好处就是Activity处理一个Activity的逻辑清楚明了，但有个缺点就是当Activity中的功能越大，整个Activity的容积也会相应增加，一个应用写下来Activity可能有一两千行。这样不利于扩展和共同开发，如果是独立开发，其恶果带价稍小，但任然需要消耗脑细胞去记忆庞大的代码结构。那么问题来了什么样的应用会有这样的使用体验，一个Activity尽然会有很多用户交互？毕竟我们做的应用有很多都是操作一步，显示到另一个Activity去显示下一步操作或者返回上一个Activity中去跟新页面绘制新的UI。虽然游戏是符合这样的场景，但游戏更多的是可以使用Canvas去分离绘制和逻辑。而不用像应用一般更多的使用Activity去显示UI。我的答案是地图。

如果使用地图，那么操作将变的十分扭捏，因为一方面必须绘制地图（虽然是底层框架绘制），但地图总是嵌套在一个Activity的layout中。用户对于地图的操作很多场景下是需要通过嵌套的Activity去回调。一般来说地图的对象将被耦合在嵌套的Activity中，而使用回调监听则被写在其中，这一系列的操作将会导致嵌套Activity代码十分庞大。如何分离其中的操作。或者说是分离：1、用户对于地图的操作。2、地图对于用户操作的回调。3、地图操作回调引起的ActivityUI变化（这里指一些基本的UI，比如说比例尺或者方向仪）。4、由于地图是一个重量级控件，笔者认为需要应用单例创建，所以对于其他Activity需要绘制地图的操作（比如说是路线优化）。这些都很令人头疼。

2、MVP启发

显然MVP对于我有了启发。即设计一个Ctl 去 总控所有操作，将所有的回调都视为一种功能插件，将绑定操作放在ctl中，各自操作有各自专属的业务类，通过Application去实例化全局唯一的Map对象，在Activity通过addView添加其中。即将原有的Activity加一两个实例化工具类，拆分成为Activty加若干的监听类，而监听类与Activity通过ctl绑定关系，但是实际调用还通过了一个Handler类去总控回调处理结果（这里可以回调一些UI变化）。在Listener的回调逻辑中加入线程或者其他操作。如此可以分离UI和逻辑。

优点：单个代码结构简化。阅读性加强

缺点：整个工程变的很复杂，多余了很多功能类去处理。