APP 基本框架设计
前言
? ? ? ? 一个良好的APP 基本遵循“简单”，“易用”，“高效”，“便维护”，“可扩展”基本也是从这几个原则出发，比较符合用户体验；同时也是比较符合我们开发人员设计程序的初衷，尽量低的耦合性和尽量高的可复用性，而一个设计良好的应用程序；必然需要有个比较规范和通用的设计框架，因此APP框架设计就变得尤为重要了.
APP框架设计包括哪些内容
APP框架搭建的设计；主要的核心思想还是分层思想，通常设计下，会包括以下内容:(如下图)
APP框架搭建需要考虑的因数
目前现在比较流行混合开发模式，而上图框架的设计内容是基于原生基础上设计，原生开发固然体验比较好，但是开发周期相对于网页通常比较长，对于混合开发模式；我们要考虑以下几个方面：
1一般情况下；从用户体验的角度出发；为了提高用户体验；一般本地的一级页面，以及改动量比较小的页面，需要做成原生的。 2 基于公司实际情况出发，经常变动版本；改动比较大的或者详情页面我们可以做成网页形式，便于我们版本迭代更新 3复杂的软件必须有清晰合理的架构，否则无法后期扩展和维护；通常情况下；我们会结合业界比较成熟的一些设计模式； 1 MVC 是最常见的软件架构之一，业界有着广泛应用，也是早期我们APP 设计时最常见的一种架构模式.
§ 视图（View）：用户界面。
§ 控制器（Controller）：业务逻辑
§ 模型（Model）：数据保存
?
MVC模式的意思是，软件可以分成三个部分。它们的通信方式
1.View传送指令到 Controller
2.Controller完成业务逻辑后，要求 Model改变状态
3.Model将新的数据发送到 View，用户得到反馈.
所有的通信都是单向的。
2 MVP 模式作为一种新型模式，是从经典的模式MVC演变而来，它们的基本思想有相通的地方，将 Controller 改名为Presenter，同时改变了通信方向。
1. 各个部分之间的通信，都是双向的。
2. View 与 Model 不发生联系，都通过 Presenter传递。
3. View 非常薄，不部署任何业务逻辑，称为”被动视图”,即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
4模型与视图完全分离，我们可以修改视图而不影响模型；
5可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
6我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
7如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
3 MVVM (数据绑定) 最早是微软提出的；模式将 Presenter 改名为ViewModel，基本上与 MVP 模式完全一致。
简单的说，ViewModel就是View与Model的连接器，View与Model通过ViewModel实现双向绑定。
唯一的区别是，它采用双向绑定：View的变动，自动反映在 ViewModel，反之亦然.
谷歌推出了Data binding这个框架，Data Binding是一个 support包，因此与 Android M没什么关系，可以轻松的实现MVVM，Data binding解决了 Android UI 编程中的一个痛点，
官方原生支持 MVVM 模型可以让我们在不改变既有代码框架的前提下，非常容易地使用这些新特性。
其实在此之前，已经有些第三方的框架（RoboAndroid)
可以支持 MVVM 模型，无耐由于框架的侵入性太强，导致一直没有流行起来。
?
Data Binding 的基本用法 一 环境??
要求你的Android Studio版本是1.3+?
在开始之前，请更新你的Support repository到最新的版本
要使用DataBinding,android的构建插件gradle要求1.5.0-alpha1或者更高的版本。
二 添加依赖
三Data Binding 入门级Demo 例子 1 我们首先定义一个java bean ?user 类
2 我们再来写一个布局文件；如下图
3最后来看看Activity怎么写。
没有了之前的find控件，没有了setText，Activity代码更加简洁明了
运行结果
结合项目用的比较多的设计架构一般分为2种： A 单Activity＋多Fragment的架构. B 多模块Activity＋多Fragment的架构. 是使用单Activity＋多Fragment的架构，还是多模块Activity＋多Fragment的架构？ 单Activity＋多Fragment：
一个app仅有一个Activity，界面皆是Frament，Activity作为app容器使用。 优点：性能高，速度最快。参考：新版知乎 、google系app 缺点：逻辑比较复杂，尤其当Fragment之间联动较多或者嵌套较深时，比较复杂。 多模块Activity＋多Fragment：
一个模块用一个Activity，比如
1、登录注册流程：
LoginActivity + 登录Fragment+ 注册Fragment + 填写信息Fragment ＋ 忘记密码Fragment
2、或者常见的数据展示流程：
DataActivity + 数据列表Fragment+ 数据详情Fragment ＋ … 优点：速度快，相比较单Activity+多Fragment，更易维护。 总结
权衡利弊，我认为多模块Activity＋多Fragment是最合适的架构，开发起来不是很复杂，app的性能又很高效。
当然。Fragment只是官方提供的灵活组件，请优先遵从你的项目设计！真的特别复杂的界面，或者单个Activity就可以完成一个流程的界面，使用Activity可能是更好的方案。
Android 的 Data Binding 框架还在 beta 阶段，Android Studio 对其内部支持也不是很完整，
进步的空间还很大。不过它被设计和开发的很好，将会改变 Android 应用开发方式(如果顺利的话)。
1 我个人比较倾向于采用了MVP+ Data Binding的混合模式.也就是比较流行热火的MVPVM模式。 2如果有程序框架，因为项目的几乎是一致的，所以上一个项目的项目计划可以直接拿过来使用，而且经过几个项目之后，这个项目计划的模板会越来越细，越来越实用。 因为结构一致，代码混乱性会降低到可以接受的程度，而且可以重用上一个项目的大部分代码。而且逻辑清晰，使得代码相对较小，不容易在代码中迷失。因为代码逻辑简单有序，所以测试起来会很容易。 3 最后我们不能永远理想化地去选择所谓最好的设计，具体问题还得具体分析；在现实的必要情况下，我们要敢于舍弃，最合适的设计才是最好的设计. 99364177
