【ITニュース解説】React Native Isn't Slow. Careless Builds Are.

React Nativeはモバイルアプリ開発で非常に人気のある技術だが、「動作が遅い」という評判を聞くことがある。しかし、この記事の筆者は、React Native自体が遅いわけではなく、開発者が注意を払わずにアプリを構築（ビルド）してしまうことが、動作の遅さの原因だと主張している。これは、特定のOS向けに直接開発するネイティブアプリでも、不注意なビルドをすれば遅くなるのと本質的には同じだという。重要なのは、どの技術を使うかだけでなく、いかに適切に開発し、最適化を行うかである。

筆者たちは実際に、あるアパレルブランドのD2C（Direct to Consumer、メーカーが消費者に直接販売する）アプリをReact Nativeで開発し、高いパフォーマンスを実現した。このアプリは、AndroidとiOSの両方のプラットフォームで同じ一つのコードベースから作られており、アプリがすでにスマートフォンのメモリ上にある状態での起動（ホットランチ）は120ミリ秒、完全に閉じている状態からの起動（コールドランチ）は900ミリ秒という高速な起動時間を達成した。この成功例は、React Nativeでも十分に高速なアプリが開発できることを示している。このアプリの技術スタックは、フロントエンドにReact Native、バックエンドにFastAPIとPostgreSQL、データのキャッシュにRedis、決済にRazorpayを利用し、管理画面も独自に開発したものだった。アプリはあえてシンプルな設計が採用されており、この高速性は、一つの画期的な技術によるものではなく、多くの小さな開発判断と最適化の積み重ねの結果であると筆者は説明している。

アプリの起動時間には「コールドランチ」と「ホットランチ」の二種類がある。コールドランチは、アプリがスマートフォンのメモリ上に全く存在しない状態から起動することで、ユーザーが初めてアプリを開く際や、長時間使わずにOSによってアプリが終了された後に開く際の体験に直結する。ホットランチは、アプリがまだメモリ上に残っている状態からの起動であり、通常はコールドランチよりも早く画面が表示される。この記事では、コールドランチの時間が最も重要だと強調されている。特に安価なスマートフォンでは、バックグラウンドで動くアプリが頻繁にOSによって終了させられるため、ユーザーはコールドランチを経験する機会が多いからだ。アプリの起動時間を評価する際には、コールドランチかホットランチか、どのデバイスで計測したか、そして最初の画面が表示されるまでか、操作可能になるまでか、といった詳細な条件を確認することが大切である。

アプリが遅いと感じる際に、筆者がまずチェックするポイントがいくつか紹介されている。第一に、アプリの最初の画面が表示される際に、ネットワークからのデータ取得を待っていないか確認することだ。もし、API（アプリケーション・プログラミング・インターフェース）からの応答を待ってから画面を表示する設計になっていると、モバイル通信環境が不安定な場合、アプリの起動時間はAPIの応答速度に直接左右されてしまう。これを避けるためには、まずスマートフォンに保存されているデータなどを使って有用な情報を素早く表示し、その後で新しいデータを静かに更新するような工夫が有効である。

次に、APIが必要以上に多くの処理をしていないかを確認する。例えば、商品のカタログデータは閲覧される頻度が高いが、更新される頻度は低い傾向にある。このようなデータの場合、毎回データベースに問い合わせるのではなく、Redisのような高速なキャッシュシステムを利用して、頻繁に読み込まれるデータを一時的に保存することで、APIの応答速度を大幅に改善できる。ただし、キャッシュされたデータが古くならないように、管理画面からの更新がどのようにキャッシュに反映されるかを事前に計画しておくことが重要だ。

三つ目のチェックポイントは、リスト表示や画像がパフォーマンスの問題を引き起こしていないかである。React Nativeでは、特に商品のグリッド表示などでこの問題が指摘されやすい。主な原因としては、リストの各要素（コンポーネント）が不必要に頻繁に再描画されたり、表示される画像のファイルサイズが、実際に画面に表示されるカードのサイズに対して不必要に大きすぎたりすることが挙げられる。これらを適切に最適化することで、スクロールが滑らかになったり、画面の描画速度が向上したりする。

四つ目は、最初の画面が描画される前に、あまりにも多くの処理が実行されていないかである。アプリ起動時の初期状態のデータが大量であったり、広告表示などのSDK（ソフトウェア開発キット）が起動時にまとめて初期化されたり、ユーザーがまだ必要としていない画面のデータを先読みしたりするような処理は、すべて起動時間の増加に繋がる可能性がある。本当に必要な処理だけを、必要なタイミングで実行するように見直すことが、パフォーマンス改善には不可欠だ。

最後に、アプリのパフォーマンスを測定する際には、デバッグビルド（開発中に使うテスト用のビルド）ではなく、リリースビルド（最終的にユーザーに配布する本番用のビルド）で測定しているかを確認する。デバッグビルドは多くの開発者向けの機能が含まれているため、一般的に動作が遅く、正確なパフォーマンスを測るのには適していないからである。

さらに重要な点として、アプリのテストは、実際に顧客が使用するであろうスマートフォンで行うべきだと述べられている。最新の高性能なスマートフォンだけでテストするだけでは、多くのパフォーマンス上の問題が見過ごされてしまう可能性がある。特に安価なAndroidスマートフォンなど、メモリやCPUの性能が低いデバイスでテストすることで、多くのユーザーが実際に経験するであろうパフォーマンスの問題を発見し、修正することができる。例えば、配送アプリや現場作業アプリの開発では、実際にドライバーが使用するような3GB RAM程度のAndroid端末を想定して開発・テストを行うことが推奨されている。

モバイルアプリ開発のフレームワーク選択についても言及されている。React Nativeは、既にReactベースのウェブサイトを運営しており、そのロジックや開発者をモバイルアプリと共有したい場合に非常に適している。今回のアパレルアプリのケースもこれに該当した。ただし、前述の通り、パフォーマンスを確保するには開発規律が求められる。一方、Flutterは、全デバイスで完全に同じデザインを実現したい場合や、既存のウェブコードベースを共有する必要がない場合に良い選択肢となる。しかし、Flutterで開発されたアプリは、ファイルサイズが大きくなる傾向があり、一部のネイティブSDKとの連携には手書きのブリッジコードが必要になる場合がある。ネイティブ開発（KotlinやSwiftといった言語を使い、それぞれのOS向けに直接開発する手法）は、Bluetoothプリンターやバーコードスキャナーとの連携、バックグラウンドでの位置情報追跡など、特定のハードウェアやOSの深い機能との連携が必須となる場合に最適である。ただし、この方法ではiOSとAndroidでそれぞれ異なる二つのコードベースを管理し、すべての機能を二度開発する必要があるというデメリットがある。どのフレームワークを選択するかは、プロジェクトの要件によって慎重に判断すべきであり、どんなプロジェクトにも同じフレームワークを勧める開発会社は、その会社の得意分野を優先しているだけで、必ずしもアプリのニーズに合致しているとは限らない。

この記事から得られる重要な教訓はいくつかある。第一に、アプリの最初の画面表示をネットワーク通信でブロックしないこと。ユーザー体験を損なわないために、キャッシュデータなどを活用して素早く画面を表示する工夫が必要である。第二に、頻繁に読み込まれるデータはキャッシュを使い、そのキャッシュが最新の状態に保たれるような仕組みを計画すること。第三に、リスト表示と画像処理は、アプリのパフォーマンスに最も影響を与えやすい部分として特に注意を払い、最適化を行うこと。第四に、アプリの起動時間は、リリースビルドの状態で、実際にユーザーが使うような安価なAndroidスマートフォンでコールドランチの時間を測定することが重要である。そして最後に、アプリ開発のフレームワークは、プロジェクトの具体的な要件に合わせて慎重に選択すべきだということだ。これらの点を意識することで、React Nativeだけでなく、どんな技術を使っても高性能で使いやすいアプリを開発できるようになるだろう。