内存范围选择 —— A类、Ch类、Ca类、Jh类到底该怎么选
什么是内存范围
Android 进程启动后，操作系统会为它分配若干不同用途的内存区域。八门神器的"内存范围"选项就是让你选择扫描哪些区域：
| 范围标签 | 实际内存段 | 包含内容 | 包含率 | 推荐场景 |
|---|---|---|---|---|
| A 类 | 堆内存（Heap） | 游戏运行时动态分配的对象、变量、数据结构 | ⭐⭐⭐⭐⭐ | 默认首选——绝大多数游戏数据都在这里 |
| Ch 类 | 代码段（Code Heap） | 游戏代码、常量、字符串资源 | ⭐⭐ | 搜字符串常量、游戏固定参数 |
| Ca 类 | 代码地址（Code Address） | 游戏函数入口、跳转表 | ⭐ | 高级逆向，一般不用 |
| Jh 类 | Java 堆 / Dalvik 堆 | Java 层对象（Android 层的游戏逻辑） | ⭐⭐⭐⭐ | 搜某些 Android 原生游戏（尤其是 Unity 低版本） |
| 全部范围 | 以上所有 | 扫进程整个内存空间 | - | 第一次搜索、找不到结果时兜底 |
核心结论
默认选 A 类
A 类（堆内存）是最常用、命中率最高的范围。游戏用 C/C++ 写的逻辑层（数值、状态、资源）几乎都存在堆内存里。90% 的单机游戏内存修改，只选 A 类就够了。
什么时候选更多范围
| 情况 | 建议 |
|---|---|
| A 类搜不到结果 | 扩大到 A + Jh，或全部范围 |
| 游戏是 Unity 开发的 | 试试 Jh 类（Java 堆），Unity 用 Mono 运行时的逻辑数据可能在这里 |
| 游戏是用 Java 写的 | Jh 类优先，因为全在 Dalvik 堆上 |
| 搜字符串常量（比如玩家名字、NPC 名字） | Ch 类（代码段），常量字符串通常放这里 |
| 搜游戏固定参数（比如最大金币上限） | Ch 类，或者 A + Ch |
什么时候缩小范围（加速）
当你知道目标一定在 A 类里时，只选 A 类比选全部范围快得多——因为 A 类只是整个内存的一部分，扫描量减少了。
这对低配手机特别重要——全部范围扫描可能要几十秒，缩小到 A 类可能只需 3-5 秒。
内存范围不是越多越好
选择的内存范围越多：
- 搜索速度越慢（要扫描更多数据）
- 结果数量越多（噪音增加）
- 过滤难度越高（更多伪命中）
所以原则是：从最小可能范围开始搜，搜不到再逐步扩大。
内存范围搜索的特殊技巧
技巧一：针对 Unity 游戏
Unity 游戏的内部状态存储在它自己的 Mono 运行时中。有些 Unity 游戏（尤其是早期版本）的关键数据在 Jh 类（Java 堆 / Mono 堆）里。如果 A 类搜不到，试试单独选 Jh。
技巧二：区分 native 和 Java 层
Android 游戏通常有两层：
- Native 层（C/C++）：游戏引擎、渲染、物理——数据在 A 类
- Java/Kotlin 层：UI、设置、存档——数据在 Jh 类
想修改游戏内数值 → 搜 A 类；想改 UI 显示文本 → 搜 Ch 类（搜字符串）。
技巧三：内存范围 + 数据类型组合
两者可以组合使用来缩小搜索面：
搜金币：
数据类型 = Dword
内存范围 = A 类 ← 最快最准
搜玩家名字：
数据类型 = 字符串 / 文本
内存范围 = Ch 类 ← 找到常量区的字符串，再反推引用它的数值
搜 Unity 游戏 HP：
数据类型 = Dword（或 Float）
内存范围 = A + Jh ← Unity 的 Mono 层可能在两边都有副本内存范围选不对的典型后果
| 后果 | 原因 | 解决 |
|---|---|---|
| 搜不到任何结果 | 范围选得太小，漏掉了数据所在的区域 | 扩大范围到全部，或换其他组合 |
| 结果特别多（几十万以上） | 范围选得太大，扫了无关区域 | 缩小回 A 类或 A + Jh |
| 搜到了但改了不生效 | 搜到的是副本，真正的数据源在另一个范围 | 把当前结果排除后，换其他范围重搜 |