App架构经验总结
然而，有些东西还是通用的。是全部架构师都须要考虑的，也是全部项目都会有的需求，比方API怎样设计？架构怎样分层？开发环境和生产环境怎样分离？这几年，我负责研发过的App，有餐饮类的、社交类的、智能家居类的、电商类的、新闻媒体类的等等。当有了一定的经验之后，你总会有一些自己的心得体会。而下面内容就是依据我的这些经历提炼出来的关于以上几个问题方面的经验总结，内容不多。旨在抛砖引玉。
从API開始
制定安全机制
- 保证API的调用者是经过自己授权的App；
- 保证传输数据的安全。
须要调用API时，将AppKey增加请求參数列表。并将AppSecret和全部參数一起，依据某种签名算法生成一个签名字符串。然后调用API时把该签名字符串也一起带上。服务端收到请求之后，依据请求中的AppKey查询对应的AppSecret。依照相同的签名算法，也生成一个签名字符串。当服务端生成的签名和请求带过来的签名一致的时候。那就表示这个请求的调用者是经过自己授权的，证明这个请求是安全的。
并且，每一个端都有一个Key，也方便不同端的标识和统计。
为了防止AppSecret被别人获取，这个AppSecret一般写死在代码里面。另外，签名算法也须要有一定的复杂度。不能轻易被别人破解。最好是採用自己规定的一套签名算法，而不是採用外部公开的签名算法。另外。在參数列表中再增加一个时间戳。还能够防止部分重放攻击。
HTTPS由于加入了SSL安全协议，自己主动对请求数据进行了压缩加密，在一定程序能够防止监听、防止劫持、防止重发，主要就是防止中间人攻击。苹果从iOS9開始。默认就採用HTTPS了。而关于在Android中怎样使用HTTPS，Google官方也给出了非常多安全建议。只是。大部分App并没有依照安全建议去实现。主要就是没有对SSL证书进行安全性检查，这就成为了一个非常大的漏洞，中间人利用此漏洞用假证书就能够通过检查，从而能够劫持到全部数据了。因此，为了安全考虑。建议对SSL证书进行强校验。包含签名CA是否合法、域名是否匹配、是不是自签名证书、证书是否过期等。
接口协议标准化
然而，JSON的值仅仅有六种数据类型：
- Number：整数或浮点数
- String：字符串
- Boolean：true 或 false
- Array：数组包括在方括号[]中
- Object：对象包括在大括号{}中
- Null：空类型
比方，你在开发机上可能得到的结果是”2016-1-1 17:11:11”，但放到server后结果却变成了“Jan 1,2016 5:11:11 PM” ，client进行反序列化时无疑会失败。
后来。我取消了全部Date类型，统一採用时间戳表示，就再没有转化的烦恼了。
接口版本号控制
实现上。一般有两种做法：
- 每一个接口有各自的版本号，一般为接口加入个version的參数；
- 整个接口系统有统一的版本号。一般在URL中加入版本号号。比方http://api.domain.com/v2。
架构分层
早期的时候，Android就是将全部操作都放在Activity里完毕，包含界面数据处理、业务逻辑处理、调用API。
后来发现Activity越来越臃肿，代码越来越复杂，非常难维护。于是就開始思考怎样拆分，怎样才干做到松耦合高内聚。
对应的也就有了三层架构：数据层、业务层、展示层。
它们之间的关系例如以下图。数据层是三层中的最底层。往下，它接入API；往上。它向业务层交付数据。业务层夹在三层中间，属于数据的加工厂，将数据层提供上来的数据加工成展示层须要展示的数据。展示层处于三层中的最上层，主要就是将从业务层取得的数据展示到界面上。
数据层
整个主流程例如以下图：
- 业务层向数据层请求数据；
- 数据层检查缓存中有没有请求须要的数据；
- 假设有缓存数据，则直接返回缓存数据；
- 假设没有缓存数据，则从网络API获取数据。并将数据增加缓存。然后返回数据。
以前，我们没有对移动网络状态下的请求进行限制，结果，測试时流量DuangDuangDuang地一下子就不见了十几M。连接WIFI时，则无需设置这样的限制，并且还能够预先请求一些接口，比方请求当前分页数据时，能够将下一页的数据也预先请求。
首先，缓存仅仅适用于获取数据的接口。对于改动数据的接口则不适用。
其次，不同接口缓存时间一般也不同。对于非常少变动的数据缓存时间能够设置长一些，而频繁变动的数据缓存时间则比較短。甚至不进行缓存。
最后，缓存数据由于比較多，我们一般保存在数据库。而对于调用频率高、最新的数据，还会在内存中也拥有一份缓存，只是缓存时间比較短。
请求缓存数据时。会先检查内存缓存中有没有。有则直接将缓存的数据返回，没有才从数据库获取。
像appKey、version、sign、time这些属于系统參数。而currentPage，或username之类的则属于业务參数。数据层开放的数据接口的參数仅仅须要包括业务參数就能够了，业务层并不须要关心系统參数是什么。系统參数在数据层内部封装API时指定就能够了。
业务层
业务层由于夹在数据层和展示层中间，起着承上启下的作用。也因此，业务层非常easy沦落为仅仅是一个数据的中转站，主要就是由于对业务层详细的作用和职责没有理解清楚。
那么，最简单的操作就是，带上这些參数调用数据层的注冊接口。好了，问题来了，注冊接口并没有提供确认password的參数。那好，调用注冊接口之前先推断下password和确认password是否一致。不一致则返回错误提示给用户，一致了才调用注冊接口。好了，第二个问题来了，用户等网络请求等了一段时间后。请求结果返回说手机号少了一位。下一次。又等了一段时间。这次又返回说手机号多了一位。就由于一个小错误要让用户等那么久。用户肯定有意见。后台也有意见，各种非法的请求都发过来，是嫌server压力不够大啊。那好。调用接口之前对这些參数做有效性检查吧。手机号要规范，短信验证码仅仅能为六位数字，password不能少于六位。最终注冊成功了。第三个问题又来了，注冊接口是没有返回用户的accessToken的，仅仅有登录接口才会返回。
让用户手动再登录一下？这用户体验不太好啊。正确的姿势应该是注冊成功后再自己主动调用一次登录接口，假设由于网络问题第一次登录失败，后面还须要再自己主动调用多一次，假设还是调用失败，才让用户手动登录。
由于获取数据是一个比較耗时的任务。通过异步回调才不会堵塞UI主线程。
展示层
因此。做好展示层。就须要保持高质量的代码。要保持高质量代码。我认为至少应该遵循几条主要的原则：
- 保持规范性：定义好开发规范，包含书写规范、命名规范、凝视规范等。并依照规范严格运行；
- 保持单一性：布局就仅仅做布局，内容就仅仅做内容。各自分离好，每一个方法、每一个类，也仅仅做一件事情；
- 保持简洁性：保持代码和结构的简洁。每一个方法，每一个类，每一个包，每一个文件，都不要塞太多代码或资源，感觉多了就应该拆分。
一份好的开发规范。是保证代码有较高的可读性的基础。
iOS方面，苹果已经有一套Coding Guidelines，主要属于命名方面的规范。
当我们制定自己的开发规范时，首先就要遵守苹果的这份规范。在此基础上再加上自己的规范。
Android方面，我也在我的博客中分享过一套（Android技术积累:开发规范），主要分为书写规范、命名规范、凝视规范三部分。
数据的初始化又能够再细分：数据的获取、数据的展示。每一个细化的行为都应该封装为一个独立的方法。这样，才真正符合方法的单一性。
资源文件的单一，是说全部相关的资源信息要在资源文件中定义并引用到代码或布局文件中。而不是在代码或布局文件中直接定义。这样做。能够非常方便地做各种适配和改动，比方支持国际化，比方不同分辨率的屏幕用不同尺寸值。iOS则没有提供和Android一样的资源文件分离的机制。但能够參考Android的做法自己去实现。
环境分离
我们知道。一个App，在一台手机上要么仅仅能是測试环境的，要么仅仅能是生产环境的。測试人员要測试两个环境，仅仅能不断替换不同环境的同个App，这实在太麻烦了。
为了解决此问题，最好的方案就是环境分离，不同环境有不同的App。
那么。在一个系统想安装不同环境的App。仅仅要每一个环境App的包名和Bundle Identify不同就可以。
比方，生产版的包名和Bundle Identify命名为com.mydomain.myapp。測试版的包名和Bundle Identify则命名为com.mydomain.myapp.beta，这样。Android和iOS都会识别为两个不同的App了。
另外，由于包名和Bundle Identify不同了。微信、微博、百度地图等这些第三方平台也都须要为不同环境的App分别申请不同的appID。
productFlavors { myapp { applicationId "com.mydomain.myapp" } myappBeta { applicationId 'com.mydomain.myapp.beta' } }
浙公网安备 33010602011771号