架构也因项目而异。不同的项目需求不同，对应的架构也会不同。

架构分层

API的设计完毕之后。接下来我就会考虑App项目的总体架构了。总体怎样架构，我也以前做过不少尝试。

早期的时候，Android就是将全部操作都放在Activity里完毕，包含界面数据处理、业务逻辑处理、调用API。

后来发现Activity越来越臃肿，代码越来越复杂，非常难维护。于是就開始思考怎样拆分，怎样才干做到松耦合高内聚。

前面也说过，一个App的核心就是数据，那么，从App对数据处理的角色划分出发，最简单的划分就是：数据管理、数据加工、数据展示。

对应的也就有了三层架构：数据层、业务层、展示层。

它们之间的关系例如以下图。数据层是三层中的最底层。往下，它接入API；往上。它向业务层交付数据。业务层夹在三层中间，属于数据的加工厂，将数据层提供上来的数据加工成展示层须要展示的数据。展示层处于三层中的最上层，主要就是将从业务层取得的数据展示到界面上。

数据层

数据层是数据管理者。主要任务就是封装API，并将数据结果交付给上层，中间会再加个数据缓存。

整个主流程例如以下图：

1. 业务层向数据层请求数据；
2. 数据层检查缓存中有没有请求须要的数据；
3. 假设有缓存数据，则直接返回缓存数据；
4. 假设没有缓存数据，则从网络API获取数据。并将数据增加缓存。然后返回数据。

调用网络API时。还要推断网络状态，依据不同状态做不同处理。假设网络不可用。就无需发起请求了。网络可用时，也要区分是连接WIFI还是连接移动网络。连接移动网络时，一般须要限制调用比較耗流量的请求。

以前，我们没有对移动网络状态下的请求进行限制，结果，測试时流量DuangDuangDuang地一下子就不见了十几M。连接WIFI时，则无需设置这样的限制，并且还能够预先请求一些接口，比方请求当前分页数据时，能够将下一页的数据也预先请求。

缓存也须要缓存策略，不同的接口须要做不同的缓存处理。

首先，缓存仅仅适用于获取数据的接口。对于改动数据的接口则不适用。

其次，不同接口缓存时间一般也不同。对于非常少变动的数据缓存时间能够设置长一些，而频繁变动的数据缓存时间则比較短。甚至不进行缓存。

最后，缓存数据由于比較多，我们一般保存在数据库。而对于调用频率高、最新的数据，还会在内存中也拥有一份缓存，只是缓存时间比較短。

请求缓存数据时。会先检查内存缓存中有没有。有则直接将缓存的数据返回，没有才从数据库获取。

那么，怎样将数据交付给业务层呢？这是整个数据层模块与外部交互的部分。当与外部交互的时候，一般都要符合面向接口编程的原则，因此仅仅要提供开放的数据接口就能够了。对于接口的參数须要说明一下，上面提到的參数有appKey、version、currentPage这几个。还有签名sign、时间戳time，事实上能够分为两类：系统參数和业务參数。

像appKey、version、sign、time这些属于系统參数。而currentPage，或username之类的则属于业务參数。数据层开放的数据接口的參数仅仅须要包括业务參数就能够了，业务层并不须要关心系统參数是什么。系统參数在数据层内部封装API时指定就能够了。

业务层

业务层是数据加工者，主要就是从数据层获取数据。然后经过业务逻辑处理后转化成展示层须要的数据。

业务层由于夹在数据层和展示层中间，起着承上启下的作用。也因此，业务层非常easy沦落为仅仅是一个数据的中转站，主要就是由于对业务层详细的作用和职责没有理解清楚。

这里用一个样例来说明业务层详细的工作吧。就举个用户注冊的样例。用户注冊时，界面上须要用户提供手机号、短信验证码、password、确认password。

那么，最简单的操作就是，带上这些參数调用数据层的注冊接口。好了，问题来了，注冊接口并没有提供确认password的參数。那好，调用注冊接口之前先推断下password和确认password是否一致。不一致则返回错误提示给用户，一致了才调用注冊接口。好了，第二个问题来了，用户等网络请求等了一段时间后。请求结果返回说手机号少了一位。下一次。又等了一段时间。这次又返回说手机号多了一位。就由于一个小错误要让用户等那么久。用户肯定有意见。后台也有意见，各种非法的请求都发过来，是嫌server压力不够大啊。那好。调用接口之前对这些參数做有效性检查吧。手机号要规范，短信验证码仅仅能为六位数字，password不能少于六位。最终注冊成功了。第三个问题又来了，注冊接口是没有返回用户的accessToken的，仅仅有登录接口才会返回。

让用户手动再登录一下？这用户体验不太好啊。正确的姿势应该是注冊成功后再自己主动调用一次登录接口，假设由于网络问题第一次登录失败，后面还须要再自己主动调用多一次，假设还是调用失败，才让用户手动登录。

上面的样例中，对參数的有效性检查，注冊成功后的自己主动登录，都属于业务逻辑的处理，也就是说都是业务层的工作。

业务层交付给展示层的数据也是通过接口的方式。只是，和数据层交付给业务层时不同的是：交付给展示层的数据应该是通过异步回调返回的。

由于获取数据是一个比較耗时的任务。通过异步回调才不会堵塞UI主线程。

展示层

展示层作为数据展示者，它仅仅要关心数据怎样展示就能够了。只是。数据怎样展示却不是那么简单。展示层是三层架构中最复杂的一层了。要考虑的东西远远多于其它两层。涉及的东西包含但不限于界面布局、屏幕适配、图片资源、文本资源、颜色资源等等。在开发一段时间后。展示层出现代码混乱是最常见的。

因此。做好展示层。就须要保持高质量的代码。要保持高质量代码。我认为至少应该遵循几条主要的原则：

1. 保持规范性：定义好开发规范，包含书写规范、命名规范、凝视规范等。并依照规范严格运行；
2. 保持单一性：布局就仅仅做布局，内容就仅仅做内容。各自分离好，每一个方法、每一个类，也仅仅做一件事情；
3. 保持简洁性：保持代码和结构的简洁。每一个方法，每一个类，每一个包，每一个文件，都不要塞太多代码或资源，感觉多了就应该拆分。

所谓无规矩不成方圆，展示层的设计。要从开发规范開始。

一份好的开发规范。是保证代码有较高的可读性的基础。

IOS方面，苹果已经有一套Coding Guidelines，主要属于命名方面的规范。

当我们制定自己的开发规范时，首先就要遵守苹果的这份规范。在此基础上再加上自己的规范。

Android方面，我也在我的博客中分享过一套（Android技术积累:开发规范），主要分为书写规范、命名规范、凝视规范三部分。

最重要的不是开发规范的制定。而是开发规范的运行。假设没有依照开发规范去运行，那开发规范就等于形同虚设，那代码混乱的问题依旧得不到解决。

说到单一性。面向对象设计中。有一个基本原则就是单一职责原则。它规定一个类应该仅仅有一个发生变化的原因。保持单一性是减低耦合度的关键标准。其目的就是各方面的解耦。而我这里说的单一性不仅仅是规定类的单一。也包含界面的单一、方法的单一、资源文件的单一等。

界面的单一，首先是界面的布局和界面的数据应该分离。另外。界面数据的获取和展示也应该分离。一句话，保持界面的单一性就是要保持界面上每一个维度都做好分离，从界面的布局。到数据的获取，数据的检查，数据的展示。

方法的单一。则表现为一个方法是对一个行为的封装。行为又能够拆分为多个步骤，每一个步骤事实上也是更细化的行为。因此。方法嵌套方法是一种常态。那么，保持方法的单一性，关键不在于怎么定义这种方法的行为，而在于这个行为要怎么拆分成更细的行为。举个样例。通常在Activity的onCreate方法，做初始化操作。细分出来就分为了：控件的初始化、逻辑变量的初始化、数据的初始化。

数据的初始化又能够再细分：数据的获取、数据的展示。每一个细化的行为都应该封装为一个独立的方法。这样，才真正符合方法的单一性。

资源文件的单一，主要是指Android的各类资源文件，包含存放字符串的strings.xml。存放字符串数组的arrays.xml。存放颜色值的colors.xml。存放尺寸值的dimens.xml，等等。

资源文件的单一，是说全部相关的资源信息要在资源文件中定义并引用到代码或布局文件中。而不是在代码或布局文件中直接定义。这样做。能够非常方便地做各种适配和改动，比方支持国际化，比方不同分辨率的屏幕用不同尺寸值。iOS则没有提供和Android一样的资源文件分离的机制。但能够參考Android的做法自己去实现。