APK体积变大以后，JEB的分析时间很容易被拉长。多DEX、混淆代码、本地库和资源文件放在同一个工程里时，软件不只是把文件打开，还要处理解析、交叉引用、反编译以及部分自动分析。要是每次载入工程都把各种分析功能一起跑，大型APK很容易出现长时间占用处理器、界面响应变慢的情况。JEB本身提供了项目级分析设置、DEX反编译参数、并发线程和Android分析配置，把分析范围按照当前任务收一收，往往比单纯延长等待时间更实用。

　　一、JEB Decompiler怎么设置分析参数

　　JEB打开文件前会提供Core Settings，工程已经载入后，也能继续调整后端分析属性。处理APK时，可以先想清楚当前主要看DEX代码、资源还是本地库，再配置对应模块，没有必要让无关分析一直占着计算资源。

　　1、载入APK前调整核心设置

　　遇到体积较大的APK，可以在工程正式处理之前先整理分析范围，后面打开项目时会轻一些。

　　①、启动【JEB Decompiler】。

　　②、依次点击【文件】→【打开】，选择目标APK。

　　③、在弹出的【Core Settings】中展开当前文件对应的分析项目。

　　④、查看这次暂时用不到的高级分析内容。

　　⑤、关闭无关的高开销分析选项。

　　⑥、确认设置后再开始载入工程。

　　2、修改当前工程的后端参数

　　①、进入【编辑】→【选项】。

　　②、打开【Specific Project Properties】。

　　③、展开【Engines】相关配置。

　　④、定位【.parsers.dcmp_dex】。

　　⑤、查看DEX反编译器当前使用的参数。

　　⑥、只调整本工程需要修改的项目并保存。

　　项目属性主要影响当前工程，比较适合测试不同参数。如果确认某项设置以后经常都会用到，再考虑放到通用后端属性里，避免其他项目也被临时配置影响。

　　3、调整DEX并发反编译线程

　　①、进入【Engines】属性树。

　　②、找到【.parsers.dcmp_dex.DecompilerThreadCount】。

　　③、保持【0】时，让JEB按照系统逻辑处理器数量分配并发线程。

　　④、希望调用全部逻辑处理器时填写【-1】。

　　⑤、排查并发问题时，可暂时填写【1】改为串行反编译。

　　⑥、保存配置并重新启动【JEB Decompiler】。

　　4、只反编译当前需要的方法

　　有些混淆类包含的方法很多，整类重新反编译会消耗不少时间。如果眼下只需要看其中一个方法，可以把处理范围缩小。

　　①、在【Assembly】中定位目标方法。

　　②、进入【Action】→【Decompile with Options】。

　　③、取消【Decompile top-level container class】。

　　④、保留当前方法需要使用的反编译选项。

　　⑤、重新执行【Decompile】。

　　二、JEB Decompiler分析速度过慢如何优化

　　JEB运行变慢时，先看看它卡在文件解析、全局分析还是代码反编译阶段。几个阶段做的工作不同，一股脑关闭所有功能虽然可能缩短等待时间，但也容易把分析时需要的信息一起关掉。

　　1、先别急着运行完整Global Analysis

　　①、完成APK和DEX的基础载入。

　　②、在【Project Explorer】中找到本次关注的包或类。

　　③、先使用【Assembly】或普通反编译查看目标代码。

　　④、确认需要处理反射、加密字符串等内容后，再进入【Android】分析功能。

　　⑤、按当前任务执行【Global Analysis】。

　　Global Analysis会调用反编译器、模拟器和沙箱进一步检查代码，适合需要深入梳理应用逻辑的场景。只是查看几个普通类时，可以把这项分析留到确实需要的时候再运行。

　　2、减少一次反编译处理的代码量

　　大型混淆类里可能塞着数量不少的方法，整类处理自然会慢。顺着当前调用关系逐个查看，会比每次重新生成整个类轻不少。

　　①、切换到目标方法的【Assembly】。

　　②、执行【Decompile with Options】。

　　③、关闭【Decompile top-level container class】。

　　④、只生成当前【Method】的反编译结果。

　　⑤、需要查看其他方法时再分别处理。

　　3、看看线程数是不是被限制住了

　　①、打开【Specific Project Properties】或通用【Engines】设置。

　　②、定位【DecompilerThreadCount】。

　　③、发现参数为【1】时，确认当前是否仍需串行处理。

　　④、没有特殊限制时恢复为【0】。

　　⑤、重新启动【JEB Decompiler】后测试相同代码。

　　4、内存紧张时调整JVM配置

　　①、关闭正在运行的【JEB Decompiler】。

　　②、在JEB根目录找到或新建【jvmopt.txt】。

　　③、需要指定内存上限时加入【-Xmx8G】一类参数。

　　④、需要按物理内存比例设置时，可填写【-XX:MaxRAMPercentage=75.0】一类参数。

　　⑤、把需要使用的JVM参数写在同一行。

　　⑥、重新启动软件并查看【Logger】中的启动信息。

　　多DEX工程占用内存较多时，频繁进行内存回收也可能拖慢分析。这里的数值要结合电脑实际内存来定，示例参数不适合直接套到每台电脑上。

　　5、不看本地库时减少原生代码分析

　　APK带着多个so文件，并不代表每次分析都要深入处理这些代码。如果当前任务只围绕Java层展开，可以先把DEX部分跑顺。

　　①、在文件载入阶段打开【Core Settings】。

　　②、找到原生代码对应的分析项目。

　　③、当前不查看so时关闭无关的高级分析选项。

　　④、完成APK和DEX的基础载入。

　　⑤、后面需要检查某个【Native Library】时再单独处理。

　　三、JEB Decompiler分析参数调整后怎么确认

　　速度变快以后，还得看看目标代码有没有因为设置收得过紧而少掉信息。找一个自己已经看过的方法做前后对照，比换不同APK测试更容易判断参数调整有没有产生副作用。

　　1、用同一个方法比较调整前后的结果

　　先固定测试对象，这样等待时间和代码显示发生变化时，原因会比较清楚。

　　①、记录目标【Method】原来使用的分析设置。

　　②、修改项目参数并重新载入当前工程。

　　③、再次定位相同的【Method】。

　　④、执行相同的【Decompile】操作。

　　⑤、检查反编译内容和【Cross References】是否正常。

　　⑥、对照两次分析时的等待情况。

　　2、留下已经跑顺的工程配置

　　①、保存当前【JEB工程】。

　　②、记录修改后的【DecompilerThreadCount】。

　　③、记下本次是否执行【Global Analysis】。

　　④、保留与DEX反编译有关的项目属性。

　　⑤、整理这次使用的分析范围和处理方式。

　　以后再碰到体量接近的APK，这些配置就有了参照。不过普通应用、重度混淆代码和包含大量本地库的安装包负担差别不小，分析参数还是要跟着任务调整，没必要所有工程都用同一套设置。

　　总结

　　JEB Decompiler分析速度偏慢时，问题经常出在一次处理的内容太多。先明确这次准备看哪部分代码，再决定是否运行全局分析、整类反编译和原生代码深度分析，等待过程会更好控制。线程数和JVM内存主要解决资源分配问题，分析范围则直接决定软件要处理多少内容。把已经跑顺的项目配置留下来，后面分析类似APK时也不用重新摸索一遍参数。