もちろん、この質問は利便性に関するものですが、アプリの現在のフレームワークを考慮する必要があります:

1. 上記のようにコールバックを使用しますが、コールバックは静的変数によって参照されるため、一般にコールバックは匿名の内部クラスであり、メモリ リークが発生する可能性があることに注意してください。

イベントバスを使用します。中間層も実装し、イベントバスを介して結果を送信します。
推奨事項:
3. リファクタリングなので、すべてのコントロールに onActivityResult の結果を取得する機能を持たせることを検討できます。

   interface onActivityResult {
   リーリー
   }

   コールバックをリッスンする必要があるカスタム コントロールは、BaseActivity でこれらのコントロールを記録し、結果が返されたときにこれらのコントロールに渡す必要があります。 リーリー

   }
   これにより、コントロールがアクティビティの結果を取得する必要があるという問題が完全に解決されます。
   

   
   上記は大まかなコードですが、実際には考慮事項もあります。 requestCode とすべての View を保存する必要があるという問題です。

リスナー形式で処理するだけです。

上記で述べたことは良いことです。インターフェイスを定義し、他の一般的なビューはこのインターフェイスを実装するだけです。

私たちのアプローチは、写真撮影とフォトアルバムをモジュールとして記述し、アバターを設定するコンポーネントにクリックイベントを追加し、クリックして処理インターフェースにジャンプしてから戻るというものです。設定コンポーネントはモジュールには含まれず、モジュールのユーザーによって設定されます。
もう 1 つの方法は、上記のようにイベント監視を使用することです。アルバムの写真を選択するか、写真を撮って写真を確認した後、このリスナーをトリガーします。
モジュールに入口ビューを必ず書くかどうか上司に尋ねることをお勧めします

ローカル maven ウェアハウスを構築し、このコントロール、ポップアップ ウィンドウ、およびジャンプ関数をカプセル化します。次に、それをローカルのmavenウェアハウスに直接アップロードし、Gradle
を介してプロジェクトに依存します。ローカルのMavenウェアハウスを構築し、Gradleを構成し、独自のライブラリをウェアハウスにアップロードします

一般的に、これは基本的な機能を備えたライブラリに対して実行でき、1 人で保守できます

コールバックを通じて呼び出し元に結果を渡すには onActivityResult 没问题呀，哔哩哔哩就是这样处理的 boxing；
不想让调用者处理 onActivityResult，可以写个中间 Activity 处理完 onActivityResult を使用するか、カメラをカスタマイズします。

他のインターフェースを伴うこの種のロジックの場合、通常は別のモジュールを作成し、呼び出し時にそのインターフェースを使用します。実装層は中間アクティビティを使用して画像の選択/処理を完了し、最後にコールバックを通じて戻ります。

これらのものを自分で書く必要さえありません。GitHub には既製のホイールがたくさんあります。ImagePicker を見つけてそれを使用するだけです。

皆さん、ありがとう。この答えは基本的に私が言いたいことです。 私の質問は明確ではありません。私のリファクタリングは、ユニバーサルアバターコントロールを作成することではなく、このアバタービューをビジネスアクティビティのレイアウトに組み込むことであり、呼び出し側は他に何もする必要がありません。どのネットワークがアバターの更新、アバターのアップロード、写真の選択を要求するか...当社のこれらのアプリのアバター関連インターフェースは共通であるため、自分で処理するために彼に電話をかけ直すのではなく、すべてがカプセル化されます