潜在的な問題
プロジェクトに外部ライブラリを追加しないことを強くお勧めします。ただし、これはライブラリの使用が悪であることを意味するものではなく、Gradleファイルから外部の依存関係を完全に削除する必要があります。新しいライブラリを追加する前に、非常に真剣な分析を行う必要があるという考えを伝えたいと思います。ライブラリを解析する方法を理解するために、プロジェクトに新しいライブラリを追加するときに直面する可能性のある潜在的な問題のいくつかを見てみましょう。
アプリケーションサイズ
ほとんどのライブラリは、アプリケーションのサイズを大幅に増やすことはありません。しかし、そのようなライブラリがあり、追加するとアプリケーションが大幅に増加します！たとえば、レルムライブラリはAPKサイズを4MBから12MBに増やすことができます。平均して、アプリケーションの重量は100MB〜200MBで、余分な8MBは目立たない場合があります。ただし、APKのサイズに悪影響を与えるライブラリはレルムだけではないことに注意してください。この依存関係を使用してAPKのサイズを縮小することは可能ですか？はい、プロセッサアーキテクチャごとにapkを分割できます。しかし、これは次の問題につながります（ポイント2）。
コードの保守性
プロジェクトは成長し、ますます多くのロジックで覆われ、時にはそれらを理解することがより困難になります。数年のプロジェクト開発の後、新しい開発者がプロジェクトに簡単に慣れることができるように、明確なプロジェクトアーキテクチャが必要です。ただし、一部のライブラリはプロジェクトの保守性を無効にする可能性があります。たとえば、EventBusを誤って操作すると、アプリケーションのロジックが大幅に混乱する可能性があります。このライブラリを使用する場所とケースを明確に区別することが重要です。また、誰もこれらのルールから逸脱しないようにするためです。しかし、実際には何が起こりますか？EventBusで始まるほとんどすべての開発者は、どこでもそれを使用しています。その結果、プロジェクトは完全に判読できなくなります。
ライブラリを探索する時間
新しいライブラリを追加するときは、そのライブラリを操作する方法を学ぶ必要があります。将来の開発速度に非常に悪影響を与える可能性のあるライブラリがあります。
たとえば、GoogleのPagingLibraryは、それを操作する方法を理解するために多大な労力を費やしています。このライブラリを理解するには、すべての新規開発者が12〜20時間かかります。あなたはほぼ3日を失っています！この3日間で、ページネーションを書き留めて、サードパーティのソリューションから独立することができます。
ビルド速度
最新のアプリケーションのビルド速度は遅いです。ただし、ビルド時間をさらに長くしたい場合は、Daggerを使用してください。Kotlinの登場後、なぜライブラリがまだ積極的に使用されているのかわかりません。ほとんどの場合、Daggerには上記の4つの問題がすべて含まれています。
バグ、バグ、バグ..。
私の経験では、たった1つのプロジェクトで、バグが存在するために5つのライブラリを見つけました。ほとんどの場合、ライブラリにはバグがあることに注意してください。例えば：
- AndroidPdfViewerはメモリリークを残し、nullを含むいくつかのケースを誤って処理します。これにより、NullPointerExceptionがスローされます。
- Androidナビゲーションコンポーネントが共有エレマントアニメーションで正しく機能しない場合があります
- Ciceroneは、次の理由でアプリケーションをクラッシュさせることがあります
executePendingTransactions()
これは、ライブラリを使用する価値がないことを意味しますか？いいえ、ライブラリは使用でき、使用する必要がありますが、少なくとも、問題リストにプロジェクトの重大なバグがないことを確認することが重要です。
ライブラリの脆弱性
1つのソースコードだけを調べて、一度に複数のアプリケーションをハッキングする最も簡単な方法を知っていますか？多くの開発者が使用している大規模なライブラリでバグを見つける必要があります。そして、このライブラリの脆弱性を介して、アプリケーションのデータにアクセスします。ユーザーの安全性にさらに注意を払う必要のあるアプリケーションを開発していない場合は、この点に目をつぶることができます。そうでない場合は、潜在的な脆弱性に対処する問題を探します。
ライブラリのサポート
ライブラリが1年間更新されていない場合は、使用する価値があるかどうかを質問してください。事実、ライブラリには定期的にバグがあります。これらのバグが修正されていない場合、このライブラリを使用する価値はありますか？近い将来、ライブラリのバグに遭遇し、機能を実装するための代替方法を探す必要がある可能性があります。現在のAndroidAPIの機能に適応する必要があるライブラリがいくつかあります。たとえば、Androidに新しい要素が登場した場合は、そのサポートを追加する必要があります。これらのライブラリには、サポートされなくなったAnkoが含まれています。現在、このライブラリを大規模なプロジェクトで使用することは意味がありません。
ライブラリはプロジェクトのすべてのレイヤーに存在します
RxJavaやPagingLibrary などのライブラリは、開発者にアプリケーションのすべてのレイヤーでAPIを使用するように強制します。ライブラリが常にプロジェクト内にあることが確実な場合は、問題はありません。しかし、何らかの理由でライブラリを切り取らなければならない場合は、莫大な労力を費やすことになります。プロジェクトの半分を書き直す必要があります。
ライブラリの制限
各libは、パブリックメソッドの可用性と内部実装の両方によって制限されるAPIを提供します。ライブラリ機能が十分であることを確認してください。たとえば、人気のあるAndroidナビゲーションコンポーネントライブラリは、開発者の手を非常に緊密に結び付けています。（FragmentTransactionにある）show、hide、addメソッドは提供しません。さらに、タブの履歴を保存する必要がある場合、ライブラリはBottomNavigationViewでの作業を複雑にします。
依存関係のある巨大なGradleファイル
新しいプロジェクトに来たとき、私が最初にすることは、Gradleファイルの依存関係を調べることです。これにより、アプリケーションで何ができるか、特定のタスクがどのように解決されるかが明確になります。しかし、OkHttp、Retrofit、およびVolley（フォーク）の両方がネットワークでの作業に使用されているのを見て驚いた。そして、それは単なるネットワーキングです。Gradleファイル自体は膨大な数のライブラリで構成されており、そのサポートはかなり前に終了しています。開発者が一人の場合、プロジェクト全体を頭に入れておくことができますが、新しい開発者が来ると、そのようなプロジェクトを理解することは非常に困難になります。
ライブラリを実装する前の質問のチェックリスト
- このライブラリにはどのような問題がありますか？それらは私のプロジェクトにとって重要ですか？
- このライブラリ/テクノロジーは、開発者コミュニティによってどのようにテストされていますか？彼女はGitHubにいくつの星を持っていますか？
- 開発者はどのくらいの頻度で問題に対応しますか？
- 開発者はどのくらいの頻度でライブラリを更新しますか？
- 新しい開発者は、使用されているテクノロジーの学習にどのくらいの時間を費やしますか？
- ライブラリはアプリケーションのサイズにどのように影響しますか？
- ライブラリはアプリケーションの速度にどのように影響しますか？
- ライブラリはビルド速度にどのように影響しますか？開発時間を節約するのに役立ちますか？
- ライブラリには脆弱性がありますか？
- ライブラリはプロジェクトのすべてのレイヤーに存在しますか？これはどれほど重要ですか？
- ライブラリが開発者のオプションをどのように制限するか（ほとんどの場合制限されます）。それは良いですか悪いですか？
- 妥当な時間枠内でプロジェクトのために研ぎ澄まされるソリューションを自分で書くことはできますか？
ライブラリを選択するときに他に何を探すことができるかを聞くのは非常に興味深いことです。あなたのコメント、フィードバック、質問を楽しみにしています！