手机app是什么架构(app的框架结构是什么)

安卓手机的软件听说是java开发的，我想知道的开发的是cs软件还是BS的。求大神详解！！

android开发的主流是java,。CS、BS一般指架构，java大多用于BS的。学习java推荐千锋教育。千锋教育十一年来，千锋以政策为引导，不断完善国内特色现代职业教育体系建设，充分发挥教研师资队伍使命，构建品质教育。

Java开发的安卓软件具备的优势：

1、Java语言是发展最快的程序语言，具有面向对象的特点，比较通俗易懂；

2、Java语言的显著特点就是简单，继承了C++语言的先进精华，是计算程序语言发展的一大进步；

3、Java语言拥有独立的体系结构，可以不受限制，随意在任何系统当中运行，所以体系结构的中立决定了Java语言可以在不同的计算机结构中得以运行。使用Java语言开发的不同程序在不同结构的计算机显示的语言位数却是统一的。

想要了解更多java开发的相关信息，推荐咨询千锋教育。千锋Java现已拥有成熟独立的项目库，项目均1：1引进大厂项目，授课采用 CREA 项目研发模型，即 Cooperation、Research、Exercise、Alliance，以项目促进高质量教学。多场景，多学科联动为学员的技能实战提供高度还原的真实演练场，充分赋能学员简历价值，打造企业直聘班，得到广大学员一致认可。

手机上安装的美团app属于C/S系统

手机上安装的美团app不属于CS系统

美团平台是saas架构。

越来越多的餐饮企业开始摆脱传统模式，踏上技术之路。在今天的餐饮江湖，其基础设施更多指的是移动互联网、大数据、商业配套以及餐饮供应链的成熟。什么是餐饮SaaS？SaaS是Software as a Service（软件即服务）的简称，餐饮SaaS即服务提供商通过软硬件，即APP、小程序、集合码、收银机等获取数据，例如客户数据、订单数据、资金数据等，并根据数据为餐饮行业经营者提供帮助其达成降本增效等经营目标的服务。在餐饮SaaS系统的普及上，现在很多企业能做到把线下的客流数据化。

手机app访问数据库通常是什么结构

一个完整的APP是由数据库、服务端以及前端组成。

1、想要使APP能够被正常使用，那么构建一个数据库就是必不可少的一道程序，更是开发一个软件的首要前提。因为任何东西都要存放在数据库中，我们用的时候都要从数据库中读取。数据库就好似一个大型的中央枢纽。

2、服务端，它的作用就是负责把数据从数据库里面搬出来，处理一些逻辑问题之后，交接给前端。服务端一般是开发APP的商家所拥有的，为客户服务的。服务端实现了客户端所不能实现的功能，提供前端获取数据接口，提供数据库，提供一些数据库机无法存储的多媒体资料，提供一部分程序逻辑。

3、前端就是负责显示的部分，主要目标就是显示的美化好看，方便用户看。此外还要设计允许用户提交信息的界面，然后把数据返回给服务端。

如何设计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传递数据，绝不进行网络请求和缓存读写。