app架构设计是什么_app的架构

文章目录：

• 1、什么是软件架构？
• 2、如何设计app的架构
• 3、软件的架构与设计模式之什么是架构
• 4、软件开发的架构设计指的是什么？

什么是软件架构？

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

如何设计app的架构

想要设计App的整体框架，首先要清楚我们做的是什么

一般我们与网络交互数据的方式有两种：主动请求(http)，长连接推送

结合网络交互数据的方式来说一下我们开发的App的类型和特点：

数据展示类型的App：特点是页面多，需要频繁调用后端接口进行数据交互，以http请求为主；推送模块，IM类型App的IM核心功能以长连接为主，比较看重电量、流量消耗。

手机助手类App：主要着眼于系统API的调用，达到辅助管理系统的目的，网络调用的方式以http为主。

游戏：一般分为游戏引擎和业务逻辑，业务脚本化编写，网络以长连接为主，http为辅。

一般我们做的App都是类型1，简要来说这类app的主要工作就是

把服务端的数据拉下来给用户展示

把用户在客户端修改的数据上传给服务端处理

所以这类App的网络调用相当频繁，而且需要考虑到网络差，没网络等情况下，App的运行，成熟的商业应用的网络调用一般是如下流程：

UI发起请求 - 检查缓存 - 调用网络模块 - 解析返回JSON / 统一处理异常 - JSON对象映射为Java对象 - 缓存 - UI获取数据并展示

这之中可以看到很明显职责划分，即：数据获取；数据管理；数据展示

确定了职责，就可以进入正题了

1. 传统的Android App架构

Android最原生也是最基础的架构，可以理解为MVC，Controller即是Activity和Fragment，但是这两者掌握了Android系统中绝大多数的资源，并且在内部直接控制View，因此传统的Android App一般是以Activity和Fragment为核心，将网络模块，数据库管理模块，文件管理模块，常用工具类等分离成若干工具类包，供Activity和Fragment使用。

这是比较基础的Android项目架构，市面上大部分App都是这种造型

优点：就是开发简单，以页面为导向；如果构建水平可以，项目就已经基本实现模块化，基于Activity，Fragment这这两个上帝般的存在，很多事情直接就妥了，不用绕。

缺点：维护难，因为是以页面为导向的，有些需要共用的业务逻辑就会很烦，don't repeat your self， 你要不要repeat ？不想repeat就要写模块，慢慢的项目就会多出一堆乱七八糟的小模块。另一方面，测试很困难，因为所有的数据处理都在Activity和Fragment，假如现在想先用假数据显示，就要直接改Activity和Fragment的数据控制逻辑。

还有个最恼火的问题，那就是业务复杂起来后Activity和Fragment的代码量激增，举一个例子，电商App的购物车，如果只是管理一下购物车中的商品，无非就是查、删、改调用，列表管理，300多行代码应该就搞定了，假如现在加了个优惠券提示呢？光优惠券不够，还有满减，还有凑单，要计算运费。还要能领取优惠券…… 噢，忘了一般来说还有一个商品推荐，好了现在有两个列表要管理了，你觉得CartActivity 2000行代码能止住么？

在上面这些缺点的描述中，可以看到一个很大的痛点在于：Activity和Fragment不应该管这么多数据处理逻辑

2. 分层架构

如果仔细看自己的项目，可以发现绝大多数数据处理的代码是不需要使用Activity和Fragment持有的资源的（比如Context），而很多时候我们需要多个页面共用一套数据和请求逻辑，很经典的例子是应用中的User对象，一般来说都是全局单例。

这些全局的数据源写多了，很容易就能想到将数据处理统一抽出来形成一层，向上层提供数据接口，而上层并不关心数据的来源（内存，缓存，网络），因为不用从Activity和Fragment拿资源而且主要工作是数据处理，所以这一层是UI无关的，大幅提升了复用性，我把这一层称为DataManager层。

这是我一个项目的包结构

Activity和Fragment剥离了数据处理的责任后，持有DataManager的引用，负责获取数据并展示，向DataManager传递数据，绝不进行网络请求和缓存读写。

软件的架构与设计模式之什么是架构

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。所有的数字都如日历般严谨，风格雄浑。难以想象这是石器时代的建筑物。 图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的要害就是建筑物对人的影响。在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为闻名的，当然就是模式理论和XP理论。架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。·可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。 ·可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

·客户体验（Customer Experience）。软件系统必须易于使用。·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。·物理架构、软件元件是怎样放到硬件上的。比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。 图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。 首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。 架构师软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

软件开发的架构设计指的是什么？

软件架构（software

architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系

统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向

对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。

在“软件构架简介”中，David Garlan 和 Mary Shaw

认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结

构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。

但构架不仅是结构；IEEE Working Group

on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注

重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管

理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑

和流程。

一般而言，软件系统的架构（Architecture）有两个要素：

它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。

所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和

联结器完成某一项需求。

建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

软件开发一般比较会关注设计模式而不是架构设计，欢迎追问。