Activity onDestroy方法未能及时执行原因

网上出现的情况也不少,大致看了下主要有以下几类:

  • AndroidManifest 针对某个activity 设置的theme为 @android:style/Theme.NoTitleBar

在目前项目中(android2.0),发现一个严重BUG。当打开了A,B两个页面的时候,此时当前页面为B,如果在B中调用finish()后,虽然已经回到了A,但B却并没有执行onDestroy()方法,只有在手机上按动了某一个按键后,这时才会执行B.onDestroy()。B才会完全销毁。另:如果按手机自带的返回按钮,却不会出现这种情况。


因此,如果此时在onDestroy()方法有一些操作的话,那么在回到A不进行按键操作的话,B并没有及时销毁,所以不会做方法中的这些操作。
 

经定位修改后发现,此BUG是由于在AndroidManifest.xml中对A页面设置了android:theme="@android:style/Theme.NoTitleBar"。而B页面并没有设置此参数造成的。把B增加此设置后,问题解决。

虽然问题已解决,但一直没有明白未设置android:theme="@android:style/Theme.NoTitleBar"的页面,为什么会在finish()后不能马上调用onDestroy()。按理说两者不应该有什么关联才是。

我写了一个Activity,反复进去和退出,这样重复20次,TV的内存居然从53M升到了惊人的 170M,

  • Activity 的 onDestroy() 是系统回调函数, 调用时机是不确定的

据张明云(编程,Andoid开发 话题的优秀回答者)所说,在finish()方法之后没有立即执行onDestroy()方法,只是上述这个命题的一种情况,不仅如此,Activity的其他生民周期方法何时会调用也是不确定的,onDestroy没有及时执行暂未找到有效的处理方法,但可以通过isFinishing()方法判断 Activity 是否处于销毁状态。

  • 按下home,再在recent中强行删除

这种情况据网上回答,位于栈顶的Activity是会执行onDestroy(),栈内其他Activity不会执行。据我测试,一个都没执行。因为又有回答说 Activity被手机内存强制回收是不会调用destory方法的。

  • onDestroy() 和 finish()

finish()方法用于结束一个Activity的生命周期,而onDestory()方法则是Activity的一个生命周期方法,其作用是在一个Activity对象被销毁之前,Android系统会调用该方法,用于释放此Activity之前所占用的资源。

finish会调用到onDestroy方法,
可以在onDestroy里打印一句话,就会发现在finish方法那也会打印这句话。。。

Activity.finish()
Call this when your activity is done and should be closed.
在你的activity动作完成的时候,或者Activity需要关闭的时候,调用此方法。
当你调用此方法的时候,系统只是将最上面的Activity移出了栈,并没有及时的调用onDestory()方法,其占用的资源也没有被及时释放。因为移出了栈,所以当你点击手机上面的“back”按键的时候,也不会再找到这个Activity。
Activity.onDestory()
the system is temporarily destroying this instance of the activity to save space.
系统销毁了这个Activity的实例在内存中占据的空间。
在Activity的生命周期中,onDestory()方法是他生命的最后一步,资源空间等就被回收了。当重新进入此Activity的时候,必须重新创建,执行onCreate()方法。

  • 我遇到的情况

在发现问题原因之前进行了多方面排查,主要有

  • activity调用finish却不立即执行onDestroy
  • SignFragment中实现定位?
  • intent.setClass()?
  • xml中 tools:context?
  • Androidmanifest中具体的activity的属性 configuration?
  • 项目activity达到峰值了?
  • v4 Fragment 还是 Fragment?

经过2/3的工作日时间找到了问题出处,虽然找到了问题,可是处理起来还是比较费劲。

我的情况是在Fragment中使用了下面代码,然后跳转到Activity,退出Activity时,Activity 的 onDestroy()方法延迟了几秒执行。

animation = AnimationUtils.loadAnimation(mContext, R.anim.anim_sign_in);

 @Override
 public void onResume() {
    super.onResume();
    EventBus.getDefault().register(this);
    mAnim.startAnimation(animation);
 }

 @Override
 public void onPause() {
    super.onPause();
    EventBus.getDefault().unregister(this);
    mAnim.setAnimation(null);
  }

 移除这句话的时候,Activity 的onDestroy()方法会立即执行。

mAnim.startAnimation(animation);

首先将startAnimation()改为 setAnimation(),在onPause()中在置null,发现还是一样。其次研究了一下AnimationUtils的基本使用情况,设置以下代码,效果还是一样

    @Override
    public void onResume() {
        super.onResume();
        EventBus.getDefault().register(this);
        mAnim.setAnimation(animation);
        animation.startNow();
    }

    @Override
    public void onPause() {
        super.onPause();
        EventBus.getDefault().unregister(this);
        animation.cancel();
        mAnim.setAnimation(null);
    }

将Animation 改用Animator 试试看,以我的理解是 Animation应该要被弃用了,它能实现的,Animator都能实现,并且更遵循面向对象的原则。所以改为以下方式后在运行,发现 Activity的onDestroy() 方法会随着Activity 界面消失立即执行。

    private void test() {
        ObjectAnimator anim1 = ObjectAnimator.ofFloat(mAnim,"scaleX",1.2f,0.8f);
        anim1.setRepeatCount(-1);
        ObjectAnimator anim2 = ObjectAnimator.ofFloat(mAnim,"scaleY",1.2f,0.8f);
        anim2.setRepeatCount(-1);
        AnimatorSet set = new AnimatorSet();
        set.play(anim1).with(anim2);
        set.setDuration(1000);
        set.start();
    }

    private void startAnimator() {
        Animator anim = AnimatorInflater.loadAnimator(mContext,R.animator.anim_signnal);
        anim.setTarget(mAnim);
        anim.start();
    }

问题总算是解决了,不过伴随着的知识还是有很多地方需要去了解和加深的。

### RT-DETRv3 网络结构分析 RT-DETRv3 是一种基于 Transformer 的实时端到端目标检测算法,其核心在于通过引入分层密集正监督方法以及一系列创新性的训练策略,解决了传统 DETR 模型收敛慢和解码器训练不足的问题。以下是 RT-DETRv3 的主要网络结构特点: #### 1. **基于 CNN 的辅助分支** 为了增强编码器的特征表示能力,RT-DETRv3 引入了一个基于卷积神经网络 (CNN) 的辅助分支[^3]。这一分支提供了密集的监督信号,能够与原始解码器协同工作,从而提升整体性能。 ```python class AuxiliaryBranch(nn.Module): def __init__(self, in_channels, out_channels): super(AuxiliaryBranch, self).__init__() self.conv = nn.Conv2d(in_channels, out_channels, kernel_size=3, padding=1) self.bn = nn.BatchNorm2d(out_channels) def forward(self, x): return F.relu(self.bn(self.conv(x))) ``` 此部分的设计灵感来源于传统的 CNN 架构,例如 YOLO 系列中的 CSPNet 和 PAN 结构[^2],这些技术被用来优化特征提取效率并减少计算开销。 --- #### 2. **自注意力扰动学习策略** 为解决解码器训练不足的问题,RT-DETRv3 提出了一种名为 *self-att 扰动* 的新学习策略。这种策略通过对多个查询组中阳性样本的标签分配进行多样化处理,有效增加了阳例的数量,进而提高了模型的学习能力和泛化性能。 具体实现方式是在训练过程中动态调整注意力权重分布,确保更多的高质量查询可以与真实标注 (Ground Truth) 进行匹配。 --- #### 3. **共享权重解编码器分支** 除了上述改进外,RT-DETRv3 还引入了一个共享权重的解编码器分支,专门用于提供密集的正向监督信号。这一设计不仅简化了模型架构,还显著降低了参数量和推理时间,使其更适合实时应用需求。 ```python class SharedDecoderEncoder(nn.Module): def __init__(self, d_model, nhead, num_layers): super(SharedDecoderEncoder, self).__init__() decoder_layer = nn.TransformerDecoderLayer(d_model=d_model, nhead=nhead) self.decoder = nn.TransformerDecoder(decoder_layer, num_layers=num_layers) def forward(self, tgt, memory): return self.decoder(tgt=tgt, memory=memory) ``` 通过这种方式,RT-DETRv3 实现了高效的目标检测流程,在保持高精度的同时大幅缩短了推理延迟。 --- #### 4. **与其他模型的关系** 值得一提的是,RT-DETRv3 并未完全抛弃经典的 CNN 技术,而是将其与 Transformer 结合起来形成混合架构[^4]。例如,它采用了 YOLO 系列中的 RepNCSP 模块替代冗余的多尺度自注意力层,从而减少了不必要的计算负担。 此外,RT-DETRv3 还借鉴了 DETR 的一对一匹配策略,并在此基础上进行了优化,进一步提升了小目标检测的能力。 --- ### 总结 综上所述,RT-DETRv3 的网络结构主要包括以下几个关键组件:基于 CNN 的辅助分支、自注意力扰动学习策略、共享权重解编码器分支以及混合编码器设计。这些技术创新共同推动了实时目标检测领域的发展,使其在复杂场景下的表现更加出色。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值