android mvc 架构,Activity(一):MVC模式架构篇

都是项目过程中曾经遇到问题，查看过相关资料，现在整理下思路，当时遇到的问题，已经如何解决。

这是重温系列第一篇，第一个想到Activity，主要有Activity启动模式，生命周期，屏幕旋转生命周期变化，回收状态保持，安全退出allActivity后重启。

在说具体Activity知识点之前，想先谈谈自己对Activity在android的重要性的理解，在MVC模式中的角色。

MVC (Model-View-Controller)：M是指逻辑模型，V是指视图模型，C则是控制器。一个逻辑模型可以对于多种视图模型，比如一批统计数据你可以分别用柱状图、饼图来表示。一种视图模型也可以对于多种逻辑模型。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式，而C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

android的官方建议应用程序的开发采用mvc模式。

图中实线表示方法调用，虚线表示事件响应

1) 视图层(View)：一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入复用。同样也可以直接代码生产视图，一般需要动态加载的布局或者自定义视图使用。当然，你也可以想到在Android中也可以使用JavaScript+HTML等的方式作为View层，当然这里需要进行Java和JavaScript之间的通信，Android提供了它们之间非常方便的通信实现。像微信，支付宝，手机百度都是致力于此，封装API，打造超级APP。

2) 控制层(Controller)：Android的控制层的重任通常落在了众多的Acitvity的肩上，这句话也就暗含了不要在Acitivity中写过多代码，要通过Activity交割Model业务逻辑层处理，所以这一层就是拿到模型层的数据，交互判断一下，调用展示到视图层上，事件响应处理，建立视图层与模型层的关联。

3) 模型层(Model)：对业务逻辑处理、数据库、对网络等的操作都应该在Model里面处理，具体开发中我也是对于建了许多业务实体处理类，这也是诞生了许徐多多的android开源框架，用的比较多的如Afinal，GreenDAO，OrmLite ，LitePal都是基于sqlite的orm框架，还有网络通信的Volley，OKHttp等其他诸多Android开源工具类框架的广泛流行，都离不开MVC模型的支持(个人意见)。

这样就定下了android程序的基本架构。我一般就按这个理解分为三部分，从上往下分别是视图层，交互层，数据层。

开发新需求：视图层-->控制层-->模型层

在开发的过程中拿到高保真图的时候，按这个思路，一层一层实现处理。第一步先确认视图展示需要的布局，控件，完成页面视图，第二步交互判断(输入框必须为数字，密码，不为空等等)，第三步接口调试，本地数据存储，业务逻辑处理实现对应模型。

需求变更：模型层-->控制层-->视图层

需求不可能一撮而就，需求变更应该说是是我们做的产品向更好的方向改变，所以就是家常便饭，特意也提出来说一下，但是处理思路和开发新需求缺是相反的。当需求出现变化的时候，产品已经做了一部分雏形，不易大幅更改，所以此时开发这边就要沟通得当。修改的时候从先分析业务逻辑的变化，对模型做出对应的修改，接着是交互操作过程的梳理，最后确认视图层展示。

基于这个理解，所以在我的思路里面Activity是面向用户的应用中，最重要的一环，先来介绍下，接下来在继续继续介绍Activity相关。