不想巴拉巴拉一大堆关于移动端应用泄露用户数据的问题，所以直接上干货，一贯风格，只有文字！
对于移动端应用的数据加密，严格来讲并没有太好的办法，一是移动设备计算能力不足，撑不起比较复杂的加密解密算法，另一个是实际上信息泄露大多数是在由移动设备与带有恶意的设备组成的内网中，而目前的解决方案针对内网的信息泄露基本无解，毕竟千防万防，家贼难防，故而明明pc端有非常好用的解决方案妈蛋就是无法移植到移动端来。（请无视掉那些特殊目的而开发的应用，本文讲昂的是普通应用）
实际上针对移动端的应用分析来看，移动端实际上做的大部分工作都是调用接口，然后有些接口做的比较丧心病狂的传输的是明文数据，这还有什么秘密可言，尽管系统做得安全无比，但我压根就不需要去碰系统，我只要拦截传输的数据就行了，实际上，大部分的移动端信息泄露都是这么来的。
对此，有好的解决办法没？有，那就是开发一种超级复杂的加密算法，然后对传输的传输的数据进行加密，这里面的原理并不复杂，所以本文不对这种办法进行过多的介绍，仅提供一种通用性的加密算法： 减法替换法
减法替换法，其实非常简单，采用的是key-vaule对应的算法，即每一个用户都拥有一对密钥，分为公钥和私钥，服务端和客户端都保存有该公钥和私钥，具体生成的话没什么要求，这里仅提出一个范例：40个字符组成的密钥对，即公钥和私钥都是40个字符长度。在通讯过程中，客户端先将要传输的数据打包处理，处理成一个连续的字符串，然后拿这个字符串去对私钥进行减法操作，注意，因为私钥只有40个字符，所以长度肯定不够，那么循环吧，先从头减到尾，然后再从尾减到头还是重头再来可以随意，当然，做减法的过程中可能会产生溢出，这就要求有这么一个文件记录溢出情况，当然，这也不是问题，加上溢出文件就是的了，然后加上公钥，打包交给tcp/ip协议打包然后发送给服务端，服务端接收到完整的数据后解密，服务端发给客户端的数据也是一样的，同样的加密过程，客户端也是同样的解密过程，不同的是服务端采用的不是统一的秘钥对，而是采用用户的密钥对，这也是为什么在数据包中附加上公钥的原因
以上就是简单的加密过程，优点是数据包加密性比较强，被解开的可能性非常小，缺点是资源消耗比较高。当然，脑洞打开的我怎么可能只会有一种解决办法，针对上面的办法的优缺点，提出了另外一种解决办法：vpn数据包隧道会话方案！
vpn这个东西是个好东西啊，简直是21世纪中国程序猿必备工具，而且这货自带加密算法，虽然这个算法安全性不怎么样，但总比裸奔要强，而且这个加密算法不用我们去设计，可以直接拿来用（这大概是我们广大程序猿最喜欢干的事了）；但是，vpn有个问题，那就是这货建立的是ip地址与ip地址间的通道，而且要授权，这样在pc端还好，但到了移动端却是个麻烦，因为我们不可能让整个移动设备的网络资源给一个应用。但是呢，网络资源尽管共享，但在某一时刻，其实是独享的，只不过因为独享的时间非常短，造成共享的错觉，这也就为我改造vpn技术提供了可能性：我可以去掉认证环节，去掉一切所有不必要的环节，仅保留对数据包加密和点对点通道的能力，这样不就ok拉！当然，这样还不行，可以预计的是，尽管我只需要点对点通道的能力，但构建点对点通道是需要时间的，所以我将点对点通道做成开放式通道，这样任何ip地址都能连接过来。
于是，这样一个怪异的vpn被构建出来：不需要认证，任何人都可以连接！这样还不够，还得改，我们知道，网络尽管在我们看来是连续的，但实际上是一个一个的数据包，于是，我们可不可以将vpn的基于ip地址改成基于数据包？貌似可行！如果能够做到只vpn的通道在需要的时候迅速建立，然后发送完数据包后就断开，这样就完美了！可以吗？可以！我们可以这样做：
现在有一台vpn服务器，开放的，这时客户端要发送数据，于是给服务器打给招呼：哥们，注意啦，我要发送数据啦，你给我开个通道咯，然后服务器与客户端建立了vpn的通道，这时，数据传输准备就完成了，接下来客户端照常传输数据，因为拥有了vpn，这时走的是vpn，自然，数据就被加密过了，然后客户端数据发送完了，又给服务端打给招呼：哥们，我数据传完了，你给断开吧，然后服务器就认为这个会话已经完成，将断开这个通道。
于是，移动端数据加密算法完成了。
好吧，我承认写得不好，也没有图来说明，看起来有点看不懂的样子，但是，谁来告诉我怎么上图来着？