【Android】サードパーティ製ライブラリで炎上した話 〜便利さの代償はデバッグ不能な泥沼だった〜

「公式よりも簡単！」「1行でできる！」
甘い言葉に誘われて使い始めたサードパーティ製ライブラリ。
しかし、ある日突然クラッシュの嵐、止まらぬANR、そして“誰もソースを読めない”という沼へ…。
本記事では、そんな ライブラリ依存の失敗と脱却までの道のり を語ります。

便利すぎるライブラリとの出会い

Android開発を始めて数年。ネットで情報も少なかった頃、ライブラリの存在はまさに救いだった。
特に「公式のやり方は面倒だけど、○○っていうライブラリなら1行でできる！」という記事に目を輝かせていた。

当時私がよく使っていたのは以下のようなライブラリ：

• 画像読み込み：Universal Image Loader
• JSONパース：Gson
• Viewバインディング：Butter Knife
• HTTP通信：AsyncHttpClient
• ログ出力：Timber

最初は本当に助かった。公式ドキュメントに頼らず、コードも短く、美しく見えた。

地雷その1：アップデートと互換性の地獄

ある日、サポートライブラリのアップデートを行ったあと、突然ビルドが通らなくなった。

java.lang.NoClassDefFoundError: android.support.v4.app.FragmentActivity

調べてみると、使っていたライブラリの1つが古い support-v4 に依存しており、新しいAndroidXに未対応だった。

GitHubを見ると「3年前からメンテナンスされていません」の文字。

他にも：

• 最新のtargetSdkVersionに非対応
• プロガードでクラッシュ
• マニフェストに勝手に権限を追加

便利だったはずのライブラリが、足枷と化した瞬間だった。

地雷その2：ブラックボックスで原因がわからない

あるアプリで、ユーザーから「特定の画面で落ちる」という報告が続いた。

クラッシュログを見ると、なんと外部ライブラリ内のNullPointerException。

at com.external.lib.ui.ImageSlider.load (ImageSlider.java:127)

このライブラリは、画像スライダーを作れる便利なUIコンポーネントで、アニメーションやタッチ対応などすべてお任せだった。

でも肝心のことがわからない：

• なぜクラッシュしたのか？
• どんな条件で起きるのか？
• 回避方法はあるのか？

ソースコードは難読化されていて読めず、Issueにも似た報告はあるが放置されていた。

結局、該当機能を自作に切り替えて置き換えることでなんとか収束したが、「依存しすぎる怖さ」を痛感した。

地雷その3：アプリサイズ肥大 & スタートアップ遅延

ライブラリを使うたびに、dependenciesに1行追加するだけ。

それが増えすぎて、アプリのAPKサイズはどんどん膨らんだ。

implementation 'com.squareup.picasso:picasso:2.71828'
implementation 'com.github.bumptech.glide:glide:4.8.0'
implementation 'com.squareup.okhttp3:okhttp:3.12.0'
implementation 'com.loopj.android:android-async-http:1.4.9'

気づけば、同じ目的のライブラリが複数共存し、競合も発生。

App Startup時間は5秒以上、Cold Startでユーザー離脱が増加していた。

しかも、ライブラリの初期化がApplicationで自動的に行われているため、起動時のログを見ても「何が遅いのか」が追えない。

なぜライブラリを多用してしまったのか？

• 自作よりも早く機能を実装できる
• 短期納期に間に合わせたい
• 「公式が面倒」という感情的理由
• 当時の書籍やQiita記事が推奨していた

そして最大の理由は、「使わないと損」だと思っていたから。

脱・ライブラリ依存のためにやったこと

✅ ソースコードが読めるライブラリしか使わない

→ GitHubで実装を読んで、必要な最小限の機能だけを取り入れる。
ImageSliderのようなUI系は、ViewPager2 + RecyclerViewで代用。

✅ 必要以上に機能を詰め込まない

→ PicassoかGlide、どちらかに絞る（しかも、最近はCoilを選ぶことも多い）

✅ 公式APIにできるだけ寄せる

→ Retrofitを使う場合でも、ConverterやCallAdapterを追加しすぎない。

✅ 「使わない勇気」を持つ

→ 便利そうでも「この機能、そもそも本当に必要か？」と立ち止まる。

現在の開発方針

今はKotlin中心、Jetpackライブラリ（Room, WorkManager, Navigationなど）を軸に構築している。

ライブラリ導入前には以下のチェックをしている：

• 最終更新日はいつか（1年以上放置されていないか）
• ソースコードは公開されているか
• Issueが解決されているか
• targetSdkVersionへの追従はあるか
• 同じ機能を公式で実現できないか

おわりに

サードパーティ製ライブラリは強力な武器になる。

しかし、「使ったことで将来のメンテが地獄になる」ことは珍しくない。

過去の私に言いたい。

今だからこそ言える。

あのときの地獄が、判断力というスキルを育ててくれたのだと。