特表 2024-515440 アプリケーションインターフェースの表示方法、装置、デバイス、及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-04-10

(54)【発明の名称】アプリケーションインターフェースの表示方法、装置、デバイス、及び記憶媒体

(51)【国際特許分類】

   G06F 1/3293 20190101AFI20240403BHJP

   G06F 1/3206 20190101ALI20240403BHJP

   G06F 15/78 20060101ALI20240403BHJP

【ＦＩ】

G06F1/3293

G06F1/3206

G06F15/78 517

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023556870

(86)(22)【出願日】2022-03-07

(85)【翻訳文提出日】2023-09-14

(86)【国際出願番号】 CN2022079536

(87)【国際公開番号】W WO2022213757

(87)【国際公開日】2022-10-13

(31)【優先権主張番号】202110366882.3

(32)【優先日】2021-04-06

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．アンドロイド

２．ＡＮＤＲＯＩＤ

３．ブルートゥース

４．ＢＬＵＥＴＯＯＴＨ

(71)【出願人】

【識別番号】516227559

【氏名又は名称】オッポ広東移動通信有限公司

【氏名又は名称原語表記】ＧＵＡＮＧＤＯＮＧ ＯＰＰＯ ＭＯＢＩＬＥ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＣＯＲＰ．， ＬＴＤ．

【住所又は居所原語表記】Ｎｏ． １８ Ｈａｉｂｉｎ Ｒｏａｄ，Ｗｕｓｈａ， Ｃｈａｎｇ’ａｎ，Ｄｏｎｇｇｕａｎ， Ｇｕａｎｇｄｏｎｇ ５２３８６０ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100120031

【弁理士】

【氏名又は名称】宮嶋 学

(74)【代理人】

【識別番号】100107582

【弁理士】

【氏名又は名称】関根 毅

(74)【代理人】

【識別番号】100152205

【弁理士】

【氏名又は名称】吉田 昌司

(74)【代理人】

【識別番号】100137523

【弁理士】

【氏名又は名称】出口 智也

(72)【発明者】

【氏名】ワン、チャオチン

【テーマコード（参考）】

5B011

5B062

【Ｆターム（参考）】

5B011DA06

5B011DC06

5B011EA05

5B011EB09

5B011LL12

5B062HH07

(57)【要約】

ウェアラブルデバイス分野に関するアプリケーションインターフェースの表示方法、装置、デバイス、及び記憶媒体が提供される。当該方法は、第一システムがウェイクアップ状態にあり、且つ第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、第一システムによって目標アプリケーションのインターフェースを描画し表示する（３０１）ことと、第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、第二システムによって目標アプリケーションのインターフェースを描画する（３０２）ことと、第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行する（３０３）ことと、を含む。第一システムによってアプリケーションの起動効果を表示することで、アプリケーションの起動速度を視覚的に向上させることが可能となり、システム切り替え中のアプリケーション画面の表示遅延を低減する。第一システムによってアプリケーションの起動効果を事前表示することで、アプリケーションの起動速度を視覚的に向上させることが可能となり、システム切り替え中のアプリケーション画面の表示遅延を低減する。

【特許請求の範囲】

【請求項1】

アプリケーションインターフェースの表示方法であって、前記方法は、第一システム及び第二システムの実行をサポートするウェアラブルデバイスに用いられ、前記方法は、
前記第一システムがウェイクアップ状態にあり、且つ前記第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示することと、
前記第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、前記第二システムによって前記目標アプリケーションのインターフェースを描画することと、
前記第二システムによる前記目標アプリケーションのインターフェースの描画の完了に応答して、前記第二システムによって、前記目標アプリケーションのインターフェースを表示し、且つ前記目標アプリケーションを実行することと、を含む、
ことを特徴とするアプリケーションインターフェースの表示方法。

【請求項2】

前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示することは、
前記第一システムによって、前記第一システムに対応する記憶空間である第一記憶空間から前記目標アプリケーションに対応する目標インターフェースリソースを取得することと、
前記目標インターフェースリソースに基づいて、前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示することと、を含む、
ことを特徴とする請求項１に記載の方法。

【請求項3】

前記第一システムによって、前記第一記憶空間から前記目標アプリケーションに対応する前記目標インターフェースリソースを取得することは、
前記第一システムによって、前記目標アプリケーションに対応する目標アプリケーション情報を取得することと、
前記目標アプリケーション情報に基づいて、前記第一システムによって前記第一記憶空間から前記目標インターフェースリソースを取得することと、を含む、
ことを特徴とする請求項２に記載の方法。

【請求項4】

前記方法は、
前記第二システムがウェイクアップ状態にある場合、前記第二システムによって前記第一システムにインターフェースリソース更新メッセージを送信することと、
前記インターフェースリソース更新メッセージに基づいて、前記第一システムによって、前記第一記憶空間に記憶されたインターフェースリソースを更新することと、をさらに含む、
ことを特徴とする請求項２に記載の方法。

【請求項5】

前記第二システムがウェイクアップ状態にある場合、前記第二システムによって前記第一システムに前記インターフェースリソース更新メッセージを送信することは、
前記第二システムがウェイクアップ状態にある場合、言語更新ブロードキャストが受信されたことに応答して、前記第二システムによって第一アプリケーションの第一アプリケーション情報を取得することであって、前記第一アプリケーションに対応する第一インターフェースリソースが前記第一記憶空間に記憶されている、取得することと、
前記第二システムによって前記第一システムに、前記第一アプリケーション情報と更新された第一インターフェースリソースとを含む第一インターフェースリソース更新メッセージを送信することと、を含み、
前記インターフェースリソース更新メッセージに基づいて、前記第一システムによって、前記第一記憶空間に記憶された前記インターフェースリソースを更新することは、
前記第一システムによって、前記第一アプリケーション情報と、前記更新された第一インターフェースリソースとを関連付けて前記第一記憶空間に記憶すること、を含む、
ことを特徴とする請求項４に記載の方法。

【請求項6】

前記第二システムによって前記第一アプリケーションの前記第一アプリケーション情報を取得することは、
前記第二システムによって前記第一システムにクエリメッセージを送信することと、
前記第一システムによって、前記第二システムに前記第一アプリケーションの前記第一アプリケーション情報を送信し、且つ、前記第一記憶空間から前記第一アプリケーションに対応する前記第一インターフェースリソースを削除することと、を含む、
ことを特徴とする請求項５に記載の方法。

【請求項7】

前記第二システムによって前記第一アプリケーションの前記第一アプリケーション情報を取得することは、
前記第二システムによって、前記第二システムに対応する記憶空間である第二記憶空間から前記第一アプリケーションの前記第一アプリケーション情報を取得すること、を含み、
前記第一システムによって、前記第一アプリケーション情報と、前記更新された第一インターフェースリソースとを関連付けて前記第一記憶空間に記憶することは、
前記第一インターフェースリソース更新メッセージに強制更新識別子が含まれていることが識別されたことに応答して、前記第一システムによって、前記第一記憶空間に記憶された前記インターフェースリソースを削除し、且つ、前記第一アプリケーション情報と、前記更新された第一インターフェースリソースとを関連付けて前記第一記憶空間に記憶すること、を含む、
ことを特徴とする請求項５に記載の方法。

【請求項8】

前記第二システムがウェイクアップ状態にある場合、前記第二システムによって前記第一システムに前記インターフェースリソース更新メッセージを送信することは、
前記第二システムがウェイクアップ状態にある場合、第二アプリケーションの起動形態更新メッセージがモニタリングされたことに応答して、前記第二システムによって前記第二アプリケーションの第二アプリケーション情報及び第二インターフェースリソースを取得することであって、前記起動形態更新メッセージは前記第二アプリケーションの起動形態の変化を表すために用いられる、取得することと、
前記第二システムによって前記第一システムに、更新形態と、前記第二アプリケーション情報と、前記第二インターフェースリソースとを含む第二インターフェースリソース更新メッセージを送信することと、を含み、
前記インターフェースリソース更新メッセージに基づいて、前記第一システムによって、前記第一記憶空間に記憶された前記インターフェースリソースを更新することは、
前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新すること、を含む、
ことを特徴とする請求項４に記載の方法。

【請求項9】

前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新することは、
前記更新形態が追加であることに応答して、前記第一システムによって、前記第二アプリケーション情報と、前記第二インターフェースリソースとを関連付けて前記第一記憶空間に記憶することと、
前記更新形態が削除であることに応答して、前記第一システムによって、前記第一記憶空間から前記第二アプリケーション情報及び前記第二インターフェースリソースを削除することと、を含む、
ことを特徴とする請求項８に記載の方法。

【請求項10】

前記方法は、
前記更新形態が追加であり、且つ前記第一記憶空間に前記第二アプリケーション情報が記憶されていることに応答して、更新衝突が存在すると特定することと、
前記更新形態が削除であり、且つ前記第一記憶空間に前記第二アプリケーション情報が記憶されており、且つ削除待ちの起動形態以外の起動形態によって前記第二アプリケーション情報が利用されることに応答して、更新衝突が存在すると特定することと、をさらに含み、
更新衝突が存在する場合、前記第一記憶空間における前記第二インターフェースリソースが更新されない、
ことを特徴とする請求項９に記載の方法。

【請求項11】

前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新することは、
前記第二インターフェースリソース更新メッセージに強制更新識別子が含まれておらず、且つ、更新衝突が存在しないことが識別されたことに応答して、前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新すること、を含み、
前記方法は、
前記第二インターフェースリソース更新メッセージに前記強制更新識別子が含まれていることが識別されたことに応答して、前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新すること、をさらに含む、
ことを特徴とする請求項８に記載の方法。

【請求項12】

前記第一記憶空間は、前記第一システムで起動されることがサポートされるアプリケーションに対応するインターフェースリソースを記憶するために用いられ、
前記第一システムでアプリケーションを起動する形態は、ショートカットキーによる起動、及び前記第一システムのウィジェットによる起動のうちの少なくとも１つを含む、
ことを特徴とする請求項２～１１のいずれか一項に記載の方法。

【請求項13】

前記第二システムによる前記目標アプリケーションのインターフェースの描画の完了に応答して、前記第二システムによって、前記目標アプリケーションのインターフェースを表示し、且つ前記目標アプリケーションを実行することは、
前記第二システムによる前記目標アプリケーションのインターフェースの描画の完了に応答して、前記第二システムによって前記第一システムに、前記第一システムにグラフィカルユーザインターフェース（ＧＵＩ）の表示権限を移行させるように指示するための切り替え指示を送信することと、
前記第二システムが前記ＧＵＩの表示権限を取得したことに応答して、前記第二システムによって、前記目標アプリケーションの前記インターフェースを表示し、且つ前記目標アプリケーションを実行することと、を含む、
ことを特徴とする請求項１～１１のいずれか一項に記載の方法。

【請求項14】

前記ウェアラブルデバイスは、第一プロセッサ及び第二プロセッサを備え、前記第二プロセッサの消費電力は前記第一プロセッサの消費電力より大きく、前記第一システムは、前記第一プロセッサによって実行されるシステムであり、前記第二システムは、前記第二プロセッサによって実行されるシステムである、
ことを特徴とする請求項１～１１のいずれか一項に記載の方法。

【請求項15】

アプリケーションインターフェース表示装置であって、前記装置は、第一システム及び第二システムの実行をサポートするウェアラブルデバイスに用いられ、前記装置は、第一システムモジュール及び第二システムモジュールを備え、
前記第一システムモジュールは、前記第一システムがウェイクアップ状態にあり、且つ前記第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示するように構成されており、
前記第二システムモジュールは、前記第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、前記第二システムによって前記目標アプリケーションのインターフェースを描画するように構成されており、
前記第二システムモジュールはさらに、前記第二システムによる前記目標アプリケーションのインターフェースの描画の完了に応答して、前記第二システムによって、前記目標アプリケーションのインターフェースを表示し、且つ前記目標アプリケーションを実行するように構成されている、
ことを特徴とするアプリケーションインターフェース表示装置。

【請求項16】

前記第一システムモジュールは、
前記第一システムによって、前記第一システムに対応する記憶空間である第一記憶空間から前記目標アプリケーションに対応する目標インターフェースリソースを取得し、
前記目標インターフェースリソースに基づいて、前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示し、
前記第一システムによって、前記目標アプリケーションに対応する目標アプリケーション情報を取得し、
前記目標アプリケーション情報に基づいて、前記第一システムによって前記第一記憶空間から前記目標インターフェースリソースを取得する、ように構成されている、
ことを特徴とする請求項１５に記載の装置。

【請求項17】

前記第二システムモジュールはさらに、前記第二システムがウェイクアップ状態にある場合、前記第二システムによって前記第一システムにインターフェースリソース更新メッセージを送信するように構成されており、
前記第一システムモジュールはさらに、前記インターフェースリソース更新メッセージに基づいて、前記第一システムによって、前記第一記憶空間に記憶されたインターフェースリソースを更新するように構成されている、
ことを特徴とする請求項１５に記載の装置。

【請求項18】

前記第二システムモジュールは、
前記第二システムがウェイクアップ状態にある場合、言語更新ブロードキャストが受信されたことに応答して、前記第二システムによって第一アプリケーションの第一アプリケーション情報を取得するように構成されており、前記第一アプリケーションに対応する第一インターフェースリソースが前記第一記憶空間に記憶されており、
前記第二システムモジュールは、前記第二システムによって前記第一システムに、前記第一アプリケーション情報と更新された第一インターフェースリソースとを含む第一インターフェースリソース更新メッセージを送信するように構成されており、
前記第一システムモジュールは、
前記第一システムによって、前記第一アプリケーション情報と、前記更新された第一インターフェースリソースとを関連付けて前記第一記憶空間に記憶するように構成されている、
ことを特徴とする請求項１７に記載の装置。

【請求項19】

前記ウェアラブルデバイスは、第一プロセッサ及び第二プロセッサを備え、前記第二プロセッサの消費電力は前記第一プロセッサの消費電力より大きく、前記第一システムは、前記第一プロセッサによって実行されるシステムであり、前記第二システムは、前記第二プロセッサによって実行されるシステムである、
ことを特徴とする請求項１５～１８のいずれか一項に記載の装置。

【請求項20】

プロセッサ及びメモリを備えるウェアラブルデバイスであって、
前記メモリに少なくとも１つの命令が記憶されており、前記少なくとも１つの命令は、前記プロセッサによって実行されることにより、請求項１～１４のいずれか一項に記載のアプリケーションインターフェースの表示方法を実現するために用いられる、
ことを特徴とするウェアラブルデバイス。

【請求項21】

少なくとも１つの命令が記憶されたコンピュータ可読記憶媒体であって、
前記少なくとも１つの命令は、プロセッサによって実行されることにより、請求項１～１４のいずれか一項に記載のアプリケーションインターフェースの表示方法を実現するために用いられる、
ことを特徴とするコンピュータ可読記憶媒体。

【請求項22】

コンピュータプログラム製品又はコンピュータプログラムであって、
前記コンピュータプログラム製品又は前記コンピュータプログラムは、コンピュータ命令を含み、前記コンピュータ命令はコンピュータ可読記憶媒体に記憶されており、ウェアラブルデバイスのプロセッサは、前記コンピュータ可読記憶媒体から前記コンピュータ命令を読み出し、前記プロセッサは前記コンピュータ命令を実行することにより、端末に請求項１～１４のいずれか一項に記載のアプリケーションインターフェースの表示方法を実行させる、
ことを特徴とするコンピュータプログラム製品又はコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の参照
本出願は、発明の名称が「アプリケーションインターフェースの表示方法、装置、デバイス、及び記憶媒体」である、２０２１年４月６日に出願された中国特許出願第２０２１１０３６６８８２．３号の優先権を主張し、そのすべての内容が引用として本出願に組み込まれる。

【0002】

本出願の実施形態は、ウェアラブルデバイス分野に関し、特にアプリケーションインターフェースの表示方法、装置、デバイス、及び記憶媒体に関する。

【背景技術】

【0003】

ウェアラブルデバイスは、直接に装着されたり、衣類やアクセサリーに統合されたりすることができる携帯型の電子デバイスである。よく見られるウェアラブルデバイスは、スマートウォッチ、スマートブレスレット、スマートグラス等を含む。

【0004】

ウェアラブルデバイスがスマートウォッチであることを例として、ユーザは、ウェアラブルデバイスを利用して時間をチェックすることができ、ウェアラブルデバイスにインストールされたアプリケーションプログラムを利用して、睡眠品質監視、運動統計、及び通知・メッセージのチェック等の機能を実現することができる。

【発明の概要】

【0005】

本出願の実施形態において、アプリケーションインターフェースの表示方法、装置、デバイス、及び記憶媒体が提供される。その技術案は以下の通りである。

【0006】

１つの様態において、本出願の実施形態では、アプリケーションインターフェースの表示方法が提供される。当該方法は、第一システム及び第二システムの実行をサポートするウェアラブルデバイスに用いられる。当該方法は、
第一システムがウェイクアップ状態にあり、且つ第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、第一システムによって目標アプリケーションのインターフェースを描画し表示することと、
第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、第二システムによって目標アプリケーションのインターフェースを描画することと、
第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行することと、を含む。

【0007】

別の様態において、本出願の実施形態では、アプリケーションインターフェース表示装置が提供される。当該装置は、第一システム及び第二システムの実行をサポートするウェアラブルデバイスに用いられる。当該装置は、第一システムモジュール及び第二システムモジュールを備える。
第一システムモジュールは、第一システムがウェイクアップ状態にあり、且つ第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、第一システムによって目標アプリケーションのインターフェースを描画し表示するように構成されており、
第二システムモジュールは、第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、第二システムによって目標アプリケーションのインターフェースを描画するように構成されており、
第二システムモジュールはさらに、第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行するように構成されている。

【0008】

別の様態において、本出願の実施形態では、ウェアラブルデバイスが提供される。当該ウェアラブルデバイスは、プロセッサ及びメモリを備える。メモリに少なくとも１つの命令が記憶されており、少なくとも１つの命令は、プロセッサによって実行されることにより、上記様態に記載のアプリケーションインターフェースの表示方法を実現するために用いられる。

【0009】

別の様態において、本出願の実施形態では、コンピュータ可読記憶媒体が提供される。当該可読記憶媒体に少なくとも１つの命令が記憶され、少なくとも１つの命令は、プロセッサによって実行されることにより、上記様態に記載のアプリケーションインターフェースの表示方法を実現するために用いられる。

【0010】

別の様態において、本出願の実施形態では、コンピュータプログラム製品又はコンピュータプログラムが提供される。当該コンピュータプログラム製品又はコンピュータプログラムは、コンピュータ命令を含み、当該コンピュータ命令はコンピュータ可読記憶媒体に記憶されている。コンピュータデバイスのプロセッサは、コンピュータ可読記憶媒体から当該コンピュータ命令を読み出し、プロセッサは当該コンピュータ命令を実行することにより、当該コンピュータデバイスに上記様態に係るアプリケーションインターフェースの表示方法を実行させる。

【図面の簡単な説明】

【0011】

【図1】図１は、本出願の１つの例示的な実施形態に係る第二プロセッサに対応するデュアルコア通信ソフトウェアフレームワークを示す概略図である。

【図2】図２は、本出願の１つの例示的な実施形態に係る第一プロセッサに対応するデュアルコア通信ソフトウェアフレームワークを示す概略図である。

【図3】図３は、本出願の１つの例示的な実施形態に係るアプリケーションインターフェースの表示方法を示すフローチャートである。

【図4】図４は、本出願の１つの例示的な実施形態に係るスマートウォッチにおけるアプリケーション起動プロセスのインターフェースを示す概略図である。

【図5】図５は、本出願の１つの例示的な実施形態に係るアプリケーションインターフェースの表示方法を示すフローチャートである。

【図6】図６は、本出願の１つの例示的な実施形態に係るインターフェースリソースの更新プロセスの実施概略図である。

【図7】図７は、本出願の１つの例示的な実施形態に係るインターフェースリソースの更新プロセスを示すフローチヤ一トである。

【図8】図８は、本出願の１つの例示的な実施形態に係るインターフェースリソースの更新プロセスにおけるシステムインタラクションのシーケンス図である。

【図9】図９は、本出願の別の例示的な実施形態に係るインターフェースリソースの更新プロセスを示すフローチャートである。

【図10】図１０は、本出願の別の例示的な実施形態に係るインターフェースリソースの更新プロセスにおけるシステムインタラクションのシーケンス図である。

【図11】図１１は、本出願の１つの例示的な実施形態に係るアプリケーションインターフェースの表示装置の構造を示すブロック図である。

【図12】図１２は、本出願の１つの例示的な実施形態に係るウェアラブルデバイスの構造を示すブロック図である。

【発明を実施するための形態】

【0012】

本出願の目的、技術案及び利点をより明確にするために、以下、図面を参照しながら本出願の実施形態についてさらに詳述する。

【0013】

本明細書に言及される「複数」は２つ以上のことをいう。用語「及び／又は」は関連対象の関連関係を説明するものであり、３種類の関係が存在することを示す。例えば、Ａ及び／又はＢの場合は、Ａのみが存在すること、ＡとＢが同時に存在すること、Ｂのみが存在することという３つの状況を示す。また、符号「／」は一般的に前後の関連対象が「又は」の関係にあることを示す。

【0014】

関連技術では、ウェアラブルデバイスに単一のプロセッサが設置され、プロセッサにおけるオペレーティングシステムを実行することにより、デバイスの稼働中に生じる全てのシステムイベントを処理するため、当該プロセッサは、高いデータ処理能力を備え、デバイスの稼働中に動作状態が維持される必要がある。しかしながら、日常的な使用中に、ウェアラブルデバイスは、多数の場合では、処理性能への要求が低い機能のみを実現すればいい。例えば、スマートウォッチ又はスマートブレスレットは、多数の場合では、時刻表示やメッセージプロンプトを行えばいい。従って、プロセッサが動作状態を長時間維持することは、ウェアラブルデバイスの性能を向上させることなく、デバイスの消費電力を増加させて、ウェアラブルデバイスの連続使用時間が短くなってしまう。

【0015】

ウェアラブルデバイスの性能を確保するとともに、ウェアラブルデバイスの消費電力を低減するために、１つの可能な実施形態において、ウェアラブルデバイスに、少なくとも、処理性能と消費電力とが異なる第一プロセッサ及び第二プロセッサを設置し、第一プロセッサは第一システムを実行し、第二プロセッサは第二システムを実行し（即ち、デュアルコア・デュアルシステムであり）、且つデュアルコア・デュアルシステムのためにシステム切り替えメカニズムが設計されている。

【0016】

ウェアラブルデバイスの稼働中に、消費電力が低いプロセッサで第一システムを実行することによって、処理性能への要求が低いイベントを処理し、また、消費電力が高いプロセッサはスリープ状態に維持される（それに応じて、消費電力が高いプロセッサで実行される第二システムはスリープ状態にある）。ウェアラブルデバイスの基本的な機能を実現するとともに、ウェアラブルデバイスの消費電力を低減することができる。処理性能への要求が高いイベントが出る場合（例えば、アプリケーションプログラムの起動時）、消費電力が高いプロセッサをウェイクアップし、第二システムに切り替えてイベントを処理することで、トリガーされたイベントがリアルタイムに応答され処理されることを確保し、ウェアラブルデバイスの性能要件を満たす。

【0017】

また、消費電力が高いプロセッサがスリープ状態からウェイクアップ状態に切り替えられるのに一定時間かかる（少なくとも２００ｍｓ～３００ｍｓかかる）必要がある。そこで、アプリケーション起動中におけるアプリケーション画面の表示遅延を低減するために、本出願では、起動効果（ｓｔａｒｔ－ｕｐ ｅｆｆｅｃｔ）事前表示のメカニズムが導入されている。消費電力が高いプロセッサがウェイクアップされる前に、消費電力が低いプロセッサで実行される第一システムによってアプリケーションインターフェースを描画し表示する。消費電力が高いプロセッサがウェイクアップされた後、消費電力が高いプロセッサで実行される第二システムによってアプリケーションインターフェースを表示し、アプリケーションを実行し、アプリケーション起動効果を事前表示する。それによって、アプリケーションの起動速度を視覚的に向上させ、システム切り替え中のアプリケーション画面の表示遅延を低減する。

【0018】

本出願の実施形態において、第一プロセッサ及び第二プロセッサが非同期的に動作し、第一システム及び第二システムはシステム通信（又はデュアルコア通信とも呼ばれる）を実現する必要がある。１つの可能な応用シナリオにおいて、第一システムは、マイクロコントロールユニット（Ｍｉｃｒｏ Ｃｏｎｔｒｏｌｌｅｒ Ｕｎｉｔ、ＭＣＵ）で実行されるリアルタイムオペレーティングシステム（Ｒｅａｌ Ｔｉｍｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ、 ＲＴＯＳ）であり、第二システムは、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）で実行されるアンドロイド（Ａｎｄｒｏｉｄ）オペレーティングシステムである。

【0019】

図１に示されるように、本出願の１つの例示的な実施形態に係るアンドロイドオペレーティングシステムのデュアルコア通信ソフトウェアフレームワークが示されている。当該デュアルコア通信ソフトウェアフレームワークは、「低結合、高信頼、高多重」の設計原則に則り、カーネル（Ｋｅｒｎｅｌ）モジュール、ハードウェア抽象化層インターフェース定義言語（Ｈａｒｄｗａｒｅ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ（ＨＡＬ）ｉｎｔｅｒｆａｃｅ ｄｅｆｉｎｉｔｉｏｎ ｌａｎｇｕａｇｅ、ＨＩＤＬ）モジュール、ネイティブサービス（Ｎａｔｉｖｅ Ｓｅｒｖｉｃｅ）モジュール、フレームワークサービス（Ｆｒａｍｅｗｏｒｋ Ｓｅｒｖｉｃｅ）モジュール、フレームワーク・アプリケーション・プログラミング・インタフェース（Ｆｒａｍｅｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ、ＦｒａｍｅｗｏｒｋＡＰＩ）モジュール、及びアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、ＡＰＰ）モジュールの開発を含む。

【0020】

ＡＰＰモジュールは、デスクトップランチャー（Ｌａｕｎｃｈｅｒ）、設定（Ｓｅｔｔｉｎｇ）及びシステムユーザーインターフェース（Ｓｙｓｔｅｍ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ、ＳｙｓｔｅｍＵＩ）等の機能モジュールを含む。ＦｒａｍｅｗｏｒｋＡＰＩモジュールは、マイクロコントローラユニット管理（ＭＣＵ Ｍａｎａｇｅｒ）、センサー管理（Ｓｅｎｓｏｒ Ｍａｎａｇｅｒ）、位置管理（Ｌｏｃａｔｉｏｎ Ｍａｎａｇｅｒ）等の管理モジュールを含む。フレームワークサービスモジュールは、ＭＣＵ管理サービス（ＭＣＵ Ｍａｎａｇｅｒ Ｓｅｒｖｉｃｅ）、システムセンサー管理（Ｓｙｓｔｅｍ Ｓｅｎｓｏｒ Ｍａｎａｇｅｒ）、位置管理サービス（Ｌｏｃａｔｉｏｎ Ｍａｎａｇｅｒ Ｓｅｒｖｉｃｅ）等のサービスモジュールを含む。ネイティブサービスモジュールは、データ呼制御サービス（ｄａｔａ ｃａｌｌ ｃｏｎｔｒｏｌ（ｄｃｃ） ｓｅｒｖｉｃｅ）、センサーサービス（Ｓｅｎｓｏｒ ｓｅｒｖｉｃｅ）等のサービスモジュールを含む。ＨＩＤＬモジュールは、センサーハードウェア抽象化層（Ｓｅｎｓｏｒ ＨＡＬ）、全地球測位システムハードウェア抽象化層（ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ（ＧＰＳ） ＨＡＬ）等のモジュールを含む。カーネルモジュールは、ｄｃｃ＿ｄａｔａｈ、ｄｃｃ＿ｄａｔａ、Ｍｃｕ＿ｓｅｎｓｏｒ、Ｍｃｕ＿ｇｐｓ、Ｍｃｕ＿ｆａｃｔｏｒｙ等のＤＣＣ伝送駆動（ＤＣＣ Ｔｒａｎｓｆｅｒ Ｄｒｉｖｅｒ）を含む。

【0021】

伝送層は、デュアルコア通信ソフトウェアフレームワークにおいて、上下層を接続するインターフェース層として、システムの下層（データリンク層）での通信の伝送ディテールをアプリケーション層から遮蔽し、応用シナリオにサービスチャネルを提供する。アプリケーション層は、サービスの提供主体として、人間とマンマシンとのインタラクションに応答して、人間とマンマシンとのインタラクション中に生じたデータを伝送層を介して伝送し、外部のデータ請求に応答する。

【0022】

ＲＴＯＳは、対等の原則を利用して設計される。ウェアラブルデバイスがスマートウォッチであることを例として、図２に示されるように、本出願の１つの例示的な実施形態に係るＲＴＯＳのデュアルコア通信ソフトウェアフレームワークが示されている。

【0023】

ＲＴＯＳのデュアルコア通信ソフトウェアフレームワークは、アプリケーション層（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）、サービス層（Ｓｅｒｖｉｃｅ Ｌａｙｅｒ）、フレームワーク層（Ｆｒａｍｅｗｏｒｋ Ｌａｙｅｒ）、ハードウェア抽象化層（ＨＡＬ）、及びプラットフォーム層（Ｐｌａｔｆｏｒｍ Ｌａｙｅｒ）に分けられる。

【0024】

アプリケーション層は、ウォッチフェイス（ｗａｔｃｈ ｆａｃｅ）、日常追跡（Ｄａｉｌｙ Ｔｒａｃｋｅｒ）、メッセージセンター（Ｍｅｓｓａｇｅ ｃｅｎｔｅｒ）、音声アプリケーション（Ｖｏｉｃｅ ａｒｏｕｎｄ Ａｐｐｓ）、健康アプリケーション（Ｈｅａｌｔｈ Ａｐｐｓ）、設定（Ｓｅｔｔｉｎｇｓ）等のアプリケーションモジュールを含む。サービス層は、運動・健康タスク（Ｓｐｏｒｔ＆ｈｅａｌｔｈ ｔａｓｋ）、システム管理タスク（Ｓｙｓｔｅｍ ｍａｎａｇｅｒ ｔａｓｋ）、アクティビティー管理サービス（Ａｃｔｉｖｉｔｙ Ｍａｎａｇｅｒ Ｓｅｒｖｉｃｅ、ＡＭＳ）、オーディオサービス（Ａｕｄｉｏ Ｓｅｒｖｉｃｅ）、ログサービス（Ｌｏｇ Ｓｅｒｖｉｃｅ）、Ｏｄｅｔｔｅファイル転送プロトコルサービス（Ｏｄｅｔｔｅ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＯＦＴＰ） Ｓｅｒｖｉｃｅ）、ブルートゥースサービス（Ｂｌｕｅｔｏｏｔｈ（ＢＴ） Ｓｅｒｖｉｃｅ）、委任サービス（Ｄｅｌｅｇａｔｅ Ｓｅｒｖｉｃｅ）、リモート・プロシージャ・コール・サービス（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ（ＲＰＣ） Ｓｅｒｖｉｃｅ）、センサーサービス（ｓｅｎｓｏｒ Ｓｅｒｖｉｃｅ）、ストレージサービス（ｓｔｏｒａｇｅ Ｓｅｒｖｉｃｅ）等のサービスモジュールを含む。フレームワーク層は、メッセージパブ（Ｍｅｓｓａｇｅ Ｐｕｂ）、ユーザインターフェースフレームワーク（ＵＩ Ｆｒａｍｅｗｏｒｋ）、Ｇ２Ｄエンジン（ｇｒａｐｈｉｃｓ ２Ｄ （Ｇ２Ｄ） Ｅｎｇｉｎｅ）、オーディオミドルウェア（Ａｕｄｉｏ Ｍｉｄｄｌｅｗａｒｅ）、プリファレンス（Ｐｒｅｆｅｒｅｎｃｅ）、ファイルシステム（Ｆｉｌｅ ｓｙｓｔｅｍ）、アルゴリズム（Ａｌｇｏｒｉｔｈｍｓ）、Ａｉｏｓ（ａｄｖａｎｃｅｄ ｉｎｐｕｔ ｏｕｔｐｕｔ ｓｙｓｔｅｍ）、ＡｓｙｃＥｖｅｎｔ等のフレームワークモジュールを含む。ＨＡＬ、スクリーン／タッチパネル（Ｓｃｒｅｅｎ／ｔｏｕｃｈ ｐａｎｅｌ（ＴＰ））、オーディオ（Ａｕｄｉｏ）、全地球測位システム（ＧＰＳ）、センサー（ｓｅｎｓｏｒｓ）、キーパッド（Ｋｅｙｐａｄ）、モーター（Ｍｏｔｏｒ）等のハードウェア抽象化モジュールを含む。プラットフォーム層は、ボードサポートパッケージ（Ｂｏａｒｄ Ｓｕｐｐｏｒｔ Ｐａｃｋａｇｅ、ＢＳＰ）、低レベル駆動（ＬＯＷ ｌｅｖｅｌ Ｄｒｉｖｅｒ）を含む。ＢＳＰは、スクリーン／タッチパネル、キー（Ｋｅｙｓ）、ＧＰＳ、コーデック（Ｃｏｄｅｃ）、センサー、フラッシュ（Ｆｌａｓｈ）、モーター、擬似スタティックランダムアクセスメモリ（Ｐｓｅｕｄｏ ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＰＳＲＡＭ）等を含む。低レベル駆動は、汎用非同期レシーバ／トランスミッタ（Ｕｎｉｖｅｒｓａｌ Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｃｅｉｖｅｒ／Ｔｒａｎｓｍｉｔｔｅｒ、Ｕａｒｔ）、アナログ－ディジタルコンバータ（ａｎａｌｏｇ－ｔｏ－ｄｉｇｉｔａｌ ｃｏｎｖｅｒｔｅｒ、ＡＤＣ）、汎用入出力（ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｉｎｐｕｔ Ｏｕｔｐｕｔ、ＧＰＩＯ）、シリアルペリフェラルインタフェース（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ、ＳＰＩ）、集積回路（Ｉｎｔｅｒ－Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、Ｉ２Ｃ）、入出力システム（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ、ＩＯＳ）、パルス符号変調（Ｐｕｌｓｅ Ｃｏｄｅ Ｍｏｄｕｌａｔｉｏｎ、ＰＣＭ）、ＩＣ間サウンド（Ｉｎｔｅｒ－ＩＣ ＳｏｕｎｄＩ２Ｓ）、ハードウェアタイマ（ｈａｒｄｗａｒｅ ｔｉｍｅｒ、ＨＷＴｉｍｅｒ）を含む。

【0025】

なお、上記デュアルコア通信ソフトウェアフレームワークを例示のみとして説明した。当業者は実際のニーズに応じて、上記フレームワークを追加、削除又は補正することも可能であり、本出願の実施形態ではデュアルコア通信ソフトウェアフレームワークの具体的構造を限定しない。

【0026】

図３を参照すると、図３は、本出願の１つの例示的な実施形態に係るアプリケーションインターフェースの表示方法を示すフローチャートである。本実施形態では、当該方法は第一システム及び第二システムの実行をサポートするウェアラブルデバイスに適用されることを例として説明される。当該方法は、以下のステップを含むことができる。

【0027】

ステップ３０１：第一システムがウェイクアップ状態にあり、且つ第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、第一システムによって目標アプリケーションのインターフェースを描画し表示する。

【0028】

１つの可能な実施形態において、ウェアラブルデバイスは、第一プロセッサ及び第二プロセッサを備える。第一プロセッサの処理性能は第二プロセッサの処理性能より低く（第一プロセッサの処理能力及び処理速度はいずれも第二プロセッサより低く）、且つ、第一プロセッサの消費電力は第二プロセッサの消費電力より小さい。それに応じて、（第二プロセッサによって実行される）第二システムは（第一プロセッサによって実行される）第一システムにより処理されるイベントを処理することができるが、第一システムは、第二システムにより処理されるイベントを処理することができるとは限らない。

【0029】

他の可能な実施形態において、ウェアラブルデバイスは、単一のプロセッサを備えることもできる。第一システム及び第二システムはそれぞれプロセッサの異なるコアで実行される。第二システムを実行するコアの処理性能は第一システムを実行するコアの処理性能より高い。

【0030】

例えば、ウェアラブルデバイスがスマートウォッチであることを例として、第一プロセッサはＭＣＵであり、第二プロセッサはＣＰＵであり、第一システムはＲＴＯＳであり、第二システムはアンドロイドシステムである。それに応じて、第一システムにより処理可能なイベントは、ウォッチフェイス表示、ウォッチフェイス・インターフェース切り替え、通知・メッセージの表示など、処理性能への要求が低いシナリオやインタラクションが弱いシナリオを含む。第二システムにより処理可能なイベントは、着信、アプリケーションの起動、ウォッチフェイス編集、機能設定など、処理性能への要求が高いシナリオやインタラクションが強いシナリオを含む。

【0031】

１つの可能な実施形態において、ウェアラブルデバイスの動作モードは、性能モード、混合モード、及び低消費電力モードを含む。性能モードでは、第二プロセッサ及び第一プロセッサはいずれもウェイクアップ状態を維持する（それに応じて、第一システム及び第二システムはいずれもウェイクアップ状態にある）。低消費電力モードでは、第一プロセッサのみがウェイクアップ状態を維持し、第二プロセッサはオフ状態にある（即ち、第一システムがウェイクアップ状態にあり、第二システムはオフ状態にある）。混合モードでは、第一システムによってイベントを処理するとき、第二プロセッサは待機状態にあり、スリープ状態とウェイクアップ状態との間で切り替え可能である（即ち、第一システムがウェイクアップ状態にあるとき、第二システムがウェイクアップ状態にあってもよく、スリープ状態にあってもよい）。

【0032】

選択的に、ウェイクアップ状態では、システム関連データは、いつでも実行されるようにランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）などのメモリにキャッシュされている。スリープ状態では、プロセッサの大部のハードウェアモジュールがオフされ、システム関連データは読み取り専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）などのハードディスクに記憶されている。スリープ状態からウェイクアップ状態に切り替えられたとき、システム関連データはハードディスクからメモリに書き込まれる。

【0033】

ウェアラブルデバイスは、スマートフォンのような強いインタラクション属性を有する電子機器と異なり、補助的な電子デバイスとして、ほとんどの使用シナリオでは、ユーザとの間で弱いインタラクションのみが存在する。例えば、大部のシナリオでは、ユーザは腕を上げてスマートウォッチによって時間やメッセージプロンプトをチェックする。従って、ウェアラブルデバイスは、第一システムによってイベントを処理する際に、第二プロセッサがスリープ状態にある（第二システムがスリープ状態にある）ように制御することで、ウェアラブルデバイス全体の消費電力を低減することができる。

【0034】

第一システムがウェイクアップ状態にあり、且つ第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示を受信すると、目標アプリケーションを起動して実行する必要があることを示す。第一システムが目標アプリケーションを実行する能力を持たないため、スリープ状態にある第二システムをウェイクアップする必要があり、第二システムによって目標アプリケーションを起動して実行する。

【0035】

しかし、第二システムのウェイクアッププロセスは一定時間を要する（少なくとも２００ｍｓ～３００ｍｓ要する）ため、目標アプリケーションの起動をトリガーしてからしばらく応答がないという現象が発生し（具体的に、アプリケーション画面が現れるまでに時間を待つ必要があり）、利用体験に影響する。本出願の実施形態では、システム切り替え中のアプリケーション画面の表示遅延を低減するために、ウェアラブルデバイスは、第一システムの実行中に目標アプリケーションのアプリケーション起動指示を受信すると、まず、第一システムによって目標アプリケーションのインターフェースを描画し表示する（第一システムによって目標アプリケーションを起動又は実行するのではなく、グラフィックインターフェースの描画のみを担当する）。

【0036】

選択的に、当該アプリケーション起動指示は、ショートカットキー（例えば物理キー）によってトリガーされ、又は、第一システムのウィジェット（ｗｉｄｇｅｔ）によってトリガーされる。目標アプリケーションは健康モニタリングアプリケーション、即時通信アプリケーション、計時アプリケーション、アラームアプリケーション、スポーツアプリケーション等であってよい。当該目標アプリケーションのインターフェースは、静止画（例えば、アプリケーションインターフェースのファーストフレーム（ｆｉｒｓｔ ｆｒａｍｅ））であってもよく、動画（例えば、アプリケーション起動プロセスの起動動画）であってもよい。本出願の実施形態では、アプリケーション起動指示のトリガー方式、目標アプリケーションのタイプ、及びインターフェースのタイプが限定されない。

【0037】

第一システムはウェイクアップ状態にあるため、アプリケーション起動指示を受信した直後に、インターフェースを描画し表示することができ、即ち、目標アプリケーションの起動がトリガーされた直後に、目標アプリケーションのインターフェースを表示することができる。それによって、アプリケーションの起動速度を視覚的に向上させる。

【0038】

例示的に、図４に示されるように、ウェアラブルデバイスがスマートウォッチであることを例として、スマートウォッチには、（第一プロセッサによって実行される）ＲＴＯＳと、（第二プロセッサによって実行される）アンドロイドシステムとが設置されている。第一プロセッサがウェイクアップ状態にあり、第二プロセッサがスリープ状態にある場合、スマートウォッチは、ＲＴＯＳによってウォッチフェイス４１を表示し、アンドロイドシステムがスリープ状態にあるようにして、低消費電力を保つ。ユーザは、スポーツアプリケーションを介してスポーツデータをチェックする必要がある場合、物理キーをダブルクリックすることにより、スポーツアプリケーションを速やかに起動することができる。スポーツアプリケーションの起動指示を受信すると、ＲＴＯＳは、スポーツアプリケーションのアプリケーションインターフェース４２を描画し表示する。

【0039】

ステップ３０２：第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、第二システムによって目標アプリケーションのインターフェースを描画する。

【0040】

１つの可能な実施形態では、第一システムによるインターフェースの描画・表示中に、同期的に第二システムをウェイクアップし、即ち、第二プロセッサがスリープ状態からウェイクアップ状態に切り替えられる。第二システムがウェイクアップ状態に切り替えられた後、第二システムによって目標アプリケーションを起動して実行する。目標アプリケーションの起動中に、第二システムは、同様に目標アプリケーションのインターフェースを描画する必要もある。

【0041】

選択的に、第二システムにより描画される目標アプリケーションのインターフェースと、第一システムにより描画される目標アプリケーションのインターフェースとが同じである。例えば、第二システム及び第一システムはいずれも、目標アプリケーションの起動後、アプリケーションインターフェースのファーストフレームを描画する。又は、第二システムにより描画される目標アプリケーションのインターフェースと、第一システムにより描画される目標アプリケーションのインターフェースとが異なる。例えば、第一システムにより描画されるインターフェースはアプリケーション起動中の遷移動画（ｔｒａｎｓｉｔｉｏｎ ａｎｉｍａｔｉｏｎ）であり、第二システムにより描画されるインターフェースは、遷移動画の再生完了後のアプリケーションインターフェースのファーストフレームである。当然ながら、第一システム及び第二システムは、目標アプリケーションに属する他のインターフェースを描画することも可能であり、本実施形態では、第一システムにより描画される具体的なインターフェース、及び第二システムにより描画される具体的なインターフェースが限定されない。

【0042】

選択的に、第一プロセッサは、第二プロセッサに割り込み（ｉｎｔｅｒｒｕｐｔ）を送信することで第二プロセッサをウェイクアップする。

【0043】

ステップ３０３：第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行する。

【0044】

第二システムによるインターフェースの描画の完了後、ウェアラブルデバイスに実行されるシステムは第一システムから第二システムに切り替えられ、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ、引き続き目標アプリケーションを実行する。

【0045】

選択的に、第二システムに切り替えられた後、第一システムは引き続きウェイクアップ状態（消費電力が低く、連続使用時間への影響が小さい）のままにあってもよく、第一システムはスリープ状態に切り替えられてもよく、本実施形態ではそれについて限定されない。

【0046】

例示的に、図４に示されるように、ＲＴＯＳによるアプリケーションインターフェース４２の表示中に、アンドロイドシステムはスリープ状態からウェイクアップ状態に切り替えられる。アンドロイドシステムをウェイクアップした後（例えば２００ｍｓ経過した後）、スマートウォッチに実行されるシステムはＲＴＯＳからアンドロイドシステムに切り替えられ、アンドロイドシステムによってアプリケーションインターフェース４２を表示し、スポーツアプリケーションを実行する。

【0047】

選択的に、第二システムがイベント処理を完了した後（例えば、目標アプリケーションを終了しウォッチフェイスに戻り）、第二プロセッサは再びスリープ状態に切り替えられ、第一システムに切り替えて、第一システムによってイベントを処理する。それによって、ウェアラブルデバイスは、少ないシナリオでは、高性能（ただし、高消費電力）を維持し、多くのシナリオでは、低消費電力（ただし、低性能）を維持し、ウェアラブルデバイスの消費電力をさらに低減し、ウェアラブルデバイスの連続使用時間を延ばす。

【0048】

上述したように、本出願の実施形態において、デュアルシステムをサポートするウェアラブルデバイスでは、第一システムが稼働状態にあり、第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示を受信すると、まず、第一システムによって目標アプリケーションのインターフェースを描画し表示し、また、第二システムをウェイクアップした後、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行する。本出願の実施形態に係る提案によれば、第一システムによってアプリケーションの起動効果を事前表示することで、アプリケーションの起動速度を視覚的に向上させることが可能となり、システム切り替え中のアプリケーション画面の表示遅延を低減する。

【0049】

選択的に、第一システムによって目標アプリケーションのインターフェースを描画し表示することは、
第一システムによって、第一システムに対応する記憶空間である第一記憶空間から目標アプリケーションに対応する目標インターフェースリソースを取得することと、
目標インターフェースリソースに基づいて、第一システムによって目標アプリケーションのインターフェースを描画し表示することと、を含む。

【0050】

選択的に、第一システムによって、第一記憶空間から目標アプリケーションに対応する目標インターフェースリソースを取得することは、
第一システムによって、目標アプリケーションに対応する目標アプリケーション情報を取得することと、
目標アプリケーション情報に基づいて、第一システムによって第一記憶空間から目標インターフェースリソースを取得することと、を含む。

【0051】

選択的に、上記方法は、
第二システムがウェイクアップ状態にある場合、第二システムによって第一システムにインターフェースリソース更新メッセージを送信することと、
インターフェースリソース更新メッセージに基づいて、第一システムによって第一記憶空間に記憶されたインターフェースリソースを更新することと、をさらに含む。

【0052】

選択的に、第二システムがウェイクアップ状態にある場合、第二システムによって第一システムにインターフェースリソース更新メッセージを送信することは、以下の内容を含む。
第二システムがウェイクアップ状態にある場合、言語更新ブロードキャストが受信されたことに応答して、第二システムによって第一アプリケーションの第一アプリケーション情報を取得する。第一アプリケーションに対応する第一インターフェースリソースが第一記憶空間に記憶されている。第二システムによって第一システムに、第一アプリケーション情報と更新された第一インターフェースリソースとを含む第一インターフェースリソース更新メッセージを送信する。
インターフェースリソース更新メッセージに基づいて、第一システムによって第一記憶空間に記憶されたインターフェースリソースを更新することは、
第一システムによって、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて第一記憶空間に記憶すること、を含む。

【0053】

選択的に、第二システムによって第一アプリケーションの第一アプリケーション情報を取得することは、
第二システムによって第一システムにクエリメッセージを送信することと、
第一システムによって、第二システムに第一アプリケーションの第一アプリケーション情報を送信し、且つ、第一記憶空間から第一アプリケーションに対応する第一インターフェースリソースを削除することと、を含む。

【0054】

選択的に、第二システムによって第一アプリケーションの第一アプリケーション情報を取得することは、
第二システムによって、第二システムに対応する記憶空間である第二記憶空間から第一アプリケーションの第一アプリケーション情報を取得すること、を含む。
第一システムによって、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて第一記憶空間に記憶することは、
第一インターフェースリソース更新メッセージに強制更新識別子が含まれていることが識別されたことに応答して、第一システムによって、第一記憶空間に記憶されたインターフェースリソースを削除し、且つ、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて第一記憶空間に記憶すること、を含む。

【0055】

選択的に、第二システムがウェイクアップ状態にある場合、第二システムによって第一システムにインターフェースリソース更新メッセージを送信することは、以下の内容を含む。
第二システムがウェイクアップ状態にある場合、第二アプリケーションの起動形態更新メッセージがモニタリングされたことに応答して、第二システムによって第二アプリケーションの第二アプリケーション情報及び第二インターフェースリソースを取得する。起動形態更新メッセージは第二アプリケーションの起動形態の変化を表すために用いられる。第二システムによって第一システムに、更新形態と、第二アプリケーション情報と、第二インターフェースリソースとを含む第二インターフェースリソース更新メッセージを送信する。
インターフェースリソース更新メッセージに基づいて、第一システムによって第一記憶空間に記憶されたインターフェースリソースを更新することは、
更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新すること、を含む。

【0056】

選択的に、更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新することは、
更新形態が追加であることに応答して、第一システムによって、第二アプリケーション情報と、第二インターフェースリソースとを関連付けて第一記憶空間に記憶することと、
更新形態が削除であることに応答して、第一システムによって、第一記憶空間から第二アプリケーション情報及び第二インターフェースリソースを削除することと、を含む。

【0057】

選択的に、上記方法は、
更新形態が追加であり、且つ第一記憶空間に第二アプリケーション情報が記憶されていることに応答して、更新衝突が存在すると特定することと、
更新形態が削除であり、且つ第一記憶空間に第二アプリケーション情報が記憶されており、且つ削除待ちの起動形態以外の起動形態によって第二アプリケーション情報が利用されることに応答して、更新衝突が存在すると特定することと、をさらに含み、
更新衝突が存在する場合、第一記憶空間における第二インターフェースリソースが更新されない。

【0058】

選択的に、更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新することは、
第二インターフェースリソース更新メッセージに強制更新識別子が含まれておらず、且つ、更新衝突が存在しないことが識別されたことに応答して、更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新すること、を含む。
上記方法は、
第二インターフェースリソース更新メッセージに強制更新識別子が含まれていることが識別されたことに応答して、更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新すること、をさらに含む。

【0059】

選択的に、第一記憶空間は、第一システムで起動されることがサポートされるアプリケーションに対応するインターフェースリソースを記憶するために用いられ、
第一システムでアプリケーションを起動する形態は、ショートカットキーによる起動、及び第一システムのウィジェットによる起動のうちの少なくとも１つを含む。

【0060】

選択的に、第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行することは、
第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって第一システムに、第一システムにグラフィカルユーザインターフェース（ＧＵＩ）の表示権限を移行させるように指示するための切り替え指示を送信することと、
第二システムがＧＵＩの表示権限を取得したことに応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行することと、を含む。

【0061】

選択的に、ウェアラブルデバイスは、第一プロセッサ及び第二プロセッサを備え、第二プロセッサの消費電力は第一プロセッサの消費電力より大きく、第一システムは、第一プロセッサによって実行されるシステムであり、第二システムは、第二プロセッサによって実行されるシステムである。

【0062】

１つの可能な実施形態では、第一システム及び第二システムはそれぞれデータ記憶空間に対応し、第一システムが簡単なイベントの処理のみを担当し、第二システムが複雑なイベントを処理する必要があるため、第二システムに対応する記憶空間は第一システムに対応する記憶空間よりはるかに大きい。第一システムによるインターフェースの描画及び表示を実現するために、第一システムに対応する記憶空間にアプリケーションに対応するインターフェースリソースが記憶される。アプリケーション起動指示を受信すると、第一システムは、記憶空間におけるインターフェースリソースに基づいてアプリケーションインターフェースを描画する。以下、例示的な実施形態を利用して説明する。

【0063】

図５を参照すると、図５は、本出願の別の例示的な実施形態に係るアプリケーションインターフェースの表示方法を示すフローチャートである。本実施形態では、当該方法はウェアラブルデバイスに適用されることを例として説明される。当該方法は、以下のステップを含むことができる。

【0064】

ステップ５０１：第一システムがウェイクアップ状態にあり、且つ第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、第一システムによって、第一システムに対応する記憶空間である第一記憶空間から目標アプリケーションに対応する目標インターフェースリソースを取得する。

【0065】

本出願の実施形態では、第一システムは第一記憶空間に対応し、第一記憶空間には、少なくとも１つのアプリケーションに対応するインターフェースリソースが記憶されている。当該インターフェースリソースは、アプリケーションインターフェースの描画に必要なリソースを指し、インターフェースリソースは、文字リソース、画像リソース、動画リソース、特殊効果リソース（ｓｐｅｃｉａｌ－ｅｆｆｅｃｔ ｒｅｓｏｕｒｃｅ）、インターフェース・レイアウト・リソース（ｉｎｔｅｒｆａｃｅ－ｌａｙｏｕｔ ｒｅｓｏｕｒｃｅ）等を含むことができ、本実施形態では、インターフェースリソースに含まれる具体的な内容が限定されない。

【0066】

１つの可能な実施形態において、第一記憶空間には、第二システムにおける各アプリケーションに対応するインターフェースリソースが記憶される。例えば、第二システムに、スポーツアプリケーション、健康モニタリングアプリケーション、アラームアプリケーション、即時通信アプリケーションがインストールされている場合、第一記憶空間には、その４つのアプリケーションのそれぞれに対応するインターフェースリソースが記憶されている。

【0067】

第一記憶空間の容量が限られているため、第二システムにおける全てのアプリケーションがいずれも第一システムにより起動されることがサポートされるというわけではない（即ち、目標アプリケーションは第一システムで起動されることがサポートされるアプリケーションである）。従って、もう１つの可能な実施形態において、第一記憶空間は、第一システムで起動されることがサポートされるアプリケーションに対応するインターフェースリソースを記憶するために用いられる。それによって、シームレスなシステム切り替えを実現しながら、インターフェースリソースにより占用される記憶空間を低減する。

【0068】

選択的に、第一システムで起動されることがサポートされるアプリケーションとは、第二システムがスリープ状態にある場合に起動可能なアプリケーションである。例えば、第一システムにアプリケーションの起動エントリ（ｓｔａｒｔ－ｕｐ ｅｎｔｒｙ）が設定されている場合、当該アプリケーションは、第一システムで起動されることがサポートされるアプリケーションに属し、及び／又は、アプリケーションがショートカットキーにより起動可能に設定されている場合、当該アプリケーションは、第一システムで起動されることがサポートされるアプリケーションに属する。

【0069】

いくつかの実施形態において、第一システムでアプリケーションを起動する形態は、ショートカットキーによる起動、及び第一システムのウィジェットによる起動のうちの少なくとも１つを含む。

【0070】

ショートカットキーを介して第一システムでアプリケーションを起動する形態は、ユーザ自らによって設定されることができ、例えば、物理キーのダブルクリックによる特定のアプリケーションの起動、又は物理キーの長押しによる特定のアプリケーションの起動が設定される。ウィジェットは、ユーザ自らにより第一システムに追加されることができ、例えば、ユーザが第一システムに表示されているウィジェットをクリックすることにより健康モニタアプリケーションを起動することができるように、ウォッチフェイスに健康モニタアプリケーションに対応するウィジェットが追加される。

【0071】

例えば、第二システムに、スポーツアプリケーション、健康モニタリングアプリケーション、アラームアプリケーション、及び即時通信アプリケーションがインストールされている場合、スポーツアプリケーションは物理キーのダブルクリックによる起動をサポートし、且つ、健康モニタリングアプリケーションはウォッチフェイスにおけるウィジェットによるトリガーをサポートするため、第一記憶空間には、スポーツアプリケーションに対応するインターフェースリソース及び健康モニタリングアプリケーションに対応するインターフェースリソースのみが記憶され、アラームアプリケーションに対応するインターフェースリソース及び即時通信アプリケーションに対応するインターフェースリソースが記憶される必要はない。

【0072】

目標アプリケーションに対応する目標インターフェースリソースの取得の具体的な形態について、１つの可能な実施形態において、アプリケーション情報と、インターフェースリソースとが関連付けられて第一記憶空間に記憶され、即ち、アプリケーション情報とインターフェースリソースとの間のマッピング関係が記憶される。

【0073】

選択的に、当該アプリケーション情報は、アプリケーション・パッケージ名（ｐａｃｋａｇｅ ｎａｍｅ）及びアプリケーション・アクティビティ名（ａｃｔｉｖｉｔｙ ｎａｍｅ）のうちの少なくとも１つを含む。アプリケーションは単一の機能インターフェースのみを有する場合、当該アプリケーション情報は、アプリケーション・パッケージ名を含む。アプリケーションは複数の機能インターフェースを有し、且つ、特定の機能インターフェースが第一システムで起動され表示されることができる場合、当該アプリケーション情報は、アプリケーション・パッケージ名、及び（特定の機能インターフェースに対応する）アプリケーション・アクティビティ名を含む。

【0074】

目標アプリケーションのアプリケーション起動指示を受信すると、第一システムによって目標アプリケーションに対応する目標アプリケーション情報を取得し、目標アプリケーション情報に基づいて、第一システムによって、第一記憶空間から目標インターフェースリソースを取得する。目標アプリケーション情報は、目標アプリケーション・パッケージ名及び目標アプリケーション・アクティビティ名のうちの少なくとも１つを含む。

【0075】

いくつかの実施形態において、第一システムは、目標アプリケーション情報に基づいて、目標アプリケーション情報にマッチングするインターフェースリソースを第一記憶空間から検索し、検索されたインターフェースリソースを、目標アプリケーションに対応する目標インターフェースリソースとして特定する。

【0076】

例示的な一例において、第一記憶空間における、アプリケーション情報とインターフェースリソースとの間のマッピング関係は、表１に示される通りである。

【0077】

【表1】

【0078】

目標アプリケーションのアプリケーション・パッケージ名をｓｐｏｒｔ＿ａｐｐとして取得した場合、第一システムは、第一記憶空間におけるインターフェースリソースファイルＡを目標インターフェースリソースとして特定する。目標アプリケーションのアプリケーション・パッケージ名をｈｅａｌｔｈ＿ａｐｐとして取得した場合、第一システムは、第一記憶空間におけるインターフェースリソースファイルＢを目標インターフェースリソースとして特定する。

【0079】

ステップ５０２：目標インターフェースリソースに基づいて、第一システムによって目標アプリケーションのインターフェースを描画し表示する。

【0080】

さらに、目標インターフェースリソースを取得すると、第一システムは直ちにインターフェースをリアルタイムに描画し表示する。

【0081】

選択的に、第一システムによるインターフェースの描画中に、目標インターフェースリソースを利用する必要がある以外に、時刻データ、センサーデータ（例えば、歩数計データ）等の他のデータを利用する必要があり、それによって、描画されるインターフェースにおけるコンテンツの正確性が確保される。

【0082】

例示的な一例において、第一システムによって取得される、スポーツアプリケーションに対応する目標インターフェースリソースに、画像リソース、文字リソース、インターフェース・レイアウト・リソースが含まれる。第一システムは、インターフェース・レイアウト・リソースによって指示されるインターフェース要素レイアウト方式に従って、画像リソース及び文字リソースを対応のインターフェース位置に描画し、現在時刻及び歩数計データをインターフェースにレンダリング（ｒｅｎｄｅｒ）して、スポーツアプリケーションのアプリケーションインターフェースを取得する。

【0083】

ステップ５０３：第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、第二システムによって目標アプリケーションのインターフェースを描画する。

【0084】

本ステップの実施形態については、ステップ３０２を参照することができ、本実施形態では省略する。

【0085】

ステップ５０４：第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって第一システムに、第一システムにグラフィカルユーザインターフェース（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ、ＧＵＩ）の表示権限を移行させるように指示するための切り替え指示を送信する。

【0086】

目標アプリケーションの正常利用を確保するために、システム切り替え中に、第一システムは、目標アプリケーションの稼働中にウェアラブルデバイスに第二システムのＧＵＩが表示されるように、ＧＵＩの表示権限を第二システムに移行する必要がある。１つの可能な実施形態において、第二システムは、インターフェース描画を完了した後、第一システムに切り替え指示を送信し、ＧＵＩの表示権限を第二システムへの移行を第一システムに指示する。

【0087】

ステップ５０５：第二システムがＧＵＩの表示権限を取得したことに応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行する。

【0088】

第二システムは、ＧＵＩの表示権限を取得した後、描画が完了した目標アプリケーションのインターフェースを表示し、目標アプリケーションを実行する。それに応じて、ウェアラブルデバイスに、目標アプリケーションのインターフェースが表示される。

【0089】

本実施形態では、アプリケーション情報及びインターフェースリソースを第一記憶空間に記憶することにより、第一システムは、アプリケーション起動指示を受信すると、目標アプリケーションの目標アプリケーション情報に基づいて、第一記憶空間から対応の目標インターフェースリソースを正確に取得することが可能となり、インターフェース描画の速度及び正確性の向上に役立つ。

【0090】

また、第一記憶空間には、第一システムで起動されることがサポートされるアプリケーションのインターフェースリソースのみが記憶され、それによって、シームレスなシステム切り替えを実現した上で、インターフェースリソースにより占用される記憶空間を低減し、第一記憶空間の容量へのニーズを低減する。

【0091】

上記実施形態では、ウェアラブルデバイスにおけるアプリケーションのインターフェースが変わらないというわけではなく、第一システムで起動されることがサポートされるアプリケーションも変化する可能性があるため、アプリケーション起動中に表示されるアプリケーションインターフェースの正確性を確保するように、第一記憶空間に記憶されるインターフェースリソースもそれに応じて更新する必要がある。１つの可能な実施形態において、第二システムがウェイクアップ状態にある場合、ウェアラブルデバイスは、第二システムによって第一システムに、（インターフェースリソース更新イベントが存在する場合に）インターフェースリソース更新メッセージを送信し、第一システムは、インターフェースリソース更新メッセージに基づいて、第一記憶空間に記憶されたインターフェースリソースを更新する。当該インターフェースリソース更新メッセージには、少なくとも更新待ちのアプリケーションのアプリケーション情報が含まれる。

【0092】

第一システムがＭＣＵによって実行されるＲＴＯＳであり、第二システムがＣＰＵによって実行されるアンドロイドシステムであることを例として、図６に示されるように、アプリケーション層（Ａｐｐｌｉｃａｔｉｏｎ）にインターフェースリソース更新イベント（言語更新、ウィジェット更新、ショートカットキー更新等のイベントを含む）が存在する場合、アプリケーション層は、更新されたインターフェースリソースを、アンドロイドシステムに対応するフレームワークリソース・アンドロイドアプリケーションパッケージ（Ａｎｄｒｏｉｄ ａｐｐｌｉｃａｔｉｏｎ Ｐａｃｋａｇｅ、ＡＰＫ）にプリセット（ｐｒｅ－ｓｅｔ）する。

【0093】

フレームワーク層内に設定されるインターフェースリソース管理制御センターは、インターフェースリソース更新イベントへのモニタリングを担当する。インターフェースリソース更新イベントがあるとをモニタリングした際に、インターフェースリソース管理制御センターは、フレームワークリソースＡＰＫからインターフェースリソースを取得し、カーネル層に設定されるデュアルコア通信モジュール（具体的に、カーネル層のＤＣＣに設定される）を介してＭＣＵと通信する。ＭＣＵは、受信されたインターフェースリソース更新データに基づいて、第一記憶空間に記憶されたインターフェースリソースを更新する。

【0094】

異なる更新シナリオに対し、第二システムと第一システムとの間のインタラクションによるインターフェースリソースの更新プロセスも異なる。システムレベルのインターフェースリソース更新イベントが存在する場合、第一システムは第一記憶空間に記憶された全てのインターフェースリソースを更新する必要がある。アプリケーションレベルのインターフェースリソース更新イベントが存在する場合、第一システムは特定のアプリケーションのインターフェースリソースのみを更新すればいい。以下、異なる更新シナリオでのインターフェースリソースの更新プロセスについて、それぞれ実施形態を利用して説明する。

【0095】

図７を参照すると、図７は、本出願の１つの例示的な実施形態に係るインターフェースリソースの更新プロセスを示すフローチヤ一トである。本実施形態では、当該方法はウェアラブルデバイスに適用されることを例として説明される。当該方法は、以下のステップを含むことができる。

【0096】

ステップ７０１：第二システムがウェイクアップ状態にある場合、言語更新ブロードキャスト（ｌａｎｇｕａｇｅ ｕｐｄａｔｅ ｂｒｏａｄｃａｓｔ）が受信されたことに応答して、第二システムによって第一アプリケーションの第一アプリケーション情報を取得する。第一アプリケーションに対応する第一インターフェースリソースが第一記憶空間に記憶されている。

【0097】

１つの可能な実施形態では、ウェアラブルデバイスのシステム言語が変更される場合、第二システムは、切り替えの後のシステム言語を含む言語更新ブロードキを受信する。例えば、ユーザが、ウェアラブルデバイスのシステム言語を中国語から英語に切り替える場合、第二システムは、英語への切り替えを指示する言語更新ブロードキを受信する。

【0098】

システム言語が変更される場合、第二システムにおける全てのアプリケーションのアプリケーション言語はいずれも変更する必要があり、それに応じて、アプリケーションインターフェースに含まれるコンテンツ（例えば、文字コンテンツ）も変化する。そのため、言語更新ブロードキを受信した後、第二システムは、全てのアプリケーションのインターフェースリソースを更新する必要があると特定し、第一記憶空間における第一アプリケーションの第一アプリケーション情報を取得する。

【0099】

第一アプリケーション情報を取得する形態について、１つの可能な実施形態では、第一記憶空間には、第一アプリケーション情報と第一インターフェースリソースとの間のマッピング関係が記憶されているため、第二システムは、第一システムによって第一アプリケーション情報を取得することができる。選択的に、本ステップは、以下のステップを含むことができる。

【0100】

一：第二システムによって第一システムにクエリメッセージを送信する。

【0101】

選択的に、第二システムは、カーネル層のデュアルコア通信モジュールを介して第一システムにクエリメッセージを送信し、第一システムに第一記憶空間に記憶された第一アプリケーション情報をクエリさせるよう請求する。それに応じて、第一システムは、クエリメッセージを受信すると、第一記憶空間から、記憶されている第一アプリケーション情報を取得する。

【0102】

例示的に、図８に示されるように、アンドロイドシステムは、ウェイクアップ状態にある場合、言語更新ブロードキ（ＡＣＴＩＯＮ＿ＬＯＣＡＬＥ＿ＣＨＡＮＧＥＤ）を受信すると、ＲＴＯＳにクエリメッセージを送信する。

【0103】

二：第一システムによって、第二システムに第一アプリケーションの第一アプリケーション情報を送信し、且つ、第一記憶空間から第一アプリケーションに対応する第一インターフェースリソースを削除する。

【0104】

選択的に、第一システムは、各第一アプリケーションの第一アプリケーション情報をクエリした後、カーネル層のデュアルコア通信モジュールを介して第二システムに、第一アプリケーション情報を含むクエリ結果を送信する。

【0105】

上記実施形態の表１に示されたデータと結びつけて、第一システムが第二システムにフィードバックするクエリ結果には、アプリケーション・パッケージ名ｓｐｏｒｔ＿ａｐｐ及びｈｅａｌｔｈ＿ａｐｐが含まれる。

【0106】

システム言語更新後、元に記憶されたインターフェースリソースが無効になるため、第一記憶空間をリリースし、後続のインターフェースリソース更新の正確性を確保するように、１つの可能な実施形態では、第一システムは、第一記憶空間から第一アプリケーションに対応する第一インターフェースリソースを削除する。

【0107】

選択的に、第二システムによって送信されるクエリメッセージには、予め設定された識別子（ｐｒｅ－ｓｅｔ ｉｄｅｎｔｉｆｉｅｒ）が含まれている。クエリメッセージに予め設定された識別子が含まれていることを識別した場合、第一システムは、システム言語の変化によるインターフェースリソース更新が必要であると特定し、第一記憶空間に記憶された第一インターフェースリソースを削除する。上記の実施形態の表１に示されたデータと結びつけて、第一システムは、第一記憶空間に記憶されたインターフェースリソースファイルＡ及びインターフェースリソースファイルＢを削除する。

【0108】

例示的に、図８に示されるように、ＲＴＯＳは、アンドロイドシステムにクエリ結果をフィードバックすると同時に、第一記憶空間に記憶された第一インターフェースリソースを削除する。

【0109】

ステップ７０２：第二システムによって第一システムに、第一アプリケーション情報と更新された第一インターフェースリソースとを含む第一インターフェースリソース更新メッセージを送信する。

【0110】

１つの可能な実施形態において、第二システムは、第一アプリケーション情報に基づいて、第二記憶空間に記憶された、第一アプリケーションに対応する更新された第一インターフェースリソースを取得する。第二記憶空間は第二システムに対応する記憶空間であり、更新された第一インターフェースリソースは、各第一アプリケーションによって第二記憶空間に記憶される。例えば、第二システムにおけるインターフェースリソース管理制御センターは、フレームワークリソースＡＰＫから、更新された第一インターフェースリソースを取得する。

【0111】

上記ステップにおける例示と結びつけて、第二システムは、アプリケーション・パッケージ名ｓｐｏｒｔ＿ａｐｐ及びｈｅａｌｔｈ＿ａｐｐに基づいて、更新されたインターフェースリソースファイルＡ’及びインターフェースリソースファイルＢ’を取得する。

【0112】

選択的に、更新後の第一インターフェースリソースに含まれる文字リソースと、更新前の第一インターフェースリソースに含まれる文字リソースとは異なる。例えば、更新後の文字リソースは第一アプリケーションの英語バージョンであり、更新前の文字リソースが第一アプリケーションの中国語バージョンである。

【0113】

さらに、第一システムが第一記憶空間におけるインターフェースリソースを更新するように、第二システムは、デュアルコア通信モジュールを介して第一システムに第一インターフェースリソース更新メッセージを送信する。

【0114】

１つの可能な実施形態において、第一インターフェースリソース更新メッセージには、次のフィールドが含まれることができる。
１．更新パス（ｕｐｄａｔｅ ｐａｔｈ）を表すためのｐａｔｈ。本実施形態において、ｐａｔｈフィールドの値は、システム言語更新によってインターフェースリソース更新をトリガーすることを表す。
２．インターフェースリソースの更新様態を表すためのａｃｔｉｏｎ。本実施形態において、ａｃｔｉｏｎフィールドの値は、インターフェースリソースの切り替えを表す。
３．アプリケーション・パッケージ名であるｐａｃｋａｇｅｎａｍｅ。
４．更新後のインターフェースリソースであるｄａｔａ。
５．インターフェースリソースを強制的に更新するか否かを表すためのｅｘｔｒａ。本実施形態において、ｅｘｔｒａフィールドの値は、インターフェースリソースを強制的に更新することを表す。

【0115】

なお、第一インターフェースリソース更新メッセージには、他のフィールドが含まれてもよく、本実施形態では、上記フィールドを含むことを例示のみとして説明するが、それに限定されない。

【0116】

例示的に、図８に示されるように、アンドロイドシステムは、クエリ結果を受信すると、更新された第一インターフェースリソースをクエリ結果に基づいて取得し、第一インターフェースリソースに基づいてＲＴＯＳに第一インターフェースリソース更新メッセージを送信する。

【0117】

ステップ７０３：第一システムによって、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて第一記憶空間に記憶する。

【0118】

第一インターフェースリソース更新メッセージを受信すると、第一システムは、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて記憶する。後続のシステム切り替え中に、第一システムは、更新されたインターフェースリソースに基づいてアプリケーションインターフェースを描画し表示することができ、表示されるアプリケーションインターフェースによって採用される言語とシステム言語が一致することが確保される。

【0119】

上記ステップにおける例示と結びつけて、第一システムが第一インターフェースリソース更新メッセージに基づいてインターフェースリソースを更新した後、第一記憶空間におけるアプリケーション情報とインターフェースリソースとの間のマッピング関係は表２に示されている。

【0120】

【表2】

【0121】

選択的に、インターフェースリソース更新が完了した後、第一システムは第二システムに更新完了通知を送信し、インターフェースリソース更新が完了したことを第二システムに通知する。第二システムが予め設定された時間内に更新完了通知を受信しなければ、改めて第一システムに第一インターフェースリソース更新メッセージを送信する。

【0122】

例示的に、図８に示されるように、ＲＴＯＳは第一インターフェースリソースを更新した後、アンドロイドシステムに更新完了通知を送信する。

【0123】

第一システムから第一アプリケーション情報を取得する形態を採用した他、もう１つの可能な実施形態では、各アプリケーションが更新されたインターフェースリソースを第二システム（の第二記憶空間）に記憶するため、ウェアラブルデバイスは、第二システムによって、第一アプリケーションの第一アプリケーション情報を第二記憶空間から取得することもでき、第一システムに送信される第一インターフェースリソース更新メッセージに強制更新識別子（ｆｏｒｃｅｄ ｕｐｄａｔｅ ｉｄｅｎｔｉｆｉｅｒ）を設定する。

【0124】

上記に応じて、第一システムは、第一インターフェースリソース更新メッセージに強制更新識別子（例えば、第一インターフェース更新メッセージにおけるｅｘｔｒａフィールドに設定される）が含まれることを識別すると、第一記憶空間に記憶されたインターフェースリソースを削除し、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて第一記憶空間に記憶し、同一アプリケーションの２セットのインターフェースリソースを記憶しないようにする。

【0125】

本実施形態では、システム言語更新の際、第二システムによって、各第一アプリケーションの第一アプリケーション情報を取得し、更新された第一インターフェースリソースを第一アプリケーション情報に基づいて取得することにより、更新された第一インターフェースリソースを第一システムに送信する。第一システムは、第一記憶空間に記憶された第一インターフェースリソースを更新し、後続のシステム切り替えの際、第一システムに表示されるアプリケーションインターフェースの言語とシステム言語とが一致することを確保する。

【0126】

図９を参照すると、図９は、本出願の別の例示的な実施形態に係るインターフェースリソースの更新プロセスを示すフローチャートである。本実施形態では、当該方法はウェアラブルデバイスに適用されることを例として説明される。当該方法は、以下のステップを含むことができる。

【0127】

ステップ９０１：第二システムがウェイクアップ状態にある場合、第二アプリケーションの起動形態更新メッセージ（ｓｔａｒｔ－ｕｐ ｍａｎｎｅｒ ｕｐｄａｔｅ ｍｅｓｓａｇｅ）がモニタリングされたことに応答して、第二システムによって第二アプリケーションの第二アプリケーション情報及び第二インターフェースリソースを取得する。起動形態更新メッセージは第二アプリケーションの起動形態の変化を表すために用いられる。

【0128】

アプリケーションの起動効率を高めるために、ユーザは、第二システムにおけるアプリケーションが第一システムによって起動されることができるように、第二システムにおけるアプリケーションのために高速起動形態（ｑｕｉｃｋ ｓｔａｒｔ－ｕｐ ｍａｎｎｅｒ）を設定する可能性がある。高速起動形態の設定は、第一システムへのアプリケーションのウィジェットの追加と、アプリケーション起動のためのショートカットキーの設定とを含むことができる。

【0129】

上記に応じて、第二アプリケーションの起動形態が更新された（例えば、高速起動形態の追加又は高速起動形態の削除）場合、第一システムは、第一記憶空間におけるインターフェースリソースを適応的に更新する必要がある。

【0130】

１つの可能な実施形態において、第二システムにおける第二アプリケーションの起動形態が変化した場合、第二システムは、起動形態変更メッセージをモニタリングする。当該起動形態変更メッセージには、目標起動形態と目標起動形態に対応する更新形態とが含まれることができる。

【0131】

例えば、第二アプリケーションにウィジェットによる起動が設定される場合、当該目標起動形態がウィジェット起動であり、更新形態が追加である。第二アプリケーションに、ショートカットキー起動形態が削除されることが設定される場合、当該目標起動形態がショートカットキー起動であり、更新形態が削除である。

【0132】

さらに、第二システムは、第二アプリケーションに対応する第二アプリケーション情報及び第二インターフェースリソースを取得する。第二システムは、起動形態更新メッセージにおける第二アプリケーションのアプリケーション情報に基づいて、第二記憶空間から第二インターフェースリソースを取得することができる。

【0133】

選択的に、起動形態更新メッセージによって指示される更新形態が追加である場合、第二システムは、第二アプリケーション情報及び第二インターフェースリソースを取得する。起動形態更新メッセージによって指示される更新形態が削除である場合、第二システムは、第二アプリケーション情報のみを取得する。

【0134】

例示的に、図１０に示されるように、アンドロイドシステムは、第二アプリケーションの起動形態更新メッセージ（ＡＣＴＩＯＮ＿ＳＨＯＲＴＣＵＴ＿ＳＥＴＴＩＮＧ＿ＣＨＡＮＧＥＤ及びＡＣＴＩＯＮ＿ＷＩＤＧＥＴ＿ＣＨＡＮＧＥＤを含む）をモニタリングした場合、第二アプリケーションの第二インターフェースリソースを取得する。

【0135】

ステップ９０２：第二システムによって第一システムに、更新形態と、第二アプリケーション情報と、第二インターフェースリソースとを含む第二インターフェースリソース更新メッセージを送信する。

【0136】

取得された第二インターフェースリソースに基づいて、第二システムは、デュアルコア通信モジュールを介して第一システムに第二インターフェースリソース更新メッセージを送信する。当該第二インターフェースリソース更新メッセージは、第二アプリケーション情報と第二インターフェースリソースとを含む以外に、目標起動形態及び更新形態をさらに含む。

【0137】

１つの可能な実施形態において、第二インターフェースリソース更新メッセージには、次のフィールドが含まれることができる。
１．更新パスを表すためのｐａｔｈ。本実施形態において、ｐａｔｈフィールドの値は、高速起動形態の更新（ウィジェットの更新及びショートカットキーの更新を含む）によってインターフェースリソース更新をトリガーすることを表す。
２．インターフェースリソースの更新様態を表すためのａｃｔｉｏｎ。本実施形態において、ａｃｔｉｏｎフィールドの値は、インターフェースリソースの追加又はインターフェースリソースの削除を表す。
３．アプリケーション・パッケージ名であるｐａｃｋａｇｅｎａｍｅ。
４．アプリケーションの特定のアプリケーションインターフェースを指示するためのアプリケーション・アクティビティ名であるａｃｔｉｖｉｔｙｎａｍｅ。
５．更新後のインターフェースリソースであるｄａｔａ。
６．インターフェースリソースを強制的に更新するか否かを表すためのｅｘｔｒａ。

【0138】

なお、第二インターフェースリソース更新メッセージには、他のフィールドが含まれてもよく、本実施形態では、上記フィールドを含むことを例示のみとして説明するが、それに限定されない。

【0139】

例示的に、図１０に示されるように、アンドロイドシステムは、第二インターフェースリソースを取得した後、ＲＴＯＳに第二インターフェースリソース更新メッセージを送信し、ＲＴＯＳに第一記憶空間に記憶されたインターフェースリソースを更新させるように指示する。

【0140】

ステップ９０３：更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新する。

【0141】

１つの可能な実施形態において、第一システムは、取得された第二インターフェースリソース更新メッセージに基づいて、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新する。

【0142】

インターフェースリソース更新の具体的な形態について、いくつかの実施形態では、更新形態が追加である場合、ウェアラブルデバイスは、第一システムによって、第二アプリケーション情報と第二インターフェースリソースとを関連付けて第一記憶空間に記憶する。更新形態が削除である場合、ウェアラブルデバイスは、第一システムによって、第一記憶空間から第二アプリケーション情報及び第二インターフェースリソースを削除する。

【0143】

１つの可能な応用シナリオにおいて、第一記憶空間に第二アプリケーションの第二インターフェースリソースが記憶されている場合、第二インターフェースリソース更新メッセージに基づいてインターフェースリソースを直接に更新すると、更新衝突（ｕｐｄａｔｅ ｃｏｎｆｌｉｃｔ）を招く可能性がある。

【0144】

例えば、第一記憶空間に第二アプリケーションの第二インターフェースリソースが記憶されている場合、第二インターフェースリソース更新メッセージが第二アプリケーションの第二インターフェースリソースの追加（異なる高速起動形態に対応することができる）を指示すれば、第二インターフェースリソースを第一記憶空間に直接に追加することは、インターフェースリソースの重複記憶、記憶空間の無駄を招く。

【0145】

別の例では、第一記憶空間に第二アプリケーションの第二インターフェースリソースが記憶されており、且つ、第二アプリケーションが少なくとも２種の異なる高速起動形態で起動されることがサポートされる場合、第二インターフェースリソース更新メッセージが、第二アプリケーションの第二インターフェースリソースの削除（高速起動形態の１つを削除する）を指示すれば、第一記憶空間から第二インターフェースリソースを直接に削除することは、他の高速起動形態のみで第二アプリケーションを起動するようになり、第一システムがアプリケーションインターフェースを描画し表示できないということを招く。

【0146】

従って、１つの可能な実施形態では、第一システムは、第二インターフェースリソース更新メッセージを受信すると、更新形態及び第二アプリケーション情報に基づいて、更新衝突を検出する。更新衝突が存在しない場合、第一システムは、第二インターフェースリソース更新メッセージによって指示された更新形態に基づいて、第一記憶空間におけるインターフェースリソースを更新する。衝突が存在する場合、第一システムは、第二インターフェースリソース更新メッセージに応答しない。

【0147】

更新衝突が存在するか否かを検出する具体的な形態について、１つの可能な実施形態では、更新形態が追加（第二インターフェースリソースの追加）である場合、第一システムは、第一記憶空間に第二アプリケーション情報が存在するか否かを検出する。第一記憶空間に第二アプリケーション情報が存在しなければ、更新衝突が存在しないことを特定し、第二アプリケーション情報と第二インターフェースリソースとを関連付けて第一記憶空間に記憶する。

【0148】

例示的な一例において、第一記憶空間におけるアプリケーション情報とインターフェースリソースとの間のマッピング関係が表１に示されたようである場合、第二インターフェースリソース更新メッセージに含まれる更新形態が追加であり、且つ、含まれる第二アプリケーション情報が「アプリケーション・パッケージ名：ａｌａｒｍ＿ａｐｐ」（アラームアプリケーション）であれば、第一記憶空間に当該第二アプリケーション情報が含まれていないため、更新衝突が存在しないと特定し、インターフェースリソースを更新する。インターフェースリソース更新後、第一記憶空間におけるアプリケーション情報とインターフェースリソースとの間のマッピング関係が表３に示されている。

【0149】

【表3】

【0150】

選択的に、更新形態が追加であり、且つ第一記憶空間に第二アプリケーション情報が記憶されていることに応答して、第一システムは、更新衝突が存在すると特定し、第一記憶空間における第二インターフェースリソースを更新しない。

【0151】

選択的に、更新形態が追加である場合、更新衝突が存在すると特定すれば、第一システムは、対応の追加待ちの起動形態を第二アプリケーション情報に追加する。

【0152】

例えば、表３に示されるデータと結びつけて、第二インターフェースリソース更新メッセージに含まれる更新形態が追加であり、且つ、含まれる第二アプリケーション情報が「アプリケーション・パッケージ名：ｓｐｏｒｔ＿ａｐｐ」である場合、第一記憶空間に当該第二アプリケーション情報が含まれているため、更新衝突が存在すると特定し、インターフェースリソースファイルＡを更新せず、ｓｐｏｒｔ＿ａｐｐに、第二インターフェースリソース更新メッセージにおける目標起動形態「ショートカットキー」のみを追加する。

【0153】

他の可能な実施形態では、更新形態が削除（第二インターフェースリソースの削除）である場合、第一システムは、第二インターフェースリソース更新メッセージにおける目標起動形態（即ち、削除待ちの起動形態）に基づいて、削除待ちの起動形態以外の起動形態によって第一記憶空間に記憶された第二アプリケーション情報が利用されるか否かを検出する。削除待ちの起動形態以外の起動形態が存在しない（即ち、第二アプリケーションが削除待ちの起動形態によって指示されるショートカット形態のみを利用して起動される）場合、第一システムは、更新衝突が存在しないと特定し、第一記憶空間から第二アプリケーション情報及び第二インターフェースリソースを削除する。

【0154】

例示的な一例において、第一記憶空間におけるアプリケーション情報、インターフェースリソース、及び起動形態の間のマッピング関係が表４に示されている。

【0155】

【表4】

【0156】

第二インターフェースリソース更新メッセージに含まれる更新形態が削除であり、且つ、含まれる第二アプリケーション情報が「アプリケーション・パッケージ名：ｈｅａｌｔｈ＿ａｐｐ」であり、削除待ちの起動形態が「ショートカットキー」である場合、第一システムは、更新衝突が存在しないと特定し、インターフェースリソースを更新する。インターフェースリソース更新後、第一記憶空間におけるアプリケーション情報、インターフェースリソース、及び起動形態の間のマッピング関係は表５に示されている。

【0157】

【表5】

【0158】

選択的に、更新形態が削除であり、且つ第一記憶空間に第二アプリケーション情報が記憶されており、且つ削除待ちの起動形態以外の起動形態によって第二アプリケーション情報が利用されることに応答して、第一システムは、更新衝突が存在すると特定し、第一記憶空間における第二インターフェースリソースを更新しない。

【0159】

選択的に、更新形態が削除である場合、更新衝突が存在すると特定すれば、第一システムは、第二アプリケーション情報のために、対応の削除待ちの起動形態を削除する。

【0160】

例えば、表４に示されたデータと結びつけて、第二インターフェースリソース更新メッセージに含まれる更新形態が削除であり、且つ、含まれる第二アプリケーション情報が「アプリケーション・パッケージ名：ｈｅａｌｔｈ＿ａｐｐ」である場合、第一記憶空間に当該第二アプリケーション情報が含まれているため、更新衝突が存在すると特定し、インターフェースリソースファイルＡを更新せず、ｈｅａｌｔｈ＿ａｐｐのために、第二インターフェースリソース更新メッセージにおける削除待ちの起動形態「ショートカットキー」のみを削除する。

【0161】

１つの可能な実施形態において、第二システムは、第二インターフェースリソース更新メッセージに強制更新識別子を設定することにより、第二インターフェースリソースに対する強制更新を指示することができる。

【0162】

選択的に、第二インターフェースリソース更新メッセージに強制更新識別子が含まれていないことが認識されたことに応答して、第一システムは、更新形態及び第二アプリケーション情報に基づいて、更新衝突を検出する。第二インターフェースリソース更新メッセージに強制更新識別子が含まれていることが認識されたことに応答して、第一システムは、更新形態に基づいて、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新する。

【0163】

選択的に、インターフェースリソース更新が完了した後、第一システムは第二システムに更新完了通知を送信し、インターフェースリソース更新が完了したことを第二システムに通知する。第二システムは予め設定された時間内に更新完了通知を受信しなければ、改めて第一システムに第二インターフェースリソース更新メッセージを送信する。

【0164】

例示的に、図１０に示されるように、ＲＴＯＳは、第二インターフェースリソース更新メッセージを受信した後、第二インターフェースリソース更新メッセージに強制更新識別子が含まれている場合、ＲＴＯＳシステムは、インターフェースリソースを直接に更新（追加又は削除）する。第二インターフェースリソース更新メッセージに強制更新識別子が含まれていない場合、ＲＴＯＳシステムは、条件に応じて（即ち、更新衝突が存在しない場合）、インターフェースリソースを更新（追加又は削除）し、第二インターフェースリソースを更新した後、更新完了通知をアンドロイドシステムに送信する。

【0165】

本実施形態では、第二アプリケーションの起動形態に更新がある場合、第二システムによって第二アプリケーションの第二アプリケーション情報を取得し、第二アプリケーション情報に基づいて第二インターフェースリソースを取得し、第二インターフェースリソース更新メッセージを第一システムに送信する。第一システムは、第二インターフェースリソースに更新衝突が存在するか否かを特定する。更新衝突が存在しない場合、第二インターフェースリソースを更新し、更新衝突が存在する場合、第二インターフェースリソースを更新しない。それによって、起動形態更新後、シームレスなシステム切り替えという機能の正常動作が確保される。

【0166】

なお、上記各実施例では、デュアルコアデュアルシステム機器でのアプリケーションインターフェースの表示プロセスのみを例として説明し、他の可能な応用シナリオにおいても、シングルコアデュアルシステム（例えば、プロセッサが異なるコアで異なるシステムを実行する）機器が本出願の実施形態に係る提案を採用して、システム切り替え中のアプリケーションインターフェースの表示を実現することもでき、それについては詳述しない。

【0167】

図１１を参照すると、図１１は、本出願の１つの実施形態に係るアプリケーションインターフェースの表示装置の構造を示すブロック図である。当該装置は、ソフトウェア、ハードウェア、又は両者の組合せによってウェアラブルデバイスの全部又は一部として実装されることができる。当該装置は、第一システムモジュール１１０１及び第二システムモジュール１１０２を備える。
第一システムモジュール１１０１は、第一システムがウェイクアップ状態にあり、且つ第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、第一システムによって目標アプリケーションのインターフェースを描画し表示するように構成されている。
第二システムモジュール１１０２は、第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、第二システムによって目標アプリケーションのインターフェースを描画するように構成されている。
第二システムモジュール１１０２はさらに、第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行するように構成されている。

【0168】

選択的に、第一システムモジュール１１０１は、
第一システムによって、第一システムに対応する記憶空間である第一記憶空間から目標アプリケーションに対応する目標インターフェースリソースを取得し、
目標インターフェースリソースに基づいて、第一システムによって目標アプリケーションのインターフェースを描画し表示するように構成されている。

【0169】

選択的に、第一システムモジュール１１０１は具体的に、
第一システムによって、目標アプリケーションに対応する目標アプリケーション情報を取得し、
目標アプリケーション情報に基づいて、第一システムによって第一記憶空間から目標インターフェースリソースを取得する、ように構成されている。

【0170】

選択的に、第二システムモジュール１１０２はさらに、第二システムがウェイクアップ状態にある場合、第二システムによって第一システムにインターフェースリソース更新メッセージを送信するように構成されている。
第一システムモジュール１１０１はさらに、インターフェースリソース更新メッセージに基づいて、第一システムによって第一記憶空間に記憶されたインターフェースリソースを更新するように構成されている。

【0171】

選択的に、第二システムモジュール１１０２は具体的に、
第二システムがウェイクアップ状態にある場合、言語更新ブロードキャストが受信されたことに応答して、第二システムによって第一アプリケーションの第一アプリケーション情報を取得するように構成されており、第一アプリケーションに対応する第一インターフェースリソースが第一記憶空間に記憶されており、
第二システムモジュールは１１０２、第二システムによって第一システムに、第一アプリケーション情報と更新された第一インターフェースリソースとを含む第一インターフェースリソース更新メッセージを送信するように構成されている。
第一システムモジュール１１０１は具体的に、第一システムによって、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて第一記憶空間に記憶するように構成されている。

【0172】

選択的に、第二システムモジュール１１０２は具体的に、第二システムによって第一システムにクエリメッセージを送信するように構成されている。
第一システムモジュール１１０１は具体的に、第一システムによって、第二システムに第一アプリケーションの第一アプリケーション情報を送信し、且つ、第一記憶空間から第一アプリケーションに対応する第一インターフェースリソースを削除するように構成されている。

【0173】

選択的に、第二システムモジュール１１０２は具体的に、第二システムによって、第二システムに対応する記憶空間である第二記憶空間から第一アプリケーションの第一アプリケーション情報を取得するように構成されている。
第一システムモジュール１１０１は具体的に、第一インターフェースリソース更新メッセージに強制更新識別子が含まれていることが識別されたことに応答して、第一システムによって、第一記憶空間に記憶されたインターフェースリソースを削除し、且つ、第一アプリケーション情報と、更新された第一インターフェースリソースとを関連付けて第一記憶空間に記憶するように構成されている。

【0174】

選択的に、第二システムモジュール１１０２は具体的に、
第二システムがウェイクアップ状態にある場合、第二アプリケーションの起動形態更新メッセージがモニタリングされたことに応答して、第二システムによって第二アプリケーションの第二アプリケーション情報及び第二インターフェースリソースを取得するように構成されており、起動形態更新メッセージは第二アプリケーションの起動形態の変化を表すために用いられる。
第二システムモジュール１１０２は、第二システムによって第一システムに、更新形態と、第二アプリケーション情報と、第二インターフェースリソースとを含む第二インターフェースリソース更新メッセージを送信するように構成されている。
第一システムモジュール１１０１は具体的に、更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新するように構成されている。

【0175】

選択的に、第一システムモジュール１１０１は具体的に、
更新形態が追加であることに応答して、第一システムによって、第二アプリケーション情報と、第二インターフェースリソースとを関連付けて第一記憶空間に記憶し、
更新形態が削除であることに応答して、第一システムによって、第一記憶空間から第二アプリケーション情報及び第二インターフェースリソースを削除する、ように構成されている。

【0176】

選択的に、第一システムモジュール１１０１はさらに、
更新形態が追加であり、且つ第一記憶空間に第二アプリケーション情報が記憶されていることに応答して、更新衝突が存在すると特定し、
更新形態が削除であり、且つ第一記憶空間に第二アプリケーション情報が記憶されており、且つ削除待ちの起動形態以外の起動形態によって第二アプリケーション情報が利用されることに応答して、更新衝突が存在すると特定する、ように構成されており、
更新衝突が存在する場合、第一記憶空間における第二インターフェースリソースが更新されない。

【0177】

選択的に、第一システムモジュール１１０１はさらに、
第二インターフェースリソース更新メッセージに強制更新識別子が含まれておらず、且つ、更新衝突が存在しないことが識別されたことに応答して、更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新し、
第二インターフェースリソース更新メッセージに強制更新識別子が含まれていることが識別されたことに応答して、更新形態に基づいて、第一システムによって、第一記憶空間における第二アプリケーション情報に対応する第二インターフェースリソースを更新する、ように構成されている。

【0178】

選択的に、第一記憶空間は、第一システムで起動されることがサポートされるアプリケーションに対応するインターフェースリソースを記憶するために用いられる。第一システムでアプリケーションを起動する形態は、ショートカットキーによる起動、及び第一システムのウィジェットによる起動のうちの少なくとも１つを含む。

【0179】

選択的に、第二システムモジュール１１０２はさらに、
第二システムによる目標アプリケーションのインターフェースの描画の完了に応答して、第二システムによって第一システムに、第一システムにグラフィカルユーザインターフェース（ＧＵＩ）の表示権限を移行させるように指示するための切り替え指示を送信し、
第二システムがＧＵＩの表示権限を取得したことに応答して、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行する、ように構成されている。

【0180】

選択的に、ウェアラブルデバイスは、第一プロセッサ及び第二プロセッサを備え、第二プロセッサの消費電力は第一プロセッサの消費電力より大きく、第一システムは、第一プロセッサによって実行されるシステムであり、第二システムは、第二プロセッサによって実行されるシステムである。

【0181】

上述したように、本出願の実施形態において、デュアルシステムをサポートするウェアラブルデバイスでは、第一システムが稼働状態にあり、第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示を受信すると、まず、第一システムによって目標アプリケーションのインターフェースを描画し表示し、また、第二システムをウェイクアップした後、第二システムによって、目標アプリケーションのインターフェースを表示し、且つ目標アプリケーションを実行する。本出願の実施形態に係る提案によれば、第一システムによってアプリケーションの起動効果を事前表示することで、アプリケーションの起動速度を視覚的に向上させることが可能となり、システム切り替え中のアプリケーション画面の表示遅延を低減する。

【0182】

本実施形態では、アプリケーション情報及びインターフェースリソースを第一記憶空間に記憶することにより、第一システムは、アプリケーション起動指示を受信すると、目標アプリケーションの目標アプリケーション情報に基づいて、第一記憶空間から対応の目標インターフェースリソースを正確に取得することが可能となり、目標アプリケーションのインターフェース描画の速度及び正確性の向上に役立つ。

【0183】

また、第一記憶空間には、第一システムで起動されることがサポートされるアプリケーションのインターフェースリソースのみが記憶され、それによって、シームレスなシステム切り替えを実現した上で、インターフェースリソースにより占用される記憶空間を低減し、第一記憶空間の容量へのニーズを低減する。

【0184】

本実施形態では、システム言語更新の際、第二システムによって、各第一アプリケーションの第一アプリケーション情報を取得し、更新された第一インターフェースリソースを第一アプリケーション情報に基づいて取得することにより、更新された第一インターフェースリソースを第一システムに送信する。第一システムは、第一記憶空間に記憶された第一インターフェースリソースを更新し、後続のシステム切り替えの際、第一システムに表示されるアプリケーションインターフェースの言語とシステム言語とが一致することを確保する。

【0185】

本実施形態では、第二アプリケーションの起動形態に更新がある場合、第二システムによって第二アプリケーションの第二アプリケーション情報を取得し、第二アプリケーション情報に基づいて第二インターフェースリソースを取得し、第二インターフェースリソース更新メッセージを第一システムに送信する。第一システムは、第二インターフェースリソースに更新衝突が存在するか否かを特定する。更新衝突が存在しない場合、第二インターフェースリソースを更新し、更新衝突が存在する場合、第二インターフェースリソースを更新しない。それによって、起動形態更新後、シームレスなシステム切り替えという機能の正常動作が確保される。

【0186】

図１２を参照すると、図１２は、本出願の１つの例示的な実施形態に係るウェアラブルデバイスの構造を示すブロック図である。本出願におけるウェアラブルデバイスは少なくとも、１つ又は複数のプロセッサ１２１０、及び１つ又は複数のメモリ１２２０を備えることができる。

【0187】

選択的に、プロセッサ１２１０は、少なくとも第一プロセッサ１２１１及び第二プロセッサ１２１２を含む。第一プロセッサ１２１１は第一システムを実行するために用いられ、第二プロセッサ１２１２は、第二システムを実行するために用いられ、第一プロセッサ１２１１の消費電力は、第二プロセッサ１２１２の消費電力より低く、第一プロセッサ１２１１の性能は、第二プロセッサ１２１２の性能より低い。プロセッサ１２１０は、各種のインターフェース及び回線を利用して、電子機器内の各部全体を接続し、メモリ１２２０に記憶された命令、プログラム、コードセット又は命令セットを実行し、メモリ１２２０に記憶されたデータを呼び出すことにより、電子機器の各種の機能及び処理データを実行する。選択的に、プロセッサ１２１０は、デジタル信号処理（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ、ＤＳＰ）、フィールドプログラム可能なゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、プログラム可能な論理アレイ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙ、ＰＬＡ）のうちの少なくとも１つのハードウェアを用いて実装されてもよい。プロセッサ１２１０は、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、グラフィックスプロセッシングユニット（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＧＰＵ）、ニューラル・ネットワーク・プロセッシング・ユニット（ｎｅｕｒａｌ－ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＮＰＵ）及びモデム等のうちの１つ又はいくつかの組み合わせを集積することができる。ＣＰＵは主に、オペレーティングシステム、ユーザインターフェース、及びアプリケーションプログラム等を処理し、ＧＰＵは、タッチディスプレイスクリーンに表示される必要のあるコンテンツのレンダリング及び描画を担当する。ＮＰＵは、人工知能（ａｒｔｉｆｉｃｉａｌ ｉｎｔｅｌｌｉｇｅｎｃｅ、ＡＩ）機能を実現するために用いられる。モデムは、無線通信を処理するために用いられる。上記モデムは、プロセッサ１２１０に集積されなくてもよく、１つのチップのみで実装されてもよい。

【0188】

メモリ１２２０は、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）を含むことができ、読み取り専用メモリ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）を含むこともできる。選択的に、当該メモリ１２２０は、非一時的なコンピュータ可読記憶媒体（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ－ｒｅａｄａｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）を含む。メモリ１２２０は命令、プログラム、コード、コードセット又は命令セットを記憶するために用いられることができる。メモリ１２２０は、プログラム記憶領域及びデータ記憶領域を含むことができる。プログラム記憶領域は、オペレーティングシステムを実現するための命令、少なくとも１つの機能（例えば、タッチ機能、音声再生機能、画像再生機能など）のための命令、各方法実施形態を実現するための命令等を記憶することができる。データ記憶領域はウェアラブルデバイスの使用に応じて作成されるデータ（例えば、オーディオデータ、電話帳）等を記憶することができる。

【0189】

本出願の実施形態に係るウェアラブルデバイスは、通信コンポーネント１２３０と、表示コンポーネント１２４０とをさらに備える。通信コンポーネント１２３０は、ブルートゥースサービスモジュール、ワイヤレスフィディリティー（ｗｉｒｅｌｅｓｓ ｆｉｄｅｌｉｔｙ、ＷｉＦｉ）モジュール、近距離無線通信（ｎｅａｒ ｆｉｅｌｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＮＦＣ）であり得、有線又は無線のネットワークを介して外部装置（サーバ又は他の端末装置）と通信する。表示コンポーネント１２４０は、ＧＵＩの表示、及び／又は、ユーザのインタラクション操作の受信のために用いられる。

【0190】

上記以外に、当業者は以下のことを理解することができる。上記図面に示されるウェアラブルデバイスの構造は、ウェアラブルデバイスを限定するものではなく、ウェアラブルデバイスは、図示された構成要素より多くもしくはより少なく、又は、一部の構成要素を組み合わせ、又は、異なる要素の配置を有してもよい。例えば、ウェアラブルデバイスには、無線回路、入力ユニット、センサー、オーディオ回路、スピーカ、マイク、電源等の構成要素も含まれ、それについては説明を省略する。

【0191】

本出願の実施形態において、コンピュータ可読記憶媒体がさらに提供される。当該記憶媒体に少なくとも１つの命令が記憶されている。少なくとも１つの命令は、プロセッサによって実行されることにより、上記実施形態に記載のアプリケーションインターフェースの表示方法を実現するために用いられる。

【0192】

本出願の実施形態において、コンピュータプログラム製品又はコンピュータプログラムが提供される。当該コンピュータプログラム製品又はコンピュータプログラムは、コンピュータ命令を含み、当該コンピュータ命令はコンピュータ可読記憶媒体に記憶されている。コンピュータ装置のプロセッサは、コンピュータ可読記憶媒体から当該コンピュータ命令を読み出し、プロセッサは当該コンピュータ命令を実行することにより、当該コンピュータ装置に上記実施形態に係るアプリケーションインターフェースの表示方法を実行させる。

【0193】

当業者は以下のことを意識することができる。上記１つ又は複数の例において、本出願の実施形態に記載された機能は、ハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組み合わせによって実現されることができる。これらの機能は、ソフトウェアによって実現される場合、コンピュータ可読媒体に記憶されてもよく、コンピュータ可読媒体上の１つ又は複数の命令又はコードとして伝送されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体と通信媒体とを含む。通信媒体は、コンピュータプログラムを１つのところから別のところに伝送しやすくするための任意の媒体を含む。記憶媒体は、汎用又は専用コンピュータによりアクセス可能な任意の利用可能媒体であってもよい。

【0194】

上記は本出願の選択可能な実施形態に過ぎず、本出願を限定するものではない。本出願の精神及び原則の範囲内にあれば、いかなる修正、均等な切り替え、改良等はいずれも、本出願の保護範囲に含まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【手続補正書】

【提出日】2023-09-14

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

アプリケーションインターフェースの表示方法であって、前記アプリケーションインターフェースの表示方法は、第一システム及び第二システムの実行をサポートするウェアラブルデバイスによって実行され、前記アプリケーションインターフェースの表示方法は、
前記第一システムがウェイクアップ状態にあり、且つ前記第二システムがスリープ状態にある場合、目標アプリケーションのアプリケーション起動指示に応答して、前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示することと、
前記第二システムのスリープ状態からウェイクアップ状態への切り替えに応答して、前記第二システムによって前記目標アプリケーションのインターフェースを描画することと、
前記第二システムによる前記目標アプリケーションのインターフェースの描画の完了に応答して、前記第二システムによって、前記目標アプリケーションのインターフェースを表示し、且つ前記目標アプリケーションを実行することと、を含む、
ことを特徴とするアプリケーションインターフェースの表示方法。

【請求項2】

前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示することは、
前記第一システムによって、前記第一システムに対応する記憶空間である第一記憶空間から前記目標アプリケーションに対応する目標インターフェースリソースを取得することと、
前記目標インターフェースリソースに基づいて、前記第一システムによって前記目標アプリケーションのインターフェースを描画し表示することと、を含む、
ことを特徴とする請求項１に記載のアプリケーションインターフェースの表示方法。

【請求項3】

前記第一システムによって、前記第一記憶空間から前記目標アプリケーションに対応する前記目標インターフェースリソースを取得することは、
前記第一システムによって、前記目標アプリケーションに対応する目標アプリケーション情報を取得することと、
前記目標アプリケーション情報に基づいて、前記第一システムによって前記第一記憶空間から前記目標インターフェースリソースを取得することと、を含む、
ことを特徴とする請求項２に記載のアプリケーションインターフェースの表示方法。

【請求項4】

前記アプリケーションインターフェースの表示方法は、
前記第二システムがウェイクアップ状態にある場合、前記第二システムによって前記第一システムにインターフェースリソース更新メッセージを送信することと、
前記インターフェースリソース更新メッセージに基づいて、前記第一システムによって、前記第一記憶空間に記憶されたインターフェースリソースを更新することと、をさらに含む、
ことを特徴とする請求項２に記載のアプリケーションインターフェースの表示方法。

【請求項5】

前記第二システムがウェイクアップ状態にある場合、前記第二システムによって前記第一システムに前記インターフェースリソース更新メッセージを送信することは、
前記第二システムがウェイクアップ状態にある場合、言語更新ブロードキャストが受信されたことに応答して、前記第二システムによって第一アプリケーションの第一アプリケーション情報を取得することであって、前記第一アプリケーションに対応する第一インターフェースリソースが前記第一記憶空間に記憶されている、取得することと、
前記第二システムによって前記第一システムに、前記第一アプリケーション情報と更新された第一インターフェースリソースとを含む第一インターフェースリソース更新メッセージを送信することと、を含み、
前記インターフェースリソース更新メッセージに基づいて、前記第一システムによって、前記第一記憶空間に記憶された前記インターフェースリソースを更新することは、
前記第一システムによって、前記第一アプリケーション情報と、前記更新された第一インターフェースリソースとを関連付けて前記第一記憶空間に記憶すること、を含む、
ことを特徴とする請求項４に記載のアプリケーションインターフェースの表示方法。

【請求項6】

前記第二システムによって前記第一アプリケーションの前記第一アプリケーション情報を取得することは、
前記第二システムによって前記第一システムにクエリメッセージを送信することと、
前記第一システムによって、前記第二システムに前記第一アプリケーションの前記第一アプリケーション情報を送信し、且つ、前記第一記憶空間から前記第一アプリケーションに対応する前記第一インターフェースリソースを削除することと、を含む、
ことを特徴とする請求項５に記載のアプリケーションインターフェースの表示方法。

【請求項7】

前記第二システムによって前記第一アプリケーションの前記第一アプリケーション情報を取得することは、
前記第二システムによって、前記第二システムに対応する記憶空間である第二記憶空間から前記第一アプリケーションの前記第一アプリケーション情報を取得すること、を含み、
前記第一システムによって、前記第一アプリケーション情報と、前記更新された第一インターフェースリソースとを関連付けて前記第一記憶空間に記憶することは、
前記第一インターフェースリソース更新メッセージに強制更新識別子が含まれていることが識別されたことに応答して、前記第一システムによって、前記第一記憶空間に記憶された前記インターフェースリソースを削除し、且つ、前記第一アプリケーション情報と、前記更新された第一インターフェースリソースとを関連付けて前記第一記憶空間に記憶すること、を含む、
ことを特徴とする請求項５に記載のアプリケーションインターフェースの表示方法。

【請求項8】

前記第二システムがウェイクアップ状態にある場合、前記第二システムによって前記第一システムに前記インターフェースリソース更新メッセージを送信することは、
前記第二システムがウェイクアップ状態にある場合、第二アプリケーションの起動形態更新メッセージがモニタリングされたことに応答して、前記第二システムによって前記第二アプリケーションの第二アプリケーション情報及び第二インターフェースリソースを取得することであって、前記起動形態更新メッセージは前記第二アプリケーションの起動形態の変化を表すために用いられる、取得することと、
前記第二システムによって前記第一システムに、更新形態と、前記第二アプリケーション情報と、前記第二インターフェースリソースとを含む第二インターフェースリソース更新メッセージを送信することと、を含み、
前記インターフェースリソース更新メッセージに基づいて、前記第一システムによって、前記第一記憶空間に記憶された前記インターフェースリソースを更新することは、
前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新すること、を含む、
ことを特徴とする請求項４に記載のアプリケーションインターフェースの表示方法。

【請求項9】

前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新することは、
前記更新形態が追加であることに応答して、前記第一システムによって、前記第二アプリケーション情報と、前記第二インターフェースリソースとを関連付けて前記第一記憶空間に記憶することと、
前記更新形態が削除であることに応答して、前記第一システムによって、前記第一記憶空間から前記第二アプリケーション情報及び前記第二インターフェースリソースを削除することと、を含む、
ことを特徴とする請求項８に記載のアプリケーションインターフェースの表示方法。

【請求項10】

前記アプリケーションインターフェースの表示方法は、
前記更新形態が追加であり、且つ前記第一記憶空間に前記第二アプリケーション情報が記憶されていることに応答して、更新衝突が存在すると特定することと、
前記更新形態が削除であり、且つ前記第一記憶空間に前記第二アプリケーション情報が記憶されており、且つ削除待ちの起動形態以外の起動形態によって前記第二アプリケーション情報が利用されることに応答して、更新衝突が存在すると特定することと、をさらに含み、
更新衝突が存在する場合、前記第一記憶空間における前記第二インターフェースリソースが更新されない、
ことを特徴とする請求項９に記載のアプリケーションインターフェースの表示方法。

【請求項11】

前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新することは、
前記第二インターフェースリソース更新メッセージに強制更新識別子が含まれておらず、且つ、更新衝突が存在しないことが識別されたことに応答して、前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新すること、を含み、
前記アプリケーションインターフェースの表示方法は、
前記第二インターフェースリソース更新メッセージに前記強制更新識別子が含まれていることが識別されたことに応答して、前記更新形態に基づいて、前記第一システムによって、前記第一記憶空間における前記第二アプリケーション情報に対応する前記第二インターフェースリソースを更新すること、をさらに含む、
ことを特徴とする請求項８に記載のアプリケーションインターフェースの表示方法。

【請求項12】

前記第二システムによる前記目標アプリケーションのインターフェースの描画の完了に応答して、前記第二システムによって、前記目標アプリケーションのインターフェースを表示し、且つ前記目標アプリケーションを実行することは、
前記第二システムによる前記目標アプリケーションのインターフェースの描画の完了に応答して、前記第二システムによって前記第一システムに、前記第一システムにグラフィカルユーザインターフェース（ＧＵＩ）の表示権限を移行させるように指示するための切り替え指示を送信することと、
前記第二システムが前記ＧＵＩの表示権限を取得したことに応答して、前記第二システムによって、前記目標アプリケーションの前記インターフェースを表示し、且つ前記目標アプリケーションを実行することと、を含む、
ことを特徴とする請求項１～１１のいずれか一項に記載のアプリケーションインターフェースの表示方法。

【請求項13】

前記目標アプリケーションは、前記第一システムによって起動も実行もできないアプリケーションであり、前記アプリケーションインターフェースの表示方法は、
前記第一システムがウェイクアップ状態にあり、且つ前記第二システムがスリープ状態にある場合、前記目標アプリケーションの前記アプリケーション起動指示に応答して、スリープ状態にある前記第二システムをウェイクアップして、前記第二システムによって前記目標アプリケーションを起動して実行すること、をさらに含む、
ことを特徴とする請求項１～１２のいずれか一項に記載のアプリケーションインターフェースの表示方法。

【請求項14】

プロセッサ及びメモリを備えるウェアラブルデバイスであって、
前記メモリに少なくとも１つの命令が記憶されており、前記少なくとも１つの命令は、前記プロセッサによって実行されることにより、請求項１～１３のいずれか一項に記載のアプリケーションインターフェースの表示方法を実現するために用いられる、
ことを特徴とするウェアラブルデバイス。

【請求項15】

少なくとも１つの命令が記憶されたコンピュータ可読記憶媒体であって、
前記少なくとも１つの命令は、プロセッサによって実行されることにより、請求項１～１３のいずれか一項に記載のアプリケーションインターフェースの表示方法を実現するために用いられる、
ことを特徴とするコンピュータ可読記憶媒体。

【国際調査報告】