1. 从API开始

（ ⼀一个App，最核⼼心的东⻄西，其实就是数据，⽽而数据的主要来源，就是API ）

1.1 制定API安全机制

主要存在两个漏漏洞洞:⼀一是因为缺少对调⽤用者进⾏行行安全验证的⽅方式，⼆二

是因为数据传输不不够安全。

主要解决问题：1.保证API的调⽤用者是经过⾃自⼰己授权的App    2.保证数据传输的安全

第一个问题的解决⽅方案，我主要采⽤用设计签名的⽅方式：

对每个客户端，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:空类型

每个技术团队⼀一般都会有⼀一份接⼝口协议⽂文档，主要内容包括每个接⼝口的描述、⼊入参、输出结果等，

但⼀一般并不不严谨，很多地⽅方没有统⼀一标准，从⽽而容易易出现很多坑。因此，有⼀一份统⼀一标准且严格执

⾏行行的接⼝口协议⾮非常重要。协议的内容除了了规定每个接⼝口，包括接⼝口中每个数据具体的数据类型，还

需要规定⼀一套共⽤用的数据字典，以及其他需要统⼀一定义的信息，⽐比如签名算法等。⼀一旦有了了这份统

⼀一标准且严格执⾏行行的接⼝口协议，很多问题都将迎刃⽽而解。

接⼝口版本控制

我们已经不不⽌止⼀一次因为接⼝口发⽣生变动⽽而导致旧版本的App出错的问题，⽽而且变动不不⼀一定是修改了了接⼝口

本身，有可能是底层增加了了⼀一种新的数据结构，接⼝口把新数据也返回给客户端了了，但客户端旧版本

是解析不不了了的，从⽽而就导致出错了了。

为了了解决接⼝口的兼容性问题，需要做好接⼝口版本控制。实现上，⼀一般有两种做法:

每个接⼝口有各⾃自的版本，⼀一般为接⼝口添加个version的参数;

整个接⼝口系统有统⼀一的版本，⼀一般在URL中添加版本号，⽐比如http://api.domain.com/v2。

平时⼩小版本的更更新，就采⽤用第⼀一种⽅方式，我们的做法是根据不不同版本号做不不同分⽀支处理理。⼤大版本的

更更新，则⽤用第⼆二种⽅方式，这时候，基本就是⼀一套全新的接⼝口系统了了，跟旧版本是相对独⽴立的。

当版本越来越多时，维护就会成为⼀一个⼤大问题，我们没那么多精⼒力力去维护所有版本，因此，太旧的

版本⼀一般就不不会再维护了了。这时候，如果有⽤用户还在使⽤用即将废弃的旧版本，需要提醒⽤用户升级到

新版本。

2.代码层

从App对数据处理理的⻆角⾊色划分出发，最简单的划分就

是:数据管理理、数据加⼯工、数据展示。相应的也就有了了三层架构:数据层、业务层、展示层。它们

之间的关系如下图，数据层是三层中的最底层，往下，它接⼊入API;往上，它向业务层交付数据。业

务层夹在三层中间，属于数据的加⼯工⼚厂，将数据层提供上来的数据加⼯工成展示层需要展示的数据。

展示层处于三层中的最上层，主要就是将从业务层取得的数据展示到界⾯面上。

数据层

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

整个主流程如下图:

业务层向数据层请求数据;

数据层检查缓存中有没有请求需要的数据;如果有缓存数据，则直接返回缓存数据;如果没有缓存数据，则从⽹网络

API获取数据，并将数据加⼊入缓存，然后返回数据。

调⽤用⽹网络API时，还要判断⽹网络状态，根据不不同状态做不不同处理理。如果⽹网络不不可⽤用，就⽆无需发起请求

了了。⽹网络可⽤用时，也要区分是连接WIFI还是连接移动⽹网络。连接移动⽹网络时，⼀一般需要限制调⽤用⽐比

较耗流量量的请求。曾经，我们没有对移动⽹网络状态下的请求进⾏行行限制，结果，测试时流量量DuangDuangDuang地⼀一下⼦子就不不⻅见了了⼗十⼏几M。连接WIFI时，则⽆无需设置这种限制，⽽而且还可以预先

请求⼀一些接⼝口，⽐比如请求当前分⻚页数据时，可以将下⼀一⻚页的数据也预先请求。

缓存也需要缓存策略略，不不同的接⼝口需要做不不同的缓存处理理。⾸首先，缓存只适⽤用于获取数据的接⼝口，

对于修改数据的接⼝口则不不适⽤用。其次，不不同接⼝口缓存时间⼀一般也不不同，对于很少变动的数据缓存时

间可以设置⻓长⼀一些，⽽而频繁变动的数据缓存时间则⽐比较短，甚⾄至不不进⾏行行缓存。最后，缓存数据因为

⽐比较多，我们⼀一般保存在数据库，⽽而对于调⽤用频率⾼高、最新的数据，还会在内存中也拥有⼀一份缓存，

不不过缓存时间⽐比较短。请求缓存数据时，会先检查内存缓存中有没有，有则直接将缓存的数据返回，

没有才从数据库获取。

那么，如何将数据交付给业务层呢?这是整个数据层模块与外部交互的部分，当与外部交互的时候，

⼀一般都要符合⾯面向接⼝口编程的原则，因此只要提供开放的数据接⼝口就可以了了。对于接⼝口的参数需要

说明⼀一下，上⾯面提到的参数有appKey、version、currentPage这⼏几个，还有签名sign、时间戳time，

其实可以分为两类:系统参数和业务参数。像appKey、version、sign、time这些属于系统参数，⽽而

currentPage，或username之类的则属于业务参数。数据层开放的数据接⼝口的参数只需要包含业务

参数就可以了了，业务层并不不需要关⼼心系统参数是什什么，系统参数在数据层内部封装API时指定就可以

了了。

业务层

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

数据。业务层因为夹在数据层和展示层中间，起着承上启下的作⽤用。也因此，业务层很容易易沦落为

只是⼀一个数据的中转站，主要就是因为对业务层具体的作⽤用和职责没有理理解清楚。

这⾥里里⽤用⼀一个例例⼦子来说明业务层具体的⼯工作吧，就举个⽤用户注册的例例⼦子。⽤用户注册时，界⾯面上需要⽤用

户提供⼿手机号、短信验证码、密码、确认密码。那么，最简单的操作就是，带上这些参数调⽤用数据

层的注册接⼝口。好了了，问题来了了，注册接⼝口并没有提供确认密码的参数。那好，调⽤用注册接⼝口之前

先判断下密码和确认密码是否⼀一致，不不⼀一致则返回错误提示给⽤用户，⼀一致了了才调⽤用注册接⼝口。好了了，

第⼆二个问题来了了，⽤用户等⽹网络请求等了了⼀一段时间后，请求结果返回说⼿手机号少了了⼀一位。下⼀一次，⼜又

等了了⼀一段时间，这次⼜又返回说⼿手机号多了了⼀一位。就因为⼀一个⼩小错误要让⽤用户等那么久，⽤用户肯定有

意⻅见。后台也有意⻅见，各种⾮非法的请求都发过来，是嫌服务器器压⼒力力不不够⼤大啊。那好，调⽤用接⼝口之前

对这些参数做有效性检查吧，⼿手机号要规范，短信验证码只能为六位数字，密码不不能少于六位。终

于注册成功了了，第三个问题⼜又来了了，注册接⼝口是没有返回⽤用户的accessToken的，只有登录接⼝口才会

返回。让⽤用户⼿手动再登录⼀一下?这⽤用户体验不不太好啊。正确的姿势应该是注册成功后再⾃自动调⽤用⼀一

次登录接⼝口，如果因为⽹网络问题第⼀一次登录失败，后⾯面还需要再⾃自动调⽤用多⼀一次，如果还是调⽤用失

败，才让⽤用户⼿手动登录。

上⾯面的例例⼦子中，对参数的有效性检查，注册成功后的⾃自动登录，都属于业务逻辑的处理理，也就是说

都是业务层的⼯工作。

业务层交付给展示层的数据也是通过接⼝口的⽅方式，不不过，和数据层交付给业务层时不不同的是:交付

给展示层的数据应该是通过异步回调返回的。因为获取数据是⼀一个⽐比较耗时的任务，通过异步回调

才不不会阻塞UI主线程。

展示层

展示层作为数据展示者，它只要关⼼心数据如何展示就可以了了。不不过，数据如何展示却不不是那么简单。

展示层是三层架构中最复杂的⼀一层了了，要考虑的东⻄西远远多于其他两层，涉及的东⻄西包括但不不限于

界⾯面布局、屏幕适配、图⽚片资源、⽂文本资源、颜⾊色资源等等。在开发⼀一段时间后，展示层出现代码

混乱是最常⻅见的。因此，做好展示层，就需要保持⾼高质量量的代码。要保持⾼高质量量代码，我觉得⾄至少

应该遵循⼏几条基本的原则:

保持规范性:定义好开发规范，包括书写规范、命名规范、注释规范等，并按照规范严格执⾏行行;

保持单⼀一性:布局就只做布局，内容就只做内容，各⾃自分离好，每个⽅方法、每个类，也只做⼀一件

事情;

保持简洁性:保持代码和结构的简洁，每个⽅方法，每个类，每个包，每个⽂文件，都不不要塞太多代

码或资源，感觉多了了就应该拆分。

所谓⽆无规矩不不成⽅方圆，展示层的设计，要从开发规范开始。⼀一份好的开发规范，是保证代码有较⾼高

的可读性的基础。iOS⽅方⾯面，苹果已经有⼀一套Coding Guidelines，主要属于命名⽅方⾯面的规范。当我

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

说到单⼀一性，⾯面向对象设计中，有⼀一个基本原则就是单⼀一职责原则，它规定⼀一个类应该只有⼀一个发

⽣生变化的原因。保持单⼀一性是减低耦合度的关键标准，其⽬目的就是各⽅方⾯面的解耦。⽽而我这⾥里里说的单

⼀一性不不只是规定类的单⼀一，也包括界⾯面的单⼀一、⽅方法的单⼀一、资源⽂文件的单⼀一等。

界⾯面的单⼀一，⾸首先是界⾯面的布局和界⾯面的数据应该分离。另外，界⾯面数据的获取和展示也应该分离。

⼀一句句话，保持界⾯面的单⼀一性就是要保持界⾯面上每个维度都做好分离，从界⾯面的布局，到数据的获取，

数据的检查，数据的展示。

⽅方法的单⼀一，则表现为⼀一个⽅方法是对⼀一个⾏行行为的封装。⾏行行为⼜又可以拆分为多个步骤，每个步骤其实

也是更更细化的⾏行行为。因此，⽅方法嵌套⽅方法是⼀一种常态。那么，保持⽅方法的单⼀一性，关键不不在于怎么

定义这个⽅方法的⾏行行为，⽽而在于这个⾏行行为要怎么拆分成更更细的⾏行行为。举个例例⼦子，通常在Activity的onCreate⽅方法，做初始化操作，细分出来就分为了了:控件的初始化、逻辑变量量的初始化、数据的初

始化。数据的初始化⼜又可以再细分:数据的获取、数据的展示。每个细化的⾏行行为都应该封装为⼀一个

独⽴立的⽅方法，这样，才真正符合⽅方法的单⼀一性。

每个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。

实现上，最笨的⽅方法就是拷⻉贝当前⼯工程，然后修改，缺陷很明显，维护成本很⾼高。不不过，好在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⽂文件⾥里里。