作为一名架构师，近来研发APP的一些经验总结。

前言

学如逆水行舟，不进则退。共勉！
iOS学习资料|领取地址

架构引人而异，不同的架构师有不同的看法；架构也因项目而异，不同的项目需求不同，相应的架构也会不同。但是万道不离其宗，有些东西还是通用的，是所有架构师需要掌握的，也是所有项目都会有的需求，比如像API如何设计？机构如何分层？开发环境如何分离？我负责研发过一些APP，像餐饮类的、社交类的、智能家居类的、电商类的、新媒体类的等等。当研发的这些经历多了，总会有点心得体会。接下来的内容都是根据我本身经历提炼出来的，关于这几个问题的一些经验分享，内容不多，旨在抛砖引玉。希望能给你带来小小的启发和帮助。

API

那就从从API开始吧

⼀个App，最核⼼的东⻄，其实就是数据，⽽数据的主要来源，就是API。我之前负责的项⽬，因为API的坑已经受过了不少苦，踩过不少坑。因此，之后对App项⽬的架构设计我都会先从API开始。

制定安全机制

设计API第⼀个需要考虑的是API的安全机制。我负责的上⼀个项⽬，因为API的安全问题，就被⼈攻击了两次。之后经过分析，主要存在两个漏洞：

• ⼀是因为缺少对调⽤者进⾏安全验证的⽅式

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

那么，制定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的值只有六种数据类型：

1. Number：整数或浮点数
2. String：字符串
3. Boolean：true 或 false
4. Array：数组包含在⽅括号[]中
5. Object：对象包含在⼤括号{}中
6. Null：空类型

我遇到过的，关于API的坑有⼤部分就是因为JSON数据和实体对象转化时出错导致的，⽽且是各种各样的错误都有，其中不乏有⼀些很奇葩的错误。

最麻烦的就是处理Date类型，因为JSON本身没有Date类型，因此，JSON库将Date类型的数据序列
化时会转为String。这时，不同环境，不同平台，以及⽤不同的JSON解析库，转换后的结果经常会
不同。⽐如，你在开发机上可能得到的结果是”2016-1-1 17:11:11”，但放到服务器后结果却变成了
“Jan 1,2016 5:11:11 PM” ，客户端进⾏反序列化时⽆疑会失败。后来，我取消了所有Date类型，统
⼀采⽤时间戳表示，就再没有转化的烦恼了。

另外，接⼝的开发⼈员有时候会将⼀些数据错误地转换为了String，导致客户端使⽤时因类型错误⽽
异常。例如，本来是数字的1，被转成了"1"，客户端做运算时就会出错，或⽤switch判断时也会出
错，或其他⽆法转换的情况发⽣时；例如，为空时JSON正确地表示应该是null，但如果转为了
String就变成了"null"，那问题就来了，我遇到的因为这个错误的转换导致的程序奔溃已经好⼏次
了，第⼀次的时候，查了⼀整天才定位到问题所在。

还有，因为接⼝的开发⼈员不同，很多时候还会出现不同接⼝同⼀个意思的参数名称却不同。⽐如，
对于有分⻚数据的接⼝，⼀般都有当前⻚的参数，A开发⼈员可能将参数命名为currentPage，第⼀
⻚是从0开始；B开发⼈员在另⼀个接⼝则命名为currPage，第⼀⻚却从1开始；C开发⼈员在另⼀个
接⼝⼜命名为presentPage，第⼀⻚⼜是从0开始。客户端的开发⼈员看到也是醉了。

每个技术团队⼀般都会有⼀份接⼝协议⽂档，主要内容包括每个接⼝的描述、⼊参、输出结果等，
但⼀般并不严谨，很多地⽅没有统⼀标准，从⽽容易出现很多坑。因此，有⼀份统⼀标准且严格执
⾏的接⼝协议⾮常重要。协议的内容除了规定每个接⼝，包括接⼝中每个数据具体的数据类型，还
需要规定⼀套共⽤的数据字典，以及其他需要统⼀定义的信息，⽐如签名算法等。⼀旦有了这份统
⼀标准且严格执⾏的接⼝协议，很多问题都将迎刃⽽解。

接⼝版本控制

我们已经不⽌⼀次因为接⼝发⽣变动⽽导致旧版本的App出错的问题，⽽且变动不⼀定是修改了接⼝ 本身，有可能是底层增加了⼀种新的数据结构，接⼝把新数据也返回给客户端了，但客户端旧版本 是解析不了的，从⽽就导致出错了。

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

每个接⼝有各⾃的版本，⼀般为接⼝添加个version的参数；

整个接⼝系统有统⼀的版本，⼀般在URL中添加版本号，⽐如api.domain.com/v2。平时⼩版本的更新…
更新，则⽤第⼆种⽅式，这时候，基本就是⼀套全新的接⼝系统了，跟旧版本是相对独⽴的。
当版本越来越多时，维护就会成为⼀个⼤问题，我们没那么多精⼒去维护所有版本，因此，太旧的
版本⼀般就不会再维护了。这时候，如果有⽤户还在使⽤即将废弃的旧版本，需要提醒⽤户升级到新版本。

架构分层

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时指定就可以
了。

• 业务层

业务层是数据加⼯者，主要就是从数据层获取数据，然后经过业务逻辑处理后转化成展示层需要的 数据。业务层因为夹在数据层和展示层中间，起着承上启下的作⽤。也因此，业务层很容易沦落为 只是⼀个数据的中转站，主要就是因为对业务层具体的作⽤和职责没有理解清楚。

这⾥⽤⼀个例⼦来说明业务层具体的⼯作吧，就举个⽤户注册的例⼦。⽤户注册时，界⾯上需要⽤
户提供⼿机号、短信验证码、密码、确认密码。那么，最简单的操作就是，带上这些参数调⽤数据
层的注册接⼝。好了，问题来了，注册接⼝并没有提供确认密码的参数。那好，调⽤注册接⼝之前
先判断下密码和确认密码是否⼀致，不⼀致则返回错误提示给⽤户，⼀致了才调⽤注册接⼝。好了，
第⼆个问题来了，⽤户等⽹络请求等了⼀段时间后，请求结果返回说⼿机号少了⼀位。下⼀次，⼜
等了⼀段时间，这次⼜返回说⼿机号多了⼀位。就因为⼀个⼩错误要让⽤户等那么久，⽤户肯定有
意⻅。后台也有意⻅，各种⾮法的请求都发过来，是嫌服务器压⼒不够⼤啊。那好，调⽤接⼝之前
对这些参数做有效性检查吧，⼿机号要规范，短信验证码只能为六位数字，密码不能少于六位。终
于注册成功了，第三个问题⼜来了，注册接⼝是没有返回⽤户的accessToken的，只有登录接⼝才会
返回。让⽤户⼿动再登录⼀下？这⽤户体验不太好啊。正确的姿势应该是注册成功后再⾃动调⽤⼀
次登录接⼝，如果因为⽹络问题第⼀次登录失败，后⾯还需要再⾃动调⽤多⼀次，如果还是调⽤失
败，才让⽤户⼿动登录。

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

业务层交付给展示层的数据也是通过接⼝的⽅式，不过，和数据层交付给业务层时不同的是：交付
给展示层的数据应该是通过异步回调返回的。因为获取数据是⼀个⽐较耗时的任务，通过异步回调
才不会阻塞UI主线程。

• 展示层

展示层作为数据展示者，它只要关⼼数据如何展示就可以了。不过，数据如何展示却不是那么简单。
展示层是三层架构中最复杂的⼀层了，要考虑的东⻄远远多于其他两层，涉及的东⻄包括但不限于
界⾯布局、屏幕适配、图⽚资源、⽂本资源、颜⾊资源等等。在开发⼀段时间后，展示层出现代码
混乱是最常⻅的。因此，做好展示层，就需要保持⾼质量的代码。要保持⾼质量代码，我觉得⾄少
应该遵循⼏条基本的原则：

1. 保持规范性：定义好开发规范，包括书写规范、命名规范、注释规范等，并按照规范严格执⾏；
2. 保持单⼀性：布局就只做布局，内容就只做内容，各⾃分离好，每个⽅法、每个类，也只做⼀件事情；
3. 保持简洁性：保持代码和结构的简洁，每个⽅法，每个类，每个包，每个⽂件，都不要塞太多代码或资源，感觉多了就应该拆分。

所谓⽆规矩不成⽅圆，展示层的设计，要从开发规范开始。⼀份好的开发规范，是保证代码有较⾼
的可读性的基础。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。实现上，最笨的⽅法就是拷⻉当前⼯程，然后修改，缺陷很明显，维护成本很⾼。不过，好在
Android和iOS都有很⽅便的修改⽅式。

Android有了Gradle，可以设置多个不同的Flavors，每个Flavor都有⼀个applicationId属性，其实就
是App的包名。⽐如，⽣产版和测试版的设置如下：

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⽂件⾥。

讲到最后还是求一波关注和点赞吧。希望能对你们有小小的启发和帮助。在给大家分享一下iOS方面的学习资料吧。

学习资料：领取地址