原文链接：http://keeganlee.me/post/architecture/20160303
版权声明：本文刊载在《程序猿》杂志2016年3期。版权归《程序猿》全部，未经许可不得转载
架构因人而异，不同的架构师大多会有不同的看法；架构也因项目而异，不同的项目需求不同，对应的架构也会不同。然而，有些东西还是通用的，是全部架构师都须要考虑的，也是全部项目都会有的需求，比方API怎样设计？架构怎样分层？开发环境和生产环境怎样分离？这几年，我负责研发过的App。有餐饮类的、社交类的、智能家居类的、电商类的、新闻媒体类的等等。当有了一定的经验之后，你总会有一些自己的心得体会。
而下面内容就是依据我的这些经历提炼出来的关于以上几个问题方面的经验总结，内容不多，旨在抛砖引玉。
从API開始
一个App。最核心的东西。事实上就是数据，而数据的主要来源，就是API。
我之前负责的项目，由于API的坑已经受过了不少苦，因此，之后对App项目的架构设计我都会先从API開始。
制定安全机制
设计API第一个须要考虑的是API的安全机制。我负责的上一个项目，由于API的安全问题，就被人攻击了两次。
之后经过分析，主要存在两个漏洞：一是由于缺少对调用者进行安全验证的方式。二是由于传输数据不够安全。
那么，制定API的安全机制，主要就是为了解决这两个问题：
- 保证API的调用者是经过自己授权的App。
- 保证传输数据的安全。
第一个问题的解决方式。我主要採用设计签名的方式。
对每一个client。Android、iOS、WeChat，分别分配一个AppKey和AppSecret。须要调用API时，将AppKey增加请求參数列表。并将AppSecret和全部參数一起。依据某种签名算法生成一个签名字符串，然后调用API时把该签名字符串也一起带上。服务端收到请求之后。依据请求中的AppKey查询对应的AppSecret。依照相同的签名算法，也生成一个签名字符串，当服务端生成的签名和请求带过来的签名一致的时候，那就表示这个请求的调用者是经过自己授权的，证明这个请求是安全的。
并且，每一个端都有一个Key。也方便不同端的标识和统计。为了防止AppSecret被别人获取。这个AppSecret一般写死在代码里面。
另外，签名算法也须要有一定的复杂度。不能轻易被别人破解。最好是採用自己规定的一套签名算法。而不是採用外部公开的签名算法。
另外，在參数列表中再增加一个时间戳，还能够防止部分重放攻击。
第二个问题的解决方式。主要就是採用HTTPS了。HTTPS由于加入了SSL安全协议。自己主动对请求数据进行了压缩加密。在一定程序能够防止监听、防止劫持、防止重发，主要就是防止中间人攻击。苹果从iOS9開始。默认就採用HTTPS了。
而关于在Android中怎样使用HTTPS，Google官方也给出了非常多安全建议。
只是，大部分App并没有依照安全建议去实现。主要就是没有对SSL证书进行安全性检查，这就成为了一个非常大的漏洞。中间人利用此漏洞用假证书就能够通过检查，从而能够劫持到全部数据了。
因此，为了安全考虑，建议对SSL证书进行强校验。包含签名CA是否合法、域名是否匹配、是不是自签名证书、证书是否过期等。
接口协议标准化
API返回的数据，一般都是採用JSON格式进行传输。然而。JSON的值仅仅有六种数据类型：
- Number：整数或浮点数
- String：字符串
- Boolean：true 或 false
- Array：数组包括在方括号[]中
- Object：对象包括在大括号{}中
- Null：空类型
我遇到过的，关于API的坑有大部分就是由于JSON数据和实体对象转化时出错导致的。并且是各种各样的错误都有，当中不乏有一些非常奇葩的错误。
最麻烦的就是处理Date类型。由于JSON本身没有Date类型。因此，JSON库将Date类型的数据序列化时会转为String。
这时。不同环境。不同平台，以及用不同的JSON解析库，转换后的结果常常会不同。
比方，你在开发机上可能得到的结果是”2016-1-1 17:11:11”。但放到server后结果却变成了“Jan 1,2016 5:11:11 PM” ，client进行反序列化时无疑会失败。后来，我取消了全部Date类型，统一採用时间戳表示，就再没有转化的烦恼了。
另外。接口的开发者有时候会将一些数据错误地转换为了String，导致client使用时因类型错误而异常。比如，本来是数字的1。被转成了"1"。client做运算时就会出错，或用switch推断时也会出错。或其它无法转换的情况发生时；比如，为空时JSON正确地表示应该是null。但假设转为了String就变成了"null"，那问题就来了，我遇到的由于这个错误的转换导致的程序奔溃已经好几次了。第一次的时候。查了一整天才定位到问题所在。
还有，由于接口的开发者不同，非常多时候还会出现不同接口同一个意思的參数名称却不同。比方，对于有分页数据的接口。一般都有当前页的參数，A开发者可能将參数命名为currentPage。第一页是从0開始。B开发者在还有一个接口则命名为currPage，第一页却从1開始；C开发者在还有一个接口又命名为presentPage，第一页又是从0開始。client的开发者看到也是醉了。
每一个技术团队一般都会有一份接口协议文档，主要内容包含每一个接口的描写叙述、入參、输出结果等，但一般并不严谨。非常多地方没有统一标准，从而easy出现非常多坑。因此。有一份统一标准且严格运行的接口协议非常重要。
协议的内容除了规定每一个接口。包含接口中每一个数据详细的数据类型。还须要规定一套共用的数据字典，以及其它须要统一定义的信息。比方签名算法等。一旦有了这份统一标准且严格运行的接口协议。非常多问题都将迎刃而解。
接口版本号控制
我们已经不止一次由于接口发生变动而导致旧版本号的App出错的问题，并且变动不一定是改动了接口本身，有可能是底层添加了一种新的数据结构，接口把新数据也返回给client了。但client旧版本号是解析不了的，从而就导致出错了。
为了解决接口的兼容性问题，须要做好接口版本号控制。实现上。一般有两种做法：
- 每一个接口有各自的版本号。一般为接口加入个version的參数；
- 整个接口系统有统一的版本号，一般在URL中加入版本号号，比方http://api.domain.com/v2。
平时小版本号的更新，就採用第一种方式，我们的做法是依据不同版本号号做不同分支处理。大版本号的更新，则用另外一种方式，这时候。基本就是一套全新的接口系统了，跟旧版本号是相对独立的。
当版本号越来越多时。维护就会成为一个大问题。我们没那么多精力去维护全部版本号，因此。太旧的版本号一般就不会再维护了。
这时候。假设实用户还在使用即将废弃的旧版本号，须要提醒用户升级到新版本号。
架构分层
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的，仅仅有登录接口才会返回。让用户手动再登录一下？这用户体验不太好啊。正确的姿势应该是注冊成功后再自己主动调用一次登录接口，假设由于网络问题第一次登录失败。后面还须要再自己主动调用多一次，假设还是调用失败，才让用户手动登录。
上面的样例中，对參数的有效性检查。注冊成功后的自己主动登录，都属于业务逻辑的处理，也就是说都是业务层的工作。
业务层交付给展示层的数据也是通过接口的方式，只是，和数据层交付给业务层时不同的是：交付给展示层的数据应该是通过异步回调返回的。由于获取数据是一个比較耗时的任务。通过异步回调才不会堵塞UI主线程。
展示层
展示层作为数据展示者，它仅仅要关心数据怎样展示就能够了。只是，数据怎样展示却不是那么简单。展示层是三层架构中最复杂的一层了。要考虑的东西远远多于其它两层，涉及的东西包含但不限于界面布局、屏幕适配、图片资源、文本资源、颜色资源等等。在开发一段时间后，展示层出现代码混乱是最常见的。
因此，做好展示层，就须要保持高质量的代码。要保持高质量代码，我认为至少应该遵循几条主要的原则：
- 保持规范性：定义好开发规范，包含书写规范、命名规范、凝视规范等，并依照规范严格运行。
- 保持单一性：布局就仅仅做布局。内容就仅仅做内容，各自分离好，每一个方法、每一个类。也仅仅做一件事情。
- 保持简洁性：保持代码和结构的简洁，每一个方法。每一个类，每一个包，每一个文件。都不要塞太多代码或资源，感觉多了就应该拆分。
所谓无规矩不成方圆。展示层的设计。要从开发规范開始。一份好的开发规范，是保证代码有较高的可读性的基础。
iOS方面，苹果已经有一套Coding
Guidelines，主要属于命名方面的规范。当我们制定自己的开发规范时。首先就要遵守苹果的这份规范。在此基础上再加上自己的规范。Android方面，我也在我的博客中分享过一套（Android技术积累:开发规范）。主要分为书写规范、命名规范、凝视规范三部分。
最重要的不是开发规范的制定，而是开发规范的运行。
假设没有依照开发规范去运行，那开发规范就等于形同虚设。那代码混乱的问题依旧得不到解决。
说到单一性，面向对象设计中，有一个基本原则就是单一职责原则，它规定一个类应该仅仅有一个发生变化的原因。
保持单一性是减低耦合度的关键标准，其目的就是各方面的解耦。
而我这里说的单一性不仅仅是规定类的单一，也包含界面的单一、方法的单一、资源文件的单一等。
界面的单一，首先是界面的布局和界面的数据应该分离。
另外。界面数据的获取和展示也应该分离。一句话。保持界面的单一性就是要保持界面上每一个维度都做好分离，从界面的布局。到数据的获取，数据的检查，数据的展示。
方法的单一，则表现为一个方法是对一个行为的封装。行为又能够拆分为多个步骤，每一个步骤事实上也是更细化的行为。
因此，方法嵌套方法是一种常态。
那么。保持方法的单一性，关键不在于怎么定义这种方法的行为。而在于这个行为要怎么拆分成更细的行为。
举个样例，通常在Activity的onCreate方法。做初始化操作，细分出来就分为了：控件的初始化、逻辑变量的初始化、数据的初始化。数据的初始化又能够再细分：数据的获取、数据的展示。
每一个细化的行为都应该封装为一个独立的方法，这样，才真正符合方法的单一性。
资源文件的单一，主要是指Android的各类资源文件。包含存放字符串的strings.xml，存放字符串数组的arrays.xml，存放颜色值的colors.xml，存放尺寸值的dimens.xml，等等。资源文件的单一，是说全部相关的资源信息要在资源文件中定义并引用到代码或布局文件中，而不是在代码或布局文件中直接定义。
这样做，能够非常方便地做各种适配和改动，比方支持国际化。比方不同分辨率的屏幕用不同尺寸值。iOS则没有提供和Android一样的资源文件分离的机制，但能够參考Android的做法自己去实现。
环境分离
每一个App项目，至少都会有两个环境：測试环境和生产环境。多的甚至有四个环境：开发环境、測试环境、预生产环境和生产环境。
开发者常常须要在环境之间切换，測试人员也相同。常常出现測试人员今天须要測试环境的最新版本号，叫App开发者打包一个给她。明天须要切换到生产版本号，再叫App开发者打包一个生产环境的给她。
我们知道，一个App。在一台手机上要么仅仅能是測试环境的，要么仅仅能是生产环境的。測试人员要測试两个环境，仅仅能不断替换不同环境的同个App，这实在太麻烦了。为了解决此问题，最好的方案就是环境分离，不同环境有不同的App。
一个App的唯一标识，Android是用包名，iOS是用Bundle Identify。那么。在一个系统想安装不同环境的App。仅仅要每一个环境App的包名和Bundle Identify不同就可以。比方，生产版的包名和Bundle Identify命名为com.mydomain.myapp，測试版的包名和Bundle Identify则命名为com.mydomain.myapp.beta，这样。Android和iOS都会识别为两个不同的App了。
只是，仅仅改包名和Bundle Identify是不够的，应用图标和应用名称也要改动，不然安装之后非常难区分哪个App是哪个环境的。一般做法就是，非生产环境的App图标就是在生产图标的基础上加入一个环境标签，同一时候App的应用名称也是在生产的基础上加入环境后缀名。另外，由于包名和Bundle Identify不同了。微信、微博、百度地图等这些第三方平台也都须要为不同环境的App分别申请不同的appID。
实现上。最笨的方法就是拷贝当前project。然后改动，缺陷非常明显。维护成本非常高。只是，好在Android和iOS都有非常方便的改动方式。
Android有了Gradle。能够设置多个不同的Flavors，每一个Flavor都有一个applicationId属性，事实上就是App的包名。比方，生产版和測试版的设置例如以下：
productFlavors {
myapp {
applicationId "com.mydomain.myapp"
}
myappBeta {
applicationId 'com.mydomain.myapp.beta'
}
}
这样，事实上就有两个App了。然后，源码新建一个和main同级的文件夹，命名为myappBeta，然后，将图标、名称和第三方设置之类的。和main保持一样的位置、文件名称、属性等。就能够替换成环境相关的了。
iOS则能够通过创建多个环境的Target来实现环境分离，不同Target能够设置不同的Bundle Identify、Bundle display name、更换图标。另外，每一个Target也各自有自己的一份plist文件的，环境变量和第三方设置之类的，都能够设置在对应的plist文件中。
写在最后
至此，关于App架构方面的经验总结就先讲这么多了。
当中，部分内容在我以往的博客上也已经有所体现。有兴趣的读者能够前往我的博客了解并欢迎參与讨论。