既存AndroidプロジェクトのKotlin化の取り組み

前回のブログで紹介したように、EAP Androidアプリでは半年ほど前から開発言語にKotlinを導入しています。今回は既存プロジェクトのKotlin化について紹介します。

なぜKotlin？

Kotlinには以下のメリットがあります。

Null安全などの安定性を向上する仕組み
簡潔な記述力
Javaとの相互運用性

まず安定性の向上についてですが、Kotlinでは言語自体でnull参照を回避することが考慮されているため、コンパイル時に多くのエラーを防止するようになっています。アプリがクラッシュする原因の多くはnull参照なので、この仕組みは大いに安定性の向上に寄与してくれます。

簡潔な記述力について、Kotlinでは文法が洗練されているので、getter/setterなどの冗長な記述をすることなくアプリを開発できます。
加えてラムダ式やコレクション操作、スコープ関数などの、かゆいところに手が届く仕組みが言語仕様として提供されています。

Javaとの相互運用性が保証されていることも重要な点です。Javaで書かれている既存ライブラリをKotlinから利用できること、逆に新規に開発したライブラリをJavaからも利用できること、さらにJavaとKotlinが混在しても問題ないことがそれぞれ保証されています。これによって、段階的にKotlinへと移行することが可能になります。

以上のような利点から、EAP AndroidアプリにおいてもKotlinの導入に至りました。

デメリットは？

とはいえ、以下のようなデメリットも考えられます。

学習コスト
ビルド時間の増大

学習コストについては、Kotlinの文法がJavaからかけ離れているわけではないので、理解するにはそれほど問題とはなりません。ただし、スコープ関数やコレクション操作によって書き方の自由度が高まったことで書き方の統一性がなくなる場合があります。この場合はプロジェクトに合った一定のルール決めが必要になってくるかもしれません。

型推論などから、Kotlinでは必然的にJavaよりもコンパイラが処理することが多くなるでビルド時間は増大しますが、感覚的にはほどんど気にならない程度でしたので、こちらも大きな問題ではありません。

Kotlin導入の方針

というわけで、Kotlinを導入することになりましたが、導入に際して以下の方針で作業しました。

方針：

新規のコードはKotlinで書く
— 特に問題がない限り、新しいコードはKotlinで書く
既存のコードはKotlinで書き換える
— ただし、JavaからKotlinへの機械的な変換ではなく、kotlin化と同時にリファクタリングを行う

Kotlinを導入する環境は整えられているとはいえ、一気にKotlinに移行するのは大変です。なので、まずは新規のコードはKotlinで書くこととしました。
次に、上記で述べたKotliｎのメリットを享受するため、既存のコードもKotlinへと書き換えることにします。Android Studioの変換機能を利用すればある程度自動的に書き換えることが出来ますが、必ずしも最適な文法に変換してくれないことや、古いコードを見直す良い期間でもあるので一つずつKotlinへと書き換えことにしました。