移动App架构经验总结 _App架构

架构也因项目而异。不同的项目需求不同，对应的架构也会不同。
架构分层API的设计完毕之后。接下来我就会考虑App项目的总体架构了。总体怎样架构，我也以前做过不少尝试。
早期的时候，Android就是将全部操作都放在Activity里完毕，包含界面数据处理、业务逻辑处理、调用API 。
后来发现Activity越来越臃肿，代码越来越复杂，非常难维护。于是就開始思考怎样拆分，怎样才干做到松耦合高内聚。
前面也说过，一个App的核心就是数据，那么，从App对数据处理的角色划分出发，最简单的划分就是：数据管理、数据加工、数据展示。
对应的也就有了三层架构：数据层、业务层、展示层。
它们之间的关系例如以下图。数据层是三层中的最底层。往下，它接入API；往上。它向业务层交付数据。业务层夹在三层中间，属于数据的加工厂，将数据层提供上来的数据加工成展示层须要展示的数据。展示层处于三层中的最上层，主要就是将从业务层取得的数据展示到界面上。

数据层

数据层是数据管理者。主要任务就是封装API，并将数据结果交付给上层，中间会再加个数据缓存。
整个主流程例如以下图：

业务层向数据层请求数据；
数据层检查缓存中有没有请求须要的数据；
假设有缓存数据，则直接返回缓存数据；
假设没有缓存数据，则从网络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的，仅仅有登录接口才会返回。