APP架构

架构因人而异，不同的架构师会有不同的看法；架构因项目而异，不同的项目需求不同，架构也自然会不同，脱离业务的架构就是耍流氓；然而有些东西还是通用的，是所有架构师需要考虑的、也是所有项目都会有的需求。比如：API如何设计、架构如何分层、各种环境如何分离(开发/测试/发布...)

一：API如何设计？

一个APP，最核心的东西就是数据，而数据的主要来源就是API，一个优质的API会给项目开发、维护、健壮性等方面带来比较大的提升

1、安全机制    数据安全是设计一个API必要考虑的因素，主要存在的两个漏洞 1⃣️缺少对调用者进行安全验证的方式  2⃣️数据传输不安全

第1个问题，保证API的调用者是经过自己授权的。解决方案：采用设计签名的方式，对每个客户的分配一个AppKey和AppSecret。调用API时将AppKey与AppSecret加入请求参数，并将AppSecret和所有参数一起根据某种签名方法生成一个签名串。服务端收到请求后，根据请求中的AppKey查询响应的AppSecret，按照同样的签名算法也生成一个签名串，如果二者一致，那么认为是安全的(签名算法最好采用自己的一套签名)。另外在参数列表中加入一个时间戳还可以防止重放攻击。

第2个问题，保证数据传输是安全的。 解决方案：HTTPS因为添加了SSL安全协议，⾃动对请求数据进行了压缩加密，在一定程序可以防止监听、防⽌劫持、防止重发，主要就是防止中间人攻击

2、接口协议标准化

API一般采用JSON数据进行传输，然而JSON的值只有6中数据类型

    Number：整数或浮点数

    String：字符串

    Boolean：true/false

    Array：数组（包含在[]中）

    Object：对象（包含在打括号[]中）

    Null：空类型

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

比如：因为JSON本身没有Date类型，JSON库将Date类型的数据序列化时会转为String，不同环境，不同平台，以及用不同的JSON解析库，转换后的结果经常会不同。比如，在开发机上可能得到的结果是”2020-03-13 08:11:11”，但放到服务器后结果却变成了 “Mar 13,2020 05:11:11 AM” ，客户端进⾏反序列化时无疑会失败

        接⼝的开发人员有时候会将⼀些数据错误地转换为String，导致客户端使用时因类型错误⽽异常。例如，本来是数字的1，被转成了"1"，客户端做运算时就会出错，或用switch判断时也会出错，或其他无法转换的情况发生时; 例如，为空时JSON正确地表示应该是null，但如果转为了了 String就变成了了"null"，这些错误都可能导致程序Crash

因此，有一份统一标准且严格执行的接⼝协议⾮常重要。协议的内容除了规定每个接⼝，包括接口中每个数据具体的数据类型，还需要规定⼀套共用的数据字典，以及其他需要统⼀定义的信息，比如签名算法等。⼀旦有了这份统一标准且严格执行的接口协议，很多问题都将迎刃而解    

3、接口版本控制

为了解决接口的兼容性，最要做好版本控制。实际上有2种做法

方法1⃣️：每个接口有各自的版本，一般为接口参数中定义version字段

方法2⃣️：整个接口系统有统一的版本，一般在URL中添加版本号 https://xxx.api.v1

二：架构分层

前面已经说过一个APP最重要的是数据，那么从APP对数据处理的角色划分，最简单的划分就是：数据管理、数据处理、数据展示。相应的也就有了数据层、业务层、展示层，三者的关系是：数据层在最底层，往下接入API，往上它向业务层提交数据。业务层在中间，负责数据的加工，将数据层提交的数据加工成展示层需要的格式。展示层在最上层，主要就是将业务层取得的数据进行展示

1、数据层    数据层是数据的管理者，主要任务就是封装API，并将结果向上层提交数据

整体流程如下

1⃣️：业务层向数据层请求数据

2⃣️：数据层检查缓存中有没有请求需要的数据;

3⃣️：如果有缓存数据，则直接返回缓存数据;

4⃣️：如果没有缓存数据，则从网络API获取数据，并将数据加入缓存，然后返回数据;

调⽤网络API时，还要判断⽹络状态，根据不同状态做不同处理。如果⽹络不可用，就无需发起请求了。网络可⽤时，也要区分是连接WIFI还是连接移动网络。连接移动网络时，⼀一般需要限制调用⽐较耗流量的请求。连接WIFI时，则无需设置这种限制，⽽且还可以预先请求一些接口，比如请求当前分页数据时，可以将下一页的数据也预先请求

缓存也需要缓存策略，不同的接口需要做不同的缓存处理。首先，缓存只适用于获取数据的接口， 对于修改数据的接口则不适用。其次，不同接⼝缓存时间一般也不同，对于很少变动的数据缓存时间可以设置⻓一些，而频繁变动的数据缓存时间则⽐较短，甚⾄不进行缓存。最后，缓存数据因为比较多，我们一般保存在数据库，而对于调用频高、最新的数据，还会在内存中也拥有⼀份缓存， 不过缓存时间比较短。请求缓存数据时，会先检查内存缓存中有没有，有则直接将缓存的数据返回，没有才从数据库获取（内存+磁盘双缓存机制）

如何将数据交付给业务层呢?这是整个数据层模块与外部交互的部分，当与外部交互的时候， ⼀般都要符合面向接口编程的原则，因此只要提供开放的数据接⼝就可以了。对于接口的参数需要说明⼀下，上面提到的参数有appKey、version，还有签名sign、时间戳time， 其实可以分为两类:系统参数和业务参数。像appKey、version、sign、time这些属于系统参数，⽽currentPage，或username之类的则属于业务参数。数据层开放的数据接口的参数只需要包含业务参数就可以了，业务层并不需要关⼼系统参数是什么，系统参数在数据层内部封装API时指定就可以 了。

2、业务层

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

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

3、展示层

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

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

2⃣️：保持单一性，布局就只做布局，内容就只做内容，各自分离好，每个方法、每个类，也只做⼀件事情

3⃣️：保持简洁性，保持代码和结构的简洁，每个方法，每个类，每个包，每个文件，都不不要塞太多代码或资源，感觉多了就应该拆分

说到单一性，⾯向对象设计中，有⼀个基本原则就是单一职责原则，它规定一个类应该只有一个发生变化的原因。保持单一性是减低耦合度的关键标准，其⽬的就是各⽅面的解耦。而这⾥说的单⼀性不只是规定类的单一，也包括界面的单一、方法的单一、资源文件的单一等。

界面的单一，⾸先是界面的布局和界面的数据应该分离。另外，界面数据的获取和展示也应该分离。 一句话，保持界⾯的单一性就是要保持界面上每个维度都做好分离，从界面的布局，到数据的获取， 数据的检查，数据的展示。

⽅法的单一，则表现为⼀个方法是对⼀个行为的封装。行为又可以拆分为多个步骤，每个步骤其实也是更细化的行为。因此，方法嵌套方法是一种常态。那么，保持方法的单一性，关键不在于怎么定义这个⽅法的行为，而在于这个行为要怎么拆分成更细的行为。举个例子，通常在ViewController的 viewDidLoad方法，做初始化操作，细分出来就分为了:控件的初始化、逻辑变量的初始化、数据的初始化。数据的初始化又可以再细分:数据的获取、数据的展示。每个细化的行为都应该封装为一个独⽴的方法，这样，才真正符合方法的单一性

三：环境分离

每个App项目，⾄少都会有两个环境:测试环境和生产环境。多的甚⾄有四个环境:开发环境、测试 环境、预⽣产环境和生产环境。开发人员经常需要在环境之间切换，测试人员也同样。经常出现测试人员今天需要测试环境的最新版本，叫App开发⼈人员打包⼀个给她，明天需要切换到生产版本，再叫App开发人员打包一个生产环境的给她。我们知道，一个App，在一台⼿手机上要么只能是测试环境 的，要么只能是⽣产环境的。最好的方案就是环境分离，不同环境有不同的App

根据以上设计经验，即可设计出一个高内聚、低耦合的APP架构，具体路线是：产品需求（驱动）接口设计（驱动）APP架构设计 具体到一个APP或者一个组件中，可以采用各自的设计结构(MVC、MVVM、MVP、VIPER...)

以上是一些个人工作经验的整理总结，抛砖引玉，与各位简友共享，后续会陆续推出如何抽离一个组件，抽离原则以及MVC、MVVM、MVP、VIPER各种设计模式的使用实战等