android.app.LoadedApk.mReceivers 内存泄漏

已于 2022-12-30 19:22:58 修改
阅读量1k 收藏
点赞数 1
分类专栏： 个人笔记 Android 文章标签： android java
于 2022-12-30 19:19:44 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/csdn_pun/article/details/128498636
版权
本文探讨了Android应用中由于未正确注销广播接收器导致的内存泄漏问题。通过两种方法定位内存泄漏的广播，一是逐一排查，二是分析hprof文件。重点讲解了如何从LoadedApk的mReceivers找到泄漏的广播，并强调了ArrayMap数据结构在定位问题中的作用。同时提醒开发者注意混淆可能导致的广播名称识别困难。

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

android.app.LoadedApk.mReceivers 内存泄漏

内存泄漏原因

== 总结：注册的广播没有进行注销 ==
原理请自行阅读源码分享，下面提供两个关键方法代码简单说明
1.注册广播
在这里插入图片描述
2.注销广播
在这里插入图片描述

定位到对应的广播
方法一，逐个广播排查，如果好找的话
方法二，通过分析hprof文件定位

1.通过泄漏的Activity定位到对应的LoadedApk
在这里插入图片描述

2.查看对应的LoadedApk的mReceivers
在这里插入图片描述

3.找到泄漏的Activity，以及它所注册的广播
在这里插入图片描述
请自行了解ArrayMap的数据结构，我这里直接给结论
n = Activity，n+1 = 对应的广播信息。所以我这里就看 4+1 = 5 的信息就可以知道是哪个广播了
在这里插入图片描述
图中的"c$a"广播被混淆了，请自行对应mapping文件进行查找。

Android Framework AMS（12）广播组件分析-3（广播发送流程解读）
wangdsh的博客
11-06 1361
说明：本章节主要解读广播组件的广播发送过程。关注思维导图中左侧部分即可。有了前面广播组件 注册和注销程分析的基础，基于此，接下来我们来分析广播组件的发送广播流程。我们先对广播组件的整体设计思路有一个了解，再详细分析其广播发送关键流程。
Android全面解析之Context机制
一只修仙的猿
10-11 8322
前言 很高兴遇见你~ 欢迎阅读我的文章。 在文章Android全面解析之由浅及深Handler消息机制中讨论到，Handler可以： 避免我们自己去手动写 死循环和输入阻塞 来不断获取用户的输入以及避免线程直接结束，而是采用事务驱动型设计，使用Handler消息机制，让AMS可以控制整个程序的运行逻辑。 这是关于android程序在设计上更加重要的一部分，不太了解的读者可以前往阅读了解一下。而当我们知道android程序的程序是通过main方法跑起来的，然后通过handler机制来控制程序的运行，那么四
Android: Application, LoadedApk对象
u011279649的专栏
07-12 3686
android.app.Apolication frameworks/base/core/java/android/app/Application.java /**  * Base class for maintaining global application state. You can provide your own  * implementation by creating a sub...
Android内存泄漏问题排查分析及常见解决方案_android内存泄露的几种情况
2401_84556656的博客
05-08 2604
这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免重复创建，不过这种写法会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而又使用了该非静态内部类创建了一个静态实例，该实例的生命周期和应用一样长，这就导致了该静态实例一直持有该Activity的引用，导致Activity的内存资源不能正常回收；它是造成应用程序OOM的主要原因之一；如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。
（4.6.10.2）Android LoadedApk详解
JAVA成长之路
05-30 4259
文章目录一、LoadedApk的构建函数和成员变量二、LoadedApk的在ActivityThread中的获取三、LoadedApk的mApplication创建Application实例四、LoadedApk的mResources创建Resources实例 是ActivityThread中进行四大组件等启动过程中的重要中间变量 LoadedApk对象是APK文件在内存中的表示。 Apk文件的相关信息，诸如Apk文件的代码和资源，甚至代码里面的Activity，Service等组件的信息我们都可以通过此
Android中的LoadedApk：使用指南与核心代码解析
zhangjiaofa的专栏
01-06 1187
LoadedApk是Android系统中的一个内部类，位于包中。它代表了一个已加载的APK文件，负责管理应用程序的资源、类加载器、以及与其他系统组件的交互。LoadedApk资源管理LoadedApk负责管理应用程序的资源，包括布局文件、字符串、图片等。类加载器管理LoadedApk负责创建和管理应用程序的类加载器，用于加载应用程序的类和资源。上下文管理LoadedApk与Context密切相关，负责为应用程序提供上下文环境。
loadedapk.java_求解答： at android.app.LoadedApk.initializeJavaConte
weixin_30838923的博客
02-16 221
原来一直运行的好好的，后来添加了表情模块，然后就一直在报10-26 08:51:44.058: E/AndroidRuntime(2018): java.lang.RuntimeException: Unable to instantiate application com.example.w3c_school.utils.ApplicationDIV: java.lang.NullPointer...
Android应用可执行文件的加载介绍(LoadedApk)
拿节
08-27 3798
Android应用启动后可加载的代码文件有三种，按加载顺序依次如下： androidmanifest内uses-library指定的jar APK包根目录的dex文件 APK包lib目录下的so文件 可以在manifest里随便指定想要加载的jar吗？当然不行，这个jar必须是在/etc/permissions/目录下的xml有过配置的，比如： //截取/etc/permissions/pla...
Android中的四大组件详解
joye123的博客
04-27 6070
Android中的四大组件详解 我们都知道Android系统应用层框架中，为开发者提供了四大组件来便于应用的开发，它们是Activity、Service、BroadcastReceiver、ContentProvider。 它们用于在应用开发过程中，不同场景的功能实现。 Activity：Activity是开发中最常用的，也是最复杂的一个组件。它是用户可以专注做一些事情的东西。它的主要功能就是可以和用户进行交互操作，所以几乎所有的Activity都会负责创建一个显示窗口，然后通过setContentView
BroadcastReceiver详解
joye123的博客
04-01 745
BroadcastReceiver详解 使用方式 在Manifest.xml文件中注册 <receiver android:name=".test.broadcast.MyTestReceiver" android:enabled="true" android:exported="true"> <intent-filter> <action android:name="android.intent.action.ACTION_POWER_CONNEC
Service的bindService和unbindService的处理流程（分析源码）
淡淡的宁静的博客
12-29 3778
AMS处理bindService请求： ActiveServices#bindServiceLocked bindServiceLocked(IApplicationThread caller, IBinder token, Intent service, String resolvedType, final IServiceConnection connection...
【Android 逆向】启动 DEX 字节码中的 Activity 组件 ( 替换 LoadedApk 中的类加载器 | 加载 DEX 文件中的 Activity 类并启动成功 )
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
12-12 2051
前言、 一、替换 LoadedApk 中的类加载器、 1、获取 ActivityThread 实例对象、 2、获取 LoadedApk 实例对象、 3、替换 LoadedApk 实例对象中的 mClassLoader 类加载器、 二、完整代码示例、 三、执行结果、 四、博客资源、
Android插件化的实现(3)--LoadedApk式插件化的实现
做一个苦行僧的专栏
10-26 857
上面介绍了关于插桩式插件化实现和Hook式插件化的实现，也分析了他们的优缺点。这次来讲解一下自定义LoadedApk式的插件化实现。 LoadedApk形式的插件化实现大致流程和需要反射的点如下图(我是基于Android28的sdk下反射)： 流程： 1.首先还是需要Hook AMS 相关的检查，将需要启动的插件的Activity 替换成能够绕过AMS检查的Pr...
loadedapk.java_统计下android.app.LoadedApk.makeApplication报错的原因
weixin_39959482的博客
02-26 409
08-07 09:02:28.359: E/AndroidRuntime(2769): FATAL EXCEPTION: main08-07 09:02:28.359: E/AndroidRuntime(2769): java.lang.RuntimeException: Unable to instantiate application com.scdhkj.phone.activity.MyA...
【Android 安全】DEX 加密 ( Application 替换 | Android 应用启动原理 | LoadedApk 后续分析 )
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
11-28 1027
一、LoadedApk 后续分析、 二、LoadedApk 后续先关源码、
【Android 安全】DEX 加密 ( Application 替换 | Android 应用启动原理 | LoadedApk 源码分析 )
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
11-27 2836
一、LoadedApk 源码分析、 二、LoadedApk 源码 makeApplication 方法分析
【Android 安全】DEX 加密 ( Application 替换 | 获取 ContextImpl、ActivityThread、LoadedApk 类型对象 )
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
12-22 827
一、获取对象类型分析、 二、替换 Application 时机、
【Android 逆向】加壳的 Android 应用启动流程 | 使用反射替换 LoadedApk 中的类加载器流程
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
12-11 1701
一、加壳的 Android 应用启动流程、 二、使用反射替换 LoadedApk 中的类加载器流程
统计下android.app.LoadedApk.makeApplication报错的原因
别了高山
08-07 5253
08-07 09:02:28.359: E/AndroidRuntime(2769): FATAL EXCEPTION: main 08-07 09:02:28.359: E/AndroidRuntime(2769): java.lang.RuntimeException: Unable to instantiate application com.scdhkj.phone.activity.M
03-16 12:33:00.942 18324 18324 E AndroidRuntime: FATAL EXCEPTION: main 03-16 12:33:00.942 18324 18324 E AndroidRuntime: Process: com.android.bluetooth, PID: 18324 03-16 12:33:00.942 18324 18324 E AndroidRuntime: java.lang.IllegalArgumentException: Receiver not registered: com.oplus.bluetooth.feature.dcs.OplusBluetoothRecorderFactory$1@f666353 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java:1777) 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at android.app.ContextImpl.unregisterReceiver(ContextImpl.java:1922) 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at android.content.ContextWrapper.unregisterReceiver(ContextWrapper.java:832) 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at com.oplus.bluetooth.feature.dcs.03-16 12:33:00.942 18324 18324 E AndroidRuntime: FATAL EXCEPTION: main 03-16 12:33:00.942 18324 18324 E AndroidRuntime: Process: com.android.bluetooth, PID: 18324 03-16 12:33:00.942 18324 18324 E AndroidRuntime: java.lang.IllegalArgumentException: Receiver not registered: com.oplus.bluetooth.feature.dcs.OplusBluetoothRecorderFactory$1@f666353 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java:1777) 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at android.app.ContextImpl.unregisterReceiver(ContextImpl.java:1922) 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at android.content.ContextWrapper.unregisterReceiver(ContextWrapper.java:832) 03-16 12:33:00.942 18324 18324 E AndroidRuntime: at com.oplus.bluetooth.feature.dcs.OplusBluetoothRecorderFactory.cleanUp(OplusBluetoothRecorderFactory.java:312).cleanUp(OplusBluetoothRecorderFactory.java:312) 帮我看看报错是什么，是什么类型的报错，怎么导致的
最新发布
03-21
<think>好的，我现在需要帮助用户解决Android中的java.lang.IllegalArgumentException: Receiver not registered异常。首先，我需要理解这个异常的具体原因和可能的解决方案。根据用户提供的引用内容，有几个关键点需要注意。 首先，用户提供的引用[1]、[2]和[3]都提到了这个异常，指出当尝试反注册一个未注册的BroadcastReceiver时会抛出这个错误。引用[3]还提到，解决方法是确保注册和反注册在onResume和onPause中进行，因为这两个方法通常是成对调用的，这样可以避免异常发生。同时，引用[4]提到了处理WebView时的情况，建议在onDestroy中设置WebView为GONE并延迟销毁。引用[5]则指出在Fragment中注册和反注册时，Context和BroadcastReceiver对象可能不一致的问题。 接下来，我需要将这些信息整理成结构化的回答，包括原因和解决方案。可能的原因包括重复反注册、生命周期不同步、Fragment中的上下文问题以及WebView的ZoomControls未处理。解决方案需要针对每个原因给出具体的步骤，比如检查注册状态、使用对称的生命周期方法、确保上下文一致、处理WebView的特殊情况，以及使用try-catch块捕获异常。 在整理过程中，需要注意用户提到的站内引用，确保每个引用对应的解决方案都被正确引用，比如引用[3]、[4]、[5]分别对应不同的解决方法。同时，要遵循用户给出的格式要求，比如使用中文回答，正确使用LaTeX格式，以及生成相关问题。 最后，生成的相关问题需要围绕该异常的其他可能原因、生命周期管理、Fragment中的处理、WebView相关的问题以及如何调试展开，确保覆盖用户可能关心的其他方面。</think>### Android java.lang.IllegalArgumentException: Receiver not registered 异常解析 #### 异常原因 1. **重复反注册** 当尝试调用`unregisterReceiver()`时，如果接收器（BroadcastReceiver）未注册或已注销，系统会抛出此异常。常见于多次调用反注册逻辑或生命周期管理混乱[^3]。 2. **生命周期不同步** 在Activity/Fragment中，注册和反注册未成对出现。例如： - 在`onCreate`注册但未在`onDestroy`反注册 - 在`onResume`注册但未在`onPause`反注册 3. **Fragment中的上下文问题** Fragment销毁时使用的上下文（Context）与注册时不一致。例如： ```java // 错误示例：可能使用已销毁的Activity上下文 getActivity().unregisterReceiver(receiver); ``` 4. **WebView的ZoomControls未处理** WebView内置的缩放控件（ZoomButtonsController）未正确销毁，导致反注册时触发异常[^4]。 --- #### 解决方案 ##### 1. 确保注册与反注册成对出现 - **对称生命周期方法** 推荐在`onResume`注册，`onPause`反注册： ```java @Override protected void onResume() { super.onResume(); registerReceiver(receiver, filter); } @Override protected void onPause() { super.onPause(); unregisterReceiver(receiver); // 确保receiver不为null } ``` 此方法可避免Activity后台时接收器未注销的问题。 ##### 2. 检查注册状态 - 添加状态标志防止重复操作： ```java private boolean isReceiverRegistered = false; private void registerMyReceiver() { if (!isReceiverRegistered) { registerReceiver(receiver, filter); isReceiverRegistered = true; } } private void unregisterMyReceiver() { if (isReceiverRegistered) { unregisterReceiver(receiver); isReceiverRegistered = false; } } ``` ##### 3. 处理WebView特殊情况 在包含WebView的Activity中，需延迟销毁WebView： ```java @Override protected void onDestroy() { if (webView != null) { webView.setVisibility(View.GONE); new Timer().schedule(new TimerTask() { @Override public void run() { webView.destroy(); } }, ViewConfiguration.getZoomControlsTimeout()); // 延迟3000ms } super.onDestroy(); } ``` 此方法可避免ZoomControls未及时销毁导致的异常[^4]。 ##### 4. Fragment中的正确实践 - 使用`requireContext()`代替`getActivity()`确保上下文有效性： ```java // 注册时 requireContext().registerReceiver(receiver, filter); // 反注册时 requireContext().unregisterReceiver(receiver); ``` - 在`onStart`/`onStop`中管理接收器[^5]。 ##### 5. 异常捕获（备用方案） ```java try { unregisterReceiver(receiver); } catch (IllegalArgumentException e) { Log.w("TAG", "Receiver already unregistered"); } ``` --- #### 引用总结 - 注册/反注册生命周期需严格匹配 - WebView需延迟销毁并隐藏 - Fragment中需验证上下文一致性[^5] ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值