APK或DEX已经被JEB识别以后，接下来真正花时间的是读代码。反编译窗口里的Java代码方便梳理逻辑，但它并不是原始源码的直接还原，类名混淆、编译优化、动态调用和复杂控制流都会影响最终显示。有时候某个类只能看到一部分方法，或者Java视图里缺少成员，也不一定代表APK中的代码真的少了。碰到这种情况，把反编译视图、DEX反汇编和工程分析状态放在一起看，会比反复重新打开文件更容易判断问题出在哪里。

APK拿到手以后，反编译并不只是把文件丢进工具里等结果。一个安装包里可能同时带有多个DEX、资源文件、Manifest以及第三方库，代码还可能经过混淆或编译优化。JEB Decompiler会递归分析APK中的不同单元，再把DEX字节码转换成便于阅读的反汇编和Java形式代码。实际查看时，类名变短、方法结构奇怪、部分代码无法还原，并不一定是文件损坏，还要结合DEX内容和反编译状态来判断。

JEB Decompiler分析DEX、Native代码或其他可反编译目标时，通常会在汇编视图与反编译视图之间来回切换。两种视图表达的是同一段程序逻辑，但反编译器会重建变量、条件和控制结构，因此代码行并不会与底层指令逐行对应。处理“JEB Decompiler怎么切换反编译视图，JEB Decompiler反编译视图与汇编位置不同步如何调整”时，应先掌握正常的视图切换方式，再判断当前位置差异属于正常映射，还是反编译结果、标签页或同步设置出现异常。

在Unfold3D中完成切缝和展开后，UV岛之间仍要预留足够间距，才能避免烘焙扩边、MipMap或低分辨率贴图采样时互相串色。处理“Unfold3D怎么设置UV岛间距，Unfold3D UV岛间距设置后仍然发生重叠如何调整”时，重点要区分三个问题：Padding控制岛与岛之间的距离，Margin控制UV岛与Tile边界之间的距离，而真正的UV重叠还可能来自Stack、锁定状态或模型本身存在重复面。新版RizomUV已经将Margin和Padding分开设置，并根据Map Resolution计算实际间距。

在JEB Decompiler分析APK、DEX或Native程序时，函数数量一多，仅靠默认名称很难长期记录分析结论。给关键函数补充用途、参数含义和调用逻辑，可以明显降低后续回看成本。JEB Decompiler怎么给函数添加注释，JEB Decompiler注释保存后为什么没有显示，关键要分清注释究竟绑定到了函数对象还是某个代码地址，同时确认当前反编译视图是否已经刷新。JEB的注释并不是普通文本覆盖，它会附着在可识别的地址或代码对象上，因此光标位置不正确时，显示位置也可能和预期不同。

想要了解JEB Decompiler的项目缓存应当怎样清理，以及项目缓存损坏导致无法加载时如何处理，首先需要明确这里所说的项目缓存具体指什么。JEB在分析过程中，会把反编译得到的结果、重新命名的内容、注释、标签，还有项目属性这一类分析数据，都保存到JDB2项目数据库里。这种文件的大小，经常比原始的APK、EXE或者二进制文件大出许多。项目加载遇到失败时，不要一上来就把整个JEB目录删掉，应当先把项目数据库和原始的分析文件备份好，再去判断到底是JDB2本身损坏了，还是版本不兼容，或者是客户端那边的配置出了异常。

要搞清楚JEB Decompiler里面的变量重命名是怎么操作的，重命名之后引用不同步又该怎么办，得先把重命名的对象给分清楚。局部变量、方法参数、字段、方法和类，这些全都会在反编译出来的代码里面出现，可是它们能起作用的范围是不一样的。局部变量一般只会在当前这个方法里头有影响，字段和方法的名字呢，是有可能被整个代码单元里好多地方给引用的。JEB给了一个统一的Rename操作，它的目标就是让代码项的名称，在对应的分析模型里面能保持一致。

关于JEB Decompiler的调用图要怎样查看，还有调用图里节点太多了应该怎样筛选，这两个问题在分析APK、DEX或者本地二进制文件的时候是会经常遇到的。调用图比较适合被先用来看看方法之间的大致联系，帮着把入口函数、核心业务方法还有关键调用链给定位出来，不过这个图并不是越完整就越好，项目只要稍微复杂一点，节点和连线的数量就会一下子多出来很多，JEB生成的那个Callgraph本身就是一种被裁剪过的调用关系图，会把一些比较重要的方法和调用重点呈现出来，分析的时候还是要跟反编译代码、交叉引用还有方法命名这些事结合到一块，去一步一步地把范围给缩小。

在分析APK、DEX或者原生二进制程序的时候，如果发现Strings窗口里面看不到域名、接口路径和一些关键的提示文字，这通常意味着样本里的字符串已经被加密了，或者是在程序运行的时候才会把它们解密出来。这时候，就需要弄清楚JEB Decompiler到底应该怎么去分析字符串加密，以及怎么去定位字符串解密的具体逻辑，而不能仅仅依靠全局搜索明文来完成。JEB这个工具支持反编译、交叉引用、脚本编写和插件扩展，也有一些能够自动解密部分受保护字符串的现成例子，但面对复杂的样本，最终还是得靠人工来找到那个执行解密的函数。

当在Android应用里碰到native方法时，在Java层能看到的也就只是一个光秃秃的方法声明，真正干活的逻辑基本上都藏在so库里面。要用JEB Decompiler把JNI调用的落脚点给找出来，再把Java层的方法和so库里的实现函数之间的映射关系给追踪清楚，关键就在于DEX这一层和Native那一层要放在一起看，不能各看各的。JEB这个工具本身既能分析Android应用，也能对ELF这类Native二进制文件做反汇编、反编译和调试，正好适合拿来把Java native方法和so里的实现函数串在一条线上去追。