知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-12-03
(54)【発明の名称】インターフェース生成方法および電子デバイス
(51)【国際特許分類】
G09G 5/377 20060101AFI20241126BHJP
G06F 3/14 20060101ALI20241126BHJP
G06F 3/0481 20220101ALI20241126BHJP
G06F 3/04845 20220101ALI20241126BHJP
G09G 5/00 20060101ALI20241126BHJP
G09G 5/02 20060101ALI20241126BHJP
G09G 5/37 20060101ALI20241126BHJP
G09G 5/373 20060101ALI20241126BHJP
【ＦＩ】
G09G5/377 110
G06F3/14 360B
G06F3/0481
G06F3/04845
G09G5/00 530H
G09G5/02 B
G09G5/37 310
G09G5/373
G09G5/00 555G
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024531374
(86)(22)【出願日】2022-11-23
(85)【翻訳文提出日】2024-07-04
(86)【国際出願番号】 CN2022133838
(87)【国際公開番号】W WO2023093779
(87)【国際公開日】2023-06-01
(31)【優先権主張番号】202111410513.6
(32)【優先日】2021-11-25
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
２．ＢＬＵＥＴＯＯＴＨ
(71)【出願人】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133569
【弁理士】
【氏名又は名称】野村 進
(72)【発明者】
【氏名】▲張▼ 孝慈
(72)【発明者】
【氏名】李 ▲ユ▼
(72)【発明者】
【氏名】余 ▲譚▼其
(72)【発明者】
【氏名】倪 ▲澤▼宇
【テーマコード（参考）】
5B069
5C182
5E555
【Ｆターム（参考）】
5B069AA01
5B069BC02
5B069CA04
5B069DD11
5B069DD13
5B069DD15
5B069HA16
5B069JA06
5C182AA02
5C182AA03
5C182AA04
5C182AA23
5C182AC02
5C182AC03
5C182AC33
5C182BA25
5C182BA28
5C182BA29
5C182BA30
5C182BA45
5C182BA46
5C182BB02
5C182BB13
5C182BC29
5C182CA32
5C182CB11
5C182CB12
5C182CB32
5C182CB44
5C182CB52
5C182CB54
5C182CB56
5C182CC02
5C182CC21
5C182DA04
5C182DA14
5C182DA44
5E555AA77
5E555BA01
5E555BA04
5E555BB01
5E555BB04
5E555BC04
5E555BC17
5E555CA12
5E555CB12
5E555CB37
5E555CB45
5E555CC22
5E555DB03
5E555DB04
5E555DB53
5E555DC09
5E555DC19
5E555DC24
5E555DC25
5E555DC30
5E555DC35
5E555DD06
5E555EA11
5E555EA14
5E555FA00
(57)【要約】
本出願は、インターフェース生成方法および電子デバイスを開示し、電子技術の分野に関する。本出願で提供されるインターフェース生成方法によれば、1つの表示領域内の1つ以上のアプリケーションのレンダツリーはマージされてもよく、1つ以上のアプリケーションインターフェースを含むインターフェースは、マージされたターゲットレンダツリーに基づいて1回のレンダリングを介して生成され、それによってレンダリング回数を低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【特許請求の範囲】
【請求項1】
第1の電子デバイスに適用されるインターフェース生成方法であって、前記第1の電子デバイスは、第1の表示領域に表示された内容が第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含むと決定し、前記方法は、前記第1のプロセスによって、第1のレンダツリーを生成するステップであって、前記第1のレンダツリーは、前記第1のプロセスの前記インターフェースを描画するために使用される、ステップと、
前記第2のプロセスによって、第2のレンダツリーを生成するステップであって、前記第2のレンダツリーは、前記第2のプロセスの前記インターフェースを描画するために使用される、ステップと、
第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するステップであって、前記第1のターゲットインターフェースは、前記第1のプロセスの前記インターフェースおよび前記第2のプロセスの前記インターフェースを含み、前記第1のターゲットインターフェースは、前記第1の表示領域に表示される、ステップと
を含む、インターフェース生成方法。
【請求項2】
第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットインターフェースを生成する前記ステップは、前記第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成するステップと、
前記第3のプロセスによって、前記第1のターゲットレンダツリーに基づいて前記第1のターゲットインターフェースを生成するステップと
を具体的には含む、請求項1に記載の方法。
【請求項3】
前記第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成する前記ステップは、前記第3のプロセスによって、前記第1のターゲットレンダツリーのルートノードとしてルートレンダノードを作成し、前記第1のレンダツリーおよび前記第2のレンダツリーを前記ルートレンダノードの子ノードとして使用するステップと
を具体的には含む、請求項2に記載の方法。
【請求項4】
前記第3のプロセスによって、前記第1のレンダツリーのZオーダーおよび前記第2のレンダツリーのZオーダーに基づいて前記第1のターゲットレンダツリー内のレンダノードを削除するステップであって、前記削除されたレンダノードは完全に遮蔽されたビューに対応する、ステップとをさらに含む、請求項3に記載の方法。
【請求項5】
前記第3のプロセスによって、前記第1のレンダツリーのZオーダーおよび前記第2のレンダツリーのZオーダーに基づいて前記第1のターゲットレンダツリーにおける描画操作を削除するステップであって、前記削除された描画操作は完全に遮蔽されたグラフィックに対応する、ステップをさらに含む、請求項3に記載の方法。
【請求項6】
前記第3のプロセスが前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて前記第1のターゲットインターフェースを生成するプロセスにおいて、前記第3のプロセスによって、第1の描画操作および第2の描画操作に対してマージまたはバッチを実行するステップであって、前記第1の描画操作は前記第1のレンダツリーに属し、前記第2の描画操作は前記第2のレンダツリーに属する、ステップをさらに含む、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記第3のプロセスによって、前記第1のプロセスの前記インターフェースのオフスクリーンレンダリングロジックを決定するステップであって、前記オフスクリーンレンダリングロジックは、ウィンドウ丸み付け、色変換、回転、およびスケーリングのうちの少なくとも1つを含む、ステップと、前記第3のプロセスによって、前記第1のプロセスの前記インターフェースの前記オフスクリーンレンダリングロジックに基づいて前記第1のレンダツリーのレンダリングプロパティにオフスクリーンレンダリングプロパティを追加するステップであって、前記オフスクリーンレンダリングプロパティは、丸み付けプロパティ、色プロパティ、回転プロパティ、およびスケーリングプロパティのうちの少なくとも1つを含む、ステップと
をさらに含み、
前記オフスクリーンレンダリングプロパティは、前記オフスクリーンレンダリングロジックに1対1に対応し、前記オフスクリーンレンダリングプロパティは、前記オフスクリーンレンダリングロジックを実現するために、前記第3のプロセスが前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて前記第1のターゲットインターフェースを生成する前記プロセスにおいて描画操作を修正するために使用される、
請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記第1のレンダツリーの基準座標系は、第1の座標系であり、前記第1の表示領域に対応する基準座標系は、第2の座標系であり、前記第1の座標系が前記第2の座標系と異なるとき、前記第3のプロセスによって、前記第1の座標系および前記第2の座標系に基づいて第1のパラメータを決定し、前記第1のパラメータを前記第1のレンダツリーの前記レンダリングプロパティに追加するステップと、
前記第3のプロセスが前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて前記第1のターゲットインターフェースを生成する前記プロセスにおいて、前記第3のプロセスによって、前記第1のパラメータに基づいて前記第1の描画操作の基準座標系を修正するステップであって、前記第1の描画操作は、前記第1のレンダツリーに属する、ステップと
をさらに含む、請求項1から7のいずれか一項に記載の方法。
【請求項9】
第2の電子デバイスに適用されるインターフェース生成方法であって、前記第2の電子デバイスは、第1の表示領域に表示された内容が第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含むと決定し、前記方法は、前記第2の電子デバイス上で動作する第3のプロセスによって、第1のレンダツリーおよび第2のレンダツリーを受信するステップであって、前記第1のレンダツリーは、第1の電子デバイス上で動作する前記第1のプロセスによって生成され、前記第1のレンダツリーは、前記第1のプロセスの前記インターフェースを描画するために使用され、前記第2のレンダツリーは、前記第2の電子デバイス上で動作する前記第2のプロセスによって生成され、前記第2のレンダツリーは、前記第2のプロセスの前記インターフェースを描画するために使用される、ステップと、
前記第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいてターゲットインターフェースを生成するステップであって、前記ターゲットインターフェースは、前記第1のプロセスの前記インターフェースおよび前記第2のプロセスの前記インターフェースを含み、前記ターゲットインターフェースは、前記第1の表示領域に表示される、ステップと
を含む、インターフェース生成方法。
【請求項10】
1つ以上のプロセッサおよびメモリを備える電子デバイスであって、前記メモリは、前記1つ以上のプロセッサに結合され、前記メモリは、コンピュータプログラムコードを格納するように構成され、前記コンピュータプログラムコードは、コンピュータ命令を含み、前記1つ以上のプロセッサは、前記コンピュータ命令を呼び出し、その結果、前記電子デバイスは、請求項1から9のいずれか一項に記載の方法を行う、電子デバイス。
【請求項11】
電子デバイスに適用されるチップシステムであって、前記チップシステムは、1つ以上のプロセッサを備え、前記プロセッサは、コンピュータ命令を呼び出すように構成され、その結果、前記電子デバイスは、請求項1から8のいずれか一項に記載の方法を実行する、チップシステム。
【請求項12】
命令を含むコンピュータ可読記憶媒体であって、前記命令が電子デバイスで実行されると、前記電子デバイスは、請求項1か9のいずれか一項に記載の方法を行うことを可能にされる、コンピュータ可読記憶媒体。
【請求項13】
コンピュータ可読命令を含むコンピュータプログラム製品であって、前記コンピュータ可読命令が1つ以上のプロセッサによって実行されると、請求項1から9のいずれか一項に記載の方法が実現される、コンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2021年11月25日に出願された中国特許出願第202111410513．6号の優先権を主張する、2022年11月23日に出願された国際出願第PCT／CN2022／133838号の継続である。前述の出願の開示は、その全体が参照により本明細書に組み込まれる。
本出願は、2021年11月25日に出願された中国特許出願第202111410513．6号の優先権を主張する、2022年11月23日に出願された国際出願第PCT／CN2022／133838号の継続である。前述の出願の開示は、その全体が参照により本明細書に組み込まれる。
【0002】
本出願は、電子技術の分野に関し、特に、インターフェース生成方法および電子デバイスに関する。
【背景技術】
【0003】
電子技術の発展に伴い、より多くの電子デバイスがユーザの日常生活に関与されるようになってきている。加えて、電子デバイスのディスプレイの解像度およびサイズなどのパラメータが増加するにつれて、より多くの内容が電子デバイスに表示されることができる。
【0004】
しかしながら、アプリケーションのインターフェースを表示する前に、電子デバイスは、アプリケーションのインターフェースを生成するためにコンピューティングリソースおよびストレージリソースを消費する必要がある。これにより、電子デバイスの消費電力を増加させる。加えて、電子デバイスの画面上に複数のアプリケーションまたは複数のウィンドウがあるとき、電子デバイスは、複数のアプリケーションまたは複数のウィンドウのインターフェースを生成するためのレンダリングを実行するために、より多くのコンピューティングリソースおよびストレージリソースを消費する必要がある。
【発明の概要】
【課題を解決するための手段】
【0005】
本出願の実施形態は、インターフェース生成方法および電子デバイスを提供する。本出願で提供されるインターフェース生成方法によれば、1つの表示領域内の1つ以上のアプリケーションのレンダツリーはマージされてもよく、1つ以上のアプリケーションインターフェースを含むインターフェースは、マージされたターゲットレンダツリーに基づいて1回のレンダリングを介して生成され、それによってレンダリング回数を低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【0006】
第1の態様によれば、本出願の一実施形態で提供されるインターフェース生成方法は、第1の電子デバイスに適用される。第1の電子デバイスは、第1の表示領域に表示された内容が第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含むと決定し、前記方法は、第1のプロセスが第1のレンダツリーを生成することであって、第1のレンダツリーは、第1のプロセスのインターフェースを描画するために使用される、ことと、第2のプロセスが第2のレンダツリーを生成することであって、第2のレンダツリーは、第2のプロセスのインターフェースを描画するために使用される、ことと、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成することであって、第1のターゲットインターフェースは、前記第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含み、第1のターゲットインターフェースは、第1の表示領域に表示される、こととを含む。
【0007】
前述の実施形態では、1つ以上のアプリケーションインターフェースを含むインターフェースが、表示領域内の1つ以上のアプリケーションのレンダツリーに基づいて生成され、それによってレンダリング回数を低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【0008】
第1の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成することは、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成することと、第3のプロセスが第1のターゲットレンダツリーに基づいて第1のターゲットインターフェースを生成することとを具体的には含む。
【0009】
前述の実施形態では、第3のプロセスは、1つ以上のアプリケーションのレンダツリーを1つのターゲットレンダツリーにマージしてもよく、その結果、インターフェースは、ターゲットレンダツリーに基づいて生成されてもよい。インターフェースは、1つ以上のアプリケーションのインターフェースを含む。1つ以上のアプリケーションを含むインターフェースは、1回のレンダリング、すなわち、レンダツリーからビットマップへの1回のレンダリングプロセスを介して生成されることができ、その結果、レンダリング回数が低減され、電子デバイスの消費電力が低減されることは明らかである。
【0010】
第1の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、第3のプロセスが、第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成することは、第3のプロセスが第1のターゲットレンダツリーのルートノードとしてルートレンダノードを作成し、第1のレンダツリーおよび第2のレンダツリーをルートレンダノードの子ノードとして使用することとを具体的には含む。
【0011】
前述の実施形態では、新しいルートノードが作成されてもよく、複数のアプリケーションのレンダツリーは、ターゲットレンダツリーの作成を実現するために、ルートノードの子ノードにマウントされてもよい。
【0012】
第1の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが第1のレンダツリーのZオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリー内のレンダノードを削除することであって、削除されたレンダノードが完全遮蔽ビューに対応する、ことをさらに含む。
【0013】
前述の実施形態では、第3のプロセスは、オーバードローを低減するために、ターゲットレンダツリー内のパラメータを最適化し、例えば、インターフェース内の完全に遮蔽されたビューに対応するレンダノードを削除してもよい。
【0014】
第1の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが第1のレンダツリーのZオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリーにおける描画操作を削除することであって、削除された描画操作が完全に遮蔽されたグラフィックに対応する、ことをさらに含む。
【0015】
前述の実施形態では、第3のプロセスは、オーバードローを低減するために、ターゲットレンダツリー内のパラメータを最適化し、例えば、インターフェース内の完全に遮蔽されたグラフィックに対応するレンダノードを削除してもよい。
【0016】
第1の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスは、第1の描画操作および第2の描画操作に対してマージまたはバッチを実行することであって、第1の描画操作は、第1のレンダツリーに属し、第2の描画操作は、第2のレンダツリーに属する、ことをさらに含む。
【0017】
前述の実施形態では、第3のプロセスは、インターフェース生成レートを増加させ、フレームフリーズを低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善するために、ターゲットレンダツリーにおける描画操作のマージまたはバッチをしてもよい。
【0018】
第1の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが、第1のプロセスのインターフェースのオフスクリーンレンダリングロジックを決定することであって、オフスクリーンレンダリングロジックは、ウィンドウ丸み付け、色変換、回転、およびスケーリングのうちの少なくとも1つを含む、ことと、第3のプロセスが第1のプロセスのインターフェースのオフスクリーンレンダリングロジックに基づいて第1のレンダツリーのレンダリングプロパティにオフスクリーンレンダリングプロパティを追加することであって、オフスクリーンレンダリングプロパティは、丸み付けプロパティ、色プロパティ、回転プロパティ、およびスケーリングプロパティのうちの少なくとも1つを含む、こととをさらに含む。オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックに1対1に対応し、オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックを実現するために、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて描画操作を修正するために使用される。
【0019】
前述の実施形態では、オフスクリーンレンダリングプロパティがレンダツリーに追加され、その結果、表面に描画操作を実行するプロセスにおいて、オフスクリーンレンダリングされたグラフィックは、オフスクリーンレンダリングプロパティに基づいて直接描画されることができ、ビットマップ全体にオフスクリーンレンダリングを実行し、次いで、描画が完了した後にレイヤ合成を実行する必要がない。これにより、オフスクリーンレンダリングを回避することができ、それによってレンダリング回数およびオフスクリーンレンダリングオーバーヘッドを低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【0020】
第1の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、第1のレンダツリーの基準座標系は、第1の座標系であり、第1の表示領域に対応する基準座標系は、第2の座標系であり、第1の座標系と第2の座標系とが異なるとき、前記方法は、第3のプロセスが第1の座標系および第2の座標系に基づいて第1のパラメータを決定し、第1のパラメータを第1のレンダツリーのレンダリングプロパティに追加することと、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスが第1のパラメータに基づいて第1の描画操作の基準座標系を修正することであって、第1の描画操作は、第1のレンダツリーに属する、こととをさらに含む。
【0021】
前述の実施形態では、アプリケーションによって生成されたレンダツリーの基準座標系と第3のプロセスがレンダツリー内で描画操作を実行する基準座標系とが異なるとき、正しい描画操作を実現するために、第1のパラメータがレンダリングプロパティに追加され、次いで、描画操作の基準座標系が第1のパラメータに基づいて変換される。
【0022】
第2の態様によれば、本出願の一実施形態で提供されるインターフェース生成方法は、第2の電子デバイス上で動作する第3のプロセスが第1のレンダツリーおよび第2のレンダツリーを受信することであって、第1のレンダツリーは、第1の電子デバイス上で動作する第1のプロセスによって生成され、第1のレンダツリーは、第1のプロセスのインターフェースを描画するために使用され、第2のレンダツリーは、第2の電子デバイス上で動作する第2のプロセスによって生成され、第2のレンダツリーは、第2のプロセスのインターフェースを描画するために使用される、ことと、第3のプロセスは、第1のレンダツリーおよび第2のレンダツリーに基づいてターゲットインターフェースを生成することであって、ターゲットインターフェースは、第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含み、ターゲットインターフェースは、第1の表示領域に表示される、こととを含む。
【0023】
前述の実施形態では、1つ以上のアプリケーションインターフェースを含むインターフェースが、表示領域内の1つ以上のアプリケーションのレンダツリーに基づいて生成され、それによってレンダリング回数を低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【0024】
第2の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成することは、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成することと、第3のプロセスが第1のターゲットレンダツリーに基づいて第1のターゲットインターフェースを生成することとを具体的には含む。
【0025】
前述の実施形態では、第3のプロセスは、1つ以上のアプリケーションのレンダツリーを1つのターゲットレンダツリーにマージしてもよく、その結果、インターフェースは、ターゲットレンダツリーに基づいて生成されてもよい。インターフェースは、1つ以上のアプリケーションのインターフェースを含む。1つ以上のアプリケーションを含むインターフェースは、1回のレンダリング、すなわち、レンダツリーからビットマップへの1回のレンダリングプロセスを介して生成されることができ、その結果、レンダリング回数が低減され、電子デバイスの消費電力が低減されることは明らかである。
【0026】
第2の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、第3のプロセスが、第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成することは、第3のプロセスが第1のターゲットレンダツリーのルートノードとしてルートレンダノードを作成し、第1のレンダツリーおよび第2のレンダツリーをルートレンダノードの子ノードとして使用することとを具体的には含む。
【0027】
前述の実施形態では、新しいルートノードが作成されてもよく、複数のアプリケーションのレンダツリーは、ターゲットレンダツリーの作成を実現するために、ルートノードの子ノードにマウントされてもよい。
【0028】
第2の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが第1のレンダツリーのZオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリー内のレンダノードを削除することであって、削除されたレンダノードが完全遮蔽ビューに対応する、ことをさらに含む。
【0029】
前述の実施形態では、第3のプロセスは、オーバードローを低減するために、ターゲットレンダツリー内のパラメータを最適化し、例えば、インターフェース内の完全に遮蔽されたビューに対応するレンダノードを削除してもよい。
【0030】
第2の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが第1のレンダツリーのZオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリーにおける描画操作を削除することであって、削除された描画操作が完全に遮蔽されたグラフィックに対応する、ことをさらに含む。
【0031】
前述の実施形態では、第3のプロセスは、オーバードローを低減するために、ターゲットレンダツリー内のパラメータを最適化し、例えば、インターフェース内の完全に遮蔽されたグラフィックに対応するレンダノードを削除してもよい。
【0032】
第2の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスは、第1の描画操作および第2の描画操作に対してマージまたはバッチを実行することであって、第1の描画操作は、第1のレンダツリーに属し、第2の描画操作は、第2のレンダツリーに属する、ことをさらに含む。
【0033】
前述の実施形態では、第3のプロセスは、インターフェース生成レートを増加させ、フレームフリーズを低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善するために、ターゲットレンダツリーにおける描画操作のマージまたはバッチをしてもよい。
【0034】
第2の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、前記方法は、第3のプロセスが、第1のプロセスのインターフェースのオフスクリーンレンダリングロジックを決定することであって、オフスクリーンレンダリングロジックは、ウィンドウ丸み付け、色変換、回転、およびスケーリングのうちの少なくとも1つを含む、ことと、第3のプロセスが第1のプロセスのインターフェースのオフスクリーンレンダリングロジックに基づいて第1のレンダツリーのレンダリングプロパティにオフスクリーンレンダリングプロパティを追加することであって、オフスクリーンレンダリングプロパティは、丸み付けプロパティ、色プロパティ、回転プロパティ、およびスケーリングプロパティのうちの少なくとも1つを含む、こととをさらに含む。オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックに1対1に対応し、オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックを実現するために、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて描画操作を修正するために使用される。
【0035】
前述の実施形態では、オフスクリーンレンダリングプロパティがレンダツリーに追加され、その結果、表面に描画操作を実行するプロセスにおいて、オフスクリーンレンダリングされたグラフィックは、オフスクリーンレンダリングプロパティに基づいて直接描画されることができ、ビットマップ全体にオフスクリーンレンダリングを実行し、次いで、描画が完了した後にレイヤ合成を実行する必要がない。これにより、オフスクリーンレンダリングを回避することができ、それによってレンダリング回数およびオフスクリーンレンダリングオーバーヘッドを低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【0036】
第2の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、第1のレンダツリーの基準座標系は、第1の座標系であり、第1の表示領域に対応する基準座標系は、第2の座標系であり、第1の座標系と第2の座標系とが異なるとき、前記方法は、第3のプロセスが第1の座標系および第2の座標系に基づいて第1のパラメータを決定し、第1のパラメータを第1のレンダツリーのレンダリングプロパティに追加することと、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスが第1のパラメータに基づいて第1の描画操作の基準座標系を修正することであって、第1の描画操作は、第1のレンダツリーに属する、こととをさらに含む。
【0037】
前述の実施形態では、アプリケーションによって生成されたレンダツリーの基準座標系と第3のプロセスがレンダツリー内で描画操作を実行する基準座標系とが異なるとき、正しい描画操作を実現するために、第1のパラメータがレンダリングプロパティに追加され、次いで、描画操作の基準座標系が第1のパラメータに基づいて変換される。
【0038】
第3の態様によれば、本出願の一実施形態は電子デバイスを提供する。電子デバイスは、1つ以上のプロセッサおよびメモリを含み、メモリは、1つ以上のプロセッサに結合され、メモリは、コンピュータプログラムコードを格納するように構成され、コンピュータプログラムコードは、コンピュータ命令を含み、1つ以上のプロセッサは、コンピュータ命令を呼び出し、その結果、電子デバイスは、以下の動作、すなわち、第1のプロセスが第1のレンダツリーを生成することであって、第1のレンダツリーは、第1のプロセスのインターフェースを描画するために使用される、ことと、第2のプロセスが第2のレンダツリーを生成することであって、第2のレンダツリーは、第2のプロセスのインターフェースを描画するために使用される、ことと、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成することであって、第1のターゲットインターフェースは、第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含み、第1のターゲットインターフェースは、第1の表示領域に表示される、こととを実行する。
【0039】
前述の実施形態では、1つ以上のアプリケーションインターフェースを含むインターフェースが、表示領域内の1つ以上のアプリケーションのレンダツリーに基づいて生成され、それによってレンダリング回数を低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【0040】
第3の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すように具体的には構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成することと、第3のプロセスが第1のターゲットレンダツリーに基づいて第1のターゲットインターフェースを生成する、こととを実行する。
【0041】
第3の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すように具体的には構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のターゲットレンダツリーのルートノードとしてルートレンダノードを作成し、第1のレンダツリーおよび第2のレンダツリーをルートレンダノードの子ノードとして使用する、ことを実行する。
【0042】
第3の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のレンダツリーのオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリー内のレンダノードを削除することであって、削除されたレンダノードは、完全に遮蔽されたビューに対応する、ことを実行する。
【0043】
第3の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のレンダツリーのオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリー内の描画操作を削除することであって、削除された描画操作は、完全に遮蔽されたグラフィックに対応する、ことを実行する。
【0044】
第3の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスが第1の描画操作および第2の描画操作に対してマージまたはバッチを実行することであって、第1の描画操作は第1のレンダツリーに属し、第2の描画操作は第2のレンダツリーに属する、ことを実行する。
【0045】
第3の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のプロセスのインターフェースのオフスクリーンレンダリングロジックを決定することであって、オフスクリーンレンダリングロジックは、ウィンドウ丸み付け、色変換、回転、およびスケーリングのうちの少なくとも1つを含む、ことと、第3のプロセスが第1のプロセスのインターフェースのオフスクリーンレンダリングロジックに基づいて第1のレンダツリーのレンダリングプロパティにオフスクリーンレンダリングプロパティを追加することであって、オフスクリーンレンダリングプロパティは、丸み付けプロパティ、色プロパティ、回転プロパティ、およびスケーリングプロパティのうちの少なくとも1つを含む、こととを実行する。オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックに1対1に対応し、オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックを実現するために、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて描画操作を修正するために使用される。
【0046】
第3の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1の座標系および第2の座標系に基づいて第1のパラメータを決定し、第1のパラメータを第1のレンダツリーのレンダリングプロパティに追加することと、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスが第1のパラメータに基づいて第1の描画操作の基準座標系を修正することであって、第1の描画操作は、第1のレンダツリーに属する、こととを実行する。
【0047】
第4の態様によれば、本出願の一実施形態は電子デバイスを提供する。電子デバイスは、1つ以上のプロセッサおよびメモリを含み、メモリは、1つ以上のプロセッサに結合され、メモリは、コンピュータプログラムコードを格納するように構成され、コンピュータプログラムコードは、コンピュータ命令を含み、1つ以上のプロセッサは、コンピュータ命令を呼び出し、その結果、電子デバイスは以下の動作、すなわち、第2の電子デバイス上で動作する第3のプロセスが第1のレンダツリーおよび第2のレンダツリーを受信することであって、第1のレンダツリーは、第1の電子デバイス上で動作する第1のプロセスによって生成され、第1のレンダツリーは、第1のプロセスのインターフェースを描画するために使用され、第2のレンダツリーは、第2の電子デバイス上で動作する第2のプロセスによって生成され、第2のレンダツリーは、第2のプロセスのインターフェースを描画するために使用される、ことと、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいてターゲットインターフェースを生成することであって、ターゲットインターフェースは、第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含み、ターゲットインターフェースは、第1の表示領域に表示される、こととを実行する。
【0048】
前述の実施形態では、1つ以上のアプリケーションインターフェースを含むインターフェースが、表示領域内の1つ以上のアプリケーションのレンダツリーに基づいて生成され、それによってレンダリング回数を低減し、電子デバイスの消費電力を低減し、ユーザ体験を改善する。
【0049】
第4の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すように具体的には構成され、その結果、電子デバイスが以下の動作、すなわち、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成することと、第3のプロセスが第1のターゲットレンダツリーに基づいて第1のターゲットインターフェースを生成することとを実行する。
【0050】
第4の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すように具体的には構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のターゲットレンダツリーのルートノードとしてルートレンダノードを作成し、第1のレンダツリーおよび第2のレンダツリーをルートレンダノードの子ノードとして使用する、ことを実行する。
【0051】
第4の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のレンダツリーのオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリー内のレンダノードを削除することであって、削除されたレンダノードは、完全に遮蔽されたビューに対応する、ことを実行する。
【0052】
第4の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のレンダツリーのオーダーおよび第2のレンダツリーのZオーダーに基づいて第1のターゲットレンダツリー内の描画操作を削除することであって、削除された描画操作は、完全に遮蔽されたグラフィックに対応する、ことを実行する。
【0053】
第4の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスが第1の描画操作および第2の描画操作に対してマージまたはバッチを実行することであって、第1の描画操作は第1のレンダツリーに属し、第2の描画操作は第2のレンダツリーに属する、ことを実行する。
【0054】
第4の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1のプロセスのインターフェースのオフスクリーンレンダリングロジックを決定することであって、オフスクリーンレンダリングロジックは、ウィンドウ丸み付け、色変換、回転、およびスケーリングのうちの少なくとも1つを含む、ことと、第3のプロセスが第1のプロセスのインターフェースのオフスクリーンレンダリングロジックに基づいて第1のレンダツリーのレンダリングプロパティにオフスクリーンレンダリングプロパティを追加することであって、オフスクリーンレンダリングプロパティは、丸み付けプロパティ、色プロパティ、回転プロパティ、およびスケーリングプロパティのうちの少なくとも1つを含む、こととを実行する。オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックに1対1に対応し、オフスクリーンレンダリングプロパティは、オフスクリーンレンダリングロジックを実現するために、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて描画操作を修正するために使用される。
【0055】
第4の態様のいくつかの実施形態を参照すると、いくつかの実施形態では、1つ以上のプロセッサは、コンピュータ命令を呼び出すようにさらに構成され、その結果、電子デバイスは以下の動作、すなわち、第3のプロセスが第1の座標系および第2の座標系に基づいて第1のパラメータを決定し、第1のパラメータを第1のレンダツリーのレンダリングプロパティに追加することと、第3のプロセスが第1のレンダツリーおよび第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するプロセスにおいて、第3のプロセスが第1のパラメータに基づいて第1の描画操作の基準座標系を修正することであって、第1の描画操作は、第1のレンダツリーに属する、こととを実行する。
【0056】
第5の態様によれば、本出願の一実施形態はチップシステムを提供する。チップシステムは電子デバイスに適用され、チップシステムは、1つ以上のプロセッサを含み、プロセッサは、コンピュータ命令を呼び出すように構成され、その結果、電子デバイスは、第1の態様および第2の態様ならびに第1の態様および第2の態様の可能な実装形態のいずれか1つによる方法を行う。
【0057】
第6の態様によれば、本出願の一実施形態は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品が電子デバイス上で動作すると、電子デバイスは、第1の態様および第2の態様ならびに第1の態様および第2の態様の可能な実装形態のいずれか1つによる方法を行うことを可能にされる。
【0058】
第7の態様によれば、本出願の一実施形態は、命令を含むコンピュータ可読記憶媒体を提供する。コンピュータ命令が電子デバイス上で動作されると、電子デバイスは、第1の態様および第2の態様ならびに第1の態様および第2の態様の可能な実装形態のいずれか1つによる方法を行うことを可能にされる。
【0059】
第3の態様および第4の態様で提供される電子デバイス、第5の態様で提供されるチップシステム、第6の態様で提供されるコンピュータプログラム製品、および第7の態様で提供されるコンピュータ記憶媒体はすべて、本出願の実施形態で提供される方法を行うために使用されることが理解されよう。したがって、達成され得る有益な効果については、上記の対応する方法の有益な効果を参照されたい。本明細書では詳細は再び説明されない。
【図面の簡単な説明】
【0060】
【図1A】本出願の一実施形態による電子デバイスのインターフェースの一例の概略図である。
【図1B】本出願の一実施形態による電子デバイスの表示インターフェースの一例の概略図である。
【図2】本出願の一実施形態による、アプリケーションによってビットマップを生成する一例の概略図である。
【図3】本出願の一実施形態によるレンダツリーの一例の概略図である。
【図4】本出願の一実施形態による、ビットマップがレイヤ合成に関与するためのレイヤとして使用される一例の概略図である。
【図5】本出願の一実施形態によるレイヤ合成の一例の概略図である。
【図6】本出願の一実施形態による、SurfaceFlingerがレイヤ合成を実行する他の例の概略図である。
【図7A】本出願の一実施形態によるレイヤ合成の他の例の概略図である。
【図7B-1】本出願の一実施形態によるレイヤ合成の他の例の概略図である。
【図7B-2】本出願の一実施形態によるレイヤ合成の他の例の概略図である。
【図8】本出願の一実施形態によるインターフェース生成方法のシステムアーキテクチャの一例の概略図である。
【図9】本出願の一実施形態によるインターフェース生成方法の一例の概略図である。
【図10】本出願の一実施形態によるUniRenderのアーキテクチャの一例の概略図である。
【図11】本出願の一実施形態による、共有メモリがレンダツリーを転送する一例の概略図である。
【図12A】本出願の一実施形態による共有メモリにおけるレンダツリーの記憶構造の一例の概略図である。
【図12B】本出願の一実施形態による共有メモリにおけるレンダツリーの記憶構造の一例の概略図である。
【図13】本出願の一実施形態によるUniRenderのアーキテクチャの一例の概略図である。
【図14】本出願の一実施形態による、アプリケーションがレンダツリーを共有メモリに書き込む一例の概略図である。
【図15】本出願の一実施形態による、アプリケーションがレンダツリーを共有メモリに書き込む他の例の概略図である。
【図16A-1】本出願の一実施形態による、オフスクリーンレンダリングをトリガする描画ロジックのシナリオの一例の概略図である。
【図16A-2】本出願の一実施形態による、オフスクリーンレンダリングをトリガする描画ロジックのシナリオの一例の概略図である。
【図16B】本出願の一実施形態による、オフスクリーンレンダリングをトリガする描画ロジックのシナリオの一例の概略図である。
【図16C】本出願の一実施形態による、オフスクリーンレンダリングをトリガする描画ロジックのシナリオの一例の概略図である。
【図17A】本出願の一実施形態による、UniRenderがオフスクリーンレンダリングトリガ命令を移行させる一例の概略図である。
【図17B】本出願の一実施形態による、UniRenderがオフスクリーンレンダリングトリガ命令を移行させる一例の概略図である。
【図18】本出願の一実施形態による、UniRenderがレンダツリーのレンダノードプロパティを修正する一例の概略図である。
【図19】本出願の一実施形態による、オフスクリーンレンダリング命令が1つのターゲットレンダツリーに移行された後に取得された複数のレンダツリーをマージする一例の概略図である。
【図20】本出願の一実施形態による、オフスクリーンレンダリング命令が1つのターゲットレンダツリーに移行された後に取得された複数のレンダツリーをマージする一例の概略図である。
【図21】本出願の一実施形態によるsetStaticMatrix（）の一例の概略図である。
【図22A】本出願の一実施形態によるマルチ表示領域シナリオの一例の概略図である。
【図22B】本出願の一実施形態によるマルチ表示領域シナリオの一例の概略図である。
【図22C】本出願の一実施形態によるマルチ表示領域シナリオの一例の概略図である。
【図23A-1】本出願の一実施形態によるマルチ表示領域シナリオの他の例の概略図である。
【図23A-2】本出願の一実施形態によるマルチ表示領域シナリオの他の例の概略図である。
【図23B】本出願の一実施形態によるマルチ表示領域シナリオの他の例の概略図である。
【図23C】本出願の一実施形態によるマルチ表示領域シナリオの他の例の概略図である。
【図24】本出願の一実施形態によるインターフェース生成方法の他の例の概略図である。
【図25】本出願の一実施形態による、UniRenderプロセスが垂直同期信号に対して周波数分割または周波数逓倍を実行する一例の概略図である。
【図26A】本出願の一実施形態による、電子デバイスがインターフェース生成方法を実現するときのデータフローの一例の概略図である。
【図26B】本出願の一実施形態による、電子デバイスがインターフェース生成方法を実現するときのデータフローの一例の概略図である。
【図27】本出願の一実施形態によるインターフェース生成方法の他の例の概略図である。
【図28A】本出願の一実施形態による、レンダツリーをターゲットレンダツリーにマージする一例の概略図である。
【図28B】本出願の一実施形態による、レンダツリーツリをターゲットレンダツリーにマージする一例の概略図である。
【図29】本出願の一実施形態による電子デバイスのハードウェア構造の概略図である。
【図30】本出願の一実施形態による電子デバイスのソフトウェア構造の一例の概略図である。
【発明を実施するための形態】
【0061】
以下の実施形態で使用される用語は、特定の実施形態を説明することを意図されているにすぎず、本出願を限定することを意図されたものではない。本出願の明細書で使用される単数形の表現「ある」、「1つ」、「その」、「前述の」、「この」、および「その1つ」は、文脈において明確に別段の指定がない限り、複数形の表現も含むことが意図される。本出願で使用される「および／または」という用語は、1つ以上の記載された項目のありとあらゆる可能な組み合わせを示し、また含むことをさらに理解されたい。
【0062】
以下の「第1」および「第2」という用語は、説明目的で使用されるにすぎず、相対的な重要性を示すもしくは暗に示す、または示された技術的特徴量を暗に示すものとして理解されるべきではない。したがって、「第1」または「第2」によって限定されている特徴は、1つ以上のこのような特徴を明示的または暗黙的に含んでもよい。本出願の実施形態の説明では、別段の指定がない限り、「複数の」は、2つ以上を意味する。
【0063】
本出願の以下の実施形態における「ユーザインターフェース（user interface、UI）」という用語は、アプリケーションまたはオペレーティングシステムとユーザとの間のインタラクションおよび情報交換のための媒体インターフェースであり、情報の内部形式とユーザが受け入れ可能な形式との間の変換を実現する。ユーザインターフェースは、javaまたは拡張可能なマークアップ言語（extensible markup language、XML）などの特定のコンピュータ言語でコンパイルされたソースコードである。インターフェースソースコードは、電子デバイス上で構文解析およびレンダリングされ、ユーザが認識できる内容として最終的に提示される。ユーザインターフェースの一般的な提示形態は、グラフィカルな方式で表示され、コンピュータ操作に関連されるユーザインターフェースを指すグラフィックユーザインターフェース（graphic user interface、GUI）である。GUIは、電子デバイスのディスプレイ上に表示される可視インターフェース要素、例えば、テキスト、アイコン、ボタン、メニュー、タブ、テキストボックス、ダイアログボックス、ステータスバー、ナビゲーションバー、またはWidgetであってもよい。
【0064】
理解を容易にするために、以下では、本出願の実施形態における関連する用語および関連する概念について最初に説明する。本発明の実施形態で使用される用語は、本発明の特定の実施形態を説明するために使用されるにすぎず、本発明を限定することを意図されたものではない。
【0065】
インターフェースは、アプリケーションとユーザとの間のインタラクションおよび情報交換のための媒体インターフェースとして使用される。垂直同期信号が到着する度に、電子デバイスは、フォアグラウンドアプリケーションのために、そのアプリケーションのインターフェースを生成する必要がある。垂直同期信号の周波数は、電子デバイスの画面のリフレッシュレートに関連される。例えば、垂直同期信号の周波数は、電子デバイスの画面のリフレッシュレートと同じである。
【0066】
具体的には、電子デバイスが画面上に表示された内容をリフレッシュする前に、電子デバイスは、毎回、フォアグラウンドアプリケーション用のアプリケーションインターフェースを生成する必要がある。この場合、画面がリフレッシュされると、新しく生成されたアプリケーションインターフェースがユーザに表示される。
【0067】
電子デバイスによって電子デバイス上に表示されたインターフェースは、1つ以上のアプリケーションのインターフェースを含んでもよく、すなわち、電子デバイスは、画面上に表示される合成されたインターフェースを取得するために、1つ以上のアプリケーションのインターフェースを生成し、インターフェースを合成する必要がある。
【0068】
電子デバイスがアプリケーションのインターフェースを生成するとき、アプリケーションは、ビットマップ（bitmap）をレンダリングおよび生成し、アプリケーションのビットマップをサーフェスコンポーザ（SurfaceFlinger）に転送する必要がある。すなわち、アプリケーションは、プロデューサとして機能し、ビットマップを描画および生成し、SurfaceFlingerによって提供されるバッファキュー（BufferQueue）に格納する。SurfaceFlingerは、コンシューマとして機能し、アプリケーションによって生成されたビットマップをBufferQueueから継続的に取得する。ビットマップは、アプリケーションによって生成されたsurface上に位置する。surfaceは、BufferQueueに入れられる。
【0069】
SurfaceFlingerが可視アプリケーションのビットマップを取得した後、SurfaceFlingerおよびハードウェア合成ポリシーモジュール（Hardware Composer、HWC）は、ビットマップがレイヤ（layer）として使用されるレイヤ合成モードを決定する。SurfaceFlingerは、ウィンドウ・マネージャ・サービス（Window Manager Service、WMS）を使用することによって可視アプリケーションを決定してもよい。
【0070】
ウィンドウ・マネージャ・サービスからアプリケーションのウィンドウに作用する、丸み付け、回転、色変換、およびスケーリングなどのオフスクリーンレンダリングロジックを取得した後、SurfaceFlingerは、レンダリングのためにアプリケーションのビットマップをオフスクリーンバッファにコピーし、オフスクリーンレンダリングを介してレイヤ合成のためのビットマップを取得してもよい。
【0071】
アプリケーションビットマップが合成された後、SurfaceFlinger／HWCは、ディスプレイサブシステム（Display Subsystem、DSS）への転送のために、合成されたビットマップ（ビットマップは、SurfaceFlinger上のレイヤと称さてもよい）をフレームバッファ（Frame Buffer）に入れる。合成ビットマップを取得した後、DSSは、合成ビットマップを画面上に表示してもよい。フレームバッファは、オンスクリーンバッファ（on－screenbuffer）であってもよい。
【0072】
（1）最初に、（1．1）アプリケーションによってビットマップを生成するプロセス、（1．2）SurfaceFlinger／HWCによってビットマップを合成するプロセス、（1．3）オフスクリーンレンダリングの例を別々に説明する。
【0073】
【0074】
図1Aに示されるように、電子デバイスの画面には、アプリケーション1およびアプリケーション2のインターフェースが表示される。アプリケーション1のインターフェースは、ステータスバーと称されてもよい。図1Aにおいて、アプリケーション1は、オペレーティングシステムであってもよく、アプリケーション2は、音楽アプリケーションであってもよい。
【0075】
図1Aに示されるインターフェースを表示する前に、電子デバイスは、アプリケーションのビットマップを別々に独立して生成する必要がある。ステータスバーのインターフェースは、オペレーティングシステムによって維持され、すなわち、ステータスバーのビットマップを生成するアプリケーションは、オペレーティングシステムであると考えられてもよい。具体的には、オペレーティングシステムは、ビットマップ1を生成した後、ビットマップ1をSurfaceFlingerへ転送し、音楽アプリケーションは、ビットマップ2を生成した後、ビットマップ2をSurfaceFlingerへ転送する。ビットマップ1は、ステータスバーの画像情報を運び、ビットマップ2は、音楽アプリケーションの画像情報を運ぶ。
【0076】
ビットマップ1およびビットマップ2を受信した後、SurfaceFlinger／HWCは、レイヤ合成を実行するために、ビットマップ1およびビットマップ2をレイヤとして使用する。レイヤ合成の内容については、（1．2）SurfaceFlinger／HWCによってビットマップを合成するプロセスの説明文を参照されたく、本明細書では詳細は再び説明されない。
【0077】
図1Bに示されるように、電子デバイスの画面には、アプリケーション1、アプリケーション2、アプリケーション3のインターフェースが表示される。アプリケーション1のインターフェースは、ステータスバーと称されてもよい。図1Bでは、アプリケーション1は、オペレーティングシステムであってもよく、アプリケーション2は、ブラウザアプリケーションであってもよく、アプリケーション3は、SMSアプリケーションであってもよい。
【0078】
図1Bに示されるインターフェースを表示する前に、電子デバイスはまた、アプリケーションのビットマップを別々に独立して生成する必要がある。
【0079】
具体的には、ビットマップ3を生成した後、オペレーティングシステムは、ビットマップ3をSurfaceFlingerへ転送し、ビットマップ4を生成した後、SMSアプリケーションは、ビットマップ4をSurfaceFlingerへ転送し、ビットマップ5を生成した後、ニュースアプリケーションは、ビットマップ5をSurfaceFlingerへ転送する。ビットマップ3は、ステータスバーの画像情報を運び、ビットマップ4は、SMSアプリケーションの画像情報を運び、ビットマップ5は、ニュースアプリケーションの画像情報を運ぶ。
【0080】
ビットマップ3、ビットマップ4、およびビットマップ5を受信した後、SurfaceFlinger／HWCは、レイヤ合成を実行するために、ビットマップ3、ビットマップ4、およびビットマップ5をレイヤとして使用する。レイヤ合成の内容については、（1．2）SurfaceFlinger／HWCによってビットマップを合成するプロセスの説明文を参照されたく、本明細書では詳細は再び説明されない。
【0081】
アプリケーションによってビットマップを生成するプロセスが図2に示される。
【0082】
図2は、本出願の一実施形態による、アプリケーションによってビットマップを生成する一例の概略図である。
【0083】
図2に示されるように、垂直同期信号（Vsync－APP）を受信した後、アプリケーションは、ビットマップを生成することを開始する。具体的なステップは、以下の3つのステップを含む。
【0084】
［1］ビュー構造（viewhierarchy）が無効化される。メインスレッド（UIスレッド、UI Thread）は、アプリケーションのビュー（view）を横断し、各ビューの描画操作を決定および格納し、ビューおよびビューに関連する描画操作（Draw Operation Struct、DrawOP）をレンダツリーのレンダノード（RenderNode）の描画命令リスト（displaylist）に記録する。
【0085】
ビューは、アプリケーションインターフェースを形成する基本要素であり、インターフェース上の1つの制御は、1つ以上のビューに対応してもよい。
【0086】
描画操作は、データ構造であり、グラフィックの描画、例えば、線の描画、幅の描画、矩形の描画、テキストの描画などに使用される。描画操作は、レンダノード上の画像処理ライブラリのAPI呼び出し、例えば、OpenGLのAPI呼び出しに変換される。例えば、DrawLineOpは、データ構造であり、そのデータ構造は、線の長さや幅などの描画データに関する情報を含む。
【0087】
描画命令リストはバッファであってもよく、そのバッファは、アドレスおよびシーケンス番号など、アプリケーションのインターフェースの1つのフレームに含まれるすべての描画操作またはすべての描画操作の識別子を記録する。アプリケーションが複数のウィンドウを有するとき、または異なる表示領域（display）に表示されるとき、複数のレンダツリーは、独立して生成される必要がある。異なるウィンドウまたは表示領域に対応する複数の描画命令リストが独立して生成される。
【0088】
本出願の実施形態では、表示領域は、画面、仮想画面（VirtualDisplay）などであってもよい。仮想画面は、画面記録中に画面上に表示される内容を運ぶために電子デバイスによって使用される領域であってもよい。
【0089】
レンダツリーは、UIスレッドによって生成され、アプリケーションインターフェースのデータ構造を生成するために使用される。レンダツリーは、複数のレンダノードを含んでもよく、各レンダノードは、レンダリングプロパティおよび描画命令リストを含む。レンダツリーは、アプリケーションの1つのフレームインターフェースを生成するためのすべての情報を記録する。
【0090】
［2］UIスレッドは、レンダツリーをレンダスレッド（Render Thread）に転送／同期し、レンダツリーは、アプリケーションに対応するプロセスのスタック（stack）に位置し、物理アドレスの点で連続的に分布されなくてもよい。
【0091】
［3］レンダスレッドは、ハードウェアキャンバス（HardwareCanvas）を最初に取得し、ビットマップを生成するために、ハードウェアキャンバス上でレンダツリー内の描画操作を実行する。ハードウェアキャンバスは、アプリケーションによって保持されたsurface上に位置し、そのsurfaceは、画像情報を格納するために使用される他のフォーマットのビットマップまたはデータを運ぶ。
【0092】
［1］は、アプリケーション内の各viewのサイズ、位置、および透過度などのプロパティを決定する役割を主に担う構築フェーズであると考えられてもよい。例えば、ビュー内のdrawLineは、構築中にDrawLineOpにパッケージ化されてもよく、そのDrawLineOpは、線の長さおよび幅などの描画データを含み、基礎となるグラフィックス処理ライブラリのdrawLineOPに対応するインターフェース呼び出しをさらに含んでもよく、レンダリングフェーズにおいてビットマップを生成するための基礎となるグラフィックスライブラリを呼び出すために使用される。
【0093】
同様に、［3］は、レンダツリーのレンダノードを横断し、各レンダノードに対して描画操作を実行し、ハードウェアキャンバス上でビットマップを生成する役割を主に担うレンダリングフェーズであると考えられてもよい。このプロセスにおいて、レンダスレッドは、レンダリングを遂行するためのGPUを呼び出すために、基礎となるグラフィックス処理ライブラリ、例えばOpenGLを呼び出して、ビットマップを生成する。
【0094】
図3は、本出願の一実施形態によるレンダツリーの一例の概略図である。
【0095】
アプリケーションによって表示される必要があるインターフェースは、複数のネストされたviewを含み、異なるviewは、親子関係を有する。したがって、viewを横断することによって生成されたレンダツリーのレンダノード間の親子関係は、view間の親子関係と同じである。言い換えれば、view間の親子関係は、異なるレンダノード間のネスト関係を決定する。そして、レンダスレッドは、レンダツリーに従ってビットマップを生成するときにアプリケーションのインターフェースを正しくレンダリングすることができる。
【0096】
1つのviewは、1つ以上のレンダノードに対応してもよい。ルートビュー（DecorView）は、ルートレンダノード（RootRenderNode）に対応する。言い換えれば、レンダノード間のネスト関係は、view間の親子関係に対応する。レンダノードは、レンダリングを介してビットマップが生成されるとき、surface上のレンダノードに対応するviewの位置、サイズ、透過度などを決定するために使用されるレンダリングプロパティ（properties）をさらに含む。
【0097】
例えば、アプリケーションのインターフェースの構造は、以下の通りである：アプリケーションのPhoneWindowは、ルートビューを運び、ルートビューの子ビューは、ビュー1およびビュー2であり、ビュー2の子ビューは、ビュー3である。この場合、アプリケーションのUIスレッドによって生成されたレンダツリーの構造は、以下の通りである：PhoneWindowに対応するルートレンダノードは、レンダツリーのルートノードであり、ルートレンダノードの子ノードは、ルートビューに対応するレンダノード0であり、レンダノード0の子ノードは、ビュー1に対応するレンダノード1およびビュー2に対応するレンダノード2であり、レンダノード2の子ノードは、ビュー3に対応するレンダノード3である。
【0098】
viewとレンダノードとの間の対応関係は、レンダノードが対応するviewにおけるすべての描画操作を含むことを意味する。
【0099】
UIスレッドによって同期されたレンダツリーを受信した後、レンダスレッドは、アプリケーションのsurface上にビットマップをレンダリングするために、OpenGLインターフェースを呼び出し、合成および表示のためにsurfaceをSurfaceFlingerに送る。
【0100】
構築フェーズではCPUのコンピューティングリソースが占有される必要があり、レンダリングフェーズではGPUのリソースが占有される必要があることに留意されたい。
【0101】
ハードウェアアクセラレーションが有効化されていない場合、アプリケーションは、UIスレッドを使用することによって構築フェーズおよびレンダリングフェーズにおけるすべての操作を遂行し、レンダノードへのパッケージングを実行する必要がないことに留意されたい。アプリケーションのビューおよびビューの描画操作が横断された後、アプリケーションは、SurfaceFlingerに匿名共有メモリを申請し、ビットマップを生成するために、メモリ内の基礎となるグラフィックスライブラリを直接呼び出す。
【0102】
図2に示される内容は、ハードウェアアクセラレーションが有効化されたときにアプリケーションがビットマップを生成するプロセスであることに留意されたい。電子デバイス上でハードウェアアクセラレーションが有効化されていないとき、アプリケーションは、ソフトウェア描画を介してビットマップを生成する。ソフトウェア描画は、以下を含む。
【0103】
［1］ビュー構造（viewhierarchy）が無効化される。UIスレッドは、アプリケーションのビューを横断し、各ビューの描画操作を記録する。［2］UIスレッドは、インターフェース、例えば、Surface．lockCanvas（）を介して描画用のソフトウェアキャンバス（Canvas）を取得し、格納された描画操作リストに基づいてキャンバス上で描画を実行し、ビットマップを生成する。ソフトウェアキャンバスは、アプリケーションによって生成されたsurface上に位置する。
【0104】
アプリケーションによって保持されたsurfaceは、binder通信を介してSurfaceFlingerによってアプリケーションに割り当てられる。アプリケーションによって保持されるsurfaceの数は、アプリケーションの現在のウィンドウ（PhoneWindow）の数と同じであってもよい。
【0105】
アプリケーションによってビットマップを生成するプロセスが説明された後は、ビットマップを合成するプロセスが例を使用して説明される。
【0106】
（1．2）SurfaceFlinger／HWCによってビットマップを合成するプロセス
SurfaceFlingerは、電子デバイス上のシステムサービスであり、アプリケーションにsurfaceを割り当て、レイヤ合成のためのレイヤとして1つ以上のsurface上のビットマップを使用するために使用される。HWCは、電子デバイスにおける合成および表示の役割を担うハードウェア抽象化層（Hardware Abstraction Layer、HAL）の機能モジュールであり、上位レイヤのSurfaceFlingerのためにインターフェースを提供し、レイヤ合成を実行するために、基礎となるハードウェア（例えば、GPUを除くディスプレイドライバなど）の機能を呼び出す。
SurfaceFlingerは、電子デバイス上のシステムサービスであり、アプリケーションにsurfaceを割り当て、レイヤ合成のためのレイヤとして1つ以上のsurface上のビットマップを使用するために使用される。HWCは、電子デバイスにおける合成および表示の役割を担うハードウェア抽象化層（Hardware Abstraction Layer、HAL）の機能モジュールであり、上位レイヤのSurfaceFlingerのためにインターフェースを提供し、レイヤ合成を実行するために、基礎となるハードウェア（例えば、GPUを除くディスプレイドライバなど）の機能を呼び出す。
【0107】
図4は、本出願の一実施形態による、ビットマップがレイヤ合成に関与するためのレイヤとして使用される一例の概略図である。
【0108】
図4に示されるように、アプリケーションのレンダスレッドは、SurfaceFlingerによってアプリケーションに割り当てられたsurface上にビットマップを生成する。SurfaceFlingerは、BufferQueueメカニズムを使用することによって1つ以上のアプリケーションのsurfaceを維持する。言い換えれば、SurfaceFlingerは、異なるアプリケーションのビットマップを取得することができる。
【0109】
1つ以上のアプリケーションのビットマップを取得した後、SurfaceFlingerは、複数のビットマップを1つのビットマップに合成するために（ビットマップ合成はレイヤ合成と称される）、GPUを呼び出す。合成は、Client合成またはGLES合成と称されてもよい。
【0110】
アプリケーションのビットマップを取得した後、SurfaceFlingerは、合成のためにHWCを介して基礎となるハードウェア（GPUを除く）を呼び出してもよい。この合成モードは、Device合成とも称される。
【0111】
Client合成は、GPUを呼び出す必要があり、Client合成は、複数のレイヤを合成し、線形深化などのピクセルごとの処理方式でレイヤの合成を遂行してもよい。
【0112】
Device合成は、限られた数のレイヤを合成してもよく、複数ピクセルごとの処理方式での合成をサポートしない。Device合成が画面上に位置交差を有さない複数のレイヤを合成する場合、レイヤ合成は、実行されなくてもよい。代わりに、異なるsurface上のデータは、画面上の異なる位置が表示されるときに読み出されて表示される。
【0113】
図4に示されるように、アプリケーション1のビットマップ1、アプリケーション2のビットマップ2、…、およびアプリケーションNのビットマップNを取得した後、SurfaceFlingerは、ビットマップ11を生成するために、ビットマップ1およびビットマップ2に対してClient合成を実行してもよい。次いで、SurfaceFlingerは、基礎となるハードウェアを呼び出すために、HWCを使用することによってビットマップ11およびビットマップNに対してDevice合成を実行する。
【0114】
Device合成では、ビットマップ11とビットマップNが一時的に格納される。電子デバイスの画面上での表示が必要とされるとき、画面上での表示のためにビットマップ11／ビットマップNから対応する画素が取得される。例えば、図1Bに示されるインターフェースにおいて、ビットマップ11は、SMSアプリケーションおよびニュースアプリケーションによって合成されたビットマップであり、ビットマップNは、ステータスバーのビットマップである。
【0115】
SurfaceFlingerまたはHWCに対応する基礎となるハードウェアについて、各ビットマップは、1つのレイヤ（Layer）に相当する。
【0116】
レイヤ合成モードは、HWCに対応する基礎となるハードウェアによって決定されてもよく、またはSurfaceFlingerによって決定されてもよい。
【0117】
例えば、ビットマップを取得した後、SurfaceFlingerは、HWCを使用することによって基礎となるハードウェアに設定されたレイヤを転送し、基礎となるハードウェアは、Client合成が実行されるべき特定のレイヤおよびDevice合成が実行されるべき特定のレイヤを決定する。基礎となるハードウェアは、レイヤリスト内のレイヤの合成モードをマークし、異なるレイヤの合成モードをSurfaceFlingerに返す。SurfaceFlingerは、GPU合成でマークされたレイヤを合成し、合成結果をバッファに格納する。SurfaceFlingerは、Overlay合成モードでマークされたバッファおよび他のレイヤを、HWCを介して基礎となるハードウェアに転送する。次いで、基礎となるハードウェアがレイヤ合成を遂行する。
【0118】
他の例では、SurfaceFlingerは、レイヤ合成プロセスにおいて、GPU合成で、ウィンドウアニメーションなどのオフスクリーンレンダリングトリガロジックに関連するレイヤを直接マークする。オフスクリーンレンダリングトリガロジックは、丸み付け、スケーリング、回転、および色変換など、HWCに対応する基礎となるハードウェアによって処理することができないロジックをさらに含む。
【0119】
アプリケーションレンダスレッドによって生成されたビットマップに加えて、アプリケーションのSurfaceFlingerによってアプリケーションに割り当てられたsurfaceは、ウィンドウ・マネージャ・サービスから取得されたレイヤのZオーダーなどのウィンドウ制御情報をさらに含む。したがって、SurfaceFlingerは、レイヤがGPU合成を必要とするか否かを決定するために、surfaceからレイヤのウィンドウ制御情報を取得してもよい。レイヤのZオーダーは、Z軸上のレイヤの序列を決定し、Z軸は、画面に垂直な方向であり、異なるレイヤ間の上下関係を計算するために使用される。
【0120】
図5は、本出願の一実施形態によるレイヤ合成の一例の概略図である。
【0121】
図5に示されるように、アプリケーションのビットマップを取得した後、SurfaceFlingerは、各ビットマップをレイヤとしてレイヤリストに書き込む。SurfaceFlingerは、HWCを介して基礎となるハードウェアにレイヤリストを転送する。基礎となるハードウェアは、基礎となるハードウェアの機能に基づいて異なるレイヤの合成モードを決定し、結果をHWCを介してSurfaceFlingerに返す。
【0122】
HWCによって返された結果を取得した後、SurfaceFlingerは、レイヤリスト内の各レイヤの合成モードを取得してもよい。GPU合成でマークされたレイヤについて、SurfaceFlingerは、レイヤを合成し、合成されたレイヤおよびoverlay合成でマークされたレイヤをHWCを介して基礎となるハードウェアに転送する。次いで、HWCに対応する基礎となるハードウェアがレイヤを合成するために使用される。
【0123】
図6は、本出願の一実施形態による、SurfaceFlingerがレイヤ合成を実行する他の例の概略図である。
【0124】
複数のsurfaceを取得した後、SurfaceFlingerは、各surface上のレイヤとしてビットマップが使用される合成モードを決定してもよい。複数のレイヤを取得し、レイヤ合成モードがGPUであると決定した後、SurfaceFlingerは、Client合成を実行してもよい。レイヤ合成モードは、Mode．CLEAR（Zオーダーの最上位のレイヤを表示）、Mode．SRC＿OVER（Zオーダーに従ってレイヤを順に表示）、Mode．DST＿IN（Zオーダーの最上位のレイヤとその下のレイヤとの非交差部分を表示）などを含んでもよい。
【0125】
例えば、図6に示すように、レイヤ合成モードがMode．SRC＿OVERのとき、SurfaceFlingerは、3つのレイヤの内容を合成し、レイヤのZオーダーに従って異なるレイヤ間の上下関係を決定し、レイヤを1つのレイヤ上に順次重ねる。
【0126】
レイヤ1のZオーダーは、aであり、レイヤ2のZオーダーは、a＋1であり、レイヤ3のZオーダーは、a＋2である。SurfaceFlingerが3つのレイヤの内容を合成した後、レイヤ1およびレイヤ2の内容は完全に遮蔽され、レイヤ3の内容のみが表示される。
【0127】
完全遮蔽とは、より高いZオーダーのレイヤの遮蔽により、より低いZオーダーのレイヤのビューが表示されないことを意味する。
【0128】
GPU合成が実行されるレイヤは、オフスクリーンレンダリングをトリガする。レイヤ合成は、オフスクリーンレンダリングを介して実行される。以下では、オフスクリーンレンダリングに関連する概念について説明する。
【0129】
（1．3）オフスクリーンレンダリング
SurfaceFlingerは、GPUを使用することによって任意の複数のレイヤが合成される必要があると決定した場合、レイヤ合成を遂行するために、オフスクリーンレンダリング（off－screen rendering）が有効化される必要がある。
SurfaceFlingerは、GPUを使用することによって任意の複数のレイヤが合成される必要があると決定した場合、レイヤ合成を遂行するために、オフスクリーンレンダリング（off－screen rendering）が有効化される必要がある。
【0130】
オフスクリーンレンダリングは、SurfaceFlinger用のオフスクリーンバッファ（off－screenbuffer）を申請し、オフスクリーンバッファ内の画像処理のためにGPUを呼び出す。オフスクリーンバッファは、現在のスクリーンバッファの外部のメモリであり、複数のレイヤがオフスクリーンバッファ内で合成される。
【0131】
オフスクリーンレンダリングは、以下のステップを含んでもよい。
【0132】
［1］SurfaceFlingerによってGPU合成が決定されるレイヤ内のビットマップは、テクスチャ（texture）に変換される必要があり、次いで、GPUメモリ（すなわち、off－screenbuffer）にアップロードされるか、または共有メモリを介してOpenGLのテクスチャにマッピングされる必要がある。そして、OpenGLは、テクスチャを結合する（テクスチャを結合することは、コンテキストcontextを結合することを含む）。
【0133】
［2］テクスチャは、レイヤに対応するウィンドウアニメーションに関連する命令に従ってレンダリングされる。加えて、複数のアプリケーションのテクスチャがマージされる。レイヤ合成では、レイヤ合成モードに従って画素単位のレンダリング処理が実行される。
【0134】
［3］SurfaceFlingerは、GPUメモリからレンダリングされたテクスチャを取得するか、または共有メモリからレンダリングされたテクスチャを直接取得する。
【0135】
オフスクリーンレンダリングがコンテキスト（context）スイッチを引き起こし、コンテキストスイッチがさらなるパフォーマンスのオーバーヘッドを増加させることは明らかである。
【0136】
（1．1）アプリケーションによってビットマップを生成するプロセス、（1．2）SurfaceFlinger／HWCによってビットマップを合成するプロセス、および（1．3）オフスクリーンレンダリングの内容を参照して、ビットマップがレイヤとして使用される合成プロセスについて、以下で詳細に説明する。
【0137】
【0138】
図7Aに示すように、異なるアプリケーションのUIスレッドは、それぞれのレンダツリーを独立して生成し、ビットマップを生成するために、レンダツリーをそれぞれのレンダリング用レンダスレッドに転送する。
【0139】
レンダスレッドは、レンダツリー内のレンダノードのプロパティおよび描画命令リストに基づくレンダリングを介してビットマップを最初に生成し、ビットマップをレイヤとして使用することによって合成を実行する。レイヤ合成モードがGPU合成であるとき、SurfaceFlingerは、オフスクリーンレンダリングを介して複数のレイヤを1つのレイヤに合成する。
【0140】
例えば、アプリケーション1は、レンダツリー1を生成し、次いで、レンダツリー1に基づいてビットマップ1を生成し、アプリケーション2は、レンダツリー2を生成し、次いで、レンダツリー2に基づいてビットマップ2を生成する。ビットマップ1およびビットマップ2を受信した後、SurfaceFlingerは、ビットマップ5を生成するために、ビットマップ1およびビットマップ2に対してオフスクリーンレンダリングを実行する。オフスクリーンレンダリングプロセスにおいて、ビットマップ1は、オフスクリーンバッファに最初にコピーされ、ビットマップ1は、ウィンドウアニメーション情報に基づいてオフスクリーンバッファ内のビットマップ3に変換され、同様に、ビットマップ2は、ビットマップ4に変換され、最後に、ビットマップ3およびビットマップ4は、ビットマップ5を生成するために、レイヤ合成モードに基づいて重畳される。
【0141】
図7B－1および図7B－2に示されるように、図1Bに示されるインターフェースを実現するために、アプリケーションのビットマップを受信した後、SurfaceFlingerは、変換を遂行するためにウィンドウアニメーションビットマップに関連するアプリケーションのビットマップに対してオフスクリーンレンダリングを最初に実行し、次いで、変換されたレイヤを送信および表示のためにオンスクリーンバッファにコピーする。
【0142】
例えば、アプリケーション3のビットマップが縮小される必要がある場合、アプリケーション3のビットマップは、変換のためにオンスクリーンバッファに直接コピーされることができない。これは、他のアプリケーションのビットマップに影響を与え得る。代わりに、アプリケーション3のビットマップは、別々の変換のためにオフスクリーンバッファにコピーされる必要があり、変換結果はオンスクリーンバッファにコピーされて返される。
【0143】
各アプリケーションによって生成されたビットマップが最初に変更され、次いで、レイヤ合成モードに基づいて重畳されたときだけ、正しいインターフェースが生成されることができることは明らかである。
【0144】
アプリケーションのメインスレッドがレンダツリーを生成するときからSurfaceFlingerがレイヤ合成を遂行するときまで、GPUを呼び出すプロセスは変化し続けるので（アプリケーション1からアプリケーション2、…、アプリケーションN、およびSurfaceFlinger）、GPUは、少なくともN＋1回別々に開始される必要があり、ここでNは、アプリケーションの数である。
【0145】
異なるアプリケーションは、アプリケーションのビットマップを独立して構築およびレンダリングするが、より低いZオーダーを有するレイヤは、レイヤ合成中に、より高いZオーダーを有するレイヤによって完全に遮蔽され得ることが理解されよう。これは、必然的に、異なるアプリケーションのビットマップのオーバードロー（Overdraw）をもたらす。例えば、図6の3つのグラフィックスの重複部分がオーバードローされ、すなわち、レイヤ1およびレイヤ2がオーバードローされる。合成されたインターフェースは、レイヤ1およびレイヤ2によって影響されない。加えて、オフスクリーンレンダリングは、新たなオフスクリーンバッファ割り当ておよびコンテキストスイッチを必要とし、電子デバイスのメモリオーバーヘッドおよびコンピューティングオーバーヘッドを増加させる。
【0146】
（2）次いで、本出願の実施形態で提供されるインターフェース生成方法について以下に説明する。
【0147】
本出願の実施形態で提供されるインターフェース生成方法によれば、最初に1つ以上のアプリケーションのレンダツリーがUniRenderプロセスを使用することによって取得され、ターゲットレンダツリーを生成するために、1つ以上のレンダツリーが再グループ化される。次に、UniRenderプロセスは、レイヤ合成を実行することなく、1つ以上のアプリケーションのインターフェースの画像情報を運ぶビットマップを直接取得するために、ターゲットレンダツリーに基づいてレンダリングを実行する。
【0148】
最初に、本出願の実施形態で提供されるインターフェース生成方法では、1つ以上のアプリケーションのターゲットレンダツリーがターゲットレンダツリーにマージされる。ターゲットレンダツリーを生成するプロセスでは、UniRenderプロセスは、各レイヤのオフスクリーンレンダリングロジックを決定し、オフスクリーンレンダリングロジックに従ってターゲットレンダツリー内の対応するレンダノードのプロパティを追加または修正し、その結果、UniRenderプロセスは、オフスクリーンレンダリングを実行することなくビットマップを直接生成する。
【0149】
次いで、本出願の実施形態で提供されるインターフェース生成方法では、1つ以上のアプリケーションのターゲットレンダツリーがターゲットレンダツリーにマージされ、合成のためにレイヤとして複数のビットマップを最初に生成する必要はない。UniRenderプロセスがビットマップを生成するために、ターゲットレンダツリーに基づいてレンダリングを実行するプロセスでは、レイヤのZオーダーがレンダツリーのZオーダーとして使用され、表示されない、または表示に影響を与えないviewに対応するレンダノードが削除されてもよく、それによってオーバードローを回避する。
【0150】
最後に、本出願の実施形態で提供されるインターフェース生成方法によれば、アプリケーションは、レンダスレッドを生成しなくてもよいが、UniRenderプロセスは、統合レンダリングを実行することで、インターフェースのレンダリング速度を改善するのに貢献する。
【0151】
（2．1）本出願の実施形態で提供されるインターフェース生成方法のシステムアーキテクチャ
【0152】
図8は、本出願の一実施形態によるインターフェース生成方法のシステムアーキテクチャの一例の概略図である。
【0153】
アプリケーションのインターフェースが更新されると、アプリケーションは、UniRenderプロセス（図8にはSurfaceFlingerが示されていない）から垂直同期信号（Vsync－APP）を要求してもよい。SurfaceFlingerが存在するとき、アプリケーションは、SurfaceFlingerから垂直同期信号（Vsync－APP）を要求してもよい。
【0154】
UniRenderプロセスの垂直同期信号（Vsync－APP）は、SurfaceFlingerから生成されてもよく、もしくは、HWCに対応する基礎となるハードウェア（画面など）から直接生成されてもよく、または、垂直同期信号（Vsync－APP）は、周期的にウェイクアップされるスレッドを開始することでUniRenderプロセスによって生成される。SurfaceFlingerが存在するとき、Vsync－APPは、SurfaceFlingerからのものであってもよい。
【0155】
アプリケーションが垂直同期信号（Vsync－APP）を取得した後、アプリケーションは、レンダツリーを生成し、レンダツリーをUniRenderプロセスへ転送する。
【0156】
垂直同期信号（Vsync－UR）を受信した後、UniRenderプロセスは、ターゲットレンダツリーを生成するために、1つ以上のレンダツリーをマージする。次いで、UniRenderプロセスは、レンダツリー内の各レンダノードの描画命令リスト内の描画操作を横断および実行するために、レンダエンジンを使用し、1つ以上のレンダツリーの画像情報を運ぶビットマップを生成する。ビットマップは、オンスクリーンバッファ内に位置してもよい。
【0157】
Vsync－URとVsync－APPとの間の差は、Vsync－Offsetであり、Vsync－Offsetは、UniRenderプロセスによって決定されてもよい。SurfaceFlingerが存在する場合、Vsync－Offsetは、SurfaceFlingerによって決定されてもよい。
【0158】
ビットマップを生成した後、UniRenderプロセスは、表示のために、HWCを介してビットマップをディスプレイサブシステムに転送する。
【0159】
本出願におけるインターフェース生成方法のシステムアーキテクチャが説明された後は、本出願の実施形態で提供されるインターフェース生成方法の方法手順が例を使用して説明される。
【0160】
（2．2）本出願の実施形態で提供されるインターフェース生成方法の方法手順
図9を参照して、本出願の一実施形態で提供されるインターフェース生成方法の一例について以下に説明する。
図9を参照して、本出願の一実施形態で提供されるインターフェース生成方法の一例について以下に説明する。
【0161】
図9は、本出願の一実施形態によるインターフェース生成方法の一例の概略図である。
【0162】
図9に示されるように、本出願の本実施形態において提供されるインターフェース生成方法は、以下のステップを含む。
【0163】
S901：垂直同期信号を受信した後にレンダツリーを構築および生成する。
【0164】
インターフェースが更新される必要があるとき、アプリケーションは、UniRenderプロセスから垂直同期信号（Vsync－APP）を要求してもよい。垂直同期信号を受信した後、アプリケーションは、UIスレッドにおいてmeasure（）メソッド、layout（）メソッド、およびdraw（）メソッドを実行する。draw（）メソッドを実行するとき、UIスレッドは、アプリケーションのviewを横断し、各viewをレンダリングするために必要な描画命令を決定し、viewに対応するレンダノードの描画命令リストに描画命令を連続的に記録する。
【0165】
アプリケーションによって表示される必要があるインターフェースは、複数のネストされたviewを含み、ルートビュー（DecorView）に対応する描画命令リストは、ルートビューの子ビューの描画命令リストエントリを含み、すなわち、描画命令リスト間のネスト関係は、view間のネスト関係と同じである。したがって、レンダノード間のネスト関係は、view間のネスト関係と同じである。レンダツリーおよびレンダノードの関連概念の定義については、図3に対応する前述の説明文を参照されたい。
【0166】
図10は、本出願の一実施形態によるレンダツリーを構築する一例の概略図である。
【0167】
測定、レイアウト、および描画を実行した後、アプリケーションのUIスレッドは、更新されるべきインターフェースの複数のviewの親子構造を取得してもよく、viewを横断するプロセスにおいて、各viewに表示されるべき内容、および内容を生成するために必要なインターフェース呼び出し、例えば、drawCircleまたはdrawLineを決定してもよい。
【0168】
アプリケーションは、drawCircleやdrawLineなどの描画インターフェース呼び出しを、DrawCircleOpやDrawLineOpなどの対応するDrawOpにパッケージ化し、そのDrawOpを描画命令リストに格納する。DrawLineOpは、基礎となるグラフィックスライブラリ（OpenGLなど）のグラフィックス描画インターフェース呼び出しであり、GPUを呼び出すためのグラフィックス描画命令にさらに変換される。
【0169】
図10に示されるように、アプリケーションのインターフェースのビュー構造は、ルートビューを含み、ルートビューの子ビューは、ビュー1およびビュー2であり、ビュー2の子ビューは、ビュー3である。ビュー2は、矩形および円を含み、ビュー2に対応するレンダノード2の描画命令リストにおける描画操作は、矩形を描画する操作、円を描画する操作などを含む。
【0170】
draw（）メソッドを実行するとき、アプリケーションのUIスレッドは、ルートビューから開始し、view間の親子関係に基づいてすべてのviewを横断し、各viewにおける描画操作を決定し、その描画操作をDrawOpにパッケージ化してもよい。描画命令リストを生成した後、アプリケーションのUIスレッドは、その描画命令リストをレンダツリーにさらにパッケージ化する。
【0171】
レンダツリー内のレンダノードは、描画命令リストおよびレンダリングプロパティを含み、レンダリングプロパティは、surface上のレンダノードによってレンダリングされるべきviewの位置、サイズ、および透過度などのプロパティを決定するために使用され、描画命令リストは、レンダノードによってレンダリングされるべきviewの線、矩形、または円などの内容を決定するために使用される。
【0172】
surfaceは、アプリケーションによって申請される。アプリケーションは、surfaceのサイズを決定する。SurfaceFlingerが存在する場合、surfaceは、SurfaceFlingerからアプリケーションによって申請されてもよい。SurfaceFlingerが存在しない場合、surfaceは、UniRenderプロセスから申請されてもよい。SurfaceFlingerは、アプリケーションにsurfaceを割り当てなくてもよい。
【0173】
必要に応じて、本出願のいくつかの実施形態では、各表示領域の画面リフレッシュレートを決定した後、UniRenderプロセスは、各表示領域における垂直同期信号（Vsync－APP）の周波数を調整してもよく、その結果、表示領域1に表示されたアプリケーションは、表示領域1の画面リフレッシュレートの周波数でレンダツリーを生成する。
【0174】
アプリケーションのUIスレッドは、例えば、マルチ画面シナリオ、仮想画面シナリオ、またはマルチウィンドウシナリオなどのマルチ表示領域（display）シナリオで、複数のレンダツリーを生成してもよいことに留意されたい。マルチ表示領域シナリオについては、（2．2）マルチ表示領域シナリオにおけるインターフェース生成方法の説明文を参照されたい。
【0175】
S902：クロスプロセス方式でレンダツリーを転送する。
【0176】
レンダツリーを生成した後、アプリケーションのUIスレッドは、IPC通信を介してレンダツリーリングツリーをUniRenderプロセスに転送する。レンダツリーは、アプリケーションに対応するプロセスのスタック上にある。対応するUniRenderプロセスは、異なるアプリケーションによって転送されたレンダツリーを受信し、レンダツリーとアプリケーションとの間の対応関係を決定する必要がある。
【0177】
フォアグラウンド内の複数のアプリケーションは、レンダツリーをUniRenderに転送する。アプリケーションが以下の3つの条件のいずれか1つを満たす場合、アプリケーションは、フォアグラウンドアプリケーションである：アプリケーションは、可視アクティビティ（Activity）を有し、アプリケーションは、フォアグラウンドサービスを有し、他のフォアグラウンドアプリケーションは、アプリケーションに関連付けられている。
【0178】
異なるプロセスのメモリは共有されないので、プロセス間のデータ交換は、プロセス間通信（Inter－Process Communication、IPC）を介して遂行される必要がある。アプリケーションは、IPC通信を実現するために、Binder、AIDL、共有メモリ、またはSocketなどの方式でレンダツリーをUniRenderプロセスに転送してもよい。これは、本明細書では限定されない。
【0179】
以下では、クロスプロセス方式でレンダツリーを転送する方式の一例を説明するために、IPC通信の一例として共有メモリを使用する。
【0180】
（a）アプリケーションは、レンダツリーを共有メモリに書き込む。
【0181】
図11は、本出願の一実施形態による、共有メモリがレンダツリーを転送する一例の概略図である。
【0182】
図11に示されるように、最初に、アプリケーションが起動される度に、アプリケーションは、UniRenderプロセスに共有メモリを申請する。アプリケーションによって開始された共有メモリに対する要求を受信した後、UniRenderプロセスは、匿名共有メモリ（Anonymous Shared Memory、Ashmem）サブシステムを介して共有メモリおよび共有メモリに対応するハンドルを申請する。
【0183】
Ashmemサブシステムから共有メモリを正常に申請した後、UniRenderプロセスは、物理メモリの読み出しおよび書き込み用の、Ashmemサブシステムによって返されたハンドルを受信する。UniRenderプロセスは、ハンドルをアプリケーションに返し、その結果、アプリケーションは、レンダツリーを物理メモリに書き込むために、ハンドルを使用することができる。UniRenderプロセスは、UniRenderプロセスのプロセス空間から物理メモリを直接読み出し、次いで、アプリケーションのレンダツリーを直接読み出すことができる。
【0184】
共有メモリは、一時ファイルシステム（tmpfs）を使用することによってメモリ（RAM）に作成された仮想ファイルであってもよく、異なるプロセスのユーザ空間に別々にマッピングされる。
【0185】
例えば、アプリケーションがUniRenderプロセスから共有メモリを申請し、UniRenderプロセスがAshmemサブシステムから共有メモリを申請し、UniRenderプロセスがアプリケーションを介して取得された共有メモリに対応するハンドルをアプリケーションに返す、クロスプロセス通信は、Binder通信を介して実現されてもよい。
【0186】
アプリケーションプロセスのスタックに格納されたレンダツリーは、メモリ共有などの他のIPC方式でUniRenderプロセスに転送されてもよいことが理解されよう。これは、本明細書では限定されない。
【0187】
必要に応じて、本出願のいくつかの実施形態では、電子デバイスまたはクラウドサーバのローカル構成ファイルに信頼リストが構成され、信頼リストは、アプリケーションのパッケージ名などの、アプリケーションプロセスを一意に決定することができる他の識別子を格納する。アプリケーションが信頼リスト内にある場合、レンダツリーは、UniRenderプロセスへ転送される。アプリケーションが信頼リストにない場合、UIスレッドのソフトウェア描画またはレンダスレッドのレンダリングを介してビットマップが取得された後、ビットマップは、プロセス合成のためにUniRenderに転送されるか、またはビットマップは、SurfaceFlingerに転送される。SurfaceFlingerは、信頼リストにないアプリケーションのビットマップとUniRenderプロセスによって生成されたビットマップとを合成する。
【0188】
必要に応じて、本出願のいくつかの実施形態では、アプリケーションが複数のレイヤを有する場合、すなわち、アプリケーションが複数のレンダツリーを生成する場合、アプリケーションは、異なるレイヤを格納するために、すなわち、異なるレンダツリーのデータを格納するためにそれぞれ使用される2つの共有メモリをUniRenderプロセスに申請してもよい。
【0189】
必要に応じて、本出願のいくつかの実施形態では、アプリケーションは、レンダツリーを互い違いに書き込むために、2つの共有メモリをUniRenderプロセスに申請してもよい。例えば、フレームのインターフェースに対応するレンダツリーが第1の共有メモリに書き込まれる場合、次のフレームのインターフェースに対応するレンダツリーが第2の共有メモリに書き込まれ、次いで、次のフレームのインターフェースに対応するレンダツリーが第1の共有メモリに書き込まれる。これは、共有メモリが1つしかないときに、レンダツリーのデータは共有メモリに適時に書き込まれることができないという読み出し／書き込み競合を回避するのに役立つ。
【0190】
（b）共有メモリにおけるレンダツリーの記憶データ構造
IPC通信効率をさらに改善するために、本出願の本実施形態では、レンダツリーは、メモリツリーの形態で共有メモリに格納される。共有メモリに格納されるレンダツリーのデータ構造形態の一例について以下に説明する。
IPC通信効率をさらに改善するために、本出願の本実施形態では、レンダツリーは、メモリツリーの形態で共有メモリに格納される。共有メモリに格納されるレンダツリーのデータ構造形態の一例について以下に説明する。
【0191】
メモリツリーは、複数のデータセグメントを含んでもよく、異なるデータセグメントは、レイヤ情報、レンダリングデータなどをそれぞれ格納する。以下では、メモリツリーの構造を説明するために、図12Aおよび図12Bに示される内容を一例として使用する。共有メモリ内の異なるデータセグメントのオフセットは、固定されていてもよいし、固定されておらず適応的であってもよい。
【0192】
【0193】
図12Aに示されるように、レンダツリーの記憶構造は、HEADフィールド、MAPPINGフィールド、およびNODESフィールドの3つのデータセグメントを含む。
【0194】
HEADフィールドは、layerkeyおよびrootidを含み、MAPPINGフィールドは、nodeidおよびnodeidに対応するaddressを含み、NODESフィールドは、currentproperties、stagingproperties、stagingdisplaylist、およびcurrentdisplaylistを含む。
【0195】
layerkeyは、レイヤとしてのレンダツリー全体のIDであり、rootidは、レンダツリーのルートノードのIDであり、nodeidは、レンダツリーのルートノード以外のレンダノードのIDであり、1つのnodeidは、1つのaddressに対応し、addressは、レンダツリーノードにおけるレンダリングプロパティ（renderproperties／properties）および描画命令リスト（displaylist）の開始アドレスであり、stagingpropertiesは、アプリケーションによって書き込まれたレンダリングプロパティであり、stagingdisplaylistは、アプリケーションによって書き込まれた描画命令リストであり、currentpropertiesは、UniRenderプロセスによって読み出されたレンダリングプロパティであり、currentdisplaylistは、UniRenderプロセスによって読み出された描画命令リストである。
【0196】
「stagingpropertiesおよびstagingdisplaylist」は、第1のデータグループであり、「currentpropertiesおよびcurrentdisplaylist」は、第2のデータグループであると考えられることに留意されたい。この場合、アプリケーションに書き込まれるデータは、第1のデータグループであり、次にアプリケーションに書き込まれるデータは、第2のデータグループであり、それによってデュアルバッファ機構を実現する。同様に、UniRenderプロセスによって読み出されたデータは、第1のデータグループであり、次に読み出されるデータは、第2のデータグループである。
【0197】
必要に応じて、本出願のいくつかの実施形態では、共有メモリ内のレンダツリーの記憶構造が図12Bに示されてもよい。NODESフィールドは、1つのデータグループのみを含んでもよく、すなわち、レンダリングプロパティおよび描画命令リストのみを含んでもよい。
【0198】
layerkeyは、UniRenderプロセスがハンドルを使用することによって共有メモリ内のレイヤデータを読み出す前に、表示されるべきアプリケーションと、WMSから合成される必要があるアプリケーションのレイヤのIDとを取得するために使用される。UniRenderプロセスは、そのレイヤIDと共有メモリ内のlayerkeyに含まれるレイヤIDとを照合する。
【0199】
rootidは以下のために使用される：レンダツリーのエントリとして、rootidは、他のレンダノードのエントリを格納する。rootidを取得した後、UniRenderプロセスは、レンダツリーのデータを読み出し、レンダツリーのネストされた構造を復元してもよい。
【0200】
currentproperties、stagingproperties、stagingdisplaylist、およびcurrentdisplaylistは、以下、すなわち、アプリケーションが描画命令リストおよびレンダリングプロパティの書き込みを遂行した後、currentpropertiesおよびstagingpropertiesの値が交換され、currentdisplaylistおよびstagingdisplaylistの値が交換されるために使用される。UniRenderプロセスは、currentpropertiesおよびcurrent displaylistからレンダリングプロパティおよび描画命令リストを読み出す。
【0201】
例えば、アプリケーション1は、フォアグラウンドに表示されたアプリケーションであり、アプリケーション1は、複数のレイヤを有してもよい。具体的には、垂直同期信号（Vsync－APP）を受信した後、アプリケーション1は、複数のレンダツリー、例えば、レンダツリー1およびレンダツリー2を生成する。UniRenderプロセスは、WMSから、レイヤ合成に関与するレイヤに対応するレンダツリーがレンダツリー1であると決定する。
【0202】
layerkeyおよびrootidのオフセットは固定されているので、UniRenderプロセスは、ルートノードのアドレスを決定することができる。UniRenderプロセスは、MAPPINGフィールド内のNODES端上のルートノードの位置を検索し、ノードのレンダリング命令を読み出す。子ノードが存在する場合、対応するDrawRenderNode命令が存在する。命令には、子ノードのIDが格納される。MAPPINGフィールド内の子ノードの位置は、ハッシュ値に基づいて検索される。例えば、レンダツリーのレンダノード間の親子関係は、DrawOP操作に格納される。例えば、レンダノード2の描画命令リストは、いくつかのDrawOP操作と、「Draw RenderNode3」（レンダノード3の描画）の操作とを含み、その結果、UniRenderプロセスは、レンダノード3がレンダノード2の子ノードであると決定してもよい。
【0203】
共有メモリ内のレンダツリーは、アプリケーションのview間のネスト関係と同じネスト関係を依然として格納していることが理解されよう。したがって、UniRenderプロセスは、ルートノードからデータを読み出し、次いで、レンダツリーのすべてのデータを読み出してもよい。
【0204】
currentproperties、stagingproperties、stagingdisplaylist、およびcurrentdisplaylistが分類されて、UniRenderプロセスによって読み出された表示データおよびアプリケーションによって書き込まれたデータのセキュリティを確保し、アプリケーションによって完全に書き込まれていないデータがアプリケーションのインターフェースをレンダリングおよび生成するための最新データとしてUniRenderプロセスによって読み出されることを防止する。レンダツリーの同時読み出しと書き込みのセキュリティ保証については、（2．3）共有メモリ内のレンダツリーの読み出しおよび書き込みにおける以下の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0205】
必要に応じて、本出願のいくつかの実施形態では、3つのデータセグメントのサイズは固定されてもよい。具体的には、UniRenderプロセスがAshmemサブシステムから共有メモリを申請した後、取得された共有メモリのサイズは、a＋b＋cである。開始アドレス（物理アドレス）から開始アドレス＋aは、HEADフィールドが埋められる位置であり、開始アドレス＋a＋1から開始アドレス＋a＋bは、MAPPINGフィールドが埋められる位置であり、開始アドレス＋a＋b＋1から開始アドレス＋a＋b＋cは、NODESフィールドが埋められる位置である。
【0206】
3つのデータセグメントのサイズが固定されている場合、UniRenderプロセスは、Mappingフィールドを検索するために、固定オフセットに従って各データセグメントの先頭を決定してもよいことが理解されよう。Mappingフィールドは、各レンダノードのデータを検索するために、NODESフィールド内のレンダツリーのレンダノードのオフセットを格納する。
【0207】
必要に応じて、本出願のいくつかの実施形態では、3つのデータセグメントのサイズが固定されており、アプリケーションによって書き込まれたレンダノードのサイズがbを超える場合、アプリケーションは、第2の共有メモリをUniRenderプロセスに申請する。第2の共有メモリのフォーマットは、第1の共有メモリのフォーマットと同じであってもよく、レンダノードの描画命令リストおよびレンダノードプロパティは、第2の共有メモリのNODESフィールドに格納され続ける。第2の共有メモリのHEADフィールドおよび／またはMAPPINGフィールドは、ヌルであってもよく、または存在しなくてもよい。言い換えれば、本出願のいくつかの実施形態では、第2の共有メモリは、NODESフィールドのみを含む。
【0208】
（c）UniRenderは、共有メモリ内のレンダツリーを読み出す。
【0209】
（c．1）UniRenderアーキテクチャ
図13は、本出願の一実施形態によるUniRenderのアーキテクチャの一例の概略図である。
図13は、本出願の一実施形態によるUniRenderのアーキテクチャの一例の概略図である。
【0210】
図13に示されるように、本出願で提供されるUniRenderは、NodeManager、LayerManager、DisplayManager、およびUniRenderCoreの4つの部分を含んでもよい。
【0211】
NodeManagerは、UniRenderプロセスにおけるノード管理モジュールであり、アプリケーションによって送られたレンダツリーを受信する役割を担う。ターゲットレンダツリーの合成については、ステップS903の説明文を参照されたい。
【0212】
LayerManagerは、UniRenderプロセスにおけるレイヤ管理モジュールであり、ウィンドウ・マネージャ・サービス（Window Manager Service、WMS）からのレイヤ作成、レイヤ破棄、およびプロパティ変更などのレイヤ情報を同期させる役割を担う。1つのビットマップは、1つのレイヤに相当する。
【0213】
DisplayerManagerは、UniRenderプロセスにおける表示デバイス管理モジュールであり、ディスプレイ・マネージャ・サービス（Display Manager Service、DMS）から画面サイズなどの表示デバイスの情報を同期させる役割を担う。
【0214】
UniRenderCoreは、UniRenderプロセスにおけるレンダリング管理モジュールであり、レイヤごとに対応するレンダノードを確立し、NodeManagerで維持された異なるアプリケーションに対応するレンダツリーを受信し、LayerManagerでアプリケーションのレイヤ情報を命令にし、その命令をレンダノードに挿入し、DisplayManagerにおいて維持されたアクティブ化状態にある表示デバイスのすべての可視レイヤに対応するレンダツリーをマージし、表示領域毎にマージされたレンダツリーを横断する役割を担う。UniRenderは、UniRenderによって割り当てられたbuffer用のビットマップを生成する。
【0215】
（c．2）UniRenderは、レンダツリーを読み出す。
【0216】
UniRenderプロセスは、DMSおよびWMSから、各表示領域に表示されたアプリケーションを最初に決定し、アプリケーションは、レイヤ合成に関与するアプリケーションである。UniRenderプロセスは、信頼リストを参照して、UniRenderプロセスにおけるレイヤ合成を実行するアプリケーションをさらに決定してもよい。UniRenderプロセスは、WMSを使用することによって、各アプリケーションのレイヤIDを決定してもよい。
【0217】
UniRenderプロセスにおけるDisplayerManagerは、DMSと通信する役割を担い、UniRenderプロセスにおけるLayerManagerは、WMSと通信する役割を担う。
【0218】
UniRenderプロセスは、アプリケーションに対応する共有メモリのハンドルを格納するので、レイヤ合成に関与するアプリケーションを決定した後、UniRenderプロセスは、ハンドルを使用することによって、アプリケーションに対応する共有メモリを決定してもよい。UniRenderは、ハンドルを介して共有メモリからレンダツリーを読み出す。
【0219】
UniRenderプロセスにおけるNodeManagerは、共有メモリのハンドルを管理し、共有メモリからレンダツリーを読み出す役割を担う。
【0220】
UniRenderプロセスが共有メモリからレンダツリーを読み出すプロセスは、以下を含む。
【0221】
UniRenderプロセスは、共有メモリの開始アドレスからlayerkeyを最初に読み出し、レイヤIDを照合する。UniRenderプロセスは、WMSによって決定されたレイヤIDと、layerkeyから決定されたレイヤIDとを比較する。レイヤIDが一致した後、UniRenderプロセスは、ルートノードのrootidからレンダツリーを読み出す。
【0222】
次いで、ルートノードのアドレスを検索した後、UniRenderプロセスは、MAPPINGフィールド内のaddressフィールドにおいて、NODESフィールド内のルートノードの開始アドレスを決定し、レンダノードの描画命令リストおよびレンダリングプロパティの読み出しを開始する。ルートノードが子ノードを有する場合、ルートノードの描画リスト命令は、子ノードのエントリ、例えば、DrawRenderNode命令を格納する。DrawRenderNode命令が子ノードのIDを含むので、UniRenderプロセスは、ハッシュ演算を介してMAPPING内の対応するnodeidを検索し、NODESフィールド内の子ノードの描画命令リストおよびレンダリングプロパティの位置を決定し、子ノードの描画命令リストおよびレンダリングプロパティを読み出す。
【0223】
（d）共有メモリにおけるレンダツリーの読み出しおよび書き込み
共有メモリ内に位置するレンダツリーは、2つ以上のプロセスによって読み出しおよび書き込みがされてもよい。読み出しおよび書き込みの競合によって生じるレンダツリーのデータのエラーを低減および回避するために、プロセス間の同期ロックは、レンダツリーの読み出しおよび書き込みのセキュリティを確保するように構成されてもよい。
共有メモリ内に位置するレンダツリーは、2つ以上のプロセスによって読み出しおよび書き込みがされてもよい。読み出しおよび書き込みの競合によって生じるレンダツリーのデータのエラーを低減および回避するために、プロセス間の同期ロックは、レンダツリーの読み出しおよび書き込みのセキュリティを確保するように構成されてもよい。
【0224】
【0225】
図14は、本出願の一実施形態による、アプリケーションがレンダツリーを共有メモリに書き込む一例の概略図である。
【0226】
各アプリケーションは、アプリケーションとUniRenderが同時に共有メモリの読み出し／書き込みをすることを回避するために、少なくとも1つのロック変数Aを格納する。UniRenderは、IPC通信を介して異なるアプリケーション上のロック変数ステータス（保持または解放）を取得する。
【0227】
図14に示されるように、［1］最初に、アプリケーションがインターフェースを更新する必要があるとき、垂直同期信号（Vsync－APP）が要求および受信され、次いで、アプリケーションに対応する共有メモリのロック変数Aが取得され、レンダノードのプロパティおよび描画命令リストがルートノードから計算および更新される。
【0228】
［2］次いで、アプリケーションは、更新されたレンダノードのプロパティおよび描画命令リストを、共有メモリ内のNODESフィールドのstagingpropertiesおよびstagingdisplaylistデータセグメントに書き込み、変更されたレンダノードのIDを、properties＿dirtyキューおよびdisplaylist＿dirtyキューに追加する。キューは、アプリケーション側の共有メモリ管理クラスシングルトンに格納される。
【0229】
変更されたレンダノードは、レンダツリーの差分更新を実現するために、properties＿dirtyキューおよびdisplaylist＿dirtyキューにマークされることが理解されよう。
【0230】
必要に応じて、本出願のいくつかの実施形態では、完全なレンダツリー更新を実現するために、properties＿dirtyキューおよびdisplaylist＿dirtyキューは格納されなくてもよい。
【0231】
［3］次いで、アプリケーションは、properties＿dirtyキュー内の対応するレンダノードのstagingpropertiesセグメントをcurrentpropertiesセグメントにコピーする。アプリケーションは、displaylist＿dirtyキュー内の対応するレンダノードのdraw＿pointerおよびrecord＿pointerを交換する、すなわち、displaylist＿dirtyキュー内の対応するレンダノードのstagingdisplaylistセグメントをcurrentdisplaylistにコピーする、または、アプリケーションは、stagingdisplaylistセグメントをcurrentdisplaylistにコピーする。
【0232】
直前の垂直同期信号（Vsync－APP）と比較して、現在の垂直同期信号（Vsync－APP）に応じて、アプリケーションは、displaylist＿dirtyに対応するレンダノードのデータのみを変更し、アプリケーションは、displaylist＿dirtyキュー内の対応するレンダノードのdraw＿pointerおよびrecord＿pointerを交換し、その結果、currentdisplaylistの差分更新が実現されることができることが理解されよう。
【0233】
アプリケーションは、完全な更新を実現するために、stagingdisplaylistセグメントをcurrentdisplaylistにコピーし、すなわち、垂直同期信号（Vsync－APP）に応じてアプリケーションによって生成されたレンダツリーのすべてのデータが共有メモリに直接書き込まれ、これは実現することが比較的容易であることが理解されよう。
【0234】
必要に応じて、本出願のいくつかの実施形態では、properties＿dirtyキューおよびdisplaylist＿dirtyキューが格納されていないとき、アプリケーションのすべてのレンダノードのstagingpropertiesセグメントがcurrentpropertiesセグメントにコピーされ、stagingdisplaylistセグメントがcurrentdisplaylistセグメントにコピーされる。コピーは、ポインタの位置を変更することによって実現されてもよい。
【0235】
［4］次いで、アプリケーションは、ロック変数Aが解放されたという情報をIPC通信を介してUniRenderプロセスに転送する。
【0236】
［5］次いで、UniRenderプロセスは、ロック変数Aを保持する。
【0237】
［6］最後に、［3］に対応して、UniRenderプロセスは、共有メモリからcurrent displaylistおよびcurrent propertiesを読み出すか、または、displaylist＿dirtyキュー内の対応するレンダノードのstagingdisplaylistセグメントを読み出し、stagingdisplaylistセグメントをcurrentdisplaylistにコピーする。
【0238】
データを読み出した後、UniRenderプロセスは、ロック変数Aを解放し、ロック変数Aが解放されたことをアプリケーションに通知してもよい。次の垂直同期信号（Vsync－APP）が到着すると、ロック変数Aが保持され、レンダツリーが共有メモリに書き込まれる。この場合、stagingデータセグメントおよびcurrentデータセグメントの機能が交換される。UniRenderプロセスは、「デュアルバッファ」機構を実現し、インターフェース生成のロバスト性を確保するために、stagingdisplaylistおよびstagingpropertiesセグメントを最後に読み出す。
【0239】
必要に応じて、本出願のいくつかの実施形態では、アプリケーションとUniRenderプロセスとの間に1つのロック変数があるとき、NODESフィールドは、stagingdisplaylistおよびstagingpropertiesのみを含むか、またはcurrentdisplaylistおよびcurrentpropertiesのみを含んでもよい。アプリケーションおよびUniRenderプロセスは、ロック変数を使用することによって読み出しおよび書き込みセキュリティを実現し、その結果、UniRenderプロセスは、正しいレンダツリーを読み出す。
【0240】
必要に応じて、本出願のいくつかの実施形態では、各アプリケーションは、より多くのロック変数を保持してもよい。例えば、各アプリケーションは、ロック変数Aおよびロック変数Bを保持する。このようにして、アプリケーションがロックAを解放した後、アプリケーションは、UniRenderがロックAを解放するのを待つ必要がない。ロック変数Bを保持した後、アプリケーションは、次の垂直同期信号（Vsync－APP）を受信した後に、レンダツリーデータを共有メモリに直接書き込む。
【0241】
ロック変数Bの保持、解放、およびプロセス間同期は、ロック変数Aの保持、解放、およびプロセス間同期と同じである。詳細については、図14の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0242】
図15は、本出願の一実施形態による、アプリケーションがレンダツリーを共有メモリに書き込む他の例の概略図である。
【0243】
図15に示されるように、アプリケーションが1つのロック変数Aを格納するとき、アプリケーションは、垂直同期信号1（Vsync－APP）が受信された後、ロック変数Aを保持し、保持フェーズにおいて、生成したレンダツリーを共有メモリに書き込む。アプリケーションがレンダツリーを共有メモリに書き込んだ後、ロック変数Aが解放される。ロック変数Aがアプリケーションによって解放されたと決定した後、UniRenderは、ロック変数Aを保持し、垂直同期信号1に応じてアプリケーションによって生成されたレンダツリーの共有メモリからの読み出しを開始する。
【0244】
UniRenderプロセスがロック変数Aを保持する期間において、アプリケーションは、垂直同期信号1の後に垂直同期信号2（Vsync－APP）を受信する。ロック変数AがUniRenderプロセスによって保持されているので、アプリケーションは、レンダツリーを共有メモリに適時に書き込むことができず、UniRenderプロセスがロックAを解放したとアプリケーションが決定するまで一定期間待つ必要がある。
【0245】
しかしながら、図13の内容では、UniRenderプロセスがcurrentdisplaylistフィールドおよびcurrentpropertiesフィールドを読み出し、アプリケーションがstagingdisplaylistフィールドおよびstagingpropertiesフィールドを書き込むことは明らかである。共有メモリ内の異なるフィールドの同時読み出しおよび書き込みは、ロック変数の数を増やすことによって実現されてもよい。
【0246】
図15に示されるように、アプリケーションが2つのロック変数Bを格納するとき、垂直同期信号1（Vsync－APP）が受信された後、アプリケーションは、ロック変数Aを保持し、保持フェーズにおいて、生成されたレンダツリーを共有メモリに書き込む。アプリケーションがレンダツリーを共有メモリに書き込んだ後、ロック変数Aが解放される。ロック変数Aがアプリケーションによって解放されたと決定した後、UniRenderプロセスは、ロック変数を保持し、垂直同期信号1に応じてアプリケーションによって生成されたレンダツリーの共有メモリからの読み出しを開始する。
【0247】
UniRenderプロセスがロック変数Aを保持する期間において、アプリケーションは、垂直同期信号1の後に垂直同期信号2（Vsync－APP）を受信する。この場合、ロック変数Bが保持されているので、アプリケーションは、レンダツリーを共有メモリに適時に書き込むことができ、UniRenderプロセスがロックAを解放したとアプリケーションが決定するまで一定期間待つ必要がない。
【0248】
それに対応して、ロック変数Bがアプリケーションによって解放されたと決定した後、UniRenderプロセスは、ロック変数Bを保持し、垂直同期信号2に応じてアプリケーションによって生成されたレンダツリーの共有メモリからの読み出しを開始する。
【0249】
アプリケーションによって保持されたロック変数の数は、共有メモリ内のNODESフィールドに含まれる内容に関連されてもよく、またはVsync－offsetの値に関連されてもよいことに留意されたい。
【0250】
例えば、currentdisplaylistおよびcurrentpropertiesが第1のグループであり、stagingdisplaylistおよびstagingpropertiesが第2のグループである場合、2つの同期された変数がアプリケーションおよびUniRenderプロセス、これらは2つのデータグループにそれぞれ対応する、において構成されてもよい。同様に、他の例では、NODESフィールドが3つのデータグループを含む場合、3つの同期されたロック変数がアプリケーションおよびUniRenderにおいて構成されてもよい。
【0251】
1つのロック変数は、1つのデータグループに対応する。例えば、ロック変数Aがcurrentdisplaylistおよびcurrentpropertiesに対応する場合、ロック変数Aの保持状態から解放状態への変化は、アプリケーションが共有メモリ内のcurrentdisplaylistおよびcurrentpropertiesのデータの更新に成功し、currentdisplaylistおよびcurrentpropertiesのデータは、UniRenderプロセスによって読み出されることができることを示す。あるいは、ロック変数Aの保持状態から解放状態への変化は、UniRenderプロセスが共有メモリからのcurrentdisplaylistおよびcurrentpropertiesのデータの読み出しを遂行し、currentdisplaylistおよびcurrentpropertiesのデータは、アプリケーションによって更新されることができることを示す。
【0252】
ロック変数の数は、Vsync－offsetの値に関連されてもよい。
【0253】
言い換えれば、ロック変数の数は、垂直同期信号（Vsync－APP）と垂直同期信号（Vsync－UR）との間の差Vsync－offsetに関連されてもよい。Vsync－offsetが大きい場合、ロック変数は構成されなくてもよい。ロック変数が構成されていない場合、UniRenderプロセスは、垂直同期信号（Vsync－UR）を受信した後に共有メモリからレンダツリーを読み出す。Vsync－offsetが大きいので、UniRenderプロセスがレンダツリーを読み出すとき、アプリケーションは、レンダツリーを共有メモリに完全に書き込んでいる。
【0254】
S903：アプリケーションのウィンドウ制御情報および表示領域情報を転送する。
【0255】
UniRenderプロセスにおけるLayerManagerは、ウィンドウ・マネージャ・サービスから1つ以上のアプリケーションのウィンドウ制御情報を取得し、ステップS802で取得された1つ以上のアプリケーションのレイヤを参照して、オフスクリーンレンダリングをトリガする描画ロジックが任意のアプリケーションのレイヤに存在するか否かをさらに決定する。
【0256】
UniRenderプロセスは、異なるアプリケーションのレイヤのZオーダーをさらに取得してもよい。Zオーダーは、異なるレイヤ間のZ軸の順序である。
【0257】
UniRenderプロセスにおけるDisplayerManagerは、ディスプレイ・マネージャ・サービスから表示領域情報を取得し、表示領域情報は、表示デバイスのサイズを含む。UniRenderプロセスは、表示領域情報に基づいて、割り当てられたsurfaceのサイズを決定する。surfaceは、ターゲットレンダツリーに基づいてUniRenderによって生成されたビットマップを運ぶために使用される。UniRenderプロセスによって、ターゲットレンダツリーに基づいてビットマップを生成することについて、ステップS905の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0258】
オフスクリーンレンダリングに関連する命令は、丸み付け、スケーリング、回転、または色変換などの命令を含む。オフスクリーンレンレンダリングの定義については、前述の（1．3）オフスクリーンレンダリングの説明文を参照されたい。本明細書では詳細は再び説明されない。
【0259】
丸み付け、スケーリング、回転、および色変換などのオフスクリーンレンダリングのトリガに関連する描画ロジックについて、例を使用して以下に説明する。
【0260】
【0261】
ユーザとのインタラクション、例えば、ベゼルレスジェスチャ（例えば、画面の底部から中央に向かって上方にスライドする）、または下部ナビゲーションバー上のマルチタスク制御をタップすることに応じて、電子デバイスは、図16A－1および図16A－2に示されるように、マルチタスクインターフェースを表示する。
【0262】
ギャラリーアプリケーションによって生成されたビットマップは、画面と同じサイズを有するが、図16A－1および図16A－2に示されるマルチタスクインターフェースにおけるギャラリーアプリケーションのインターフェースは、スケーリングおよび丸み付け処理後に取得されたインターフェースである。
【0263】
図16Bに示されるように、小ウィンドウモードでは、複数のアプリケーションのビューが電子デバイスのインターフェース上に表示される。いくつかのアプリケーションのインターフェースは、フローティングウィンドウ内にある。
【0264】
例えば、ニュースアプリケーションのインターフェースおよびSMSアプリケーションのインターフェースは、電子デバイスのインターフェース上に表示され、SMSアプリケーションのインターフェースは、レンダリングフローティングウィンドウ内にある。
【0265】
SMSアプリケーションによって生成されるビットマップは、画面と同じサイズであるが、図16Bに示される小ウィンドウモードのSMSアプリケーションのインターフェースは、スケーリングおよび丸み付け処理後に取得されるインターフェースである。
【0266】
図16Cに示されるように、ユーザがデスクトップアプリケーション上のリーダアプリケーションのアイコンをタップすることに応じて、電子デバイスがリーダアプリケーションを起動する。リーダアプリケーションの起動プロセスでは、リーダアプリケーションのメインインターフェース（Main Activityに対応するインターフェース）または起動ウィンドウ（startingwindow）が連続的に拡大される。
【0267】
リーダアプリケーションのメインインターフェースまたは起動ウィンドウに対応するビットマップは、画面と同じサイズを有し、スケーリング比を調整することによって連続的なスケールアップ効果が実現される。そして、リーダアプリケーションのメインインターフェースまたは起動ウィンドウに対応するビットマップは、丸み付け処理後に取得されたビットマップであり、電子デバイスのインターフェース上に表示される。
【0268】
図16A－1および図16A－2から図16Cに示されたシナリオ、およびより多くの他のシナリオでは、ユーザ体験を改善するために、丸み付け、スケーリング、回転、および色変換を介してユーザの視覚的習慣によりよく適合するインターフェースが生成される必要があることが理解されよう。
【0269】
図16A－1および図16A－2から図16Cに示されたシナリオ、およびより多くの他のシナリオでは、UniRenderプロセスは、各アプリケーションのレイヤに対して丸み付け、スケーリング、回転、および色変換が実行される必要があるか否かを決定するために、ウィンドウ・マネージャ・サービスから各アプリケーションのレイヤのウィンドウ制御情報を受信することに留意されたい。
【0270】
必要に応じて、本出願のいくつかの実施形態では、UniRenderプロセスは、ウィンドウ・マネージャ・サービスから1つ以上のアプリケーションのウィンドウ制御情報を最初に取得し、次いで、1つ以上のアプリケーションのレンダツリーを取得してもよい。すなわち、ステップS902とステップS903の時間順序は、逆にされてもよい。
【0271】
S904：取得されたレンダツリー、ウィンドウ制御情報、および表示領域情報に基づいてターゲットレンダツリーを生成する。
【0272】
最初に、1つ以上のアプリケーションによって生成されたレンダツリーを受信した後、UniRenderプロセスは、垂直同期信号およびウィンドウ制御情報を受信したことに応じて、ウィンドウ制御情報から、各アプリケーションのレイヤがオフスクリーンレンダリングをトリガするためのロジックを有するか否かを決定する。
【0273】
アプリケーションがローカル電子デバイスの表示領域に表示されるとき、ウィンドウ制御情報は、ローカル・ウィンドウ・マネージャ・サービスからのものであってもよい。アプリケーションが他の電子デバイスの表示領域に表示されるとき、ウィンドウ制御情報は、ピア電子デバイスのウィンドウ・マネージャ・サービスからのものであってもよい。
【0274】
オフスクリーンレンダリングをトリガするためのロジックが任意のアプリケーションのレイヤに存在するとUniRenderプロセスが決定した場合、UniRenderプロセスは、オフスクリーンレンダリングをトリガするためのロジックをオフスクリーンレンダリング命令に変換し、オフスクリーンレンダリング命令を対応するレンダツリーのレンダノードのプロパティに変換する。説明を簡単にするために、UniRenderプロセスがオフスクリーンレンダリングをトリガするためのロジックをオフスクリーンレンダリング命令に変換し、オフスクリーンレンダリング命令を対応するレンダツリーのレンダノードのプロパティに変換するプロセスは、オフスクリーンレンダリング命令を進めると簡潔に称されてもよい。
【0275】
次いで、UniRenderプロセスが1つ以上のレンダツリーのオフスクリーンレンダリングトリガ命令を移行させた後、UniRenderプロセスは、ターゲットレンダツリーを生成するために、表示領域（display）毎に、各表示領域の可視レイヤに対応するレンダツリーをマージする。言い換えれば、ターゲットレンダツリーの数は、表示領域の数に関連されてもよい。
【0276】
垂直同期信号（Vsync－UR）を受信した後、UniRenderプロセスは、共有メモリからのレンダツリーの読み出しを開始し、複数のレンダツリーを取得した後、オフスクリーンレンダリング命令を移行させ、レンダツリーをマージすることを開始してもよい。あるいは、UniRenderプロセスは、ロック変数を保持しているときに共有メモリからのレンダツリーの読み出しを開始し、垂直同期信号（Vsync－UR）を受信したときにオフスクリーンレンダリング命令を移行させて、レンダツリーをマージすることを開始してもよい。
【0277】
オフスクリーンレンダリング命令をトリガして移行させるプロセスと、ターゲットレンダツリーを生成するプロセスとについて、以下に別々に説明する。
【0278】
（a）オフスクリーンレンダリングをトリガするための命令を進めるプロセス
最初に、UniRenderプロセスは、各アプリケーションレイヤのウィンドウ制御情報を取得し、レイヤのウィンドウ制御情報がオフスクリーンレンダリングをトリガするための描画ロジックを含むか否かを決定する。表示領域内のすべてのアプリケーションのレイヤのウィンドウ制御情報のいずれもがオフスクリーンレンダリングをトリガするための描画ロジックを含まないとUniRenderプロセスが決定した場合、1つ以上のレンダツリーは、ターゲットレンダツリーに直接マージされてもよい。表示領域内の任意のアプリケーションのレイヤのウィンドウ制御情報がオフスクリーンレンダリングをトリガするための描画ロジックを含むとUniRenderプロセスが決定した場合、UniRenderプロセスは、オフスクリーンレンダリングをトリガするための命令を最初に移行させ、次いで、複数のレンダツリーをターゲットレンダツリーにマージする。
最初に、UniRenderプロセスは、各アプリケーションレイヤのウィンドウ制御情報を取得し、レイヤのウィンドウ制御情報がオフスクリーンレンダリングをトリガするための描画ロジックを含むか否かを決定する。表示領域内のすべてのアプリケーションのレイヤのウィンドウ制御情報のいずれもがオフスクリーンレンダリングをトリガするための描画ロジックを含まないとUniRenderプロセスが決定した場合、1つ以上のレンダツリーは、ターゲットレンダツリーに直接マージされてもよい。表示領域内の任意のアプリケーションのレイヤのウィンドウ制御情報がオフスクリーンレンダリングをトリガするための描画ロジックを含むとUniRenderプロセスが決定した場合、UniRenderプロセスは、オフスクリーンレンダリングをトリガするための命令を最初に移行させ、次いで、複数のレンダツリーをターゲットレンダツリーにマージする。
【0279】
オフスクリーンレンダリングをトリガするための命令を移行させるプロセス：
UniRenderプロセスは、ウィンドウ制御情報から、オフスクリーンレンダリングをトリガする描画ロジックを最初に決定し、オフスクリーンレンダリングをトリガする描画ロジックを、レンダノードのレンダリングプロパティに構成されることができる命令（または描画ロジック命令と称される）に変換する。レイヤとレンダツリーとの間の結合関係を決定した後、UniRenderプロセスは、オフスクリーンレンダリング命令を対応するレンダノードのレンダリングプロパティに更新する。
UniRenderプロセスは、ウィンドウ制御情報から、オフスクリーンレンダリングをトリガする描画ロジックを最初に決定し、オフスクリーンレンダリングをトリガする描画ロジックを、レンダノードのレンダリングプロパティに構成されることができる命令（または描画ロジック命令と称される）に変換する。レイヤとレンダツリーとの間の結合関係を決定した後、UniRenderプロセスは、オフスクリーンレンダリング命令を対応するレンダノードのレンダリングプロパティに更新する。
【0280】
レンダノードのレンダリングプロパティは、対応するスケーリングプロパティ（scale）、丸み付けプロパティ（roundrect）、色変換プロパティ（colortransform）、または回転プロパティ（transform）を含むとき、オフスクリーンレンダリングをトリガするための命令内のスケーリング命令、丸み付け命令、色変換命令、または回転命令内のパラメータは、レンダノードのプロパティ内のスケーリングプロパティ、丸み付けプロパティ、色変換プロパティ、または回転プロパティに割り当てられる。レンダノードのレンダリングプロパティは、対応するスケーリングプロパティ、丸み付けプロパティ、色変換プロパティ、または回転プロパティを含まないとき、スケーリングプロパティ、丸み付けプロパティ、色変換プロパティ、または回転プロパティがレンダノードに追加され、オフスクリーンレンダリングをトリガするための命令内のスケーリング命令、丸み付け命令、色変換命令、または回転命令内のパラメータは、レンダノードのプロパティ内のスケーリングプロパティ、丸み付けプロパティ、色変換プロパティ、または回転プロパティに割り当てられる。
【0281】
【0282】
図17Aに示されるように、アプリケーション1およびアプリケーション2のUIスレッドがレンダツリーを独立して生成し、IPC通信を介してUniRenderプロセスにレンダツリーを独立して転送した後、UniRenderプロセスは、ウィンドウ・マネージャ・サービスから、各アプリケーションのレイヤでオフスクリーンレンダリングをトリガするための命令を決定する。アプリケーション1によって生成されたレンダツリーは、レンダツリー1であり、アプリケーション2によって生成されたレンダツリーは、レンダツリー2である。
【0283】
UniRenderは、異なるレンダツリー内のレンダノードのプロパティを独立して更新する。すなわち、UniRenderプロセスは、レンダツリー1内のレンダノードのプロパティを更新し、UniRenderプロセスは、レンダツリー2内のレンダノードのプロパティを更新する。
【0284】
オフスクリーンレンダリングをトリガするための命令がレイヤ全体に適用される場合、UniRenderプロセスは、オフスクリーンレンダリング命令内のパラメータを、レイヤに対応するレンダツリーのルートノードに、またはレンダツリーのすべてのレンダノードに直接割り当てる。
【0285】
UniRenderプロセスは、オフスクリーンレンダリング命令内のパラメータをレイヤに対応するレンダツリーのルートノードに割り当てるとき、UniRenderプロセスは、レンダツリーに基づいてビットマップを生成するとき、レンダノードのこれらのプロパティをルートノードの子ノードのレンダリングプロパティに自動的に構成する。
【0286】
例えば、レンダノード1の子ノードがレンダノード2である場合、レンダノード1のレンダリングプロパティに回転プロパティ（transform）が構成された後、UniRenderプロセスは、レンダツリーを生成するときに、RenderNode2のレンダリングプロパティに対して同じ回転プロパティ（transform）を構成する。
【0287】
図17Bに示されるように、オフスクリーンレンダリング命令が移行される前に、アプリケーションによって生成されたレンダツリーに対応するビットマップを受信した後、SurfaceFlingerは、レイヤ合成を遂行するために、ウィンドウ制御情報に基づいて異なるアプリケーションのビットマップに対して異なる処理を実行する必要がある。
【0288】
アプリケーションのレンダツリーのためにオフスクリーンレンダリング命令が移行された後、UniRenderプロセスは、オフスクリーンレンダリング命令内のパラメータをレンダツリーのレンダリングプロパティに割り当て、その結果、変換されたビットマップは、レンダツリーに基づいてビットマップを生成するプロセスにおいてキャンバス上に直接描画される。異なるアプリケーションのビットマップは、異なるように処理される必要がないので、異なるアプリケーションのビットマップは、1つのオンスクリーンバッファに順番に描画されることができる。
【0289】
UniRenderプロセスは、図18に示されるように、オフスクリーンレンダリング命令内のパラメータをレンダツリーのレンダリングプロパティに割り当てる。
【0290】
図18は、本出願の一実施形態による、UniRenderがレンダツリーのレンダノードプロパティを修正する一例の概略図である。
【0291】
図18に示されるように、UniRenderプロセスは、レンダツリーのルートノードのプロパティを修正し、レンダノードのプロパティの追加を実現するための命令を追加する。スケーリングプロパティに対応する命令は、setScale（）であり、丸み付けプロパティに対応する命令は、outline．setRoundRect（）であり、色変換プロパティに対応する命令は、setColorFilter（）であり、回転プロパティに対応する命令は、setLeftTopRightBottom（）である、などである。
【0292】
続くステップS905において、レンダツリーに基づいてビットマップを生成するときに、UniRenderプロセスは、レンダリングプロパティに従って描画命令リスト内の描画操作を修正し、次いで、スケーリング、丸み付け、色変換、および回転の後に取得されるビットマップを生成する。詳細については、ステップS905の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0293】
必要に応じて、本出願のいくつかの実施形態では、レンダツリーのルートノードのプロパティ内の命令は、命令setStaticMatrix（）などをさらに含んでもよい。アプリケーションのUIスレッドは、SurfaceFlingerから申請されたsurfaceに基づいてレンダツリーを生成するので、UniRenderがステップS905でレンダツリーに基づいてビットマップを生成するときに参照システムを変更するために、オフスクリーンレンダリングをトリガするための命令を移行させるプロセスでは、命令setStaticMatrix（）は、レンダツリーのルートノードに構成される。命令setStaticMatrix（）の具体的な内容について、ステップS905の以下の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0294】
（b）ターゲットレンダツリーを生成するプロセス
UniRenderプロセスは、すべてのレンダツリーについてオフスクリーンレンダリング命令を移行させた後に、1つ以上の処理されたレンダツリーを取得する。
UniRenderプロセスは、すべてのレンダツリーについてオフスクリーンレンダリング命令を移行させた後に、1つ以上の処理されたレンダツリーを取得する。
【0295】
処理されたレンダツリーが1つのとき、処理されたレンダツリーは、ターゲットレンダツリーであり、または、処理されたレンダツリーが複数あるとき、複数の処理されたレンダツリーは、1つのターゲットレンダツリーを形成するためにマージされる。
【0296】
図19は、本出願の一実施形態による、オフスクリーンレンダリング命令が1つのターゲットレンダツリーに移行された後に取得された複数のレンダツリーを合成する一例の概略図である。
【0297】
図19に示されるように、UniRenderプロセスは、新しいルートレンダノード、例えば、図19の新しいルートレンダノードを作成し、複数のアプリケーションの処理されたレンダツリーをルートレンダノードの子ノードとして使用してもよい。具体的には、ルートレンダノードは、異なるアプリケーションの処理されたレンダツリー間の親子関係を格納してもよく、その結果、UniRenderプロセスは、異なるアプリケーションの処理されたレンダツリーを検索するために、ルートレンダノードからターゲットレンダツリーを横断してもよい。
【0298】
図20は、本出願の一実施形態による、オフスクリーンレンダリング命令が1つのターゲットレンダツリーに移行された後に取得された複数のレンダツリーを合成する一例の概略図である。
【0299】
UniRenderプロセスは、ウィンドウ・マネージャ・サービスに従って、異なるアプリケーションに対応するレイヤのZオーダーを最初に決定してもよく、すなわち、アプリケーションのレイヤ間の上下遮蔽関係を決定してもよい。さらに、ターゲットレンダツリーを生成するプロセスにおいて、完全に遮蔽されたviewに対応するレンダノードが削除されることで、ステップS905のビットマップを生成するプロセスにおける計算量を低減させ、ビットマップの生成速度を改善させる。
【0300】
例えば、図20に示されるように、アプリケーション1によって生成されたレンダツリーに対応するレイヤは、レイヤ1であり、アプリケーション2によって生成されたレンダツリーに対応するレイヤは、レイヤ2である。レイヤ1のZオーダーは、レイヤ2のZオーダーよりも高い。レイヤ1に対応するレンダツリーは、ルートレンダノード1、レンダノード1、レンダノード2、およびレンダノード3であり、レンダノード1およびレンダノード2は、ルートレンダノード1の子レンダノードであり、レンダノード3は、レンダノード2の子レンダノードである。レイヤ2に対応するレンダツリーは、ルートレンダノード2、レンダノード4、レンダノード5、およびレンダノード6であり、レンダノード4およびレンダノード5は、新しいルートレンダノードの子レンダノードであり、レンダノード6は、レンダノード5の子レンダノードである。
【0301】
UniRenderプロセスは、レイヤ1に対応するレンダツリーの子レンダノードおよびレイヤ2に対応するレンダツリーの子ノードを横断し、surface（UniRenderプロセスによって割り当てられたsurface）上の各レンダノードに対応するviewの位置を決定し、レイヤ1のZオーダーおよびレイヤ2のZオーダーを参照して、完全に遮蔽されたviewおよび完全に遮蔽されたviewのレンダノードを決定してもよい。
【0302】
例えば、UniRenderは、レイヤ2に対応するレンダツリー内のレンダノード6に対応するviewが完全に遮蔽されていると決定し、次いで、レンダノード6を削除してもよい。
【0303】
完全に遮蔽されたviewに対応するレンダノードを削除した後、UniRenderプロセスは、図18に示される内容に従って、オフスクリーンレンダリングトリガ命令を移行させた後に取得されたすべてのレンダツリーをターゲットレンダツリーにマージしてもよい。
【0304】
必要に応じて、本出願のいくつかの実施形態では、UniRenderは、レンダノードをさらに横断し、DrawOP描画操作の粒度に基づいてターゲットレンダツリーのパラメータを最適化してもよい。例えば、インターフェースに影響を及ぼさないDrawOP描画操作は削除され、影響を及ぼさないとは、DrawOP描画操作によって描画されたグラフィックがインターフェースに表示されないことを意味する。他の例として、異なるアプリケーションでは、描画ノード内のDrawOP操作の位置が修正され、その結果、同じタイプのDrawOP描画操作は、同時に実行されることができる。例えば、アプリケーション1のレンダノード2のDrawOP描画操作は、アプリケーション2のレンダノード1の描画命令リストに修正される。これは、本明細書では限定されない。
【0305】
必要に応じて、本出願のいくつかの実施形態では、オフスクリーンレンダリングトリガ命令が移行された後に取得された複数のレンダツリーは、図18に示される内容に従って1つのレンダツリーにマージされてもよく、次いで、完全に遮蔽されたviewに対応するレンダノードを削除するために完全に遮蔽されたviewが決定され、ターゲットレンダツリーを生成する。
【0306】
必要に応じて、本出願のいくつかの実施形態では、部分的に遮蔽されたviewについて、そのviewに対応するレンダノードもまた、clip命令を使用することによってクリップされてもよい。クリッピングは、ターゲットレンダツリーがマージされる前に実行されてもよく、またはターゲットレンダツリーがマージされた後に実行されてもよい。
【0307】
必要に応じて、本出願のいくつかの実施形態では、ステップS904の後およびステップS905の前に、ターゲットレンダツリーを生成した後、UniRenderプロセスは、一連のDrawOPを取得するためにRenderNodeの描画命令リストをデパッケージング化し、次いで、バッチ（Batch）およびマージ（Merge）を実行するためにターゲットレンダツリー全体に対してDrawOP操作を実行する。ステップS805では、より少ない演算量でビットマップが生成されることができるターゲットレンダツリーが取得される。
【0308】
図16A－1および図16A－2ならびに図16Bに示されるシナリオおよび他のシナリオでは、オーバードローを回避または低減するために、複数のレンダツリーがマージされ、マージされたレンダツリーが最適化され、それによってステップS905でビットマップを生成する速度を改善し、電子デバイスの消費電力を低減し、ユーザ体験を改善することが理解されよう。
【0309】
UniRenderプロセスは、ターゲットレンダツリーを生成するプロセスにおいて、ターゲットレンダツリーの他のパラメータをさらに最適化してもよいことに留意されたい。これは、本明細書では限定されない。
【0310】
S905：ターゲットレンダツリーに基づいてビットマップを生成する。
【0311】
ターゲットレンダツリーが取得された後、UniRenderプロセスは、ターゲットレンダツリーにsurfaceを割り当て、UniRenderプロセスは、ターゲットレンダツリーに基づいてsurface上にビットマップを生成し、ビットマップは、1つ以上のアプリケーションの合成されたインターフェースに対応する。
【0312】
電子デバイスが複数の表示領域を有するとき、surfaceは、表示領域のうちの1つに結合されてもよく、surfaceのサイズは、surfaceに結合された表示領域のサイズと同じであってもよい。
【0313】
UniRenderプロセスがターゲットレンダツリーに基づいてsurface上にビットマップを生成することは、以下を含む。
【0314】
最初に、UniRenderプロセスは、ルートノードからターゲットレンダツリーへの横断を開始し、ルートノードの子ノードを複数の方式で横断してもよい。
【0315】
UniRenderプロセスは、レイヤのZオーダーに基づいてルートノード下の異なるレイヤを横断することができる。UniRenderプロセスは、Zオーダーの降順で異なるレイヤを横断してもよく、またはZオーダーの昇順で異なるレイヤを横断してもよい。
【0316】
例えば、図20に示されるターゲットレンダツリーでは、レイヤ1のZオーダーがレイヤ2のZオーダーよりも高い場合、UniRenderプロセスは、レイヤ1に対応するレンダツリーを最初に横断してもよく、すなわち、ルートレンダノード1、レンダノード1、レンダノード2、およびレンダノード3を含むレンダツリーを最初に横断し、次いで、ルートレンダノード2、レンダノード4、およびレンダノード5を含むレンダツリーを横断してもよい。同様に、UniRenderプロセスは、レイヤ2に対応するレンダツリーを最初に横断し、次いで、レイヤ1に対応するレンダツリーを横断してもよい。
【0317】
UniRenderプロセスがZオーダーの降順でレイヤを横断するとき、UniRenderプロセスが描画命令リスト内の描画操作を実行するとき、レイヤが上下遮蔽関係に合成されている場合、オーバードローを低減するために、描画されていない場所でのみ描画が実行されてもよいことに留意されたい。
【0318】
UniRenderプロセスがZオーダーの昇順でレイヤを横断するとき、UniRenderプロセスは、ビットマップを生成するために、異なるレイヤに対応するレンダツリー内の描画命令リスト内の描画操作を順次実行することに留意されたい。
【0319】
次に、UniRenderプロセスは、レンダリングプロパティに従って描画命令リスト内の描画操作を修正し、ビットマップを生成するために描画操作を実行する。
【0320】
各レンダノードを横断するとき、UniRenderプロセスは、レンダノードのレンダリングプロパティを読み出す。レンダリングプロパティがスケーリングプロパティ、丸み付けプロパティ、色変換プロパティ、回転プロパティなどを含むとき、UniRenderプロセスは、これらのプロパティに従って描画命令リスト内の描画操作のパラメータを修正し、次いで、修正された描画命令リスト内の描画操作を実行する。レンダリングプロパティが、スケーリングプロパティ、丸み付けプロパティ、色変換プロパティ、または回転プロパティを含まない場合、UniRenderは、描画命令リスト内の描画操作を直接実行する。
【0321】
レンダリングプロパティに従って描画命令リスト内の描画操作のパラメータをUniRenderプロセスによって修正する方法について、例を使用して以下に説明する。
【0322】
例えば、レンダノードのレンダリングプロパティは、setscale（0．5）を含み、setscale（0．5）は、元のサイズの0．5倍にスケールダウンすることを示し、描画命令リストは、drawCircle（x0、y0、5）を含む。この場合、描画操作drawCircle（x0、y0、5）を実行するとき、UniRenderプロセスは、描画操作をdrawCircle（x0、y0、2．5）に変更する。drawCircle（）において、第1のパラメータは、X軸上の円の中心の座標であり、第2のパラメータは、Y軸上の円の中心の座標であり、第3のパラメータは、円の半径である。
【0323】
アプリケーションのUIスレッドによって生成された描画命令リストがアプリケーションによって申請されたsurfaceのサイズに関連されてもよいことを考慮すると、本出願の本実施形態では、レンダツリーノードを横断するとき、UniRenderプロセスは、描画およびレンダリングの基準座標系を変換するために、レンダノードのプロパティ内にsetStaticMatrix（）を構成する。
【0324】
UniRenderプロセスは、setStaticMatrix（）のパラメータを決定するために、各アプリケーションが描画命令リストを生成するときの基準座標系または基準surfaceのサイズを、WMSを使用することによって決定してもよい。
【0325】
図21は、本出願の一実施形態によるsetStaticMatrix（）の一例の概略図である。
【0326】
描画命令リストを生成するためにアプリケーションによって参照されるsurface座標系を決定した後、UniRenderプロセスは、UniRenderプロセスによって保持されるsurfaceの座標系に基づいて座標変換行列Transformationを決定する。
【数1】
【0327】
本明細書では、scalexは、x軸方向のスケーリング、skewxは、x軸方向のねじれ／傾き、translatexは、x軸方向の平行移動、scaleyは、y軸方向のスケーリング、skewyは、y軸方向のねじれ／傾き、translateyは、y軸方向の平行移動である。
【0328】
setStaticMatrix（）命令を実行した後、UniRenderプロセスは、計算を介して座標変換行列Transformationを取得し、その変換行列を描画命令リスト内の各描画操作に適用する。図21に示されるように、レンダツリーを生成するためにアプリケーションのUIスレッドによって参照される座標系がUniRenderプロセスによって保持されているsurface上の座標系でないとき、UniRenderプロセスは、setStaticMatrix（）命令を使用することによって座標変換行列Transformationを決定し、インターフェースを正しく描画するために、描画命令リストに基づいてsurface上にインターフェースを描画するときに基準座標系を変換する。
【0329】
上記は、電子デバイスが単一表示領域シナリオで本出願の実施形態で提供されるインターフェース生成方法を実現する特定の手順を主に説明している。以下では、電子デバイスが本出願の実施形態で提供されるインターフェース生成方法をマルチ表示領域シナリオで実現する具体的な手順を主に説明する。
【0330】
（2．3）マルチ表示領域シナリオにおけるインターフェース生成方法
最初に、マルチ表示領域シナリオが、例を挙げて説明される。
最初に、マルチ表示領域シナリオが、例を挙げて説明される。
【0331】
（a）マルチ表示領域シナリオ
本出願の実施形態では、表示領域（display）は、画面、仮想画面（VirtualDisplay）などであってもよい。仮想画面は、画面記録中に画面上に表示される内容を運ぶために電子デバイスによって使用される領域であってもよい。
本出願の実施形態では、表示領域（display）は、画面、仮想画面（VirtualDisplay）などであってもよい。仮想画面は、画面記録中に画面上に表示される内容を運ぶために電子デバイスによって使用される領域であってもよい。
【0332】
【0333】
電子デバイスに複数の画面が構成されるとき、各画面は表示領域である。図22Aに示されるように、電子デバイスの一次画面は、デスクトップアプリケーションを表示するための表示領域1として使用され、電子デバイスの二次画面は、音楽アプリケーションを表示するための表示領域2として使用される。
【0334】
電子デバイスの画面は複数の状態を有し、各状態における画面は、1つ以上の表示領域であってもよい。図22Bに示されるように、電子デバイスの画面が折り畳まれた状態にあるとき、画面の各部は表示領域であってもよく、または、電子デバイスの画面が展開状態にあるとき、画面の左半分および画面の右半分はそれぞれ、表示領域であってもよい。
【0335】
図22Cに示されるように、画面記録機能が有効化されているとき、電子デバイスの画面は表示領域であり、画面記録内容を運ぶ仮想画面は表示領域である。2つの表示領域に表示される内容は同じであってもよい。
【0336】
【0337】
図23A－1および図23A－2に示されるように、電子デバイス1は、画面に表示される内容を電子デバイス2の画面と共有する。この場合、電子デバイス1にとって、電子デバイス1の画面は表示領域1であり、電子デバイス2の画面は表示領域2である。電子デバイス2の画面上に表示される内容は、電子デバイス1の画面上の内容を含む。
【0338】
図23Bに示されるように、電子デバイス1は、画面に表示された内容を電子デバイス2の画面に投影する。この場合、電子デバイス1にとって、電子デバイス1の画面は表示領域1であり、電子デバイス2の画面は表示領域2である。図23A－1および図23A－2に示される内容と異なり、電子デバイス2の画面上に表示される内容は、電子デバイス1の画面上の内容のみである。
【0339】
図23Cに示されるように、電子デバイス1は、画面に表示された内容を電子デバイス2の画面上に投影する。この場合、電子デバイス1にとって、電子デバイス1の画面は表示領域1であり、電子デバイス2の画面は表示領域2である。図23A－1および図23A－2ならびに図23Bに示される内容とは異なり、電子デバイス2の画面上に表示される内容は、電子デバイス1の画面上の一部の内容である。
【0340】
マルチ表示領域シナリオでは、複数の電子デバイスの場合、例えば、電子デバイス1上に表示領域1があり、電子デバイス2上に表示領域2がある場合、電子デバイス1の画面上に表示されている内容のみが表示領域2に表示されてもよく、電子デバイス1の画面上に表示されている内容の一部または全部と、電子デバイス2の画面上に元々表示されている内容とが重畳して表示領域2に表示されてもよいことに留意されたい。
【0341】
（b）単一デバイス・マルチ表示領域・シナリオにおけるインターフェース生成方法
図24は、本出願の一実施形態によるインターフェース生成方法の他の例の概略図である。
図24は、本出願の一実施形態によるインターフェース生成方法の他の例の概略図である。
【0342】
図24に示されるように、単一デバイス・マルチ表示領域・シナリオにおけるインターフェース生成方法は、以下のステップを含む。
【0343】
S2401：垂直信号を受信した後にレンダツリーを構築および生成する。
【0344】
具体的な内容については、図9のステップS901の対応する説明文を参照されたい。本明細書では詳細は再び説明されない。
【0345】
S2402：クロスプロセス方式でレンダツリーを転送する。
【0346】
具体的な内容については、図9のステップS902の対応する説明文を参照されたい。本明細書では詳細は再び説明されない。
【0347】
必要に応じて、本出願のいくつかの実施形態では、DisplayRenderサブプロセスは、対応するアプリケーションとのIPC通信を介してレンダツリーを直接取得してもよい。UniRenderプロセスは、DisplayRenderサブプロセスとアプリケーションとの間の対応関係を決定する。
【0348】
必要に応じて、本出願のいくつかの実施形態では、複数の共有メモリを含む共有メモリセットは、すべてのDisplayRenderサブプロセスとすべてのアプリケーションとの間に存在してもよく、各DisplayRenderサブプロセスは、複数の共有メモリのハンドルを保持する。
【0349】
DisplayRenderサブプロセスの概念については、ステップS2404の対応する説明文を参照されたい。本明細書では詳細は再び説明されない。
【0350】
S2403：アプリケーションのウィンドウ制御情報および表示領域情報を転送する。
【0351】
具体的な内容については、図9のステップS903の対応する説明文を参照されたい。本明細書では詳細は再び説明されない。
【0352】
S2404：レンダツリーを割り当てる。
【0353】
UniRenderプロセスは、その数が表示領域の数に等しいサブプロセスDisplayRender（図24のDisplayRender1からDisplayRenderN）を作成し、表示領域に表示されたアプリケーションのレンダツリーをDisplayRenderに転送してもよい。
【0354】
例えば、アプリケーション1およびアプリケーション2が表示領域1に表示され、表示領域1は、サブプロセスDisplayRender1に対応し、アプリケーション3およびアプリケーション4が表示領域2に表示され、表示領域2は、サブプロセスDisplayRender2に対応している。この場合、UniRenderプロセスは、アプリケーション1のレンダツリーとアプリケーション2のレンダツリーをサブプロセスDisplayRender1に転送し、アプリケーション3のレンダツリーとアプリケーション4のレンダツリーをサブプロセスDisplayRender2に転送する。
【0355】
DisplayRender1およびDisplayRender2は、対応するアプリケーションのレンダツリーを取得するために、UniRenderプロセスから対応するアプリケーションの共有メモリのハンドルを取得してもよい。あるいは、アプリケーションのレンダツリーは、Binderなどの他のIPC通信方式でUniRenderプロセスから取得される。これは、本明細書では限定されない。
【0356】
必要に応じて、本出願のいくつかの実施形態では、UniRenderプロセスは、複数のアプリケーションのレンダツリーをターゲットレンダツリーに最初にマージし、次いで、ターゲットレンダツリーを対応するDisplayRenderサブプロセスに転送してもよい。ターゲットレンダツリーの転送は、共有メモリおよびBinderなどの複数のIPC通信方式で実現されてもよい。これは、本明細書では限定されない。
【0357】
必要に応じて、本出願のいくつかの実施形態では、UniRenderプロセスは、レンダツリーのためにオフスクリーンレンダリング命令を移行させ、次いで、レンダツリーを対応するDisplayRenderサブプロセスに転送してもよく、または、対応する表示領域内のアプリケーションのウィンドウ制御情報およびレンダツリーを対応するDisplayRenderサブプロセスに転送してもよく、DisplayRenderサブプロセスは、レンダツリーのためにオフスクリーンレンダリング命令を移行させ、複数のレンダツリーをターゲットレンダツリーにマージする。
【0358】
必要に応じて、本出願のいくつかの実施形態では、2つのスレッド、例えばI／OスレッドおよびレンダスレッドがDisplayRenderサブプロセスのために構成されてもよい。I／Oスレッドは、レンダツリーを受信する役割を担い、レンダスレッドは、ターゲットレンダツリーを生成し、ターゲットレンダツリーに基づいてビットマップを生成する役割を担う。
【0359】
複数のDisplayRenderサブプロセスを作成することによって、UniRenderプロセスは、垂直同期信号（Vsync－UR）に対して周波数分割および周波数逓倍を実行し、周波数分割および周波数逓倍が実行される垂直同期信号（Vsync－UR）を異なるDisplayRenderサブプロセスに送信してもよく、その結果、異なるDisplayRenderサブプロセスは、異なる表示領域のリフレッシュレートに一致するように異なる周波数でビットマップを生成することが理解されよう。
【0360】
図25は、本出願の一実施形態による、UniRenderプロセスが垂直同期信号に対して周波数分割または周波数逓倍を実行する一例の概略図である。
【0361】
図25に示されるように、異なるDisplayRenderサブプロセスに対応する表示領域のリフレッシュレートが異なる場合、UniRenderは、垂直同期信号を異なるDisplayRenderサブプロセスに転送するために、垂直同期信号（Vsync－UR）に対して周波数分割または周波数逓倍を実行してもよい。
【0362】
例えば、表示領域1のリフレッシュレートは60Hzであり、表示領域2のリフレッシュレートは30Hzであり、表示領域1に対応するDisplayRenderサブプロセスはDisplayRender1であり、表示領域2に対応するDisplayRenderサブプロセスはDisplayRender2である。この場合、60Hzの垂直同期信号（Vsync）を受信した後、または60Hzの垂直同期信号（Vsync）を生成した後、UniRenderプロセスは、30Hzの垂直同期信号（Vsync－UR）および60Hzの垂直同期信号（Vsync－UR）を生成するために周波数分割を実行し、60Hzの垂直同期信号（Vsync－UR）をDisplayRender1サブプロセスに転送し、30Hzの垂直同期信号（Vsync－UR）をDisplayRender2サブプロセスに転送する。
【0363】
周波数分割または周波数逓倍が垂直同期信号（Vsync－UR）に対して実行され、その結果、DisplayUniRenderプロセスがレンダツリーまたはターゲットレンダツリーを受信する周波数およびビットマップが生成される周波数は、表示領域のリフレッシュ周波数と一致することが理解されよう。
【0364】
垂直同期信号（Vsync－UR）を受信した後、DisplayRenderサブプロセスは、レンダツリーの読み出し、ターゲットレンダツリーの生成、およびビットマップの生成を開始してもよい。
【0365】
UniRenderプロセスは、ディスプレイ・マネージャ・サービスによって送られた表示領域情報を受信し、各表示領域の接続状態を決定し、表示領域の接続状態に従って、各表示領域に対応するDisplayRenderプロセスを作成または破棄してもよいことに留意されたい。
【0366】
UniRenderおよび共有メモリのアーキテクチャなどの概念の内容については、ステップS904の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0367】
S2405：取得されたレンダツリー、ウィンドウ制御情報、および表示領域情報に基づいて、ターゲットレンダツリーを生成する。
【0368】
DisplayRenderサブプロセスは、1つ以上のターゲットレンダツリーをターゲットレンダツリーにマージし、アプリケーションのレイヤがオフスクリーンレンダリングロジックに関連するとき、アプリケーションのレンダツリーのためにオフスクリーンレンダリング命令を移行させる。
【0369】
DisplayRenderサブプロセスは、UniRenderプロセスから表示領域内のウィンドウ制御情報および表示領域情報を取得してもよいことに留意されたい。
【0370】
必要に応じて、本出願のいくつかの実施形態では、UniRenderプロセスは、1つ以上のレンダツリーをターゲットレンダツリーにマージし、次いで、ターゲットレンダツリーをDisplayRenderサブプロセスに転送してもよい。
【0371】
ターゲットレンダツリーを生成し、オフスクリーンレンダリング命令を移行させるプロセスなどの概念の内容については、ステップS904の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0372】
S2406：ターゲットレンダツリーに基づいてビットマップを生成する。
【0373】
ターゲットレンダツリーを生成した後、DisplayRenderサブプロセスは、ターゲットレンダツリーに基づいてビットマップを生成する。ビットマップを生成した後、DisplayRenderサブプロセスは、ビットマップを運ぶsurfaceをUniRenderプロセスに転送する。UniRenderプロセスは、DSSを介して各表示領域にsurfaceの内容を送る。
【0374】
ターゲットレンダツリーに基づいてビットマップを生成するプロセスについては、ステップS905の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0375】
基礎となるグラフィックスライブラリの呼び出しはコンテキストに依存するので、異なるDisplayRenderサブプロセスは異なるコンテキストに対応し、その結果、ビットマップは、異なる表示領域に対して並列に生成されることができる。
【0376】
UniRenderプロセスは、表示領域と1対1に対応するDisplayRenderサブプロセスを作成することによって、各表示領域に対してビットマップを並行して生成してもよいことが理解されよう。マルチ表示領域シナリオでは、インターフェース生成速度は改善されることができ、フレームフリーズは低減されることができ、ユーザ体験は改善されることができる。
【0377】
【0378】
【0379】
図26Aに示されるように、電子デバイスには、表示領域1と表示領域2の2つの表示領域がある。表示領域1には、アプリケーション1およびアプリケーション3の内容が表示され、表示領域2には、アプリケーション2、アプリケーション3およびアプリケーション4の内容が表示される。
【0380】
UniRenderプロセスは、表示領域1に対応するDisplayRender1サブプロセスと、表示領域2に対応するDisplayRender2サブプロセスを作成する。アプリケーション1のレンダツリー1、アプリケーション2のレンダツリー2、アプリケーション3のレンダツリー3、およびアプリケーション4のレンダツリー4を受信した後、UniRenderプロセスは、レンダツリー1およびレンダツリー3をDisplayRender1サブプロセスへ転送し、レンダツリー2、レンダツリー3、およびレンダツリー4をDisplayRender2サブプロセスへ転送する。UniRenderプロセスは、関連するウィンドウ制御情報および表示領域情報をDisplayRenderサブプロセスに転送する。
【0381】
DisplayRender1サブプロセスおよびDisplayRender2サブプロセスは、ターゲットレンダツリーに基づいてビットマップを別々に生成する。DisplayRender1サブプロセスは、表示領域1の表示領域情報に基づいてsurface1を生成し、DisplayRender1サブプロセスは、表示領域2の表示領域情報に基づいてsurface2を生成する。surface1は、DisplayRender1サブプロセスによって生成されたビットマップ1を運ぶために使用され、surface2は、DisplayRender1サブプロセスによって生成されたビットマップ2を伝達するために使用される。surface1のサイズは、表示領域1のサイズに関連されていてもよく、surface2のサイズは、表示領域2のサイズに関連されていてもよい。
【0382】
本出願の本実施形態では、異なる表示領域にアプリケーションによって表示された内容は、同じであっても異なっていてもよい。異なる表示領域にアプリケーションによって表示された内容が同じである場合、アプリケーションによって生成された1つのレンダツリーは、複数のDisplayRenderサブプロセスに割り当てられる。異なる表示領域にアプリケーションによって表示された内容が異なる場合、アプリケーションは、複数の異なるレンダツリーを生成し、それに対応してレンダツリーを複数のDisplayRenderサブプロセスに割り当てる。
【0383】
例えば、図26Bに示される内容では、表示領域1と表示領域2のサイズ（例えば、解像度）が異なるので、表示領域1と表示領域2にアプリケーション3によって表示するインターフェースは異なる（例えば、レイアウト構造は異なるが、内容は同じである）。したがって、アプリケーションは、それぞれレンダツリー31およびレンダツリー32である異なる表示領域に対応するレンダツリーを生成する。レンダツリー31は、DisplayRender1サブプロセスに転送され、レンダツリー32は、DisplayRender2サブプロセスに転送される。
【0384】
2つのスレッドは、例えばI／Oスレッドおよびレンダスレッドなど、任意のDisplayRenderサブプロセスのために構成されてもよい。I／Oスレッドは、レンダツリーを受信する役割を担い、レンダスレッドは、ターゲットレンダツリーを生成し、ターゲットレンダツリーに基づいてビットマップを生成する役割を担う。
【0385】
（c）マルチデバイス・マルチ表示領域・シナリオにおけるインターフェース生成方法
図23A－1および図23A－2から図23Cのシナリオに示されるように、電子デバイスは、投影またはマルチ画面協調などの方式で、ピア電子デバイスの画面上の画面上に画面上内容の一部または全部を表示してもよい。
図23A－1および図23A－2から図23Cのシナリオに示されるように、電子デバイスは、投影またはマルチ画面協調などの方式で、ピア電子デバイスの画面上の画面上に画面上内容の一部または全部を表示してもよい。
【0386】
マルチデバイス・マルチ表示領域・シナリオでは、ピア電子デバイスへの接続を確立した後、ローカル電子デバイスは、ピア電子デバイスの画面を表示領域2として使用し、表示領域2に表示される必要があるアプリケーションのレンダツリーをピア電子デバイスに転送してもよい。ローカル電子デバイスのレンダツリーを受信した後、ピア電子デバイスは、ビットマップを生成し、表示のためにビットマップを送るために、表示領域2に表示されたすべてのアプリケーションのレンダツリーをターゲットレンダツリーにマージする。
【0387】
あるいは、ローカル電子デバイスは、表示領域2に表示されたアプリケーションのインターフェースをピア電子デバイスに送ってもよい。
【0388】
図27は、本出願の一実施形態によるインターフェース生成方法の他の例の概略図である。
【0389】
図27に示されるように、本出願の本実施形態において提供されるインターフェース生成方法は、以下のステップを含む。
【0390】
S2701：接続を確立する。
【0391】
電子デバイス1と電子デバイス2とは、Bluetooth、Wi－Fi、HiLinkなどの複数の方式で通信接続を確立する。電子デバイス1は、電子デバイス2の画面を表示領域2として使用し、電子デバイス1の画面は、表示領域1として使用される。
【0392】
電子デバイス1と電子デバイス2との間に接続が確立されたと決定した後、またはディスプレイ・マネージャ・サービスおよびウィンドウ・マネージャ・サービスの投影要求、マルチ画面協調要求などを受信した後、電子デバイス2上のUniRenderプロセスは、電子デバイス1によって送られ、ビットマップ、例えば、レンダツリーをレンダリングおよび生成するために使用されるデータを格納するために、ヒープメモリを申請してもよい。
【0393】
S2702：表示領域2に表示されたアプリケーションを決定する。
【0394】
電子デバイス1上のウィンドウ・マネージャ・サービスおよびディスプレイ・マネージャ・サービスは、表示領域2に表示されるべきアプリケーションを決定し、その結果を電子デバイス1上のUniRender1プロセスに転送する。そして、電子デバイス1上のUniRender1プロセスは、IPC通信を介して、表示領域2に表示されているアプリケーションのレンダツリーを取得する。
【0395】
UniRender1プロセスによってアプリケーションのレンダツリーをIPC通信を介して取得することについて、ステップS902の前述の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0396】
S2703：表示領域2に表示されているアプリケーションのレンダツリーを送る。
【0397】
電子デバイス1上のUniRender1プロセスは、表示領域2に表示されているアプリケーションのレンダツリーを電子デバイス2に送る。
【0398】
UniRender1は、共有メモリの開始アドレスと共有メモリのサイズを決定し、ステップS2701の通信接続を使用することによって、レンダツリーを電子デバイス2上のUniRender2プロセスの作成されたヒープメモリに転送してもよい。
【0399】
ヒープメモリ内のデータの記憶構造は、UniRender1内の共有メモリ内のデータの記憶構造に一致してもよい。ヒープメモリ内のデータの記憶構造およびヒープメモリの読み出しおよび書き込みセキュリティについては、ステップS902の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0400】
電子デバイス1がレンダツリーを電子デバイス2に送ることにより、電子デバイス1と電子デバイス2との間のデータ伝送量は低減されることができ、それによって遅延を低減し、インターフェース生成速度を改善することが理解されよう。
【0401】
S2704：表示領域2に表示されているアプリケーションのレンダツリーをターゲットレンダツリーにマージする。
【0402】
垂直同期信号（Vsync－UR2）を受信した後、電子デバイス2上のUniRender2プロセスは、表示領域2に表示されているアプリケーションのレンダツリーをターゲットレンダツリーにマージし、このプロセスでオフスクリーンレンダリング命令の移行を遂行してもよい。
【0403】
電子デバイス2は、電子デバイス1によって送られたレンダツリーと電子デバイス2のローカルレンダツリーとをターゲットレンダツリーにマージしてもよい。
【0404】
【0405】
図28Aに示されるように、アプリケーション1およびアプリケーション2は、電子デバイス1上で動作し、アプリケーション1によって生成されたレンダツリーはレンダツリー1であり、アプリケーション2によって生成されたレンダツリーはレンダツリー2である。アプリケーション3は電子デバイス2上で動作し、アプリケーション3によって生成されたレンダツリーはレンダツリー3である。
【0406】
電子デバイス1上のUniRender1プロセスは、アプリケーション2のインターフェースが表示領域2に表示される必要があると決定し、電子デバイス2上のUniRender2プロセスにレンダツリー2を送る。
【0407】
UniRender1プロセスは、オフスクリーンレンダリング命令をレンダツリー1およびレンダツリー2に対して別々に移行させ、ビットマップ1を生成するために、レンダツリー1およびレンダツリー2をターゲットレンダツリー1にマージする。UniRender2プロセスは、オフスクリーンレンダリング命令をレンダツリー2およびレンダツリー3に対して別々に移行させ、ビットマップ2を生成するために、レンダツリー2およびレンダツリー3をターゲットレンダツリー2にマージする。
【0408】
UniRender1プロセスは、レンダツリー2のデータをUniRender2プロセスに送るときに、レンダツリー2のすべてのデータまたはレンダツリー2の差分データをUniRender2プロセスに送ってもよいことに留意されたい。レンダツリー2のすべてのデータは、共有メモリ内のcurrent properties、current displaylist、staging displaylist、またはstaging propertiesであってもよく、レンダツリー2の差分データは、properties＿dirtyキューおよびdisplaylist＿dirtyキュー内のレンダツリー2のレンダノードの描画命令リストおよびレンダリングプロパティであってもよい。
【0409】
図28Bに示されるように、アプリケーション1、アプリケーション2、およびアプリケーション3は、電子デバイス1上で動作し、アプリケーション1によって生成されたレンダツリーはレンダツリー1であり、アプリケーション2によって生成されたレンダツリーはレンダツリー2であり、アプリケーション2によって生成されたレンダツリーはレンダツリー3である。アプリケーション4は電子デバイス2上で動作し、アプリケーション4によって生成されたレンダツリーはレンダツリー4である。
【0410】
電子デバイス1上のUniRender1プロセスは、アプリケーション2およびアプリケーション3のインターフェースが表示領域2に表示される必要があると決定した場合、UniRender1プロセスは、レンダツリー2およびレンダツリー3を電子デバイス2のUniRender2プロセスに送り、または、レンダツリー2およびレンダツリー3がターゲットレンダツリー2にマージされた後、ターゲットレンダツリー2を電子デバイス2のUniRender2プロセスに送る。
【0411】
UniRender1プロセスは、レンダツリー1、レンダツリー2、およびレンダツリー3のためにオフスクリーンレンダリング命令を別々に移行させ、ビットマップ1を生成するために、レンダツリー1、レンダツリー2、およびレンダツリー3をターゲットレンダツリー1にマージする。UniRender1プロセスは、レンダツリー2のためにオフスクリーンレンダリング命令を移行させ、レンダツリー2をターゲットレンダツリー2にマージする。
【0412】
必要に応じて、本出願のいくつかの実施形態では、UniRender1プロセスは、異なるアプリケーションからレンダツリーを別々に受信するために、複数のサブプロセスDisplayRenderを作成してもよい。具体的には、図28Bに示された内容において、UniRender1プロセスは、2つのサブプロセスDisplayRender：DisplayRender1およびDisplayRender2を作成してもよい。DisplayRender1サブプロセスは、レンダツリー1、レンダツリー2、およびレンダツリー3を受信し、レンダツリー1、レンダツリー2、およびレンダツリー3をターゲットレンダツリー1にマージする。DisplayRender2サブプロセスは、レンダツリー2およびレンダツリー3を受信し、レンダツリー2およびレンダツリー3をターゲットレンダツリー2にマージし、ターゲットレンダツリー2をUniRender2プロセスに送る。
【0413】
UniRender2プロセスは、オフスクリーンレンダリング命令をレンダツリー2およびレンダツリー3に対して別々に移行させ、ビットマップ2を生成するために、レンダツリー2およびレンダツリー3をターゲットレンダツリー2にマージする。
【0414】
電子デバイス1上の垂直同期信号（Vsync－UR1）に応じて、UniRender1プロセスは、共有メモリから1つ以上のアプリケーションのレンダツリーを取得し、ターゲットレンダツリーの生成を開始することに留意されたい。電子デバイス2上の垂直同期信号（Vsync－UR2）に応じて、UniRender2は、1つ以上のアプリケーションのレンダツリーをヒープメモリおよび／または共有メモリから取得し、ターゲットレンダツリーの生成を開始する。
【0415】
必要に応じて、本出願のいくつかの実施形態では、電子デバイス1上の垂直同期信号（Vsync－UR1）と電子デバイス2上の垂直同期信号（Vsync－UR2）の周波数が一致しないとき、電子デバイス1上のUniRenderは、周波数分割または周波数逓倍を介して、垂直同期信号（Vsync－UR1）の周波数をVsync－UR2の周波数と同じになるように調整してもよい。あるいは、電子デバイス2上のUniRender2は、周波数分割または周波数逓倍を介して、垂直同期信号（Vsync－UR2）の周波数を、垂直同期信号（Vsync－UR1）の周波数と同じになるように調整してもよい。
【0416】
必要に応じて、本出願のいくつかの実施形態では、複数の周波数の垂直同期信号（Vsync－UR1）が電子デバイス1に対して構成されてもよい。例えば、図28Aおよび図28Bに示されるシナリオでは、電子デバイス1上の垂直同期信号（Vsync－UR）の元の周波数は60Hzであり、電子デバイス2上の垂直同期信号（Vsync－UR2）の元の周波数は90Hzである。電子デバイス1が電子デバイス2上のアプリケーション2のインターフェースを表示することを決定した後、電子デバイス1のUniRenderプロセスは、それぞれ60Hzおよび90Hzである垂直同期信号（Vsync－UR1）周波数を生成してもよく、その結果、アプリケーション2は、90Hzの周波数でレンダツリーを生成する。このようにして、UniRender1プロセスは、90Hzの周波数でレンダツリーをUniRender2プロセスに転送してもよい。アプリケーション1は、引き続き60Hzの周波数でレンダツリーを生成してもよい。
【0417】
任意の電子デバイス上で、UniRenderによって受信または生成された垂直同期信号（Vsync－UR）は、アプリケーションによって受信された垂直同期信号（Vsync－APP）と同じであってもよい。
【0418】
S2705：ターゲットレンダツリーに基づいてビットマップを生成する。
【0419】
具体的な内容については、ステップS905の説明文を参照されたい。本明細書では詳細は再び説明されない。
【0420】
必要に応じて、本出願のいくつかの実施形態では、電子デバイス1のUniRender1プロセスは、表示領域2内の1つ以上のレンダツリーをターゲットレンダツリーに最初にマージし、ターゲットレンダツリーに基づいてビットマップを生成し、ビットマップを電子デバイス2のUniRender2プロセスに転送してもよい。
【0421】
電子デバイス2が電子デバイス1上のアプリケーション1のインターフェースを表示するとき、ユーザは、タップなどの他のインタラクション方式で電子デバイス2上のアプリケーション1のインターフェースをタップし、電子デバイス2は、アプリケーション1のインターフェース内でユーザによって実行されたタップ操作の位置を電子デバイス1上のアプリケーション1に送ってもよく、その結果、アプリケーション1は、ユーザインタラクションに正しく応答することができることに留意されたい。あるいは、電子デバイス2上のアプリケーション1のインターフェースは、レンダツリーに基づいて電子デバイス2上のUniRender2プロセスによって生成され、レンダツリーは、viewの位置情報を含むので、電子デバイス2は、ユーザによってタップされたviewを決定し、電子デバイス1上のアプリケーション1にviewタップイベントを直接送ってもよく、その結果、アプリケーション1は、ユーザインタラクションに正しく応答することができる。
【0422】
（3）最後に、本出願の実施形態で提供される電子デバイスのハードウェアアーキテクチャおよびソフトウェアアーキテクチャが説明される。
【0423】
図29は、本出願の一実施形態による電子デバイスのハードウェア構造の概略図である。
【0424】
以下では、電子デバイスを一例にとして使用して、実施形態を具体的に説明する。電子デバイスは、図に示されるものよりも多いかまたは少ない構成要素を有してもよいし、2つ以上の構成要素を組み合わせてもよいし、異なる構成要素構成を有してもよいことを理解されたい。図に示される構成要素は、1つ以上の信号処理および／または特定用途向け集積回路を含むハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組み合わせで実現されてもよい。
【0425】
電子デバイスは、プロセッサ110、外部メモリインターフェース120、内部メモリ121、ユニバーサルシリアルバス（universal serial bus、USB）インターフェース130、充電管理モジュール140、電力管理モジュール141、バッテリ142、アンテナ1、アンテナ2、移動通信モジュール150、無線通信モジュール160、オーディオモジュール170、スピーカ170A、受信機170B、マイクロフォン170C、ヘッドセットジャック170D、センサモジュール180、ボタン190、モータ191、インジケータ192、カメラ193、ディスプレイ194、加入者識別モジュール（subscriber identification module、SIM）カードインターフェース195などを含んでもよい。センサモジュール180は、圧力センサ180A、ジャイロセンサ180B、気圧センサ180C、磁気センサ180D、加速度センサ180E、距離センサ180F、光学式近接センサ180G、指紋センサ180H、温度センサ180J、タッチセンサ180K、周囲光センサ180L、および骨伝導センサ180Mなどを含んでもよい。
【0426】
本発明の本実施形態に示されている構造は、電子デバイスに対して特定の限定をするものではないことが理解されよう。本出願のいくつかの他の実施形態では、電子デバイスは、図に示されるものよりも多いまたは少ない構成要素を含んでもよく、またはいくつかの構成要素を組み合わせてもよく、またはいくつかの構成要素を分割してもよく、または異なる構成要素の配置を有してもよい。図に示される構成要素は、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアとの組み合わせによって実現されてもよい。
【0427】
プロセッサ110は、1つ以上の処理ユニットを含んでもよい。例えば、プロセッサ110は、アプリケーションプロセッサ（application processor、AP）、モデムプロセッサ、グラフィック処理ユニット（graphics processing unit、GPU）、画像信号プロセッサ（image signal processor、ISP）、コントローラ、メモリ、ビデオコーデック、デジタル信号プロセッサ（digital signal processor、DSP）、ベースバンドプロセッサ、および／またはニューラルネットワーク処理ユニット（neural－network processing unit、NPU）を含んでもよい。異なる処理ユニットは、独立した構成要素であってもよいし、または1つ以上のプロセッサに統合されてもよい。
【0428】
コントローラは、電子デバイスの中枢およびコマンドセンタであってもよい。コントローラは、命令のフェッチおよび命令の実行の制御を遂行するために、命令動作コードおよび時系列信号に基づいて動作制御信号を生成してもよい。
【0429】
命令およびデータを格納するために、プロセッサ110内にメモリがさらに配置されてもよい。いくつかの実施形態では、プロセッサ110内のメモリはキャッシュである。メモリは、プロセッサ110によって使用されたばかりか、または周期的に使用される命令またはデータを格納してもよい。プロセッサ110が命令またはデータを再び使用する必要がある場合、命令またはデータはメモリから直接呼び出されてもよい。これにより、繰り返しアクセスを回避し、プロセッサ110の待ち時間を低減し、その結果、システム効率が改善される。
【0430】
いくつかの実施形態では、プロセッサ110は、1つ以上のインターフェースを含んでもよい。インターフェースは、集積回路間（inter－integrated circuit、I2C）インターフェース、集積回路間サウンド（inter－integrated circuit sound、I2S）インターフェース、パルス符号変調（pulse code modulation、PCM）インターフェース、汎用非同期受信機／伝送機（universal asynchronous receiver／transmitter、UART）インターフェース、モバイルインダストリプロセッサインターフェース（mobile industry processor interface、MIPI）、汎用入力／出力（general－purpose input／output、GPIO）インターフェース、加入者アイデンティティモジュール（subscriber identity module、SIM）インターフェース、および／またはユニバーサルシリアルバス（universal serial bus、USB）インターフェースなどを含んでもよい。
【0431】
I2Cインターフェースは、双方向同期シリアル・バスであり、シリアル・データ・ライン（serial data line、SDA）とシリアル・クロック・ライン（derail clock line、SCL）とを含む。いくつかの実施形態では、プロセッサ110は、I2Cバスの複数のグループを含んでもよい。プロセッサ110は、異なるI2Cバスインターフェースを介してタッチセンサ180K、充電器、フラッシュ、およびカメラ193などに別々に結合されてもよい。例えば、プロセッサ110は、プロセッサ110がI2Cバスインターフェースを使用することによってタッチセンサ180Kに結合されてもよく、その結果、プロセッサ110は、電子デバイスのタッチ機能を実現するために、I2Cインターフェースを使用することによってタッチセンサ180Kと通信する。
【0432】
I2Sインターフェースは、オーディオ通信に使用されてもよい。PCMインターフェースは、オーディオ通信を実行し、アナログ信号をサンプリング、量子化、および符号化するように構成されてもよい。UARTインターフェースは、ユニバーサルシリアルデータバスであり、非同期通信に使用される。
【0433】
MIPIインターフェースは、プロセッサ110をディスプレイ194またはカメラ193などの周辺構成要素に接続するように構成されてもよい。MIPIインターフェースは、カメラシリアルインターフェース（camera serial interface、CSI）およびディスプレイシリアルインターフェース（display serial interface、DSI）などを含む。いくつかの実施形態では、プロセッサ110およびカメラ193は、電子デバイスの撮影機能を実現するために、CSIインターフェースを使用することによって互いに通信する。プロセッサ110は、電子デバイスの表示機能を実現するために、DSIインターフェースを使用することによってディスプレイ194と通信する。GPIOインターフェースは、ソフトウェアを使用することによって構成されてもよい。GPIOインターフェースは、制御信号として構成されてもよく、データ信号として構成されてもよい。いくつかの実施形態では、GPIOインターフェースは、カメラ193、ディスプレイ194、無線通信モジュール160、オーディオモジュール170、センサモジュール180などにプロセッサ110を接続するように構成されてもよい。GPIOインターフェースは、あるいは、I2Cインターフェース、I2Sインターフェース、UARTインターフェース、MIPIインターフェースなどとして構成されてもよい。SIMインターフェースは、SIMカードにデータを送信する機能またはSIMカードのデータを読み出す機能を実現するために、SIMカードインターフェース195と通信するように構成されてもよい。USBインターフェース130は、USB標準仕様に準拠したインターフェースであり、具体的には、Mini USBインターフェース、Micro USBインターフェース、USB Type Cインターフェースなどであってもよい。
【0434】
本発明の本実施形態に示されるモジュール間のインターフェース接続関係は、説明のための例にすぎず、電子デバイスの構造に対して限定するものではないことが理解されよう。本出願のいくつかの他の実施形態では、電子デバイスは、あるいは、前述の実施形態とは異なるインターフェース接続方式、または複数のインターフェース接続方式の組み合わせを使用してもよい。
【0435】
充電管理モジュール140は、充電器から充電入力を受信するように構成される。電力管理モジュール141は、バッテリ142、充電管理モジュール140、およびプロセッサ110を接続するように構成される。
【0436】
電子デバイスの無線通信機能は、アンテナ1、アンテナ2、移動通信モジュール150、無線通信モジュール160、モデムプロセッサ、ベースバンドプロセッサなどを使用することによって実現されてもよい。アンテナ1およびアンテナ2は、電磁波信号を送信および受信するように構成される。電子デバイス内の各アンテナは、1つ以上の通信帯域をカバーするように構成されてもよい。アンテナの利用率を改善するために、異なるアンテナが多重化されてもよい。移動通信モジュール150は、電子デバイスに適用される2G／3G／4G／5Gなどを含む無線通信のためのソリューションを提供してもよい。移動通信モジュール150は、少なくとも1つのフィルタ、スイッチ、電力増幅器、低雑音増幅器（low noise amplifier、LNA）などを含んでもよい。移動通信モジュール150は、アンテナ1を使用することによって電磁波を受信し、受信した電磁波に対してフィルタリングや増幅などの処理を実行し、処理された電磁波を復調のためにモデムプロセッサに送ってもよい。移動通信モジュール150は、モデムプロセッサによって変調された信号をさらに増幅し、この信号をアンテナ1を介して放射するための電磁波に変換してもよい。いくつかの実施形態では、移動通信モジュール150の少なくとも一部の機能モジュールは、プロセッサ110に配置されてもよい。いくつかの実施形態では、移動通信モジュール150の少なくとも一部の機能モジュールは、プロセッサ110の少なくとも一部のモジュールと同一の構成要素に配置されてもよい。
【0437】
モデムプロセッサは、変調器と復調器とを含んでもよい。変調器は、送信対象の低周波ベースバンド信号を中／高周波信号に変調するように構成される。復調器は、受信された電磁波信号を低周波ベースバンド信号に復調するように構成される。次いで、復調器は、復調によって得られた低周波ベースバンド信号を処理のためにベースバンドプロセッサに送信する。ベースバンドプロセッサによって処理された後、低周波ベースバンド信号はアプリケーションプロセッサに送信される。アプリケーションプロセッサは、オーディオデバイス（スピーカ170Aや受信機170Bなどに限定されない）を使用することによって音響信号を出力するか、またはディスプレイ194を使用することによって画像もしくはビデオを表示する。いくつかの実施形態では、モデムプロセッサは独立したデバイスであってもよい。いくつかの他の実施形態では、モデムプロセッサは、プロセッサ110から独立していてもよく、移動通信モジュール150または他の機能モジュールと同じデバイスに配置され得る。
【0438】
無線通信モジュール160は、無線ローカルエリアネットワーク（wireless local area networks、WLAN）（例えば、ワイヤレスフィデリティ（wireless fidelity、Wi－Fi）ネットワーク）、Bluetooth（bluetooth、BT）、全地球航法衛星システム（global navigation satellite system、GNSS）、周波数変調（frequency modulation、FM）、近距離無線通信（near field communication、NFC）、赤外線（infrared、IR）技術などを含む、電子デバイスに適用される無線通信のためのソリューションを提供してもよい。無線通信モジュール160は、少なくとも1つの通信処理モジュールを統合した1つ以上の構成要素であってもよい。無線通信モジュール160は、アンテナ2を介して電磁波を受信し、電磁波信号に対して周波数変調とフィルタリングを実行し、処理した信号をプロセッサ110へ送る。無線通信モジュール160は、プロセッサ110から、送信対象の信号をさらに受信し、送信対象の信号に対して周波数変調および増幅を実行し、送信対象の信号をアンテナ2を介して放射するための電磁波に変換してもよい。
【0439】
いくつかの実施形態では、電子デバイスにおいて、アンテナ1は、移動通信モジュール150に結合され、アンテナ2は、無線通信モジュール160に結合され、その結果、電子デバイスは、無線通信技術に従ってネットワークおよび他のデバイスと通信することができる。無線通信技術は、グローバルシステムフォーモバイルコミュニケーションズ（global system for mobile communications、GSM）、汎用パケット無線サービス（general packet radio service、GPRS）、符号分割多元接続（code division multiple access、CDMA）、広帯域符号分割多元接続（wideband code division multiple access、WCDMA（登録商標））、時分割符号分割多元接続（time－division code division multiple access、TD－SCDMA）、ロングタームエボルーション（long term evolution、LTE）、BT、GNSS、WLAN、NFC、FM、IR技術などを含んでもよい。GNSSは、全地球測位システム（global positioning system、GPS）、全地球航法衛星システム（global navigation satellite system、GLONASS）、北斗航法衛星システム（beidou navigation satellite system、BDS）、準天頂衛星システム（quasi－zenith satellite system、QZSS）、および／または静止衛星型補強システム（satellite based augmentation systems、SBAS）を含んでもよい。
【0440】
電子デバイスは、GPU、ディスプレイ194、アプリケーションプロセッサなどを使用することによって表示機能を実現する。GPUは、画像処理用のマイクロプロセッサであり、ディスプレイ194およびアプリケーションプロセッサに接続される。GPUは、数学的および幾何学的計算を実行し、グラフィックスをレンダリングするように構成される。プロセッサ110は、表示情報を生成するまたは変更するためにプログラム命令を実行する1つ以上のGPUを含んでもよい。
【0441】
ディスプレイ194は、画像やビデオなどを表示するように構成される。ディスプレイ194は、表示パネルを含む。表示パネルは、液晶ディスプレイ（liquid crystal display、LCD）、有機発光ダイオード（organic light－emitting diode、OLED）、アクティブマトリックス式有機発光ダイオード（active－matrix organic light emitting diode、AMOLED）、フレキシブル発光ダイオード（flex light－emitting diode、FLED）、Miniled、MicroLed、Micro－oLed、量子ドット発光ダイオード（quantum dot light emitting diodes、QLED）などであってもよい。いくつかの実施形態では、電子デバイスは、1つまたはN個のディスプレイ194を含んでもよく、Nは1よりも大きい正の整数である。
【0442】
電子デバイスは、ISP、カメラ193、ビデオコーデック、GPU、ディスプレイ194、アプリケーションプロセッサなどを使用することによって撮影機能を実現し、リアルタイムのビデオデータを取得してもよい。
【0443】
ISPは、カメラ193によってフィードバックされたデータを処理するように構成される。例えば、撮影中に、シャッターが押され、光がレンズを介してカメラの受光素子に送られ、光信号が電気信号に変換され、カメラの受光素子が電気信号を処理のためにISPに送信し、電気信号を可視画像に変換する。ISPは、画像のノイズおよび輝度に対してアルゴリズムの最適化をさらに実行してもよい。ISPは、撮影シナリオの露出や色温度などのパラメータをさらに最適化してもよい。いくつかの実施形態では、ISPは、カメラ193に配置されてもよい。
【0444】
カメラ193は、静止画像またはビデオをキャプチャするように構成される。対象物の光学像は、レンズを使用することによって生成され、受光素子上に投影される。受光素子は、電荷結合素子（charge coupled device、CCD）または相補型金属酸化膜半導体（complementary metal－oxide－semiconductor、CMOS）フォトトランジスタであってもよい。受光素子は、光信号を電気信号に変換し、次いで、デジタル画像信号に変換するために電気信号をISPに送信する。ISPは、処理のためにデジタル画像信号をDSPに出力する。DSPは、デジタル画像信号をRGBまたはYUVなどのフォーマットの標準画像信号に変換する。いくつかの実施形態では、電子デバイスが1つまたはN個のカメラ193を含んでもよく、Nは1より大きい正の整数である。
【0445】
デジタル信号プロセッサは、デジタル信号を処理するように構成される。デジタル画像信号を処理することに加えて、デジタル信号プロセッサは、他のデジタル信号をさらに処理してもよい。例えば、電子デバイスが周波数を選択したときに、デジタル信号プロセッサは、周波数エネルギーに対してフーリエ変換などを実行するように構成される。
【0446】
ビデオコーデックは、デジタルビデオを圧縮または解凍するように構成される。電子デバイスは、1つ以上のビデオコーデックをサポートすることができる。このようにして、電子デバイスは、複数の符号化フォーマット、例えば、ムービングピクチャーエキスパートグループ（moving picture experts group、MPEG）1、MPEG2、MPEG3、およびMPEG4でビデオを再生または録画してもよい。
【0447】
NPUは、生物の神経回路網の構造を参照することによって、例えば、ヒトの脳神経細胞間の伝達モードを参照することによって、入力情報を迅速に処理し、絶えず自己学習をさらに実行することができる、ニューラルネットワーク（neural－network、NN）コンピューティングプロセッサである。NPUは、電子デバイスのインテリジェントな認知、例えば、画像認識、顔認識、音声認識、およびテキスト理解などのアプリケーションを実現するために使用されてもよい。
【0448】
内部メモリ121は、1つ以上のランダム・アクセス・メモリ（random access memory、RAM）および1つ以上の不揮発性メモリ（non－volatile memory、NVM）を含んでもよい。
【0449】
ランダム・アクセス・メモリは、スタティック・ランダム・アクセス・メモリ（static random access memory、SRAM）、ダイナミック・ランダム・アクセス・メモリ（dynamic random access memory、DRAM）、同期ダイナミック・ランダム・アクセス・メモリ（synchronous dynamic random access memory、SDRAM）、ダブル・データ・レート同期ダイナミック・ランダム・アクセス・メモリ（double data rate synchronous dynamic random access memory、DDR SDRAM、ここで、例えば、第5世代DDR SDRAMは、通常、DDR5 SDRAMと称される）などを含んでもよい。
【0450】
不揮発性メモリは、ディスク記憶装置およびフラッシュメモリ（flash memory）を含んでもよい。
【0451】
本出願の実施形態では、非リアルタイムビデオは、不揮発性メモリに位置してもよい。
【0452】
動作原理によれば、フラッシュメモリは、NOR FLASH、NAND FLASH、および3D NAND FLASHなどを含んでもよい。記憶ユニットの潜在的なレベル数に応じて、フラッシュメモリは、シングルレベルセル（single－level cell、SLC）、マルチレベルセル（multi－level cell、MLC）、トリプルレベルセル（triple－level cell、TLC）、クアッドレベルセル（quad－level cell、QLC）などを含んでもよい。記憶仕様によれば、フラッシュメモリは、ユニバーサルフラッシュストレージ（英語：universal flash storage、UFS）、組込み型マルチメディアカード（embedded multi media Card、eMMC）などを含んでもよい。
【0453】
ランダム・アクセス・メモリは、プロセッサ110によって直接読み出しおよび書き込みされてもよく、オペレーティングシステムまたは他の実行中プログラムの実行可能プログラム（例えば、機械命令）を格納するように構成されてもよく、ユーザおよびアプリケーションのデータを格納するようにさらに構成されてもよい。
【0454】
不揮発性メモリはまた、実行可能プログラム、ユーザおよびアプリケーションのデータなどを格納してもよく、プロセッサ110による直接読み出しおよび書き込みのために、予めランダム・アクセス・メモリにロードされてもよい。
【0455】
外部メモリインターフェース120は、電子デバイスの記憶容量を拡張するために、外部不揮発性メモリに接続するように構成されてもよい。外部不揮発性メモリは、データ記憶機能を実現するために、外部メモリインターフェース120を使用することによってプロセッサ110と通信する。外部不揮発性メモリには、例えば、音楽やビデオなどのファイルが格納される。
【0456】
電子デバイスは、オーディオモジュール170、スピーカ170A、受信機170B、マイクロフォン170C、ヘッドセットジャック170D、アプリケーションプロセッサなどを使用することによって音楽再生および録音などのオーディオ機能を実現してもよい。
【0457】
オーディオモジュール170は、デジタルオーディオ情報を出力のためのアナログオーディオ信号に変換するように構成され、アナログオーディオ入力をデジタルオーディオ信号に変換するようにも構成される。「ラウドスピーカ」とも称されるスピーカ170Aは、オーディオ電気信号を音響信号に変換するように構成される。「イヤホン」とも称される受信機170Bは、オーディオ電気信号を音響信号に変換するように構成される。「マイク（mike）」または「マイク（mic）」とも称されるマイクロフォン170Cは、音響信号を電気信号に変換するように構成される。
【0458】
ヘッドセットジャック170Dは、有線ヘッドセットに接続するように構成される。ヘッドセットジャック170Dは、USBインターフェース130であってもよく、または3．5mmオープンモバイル端末プラットフォーム（open mobile terminal platform、OMTP）標準インターフェース、または米国セルラー通信工業会（cellular telecommunications industry association of the USA、CTIA）標準インターフェースであってもよい。
【0459】
圧力センサ180Aは、圧力信号を感知するように構成され、圧力信号を電気信号に変換してもよい。いくつかの実施形態では、圧力センサ180Aは、ディスプレイ194上に配置されてもよい。ジャイロセンサ180Bは、電子デバイスのモーションジェスチャを決定するように構成されてもよい。気圧センサ180Cは、気圧を測定するように構成される。磁気センサ180Dは、ホールセンサを含む。加速度センサ180Eは、全方向（通常は3軸）の電子デバイスの加速度値を検出してもよい。距離センサ180Fは、距離を測定するように構成される。光学式近接センサ180Gは、例えば、発光ダイオード（LED）およびフォトダイオードなどの光検出器を含んでもよい。周囲光センサ180Lは、周囲光の明るさを感知するように構成される。指紋センサ180Hは、指紋を採取するように構成される。電子デバイスは、採取された指紋の特徴に基づいて、指紋ベースのロック解除、アプリケーションロックアクセス、指紋ベースの写真撮影、および指紋ベースの電話応答などを実現してもよい。温度センサ180Jは、温度を検出するように構成される。
【0460】
タッチセンサ180Kは、タッチパネルとも称される。タッチセンサ180Kは、ディスプレイ194上に配置されてもよい。タッチセンサ180Kおよびディスプレイ194は、「タッチスクリーン」とも称されるタッチスクリーンを形成する。タッチセンサ180Kは、タッチセンサ上またはその近くで行われたタッチ操作を検出するように構成される。タッチセンサは、タッチイベントのタイプを決定するために、検出されたタッチ操作をアプリケーションプロセッサに転送してもよい。タッチ操作に関連する視覚出力は、ディスプレイ194を使用することによって提供されてもよい。いくつかの他の実施形態では、タッチセンサ180Kは、あるいは、電子デバイスの表面上の、ディスプレイ194の位置とは異なる位置に配置されてもよい。
【0461】
ボタン190は、電源ボタン、音量ボタンなどを含む。ボタン190は、機械式ボタンであってもよいし、タッチ式ボタンであってもよい。電子デバイスは、ボタン入力を受信し、電子デバイスのユーザ設定および機能制御に関連するボタン信号入力を生成してもよい。モータ191は、振動プロンプトを生成してもよい。インジケータ192は、インジケータライトであってもよく、充電状態または電源変化を示すために使用されてもよく、またはメッセージ、不在着信、通知などを示すために使用されてもよい。SIMカードインターフェース195は、SIMカードに接続するように構成される。電子デバイスは、会話およびデータ通信などの機能を実現するために、SIMカードを使用することによってネットワークとやり取りする。
【0462】
図30は、本出願の一実施形態による電子デバイスのソフトウェア構造の一例の概略図である。
【0463】
階層化アーキテクチャでは、ソフトウェアはいくつかの層に分割され、各層は明確な役割およびタスクを有する。層は、ソフトウェアインターフェースを介して互いに通信する。いくつかの実施形態では、システムは、上から順にアプリケーション層、アプリケーションフレームワーク層、システムライブラリ、およびカーネル層の4つの層に分割される。
【0464】
アプリケーション層は、一連のアプリケーションパッケージを含んでもよい。図20に示されるように、アプリケーションパッケージは、カメラ、ギャラリー、カレンダー、電話、マップ、ナビゲーション、WLAN、Bluetooth、音楽、ビデオ、およびメッセージなどのアプリケーションプログラム（アプリケーションとも称される）を含んでもよい。
【0465】
アプリケーションフレームワーク層は、アプリケーション層におけるアプリケーションのためのアプリケーションプログラミングインターフェース（application programming interface、API）およびプログラミングフレームワークを提供する。アプリケーションフレームワーク層は、いくつかの事前定義された機能を含む。
【0466】
図30に示されるように、アプリケーションフレームワーク層は、ウィンドウ・マネージャ・サービス、ディスプレイ・マネージャ・サービス、コンテンツプロバイダ、ビューシステム、電話マネージャ、リソースマネージャ、通知マネージャ、ローカル・Profile・アシスタント（Local Profile Assistant、LPA）などを含んでもよい。
【0467】
ウィンドウ・マネージャ・サービスは、ウィンドウの開始、追加、および削除の役割を担い、ウィンドウに表示されたアプリケーションを決定し、アプリケーションのレイヤの作成、破棄、プロパティ変更などを決定し、ステータスバーの有無を決定し、画面をロックし、画面をキャプチャするなどができる。
【0468】
ディスプレイ・マネージャ・サービスは、表示領域の数および表示領域のサイズを取得することができ、表示領域の開始、追加、および削除の役割を担う。
【0469】
コンテンツプロバイダは、データを格納および取得し、アプリケーションがデータにアクセスできるようにするように構成される。データは、ビデオ、画像、オーディオ、発信および受信された通話、閲覧履歴およびブックマーク、ならびにアドレス帳などを含んでもよい。
【0470】
電話マネージャは、電子デバイスの通信機能、例えば、通話ステータスの管理（応答または拒否を含む）を提供するように構成される。
【0471】
リソースマネージャは、ローカライズされた文字列、アイコン、ピクチャ、レイアウトファイル、ビデオファイルなどの、アプリケーションのための様々なリソースを提供する。
【0472】
通知マネージャは、アプリケーションがステータスバーに通知情報を表示することを可能にし、通知タイプのメッセージを転送するように構成されてもよい。その情報は、ユーザとのインタラクションなしに、少し間をおいて自動的に消えてもよい。例えば、通知マネージャは、ダウンロード完了、メッセージリマインダなどを通知するように構成される。通知マネージャは、あるいは、システムの上部のステータスバーにグラフまたはスクロールバーテキストの形態で現れる通知、例えば、バックグラウンドで動作するアプリケーションの通知またはダイアログインターフェースの形態で画面に現れる通知であってもよい。例えば、ステータスバーがテキスト情報を表示し、プロンプトトーンが発せられ、電子デバイスが振動し、インジケータが点滅する。
【0473】
ビューシステムは、テキスト表示制御またはピクチャ表示制御などの視覚制御を含む。ビューシステムは、アプリケーションを構築するように構成されてもよい。表示インターフェースは、1つ以上のビューを含んでもよい。例えば、SMS通知アイコンを含む表示インターフェースは、テキスト表示ビューおよびピクチャ表示ビューを含んでもよい。
【0474】
ビューシステムは、UniRenderをさらに含み、UniRenderは、1つ以上のアプリケーションのレンダツリーを受信してもよい。UniRenderは、ウィンドウ・マネージャ・サービスを使用することによって、レイヤ作成、レイヤ破棄、およびプロパティ変更などのレイヤ情報を同期させてもよい。UniRenderは、ディスプレイ・マネージャ・サービスからの画面サイズなどの表示領域に関する情報を同期させてもよい。
【0475】
必要に応じて、本出願のいくつかの実施形態では、ビューシステムは、SurfaceFlingerをさらに含む。信頼リストで構成された電子デバイス上で、アプリケーションが信頼リストに属さないとき、アプリケーションのUIスレッドがレンダツリーを生成した後、アプリケーションのレンダスレッドがビットマップを生成し、次いで、ビットマップがレイヤ合成のためにSurfaceFlingerに送られる。
【0476】
必要に応じて、本出願のいくつかの実施形態では、信頼リスト内のアプリケーションおよび信頼リスト内にないアプリケーションが表示領域に表示されるとき、UniRenderは、信頼リスト内のアプリケーションのビットマップを生成する役割を担う。ビットマップを生成した後、UniRenderは、ビットマップをSurfaceFlingerに転送する。次いで、SurfaceFlingerは、表示のために送られるビットマップを生成するために、ビットマップおよび信頼リストにない他のアプリケーションに対してレイヤ合成を実行する。
【0477】
ランタイムは、カーネルライブラリおよび仮想マシンを含む。ランタイムは、オペレーティングシステムのスケジューリングおよび管理の役割を担う。
【0478】
カーネルライブラリは、2つの部分、すなわち、java言語を使用して呼び出される必要がある関数と、カーネルライブラリとを含む。
【0479】
アプリケーション層およびアプリケーションフレームワーク層は、仮想マシン上で動作する。仮想マシンは、アプリケーション層およびアプリケーションフレームワーク層のjavaファイルをバイナリファイルとして実行する。仮想マシンは、オブジェクトライフサイクル管理、スタック管理、スレッド管理、セキュリティおよび異常管理、ならびにガベージコレクションなどの機能を実行するように構成される。
【0480】
システムライブラリは、複数の機能モジュール、例えば、サーフェスマネージャ（surface manager）、メディアライブラリ（Media Libraries）、グラフィックス処理ライブラリを含んでもよく、グラフィックス処理ライブラリは、3次元グラフィックス処理ライブラリ（例えば、OpenGL ES）、2次元グラフィックスエンジン（例えば、SGL）などを含む。
【0481】
サーフェスマネージャは、ディスプレイサブシステムを管理し、複数のアプリケーションのために2次元（2－Dimensional、2D）レイヤと3次元（3－Dimensional、3D）レイヤとの融合を提供するように構成される。
【0482】
メディアライブラリは、複数の一般的に使用されるオーディオおよびビデオフォーマット、ならびに静止画像ファイルの再生および記録をサポートする。メディアライブラリは、MPEG4、H．264、MP3、AAC、AMR、JPG、およびPNGなどの複数のオーディオおよびビデオ符号化フォーマットをサポートすることができる。
【0483】
3次元グラフィックス処理ライブラリは、3Dグラフィックス描画、画像レンダリング、レイヤ合成、レイヤ処理などを実現するように構成される。2Dグラフィックスエンジンは、2D描画のための描画エンジンである。
【0484】
カーネル層は、ハードウェアとソフトウェアとの間の層である。カーネル層は、少なくともディスプレイドライバ、カメラドライバ、オーディオドライバ、センサドライバ、および仮想カードドライバを含む。
【0485】
本出願の実施形態では、アプリケーション層における1つ以上のアプリケーションは、アプリケーションのUIスレッドによって生成されたレンダツリーをビューシステムのUniRenderプロセスに転送する。UniRenderプロセスは、ウィンドウ・マネージャ・サービスおよびディスプレイ・マネージャ・サービスからウィンドウ制御情報および表示領域情報を取得し、次いで、表示領域内のアプリケーションのレンダツリーをターゲットレンダツリーにマージする。ターゲットレンダツリーを生成した後、UniRenderプロセスは、ターゲットレンダツリーの描画命令リスト内のDrawOP操作を実行するためにレイヤ処理ライブラリを呼び出して、ビットマップを生成する。UniRenderは、生成されたビットマップを表示のためにディスプレイドライバに転送する。
【0486】
文脈によれば、前述の実施形態で使用される「とき」という用語は、「場合」、「後」、「決定に応じて」、または「検出に応じて」の意味として解釈され得る。同様に、文脈に応じて、「決定したとき」または「（述べられた状態または事象を）検出した場合」という句は、「決定した場合」、「決定に応じて」、「（述べられた状態もしくは事象を）検出したとき」、または「（述べられた状態もしくは事象の）検出に応じて」として解釈され得る。
【0487】
前述の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせによって実現されてもよい。ソフトウェアが実施形態を実現するために使用されるとき、実施形態の全部または一部は、コンピュータプログラム製品の形態で実現されてもよい。コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされて実行されるとき、本出願の実施形態による手順または機能がすべてまたは部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラム可能な装置であってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に格納されてよく、またはあるコンピュータ可読記憶媒体から他のコンピュータ可読記憶媒体へ送信されてもよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンタから他のウェブサイト、コンピュータ、サーバ、またはデータセンタに、有線（例えば、同軸ケーブル、光ファイバ、デジタル加入者線）方式で、または無線（例えば、赤外線、電波、マイクロ波）方式で送信されてもよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体であってもよく、または1つ以上の使用可能な媒体を統合した、サーバやデータセンタなどのデータ記憶デバイスであってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、または磁気テープ）、光学媒体（例えば、DVD）、半導体媒体（例えば、ソリッドステートドライブ）などであってもよい。
【0488】
前述の実施形態における方法の手順のすべてまたは一部が関連するハードウェアに命令するコンピュータプログラムによって遂行されてもよいことを、当業者は理解されよう。プログラムは、コンピュータ可読記憶媒体に格納されてもよい。プログラムが実行されると、前述の方法の実施形態の手順が含まれ得る。前述の記憶媒体は、ROM、ランダム・アクセス・メモリRAM、磁気ディスク、光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。
【符号の説明】
【0489】
110 プロセッサ
120 外部メモリインターフェース
121 内部メモリ
130 ユニバーサルシリアルバスインターフェース
140 充電管理モジュール
141 電力管理モジュール
142 バッテリ
150 移動通信モジュール
160 無線通信モジュール
170 オーディオモジュール
170A スピーカ
170B 受信機
170C マイクロフォン
170D ヘッドセットジャック
180 センサモジュール
180A 圧力センサ
180B ジャイロセンサ
180C 気圧センサ
180D 磁気センサ
180E 加速度センサ
180F 距離センサ
180G 光学式近接センサ
180H 指紋センサ
180J 温度センサ
180K タッチセンサ
180L 周囲光センサ
180M 骨伝導センサ
190 ボタン
191 モータ
192 インジケータ
193 カメラ
194 ディスプレイ
195 加入者識別モジュールカードインターフェース
120 外部メモリインターフェース
121 内部メモリ
130 ユニバーサルシリアルバスインターフェース
140 充電管理モジュール
141 電力管理モジュール
142 バッテリ
150 移動通信モジュール
160 無線通信モジュール
170 オーディオモジュール
170A スピーカ
170B 受信機
170C マイクロフォン
170D ヘッドセットジャック
180 センサモジュール
180A 圧力センサ
180B ジャイロセンサ
180C 気圧センサ
180D 磁気センサ
180E 加速度センサ
180F 距離センサ
180G 光学式近接センサ
180H 指紋センサ
180J 温度センサ
180K タッチセンサ
180L 周囲光センサ
180M 骨伝導センサ
190 ボタン
191 モータ
192 インジケータ
193 カメラ
194 ディスプレイ
195 加入者識別モジュールカードインターフェース
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B-1】
【図7B-2】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【図14】
【図15】
【図16A-1】
【図16A-2】
【図16B】
【図16C】
【図17A】
【図17B】
【図18】
【図19】
【図20】
【図21】
【図22A】
【図22B】
【図22C】
【図23A-1】
【図23A-2】
【図23B】
【図23C】
【図24】
【図25】
【図26A】
【図26B】
【図27】
【図28A】
【図28B】
【図29】
【図30】
【手続補正書】
【提出日】2024-07-23
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
第1の電子デバイスに適用されるインターフェース生成方法であって、前記第1の電子デバイスは、第1の表示領域に表示された内容が第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含むと決定し、前記方法は、前記第1のプロセスによって、第1のレンダツリーを生成するステップであって、前記第1のレンダツリーは、前記第1のプロセスの前記インターフェースを描画するために使用される、ステップと、
前記第2のプロセスによって、第2のレンダツリーを生成するステップであって、前記第2のレンダツリーは、前記第2のプロセスの前記インターフェースを描画するために使用される、ステップと、
第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットインターフェースを生成するステップであって、前記第1のターゲットインターフェースは、前記第1のプロセスの前記インターフェースおよび前記第2のプロセスの前記インターフェースを含み、前記第1のターゲットインターフェースは、前記第1の表示領域に表示される、ステップと
を含む、インターフェース生成方法。
【請求項2】
第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットインターフェースを生成する前記ステップは、前記第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成するステップと、
前記第3のプロセスによって、前記第1のターゲットレンダツリーに基づいて前記第1のターゲットインターフェースを生成するステップと
を具体的には含む、請求項1に記載の方法。
【請求項3】
前記第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて第1のターゲットレンダツリーを生成する前記ステップは、前記第3のプロセスによって、前記第1のターゲットレンダツリーのルートノードとしてルートレンダノードを作成し、前記第1のレンダツリーおよび前記第2のレンダツリーを前記ルートレンダノードの子ノードとして使用するステップと
を具体的には含む、請求項2に記載の方法。
【請求項4】
前記第3のプロセスによって、前記第1のレンダツリーのZオーダーおよび前記第2のレンダツリーのZオーダーに基づいて前記第1のターゲットレンダツリー内のレンダノードを削除するステップであって、前記削除されたレンダノードは完全に遮蔽されたビューに対応する、ステップとをさらに含む、請求項3に記載の方法。
【請求項5】
前記第3のプロセスによって、前記第1のレンダツリーのZオーダーおよび前記第2のレンダツリーのZオーダーに基づいて前記第1のターゲットレンダツリーにおける描画操作を削除するステップであって、前記削除された描画操作は完全に遮蔽されたグラフィックに対応する、ステップをさらに含む、請求項3に記載の方法。
【請求項6】
前記第3のプロセスが前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて前記第1のターゲットインターフェースを生成するプロセスにおいて、前記第3のプロセスによって、第1の描画操作および第2の描画操作に対してマージまたはバッチを実行するステップであって、前記第1の描画操作は前記第1のレンダツリーに属し、前記第2の描画操作は前記第2のレンダツリーに属する、ステップをさらに含む、請求項1に記載の方法。
【請求項7】
前記第3のプロセスによって、前記第1のプロセスの前記インターフェースのオフスクリーンレンダリングロジックを決定するステップであって、前記オフスクリーンレンダリングロジックは、ウィンドウ丸み付け、色変換、回転、およびスケーリングのうちの少なくとも1つを含む、ステップと、前記第3のプロセスによって、前記第1のプロセスの前記インターフェースの前記オフスクリーンレンダリングロジックに基づいて前記第1のレンダツリーのレンダリングプロパティにオフスクリーンレンダリングプロパティを追加するステップであって、前記オフスクリーンレンダリングプロパティは、丸み付けプロパティ、色プロパティ、回転プロパティ、およびスケーリングプロパティのうちの少なくとも1つを含む、ステップと
をさらに含み、
前記オフスクリーンレンダリングプロパティは、前記オフスクリーンレンダリングロジックに1対1に対応し、前記オフスクリーンレンダリングプロパティは、前記オフスクリーンレンダリングロジックを実現するために、前記第3のプロセスが前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて前記第1のターゲットインターフェースを生成する前記プロセスにおいて描画操作を修正するために使用される、
請求項1に記載の方法。
【請求項8】
前記第1のレンダツリーの基準座標系は、第1の座標系であり、前記第1の表示領域に対応する基準座標系は、第2の座標系であり、前記第1の座標系が前記第2の座標系と異なるとき、前記第3のプロセスによって、前記第1の座標系および前記第2の座標系に基づいて第1のパラメータを決定し、前記第1のパラメータを前記第1のレンダツリーの前記レンダリングプロパティに追加するステップと、
前記第3のプロセスが前記第1のレンダツリーおよび前記第2のレンダツリーに基づいて前記第1のターゲットインターフェースを生成する前記プロセスにおいて、前記第3のプロセスによって、前記第1のパラメータに基づいて前記第1の描画操作の基準座標系を修正するステップであって、前記第1の描画操作は、前記第1のレンダツリーに属する、ステップと
をさらに含む、請求項1に記載の方法。
【請求項9】
第2の電子デバイスに適用されるインターフェース生成方法であって、前記第2の電子デバイスは、第1の表示領域に表示された内容が第1のプロセスのインターフェースおよび第2のプロセスのインターフェースを含むと決定し、前記方法は、前記第2の電子デバイス上で動作する第3のプロセスによって、第1のレンダツリーおよび第2のレンダツリーを受信するステップであって、前記第1のレンダツリーは、第1の電子デバイス上で動作する前記第1のプロセスによって生成され、前記第1のレンダツリーは、前記第1のプロセスの前記インターフェースを描画するために使用され、前記第2のレンダツリーは、前記第2の電子デバイス上で動作する前記第2のプロセスによって生成され、前記第2のレンダツリーは、前記第2のプロセスの前記インターフェースを描画するために使用される、ステップと、
前記第3のプロセスによって、前記第1のレンダツリーおよび前記第2のレンダツリーに基づいてターゲットインターフェースを生成するステップであって、前記ターゲットインターフェースは、前記第1のプロセスの前記インターフェースおよび前記第2のプロセスの前記インターフェースを含み、前記ターゲットインターフェースは、前記第1の表示領域に表示される、ステップと
を含む、インターフェース生成方法。
【請求項10】
1つ以上のプロセッサおよびメモリを備える電子デバイスであって、前記メモリは、前記1つ以上のプロセッサに結合され、前記メモリは、コンピュータプログラムコードを格納するように構成され、前記コンピュータプログラムコードは、コンピュータ命令を含み、前記1つ以上のプロセッサは、前記コンピュータ命令を呼び出し、その結果、前記電子デバイスは、請求項1から9のいずれか一項に記載の方法を行う、電子デバイス。
【請求項11】
電子デバイスに適用されるチップシステムであって、前記チップシステムは、1つ以上のプロセッサを備え、前記プロセッサは、コンピュータ命令を呼び出すように構成され、その結果、前記電子デバイスは、請求項1から9のいずれか一項に記載の方法を実行する、チップシステム。
【請求項12】
命令を含むコンピュータ可読記憶媒体であって、前記命令が電子デバイスで実行されると、前記電子デバイスは、請求項1から9のいずれか一項に記載の方法を行うことを可能にされる、コンピュータ可読記憶媒体。
【請求項13】
コンピュータ可読命令を含むコンピュータプログラム製品であって、前記コンピュータ可読命令が1つ以上のプロセッサによって実行されると、請求項1から9のいずれか一項に記載の方法が実現される、コンピュータプログラム製品。
【国際調査報告】