maokabc

把核心代码 native 化就能防止这类工具反编译，可以试试这个 https://github.com/maoabc/nmmp

用 javap 看字节码就可以发现区别，就是 gefield 指令比 aload 、iload 这类指令开销大，更别说 getfield 之前还有一条 aload_0 指令先得到 this 。

每个人用法不同，我个人实际平均内存用量才 3.8g ，6g 内存的手机就够了。基于 webview 的那些垃圾 app 一律不用，小程序那类垃圾有多远滚多远。

从自己画 pcb 跟外壳起 diy 了一个，之后索然无味。做好的都不想用，还不如 thinkpad 自带的键盘省事。

@StonyGround 和寄存器这个关系不大，比如 const-class vAA, [email protected] ，[email protected] 就是索引到类型常量池，这个只在 u2 范围内，如果一个 dex 包含的 class 太多那么类型常量池可能超过 0xffff ，这时就出现了 64k 问题。实际还有更多的指令都是 u2 索引，像 invoke 系列指令的 method ref 也只能在 u2 范围内。

没这么复杂，就是谷歌设计 dex 格式时没考虑到。.class 索引是 u2 那是别人只是单文件，这么用没问题，它.dex 也跟着这样，然后很快就有问题了。dalivk 字节码很多指令只有 u2 的索引，所以那些常量池只能在 u2 范围内。

加固 aab 也没啥特别的吧，签名机制好像还是用 v1 那套，加固核心无非就是保护 classes.dex 。

只能说加油了，跟你差不多情况。在跟你差不多的年级选择宅了七八年，所以不知道给别人什么建议。
很多时候你不说学历前还能和一些人聊技术，一旦你挑明学历，你之前说的都会变垃圾，哈哈😄

其实吧被人用心里还挺高兴，就是可能过的时间长以后，别人用衍生改进的反过来说你是垃圾。如果最初协议没选好，你反击别人还说你蹭热度。