在做app开发跟服务端通信时，必然要保证安全性，一般情况下都是加密来搞，那怎么做比较简单且安全呢；有几种办法，优缺点都有，我们来看看
1，简单点，明文传输，非登录态其实没啥好说的，看看登录态，用户登录后，服务器给客户端分配tokenid，类似pc端的sessionid一样，那么客户端后续请求服务器都要带上tokenid，服务器检查tokenid是否已经登录，然后检查权限等，如果认为已登录没啥问题就会执行正常的业务逻辑，因此这个tokenid很重要，除此之外，我们还需要对请求数据做签名，我们用不可逆的加密来做，比如说加盐后的md5以及加盐后的sha-256等算法，然后保证传输过程中数据不被篡改就行了。
2，https方式，如果想这样做，你必须向ca申请一个证书安装到你的服务器上，然后凯奇443端口通信，当然这么做是安全的；但你需要花钱购买ca证书，以及通讯效率会比较低，因为建立连接的过程是非对称加密的，后续的通信还好，除非银行等金融领域对安全性要求比较高时，这样做没问题。但你得保证你服务器别被攻击哈，如果服务器被攻击，服务器证书或者私钥泄露，那就完了，攻击者可以做中间人攻击，你懂的。
3，对称加密，比如aes或者blowfish这种算法，密钥长度长一些，安全性还是很可以的，但是有个问题，用这种算法需要privateKey，你客户端代码如果保存privateKey去加密，那就没什么意义了，坏人可以反编译你的android的源码的，所以密钥是绝对不可以写死在客户端代码的，那只能从服务端获取了，且是临时保存在客户端通信用用，密钥可以是固定的，也可以是不固定的，跟人或者设备session相关，先看看固定的密钥吧，好办，可以采用https类似的机制来做，获取对称加密密钥前，我们先通过rsa等非对称加密请求服务器端，获取对称密钥保存在客户端很长时间，再加上session验证和参数签名，安全性还是很有保障的；
4，还有一种，跟方案3比较类似，客户端在本地生成一个唯一的tokenid，客户端请求服务器获取对称密钥的时带上这个tokenid，服务器为每个tokenid生成一一对应的对称加密密钥，每台设备请求的加密密钥都不一样，安全性更高一些，然后用户登录后给tokenid授予已登录的权限，这个做法跟方案1中的不太一样，方案1是服务器生成tokenid下发，本方案恰恰相反；