Vue.jsで作る空間解析アプリとCapacitorプラグインのData Bridge

Vu e Fe s Ja p a n 2 0
2 6 Vu e . j s で作る空間解析アプリと C a p a c i to r プラグインの D a ta B r i d g e Hal

本日のスライド

Hal ソフトウェアエンジニア Vue.js / Nuxt / Hono / Photo /
Cinema / Tacos どこにでもいる人になりつつある

今日伝えたいこと Vue.js でも AR のような超ネイティブな振る舞いを持つアプリが作れる AR などの重いデータを
Web 層とやり取りするときの効率化のポイント

なぜ We b フロントエン
ドでネイティブアプリを作るのか

なぜ Web FW でネイティブアプリ？ネイティブな体験を提供したい
今のスキル範囲から小さく始めたいデバイスのポテンシャルを引き出し、より立体的な体験を提供したい e.g. NFC ・ ARKit ・ Live Activity Web から呼べる API も増えてきたが、 iOS では使えないものもある（ e.g. Web NFC ）出典 : MDN 「 Web NFC API 」

どのフレームワークを選ぶ？ React Native JS エンジン JS ⇔ Native
Vue で書ける？ Web としても出せる？ネイティブ層（ Hermes ） JSI ・ TurboModules NativeScript Lynx Capacitor ネイティブ層（ V8 ） PrimJS ・ JSC (Dual Thread) WebView （ JSC ・ V8 ） NativeModules JSON Bridge ◯ ◯（ PWA も）ランタイムが直接呼び出し（メタデータ） ✕ （ React のみ） nativescript-vue vue-lynx ( コミュニティ OSS) react-native-web 自前で工夫が必要 Lynx for Web

どのフレームワークを選ぶ？ React Native JS エンジン JS ⇔ Native
Vue で書ける？ Web としても出せる？ネイティブ層（ Hermes ） JSI ・ TurboModules NativeScript Lynx Capacitor ネイティブ層（ V8 ） PrimJS ・ JSC (Dual Thread) WebView （ JSC ・ V8 ）ランタイムが直接呼び出今回は Capacitor を採用し（メタデータ） NativeModules JSON Bridge ◯ ◯（ PWA も） ✕ （ React のみ） nativescript-vue vue-lynx ( コミュニティ OSS) react-native-web 自前で工夫が必要 Lynx for Web

Capacitor とは WebView ベースのフレームワーク（ Cordova の精神的後継） JS エンジンは WebView のもの（
JavaScriptCore ・ V8 ） Vue.js ・ React ・ Svelte ・ Angular ・ Qwik などと組み合わせて使える Native ⇔ JS のデータ転送は JSON Bridge ← ここがポイント

Capacitor を採用した理由 Vue.js でネイティブアプリを書きたかった Swift ・ Kotlin
に意識を向ける時間を減らしたかったプラグイン設計や接続部を作るときだけ集中する iOS ・ Android ・ Web でのアプリ配信が必要でも小さく始めやすい

空間解析アプリについて

空間解析アプリで取り組んでいること収集 3D
出力図面出力 AR で空間情報を集める高品質な 3D （ 3DGS ）空間情報から図面へ（奥行・幅・高さ・カテゴライズ）

空間解析アプリで取り組んでいること収集 AR
で空間情報を集める（奥行・幅・高さ・カテゴライズ）

品質を上げるためにやっていること 1 AR 計測の補正モジュール 2 3D 出力の品質・速度向上
3 ・今日はここを中心に計測時のデータ転送効率改善

そもそも LiDAR とは光を当てて、返ってくるまでの時間で距離を測る iPhone Pro は dToF （
Direct Time-ofFlight ）苦手：強い光・反射面・細かいエッジ暗い場所も苦手（ LiDAR は測れるが、 ARKit のトラッキングが落ちる）取れるもの：深度マップ信頼度マップ RGB （カメラ映像として）点群（深度の加工結果） iPhone 13 Pro の LiDAR 深度から作った点群

深度データの中身 depthMap （ Float32 ）：端末からその場所までの推定距離（ m ）行列
[ // 192 × 256 … [0.992, 0.995, 0.998, 1.000, 1.004, 1.008, 1.012, 1.016, …], [0.990, 0.994, 0.996, 0.999, 1.002, 1.006, 1.009, 1.013, …], [0.995, 0.998, 0.999, 1.002, 1.004, 1.011, 1.020, 1.021, …], [0.991, 0.992, 0.994, 0.997, 1.004, 1.007, 1.013, 1.021, …], [0.995, 1.000, 0.999, 1.004, 1.008, 1.009, 1.092, 1.057, …], [1.946, 2.695, 2.836, 2.922, 2.951, 2.885, 2.920, 2.967, …], … ] confidenceMap （ UInt8 ）：その距離の確からしさ拡大図の 6 × 8 マスが、右の配列に対応する。上 5 行はドアの面（約 1m ）、最後の行はスリットの奥（約 2.9m ）で、境目に近づくほど信頼度が下がる。画像も深度も、センサーの向き（横向き）のままデータ : iPhone 13 Pro で撮影行列。 [ // 192 × 256 0=low 1=medium 2=high … [2, 2, 2, 2, 2, 2, 2, 2, …], [2, 2, 2, 2, 2, 2, 2, 2, …], [2, 2, 2, 2, 2, 2, 2, 2, …], [1, 1, 1, 1, 1, 1, 1, 1, …], [1, 1, 1, 1, 1, 1, 1, 1, …], [0, 0, 0, 0, 0, 0, 0, 0, …], … ]

Capacitor × ARKit の壁

Capacitor で ARKit を扱う際の問題
点公式のプラグインが存在しない Capacitor 公式の 38 プラグインに、 ARKit や LiDAR を扱うものはない自作には Swift などネイティブ言語の知識が必要カメラ映像を含む計測データが特大 JS 層での処理が現実的ではない生データは 1 秒あたり約 260MB 。 Bridge は 100MiB を渡すだけで約 0.6 秒かかる映像まで含めると、 Bridge では毎秒の量を送り切れない出典 : Capacitor 「 Official Plugins 」・「 Custom Native iOS Code 」

どれくらい重い？ iPhone 13 Pro （ LiDAR ）でドアを 1 枚スキャン
70 秒 → 約 420MB 動画 295MB （ HEVC ）＋深度 125MB （ DEFLATE ）＋メタデータ 2MB ARKit の深度データは 60fps （毎フレーム取得）データ 1 フレームあたり深度マップ sceneDepth.depthMap 256×192×4B ≒ 約 197KB 信頼度マップ sceneDepth.confidenceMap 256×192×1B ≒ 約 49KB RGB 映像 capturedImage 1920×1440 ・ YUV420 ≒ 約 4.1MB

他のフレームワークは大きいデータをどう運んでいる？

React Native ： JSI で直接つなぐ旧アーキテクチャは非同期ブリッジで呼び出
しをシリアライズ → 大きいオブジェクトでボトルネックに New Architecture では JSI で JS が C++ オブジェクトの参照を持ち、シリアライズなしで直接呼び出す e.g. VisionCamera は約 30MB のフレーム（約 2GB/s ）を JSI で処理図 : https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here 解説 : https://reactnative.dev/architecture/landing-page （ CC BY 4.0 ）

Flutter ： Platform Channel と FFI Platform Channel ：メッセージを StandardMessageCodec
でバイナリにシリアライズ（ Uint8List ⇔ Swift の FlutterStandardTypedData ） FFI （ dart:ffi ）： C の API を直接呼ぶ。データの受け渡しにシリアライズが不要で、 Platform Channel よりかなり速くなりうる図 : https://docs.flutter.dev/resources/architectural-overview 解説 : https://docs.flutter.dev/platform-integration/platform-channels （ CC BY 4.0 ）

NativeScript ： JS からネイティブ API を
直接呼ぶ JavaScript Application Code Plugins NPM Packages NativeScript Runtime Webpack Chrome DevTools Module Loader iOS ・ Android の API をそのまま呼べる JS Debugger V8 VM JS Workers LiveSync ビルド時に生成するメタデータで、 JS （ V8 ）から NativeScript CLI 型の変換（マーシャリング）はランタイムが暗黙的に行う大きいデータは interop.bufferFromData() で Metadata / Type Marshaller @nativescript/ios FFI NSData を ArrayBuffer にラップして扱える Native iOS System Frameworks Obj-C runtime Native Deps 図 : https://docs.nativescript.org/dev-reference 解説 : NativeScript 「 Metadata 」「 Marshalling 」「 iOS Runtime Types 」

Lynx ：デュアルスレッドと NativeModules JS はメインスレッド（ PrimJS ）とバックグラウンドスレッド（ iOS
は JavaScriptCore ）の 2 つで動く NativeModules は ArrayBuffer ⇔ NSData （ iOS ）・ byte[] （ Android ）の型変換に対応図 : https://lynxjs.org/react/main-thread-script.html 解説 : https://lynxjs.org/guide/scripting-runtime/index.html ・ https://lynxjs.org/guide/use-native-modules.html （ CC BY 4.0 ）

Capacitor ： WebView と Native Bridge Web アプリは WebView 内で動き、
Native Bridge がプラグイン呼び出しをメッセージとして Native Runtime に渡す（呼び出しはすべて非同期） Web ⇔ Native のデータは JSON で表せる型にシリアライズ・デシリアライズされる → 大量のデータをやり取りするとシリアライズのオーバーヘッドが出る（ Ionic 公式も言及）図 : https://ionic.io/blog/how-capacitor-works-2 解説 : https://capacitorjs.com/docs/core-apis/data-types ・ https://ionic.io/blog/capacitor-everything-youve-ever-wanted-to-know

まとめ：大きいデータの通り道 JS ⇔ Native の通り道大きいデータストリームで送れるか
JSI （ C++ への直接バ参照を持つのでシリアライズなし △ イベント（バイト列は 0.87 からの ArrayBuffer 型か自作の JSI ） Flutter Platform Channel （バイナリ）・ FFI FFI ならシリアライズ ◯ EventChannel （バイナリのまま） NativeScript ランタイムがメタデータで直接呼び出し NSData を ArrayBuffer にラップ NativeModules （デュ ArrayBuffer ⇔ Native Bridge （ JSON メッセージ） JSON にシリアライズ React Native Lynx Capacitor インディング）アルスレッド）なし NSData ・ byte[] → オーバーヘッド △ 専用の仕組みはない △ 専用の仕組みはない △ イベント・ readFileInChunks （ Bridge 経由）ストリームの出典 : React Native 「 Emitting Events in Native Modules 」・ Flutter 「 EventChannel 」 Lynx 「 Native Modules 」・ Capacitor 「 Filesystem 」

まとめ：大きいデータの通り道 React Native JS ⇔ Native の通り道
大きいデータストリームで送れるか JSI （ C++ への直接バ参照を持つのでシリアライズなし △ イベント（バイト列は 0.87 からの ArrayBuffer 型か自作の JSI ） ◯ EventChannel （バイナリのまま）インディング） Capacitor では大きいデータを Bridge に流さない Flutter Platform Channel （バイナリ）・ FFI FFI ならシリアライズ NativeScript ランタイムがメタデータで直接呼び出し NSData を ArrayBuffer にラップ Lynx Capacitor 設計が必要 ArrayBuffer NativeModules （デュアルスレッド）なし Native Bridge （ JSON メッセージ） ⇔ NSData ・ byte[] JSON にシリアライズ → オーバーヘッド △ 専用の仕組みはない △ 専用の仕組みはない △ イベント・ readFileInChunks （ Bridge 経由）ストリームの出典 : React Native 「 Emitting Events in Native Modules 」・ Flutter 「 EventChannel 」 Lynx 「 Native Modules 」・ Capacitor 「 Filesystem 」

どう解決するかプラグインを作ろうデータ転送を最小限に抑え、処理はネイティブ層の中で完結させようネイティブ層を JS からコントロールできる仕組みを提供しよう Bridge で送るのは「指示」だけファイルは chunk
して受け取る

Capacitor プラグインの作り方 ① JS 側でインターフェースを定義
import { registerPlugin } from '@capacitor/core'; export interface EchoPlugin { echo(options: { value: string }): Promise<{ value: string }>; } const Echo = registerPlugin<EchoPlugin>('Echo'); export default Echo; 出典 : https://capacitorjs.com/docs/ios/custom-code （ Apache-2.0 ）

Capacitor プラグインの作り方 ② Swift 側でモジュールを宣言して実装
import Capacitor @objc(EchoPlugin) public class EchoPlugin: CAPPlugin, CAPBridgedPlugin { public let identifier = "EchoPlugin" public let jsName = "Echo" public let pluginMethods: [CAPPluginMethod] = [ CAPPluginMethod(name: "echo", returnType: CAPPluginReturnPromise) ] @objc func echo(_ call: CAPPluginCall) { let value = call.getString("value") ?? "" call.resolve(["value": value]) } } 出典 : https://capacitorjs.com/docs/ios/custom-code （ Apache-2.0 ）

Control Plane・Data Plane データ転送の効率化

Control Plane ・ Data Plane とはもともとはネットワーク機器（ルーター・スイッチ）のアーキテクチャで使われる考え方 Control Plane
パケットを「どう流すか」を決めて、 Data Data Plane （ For warding Plane ） Plane に指示する指示に従って、パケットを実際に処理する e.g. 経路の選択・転送テーブルの調整 e.g. 転送・破棄・書き換え出典 : RFC 7426 Section 2, 3.1, 3.3 https://datatracker.ietf.org/doc/html/rfc7426

Control Plane ・ Data Plane とはもともとはネットワーク機器（ルーター・スイッチ）のアーキテクチャで使われる考え方 We b
層 = C o n tData r o Plane l Plane （ For warding Plane ） Data Native 層 = Data Plane Control Plane パケットを「どう流すか」を決めて、 Plane に指示する指示に従って、パケットを実際に処理する e.g. 経路の選択・転送テーブルの調整 e.g. 転送・破棄・書き換えと当てはめてみる出典 : RFC 7426 Section 2, 3.1, 3.3 https://datatracker.ietf.org/doc/html/rfc7426

考え方 Web 層（ Vue.js ） Control Plane Native 層（ Swift
）・ ① 指示だけ startSession updateCapture 進捗 captureProgress（ 0.5 秒ごと） UI ・撮影ガイド Data Plane ARKit ・ LiDAR ② 逆投影・ボクセル化 ③ 点群データ dataplane://（ 256KB ずつ）点群ファイル

① 指示は Web 、作業は Native Swift の実装を都度書かず、プラグイン経由でネイティブ機能を操作する進捗を
0.5 秒ごとに受け取るよう登録し、撮影を始める handle = await SpatialCapture.addListener( 'captureProgress', (e) => { progress.value = e }, ) const r = await SpatialCapture.startSession(o) sessionId.value = r.sessionId 足りない視点を Web で判定し、撮り方だけを伝える const keyframe = next === 'sparse' ? { translation: base.translation * 3, rotationDeg: base.rotationDeg * 2.5 } : { translation: base.translation, rotationDeg: base.rotationDeg } await SpatialCapture.updateCapture({ keyframe })

② 重いデータは Native 内で閉じる重いデータの処理や負荷の高い計算は、できる限りネイティブ内で終わらせる Metal などを使う場合も同じ考え方を応用できる
点群の生成は深度の逆投影からファイルの書き出しまで Swift で行い、 JS には点群ファイルの場所と点数などだけを返す @objc func buildPointCloud(_ call: CAPPluginCall) { // … work.async { [self] in do { // … let result = try DepthUnprojector.build(sessionDir: dir, frames: frames, condition: cond) { p in report(base + p * (1 - base), "points") } let lods = try store.writeLods(id, result: result, condition: cond) call.resolve(["lods": lods, "framesUsed": result.framesUsed, "samples": result.samples /* … */]) } catch { call.reject(error.localizedDescription) } } }

③ JS に渡すときは chunk する最後に JS へ送る巨大なデータも
chunk して、描画への影響を抑える Native ： dataplane:// で 256KB ずつ返す Web ： ReadableStream で受け、 1 点 16B 単位で GPU へ渡す while remaining > 0 { window.wait() let n = min(chunkSize, remaining) guard let data = try handle.read(upToCount: n), !data.isEmpty else { break } remaining -= data.count DispatchQueue.main.async { [weak self] in defer { window.signal() } // … task.didReceive(data) } } const res = await fetch(url, { signal: o.signal }) // … const reader = res.body.getReader() for (;;) { const { done, value } = await reader.read() if (done) break // … carry const usable = buf.byteLength - (buf.byteLength % 16) if (usable) o.onChunk(buf.subarray(0, usable)) if (usable < buf.byteLength) carry = buf.slice(usable) } （前回の端数をつなぐ）

デモ ① スキャン：撮影ガイドの指示に沿って、ドアの枠をなぞる

デモ ② 寸法の計算：撮影後に自動で点群化し、寸法を測る

デモ ③ 3D 表示：約 12 万点の点群と寸法線を Web 層で描く

Before ・ After 100MiB をネイティブから JS の Uint8Array へ渡す（ Bridge
は base64 、 Data Plane は Range 付きの fetch ）時間メモリ（アプリ＋ WebView ）

逆に転送方法を変えても速くならなかったものサーバーからの取り込みは
Data Plane の方が約 1 秒遅く、深度を毎秒 60 回送ったときは遅延も CPU も同じだったサーバーから 100MiB を取り込む時間（ iPhone 15 Plus ） LiDAR の深度（ 1 フレーム約 246KB ）を毎秒 60 回届けたときの遅延 p95 （ iPad Pro ）

同じ発想が活きる場面 GPU （ WebGL ・ WebGPU ）ゲームの
UI （ Coherent Gameface ）指示： JS が描画の命令を出す指示：画面は HTML ・ CSS ・ JS で作るデータ：頂点やテクスチャは GPU に置いたままデータ：ゲームの状態は C++ 側が持つ CPU へ読み戻す readPixels などは、呼び出したスレッド C++ から出したモデルを、 data-bind-* 属性で画面に結びが止まるので本番では避ける（ MDN ）つける XR ・ AR の 3D シーン（ visionOS ）ネイティブの部品（ Capacitor Google Maps ）指示：アプリは UI と 3D の変更だけを送る指示： JS の API で地図を作り、マーカーやカメラを動かデータ：描画は別プロセスの render server が行うす Apple も、毎フレーム送る更新を減らすよう勧めているデータ：地図はネイティブで描く（ Android は WebView の下）このアプリの AR プレビューも同じ形出典 : MDN 「 WebGL best practices 」・ Gameface 「 HTML Data Binding 」・ Capacitor 「 @capacitor/google-maps 」 Apple 「 Understanding the visionOS render pipeline 」「 Reducing the rendering cost of RealityKit content on visionOS 」

最後に

今後の課題 LiDAR 非対応端末のフォールバック、どうする？ Android サポート ARCore Depth API Web は
View Only に振り切る？

Ask the Speaker ・懇親会で話した
いこと WebView で認証を受け渡す方法空間解析・ 3D モデルの出力品質を上げるためにやっていること解析データの LLM ・ VLM 処理 3DGS

thank you for listening ご清聴ありがとうございました

Vue.jsで作る空間解析アプリとCapacitorプラグインのData Bridge

Vue.jsで作る空間解析アプリとCapacitorプラグインのData Bridge

More Decks by Hal

Other Decks in Programming

Featured

Transcript