了解鸿蒙開発（一）-- 実行時の視点

Introduction#

The following text has been translated to Japanese:

前言#

鸿蒙開発を学ぶことで、以下の目標を達成したいと思います：

ネイティブ開発に必要な全体的な概念と知識をより速く構築するための中国語のドキュメントを利用し、ネイティブ開発スキルの拡張を完了させます。
新しい競技場に備えて知識を蓄え、風が吹くのを待ちます。

この記事では、Web フロントエンドエンジニアの視点から、HarmonyOS 開発が何を開発しているのかを理解します。

アプリケーションモデル - HarmonyOS アプリの基本ルール#

アプリケーションモデルは、HarmonyOS が開発者に提供するアプリケーションの能力を抽象化し、アプリケーションに必要なコンポーネントと実行メカニズムを提供します -- HarmonyOS Developer ドキュメント

アプリケーションモデルは、HarmonyOS アプリの開発の「ルール」を定義しています。HarmonyOS アプリの開発は、既定の実行メカニズムの下でコンポーネントを使用してアプリの機能を実現することです。

具体的には、アプリケーションモデルにはアプリケーションコンポーネント、アプリケーションプロセスモデル、アプリケーションスレッドモデル、アプリケーションタスク管理モデル、アプリケーション設定ファイルの 5 つの要素が含まれています。（後の 4 つは実行メカニズムです）

HarmonyOS の進化の過程で、FA モデルと Stage モデルの 2 つのモデルがありますが、これらは 5 つの要素のいずれかに異なる点があります。ここでは、将来的に主力となる Stage アプリケーションモデルに焦点を当てます。

Stage モデルの開発概要#

アプリケーションコンポーネント#

アプリケーションコンポーネントは、開発者が主に使用して実装する実体です。Stage アプリケーションモデルでは、アプリケーションコンポーネントは UIAbility と ExtentionAbility に分かれます。

UIAbility は、UI インターフェースを含むアプリケーションコンポーネントであり、フロントエンド開発者にとってはおなじみのページのキャリアであり、ユーザーとのインタラクションに主に使用されます。UIAbility は、Chrome のタブで複数のページを表示するためのものであり、具体的な UI は複数のページで完成します。

一方、ExtentionAbility は、特定のアプリケーションシナリオ向けのアプリケーションコンポーネントであり、UI インターフェースを含まない場合もあります。例えば、入力法シナリオ、デスクトップカード / ウィジェットシナリオ、バックグラウンドサービスなどです。具体的なコンポーネントのタイプについては、ドキュメントを参照してください。

その他の主要な概念#

アプリケーションコンポーネントとプロセス、スレッドなどの実行メカニズムの間には、コンポーネントと実行メカニズムを結びつける実装と概念のレイヤーがあります。以下の図を参照して理解することができます。

AbilityStage と Context#

アプリケーションコンポーネントは自己駆動できないため、Ability を駆動および調整するための「人」が必要です。それが AbilityStage です。アプリが起動すると、AbilityStage が最初に作成され、デフォルトの Ability の読み込みと実行が開始されます。

AbilityStage と一緒に作成されるのは、その AbilityStage のすべてのコンテキスト情報を記録する Context です。各 UIAbility は、この Context（UIAbilityContext）から自分自身のコンテキストを派生させます。UIAbility のページは、いくつかの実行情報とメソッドを取得するために、このコンテキストを使用することができます。

WindowStage と Page#

各 UIAbility は、実行時に直接ページを管理するのではなく、保持している WindowStage を使用してページを管理します。これは、現在のアプリケーションでは、単一のフルスクリーンウィンドウの形態だけでなく、ドキュメントアプリケーションではリアルタイムプレビューに使用される複数のウィンドウ、ビデオアプリケーションではフローティングウィンドウでのビデオ再生などがあるためです。ページ内でシミュレートされたウィンドウと比較して、WindowStage はより正確なライフサイクルとより強力なインタラクション能力を持っています。（アプリケーションモデルのより基本的な実装に近いため）

最後に、フロントエンド開発者が馴染みのあるページ（Page）に到達しました。ページは ArkUI を使用してインタラクティブなインターフェースを実現するためのものであり、ユーザーが見ることができる画面です。1 つの UIAbility には複数のページがあり、指定されたウィンドウに表示されます。

ここで言及する価値があるのは、HarmonyOS 開発では、ArkUI の他にも、HTML、CSS、JavaScript を使用してページ UI を構築する Web 開発パラダイムも存在することです（ArkUI は ArkTS を使用してページを構築するため、HTML と CSS は使用しません）。** ただし、Stage 開発モデルでは、ページの開発には ArkUI のみを使用できます。** したがって、個人としては、Stage アプリケーションモデルに従い、ArkTS と ArkUI を使用して HarmonyOS アプリを実装することが、HarmonyOS の発展トレンドにより適合し、長期的な利益をもたらすでしょう。企業としては、Stage モデルを選択して既存のアプリを完全に再現するか、FA アプリモデルを選択して既存の Web ページを迅速に移行するかを選択することになります。この選択は、Huawei の決意と投資、政策の方向性などの外部要因、および現在の技術選択、スケジュール可能なリソースなどの内部要因を総合的に考慮して決定する必要があります。

UIAbility の理解#

Stage 開発モデルの主要な概念を学んだことで、ユーザーが見る HarmonyOS アプリは、AbilityStage を基盤とし、UIAbility を主要なスケジューリングユニットとする能力の集合であることがわかります。

UIAbility をさらに理解し、UIAbility の能力範囲を把握することで、アプリの機能を適切に分割し、アプリの構造を設計することができます。

以下では、内部（ライフサイクル）から外部（他のエンティティとのインタラクション）まで、UIAbility の理解を深めます。

ライフサイクル#

保持モード（retained mode）の GUI の世界では、ここでの「万物」は人と同様に周期的に「生老病死」を経験します。私たちは周期ノードのコールバック関数に応答することで、UI の状態を構築・変更し、特定の期間の画面ビューを描画します。UIAbility は「世界」の一員として、もちろん自身のライフサイクルを持っています。

Pasted image 20230927182238_副本

図からわかるように、UIAbility のライフサイクルはユーザーの視点であり、作成、フォアグラウンドへの移行、バックグラウンドへの移行、破棄の 4 つのノードを含んでいます。それは WindowStage と「共生共死」しているため、彼らのライフサイクルも関連しています。この図を大まかに心に刻んだ後、実際の開発では、目的に応じて適切なアプローチを取ることができます。

これらのノードの中で、UIAbility の現在の状態（作成済み、表示可能、現在のフォーカス）を感知することができます。また、いくつかの手段を通じて、関連するエンティティとのインタラクションを行い、アプリの状態を変更することもできます。

ページとのインタラクション#

イベントメカニズムを使用して、UIAbility 内のページにイベントを送信し、特定の変更を通知し、グローバルオブジェクトとページ間でデータを共有することができます。具体的な使用方法については、ドキュメントを参照してください。注意すべきは、イベントは UIAbility 内部に限定されていることです。なぜなら、EventBus は UIAbility 自体の Context にマウントされているためであり、ページは他の UIAbility の Context にアクセスすることはできません。グローバルオブジェクトはアプリケーションモデルに依存します。Stage では、すべての Ability が同じ ArkTS エンジンを共有しているため、1 つのグローバルオブジェクトしかありません。誰でもこのオブジェクト上で読み書きを行うことができますが、上書きのリスクがあります。（FA モデルでは、Ability は独自の ArkTS エンジンを持つため、グローバルオブジェクトは独立しています）

他の Ability とのインタラクション#

他の Ability とのインタラクションは、オープンメソッドと情報キャリアの 2 つの要素にまとめることができます。現時点では、他の Ability とのインタラクションは、他の Ability を起動することによって行われます。結果を取得する必要があるかどうかに応じて、メソッドは細分化されます。情報キャリアである「want」は、どの Ability をどのような方法で開くかを説明しています。いくつかのパラメータを確定することで、同じアプリ内の Ability を開くことも、異なるアプリの Ability を開くこともできます。これにより、現在一般的なサードパーティの支払いなどのシナリオを実現することができます。ここで言及されている「方法」とは、「新規作成」または「再利用」のことを指します。

ここで UIAbility の起動モードについて補足します。3 つのモードがあります：シングルトンモード、スタンダードモード、指定モードです。シングルトンモードは、現在の Ability が既に作成されている場合、新しい Ability を作成せずにフォアグラウンドに切り替えるだけです。スタンダードモードは常に新しい Ability を作成します。複雑なシナリオでは、呼び出し時に新しい Ability を作成するか再利用するかを決定する指定モードがあります。具体的な操作方法については、ドキュメントを参照してください。

プロセスとスレッドモデルの理解#

プロセスとスレッドについての説明はドキュメント中には少ないです。理解する必要があるのは、同じアプリのすべての Ability が同じプロセスで実行されること、Web ビューは独自のレンダリングプロセスを持っていることです。1 つのプロセスには 1 つのメインスレッドと複数のワーカースレッドがあり、どちらのスレッドにも ArkTS エンジンがあります。前述のように、Stage モデルでは、UIAbility はメインスレッドの ArkTS エンジンで実行されます。メインスレッドの機能は、ドキュメントで言及されています：

UI の描画を実行する。
メインスレッドの ArkTS エンジンインスタンスを管理し、複数の UIAbility コンポーネントがそれ上で実行できるようにする。
他のスレッド（例：ワーカースレッド）の ArkTS エンジンインスタンスを管理し、他のスレッドの起動と終了を行う。
インタラクションイベントをディスパッチする。
イベント処理とライフサイクル管理を含むアプリケーションコードのコールバックを処理する。
ワーカースレッドからのメッセージを受信する。

私自身の知識の限界により、この領域の理解は深まりにくいです。実際のアプリケーションを使用する際に研究を行います。

結語#

HarmonyOS ドキュメントのアプリケーションモデルセクションを読むことで、HarmonyOS アプリの実行時の様子を大まかに把握することができました。1 つのプロセスのメインスレッドで、AbilityStage を介して異なる UIAbility をスケジュールし、さらに UIAbility 自体がウィンドウを管理し、ページを表示します。

また、複雑な既存のアプリにとって、どの開発モデルを選択するかは検討する必要があります。Stage モデルと FA モデルは混在できないため、1 つのアプリ内で 1 つのモジュールが Stage モデルで開発され、別のモジュールが FA モデルで開発されることはありません。したがって、アプリの主体を選択すると、既存の Web ページや小さなプログラムページをクイックに移行するための Web 開発パラダイムを使用できるかどうかが制限されます。

次の記事では、コンパイル時の視点から、具体的なコードの組織方法、モジュールの再利用方法、最終的なパッケージ化された成果物について理解し、完全な HarmonyOS アプリ開発体系を構築します。