Native Memory Analysis and Optimization in Android K歌 Application

The article presents a comprehensive study of native memory issues in the K歌 Android application, describing the background, analysis, and systematic solutions for memory crashes and leaks.

Background : In the first half of 2020, the crash rate of the app increased, especially in the native layer. The top crash stack showed no clear business code reference, but the virtual memory at crash time was close to 4 GB.

Problem Analysis : Using scripts to simulate user scenarios revealed a gradual increase in memory water level, reproducing the crash when virtual memory approached 4 GB. The majority of memory consumption was identified in the native layer.

Memory Distribution : By reading /proc/pid/smaps via adb run-as xxx.xxx.xxx cat /proc/pid/smaps , the report showed that memory is mainly allocated by the JVM, system libraries, dex files, and native malloc calls. The analysis distinguished two major parts:

Program files: dex (≈35%) and loaded .so libraries (≈7%).

NativeHeap: business‑integrated .so libraries and images (≈39%).

Tool Comparison : Three native memory analysis tools were compared:

Tool

Principle

Capability

Pros

Cons

malloc_debug

Replace

malloc

/

free

in

libc.so

Detect allocation/release, stack trace

No integration needed, works on rooted devices

Root required, limited business insight

perfetto

heapprofd

Detect allocation/release, stack trace

Fast, no integration needed

Android 10+, needs recompilation

loli_profiler

Hook

malloc

/

free

in

libc.so

Detect allocation/release, stack trace

No integration, works on any Android version

Requires PC tool, less convenient

Based on experience, a custom tool built on loli_profiler was proposed.

Native Memory Management Mechanism : The article explains how memory is requested via malloc / new (or mmap ) and released via free / delete . It details the PLT/GOT mechanism for function resolution and how hooking can replace the original malloc address with a custom hook_malloc implementation.

Stack Trace Acquisition : By capturing the stack address (e.g., 0xb65cd635 ) and mapping it to the loaded libkmemory.so , the exact function responsible for allocation can be identified using symbol tables.

So Library Memory Detection : A workflow is described to hook malloc / free in each .so , record allocation size, address, and stack, and write aggregated data to a file. This enables offline analysis of memory leaks and large allocations.

Bitmap Creation Monitoring : All image creation eventually calls BitmapFactory.cpp::doDecode() which uses HeapAllocate and creates a SkBitmap . Hooking the JNI function createBitmap (found via nm -D libandroid_runtime.so | grep bitmap ) captures bitmap dimensions, memory usage, and stack trace.

Bitmap Destruction : Two paths are covered: explicit bitmap.recycle() which triggers native sk_free() , and automatic GC‑driven destruction via NativeAllocationRegistry .

Monitoring Framework : The SDK integrates into the app, toggles monitoring via a network switch, reports bitmap info (size, memory, stack) to a performance platform, and visualizes hot‑spots. Sample dashboards show per‑so memory distribution and leak detection.

Case Studies :

Native library leak in libxxx.so causing OOM.

Audio processing .so leaking 40 MB after 50 UI slides.

Oversized images (e.g., 12300×480 → 22.5 MB) in web‑driven Hippy pages.

Glide misconfiguration leading to ARGB_8888 usage instead of RGB_565, inflating memory by ~4 MB.

Future Work : Optimize image caching in Glide, investigate unknown native allocations in singing rooms, and improve online monitoring with minimal performance impact.

Conclusion : By building native‑memory and bitmap monitoring tools, the team achieved precise visibility into native allocations, identified and fixed multiple leaks, and established a continuous monitoring loop for ongoing performance optimization.