博客摘录「 App架构总结」2023年6月7日

API重点一：安全机制

        安全机制是很重要的点，因为安全机制在一开始不考虑进去，程序也能正常展现，功能也能正常，大家都会忽视掉，但当出现问题时，都是严重问题，而且解决的话要从底层维护。安全机制可以通过两个方面来进行保障，一是API的安全校验机制，二是数据传输安全性。关于安全校验机制，我觉得签名的方式是可以解决的，就是给各个端分别配一个AppKey和AppSecet，在API调用的时候，将AppSecet作为参数传递，并且与其他参数一起根据签名算法生成签名字符串，在服务端收到请求时，进行同样算法签名，核对是否一致。关于数据传输安全，作为APP开发，我认为HTTPS协议很好进行了保障。HTTPS因为加入了SSL安全协议。

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

API重点三：接口版本控制

APP架构设计：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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