我可以看出这个问题有很好的答案。除此之外，您可以使用FacebookReDex来优化代码。ReDex在.dex级别工作，而ProGuard在.class级别工作。

基本上，有五种方法可以保护APK文件：

隔离Java程序，加密类文件，转换为本地代码，代码混淆联机加密

我建议你使用在线加密，因为它既安全又方便。你不必花太多时间来实现这一点。

如APK Protect。这是APK的在线加密网站。它提供Java代码和C++代码保护，以实现反调试和反编译效果。操作过程简单易行。

100%避免Android APK的反向工程是不可能的，但您可以使用以下方法避免提取更多数据，如源代码、APK中的资产和资源：

使用ProGuard混淆应用程序代码使用使用C和C++的NDK将应用程序核心和安全部分代码放在.so文件中为了保护资源，不要将所有重要资源都包含在APK的资产文件夹中。在应用程序首次启动时下载这些资源。

工具：在应用程序中使用ProGuard，可以限制其对应用程序进行反向工程

不，不可能！

你的三个问题围绕着100%保护应用程序不被阅读。原则上这是做不到的。而且，你在尝试做这件事上投入的越多，你的体验就会越差，最终，无论哪台机器只想读你的应用。想想HTTP的HTTPS本质上有多慢，因为需要处理安全层和数学。层数越多，有人打开它的速度就越慢，但如果你真的想让它被阅读，那就永远不可能，这就是为什么它会被打包并交付的原因。

一个简单的类比是将任何给定的隐藏对象交给某人。如果那个人能看到里面的东西，那么他们就可以拍一张照片，做一些完全类似的事情。更重要的是，在代码的情况下，有足够的专业人员可以创建该对象的精确副本，即使使用完全不同的过程。

假安全感

作为一个处理应用程序，你不应该关心你认为可以在二进制代码中创建的任何安全性，也不应该关心整个系统的完整性。假设来自客户机的任何信息都可能很快变得不可靠。保持应用程序简单、流畅、快速。相反，请担心您的服务器。例如，制定一个严格的通信协议以方便地监控服务器。这是我们唯一可以依靠的。

现在，坚持我的另一个想法，如何改进服务器端。。。

嘴上的钱

我正在开发支付处理应用程序

谷歌通过使用一种简单的财务方法来“保护”谷歌Chrome，在总体上成功地避免了恶意黑客，我引述如下：

我们有50000美元的奖励，奖励参与者可以在客户模式下使用Chromebook或Chromebox进行设备持久性测试

我们真正接近100%“安全”的最佳选择是为我们的金钱价值选择正确的斗争。也许大多数人都无法提供50k的奖励，但即使是1k的奖励也会有很长的路要走，而且这也比将这些钱投资于设计任何类型的bug捕捉器要便宜得多。

投资于人工智能来识别资金流动模式，以预测潜在风险并发现小的泄漏，这也比通过任何工程来防止这两种情况要便宜得多。

明显的例外

当然，这并不能保护我们免受“疯子”和“幸运的恶作剧者”的伤害。。。但什么都不会。同时，如果设置得当，当系统重新调整时，后一组只会享受很少的时间。而一个疯子，我们只需要担心，以防它大到有一个克星。无论如何，这将是一个伟大的故事！：）

太长；没有阅读；

换言之，也许一个更好的问题可以问你自己，而不是“如何避免在我的应用程序中进行逆向工程”，而是“如何设计一个更安全的支付处理系统”，并专注于你实际想要实现的目标：一个安全的系统。

很久以前，我曾尝试写更多关于以上所有内容的文章，以回答一些问题，比如为什么我在引号中加上“安全”和“保护”（它们到底是什么意思？）。

无法完全避免APK文件的反向工程。为了保护应用程序资产和资源，可以使用加密。

加密将使其在不解密的情况下更难使用。选择一些强大的加密算法将使破解更加困难。在主逻辑中添加一些欺骗代码，使其更难破解。如果你能用任何一种母语编写你的关键逻辑，那么反编译肯定会更加困难。使用任何第三方安全框架，如Quixxi