App架构经验总结
架构因⼈而异，不同的架构师⼤多会有不同的看法;架构也因项⽬而异，不同的项⽬需求不同，相 应的架构也会不同。然⽽，有些东西还是通用的，是所有架构师都需要考虑的，也是所有项⽬都会 有的需求，⽐如API如何设计?架构如何分层?开发环境和生产环境如何分离?这⼏年，我负责研发 过的App，有餐饮类的、社交类的、智能家居类的、电商类的、新闻媒体类的等等。当有了一定的经 验之后，你总会有⼀些⾃己的⼼得体会。⽽以下内容就是根据我的这些经历提炼出来的关于以上⼏个问题⽅面的经验总结，内容不多，旨在抛砖引玉。
从API开始 ⼀个App，最核心的东⻄西，其实就是数据，⽽数据的主要来源，就是API。我之前负责的项目，因为API的坑已经受过了不少苦，因此，之后对App项⽬目的架构设计我都会先从API开始。 制定安全机制
设计API第一个需要考虑的是API的安全机制。我负责的上一个项⽬，因为API的安全问题，就被⼈攻击了两次。之后经过分析，主要存在两个漏洞:⼀是因为缺少对调用者进行安全验证的方式，⼆ 是因为数据传输不够安全。那么，制定API的安全机制，主要就是为了解决这两个问题:
保证API的调⽤者是经过⾃己授权的App; 保证数据传输的安全。
第⼀个问题的解决方案，我主要采用设计签名的⽅式。对每个客户端，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”，但放到服务器后结果却变成了“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中添加版本号，比如http://api.domain.com/v2。平时小版本的更新，就采⽤第⼀种⽅方式，我们的做法是根据不同版本号做不同分⽀处理。大版本的更新，则用第⼆种方式，这时候，基本就是⼀套全新的接口系统了了，跟旧版本是相对独⽴立的。当版本越来越多时，维护就会成为一个⼤问题，我们没那么多精⼒去维护所有版本，因此，太旧的版本⼀般就不会再维护了。这时候，如果有⽤用户还在使用即将废弃的旧版本，需要提醒用户升级到新版本。
架构分层
API的设计完成之后，接下来我就会考虑App项⽬的整体架构了。整体如何架构，我也曾经做过不少 尝试。早期的时候，Android就是将所有操作都放在Activity里完成,iOS放在controll里完成，包括界面数据处理、业务逻辑处 理、调用API。后来发现Activity和控制器越来越臃肿，代码越来越复杂，很难维护。于是就开始思考如何拆 分，如何才能做到松耦合⾼内聚。
前面也说过，⼀个App的核⼼心就是数据，那么，从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，主要属于命名⽅面的规范。当我 们制定⾃己的开发规范时，首先就要遵守苹果的这份规范，在此基础上再加上⾃己的规范。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的包名。⽐比如，⽣产版和测试版的设置如下:
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文件里。
网友评论