你的客户应该雇佣一个知道他们在做什么、能够做出正确决定并能够指导你的人。

上面所说的你有能力改变后端的事务处理系统是荒谬的——你不应该被允许进行这样的架构改变，所以不要期望能够这样做。

我的理由是：

由于您的域是支付处理，因此可以安全地假设PCI DSS和/或PA DSS（以及潜在的州/联邦法律）对您的业务非常重要-为了符合要求，您必须证明自己是安全的。为了不安全，然后（通过测试）发现自己不安全，再进行修复、重新测试等，直到安全性能够在合适的水平上得到验证=昂贵、缓慢、高风险的成功方法。要做正确的事情，要事先认真思考，让有经验的人才投入工作，以安全的方式发展，然后测试、修复（更少）等，直到安全性可以在合适的水平上得到验证=廉价、快速、低风险的成功方式。

AFAIK，您不能再保护/res目录中的文件，因为它们现在受到保护。

然而，您可以采取一些步骤来保护源代码，或者至少保护它的功能（如果不是所有功能）。

使用ProGuard等工具。这些将使您的代码变得模糊，如果不是不可能的话，在反编译时更难阅读。将服务中最关键的部分从应用程序中移出，并隐藏在服务器端语言（如PHP）后面的Web服务中。例如，如果你有一个花费了一百万美元编写的算法。你显然不希望人们从你的应用程序中窃取它。移动算法，让它在远程服务器上处理数据，然后使用应用程序简单地向它提供数据。或者使用NDK将它们本机写入.so文件，这比apk更不容易被反编译。我认为目前还没有一个.so文件的反编译器（即使存在，也不如Java反编译器）。此外，正如@nikolay在评论中提到的，在服务器和设备之间进行交互时，应该使用SSL。在设备上存储值时，不要以原始格式存储。例如，如果您有一个游戏，并且您正在SharedPreferences中存储用户的游戏货币数量。假设是10000枚硬币。不要直接保存10000，而是使用（（货币*2）+1）/13这样的算法保存。因此，您将1538.53846154保存到SharedPreferences中，而不是10000。然而，上面的例子并不完美，你必须努力想出一个不会因舍入误差而失去货币价值的公式。您可以对服务器端任务执行类似的操作。现在举个例子，让我们来看看你的支付处理应用。假设用户必须支付200美元。不要向服务器发送一个200美元的原始值，而是发送一系列较小的预定义值，这些值加起来可以达到200美元。例如，在服务器上有一个文件或表，它将单词与值等同。假设查理相当于47美元，约翰相当于3美元。所以，你不需要寄200美元，而是可以寄查理四次，约翰四次。在服务器上，解释它们的含义并将其相加。这可以防止黑客向您的服务器发送任意值，因为他们不知道哪个单词对应什么值。作为一种额外的安全措施，您可以使用类似于第3点的公式，并每隔n天更改关键字。最后，你可以在你的应用程序中插入随机无用的源代码，这样黑客就可以大海捞针了。插入包含来自互联网的片段的随机类，或者只是用于计算诸如斐波那契序列之类的随机事物的函数。确保这些类可以编译，但不会被应用程序的实际功能所使用。添加足够多的这些虚假类，黑客将很难找到真正的代码。

总而言之，没有办法100%保护您的应用程序。你可以让它更难，但不是不可能。你的网络服务器可能会被破坏，黑客可以通过监控多个交易金额和你发送的关键字来找出你的关键字，黑客可以费力地通过源代码找出哪个代码是伪代码。

你只能反击，但永远不会赢。

我知道一些银行应用程序正在使用DexGuard，它提供了类、字符串、资产、资源文件和本地库的混淆和加密。

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

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

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

当他们在手机上安装该应用程序时，他们可以完全访问该应用程序的内存。因此，如果你想防止它被黑客入侵，你可以尝试将其制作成这样，你就不能通过使用调试器直接获取静态内存地址。如果有地方可以写并且有限制，那么它们可能会发生堆栈缓冲区溢出。所以在他们写东西的时候尽量做到这一点，如果你必须有一个限制，如果他们发送的字符数超过了限制，如果（input＞limit）则忽略，这样他们就不能把汇编代码放在那里。