防破解确实是个成本收益的问题，但是你如果认为 hook 就能拦住 99% 那就太理想化了。由于逆向工具的进步，学习 hook 的门槛非常低。你有正向开发的能力，半个小时学习一下 frida 甚至脚本都不用自己写，就能绕过绝大部分不设防的应用。

从知己知彼的角度上说，还是要了解逆向是怎么做的。精力放在抵御那些高度自动化的逆向方案上。

静态方面，一般防御手段是混淆和加壳。混淆可以某种程度上避免反编译后你自己的程序逻辑被分析，但是涉及到的系统 api 调用是不好藏的，所以聊胜于无。加壳对于大部分开发者来说门槛过高，选择加壳的时候，顺便搜一下对应的脱壳工具，大致上可以防技术不过硬的选手了。

动态方面，核心思路是将关键代码 native 化。同时 native 接口要采用互操作的形式，否则很容易被当作黑盒来直接调用。通常 hook native 只有在 onEnter/onLeave 环节能做一些记录入参，修改返回值的操作，所以拆解 native 逻辑避开这种利用方式也能防住很大一部分。

另外就是所有你认为的“检测”结果都不可信，这个事情哲学上就是你不可能判断自己是不是生活在虚拟世界是一个意思。相关的检测还是可以做的，但这种检测必然依赖 api 和特征，在 hook 环境中都可能是假象。检测到了随机插入假结果给逆向的人带来迷惑，远比粗暴禁用等手段有意义。这也是多数大厂的做法，用风控替代对抗。

抓包层面，大部分人都说了，除非你像 fb 一样自己实现 tls 库，不然都有自动化的解决方案。另外 ecapture 还是 hook 方案，知道的人少，被检测的几率小。如果项目合适，可以考虑用 protobuf 之类替代 http 。