問題タブ [incremental-compiler]

この質問で説明されているように、ビルド システムを改善し、インクリメンタル ビルドとコンパイルを有効にしました。残念なことに、 Gradles ブログ投稿を読んで期待したほど、インクリメンタル コンパイルはビルド時間を改善しませんでした。

調査の結果、アプリの奥深くにある小さなクラスにコメントを追加しただけなのに、コードベースのほぼ全体が再構築されていることが問題であることがわかりました。実際、どのクラスに触れるかは問題ではありません。Gradles の--debug出力を見ると、基本的に常に 476 個のクラスが再コンパイルされることがわかります。

12.51 秒で完了した 476 クラスのインクリメンタル コンパイル。

変更されたファイルの定数が完全な再コンパイルをトリガーすることは理解していpublic staticますが (これはわずかに遅いだけです)、インクリメンタル コンパイルが実際に機能するようにクラスの依存関係を適切に分割する方法がわかりません。インクリメンタル コンパイルに影響を与えるクラスの依存関係を決定するための正確な規則は何ですか? ここでいくつかの例を読むことができましたが、(かなり標準的な) プロジェクトにはまったく当てはまらないようです。

私自身のテストのいくつかは、次の結果をもたらしました。

実装の詳細が変更されたときに A の再コンパイルが必要なのはなぜですか? B のインターフェイスは変更されていません。

また、インターフェース C の背後に B を「隠す」ことも試みました。これが、依存関係を分割する適切な方法であると考えました (多くの場合非常に面倒ですが)。しかし、それはまったく役に立たなかったことがわかりました。

私には、この大きな依存関係の塊があるように見えます。合理的に設計されたコードベースがあると主張しても、これが合理的に変更される可能性があるかどうかはわかりません。インクリメンタル コンパイルを効果的に改善する、Android 開発者の間で一般的なベスト プラクティス、ガイドライン、またはデザイン パターンはありますか?

他の人が私たちと同じ問題を抱えているかどうか疑問に思います。そうでない場合、あなたは何をしましたか?

インクリメンタル コンパイルとは何かを理解しています。コンパイラは、編集したコードのすべてではなく、そのコードのみをコンパイルします。しかし、コードを .h ファイルと .c/.cc ファイル、および C++ の makefile に分割すると、インクリメンタル コンパイルにどのように役立つのでしょうか?

大規模な Typescript プロジェクトがあり、開発時間を支配することがある増分コンパイル時間を改善しようとしています。多くのファイルでは、すべてのimportステートメントに従うと、プロジェクトのほとんどのファイルに到達するため、インクリメンタル コンパイルは非常に遅くなる可能性があります。このグラフの接続を減らす作業を行っていますが、Typescript ファイルに加えたいくつかの変更について、インポートファイルが --incremental または watch モードで再コンパイルされないことにも気付きました。

たとえば、クラスのメソッド本体 (シグネチャは変更しない) を変更しても、そのクラスをインポートするファイルの再コンパイルは発生しません。さらに、(ソフトおよびハード)プライベートフィールドをクラスまたはファイル ローカル宣言に追加しても、インポーターの再コンパイルは発生しないようです。

ただし、mixin パターン ( https://www.typescriptlang.org/docs/handbook/mixins.html ) を使用する場合、mixin クラスを変更すると、ハード プライベート フィールドが追加されても、すべてのインポーターが再コンパイルされることに気付きました。インポート/エクスポート タイプを使用しても、依存関係に関して何の違いもないように思われますが、関連するドキュメントは見つかりませんでした。

インクリメンタル コンパイルの目的で依存関係を構成するものの正式なドキュメントはありますか? この依存関係グラフはコンパイラ (またはインクリメンタル コンパイルの出力) から取得できますか? より実際には、プライベート フィールドとメソッドの実装にコンパイルの依存関係を作成せずにミックスインを使用する方法はありますか? 関連するすべてのクラスにインターフェースを導入することによってのみこれを解決できましたが、これは非常に面倒であり、独自の問題を引き起こします。プロジェクトをサブプロジェクトに分割してプロジェクト参照を使用することはできないようです。そのような分割では循環依存関係が発生するためです。

strictNull チェックの目的で、推奨されるようにそれらをコードに徐々に導入しようとしていますが、チェックされたファイルのリストに 1 つのファイルを追加すると、推移的にインポートするすべてのファイルも追加されます (またはそう思われます)。ここで使用されている依存関係の正式なドキュメントはありますか? インクリメンタルコンパイル用のものと同じですか？