jadx ran out of memory at 49% on the APK Droid ASC searched in 1.79 seconds

The order of work explains the memory curve. jadx's pipeline unpacks the APK, builds a global index and resolves cross-references before you ask your first question ^[8]. Droid ASC inverts that. It probes the Deflate stream directly, builds a dense Huffman lookup table, pulls only the core metadata blocks it needs and disregards the rest ^[9]. Bytecode offsets map to methods in constant time with no map table built ^[11]. On a hit, only the target class and its dependent bytecode are assembled into a self-consistent minimal DEX in memory ^[12].

The fourth piece is a bet on the compiler. R8 does deterministic constant propagation and instruction de-duplication. Both concentrate code physically, and the search exploits that layout ^[10]. For the search multiplier to transfer to your targets, those targets have to have been built the way the test set was built. The tool's side describes the comparison as official tests, on four real-world commercial APKs at ten threads with jadx as the control group ^[5], and the benchmark figure is credited to the GitHub repository MG1937/ASC ^[18].

Read the multipliers as maxima. Search is up to 269 times faster, decompilation up to 222 times faster and memory up to 125 times lower, each "up to" being the best of those four packages ^[3]. In its own summary, the write-up rounds the memory figure to two orders of magnitude ^[15].

I would budget on the Douyin comparison. jadx's global search on the 352 MB package reached 49% and was terminated by an out-of-memory error, while Droid ASC produced results in 1.79 seconds ^[6]. A screening pass that dies halfway has spent the analyst's twenty minutes and returned nothing about the app.

In the briefing, jadx on a several-hundred-megabyte APK pushes memory past ten gigabytes with progress crawling for tens of minutes ^[14]. If the 125x ratio held on that same package, the equivalent footprint is about 82 MB ^[1]. Those two numbers are not stated to come from the same APK, so treat 82 MB as an illustration of scale.

According to the tool's author, compilation output is highly structured data which modern decompilers rebuild into an unwieldy relational database, an approach that defies common sense ^[13]. That is a harsh way to describe an index, and roughly right for first-pass work. Zero indexing also means there is no persistent cross-reference graph to come back to ^[2]. Some review work wants exactly that.

The economics are asserted. The briefing notes that a single vulnerability may pay from thousands to tens of thousands, and that in per-vulnerability crowd-testing and SRC programmes tool efficiency converts into income ^[17]. Coverage per analyst-hour is the figure you would have to produce yourself. Droid ASC is pitched at red teams, SRC operations and emergency response, and recommended for authorised testing only ^[16].