Android data-binding？の長所と短所は何ですか？
同僚と私はどちらもWebアプリのMVVMの経験がありますが、ネイティブAndroid開発は初めてです。現在、Androidデータバインディングについて反対意見があります。彼はそうではありませんが、私はそれが好きです。
私の議論：
- 順番にもたらす定型コードを削減します
- 少ないカップリング
- より読みやすく
- 強力で実装しやすいカスタム属性とカスタムビュー
- FindViewByIdよりも高速です（ details ）
彼の議論：
- 自動生成された.classは、アプリのサイズを増やします。
- デバッグが難しい
私はいくつかの調査を行いましたが、それについて多くの議論はありません。次に、Androidデータバインディングの長所と短所を収集します。
議論の側面には以下が含まれますが、これらに限定されません。
- 単体テスト
- アプリサイズ
- 性能
- 学習曲線
- 読みやすさ
- カップリング
最初にあなたの議論についてコメントし、それから私の意見を述べます。
1.定型コードを削除します。一部を削除し、xml内の一部を移動するか、追加のクラスが必要になります。そのため、データバインディングの使用には注意してバランスを取る必要があります。
2.読みやすさ-あなたが新しい開発者であれば簡単に習得できるかもしれませんが、以前に作業していた場合はAndroidを習得するのに余分な時間が必要になります。
3.強力-コードはより強力で、コードに好きなものを実装できます。このように考えてください。データバインディングを使用して実装するすべてのものには同等のコードがあります（記述するコードが長くなります）が、リバースは有効ではありません。
4. findViewByIdよりも高速-これらの2つの速度を比較すると、私の意見では役に立たないので、違いに気付かないでしょう。違いが見られれば、実装の1つが間違っています。
5.自動生成されたクラス-それはアプリのサイズを増やすことは確かですが、それはあなたがそれをたくさん持っている場合にのみ重要です。 Android devウェブサイトで、自動生成されたコードを作成するライブラリまたは余分なコードを生成するannotationsを使用するのは少し悪いと述べているのは事実です。
6.デバッグが難しい-読みやすさなど、慣れているものに依存しますが、いくつかの問題ではデバッグが難しいため、別のライブラリを使用しないでデバッグすることで改善されます。
だからこれは純粋な私の意見です、私はさまざまなライブラリとさまざまなアプローチを使用して多くのアプリを開発し、それらにはすべて長所と短所がありましたが、私が学んだこと：すべてのバランスを取り、大量のライブラリを使用しないで、無駄にしないでくださいすでに実装され、うまく機能するものを実装する時間、「すべてを分離」しない、すべてを「結合」しない、コードのみを使用しない、すべてを「生成」しようとしないでください。
私はそれがかなり間違っていると思います、そしてあなたがいくつかのライブラリ/実装について「賛否両論」を求めるならば、あなたは間違った考えを得ることができます、通常それは公平ではないので、あなたが使用した誰かから多くのプロを得ますライブラリは特定の方法で機能しましたが、他のライブラリは異なる方法で使用し、機能しなかったため、短所があります。
結論として、私はあなたがライブラリがあなたのためにできることとあなたのためにできないことをチェックし、それがあなたのセットアップに適しているかどうかを判断すべきだと思います。言い換えれば、ライブラリが他の人ではなくあなたにとって良いかどうかを判断する必要があります;）.
更新-2018年8月8日
まず第一に、このような状況ではバランスが重要です。しかし、私の場合、データバインディングは開発プロセスを少しスピードアップし、改善しました。ここに、皆さんが考えるべきいくつかの新しいポイントがあります。
UIのテスト-データバインディングを使用すると、UIのテストがはるかに簡単になりますが、データバインディングだけでは十分ではありません。また、優れたアーキテクチャが必要です。Googleが推奨するアーキテクチャを使用すると、データバインディングの実際の能力がわかります。
最も目に見える変化は、元の回答からポイント2と5に提供されました。データバインディングを使用するが決定した後、コードを読むのが簡単になりました。ここで最も重要なことは、チームとして決定したことです。データバインディングを使用し、その後、XMLファイルにほとんどの些細で基本的なUIセットアップが含まれることが予想されます。
デバッグの部分については、ここで少し注意が必要です。Android Studioにはエラーを改善し、データバインディングのオートコンプリートがたくさんありますが、最も一般的なエラーは最初の後に発生します2-3発生。また、「クリーンなプロジェクト」が時折、「大いに役立つ」ことを学びました。
- 考慮しなければならない別のポイントは、データバインディングを使用するためのプロジェクト構成です。現在、AS（3.1）はデフォルトでJavaのデータバインディング（graddleにフラグを設定する）をサポートしていますが、 Kotlin、SOで少し検索した後、すべてを修正することができました。
2番目の結論として（元の投稿から）、できればプロジェクトの締め切り/要件/などでデータバインディングを試すことができれば、それは価値があります（本当に愚かなことをしない限り:)））。
Danypataの答えが好きな場合でも、彼のステートメントの一部をAndroid databinding。
1。定型コードの削除-danypatasの回答に書かれているように、いくつかのコードを削除し、レイアウトのように他の場所にコードを追加します。通常、ボイラーコードが削減されるため、ボイラーコードが削減されないという意味ではありません。
たとえば、spinner/recyclerview/listview/..のいくつかのカスタムアレイアダプターを処理するバインディングアダプターを作成することができますが、必要なアダプターは1つだけです。レイアウトでアダプターを使用する場合は、たとえば.
app:myCoolAdaptersData="@{model.mydata}"
これで、たとえば次のように使用する代わりに、汎用アダプターを作成し、すべてのレイアウトでバインディングアダプターを（再）使用できます：
ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);
これは、大規模なプロジェクトで多くのコードを使用する1つの簡単な例です。コードを省くもう1つのサンプルは、モデルをレイアウトにバインドすることです。モデルのフィールド値を更新すると、通常、モデルも更新されます（少なくともBaseObservable/ObservableFieldの場合）。
つまり、すべてのビューを見つけたり、ビューを更新したり、モデルを更新したりする必要はありません...
2.Stronger readability-データバインディングの学習に費やされる余分な時間は本当に重要ではありません。レイアウトはレイアウトタグにラップして名前空間を配置することを除いて実際には違いがないため、「通常の」レイアウトと実際には違いはありません。バインディングアダプターの使用とレイアウト内のモデルへのアクセスには時間がかかる場合がありますが、通常は使いやすくて美しい基本から始めることができます。新しいことを学ぶには常に時間がかかりますが、しばらくしてからデータバインディングを使用すると、時間を簡単にオーバーホールできます。
.Powerful-はい、非常に強力です。既存のコードの再利用、既存のバインディングアダプターの再利用が容易であり、より多くのコードが生成される可能性がありますが、必ずしもそうとは限りません。たとえば、1つのバインディングアダプターを作成するのではなく、複数のクラス内に複数のアダプターを作成できますが、後で「最適化」するのは難しい場合があります。 Bindingadapterを最適化すると、どこでも更新されます。とにかくボイラープレイスが減るので、最適化は「コードの行」を減らすかもしれません。
4.と5.に同意します.
6。デバッグが困難 AS 3.0+は、レイアウト（行番号とファイル）の構文の問題などの有用なヒントを出力するため、データバインディングで生成されたコードをデバッグしやすいです。問題の発見に問題がある場合は、生成されたコードのエラーを確認することもできます。 dagger 2やAndroidアーキテクチャライブラリなどのライブラリは、エラー行が実際の「エラー」と一致しないため混乱する可能性があります。これは、他の注釈プロセッサによって生成されたコードによるものです。プロセッサがデータバインディングのエラー出力で問題を起こす可能性がありますが、簡単に修正できます。
7。単体テスト executePendingBindingsを使用してデータバインディングを使用しない場合のように可能です。
8。可読性データバインディングなしで可読性が向上する場合があります。いくつかのビジネスロジックをレイアウトに入れ、いくつかを実際のコードに入れているため、スパゲッティコードにつながる可能性があります。もう1つの問題は、「layout-designer」がどのパラメーターを使用できるかを知らない場合、レイアウトでラムダを使用すると非常に混乱する可能性があることです。
もう1つの非常に大きな問題は、bindingadapterがどこにでもあるということです。 BindingAdapterアノテーションを使用すると、コードが生成されます。つまり、レイアウトでこれを使用すると、適切なコードを見つけるのに問題が生じる可能性があります。バインディングアダプターを更新する場合は、それを「見つける」必要があります。
何をいつ使用する必要がありますか大規模なプロジェクトでは、mvvmまたはmvpパターンとともにデータバインディングを使用することをお勧めします。これは非常にクリーンなソリューションであり、非常に簡単に拡張できます。小さなシンプルなアプリケーションを作成したいだけなら、データバインディングなしでMVCパターンを使用しても構いません。他のプロジェクトから使用できる既存の汎用バインディングアダプターがある場合は、このコードを簡単に再利用できるため、データバインディングを使用できます。
私は巨大なAndroidプロジェクトに取り組んでおり、チームはデータバインディングライブラリを段階的に廃止することを決定しました。主な理由は、ビルド時間（10ビルドプロセスの多くのクラス。