特表2024-541894 | 知財ポータル「IP Force」

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

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

▶ ▲騰▼▲訊▼科技（深▲セン▼）有限公司の特許一覧

特表2024-541894データ処理方法、装置、機器、及びプログラム

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

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

< >

1a
1b
1c
1d
1e
1f
1g
2a
2b
2c
3a
3b
4
5
6a
6b
7
8

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

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

(11)【公表番号】

(43)【公表日】2024-11-13

(54)【発明の名称】データ処理方法、装置、機器、及びプログラム

(51)【国際特許分類】

G06F 11/07 20060101AFI20241106BHJP

【ＦＩ】

G06F11/07 190

G06F11/07 193

G06F11/07 157

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024523972

(86)(22)【出願日】2023-04-25

(85)【翻訳文提出日】2024-04-22

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

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

(87)【国際公開日】2024-01-18

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

(32)【優先日】2022-07-13

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．ＷＩＮＤＯＷＳ

２．ＪＡＶＡ

３．ＪＡＶＡＳＣＲＩＰＴ

４．ｉＯＳ

(71)【出願人】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

【氏名又は名称原語表記】ＴＥＮＣＥＮＴＴＥＣＨＮＯＬＯＧＹ（ＳＨＥＮＺＨＥＮ）ＣＯＭＰＡＮＹＬＩＭＩＴＥＤ

【住所又は居所原語表記】３５／Ｆ，ＴｅｎｃｅｎｔＢｕｉｌｄｉｎｇ，ＫｅｊｉｚｈｏｎｇｙｉＲｏａｄ，ＭｉｄｗｅｓｔＤｉｓｔｒｉｃｔｏｆＨｉ－ｔｅｃｈＰａｒｋ，ＮａｎｓｈａｎＤｉｓｔｒｉｃｔ，Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８０５７，ＣＨＩＮＡ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾直樹

(72)【発明者】

【氏名】曹 ▲チェン▼

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

5B042

【Ｆターム（参考）】

5B042JJ13

5B042JJ15

5B042KK15

5B042KK17

(57)【要約】

本願は、データ処理方法、装置、機器、及び記憶媒体を開示し、方法は、目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得するステップであって、いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において生じるものであり、現場情報は、相応な無応答現象が生じるときのシステムコードの実行状況を記述することに用いられる、ステップと、各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ共通性分析結果に基づき、システムコードから無応答現象が生じる障害点を決定するステップと、障害点に基づきシステムコードを修復処理することにより、修復後のシステムコードに基づいて目標アプリケーションを動作させるステップと、を含む。本願は、クラウドサーバにより実行されてもよく、オペレーティングシステムのレベルから目標アプリケーションの無応答現象を効果的に解決し、いずれか一種類の無応答現象が発生する確率を低減させることができ、汎用性が高く、全体の安定性を向上させることができる。

【特許請求の範囲】

【請求項1】

コンピュータ機器により実行される、データ処理方法であって、前記方法は、
目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得するステップであって、いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて前記目標アプリケーションを動作させる過程において生じるものであり、且ついずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときの前記システムコードの実行状況を記述することに用いられる、ステップと、
前記各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ前記共通性分析結果に基づき、前記システムコードから無応答現象が生じる障害点を決定するステップであって、前記共通性分析結果は、前記各種類の無応答現象の現場情報における共通情報を含む、ステップと、
前記障害点に基づき前記システムコードを修復処理することにより、修復後のシステムコードに基づいて前記目標アプリケーションを動作させるステップと、を含む、データ処理方法。

【請求項2】

前記システムコードは、複数のプロセスと、個々のプロセスにより実行されるコードセグメントと、を含み、前記いずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときに、前記システムコードにおいて動作する各々のプロセスのプロセス識別子を含み、
前記各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得ることは、
前記各種類の無応答現象の現場情報のうちのいずれかの現場情報に対して、前記いずれかの現場情報における各々のプロセス識別子をトラバースするステップと、
前記いずれかの現場情報以外の各々の現場情報において、現在トラバースされているプロセス識別子を探すステップと、
前記現在トラバースされているプロセス識別子を見つけ出した場合に、前記現在トラバースされているプロセス識別子を共通性分析結果内に追加するステップと、
前記現在トラバースされているプロセス識別子を見つけ出さなかった場合に、前記いずれかの現場情報における各々のプロセス識別子をトラバースし続けるステップと、を含む、請求項１に記載の方法。

【請求項3】

前記共通性分析結果は、各種類の前記無応答現象の現場情報の間で共通するプロセス識別子を含み、前記共通性分析結果に基づき、前記システムコードから無応答現象が生じる障害点を決定することは、
前記共通性分析結果における各々のプロセス識別子に基づいてＭ個の目標プロセスを決定するステップであって、Ｍの数値は、前記共通性分析結果におけるプロセス識別子の数に等しい、ステップと、
前記Ｍ個の目標プロセスのうちの各々の目標プロセス間の関連関係を決定し、且つ前記システムコードから前記各々の目標プロセスにより実行されるコードセグメントを取得するステップと、
前記関連関係に基づいて、取得されたＭ個のコードセグメントから、無応答現象が生じる障害点を決定するステップと、を含む、請求項１、又は２に記載の方法。

【請求項4】

前記Ｍ個の目標プロセスは、第１プロセスと、第２プロセスと、を含み、前記Ｍ個の目標プロセスのうちの各々の目標プロセス間の関連関係を決定することは、
前記各種類の無応答現象の現場情報から、前記第１プロセスの属性情報、及び前記第２プロセスの属性情報を取得するステップであって、いずれかのプロセスの属性情報は、前記いずれかのプロセスのプロセス番号と、前記いずれかのプロセスを呼び出すプロセスのプロセス番号と、を含む、ステップと、
前記第２プロセスの属性情報において前記第１プロセスのプロセス番号が含まれる場合、又は前記第１プロセスの属性情報において前記第２プロセスのプロセス番号が含まれる場合に、前記第１プロセスと前記第２プロセスとの間の関連関係が親子関係であると決定するステップと、を含む、請求項３に記載の方法。

【請求項5】

前記Ｍ個の目標プロセスは、第１プロセスと、第２プロセスと、を含み、且つ前記第１プロセスと前記第２プロセスとの間の関連関係が親子関係であり、前記第１プロセスは、前記第２プロセスの親プロセスであり、
前記関連関係に基づいて、取得されたＭ個のコードセグメントから、無応答現象が生じる障害点を決定するステップは、
前記親子関係に基づいて、取得された第１プロセスにより実行されるコードセグメントを基準コードセグメントとして決定し、且つ前記基準コードセグメントから第１コード文を決定するステップであって、前記第１コード文とは、無応答現象が発生する前に、前記第１プロセスにより実行されるコード文を指す、ステップと、
前記第１コード文が関数呼び出し操作を実現することに用いられる文であるときに、前記第１プロセスが実行するコードセグメントにおいて第１コード文に沿って前記第１プロセスの呼び出しスタックを分析して得るステップであって、前記呼び出しスタックは、前記第１プロセスが呼び出す各種類の関数を含む、ステップと、
前記呼び出しスタックにおいて呼び出しに失敗した目標関数が存在する場合に、前記基準コードセグメントから前記目標関数のロジックコードを決定し、前記第２プロセスにより実行されるコードセグメントに基づいて、前記目標関数のロジックコードから、無応答現象が生じる障害点を決定するステップと、を含む、請求項３に記載の方法。

【請求項6】

前記目標関数のロジックコードにおいてプロセス作成文が含まれ、前記プロセス作成文は、子プロセスを作成することに用いられる文であり、且つ前記プロセス作成文によって作成された子プロセスと相応な親プロセスとの間で同一のアドレス空間を共有し、
前記第２プロセスにより実行されるコードセグメントに基づいて、前記目標関数のロジックコードから、無応答現象が生じる障害点を決定することは、
前記第２プロセスが実行するコードセグメントから第２コード文を決定するステップであって、前記第２コード文とは、無応答現象が発生する前に、前記第２プロセスにより実行されるコード文を指す、ステップと、
前記第２コード文がデータ読み取り操作を実現することに用いられる文であるときに、前記第２コード文に基づき、前記第２プロセスがデータ読み取り操作を実行することに必要な目標リソースを決定するステップと、
前記第１プロセスが前記目標リソースを持っている場合に、前記目標関数のロジックコードにおけるプロセス作成文を、無応答現象が生じる障害点として決定するステップと、を含み、
前記第２プロセスは、前記第１プロセスの子プロセスであり、前記第１プロセスが前記目標リソースを持っている場合に、前記第２プロセスは、ブロックされ、且つ前記第２プロセスがブロックされる継続時間が継続時間の閾値より大きいときに、無応答現象がトリガーされる、請求項５に記載の方法。

【請求項7】

前記障害点に基づき前記システムコードを修復処理することは、
子プロセスを作成することに用いられる目標文を決定するステップであって、前記目標文により作成される子プロセスと相応な親プロセスとは、異なるアドレス空間を独立して使用する、ステップと、
前記システムコードにおいて前記目標文を採用して前記プロセス作成文を置き換えることにより、前記システムコードを修復するステップと、を含む、請求項６に記載の方法。

【請求項8】

前記プロセス作成文において関数フィールドが含まれ、且つ前記関数フィールドに第１システム呼び出し関数が記憶され、前記プロセス作成文は、前記第１システム呼び出し関数によって子プロセスを作成し、
子プロセスを作成することに用いられる目標文を決定する前記ステップは、
前記プロセス作成文における関数フィールドにおける第１システム呼び出し関数を、第２システム呼び出し関数に修正し、子プロセスを作成することに用いられる目標文を得るステップを含み、
前記目標文は、前記第２システム呼び出し関数によって子プロセスを作成する、請求項７に記載の方法。

【請求項9】

前記目標アプリケーションの複数の種類の無応答現象は、サービス型の無応答現象を含み、前記サービス型の無応答現象が生じる過程は、
目標アプリケーションのアプリケーションプロセスが送信するサービス作成要求に応答して、サービスの継続時間の閾値を設定するステップと、
サービスプロセスにサービス作成メッセージを送信することにより、前記サービスプロセスが前記サービス作成メッセージに基づいて、１つ又は複数の他のプロセスを呼び出してサービス作成作業を実行するように前記サービスプロセスに通知し、且つサービスの作成が成功した後にフィードバック情報を返すステップと、
前記サービスの継続時間の閾値内に前記サービスプロセスから返されたフィードバック情報を受信しなかった場合に、前記サービス型の無応答現象が生じるステップと、を含む、請求項１に記載の方法。

【請求項10】

前記目標アプリケーションの複数の種類の無応答現象は、ブロードキャスト型の無応答現象を含み、前記ブロードキャスト型の無応答現象が生じる過程は、
目標アプリケーションのアプリケーションプロセスが開始したブロードキャスト送信要求に応答して、ブロードキャストの継続時間の閾値を設定するステップと、
ブロードキャスト受信プロセスにブロードキャスト登録メッセージを送信することにより、前記ブロードキャスト受信プロセスが前記ブロードキャスト登録メッセージに基づいて、１つ又は複数の他のプロセスを呼び出してブロードキャスト作業を実行するように前記ブロードキャスト受信プロセスに通知し、且つブロードキャストが完了した後にフィードバック情報を返すステップと、
前記ブロードキャストの継続時間の閾値内に前記ブロードキャスト受信プロセスから返されたフィードバック情報を受信しなかった場合に、前記ブロードキャスト型の無応答現象が生じるステップと、を含む、請求項１に記載の方法。

【請求項11】

前記目標アプリケーションの複数の種類の無応答現象は、コンテンツ提供型の無応答現象を含み、前記コンテンツ提供型の無応答現象が生じる過程は、
目標アプリケーションのアプリケーションプロセスが開始したコンテンツ提供オブジェクトの取得要求に応答して、前記コンテンツ提供オブジェクトと対応するコンテンツ提供プロセスの起動状態を検出するステップと、
前記起動状態が前記コンテンツ提供プロセスが起動していないことを指示する場合に、前記コンテンツ提供プロセスを作成し、且つ１つ又は複数の他のプロセスを呼び出して、前記コンテンツ提供オブジェクトをインストールするように前記コンテンツ提供プロセスに通知し、且つ前記コンテンツ提供オブジェクトをインストールした後にフィードバック情報を返すステップであって、前記コンテンツ提供オブジェクトに１つのインストールの継続時間の閾値が設定されている、ステップと、
前記インストールの継続時間の閾値内に前記コンテンツ提供プロセスから返されたフィードバック情報を受信しなかった場合に、前記コンテンツ提供型の無応答現象が生じるステップと、を含む、請求項１に記載の方法。

【請求項12】

前記目標アプリケーションの複数の種類の無応答現象は、入力イベント配信型の無応答現象を含み、前記入力イベント配信型の無応答現象が生じる過程は、
１つの入力イベントを受信した場合に、現在受信した入力イベントを入力キューに追加し、且つ入力配信スレッドをウェイクアップするステップであって、前記入力配信スレッドは、前記入力キューにおける各々の入力イベントを前記目標アプリケーションのアプリケーションプロセスに順番に配信して処理させることに用いられる、ステップと、
前記現在受信した入力イベントの配信順位に達するときに、前記目標アプリケーションのアプリケーションプロセスが他の入力イベントを処理すると、前記入力イベント配信型の無応答現象が生じるステップと、を含む、請求項１に記載の方法。

【請求項13】

データ処理装置であって、
目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得することに用いられる取得モジュールであって、いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて前記目標アプリケーションを動作させる過程において生じるものであり、且ついずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときの前記システムコードの実行状況を記述することに用いられる、取得モジュールと、
前記各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ前記共通性分析結果に基づき、前記システムコードから無応答現象が生じる障害点を決定することに用いられる処理モジュールであって、前記共通性分析結果は、前記各種類の無応答現象の現場情報における共通情報を含む、処理モジュールと、を含み、
前記処理モジュールは、前記障害点に基づき前記システムコードを修復処理することにより、修復後のシステムコードに基づいて前記目標アプリケーションを動作させることに用いられる、データ処理装置。

【請求項14】

コンピュータ機器であって、プロセッサと、メモリと、ネットワークインタフェースと、を含み、
前記プロセッサは、前記メモリ、及び前記ネットワークインタフェースに連結され、前記ネットワークインタフェースは、ネットワーク通信機能を提供することに用いられ、前記メモリは、コンピュータプログラムを記憶することに用いられ、前記プロセッサは、前記コンピュータプログラムを呼び出すことにより、請求項１～１２のうちのいずれか１項に記載のデータ処理方法を実行することに用いられる、コンピュータ機器。

【請求項15】

コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体にコンピュータプログラムが記憶されており、前記コンピュータプログラムがプロセッサに実行されるときに、請求項１～１２のうちのいずれか１項に記載のデータ処理方法を実行する、コンピュータ可読記憶媒体。

【請求項16】

コンピュータプログラムを含むコンピュータプログラム製品であって、コンピュータにおいて動作するときに、前記コンピュータに請求項１～１２のうちのいずれか１項に記載のデータ処理方法を実行させる、コンピュータプログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、コンピュータの技術分野に関し、特にデータ処理に関する。

【0002】

本願は、２０２２年７月１３日に中国特許庁に提出された、出願番号が第２０２２１０８１９９２８．７号であり、出願の名称が「データ処理方法、装置、機器、及び記憶媒体」である中国特許出願の優先権を主張し、その全部の内容は、引用によって本願に組み込まれている。

【背景技術】

【0003】

コンピュータ技術の発展に伴って、一部のオープンソースであるオペレーティングシステムが、オペレーティングシステムの二次開発、及びカスタマイズを可能にし、オペレーティングシステムにより提供されるますます多くの面白く、且つ実用的な機能が人々に便利でスピーディな体験をもたらし続けている。

【0004】

オペレーティングシステムにおいて各種のアプリケーションプログラムの動作がサポートされるが、もしアプリケーションプログラムの応答の感度が十分に高くなければ、ＡＮＲ（ＡｐｐｌｉｃａｔｉｏｎＮｏｔＲｅｓｐｏｎｄｉｎｇ、アプリケーション無応答）の現象が発生し得る可能性があり、このようなＡＮＲ現象の存在は、使用体験に影響を与え得る。しかしながら、現状では、ＡＮＲを解決するスキームは、ほとんど、他人の分析経験に基づいて自分が遭遇したＡＮＲ問題のポジショニングを行い、具体的なＡＮＲの問題に対して具体的な分析を行うことになる。これは、オペレーティングシステムのバージョン、及びアプリケーションプログラムのバージョン等の具体的なシーンに限定されてしまい、必ずしも今回のＡＮＲを解決した後に他の原因でＡＮＲが再発生しないことを確実にすることができず、汎用性が高くない。

【発明の概要】

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

【0005】

本願の実施例は、データ処理方法、装置、機器、記憶媒体、及びプログラム製品を提供し、オペレーティングシステムのレベルから目標アプリケーションの無応答現象を効果的に解決し、いずれか一種類の無応答現象が発生する確率を低減させることができ、汎用性が高く、全体の安定性を向上させることができる。

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

【0006】

一態様では、本願の実施例は、データ処理方法を提供し、
目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得するステップであって、いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において生じるものであり、且ついずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときのシステムコードの実行状況を記述することに用いられる、ステップと、
各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ共通性分析結果に基づき、システムコードから無応答現象が生じる障害点を決定するステップであって、前記共通性分析結果は、前記各種類の無応答現象の現場情報における共通情報を含む、ステップと、
障害点に基づきシステムコードを修復処理することにより、修復後のシステムコードに基づいて目標アプリケーションを動作させるステップと、を含む。

【0007】

一態様では、本願の実施例は、データ処理装置を提供し、
目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得することに用いられる取得モジュールであって、いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において生じるものであり、且ついずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときのシステムコードの実行状況を記述することに用いられる、取得モジュールと、
各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ共通性分析結果に基づき、システムコードから無応答現象が生じる障害点を決定することに用いられる処理モジュールであって、前記共通性分析結果は、前記各種類の無応答現象の現場情報における共通情報を含む、処理モジュールと、を含み、
処理モジュールは、障害点に基づきシステムコードを修復処理することにより、修復後のシステムコードに基づいて目標アプリケーションを動作させることに用いられる。

【0008】

相応に、本願の実施例は、コンピュータ機器を提供し、プロセッサと、メモリと、ネットワークインタフェースと、を含み、プロセッサは、メモリ、及びネットワークインタフェースに連結され、ネットワークインタフェースは、ネットワーク通信機能を提供することに用いられ、メモリは、コンピュータプログラムを記憶することに用いられ、プロセッサは、コンピュータプログラムを呼び出することにより、本願の実施例におけるデータ処理方法を実行することに用いられる。

【0009】

相応に、本願の実施例は、コンピュータ可読記憶媒体を提供し、コンピュータ可読記憶媒体にコンピュータプログラムが記憶されており、コンピュータプログラムがプロセッサに実行されるときに、本願の実施例におけるデータ処理方法を実行する。

【0010】

相応に、本願の実施例は、コンピュータプログラム製品を提供し、コンピュータプログラム製品は、コンピュータプログラム、又はコンピュータ命令を含み、コンピュータプログラム、又はコンピュータ命令は、プロセッサに実行されるときに、本願の実施例のデータ処理方法を実現する。

【発明の効果】

【0011】

本願の実施例において、目標アプリケーションの複数の種類の無応答現象の現場情報を取得することができ、いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において生じるものであってもよく、且つ対応する現場情報は、該無応答現象が生じるときのシステムコードの実行状況を記述することに用いることができる。取得された各種類の無応答現象の現場情報に対して共通性分析を行うことによって、オペレーティングシステムのレベルからシステムコードの実行状況を分析し、最下層から目標アプリケーションに各種類の無応答現象が生じる共通特性を探し、共通性分析結果を得ることができる。更に、該共通性分析結果に基づいて、システムコードから無応答現象が生じる障害点を決定し、且つ障害点に基づいてシステムコードを修復することができる。修復後のシステムコードに基づいて目標アプリケーションを動作させれば、オペレーティングシステム側から、アプリケーション無応答現象（すなわち、目標アプリケーションの無応答現象）が発生する可能性がある状況を阻止し、アプリケーション無応答現象の発生を最大限に回避することができる。これから分かるように、この方式は、オペレーティングシステムのレベルから始めて、実際に発生する各種類の無応答現象の現場情報に対して収集、及び共通性分析を行う。また分析して得られた結果に基づいて、ネイティブのオペレーティングシステムのシステムコードを修復し、オペレーティングシステムにおけるアプリケーション無応答現象の問題を根本的に解決することができるため、汎用性が高く、オペレーティングシステムにおいて目標アプリケーションにいずれか一種類の無応答現象が発生する状況を減少させることができることにより、システム、又はアプリケーションの安定性を効果的に向上させる。

【図面の簡単な説明】

【0012】

【図1a】本願の実施例が提供するアプリケーション無応答の分類模式図である。

【図1b】本願の実施例が提供するアプリケーション無応答現象をトリガーする過程模式図である。

【図1c】本願の実施例が提供するサービスを起動するフローチャートである。

【図1d】本願の実施例が提供するサービス型の無応答現象が生じる過程の模式図である。

【図1e】本願の実施例が提供するブロードキャスト型の無応答現象が生じる過程の模式図である。

【図1f】本願の実施例が提供するコンテンツ提供型の無応答現象が生じる過程の模式図である。

【図1g】本願の実施例が提供する入力配信型の無応答現象が生じる過程の模式図である。

【図2a】本願の実施例が提供するクラウドゲームシステムのアーキテクチャ図である。

【図2b】本願の実施例が提供するクラウドゲームにおける無応答現象の提示模式図である。

【図2c】本願の実施例が提供するクラウドゲームシーンにおけるサーバにおけるシステムの最下層のインタラクションロジックの模式図である。

【図3a】本願の実施例が提供するデータ処理方法のフローチャートである。

【図3b】本願の実施例が提供するクラウドゲームシーンにおいて生じた無応答現象の現場情報の模式図である。

【図4】本願の実施例が提供する別のデータ処理方法のフローチャートである。

【図5】本願の実施例が提供するさらに別のデータ処理方法のフローチャートである。

【図6a】本願の実施例が提供する親プロセスの呼び出しスタックの結果模式図である

【図6b】本願の実施例が提供する目標関数のロジックコードの模式図である。

【図7】本願の実施例が提供するデータ処理装置の構造模式図である。

【図8】本願の実施例が提供するコンピュータ機器の構造模式図である。

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

【0013】

本願の実施例のスキームをより良好に理解するために、以下では、まず、本願の実施例に関わる可能性のある関連用語、及び概念を紹介する。

【0014】

オペレーティングシステム：英語の正式名称は、ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍであり、ＯＳと略称される。オペレーティングシステムは、コンピュータハードウェアとソフトウェアリソースとを管理するコンピュータプログラムである。コンピュータシステムにおける最も基本的なシステムソフトウェアである。オペレーティングシステムは、処理マシン管理（たとえば、プロセス制御、及びプロセス同期）、メモリ管理（たとえば、内部メモリの割り当てや回収、及びアドレスマッピング）、機器管理（たとえば、ファイル記憶空間の管理、及びファイル読み書き管理）、及びファイル管理（たとえば、バッファリング管理、及び仮想機器）等の機能を備える。オペレーティングシステムの種類は、非常に多く、例えば、よく見られるＡｎｄｒｏｉｄ（又はＡｎｄｒｏｉｄシステムと呼ばれる）、Ｌｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ、及びＩＯＳ等である。

【0015】

カーネル：カーネルは、オペレーティングシステムのコアである。カーネルは、入力されたコマンドを、コンピュータハードウェアが理解可能な機械言語に変換することができ、またカーネルは、ハードウェアに直接連絡し、且つハードウェアにアプリケーションプログラムが開始した要求を知らせることができる。カーネルの機能は、プロセス管理、タスクスケジューリング、及び内部メモリ管理等を含むが、これらに限定されない。ここで、ファイル管理とは、カーネルがファイルシステムを使用してファイルを組織し、且つファイルシステムによって、ファイルデータの記憶、ファイルの状態、及びアクセス設定に対する監視を維持することを指す。プロセス管理とは、マルチプロセス環境において、カーネルがどのプロセスをＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、中央プロセッサ）に優先的に動作させるか、また割り当てられる動作のタイムスライスの長さがどれぐらいであるかを決めることを指す。内部メモリ管理とは、カーネルが内部メモリ空間を検出し、内部メモリを生成、又は破棄することができることによりアプリケーションプログラムが正確に実行されるのを確実にすることを指す。

【0016】

ハードコーディング：データをプログラム、又は他の実行可能なオブジェクトのソースコードに直接埋め込むプリケーション開発の実践を指す。外部からデータを取得すること、又は動作するときにデータを生成することと異なり、ハードコーディングは、通常、ソースコードの編集、及び実行可能なファイルの再コンパイルによってのみ修正できる。コンピュータプログラム、又はテキストの編集において、ハードコーディングとは、可変な変数を１つの固定値で置き換える方法を指す。

【0017】

ＡＮＲ：英語の正式名称は、ＡｐｐｌｉｃａｔｉｏｎＮｏｔＲｅｓｐｏｎｄｉｎｇであり、中国語は、アプリケーション無応答（無応答と略称できる）である。ＡＮＲは、オペレーティングシステム（たとえば、Ａｎｄｒｏｉｄシステム）におけるよく見られる現象であり、開発者にとっては、コードにおけるｂｕｇ（エラー）であり得るがあるが、使用者にとっては、良くない使用体験を引き起こす可能性がある。オペレーティングシステムは、幾つかのイベントを一定の時間内で完了する必要があり、もし所定の時間を超えても効果的な応答を得ない、又は応答時間が長すぎるとなれば、いずれもＡＮＲを引き起こし得る。一般的には、システムインターフェースに１つの提示ボックスがポップアップされる可能性があり、オブジェクトに現在のアプリケーションが応答していないことを知らせ、オブジェクトは、ウェイト（Ｗａｉｔ）を継続すること、又は強制的に閉じる（Ｆｏｒｃｅｃｌｏｓｅ）ことを選択することができるという、オペレーティングシステムの自己保護メカニズムである。この他、アプリケーション無応答が発生するときに、アプリケーション無応答が発生したプロセスを直接閉じて、オブジェクトに提示するための提示ボックスをポップアップしないようにしてもよい。

【0018】

目標アプリケーション：本願において、目標アプリケーションとは、コンピュータ機器において動作するいずれかのアプリケーション、たとえば、端末におけるアプリケーションプログラム、又はサーバにおけるサービスプログラムを指す。アプリケーションのインストール方式に応じて分けると、目標アプリケーションは、インストール不要のアプリケーション（たとえば、アプレット、及びウェブページアプリケーション（例えば、ショッピングウェブサイト））、又はコンピュータ機器においてインストールされるサードパーティアプリケーションプログラムであってもよい。アプリケーション機能に応じて分けると、目標アプリケーションは、具体的に、ゲーム類アプリケーション、オーディオビデオ類アプリケーション、ソーシャル類アプリケーション、及びショッピング類アプリケーション等のうちのいずれか一種であってもよい。

【0019】

目標アプリケーションは、オペレーティングシステムにより提供される環境に基づいて動作させることができ、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において、目標アプリケーションは、無応答の状況（すなわち、ＡＮＲ）が発生し得る可能性がある。本願の実施例において、目標アプリケーションに生じたＡＮＲは、サービス型の無応答現象、ブロードキャスト型の無応答現象、コンテンツ提供型の無応答現象、及び入力配信型の無応答現象のいくつかの種類を含んでもよい。Ａｎｄｒｏｉｄオペレーティングシステムを例とすると、サービス型の無応答現象とは、サービスの実行が所定の継続時間（たとえば、２０ｓ）内に完了しないこと（ＳｅｒｖｉｃｅＴｉｍｅｏｕｔ）によりトリガーされた無応答現象を指し、ブロードキャスト型の無応答現象とは、ブロードキャストの実行が所定の継続時間（たとえば、１０ｓ）内に完了しないこと（ＢｒｏａｄｃａｓｔＱｕｅｕｅＴｉｍｅｏｕｔ）によりトリガーされた無応答現象を指し、コンテンツ提供型の無応答現象とは、コンテンツプロバイダーが発行（ｐｕｂｌｉｓｈ）した後にタイムアウトすること（ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒＴｉｍｅｏｕｔ）によりトリガーされた無応答現象を指し、入力配信型の無応答現象とは、入力イベント配信がタイムアウトすること（ＩｎｐｕｔＤｉｓｐａｔｃｈｉｎｇＴｉｍｅｏｕｔ）によりトリガーされた無応答現象を指す。上記の４種類のＡＮＲは、図１ａに示されるアプリケーション無応答の分類の模式図にまとめることができる。上記に言及されたアプリケーションの各種類類の無応答現象が生じる過程（或いは、トリガーメカニズム）に対して、下記で１つずつ紹介する。

【0020】

オペレーティングシステムのシステムソースコードの観点から言えば、ＡＮＲのトリガー過程は、具体的には、３つのステップに分けることができ、図１ｂに示すように、継続時間の閾値の設定、アプリケーション無応答（すなわち、アプリケーションの無応答現象、ＡＮＲと略称される）のトリガー条件の解除、及びアプリケーション無応答（すなわち、ＡＮＲ）のトリガーを含む。継続時間の閾値を設定することによって、相応なイベントの実際の処理の継続時間がタイムアウトする（すなわち、実際の処理の継続時間が設定された継続時間の閾値より大きい）か否かを判断することができる。継続時間の閾値は、相応なＡＮＲに基づき設定することができ、異なるＡＮＲの継続時間の閾値は、同じであってもよく、又は異なってもよい。タイムアウトする場合に、ＡＮＲがトリガーされ、タイムアウトしない場合に、ＡＮＲがトリガーされることがなく、且つＡＮＲのトリガー条件が解除される。ここで、ＡＮＲのトリガー条件の解除とは、元に設定された継続時間の閾値をキャンセルすることを指す。

【0021】

以下では、各種類のＡＮＲが生じる過程を詳細に紹介する。ここで、まず、下記のアプリケーション無応答現象に関わる共通の概念、及び幾つかの用語を紹介する。

【0022】

目標アプリケーションとは、コンピュータ機器における現在動作しているいずれかのアプリケーションプログラムを指す。目標アプリケーションのアプリケーションプロセスは、オペレーティングシステムの最下層のプロセス（たとえば、システムサービスプロセス）とインタラクションして、相応なイベントを完了することができる。

【0023】

システムサービスプロセスは、Ｊａｖａｆｒａｍｅｗｏｒｋ全体を起動、及び管理することに用いられる。システムにおける重要なサービスは、全てシステムサービスプロセスにおいて始めることができ、たとえば、コンポーネント管理サービスＡＭＳ（ＡｃｔｉｖｉｔｙＭａｎａｇｅｒＳｅｒｖｉｃｅ）、及びウィンドウ管理サービスＷＭＳ（ＷｉｎｄｏｗＭａｎａｇｅｒＳｅｒｖｉｃｅ）等である。Ａｎｄｒｏｉｄオペレーティングシステムにおいて、Ｚｙｇｏｔｅプロセス（新しいプロセスをフォークすることに用いられるプロセスであり、ここで、フォークプロセスと呼ばれる）によってシステムサービスプロセス、及び目標アプリケーションのアプリケーションプロセスをフォークすることができる。下記の内容は、具体的に、オペレーティングシステムにおけるシステムサービスプロセスを実行主体として記述する。

【0024】

Ａｎｄｒｏｉｄオペレーティングシステムの４つのコンポーネントは、Ａｃｔｉｖｉｔｙ、Ｓｅｒｖｉｃｅ、ＢｒｏａｄＣａｓｔＲｅｃｅｉｖｅｒ、及びＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒである。(1)Ａｃｔｉｖｉｔｙ（コンポーネント）は、オブジェクトが操作する可視化インターフェースであり、オブジェクトに操作命令を完了するウィンドウを提供することができる。(2)Ｓｅｒｖｉｃｅ（サービス）は、バックグラウンドで長時間の動作操作を実行でき、オブジェクトインターフェースがないアプリケーションコンポーネントである。Ｓｅｒｖｉｃｅは通常、バックグラウンドで動作し、一般的にオブジェクトとインタラクションする必要がないため、Ｓｅｒｖｉｃｅコンポーネントは、グラフィカルオブジェクトインターフェースを有しない。Ｓｅｒｖｉｃｅコンポーネントは、通常、他のコンポーネントにバックグラウンドサービスを提供するか、又は他のコンポーネントの動作状態を検出することに用いられる。(3)ＢｒｏａｄＣａｓｔＲｅｃｅｉｖｅｒ（ブロードキャストレシーバ）は、アプリケーションが関心を持つ外部イベント（たとえば、電話着信、及びデータネットワークが利用可能であるときに）をフィルタリングし、且つそれに対して応答を行うことに用いることができる。ＢｒｏａｄＣａｓｔＲｅｃｅｉｖｅｒは、１つのＡｃｔｉｖｉｔｙ、又はＳｅｒｖｉｃｅを起動することで、それらが受信した情報に応答するか、又はＮｏｔｉｆｉｃａｔｉｏｎＭａｎａｇｅｒ（通知マネージャー）を用いてオブジェクトに通知することができ、たとえば、サウンドを再生する通知、又はステータスバーに表示されるメッセージがある。(4)ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒ（コンテンツプロバイダー）は、１つのアプリケーションプログラムの指定されたデータセットを他のアプリケーションプログラムに提供する。他のアプリケーションは、ＣｏｎｔｅｎｔＲｅｓｏｌｖｅｒクラスによって該コンテンツプロバイダーからデータを取得、又は保存することができる。具体的に、ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒは、データを発行し、ＣｏｎｔｅｎｔＲｅｓｏｌｖｅｒオブジェクトとＵｒｉ（ＵｎｉｖｅｒｓａｌＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｅｒ、ユニバーサルリソース識別子）とを結合することによって呼び出すことができる。ここで、Ｕｒｉは、データ操作のアドレスを表し、各ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒがデータを発行するときに、全て唯一のアドレスを有し得る。

【0025】

（一）サービス型の無応答現象。

【0026】

サービス型の無応答現象が生じる過程は、目標アプリケーションのアプリケーションプロセスが送信するサービス作成要求に応答して、サービスの継続時間の閾値を設定するステップと、サービスプロセスにサービス作成メッセージを送信することにより、サービスプロセスがサービス作成メッセージに基づいて、１つ又は複数の他のプロセスを呼び出してサービス作成作業を実行するようにサービスプロセスに通知し、且つサービスの作成が成功した後にフィードバック情報を返すステップと、サービスの継続時間の閾値内にサービスプロセスから返されたフィードバック情報を受信しなかった場合に、サービス型の無応答現象が生じるステップと、を含む。

【0027】

目標アプリケーションのアプリケーションプロセスが送信するサービス作成要求は、目標アプリケーションに必要なサービス、たとえば、聴取サービス、及び通知サービス等を作成することをシステムに要求することに用いることができる。クラウドゲームシーンにおいて、該聴取サービスは、たとえば、プレイヤーのアカウントがログインするか否かを聴取するサービス、又はプレイヤーがオンラインであるか否かを聴取するサービスである。システムサービスプロセスは、アプリケーションプロセスが開始したサービス作成要求に応答して、サービスの継続時間の閾値を設定することができる。該サービスの継続時間の閾値は、サービス作成がタイムアウトするか否かを検出することに用いることができる。たとえば、フォアグラウンドサービスの継続時間の閾値とバックグラウンドサービスの継続時間の閾値は、いずれも２０ｓである。続いて、システムサービスプロセスは、サービスプロセスにサービス作成メッセージを送信することができ、これによりサービスプロセスは、１つ又は複数のプロセスを呼び出してサービス作成作業を実行し、サービス作成作業によって、目標アプリケーションに必要なサービスを作成することができる。サービスプロセスは、システムサービスプロセスにおけるコンポーネント管理サービスにより要求して予め作成されたものであってもよい。具体的に、サービスプロセスにおけるメインスレッドは、１つ又は複数の他のプロセス（すなわち、サービスプロセスと異なるプロセス）を呼び出してサービス作成作業を実行することができる。この１つ又は複数のプロセスにおいて、親子関係を備えるプロセスが含まれてもよく、且つ親子プロセスの間で、アドレス空間を共有することができる。サービス作成作業の実行が完了した後に、サービスプロセスにおけるメインスレッドによりシステムサービスプロセスにフィードバック情報を送信することができ、ここでのフィードバック情報は、サービス作成が完了したことを指示することに用いられる通知メッセージであってもよい。サービスの継続時間の閾値内にサービスプロセスから返されたフィードバック情報を受信しなかった場合に、サービス作成作業にかかる継続時間がサービスの継続時間の閾値以上であり、サービスタイムアウトの現象が発生し、更にサービス型の無応答現象が生じることを意味する。逆に、サービスの継続時間の閾値内にサービスプロセスから返されたフィードバック情報を受信した場合に、サービス作成作業にかかる継続時間がサービスの継続時間の閾値より小さく、サービス型の無応答現象が生じることがないことを意味する。

【0028】

ＡｎｄｒｏｉｄオペレーティングシステムのＡＮＲを例にして、上記内容を例示的に紹介する。ＳｅｒｖｉｃｅＴｉｍｅｏｕｔは、ｓｔａｒｔＳｅｒｖｉｃｅ（サービス起動）の際に発生し、Ｓｅｒｖｉｃｅについて、具体的には、タイムアウト時間（すなわち、サービスの継続時間の閾値）が２０ｓであるフォアグラウンドサービスと、タイムアウト時間が２００ｓであるバックグラウンドサービスとの２種類を含んでもよい。目標アプリケーションにおいて、１つのＳｅｒｖｉｃｅを起動することは、具体的に、ＡＰＩｓｔａｒｔＳｅｒｖｉｃｅの１行のコードを呼び出すことによって実現できる。Ａｎｄｒｏｉｄオペレーティングシステムのレベルから言えば、過程は、下記の図１ｃに示されるｓｔａｒｔＳｅｒｖｉｃｅの簡単なフローチャートのとおりである。サービス作成の起動の過程は、主にシステムサービスプロセスにおけるコンポーネント管理サービス（ＡＭＳ、ＡｃｔｉｖｉｔｙＭａｎａｇｅｒＳｅｒｖｉｃｅ）により完了される。ＡＭＳは、ｓｏｃｋｅｔ（ソケット、一種類の通信方式）通信によって、ベアラサービスを作成する作成プロセス（ＣｒｅａｔｅＰｒｏｃｅｓｓ）をＺｙｇｏｔｅに要求し、ここで、スレッド（ＡｃｔｉｖｉｔｙＴｈｒｅａｄ、すなわち、メインスレッド）の作成を要求することを含む。サービスは、単独の作成プロセスにおいて動作し、ローカルサービスの動作に対して、サービスの過程を起動しなくてもよく、ＡｃｔｉｖｉｔｙＴｈｒｅａｄは、アプリケーションプログラムのメインスレッドの役割を果たす。その後、Ｚｙｇｏｔｅは、ｆｏｒｋによって、Ｚｙｇｏｔｅプロセスをコピーして新たなプロセスを生成し、且つＡｃｔｉｖｉｔｙＴｈｒｅａｄに関連するリソースを新しいプロセスにロードする。ＡＭＳは、新たに生成されたプロセスにおけるＡｃｔｉｖｉｔｙＴｈｒｅａｄに、Ｂｉｎｄｅｒ（プロセス間通信メカニズム）通信の方式によって、サービス作成の要求を送信する。ＡｃｔｉｖｉｔｙＴｈｒｅａｄは、サービスを起動して動作させるが、具体的には、ＡｃｔｉｖｉｔｙＴｈｒｅａｄによりｏｎＣｒｅａｔｅ方法を呼び出してサービス（ｃｒｅａｔｅｓｅｒｖｉｃｅ）を作成してもよい。

【0029】

図１ｄに示すように、アプリケーションプロセス（すなわち、ＡＰＰプロセス）がサービス作成の要求を開始する（ｓｔａｒｔＳｅｒｖｉｃｅ）ときに（図面におけるステップ１を参照）、システムにおけるシステムサービスプロセス（すなわち、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセス）は、１つのアイドルスレッドｂｉｎｄｅｒ＿１（すなわち、通信スレッド１）を割り当てることで該要求を受信することができる。続いて、コンポーネントマネージャーＡｃｔｉｖｉｔｙＭａｎａｇｅｒにサービスタイムアウトメッセージＳＥＲＶＩＣＥ＿ＴＩＭＥＯＵＴ＿ＭＳＧを送信し、サービスの継続時間の閾値を設定する（図面におけるステップ２を参照）。次に、ｂｉｎｄｅｒ＿１は、サービスプロセス（すなわち、ｓｅｒｖｉｃｅプロセス）のｂｉｎｄｅｒ＿３（すなわち、通信スレッド３）に、処理作業（スケジューリングしてサービスを作成することｓｃｈｅｄｕｌｅＣｒｅａｔｅＳｅｒｖｉｃｅ）の実行を用意することを通知する（図面におけるステップ３を参照）。ｂｉｎｄｅｒ＿３は、受信した後に、メインスレッド（すなわち、ｍａｉｎスレッド、図１ｃにおけるメインスレッドＡｃｔｉｖｉｔｙＴｈｒｅａｄに対応してもよい）に引き渡し、サービス作成イベントをｍａｉｎスレッドのタスクキューに加える（すなわち、メッセージの送信ｓｅｎｄＭｅｓｓａｇｅ）（図面におけるステップ４を参照）。次に、ｍａｉｎスレッドは、一連の作業を行うようになり、ここでは、具体的にサービス作成作業であり、図１ｃにおけるＡｃｔｉｖｉｔｙＴｈｒｅａｄスレッドによりサービスを作成する過程を含んでもよく（図面におけるステップ５を参照）、ｓｅｒｖｉｃｅライフサイクルの起動を完了する（完了をウェイトするｗａｉｔＴｏＦｉｎｉｓｈ）。上記作業を完了した後に、ｍａｉｎスレッドは、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスに、作業が既に完了したこと（すなわち、サービス作成作業の完了ｓｅｒｖｉｃｅＤｏｎｅＥｘｅｃｕｔｉｎｇ）を報告することができる。次に、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスにおけるｂｉｎｄｅｒ＿２スレッド（すなわち、通信スレッド２）は、メッセージを受信することができ（図面におけるステップ６を参照）、サービスの継続時間の閾値の時間内にサービス作成作業を完了した場合には、ＡＮＲのトリガー条件を解除することができてＡＮＲが発生することがなく、そうでなければ、ＡＮＲが発生するようになる。

【0030】

（二）ブロードキャスト型の無応答現象。

【0031】

ブロードキャスト型の無応答現象が生じる過程は、目標アプリケーションのアプリケーションプロセスが開始したブロードキャスト送信要求に応答して、ブロードキャストの継続時間の閾値を設定するステップと、ブロードキャスト受信プロセスにブロードキャスト登録メッセージを送信することにより、ブロードキャスト受信プロセスがブロードキャスト登録メッセージに基づいて、１つ又は複数の他のプロセスを呼び出してブロードキャスト作業を実行するようにブロードキャスト受信プロセスに通知し、且つブロードキャストが完了した後にフィードバック情報を返すステップと、ブロードキャストの継続時間の閾値内にブロードキャスト受信プロセスから返されたフィードバック情報を受信しなかった場合に、ブロードキャスト型の無応答現象が生じるステップと、を含む。

【0032】

ブロードキャストメカニズムは、プロセス／スレッド間の通信に用いられ、ブロードキャストは、ブロードキャスト送信、及びブロードキャスト受信に分けることができる。ブロードキャストは、パラレルブロードキャスト、及びシリアルブロードキャストを含んでもよい。通常、アプリケーションの無応答現象は、シリアルブロードキャストのシーンにおいて発生する。サービス型のＡＮＲが生じる過程と同様に、システムサービスプロセスは、目標アプリケーションのアプリケーションプロセスが開始したブロードキャスト送信要求に応答して、ブロードキャストの継続時間の閾値を設定することができる。目標アプリケーションのアプリケーションプロセスは、ブロードキャスト送信側があるプロセスである。システムサービスプロセスは、ブロードキャスト受信プロセスにブロードキャスト登録メッセージを送信することができることにより、ブロードキャスト受信プロセスにおけるメインスレッドは、１つ又は複数の他のプロセスを呼び出してブロードキャスト作業を実行することができる。この１つ又は複数のプロセスにおいて、親子関係を備えるプロセスが含まれてもよく、且つ親子プロセスの間で、アドレス空間を共有することができる。

【0033】

ブロードキャスト受信プロセスは、ブロードキャスト受信側があるプロセスであり、他のアプリケーションプログラム、又はシステムからのブロードキャストメッセージを受信することに用いることができる。ブロードキャスト作業は、具体的に、各種類のイベントをブロードキャストすることができ、たとえば、日付変更が発生したブロードキャスト、及びシステムの起動が完了したブロードキャスト等である。クラウドゲームシーンにおいて、該ブロードキャストイベントは、たとえば、ネットワーク切り替えブロードキャスト、及びネットワーク故障ブロードキャスト等である。ブロードキャスト作業を実行する前に、ブロードキャスト登録メッセージに基づいてブロードキャスト受信キューを作成し、受信されたブロードキャストイベントを順に処理することができる。メインスレッドは、ブロードキャスト作業の処理が完了した後に、フィードバック情報を返すことができ、該フィードバック情報は、ブロードキャスト作業が完了したことを指示することに用いられる通知メッセージである。ブロードキャストの継続時間の閾値内にブロードキャスト受信プロセスから返されたフィードバック情報を受信しなかった場合に、ブロードキャスト作業にかかる継続時間は、ブロードキャストの継続時間の閾値以上となり、ブロードキャストタイムアウトの現象が発生し、更にブロードキャスト型の無応答現象が生じる。逆に、ブロードキャストの継続時間の閾値内にブロードキャストプロセスから返されたフィードバック情報を受信した場合に、ブロードキャスト作成作業にかかる継続時間はブロードキャストの継続時間の閾値より小さく、ブロードキャスト型の無応答現象が生じることがないことを意味する。

【0034】

ＡｎｄｒｏｉｄオペレーティングシステムのＡＮＲを例にして、ブロードキャスト型のＡＮＲをより詳細に紹介する。具体的には、図１ｅに示されるブロードキャスト型のＡＮＲが生じる過程の模式図も併せて参照することができる。目標アプリケーションのアプリケーションプロセスがブロードキャスト送信要求（ｓｅｎｄＢｒｏａｄｃａｓｔ）を開始するときに（図面におけるステップ１を参照）、システムサービスプロセスは、１つのアイドルスレッドｂｉｎｄｅｒ＿１（すなわち、通信スレッド１）を割り当てることで該ブロードキャスト送信要求を受信することができる。引き続いて、コンポーネントマネージャーＡｃｔｉｖｉｔｙＭａｎａｇｅｒにブロードキャストタイムアウトメッセージＢＲＯＡＤＣＡＳＴ＿ＴＩＭＥＯＵＴ＿ＭＳＧを送信し（ｓｅｎｄＭｅｓｓａｇｅ）、ブロードキャストの継続時間の閾値を設定する（図面におけるステップ２～３を参照）。次は、ｂｉｎｄｅｒ＿１は、ブロードキャスト登録メッセージによって、ブロードキャスト受信プロセス（すなわち、Ｒｅｃｉｖｅｒプロセス）のｂｉｎｄｅｒ＿３スレッド（すなわち、通信スレッド３）に、処理作業の実行を用意することを通知する（図面におけるステップ４を参照）。ｂｉｎｄｅｒ＿３は、受信した後に、メインスレッド（すなわち、ｍａｉｎスレッド）にメッセージを送信し、イベントをｍａｉｎスレッドのタスクキューに加える（通信スレッド３は、メインスレッドにメッセージを送信し、ｓｅｎｄＭｅｓｓａｇｅ、図面におけるステップ５を参照）。次に、ｍａｉｎスレッドは、一連の作業を行うことができ、ここでは、ブロードキャスト作業であり、ブロードキャスト受信のライフサイクルの起動を含み、現在のプロセスに、さらにＳＰ（ＳｈａｒｅｄＰｒｅｆｅｒｅｎｃｅｓ、一種類のデータ記憶方式）がファイルを書き込んでいることを発見した場合、ＳＰデータの永続化作業を待って（すなわち、メインスレッドは、キューイング作業サイクルスレッドにメッセージを送信し、ｓｅｎｄＭｅｓｓａｇｅ、図面におけるステップ６を参照）、ｑｕｅｕｅｄ－ｗｏｒｋ－ｌｏｏｐｅｒスレッド（キューイング作業サイクルスレッド）によりｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスに、ブロードキャスト作業が既に完了したことを報告する必要があり（図面におけるステップ７を参照）、逆に、直接メインスレッドによりブロードキャスト作業が既に完了したことを報告することができる（すなわち、ｆｉｎｉｓｈＲｅｃｅｉｖｅｒ）。次に、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスにおけるｂｉｎｄｅｒ＿２スレッド（すなわち、通信スレッド２）は、メッセージを受信することができ、ブロードキャストの継続時間の閾値の時間内にすべての作業が完了した場合に、ＡＮＲのトリガー条件を解除することができてＡＮＲが発生することがなく（図面におけるステップ８を参照）、そうでなければ、ＡＮＲが発生することがある。

【0035】

（三）コンテンツ提供型の無応答現象。

【0036】

コンテンツ提供型の無応答現象が生じる過程は、目標アプリケーションのアプリケーションプロセスが開始したコンテンツ提供オブジェクトの取得要求に応答して、コンテンツ提供オブジェクトと対応するコンテンツ提供プロセスの起動状態を検出するステップと、起動状態がコンテンツ提供プロセスが起動していないことを指示する場合に、コンテンツ提供プロセスを作成し、且つ１つ又は複数の他のプロセスを呼び出して、コンテンツ提供オブジェクトをインストールするようにコンテンツ提供プロセスに通知し、且つコンテンツ提供オブジェクトをインストールした後にフィードバック情報を返すステップであって、コンテンツ提供オブジェクトに１つのインストールの継続時間の閾値が設定されている、ステップと、インストールの継続時間の閾値内にコンテンツ提供プロセスから返されたフィードバック情報を受信しなかった場合に、コンテンツ提供型の無応答現象が生じるステップと、を含む。

【0037】

コンテンツ提供オブジェクトは、異なるアプリケーションプログラムの間でデータ共有の機能を実現することに用いられる。コンテンツ提供プロセスは、コンテンツ提供オブジェクトをインストールし、且つ発行することにより、コンテンツデータを提供し、データ共有の機能を実現することに用いられる。システムサービスプロセスは、目標アプリケーションのアプリケーションプロセスが開始したコンテンツ提供オブジェクトの取得要求に応答して、コンテンツ提供プロセスの起動状態を検出することができる。コンテンツ提供プロセスが起動していない場合に、コンテンツ提供プロセスが作成されていない可能性があることを意味しており、該コンテンツ提供プロセスを作成し、且つ起動することができる。コンテンツ提供プロセスは、作成後に、システムサービスプロセスに自分を登録し、且つインストールの継続時間の閾値を設定することができる。その後、コンテンツ提供オブジェクトのインストール作業を実行するようにコンテンツ提供プロセスに通知することができ、具体的には、コンテンツ提供プロセスにおけるメインスレッドにより１つ又は複数の他のプロセスを呼び出すことで実行することができる。この１つ又は複数のプロセスにおいて、親子関係を備えるプロセスが含まれてもよく、且つ親子プロセスの間で、アドレス空間を共有することができる。

【0038】

インストールが完了した後に、フィードバック情報を返すことができる。該フィードバック情報は、コンテンツ提供オブジェクトのインストール作業が完了したことを指示することに用いられる通知メッセージであり、さらに、コンテンツ提供オブジェクトを発行することにより、取得されたコンテンツ提供オブジェクトにより提供されたコンテンツデータを返すことを指示することに用いることができる。クラウドゲームシーンにおいて、該コンテンツ提供オブジェクトは、システムにおけるアドレス帳であってもよく、提供されるコンテンツデータは、アドレス帳における連絡先の関連するデータであってもよい。理解できるように、本願の具体的な実施形態においては、アドレス帳等の関連するデータに関して、本願の上記の実施例が具体的な製品又は技術に適用されるときには、オブジェクトの許可又は同意を獲得する必要があり、また関連するデータの収集、使用、及び処理は、関連する国や地域の関連する法律法規、及び標準に準拠する必要がある。

【0039】

インストールの継続時間の閾値内にコンテンツ提供プロセスから返されたフィードバック情報を受信しなかった場合に、インストール作業にかかる継続時間は、インストールの継続時間の閾値以上になり、コンテンツ提供タイムアウトの現象が発生し、更にコンテンツ提供型の無応答現象が生じる。逆に、インストールの継続時間の閾値内にコンテンツ提供プロセスから返されたフィードバック情報を受信した場合に、コンテンツ提供オブジェクトのインストール作業にかかる継続時間がインストールの継続時間の閾値より小さくなり、コンテンツ提供型の無応答現象が生じることがないことを意味する。

【0040】

ＡｎｄｒｏｉｄオペレーティングシステムのＡＮＲを例にして、コンテンツ提供型のＡＮＲをより詳細に紹介する。具体的には、図１ｆに示されるブロードキャスト型のＡＮＲが生じる過程の模式図を併せて参照することができる。目標アプリケーションのアプリケーションスレッドがコンテンツ提供オブジェクトＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒの取得要求（ｇｅｔＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒ）を開始するときに（図面におけるステップ１を参照）、システムサービスプロセスは、１つのアイドルスレッドｂｉｎｄｅｒ＿１（すなわち、通信スレッド１）を割り当てることでＣｏｎｔｅｎｔＰｒｏｖｉｄｅを取得する該要求を受信することができる。ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒがまだ起動していないと検出した場合に、まずＺｙｇｏｔｅによって、まず新しいプロセスをｆｏｒｋする（すなわち、Ｚｙｇｏｔｅｆｏｒｋによって新しいプロセスを作成し、図面におけるステップ２を参照）。新たなＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒプロセスは、システムに自分を登録し（ａｔｔａｃｈａｐｐｌｉｃａｔｉｏｎｌｏｃｋｅｄ、アプリケーションロックの添付）、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスの通信現場ｂｉｎｄｅｒ＿２（すなわち、通信スレッド２）は、該登録メッセージを受信し（図面におけるステップ３を参照）、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセス内部のＡｃｔｉｖｉｔｙＭａｎａｇｅｒにコンテンツ提供オブジェクトの発行タイムアウトメッセージＣＯＮＴＥＮＴ＿ＰＲＯＶＩＤＥＲ＿ＰＵＢＬＩＳＨ＿ＴＩＭＥＯＵＴ＿ＭＳＧメッセージを送信し、インストールの継続時間の閾値を設定する（図面におけるステップ４を参照）。次に、ｂｉｎｄｅｒ＿２は、ｐｒｏｖｉｄｅｒプロセス（すなわち、コンテンツ提供プロセス）のｂｉｎｄｅｒ＿４スレッド（すなわち、通信スレッド４）に、処理作業（アプリケーションプログラムのバインディング、ｂｉｎｄＡｐｐｌｉｃａｔｉｏｎ、図面におけるステップ５を参照）の実行を用意することを通知する。ｂｉｎｄｅｒ＿４は、受信した後に、メインスレッドに引き渡し（すなわち、ｍａｉｎスレッドにメッセージを送信し、ｓｅｎｄＭｅｓｓａｇｅ、図面におけるステップ６を参照）、イベントをタスクキューに加える。次に、ｍａｉｎスレッドは、一連の作業を行うことができ、ここでは、コンテンツ提供オブジェクトのインストール作業であり、選択可能に、コンテンツ提供オブジェクトの発行作業をさらに含んでもよい。次に、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスにインストール作業が既に完了したことを報告し、取得されたコンテンツ提供オブジェクトのコンテンツデータを返す（コンテンツ提供オブジェクトの発行、ｐｕｂｌｉｓｈＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒ、図面におけるステップ７を参照）。次に、ｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスにおけるｂｉｎｄｅｒ＿３スレッド（すなわち、通信スレッド３）は、メッセージを受信し、インストールの継続時間の閾値内にすべての作業が完了する場合に、ＡＮＲのトリガー条件を解除することができ、ＡＮＲが発生することがなく（図面におけるステップ８を参照）、そうでなければ、ＡＮＲが発生することになる。

【0041】

（四）入力イベント配信型の無応答現象。

【0042】

入力イベント配信型の無応答現象が生じる過程は、１つの入力イベントを受信した場合に、現在受信された入力イベントを入力キューに追加し、且つ入力配信スレッドをウェイクアップするステップであって、入力配信スレッドは、入力キューにおける各々の入力イベントを目標アプリケーションのアプリケーションプロセスに順番に配信して処理させることに用いられる、ステップと、現在受信された入力イベントの配信順位に達するときに、目標アプリケーションのアプリケーションプロセスが他の入力イベントを処理すると、入力イベント配信型の無応答現象が生じるステップと、を含む。

【0043】

具体的に、システムサービスプロセスにおけるスレッドは、最下層から告知した入力イベントを聴取することができ、且つ入力イベントを受信したときに、それを入力キューに追加して配信処理をウェイトすることができる。同時に、入力配信スレッドをウェイクアップして該入力キューにおける入力イベントを配信することができ、このときに、配信開始時間を設定することができる。現在受信された入力イベントの配信順位に達するとき、たとえば、現在受信された入力イベントの配信時間点に達するときに、もし目標アプリケーションのアプリケーションプロセスがまだ他の入力イベントを処理するとすれば、アプリケーションプロセスが配信されようとする現在受信された入力イベントを処理できないことを意味し、入力イベント配信型の無応答現象が生じ得る。クラウドゲームシーンにおいて、該入力イベントは、具体的に、オブジェクトのゲームクライアント端末における操作イベントであってもよく、操作イベントが操作ストリームの方式でクラウドゲームを動作させるサーバに達し、処理されることができず、ＡＮＲが発生する。

【0044】

別の実現形態では、現在受信された入力イベントの配信順位に達するときに、目標アプリケーションのアプリケーションプロセスが他の入力イベントを処理していなければ、入力配信スレッドによって、現在受信された入力イベントをアプリケーションプロセスに配信することにより、アプリケーションプロセスは、１つ又は複数の他のプロセスを呼び出して現在受信された入力イベントを処理し、且つ処理が完了した後にフィードバック情報を返す。処理継続時間の閾値内にアプリケーションプロセスから返されたフィードバック情報を受信しなかった場合には、入力イベント配信型の無応答現象が生じる。

【0045】

現在受信された入力イベントが配信順位に達し、たとえば、配信開始時間点、及び処理継続時間の閾値に基づいて、該入力イベントの配信時間点に達すると決定したときに、入力配信スレッドによって、現在受信された入力イベントをアプリケーションプロセスに配信することができ、具体的に、アプリケーションプロセスの目標ウィンドウに配信することができる。アプリケーションプロセスは、１つ又は複数の他のプロセスを呼び出して現在受信された入力イベントを処理し、且つ処理が完了した後にフィードバック情報を返すことができる。該フィードバック情報は、入力イベントが完了したことを指示することに用いられる通知メッセージである。ここで、呼び出された１つ又は複数のプロセスにおいて、親子関係を備えるプロセスが含まれてもよく、且つ親子プロセスの間で、アドレス空間を共有することができる。

【0046】

処理継続時間の閾値内にアプリケーションプロセスから返されたフィードバック情報を受信せず、且つ新たな入力イベントを受信した場合、現在受信された入力イベントの処理が規定された処理継続時間の閾値内に終了せず、次の入力イベントが現在受信された入力イベントの処理をウェイトするようになることを意味する。それにより、入力イベント配信型の無応答現象が生じ得る。逆に、現在受信された入力イベントを処理するときに、新たな入力イベントを受信しない限り、処理継続時間の閾値内にアプリケーションプロセスから返されたフィードバック情報を受信しなかった場合でも、又は処理継続時間の閾値内にアプリケーションプロセスから返されたフィードバック情報を受信した場合でも、入力イベント配信型の無応答現象が発生することがない。

【0047】

ＡｎｄｒｏｉｄオペレーティングシステムのＡＮＲを例にして、入力イベント配信型のＡＮＲをより詳細に紹介する。具体的に、図１ｇに示される入力イベント配信型のＡＮＲが生じる過程の模式図を併せて参照することができる。まず、ＩｎｐｕｔＲｅａｄｅｒスレッド（すなわち、入力読み取りスレッド）は、ＥｖｅｎｔＨｕｂ（イベントハブ）によって最下層から告知した入力イベントを聴取し、一旦入力イベントを受信すると、それをｍＩｎＢｏｕｎｄＱｕｅｕｅキュー（入力キューであり、配信されようとする入力イベントを記憶することに用いられる）に入れ、且つＩｎｐｕｔＤｉｓｐａｔｃｈｅｒスレッド（入力配信スレッド）をウェイクアップする（図面におけるステップ１を参照）。ＩｎｐｕｔＤｉｓｐａｔｃｈｅｒスレッドは、入力イベントの配信をスタートし、配信起点時間を設定する。まず、処理されているイベントがあるか否かを検出し、ない場合に、ｍＩｎＢｏｕｎｄＱｕｅｕｅの先頭のイベントを取り出す。次にウィンドウが準備できているか否かを検査し、ウィンドウが準備できていると、イベントをｏｕｔＢｏｕｎｄＱｕｅｕｅキュー（出力キューであり、目標ウィンドウに配信されようとする入力イベントを記憶することに用いられる）に移動する。このときに、アプリケーションパイプラインの相手端末の接続が正常である場合に、データをｏｕｔＢｏｕｎｄＱｕｅｕｅから取り出し、ｗａｉｔＱｕｅｕｅキュー（ウェイトキューであり、目標ウィンドウの処理をウェイトする入力イベントを記憶することに用いられる）に入れる（図面におけるステップ２～４を参照）。次にＩｎｐｕｔＤｉｓｐａｔｃｈｅｒは、メッセージを送信して目標アプリケーションに処理作業の実行を用意することを知らせる。このときに、目標アプリケーションのｍａｉｎスレッド（すなわち、メインスレッド）は、入力イベントを受信し、且つ受信された入力イベントを１層ずつに目標ウィンドウに転送して処理し、上記作業が完了すると、メッセージを送信してｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスに作業が完了することを報告することができる（すなわち、完了信号を送信し、図面におけるステップ７を参照）。次に、システムは、該イベントをｗａｉｔＱｕｅｕｅキューから取り外すことができる。現在の入力システムにおいて時間がかかるある操作（たとえば、ファイル操作）を処理している場合に、その後の毎回の入力イベントは、みな１つ前の入力イベントがタイムアウトするか否かを検出することができ、タイムアウトする場合はＡＮＲである。

【0048】

ＡＮＲに対する上記の具体的な原理の紹介に基づき、またＡＮＲが発生したオペレーティングシステムのソースコード（すなわち、システムコード）を分析することから明らかなように、Ｓｅｒｖｉｃｅ、ＢｒｏａｄｃａｓｔＱｕｅｕｅ、ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒ、及びＩｎｐｕｔ等のシーンにおけるＡＮＲにおいて、アプリケーションプロセスは、みなｓｙｓｔｅｍ＿ｓｅｒｖｅｒプロセスとインタラクションすることができ、またみなＺｙｇｏｔｅと要求を開始して新たなプロセスを作成し得る（一部は図示されていないが、新しいプロセスの作成がみなＺｙｇｏｔｅプロセスによって実現できると理解できる）。これらは、みな最下層のオペレーティングシステムにおけるコンテンツである。

【0049】

ＡＮＲの問題を解決するために、本願は、システムコードを修復することにより、アプリケーションの無応答現象を解決するスキームを提供する。具体的に言えば、目標アプリケーションの各種類の無応答現象の現場情報を収集することができ、該現場情報に基づいて、目標アプリケーションに無応答現象が生じるときのシステムコードの実行状況を知ることができ、収集された各種類の無応答の現場情報に対して共通性分析を行うことによって、共通性分析結果を決定することができる。いわゆる共通性分析とは、共通要素を探す分析を指し、共通性分析で得られた共通性分析結果に基づいて、オペレーティングシステムのシステムコードから無応答現象が生じる障害点を決定し、それにより、障害点に基づいてシステムコードを修復することができる。このように、修復後のシステムコードに基づいて目標アプリケーションを動作させれば、無応答現象の発生確率を効果的に低減させて、無応答現象の発生による目標アプリケーション、又はオペレーティングシステムのクラッシュ状況を減少させることができ、システム、及びアプリケーションの安定した動作において有利である。本スキームは、最下層システムの観点から、オペレーティングシステムのレベルにおいて、オペレーティングシステムのシステムコードを修復することによって、オペレーティングシステムにおけるアプリケーション無応答の問題を根本的に解決することを実現する。これは根本的な解決方法であり、汎用性を備えるものである。

【0050】

これから分かるように、オペレーティングシステムのレベルから、オペレーティングシステムにおけるＡＮＲが生じる過程を深く研究し、ＡＮＲのトリガー原理を知り、且つオペレーティングシステムのソースコードからいくつかの種類のＡＮＲが発生するときの最下層のアーキテクチャロジックを分析し、システム呼び出し関数を変えることによって、オペレーティングシステムにおけるＡＮＲトリガーのアーキテクチャロジックの変更を実現し、オペレーティングシステムにおけるＡＮＲの問題を根本的に解決することができ、アプリケーションプログラム、又はシステムがクラッシュする状況を減少させ、システム、及びアプリケーションの互換性、及び安定性を向上させることができる。変更されるのは、ネイティブのオペレーティングシステムであり、且つハードコーディングが使用されないため、特定のプラットフォームと強くバインディングされておらず、クラウドゲーム、端末、及びシミュレーター等の各種類のシーンに適用することができ、シーン汎用性が高く、且つ複数の種類のＡＮＲに対処して各種類のＡＮＲの問題を効果的に避けることができる。

【0051】

理解できるように、本スキームは、アプリケーション無応答が生じる各種類のシーン、たとえば、端末、シミュレーター、及びクラウドゲームシーンに応用できる。クラウドゲームシーンに応用されるときに、クラウドゲームシーンにおけるＡＮＲの問題を解決し、クラウドゲームプラットフォームの互換性、及び安定性を向上させ、使用体験を向上させることができる。ここで、目標アプリケーションは、クラウドゲームアプリケーションであってもよい。いわゆるクラウドゲームとは、クラウドコンピューティング技術を基礎としたオンラインゲーム技術を指す。

【0052】

クラウドコンピューティング技術は、クラウド技術に属する。いわゆるクラウド技術（Ｃｌｏｕｄｔｅｃｈｎｏｌｏｇｙ）とは、広域ネットワーク、又はローカルエリアネットワーク内にハードウェア、ソフトウェア、及びネットワーク等の一連のリソースを統合し、データのコンピューティング、記憶、処理、及び共有を実現するホスティング技術を指す。ここで、クラウドコンピューティング（ｃｌｏｕｄｃｏｍｐｕｔｉｎｇ）は、コンピューティングモードであって、コンピューティングタスクを多くのコンピュータで構成されるリソースプールに分布し、各種類のアプリケーションシステムが必要に応じてコンピューティング能力、記憶空間、及び情報サービスを取得できるようにするものである。リソースを提供するネットワークは、「クラウド」と呼ばれる。「クラウド」におけるリソースは、使用者から見れば、無限に拡張することができ、且ついつでも取得し、必要に応じて使用し、いつでも拡張し、使用に応じて料金を支払うことができる。クラウドコンピューティングの基礎能力プロバイダーとして、クラウドコンピューティングリソースプール（クラウドプラットフォームとの略称であり、一般的にＩａａＳ（ＩｎｆｒａｓｔｒｕｃｔｕｒｅａｓａＳｅｒｖｉｃｅ、インフラストラクチャーアズアサービスと呼ばれる）プラットフォームを確立することができ、リソースプールにおいて、複数の種類の型の仮想リソースを配備し、外部クライアントの選択や使用に供する。クラウドコンピューティングリソースプールにおいては、主に、コンピューティング機器（仮想化機械であり、オペレーティングシステムを含む）、記憶機器、及びネットワーク機器が含まれる。本願では、現場情報の共通性分析に対して、クラウドコンピューティング技術を採用してもよい。

【0053】

クラウドゲームシーンにおいて、ゲームをクラウド端末サーバにおいて動作させることができ、ゲームにおける高消費量のレンダリングコンピューティングに対して、クラウド端末サーバに配置して行い、且つオーディオビデオストリームで画面、及び音声をネットワークによってプレイヤーのゲーム端末に伝送し、操作ストリームの方式でユーザー操作命令をクラウド端末サーバに伝送し、相応なコンピューティングを実行することができる。現在の移動通信技術、例えば、５Ｇ（５ｔｈＧｅｎｅｒａｔｉｏｎＭｏｂｉｌｅＣｏｍｍｕｎｉｃａｔｉｏｎＴｅｃｈｎｏｌｏｇｙ、第五世代移動通信技術、５Ｇと略称される）の急速な発展、より高い伝送帯域幅、及びより強い並行能力の恩恵を受けて、ネットワーク遅延をより短くし、クラウドゲームのためにより多くの発展の機会、及びより多くの想像力の余地をももたらす。

【0054】

クラウドゲームを動作させる環境は、クラウドゲーム環境と呼ばれてもよい。該クラウドゲーム環境において、システムコンテナを動作させる方式によって、複数のオペレーティングシステムを１つ又は複数の独立したサーバ（例えば、ＡＲＭ／ｘ８６等のアーキテクチャを採用するサーバ）で動作させ、且つビデオストリームの方式によって関連する画像をリモート受信プログラムに伝達して処理することができる。ここで、ＡＲＭアーキテクチャは、３２ビット／又は６４ビットの縮小命令セットのプロセッサアーキテクチャであり、ｘ８６アーキテクチャ（ＴｈｅＸ８６ａｒｃｈｉｔｅｃｔｕｒｅ）は、マイクロプロセッサが実行するコンピュータ言語命令セットである。コンテナとは、オペレーティングシステムレベルの仮想化の一種の型を指し、コンテナは、オペレーティングシステムをベアラすることに用いることができる。それは、分離メカニズム（たとえば、ｎａｍｅｓｐａｃｅ（名前空間））によって、カーネルモードでは、複数のオペレーティングシステム（すなわち、サーバオペレーティングシステム、及び機器オペレーティングシステム）が同一のカーネルを共用することと、ユーザーモードでは、複数のオペレーティングシステムが相互に独立することを維持することと、を実現することができる。ここでのサーバオペレーティングシステムとは、サーバ内の汎用オペレーティングシステム、例えば、Ｌｉｎｕｘオペレーティングシステム、及びＡｎｄｒｏｉｄオペレーティングシステム等を指し、機器オペレーティングシステムとは、コンテナ内のオペレーティングシステム、例えば、Ａｎｄｒｏｉｄ（アンドロイド（登録商標））オペレーティングシステム、及びＩＯＳオペレーティングシステム等を指す。

【0055】

相応に、システムコンテナとは、コンテナの一種の実例を指しており、サーバオペレーティングシステム（例えば、Ｌｉｎｕｘオペレーティングシステム）に基づいて動作することができる。たとえば、該システムコンテナは、Ｌｉｎｕｘオペレーティングシステムにおいて動作するＡｎｄｒｏｉｄコンテナであってもよく、Ａｎｄｒｏｉｄコンテナがロードするのは、Ａｎｄｒｏｉｄミラーリングであり、いわゆるミラーリングは、ファイルの記憶形式であり、ミラーリングによって複数のファイルを１つのミラーファイルに合併することで、ファイルの配信、及び使用を容易にすることができる。理解すべきであるように、本願の実施例に言及されるシステムコンテナは、Ａｎｄｒｏｉｄコンテナに限定されず、たとえば、ＩＯＳオペレーティングシステムがオープンソースの研究開発をサポートする場合に、該システムコンテナは、さらにＩＯＳコンテナ等であってもよい。これから分かるように、本願の実施例により提案されるクラウドゲーム環境において、１つの独立したサーバにおいて多くのシステムコンテナを配備することによって、サーバ側の強力なＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、中央プロセッサ）能力、及びＧＰＵ（ＧｒａｐｈｉｃｓＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、グラフィックスプロセッサ）能力を十分に利用し、システム操作を高並行性で実行することを実現し、クラウドゲームの動作速度を向上させることができる。

【0056】

クラウドゲーム環境は、クラウドゲームシステムにおける機器が相応な動作リソースを提供することによりサポートされてもよい。図２ａに示されるクラウドゲームシステムのアーキテクチャ模式図に参照されるように、クラウドゲームシステムは、少なくとも１つのエッジサーバ１１、複数のゲームクライアント端末１２、及び少なくとも１つの分析サーバ１３を含んでもよい。ここで、エッジサーバは、クラウドゲームを動作しているサーバであり、図２ａに示される各々のエッジサーバ内に、少なくとも１つのシステムコンテナが配備され、且つシステムコンテナ内に１つ又は複数のゲームＡＰＰ（Ａｐｐｌｉｃａｔｉｏｎ、アプリケーションプログラム）がインストールされてもよく、これらのゲームＡＰＰによって、１つ又は複数のクラウドゲームを動作させることができる。このように、システムコンテナによってクラウドゲームを動作させることができる。個々のシステムコンテナは、少なくとも１つのゲームクライアント端末１２と接続されてもよく、それにより、クラウドゲームのゲーム画面、及び音声を、接続されたゲームクライアント端末１２に伝送することができる。この他、エッジサーバ１１がクラウドゲームを動作させる過程においてＡＮＲが発生するときに、ゲームクライアント端末１２に提示を表示することができ、図２ｂに示されている通りである。

【0057】

分析サーバ１３は、アプリケーションに無応答現象が発生することを分析することに用いられるサーバである。少なくとも１つのエッジサーバ１１におけるシステムコンテナにおけるクラウドゲームアプリケーションが動作している過程において、１つ又は複数のエッジサーバにおけるアプリケーションに異なる型の無応答現象が発生することが存在する可能性がある。このときに、分析サーバ１３は、エッジサーバ１１におけるあるクラウドゲームアプリケーションの少なくとも二種類の無応答現象が発生するときに生じた現場情報を収集し、且つ各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析の結果に基づいて、無応答現象が生じる共通の障害点を探し出すことができる。該共通の障害点によってオペレーティングシステムのシステムコードを修復し、且つ修復後のシステムコードに基づいて、クラウドゲームアプリケーションを動作させ、アプリケーション無応答の問題を解決する。別の実施例において、上記作業は、１つの目標エッジサーバにより実行されてもよく、すなわち、少なくとも１つのエッジサーバ１１のうちのいずれか１つのエッジサーバは、複数の種類の無応答現象の現場情報を取得することができ、上記同じ原理に基づいてオペレーティングシステムのシステムコードを修復することにより、アプリケーション無応答現象を解決し、且つ避けることができる。

【0058】

説明する必要がある点として、エッジサーバ、及び分析サーバは、独立した物理サーバであってもよく、複数の物理サーバで構成されたサーバクラスター、又は分散システムであってもよく、さらに、クラウドサービス、クラウドデータベース、クラウドコンピューティング、クラウド関数、クラウド記憶、ネットワークサービス、クラウド通信、ミドルウェアサービス、ドメイン名サービス、セキュリティサービス、ＣＤＮ（ＣｏｎｔｅｎｔＤｅｌｉｖｅｒｙＮｅｔｗｏｒｋ、コンテンツ配信ネットワーク）、及びビッグデータや人工知能プラットフォーム等の基本的なクラウドコンピューティングサービスを提供するクラウドサーバであってもよいが、これらに限定されない。

【0059】

ゲームクライアント端末１２は、ストリーミングメディア再生能力、人間とコンピュータとのインタラクション能力、及び通信能力等の基本能力を提供する端末機器であってもよく、端末機器において動作するアプリケーションプログラムであってもよい。ここで、端末機器は、携帯電話、コンピュータ、スマート音声インタラクション機器、スマート家電、車載端末、及び航空機等の機器を含むが、これらに限定されず、本願は、これに対して限定しない。理解できるように、図２ａは、クラウドゲームシステムのシステムアーキテクチャを例示的に表すためのものに過ぎず、クラウドゲームシステムの具体的なアーキテクチャを限定するものではない。たとえば、他の実施例において、クラウドゲームシステムにおいてはスケジューリングすることに用いられるバックグラウンドサーバ等がさらに含まれてもよい。

【0060】

上記で紹介されたクラウドゲーム環境、及びクラウドゲームシステムに基づいて、サーバの一側に配備されるクラウドゲームに対して、その最下層は、コンテナ化技術、システム、及びカーネル技術に基づくことができる。且つこれに基づき、オーディオビデオ技術、ネットワーク最適化、及びコンピューティングリソース管理等の面と合わせて、相応なクラウドゲームプラットフォーム（クラウドゲームに動作環境、及びサービスを提供することができる）を作ることができ、該クラウドゲームプラットフォームにおいて、複数の種類のクラウドゲームを動作させることができる。以下では、クラウドゲームの最下層がＡｎｄｒｏｉｄネイティブオペレーティングシステム、及びＬｉｎｕｘカーネルに基づくことを例にして、クラウドゲームの動作過程におけるシステムのレベルの関連するインタラクションロジックを例示的に説明する。図２ｃに示すように、サーバにおけるシステムの最下層のインタラクションロジックは、具体的に、システムコンテナ、Ｌｉｎｕｘカーネル、及びサーバにより提供されるハードウェアの間のインタラクションに関する。

【0061】

システムコンテナがクラウドゲームを動作させる過程において、システムコンテナ、又はシステムコンテナにおけるゲームＡＰＰは、オペレーティングシステムに操作要求を送信することができ、且つオペレーティングシステムによりその内のＬｉｎｕｘカーネルとインタラクションし、Ｌｉｎｕｘカーネルにより該操作要求を受信する。該操作要求に基づいて、Ｌｉｎｕｘカーネルは、関連するハードウェア（たとえば、中央プロセッサ、グラフィックスプロセッサ、及び内部メモリ等のうちの一種、又は複数の種類）を呼び出して、該操作要求に対応する操作を完了することができる。ハードウェアは、操作要求に基づき実行を完了した後に、操作要求に対応する操作結果をＬｉｎｕｘカーネルによってシステムコンテナに返すことができる。例を挙げると、操作要求がレンダリング要求であるときに、レンダリング要求に基づいてサーバにより提供されるグラフィックスプロセッサ（ＧＰＵ、ＧｒａｐｈｉｃｓＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）を呼び出し、該レンダリング要求に対応するレンダリングイベントを実行して、レンダリングが完了したゲーム画面を得て、且つＬｉｎｕｘカーネルによって、レンダリングが完了したゲーム画面を返すことができる。一種の実現形態では、さらに、システムコンテナにおけるコーディングモジュールを呼び出し、返されたゲーム画面に対して画像圧縮処理を行い、圧縮後の画像を得ることができる。画像圧縮の過程において、Ｌｉｎｕｘカーネルによって最下層のハードウェアリソースを呼び出してコーディングを行い、コーディングデータ（すなわち、圧縮後の画像）を得て、且つ圧縮後の画像を、Ｌｉｎｕｘカーネルによってオペレーティングシステムに返し、コーディングデータを得た後に、ビデオストリームの方式で圧縮後の画像をゲームクライアント端末に伝送することができる。

【0062】

クラウドゲームの最下層もまたオペレーティングシステムに基づくものであり、ＡＮＲがオペレーティングシステムにおけるよく見られる現象であるため、クラウドゲームを動作させる過程においても、ＡＮＲの問題に直面する可能性がある。上記で言及されたシステムコードを修復してアプリケーション無応答現象を解決するスキームを採用することで解決することができる。

【0063】

上記で言及されたシステムコードを修復してアプリケーション無応答現象を解決するスキームに基づいて、本願は、データ処理方法を提供する。該データ処理方法は、コンピュータ機器により実行されてもよく、コンピュータ機器は、端末、又はサーバであってもよい。目標アプリケーションがクラウドゲームアプリケーションであるときに、ここでのコンピュータ機器は、たとえば、図２ａに示されるクラウドゲームシステムにおけるいずれかの分析サーバ１３であってもよい。勿論、該データ処理方法は、端末、及びサーバにより共同で実行されてもよく、これについて限定しない。理解を容易にするために、該データ処理方法がコンピュータ機器により実行されることを例にして、以下のように説明する。

【0064】

理解できるように、端末は、携帯電話、コンピュータ、スマート音声インタラクション機器、スマート家電、車載端末、及び航空機等の機器であってもよく、本願は、これに対して限定しない。サーバは、独立した物理サーバであってもよく、複数の物理サーバで構成されたサーバクラスター、又は分散システムであってもよく、さらに、クラウドサービス、クラウドデータベース、クラウドコンピューティング、クラウド関数、クラウド記憶、ネットワークサービス、クラウド通信、ミドルウェアサービス、ドメイン名サービス、セキュリティサービス、ＣＤＮ（ＣｏｎｔｅｎｔＤｅｌｉｖｅｒｙＮｅｔｗｏｒｋ、コンテンツ配信ネットワーク）、及びビッグデータや人工知能プラットフォーム等の基本的なクラウドコンピューティングサービスを提供するクラウドサーバであってもよいが、これらに限定されない。

【0065】

図３ａに参照されるように、図３ａは、本願の実施例が提供するデータ処理方法のフローチャートであり、該データ処理方法は、以下のＳ３０１～Ｓ３０３を含んでもよい。

【0066】

Ｓ３０１：目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得する。

【0067】

目標アプリケーションの複数の種類の無応答現象とは、目標アプリケーションの少なくとも二種類の無応答現象、たとえば、前述に紹介されたサービス型の無応答現象、ブロードキャスト型の無応答現象、コンテンツ提供型の無応答現象、及び入力イベント配信型の無応答現象のうちの少なくとも二種類を指す。

【0068】

いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において生じるものである。目標アプリケーションの無応答現象とは、目標アプリケーションプログラムが応答しない現象を指し、具体的に、幾つかのイベントが所定の時間内に効果的な応答を得ることができず、又は応答時間が長すぎるという現象である。記述の便宜上、目標アプリケーションの無応答現象は、アプリケーション無応答（ＡＮＲ）、又はＡＮＲ現象と略称できる。

【0069】

オペレーティングシステム（ＯｐｅｒａｔｉｏｎＳｙｓｔｅｍ、ＯＳ）は、コンピュータシステム全体のハードウェア、及びソフトウェアリソースを制御し、かつ管理し、コンピュータの作業、及びリソースの割り当てを合理的に組織、及びスケジューリングすることにより、オブジェクト、及び他のソフトウェアに便利なインタフェース、及び環境を提供することに用いられる。オペレーティングシステムのカテゴリは、Ａｎｄｒｏｉｄオペレーティングシステム、Ｗｉｎｄｏｗｓオペレーティングシステム、Ｌｉｎｕｘオペレーティングシステム、及びｉＯＳオペレーティングシステム等を含むが、これらに限定されない。

【0070】

オペレーティングシステムは、アプリケーションプログラムに動作環境を提供することができ、アプリケーションプログラムは、オペレーティングシステムが提供する関数を呼び出すこと（すなわち、システム呼び出し）によって幾つかのイベントを完了することができる。従って、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させることとは、目標アプリケーションを動作させる過程において、オペレーティングシステムのシステムコードの呼び出しが可能であることを指す。この過程において、目標アプリケーションに無応答現象が発生する可能性があり、たとえば、Ａｎｄｒｏｉｄオペレーティングシステムのシステムコードを呼び出して目標アプリケーションを動作させるときに、目標アプリケーションに必要な聴取サービスの作成が所定の時間内に完了しないことによる無応答現象がある。目標アプリケーションとは、コンピュータ機器において動作するいずれかのアプリケーションを指す。たとえば、端末において動作するアプリケーション、又はサーバにおいて動作するサービスプログラムである。目標アプリケーションは、具体的に、ゲーム類アプリケーション、オーディオビデオ類アプリケーション、ソーシャル類アプリケーション、及びショッピング類アプリケーション等のうちのいずれか一種であってもよい。クラウドゲームシーンを例にすると、該目標アプリケーションとは、サーバのシステムコンテナにおいて配備されたクラウドゲームアプリケーション、又はクラウドゲームサービスプログラムを指してもよい。

【0071】

目標アプリケーションの無応答現象は、異なるシーンにおいて生じることができ、一種類のシーンにおいて生じた無応答現象は、一類型の無応答現象に対応できる。Ａｎｄｒｏｉｄオペレーティングシステムを例とすると、具体的に、下記シーンにおいて無応答現象が生じ得る。(1)サービスタイムアウト（ＳｅｒｖｉｃｅＴｉｍｅｏｕｔ）：具体的に、フォアグラウンドサービスタイムアウト、及びバックグラウンドサービスタイムアウトを含み、例えば、フォアグラウンドサービスの実行が２０ｓ内に完了しない。(2)ブロードキャストタイムアウト（ＢｒｏａｄｃａｓｔＴｉｍｅｏｕｔ）：フォアグラウンドブロードキャストタイムアウト、及びバックグラウンドブロードキャストタイムアウトを含み、たとえば、フォアグラウンドブロードキャストの実行が１０ｓ内に完了しない。(3)コンテンツプロバイダータイムアウト（ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒＴｉｍｅｏｕｔ）：たとえば、コンテンツプロバイダーがｐｕｂｌｉｓｈ（発行）の後に１０ｓタイムアウトすると無応答現象が発生する。(4)入力イベント配信タイムアウト（ＩｎｐｕｔＤｉｓｐａｔｃｈｉｎｇＴｉｍｅｏｕｔ）：キー、及びタッチイベントを含み、具体的に、キー応答配信タイムアウト（ＫｅｙＤｉｓｐａｔｃｈＴｉｍｅｏｕｔ）、及びタッチイベント配信タイムアウトを含み、たとえば、キー応答配信の継続時間はデフォルトで５ｓであり、超えれば無応答現象が発生し得る。

【0072】

各種類の無応答現象が発生するときにはみな、現場情報を自動的に生成して収集することができ、一種類の無応答現象は、一類型の現場情報に対応できる。いずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときのシステムコードの実行状況を記述することに用いられる。

【0073】

無応答現象の現場情報とは、該無応答現象が生じるときに、オペレーティングシステムによりキャプチャーされた関連する情報を指す。該現場情報は、該種類の無応答現象が生じるときのオペレーティングシステムのシステムコードの実行状況を記述することに用いることができる。システムコードの実行状況は、たとえば、システムコードがどのステップに実行されて無応答現象が発生するか、及びどのプロセス、又はスレッドにおいてイベントの応答がタイムアウトするか等の内容である。前述した図１ｄ～図１ｇにより紹介されたＡＮＲが生じる過程から明らかなように、ＡＮＲが発生するときに、非常に多くのプロセスが動作することになり、たとえば、サービス型のＡＮＲにおいて動作するプロセスは、システムサービスプロセス、サービスプロセス、及び他の示されていないプロセスを有する。従って、現場情報は、システムコードにおいて動作するプロセスの関連する情報、たとえば、プロセスのプロセス識別子を含んでもよい。選択可能に、現場情報は、ＡＮＲの発生時間、ＡＮＲ発生前後のプロセスの各々のスレッドのスタック（ｓｔａｃｋ）を記録することに用いられるトレース（ｔｒａｃｅ）ファイル、ＡＮＲの型、及びＡＮＲが生じるときの各々のプロセスの情報（たとえば、プロセス番号、プロセス名称、プロセス実行スタート時間、及び終了時間）等の内容を含んでもよいが、これらに限定されない。各種類の無応答の現場情報は、関連するログにおいて記録されてもよく、具体的に分析するときに、全部、又は一部の現場情報を取得して更に分析することができる。

【0074】

例示的に、クラウドゲームシーンを例として、１つのクラウドゲームにおけるアプリケーション無応答の現場は、図３ｂに示されてもよい。ここで、ｄｏｃｋｅｒｅｘｅｃ－ｉｔｂ２３ｓｈｂ２３４３９８５６３９ｅは、コンテナ名称がｂ２３４３９８５６３９ｅであるコンテナ内に入って、ミラーリングに対応する設定ファイルがある位置を探すことを表す。ｐｓ－ｅｆ｜ｇｒｅｐＳｇａｍｅは、コンテナ名称がｂ２３４３９８５６３９ｅであるコンテナにおいて、ｓｇａｍｅキーワードを含有するプロセスを見つけ出し、且つ表示することを表す。図３ｂに示されるクラウドゲームプラットフォームでアプリケーション無応答現象が生じる現場のように、取得された現場情報は、コンテナにおける各々のプロセス（一部のみをディスプレイする）のプロセス情報を含む。表示された１行目の情報を例にして、プロセスのプロセスＩＤ（ＰＩＤ、ＰｒｏｃｅｓｓＩｄｅｎｔｉｆｉｃｔｉｏｎ）１９１０、該プロセスの親プロセスのＩＤ（ＰＰＩＤ、ＰａｒｅｎｔＰｒｏｃｅｓｓＩｄｅｎｔｉｆｉｃｔｉｏｎ）１１０、ｃｐｕが使用するリソース百分率１６、システムの起動時間１２：５４：１８、ＣＰＵの使用時間００：０３：１５、及びプロセス名称「ｃｏｍ．ｔｅｎ．ｔｍｇｐ．ｓｇａｍｅ」等を含む。

【0075】

各種類の無応答現象の現場情報を収集することによって、各種類の無応答現象が発生するときのオペレーティングシステムのシステムコードの実行状況を得ることができる。このように、その後にこれらの無応答現象が発生する共通特性を分析することにより、オペレーティングシステムにおけるアプリケーション無応答現象を効果的に回避することにおいて有利である。具体的に、Ｓ３０２、及びＳ３０３の紹介を参照できる。

【0076】

Ｓ３０２：各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ共通性分析結果に基づき、システムコードから無応答現象が生じる障害点を決定する。

【0077】

共通性分析とは、共通特性を探す分析方法を指す。ここで、各種類の無応答現象の現場情報に対して共通性分析を行うこととは、すなわち、各種類の無応答現象が生じる共通特性を探し、共通性分析結果を得ることを指す。共通性分析結果は、各種類の無応答現象の現場情報における共通情報、たとえば、各種類の無応答現象の現場情報においてみな有する同じプロセス番号を含む。

【0078】

共通性分析結果に基づいて、システムコードから無応答現象が生じる障害点を決定することができる。該障害点は、各種類の無応答現象が発生する共通の障害点である。障害点は、システムコードにおける、各種類の無応答現象が生じることを引き起こす障害コードであってもよい。たとえば、みなシステム呼び出し関数を使用するときに発生する無応答現象である。該障害点によって、アプリケーション無応答現象が生じることを引き起こす共通の原因を更に知ることができ、それにより、システムコードに対する修復方式を容易に決定する。

【0079】

ＡＮＲの発生を引き起こす原因は非常に多く、たとえば、デッドロックがＡＮＲを引き起こす、Ｉ／Ｏリソースの不足がＡＮＲを引き起こす、且つメインスレッドのエンドレスループがＡＮＲを引き起こす等があるため、具体的なＡＮＲに対する具体的な分析方法が具体的なシーン（たとえば、オペレーティングシステムバージョン、アプリケーションバージョン、及び端末等）に限定され得る場合、別のシーンに変わると、ＡＮＲを解決するスキームは、適用されない可能性がある。従って、各種類のシーンに対する汎用性が高くない。本スキームにおいて提供される分析メカニズムは、共通性分析メカニズムであり、各種類の無応答現象の現場情報の間の共通特性を探すことによって、共通性分析結果を得て、且つ共通性分析結果に基づいて各種類の無応答現象が発生する障害点を知る。更に、その後の修復処理によって目標アプリケーションの複数の種類の無応答現象のうちのいずれか一種類の無応答現象を解消でき、アプリケーション無応答現象の発生確率を効果的に低減させ、各種類のシーンにおいて、全て汎用性、及び安定性を備えることができる。

【0080】

Ｓ３０３：障害点に基づきシステムコードを修復処理することにより、修復後のシステムコードに基づいて目標アプリケーションを動作させる。

【0081】

障害点が最下層のシステムコードから決定されるため、障害点に基づいてオペレーティングシステムのシステムコードを修復処理し、修復後のシステムコードを得ることができる。ここでの修復処理とは、システムコードに対する修正を指してもよく、修復後のシステムコードは、障害点に基づいて元のシステムコードを最適化したものである。修復後のシステムコードに基づいて目標アプリケーションを動作させると、目標アプリケーションの動作の過程において、修復後のシステムコードを呼び出すことができる。システムコードは、無応答現象が発生する障害点を最適化しているため、アプリケーションプログラムの動作の過程において、無応答現象が生じることを効果的に回避することができる。

【0082】

このように、オペレーティングシステムのシステムコードに対する修復によって、ネイティブオペレーティングシステムに対する変更を実現する。システムコードに対する修正であることから、複数の種類のＡＮＲが発生するときの問題を原理的に解決することができるため、オペレーティングシステムがどのような機器、又はプラットフォームにおいて配備されてもよい。このように、本スキームは、クラウドゲームプラットフォームに応用され、クラウドゲームプラットフォームのＡＮＲの発生による不安定現象を効果的に解決し、クラウドゲームプラットフォームの安定性を向上させることができるだけでなく、実際の端末（たとえば、携帯電話）、シミュレーター（たとえば、Ａｎｄｒｏｉｄシミュレーター）製品、及びオペレーティングシステムプラットフォーム（たとえば、他のＡｎｄｒｏｉｄプラットフォーム）等にも応用することができ、シーンの汎用性が高くなり、各種類のＡＮＲ現象を効果的に避けることができる。

【0083】

本願の実施例が提供するデータ処理スキームによって、目標アプリケーションの複数の種類の無応答現象の現場情報を収集することをサポートする。現場情報は、該無応答現象が対応して発生するときのシステムコードの実行状況を記述することに用いられるため、複数の種類のＡＮＲの現場情報に対して共通性分析を行うことによって、オペレーティングシステムのレベルからシステムコードの実行状況を分析し、最下層から各種類の無応答現象が生じる共通特性を探し、共通性分析結果を得ることができ、共通性分析結果に基づいて無応答現象が生じる障害点を決定し、更に障害点に基づいてオペレーティングシステムのシステムコードを修復し、且つ修復後のシステムコードに基づいて目標アプリケーションを動作させることができる。このように、目標アプリケーションを動作させる過程において、修復後のシステム操作は、オペレーティングシステム側から無応答現象が発生する可能性がある状況を阻止することができ、ほとんどのＡＮＲシーンに非常に良好に対処し、ほとんどのＡＮＲの問題を回避することができる。これから分かるように、本スキームは、オペレーティングシステムの最下層のシステムコードから、オペレーティングシステムにおけるＡＮＲの問題を根本的に解決することができ、汎用性が高く、オペレーティングシステム、又は目標アプリケーションにいずれか一種類の無応答現象が発生する状況を減少することができ、それにより、システム、又はアプリケーションの安定性を効果的に向上させることができる。クラウドゲームプラットフォームに応用されるときには、クラウドゲームプラットフォームの互換性、及び安定性を向上させ、プレイヤーのゲーム体験を向上させることができる。

【0084】

図４に参照されるように、図４は、本願の実施例が提供する別のデータ処理方法のフローチャートであり、該データ処理方法は、Ｓ４０１～Ｓ４０６を含んでもよい。

【0085】

Ｓ４０１：目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得する。

【0086】

Ｓ４０２：各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得る。

【0087】

１つの実施例において、システムコードは、複数のプロセスと、個々のプロセスにより実行されるコードセグメントと、を含み、いずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときに、システムコードにおいて動作する各々のプロセスのプロセス識別子を含む。

【0088】

システムコードにおいて、複数のプロセスを有してもよく、プロセスは、プログラムの一回の実行過程であり、実行可能なプログラムが動作するとプロセスになる。プロセスは、動作環境においてコードを実行することができる。システムコードにおいて、複数のプロセスのうちの個々のプロセスにより実行されるコードセグメントが含まれ、コードセグメントは、システムコードにおけるプロセスで実行される一部のシステムコードである。具体的に、システムコードをコンパイルされた後に動作させる場合、該システムコードは、複数のプロセス実例として動作させることができ、個々のプロセス実例は、対応するコードセグメントを実行する。

【0089】

無応答現象は、目標アプリケーションを動作させる過程において生じるものであり、目標アプリケーションの動作は、オペレーティングシステムのシステムコードを呼び出し得る。システムコードにおいて含まれる各々のプロセスを動作させることにより、対応するコードセグメントを実行することができる。従って、現場情報は、動作するプロセスに対応するプロセス識別子を含んでもよい。プロセス識別子は、プロセスをマークすることに用いられる情報であり、該プロセス識別子は、プロセス名称、又はプロセス名称のキーワード等であってもよい。

【0090】

上記の内容に基づいて、共通性分析は、現場情報において含まれるプロセス識別子に基づいて行われてもよい。Ｓ４０２の選択可能な実現形態は、以下のとおりであってもよい。各種類の無応答現象の現場情報のうちのいずれかの現場情報に対して、いずれかの現場情報における各々のプロセス識別子をトラバースし、いずれかの現場情報以外の各々の現場情報において、現在トラバースされているプロセス識別子を探し、現在トラバースされているプロセス識別子を見つけ出した場合に、現在トラバースされているプロセス識別子を共通性分析結果内に追加し、現在トラバースされているプロセス識別子を見つけ出さなかった場合に、いずれかの現場情報における各々のプロセス識別子をトラバースし続ける。

【0091】

いずれかの現場情報とは、取得された各種類の無応答現象の現場情報のうちのいずれか一種類の無応答現象の現場情報を指す。いずれかの現場情報における各々のプロセス識別子をトラバースすることができるため、トラバースの過程において、現在でトラバースされているプロセス識別子に対して、他の無応答現象における現場情報において現在トラバースされているプロセス識別子を探すことができる。現在トラバースされているプロセス識別子は、いずれかの現場情報においてトラバースされているプロセス識別子である。現在トラバースされているプロセス識別子を見つけ出した場合に、他の現場情報において、現在トラバースされているプロセス識別子と同じプロセス識別子が存在することを意味する。該プロセス識別子に対応するプロセスは、他の無応答現象が生じるときに同様に動作し、見つけ出した現在トラバースされているプロセス識別子は、各種類の無応答現象の共通するプロセス識別子であり、現在トラバースされているプロセス識別子を共通性分析結果に追加することができる。現在トラバースされているプロセス識別子を見つけ出さなかった場合に、他の現場情報において、現在トラバースされているプロセス識別子と同じプロセス識別子が存在しないことを意味し、更に、いずれか一種類の無応答現場情報における各々の他のプロセス識別子をトラバースし続けることができる。

【0092】

例を挙げると、取得された複数の種類の無応答現象の現場情報は、４種の無応答現象の現場情報を含み、４種の無応答現象の現場情報は、それぞれ、Ａ類無応答現象のａ現場情報、Ｂ類無応答現象のｂ現場情報、Ｃ類無応答現象のｃ現場情報、及びＤ類無応答現象のｄ現場情報である。現場情報において含まれるプロセス識別子がプロセス名であると仮定すると、現在ａ現場情報におけるプロセス名ｇａｍｅをトラバースしており、ｂ現場情報、ｃ現場情報、及びｄ現場情報において探すことができ、ｂ現場情報、ｃ現場情報、及びｄ現場情報の全てにおいて該プロセス名を見つけた場合、見つけ出したプロセス名を分析結果に追加することができる。理解できるように、上記の共通性分析の具体的な実現形態は、一種の選択可能な方式であり、他の方式を採用して共通性分析を行ってもよく、たとえば、スレッドに基づいて共通性分析を行ってもよいが、ここでは、限定しない。

【0093】

これから分かるように、いずれか一種類の無応答現象の現場情報におけるトラバースされているプロセス識別子を基準とし、他の各々の現場情報における同じプロセス識別子を探すことによって、システムコードにおける共通する特性の分析を実現することができる。通常、プロセス識別子は、簡潔な表現、たとえば、数字、又は簡単な文字であり、同じプロセス識別子を高効率に探すときに、共通性分析の効率を向上させることができる。

【0094】

一種の実現形態では、共通性分析結果において、各種類の無応答現象の現場情報の間で共通するプロセス識別子が含まれる。これに基づき、共通性分析結果に基づいてシステムコードから障害点を決定する方式は、下記Ｓ４０３～Ｓ４０５の実現形態を採用することができる。ここで、共通するプロセス識別子は、上記に紹介されたＳ４０２の選択可能な実現形態を採用して実現されてもよく、他の方式を採用してもよい。

【0095】

Ｓ４０３：共通性分析結果における各々のプロセス識別子に基づいてＭ個の目標プロセスを決定する。

【0096】

プロセス識別子がプロセスをマークすることに用いられるため、共通性分析結果における個々のプロセス識別子に対応するプロセスを全て目標プロセスとして決定し、それによりＭ個の目標プロセスを得ることができる。ここで、Ｍは、１より大きい正の整数であり、Ｍの数値は、共通性分析結果におけるプロセス識別子の数に等しい。例を挙げると、共通性分析結果において、ｐｒｏｃｅｓｓ１、及びｐｒｏｃｅｓｓ２の２つのプロセス識別子が含まれるので、ｐｒｏｃｅｓｓ１に対応するプロセス、及びｐｒｏｃｅｓｓ２に対応するプロセスは、いずれも目標プロセスとすることができる。このように、共通性分析結果における２つのプロセス識別子に基づいて２つの目標プロセスを決定することができる。

【0097】

Ｓ４０４：Ｍ個の目標プロセスのうちの各々の目標プロセス間の関連関係を決定し、且つシステムコードから各々の目標プロセスにより実行されるコードセグメントを取得する。

【0098】

各々の目標プロセス間の関連関係は、Ｍ個の目標プロセスのうちの少なくとも２つのプロセス間の階層関係を記述することに用いることができる。該関連関係は、親子関係、及び兄弟関係等を含むが、これらに限定されない。１つのプロセスと他の１つ又は複数のプロセスとの間に関連関係が存在することが可能であり、例えば、プロセスｐｒｏｃｅｓｓ１は、ｐｒｏｃｅｓｓ２の親プロセスであるが、ｐｒｏｃｅｓｓ１は、ｐｒｏｃｅｓｓ４の子プロセスでもあり、すなわち、ｐｒｏｃｅｓｓ１とｐｒｏｃｅｓｓ２とは、親子関係であり、且つｐｒｏｃｅｓｓ１とｐｒｏｃｅｓｓ４とも、親子関係であるが、ただし親子関係においてプロセスｐｒｏｃｅｓｓ１が果たす役割は異なる。

【0099】

１つの実施例において、Ｍ個の目標プロセスは、第１プロセス、及び第２プロセス、すなわち、２つの目標プロセスを含む。第１プロセス、及び第２プロセスは、各種類の無応答現象が生じるときの共通のプロセスであり、具体的に、無応答現象が生じる前に全て動作し得るプロセスを指す。

【0100】

Ｍ個の目標プロセスのうちの各々の目標プロセス間の関連関係を決定する具体的な実現形態は、下記の内容を含んでもよい。各種類の無応答現象の現場情報から、第１プロセスの属性情報、及び第２プロセスの属性情報を取得し、いずれかのプロセスの属性情報は、いずれかのプロセスのプロセス番号、及びいずれかのプロセスを呼び出すプロセスのプロセス番号を含み、第２プロセスの属性情報において第１プロセスのプロセス番号が含まれる場合、又は第１プロセスの属性情報において第２プロセスのプロセス番号が含まれる場合に、第１プロセスと第２プロセスとの間の関連関係が親子関係であると決定する。

【0101】

いずれか一種類の無応答現象の現場情報において、該種類の無応答現象が生じるときに、システムコードにおいて動作するプロセスに対応する属性情報を含んでもよい。各種類の無応答現象の現場情報から、共通性分析結果におけるプロセス識別子と対応するプロセス（すなわち、目標プロセス）の属性情報を取得することができる。ここでは、目標プロセスは、第１プロセスと、第２プロセスと、を含み、現場情報から取得されたプロセスの属性情報は、具体的に、第１プロセスの属性情報、及び第２プロセスの属性情報を含む。プロセスの属性情報は、プロセスの特徴を記述することに用いられる情報であり、いずれかのプロセスの属性情報は、該プロセスのプロセス番号、及びいずれかのプロセスを呼び出すプロセスのプロセス番号を含む。たとえば、いずれかのプロセスがプロセスＡであり、プロセスＢがプロセスＡを呼び出す場合に、プロセスＡの属性情報は、プロセスＡのプロセス番号（すなわち、いずれかのプロセスのプロセス番号）、及びプロセスＢのプロセス番号（すなわち、いずれかのプロセスを呼び出すプロセスのプロセス番号）を含むことができる。属性情報によって、プロセス自体のプロセス番号、及び具体的にどのプロセスが現在のプロセスを呼び出すかを知ることができる。プロセス番号（ｐｒｏｃｅｓｓＩｄｅｎｔｉｆｉｃａｔｉｏｎ、ＰＩＤ）は、オペレーティングシステムがプロセスを作成するときに、プロセスに割り当てた唯一の識別番号であってもよく、プロセス番号は、自然数、たとえば、１２３、及び６０５によって表されてもよく、二進数、たとえば、００１、及び０１０によって表されてもよく、ここでは、プロセス番号の表現は、限定されない。

【0102】

第１プロセスの属性情報は、第１プロセスのプロセス番号、及び第１プロセスを呼び出すプロセスのプロセス番号を含み、第２プロセスの属性情報は、第２プロセスのプロセス番号、及び第２プロセスを呼び出すプロセスのプロセス番号を含む。続いて、いずれかのプロセスの属性情報を選択して分析することができ、具体的に、下記のいくつかの状況を含む。

【0103】

（１）第２プロセスの属性情報において第１プロセスのプロセス番号が含まれる場合、第２プロセスの属性情報における第２プロセスを呼び出すプロセスのプロセス番号が第１プロセスのプロセス番号であることを意味する。すなわち、第２プロセスが第１プロセスに呼び出され、或いは第１プロセスが第２プロセスを呼び出す。この場合に、第１プロセスと第２プロセスとの間の関連関係が親子関係であり、且つ第１プロセスが第２プロセスの親プロセスであり、第２プロセスが第１プロセスの子プロセスであると決定することができる。

【0104】

（２）第１プロセスの属性情報において第２プロセスのプロセス番号が含まれる場合、第１プロセスの属性情報における第１プロセスを呼び出すプロセスのプロセス番号が該第２プロセスのプロセス番号であることを意味する。すなわち、第１プロセスが第２プロセスに呼び出され、或いは第２プロセスが第１プロセスを呼び出す。この場合に、第１プロセスと第２プロセスとの間の関連関係が親子関係であり、且つ第１プロセスが第２プロセスの子プロセスであり、第２プロセスが第１プロセスの親プロセスであると決定することもできる。

【0105】

例示的に、前述した図３ｂに示すように、クラウドゲームＡＮＲの現場について、各種類の無応答に全て該現場が生じることになり、且つ現場情報が収集される。従って、共通性分析結果において、図３ｂに示されるプロセスの関連する内容が含まれてもよい。図３ｂから明らかなように、オペレーティングシステムは、２つのｓｇａｍｅプロセスを同時に有し、それぞれ、プロセス番号が１９１０のプロセス、及びプロセス番号が４６９７のプロセスである。プロセス番号に基づき、２番目のプロセス（すなわち、プロセス番号が４６９７のプロセス）の親プロセス番号が１９１０であり、つまり、１番目のｓｇａｍｅプロセスであることを発見することができる。これから分かるように、この２つのプロセスの間は、親子関係であり、且つ２番目のプロセスは、１番目のプロセスの子プロセスであり、１番目のプロセスは、プロセス番号が１１０のプロセスの子プロセスである。

【0106】

（３）第２プロセスの属性情報において第１プロセスのプロセス番号が含まれず、第１プロセスの属性情報にも第２プロセスのプロセス番号が含まれない場合、第２プロセスを呼び出すプロセスが第１プロセスではなく、他のプロセスであり、第１プロセスを呼び出すプロセスも第２プロセスではなく、別のプロセスであることを意味する。この場合に、第１プロセスと第２プロセスとの間の関連関係は、親子関係ではなく、他の関係、たとえば、兄弟関係であると決定することができ、すなわち、第１プロセスと第２プロセスとは、みなある同じプロセスの子プロセスである。例を挙げると、プロセス番号が１９１０の第１プロセス、及びプロセス番号が４９０６の第２プロセスは、みなｓｇａｍｅプロセスである。しかし、第１プロセス、及び第２プロセスの親プロセス番号は、みな１１０であると仮定すると、つまり、第１プロセス、及び第２プロセスは、みなプロセス番号が１１０のプロセスの子プロセスである。この２つのプロセスが兄弟関係であると判断できる。

【0107】

これから分かるように、プロセスの属性情報において含まれるプロセス自体のプロセス番号、及び該プロセスを呼び出すプロセスのプロセス番号によって、他のプロセスのプロセス番号との間の関係を決定することができ、それにより、プロセス間の関連関係を非常に容易に決定することができる。

【0108】

プロセスが動作するときに、システムコードにおける対応するコードセグメントを実行し得るため、システムコードから各々の目標プロセスにより実行されるコードセグメントを取得することができる。目標プロセスがＭ個あるため、具体的に、Ｍ個のコードセグメントを取得することができ、その後に各々のコードセグメントから無応答現象が生じる障害点を容易に決定する。具体的に、下記のＳ４０５を参照できる。

【0109】

Ｓ４０５：関連関係に基づいて、取得されたＭ個のコードセグメントから、無応答現象が生じる障害点を決定する。

【0110】

Ｍ個のコードセグメントのうちの個々のコードセグメントは、Ｍ個のプロセスのうちの対応するプロセスにより実行される。Ｍ個の目標プロセスのうちの各々のプロセス間の関連関係によって、取得されたＭ個のコードセグメントから、無応答現象が生じる障害点を決定することができる。該障害点は、Ｍ個のコードセグメントのうちのあるコードセグメントにおける１つのコード文、又はコードのピースであってもよい。コードセグメントが、各種類の無応答現象が発生するときに全て実行され得るものであるため、該障害点は、各種類の無応答現象に対して共通する障害点であり、該障害点が存在するため、いずれか一種類の無応答現象は、全てトリガーされる可能性がある。具体的にどの無応答現象がトリガーされるかについては、他の情報、例えば、プロセスが実行するイベント型と結合して判断することができ、たとえば、プロセスが入力配信イベントを実行する場合、入力配信タイムアウトのＡＮＲであると判定することができる。

【0111】

上記のＳ４０３～Ｓ４０５のステップでは、共通性分析結果において含まれるプロセス識別子によって目標プロセスを決定することができ、更に、各々の目標プロセス間の関連関係を決定し、システムコードから、各々の目標プロセスにより実行されるコードセグメントを取得し、且つ関連関係、及び取得されたコードセグメントに基づいて、無応答現象が生じる障害点を分析して得ることができる。この方式は、最下層のオペレーティングシステムのシステムコードから始め、各種類の無応答現象に対して共通性分析を行った後に、共通性分析結果を、各種類の無応答現象が生じるときに全て実行されるシステムコードを決定することに用いて、システムコードから障害点を決定し、更に、システムレベルから、ＡＮＲを引き起こす共通の原因を決定することができることにより、根本的に修復してＡＮＲの問題を解決する。

【0112】

Ｓ４０６：障害点に基づきシステムコードを修復処理することにより、修復後のシステムコードに基づいて目標アプリケーションを動作させる。

【0113】

本願の実施例により提供されるスキームは、取得された複数の種類の無応答現象の現場情報に対して共通性分析を行い、目標アプリケーションに無応答現象が発生するときに動作する共通のプロセス（たとえば、共通するプロセス識別子に対応するプロセス）を探すことができる。これらの共通のプロセスは、目標プロセスとして更に分析でき、具体的に、オペレーティングシステムのシステムコードに回帰し、関連関係、及び目標プロセスにより実行されるコードセグメントに基づいて無応答現象が生じる障害点を決定するようにしてもよい。該障害点は、具体的に、目標プロセスにより実行されるコードセグメントから決定されるものであり、このように、システムの最下層から、アプリケーション無応答現象が生じる根本的な原因を決定することにより、アプリケーション無応答の問題を根本的に解決することができる。障害点に基づいてシステムコードを修復した後に、修復後のシステムコードは、目標アプリケーションの動作過程における無応答現象が生じる状況を効果的に減少し、アプリケーション動作、及びシステムの全体の安定性を向上させることができる。

【0114】

図５に参照されるように、図５は、本願の実施例が提供するさらに別のデータ処理方法のフローチャートであり、該データ処理方法は、Ｓ５０１～Ｓ５０７を含んでもよい。

【0115】

Ｓ５０１：目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得する。

【0116】

Ｓ５０２：各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得る。

【0117】

Ｓ５０３：共通性分析結果における各々のプロセス識別子に基づいてＭ個の目標プロセスを決定する。

【0118】

Ｓ５０４：Ｍ個の目標プロセスのうちの各々の目標プロセス間の関連関係を決定し、且つシステムコードから各々の目標プロセスにより実行されるコードセグメントを取得する。

【0119】

Ｓ５０５：関連関係に基づいて、取得されたＭ個のコードセグメントから、無応答現象が生じる障害点を決定する。

【0120】

１つの実施例において、Ｍ個の目標プロセスは、第１プロセスと、第２プロセスと、を含み、且つ第１プロセスと第２プロセスとの間の関連関係が親子関係である。ここで、第１プロセスは、第２プロセスの親プロセスである。第２プロセスは、第１プロセスの子プロセスである。第１プロセスと第２プロセスとの間の関連関係の決定に対して、上記実施例において紹介された、プロセスの属性情報において含まれるプロセス番号に基づき関連関係を決定することを採用することができる。

【0121】

図４の対応する実施例における関連部分に基づいて紹介された内容に基づき、Ｓ５０５の具体的な実現形態は、以下の内容を含んでもよい。親子関係に基づいて、取得された第１プロセスにより実行されるコードセグメントを基準コードセグメントとして決定し、且つ基準コードセグメントから第１コード文を決定する。第１コード文とは、無応答現象が発生する前に、第１プロセスにより実行されるコード文を指し、第１コード文が関数呼び出し操作を実現することに用いられる文であるときに、第１プロセスが実行するコードセグメントにおいて第１コード文に沿って第１プロセスの呼び出しスタックを分析して得る。呼び出しスタックは、第１プロセスが呼び出す各種類の関数を含み、呼び出しスタックにおいて呼び出しに失敗した目標関数が存在する場合に、基準コードセグメントから目標関数のロジックコードを決定し、第２プロセスにより実行されるコードセグメントに基づいて、目標関数のロジックコードから、無応答現象が生じる障害点を決定する。

【0122】

第１プロセスにより実行されるコードセグメントにおいて非常に多くのコード文が含まれており、無応答現象が発生する時点の前に、第１プロセスは、コードセグメントにおける一部のコード文を実行して実行を停止する可能性がある。第２プロセスも同様の原理である。第１プロセスと第２プロセスとの間が親子関係であり、第１プロセスが親プロセスとされ、それにより実行されるコードに第２プロセスを作成するコードが存在する可能性があるため、まず、第１プロセスにより実行されるコードセグメントを基準コードセグメントとして決定して分析することができる。基準コードセグメントは、分析基準とすることに用いられるコードセグメントである。基準コードセグメントから第１コード文を決定することができ、該第１コード文は、無応答現象が発生する前に、第１プロセスにより実行されるコード文である。第１コード文を判断し、分析条件を満たすか否かを決定し、より更なる分析を実行することができる。具体的に以下のとおりである。

【0123】

（１）第１コード文が関数呼び出し操作を実現することに用いられる文であるときに、第１プロセスが実行するコードセグメントにおいて第１コード文に沿って第１プロセスの呼び出しスタックを分析して得ることができる。

【0124】

第１コード文に基づいて、関連する実行可能なプログラム、又はシステムコマンドを呼び出して、関数呼び出し操作を実現することができる。例示的に、親プロセスとされる第１プロセスが実行する第１コードは、具体的に、Ｒｕｎｔｉｍｅ．ｇｅｔＲｕｎｔｉｍｅ（）．ｅｘｅｃ（「ｘｘｘ．ｅｘｅ」）を実行する文であってもよい。ここで、Ｒｕｎｔｉｍｅ．ｇｅｔＲｕｎｔｉｍｅ（）．ｅｘｅｃ（）は、外部の実行可能なプログラム、又はシステムコマンドを呼び出すことに用いられる。Ｒｕｎｔｉｍｅ．ｇｅｔＲｕｎｔｉｍｅ（）は、現在のアプリケーションプログラムのＲｕｎｔｉｍｅオブジェクトを返し、該オブジェクトのｅｘｅｃ（）方法は、１つの子プロセスを作成し、指定された実行可能なプログラム（ここでは、すなわち名称が「ｘｘｘ．ｅｘｅ」である実行可能なプログラムである。「ｘｘｘ．ｅｘｅ」は、実行されようとするプログラム名を表す）を実行し、且つ該子プロセスに対応するＰｒｏｃｅｓｓオブジェクトの実例を返すことを指示し、Ｐｒｏｃｅｓｓによって、該子プロセスの実行を制御し、又は該子プロセスの情報を取得することができる。

【0125】

ＡＮＲが発生する前に親プロセスが実行する最後のコード文は、第１コード文であり、第１コード文を更に分析することができる。第１プロセスにより実行されるコードセグメントにおいて、第１コード文に沿って第１プロセスの呼び出しスタックを分析して得ることができ、該呼び出しスタックは、第１プロセスが呼び出す各種類の関数を含む。呼び出しスタックに対する分析は、第１プロセスが実行するコードセグメントの型に基づき、相応なデバッグツールを採用することができ、たとえば、第１プロセスが実行するコードセグメントがＪａｖａコードであれば、ｐｒｉｎｔＳｔａｃｋＴｒａｃｅ（コマンドラインに、プログラムにおける異常情報のエラーが出る位置、及び原因を印刷するデバッグツール）を使用することができ、第１プロセスが実行するコードセグメントがＮａｔｉｖｅＣコードであれば、ｓｔｒａｃｅ（プロセスにより実行されるシステム呼び出し、且つプロセスにより受信される信号を阻止し、且つ記録するためのデバッグツール）を使用することができる。これらのデバッグツールは、みな相応なプロセスの呼び出しスタックを分析して得ることができる。呼び出しスタックは、インタープリター（例えば、ブラウザにおけるＪａｖａＳｃｒｉｐｔインタープリター）が関数の実行フローを追跡する一種のメカニズムとして理解されてもよく、このメカニズムによって、どの関数が実行されているか、及び実行される関数体においてどの関数が呼び出されるかを知ることができる。

【0126】

以下では、クラウドゲームシーンにおいてＡＮＲが発生することを例にして、クラウドゲームプラットフォームにおけるＡＮＲの現場情報に基づき分析をすると、操作システムは２つのｓｇａｍｅプロセスを同時に有し、且つこの２つのプロセスが親子関係であることを決定し、デバッグツールによって、現場の呼び出しスタックをキャプチャーし、呼び出しスタックによって、親プロセスがＡＮＲの前にＲｕｎｔｉｍｅ．ｇｅｔＲｕｎｔｉｍｅ（）．ｅｘｅｃ（）の文を実行する（すなわち、第１コード文を実行する）と決定し、Ｒｕｎｔｉｍｅ．ｇｅｔＲｕｎｔｉｍｅ（）．ｅｘｅｃ（）に沿って、親プロセスの呼び出しスタックが図６ａに示されることを発見できる。具体的に、Ｒｕｎｔｉｍｅクラスは、ｅｘｅｃ方法を呼び出し、ｅｘｅｃ方法によってＰｒｏｃｅｓｓＢｕｉｌｄｅｒクラスを作成し、且つＰｒｏｃｅｓｓＢｕｉｌｄｅｒ．ｓｔａｒｔ（）方法によってＰｒｏｃｅｓｓＩｍｐｌクラスを作成する。次に、ｓｔａｒｔ（）方法を使用してＵｎｉｘ（登録商標）プロセスを作成し、ｎｅｗＵｎｉｘｐｒｏｃｅｓｓによってＵｎｉｘプロセスオブジェクトを作成する。さらに、Ｕｎｉｘプロセスオブジェクトに基づいて１つの新しいプロセスをｆｏｒｋし、新しいプロセスは、Ｕｎｉｘプロセスと異なるプログラムコードを実行して、ＵｎｉｘＰｒｏｃｅｓｓ＿ｍｄ．ｃを得る。次に、ＵＮＩＸ（登録商標）プロセスに基づいて１つの新しいプロセスをｆｏｒｋし、且つＵＮＩＸプロセスと異なるプログラムコードを実行し、最後に、ｓｔａｒｔＣｈｉｌｄ関数を呼び出す。上記は、すなわち、親プロセスの呼び出しスタックであり、親プロセスの呼び出しスタックにおける最後の関数呼び出しのｓｔａｒｔＣｈｉｌｄ関数は、プログラムのエラーが出る大まかな位置である。

【0127】

呼び出しスタックにおいて呼び出しに失敗した目標関数が存在する場合、第１プロセスが実行するコードセグメントにおいてエラーが出ることを意味する。また、エラーが出る位置は、目標関数の箇所であり、例えば、上記図６ａに示される親プロセスの呼び出しスタックにおける関数呼び出しは、ｓｔａｒｔＣｈｉｌｄ関数までしか表示されない。これは、第１プロセスが、ｓｔａｒｔＣｈｉｌｄ関数が呼び出されることを実行するときに、プログラムがクラッシュすることを意味する。従って、更に目標関数を分析することができる。第１プロセスにより実行されるコードセグメントから目標関数のロジックコードを決定し、該ロジックコードは、第１プロセスにより実行されるコードセグメントにおける一部のコードであり、第２プロセスにより実行されるコードセグメントに基づいて、目標関数に対応するロジックコードから、無応答現象が生じる障害点を決定する。このときに、障害点は、具体的に、目標関数に対応するロジックコードにおけるコード文である。

【0128】

（２）第１コード文が関数呼び出し操作を実現することに用いられる文ではないときに、たとえば、第１コード文が他のコード文であるときに、該コード文の実行状況に基づきそれに関連するコード文を分析することができる。

【0129】

これから分かるように、親子関係を備えるプロセスにより実行されるコードセグメントを分析する、具体的に、親プロセスの第１プロセスの呼び出しスタックを分析することによって、親プロセスによるコードセグメントに対する実際の実行状況を大まかに知ることができる。それにより、実際の実行状況に基づいて、実行がクラッシュした目標関数のロジックコードから、無応答現象が生じる障害点を具体的に位置決めすることを決定することができ、位置決めの範囲を更に狭める。

【0130】

一種の実現形態では、目標関数のロジックコードにおいてプロセス作成文が含まれ、該プロセス作成文は、子プロセスを作成することに用いられる文であり、且つプロセス作成文によって作成された子プロセスと相応な親プロセスとの間で、同一のアドレス空間を共有する。

【0131】

例示的に、図６ａの親プロセスの呼び出しスタックにおける目標関数に基づいて、図６ｂに示される目標関数のロジックコードを提供し、ここで、プロセス作成文が含まれる。目標関数は、図６ａの親プロセスの呼び出しスタックに基づいて分析して得られたｓｔａｒｔＣｈｉｌｄ関数であり、図６ｂに示されるｓｔａｒｔＣｈｉｌｄ関数の具体的なロジックは、もしＳＴＡＲＴ＿ＣＨＩＬＤがｖｆｏｒｋ（ｉｆＳＴＡＲＴ＿ＣＨＩＬＤ＿ＵＳＥ＿ＶＦＯＲＫ）を使用するなら、プロセス作成文Ｖｏｌａｔｉｌｅｐｉｄ＿ｔｒｅｓｕｌｔＰｉｄ＝ｖｆｏｒｋ（）によってプロセスを作成できるということである。この方式の採用に対する解釈は、以下の通りである。ｖｆｏｒｋに対する呼び出しを、１つの単独のｓｔａｒｔＣｈｉｌｄ関数に分離し、子スタックが親スタックを破壊するのを防止することを確実にすることができ、ｇｃｃ警告に推奨される通りである。ここで、ｇｃｃ警告は、具体的に、変数「ｆｏｏ」が「ｌｏｎｇｊｍｐ」、又は「ｖｆｏｒｋ」に破壊される可能性があることであり、ｆｏｏは、データ、機能、又はコマンドの変数を表し、ｌｏｎｇｊｍｐは、一種のジャンプ方式である。ここで、ｖｆｏｒｋは、Ｌｉｎｕｘ（登録商標）の１つのシステム呼び出しであり、それが作成したプロセスについて、親子プロセスのアドレス空間を共有する。つまり、システム呼び出しｖｆｏｒｋによって作成された子プロセスとそれに対応する親プロセスとの間で、同一のアドレス空間を共有する。このように、子プロセスは、完全に親プロセスのアドレス空間において動作し、子プロセスがある変数を修正する場合、親プロセスに直接影響を与え得る。

【0132】

親子関係を備える第１プロセス、及び第２プロセスに対して、第２プロセスは、第１プロセスの子プロセスであり、すなわち、第１プロセスは、親プロセスであり、第２プロセスは、子プロセスである。第１プロセスは、目標関数におけるプロセス作成文を実行することによって第２プロセスを作成することができ、このように、第１プロセスと第２プロセスとの間で、同一のアドレス空間を共有する。ここで、アドレス空間は、すべての利用可能なリソースの集合であり、ここでは、共有されるアドレス空間は、物理アドレス空間、又は仮想アドレス空間であってもよい。

【0133】

第２プロセスにより実行されるコードセグメントに基づいて、目標関数のロジックコードから、無応答現象が生じる障害点を決定する実現形態は、以下の内容を含んでもよい。第２プロセスが実行するコードセグメントから第２コード文を決定し、第２コード文がデータ読み取り操作を実現することに用いられる文であるときに、第２コード文に基づき、第２プロセスが読み取る必要がある目標リソースを決定する。第１プロセスが目標リソースを持っている場合に、目標関数のロジックコードにおけるプロセス作成文を、無応答現象が生じる障害点として決定し、ここで、第２プロセスは、第１プロセスの子プロセスである。第１プロセスが目標リソースを持っている場合に、第２プロセスは、ブロックされ、且つ第２プロセスがブロックされる継続時間が継続時間の閾値より大きいときに、無応答現象がトリガーされる。

【0134】

まず、第２プロセスが実行するコードセグメントから第２コード文を決定することができる。該第２コード文とは、無応答現象が発生する前に、第２プロセスにより実行されるコード文を指す。ＡＮＲが発生する前に、第２プロセスが対応するコードセグメントにおける複数のコード文を実行する可能性があり、幾つかのコード文がその後の分析方式を採用して分析することに適合しない可能性があるため、第２コード文を判断し、該コード文が分析条件に合致するか否かを決定することができる。具体的に以下のとおりである。

【0135】

（１）第２コード文がデータ読み取り操作を実現することに用いられる文であるときに、第２コード文が分析条件に合致して、第２コード文を更に分析できることを意味する。第２コード文がデータ読み取り操作を実行するときに、読み取られたデータをロックする可能性がある、すなわち、他のプロセスが該データにアクセスすることができず、第２プロセスがデータ読み取り操作を実行することに必要な目標リソースを決定することができる。該データ読み取り操作の文は、たとえば、ファイルリソースを読み取るコード文であってもよく、例示的に、第２プロセスは、ｒｅａｄｄｉｒ（）関数を実行することにより、／ｐｒｏｃ／ｓｅｌｆ／ｆｄを読み取る。ここで、ｒｅａｄｄｉｒ（）は、常にフォルダにおけるファイルをトラバースすることに用いられ、／ｐｒｏｃ／ｓｅｌｆ／ｆｄは、現在のプロセスディレクトリーにおけるファイル記述子を表す。

【0136】

第２プロセスがデータの読み取り操作を実行することに必要な目標リソースは、アドレス空間における利用可能なリソース、たとえば、ＣＰＵ、及び内部メモリ等のハードウェアリソースであってもよい。第１プロセスが目標リソースを持っている場合、第１プロセスが、第２プロセスがデータを読み取ることに必要な目標リソースを持っていることを意味する。第１プロセスと第２プロセスとの間のアドレス空間が共有されるため、第２プロセスがブロックされるようになり、且つ第１プロセスによる該目標リソースのリリースをウェイトする。第２プロセスがブロックされる継続時間が継続時間の閾値より大きいときに、たとえば、第２プロセスがブロックされる継続時間が１０ｓであり、継続時間の閾値が８ｓであり、ブロックされる継続時間が継続時間の閾値より大きいときに、無応答現象が生じ得る。上記分析に基づけば、これはプロセスの作成方式により引き起こされるため、従って目標関数のロジックコードにおけるプロセス作成文を、無応答現象が生じる障害点として決定することができる。逆に、第１プロセスが目標リソースを持っていない場合、第２プロセスが目標リソースを使用できることを意味し、それならば無応答現象が生じることがない。

【0137】

（２）第２コード文がデータ読み取り操作を実現することに用いられる文ではないときに、該第２コード文により指示される具体的な内容に基づき、他の内容を分析することができる。

【0138】

これから分かるように、目標関数に対する分析は、第２プロセスが実行するコードセグメントと結合して実現される。第２プロセスが実行するコードセグメントについて、データ読み取り操作の文が存在するため、第１プロセスがデータ読み取り操作に必要な目標リソースを持っているときに、２つのプロセス間のアドレス空間が共有されることにより、目標アプリケーションの無応答現象がトリガーされるようになる。このロジックに基づいて、無応答現象が生じることが目標関数のロジックコードにおけるプロセス作成文により引き起こされることを決定することができ、更に、それを障害点として決定することができる。

【0139】

無応答現象が生じる障害点の決定方式に対する上記の紹介に基づき、障害点が第１プロセスにより実行されるコードセグメントの目標関数、具体的に、目標関数におけるプロセス作成文を含むことを明確にすることができる。従って、オペレーティングシステムにおいて目標関数の実現を修正することができる。１つの実施例において、障害点に基づきシステムコードを修復する方式は、以下のＳ５０６～Ｓ５０７で紹介される内容を採用することができる。

【0140】

Ｓ５０６：子プロセスを作成することに用いられる目標文を決定する。

【0141】

子プロセスを作成する目標文は、プロセス作成文と異なるコード文であり、プロセス作成文と同様の機能を有する、すなわち、全て子プロセスを作成できるが、目標文により作成される子プロセスと相応な親プロセスとは、異なるアドレス空間を独立して使用する。相応な親プロセスは、目標文により作成される子プロセスを呼び出すプロセスであり、子プロセスと相応な親プロセスとの間のアドレス空間は、共有されない。このように、子プロセスがデータ読み取り操作を実行するときに、第１プロセスが必要な目標リソースを持つことがなく、独立したアドレス空間にあることにより、アプリケーションの無応答現象が生じることを効果的に回避することができる。

【0142】

１つの実施例において、プロセス作成文において関数フィールドが含まれ、且つ関数フィールドに第１システム呼び出し関数が記憶され、プロセス作成文は、第１システム呼び出し関数によって子プロセスを作成する。プロセス作成文において含まれる関数フィールドは、第１システム呼び出し関数を記憶することができ、該第１システム呼び出し関数は、オペレーティングシステムにより提供されてもよい。オペレーティングシステムのシステムコードにおいて、プロセス作成文は、第１システム呼び出し関数によって子プロセスを作成することができる。例を挙げると、前述したプロセス作成文Ｖｏｌａｔｉｌｅｐｉｄ＿ｔｒｅｓｕｌｔＰｉｄ＝ｖｆｏｒｋ（）の通りであり、ここで、関数フィールドは、ｒｅｓｕｌｔＰｉｄであり、ｖｆｏｒｋ（）は、第１システム呼び出し関数である。

【0143】

上記の内容に基づいて、Ｓ５０６の具体的な実現内容は、プロセス作成文における関数フィールドにおける第１システム呼び出し関数を、第２システム呼び出し関数に修正し、子プロセスを作成することに用いられる目標文を得るステップであって、ここで、目標文は、第２システム呼び出し関数によって子プロセスを作成する、ステップを含む。

【0144】

第２システム呼び出し関数は、第１システム呼び出し関数と異なるシステム呼び出し関数であり、それもオペレーティングシステムにより提供される。第２システム呼び出し関数において、第２システム呼び出し関数によって作成された子プロセスと、対応する親プロセスとの間のアドレス空間は、相互に独立するものである。システム呼び出し関数が、オペレーティングシステムが提供する一種のカーネル関数であるため、システム呼び出し関数に対する修正は、カーネルのレベルから実行される修正である。このように、システムカーネルのレベルから、オペレーティングシステムにおけるＡＮＲの問題を解決することができ、プラットフォームの互換性、及び安定性を向上させ、ＡＮＲ現象を効果的に予防し、且つ避けることができる。

【0145】

Ｓ５０７：システムコードにおいて目標文を採用してプロセス作成文を置き換えることにより、システムコードを修復する。

【0146】

目標文を決定した後に、元のシステムコードにおけるプロセス作成文を目標文に置き換えることができる。このように、第１システム呼び出し関数を無効にし、第２システム呼び出し関数に変え、カーネルのレベルからシステムコードの修復を実現することができ、第１プロセスが親プロセスであり、第２プロセスが子プロセスである状況において、目標文によって作成された第２プロセスと第１プロセスとが異なるアドレス空間を独立して使用するため、修復後のシステムコードに基づいて目標アプリケーションを動作させるときに、順調に目標リソースを利用してデータ読み取り操作を行うことができ、ブロックが発生することがなく、それにより、無応答現象の発生を回避する。

【0147】

例を挙げると、プロセスコード作成文Ｖｏｌａｔｉｌｅｐｉｄ＿ｔｒｅｓｕｌｔＰｉｄ＝ｖｆｏｒｋ（）は、目標文Ｖｏｌａｔｉｌｅｐｉｄ＿ｔｒｅｓｕｌｔＰｉｄ＝ｆｏｒｋ（）に修正でき、ｉｆＳＴＡＲＴ＿ＣＨＩＬＤ＿ＵＳＥ＿ＶＦＯＲＫも、ｉｆＳＴＡＲＴ＿ＣＨＩＬＤ＿ＵＳＥ＿ＦＯＲＫに修正できる。それにより、ｖｆｏｒｋ（）を無効にし、ｆｏｒｋ（）の方式に変えることを実現する。

【0148】

理解できるように、オペレーティングシステムの完全性に鑑みて、目標関数におけるプロセスコード作成文に対する修正は、オペレーティングシステムのシステムコードにおける目標関数以外の他の一部のコードに影響を与え得る可能性がある。従って、システムコードの他の内容に対して、適応的に修正することもできることにより、上記の具体的な修復内容に適合させることができる。上記の方式によって、システムコードを修復し、且つ修復後のシステムコードを得て、修復後のシステムコードに基づいて目標アプリケーションを動作させることができる。

【0149】

これから分かるように、オペレーティングシステムのシステムコードに対する修復内容は、システムコードに対してカスタマイズされた修正内容であり、該修正内容は、カーネルのシステム呼び出しに対する変更に関し、カーネル側、及びシステム側から、ＡＮＲが発生する可能性のある状況を阻止し、且つＡＮＲが発生する可能性のあるほとんどのシーンに対処することを実現することができる。この他、修正内容は、特定のプラットフォームに強く縛られるポリシーがなく、ハードコーディングされた部分もない。従って、機器、又はプラットフォーム自体との緩い結合を実現することができる。それにより、修復後のオペレーティングシステムを任意のシーンにおいて、たとえば、クラウドゲーム、実際の端末機器、又はシミュレーター等に応用することができ、アプリケーション無応答現象を効果的に避け、プラットフォーム、又は機器の安定性、及び互換性を向上させることができる。

【0150】

一種の実現形態では、カスタマイズして修正されたシステムコードに対して、修復後のシステムコードに対して品質検査を行ってもよい。該品質検査は、コードレビュー、及びシステムコード作り過程における安全性検出を含む。コード作り過程において、安全性検査を行うと、カスタマイズされたシステムコードにおいて存在する安全性の問題を発見し、修復後のシステムコードの安全性を確実することができる。コードレビュー（ＣｏｄｅＲｅｖｉｅｗ）は、コード再チェックとも呼ばれ、ここでは、コードを閲覧することによって、ソースコードとコーディング標準との合致性、及びコード品質を検査する操作を指す。コードレビューによって、コード品質を高め、潜在的なエラー（ｂｕｇ）等を探し出すことができる。安全性検査、及びコードレビューに対して、いずれも相応な分析ツールを利用して実行することができる。このように、各項のデータが期待の状況に合致するのを確実にすることができ、且つオペレーティングシステムの互換性、及び安定性を確実にする前提において、アプリケーション無応答の問題を解決する。

【0151】

上記修復スキームによって処理を行い、クラウドゲームシーンにおいて、修復後のコードを動作させることに基づいてクラウドゲームを動作させるテスト過程、及び実際のオンラインサービス過程において、クラウドゲームプラットフォームに、いずれもＡＮＲの状況が現れないことにより、ＡＮＲが発生する頻度を減少させることができる。理解できるように、クラウドゲームプラットフォームはオペレーティングシステムであり、システム側に属し、システムにおいて他の多くのゲームＡＰＰ、及び他のＡＰＰを動作し得るため、少数のＡＮＲ現象が存在し得る可能性があるが、確率が極めて低い。

【0152】

本願の実施例により提供されるデータ処理スキームは、目標アプリケーションの複数の種類の無応答現象の現場情報を取得して収集することができる。現場情報は、該無応答現象が対応して発生するときのシステムコードの実行状況を記述することに用いられるため、複数の種類のＡＮＲの現場情報に対して共通性分析を行うことによって、オペレーティングシステムのレベルからシステムコードの実行状況を分析し、最下層から各種類の無応答現象が生じる共通特性を探し、共通性分析結果を得ることができる。ここで、共通性分析結果は、共通するプロセス識別子を含み、共通するプロセス識別子に基づいて共通する複数の目標プロセスを決定し、且つ各々の目標プロセスが実行するコードセグメントを分析する。具体的に、呼び出しスタックによって、プロセスがコードセグメントを実行する状況を追跡することができ、呼び出しスタック、及び他のコードセグメントの実行ロジックに基づいて、より具体的な障害点を決定する。この過程において、各種類のデバッグツールを利用して、問題を追跡、及びデバッグすることで障害点を決定することができる。障害点に基づいて、オペレーティングシステムに対してカスタマイズされた変更を行うことができ、具体的に、カーネルレベルから、プロセスを作成するときに呼び出されたシステム関数を修正することができる。それにより、アプリケーション無応答現象の発生を効果的に解決し、システムカーネルのレベルに対して修復することでオペレーティングシステムのアプリケーション無応答の問題を解決するため、互換性、及び安定性を顕著に向上させることができる。

【0153】

図７に参照されるように、図７は、本願の実施例が提供するデータ処理装置の構造模式図である。上記データ処理装置は、コンピュータ機器において動作する１つのコンピュータプログラム（プログラムコードを含む）であってもよく、たとえば、該データ処理装置は、１つのアプリケーションソフトウェアであってもよく、該データ処理装置は、本願の実施例が提供する方法における相応なステップを実行することに用いることができる。図７に示すように、該データ処理装置７００は、取得モジュール７０１、及び処理モジュール７０２の少なくとも一種を含んでもよい。

【0154】

取得モジュール７０１は、目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得することに用いられる。いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において生じるものであり、且ついずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときのシステムコードの実行状況を記述することに用いられる。

【0155】

処理モジュール７０２は、各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ共通性分析結果に基づき、システムコードから無応答現象が生じる障害点を決定することに用いられる。ここで、上記共通性分析結果は、上記各種類の無応答現象の現場情報における共通情報を含む。

【0156】

処理モジュール７０２は、障害点に基づきシステムコードを修復処理することにより、修復後のシステムコードに基づいて目標アプリケーションを動作させることに用いられる。

【0157】

１つの実施例において、システムコードは、複数のプロセスと、個々のプロセスにより実行されるコードセグメントと、を含み、いずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときに、システムコードにおいて動作する各々のプロセスのプロセス識別子を含む。処理モジュール７０２は、具体的に、各種類の無応答現象の現場情報のうちのいずれかの現場情報に対して、いずれかの現場情報における各々のプロセス識別子をトラバースすることと、いずれかの現場情報以外の各々の現場情報において、現在トラバースされているプロセス識別子を探すことと、現在トラバースされているプロセス識別子を見つけ出した場合に、現在トラバースされているプロセス識別子を共通性分析結果内に追加することと、現在トラバースされているプロセス識別子を見つけ出さなかった場合に、いずれかの現場情報における各々のプロセス識別子をトラバースし続けることと、に用いられる。

【0158】

１つの実施例において、共通性分析結果は、各種類の無応答現象の現場情報の間で共通するプロセス識別子を含み、処理モジュール７０２は、具体的に、共通性分析結果における各々のプロセス識別子に基づいてＭ個の目標プロセスを決定することであって、Ｍの数値は、共通性分析結果におけるプロセス識別子の数に等しい、ことと、Ｍ個の目標プロセスのうちの各々の目標プロセス間の関連関係を決定し、且つシステムコードから各々の目標プロセスにより実行されるコードセグメントを取得することと、関連関係に基づいて、取得されたＭ個のコードセグメントから、無応答現象が生じる障害点を決定することと、に用いられる。

【0159】

１つの実施例において、Ｍ個の目標プロセスは、第１プロセスと、第２プロセスと、を含み、処理モジュール７０２は、具体的に、各種類の無応答現象の現場情報から、第１プロセスの属性情報、及び第２プロセスの属性情報を取得することであって、いずれかのプロセスの属性情報は、いずれかのプロセスのプロセス番号、及びいずれかのプロセスを呼び出すプロセスのプロセス番号を含む、ことと、第２プロセスの属性情報において第１プロセスのプロセス番号が含まれる場合、又は第１プロセスの属性情報において第２プロセスのプロセス番号が含まれる場合に、第１プロセスと第２プロセスとの間の関連関係が親子関係であると決定することと、に用いられる。

【0160】

１つの実施例において、Ｍ個の目標プロセスは、第１プロセスと、第２プロセスと、を含み、且つ第１プロセスと第２プロセスとの間の関連関係が親子関係であり、ここで、第１プロセスは、第２プロセスの親プロセスであり、処理モジュール７０２は、具体的に、さらに、親子関係に基づいて、取得された第１プロセスにより実行されるコードセグメントを基準コードセグメントとして決定し、且つ基準コードセグメントから第１コード文を決定することであって、第１コード文とは、無応答現象が発生する前に、第１プロセスにより実行されるコード文を指す、ことと、第１コード文が関数呼び出し操作を実現することに用いられる文であるときに、第１プロセスが実行するコードセグメントにおいて第１コード文に沿って第１プロセスの呼び出しスタックを分析して得ることであって、呼び出しスタックは、第１プロセスが呼び出す各種類の関数を含む、ことと、呼び出しスタックにおいて呼び出しに失敗した目標関数が存在する場合に、基準コードセグメントから目標関数のロジックコードを決定することと、第２プロセスにより実行されるコードセグメントに基づいて、目標関数のロジックコードから、無応答現象が生じる障害点を決定することと、に用いられる。

【0161】

１つの実施例において、目標関数のロジックコードにおいてプロセス作成文が含まれ、プロセス作成文は、子プロセスを作成することに用いられる文であり、且つプロセス作成文によって作成された子プロセスと相応な親プロセスとの間で、同一のアドレス空間を共有する。処理モジュール７０２は、具体的に、第２プロセスが実行するコードセグメントから第２コード文を決定することであって、第２コード文とは、無応答現象が発生する前に、第２プロセスにより実行されるコード文を指す、ことと、第２コード文がデータ読み取り操作を実現することに用いられる文であるときに、第２コード文に基づき、第２プロセスがデータ読み取り操作を実行することに必要な目標リソースを決定することと、第１プロセスが目標リソースを持っている場合に、目標関数のロジックコードにおけるプロセス作成文を、無応答現象が生じる障害点として決定することと、に用いられる。ここで、第２プロセスは、第１プロセスの子プロセスであり、第１プロセスが目標リソースを持っている場合に、第２プロセスは、ブロックされ、且つ第２プロセスがブロックされる継続時間が継続時間の閾値より大きいときに、無応答現象がトリガーされる。

【0162】

１つの実施例において、処理モジュール７０２は、具体的に、子プロセスを作成することに用いられる目標文を決定することであって、目標文により作成される子プロセスと相応な親プロセスとは、異なるアドレス空間を独立して使用する、ことと、システムコードにおいて目標文を採用してプロセス作成文を置き換えることにより、システムコードを修復することと、に用いられる。

【0163】

１つの実施例において、プロセス作成文において関数フィールドが含まれ、且つ関数フィールドに第１システム呼び出し関数が記憶される。プロセス作成文は、第１システム呼び出し関数によって子プロセスを作成し、処理モジュール７０２は、具体的に、プロセス作成文における関数フィールドにおける第１システム呼び出し関数を、第２システム呼び出し関数に修正し、子プロセスを作成することに用いられる目標文を得ることに用いられる。ここで、目標文は、第２システム呼び出し関数によって子プロセスを作成する。

【0164】

１つの実施例において、目標アプリケーションの複数の種類の無応答現象は、サービス型の無応答現象を含み、サービス型の無応答現象が生じる過程は、目標アプリケーションのアプリケーションプロセスが送信するサービス作成要求に応答して、サービスの継続時間の閾値を設定するステップと、サービスプロセスにサービス作成メッセージを送信することにより、サービスプロセスがサービス作成メッセージに基づいて、１つ又は複数の他のプロセスを呼び出してサービス作成作業を実行するようにサービスプロセスに通知し、且つサービスの作成が成功した後にフィードバック情報を返すステップと、サービスの継続時間の閾値内にサービスプロセスから返されたフィードバック情報を受信しなかった場合に、サービス型の無応答現象が生じるステップと、を含む。

【0165】

１つの実施例において、目標アプリケーションの複数の種類の無応答現象は、ブロードキャスト型の無応答現象を含み、ブロードキャスト型の無応答現象が生じる過程は、目標アプリケーションのアプリケーションプロセスが開始したブロードキャスト送信要求に応答して、ブロードキャストの継続時間の閾値を設定するステップと、ブロードキャスト受信プロセスにブロードキャスト登録メッセージを送信することにより、ブロードキャスト受信プロセスがブロードキャスト登録メッセージに基づいて、１つ又は複数の他のプロセスを呼び出してブロードキャスト作業を実行するようにブロードキャスト受信プロセスに通知し、且つブロードキャストが完了した後にフィードバック情報を返すステップと、ブロードキャストの継続時間の閾値内にブロードキャスト受信プロセスから返されたフィードバック情報を受信しなかった場合に、ブロードキャスト型の無応答現象が生じるステップと、を含む。

【0166】

１つの実施例において、目標アプリケーションの複数の種類の無応答現象は、コンテンツ提供型の無応答現象を含み、コンテンツ提供型の無応答現象が生じる過程は、目標アプリケーションのアプリケーションプロセスが開始したコンテンツ提供オブジェクトの取得要求に応答して、コンテンツ提供オブジェクトと対応するコンテンツ提供プロセスの起動状態を検出するステップと、起動状態がコンテンツ提供プロセスが起動していないことを指示する場合に、コンテンツ提供プロセスを作成し、且つ１つ又は複数の他のプロセスを呼び出して、コンテンツ提供オブジェクトをインストールするようにコンテンツ提供プロセスに通知し、且つコンテンツ提供オブジェクトをインストールした後にフィードバック情報を返すステップであって、コンテンツ提供オブジェクトに１つのインストールの継続時間の閾値が設定されている、ステップと、インストールの継続時間の閾値内にコンテンツ提供プロセスから返されたフィードバック情報を受信しなかった場合に、コンテンツ提供型の無応答現象が生じるステップと、を含む。

【0167】

１つの実施例において、目標アプリケーションの複数の種類の無応答現象は、入力イベント配信型の無応答現象を含む。入力イベント配信型の無応答現象が生じる過程は、１つの入力イベントを受信した場合に、現在受信された入力イベントを入力キューに追加し、且つ入力配信スレッドをウェイクアップするステップであって、入力配信スレッドは、入力キューにおける各々の入力イベントを目標アプリケーションのアプリケーションプロセスに順番に配信して処理させることに用いられる、ステップと、現在受信された入力イベントの配信順位に達するときに、目標アプリケーションのアプリケーションプロセスが他の入力イベントを処理すると、入力イベント配信型の無応答現象が生じるステップと、を含む。

【0168】

理解できるように、本願の実施例により記述されるデータ処理装置の各機能モジュールの機能は、上記方法の実施例における方法に基づき具体的に実現でき、その具体的な実現過程は、上記方法の実施例の関連する記述を参照できるため、ここでは、再度詳細に説明しない。また、同じ方法を採用する有益な効果に対する記述も、再度詳細に説明されない。

【0169】

図８に参照されるように、図８は、本願の実施例が提供するコンピュータ機器の構造模式図である。該コンピュータ機器８００は、独立した機器（たとえば、サーバ、ノード、及び端末等のうちの１つ又は複数）を含んでもよく、独立した機器の内部の部材（たとえば、チップ、ソフトウェアモジュール、又はハードウェアモジュール等）を含んでもよい。該コンピュータ機器８００は、少なくとも１つのプロセッサ８０１、及び通信インタフェース８０２を含んでもよく、更に、選択可能に、コンピュータ機器８００は、少なくとも１つのメモリ８０３、及びバス８０４をさらに含んでもよい。ここで、プロセッサ８０１、通信インタフェース８０２、及びメモリ８０３は、バス８０４によって連結される。

【0170】

ここで、プロセッサ８０１は、算術演算、及び／又はロジック演算を行うモジュールであり、具体的に、中央プロセッサ（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＣＰＵ）、画像プロセッサ（ｇｒａｐｈｉｃｓｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＧＰＵ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒｕｎｉｔ、ＭＰＵ）、特定用途向け集積回路（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ、ＦＰＧＡ）、コンプレックスプログラマブルロジックデバイス（Ｃｏｍｐｌｅｘｐｒｏｇｒａｍｍａｂｌｅｌｏｇｉｃｄｅｖｉｃｅ、ＣＰＬＤ）、コプロセッサ（中央プロセッサを支援して相応な処理、及びアプリケーションを完了する）、及びマイクロコントローラユニット（ＭｉｃｒｏｃｏｎｔｒｏｌｌｅｒＵｎｉｔ、ＭＣＵ）等の処理モジュールのうちの一種、又は複数の種類の組み合わせであってもよい。

【0171】

通信インタフェース８０２は、少なくとも１つのプロセッサに情報の入力、又は出力を提供することに用いることができる。及び／又は、通信インタフェース８０２は、外部から送信されたデータを受信する、及び／又は外部にデータを送信することに用いることができ、例えば、イーサネットケーブル等を含む有線リンクインタフェースであってもよく、無線リンク（Ｗｉ－Ｆｉ、ブルートゥース（登録商標）、汎用無線伝送、車載短距離通信技術、及び他の短距離無線通信技術等）インタフェースであってもよい。通信インタフェース８０２は、ネットワークインタフェースとされてもよい。

【0172】

メモリ８０３は、記憶空間を提供することに用いられ、記憶空間においてオペレーティングシステム、及びコンピュータプログラム等のデータが記憶されてもよい。メモリ８０３は、ランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）、読み取り専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ｅｒａｓａｂｌｅｐｒｏｇｒａｍｍａｂｌｅｒｅａｄｏｎｌｙｍｅｍｏｒｙ、ＥＰＲＯＭ）、又はポータブル読み取り専用メモリ（ｃｏｍｐａｃｔｄｉｓｃｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＣＤ－ＲＯＭ）等のうちの一種、又は複数の種類の組み合わせであってもよい。

【0173】

該コンピュータ機器８００における少なくとも１つのプロセッサ８０１は、少なくとも１つのメモリ８０３において記憶されているコンピュータプログラムを呼び出すことに用いられ、本願に示される実施例により記述されるデータ処理方法を実行することに用いられる。

【0174】

一種の可能な実施形態では、該コンピュータ機器８００におけるプロセッサ８０１は、少なくとも１つのメモリ８０３において記憶されているコンピュータプログラムを呼び出すことに用いられ、以下の操作を実行することに用いられる。

【0175】

１つの実施例において、プロセッサ８０１は、具体的に、目標アプリケーションの複数の種類の無応答現象のうちの各種類の無応答現象の現場情報を取得することであって、いずれか一種類の無応答現象は、オペレーティングシステムのシステムコードに基づいて目標アプリケーションを動作させる過程において生じるものであり、且ついずれか一種類の無応答現象の現場情報は、相応な無応答現象が生じるときのシステムコードの実行状況を記述することに用いられる、ことと、各種類の無応答現象の現場情報に対して共通性分析を行い、共通性分析結果を得て、且つ共通性分析結果に基づき、システムコードから無応答現象が生じる障害点を決定することと、障害点に基づきシステムコードを修復処理することにより、修復後のシステムコードに基づいて目標アプリケーションを動作させることと、に用いられ、ここで、上記共通性分析結果は、上記各種類の無応答現象の現場情報における共通情報を含む。

【0176】

理解すべきであるように、本願の実施例において記述されるコンピュータ機器８００は、上記と対応する実施例における該データ処理方法に対する記述を実行することができ、上記の図７と対応する実施例における該データ処理装置７００に対する記述を実行することもできるが、ここで再度詳細に説明しない。また、同じ方法を採用する有益な効果に対する記述も、再度詳細に説明されない。

【0177】

この他、さらに指摘すべきであるように、本願の１つの例示的な実施例は、記憶媒体をさらに提供し、該記憶媒体において前述したデータ処理方法のコンピュータプログラムが記憶されており、１つ又は複数のプロセッサが該コンピュータプログラムをロードし、且つ実行すると、実施例におけるデータ処理方法に対する記述を実現することができるが、ここでは、再度詳細に説明しない。同じ方法を採用する有益な効果に対する記述も、ここでは、再度詳細に説明されない。理解できるように、プログラム命令は、１つ、又は互いに通信できる複数のコンピュータ機器に配備して実行されてもよい。

【0178】

上記コンピュータ可読記憶媒体は、前述したいずれかの実施例が提供するデータ処理装置、又は上記コンピュータ機器の内部記憶ユニットであってもよく、たとえば、コンピュータ機器のハードディスク、又は内部メモリであってもよい。該コンピュータ可読記憶媒体は、該コンピュータ機器の外部記憶機器であってもよく、たとえば、該コンピュータ機器に配置されたプラグインハードディスク、スマートメディアカード（ｓｍａｒｔｍｅｄｉａｃａｒｄ、ＳＭＣ）、セキュアデジタル（ｓｅｃｕｒｅｄｉｇｉｔａｌ、ＳＤ）カード、及びフラッシュカード（ｆｌａｓｈｃａｒｄ）等である。更に、該コンピュータ可読記憶媒体は、さらに、該コンピュータ機器の内部記憶ユニットと外部記憶機器との両方を含んでもよい。該コンピュータ可読記憶媒体は、該コンピュータプログラム、及び該コンピュータ機器に必要な他のプログラムやデータを記憶することに用いられる。該コンピュータ可読記憶媒体は、さらに、既に出力された、又は出力されようとするデータを一時的に記憶することに用いられてもよい。

【0179】

本願の一態様は、コンピュータプログラム製品を提供し、該コンピュータプログラム製品は、コンピュータプログラムを含み、該コンピュータプログラムは、コンピュータ可読記憶媒体において記憶される。コンピュータ機器のプロセッサは、コンピュータ可読記憶媒体から該コンピュータプログラムを読み取り、プロセッサは、該コンピュータプログラムを実行して、該コンピュータ機器に本願の実施例における方法を実行させる。

【0180】

本願の実施例の方法におけるステップは、実際の必要に応じて順序の調整、合併、及び削除を行うことができる。

【0181】

本願の実施例の装置におけるモジュールは、実際の必要に応じて合併、分割、及び削除を行うことができる。

【0182】

上記の開示は、本願の一部の実施例に過ぎず、勿論、これを利用して本願の特許請求の範囲を限定することができない。当業者は、上記の実施例を実現する全部、又は一部のフローを理解することができ、且つ本願の請求項に基づき行われた均等な構成への変更は、依然として発明がカバーする範囲に属する。

【図1a】