アプリ実行モデルの体系化推移

HarmonyOSのネイティブ開発において、アプリケーションの実行環境は段階的に刷新されてきた。当初採用されたFA（Feature Ability）モデルから、現在の標準であるStageモデルへの移行は、単なる構文の変更にとどまらず、システムリソースの最適配分と分散コンピューティング基盤への対応を意味する重要な転換点である。各モデルの本質的な違いを理解することは、高信頼性のOS開発に不可欠である。

初期実装アプローチ：FAモデルの構造特性

APIレベル8〜10で運用されていたFAモデルは、比較的単純なUI要件を満たすことを主眼に設計されていた。この架構では「Ability」が最小の実行単位となり、ユーザーインターフェースを提供するFAとバックグラウンド処理専門のPAに分類される。最大の特徴は、画面遷移ロジックとビジネスロジックがAbilitySliceという単位内で密結合している点である。一つのMainAbilityの下に複数のスライスを配置し、スタックベースで画面状態を管理する方式は、初期の軽量開発には適していたが、複雑なステートマシンや大規模レンダリングではボトルネックとなる可能性があった。

project_root
├── AppRoot/
│   └── MainFeature/
│       ├── src/
│       │   ├── slices/          # UI断面管理クラス群
│       │   ├── core.js          # クラス定義とステート維持
│       │   └── resources/       # 静的アセット
│       └── manifest.json        # レンチポイント宣言リスト

モダン分散基盤：Stageモデルの登場背景と核概念

API 9以降、システム側が推奨するStageモデルは、現代のフロントエンドアーキテクチャが採用するコンポーネント分離思想をOSレベルに取り入れた革新である。従来の「ページ＝機能」の直結関係から脱却し、UI表示層、ウィンドウ制御層、バックエンドロジック層を明確に分離した。
主要な構成要素は以下の3つである：

• UIAbility： アプリケーションのエントリポイント兼コンテナ。プロセス分離によりクラッシュ隔離を実現。
• WindowStage： 仮想スクリーン領域を抽象化したマネージャー。マルチウィンドウやドラッグ＆ドロップの制御を担当。
• LayoutNode（ウィジェット群）： ArkUIエンジンが担当する描画オブジェクト。親要素に対して多対一の依存関係を持つ。

これらの階層構造により、デバイス間の画面サイズ差異や分割表示機能を柔軟に吸収できるようになった。

ディレクトリ構成と設定フローの変化

開発プロジェクトのファイルレイアウトは、よりモジュール性と設定の分離度を高める方向へ進化している。新しい構造では、グローバル設定とモジュール固有の設定が完全に独立し、主にArkTS言語を用いて型安全な実装が行われる。

harmony_app_base/
├── AppScope/
│   └── config/                  # グローバルバージョン・バンドル情報管理
├── entry/
│   ├── src/main/ets/
│   │   ├── ui/                  # コンポーネント定義ディレクトリ
│   │   ├── managers/            # ビジネスルール統合層
│   │   └── ability/             # EntryAbility.ts（エントリクラス）
│   ├── src/main/resources/base/ # 国際化リソースプール
│   └── descriptor.json          # モジュール依存・権限マニフェスト

状態遷移メカニズムの比較

Stageモデルでは、プロセスとUIの生成順序が厳格に規定され、開発者が意図しない状態遷移を防ぐ仕組みが組み込まれている。典型的なイベントフックは以下の通り定義される：

• onCreate()：インスタンス化直後に呼出される初期化トリガー。
• onWindowStageCreate(windowStage)：ウィンドウコンテナの準備完了時に発行。
• onForeground() / onBackground()：フォアグラウンド活動の有効・無効を切り替えるための状態フラグ管理。
• onDestroy()：リソース解放とクリーンアップ対象メソッド。

この厳密なコールバックチェーンは、ネットワーク切断時のステート復帰や、他端末からのタスク引き継ぎ処理を予測可能にする基盤となっている。

技術的優位性と開発効率への寄与

Stageモデルが従来の架構に対し持つ利点は、主にリソース制御粒度、分散接続能力、コード品質の3点に集約される。

リソースオーケストレーションの高度化： OSカーネル側がUIAbilityの状態を監視するため、バックグラウンド遷移時に自動でスレッド優先度やメモリ割り当てを最適化できる。これによりマルチタスク環境下でのフレームレート低下や熱暴走を軽減する。

Native Distributed対応： デバイス間プロキシ機能が標準搭載され、UIAbilityインスタンス自体を別のハードウェアに移動させる「Continuation（継続）」機能が容易に実装可能となった。ユーザー体験におけるデバイスの枠取りを超えた作業流の確保に直結する。

関心の分離による保守性向上： View層（ArkUI）、Control層（ViewModel/Controller）、Data層を物理的にも論理的にも区切ることで、チーム開発時の競合を大幅に抑制できる。型チェック機能を活用したArkTS環境との相性も極めて高い。

新規構築と既存資産の移行ガイドライン

ゼロから作成するアプリケーションであれば、迷わずStageモデルを採用すべきである。公式ツールチェインの最新機能、パフォーマンストレーシングツール、ドキュメントの多くがStage基盤に最適化されているためだ。

既存のFAコードベースをアップデートする場合、以下の方針でステップ実行するのが確実である：

1. ルーティング再編： スライスベースのナビゲーションスタックから、Routerまたはナビゲーションコンポーネントへの書き換えを実行。
2. マニフェスト移植： JSON形式の古い定義ファイルをdescriptor.jsonの構造へマッピングし、権限カテゴリを見直す。
3. 漸進的置き換え： 全量一括変換ではなく、機能ブロックごとにStageアダプターをかませるパターンを選択すると、ビルド失敗リスクを回避できる。