我有一个片段(F1)与这样的公共方法

public void asd() {
    if (getActivity() == null) {
        Log.d("yes","it is null");
    }
}

是的,当我调用它(从活动),它是空…

FragmentTransaction transaction1 = getSupportFragmentManager().beginTransaction();
F1 f1 = new F1();
transaction1.replace(R.id.upperPart, f1);
transaction1.commit();
f1.asd();

一定是我做错了什么,但我不知道是什么。


当前回答

我正在使用OkHttp,我刚刚遇到了这个问题。


@thucnguyen的第一部分是正确的。

这发生在您在另一个线程中调用getActivity()时,该线程在片段被删除后结束。典型的情况是在HTTP请求完成时调用getActivity()(例如Toast)(例如onResponse)。

一些HTTP调用甚至在活动关闭后仍在执行(因为完成HTTP请求可能需要一段时间)。然后,我通过HttpCallback试图更新一些片段字段,并在尝试getActivity()时得到一个空异常。

http.newCall(request).enqueue(new Callback(...
  onResponse(Call call, Response response) {
    ...
    getActivity().runOnUiThread(...) // <-- getActivity() was null when it had been destroyed already

IMO的解决方案是防止当片段不再活跃时发生回调(不仅仅是Okhttp)。

解决办法:预防。

如果你看一下片段的生命周期(更多信息在这里),你会注意到有onAttach(Context Context)和onDetach()方法。它们分别在Fragment属于一个活动之后和停止之前被调用。

这意味着我们可以通过在onDetach方法中控制它来防止回调的发生。

@Override
public void onAttach(Context context) {
    super.onAttach(context);

    // Initialize HTTP we're going to use later.
    http = new OkHttpClient.Builder().build();
}

@Override
public void onDetach() {
    super.onDetach();

    // We don't want to receive any more information about the current HTTP calls after this point.
    // With Okhttp we can simply cancel the on-going ones (credits to https://github.com/square/okhttp/issues/2205#issuecomment-169363942).
    for (Call call : http.dispatcher().queuedCalls()) {
        call.cancel();
    }
    for (Call call : http.dispatcher().runningCalls()) {
        call.cancel();
    }
}

其他回答

PJL是对的。 我采纳了他的建议,我是这样做的:

为fragment定义的全局变量: attachingActivityLock = new Object(); private boolean syncVariable = false; 实现

@Override onAttach(Activity Activity) { super.onAttach(活动); synchronized (attachingActivityLock) { syncVariable = true; attachingActivityLock.notifyAll (); } }

3.我在线程中包装了我的函数,在那里我需要调用getActivity(),因为如果它将在主线程上运行,我将用步骤4阻塞线程。onAttach()将永远不会被调用。

    Thread processImage = new Thread(new Runnable() {

        @Override
        public void run() {
            processImage();
        }
    });
    processImage.start();

4所示。在我的函数中,我需要调用getActivity(),我使用这个(在调用getActivity()之前)

    synchronized (attachingActivityLock) {
        while(!syncVariable){
            try {
                attachingActivityLock.wait();
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
    }

如果你有一些UI更新,记得在UI线程上运行它们。我需要更新ImgeView,所以我做了:

image.post(new Runnable() {

    @Override
    public void run() {
        image.setImageBitmap(imageToShow);
    }
});

在哪里调用这个函数?如果在Fragment的构造函数中调用它,它将返回null。

当onCreateView()方法被执行时,只需调用getActivity()。

在onActivityCreated()中调用getActivity()方法

The other answers that suggest keeping a reference to the activity in onAttach are just suggesting a bandaid to the real problem. When getActivity returns null it means that the Fragment is not attached to the Activity. Most commonly this happens when the Activity has gone away due to rotation or the Activity being finished but the Fragment still has some kind of callback listener registered preventing it from being garbage collected. When the listener gets called if you need to do something with the Activity but the Activity is gone there isn't much you can do. In your code you should just check getActivity() != null and if it's not there then don't do anything. If you keep a reference to the Activity that is gone you are preventing the Activity from being garbage collected. Any UI things you might try to do won't be seen by the user. I can imagine some situations where in the callback listener you want to have a Context for something non-UI related, in those cases it probably makes more sense to get the Application context. Note that the only reason that the onAttach trick isn't a big memory leak is because normally after the callback listener executes it won't be needed anymore and can be garbage collected along with the Fragment, all its View's and the Activity context. If you setRetainInstance(true) there is a bigger chance of a memory leak because the Activity field will also be retained but after rotation that could be the previous Activity not the current one.

我用这种方法解决了我的问题。我已经从前一个类传递了getApplicationContext,它已经访问了getApplicationContext。我已经将Inputstream对象传递给我的新类营养素。

try{
                    InputStream is= getApplicationContext().getAssets().open("nutrient_list.json");
                    Nutrients nutrients=Nutrients.getNutrients(topRecognition,is);

                  } catch (IOException e) {
                    e.printStackTrace();
                  }