手机APP软件，属于CS架构么？

不全属于C/S架构，手机APP软件除了C/S架构，还有单机版APP，B/S架构等类型的APP。

在C/S结构中，应用程序分为两部分:服务器部分和客户机部分。服务器部分是多个用户共享的信息与功能，执行后台服务。典型的如一些聊天APP，视频APP等就是作为本地客户机，与服务器端进行信息交流、请求等，属于典型的C/S结构。

B/S架构中，客户机上只要安装一个浏览器，如Netscape Navigator或Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互。手机中就有许多浏览器应用，是属于B/S架构的。当然手机中还有一些单机版游戏等应用。

扩展资料：

C/S和B/S的比较：

1、硬件环境的比较：

CS建立在局域网的基础上，局域网之间再通过专门服务器提供连接和数据交换服务。在CS结构中，客户机和服务器都需要处理数据任务，这就对客户机的硬件提出了较高的要求。BS结构建立在广域网之上，不必配备专门的网络硬件环境。

2、系统维护 、 升级的比较

CS结构中的每一个客户机都必须安装和配置相关软件，如 *** 作系统、客户端软件等。BS结构中每一个客户端只需通过浏览器便可进行各种信息的处理，而不需要安装客户端软件，维护、升级等几乎所有的工作都在服务器端进行，如果系统需要升级，只需要将升级程序安装在服务器端即可。

参考资料来源：百度百科-B/S架构

参考资料来源：百度百科-C/S架构

树状结构。

树状结构是一个或多个节点的有限集合。

树状结构有一个特定的点称为根节点（root），树状结构其余的节点分成n个独立的集合T1,?,Tn，每个集合也都是一个树状结构。T1,?,Tn为根节点的子树（subtree）。

视图是指计算机数据库中的视图，是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。

但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。

扩展资料

视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图的作用类似于筛选。定义视图的筛选可以来自当前或其它数据库的一个或多个表，或者其它视图。分布式查询也可用于定义使用多个异类源数据的视图。

视图是存储在数据库中的查询的SQL语句，它主要出于两种原因：安全原因，视图可以隐藏一些数据，如：社会保险基金表，可以用视图只显示姓名，地址，而不显示社会保险号和工资数等，另一原因是可使复杂的查询易于理解和使用。

参考资料来源：百度百科-树状结构

参考资料来源：百度百科-视图

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

---