DialogFragment是Android3.0之后引入的一种特殊的Fragment,官方建议使用DialogFragment代替Dialog或者AllertDialog来实现弹框的功能,因为它可以更好的管理Dialog的生命周期以及可以更好复用。
在使用过程中,由于业务需要对DialogFragment的dismiss事件进行了监听,在DialogFragment展示与消失的时候,经常会出现LeakCanary检测的内存泄露问题。查看LeakCanary的内存泄露引用链如下图所示:
这里只贴出了一张图,LeakCanary每次报出来的引用链并不完全相同,图上中显示的是RxJava的ThreadHandler,有的则显示的是高德地图的ThreadHandler(amapLocManagerThread),由此猜测这里并不是主线程的ThreadHandler引起的内存泄露,而是第三方库中的ThreadHandler引起的内存泄露。
但总的来说都是HandlerThread中处理的Message引用了NormalTitleBgDialog(DialogFragment)不能被释放。下面具体分析一下出现这个问题的原因。
那么Message是怎么引用到DialogFragment的呢?在DialogFragment中搜索一下Message一无所获。DialogFragment实际是Dialog的封装,在Dialog中搜索Message试试,果然发现Dialog的Cancle和Dismiss都是通过Handler进行操作的,从这里入手分析一下内存泄露的原因:
Cancle和Dismiss的监听传入的是DialogFragment实现的两个接口:DialogInterface.OnCancelListener,
DialogInterface.OnDismissListener
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
mDialog.setOnCancelListener(this);
mDialog.setOnDismissListener(this);
}
这里会通过mListenerHandler获取到一个mDismissMessage对象。
public void setOnDismissListener(@Nullable OnDismissListener listener) {
if (mCancelAndDismissTaken != null) {
throw new IllegalStateException(
"OnDismissListener is already taken by "
+ mCancelAndDismissTaken + " and can not be replaced.");
}
if (listener != null) {
mDismissMessage = mListenersHandler.obtainMessage(DISMISS, listener);
} else {
mDismissMessage = null;
}
}
public void setOnCancelListener(@Nullable OnCancelListener listener) {
if (mCancelAndDismissTaken != null) {
throw new IllegalStateException(
"OnCancelListener is already taken by "
+ mCancelAndDismissTaken + " and can not be replaced.");
}
if (listener != null) {
mCancelMessage = mListenersHandler.obtainMessage(CANCEL, listener);
} else {
mCancelMessage = null;
}
}
其中obtainMessage内部是通过Message.obtain方法得到,而这个方法会从消息池中通过复用的方式拿到Message。
public static Message obtain(Handler h, int what, Object obj) {
Message m = obtain();
m.target = h;
m.what = what;
m.obj = obj;
return m;
}
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize--;
return m;
}
}
return new Message();
}
至此,mDismissMessage中的obj属性引用了DialogFragment。但是Message是怎么被ThreadHandler引用到并且不能被释放的呢?下面看一下消息循环的处理过程是怎么样的。
3.Looper.loop
Looper.loop()方法在HandlerThread中运行。Looper.loop()方法执行过程就是消息的处理过程,首先从MessageQueue中取出一条消息,然后调用msg.target.dispatchMessage(msg)
分发处理消息,最后调用msg.recycleUnchecked()
回收消息。当MessageQueue中没有消息时queue.next()
方法会阻塞线程。
public static void loop() {
final Looper me = myLooper();
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
msg.target.dispatchMessage(msg);//分发消息
msg.recycleUnchecked();//回收消息
}
}
void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = UID_NONE;
workSourceUid = UID_NONE;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}
一些第三方库会创建自己的消息循环(HandlerThread),当这些消息循环(HandlerThread)中没有消息时,消息循环线程就会阻塞。从Java的内存模型我们知道线程开启时会创建自己独有的虚拟机栈空间,当消息循环发生阻塞时,方法中的局部变量不能被释放。
MessageQueue中取出的最后一条消息Message是Looper.loop()方法的局部变量,存储在栈帧的局部变量表中,由于当前线程被阻塞而不能被释放。以上我们知道了第三方库的HandlerThread会引用Message不能释放,但是第三方库的HandlerThread中的Message怎么会引用到DialogFragment呢?
由于内存泄露发生是在DialogFragment关闭时,我们看一下DialogFragment的dismiss是怎么处理的。
Dialog关闭时也是通过发送消息来实现的,这里通过Message.obtain复制了一份mDismissMessage,同样是从消息池中复用的消息,因此这里是有可能取到已经回收的消息的。
private void sendDismissMessage() {
if (mDismissMessage != null) {
// Obtain a new message so this dialog can be re-used
Message.obtain(mDismissMessage).sendToTarget();
}
}
当刚Dialog关闭dismiss时,刚好取出的是已经回收的消息,并且这条消息被另一个线程所引用,此时的mDimissMessage重新引用了DialogFragment,因此不能被回收,造成内存泄露。
总结:下图更容易说明造成内存泄露的原因。左图是线程A中的消息循环,线程A持有被回收到消息池中的消息对象,右边是主线程消息循环,Dialog关闭时从消息池中复用的的mDismissMessage被线程A持有,而mDismissMessage又持有DialogFragment,因为造成了内存泄露。
LeakCanary提供了一种解决方案:建议第三方库一直发送空的消息,保持第三方库的消息循环消息队列一直不为空。这种方式只能是提前知道哪个第三方库创建了自己的消息循环,才能向这个消息循环中发送空消息,这并不能覆盖到所有的第三方创建的消息循环。而且,不断的向一个阻塞线程中发消息,线程时刻处于运行状态,占用线程空间资源。因此,此方案对于客户端开发来说并不可行。
不监听Dialog的dimiss和cancle:如果没有需求要监听这两个方法则可以直接继承Dialog,放弃使用DialogFragment。因为DialogFragment在onActivityCreate方法中会注册dismiss和cancle的监听。网络上有种方案是通过重写DialogFragment在onActivityCreate方法中设置dialog.setOnCancelListener(null)
和 dialog.setOnDismissListener(null)
。如下所示,这种方案仍然会出现内存泄露,原因是在super.onActivityCreate()方法中仍然有 mDialog.setOnCancelListener(this)
和mDialog.setOnDismissListener(this)
。此时获取的mDismissMessage有可能是消息池中的消息,而这条消息刚好被一个消息循环所持有不能释放。
override fun onActivityCreated(savedInstanceState: Bundle?) {
super.onActivityCreated(savedInstanceState)
dialog.setOnCancelListener(null)
dialog.setOnDismissListener(null)
}
public void setOnDismissListener(@Nullable OnDismissListener listener) {
if (mCancelAndDismissTaken != null) {
throw new IllegalStateException(
"OnDismissListener is already taken by "
+ mCancelAndDismissTaken + " and can not be replaced.");
}
if (listener != null) {
mDismissMessage = mListenersHandler.obtainMessage(DISMISS, listener);
} else {
mDismissMessage = null;
}
}
弱引用的方式:mDismissMessage实际上引用的是DialogInterface.OnDismissListener,如果把这个引用改成弱引用,当系统gc时就能够回收掉DialogFragment了。这里需要注意的是不能直接继承DialogFragment,因为如果继承的是DialogFragment,当重写onActivityCreate方法时加上 super.onActivityCreated(savedInstanceState)
还会出现内存泄露,如果不加这句话则会报错。下面分步说明实现方法:
重写DialogFragment
直接拷贝DialogFragment代码至LeakDialogFragment类中,放弃实现DialogInterface.OnCancelListener
, DialogInterface.OnDismissListener
两个接口
public class LeakDialogFragment extends Fragment {
}
public void onCancelDialog(DialogInterface dialog) {
}
public void onDismissDialog(DialogInterface dialog) {
if (!mViewDestroyed) {
// Note: we need to use allowStateLoss, because the dialog
// dispatches this asynchronously so we can receive the call
// after the activity is paused. Worst case, when the user comes
// back to the activity they see the dialog again.
dismissInternal(true);
}
}
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
}
public void onDestroyView() {
super.onDestroyView();
}
public static class DialogDismissListener implements DialogInterface.OnDismissListener {
private WeakReference<LeakDialogFragment> leakDialogFragmentWeakReference;
public DialogDismissListener(LeakDialogFragment leakDialogFragment) {
this.leakDialogFragmentWeakReference = new WeakReference<>(leakDialogFragment);
}
@Override
public void onDismiss(DialogInterface dialog) {
LeakDialogFragment leakDialogFragment = leakDialogFragmentWeakReference.get();
if(leakDialogFragment!=null){
leakDialogFragment.onDismissDialog(dialog);
}
}
}
public static class DialogCancleListener implements DialogInterface.OnCancelListener {
private WeakReference<LeakDialogFragment> leakDialogFragmentWeakReference;
public DialogCancleListener(LeakDialogFragment leakDialogFragment) {
this.leakDialogFragmentWeakReference = new WeakReference<>(leakDialogFragment);
}
@Override
public void onCancel(DialogInterface dialog) {
LeakDialogFragment leakDialogFragment = leakDialogFragmentWeakReference.get();
if(leakDialogFragment!=null){
leakDialogFragment.onCancelDialog(dialog);
}
}
}
在onActivityCreated中设置自定义的onDismissListener和onCancleListener,并且在onDestroyView时设置为空。
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
mDialogDissmissLitener = new DialogDismissListener(this);
mDialog.setOnDismissListener(mDialogDissmissLitener);
mDialogCancleListener = new DialogCancleListener(this);
mDialog.setOnCancelListener(mDialogCancleListener);
}
public void onDestroyView() {
super.onDestroyView();
if(mDialogDissmissLitener!=null){
mDialogDissmissLitener = null;
}
if(mDialogCancleListener!=null){
mDialogCancleListener = null;
}
}
五、总结
本文从一个DialogFragment内存泄露问题出发,通过分析Dialog的Dismiss的监听实现方法,找出了引起内存泄露的原因。然后重写DialogFragment,通过静态内部类以及弱引用的方式来解决内存泄露问题,希望对于DialogFragment的使用有帮助。
参考:https://medium.com/square-corner-blog/a-small-leak-will-sink-a-great-ship-efbae00f9a0f
本文由哈喽比特于4年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/1t2O-UUCKhru2SAcYoCuLA
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。