最近项目已经准备上线～在提交App Store时被各种拒绝，首先允许我吐槽一下App Store的奇葩审核制度，不过也由于提交App Store审核需要时间，给了我一点喘息的时间，写一点东西。其实上次在写完基于DES加密AssetBundle那篇博客后，我在实际工作中就已经遇到了解密效率的问题，但苦于项目比较忙，没有时间补充之前写的这篇博客，今天终于有时间来重新谈一下加密的方式。
    在项目中我原先是使用的DES加密算法来加密AssetBundle的，但是在实际的项目中，由于我们的AssetBundle是动态实时加载的，结果导致我在项目中创建从AssetBundle中加载的模型非常慢，而且会引起屏幕卡顿。最后细查之下发现影响创建速度的根本原因就是由于使用了DES加密算法，这个算法本身可以说是安全性很高，但是有一个不好的地方就是效率比较慢，导致在解密时需要花一点时间来解密。我们都知道使用AssetBundle的其中一个原因是为了热更新，而对于大部分的手机游戏开发来说，我们都是在未正式进入游戏之前，进行版本检查，如果有更新，那么下载更新的AssetBundle，然后解密，加载资源，在这种情况之下其实使用DES加密是没有什么问题的，因为我们在检查版本更新过程中，很多游戏都会有提示下载的进度，然后提示正在加载资源什么的，总之有一个Loading页面，这样对于用户的体验是没有什么问题的。而由于有些项目中有些AssetBundle是需要动态实时加载的，那么加载AssetBundle如果会阻塞主线程，导致游戏卡住，这样的用户体验肯定是不行的。所以针对这种情况，我们可以使用次一级的加密方式来提升解密时的效率。而方法多种多样，这里就不提供代码了，主要说一下思路，因为其实就是在我上篇的加密的方法里，把用DES加密的方式，改为其他方式就好，所以主要说一下几种思路，第一种就是约定一个密钥，如果再考虑更好的安全性，这个密钥可以通过服务器来获取，然后在AssetBundle的中，对AssetBundle每隔一个长度，这个长度自己来定，也可以用一定的数学公式来设定，例如第一个隔一个字符，第二个隔2个字符，以此类推来依次插入你的密钥的第1到n个字符。第二种可以考虑AssetBundle的字符做交换，比如把前n位和后n位做交换。经过我的方法试验之下，这两种效率都不会有太大的问题。鉴于安全起见，我们项目所使用的方式我并没有在这篇博客中透露。但写本篇的目的就是想告诉大家如果对于AssetBundle的加载有比较高的实时性要求的时候，我们的加密算法可以自己来定义，只要它的效率够高，又相对比较安全，是完全可以使用的，这里我只是举了两种加密方式的例子，如果真的有兴趣也可以去网上搜索加密相关的技术文章。