一名架构师的职责是解放公司第一生产力(程序员们)脱离制造轮子的繁复工作。好的架构设计是要经得起检验的，但是它未必经得住时间的考验，任何框架和架构都会在熊熊的社区烈火考验中被逐步淘汰。在这篇文章会详细介绍APP的设计，APP的框架选型，以及APP后台服务的交互通信安全方面的问题。
互联网时间的指针已经指向了2017年，我们手机的空间越来越大，手机中的APP应用也越来越多，每一个应用所占用的内存也是越来越多，似乎现在的我们已经不太在乎每一个APP应用的大小了，那么我们在使用和体验这些APP的时候，我们在乎的是什么呢？
在13年到15年的时候，app 在UI设计上充斥了很多同质化的产品，手机银行，直销银行这两类APP，更是在内容上存在同质化，当然这与其行业特性分不开。但是，现在到了2017年，UI设计师们在dribbble和behance的风格影响下，有了更多的发展空间，不得不说的是，现在的app比之前越来越好看和越来越好用了。
这里有一个关键的问题就出现了，为什么有些app，普通用户一打开就自然而然地觉得它很美？用户这种“觉得它很美”的意识到底是从哪儿来的？为了阐述用户这种“觉得他很美”的意识的来源，就必须要了解app中“内容”和“形式”之间的关系。
那我们不妨来了解一下内容和形式的关系。内容是集成在app中所有可被感知的图片、文字、声音的合集。之所以说是可被感知，主要是从用户层面上看，忽略用户不可感知的”代码”层面。那么我们必要搞要清楚的是，一个app的内容到底是如何产生的？
假如有一天，一家银行找到我们说，做一个手机银行APP，我们这里参考招商银行。打开招商APP，参考他的UI设计和功能设计。这个时候开始思考这款app的MVP状态应该需要什么功能：
MVP=Minimum Viable product（最小可行产品）是《精益创业》的作者埃里克·莱斯提出提出的一个概念，意思就是可保证产品正常使用（主逻辑闭环）的最小产品单元。MVP又分为Validating MVP和Invalidating MVP，《精益创业》是一本特别赞的书，推荐大家阅读。
▲********内容设计APP内容设计需要包含：“首页”是核心，主要提现手机银行的核心功能，账户，转账，信用卡还款等， “理财”将银行的各类理财产品以分类列表的形式展现，生活类的类似于电商APP提现各类活动和生活应用，“我的”里面会有账户总览，收支记录等一堆东西。其实这个时候，产品设计师已经在定义产品的信息架构了。内容就是这样产生了。
▲********形式设计如果说把所有集成在app中，可感知的图文声的集合都可以称作app的内容的话，那app的形式就是“承载内容，使内容更好被感知的方式”。
人有五感，视觉、听觉、嗅觉、味觉、触觉。而人去和一款手机应用进行交互的时候只会从视觉，听觉，触觉（反馈）三个方面去感知，而触觉涉及到交互层面， 关于听觉其实也不是本文重点。
举个例子，比如大家都用过滴滴，滴滴有一个“内容（功能）”是司机送一个乘客的过程中，当判断距离目的地很近的时候会默认进行一个“下一单的匹配”的功能。我们用滴滴的这个功能来对比手机游戏里面的“匹配下一局”，我们会发现这是几乎相同的“内容”，但是承载形式不一样，手游是视觉展现，你必须点击手机上的“匹配”按钮，而滴滴因为考虑到司机在开车很难解放双手去点击匹配，所以从产品逻辑上设计的是“语音提示+主动匹配+手动接单”的方式，所以我们总能在快下出租车的时候听到司机手机上传出响亮的“开始接单啦”语音提示。
一款APP的设计过程，从无到有，大概就是如此。
【前端工具介绍】
大多做APP的是从WEB开发转化而来的，如果要在这里说说前端的发展之路，这可能又要开始一篇新的文章了。这些年来，前端的框架如同雨后春笋，层出不穷。一直以来，许多软件公司都希望开发一套框架来统一处理前端的所有问题，例如Facebook开发和维护的React，用于支持起WhatsApp和Instagram产品，它目前是GitHub上最受欢迎的项目之一，再如Google推出的Angular系列框架用于其Adwords,Fiber项目，还有号称轻量级低门槛的Vue，等等。
各家公司封装的前端框架都有各自的侧重点，并不能全部的解决所有问题，当然，他们也都解决了前端需要共同面对的问题：组件化，数据绑定以及平台无关的Render机制，我第一次听说Render这个词，是在学习ExtJs(其在前端实现类似后端服务的MVC模式给我及其深刻的印象)。
2007年到2009年，对于前端开发来说，这是一个极其重要的时间段。因为2007年Apple发布了IPhone1（IPhone在中国的大爆发是从4和4S开始的，123这3代在国内基本上没有人知道），而2009年诞生了NodeJS。两个缺一不可的主角终于登场了！
IPhone把人类带入了移动互联网时代，而NodeJS把前端开发带入了工业化时代！所以，以2009年为界，你会发现，2009年之后出现的所有前端框架（包括CSS和JS标准），都会做一件事：那就是必须要兼容移动端的小屏幕！于是，老一代桌面端框架的光环开始褪色，2009年首先出现了AngularJS、2014年底诞生了React、2015年初诞生了Vue，移动互联时代的前端技术开始大爆炸啦！
目前来看，React、Angular、Vue基本上处于三足鼎立的态势。
Angular是一个功能丰富的框架，React是一个丰富的UI组建库，Vue是一个号称最易入门，最轻量级的框架，从这三者的对比上来看，解决前端的思路主要有：
一是，高效的渲染技术加丰富的组件库，开发人员只需要拖拽来用即可。
二是，是给开发后端服务的程序员们一个进入前端开发的学习机会，例如后台服务的MVC思想引入前端，出现了ExtJs（针对4以上的版本），例如Angular中引入的TypeScript,这对原来有.NET语言和Java语言基础的同学来说非常容易。
【APP后台服务架构】
当设计APP后台架构的时候，根据架构框架，采用以下4点设计APP架构：▪ 根据APP的设计，梳理出APP的业务流程，把每个业务流程列出；▪ 把每个业务流程可能会遇到的问题整理出来；▪ 根据整理出的问题，探讨可行的技术解决方案；▪ 把第三点中的所有技术解决方案有机融合，就是一个APP后台的初步架构。
每个APP都有独自的业务逻辑，遇到的问题会不一样，解决方案也不一样，因此架构也不尽相同。APP的架构演变是由业务驱动的，架构是为了满足业务的需求而设计的，技术人员不该过度设计，学了一堆最新，最炫的技术并将其放进架构，这是不合适的。技术是为了满足业务而存在。
APP和APP后台的通信是用HTTP协议还是私有协议，是用长连接还是短连接？使用通用语言通信还是使用暗语通信？
▲****HTPP协议OR私有协议
协议就相当于一套语言，双方都知道每个字节的具体含义，网络通信中有很多通用协议，其中HTTP协议就是使用最广泛的一种。大多数开发语言都支持通用协议，有大量成熟的模块供程序员调用，方便程序员解析这些通用协议的内容，使用私有协议就相当于使用暗语通信，其类似于开发一套新的语言。
私有协议对协议的封装和拆解工作量大，App程序员和后台程序员都要增加额外的工作量，而且私有协议对程序员的设计能力要求高，从WEB网站转向移动开发的开发者上手有一定的困难，除非开发者对App的安全性和性能要求高，不然选择HTTP协议就足够了。
▲长****连接OR短连接
长连接短连接的选择问题。我想作为一名成熟的开发者来说，应该是非常明白的。我们的服务器资源是有限的，所以长连接并不太合适，但是，在一些场景下，我们又不得不用长连接，例如我们的消息推送，还有手游，这些场景为了做到数据的及时性，长连接又是必然的选择。
▲通信****安全
安全，是在做APP时最应该关心的领域。提到安全，回到我们曾经熟悉的领域，WEB前端。做WEB的时候，为了做到安全，一些核心的数据和内容，往往是放在后端session中的，传统的WEB网站使用Cookie+Session保持用户的登录状态，那么在App后台怎么实现类似的功能呢？在App后台怎么避免每次验证用户身份都需要传输用户名和密码呢？
假设如下场景：把App后台想象为一个房间，里面有个房间管理员，同时房间门有一把锁，这把锁有两种打开方式：(1)输入了这把锁上注册的用户名和密码；(2)用房间管理员提供的钥匙。
用户进入这个房间的流程如下：用户第一次输入锁上注册的用户名和密码打开这把锁后进入房间，找到房间管理员让其提供一把钥匙。以后用户每次需要进入这个房间用这把钥匙就行，不用担心旁边有人偷看到自己的用户名和密码，从而导致用户名和密码泄漏。(3)用户决定一段时间内不再进入这个房间了，又怕钥匙被偷，进入房间后把钥匙归还给管理员，让管理员把钥匙销毁。这里对应上我们的APP登录过程，用下图来表示
生成token的流程如下：
注意，这个方案是不安全的，身份验证依赖token字符串，如果用户泄漏了URL，那token也就泄漏了。这相当于钥匙被黑客复制了一份。那么我们如何来保障App的通信安全呢？
身份验证依赖于token，token被我们拿着满大街的跑，生怕黑客不知道我们的token可以来校验用户信息。所以，不能拿着钥匙满大街的跑。
因此不在网络上传输token就能很大程度上防止token泄漏。那么不在网络上传输token的方案呼之欲出了，这个方案被叫做URL签名，方案如下：在上一个方案版本中，Redis中除了维护token字符串和用户信息的对应关系，还要维护用户id和token的对应关系，以方便后面APP后台验证URL签名时快速查找。
假设API请求为”test.com/user/info”,APP用token字符串” daf32asd12w”和URL的md5值作为URL签名
APP后台接收到这个URL后，用和APP前端相同的签名算法生成签名和sign参数对比，如果发现相等就表示验证通过，继续执行这个API的其他逻辑。
但是，这个URL前面方法还有一个问题：假设在API请求
没有过期期间，黑客截获了这个API请求的URL,就能反复调用这个URL.那怎么解决呢？可能有的小伙伴想到一个办法了，我们的信息不是保存在Redis中的吗，如果验证完一次，我的token值就删掉一次重新生成一个，不就解决了吗？但事实证明，这不是一个很好的解决方案，为何呢？
因为如果黑客截获了这个url，可以反复不停地pin你的服务器，给你的服务器带来很大的压力，并且，这样做了之后，对于那些手里有钥匙的真正的客户来说，他也用不了，因为他手里的token已经被之前黑客攻击使用的url给改变了。
那么这里有一个改进的方案，就是在传递参数中增加时间戳，当App后台发现这个时间戳相隔当前时间很久的，就判断这个URL已经失效。但是，APP端使用时间戳存在一个问题是：App端的时间有可能和APP后台服务的时间不一致。
保证APP端和APP后台时间同步的方法为：APP每次启动时通过API获取APP后台时间，保存APP端时间和App后台的时间差，以后APP端用这个时间戳调整其生成的时间戳。例如，某一刻API获取的APP后台时间是1115922778，APP端的时间应该是111592775，两者的时间差是3。当APP在本地时间应该是213984751准备向APP后台发送API请求时，加上时间差3，即可得到APP后台的时间为213984754. 213984754即为参数传递中的时间戳。
改进方案的流程如下：
上面这个方案就完美了吗？很遗憾，它也不完美。
在今年(2017年)的1月份，苹果App Store中的所有App都必须启用ATS(App Transport Security)安全功能。苹果公司在该公司的全球开发者会议（WWDC）上宣布称，公司希望官方应用商店中的所有iOSapp都使用安全的HTTPS链接与服务器进行通信。
启用ATS后，它会屏蔽明文HTTP资源加载，强制App通过HTTPS连接网络服务，不满足以下条件，ATS都会拒绝连接。
▲********ATS客户端支持https走域名方式请求的，无需更改。https走IP直连方式，使用私有证书走442端口的，将不再可行；需要端口改成443端口，客户端预埋证书改为CA证书，并且需要设置域名白名单。
▲********服务端支持要求服务器必须支持传输层安全(TLS)协议1.2以上版本;证书必须使用SHA256或更高的哈希算法签名;必须使用2048位以上RSA密钥或256位以上ECC算法等。
在网络环境日趋复杂的今天，个人信息的保护已经显得非常重要了前文的例子中，我们的API即使使用了HTTPS协议也不能保证信息的绝对安全，万一基于HTTPS的API请求被黑客截获，使用URL签名会有如下3个问题：
● 当用户登录后，APP后台返回给APP的信息(包括个人信息)没加密，有被截取的风险● URL签名只能保护token值不泄漏，但没法保护其他敏感数据，例如当用户更新自己的个人信息时，所有的信息在传输过程中应该被加密● URL被黑客截获后还是能在一段时间内调用（假设APP后台认为有效的时间间隔是30S）。
怎么解决，总会有办法的，这就是AES对称加密。这里，对称加密的原理就不在赘述了，直接讲过程：后台返回给APP用户个人信息的流程如下：(1)用户在APP后台登录后得到”个人信息”{"token":"daf32asd12w","userId":1,"name":"jack"}(2)App后台的当前时间戳为1427871234，用这个时间戳生成HTTP请求头Toke-ParamToke-Param:1427871234(3)取请求头Toke-Param的22位长度作为密钥secretKey(4)用AES算法把个人信息用密钥secretKey加密，再进行base64编码，最后用HTTPS协议返回给App。
HTTPS协议内容如下：
客户端解密APP后台返回的内容流程如下：
（1）取HTTPS协议中HTTP请求头Token-Param的值的22位长度作为密钥secretKey
（2）把Http body的数据先用base64算法解码，用AES算法把解码后的数据用密钥secretKey解密，得到用户的个人信息。
AES算法中的密钥不是固定不变的，可以根据项目的需要和实际情况，设计其他的密钥方式。
App和App后台服务的通信安全大体上就说完了，那么我们最终版的AES对称加密方法就是安全的，万能的吗？非常遗憾，这并不是终极的解决方案。如果APP被黑客反编译了，黑客就知道了整个通信的加密过程(知道使用的加密算法和如何获取密钥)，如果又同时截取了API的请求数据，那么整个安全措施就无效。更进一步的加密措施：
★使用自定义的通信协议传输敏感数据(例如纳美语言)
★使用DES（非对称加密算法）加强通信的安全性
★使用第三方加固方案对APP进行加密
★涉及到特别敏感的信息(支付密码)，每次都需要用户输入，支付密码永远不要在APP端保存
★使用自主开发的安全控件输入敏感信息。
