Android内存优化（二）系统进程之logd的native memory优化

最新推荐文章于 2025-05-18 23:53:59 发布
原创 最新推荐文章于 2025-05-18 23:53:59 发布 · 4.3k 阅读 · 10 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

针对C1logd进程内存占用过大的问题，通过调整LogBuffer大小降低内存消耗，并分析改动前后对日志记录的影响。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

最近的测试发现，C1 logd进程内存占用比Mate9 logd进程内存占用大很多，详细数据如下：
内存最大值（KB） 内存最小值（KB） 内存平均值（KB）
C1 39794 21985 39353
Mate9 2804 2565 2719

怀疑有native内存泄露，或者内存老化问题出现，于是做了针对性的Native内存泄露测试，发现跑两个小时的固定场景，很容易出现下面这段trace

Begin trace
size 4111590 count:49857 parentcnt:51505
0x00008c0c debug_malloc bionic/libc/malloc_debug/malloc_debug.cpp:310 /system/lib64/libc_malloc_debug.so
0x00083070 operator new(unsigned long) external/libcxxabi/src/cxa_new_delete.cpp:44 (discriminator 1) /system/lib64/libc++.so 
0x0000ac4c LogBufferElement system/core/logd/LogBufferElement.cpp:47 /system/bin/logd 
0x00007498 LogBuffer::log(log_id, log_time, unsigned int, int, int, char const*, unsigned short) system/core/logd/LogBuffer.cpp:209 (discriminator 3) /system/bin/logd 
0x00006168 LogListener::onDataAvailable(SocketClient*) system/core/logd/LogListener.cpp:112 (discriminator 1) /system/bin/logd 
0x00004200 SocketListener::runListener() system/core/libsysutils/src/SocketListener.cpp:245 /system/lib64/libsysutils.so 
0x00003cf8 SocketListener::threadStart(void*) system/core/libsysutils/src/SocketListener.cpp:147 /system/lib64/libsysutils.so 
0x00075c54 __pthread_start(void*) bionic/libc/bionic/pthread_create.cpp:198 (discriminator 1) /system/lib64/libc.so 
0x0001e0fc __start_thread bionic/libc/bionic/clone.cpp:41 (discriminator 1) /system/lib64/libc.so 
0xfffffffffffffffc ??? ??? ??? 
End Trace
Begin trace
size 2920176 count:52146 parentcnt:53794
0x00008c0c debug_malloc bionic/libc/malloc_debug/malloc_debug.cpp:310 /system/lib64/libc_malloc_debug.so
0x00083070 operator new(unsigned long) external/libcxxabi/src/cxa_new_delete.cpp:44 (discriminator 1) /system/lib64/libc++.so 
0x00007474 LogBuffer::log(log_id, log_time, unsigned int, int, int, char const*, unsigned short) system/core/logd/LogBuffer.cpp:209 (discriminator 1) /system/bin/logd 
0x00006168 LogListener::onDataAvailable(SocketClient*) system/core/logd/LogListener.cpp:112 (discriminator 1) /system/bin/logd 
0x00004200 SocketListener::runListener() system/core/libsysutils/src/SocketListener.cpp:245 /system/lib64/libsysutils.so 
0x00003cf8 SocketListener::threadStart(void*) system/core/libsysutils/src/SocketListener.cpp:147 /system/lib64/libsysutils.so 
0x00075c54 __pthread_start(void*) bionic/libc/bionic/pthread_create.cpp:198 (discriminator 1) /system/lib64/libc.so 
0x0001e0fc __start_thread bionic/libc/bionic/clone.cpp:41 (discriminator 1) /system/lib64/libc.so 
0xfffffffffffffffc ??? ??? ??? 
End Trace
Begin trace
size 1249464 count:52061 parentcnt:53709
0x00008c0c debug_malloc bionic/libc/malloc_debug/malloc_debug.cpp:310 /system/lib64/libc_malloc_debug.so
0x00083070 operator new(unsigned long) external/libcxxabi/src/cxa_new_delete.cpp:44 (discriminator 1) /system/lib64/libc++.so 
0x000075f4 std::_1::_allocate(unsigned long) external/libcxx/include/new:168 /system/bin/logd 
0x00006168 LogListener::onDataAvailable(SocketClient*) system/core/logd/LogListener.cpp:112 (discriminator 1) /system/bin/logd 
0x00004200 SocketListener::runListener() system/core/libsysutils/src/SocketListener.cpp:245 /system/lib64/libsysutils.so 
0x00003cf8 SocketListener::threadStart(void*) system/core/libsysutils/src/SocketListener.cpp:147 /system/lib64/libsysutils.so 
0x00075c54 __pthread_start(void*) bionic/libc/bionic/pthread_create.cpp:198 (discriminator 1) /system/lib64/libc.so 
0x0001e0fc __start_thread bionic/libc/bionic/clone.cpp:41 (discriminator 1) /system/lib64/libc.so 
0xfffffffffffffffc ??? ??? ??? 
End Trace

从上面的backtrace看，主要描述的是Logd如何处理客户端的log过程，以Java层的Log.d（smg）举例，主要执行流程：

Log.java d()​->Log.java println_native()->android_util_Log.cpp android_util_Log_println_native()->logger_write.c __android_log_buf_write​()->logger_write.c write_to_log() -> logger_write.c __write_to_log_init​() -> logger_write.c​ __write_to_log_initialize()​ -> logger_write.c __write_to_log_daemon​() 从逻辑看，就是往socket不断的写log，写给谁呢？在__write_to_log_initialize()​ ​方法中会调用 config_write.c __android_log_config_write​(),初始化logdLoggerWrite​，从logd_write.c中可以看出，logdLoggerWrite​是个socket，
strcpy(un.sun_path, “/dev/socket/logdw”);
往socket里面写了，谁会去处理呢？
logd进程启动的源码中可知，LogListener​ listens on /dev/socket/logdw for client​，可见下面源码
// LogListener listens on /dev/socket/logdw for client
// initiated log messages. New log entries are added to LogBuffer
// and LogReader is notified to send updates to connected clients.

LogListener *swl = new LogListener(logBuf, reader);
LogListener是SocketListener类型，初始化完成后会runListener​，当socket中有信息时，执行流：
SocketListener::runListener​() -> LogListener::onDataAvailable​() -> LogBuffer::log()
在LogBuffer::log()方法中，new LogBufferElement​，（这部分就跟上面的backtrace对应上了），并将其添加至LogBufferElementCollection​中，在LogBufferElement​构造方法中，会根据msg信息new char[]，将信息存在LogBuffer～
存起来的Log，什么时候会消费呢？
在代码中，调用LogBuffer::erase()会释放，从单词意思也能猜到，这个方法什么时候调用呢？
LogBuffer::maybePrune() -> LogBuffer::prune() -> LogBuffer::erase()​
而LogBuffer::maybePrune()​调用，只有在 LogBuffer::log()​，也就是说，上面的Java层调用Log.d()就可以触发这个逻辑，触发的条件在LogBuffer::maybePrune()​方法中

// Prune at most 10% of the log entries or maxPrune, whichever is less.
//
// mLogElementsLock must be held when this function is called.
void LogBuffer::maybePrune(log_id_t id) {
    size_t sizes = stats.sizes(id);
    unsigned long maxSize = log_buffer_size(id);
    if (sizes > maxSize) {
        size_t sizeOver = sizes - ((maxSize * 9) / 10);
        size_t elements = stats.realElements(id);
        size_t minElements = elements / 100;
        if (minElements < minPrune) {
            minElements = minPrune;
        }
        unsigned long pruneRows = elements * sizeOver / sizes;
        if (pruneRows < minElements) {
            pruneRows = minElements;
        }
        if (pruneRows > maxPrune) {
            pruneRows = maxPrune;
        }
        prune(id, pruneRows);
    }
}

从代码可知，当对应的LogBuffer size超过了maxSize​，进行裁剪log，释放一部分LogBufferElement​～其实到这可以看出，logd是log池，只有池子满了，才会主动释放一部分内存
系统中有多少LogBuffer呢？最大值又是多少呢？
LogBuffer::init()方法中，会对LogBuffer初始化，从初始化的过程看，有7个LogBuffer，分别是：

​static const char *LOG_NAME[LOG_ID_MAX] = {
    [LOG_ID_MAIN] = "main",
    [LOG_ID_RADIO] = "radio",
    [LOG_ID_EVENTS] = "events",
    [LOG_ID_SYSTEM] = "system",
    [LOG_ID_CRASH] = "crash",
    [LOG_ID_SECURITY] = "security",
    [LOG_ID_KERNEL] = "kernel",
};

根据系统属性设置maxsize，从C1上看下跟logd相关的属性：
设置逻辑贴代码比较多，直接看一个说明文档的注释：
persist.logd.size number ro Global default size of the buffer for
all log ids at initial startup, at
runtime use: logcat -b all -G
ro.logd.size number svelte default for persist.logd.size. Larger
platform default sizes than 256KB are
known to not scale well under log spam
pressure. Address the spam first,
resist increasing the log buffer.
persist.logd.size. number ro Size of the buffer for log
ro.logd.size. number svelte default for persist.logd.size.
初始化过程执行完，每个LogBuffer的最大值如下：
main:2M
radio:4M
events:2M
system:4M
crash:1M
security:2M
kernel:2M

如果每个LogBuffer都填满，所有LogBuffer内存占用近20MB，再加上分配内存的中间开销，占用内存可能会非常大～

再来看下Mate9的logd相关设置：
Mate9没有设置LogBuffer的大小，如果不设置，LogBuffer大小使用默认值，即256KB
如果将C1的logd相关属性和Mate9保持一致后，测试结果如下：
内存最大值(KB) 内存最小值(KB) 内存平均值(KB)
C1 修改版 7894 4877 6610
Mate9 2804 2565 2719
​修改LogBuffer后的效果比较明显，内存值会下降很多，但同样会带来log丢失的问题。也就是 LogBuffer::prune()方法带来的问题
裁剪的主要逻辑：先删黑名单和Log数最多的UID对应的Log，而且先删oldest的log，如果仍不满足，再根据白名单的配置，白名单的不删除，其他都删除，直到满足条件

LogBuffer最大值意味着存放log信息的多少，比如我们生成bugreport时，会dumpstate，取system log，event log，radio log等信息，
LogBuffer比较小的话，取出来的信息会相对少一些，可能会对开发解问题造成影响。
也就说，改动前会看到2个小时前的event log，system log，改动配置后可能就会看到近20分钟的event log，system log

看一下实际情况，跑了几个小时的场景后，一台C1是16号开发版包，logd内存：46614K​，一个C1是修改logd后的开发版包，logd内存6794K，
抓取两个C1的bugreport
11-16开发版第一个bugreport
system log起始时间 event log起始时间 radio起始时间
15:00-17:52 15:20-17:52 10:27-17:5​2
11-16开发版第一个bugreport
system log起始时间 event log起始时间 radio起始时间
15:00-18:07 15:21-18:07 10:27-18:07
修改logd属性的11-16号开发版第一个bugreport
system log起始时间 event log起始时间 radio起始时间
17:26-17:53 17:33-17:53 15:48-17:53
修改logd属性的11-16号开发版第二个bugreport
system log起始时间 event log起始时间 radio起始时间
17:26-18:07 17:41-18:07 16:03-18：07
从数据可以看出，未做修改的版本system log会记录4个小时左右，event log会记录3个半小时左右，radio会记录7个半小时，而修改logd属性的版本system log会记录30分钟左右，
event log会记录20分钟左右，radio会记录2个小时，整体比未做修改的版本时间要短，符合预期

开发版上log比较多，如果是稳定版，由于log少情况会好一些～从数据看，也是可以接受

因此，建议将RAM较小的外发版机型，将LogBuffer size调小，或者直接调至256KB，将内存影响降至最低～

Android 系统内的守护进程 - core类中的服务 (5) : logd
Android系统工程师--小馬佩德罗
05-07 642
只要是操作系统，不用说的就是其中肯定会运行着一些很多守护进程（daemon）来完成很多杂乱的工作。通过系统中的init.rc文件也可以看出来，其中每个service中就包含着系统后台服务进程。而这些服务被分为：core类服务（adbd/servicemanager/healthd/lmkd/logd/vold）和main类服务；
android native 内存分析,Android native Memory分析
weixin_29112009的博客
05-25 1473
本文将分析Android native memory的使用状况及通过一些手段来定位到native memory leak代码。在EngLoad上执行以下adb命令$adbshellsetproplibc.debug.malloc1$adbshellstop$adbshellstart然后等手机重新启动后，链接DDMS就可以看到每个SO文件占用的内存大小了。一般占用很大的比较可...
android logging 机制及优化
yzy9508的博客
09-07 1495
用户空间 Java:                 frameworks/base/core/java/android/util/Log.java 用户空间native http://androidxref.com/5.0.0_r2/xref/frameworks/base/core/jni/android_util_Log.cpp
Android 性能优化入门（二）—— 内存优化
最新发布
tmacfrank
05-18 1670
首先，在 LeakCanary 的部分模块的 AndroidManifest.xml 中会声明一些 Provider，这些 Provider 在 apk 打包时会汇入 mergeAndroidManifest.xml，最后体现在 app 的 AndroidManifest.xml 文件中。A~G 每个对象都占 10 个内存单位，它们的浅堆都是 10，但是 B、C 的深堆就要计算上各自分支上的对象总和，即 30，而 A 要计算分支上所有对象的内存总和，即 70。
android log 优化,Android 项目Log日志输出优化
weixin_35733495的博客
05-27 370
概述Android开发过程中经常需要向控制台输出日志信息，有些人还在用Log.i(tag,msg)的形式或者system.out.println(msg)方式吗？本篇文章对日志信息输出进行优化，以达到快速定位输出日志位置及输出规范日志的效果。日志输出行展示调用输出日志信息在哪个文件的第几行，并且可以和点击跳转到对应位置的作用。输出日志的一般形式1、在项目中直接调用Log.i(tag,msg)或者p...
linux添加开机启动项
01-18 1万+
使用chkconfig命令可以查看在不同启动级别下课自动启动的服务（或是程序），命令格式如下：chkconfig --list可能输出如下：openvpn    0：关闭 1：开启 ...... 6：关闭 （0-6 为启动级别 ; 关闭/开启为相应级别下该服务的自动启动选项）如果希望对自动启动选项做出改变，命令格式为：chkconfig --level x name on/offz.B. chkconfig --level 5 openvpn off以上的命令可以查询系统可提供的服务，如果希望开机时启动某一
Android性能优化之内存优化
m0_67595789的博客
04-28 653
除了基本使用外，我们还可以自定义处理结果，首先，继承DisplayLeakService实现一个自定义的监控处理Service，代码如下： public class LeakCnaryService extends DisplayLeakServcie { private final String TAG = “LeakCanaryService”； @Override protected void afterDefaultHandling(HeapDump heapDump， AnalysisResult
【Android性能优化】内存优化前置知识剖析
Shujie
02-01 1129
内存优化作为Android性能优化中非常重要的一环，这篇blog主要记录了跟内存优化相关的重要命令、核心指标、相关原理的解析。作为前置知识，起到奠基的作用。阅读完本篇内容，你将对于Android的内存优化有个大致的知识框架。更加详细的解析，会在后续blog中更新。
Android Native内存泄漏检测方案详解
陆业聪
07-28 1597
本文将分三个部分阐述如何实现 Android Native 内存泄漏监控，包括代理实现的三种方案（Inline Hook、PLT/GOT Hook、LD_PRELOAD）及其优缺点，以及如何检测Native内存泄露和获取Android Native堆栈的方法。本文将提供一套比较全面的解决思路，帮助大家更好地检测 Android Native 内存泄漏问题。
Android 内存优化 查找问题所在
coder_nice的专栏
07-29 834
内存飙高，居高不下，oom，是Android程序员经常遇到的问题，想要解决内存问题需要先找到内存问题出在哪里。所以内存问题最难的在于找到哪里导致了内存出问题。观察Android studio图形化工具使用Android Device Monitor点击Android studio 功能栏图标，打开Android Device Monitor Android Device Monitor 方便
Android 性能优化——ANR监控与解决_waited 5000ms for focusevent
2401_85835544的博客
08-13 759
Android M(6.0) 版本之后，应用侧不能直接通过监听文件，监控是否发生 ANR。
Android Native 内存泄漏系统化解决方案
08-25
主要介绍了Android Native 内存泄漏系统化解决方案,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
Android中 logd 详解
热门推荐
私房菜
04-09 2万+
logd 是Android L版本提出来的概念，其作用是保存Android运行期间的log（日志）。在Android L之前，log由kernel的ring buffer 保存，在Android L之后，log保存在用户空间。源码基于：Android P。
Native开发工具之CPU 和架构（三）(1)，android性能优化和内存优化
erthre的博客
03-23 791
通常，在编译时使用#ifdef及以下各项确定 ABI 最为方便：对于 32 位 ARM，使用__arm__对于 64 位 ARM，使用对于 32 位 X86，使用__i386__对于 64 位 X86，使用__x86_64__请注意：32 位 X86 称为__i386__，而不是__x86__，这可能与您预想的有所不同！
Android 内存分析(java/native heap内存、虚拟内存、处理器内存 )
HeXinGen的博客
05-05 8233
通过Byte数组和Bitmap来了解，dalvik java 堆内存、native heap 内存、32位设备3G虚拟内存，手机处理器内存等等。
深入探索 Android 内存优化（炼狱级别）
idaretobe的专栏
03-09 3644
前言 成为一名优秀的Android开发，需要一份完备的知识体系，在这里，让我们一起成长为自己所想的那样~。 本篇是 Android 内存优化的进阶篇，难度可以说达到了炼狱级别，建议对内存优化不是非常熟悉的仔细看看前篇文章：Android性能优化之内存优化，其中详细分析了以下几大模块： 1）、Android的内存管理机制 2）、优化内存的意义 3）、避免内存泄漏 4）、优化内存空间 5）、图片管理模块的设计与实现 如果你对以上基础内容都比较了解了，那么我们便开始 Android 内...
JVM的Heap Memory和Native Memory
Venus专栏
04-20 1万+
JVM管理的内存可以总体划分为两部分：Heap Memory和Native Memory。前者我们比较熟悉，是供Java应用程序使用的；后者也称为C-Heap，是供JVM自身进程使用的。Heap Memory及其内部各组成的大小可以通过JVM的一系列命令行参数来控制，在此不赘述。Native Memory没有相应的参数来控制大小，其大小依赖于操作系统进程的最大值（对于32位系统就是3~4G，各种系统
Android内存优化分析总结，这一篇就够了
bugyinyin的博客
10-17 1544
内存优化一直是一个很重要但却缺乏关注的点，内存作为程序运行最重要的资源之一，需要运行过程中做到合理的资源分配与回收，不合理的内存占用轻则使得用户应用**程序运行卡顿、ANR、黑屏，重则导致用户应用程序发生 OOM（out of memory）崩溃。在你认真跟踪下来可能会发现内存出现问题的地方仅仅只是一个表现的地方，并非深层次的原因，因为内存问题相对比较复杂，它是一个逐渐挤压的过程，正好在你出现问题的代码那里爆了，所以针对应用的内存问题开发者必须多加关注。
深入探索 Android 内存优化（炼狱级别-上）
QG
11-10 543
内存优化
进程内存读取，并后续切换成能够在安卓系统上使用的代码
03-11
<think>好的，用户现在想了解如何在安卓系统上实现进程内存读取，并且希望看到相关的代码。之前我已经提供了Windows平台上的进程内存读取方案，现在需要调整到安卓环境。 首先，安卓系统与Windows不同，它基于Linux内核，所以内存读取的方法会有所区别。在Linux系统中，通常通过访问/proc/[pid]/mem文件来实现，但需要相应的权限。安卓系统可能还需要考虑root权限的问题，因为普通应用无法直接读取其他进程的内存。 用户之前可能已经了解过Windows下的实现，现在想迁移到安卓，可能是因为他们正在开发跨平台工具或移动应用相关的功能。需要确保提供的方案在安卓上可行，并且考虑到不同版本的安卓系统可能存在的差异。 接下来，我需要考虑在安卓上实现进程内存读取的几种可能方法。常见的方法包括使用ptrace系统调用、直接读取/proc/[pid]/mem文件，或者利用安卓的NDK进行本地代码开发。由于用户提到后续切换成安卓代码，可能需要使用JNI和C/C++结合的方式。 需要注意的是，普通应用没有权限访问其他进程的内存，除非设备已root。因此，代码示例可能需要运行在root过的设备上，或者应用具有root权限。这一点必须在回答中明确指出，避免用户在不具备条件的情况下尝试。 另外，安卓的权限管理比较严格，即使使用ptrace，也需要相应的权限配置。可能需要修改应用的AndroidManifest.xml文件，或者通过su命令获取超级用户权限。 接下来，我需要提供具体的代码示例。例如，使用C编写一个本地库，通过JNI在Java/Kotlin中调用。代码需要包括打开目标进程、读取内存的步骤。同时，要处理错误情况，如权限不足或内存不可读的情况。 还需要考虑不同架构的兼容性，比如ARM和x86的区别，以及如何编译本地代码为SO库。用户可能需要使用NDK来编译代码，并集成到安卓项目中。 最后，需要提醒用户注意安全性和合法性，修改或读取其他进程内存在很多情况下可能违反用户协议或法律法规，特别是在游戏或商业应用中。确保用户明确这些风险，并遵守相关规定。 总结步骤： 1. 分析安卓与Windows内存读取的差异。 2. 确定实现方法：ptrace或/proc文件系统。 3. 提供需要root权限的警告。 4. 编写C代码示例，使用ptrace或文件操作。 5. 集成到安卓应用中的方法，使用NDK和JNI。 6. 处理权限和错误情况。 7. 强调安全和法律问题。</think>以下是针对Android系统的进程内存读取实现指南，包含从基础原理到具体代码的完整方案： --- ### **Android内存读取原理图** ``` [应用层] → JNI接口 → [Native层] ↓ ptrace()/proc文件系统 ↓ Linux内核内存管理 ``` --- ### **Android与Windows内存读取对比** | 特性 | Windows | Android | |----------------|-----------------------|----------------------| | 核心API | ReadProcessMemory | ptrace()/proc文件系统 | | 权限要求 | Administrator | root权限 | | 进程隔离机制 | 用户账户控制(UAC) | SELinux | | 典型实现方式 | Win32 API | NDK + JNI | --- ### **Android实现方案** #### 前置条件： 1. 已root的Android设备 2. 开启`ptrace`系统调用权限 3. 项目配置NDK开发环境 --- ### **方案一：使用ptrace系统调用** #### 1. 创建native-lib.cpp ```cpp #include <jni.h> #include <sys/ptrace.h> #include <unistd.h> #include <android/log.h> #define LOG_TAG "MemoryReader" #define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, __VA_ARGS__) extern "C" JNIEXPORT jbyteArray JNICALL Java_com_example_memreader_MemoryUtils_readMemory( JNIEnv* env, jobject /* this */, jint pid, jlong address, jint size ) { // 附加到目标进程 if (ptrace(PTRACE_ATTACH, pid, NULL, NULL) == -1) { LOGD("Attach failed: %s", strerror(errno)); return NULL; } waitpid(pid, NULL, 0); // 等待进程暂停 // 创建缓冲区 jbyteArray result = env->NewByteArray(size); jbyte* buffer = env->GetByteArrayElements(result, NULL); // 逐字读取内存 long* ptr = (long*)address; for (int i = 0; i < size/sizeof(long); i++) { long data = ptrace(PTRACE_PEEKDATA, pid, ptr + i, NULL); if (data == -1 && errno) { LOGD("Read error at %p: %s", ptr+i, strerror(errno)); break; } memcpy(buffer + i*sizeof(long), &data, sizeof(long)); } ptrace(PTRACE_DETACH, pid, NULL, NULL); // 解除附加 env->ReleaseByteArrayElements(result, buffer, 0); return result; } ``` #### 2. Java层封装 ```java public class MemoryUtils { static { System.loadLibrary("native-lib"); } public native static byte[] readMemory(int pid, long address, int size); // 示例：读取自身进程内存 public static void readSelfMemory() { long mallocAddr = 0x12345678L; // 示例地址 byte[] data = readMemory(android.os.Process.myPid(), mallocAddr, 4); Log.d("Memory", "Read value: " + bytesToInt(data)); } private static int bytesToInt(byte[] bytes) { return ByteBuffer.wrap(bytes).order(ByteOrder.LITTLE_ENDIAN).getInt(); } } ``` --- ### **方案二：通过/proc文件系统** ```cpp extern "C" JNIEXPORT jbyteArray JNICALL Java_com_example_memreader_MemoryUtils_procRead( JNIEnv* env, jobject, jint pid, jlong address, jint size ) { char mem_path[32]; sprintf(mem_path, "/proc/%d/mem", pid); FILE* mem_file = fopen(mem_path, "r"); if (!mem_file) { LOGD("Open /proc/%d/mem failed: %s", pid, strerror(errno)); return NULL; } // 定位到目标地址 if (fseek(mem_file, address, SEEK_SET) != 0) { fclose(mem_file); return NULL; } // 读取数据 jbyteArray result = env->NewByteArray(size); jbyte* buffer = env->GetByteArrayElements(result, NULL); size_t read = fread(buffer, 1, size, mem_file); fclose(mem_file); env->ReleaseByteArrayElements(result, buffer, 0); return (read == size) ? result : NULL; } ``` --- ### **Android实现关键点** 1. **权限配置**： ```xml <!-- AndroidManifest.xml --> <uses-permission android:name="android.permission.INTERNET"/> <uses-permission android:name="android.permission.ACCESS_SUPERUSER"/> ``` 2. **Root权限获取**： ```java public static boolean requestRoot() { Process process = null; try { process = Runtime.getRuntime().exec("su"); DataOutputStream os = new DataOutputStream(process.getOutputStream()); os.writeBytes("exit\n"); os.flush(); process.waitFor(); return (process.exitValue() == 0); } catch (Exception e) { return false; } } ``` 3. **地址获取方法**： - 通过`/proc/[pid]/maps`解析内存布局 ```cpp void parse_maps(int pid) { char path[32]; sprintf(path, "/proc/%d/maps", pid); FILE* maps = fopen(path, "r"); while(fgets(line, sizeof(line), maps)) { // 示例行：00400000-0040a000 r-xp 00000000 08:01 1077152 /bin/cat sscanf(line, "%lx-%lx", &start, &end); } fclose(maps); } ``` --- ### **Android内存读取限制对策** | 限制类型 | 解决方案 | |----------------|----------------------------| | SELinux限制 | 修改`/system/etc/selinux`配置 | | 非root环境 | 使用`debuggable`进程注入 | | ASLR地址随机化 | 通过maps文件计算基址偏移 | | 内存保护标记 | 临时修改`/proc/[pid]/mem`权限 | --- ### **完整工作流程** 1. 获取root权限 2. 查找目标进程PID ```shell adb shell ps | grep com.target.app ``` 3. 解析内存映射 ```java // 读取/proc/[pid]/maps获取模块基地址 ``` 4. 计算动态地址 ```java long finalAddress = baseAddress + offset; ``` 5. 执行内存读取 ```java byte[] data = MemoryUtils.readMemory(pid, finalAddress, 4); ``` --- ### **高级技巧：内存监控** ```cpp // 使用inotify监控/proc/[pid]/maps变化 int fd = inotify_init(); inotify_add_watch(fd, "/proc/目标pid/maps", IN_MODIFY); while(true) { struct inotify_event* event = read(fd); if(event->mask & IN_MODIFY) { // 触发内存布局变化回调 } } ``` --- ### **安全警告** 1. 修改系统内存可能导致应用崩溃 2. 频繁内存读取可能触发安全检测 3. 部分厂商系统（如华为EMUI）会限制/proc访问 4. Android 11+ 对非SDK接口的限制增强 建议仅在root后的测试设备上使用这些方法，并遵守《移动终端安全技术规范》等相关法规。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值