私たちのプロジェクトはkotlin &&データバインディングプロセスを使用して、あなたはkotlinを使用しているので、なぜkotlinx使用しないで、間違いであってもよいですか？新しいページには、問題の進路kotlinx使用されているが、我々はかなり大きな歴史のコードを持っている、と私たちのユニバーサルアダプタは、実際にパッケージ化するデータバインディングをベースにしています。だから、我々はまだデータバインディングのピットで（スロット）に（つば）を議論する必要があります。実際には、この問題は、私はあまりにも破っバイトにインタビューするように頼まれたとき。
これは非常にオープンな質問ですので、この記事の小さなパートナーは、色付きのメガネで見てみました、次のように著者はできるだけピットが発生した一覧が表示されます、見ることはもちろん、限られた容量は、多くのことがあるかもしれませんデータバインディングは問題ではありません、私たちは一緒に仕事してスクリーニングを補完する必要があります。
以前のGoogleはデータバインディングは、ライブラリに限り、我々はコード頻繁に発生解決する勇気持っているとしてサポートされ打ち上げfindViewById()問題を、その前に、私はほとんどの人がのことを聞いたか、使用していると信じてButterknifeを、今までは、ライブラリに更新されました10.1.0は、と著者はあるJakeWharton偉大な神が、実際には、非常に使いやすいです。
しかし、今日、私たちはあまりにも多くのコメントもButterknife、と私たちの主人公のデータバインディングに転送されません。
データバインディングを使用する場合や物語をここでは紹介しません、私はあなたが直接にすることを示唆している公文書
私はデータバインディングで年以上に強化するものメインピットの一部を共有し、議論するために、ここでは、今日の学習へのアクセスでした。私は確かにこれらのヒントすべてではないと思うし、いくつかの原因個人的に実際に誤動作している、とにかく、私たちはこのデータバインディング本日賞賛、Tucao Tucaoをあきらめます。
非常に困難な位置決め誤差
ああ、これはほとんどの最大のピットデータバインディングを使用して、ほとんどの友人である必要があり、あなたが見ても、タイヤの技術開発と人口の交流の様々なそのジュニアパートナーの一部を嫌っている必要があります。どんなにあなたのコードに問題があるものを、あなたは生成されたクラスは、データバインディングの多くを見つけることができませんされ、エラー・ログを受信しません。
非常に多くの小さなパートナーは、この質問に残ることがあり、これは、ログエラーが最終的にそれを見ることができますビルドでは真実ではないのですか？本当に見ていない、あなたはまた、コンソールを入力することができ./gradlew build --stacktrace、詳細なログを表示します。
しかし、それは本当？何のジュニアパートナーは、あなたが実際のエラーコードを見つけることができないログを表示する方法に関係なくはあり経験されません。
私はそこに持っている必要がありますと思います！我々は、我々は、一般的に「多くの小さな」の原則を維持するためにコミットする必要があるが、これは、我々は常に厳密に遵守しなければならなかったすべてのコミットので、非常に無秩序事業の一環で、私たちはしばしば、コミットしたくないことを保証するものではありませんが私たちは、コンパイルがどの文法的な問題もなく、現在のコードを確認しなければなりません。具体的には、だけでなく、歴史的な理由ではないプロジェクトを徹底的に十分な要素の種々の方法により、コードの膨大な量、については、基本的なコンパイラは、あなたが食事を作ることができます。私たちのプロジェクトがそうである、歴史的な理由の対象に、少なくとも10分をキャッシュヒットせず、これは中にMac Proの16Gでた地元のコンパイルで、その結果、完全に追い越さコンポーネントではありません。そして、ほとんどの人々のコンピュータの構成も低くなる可能性があり、コンパイル時に他の仕事に関係のことを行うことは困難です。
この問題は、コンパイルに対処するために、当社は、業務をコンパイルするためのスクリプトコンパイラを書かなければならなかった、キャッシュヒット状況が存在しない状態でデバッグパッケージをコンパイルし、最適化の一連の操作を行った後、サーバー上で処理またはコースの4.5分を、必要とされています今、我々は他の興味深いもののコンパイルに行うことができます。
前の二つの段落のように無関係な多くのことを言うが、！私は本当にこの時にエラーが発生したことであると言いたい、そして、あなたは、ドキュメントへの変更の数十を持っていることが、非常に苦痛でしょう見つけることができないエラーを記録し、新しいXMLの多くは、彼らはログを見つけることができないので、あなたはラインの構文チェックで整列する必要があります。
この問題についての私の経験は、私は深く、私は歴史問題のコンポーネントので、1時間を覚えて、チェックがより恥ずかしい状況の問題をコンパイルに失敗し、一般的に、このような間違いを見つけるのは容易ではない、話す、時間がかかり、2時間をコード化されていましたコンポーネントのコードが別のコンポーネントに移動しなければならなかった、予期しないエラーがシーンを悲しみ起こります。あなたの場合はstash変更をコンパイルすることができますが、後にpop間違った時に出てきた、あなたは非常に残酷な手段であるか知っているだろう。
OK、現在の状況になる、または問題の95％は、XMLコードであるこのケースをまとめた、あなたはXMLを直接確認することができます。
コードは維持することは非常に困難です
双方向バインディング操作を好きに結合した場合、我々はデータバインディングを使用しています。直接いくつかの簡単なロジックを行うXMLで、この操作は、我々のコードは非常に簡単になることができ、および保存することができfindViewById()、性能の不必要な損失を。しかし、このような操作を、その後の保守機能コードは非常に苦痛になるように。
このようなコードのかなりの部分を持っています私たちのコードは、ページの一部は、製品の詳細ページのような非常に複雑なロジックであり、情報の表示やプロモーションスパイク状態の様々な非常に大きな金額を伴うだろう、ダイナミック効率の多くは、この時間は、あります内部XMLのロジックの多くの後、フォローアップメンテナンスの同僚は確かに心の中で、製品の変更を扱う密かに虐待します。
一般的に言って、私は私達のJavaコードに配置されたこれらの複雑なロジックに慣れています。今のところ、たくさんのコードでこれらの複雑な相互作用ロジックは便利ご覧ください。
{@}の検査を行うことはありません
以前、私は2つの連続した低レベルのエラーを犯しので、この問題に関する思い出。私たちは、内部の類似したXMLサポートを使用、見ることができる@{}ような方法でTextViewコンテンツの設定を表示していますが、もともと傾向があるように、XMLに我々は、メカニズムを検出しなかったNumber値の型が、コンパイラとしてresourceId扱いますエラー。与えられているコードで直接実際には、コンパイラ設定。
それによれば、コード内のコントロールIDを見つけることは困難なこと
在我们项目的早期代码中，XML 里面的命名规范基本是 xxx_xxx_xxx 这样的格式，但在 DataBinding 里面为我们生成的变量却采用的是驼峰命名法，这导致我们根据一个控件 id 去对应 class 里面寻找的时候，还得自己更改为驼峰命名法命名的名字，这一度让我们感到非常不适，所以我们后面的代码 XML 命名规范就跟着变成驼峰命名法了。这可能和命名规范有些许出入，不过我们坚信适合自己的，才是最好的理念。
部分 XML 中的表达式在不同 gradle 版本上表现有所不同
前面说到，我们平时会采用服务器编译，所以此前有出现过 XML 文件里面的某个属性设置在本地编译不过，但在服务器上甚至其他同事的电脑上可以编译的问题。老实说，目前我并没有找到真正的原因，我姑且把这个问题甩锅给了此前做这个的同事。我后续更改了他的实现方式才让这个问题得到妥善处理，但至今没有明白问题出在哪里，因为那样的方式我认为本身代码是没有什么问题的。可惜我现在没有时间去寻找这个代码，大概是设置一个公用的 onClickListener 的问题。
BindingAdapter 不好维护
我们通常会用到 @BindingAdapter 方式来做一些公用逻辑，而不是直接去把逻辑放在页面通过设置属性来使用它，这样就会出现这些公用逻辑比较难维护，当然，这极有可能是我们项目的历史问题，但我觉得这算是一个坑点了。不知道有没有人出现这样的属性在 XML 里面没有提示的情况。就像你自定义 View Styleable 名字不唯一一样。
多模块依赖问题
这个问题我之前还没有发现，因为我们每个模块都用到了 DataBinding，所以认为每个模块的 gradle 都设置上 DataBinding 的配置，并不算什么令人可以吐槽的事，但看起来这个问题挺严重的，所以也在这分享给大家。转自 wanAndroid 上面 xujiafeng 的回答}
DataBinding在多模块开发的时候，有这样一个机制：
如果子模块使用了 DataBinding，那么主模块也必须在 gradle 加上配置，不然就会报错；
如果主模块和子模块都添加上了 DataBinding 的配置，那么在编译时，子模块的 XML 文件产生的 Binding 类除了在自己的 build 里会有一份外，在主模块下也会有一份。
那么，如果主模块与子模块都有一个 layout 根目录的 activity_main.xml，主模块生成的 ActivityMainBinding 会是根据子模块的文件生成的！这种情况我们还可以通过让主模块和子模块使用不同的命名，那么下面这个问题就更要命了：如果子模块的某个 XML 文件使用了一些第三方的控件，那么主模块由于也会生成这个文件的 Binding 类，并且其会有第三方控件的引用，这时候由于主模块没有引入这些控件，就会报错，解决办法是在子模块应用第三方控件的时候，使用 API 的方式应用，这样主模块就坚决引用到了这些第三方控件，这是这样违背了解耦的原则。
哎，个人能力有限，就想到哪儿说到哪儿了。可能有不少其实并不是 databinding 的坑，是个人使用问题，还往明白的人能直接指出。PS：再给我一个机会，我不想在用 Databinding。
希望有其他槽点或者认为上面的东西是有更好的处理方式的小伙伴一定要在下面留言，盼复盼复~