しばらくの間、Otto イベント バスを使用してきましたが、非常に便利です。パッケージ内の BroadcastReceiver 実装、またはより従来のインターフェイス リスナー パターンに対して使用することの欠点は何か考えられますか?
たとえば、Google では、フラグメントのホスト アクティビティに、子フラグメントがそのホスト アクティビティを呼び出すことができるインターフェイスを実装することをお勧めします。これはすばらしいことですが、Otto を使用するとさらに簡単になります。私が思いつく唯一のことは、インターフェースを持つことでいくつかのイベントを強制的に実装することができるということですが、Otto の使いやすさに基づいて、私が望むものを注意深く聞くことだけはあまり気にしません。
Google は、人々に他のライブラリを使用するよう提案することはできないため、それを提案しています。彼らの提案は、追加のライブラリ (サポート ライブラリは別として) なしで Android OS 内で実行できる方法に常に基づいています。
otto はコンパイルされたコードの代わりにリフレクションを使用するため、パフォーマンス ヒットの一部 (非常に小さい) がありますが、Otto はリフレクトされた "もの" もキャッシュするため、このわずかなパフォーマンス ヒットは、特定のイベント クラスが最初に発生したときにのみ適用されます。
あなたが言及したように、インターフェイスが行う契約の強制がありますが、Otto の使いやすさを考えると、もう少し慎重にコーディングするだけの価値があります。
LocalBroadcastReceivers は代替手段になる可能性がありますが、インテントやインテント フィルターなどを作成するためのすべてのコードを考慮すると、それだけの価値はありません。
だから私見、ええ、先に進んでどこでもOttoを使用してください（私が現在取り組んでいるアプリでそれを行っており、月平均920Kのアクティブユーザーがいます）