App架构总结

App架构相关总结

题外语：其实前两年都有意识到自己的累积输出太少，尽管也经常在印象笔记、备忘录等地方进行记录，但没有一个系统的整理，对自己所学也没能有一个很好的总结索引，因此，调整习惯是刻不容缓的事情。最近刚好在看一些架构类的材料，就顺带记录下自己对于架构的一些总结。

 

每个项目首先是根据需求产生的，而不同的人对于架构设计有不同的看法。但很多架构思维还是通用的。比如API的设计、架构的分层、开发坏境与生产环境的分离等等。

我认为一个App，最核心的东西应该是数据，而数据的主要来源就是API了。一般架构设计，通常会从API开始着手。

API重点一：安全机制

我认为有个很重要的点容易被忽视，就是安全机制。为什么呢？因为安全机制在一开始不考虑进去，程序也能正常展现，功能也能正常，大家都会忽视掉，但一旦出现问题，都是重大问题，而且解决的话要从基地上调整。

安全机制可以通过两个方面来进行保障，一是API的安全校验机制，二是数据传输安全性。

关于安全校验机制，我觉得签名的方式是可以解决的，就是给各个端分别配一个AppKey和AppSecet，在API调用的时候，将AppSecet作为参数传递，并且与其他参数一起根据签名算法生成签名字符串，在服务端收到请求时，进行同样算法签名，核对是否一致。

关于数据传输安全，作为ios开发，我认为HTTPS协议很好进行了保障。HTTPS因为加入了SSL安全协议。从ios9开始，默认采用HTTPS了。

API重点二：接口协议标准化

API返回数据，一般都是JSON格式，而JSON里包含了六种数据类型：

Number,String,Boolean,Array,Object,Null,我自己开发过程中遇到很多坑都是因为JSON数据和实体对象转化出错导致的，这一点填坑也是很多。总结了几点，希望开发过程中注意。

1.Date类型处理，Json本省没有Date格式，Json 序列化时会将Date转换为String，不同环境不同平台解析出来的结果可能不一致，所以我认为最好都用时间戳的格式，避免不同平台问题。

2.开发人员将错误数据类型转换为了String，导致异常。比如null被转换成“null”,有些判断就会导致崩溃。

3.同一个含义的接口参数，不同开发人员制定了不同的名称，或者制定了不同的含义如当前页这个参数，A命名为currentPage，第一页从0开始，B命名为currPage，第一页从1开始，这样对应客户端开发时，也是很容易一脸懵。

API重点三：接口版本控制

在开发版本迭代过程中，不止一次出现因接口变动导致旧版本出错问题，或者旧接口出现问题，这种变动可能不一定是接口本省，有可能是底层数据结构变动导致解析问题，所以对于接口兼容性，最好就是做好接口版本控制。

每个接口增加version参数，版本迭代的时候对应更新版本号。

 

继API之后，就应该是整体APP架构设计，因为APP核心是数据，那么根据App对数据处理简单角色划分可以分为：数据管理、数据加工、数据展示。也就是我们通常的三层架构：数据层、业务层、展示层。

 

数据层就是数据管理者，主要任务就是封装API，并将数据结果提交给上层，中间再加个数据缓存。整个过程主要流程包含：

1.业务层向数据层请求数据；

2.数据层检查缓存中是否有所需数据；

3.有缓存数据，返回缓存数据；

4.没有缓存数据，则通过网络API获取数据。

API调用时，还需要有网络状态判断，不同网络状态不同处理。比如WIFI及移动网络，考虑用户体验问题。

而数据怎么交付给业务层呢？那就需要遵循面向接口编程原则，开发数据接口就可以了。需要注意的是，接口参数一般分为系统参数和业务参数。

业务层就是数据加工者。主要是从数据层获取数据，经过业务逻辑处理转化成展示层需要的数据。业务层处于数据层和展示层之间，起到承上启下的作用。也因此，开发时，很容易将业务层沦为数据总中转站。

比如一个注册页面，需要手机号、短息验证码、密码、确认密码，当然，最简单操作就是直接将这些参数调用数据层的注册接口。但这时候就有个问题，接口是没有确认密码的，那是注册前先判断密码和确认密码是否一致，不一致给用户提示，一致再继续注册。但又有一个问题，注册请求一段时间后，返回结果，说手机号多一位或手机号少一位，或者格式等等不对，那对于用户来说，格式有问题还要等一段时间，体验不好，对于服务端来说，各种非法请求让服务器压力更大，这就不合理了。再一个问题，当用户注册成功后，肯定是想要登录啊，注册接口一般是不会返回用户token的，难道再让用户登录一次么，这样体验就不好了，正确应该是程序自动为用户进行一次登录，登录失败才会让用户手动登录。

这里说的参数格式验证、注册后自动登录都是属于业务层逻辑，都应该归属于业务层。

业务层给展示层数据也是通过接口，但需要注意的是，给展示层应该采用异步线程回调返回。取数据是耗时工作，异步才能保障UI主线程流畅不被阻塞。

展示层就是数据展示者。主要关心数据展示就可以了。数据展示直接关系到用户体验，这时候需要更为多的考虑了。

页面布局、屏幕适配、图片资源、文本资源、颜色资源等等。我觉得展示层很重要的几点原则有：

1.规范性：开发规范一开始就制定好，命名规范、代码规范、注释规范，并且严格执行

2.单一性：布局就单纯布局，内容就单纯内容，每个方法每个类，只做一件事

3.简洁性：代码和结构简洁，多了就拆分

苹果官方有一份Coding Guidelines，这是命名规范，我觉得我们应该基于苹果这份规范基础上，加上自己规范。