React Nativeの新アーキテクチャが導入したTurboModuleは、JavaScriptからネイティブ機能を呼び出す際のオーバーヘッドを削減する仕組みです。しかし「同期API＝高速」という誤解が、本番環境で静かにパフォーマンスを蝕む罠になります。
TurboModuleの同期呼び出しとは何かを、まず整理します。従来のReact Nativeは「ブリッジ」と呼ばれる非同期通信レイヤーを介してJavaScriptとネイティブコードをつないでいました。この方式はシリアライズ（データ変換）コストが高く、遅延も生じやすいものでした。新アーキテクチャではJSIというC++ベースのインターフェースを使い、JavaScriptからネイティブ関数を直接呼び出せます。この仕組みにより、同期的な値の取得が技術的に可能になりました。
問題は、「通信コストが下がった」ことと「ネイティブ処理が速い」ことを混同しやすい点です。たとえば次のような呼び出しを見てみます。
const token = SecureStorage.getAccessToken();
renderScreen(token);このコードはawaitもコールバックも不要で、一見シンプルです。しかし裏では、AndroidのKeystoreやiOSのKeychainへのアクセス、復号処理、ディスク読み込み、JSONパースといった複数の重い処理が走っています。JavaScriptスレッドはこれらが全て完了するまで次の処理に進めません。
なぜJavaScriptスレッドのブロッキングが深刻なのか
React Nativeアプリでは、JavaScriptスレッドが担う責務は非常に多岐にわたります。状態更新の処理、ユーザー操作のハンドリング、Reactのレンダリング計算、ナビゲーション制御、アニメーション連携など、UIの滑らかさに直結する処理が集中しています。
このスレッドが同期的なネイティブ呼び出しによってブロックされると、他のすべての処理は待機状態になります。1回の呼び出しならほぼ気づかないかもしれません。しかしコンポーネントのレンダリング中に毎回呼び出されていたらどうでしょうか。ナビゲーション遷移や状態更新のたびにレンダリングが走れば、同期呼び出しも同じ回数繰り返されます。結果として画面遷移の遅延、ボタン操作への応答性の低下、アニメーションのコマ落ち（フレームドロップ）といった問題が表面化します。特にローエンドデバイスでは顕著です。
SRE・インフラ観点で言えば、この種の問題は「レイテンシの可変性」として捉えられます。ネイティブ処理の実行時間は一定ではなく、データがキャッシュされていれば1ミリ秒以下、暗号化処理が絡めば数十ミリ秒に跳ね上がる可能性があります。この不確かさがP99レイテンシ（99パーセンタイルの応答時間）を悪化させ、SLO（サービスレベル目標）の「応答性」や「快適性」に関わる指標を静かに侵食します。
TurboModuleが削減するものとしないもの
TurboModuleの恩恵は「通信レイヤーのオーバーヘッド削減」にあります。旧来のブリッジでは、JavaScriptとネイティブ間のデータのシリアライズ・デシリアライズに固定コストがかかっていました。TurboModuleはこの経路を効率化します。
ただし、ネイティブ側で実行される処理そのものは何も変わりません。以下の3工程はTurboModuleを使っても省略されません。
- ストレージへのアクセス（ディスクI/O）
- 暗号処理（Keystore/Keychainの復号）
- JavaScriptオブジェクトへの変換（アロケーションコスト）
「扉が速くなっても、部屋の中の作業量は変わらない」というのが本質です。TurboModuleによる最適化は、扉をより高速に開ける改善です。部屋の中（ネイティブ処理）を速くするには別のアプローチが必要です。
オブザーバビリティの観点では、この種の問題はFlipperやPerfettoを用いたJSスレッドのトレースや、Reactの<Profiler>コンポーネントで計測できます。「レンダリングが遅い」と気づいたとき、原因がReactの再レンダリングそのものではなく、レンダリング中に呼ばれる同期ネイティブ処理である可能性を念頭に置く必要があります。
同期呼び出しが許容できるのは、処理がメモリ上で完結していて実行時間が予測可能な場合に限られます。たとえばデバイスの機能フラグをキャッシュから返すだけの処理（DeviceCapabilities.supportsBiometrics()のようなもの）は同期でも問題になりにくいです。一方、I/O・暗号・外部サービス通信を伴う処理は、たとえ呼び出しのAPIが同期であっても非同期化（Promise／async-await）を検討すべきです。
通信経路の最適化と処理コストの削減は、独立した問題として切り分けて評価する姿勢がパフォーマンス設計の土台になります。