为什么我的onResume被调用两次？

Basically, this is what I'm doing

基本上，这就是我正在做的事情

1) Set AlarmManager to execute BroadcastReceiver (BCR)

1）设置AlarmManager以执行BroadcastReceiver（BCR）

Intent intent = new Intent(m_Context, BCR.class);  
intent.putExtras(extras);  
PendingIntent pendingIntent = PendingIntent.getBroadcast(m_Context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);  
AlarmManager am = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
am.set(AlarmManager.RTC_WAKEUP, StartTime, pendingIntent)  

2) Start MyActivity from BCR

2）从BCR启动MyActivity

@Override  
public void onReceive(Context context, Intent intent) {  
    Intent newIntent = new Intent(context, MyActivity.class);
    newIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);  
    context.startActivity(newIntent);  
}

3) Have MyActivity turn on the screen if its not on

3）如果MyActivity未打开，请将其打开

@Override  
public void onCreate(Bundle savedInstanceState) {  
    super.onCreate(savedInstanceState); 
    getWindow().addFlags(LayoutParams.FLAG_DISMISS_KEYGUARD);
    getWindow().addFlags(LayoutParams.FLAG_SHOW_WHEN_LOCKED);
    getWindow().addFlags(LayoutParams.FLAG_TURN_SCREEN_ON);
    setContentView(R.layout.myactivity);  
} 

@Overide  
protected void onNewIntent(Intent intent) {  
    super.onNewIntent(intent);  
}  

For some reason, I notice that right when MyActivity is opened, it's flow goes like:

出于某种原因，我注意到当MyActivity打开时，它的流程如下：

onCreate/onNewIntent -> onResume -> onPause -> onResume

onCreate / onNewIntent - > onResume - > onPause - > onResume

I'm not sure why it does an onPause right away. I notice this only happens when the screened is being turned on by the flags. Does anyone know why this happens? Is there any way this behavior can be prevented?

我不确定为什么它会立即执行onPause。我注意到这只发生在标志打开被筛选时。有谁知道为什么会这样？有什么办法可以防止这种行为？

13 个解决方案

#1

Just in case anyone else runs into this, I seem to notice this behaviour only when I inflate fragments inside of an activity via XML layout. I don't know if this behaviour also happens with the compatibility library version of Fragments (I'm using android.app.Fragment)

为了防止其他人遇到这种情况，我似乎只在通过XML布局将活动内部的片段膨胀时才注意到这种行为。我不知道这种行为是否也发生在Fragments的兼容性库版本中（我使用的是android.app.Fragment）

It seems the activity will call Activity#onResume once before calling Fragment#onResume to any added Fragments, and then will call Activity#onResume again.

在将Fragment＃onResume调用到任何添加的片段之前，活动似乎会调用Activity＃onResume，然后再次调用Activity＃onResume。

1. Activity:onCreate
2. 活动：的onCreate
3. Fragment:onAttach
4. 片段：onAttach
5. Activity:onAttachFragments
6. 活动时间：onAttachFragments
7. Fragment:onCreate
8. 片段：的onCreate
9. Activity: onStart
10. 活动：onStart
11. Activity: onResume
12. 活动：onResume
13. Fragment: onResume
14. 片段：onResume
15. Activity: onResume
16. 活动：onResume

#2

If you have ES File Explorer, FORCE-STOP it. Somehow, they interrupt your app's lifecycle.

如果你有ES文件资源管理器，请强行停止它。不知何故，它们会中断您应用的生命周期。

My issue with onResume being caused twice was because onPause was somehow being called after the activity was created, something was interrupting my app.

我的onResume被引发两次的问题是因为onPause在创建活动后以某种方式被调用，有些东西正在打断我的应用程序。

And this only happens after being opened for the first time after installation or built from studio.

这只有在安装后第一次打开或者从工作室构建后才会发生。

I got the CLUE from another post and found out it was because of ES File Explorer. Why does onResume() seem to be called twice?

我从另一篇文章中得到了CLUE，发现这是因为ES文件资源管理器。为什么onResume（）似乎被调用了两次？

As soon as I 'force stop' ES File Explorer, this hiccup behavior no longer happens... very frustrating to know after trying so many other proposed solutions.

一旦我'强制停止'ES文件资源管理器，这种打嗝行为就不再发生了......在尝试了这么多其他提议的解决方案之后知道非常令人沮丧。

#3

I was researching about this for a while because on the internet there is no any mention about this weird behaviour. I don't have a solution how to overcome this dark-side-behavior but I have found an exact scenario when it certainly happens.

我正在研究这个问题一段时间，因为在互联网上没有提到这种奇怪的行为。我没有解决方法如何克服这种黑暗行为，但我确实发现了确实发生的情况。

onPause-onResume-onPause-onResume just happens every time, when app is starting first time after installation. You can simply invoke this behavior by doing any change in code and rerunning (which includes recompiling) the app from your IDE.

onPause-onResume-onPause-onResume每当安装后第一次启动app时就会发生。您可以通过对代码进行任何更改并从IDE重新运行（包括重新编译）应用程序来简单地调用此行为。

No matter if you use AppCompat libs or not. I have tested both cases and behavior carries on.

无论您是否使用AppCompat库。我已经测试了这两种情况和行为继续进行。

Note: Tested on Android Marshmallow.

注意：在Android Marshmallow上测试过。

I have borrowed the code from this thread about fragment and activity lifecycle and here it is (just copy, paste, declare activity in manifest and run Forest run):

我从这个线程中借用了有关片段和活动生命周期的代码，这里是（只需复制，粘贴，在清单中声明活动并运行Forest运行）：

import android.app.Activity;
import android.app.Fragment;
import android.app.FragmentTransaction;
import android.content.Context;
import android.os.Bundle;
import android.util.Log;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.TextView;

public class TestActivity extends Activity {

    private static final String TAG = "ACTIVITY";

    public TestActivity() {
        super();
        Log.d(TAG, this + ": this()");
    }

    protected void finalize() throws Throwable {
        super.finalize();
        Log.d(TAG, this + ": finalize()");
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.d(TAG, this + ": onCreate()");


        TextView tv = new TextView(this);
        tv.setText("Hello world");
        setContentView(tv);

        if (getFragmentManager().findFragmentByTag("test_fragment") == null) {
            Log.d(TAG, this + ": Existing fragment not found.");
            FragmentTransaction ft = getFragmentManager().beginTransaction();
            ft.add(new TestFragment(), "test_fragment").commit();
        } else {
            Log.d(TAG, this + ": Existing fragment found.");
        }
    }

    @Override
    public void onStart() {
        super.onStart();
        Log.d(TAG, this + ": onStart()");
    }

    @Override
    public void onResume() {
        super.onResume();
        Log.d(TAG, this + ": onResume()");
    }

    @Override
    public void onPause() {
        super.onPause();
        Log.d(TAG, this + ": onPause()");
    }

    @Override
    public void onStop() {
        super.onStop();
        Log.d(TAG, this + ": onStop()");
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        Log.d(TAG, this + ": onDestroy()");
    }


    public static class TestFragment extends Fragment {

        private static final String TAG = "FRAGMENT";

        public TestFragment() {
            super();
            Log.d(TAG, this + ": this() " + this);
        }

        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            Log.d(TAG, this + ": onCreate()");
        }


        @Override
        public void onAttach(final Context context) {
            super.onAttach(context);
            Log.d(TAG, this + ": onAttach(" + context + ")");
        }

        @Override
        public void onActivityCreated(Bundle savedInstanceState) {
            super.onActivityCreated(savedInstanceState);
            Log.d(TAG, this + ": onActivityCreated()");
        }

        @Override
        public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
            Log.d(TAG, this + ": onCreateView()");
            return null;
        }

        @Override
        public void onViewCreated(View view, Bundle savedInstanceState) {
            super.onViewCreated(view, savedInstanceState);
            Log.d(TAG, this + ": onViewCreated()");
        }

        @Override
        public void onDestroyView() {
            super.onDestroyView();
            Log.d(TAG, this + ": onDestroyView()");
        }

        @Override
        public void onDetach() {
            super.onDetach();
            Log.d(TAG, this + ": onDetach()");
        }

        @Override
        public void onStart() {
            super.onStart();
            Log.d(TAG, this + ": onStart()");
        }

        @Override
        public void onResume() {
            super.onResume();
            Log.d(TAG, this + ": onResume()");
        }

        @Override
        public void onPause() {
            super.onPause();
            Log.d(TAG, this + ": onPause()");
        }

        @Override
        public void onStop() {
            super.onStop();
            Log.d(TAG, this + ": onStop()");
        }

        @Override
        public void onDestroy() {
            super.onDestroy();
            Log.d(TAG, this + ": onDestroy()");
        }
    }

}

#4

I don't know for sure what's going on, but I suspect that your activity is being restarted because setting the screen on is treated by the system as a configuration change. You might try logging the configuration on each call to onResume to see if that's what's happening and, if so, what is actually changing. You can then modify the manifest to tell the system that your activity will handle the change on its own.

我不确定发生了什么，但我怀疑您的活动正在重新启动，因为设置屏幕被系统视为配置更改。您可以尝试在每次调用onResume时记录配置，看看是否正在发生这种情况，如果是，那么实际发生了什么变化。然后，您可以修改清单，告诉系统您的活动将自行处理更改。

protected void onResume() [
    super.onResume();
    Configuration config = new Configuration();
    config.setToDefaults();
    Log.d("Config", config.toString());
    . . .
}

#5

I had a similar issue, and my problem was that at the onCreate() method, I was doing:

我有一个类似的问题，我的问题是在onCreate（）方法，我正在做：

@Override
protected void onCreate(Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);
    super.setContentView(R.layout.friends);  <-- problem
}

My call to "super." was triggering the onResume() twice. It worked as intended after I changed it to just:

我打电话给“超级”。两次触发onResume（）。在我将其更改为以下之后，它按预期工作：

@Override
protected void onCreate(Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);
    setContentView(R.layout.friends);  <-- 'super.' removed
}

Hope it helps.

希望能帮助到你。

#6

I have similar problem. My situation was next CurrentActivity extends MainActivity CurrentFragment extends MainFragment

我有类似的问题。我的情况是下一个CurrentActivity扩展MainActivity CurrentFragment扩展MainFragment

I was opening CurrentActivity with intent as usually. In onCreate CurrentAcitivity I was replacing CurrentFragment.

我通常是故意打开CurrentActivity。在onCreate CurrentAcitivity中，我正在替换CurrentFragment。

Life Cycle was: 1. onResume MainActivity 2. onResume CurrentActivity 3. onResume MainFragment 4. onResume CurrentFragment

生命周期是：1。onResume MainActivity 2. onResume CurrentActivity 3. onResume MainFragment 4. onResume CurrentFragment

called onPause Automatically, and after that again

自动调用onPause，然后再调用

1. onResume MainActivity
2. onResume MainActivity
3. onResume CurrentActivity
4. onResume CurrentActivity
5. onResume MainFragment
6. onResume MainFragment
7. onResume CurrentFragment
8. onResume CurrentFragment

I decide to retest everything and after few hours spend trying and playing I found root issue. In MainFragment onStart I was calling startActivityForResult every time (in my case android popup for turning on Wifi) which was call onPause on MainFragment. And all of us know that after onPause next is onResume.

我决定重新测试所有内容，经过几个小时的尝试和玩游戏，我找到了root问题。在MainFragment onStart中，我每次调用startActivityForResult（在我的情况下是用于打开Wifi的android弹出窗口），它在MainFragment上调用onPause。我们所有人都知道onPause接下来是onResume。

So its not Android bug, it's only mine :-)

所以它不是Android的bug，它只是我的:-)

Happy lifecycle debuging!

快乐的生命周期！

#7

I also ran into this onresume-onpause-onresume sequence (on 4.1.2 and above, but I did not experience this on 2.3). My problem was related to wakelock handling: I accidentally forgot to release a wakelock and reacquiring it caused an error with a message "WakeLock finalized while still held". This problem resulted in onPause being called immediately after onResume and resulted in faulty behavior.

我也遇到了这个onresume-onpause-onresume序列（在4.1.2及更高版本上，但我没有在2.3上遇到过这个）。我的问题与唤醒锁处理有关：我不小心忘记释放唤醒锁并重新获取它导致错误，并显示“WakeLock在保持时仍然完成”的消息。此问题导致在onResume之后立即调用onPause并导致错误行为。

My suggestion is: check for errors in the log, those might be related to this issue.

我的建议是：检查日志中的错误，这些可能与此问题有关。

Another hint: turning on the screen might be a bit more tricky than simply using window flags. You might want to check this answer here - it suggests you set up a receiver to check if the screen has already been turned on and launch the desired activity only after: https://*.com/a/16346369/875442

另一个提示：打开屏幕可能比简单地使用窗口标志更棘手。您可能需要在此处查看此答案 - 它建议您设置接收器以检查屏幕是否已打开并仅在以下情况下启动所需的活动：https：//*.com/a/16346369/875442

#8

It seems that using Activity from the support library saves and restores instance automatically. Therefore, only do your work if savedInstanceState is null.

似乎使用支持库中的Activity自动保存和恢复实例。因此，如果savedInstanceState为null，则仅执行您的工作。

#9

I just ran into this, and it seems that getWindow().addFlags() and tweaking Window properties in general might be a culprit.

我刚碰到这个，似乎getWindow（）。addFlags（）和调整Window属性一般可能是罪魁祸首。

When my code is like this

当我的代码是这样的

@Override
protected void onCreate(Bundle savedInstanceState) {
    requestWindowFeature(Window.FEATURE_NO_TITLE);
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_generic_fragment_host);
    // performing fragment transaction when instance state is null...

onResume() is triggered twice, but when I remove requestWindowFeature(), it's only called once.

onResume（）被触发两次，但当我删除requestWindowFeature（）时，它只被调用一次。

#10

I think you should have a look at that question: Nexus 5 going to sleep mode makes activity life cycle buggy You should find leads

我想你应该看一下这个问题：Nexus 5进入睡眠状态让活动生命周期越来越多你应该找到潜在客户

#11

Basically a lot of stuff can trigger this. Some resume processes that loses focus can do it. A few apps will cause it to happen too. The only way to cope is to block the double running. Note, this will also have an errant pause thrown in for good measure.

基本上很多东西都可以触发这个。一些失去焦点的恢复过程可以做到。一些应用程序也会导致它发生。应对的唯一方法是阻止双重运行。请注意，这也会有一个错误的暂停，以获得良好的衡量标准。

    boolean resumeblock = false;

    @Override
    protected void onResume() {
        super.onResume();
        sceneView.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
            @Override
            public boolean onPreDraw() {
                sceneView.getViewTreeObserver().removeOnPreDrawListener(this);
                if (resumeblock) return false;
                resumeblock = true;

                //Some code.

                return false;
            }
        });
    }

This is a solid way to prevent such things. It will block double resumes. But, it will also block two resumes that preserve the memory. So if you just lost focus and it doesn't need to rebuild your stuff. It will block that too. Which might be a benefit clearly, since if you're using the resume to control some changes over focus, you only actually care if you need to rebuild that stuff because of focus. Since the pre-draw listeners can only be called by the one thread and they must be called in sequence, the code here will only run once. Until something properly destroys the entire activity and sets resumeblock back to false.

这是防止此类事情的可靠方法。它将阻止双重简历。但是，它还会阻止两个保留内存的简历。所以，如果你失去了焦点，它不需要重建你的东西​​。它也会阻止它。这可能是一个明显的好处，因为如果你使用简历来控制焦点上的一些变化，你实际上只关心你是否因为焦点需要重建那些东西。由于预绘制侦听器只能由一个线程调用，并且必须按顺序调用它们，因此此处的代码只运行一次。直到某些东西正确销毁整个活动并将resumeblock设置为false。

#12

i also faced this issue this is because of fragments.. the number of fragments you have in activity onResume() will call that number of times. to overcome i used flag variables in SharedPrefrences

我也遇到了这个问题，这是因为碎片..你在活动onResume（）中拥有的碎片数量会调用那么多次。克服我在SharedPrefrences中使用的标志变量

#13

if you trying request permissions every time it can cause such problems, just check if you already granted them

如果您每次尝试请求权限都会导致此类问题，请检查您是否已授予权限

requestPermissions can cause it:

requestPermissions可以导致它：

onCreate
onStart
onResume
onPause
onResume