カスペルスキーモバイルトーク＃1。 マルチモジュラリティ

2月下旬、 Kaspersky Mobile Talksの Android開発者向けの会議用の新しい形式を開始しました。 通常の集会との主な違いは、何百人ものリスナーや美しいプレゼンテーションの代わりに、「経験豊富な」開発者がいくつかの異なるトピックに集まって、1つのトピックだけを議論することです：アプリケーションでのマルチモジュールの実装方法、直面する問題、解決方法です。

内容

1. 背景
2. HeadHunterのメディエーター。 アレクサンダー・ブリノフ
3. Tinkoffドメインモジュール ウラジミール・コハノフ、アレクサンダー・ジューコフ
4. Avitoの影響分析。 エフゲニー・クリボボコフ、ミハイル・ユディン
5. Tinkoffと同様に、彼らはPRの組み立て時間を40分から4分に短縮しました。 ウラジミール・コハノフ
6. 便利なリンク

Kaspersky Labオフィスでの会議の内容に移る前に、アプリケーションをモジュールに分割するためのmodがどこから来たのかを思い出してみましょう（以下、モジュールは特に明記しない限り、DaggerではなくGradleモジュールです）。

マルチモジュールのトピックは、長年にわたってAndroidコミュニティの頭の中にありました。 基本的なものの1つは、昨年のサンクトペテルブルク「モビウス」でのデニス・ネクリドフによる報告と考えることができます。 彼は、長い間シンクライアントではなくなっていたモノリシックアプリケーションを、ビルド速度を上げるためにモジュールに分割することを提案しました。

レポートへのリンク： プレゼンテーション 、 ビデオ

次に、Daggerを使用したモジュールのリンクに関するYandex.MapsのVladimir Tagakovによるレポートがありました。 したがって、他の多くのYandexアプリケーションで再利用するために、カードの単一コンポーネントを割り当てる問題を解決します。

レポートへのリンク： プレゼンテーション 、 ビデオ

Kaspersky Labもこの傾向を無視していませんでした：9月、Evgeni MatsyukはDaggerを使用してモジュールを接続し、同時にマルチモジュールアーキテクチャを水平に構築する方法に関する記事を書きました。クリーンアーキテクチャの原則に従うことを忘れませんでした。

記事へのリンク

そして冬のメビウスには、一度に2つの報告がありました。 最初に、Alexander Blinovが、つまようじをDIとして使用するHeadHunterアプリケーションのマルチモジュラー性について話し、その直後にArtem ZinnatulinがLyftの800以上のモジュールの痛みについて話しました。 Sashaは、アセンブリの速度を上げるだけでなく、アプリケーションのアーキテクチャを改善する方法として、マルチモジュラー性について話し始めました。

ブリノフレポート： プレゼンテーション 、 ビデオ

ジンナツリンレポート： ビデオ

なぜ回顧から記事を始めたのですか？ 第一に、マルチモジュール性について初めて読んでいる場合、トピックをよりよく研究するのに役立ちます。 2番目に、私たちの会議での最初のスピーチは、Stream社のAlexey Kalaidaによるミニプレゼンテーションで始まりました。これは、Zhenyaの記事に基づいてアプリケーションをモジュールに分割する方法を示しました。

このアプローチの主な機能は、UIへのバインドでした。各モジュールは個別の画面として接続されます-FragmentManagerを含むメインアプリモジュールから依存関係が転送されるフラグメント。 最初に、同僚はプロキシインジェクターを介してマルチモジュラを実装しようとしました。これはZhenyaが記事で提案したものです。 しかし、このアプローチは圧倒的でした。ある機能が別の機能に依存し、さらに3番目の機能に依存するという問題があったため、各機能モジュールにプロキシインジェクターを記述する必要がありました。 UIコンポーネントに基づくアプローチにより、インジェクターを記述せずに、ターゲットフラグメントの依存関係レベルで依存関係を許可できます。

この実装の主な制限：フィーチャーはフラグメント（または別のビュー）でなければなりません。 ネストされたフラグメントが存在するため、大きな定型文が作成されます。 機能が他の機能を実装する場合、依存マップに追加する必要があります。これは、コンパイル時にDaggerがチェックします。 このような機能が多数ある場合、依存関係グラフをリンクするときに問題が発生します。

アレクセイの報告の後、アレクサンダー・ブリノフが発言しました。 彼の意見では、UIに関連付けられた実装は、FlutterのDIコンテナに適しています。 その後、ディスカッションはHeadHunterのマルチモジュールディスカッションに切り替わりました。 モジュールに分割する目的は、機能をアーキテクチャ的に分離し、アセンブリ速度を上げる可能性でした。

モジュールに分割する前に、準備することが重要です。 まず、依存関係グラフを作成できます-たとえば、このようなツールを使用します 。 これにより、最小数の依存関係を持つコンポーネントを識別し、不要なコンポーネントを削除できます（チョップ）。 その後のみ、最も接続されていないコンポーネントをモジュールに選択できます。

アレクサンダーは、彼がメビウスでもっと詳しく話した主なポイントを思い出した。 アーキテクチャが考慮しなければならない複雑なタスクの1つは、アプリケーション内のさまざまな場所から単一のモジュールを再利用することです。 hhアプリケーションを使用した例では、これは再開モジュールであり、ユーザーがこの欠員のために送信した履歴書にアクセスするときに、空席リストモジュール（VacanciesList）と否定応答モジュール（ネゴシエーション）の両方にアクセスできる必要があります。 明確にするために、サーシャがフリップチャートに描いた絵を描き直しました。

各モジュールには2つの主要なエンティティが含まれています。依存関係-このモジュールに必要な依存関係とAPI-モジュールが他のモジュールに外部から提供するメソッドです。 モジュール間の通信はメディエーターによって実行されます。メディエーターはメインアプリモジュールのフラットな構造です。 各機能には1つのピックがあります。 メディエーター自体は、プロジェクトのappモジュールの特定のMediatorManagerに含まれています。 コードでは、次のようになります。

object MediatorManager { val chatMediator: ChatMediator by lazy { ChatMediator() } val someMediator: ... } class TechSupportMediator { fun provideComponent(): SuppportComponent { val deps = object : SuppportComponentDependencies { override fun getInternalChat{ MediatorManager.rootMediator.api.openInternalChat() } } } } class SuppportComponent(val dependencies) { val api: SupportComponentApi = ... init { SupportDI.keeper.installComponent(this) } } interface SuppportComponentDependencies { fun getSmth() fun close() { scopeHolder.destroyCoordinator < -ref count } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Alexanderは間もなく、Android Studioでモジュールを作成するためのプラグインを公開することを約束しました。これは、会社でのコピーと貼り付けをなくすために使用され、コンソールのマルチモジュールプロジェクトの例です。

hhアプリケーションモジュール分離の現在の結果に関するいくつかの事実：

• 〜83の機能モジュール。
• A / Bテストを実施するには、メディエーターレベルで機能を機能モジュールに完全に置き換えることができます。
• Gradle Scanのグラフは、モジュールを並列にコンパイルした後、アプリケーションのデキシングのかなり長いプロセスが発生することを示しています（この場合、2つ：求職者と雇用者向け）。
  
  

以下は、アレキサンダーから床を取り、ティンコフからウラジミールを取りました。

マルチモジュールアーキテクチャのスキームは次のようになります。

モジュールは、機能モジュールとドメインモジュールの2つのカテゴリに分類されます。

機能モジュールには、ビジネスロジックとUI機能が含まれています。 ドメインモジュールに依存していますが、相互に依存することはできません。

ドメインモジュールには、データソースを操作するためのコード、つまり一部のモデル、DAO（データベースを操作するため）、API（ネットワークを操作するため）、およびリポジトリ（APIとDAOの操作を組み合わせる）が含まれています。 ドメインモジュールは、機能モジュールとは異なり、相互に依存できます。

ドメインと機能モジュール間の接続は完全に機能モジュール内で行われます（つまり、hhの用語では、ドメインモジュールの依存関係とAPI依存関係は、メディエーターなどの追加エンティティを使用せずに、それらを使用する機能モジュールで完全に解決されます）。

これに続いて一連の質問がありましたが、ここではほとんど変更せずに「質問-回答」形式で説明します。

-認証はどのように行われますか？ フィーチャモジュールにどのようにドラッグしますか？

-アプリケーションのほとんどすべてのアクションは許可されたゾーンで行われるため、当社の機能は許可に依存しません。



-未使用のコンポーネントを追跡およびクリーニングする方法

-InjectorRefCount（WeakHashMapを通じて実装）などのエンティティがあり、このコンポーネントを使用して最後のアクティビティ（またはフラグメント）を削除すると、それを削除します。



-「クリーンな」スキャンとビルド時間の測定方法 キャッシュがオンになっている場合、かなりダーティなスキャンが取得されます。

-Gradle Cache（gradle.propertiesのorg.gradle.caching）を無効にできます。



-デバッグモードですべてのモジュールからユニットテストを実行する方法 gradleテストだけを実行すると、すべてのフレーバーとbuildTypeのテストがプルされます。

（この質問は、会議の多くの参加者の議論を引き起こしました。）

-testDebugを実行してみてください。

-デバッグ構成のないモジュールは強化されません。 開始が多すぎるか少なすぎます。

-このようなモジュールのtestDebugをオーバーライドするGradleタスクを作成するか、モジュールbuild.gradleで偽のデバッグ構成を作成できます。

-このアプローチは次のように実装できます。

 withAndroidPlugin(project) { _, applicationExtension -> applicationExtension.testVariants.all { testVariant -> val testVariantSuffix = testVariant.testedVariant.name.capitalize() } } val task = project.tasks.register < SomeTask > ( "doSomeTask", SomeTask::class.java ) { task.dependsOn("${project.path}:taskName$testVariantSuffix") }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の即興のプレゼンテーションは、AvitoのEvgeny KrivobokovとMikhail Yudinによって行われました。

彼らはマインドマップを使用してストーリーを視覚化しました。

現在、同社のプロジェクトには300以上のモジュールがあり、コードベースの97％はKotlinで記述されています。 モジュールへの分類の主な目的は、プロジェクトの組み立てを加速することでした。 モジュールへの分類は徐々に行われ、最も依存度の低いコード部分がモジュールに選択されました。 これを行うために、影響分析のためにグラフ内のソースコードの依存関係をマークするツールが開発されました（ Avitoの影響分析に関するレポート ）。

このツールを使用すると、他のモジュールが機能モジュールに依存できないように、機能モジュールを最終としてマークできます。 このプロパティは、影響分析中にチェックされ、モジュールを担当するチームとの明示的な依存関係および合意の指示を提供します。 構築されたグラフに基づいて、影響を受けるコードの単体テストを実行するために、変更の分布もチェックされます。

同社はモノリポジトリを使用していますが、Androidソースのみに使用しています。 他のプラットフォームのコードは別々に存在します。

Gradleはプロジェクトのビルドに使用されます（同僚はすでに、 BuckやBazelのようなマルチモジュールプロジェクトに適したコレクターについて考えています）。 彼らはすでにKotlin DSLを試し、Gradleとプロジェクトで異なるバージョンのKotlinをサポートするのは不便であるため、GradleスクリプトでGroovyに戻りました。一般的なロジックはプラグインに組み込まれています。

Gradleは、タスク、キャッシュを並列化でき、ABIが変更されていない場合はバイナリ依存関係を再コンパイルしないため、マルチモジュールプロジェクトのアセンブリを高速化できます。 より効率的なキャッシングのために、Mainfraimerおよびいくつかの自己記述型ソリューションが使用されます。

• ブランチからブランチに切り替えると、Gitはキャッシュを壊す空のフォルダーを残す場合があります（ Gradle issue＃2463 ）。 したがって、Gitフックを使用して手動で削除されます。
• 開発者のマシンの環境を制御しない場合、異なるバージョンのAndroid SDKおよびその他のパラメーターによりキャッシュが低下する可能性があります。 プロジェクトのビルド中に、スクリプトは環境パラメーターを予想されるものと比較します。間違ったバージョンまたはパラメーターがインストールされている場合、ビルドはドロップされます。
• 分析は、オン/オフパラメータと環境で行われます。 これは、開発者を監視および支援するためのものです。
• ビルドエラーも分析に送信されます。 既知の一般的な問題は、ソリューションのある特別なページに入力されます。

これらすべてにより、CIで15％、ローカルで60-80％のキャッシュミスを達成できます。

次のGradleのヒントは、プロジェクトに多数のモジュールが表示される場合にも役立ちます。

• IDEフラグを介してモジュールを無効にするのは不便です;これらのフラグはリセットできます。 したがって、モジュールはsettings.gradleによって無効になります。
• スタジオ3.3.1には、「プロジェクトに複数のモジュールがある場合、Gradle同期でソース生成をスキップする」チェックボックスがあります。 デフォルトではオフになっていますが、オンにすることをお勧めします。
• 依存関係はbuildSrcに書き込まれ、すべてのモジュールで再利用されます。 別のオプションはPlugins DSLですが、プラグインのアプリケーションを別のファイルに入れることはできません。

私たちの会議は、レポートのクリックベイトタイトル「PRのアセンブリを40分から4に減らす方法」でTinkoffのVladimirで終わりました。 実際、私たちはgradleプラグの開始の配布について話していました：apkビルド、テスト、および静的アナライザー。

最初は、各プルリクエストの担当者が静的解析を実行し、アセンブリとテストを直接実行しました。 このプロセスには40分かかりましたが、そのうちリントとSonarQubeだけが25分かかり、打ち上げの7％しか落ちませんでした。

したがって、2時間ごとにスケジュールで実行され、エラーが発生した場合にSlackにメッセージを送信する別のジョブに起動を配置することが決定されました。

反対の状況はDetectです。 ほぼ絶え間なくクラッシュしたため、事前の事前プッシュチェックが行われました。

したがって、プルリクエストの検証では、apkアセンブリと単体テストのみが残りました。 テストは実行前にソースをコンパイルしますが、リソースを収集しません。 リソースのマージはほぼ常に成功したため、apkアセンブリ自体も破棄されました。

その結果、プルリクエストには単体テストの起動のみが残り、指定された4分を達成することができました。 ビルドapkは、devのマージプルリクエストで実行されます。

会議はほぼ4時間続いたという事実にもかかわらず、マルチモジュールプロジェクトでナビゲーションを整理するという難題を議論することができませんでした。 おそらくこれは、次のカスペルスキーモバイルトークのトピックです。 さらに、参加者はこの形式を本当に気に入っていました。 アンケートまたはコメントで話したいことを教えてください。

そして最後に、同じチャットからの便利なリンク：

• モノリシック接続グラフの定義
• hhでコードを記述するためのルールとそれらをサポートするユーティリティ
• Mirakle-ビルドをメインフレームに転送するためのプラグイン
• Androidアプリケーションのモジュール化調査結果