APP 基本框架设计

APP 基本框架设计

前言

        一个良好的APP 基本遵循“简单”,“易用”,“高效”,“便维护”,“可扩展”基本也是从这几个原则出发,比较符合用户体验;同时也是比较符合我们开发人员设计程序的初衷,尽量低的耦合性和尽量高的可复用性,而一个设计良好的应用程序;必然需要有个比较规范和通用的设计框架,因此APP框架设计就变得尤为重要了.

APP框架设计包括哪些内容

APP框架搭建的设计;主要的核心思想还是分层思想,通常设计下,会包括以下内容:(如下图)

APP 基本框架设计_第1张图片

APP框架搭建需要考虑的因数

目前现在比较流行混合开发模式,而上图框架的设计内容是基于原生基础上设计,原生开发固然体验比较好,但是开发周期相对于网页通常比较长,对于混合开发模式;我们要考虑以下几个方面:

1一般情况下;从用户体验的角度出发;为了提高用户体验;一般本地的一级页面,以及改动量比较小的页面,需要做成原生的。

2 基于公司实际情况出发,经常变动版本;改动比较大的或者详情页面我们可以做成网页形式,便于我们版本迭代更新

3复杂的软件必须有清晰合理的架构,否则无法后期扩展和维护;通常情况下;我们会结合业界比较成熟的一些设计模式;

1 MVC 是最常见的软件架构之一,业界有着广泛应用,也是早期我们APP 设计时最常见的一种架构模式.

APP 基本框架设计_第2张图片

§ 视图(View):用户界面。

§ 控制器(Controller):业务逻辑

§ 模型(Model):数据保存

 

MVC模式的意思是,软件可以分成三个部分。它们的通信方式

1.View传送指令到 Controller

2.Controller完成业务逻辑后,要求 Model改变状态

3.Model将新的数据发送到 View,用户得到反馈.

所有的通信都是单向的。

2 MVP 模式作为一种新型模式,是从经典的模式MVC演变而来,它们的基本思想有相通的地方,将 Controller 改名为Presenter,同时改变了通信方向。

APP 基本框架设计_第3张图片

1. 各个部分之间的通信,都是双向的。

2. View 与 Model 不发生联系,都通过 Presenter传递

3. View 非常薄,不部署任何业务逻辑,称为"被动视图",即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。

4模型与视图完全分离,我们可以修改视图而不影响模型;

5可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部;

6我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;

7如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)

3 MVVM (数据绑定) 最早是微软提出的;模式将 Presenter 改名为ViewModel,基本上与 MVP 模式完全一致。

APP 基本框架设计_第4张图片

简单的说,ViewModel就是View与Model的连接器,View与Model通过ViewModel实现双向绑定。

唯一的区别是,它采用双向绑定:View的变动,自动反映在 ViewModel,反之亦然.

谷歌推出了Data binding这个框架,Data Binding是一个 support包,因此与 Android M没什么关系可以轻松的实现MVVMData binding解决了 Android UI 编程中的一个痛点,

官方原生支持 MVVM 模型可以让我们在不改变既有代码框架的前提下,非常容易地使用这些新特性。

其实在此之前,已经有些第三方的框架(RoboAndroid)

可以支持 MVVM 模型,无耐由于框架的侵入性太强,导致一直没有流行起来。

 

Data Binding 的基本用法

一 环境  

要求你的Android Studio版本是1.3+ 

在开始之前,请更新你的Support repository到最新的版本

要使用DataBinding,android的构建插件gradle要求1.5.0-alpha1或者更高的版本。

二 添加依赖

APP 基本框架设计_第5张图片

三Data Binding 入门级Demo 例子

1 我们首先定义一个java bean  user

APP 基本框架设计_第6张图片

2 我们再来写一个布局文件;如下图

APP 基本框架设计_第7张图片

3最后来看看Activity怎么写。
APP 基本框架设计_第8张图片

没有了之前的find控件,没有了setTextActivity代码更加简洁明了

运行结果
APP 基本框架设计_第9张图片

结合项目用的比较多的设计架构一般分为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 最后我们不能永远理想化地去选择所谓最好的设计,具体问题还得具体分析;在现实的必要情况下,我们要敢于舍弃,最合适的设计才是最好的设计.

你可能感兴趣的:(android,技术博客,框架,设计,app)