このようなパブリックメソッドのフラグメント（F1）があります

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

そして、私が（アクティビティから）それを呼び出すと、それはnullです...

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

それは私が非常に間違っていることであるに違いありませんが、それが何であるかはわかりません

commit トランザクションをスケジュールします。つまり、すぐには発生しませんが、次にメインスレッドの準備ができたときに、メインスレッドでの作業としてスケジュールされます。

追加することをお勧めします

onAttach(Activity activity)

メソッドをFragment呼び出してブレークポイントを設定し、への呼び出しと比較していつ呼び出されるかを確認しますasd()。asd()exit の呼び出しを行うメソッドの後に呼び出されることがわかります。onAttachここで、呼がFragment、その活性にし、この点から装着されているgetActivity()非ヌルが返される（NBもあるonDetach()コール）。

これを取り除くための最善の方法は、onAttachが呼び出されたときにアクティビティ参照を保持し、必要に応じてアクティビティ参照を使用することです。たとえば、

@Override
public void onAttach(Context context) {
    super.onAttach(activity);
    mContext = context;
}

@Override
public void onDetach() {
    super.onDetach();
    mContext = null;
}

これgetActivity()は、フラグメントが削除された後に終了した別のスレッドを呼び出すと発生しました。典型的なケースは、HTTPリクエストが終了したときに（たとえば）を呼び出すことですgetActivity()（たとえば）。ToastonResponse

これを回避するには、フィールド名mActivityを定義して、の代わりに使用しますgetActivity()。このフィールドは、次のようにFragmentのonAttach（）メソッドで初期化できます。

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

    if (context instanceof Activity){
        mActivity =(Activity) context;
    }
}

私のプロジェクトでは、通常、この機能を使用してすべてのフラグメントの基本クラスを定義しています。

public abstract class BaseFragment extends Fragment {

    protected FragmentActivity mActivity;

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

    if (context instanceof Activity){
        mActivity =(Activity) context;
    }
}
}

ハッピーコーディング、

onAttachでのアクティビティへの参照を維持することを示唆する他の回答は、実際の問題に対する応急処置を示唆しているだけです。getActivityがnullを返す場合、フラグメントがアクティビティに関連付けられていないことを意味します。最も一般的には、これは、ローテーションまたはアクティビティが終了したためにアクティビティがなくなったが、フラグメントにまだ何らかの種類のコールバックリスナーが登録されている場合に発生します。アクティビティで何かをする必要があるが、アクティビティがなくなった場合にリスナーが呼び出されたとき、できることはあまりありません。あなたのコードではあなただけをチェックする必要がありますgetActivity() != nullそして、それがなければ、何もしません。なくなったアクティビティへの参照を保持している場合は、アクティビティがガベージコレクションされるのを防ぎます。実行しようとする可能性のあるUIの操作は、ユーザーには表示されません。コールバックリスナーで、UIに関連しない何かのコンテキストが必要になる状況を想像できます。そのような場合は、おそらくアプリケーションコンテキストを取得する方が理にかなっています。唯一の理由ですonAttachトリックが大きなメモリリークではないは、通常、コールバックリスナーの実行後は不要になり、フラグメント、そのすべてのビュー、およびアクティビティコンテキストと共にガベージコレクションできるためです。もし、あんたがsetRetainInstance(true) アクティビティフィールドも保持されるため、メモリリークの可能性が高くなりますが、ローテーション後は、現在のアクティビティではなく、前のアクティビティになる可能性があります。

Android APIレベル23以降、onAttach（Activity activity）は非推奨になりました。onAttach（Context context）を使用する必要があります。http://developer.android.com/reference/android/app/Fragment.html#onAttach(android.app.Activity）

アクティビティはコンテキストであるため、単にコンテキストを確認できればアクティビティであり、必要に応じてキャストできます。

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

    Activity a;

    if (context instanceof Activity){
        a=(Activity) context;
    }

}

PJLは正しいです。私は彼の提案を使用しており、これは私がやったことです：

1. フラグメント用に定義されたグローバル変数：

   private final Object attachingActivityLock = new Object();

   private boolean syncVariable = false;

2. 実装された

@Override
public void onAttach(Activity activity) {
  super.onAttach(activity);
  synchronized (attachingActivityLock) {
      syncVariable = true;
      attachingActivityLock.notifyAll();
  }
}

３。メインスレッドで実行される場合、手順4でスレッドをブロックするため、getActivity（）を呼び出す必要がある関数をスレッドでラップしました。onAttach（）は呼び出されません。

    Thread processImage = new Thread(new Runnable() {

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

４。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);
    }
});

commit（）の後にコールバックが呼び出される順序：

1. commit（）の直後に手動で呼び出すメソッド
2. onAttach（）
3. onCreateView（）
4. onActivityCreated（）

ビューを含むいくつかの作業を行う必要があったため、onAttach（）は機能しませんでした。クラッシュしました。そのため、commit（）の直後に呼び出されるメソッド内にいくつかのパラメーターを設定していたコードの一部を移動し（1）、次にonCreateView（）内のビューを処理するコードの別の部分を移動しました（3）。

私はOkHttpを使用していますが、この問題に直面しました。

最初の部分では、@ thucnguyenは正しい方向に進んでいました。

これは、フラグメントが削除された後に終了した別のスレッドでgetActivity（）を呼び出すと発生しました。典型的なケースは、HTTPリクエストが終了したときに（たとえば、onResponseで）getActivity（）を呼び出すことです（Toastの場合など）。

アクティビティが閉じられた後でも、一部のHTTP呼び出しが実行されていました（HTTPリクエストが完了するまでに時間がかかるため）。次に、HttpCallbackいくつかのFragmentフィールドを更新nullしようとし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();
    }
}

この関数をどこで呼び出しますか？のコンストラクタで呼び出すと、Fragmentが返されnullます。

getActivity()メソッドonCreateView()が実行されたときに呼び出すだけです。

以下のようにしてください。参考になると思います。

private boolean isVisibleToUser = false;
private boolean isExecutedOnce = false;


@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    View root = inflater.inflate(R.layout.fragment_my, container, false);
    if (isVisibleToUser && !isExecutedOnce) {
        executeWithActivity(getActivity());
    }
    return root;
}

@Override
public void setUserVisibleHint(boolean isVisibleToUser) {
    super.setUserVisibleHint(isVisibleToUser);
    this.isVisibleToUser = isVisibleToUser;
    if (isVisibleToUser && getActivity()!=null) {
        isExecutedOnce =true;
        executeWithActivity(getActivity());
    }
}


private void executeWithActivity(Activity activity){
    //Do what you have to do when page is loaded with activity

}

onAttach（Activityアクティビティ）にまだ問題がある人は、コンテキストに変わりました-

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

ほとんどの場合、コンテキストを保存するだけで十分です。たとえば、getResources（）を実行する場合は、コンテキストから直接実行できます。コンテキストをアクティビティに追加する必要がある場合-

 @Override
public void onAttach(Context context) {
    super.onAttach(context);
    mActivity a; //Your activity class - will probably be a global var.
    if (context instanceof mActivity){
        a=(mActivity) context;
    }
}

user1868713によって提案されたとおり。

onAttachを使用するか、onAttachをどこにも配置したくない場合は、メインのAppクラスにApplicationContextを返すメソッドを配置できます。

public class App {
    ...  
    private static Context context;

    @Override
    public void onCreate() {
        super.onCreate();
        context = this;
    }

    public static Context getContext() {
        return context;
    }
    ...
}

その後、次のように、プロジェクト全体のどこでも再利用できます。

App.getContext().getString(id)

これでうまくいかない場合はお知らせください。

別の良い解決策は、MVVMアーキテクチャでAndroidのLiveDataを使用することです。ViewModel内にLiveDataオブジェクトを定義し、それをフラグメントで観察します。LiveData値が変更されると、フラグメントがアクティブな状態である場合にのみオブザーバー（この場合はフラグメント）に通知します。そのため、次のことが保証されます。フラグメントがアクティブな状態の場合にのみ、UIを機能させ、アクティビティにアクセスします。これは、1つの利点です。 LiveDataに

もちろん、この質問が最初に出されたとき、LiveDataはありませんでした。私が見るように、この問題がまだあり、誰かに役立つかもしれないので、私はこの答えをここに残します。

onActivityCreated（）内でgetActivity（）メソッドを呼び出す