本文将带你了解WEBAPP开发教程APP 基本框架设计，希望本文对大家学WEBAPP有所帮助。

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 最后我们不能永远理想化地去选择所谓最好的设计，具体问题还得具体分析；在现实的必要情况下，我们要敢于舍弃，最合适的设计才是最好的设计.    

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标移动开发之WebApp频道！