特許7241729 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ 阿波▲羅▼智▲聯▼（北京）科技有限公司の特許一覧

特許7241729リソーススケジューリング方法、装置、設備、記憶媒体、及びプログラム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-03-09

(45)【発行日】2023-03-17

(54)【発明の名称】リソーススケジューリング方法、装置、設備、記憶媒体、及びプログラム

(51)【国際特許分類】

G06F 9/50 20060101AFI20230310BHJP

【ＦＩ】

G06F9/50 120A

【請求項の数】 12

(21)【出願番号】P 2020201112

(22)【出願日】2020-12-03

(65)【公開番号】P2021190074

(43)【公開日】2021-12-13

【審査請求日】2020-12-04

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

(32)【優先日】2020-05-28

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

(73)【特許権者】

【識別番号】521208273

【氏名又は名称】阿波▲羅▼智▲聯▼（北京）科技有限公司

【氏名又は名称原語表記】ＡＰＯＬＬＯＩＮＴＥＬＬＩＧＥＮＴＣＯＮＮＥＣＴＩＶＩＴＹ（ＢＥＩＪＩＮＧ）ＴＥＣＨＮＯＬＯＧＹＣＯ．，ＬＴＤ．

【住所又は居所原語表記】１０１，１ｓｔＦｌｏｏｒ，Ｂｕｉｌｄｉｎｇ１，Ｙａｒｄ７，ＲｕｉｈｅＷｅｓｔ２ｎｄＲｏａｄ，ＢｅｉｊｉｎｇＥｃｏｎｏｍｉｃａｎｄＴｅｃｈｎｏｌｏｇｉｃａｌＤｅｖｅｌｏｐｍｅｎｔＺｏｎｅ，Ｂｅｉｊｉｎｇ１００１７６，Ｃｈｉｎａ

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤和彦

(74)【代理人】

【識別番号】100108213

【弁理士】

【氏名又は名称】阿部豊隆

(72)【発明者】

【氏名】ワン，ゼシャン

(72)【発明者】

【氏名】ジア，ジャン

【審査官】漆原孝治

(56)【参考文献】

【文献】特開２０１１－１００３３８（ＪＰ，Ａ）

【文献】特開２０１２－０５８９０７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ９／５０

(57)【特許請求の範囲】

【請求項1】

現在のシステムが高計算力シーンに入るよう既にトリガされた目標アプリケーションをロードできるか否かをモニタリングすることであって、前記目標アプリケーションが、まもなく高計算力シーンに入るとき、まもなく高計算力シーンに入ることの放送を送信する、ことと、
前記システムが前記目標アプリケーションをロードできないとモニタリングした場合に、前記システムに対してリソーススケジューリングを行い、前記システム及び高計算力シーンに入るようまだトリガされていない残りの既に実行されているアプリケーションが前記放送を受信した後、前記目標アプリケーションの高計算力シーンプロセスをリアルタイムプロセスに設定するとともに、前記システム内のＣＰＵおよび／または前記残りの既に実行されているアプリケーションに対してリソーススケジューリング処理を行うことと、
スケジューリングされたシステムリソースに基づいて、高計算力シーンにある前記目標アプリケーションを実行することと、を含むことを特徴とするリソーススケジューリング方法。

【請求項2】

前記現在のシステムが高計算力シーンに入るよう既にトリガされた目標アプリケーションをロードできるか否かをモニタリングすることは、
現在のシステムにおいて既に実行されているアプリケーションの実行状態データに基づいて、前記システムに高計算力シーンに入るよう既にトリガされた目標アプリケーションが存在するか否かをモニタリングすることと、
前記システムに前記目標アプリケーションが存在するとモニタリングした場合に、前記システムが前記目標アプリケーションをロードできるか否かをモニタリングすることと、を含むことを特徴とする請求項１に記載のリソーススケジューリング方法。

【請求項3】

前記現在のシステムにおいて既に実行されているアプリケーションの実行状態データに基づいて、前記システムに高計算力シーンに入るよう既にトリガされた目標アプリケーションが存在するか否かをモニタリングすることは、
既に実行されているアプリケーションの実行状態データのいずれかが高計算力シーンのトリガ条件を満たすと検出された場合に、高計算力シーントのリガ条件を満たす既に実行されているアプリケーションを目標アプリケーションと決定すること、を含む
ことを特徴とする請求項２に記載のリソーススケジューリング方法。

【請求項4】

前記システムが前記目標アプリケーションをロードできるか否かをモニタリングすることは、
前記システムにおいて既に実行されているアプリケーションのそれぞれの現在の実行状態データと現在の中央処理装置ＣＰＵのアイドル率とに基づいて、システムのロードストレス値を計算することと、
前記システムのロードストレス値がロードストレス閾値よりも大きいと検出した場合に、前記システムが前記目標アプリケーションをロードできないと決定することと、を含む
ことを特徴とする請求項２に記載のリソーススケジューリング方法。

【請求項5】

前記システム内のＣＰＵに対してリソーススケジューリング処理を行うことは、
ＣＰＵの時分割処理のメカニズムに基づいて、前記システムにおける目標アプリケーションのプロセス処理の時間を延長し、かつ、前記残りの既に実行されているアプリケーションのプロセス処理の時間を短縮すること、を含む
ことを特徴とする請求項１に記載のリソーススケジューリング方法。

【請求項6】

前記システム内のＣＰＵに対してリソーススケジューリング処理を行うことは、
前記システム内のＣＰＵの周波数を最大周波数に調整すること、を含む
ことを特徴とする請求項１に記載のリソーススケジューリング方法。

【請求項7】

前記システム内の高計算力シーンに入るようまだトリガされていない残りの既に実行されているアプリケーションに対してリソーススケジューリング処理を行うことは、
前記システム内の残りの既に実行されているアプリケーションのサイレント機能のプロセスを一時停止すること、を含む
ことを特徴とする請求項１に記載のリソーススケジューリング方法。

【請求項8】

前記システムはスマートビークルシステムであり、前記目標アプリケーションには少なくとも地図ナビゲーションアプリケーションとスマート音声アプリケーションとを少なくとも含む、
ことを特徴とする請求項１に記載のリソーススケジューリング方法。

【請求項9】

現在のシステムが高計算力シーンに入るよう既にトリガされた目標アプリケーションをロードできるか否かをモニタリングするシステムモニタリングモジュールであって、前記目標アプリケーションが、まもなく高計算力シーンに入るとき、まもなく高計算力シーンに入ることの放送を送信する、システムモニタリングモジュールと、
前記システムが前記目標アプリケーションをロードできないとモニタリングした場合に、前記システムに対してリソーススケジューリングを行い、前記システム及び高計算力シーンに入るようまだトリガされていない残りの既に実行されているアプリケーションが前記放送を受信した後、前記目標アプリケーションの高計算力シーンプロセスをリアルタイムプロセスに設定するとともに、前記システム内のＣＰＵおよび／または前記残りの既に実行されているアプリケーションに対してリソーススケジューリング処理を行うリソーススケジューリングモジュールと、
スケジューリングされたシステムリソースに基づいて、高計算力シーンにある前記目標アプリケーションを実行するアプリケーション実行モジュールと、を備える
ことを特徴とするリソーススケジューリング装置。

【請求項10】

少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに通信接続されるメモリと、を備え、
前記メモリには、前記少なくとも１つのプロセッサにより実行可能な命令が記憶されており、
前記命令は、前記少なくとも１つのプロセッサにより実行される場合、請求項１～８のいずれか１項に記載のリソーススケジューリング方法を実行させることを特徴とする電子設備。

【請求項11】

請求項１～８のいずれか１項に記載のリソーススケジューリング方法をコンピュータに実行させるためのコンピュータ命令を記憶した非一過性のコンピュータ可読記憶媒体。

【請求項12】

コンピュータにおいて、プロセッサにより実行される場合、請求項１～８のいずれか１項に記載のリソーススケジューリング方法を実現することを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、コンピュータ技術分野に関し、特にシステムリソーススケジューリング技術分野に関し、具体的にリソーススケジューリング方法、装置、設備、記憶媒体、及びプログラムに関する。

【背景技術】

【0002】

スマートビークルシステム等のスマートデバイスにおいて、実行されているアプリケーションの読み込みが比較的多い、又はアプリケーションの実行している機能が比較的多い場合、システムＣＰＵの使用率が高くなって、比較的多くのＣＰＵリソースを占め、ＣＰＵの周波数調整が連続的に遅く、消耗時間が長いため、アプリケーションの高計算力シーンに追いつけず、さらにはアプリケーションにラグが発生する現象が現れる。そのため、システムのハードウェア構成に対してアップグレードを行わないもとで、既存の技術は高計算力シーンに入ったアプリケーションのスムーズな実行を確保できない。

【発明の概要】

【発明が解決しようとする課題】

【0003】

リソーススケジューリング方法、装置、設備、及び記憶媒体を提供し、高計算力シーンに入るアプリケーションのスムーズな実行を保証する。

【課題を解決するための手段】

【0004】

本発明の第１態様は、リソーススケジューリング方法を提供し、当該方法は、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングすることと、前記システムが前記目標アプリケーションをロードできないとモニタリングした場合に、前記システムに対してリソーススケジューリングを行うことと、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある前記目標アプリケーションを実行することと、を含む。

【0005】

本発明の第２態様は、リソーススケジューリング装置を提供し、当該装置は、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングするシステムモニタリングモジュールと、前記システムが前記目標アプリケーションをロードできないとモニタリングした場合に、前記システムに対してリソーススケジューリングを行うリソーススケジューリングモジュールと、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある前記目標アプリケーションを実行するアプリケーション実行モジュールと、を備える。

【0006】

本発明の第３態様は、電子設備を提供し、少なくとも１つのプロセッサと、少なくとも１つのプロセッサと通信接続するメモリと、を備え、メモリには、少なくとも１つのプロセッサにより実行される命令が記憶されており、命令は、少なくとも１つのプロセッサにより実行される場合、本発明のいずれか一項に記載の実施形態により提供されるリソーススケジューリング方法を実行させる。

【0007】

本発明の第４態様は、本発明のいずれか一項に記載の実施形態により提供されるリソーススケジューリング方法をコンピュータに実行させるためのコンピュータ命令を記憶した非一過性のコンピュータ可読記憶媒体を提供する。

【0008】

本発明の技術に基づいて、如何にシステムのハードウェア構成に対してアップグレードを行わないもとで、高計算力シーンに入るアプリケーションのスムーズな実行を確保するのかという問題を解決する。

【0009】

ここに記載された内容は、本発明の実施形態のキーポイント又は重要な特徴を識別することを意図せず、また、本発明の範囲を制限することにも用いられないことを理解すべきである。本発明の他の特徴については、下記の明細書を通して説明を促す。

【図面の簡単な説明】

【0010】

添付図面は、本方案をより良く理解するためのものであり、本発明を限定するものではない。

【図1】本発明の実施形態によるリソーススケジューリング方法のフローチャートである。

【図2】本発明の実施形態による他のリソーススケジューリング方法のフローチャートである。

【図3】本発明の実施形態によるシステムモニタリングの模式図である。

【図4】本発明の実施形態による他のリソーススケジューリング方法のフローチャートである。

【図5】本発明の実施形態によるシステムリソーススケジューリングの模式図である。

【図6】本発明の実施形態による他のリソーススケジューリング方法のフローチャートである。

【図7】本発明の実施形態によるリソーススケジューリング装置の構成模式図である。

【図8】本発明の実施形態によるリソーススケジューリング方法の電子設備のブロック図である。

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

【0011】

以下、添付図面を参照しながら、本発明の例示的な実施形態について説明するが、理解を容易にするために本発明の実施形態の様々な詳細が含まれており、それらは単なる例示的なものと見なすべきである。したがって、当業者は、本発明の範囲及び旨から逸脱することがなく、本発明の明細書に記載された実施形態に対して様々な変更及び修正を行うことができることを理解すべきである。同様に、以下の説明では、明瞭かつ簡潔のために、公知の機能及び構造についての説明を省略する。

【0012】

図１は、本発明の実施形態によるリソーススケジューリング方法のフローチャートであり、本実施形態は、現在のシステムにおいて、まもなく高計算力シーンに入る目標アプリケーションが存在するとモニタリングしたとき、システムに対してリソーススケジューリングを行い、目標アプリケーションが高計算力シーンに入った後にスムーズに実行できるようにする。該方法はリソーススケジューリング装置により行われることができ、該装置はソフトウェア及び／又はハードウェアの方法を用いて実現され、電子設備、例えば、スマートビークルシステムが集積されているスマートデバイスに配置されるのが好ましい。図１に示すように、該方法は、具体的に以下のステップを含む。

【0013】

Ｓ１１０において、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングする。

【0014】

本発明の具体的な実施形態において、システムは、デバイスのハードウェアとソフトウェアリソースとを管理するコンピュータプログラムを指す。システムには複数のアプリケーション（Application，App）をインストールし、アプリケーションのための実行環境を提供してもよい。同一の時間内に、システムに1つ又は複数の実行中にある既に実行されているアプリケーションが存在してもよく、相応的に、アプリケーションの実行は一定のシステムリソースを占有している。

【0015】

本実施形態において、計算力とは、中央処理装置（Central Processing Unit，ＣＰＵ）の毎秒あたりの実行回数を指し、例えば、ＣＰＵは毎秒1.4万回実行される。アプリケーションの高計算力シーンとは、ＣＰＵの計算力を比較的高く消費する実行シーンを指す。例えば、地図ナビゲーションアプリケーションの遠距離ナビゲーションシーンや、スマート音声アプリケーションの音声認識や解析シーン等である。システムの実行しているアプリケーションが比較的多い場合、又はアプリケーションの実行している機能が比較的多い場合、システムＣＰＵの使用率が比較的高くなって、比較的大きなＣＰＵリソースを占めているため、システムにはラグが発生する等の不具合が発生しやすい。

【0016】

相応的に、システムにおいて既に実行されているアプリケーションのそれぞれに対するモニタリングにより、トリガされたが、まだ高計算力シーンに入っていない既に実行されているアプリケーションを、目標アプリケーションと決定することができる。そのうち、予め設定された高計算力トリガ条件に基づいて、既に実行されているアプリケーションのそれぞれの実行状態データより、アプリケーションの高計算力シーンがトリガされたか否かを決定することができる。システム全体から見ると、目標アプリケーションの高計算力シーンは必ずシステムが高計算力シーンに入ることを引き起こし、例えば、ＣＰＵ使用率が９２％を超える。しかし、逆に、ＣＰＵ使用率が高いとき、必ずしも高計算力シーンに入っているアプリケーションがあるというわけではない。

【0017】

例示的に、地図アプリケーションは、ユーザのナビゲーションリクエストに応じて、ユーザが入力したナビゲーションの始終点情報を取得する。地図アプリケーションがナビゲーションの始終点等の実行状態データに基づいてナビゲーション経路の計画を行う前に、システム又はシステムにおけるシステムモニタリング専用のモニタリングは、ナビゲーションの始終点に基づいて今回のナビゲーションが遠距離ナビゲーションであると判断したとすると、該地図アプリケーションを高計算力シーンがトリガされた目標アプリケーションと決定することができる。しかし、システムのロードストレスの検出及びシステムリソースのスケジューリングの前に、該地図アプリケーションはまだナビゲーション経路の計画操作を実行しない。

【0018】

本実施形態において、システムの目標アプリケーションに対するロードとは、システムが目標アプリケーションの実行を負担できることを指し、即ち、システムは目標アプリケーションに十分なシステムリソースを提供でき、目標アプリケーションがスムーズな実行をできるようにし、ラグが発生する等のユーザの体験を低下させる現象は現れない。目標アプリケーションの高計算力シーンがトリガされたとしても、システムは目標アプリケーションをロードできるとモニタリングした場合、システムのリソーススケジューリングを必要とせず、後続の目標アプリケーションをスムーズに実行することができると理解されるべきである。システムは目標アプリケーションをロードできないとモニタリングした場合、後続の目標アプリケーションの実行には必ずラグが発生する等の現象が現れ、相応的に、目標アプリケーションが高計算力シーンに入る前に、システムに対してリソーススケジューリングを行う必要がある。

【0019】

具体的に、システム内に独立したシステムモニタリングモジュールを集積してもよく、アプリケーション及びシステムに対する高計算力シーンのモニタリングに用いられる。それぞれのアプリケーションに対して、それぞれのアプリケーションに対応する高計算力シーンのトリガ条件を予め設定することができる。システムモニタリングモジュールはシステムにおいて既に実行されているアプリケーションの実行状態データを同期することを通して、該既に実行されているアプリケーションの実行状態データは対応する高計算力シーンのトリガ条件を満たすか否かを判別し、目標アプリケーションを決定する。次に、システムＣＰＵの使用率又はアイドル率に基づいて、システム内の全ての既に実行されているアプリケーションの状態データに応じて、システムのロードストレス値を計算する。システムのロードストレス値がロードストレス閾値よりも大きい場合、システムは目標アプリケーションをロードできないと決定し、逆の場合、システムは目標アプリケーションをロードできる。

【0020】

そのうち、車両のスマート化が進むにつれて、スマートビークルシステムに携帯されている、例えば、スマートスピーカー、スマートバックミラー、スマートフォン、スマートカーケース等のススマートデバイスはますます増え、これらのスマートデバイスに携帯されている、例えば、音楽、ビデオ、地図、ランチャ（Launcher）等の機能もますます増えている。スマートビークルシステムに集積されているチップのスペックが通常比較的低いが、システムのハードウェア構成を向上するのが製品のコストを高めるため、製品の販売に影響を与える。そのため、選択的に、本実施形態におけるシステムは、スマートビークルシステムであってもよく、相応的に、目標アプリケーションは、地図ナビゲーションアプリケーションやスマート音声アプリケーション等を含むが、これらに限定されない。

【0021】

Ｓ１２０において、システムが目標アプリケーションをロードできないとモニタリングした場合に、システムに対してリソーススケジューリングを行う。

【0022】

本発明の具体的な実施形態において、システムが目標アプリケーションをロードできない場合、目標アプリケーションのスムーズな実行を保証するため、目標アプリケーション自体、より多くのシステムリソースを実行のために必要とする。相応的に、本実施形態におけるシステムリソーススケジューリングとは、より多くのシステムリソースを目標アプリケーションの実行に使用されるよう分配することを指す。

【0023】

例示的に、システムの面から、システム内のＣＰＵの周波数を高周波又は最大周波数に調整してもよく、ＣＰＵの実行速度を向上させ、システムの計算能力を向上させる。システムの面から、さらに、ＣＰＵの時分割処理のメカニズムに基づいて、システムにおける目標アプリケーションのプロセス処理の時間を延長し、かつ、残りの既に実行されているアプリケーションのプロセス処理の時間を短縮してもよく、即ち、優先的に目標アプリケーションを処理してもよい。アプリケーションの面から、システム内の残りの既に実行されているアプリケーションのサイレント機能のプロセスを一時停止してもよく、即ち、残りの既に実行されているアプリケーションにおけるユーザが感知していない、又は感知が小さい機能のプロセスを一時停止し、できるだけ大きいリソースを目標アプリケーションが使用できるようにする。

【0024】

Ｓ１３０において、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある前記目標アプリケーションを実行する。

【0025】

本発明の具体的な実施形態において、システムリソースに対してスケジューリングした後、目標アプリケーションは高計算力シーンに入ることができ、目標アプリケーションの高計算力シーンに対応する機能を実現する。例えば、上記遠距離ナビゲーションシーンにおいて、地図ナビゲーションアプリケーションは遠距離ナビゲーションシーンに入ることができ、遠距離のナビゲーション経路を計画し、かつ、ユーザにナビゲーションサービスを提供する。さらに、目標アプリケーションの高計算力シーン終了をモニタリングしたとき、システムリソースを復元することができる。例えば、ＣＰＵの周波数を復元し、ＣＰＵの時分割処理のプロセスを再開し、残りの既に実行されているアプリケーションの一時停止している機能をそれぞれ復元する等である。

【0026】

本実施形態の技術方案において、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングし、かつ、システムが前記目標アプリケーションをロードできないとモニタリングした場合に、システムに対してリソーススケジューリングを行い、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある前記目標アプリケーションを実行できるようにする。本発明の実施形態では、アプリケーション及びシステムの高計算力シーンに対するモニタリングを通して、システムがロードできないとモニタリングした場合に、システムリソースに対してスケジューリングを行い、高計算力シーンに入るアプリケーションのために十分なシステムリソースを提供し、高計算力シーンに入るアプリケーションがスムーズに実行できるよう保証するだけでなく、ラグが発生する等の不具合がアプリケーションに現れることを避け、システムのハードウェア構成に対してアップグレードすることを必要とせず、システムのハードウェアコストをダウンすることができる。

【0027】

図２は、本発明の実施形態による他のリソーススケジューリング方法のフローチャートであり、本実施形態は、上記実施形態を基に、ステップＳ１１０における、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングすることについてさらに説明を行い、現在のシステムにおいて既に実行されているアプリケーションの実行状態データに基づいて、システムに高計算力シーンに入るように既にトリガされた目標アプリケーションが存在するか否かをモニタリングすることができ、システムに目標アプリケーションが存在するとモニタリングした場合に、システムが目標アプリケーションをロードできるか否かをモニタリングする。図２に示すように、該方法は、具体的に以下のステップを含む。

【0028】

Ｓ２１０において、現在のシステムにおいて既に実行されているアプリケーションの実行状態データに基づいて、システムに高計算力シーンに入るように既にトリガされた目標アプリケーションが存在するか否かをモニタリングする。

【0029】

本発明の具体的な実施形態において、既に実行されているアプリケーションとは、システムにおいて実行中のアプリケーションを指し、例えば、ナビゲーション中の地図ナビゲーションアプリケーション、ユーザとの音声対話を行っているスマート音声アプリケーション、及び音楽を再生している音楽アプリケーション等である。

【0030】

本実施形態において、実行状態データは、既に実行されているアプリケーションの現在のすべての実行において受信又は生成されたデータを含むことができ、アプリケーションの基礎パラメータ、アプリケーション状態を識別するパラメータ、ユーザの入力したデータ、ユーザの入力したデータの属性パラメータ等を含むが、これらに限定されない。例示的には、地図ナビゲーションアプリケーションの実行状態データは、少なくとも車両の現在の位置座標、ナビゲーション終点の位置座標、車両速度、及び道路状況等を含むことができる。スマート音声アプリケーションの実行状態データは、少なくとも録音状態にあるか否か、解析状態にあるか否か、録音したオーディオの長さ、録音時間等を含むことができる。音楽アプリケーションの実行状態データは、少なくとも再生状態にあるか否か、バッファ状態にあるか否か、解析状態にあるか否か、バッファ又は解析されたオーディオの長さ、バッファ又は解析されたオーディオファイルのサイズ等を含むことができる。

【0031】

具体的に、システム内に独立したシステムモニタリングモジュールを集積し、システムにおいて既に実行されているアプリケーションの実行状態データをそれぞれリアルタイムに同期し、かつ、既に実行されているアプリケーションのそれぞれの実行状態データに基づいて、高計算力シーンにまもなく入る目標アプリケーションが存在するか否かを予測することができる。

【0032】

選択的に、既に実行されているアプリケーションの実行状態データのいずれかが高計算力シーンのトリガ条件を満たすと検出された場合に、高計算力シーンのトリガ条件を満たす既に実行されているアプリケーションを目標アプリケーションと決定する。

【0033】

本実施形態において、高計算力シーンのトリガ条件は、アプリケーションがまもなく高計算力シーンに入ろうとしているか否かを判別するために用いられる。システム内のアプリケーションは、それぞれ1つ又は複数の高計算力シーンを有し、高計算力シーンはそれぞれ対応する高計算力シーンのトリガ条件を有する。例えば、地図ナビゲーションアプリケーションの高計算力シーンは、遠距離ナビゲーション等を含むことができ、スマート音声アプリケーションの高計算力シーンは、長時間録音シーン、大オーディオファイルの意味解析シーン等を含むことができ、音楽アプリケーションの高計算力シーンは、大オーディオファイルのバッファやデコードシーン等を含むことができる。

【0034】

具体的に、アプリケーションがそれぞれ高計算力シーンに入るときのシステムリソースに対する占有状況に応じて、アプリケーションのそれぞれの高計算力シーンを予め定義し、かつ、高計算力シーンのそれぞれに高計算力シーンのトリガ条件を設定することができる。したがって、システムモニタリングモジュールが既に実行されているアプリケーションの実行状態データをそれぞれリアルタイムに同期して得た後に、実行状態データに対して計算を行い、又は実行状態データと対応する高計算力シーンのトリガ条件との直接比較を行い、高計算力シーンのトリガ条件を満たす既に実行されているアプリケーションを目標アプリケーションとして決定する。

【0035】

例示的に、地図ナビゲーションアプリケーションがナビゲーションを行うとき、ナビゲーション始終点に基づいて、推定経路の長さが高計算力シーンの閾値よりも大きいと決定した場合、及び／又は推定経路の通過する交差点の数を高計算力シーンの閾値よりも大きいと決定した場合、地図ナビゲーションアプリケーションの高計算力シーンはトリガされたと判断する。スマート音声アプリケーションが録音又は解析を行うとき、オーディオの長さが高計算力シーンの閾値よりも大きい場合、スマート音声アプリケーションの高計算力シーンはトリガされたと判断する。音楽アプリケーションがオーディオをバッファ又はデコードを行うとき、オーディオの時間が長い又はファイルのサイズが高計算力シーンの閾値よりも大きい場合、音楽アプリケーションの高計算力シーンはトリガされたと判断する。

【0036】

そのうち、予め設定された高計算力シーンのトリガ条件を通して、アプリケーションの高計算力シーンの予測に根拠を提供し、高計算力シーンの予測精度を向上させ、システムにおいて既に実行されているアプリケーションの現在の実行優先度を決定できるようにし、さらに、システムにおいて現在スムーズな実行を保証する必要のある、まもなく高計算力シーンに入る目標アプリケーションを正確に定める。

【0037】

Ｓ２２０において、システムに目標アプリケーションが存在するとモニタリングした場合に、システムが目標アプリケーションをロードできるか否かをモニタリングする。
本発明の具体的な実施形態において、目標アプリケーションの高計算力シーンは必ずシステムが高計算力シーンに入ることを引き起こし、例えば、ＣＰＵ使用率が９２％を超える。しかし、逆に、ＣＰＵ使用率が高いとき、必ずしも高計算力シーンに入っているアプリケーションがあるわけというではなく、例えば、ＣＰＵ使用率が９２％を超えるときでも、システムは依然として地図ナビゲーションアプリケーションの近距離ナビゲーションをロードすることができる。そのため、本実施形態は、システムに高計算力シーンに入るように既にトリガされた目標アプリケーションが存在とモニタリングした場合のみ、即ち、システムにおいて現在スムーズな実行を保証する必要のある目標アプリケーションを正確に定めた場合に、システムが該目標アプリケーションをロードできるか否かをモニタリングする。

【0038】

具体的に、本実施形態は、ＣＰＵ使用率を基に、システムにおいて既に実行されているアプリケーションのそれぞれの実行状況を総合して、システムが高計算力シーンにある目標アプリケーションをロードできるか否かを総合的に判断することができる。システムがロードできると判断した場合、システム内のアプリケーションはそれぞれ正常に実行し、ロードできないと判断した場合、システムモニタリングモジュールは既に実行されているアプリケーションのうちの目標アプリケーション以外のアプリケーションに対して放送を送信して、残りの既に実行されているアプリケーションに目標アプリケーションが存在し、さらにシステムはまもなく高計算力シーンに入ることを知らせ、後続のシステムリソーススケジューリングができるようにする。

【0039】

選択的に、システムにおいて既に実行されているアプリケーションのそれぞれの現在の実行状態データと現在の中央処理装置ＣＰＵのアイドル率とに基づいて、システムのロードストレス値を計算し、システムのロードストレス値がロードストレス閾値よりも大きいと検出した場合に、システムは目標アプリケーションをロードできないと決定する。

【0040】

本実施形態において、ＣＰＵのアイドル率とは、システムにおいて全体のリソースに対する使用されていないシステムリソースの比重を指し、ＣＰＵのアイドル率は、1からＣＰＵ使用率を引いたものである。システムのロードストレス値は、システムの現在のロードストレスを測るのに用いられる。システムのロードストレス値が高いほど、システムの現在のストレスが大きいことを表し、現在のシステム環境において、ラグが発生する等の不具合が出現する確率が高い。そのうち、ロードストレス閾値を予め設定し、ロードストレス値がロードストレス閾値よりも大きいと検出した場合に、システムは目標アプリケーションをロードできないと決定する。

【0041】

具体的に、以下の公式に基づきシステムのロードストレス値を計算することができる。

【0042】

ロードストレス値＝（ＣＰＵのアイドル率×重み０＋アプリケーション１の実行状態データ×重み１＋アプリケーション２の実行状態データ×重み２＋…＋アプリケーションＮの実行状態データ×重みＮ）×１００

【0043】

そのうち、アプリケーション１～アプリケーションＮは、システムにインストールされているすべてのアプリケーションである。数値形式の実行状態データについては、直接に代入することができ、状態識別の実行状態データについては、予めその状態に対応する代表値を設定してもよく、例えば、録音状態にない代表値を０とし、録音状態にある代表値を０．８とすることで、状態の代表値を代入する。アプリケーションが実行されていない場合、相応の実行状態データはゼロとなる。アプリケーションのそれぞれのシステムリソースに対する占有状況が異なるため、ＣＰＵのアイドル率及びそれぞれのアプリケーションに対応する重みを設定することもでき、重み０～重みＮの合計は１である。システムのロードストレス値の最大値が１００点とで、ロードストレス閾値が８５点と仮定すると、現在のシステムのロードストレス値が８５点を超えていると検出した場合、システムは目標アプリケーションをロードできないと決定する。

【0044】

例示的に、図３はシステムモニタリングの模式図である。図３に示すように、実行状態データは、コア計算力指標データと、高計算力シーンをトリガするシーンデータとに細かく分けてもよい。システムにおいて既に実行されているアプリケーションは、それぞれコア計算力指標データをシステムモニタリングモジュールにリアルタイムで同期し、高計算力シーンをトリガする可能性のあるシーンデータをシステムモニタリングモジュールに転送することができる。したがって、システムモニタリングモジュールは、アプリケーションに対してリアルタイムでモニタリングを行い、既に高計算力シーンをトリガされた目標アプリケーションが存在するか否かを予測する。かつ、目標アプリケーションが存在する場合、システムが目標アプリケーションをロードできるか否かを予測する。最終的に、システムは目標アプリケーションをロードできないと判断したとき、既に実行されているアプリケーションのうちの目標アプリケーション以外のアプリケーションに対して放送を送信して、残りの既に実行されているアプリケーションに目標アプリケーションが存在することとシステムはまもなく高計算力シーンに入ることとを知らせる。例えば、地図ナビゲーションアプリケーションは、自身の経緯度、速度及び道路状況等の情報をシステムモニタリングモジュールに同期し、ユーザのナビゲーションリクエストを受信すると、システムモニタリングモジュールがリアルタイムでモニタリングするように、目的地の経緯度をシステムモニタリングモジュールに転送する。

【0045】

そのうち、システムにおいて既に実行されているアプリケーションのそれぞれの現在の実行状態データとＣＰＵのアイドル率とに基づいて、システムのロードストレス値を計算することで、高計算力シーンにある目標アプリケーションに対するシステムのロード能力を測定し、単にＣＰＵのアイドル率等のシステムの指標に基づいて、システムのロードストレスを評価したときに、実際に実行を保証する必要のある目標アプリケーションを見落とすことを避け、システムのロードストレスが測る正確性を高め、ストレスが比較的大きい、即ち目標アプリケーションの実行にラグが存在したときに、後続のシステムリソーススケジューリングを実行するようにしたため、システムリソースに対する必要のないスケジューリングを避ける。

【0046】

本実施形態は、まず、既に実行されているアプリケーションの高計算力シーンに対してモニタリングを行い、システムに高計算力シーンに入るように既にトリガされた目標アプリケーションが存在するとモニタリングした場合に、システムが高計算力シーンにある目標アプリケーションをロードできるか否かを予測することにより、システムにおいて現在スムーズな実行を保証する必要のある目標アプリケーションを定めるだけでなく、さらにシステムのロードストレスの評価に根拠を提供し、システムが高計算力シーンにある目標アプリケーションに対する真のロード能力を得ることで、ストレスが比較的大きい、即ち目標アプリケーションの実行にラグが存在したときに、後続のシステムリソーススケジューリングを実行するようにしたため、システムリソースに対する必要のないスケジューリングを避ける。

【0047】

Ｓ２３０において、システムが目標アプリケーションをロードできないとモニタリングした場合に、システムに対してリソーススケジューリングを行う。

【0048】

Ｓ２４０において、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある目標アプリケーションを実行する。

【0049】

本実施形態の技術方案において、システムにおいて現在実行されているアプリケーションのそれぞれの実行状態データに基づいて、高計算力シーンに入るように既にトリガされた目標アプリケーションが存在するか否かをモニタリングし、目標アプリケーションが存在するとモニタリングした場合のみ、システムの高計算力シーンにある目標アプリケーションに対するロード能力をモニタリングし、システムが高計算力シーンをロードできないとモニタリングしたとき、システムに対してリソーススケジューリングを行い、アプリケーションがスケジューリングされた後のシステムリソースに基づいて高計算力シーンにある目標アプリケーションを実行できるようにする。本発明の実施形態では、アプリケーション及びシステムの高計算力シーンに対するモニタリングを通して、システムがロードできないとモニタリングした場合に、システムリソースに対してスケジューリングを行い、高計算力シーンに入るアプリケーションのために十分なシステムリソースを提供し、高計算力シーンに入るアプリケーションがスムーズに実行できるよう保証するだけでなく、ラグが発生する等の不具合がアプリケーションに現れることを避け、システムのハードウェア構成に対してアップグレードすることを必要とせず、システムのハードウェアコストをダウンすることができる。

【0050】

図４は、本発明の実施形態による他のリソーススケジューリング方法のフローチャートであり、本実施形態は、上記実施形態を基に、ステップＳ１２０におけるシステムリソーススケジューリングに対して説明を行い、システム内のＣＰＵ及び／又は高計算力シーンに入るようにまだトリガされていない残りの既に実行されているアプリケーションに対してリソーススケジューリング処理を行うことができる。図４に示すように、該方法は、具体的に以下のステップを含む。

【0051】

Ｓ４１０において、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングする。

【0052】

Ｓ４２０において、システムは目標アプリケーションをロードできないとモニタリングした場合に、システム内のＣＰＵ及び／又は高計算力シーンに入るようにまだトリガされていない残りの既に実行されているアプリケーションに対してリソーススケジューリング処理を行う。

【0053】

本発明の具体的な実施形態において、ＣＰＵの機能は、主に命令処理、実行操作、時間制御及びデータ処理であり、ＣＰＵは、コンピュータのすべてのハードウェアリソース（メモリ、入出力ユニット等）を制御、配分し、汎用演算を実行するコアのハードウェアユニットである。ＣＰＵの構成情報を変更することより、目標アプリケーションにより速い実行速度と実行時間を提供することができる。

【0054】

本実施形態において、残りの既に実行されているアプリケーションとは、目標アプリケーション以外のアプリケーションを指し、即ち高計算力シーンに入るようにまだトリガされていないことである。残りの既に実行されているアプリケーションも一定のシステムリソースを占めているため、残りの既に実行されているアプリケーションのプロセス処理状態に対して適宜に調整してもよく、目標アプリケーションにより多くのシステムリソースを提供する。

【0055】

そのうち、ＣＰＵと残りの既に実行されているアプリケーションのいずれか一項に対するスケジューリングは、すべて目標アプリケーションにより多くのシステムリソースを提供することができ、高計算力シーンの実行をサポートする。そのため、ＣＰＵと実残りの既に実行されているアプリケーションに基づくシステムリソーススケジューリングの方法は、単独に使用してもよく、また、組み合わせて使用してもよい。組み合わせて使用する方法が多いほど、目標アプリケーションに提供されるシステムリソースが多く、目標アプリケーションの実行はよりスムーズになることを理解すべきである。

【0056】

本実施形態は、システムのハードウェア構成に対してアップグレードを行わず、システムのソフトウェアに対してシステムリソーススケジューリングを行い、システムのハードウェア構成の元のコストを維持するだけでなく、システムのハードウェア構成のアップグレードによる製品コストの増加や製品の販売量への影響を避けることができ、さらに、システム内の限られたリソースに対して柔軟にスケジューリングを行うことができ、最大限の掘削により、目標アプリケーション高計算力シーンの実行を助けることができ、システムリソースの利用率を高める。

【0057】

選択的に、ＣＰＵの時分割処理のメカニズムに基づいて、システムにおける目標アプリケーションのプロセス処理の時間を延長し、かつ、残りの既に実行されているアプリケーションのプロセス処理の時間を短縮する。

【0058】

本実施形態において、ＣＰＵの時分割処理のメカニズムとは、ＣＰＵがクロックにより制御され、一定のタイムスライス内にタスクの一部をそれぞれ完成させ、中間処理の結果を保存した後、次のタスクの一部を実行して保存し、このように、すべてのタスク処理が完了するまでループする。そのうち、タスクのそれぞれの処理タイムスライスは短いが、ＣＰＵの計算速度が高いため、タスクのそれぞれの処理結果に影響を与えない。例えば、Ａ、Ｂ、Ｃの３つのプロセスを時分割実行し、Ａプロセスを実行した１ｓ後にＢプロセスを実行し、Ｂプロセスを実行した１ｓ後にＣプロセスを実行し、Ｃプロセスを実行した２ｓ後に再びＡプロセスを実行するように、３つのプロセスを処理し終わるまでループする。

【0059】

本実施形態において、ＣＰＵの時分割処理のメカニズムにおいて、１つの処理周期内で、目標アプリケーションのプロセス処理の時間を延長し、かつ、残りの既に実行されているアプリケーションのプロセス処理の時間を短縮することにより、高計算力シーンプロセスをリアルタイムプロセスのように設定する。そのうち、本実施形態は、プロセス処理の時間の延長及び短縮の方式については限定しない。例えば、上記の例において、Ａプロセスを高計算力シーンプロセスと仮定すると、Ａプロセスを実行した３ｓ後にＢプロセスを実行し、Ｂプロセスを実行した０．５ｓ後にＣプロセスを実行し、Ｃプロセスを実行した０．５ｓ後に再びＡプロセスを実行するように変更し、このようにループする。

【0060】

そのうち、ＣＰＵの時分割処理のメカニズムにおけるプロセス処理のそれぞれの時間の長さを調整することにより、既に実行されているアプリケーションにおけるそれぞれのプロセス処理の優先度を適宜に調整し、より多くのＣＰＵ演算能力を、残りの既に実行されているアプリケーションから目標アプリケーションに均等に割り当てることで、１つのＣＰＵの処理周期における処理の時間を高める。

【0061】

選択的に、システム内のＣＰＵの周波数を最大周波数に調整する。

【0062】

本実施形態において、ＣＰＵの周波数とは、ＣＰＵのクロック周波数を指し、即ちＣＰＵ演算時の動作周波数（1秒以内に発生する同期パルス数）であり、コンピュータの実行速度を決定する。最大周波数とは、ＣＰＵの周波数の最大値を指し、相応的に、ＣＰＵが最大周波数に達したとき、コンピュータの実行速度は最大であり、データ処理能力が最強である。

【0063】

本実施形態において、システムに高計算力シーンにおけるＣＰＵの周波数調整の規則を予め追加してもよく、システムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできないとモニタリングした場合、ＣＰＵの周波数を最大周波数に引き上げる。例えば、ＣＰＵの最大周波数をシステムアドレスｓｙｓ／ｄｅｖｉｃｅｓ／ｓｙｓｔｅｍ／ｃｐｕ／ｃｐｕ０／ｃｐｕｆｒｅｑ／ｓｃａｌｉｎｇ＿ｍｉｎ＿ｆｒｅｑに書き込み、書き込んだ周波数に基づいてシステムが直接周波数調整を行えるようにする。

【0064】

そのうち、従来のＣＰＵ周波数調整方法において、ＣＰＵの周波数は連続的に変化し、全体の周波数調整の時間は長い。目標アプリケーションの高計算力シーンは瞬時に入るため、従来のＣＰＵ周波数調整方法は高計算力シーンに入ることに追いつけず、即ち高計算力シーンに入るとき、ＣＰＵの周波数はまだ緩やかな周波数調整過程にあり、計算力シーンの目標アプリケーションをサポートすることができない。従来技術に対して、本実施形態はＣＰＵの周波数調整時間を大幅に短縮し、最短時間で目標アプリケーションに最高のコンピュータ実行速度を提供し、目標アプリケーションのスムーズな実行を十分にサポートする。

【0065】

選択的に、システム内の残りの既に実行されているアプリケーションのサイレント機能のプロセスを一時停止する。

【0066】

本実施形態において、サイレント機能とは、ユーザに如何なる通知又は相互の機能も行わないことを指し、即ちユーザの目又は耳は、感知しない又は感知が小さい機能である。例えば、システムのバックグラウンドのバッファ、解析、ダウンロード又は傍受等の機能である。

【0067】

具体的に、既に実行されているアプリケーションのプロセスに対して識別を行うことができ、既に実行されているアプリケーションにおけるそれぞれのサイレント機能のプロセスを決定し、かつ、サイレント機能のプロセスをすべて一時停止し、即ちユーザ体験に影響を与えないプロセスを一時停止し、ユーザ体験に影響を与えない又は影響が比較的小さいプロセスのシステムリソースに対する占有を避け、目標アプリケーションにより多くのシステムリソースを均等に割り当て、ユーザの利用体験に影響を与えないようにする。

【0068】

例示的に、音楽アプリケーションの音楽再生機能は、ユーザが完全に感知するものであるため、音楽アプリケーションの音楽再生機能に関するプロセスを保留する。残りの既に実行されているアプリケーションにおけるバックグラウンド傍受機能、バックグラウンドダウンロード機能、バックグラウンドアップロード機能等を一時停止する。

【0069】

そのうち、本実施形態は、サイレント機能の識別方法に対して限定せず、いかなるサイレント機能を識別する方法も本実施形態に応用することができる。例えば、システムにおけるアプリケーションのそれぞれの機能に対して予め分類を行い、予めサイレント機能を選出し、検出されるべき機能と予め設定されたサイレント機能との比較を行うことで、サイレント機能を識別する。

【0070】

Ｓ４３０において、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある目標アプリケーションを実行する。

【0071】

本発明の具体的な実施形態において、システムリソースに対してスケジューリングを行った後、目標アプリケーションは瞬時に高計算力シーンに入ることができ、目標アプリケーションの高計算力シーンに対応する機能を実現する。そのうち、目標アプリケーションの実行過程において、さらに上記実施形態におけるアプリケーション及びシステムのモニタリング方法に基づいて、目標アプリケーションは高計算力シーンを終了したか否かをリアルタイムでモニタリングし、システムのロードストレス値を計算することにより、システムは高計算力シーンに対するロードを終了したか否かを決定することができる。さらに、目標アプリケーション及びシステムの高計算力シーンの終了をモニタリングした場合、上記システムリソースリソーススケジューリングに対して復元を行い、即ちＣＰＵの周波数を復元し、ＣＰＵの時分割処理のプロセスを再開し、残りの既に実行されているアプリケーションの一時停止している機能をそれぞれ復元する。

【0072】

例示的に、図５はシステムリソーススケジューリングの模式図である。図５に示すように、目標アプリケーション及びシステムがまもなく、例えば、遠距離ナビゲーション等の高計算力シーンに入ると決定したとき、システムモニタリングモジュールはまもなく高計算力シーンに入ることの放送を送信する。相応的に、システムは放送を受信した後、ＣＰＵの周波数を最大周波数に調整し、かつ、目標アプリケーションの高計算力シーンプロセスをリアルタイムプロセスに設定する。残りの既に実行されているアプリケーションは放送を受信した後、バックグラウンド傍受、ダウンロード、アップロード等の一連のサイレント機能のプロセスを一時停止する。これにより、システムリソーススケジューリングを終わらせ、高計算力シーンに入る。さらに、高計算力シーンが終了すると、システムはＣＰＵの周波数及びアプリケーションプロセスの優先度を復元し、残りの既に実行されているアプリケーションはバックグラウンド傍受、ダウンロード、アップロード等の一連のサイレント機能のプロセスを復元する。これにより高計算力シーンにおけるシステムリソースのスケジューリングを終わらせる。

【0073】

本実施形態の技術方案において、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングし、かつ、システムは目標アプリケーションをロードできないとモニタリングした場合に、システム内のＣＰＵ及び／又は残りの既に実行されているアプリケーションに対してリソーススケジューリングを行い、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある目標アプリケーションを実行できるようにする。本発明の実施形態では、アプリケーション及びシステムの高計算力シーンに対するモニタリングを通して、システムがロードできないとモニタリングした場合に、システムリソースに対してスケジューリングを行い、高計算力シーンに入るアプリケーションのために十分なシステムリソースを提供し、高計算力シーンに入るアプリケーションがスムーズに実行できるよう保証するだけでなく、ラグが発生する等の不具合がアプリケーションに現れることを避け、システムのハードウェア構成に対してアップグレードすることを必要とせず、システムのハードウェアコストをダウンすることができる。

【0074】

図６は、本発明の実施形態による他のリソーススケジューリング方法のフローチャートであり、本実施形態は、上記実施形態を基に、ステップＳ１１０とＳ１２０との実施形態についてさらに総合する。図６に示すように、該方法は、具体的に以下のステップを含む。

【0075】

Ｓ６１０において、既に実行されているアプリケーションの実行状態データのいずれかが高計算力シーンのトリガ条件を満たすと検出された場合に、高計算力シーンのトリガ条件を満たす既に実行されているアプリケーションを目標アプリケーションと決定する。

【0076】

Ｓ６２０において、システムにおいて既に実行されているアプリケーションのそれぞれの現在の実行状態データと現在の中央処理装置ＣＰＵのアイドル率とに基づいて、システムのロードストレス値を計算する。

【0077】

Ｓ６３０において、システムのロードストレス値がロードストレス閾値よりも大きいと検出した場合に、システムは前記目標アプリケーションをロードできないと決定する。

【0078】

Ｓ６４０において、システムに対してリソーススケジューリングを行い、以下の少なくとも1つを実行する。

【0079】

ＣＰＵの時分割処理のメカニズムに基づいて、システムにおける目標アプリケーションのプロセス処理の時間を延長し、かつ、残りの既に実行されているアプリケーションのプロセス処理の時間を短縮する。

【0080】

システム内のＣＰＵの周波数を最大周波数に調整する。

【0081】

システム内の残りの既に実行されているアプリケーションのサイレント機能のプロセスを一時停止する。

【0082】

Ｓ６５０において、スケジューリングされたシステムリソースに基づいて、高計算力シーンにある目標アプリケーションを実行する。

【0083】

本発明の実施形態では、アプリケーション及びシステムの高計算力シーンに対するモニタリングを通して、システムがロードできないとモニタリングした場合に、システムリソースに対してスケジューリングを行い、高計算力シーンに入るアプリケーションのために十分なシステムリソースを提供し、高計算力シーンに入るアプリケーションがスムーズに実行できるよう保証するだけでなく、ラグが発生する等の不具合がアプリケーションに現れることを避け、システムのハードウェア構成に対してアップグレードすることを必要とせず、システムのハードウェアコストをダウンすることができる。

【0084】

図７は、本発明の実施形態によるリソーススケジューリング装置の構成模式図であり、本実施形態は、現在のシステムにおいて、まもなく高計算力シーンに入る目標アプリケーションが存在するとモニタリングしたとき、システムに対してリソーススケジューリングを行い、目標アプリケーションが高計算力シーンに入った後にスムーズに実行できるようにし、該装置は、本発明の任意の実施形態において述べられているリソーススケジューリング方法を実現することができる。該装置７００は、具体的に以下のモジュールを含む。

【0085】

システムモニタリングモジュール７１０において、現在のシステムが高計算力シーンに入るように既にトリガされた目標アプリケーションをロードできるか否かをモニタリングする。

【0086】

リソーススケジューリングモジュール７２０において、前記システムが前記目標アプリケーションをロードできないとモニタリングした場合に、前記システムに対してリソーススケジューリングを行う。

【0087】

アプリケーション実行モジュール７３０において、ケジューリングされたシステムリソースに基づいて、高計算力シーンにある前記目標アプリケーションを実行する。

【0088】

選択的に、前記システムモニタリングモジュール７１０は、具体的に以下のユニットを含む。

【0089】

アプリケーションモニタリングユニット７１０１は、現在のシステムにおいて既に実行されているアプリケーションの実行状態データに基づいて、前記システムに高計算力シーンに入るように既にトリガされた目標アプリケーションが存在するか否かをモニタリングする。

【0090】

システムモニタリングユニット７１０２は、前記システムに前記目標アプリケーションが存在するとモニタリングした場合に、前記システムが前記目標アプリケーションをロードできるか否かをモニタリングする。

【0091】

選択的に、前記アプリケーションモニタリングユニット７１０１は、具体的に、既に実行されているアプリケーションの実行状態データのいずれかが高計算力シーンのトリガ条件を満たすと検出された場合に、高計算力シーンのトリガ条件を満たす既に実行されているアプリケーションを目標アプリケーションと決定することに用いられる。

【0092】

選択的に、前記システムモニタリングユニット７１０２は、具体的に、前記システムにおいて既に実行されているアプリケーションのそれぞれの現在の実行状態データと現在の中央処理装置ＣＰＵのアイドル率とに基づいて、システムのロードストレス値を計算し、前記システムのロードストレス値がロードストレス閾値よりも大きいと検出した場合に、前記システムは前記目標アプリケーションをロードできないと決定することに用いられる。

【0093】

選択的に、前記リソーススケジューリングモジュール７２０は、具体的に、前記システム内のＣＰＵ及び／又は高計算力シーンに入るようにまだトリガされていない残りの既に実行されているアプリケーションに対してリソーススケジューリング処理を行うことに用いられる。

【0094】

選択的に、前記リソーススケジューリングモジュール７２０は、具体的に、ＣＰＵの時分割処理のメカニズムに基づいて、前記システムにおける目標アプリケーションのプロセス処理の時間を延長し、かつ、前記残りの既に実行されているアプリケーションのプロセス処理の時間を短縮することに用いられる。

【0095】

選択的に、前記リソーススケジューリングモジュール７２０は、具体的に、前記システム内のＣＰＵの周波数を最大周波数に調整することに用いられる。

【0096】

選択的に、前記リソーススケジューリングモジュール７２０は、具体的に、前記システム内の残りの既に実行されているアプリケーションのサイレント機能のプロセスを一時停止することに用いられる。

【0097】

選択的に、前記システムはスマートビークルシステムであり、前記目標アプリケーションには少なくとも地図ナビゲーションアプリケーションとスマート音声アプリケーションとを少なくとも含む。

【0098】

本実施形態の技術方案は、機能モジュールのそれぞれの間の相互協力によって、実行状態データの同期、目標アプリケーションの高計算力シーンのモニタリング、システムのロードストレスのモニタリング、ＣＰＵの周波数の調合、ＣＰＵの時分割処理のメカニズムの調合、残りの既に実行されているアプリケーションのサイレント機能のプロセスの一時停止、高計算力シーンに入ること、高計算力シーンの終了及びシステムの復元等の機能を実現する。本発明の実施形態では、アプリケーション及びシステムの高計算力シーンに対するモニタリングを通して、システムがロードできないとモニタリングした場合に、システムリソースに対してスケジューリングを行い、高計算力シーンに入るアプリケーションのために十分なシステムリソースを提供し、高計算力シーンに入るアプリケーションがスムーズに実行できるよう保証するだけでなく、ラグが発生する等の不具合がアプリケーションに現れることを避け、システムのハードウェア構成に対してアップグレードすることを必要とせず、システムのハードウェアコストをダウンすることができる。

【0099】

本発明の実施形態によれば、本発明は、電子設備及び可読記憶媒体をさらに提供する。

【0100】

図８に示すよう、本発明の実施形態によるリソーススケジューリング方法を実現する電子設備のブロック図である。電子設備は、ラップトップコンピュータ、デスクトップコンピュータ、ワークステーション、パーソナルデジタルアシスタント、サーバ、ブレードサーバ、大型コンピュータ、及び他の適切なコンピュータのような様々な形態のデジタルコンピュータを表すことができる。また、電子設備はパーソナルデジタル処理、携帯電話、スマートフォン、装着可能デバイス、及びその他の類似のコンピューティングデバイス等の様々な形態のモバイルデバイスを表すことができる。ここで示した構成要素、それらの接続と関係、及びそれらの機能は例示的なものに過ぎず、本発明で説明されたもの及び／又は要求される本発明の実施を制限することは意図されない。

【0101】

図８に示すよう、当該電子設備は、１つ又は複数のプロセッサ８０１と、メモリ８０２と、高速インターフェースと低速インターフェースとを含む各構成要素を接続するためのインターフェースとを含む。各構成要素は、異なるバスを利用して互いに接続し、共通のマザーボードに取り付けられてもよいし、必要に応じて他の方法で取り付けられてもよい。プロセッサは、電子設備内で実行される命令を処理してもよく、また、外部入出力デバイス（例えば、インターフェースに接続された表示デバイス）にグラフィックユーザインターフェース（ＧｒａｐｈｉｃａｌＵｓｅｒＩｎｔｅｒｆａｃｅ，ＧＵＩ）を表示するための、メモリ又はメモリ上に記憶されたグラフィカル情報の命令を含む。他の実施形態では、必要に応じて、複数のプロセッサ及び／又は複数のバスを複数のメモリ及び複数のメモリとともに使用することができる。同様に、複数の電子設備を接続してもよく、各デバイスは、部分的に必要な動作（例えば、サーバアレイ、ブレードサーバのセット、又はマルチプロセッサシステムとして）を提供する。図８においてプロセッサ８０１を例とする。

【0102】

メモリ８０２は、本発明にて提供された非一過性のコンピュータ可読記憶媒体である。メモリは、本発明で提供されるリソーススケジューリング方法を少なくとも１つのプロセッサに実行させるように、少なくとも１つのプロセッサによって実行されることができる命令を記憶する。本発明における非一過性のコンピュータ可読記憶媒体は、本発明で提供されたリソーススケジューリング方法をコンピュータに実行させるためのコンピュータ命令を記憶する。

【0103】

メモリ８０２は、非一過性のコンピュータ可読記憶媒体として、非一過性のソフトウェアプログラム、非一過性のコンピュータ実行可能なプログラム及びモジュールを記憶するために使用されてもよく、本発明の実施形態におけるリソーススケジューリング方法に対応するプログラム命令／モジュール（例えば、図７に示すモニタリングモジュール７１０、リソーススケジューリングモジュール７２０及びアプリケーション実行モジュール７３０）のようなものである。プロセッサ８０１は、メモリ８０２に記憶されている非一過性のソフトウェアプログラム、命令及びモジュールを実行することにより、サーバの様々な機能アプリケーション及びデータ処理、即ち上述した方法に関する実施形態に係るリソーススケジューリング方法を実行する。

【0104】

メモリ８０２は、オペレーティングシステムや少なくとも１つの機能に必要なアプリケーションを記憶することができるプログラムの記憶領域と、リソーススケジューリング方法に係る電子設備の使用によって生成されたデータ等を記憶することができるデータの記憶領域と、を含むことができる。さらに、メモリ８０２は、高速ランダムアクセスメモリを含んでもよく、非一過性の固体記憶装置を含んでもよい。例えば、少なくとも１つの磁気ディスク記憶装置、フラッシュメモリ装置、又は他の非一過性の固体記憶装置を含むことができる。いくつかの実施形態では、メモリ８０２はオプションとして、プロセッサ８０１に対して遠隔的に設定されたメモリを含み、これらの遠隔メモリは、ネットワークを介してリソーススケジューリング方法に係る電子設備に接続されてもよい。上記のネットワークの例は、インターネット、企業内ネットワーク、ローカルネットワーク、モバイル通信ネットワーク及びその組み合わせを含むが、これらに限定されない。

【0105】

本発明の実施形態のリソーススケジューリング方法に対応する電子設備は、入力装置８０３と出力装置８０４とをさらに含むことができる。プロセッサ８０１、メモリ８０２、入力装置８０３、及び出力装置８０４は、バス又は他の方法で接続されてもよく、図８ではバスを介して接続されている。

【0106】

入力装置８０３は、入力された数字又は文字を受信し、リソーススケジューリング方法に係る電子設備のユーザ設定及び機能制御に関するキー信号入力を生成することができ、例えば、タッチパネル、キーパッド、マウス、トラックボード、タッチパッド、指示棒、１つ又は複数のマウスボタン、トラックボール、ジョイスティック等を含むことができる。出力装置８０４は、表示装置、補助照明装置（例えばＬＥＤ）、及び触覚フィードバック装置（例えば、振動モータ）等を含むことができる。この表示装置は、液晶ディスプレイ（ＬｉｑｕｉｄＣｒｙｓｔａｌＤｉｓｐｌａｙ、ＬＣＤ）、発光ダイオード（ＬｉｇｈｔＥｍｉｔｔｉｎｇＤｉｏｄｅ、ＬＥＤ）ディスプレイ及びプラズマディスプレイを含むことができるがこれらに限定されない。いくつかの実施形態では、表示装置はタッチパネルであってもよい。

【0107】

本発明におけるシステム及び技術に係る様々な実施形態は、デジタル電子回路システム、集積回路システム、専用集積回路（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔｓ、ＡＳＩＣ）、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／又はこれらの組み合わせによって実現されることができる。これらの様々な実施形態は、１つ又は複数のコンピュータプログラムにおいて実装されてもよく、この１つ又は複数のコンピュータプログラムは、少なくとも１つのプログラマブルプロセッサを含むプログラム可能なシステム上で実行されてもよく、及び／又は解釈されてもよく、このプログラマブルプロセッサは、専用又は汎用のプログラマブルプロセッサであってもよく、記憶システム、少なくとも１つの入力装置、及び少なくとも１つの出力装置より、データと命令を受信し、記憶システム、少なくとも１つの入力装置、及び少なくとも１つの出力装置に、データと命令を送信する。

【0108】

これらの計算プログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードともいう）は、プログラマブルプロセッサのマシン命令を含み、プロセス指向及び／又はオブジェクト指向プログラミング言語、及び／又はアセンブリ／マシン言語を用いてこれらの計算プログラムを実施することができる。本発明で使用されるように、「機械可読媒体」及び「コンピュータ可読媒体」という用語は、マシン命令及び／又はデータをプログラマブルプロセッサに提供するための任意のコンピュータプログラム製品、デバイス、及び／又は装置（例えば、磁気ディスク、光ディスク、メモリ、編集可能論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅｌｏｇｉｃｄｅｖｉｃｅ、ＰＬＤ）を意味し、機械読み取り可能な信号としてのマシン命令を受信する機械可読媒体を含む。「機械読み取り可能な信号」という用語は、マシン命令及び／又はデータをプログラマブルプロセッサに提供するための任意の信号を意味する。

【0109】

ユーザとのイントラクションを提供するために、本発明で説明されているシステムや技術は、コンピュータ上で実施されてもよく、また、ユーザに情報を表示するための表示装置（例えば、ＣＲＴ（ＣａｔｈｏｄｅＲａｙＴｕｂｅ、ブラウン管）又はＬＣＤ（液晶ディスプレイ）モニタ）と、入力をコンピュータに提供するためのキーボード及びポインティングデバイス（例えば、マウス又はトラックボール）とを備えてもよい。他の種類の装置も、ユーザとのイントラクションを提供するために使用され得る。例えば、ユーザに提供されたフィードバックは、任意の形態のセンシングフィードバック（例えば、視覚フィードバック、聴覚フィードバック、又は触覚フィードバック）であってもよく、ユーザからの入力は、いかなる形式（音響入力、音声入力、又は触覚入力を含む）で受信されてもよい。

【0110】

本発明で説明されているシステム及び技術は、バックグラウンド構成要素を含む計算システム（例えば、データサーバとして）、又は中間部構成要素を含む計算システム（例えば、アプリケーションサーバ）、又は、フロントエンド構成要素を含む計算システム（例えば、グラフィカルユーザインタフェース又はネットワークブラウザを備えたユーザコンピュータであって、ユーザがこのグラフィカルユーザインタフェース又はネットワークブラウザを介して本発明で説明されたシステム及び技術に係る実施形態とインタラクションを行うことができるユーザコンピュータ）に実行されてもよく、又は、このようなバックグラウンド構成要素、中間部構成要素、又はフロントエンド構成要素の任意の組合せを含む計算システムにおいて実行されてもよい。システムの構成要素は、任意の形態又は媒体のデジタルデータ通信（例えば、通信ネットワーク）によって相互に接続されてもよい。通信ネットワークの例えとして、ローカルネットワーク（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ，ＬＡＮ）、広域ネットワーク（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ，ＷＡＮ）及びインターネットを含む。

【0111】

コンピュータシステムは、クライアント及びサーバを含むことができる。クライアントとサーバは一般的に相互に離れており、通信ネットワークを介してインタラクションを行う。クライアントとサーバとの関係を持つコンピュータプログラムがそれぞれのコンピュータ上で実行されることによって、クライアントとサーバとの関係は構築される。

【0112】

本発明の技術方案によると、アプリケーション及びシステムの高計算力シーンに対するモニタリングを通して、システムがロードできないとモニタリングした場合に、システムリソースに対してスケジューリングを行い、高計算力シーンに入るアプリケーションのために十分なシステムリソースを提供し、高計算力シーンに入るアプリケーションがスムーズに実行できるよう保証するだけでなく、ラグが発生する等の不具合がアプリケーションに現れることを避け、システムのハードウェア構成に対してアップグレードすることを必要とせず、システムのハードウェアコストをダウンする。

【0113】