许多厂商都在做加固，方法都千篇一律是使用dexClassLoader加载已经被加密后的dex文件。
这种方法主要存在的两个技术瓶颈是，
1、第一次使用dexClassLoader时，会执行dexopt dex2oat耗费大量的时间，后来，各大厂商都是寻找折中方法，局部加固，按需加载也都是这个时候出现的名词，甚至还有些加固团队在内部秘密研发vmp壳加固，但仍然免不了性能下降，安装包体积的增大。
2、某些sdk也会去操作ClassLoader，导致与加固不兼容，从而市面上有相当数量应用在加固以后不能正常运行，大大地制约了加固技术的推厂。
当然，所有的技术瓶颈都只是暂时的，我发现360、百度与梆梆已经成功突破上面两个技术瓶颈了。另外聚安全也实现了，加固android qq。实在是佩服他们的加固大神，太牛逼了。

我以前也是做加固的，我说说当时我整的一套弱加固方法吧：
1、不使用dexClassLoader、不进行入口替换等影响兼容与和性能的技术
2、定制了一套dex arsc xml文件的格式，使其能触发反编译工具baksmali dex2jar apktool jeb自身的bug缺陷，同时去掉了一些冗余的信息，优化apk体积，加固的过程就是将原本的apk转化为我定制的apk的过程。

效果
1、由于反编译时，反编译工具要崩溃，所以用户认为安全性更高
2、不影响性能，对安装包体积的影响也很小，某些apk加固后还会减小体积，即使对安全性无要求的用户也愿意加固。
3、使用zjdroid xposed等通用脱壳技术脱出来的odex依然是加固过的odex。
4、不影响兼容性，而且无论使用了何种sdk的apk都可以加固。

然后，被某些用户认为是当前最好的加固，希望各加固厂商也使用一下这种方案。

另外，这套弱加固方案少不了很多人的贡献，首先得是梆梆与聚安全，因为我在逆向它们的样本时学了很多东西。
其次是某些病毒、木马团队，他们也是构思出了各种奇奇怪怪的对抗反编译的办法。
然后是我的一些朋友、老同学，给我提供了很多好的样本。

最后，说一下这种方法毕尽是弱的加固，目地仅是为了满足用户的安全需求的弱加固，
如果黑客使用了zerofile改版的反编译工具，或者反编译工具升级更新后，把自身的bug修复了，
那么这种加固技术就失去了安全性。所以建议各用户慎用我做的加固。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)