JP7006780B2 - システムサービスタイムアウト処理方法および装置 - Google Patents

Description

本願の実施形態は、通信技術の分野、特に、システムサービスタイムアウト処理方法および装置に関する。

現在、ユーザは、携帯電話、ウェアラブルデバイスおよびタブレットコンピュータ等の端末の円滑な実行に対しますます高い要求を有する。しかしながら、より多くの機能が端末に実装可能になるにつれ、実行中のアプリケーションプログラムによって占有されるリソースはますますフラグメント化され、その結果、ユーザの端末の使用中に、フレームフリーズあるいは場合によってはスクリーンフリーズを引き起こし、ユーザエクスペリエンスに大きな影響を及ぼしている。

通常、端末はウォッチドッグ（ｗａｔｃｈｄｏｇ）メカニズムを用いて、端末で提供されているシステムサービスがタイムアウトしたかどうかをモニタリングし得る。例えば、Ａｎｄｒｏｉｄ（登録商標）システムでは、ｗａｔｃｈｄｏｇは、システムサービス（ｓｙｓｔｅｍ ｓｅｒｖｅｒ）プロセス内のスレッド（ｔｈｒｅａｄ）、および、ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセス内に常駐する、例えばウィンドウマネージャサービス（ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｅｒ）およびアクティビティマネージャシステムサービス（ａｃｔｉｖｉｔｙ ｍａｎａｇｅｒ ｓｙｓｔｅｍ ｓｅｒｖｉｃｅ）等の様々なシステムサービスのスレッドとして実行されてよい。ｗａｔｃｈｄｏｇは、ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセス内のこれらのスレッドをモニタリングしてよい。スレッドがブロックされ、ｗａｔｃｈｄｏｇが予め設定された時間内に当該スレッドから応答を受信しない場合は、ｗａｔｃｈｄｏｇは端末に対し、Ａｎｄｒｏｉｄ（登録商標）システム全体を再起動するようトリガする。

換言すると、ｓｙｓｔｅｍ ｓｅｒｖｅｒ内のスレッドがブロックされていることを検出すると、ｗａｔｃｈｄｏｇは端末に対し再起動をトリガする。強制ブロッキングによるこの回復方式は、ユーザに対し、現在のシナリオにおけるすべてのデータを失わせることを生じさせ、また、ユーザは端末が再起動するまで待機する必要がある。

本願の実施形態は、システムサービスのタイムアウト時に、端末でのフレームフリーズまたはスクリーンフリーズの可能性を低減し、ユーザエクスペリエンスを向上させるためのシステムサービスタイムアウト処理方法および装置を提供する。

上述の目的を達成すべく、以下の技術的解決手段が本願の実施形態において用いられる。

第１の態様により、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが、本方法が適用される端末上で実行され、システムサービスプロセスは、少なくとも１つのシステムサービススレッドを含む。具体的には、方法は、少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき（ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されたロックオブジェクトが予め設定された時間内に解放されないこと、およびターゲットシステムサービススレッドがブロックされることのうちの少なくとも１つを含む）、端末によって、ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセス（特に、第１のアプリケーションプロセスおよび第２のアプリケーションプロセスは、少なくとも１つのアプリケーションプロセス内の２つの異なるアプリケーションプロセスである）を判定する段階と、端末によって、第１のアプリケーションプロセスを終了させる段階と、を備える。

このようにして、第１のアプリケーションプロセスが終了された後、第１のアプリケーションプロセスと通信するターゲットシステムサービススレッドによって占有されるターゲットロックオブジェクトは解放され得、ターゲットシステムサービススレッドのブロッキングは除去され、端末上で実行中の別のシステムサービススレッドは影響を受けない。これにより、端末でのフレームフリーズまたはスクリーンフリーズの可能性が低減され、ユーザエクスペリエンスが向上する。

具体的に、ターゲットシステムサービススレッドがブロックされることは、ターゲットシステムサービススレッドと第１のアプリケーションプロセスとの間の通信の持続期間が第１の予め設定された値より大きいこと、および、実行プロシージャにおけるターゲットシステムサービススレッドの保留持続期間が第２の予め設定された値より大きいこと、のうちの少なくとも１つを含んでよい。

可能な設計方法において、システムサービスプロセスは、さらにｗａｔｃｈｄｏｇスレッドを含む。方法は、さらに、ｗａｔｃｈｄｏｇスレッドによって、電気信号を上述のシステムサービススレッドにシーケンシャルに送信する段階と、上述のシステムサービススレッド中のターゲットシステムサービススレッドによってフィードバックされる応答信号が予め設定された時間内に受信されない場合、端末によって、ターゲットシステムサービススレッドはタイムアウトすると判定する段階と、を備える。換言すると、端末は、既存のｗａｔｃｈｄｏｇメカニズムに基づき、本願のシステムサービスタイムアウト処理方法を実装してよく、実装の複雑さが低減され、システムリソースが節約される。

可能な設計方法において、端末によって、ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定する段階は、端末によって、格納された登録情報に対し、ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスをクエリする段階を含み、ＩＰＣを実行するシステムサービススレッドと、第１のアプリケーションプロセスとの間の対応関係が登録情報に記録されている。

可能な設計方法において、端末によって、第１のアプリケーションプロセスを終了させる段階の後、方法は、端末によって、第１のアプリケーションプロセスを再起動する段階を含み、この結果、ユーザは、再起動された第１のアプリケーションプロセス上で処理を継続できる。

可能な設計方法において、方法は、さらに、端末が現在実行中のｂｉｎｄｅｒスレッドの総数Ｎをモニタリングすることを含み、Ｎは０以上の整数である。ｂｉｎｄｅｒスレッドの総数が第１の予め設定された値より大きい場合、端末は、Ｎ個のｂｉｎｄｅｒスレッドの各々によってサービスされているアプリケーションプロセスを判定する。さらに、端末は、すべてのアプリケーションプロセスの各々によって占有されているｂｉｎｄｅｒスレッド数をカウントする。第１のターゲットアプリケーションプロセスにより占有されるｂｉｎｄｅｒスレッドの数が第２の予め設定された値より大きい場合、このことは、第１のターゲットアプリケーションプロセスが多くのｂｉｎｄｅｒリソースを占有し過ぎており、端末でフレームフリーズまたはスクリーンフリーズが生じるリスクが比較的高い状態をもたらすことを示している。従って、端末は、第１のターゲットアプリケーションプロセスを終了させて、第１のターゲットアプリケーションプロセスによって占有されているｂｉｎｄｅｒスレッドを解放してよい。解放されたｂｉｎｄｅｒスレッドは、プロセス間通信を待機する別のプロセス（または別のスレッド）によって用いられてよい。

可能な設計方法において、第２のターゲットアプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッドの数が第２の予め設定された値より大きく、第２のターゲットアプリケーションプロセスの優先度が第１のターゲットアプリケーションプロセスの優先度より高い場合、方法はさらに、端末によって、第２のターゲットアプリケーションプロセスを終了させる段階と、端末によって、第２のターゲットアプリケーションプロセスを再起動させる段階と、を含む。換言すると、比較的多くのｂｉｎｄｅｒスレッドが複数の端末によって占有される場合、端末は、より低い優先度を持つアプリケーションプロセスを解放し、より高い優先度を持つアプリケーションプロセスを確保して、より高い優先度を持つアプリケーションプロセスが終了（または再起動）された後の端末の実行ステータスおよびユーザエクスペリエンスが悪影響を受けることを回避してよい。

可能な設計方法において、端末が第２のターゲットアプリケーションプロセスを終了させるとき、方法は、さらに、端末によって、第２のターゲットアプリケーションプロセスの実行の進行状況を記録する段階を備え、端末によって、第２のターゲットアプリケーションプロセスを再起動する段階は、端末によって、実行の進行状況に基づき、第２のターゲットアプリケーションプロセスを、実行の進行状況と同一の実行ステータスに回復させる段階を含む。このようにして、第２のターゲットアプリケーションプロセスを再起動させるとき、端末は、記録された実行の進行状況に基づき第２のターゲットアプリケーションプロセスを再起動前のステータスに回復させてよく、その結果、アプリケーションプロセスの再起動の前後に、サービスは割り込まれることがないので、ユーザエクスペリエンスが向上する。

可能な設計方法において、方法は、さらに、端末がターゲットアプリケーションにＩＰＣサービスを提供するｂｉｎｄｅｒスレッドの数Ｍをカウントし、Ｍは０以上の整数である、ことを含む。ｂｉｎｄｅｒスレッドの数Ｍが第１の閾値以上である場合、このことは、ｂｉｎｄｅｒスレッドリソースの枯渇の潜在的リスクが存在することを示しており、端末は、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止して、ｂｉｎｄｅｒスレッドリソースの枯渇を回避してよい。

可能な設計方法において、ｂｉｎｄｅｒスレッドの数が第１の閾値より大きい場合、端末によってターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する段階は、端末がＭ個のｂｉｎｄｅｒスレッドの各々により呼び出されるＡＰＩに関する統計を収集することを含む。１つのＡＰＩが呼び出される回数が第２の閾値より大きい場合、このことは、当該ＡＰＩは比較的負荷が重い状態にあり、ｂｉｎｄｅｒスレッドが悪意でＡＰＩを呼び出しているリスクが存在する可能性があることを示している。この場合、比較的多数のｂｉｎｄｅｒスレッドリソースが占有されており、ｂｉｎｄｅｒスレッドは頻繁に単一のＡＰＩを呼び出す。従って、端末は、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成要求への応答を停止して、悪意の占有により引き起こされるｂｉｎｄｅｒスレッドリソースの枯渇を回避してよい。

可能な設計方法において、端末によって、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する段階の後、方法は、さらに、ターゲットアプリケーションにＩＰＣサービスを提供するｂｉｎｄｅｒスレッドの数Ｍが第１の閾値未満の場合、端末によって、ターゲットアプリケーションのために新しいｂｉｎｄｅｒスレッドを作成する段階を含む。

可能な設計方法において、方法は、さらに、端末によって、ターゲットシステムサービススレッドがタイムアウトする原因を表示する段階、または、第１のアプリケーションプロセスを終了させるプロンプトメッセージを表示する段階を含む。

可能な設計方法において、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。具体的には、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスは、方法が適用される端末上で実行される。システムサービスプロセスは、少なくとも１つのシステムサービススレッドを含む。具体的には、方法は、第１のシステムサービススレッドがターゲットロックオブジェクトを占有するとき、第１のタイマが計時を開始するようトリガされることを含む。第１のタイマが期限切れになったときに、第１のシステムサービススレッドがまだターゲットロックオブジェクトを解放しない場合は、端末は、ターゲットロックオブジェクトを占有する第１のシステムサービススレッドの識別子を取得するようトリガされる。さらに、端末は、第１のシステムサービススレッドの識別子に基づき、第１のシステムサービススレッドと通信するターゲットアプリケーションプロセスを判定し、ターゲットアプリケーションプロセスを終了させる。

別の可能な設計方法において、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。具体的には、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが、方法が適用される端末上で実行され、システムサービスプロセスは、少なくとも１つのシステムサービススレッドを含む。具体的に、方法は、第１のシステムサービススレッドが、第１のアプリケーションプロセスと通信することを含む。第２のアプリケーションプロセスが第１のシステムサービススレッドによって提供されるシステムサービスを要求するとき、第２のタイマが計時を開始するようトリガされる。第２のタイマが期限切れになったときに、第１のシステムサービススレッドがまだ第１のアプリケーションプロセスと通信中の場合、端末は、第１のアプリケーションプロセスを終了させるようトリガされる。

第２の態様により、本願の一実施形態は、端末を提供する。システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが端末上で実行され、システムサービスプロセスは少なくとも１つのシステムサービススレッドを含む。端末は、少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするか否かを検出するよう構成されたタイムアウト検出ユニットと、ターゲットシステムサービススレッドがタイムアウトするとき、ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定するよう構成された判定ユニットであって、ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されるロックオブジェクトが予め設定された時間内に解放されないこと、および、ターゲットシステムサービススレッドがブロックされていることのうちの少なくとも１つを含む、判定ユニットと、第１のアプリケーションプロセスを終了させるよう構成されたタイムアウト処理ユニットと、を備える。

可能な設計方法において、具体的に、判定ユニットは、格納された登録情報に対し、ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスをクエリするよう構成されており、プロセス間通信（ＩＰＣ）を実行するシステムサービススレッドと、第１のアプリケーションプロセスとの間の対応関係が登録情報に記録されている。

可能な設計方法において、タイムアウト処理ユニットは、さらに、第１のアプリケーションプロセスを再起動させるよう構成されている。

可能な設計方法において、タイムアウト検出ユニットは、さらに、現在実行中のｂｉｎｄｅｒスレッドの総数Ｎをモニタリングするよう構成されており、Ｎは０以上の整数であり、判定ユニットは、さらに、ｂｉｎｄｅｒスレッドの総数が第１の予め設定された値より大きい場合、Ｎ個のｂｉｎｄｅｒスレッドの各々によってサービスされるアプリケーションプロセスを判定し、且つ、すべてのターゲットアプリケーションプロセスの各々によって占有されるｂｉｎｄｅｒの数をカウントするよう構成されており、タイムアウト処理ユニットサは、さらに、第１のターゲットアプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッドの数が第２の予め設定された値より大きい場合、第１のターゲットアプリケーションプロセスを終了させるよう構成されている。

可能な設計方法において、第２のターゲットアプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッドの数が第２の予め設定された値より大きく、第２のターゲットアプリケーションプロセスの優先度が第１のターゲットアプリケーションプロセスの優先度より高い場合、タイムアウト処理ユニットは、さらに、第２のターゲットアプリケーションプロセスを終了させる、および、第２のターゲットアプリケーションプロセスを再起動させるよう構成されている。

可能な設計方法において、具体的に、タイムアウト処理ユニットは、第２のターゲットアプリケーションプロセスの実行の進行状況を記録し、実行の進行状況に基づき、第２のターゲットアプリケーションプロセスを、実行の進行状況と同一の実行ステータスに回復させるよう構成されている。

可能な設計方法において、判定ユニットは、さらに、ターゲットアプリケーションにＩＰＣサービスを提供するｂｉｎｄｅｒの数Ｍをカウントするよう構成されており、Ｍは０以上の整数であり、タイムアウト処理ユニットは、さらに、ｂｉｎｄｅｒスレッドの数Ｍが第１の閾値以上である場合、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止するよう構成されている。

可能な設計方法において、具体的に、タイムアウト処理ユニットは、Ｍ個のｂｉｎｄｅｒスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェース（ＡＰＩ）に関する統計を収集するよう構成されており、１つのＡＰＩが呼び出される回数が第２の閾値より多い場合、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成要求に応答することを停止するよう構成されている。

可能な設計方法において、タイムアウト処理ユニットは、さらに、ターゲットアプリケーションにＩＰＣサービスを提供するｂｉｎｄｅｒスレッドの数Ｍが第１の閾値未満の場合、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドを作成するよう構成されている。

可能な設計方法において、端末は、さらに、ターゲットシステムサービススレッドがタイムアウトする原因を表示する、または第１のアプリケーションプロセスを終了させるプロンプトメッセージを表示するよう構成されたディスプレイユニットを備える。

第３の態様により、本願の一実施形態は、端末を提供する。端末は、プロセッサ、メモリ、バスおよび通信インタフェースを含む。メモリは、コンピュータ実行可能命令を格納するよう構成されており、プロセッサはバスを用いてメモリに接続されており、端末が稼働される場合、プロセッサは、メモリ内に格納されたコンピュータ実行可能命令を実行し、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の１つを実行できるようにされる。

第４の態様により、本願の一実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を格納し、当該命令が上述の端末のうちの任意の１つで実行されると、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の１つを実行できるようにされる。

第５の態様により、本願の一実施形態は、命令を含むコンピュータプログラムプロダクトを提供する。コンピュータプログラムプロダクトが、上述の端末のうちの任意の１つで実行されると、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の１つを実行できるようにされる。

第２の態様から第５の態様までの任意の設計によりもたらされる技術的効果については、第１の態様における異なる設計方法によりもたらされる技術的効果を参照されたい。ここに詳細を再度説明することはしない。

本願の実施形態による、端末の第１の概略構造図である。

本願の一実施形態によるＡｎｄｒｏｉｄ（登録商標）システムの第１の概略アーキテクチャ図である。

本願の一実施形態によるＡｎｄｒｏｉｄ（登録商標）システムの第２の概略アーキテクチャ図である。

本願の一実施形態によるＡｎｄｒｏｉｄ（登録商標）システムの第３の概略アーキテクチャ図である。

本願の一実施形態によるシステムサービスタイムアウト処理方法の第１の概略フローチャートである。

本願の一実施形態による、システムサービスタイムアウト処理方法のアプリケーションシナリオの第１の概略図である。

本願の一実施形態による、システムサービスタイムアウト処理方法のアプリケーションシナリオの第２の概略図である。

本願の一実施形態による、システムサービスタイムアウト処理方法の第２の概略フローチャートである。

本願の一実施形態によるシステムサービスタイムアウト処理方法の第３の概略フローチャートである。

本願の一実施形態による、端末の第２の概略構造図である。

本願の一実施形態による、端末の第３の概略構造図である。

以下で言及する「第１」および「第２」という用語は、説明のためのものに過ぎず、相対的重要性のを示すもの若しくは暗示、あるいは、示された技術的特徴の数の暗示として理解されるべきではない。従って、「第１」または「第２」として限定される特徴は、１または複数の特徴を明示的または暗黙的に含んでよい。本願の実施形態の説明において、別途の記載がない限り、「複数」は、２または２より多いことを意味する。

本願の実施形態で提供されるシステムサービスタイムアウト処理方法を明確に説明するために、まず、後続の実施形態に現れ得るいくつかの概念について説明する。

プロセス（ｐｒｏｃｅｓｓ）とは、アプリケーションプログラムのデータセット上で実行中のアクティビティであり、オペレーティングシステム（例えば、Ａｎｄｒｏｉｄ（登録商標）システム）が割り当ておよびリソーススケジューリングを行う基本単位である。各プロセスは、アドレス空間を占有する。アプリケーションプログラムは、オペレーティングシステム上で、対応する機能を実装するための１または複数のプロセスとして実行される。

スレッド（ｔｈｒｅａｄ）とは、１プロセスの１エンティティであり、プロセスより小さく、独立して実行可能な基本単位である。スレッドは、あるプロセスのすべてのリソースを、同一プロセスに属する他の複数のスレッドと共有可能である。１つのスレッドが、別のスレッドを作成およびキャンセルできる。１つのプロセス内の複数のスレッドが並列に実行可能である。

オブジェクトロッキングとは、一度に１つのスレッドのみがメソッドまたは変数にアクセスすることを保証するメカニズムである。Ｊａｖａ（登録商標）言語では、あるスレッドがシンクロナイズドコードにアクセスすると、当該コードが属するロックオブジェクトが取得される必要がある。さもなければ、当該スレッドは、当該ロックオブジェクトが解放されるまで、待機（またはブロック）されることになる。シンクロナイズドコードとは、キーワード"ｓｙｎｃｈｒｏｎｉｚｅｄ"で修飾されたメソッドまたはステートメントブロックである。

換言すると、オブジェクトロッキングとは、最大で１つのスレッドがロックを取得できることを意味する排他処理である。スレッドＡが、スレッドＢが保持するロックオブジェクトの取得を試みると、スレッドＡは待機する必要がある、またはブロックされる必要がある。スレッドＡは、スレッドＢがロックを解放するまで、対応するメソッドまたは変数にアクセスすべく、ロックオブジェクトを取得できない。

通常、スレッドブロッキングとは、実行プロシージャ内のスレッドの保留持続期間が予め設定された値より大きい場合に生じるタイムアウトを指す。例えば、スレッドＡの実行プロシージャで、実行を継続するために、スレッドＢの実行結果が入力パラメータとして用いられる必要がある。この場合、スレッドＡがスレッドＢの実行結果を取得しない場合、実行は保留される。スレッドＡが予め設定された時間内にスレッドＢの実行結果を取得しない場合、スレッドＡはブロックされる。代替的に、スレッドブロッキングとは、スレッドがあるプロセスとの通信時に、当該スレッドがそのプロセスによって、長期間占有されることを原因として、当該スレッドが別のプロセスのためのサービスを提供できない現象を指してよい。

現在、端末は、ｗａｔｃｈｄｏｇメカニズムに基づき、オペレーティングシステム内のいくつかのスレッドおよびロックオブジェクトをモニタリングし得る。モニタリングされるスレッドがブロックされている場合、または、モニタリングされるロックオブジェクトが長期間解放されない場合、端末は、保留またはスクリーンフリーズを回避すべく、オペレーティングシステム全体を再起動するようトリガされ得る。

しかしながら、オペレーティングシステム全体を再起動することによるフリーズの除去は、スレッドがブロックされる、またはロックオブジェクトが正常に解放されないという問題を解決できるが、オペレーティングシステム内で正常に実行中の別のスレッドおよびロックオブジェクトも強制的に終了される。実行中のアプリケーションプログラムの大量のデータが失われることは間違いない。また、ユーザエクスペリエンスも犠牲になる。

従って、本願の実施形態では、既存のｗａｔｃｈｄｏｇトリガメカニズムに基づき、モニタリングされるスレッドがブロックされていること、または、モニタリングされるロックオブジェクトが長期間解放されないことを検出したときに、端末がまず、ブロックされているスレッドまたはロックオブジェクトを占有するスレッド（またはプロセス）と通信中のアプリケーションプロセスを判定してよい。さらに、端末は、アプリケーションプロセスの終了または再起動等の回復ポリシーを用いて、現在のスレッドがブロックされている、またはロックオブジェクトが解放できないという問題を解決してよい。このようにすると、オペレーティングシステムにおけるブロックされていない、または、ロックオブジェクトを正常に解放するスレッドの実行中のプロシージャは影響を受けることがなく、スレッドブロッキングまたはロックオブジェクト解放エラーにより引き起こされるフリーズの問題も解決されてよく、これによりユーザエクスペリエンスが大きく向上する。

上述のアプリケーションプロセスは、端末のアプリケーションレイヤでのアプリケーションプログラムのプロセスであってよく、または、バックグランドで実行中のデーモン（ｄａｅｍｏｎ）プロセスであってよい。このことは、本願の実施形態において限定されるものではない。

本願の一実施形態で提供されるシステムサービスタイムアウト処理方法は、携帯電話、ウェアラブルデバイス、拡張現実（ａｕｇｍｅｎｔｅｄ ｒｅａｌｉｔｙ，ＡＲ）／仮想現実（ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ，ＶＲ）デバイス、タブレットコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ（ｕｌｔｒａ－ｍｏｂｉｌｅ ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ，ＵＭＰＣ）、ネットブックまたはパーソナルデジタルアシスタント（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ，ＰＤＡ）等の任意の端末に適用されてよい。以降の実施形態において、特定の形態の端末に限定されないのはもちろんである。

図１に示される通り、本願の実施形態における端末は、携帯電話１００であってよい。以下に、携帯電話１００を例に用いて、実施形態について詳細に説明する。当該図に示される携帯電話１００は、端末の一例に過ぎず、携帯電話１００は、図に示されるものより多いまたは少ないコンポーネントを有してよく、２または２より多いコンポーネントが組み合わされてよく、あるいは異なるコンポーネント構成が用いられてよいことを理解されたい。

図１に示される通り、具体的に携帯電話１００は、プロセッサ１０１、無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ，ＲＦ）回路１０２、メモリ１０３、タッチスクリーン１０４、Ｂｌｕｅｔｏｏｔｈ（登録商標）装置１０５、１または複数のセンサ１０６、ワイヤレスフィディリティ（ｗｉｒｅｌｅｓｓ ｆｉｄｅｌｉｔｙ，Ｗｉ－Ｆｉ）装置１０７、位置特定装置１０８、オーディオ回路１０９、周辺機器インタフェース１１０および電力システム１１１等のコンポーネントを含んでよい。これらのコンポーネントは、１または複数の通信バスまたは信号ケーブル（図１に不図示）を用いて互いに通信してよい。当業者であれは、図１に示されるハードウェア構造は、携帯電話に対する限定を構成せず、携帯電話１００は、図に示されるものより多いまたは少ないコンポーネントを含んでよく、いくつかのコンポーネントは組み合わされてよく、あるいは異なるコンポーネント構成が用いられてよいことを理解するであろう。

以下に、図１を参照して、携帯電話１００のコンポーネントについて詳細に説明する。

プロセッサ１０１は、携帯電話１００の制御センターである。プロセッサ１０１は、様々なポートおよび配線を用いて携帯電話１００の様々な部分に接続され、メモリ１０３内に格納されたアプリケーションプログラムを稼働または実行し、メモリ１０３内に格納されたデータを呼び出して、携帯電話１００の様々な機能を実行して、データを処理する。いくつかの実施形態において、プロセッサ１０１は、１または複数の処理ユニットを含んでよい。例えば、プロセッサ１０１は、Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ製のＫｉｒｉｎ ９６０チップであってよい。本願のいくつかの実施形態において、プロセッサ１０１はさらに、収集された指紋を検証するよう構成された指紋検証チップを含んでよい。

無線周波数回路１０２は、情報の送信および受信プロシージャにおいて、またはコールプロシージャにおいて、無線信号を送信および受信するよう構成されてよい。特に、基地局からダウンリンクデータを受信した後、無線周波数回路１０２は、ダウンリンクデータをプロセッサ１０１に処理させるために送信してよい。また、無線周波数回路１０２は、関連するアップリンクデータを基地局に送信する。一般に、無線周波数回路は、アンテナ、少なくとも１つの増幅器、送受信機、カプラ、低雑音増幅器およびデュプレクサ等を含むが、これらに限定されるものではない。また、無線周波数回路１０２は、さらに、無線通信を通して別のデバイスと通信してよい。グローバルシステムフォーモバイルコミュニケーション、汎用パケット無線サービス、符号分割多重アクセス、広帯域符号分割多重アクセス、ロングタームエボリューション、電子メールおよびショートメッセージサービス等を含む無線通信における任意の通信規格またはプロトコルが用いられてよく、これらに限定されるものではない。

メモリ１０３は、アプリケーションプログラムおよびデータを格納するよう構成されている。プロセッサ１０１は、携帯電話１００の様々な機能を実行し、および、データを処理するために、メモリ１０３内に格納されたアプリケーションプログラムおよびデータを実行する。メモリ１０３は、主に、プログラム格納領域およびデータ格納領域を含む。プログラム格納領域は、オペレーティングシステムと、少なくとも１つの機能（例えば、サウンド再生またはイメージ再生機能）により必要とされるアプリケーションプログラムとを格納してよい。データ格納領域は、携帯電話１００の使用を基に作成されたデータ（例えば、オーディオデータまたは電話帳）を格納してよい。また、メモリ１０３は、高速ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ，ＲＡＭ）を含んでよく、さらに、磁気ディスク記憶デバイス、フラッシュメモリデバイス等の不揮発性メモリ、または別の揮発性ソリッドステートメモリを含んでよい。メモリ１０３は、Ａｐｐｌｅ社が開発したｉＯＳ（登録商標）オペレーティングシステムおよびＧｏｏｇｌｅ社が開発したＡｎｄｒｏｉｄ（登録商標）オペレーティングシステム等の様々なオペレーティングシステムを格納してよい。メモリ１０３は独立していてよく、通信バスを用いてプロセッサ１０１に接続される。代替的に、メモリ１０３はプロセッサ１０１に統合されてよい。

具体的に、タッチスクリーン１０４は、タッチパッド１０４－１およびディスプレイ１０４‐２を含んでよい。

タッチパッド１０４－１は、携帯電話１００のユーザにより、携帯電話１００上でまたはその近傍で行われたタッチイベント（例えば、ユーザにより、指またはスタイラス等の好適なオブジェクトを用いてタッチパッド１０４－１上でまたはその近傍で、行われた操作）を収集してよく、収集されたタッチ情報を別のコンポーネント（プロセッサ１０１等）に送信してよい。ユーザにより、タッチパッド１０４－１の近傍で行われたタッチイベントは、フローティングタッチと呼ばれてよい。フローティングタッチとは、ユーザがオブジェクト（例えば、アイコン）を選択、移動またはドラッグするために、タッチパッドを直接タッチする必要がないこと、および、ユーザが所望の機能を実行するために端末の付近にいるだけでよいことを意味してよい。また、タッチパッド１０４－１は、抵抗タイプ、静電容量タイプ、赤外線タイプまたは表面弾性波タイプ等の複数のタイプで実装されてよい。

ディスプレイ（ディスプレイスクリーンとも言う）１０４‐２は、ユーザにより入力された情報またはユーザに対し提供される情報、および携帯電話１００の様々なメニューを表示するよう構成されてよい。ディスプレイ１０４－２は、液晶ディスプレイまたは有機発光ダイオード等の形態で構成されてよい。タッチパッド１０４－１は、ディスプレイ１０４－２を覆ってよい。タッチパッド１０４－１上またはその近傍でのタッチイベントを検出すると、タッチパッド１０４－１は、タッチイベントのタイプを判定すべく、そのタッチイベントをプロセッサ１０１に転送する。次に、プロセッサ１０１は、タッチイベントのタイプに基づき、対応するビジュアル出力をディスプレイ１０４－２に提供してよい。図１中のタッチパッド１０４－１およびディスプレイスクリーン１０４－２は、携帯電話１００の入力および出力機能を実装するための２つの独立したコンポーネントとして用いられるが、いくつかの実施形態においては、携帯電話１００の入力および出力機能を実装すべく、タッチパッド１０４－１およびディスプレイスクリーン１０４－２が統合されてよい。タッチスクリーン１０４は、材料の複数のレイヤを積層することで形成されることが理解可能である。本願のこの実施形態において、タッチパッド（レイヤ）およびディスプレイスクリーン（レイヤ）のみが表示されており、別のレイヤは本願のこの実施形態において記載されていない。また、タッチパッド１０４－１は、ベゼルレス画面の形態で、携帯電話１００の前面に構成されてよく、ディスプレイスクリーン１０４－２も、ベゼルレス画面の形態で携帯電話１００の前面に構成されてよい。このようにして、ベゼルレス構造が携帯電話の前面に実装されてよい。

また、携帯電話１００は、さらに、指紋認識機能を有してよい。例えば、指紋認識部１１２が、携帯電話１００の裏面（例えば、背面カメラの下方）に構成されてよく、または、指紋認識部１１２は、携帯電話１００の前面（例えば、タッチスクリーン１０４の下方）に構成されてよい。別の例では、指紋収集コンポーネント１１２は、指紋認識機能を実装すべく、タッチスクリーン１０４に配置されてよく、すなわち、指紋収集コンポーネント１１２は、携帯電話１００の指紋認識機能を実装すべく、タッチスクリーン１０４に統合されてよい。この場合、指紋収集コンポーネント１１２はタッチスクリーン１０４内に構成されてよく、タッチスクリーン１０４の一部であってよい、または、別の態様でタッチスクリーン１０４内に構成されてよい。本願のこの実施形態における指紋収集コンポーネント１１２の主なコンポーネントは、指紋センサである。指紋センサは、任意のタイプの感知技術を用いてよく、このようなものとして、光感知技術、静電容量感知技術、圧電感知技術または超音波感知技術等が含まれるが、これらに限定されるものではない。

携帯電話１００は、さらに、携帯電話１００と別の短距離端末（例えば、携帯電話またはスマートウォッチ）との間でデータを交換するよう構成されたＢｌｕｅｔｏｏｔｈ（登録商標）装置１０５を含んでよい。本願のこの実施形態において、Ｂｌｕｅｔｏｏｔｈ（登録商標）装置は、集積回路またはＢｌｕｅｔｏｏｔｈ（登録商標）チップ等であってよい。

携帯電話１００は、さらに、光学センサ、モーションセンサおよび別のセンサ等の少なくとも１つのセンサ１０６を含んでよい。具体的には、光学センサは、環境光センサおよび近接センサを含んでよい。環境光センサは、周囲光の輝度に基づき、タッチスクリーン１０４のディスプレイの輝度を調整してよい。近接センサは、携帯電話１００が耳に近づけられたとき、ディスプレイの電源をオフにしてよい。モーションセンサのタイプとしての加速度計センサが、全方向（通常、３軸）における加速度の値を検出してよく、センサの静止時の重力の値および方向を検出してよく、携帯電話の姿勢（ランドスケープモードとポートレイトモードとの間の画面切り替え、関連するゲームまたは磁力計の姿勢較正等）を識別するためのアプリケーションプログラム、振動の識別に関連する機能（歩数計またはノック等）等において用いられてよい。ジャイロスコープ、バロメータ、湿度計、温度計および赤外線センサ等の他センサが、さらに、携帯電話１００上に配置されてよい。詳細については、ここで説明はしない。

Ｗｉ－Ｆｉ（登録商標）装置１０７は、携帯電話１００に対し、Ｗｉ－Ｆｉ（登録商標）関連の規格プロトコルに準拠するネットワークアクセスを提供するよう構成されている。携帯電話１００は、ユーザが電子メールを送信および受信する、ウェブページを閲覧する、ストリーミングメディアにアクセスする等を補助すべく、Ｗｉ－Ｆｉ（登録商標）装置１０７を用いて、Ｗｉ－Ｆｉ（登録商標）アクセスポイントにアクセスしてよい。Ｗｉ－Ｆｉ（登録商標）装置１０７は、ユーザに無線ブロードバンドインターネットアクセスを提供する。いくつかの他の実施形態においては、Ｗｉ－Ｆｉ（登録商標）装置１０７は、Ｗｉ－Ｆｉ（登録商標）無線アクセスポイントとして用いられてよく、別の端末に対し、Ｗｉ－Ｆｉ（登録商標）ネットワークアクセスを提供してよい。

位置特定装置１０８は、携帯電話１００に地理的位置を提供するよう構成されている。具体的に、位置特定装置１０８は、全地球測位システム（ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ，ＧＰＳ）、Ｂｅｉｄｏｕ衛星測位システムまたはロシアのＧＬＯＮＡＳＳ等の位置特定システムの受信機であってよいことが理解できるであろう。位置特定システムによって送信された地理的位置を受信した後、位置特定装置１０８は、当該情報を処理させるためにプロセッサ１０１に送信し、または、当該情報を格納させるためにメモリ１０３に送信する。いくつかの他の実施形態においては、位置特定装置１０８は、さらに、アシスト型全地球測位システム（ａｓｓｉｓｔｅｄ ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ，ＡＧＰＳ）の受信機であってよい。ＡＧＰＳシステムは、位置特定装置１０８が測距サービスおよび位置特定サービスを完了するのを補助するアシストサーバとして機能する。この場合、アシスト位置特定サーバは、端末、例えば携帯電話１００の位置特定装置１０８（すなわち、ＧＰＳ受信機）と、無線通信ネットワークを通して通信し、位置特定補助を提供する。いくつかの他の実施形態においては、位置特定装置１０８は、Ｗｉ－Ｆｉ（登録商標）アクセスポイントに基づく位置特定技術であってよい。各Ｗｉ－Ｆｉ（登録商標）アクセスポイントは、グローバル一意メディアアクセス制御（ｍｅｄｉａ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ，ＭＡＣ）アドレスを有し、端末は、Ｗｉ－Ｆｉ（登録商標）が有効になっている場合、周囲のＷｉ－Ｆｉ（登録商標）アクセスポイントのブロードキャスト信号をスキャンし、収集することができる。従って、端末は、Ｗｉ－Ｆｉ（登録商標）アクセスポイントによってブロードキャストされたＭＡＣアドレスを取得できる。端末は、Ｗｉ－Ｆｉ（登録商標）アクセスポイントを識別可能なかかるデータ（例えば、ＭＡＣアドレス）を、無線通信ネットワークを通してロケーションサーバに送信する。ロケーションサーバは、各Ｗｉ－Ｆｉ（登録商標）アクセスポイントの地理的位置を取得し、Ｗｉ－Ｆｉ（登録商標）ブロードキャスト信号の強度を参照して端末の地理的位置を計算し、端末の地理的位置を、端末の位置特定装置１０８に送信する。

音声回路１０９、スピーカ１１３およびマイク１１４は、ユーザと携帯電話１００との間のオーディオインタフェースを提供してよい。可聴周波数回路１０９は、受信したオーディオデータから変換された電気信号をスピーカ１１３に送信してよく、スピーカ１１３は当該電気信号を出力するための音声信号に変換する。また、マイク１１４は、収集された音声信号を電気信号に変換し、可聴周波数回路１０９は、当該電気信号を受信した後に当該電気信号をオーディオデータに変換し、その後、オーディオデータを例えば別の携帯電話に送信するために、オーディオデータをＲＦ回路１０２に出力する、またはさらなる処理のためにオーディオデータをメモリ１０３に出力する。

周辺機器インタフェース１１０は、外部入／出力デバイス（キーボード、マウス、外部ディスプレイ、外部メモリおよび加入者識別モジュールカード等）用の様々なインタフェースを提供するよう構成されている。例えば、携帯電話１００は、ユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ，ＵＳＢ）インタフェースを用いてマウスに接続され、ユーザ識別モジュールカードのカードスロット上の金属コンタクトを用いて、電気通信事業者が提供するユーザ識別モジュールカード（ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｍｏｄｕｌｅ，ＳＩＭ）に接続される。周辺機器インタフェース１１０は、外部入／出力周辺デバイスを、プロセッサ１０１およびメモリ１０３に結合するよう構成されてよい。

携帯電話１００は、さらに、電力を様々なコンポーネントに提供する電源装置１１１（例えば、バッテリまたは電力管理チップ）を含んでよい。バッテリは、充電管理、放電管理および電力消費管理等の機能が電源装置１１１を用いて実装されるように、電力管理チップを用いてプロセッサ１０１に論理的に接続されてよい。

図１には図示されていないが、携帯電話１００は、さらに、カメラ（前面カメラおよび／または背面カメラ）、フラッシュライト、マイクロプロジェクション装置および近距離無線通信（ｎｅａｒ ｆｉｅｌｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ，ＮＦＣ）等を含んでよい。詳細については、ここに説明はしない。

さらに、携帯電話１００は、Ａｎｄｒｏｉｄ（登録商標）またはｉＯＳ等のオペレーティングシステムを実行してよい。本願のこの実施形態はこの点において限定されるものではない。

Ａｎｄｒｏｉｄ（登録商標）オペレーティングシステムを例に用いると、図２に示される通り、Ａｎｄｒｏｉｄ（登録商標）オペレーティングシステムは、降順に、アプリケーションプログラムレイヤ２０１（すなわち、ＡＰＰレイヤ）、アプリケーションプログラムフレームワークレイヤ２０２（すなわち、ｆｒａｍｅｗｏｒｋレイヤ）、システムランタイムライブラリレイヤ２０３（すなわち、ｌｉｂｒａｒｙレイヤ）およびＬｉｎｕｘ（登録商標）カーネルレイヤ２０４の４つのレイヤに分割されてよい。

Ｌｉｎｕｘ（登録商標）カーネルレイヤ２０４は、携帯電話１００のセキュリティ（ｓｅｃｕｒｉｔｙ）制御、メモリ管理（ｍｅｍｏｒｙ ｍａｎａｇｅｍｅｎｔ）、プログラム管理（ｐｒｏｃｅｓｓ ｍａｎａｇｅｍｅｎｔ）、ネットワークスタック（ｎｅｔｗｏｒｋ ｓｔａｃｋ）およびドライバモデル（ｄｒｉｖｅｒ ｍｏｄｅｌ）等の機能に用いられてよい。Ｌｉｎｕｘ（登録商標）カーネルレイヤ２０４はまた、ハードウェア（例えば、ＣＰＵ、ネットワークインタフェースカードおよびメモリ）とソフトウェアスタックとの間の抽象化レイヤとしても機能し、特定のハードウェアの詳細情報を非表示にして、上位レイヤ（システムランタイムライブラリレイヤ２０３、アプリケーションプログラムフレームワークレイヤ２０２およびアプリケーションプログラムレイヤ２０１）に対し統合サービスを提供してよい。

システムランタイムライブラリレイヤ２０３は、メディアライブラリ、システムＣライブラリおよびディスプレイ管理ライブラリ（ｓｕｒｆａｃｅ ｍａｎａｇｅｒ）等のいくつかのＣ／Ｃ＋＋ライブラリを含む。これらのライブラリは、Ａｎｄｒｏｉｄ（登録商標）システム内の異なるコンポーネントによって用いられてよい。システムランタイムライブラリレイヤ２０３は、ｆｒａｍｅｗｏｒｋレイヤ２０２を用いて、開発者にサービスを提供してよい。

ｆｒａｍｅｗｏｒｋレイヤ２０２は、アプリケーションプログラムへのフルアクセスを可能にするアプリケーションプログラミングインタフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ，ＡＰＩ）フレームワークを開発者に提供する。具体的には、ｆｒａｍｅｗｏｒｋレイヤ２０２は、アプリケーションプログラムを開発するための多くのＡＰＩを提供し、および関連するサービスの要求を満たすＡＰＰが、対応するＡＰＩを呼び出して構築されてよい。

アプリケーションプログラムレイヤ２０１は、主に、Ｊａｖａ（登録商標）言語を用いてコンパイルされたＡＰＰを含む。当該ＡＰＰで操作スクリーンを操作するとき、ユーザは、ｆｒａｍｅｗｏｒｋレイヤ２０２内の関連するＡＰＩを呼び出すことで、システムランタイムライブラリレイヤ２０３またはＬｉｎｕｘ（登録商標）カーネルレイヤ２０４とやり取りして、操作スクリーンに対応する機能を実装する。

図３に示される通り、システムサービス（ｓｙｓｔｅｍ ｓｅｒｖｅｒ）プロセスは、ｆｒａｍｅｗｏｒｋレイヤ２０２で実行される。ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセスは、携帯電話１００にほとんどすべてのシステムサービスを提供してよく、これには、例えば、電力マネージャサービス（ｐｏｗｅｒ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅ，ＰＭＳ）、アクティビティマネージャサービス（ａｃｔｉｖｉｔｙ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅ，ＡＭＳ）、ウィンドウマネージャサービス、（ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅ，ＷＭＳ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）サービス（ｂｌｕｅｔｏｏｔｈ ｓｅｒｖｉｃｅ）、ネットワーク管理サービス（ｎｅｔｗｏｒｋ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅ，ＮＭＳ）、および入力マネージャサービス（ｉｎｐｕｔ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅ，ＩＭＳ）が含まれる。

また図３に示される通り、これらのシステムサービスは、ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセス内にスレッド（以降、システムサービススレッドと称される）として常駐してよく、これらのシステムサービススレッドは、アプリケーションプログラムレイヤ２０１におけるサードパーティのアプリケーションのプロセスまたはデーモン（ｄａｅｍｏｎ）プロセスと、プロセス間通信（ｉｎｔｅｒ－ｐｒｏｃｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ，ＩＰＣ）を実装してよい。例えば、ＷｅＣｈａｔアプリケーションのプロセスは、実行中のプロシージャにおいてｉｎｐｕｔ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドと通信して、ｉｎｐｕｔ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅのＡＰＩを呼び出して、ＷｅＣｈａｔアプリケーションで入力メソッドサービスを提供してよい。

例えば、具体的に、システムサービススレッド（例えば、ｉｎｐｕｔ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッド）は、ｂｉｎｄｅｒサービスまたはｓｏｃｋｅｔ（ソケット）サービスを用いて、別のアプリケーションのプロセスと通信してよい。

ｂｉｎｄｅｒサービスを例に用いると、図４に示される通り、３つのモジュール、サーバ、ｂｉｎｄｅｒドライバおよびクライアントがｂｉｎｄｅｒサービスアーキテクチャ内に提供される。ＡＰＰレイヤ２０１で実行中のアプリケーションプロセスはクライアントとして用いられてよく、ｆｒａｍｅｗｏｒｋレイヤ２０２によって提供される各システムサービスは、サーバとして用いられてよい。ｂｉｎｄｅｒドライバは、Ｌｉｎｕｘ（登録商標）カーネルレイヤ２０４に配置されてよく、ｂｉｎｄｅｒサービスを用いて通信する複数のプロセス（またはスレッド）の各ペアの識別子がｂｉｎｄｅｒドライバ内に記録される。

クライアント（例えば、ＷｅＣｈａｔプロセス）が関連するシステムサービスを呼び出すために、サーバ（例えば、ｉｎｐｕｔ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッド）にアクセスを試みるとき、クライアントは、ｔｒａｎｓａｃｔ（）ファンクションを用いてｂｉｎｄｅｒドライバを呼び出してよく、ｂｉｎｄｅｒドライバは、呼び出しメッセージをサーバのシステムサービススレッドに送信する。ｂｉｎｄｅｒドライバにより送信された呼び出しメッセージを受信した後、サーバのシステムサービススレッドはｂｉｎｄｅｒスレッドを開始し、ｏｎＴｒａｎｓａｃｔ（）ファンクションのパラメータに基づき、サーバのサービスコードを実行して、対応するシステムサービスを実装する。

システムサービススレッドが別のプロセスと通信するとき、システムサービススレッドは、ブロックされてよく、または、システムサービススレッドによって占有されるロックオブジェクトは長期間解放されない可能性がある。例えば、ＷｅＣｈａｔアプリケーションのあるプロセスが実行プロシージャ内で無限ループに入った場合、ＷｅＣｈａｔアプリケーションの当該プロセスと通信するシステムサービススレッドＡはブロックされる。既存のｗａｔｃｈｄｏｇメカニズムが用いられる場合、携帯電話１００は再起動するようにトリガされる。この結果、携帯電話１００のすべての現在実行中のデータが失われる。

本願のいくつかの実施形態において、ロックオブジェクトが占有される場合、端末は、第１のタイマを有効化して計時を開始するようトリガされてよい。第１のタイマが期限切れになったとき、ロックオブジェクトがまだ占有されていれば、ロックオブジェクトはタイムアウトする。この場合、端末は、ロックオブジェクトを占有するシステムサービススレッド（例えば、第１のシステムサービススレッド）の識別子を取得するようトリガされてよい。さらに、端末は、第１のシステムサービススレッドの識別子に基づき、ｂｉｎｄｅｒドライバを用いて、第１のシステムサービススレッドと通信するターゲットアプリケーションプロセスを判定してよく、当該ターゲットアプリケーションプロセスを終了させてよい。ターゲットアプリケーションプロセスが終了された後、ターゲットアプリケーションプロセスと通信する第１のシステムサービススレッドは解放される。従って、また第１のシステムサービススレッドによって占有されたロックオブジェクトも解放され、その結果、要求を有する別のシステムサービススレッドが当該ロックオブジェクトを継続して用いてよい。

代替的に、本願のいくつかの他の実施形態において、複数のアプリケーションプロセスが端末上で実行されてよく、これらのアプリケーションプロセスは、１または複数のシステムサービススレッドと通信して、関連するシステムサービスを実装してよい。第１のアプリケーションプロセスがシステムサービススレッド（例えば、第１のシステムサービススレッド）と通信するとき、第１のシステムサービススレッドは、別のアプリケーションプロセス（例えば、第２のアプリケーションプロセス）にサービスを提供できない。従って、第１のアプリケーションプロセスが第１のシステムサービススレッドを占有した後、端末は、第２のタイマを有効化して計時を開始するようトリガされてよい。第２のタイマが期限切れになったときに、第１のシステムサービススレッドがまだ占有されている、換言すると、第１のシステムサービススレッドがブロックされている場合、端末は、第１のシステムサービススレッドと現在通信中の特定のプロセス、すなわち、第１のアプリケーションプロセスを判定し、且つ、第１のアプリケーションプロセスを終了するようトリガされてよい。第１のアプリケーションプロセスが終了された後、第１のアプリケーションプロセスと通信中の第１のシステムサービススレッドは解放され、その後、要求を有する別のアプリケーションプロセスが、解放された第１のシステムサービススレッドと通信して、関連するシステムサービスを実装してよい。

また、上述の実施形態からわかるように、端末が、第１のシステムサービススレッドと通信中のアプリケーションプロセスを終了させた後、端末で実行中の別のシステムサービススレッドまたはアプリケーションプロセスは影響を受けることはなく、これにより、端末のフレームフリーズまたはスクリーンフリーズの可能性を低減し、ユーザエクスペリエンスを向上させる。

別の実施形態においては、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが端末で実行され、システムサービスプロセスは少なくとも１つのシステムサービススレッドを含む。少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき、端末は、当該ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定し、ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されたロックオブジェクトが予め設定された時間内に解放されないこと、ターゲットシステムサービススレッドがブロックされること、のうちの少なくとも１つを含み、端末は第１のアプリケーションプロセスを終了させる。

本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。説明を簡単にするため、本願のこの実施形態においては、システムサービススレッドのタイムアウトは、ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセス内のシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないことを意味してよい、または、ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセス内のシステムサービススレッドのブロッキング持続期間が予め設定された持続期間に到達したことを意味してよい。図５に示される通り、方法は、具体的に、以下の段階を含む。

５０１．端末は、ターゲットシステムサービススレッドがタイムアウトするか否かをモニタリングする。

ターゲットシステムサービススレッドは、ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセス内で実行される任意のシステムサービススレッドであってよく、例えば、ターゲットロックオブジェクト（例えば、ｉｎｐｕｔｍａｎａｇｅｒｓｅｒｖｉｃｅ．ｔｈｉｓまたはａｃｔｉｖｉｔｙｍａｎａｇｅｒｓｅｒｖｉｃｅ．ｔｈｉｓ等の任意のロックオブジェクト）を占有するシステムサービススレッドであってよく、または、別のスレッド（またはプロセス）と通信中のシステムサービススレッドであってよい。本願のこの実施形態はこの点において限定されるものではない。

具体的に、端末は、ここでも既存のｗａｔｃｈｄｏｇモニタリングメカニズムを用いてよく、端末のプロセッサは、いくつかのシステムサービススレッドによって占有されるロックオブジェクトおよび当該システムサービススレッドをモニタリングする。

例えば、プロセッサは、ｗａｔｃｈｄｏｇスレッドを用いて、ターゲットロックオブジェクトが予め設定された時間（例えば、６０秒）内に解放されるか否かをモニタリングしてよい。ターゲットロックオブジェクトが６０秒以内に解放されない場合、このことは、ターゲットロックオブジェクトを占有しているシステムサービススレッド（すなわち、ターゲットシステムサービススレッド）がタイムアウトすること、換言すると、ターゲットシステムサービスがタイムアウトすることを示している。

可能な実装において、プロセッサは、ターゲットシステムサービススレッドが、アプリケーションプロセスによって占有されているか否かをモニタリングしてよく、ターゲットシステムサービススレッドがあるアプリケーションプロセスによって占有されており、且つ占有持続期間が予め設定された閾値以上である場合、プロセッサは、ターゲットシステムサービススレッドがタイムアウトすると判定してよい。

別の例では、プロセッサは、さらに、ｗａｔｃｈｄｏｇスレッドを用いて、システムサービススレッドによって報告されたブロッキングイベントが存在するか否かをモニタリングしてよい。システムサービススレッドによって報告されたブロッキングイベントが受信されると、このことは、システムサービススレッド（この場合、システムサービススレッドはターゲットシステムサービススレッドである）がブロックされていること、換言すると、ターゲットシステムサービスがタイムアウトすることを示している。

本願のいくつかの実施形態において、端末内のｗａｔｃｈｄｏｇスレッドは、ロックオブジェクトを占有するシステムサービススレッドをシーケンシャルにポーリングしてよい。例えば、それぞれ異なるシステムサービススレッドによって占有されたロックオブジェクトが現在５つ存在する。ｗａｔｃｈｄｏｇスレッドは、５つのシステムサービススレッドにシーケンシャルに電気信号を送信する（すなわち、フィードドッグ、ｆｅｅｄ ｄｏｇ）。電気信号を受信したシステムサービススレッドは、予め設定された時間内にｗａｔｃｈｄｏｇスレッドに応答を返す必要がある（すなわち、キックドッグ、ｋｉｃｋ ｄｏｇ）。応答を受信した後、ｗａｔｃｈｄｏｇスレッドは、シーケンシャルに、次のシステムサービススレッドのためにフィードドッグする。システムサービススレッド（例えば、システムサービススレッドＡ）が予め設定された時間内に応答をｗａｔｃｈｄｏｇスレッドに返さない場合、システムサービススレッドＡによって占有されたロックオブジェクトはタイムアウトすると判定されてよい。この場合、システムサービススレッドＡがターゲットシステムサービススレッドであり、システムサービススレッドＡによって占有されたロックオブジェクトがターゲットロックオブジェクトである。

本願のいくつかの実施形態において、端末内のｗａｔｃｈｄｏｇスレッドは、ロックオブジェクトを占有していない様々なシステムサービススレッドをシーケンシャルにポーリングして、システムサービススレッドがブロックされているか否かを検出してよい。例えば、ｗａｔｃｈｄｏｇスレッドは、ロックオブジェクトを占有していない現在実行中の４つのシステムサービススレッドに、電気信号をシーケンシャルに送信してよい（すなわち、フィードドッグ）。電気信号を受信したシステムサービススレッドは、予め設定された時間内に、応答をｗａｔｃｈｄｏｇスレッドに返す必要がある（すなわち、キックドッグ）。システムサービススレッド（例えば、システムサービススレッドＢ）が、予め設定された時間内に応答をｗａｔｃｈｄｏｇスレッドに返さない場合、システムサービススレッドＢはブロックされていると判定されてよい。

５０２．ターゲットシステムサービススレッドがタイムアウトするとき、端末は、ターゲットシステムサービススレッドの識別子を取得する。

ターゲットシステムサービススレッドのブロッキングにより、ターゲットシステムサービススレッドのタイムアウトが生じる場合、ターゲットシステムサービススレッドは、ブロッキングイベントをｗａｔｃｈｄｏｇスレッドに報告する。ブロッキングイベントは、端末がターゲットシステムサービススレッドの識別子を取得するように、ブロッキングイベントの識別子、例えば、ターゲットシステムサービススレッドのＩＤ番号を保持してよい。代替的に、端末は、ｇｅｔＴｈｒｅａｄＩｄ（）ファンクションを呼び出すことで、ターゲットシステムサービススレッドのＩＤ番号を取得してよい。

ターゲットロックオブジェクトのタイムアウトにより、ターゲットシステムサービススレッドのタイムアウトが生じる場合、このことは、ターゲットロックオブジェクトを占有するターゲットシステムサービススレッドが、システムリソース（例えば、メモリリソース）を占有し続けており、システムリソースを解放しないことを示している。従って、その後、別のスレッドが関連するサービスを実装するために、そのターゲットロックオブジェクトを取得できない。この場合、可能性として、端末のフレームフリーズあるいはスクリーンフリーズすら生じ得る。

従って、ターゲットロックオブジェクトがタイムアウトするとき、端末は、Ｊａｖａ（登録商標）ネイティブインタフェース（Ｊａｖａ（登録商標）Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ，ＪＮＩ）インタフェースを呼び出して、ターゲットロックオブジェクトを占有する特定のターゲットシステムサービススレッドの識別子を検索してよい。例えば、端末のプロセッサは、ＪＮＩインタフェース内のＧｅｔＬｏｃｋＯｗｎｅｒＴｈｒｅａｄＩｄ（）ファンクションを呼び出してよい。当該ファンクションの戻り値は、ターゲットロックオブジェクトを占有するターゲットシステムサービススレッドのＩＤ番号（すなわち、ターゲットシステムサービススレッドの識別子）である。例えば、ＧｅｔＬｏｃｋＯｗｎｅｒＴｈｒｅａｄＩｄ（）ファンクションの戻り値が０１であり、０１がｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅ（ウィンドウマネージャサービス）スレッドのＩＤ番号である場合、ターゲットシステムサービススレッドは、ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドである。

代替的に、ターゲットシステムサービススレッドの識別子は、端末におけるスレッドを一意に識別可能なターゲットシステムサービススレッドの名前等のパラメータであってよいことが理解され得ることはもちろんである。本願のこの実施形態はこの点において限定されるものではない。

５０３．端末は、ターゲットシステムサービススレッドの識別子に基づき、ターゲットシステムサービススレッドと通信するアプリケーションプロセスをクエリする。

ターゲットシステムサービススレッドがタイムアウトする原因は、ターゲットシステムサービススレッドと通信するアプリケーションプロセスがブロックされている、または、無限ループに入っている等であってよい。従って、段階５０３において、タイムアウトするターゲットシステムサービススレッドを判定した後、端末のプロセッサは、さらに、ターゲットシステムサービススレッドの識別子に基づき、ターゲットシステムサービススレッドと通信する特定のアプリケーションプロセスをメモリ内でクエリしてよい。

ターゲットシステムサービススレッドが、ｂｉｎｄｅｒサービスを用いてアプリケーションプロセスと通信する例を用いる。ここでも図４に示される通り、各システムサービススレッドのＩＤ番号等の登録情報がｂｉｎｄｅｒドライバに記録されるので、ｓｙｓｔｅｍ ｓｅｒｖｅｒプロセス内の各システムサービススレッドは、前もってｂｉｎｄｅｒドライバに登録してよい。

例えば、ｂｉｎｄｅｒドライバに登録するとき、ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドは、ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドのＩＤ番号およびｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドのファンクション、例えば、ｗｉｎｄｏｗ（ウィンドウ）作成ファンクションを報告してよい。この後、アプリケーションプログラムレイヤ２０１におけるＡＰＰ１プロセスが、当該作成ファンクションを用いる必要がある場合、ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドと通信するためのプロセス間通信要求が、ｂｉｎｄｅｒドライバに対し開始されてよい。プロセス間通信要求を受信した後、ｂｉｎｄｅｒドライバは登録情報に基づき、ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドに対し、対応するＷｉｎｄｏｗを作成するよう要求して、ＡＰＰ１プロセスとｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッドとの間のＩＰＣ通信プロシージャを完了させてよい。

換言すると、ｂｉｎｄｅｒドライバは、ＩＰＣ通信を実行する各システムサービススレッドとアプリケーションプロセスとの間の対応関係を維持するよう構成されてよい。

例えば、表１に示される通り、サードパーティのアプリケーションプロセス（またはｄａｅｍｏｎプロセス）のプロセス間通信要求を受信した後は毎回、ｂｉｎｄｅｒドライバは、上述の登録情報内に、サードパーティのアプリケーションプロセス（またはｄａｅｍｏｎプロセス）と、サードパーティのアプリケーションプロセス（またはｄａｅｍｏｎプロセス）と通信するシステムサービススレッドとの間の対応関係を記録してよい。段階５０３において、ターゲットシステムサービススレッドの識別子を判定した後、端末は、表１に示された登録情報から、ターゲットシステムサービススレッド（例えば、ｗｉｎｄｏｗ ｍａｎａｇｅｒ ｓｅｒｖｉｃｅスレッド）と通信するアプリケーションプロセスが、ＷｅＣｈａｔアプリケーションプロセスであることを見つけてよい。ＷｅＣｈａｔアプリケーションプロセスの識別子は１１である。

また、ターゲットシステムサービススレッドが登録情報に記録されていない場合、このことは、ターゲットシステムサービススレッドがＩＰＣ通信を実行しない可能性があること、または、ターゲットシステムサービススレッドがサードパーティのアプリケーションプロセス（またはｄａｅｍｏｎプロセス）と別の態様（例えば、ｓｏｃｋｅｔサービスを用いる）で通信する可能性があることを示している。

例えば、ターゲットシステムサービススレッドは、ｓｏｃｋｅｔサービスを用いてアプリケーションプロセスと通信してよい。本願のこの実施形態において、システムサービススレッドが、ｓｏｃｋｅｔサービスに基づきアプリケーションプロセスと通信する場合、端末は、当該アプリケーションプロセスの識別子を能動的に記録してよい。このように、ターゲットシステムサービスがタイムアウトする場合、例えば、ターゲットシステムサービススレッドとアプリケーションプロセスとの間のｓｏｃｋｅｔ接続の確立がタイムアウトする場合、端末は、ターゲットシステムサービススレッドと通信するアプリケーションプロセスの記録された識別子をクエリして、ターゲットシステムサービスのタイムアウトを生じさせた特定のアプリケーションプロセスを判定してよい。

５０４．端末は、上述のアプリケーションプロセスを終了させて、ターゲットシステムサービススレッドのタイムアウトにより生じたフレームフリーズを除去する。

端末が、ターゲットシステムサービススレッドと通信する特定のアプリケーションプロセスを判定した後、端末のプロセッサは、当該アプリケーションプロセスを終了（ｋｉｌｌ）させてよい。アプリケーションプロセスが終了された後、アプリケーションプロセスと通信中のターゲットシステムサービススレッドが解放される。このように、ターゲットシステムサービススレッドによって占有されているターゲットロックオブジェクトは解放されてよく、元々ブロックされていたターゲットシステムサービススレッドが対応するシステムサービスの提供を継続してよく、これにより、システムサービスのタイムアウトにより生じるブロッキングまたはスクリーンフリーズの可能性を低減させる。

さらに、端末がアプリケーションプロセスを終了させた後、プロセッサはさらに、ユーザが再起動されたＡＰＰで処理を継続できるように、当該アプリケーションプロセスを再起動、例えば、ＷｅＣｈａｔアプリケーションを再起動してよい。

このように、アプリケーションプロセスが終了または再起動された後、当該アプリケーションプロセスと通信中のターゲットシステムサービススレッドによって占有されたターゲットロックオブジェクトは解放されてよく、ターゲットシステムサービススレッドのブロッキングが除去され、端末における別のシステムサービスの実行中のプロシージャは影響を受けない。

アプリケーションプロセスを直接終了または再起動することに加え、代替的に、当業者はアプリケーションプロセスを回復するための回復ポリシーを設定してよいことはもちろんである。例えば、複数のシステムサービススレッドがタイムアウトする場合、アプリケーションプロセスの優先度に基づき、端末は、より低い優先度を有するアプリケーションプロセスを直接終了させ、より高い優先度を有するアプリケーションプロセスを再起動させてよい。

また、アプリケーションプロセスを終了させるとき、端末は、さらに、現在のアプリケーションプロセスの実行の進行状況を記録してよい。このようにして、アプリケーションプロセスを再起動させた後、端末は、当該アプリケーションプロセスを、記録された実行の進行状況に基づき、元のステータスに回復させてよい。例えば、ＷｅＣｈａｔアプリケーションプロセスがアプリケーションプロセスであり、ＷｅＣｈａｔアプリケーションプロセスを終了させるとき、端末は、ユーザＡとのチャット情報を実行の進行状況として記録してよい。このようにして、ＷｅＣｈａｔアプリケーションプロセスを再起動させるとき、端末は、ＷｅＣｈａｔアプリケーションプロセスを、記録された実行の進行状況に基づき、再起動前のステータスに回復させてよく、その結果、サービスは、アプリケーションプロセスの再起動の前後で割り込まれることがなく、これにより、ユーザエクスペリエンスを向上させる。

さらに、アプリケーションプロセスを回復させるとき、端末は、ＵＩインタフェースを用いて、ユーザに対し待機を依頼するプロンプトメッセージをユーザに示して、ユーザが、端末が現在フリーズしていると誤認識することを防いでよい。例えば、図６の（ａ）に示される通り、アプリケーションプロセスを再起動するとき、端末は、ユーザに対し、アプリケーションプロセスが再起動中であることを通知してよい。図６の（ｂ）に示される通り、アプリケーションプロセスを終了させた後、端末は、ユーザに対し、アプリケーションプロセスが、当該アプリケーションプロセスによって生じたシステムサービスのタイムアウトにより終了されたことを通知してよい。代替的に、図６の（ｃ）に示される通り、ターゲットシステムサービスのタイムアウトを生じさせたアプリケーションプロセスを判定した後、端末は、さらに、プロンプトメッセージダイアログボックス内に、アプリケーションプロセスを終了させるか否かを示すプロンプトメッセージを表示させてよい。ユーザがアプリケーションプロセスを終了させると決定した場合、端末は、アプリケーションプロセスを終了する。

代替的に、アプリケーションプロセスを終了させるとき、端末は、さらに、ＵＩインタフェース上に表示されたアプリケーションプロセスのアプリケーションインタフェーススナップショットを保存してよい。例えば、図７に示される通り、アプリケーションプロセスがＷｅＣｈａｔプロセスである場合、ＷｅＣｈａｔプロセスが終了される前に、ＵＩインタフェース上に現在表示されているＷｅＣｈａｔアプリケーションのアプリケーションインタフェース７１のスナップショットがローカルに保存されてよい。ここでも図７に示される通り、ＷｅＣｈａｔプロセスを再起動させるとき、端末は、ＷｅＣｈａｔプロセスの終了時に保存されたアプリケーションインタフェース７１のスナップショットをまず表示させて、同時にバックグランドでＷｅＣｈａｔプロセスを起動してよい。例えば、端末はアプリケーションインタフェーススナップショットを２秒間表示させ、アプリケーションインタフェーススナップショットの表示と同時にＷｅＣｈａｔプロセスを再起動させる。このようにすると、ＷｅＣｈａｔプロセスの再起動の時間を視覚的に短くでき、これにより、ユーザエクスペリエンスを向上させる。

代替的に、システムサービスタイムがタイムアウトするたびに、端末は、タイムアウトを生じさせた特定のシステムサービスおよびアプリケーションプロセスを記録してよい。あるアプリケーションプロセスが頻繁にタイムアウトを生じさせる場合、このことは、当該アプリケーションプロセスの実行により生じるフレームフリーズのリスクが比較的高いことを示している。この後、当該アプリケーションプロセスを実行するときに、端末は、追加のシステムリソースを当該アプリケーションプロセスに割り当てる、現在の冗長プロセスを消去する等によって、当該アプリケーションプロセスにより生じるタイムアウトを防いでよい。もちろん、端末がフレームフリーズのリスクが比較的高いといった後続のシナリオを予測し、および、端末がフレームフリーズのリスクが比較的高いシナリオにおいてアプリケーションプロセスによって生じるタイムアウトを前もって防ぐように、端末は、さらに、タイムアウトが生じるたびに特定の実行中のシナリオ、例えば、決済シナリオまたはコールシナリオに関する統計を収集してよい。

端末は、タイムアウトが引き起こされるたびに、タイムアウトを生じさせた特定の記録済みシステムサービスおよびアプリケーションプロセスをサーバに履歴データとして報告してよく、サーバは、ビッグデータ統計に基づき、当該端末に対し、予測ポリシー、または、前もって防止される必要のある、容易にタイムアウトを生じさせるアプリケーションプロセスを判定することが理解できるであろう。本願のこの実施形態はこの点において限定されるものではない。

段階５０１から５０４までの端末のアクションは、図１中のプロセッサ１０１が、メモリ１０３内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。

システムサービススレッドおよびアプリケーションプロセスが、ｂｉｎｄｅｒサービスプロセスに基づき、プロセス間通信を実行する場合、端末は、プロセス間通信サービスを実装するためのｂｉｎｄｅｒスレッドを割り当てる。ｂｉｎｄｅｒスレッド数が多すぎる場合、ｂｉｎｄｅｒサーバにおけるｂｉｎｄｅｒリソースが枯渇する。その結果、プロセス間通信を要求する別のプロセスは、ｂｉｎｄｅｒスレッドを申請できない。従って、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。図８に示される通り、方法は以下の段階を含む。

８０１．ｂｉｎｄｅｒスレッドの総数が予め設定された値に到達したとき、端末は、各ｂｉｎｄｅｒスレッドによってサービスされるアプリケーションプロセスを判定する。

具体的に、端末のプロセッサは、現在の端末でｂｉｎｄｅｒサービスを提供するｂｉｎｄｅｒスレッドの総数をカウントしてよい。一般に、オペレーティングシステムによってサポート可能なｂｉｎｄｅｒスレッド数は固定であり、例えば１６である。従って、カウントされたｂｉｎｄｅｒスレッドの総数が１６である場合、すなわち、ｂｉｎｄｅｒスレッドがいっぱいであるとき、プロセッサは、さらに、１６個のｂｉｎｄｅｒスレッドの各々によってサービスされるアプリケーションプロセスを判定するようトリガされてよい。

例えば、ｂｉｎｄｅｒドライバが、サードパーティのアプリケーションプロセス（またはｄａｅｍｏｎプロセス）によって送信されたプロセス間通信要求を受信した後、毎回ｂｉｎｄｅｒドライバは、ｂｉｎｄｅｒリソースプールから、１または複数のｂｉｎｄｅｒスレッドをサードパーティのアプリケーションプロセス（またはｄａｅｍｏｎプロセス）に割り当てて、プロセス間通信サービスを実装する。表２に示される通り、互いに通信するシステムサービススレッドと、サードパーティのアプリケーションプロセス（またはｄａｅｍｏｎプロセス）との各ペアの対応関係に加え、ｂｉｎｄｅｒドライバは、さらに、登録情報内に、システムサービススレッドと、サードパーティのアプリケーションプロセスとの各ペアにＩＰＣサービスを提供するｂｉｎｄｅｒスレッドの識別子を記録してよい。従って、段階８０１において、端末は、表２に示された登録情報において、各ｂｉｎｄｅｒスレッドによってサービスされるアプリケーションプロセスをクエリしてよい。

８０２．端末は、すべてのアプリケーションプロセスの各々によって占有されるｂｉｎｄｅｒスレッド数をカウントする。

プロセス間通信を実行するために、１つのアプリケーションプロセスが複数のｂｉｎｄｅｒスレッドを占有する可能性があるので、プロセッサは、各ｂｉｎｄｅｒスレッドによってサービスされるアプリケーションプロセスに基づき、１つのアプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッド数をカウントしてよい。例えば、上述の１６個のｂｉｎｄｅｒスレッドでは、ＷｅＣｈａｔアプリケーションプロセスが８個のｂｉｎｄｅｒスレッドを占有し、音楽アプリケーションプロセスが５個のｂｉｎｄｅｒスレッドを占有し、ブラウザアプリケーションプロセスが３個のｂｉｎｄｅｒスレッドを占有する。

８０３．端末は、各アプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッドの数に基づき、少なくとも１つのアプリケーションプロセスを終了させる。

例えば、端末は、最大数のｂｉｎｄｅｒスレッドを占有しているアプリケーションプロセス、例えば、ＷｅＣｈａｔアプリケーションプロセスを終了または再起動して、ＷｅＣｈａｔアプリケーションプロセスによって占有されている８個のｂｉｎｄｅｒスレッドを解放してよい。解放されたｂｉｎｄｅｒスレッドは、プロセス間通信を待機中の別のプロセス（または別のスレッド）によって用いられてよい。

代替的に、端末は、さらに、現在すべてが占有されているｂｉｎｄｅｒスレッドを解放すべく、アプリケーションプロセスを終了または再起動してよく、ここで当該アプリケーションプロセスによって占有されているｂｉｎｄｅｒスレッド数は、予め設定された値より大きい。代替的に、端末はさらに、アプリケーションプロセスの優先度に基づき、より低い優先度を有するアプリケーションプロセスによって占有されているｂｉｎｄｅｒスレッドが解放されるように、より低い優先度を有するアプリケーションプロセスを解放してよく、より高い優先度を有するアプリケーションプロセスを確保して、より高い優先度を有するアプリケーションプロセスが終了（または再起動）された後に端末の実行の実行ステータスおよびユーザエクスペリエンスが影響を受けることを回避してよい。

もちろん、代替的に、ユーザは、ｂｉｎｄｅｒスレッドがすべて占有されたとき終了されるべきアプリケーションプロセスのホワイトリストまたはブラックリストを手動で設定してよい。このようにして、ｂｉｎｄｅｒスレッドがすべて占有されたとき、ホワイトリスト内のアプリケーションプロセスは確保されてよく、一方でブラックリスト内のアプリケーションプロセスが終了または再起動されてよい。

当業者が、ｂｉｎｄｅｒスレッドがすべて占有された場合の実際の経験または実際のアプリケーションシナリオに基づき、アプリケーションプロセス回復ポリシーを設定してよいことを理解されたい。本願のこの実施形態はこの点において限定されるものではない。

また、段階８０１から８０３までの端末のアクションは、図１中のプロセッサ１０１が、メモリ１０３内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。

さらに、ｂｉｎｄｅｒスレッドがすべて占有された場合に引き起こされる端末のフレームフリーズを防ぐべく、本願の一実施形態は、さらに、システムサービスタイムアウト処理方法を提供する。図９に示される通り、方法は、以下の段階を含む。

９０１．端末は、ターゲットアプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッド数をカウントする。

ターゲットアプリケーションプロセスは、端末のＡＰＰレイヤにインストールされた任意のアプリケーションプロセスであってよい。本願のこの実施形態はこの点において限定されるものではない。

通常、１つのプロセスは複数のスレッドを含むので、ターゲットアプリケーションプロセスの実行中、当該プロセスは、別のプロセス（例えば、システムサービスプロセス）と通信する必要がある。この場合、ｂｉｎｄｅｒドライバは、ターゲットアプリケーションプロセス内にプロセス間通信を実装するためのｂｉｎｄｅｒスレッドを作成する。従って、段階９０１において、端末は、プロセッサを用いて、ターゲットアプリケーションプロセスによって現在占有されているｂｉｎｄｅｒスレッド数を定期的にカウントしてよい。

例えば、端末は、ＩＰＣスレッド状態（ＩＰＣ Ｔｈｒｅａｄ Ｓｔａｔｅ）にｔｒａｎｓａｃｔ（）ファンクションが入った時点で、ターゲットアプリケーションプロセスによって作成されたｂｉｎｄｅｒスレッドをカウントして、ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッドの数を取得してよい。

９０２．ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッドの数が第１の閾値以上である場合、端末は、これらのｂｉｎｄｅｒスレッドによって呼び出された特定のＡＰＩに関する統計の収集を開始する。

ＡＰＩは、１または複数の予め定められたファンクションであり、アプリケーションプログラムおよび開発者が、ソフトウェアまたはハードウェアに基づき、グループのルーティンにアクセス可能になる能力を提供する。このようにして、アプリケーションプログラムはソースコードにアクセスする必要がなく、開発者は、端末内の動作メカニズムの詳細を理解していなくても、対応する機能を実装できる。具体的に、ＡＰＩは、Ｌｉｎｕｘ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）システムにおける任意のＡＰＩであってよく、例えば、ファイルオープンに用いられるＡＰＩ：ｏｐｅｎ｛｝、書き込みに用いられるＡＰＩ：ｗｒｉｔｅ｛｝またはメッセージキューへのアクセスに用いられるＡＰＩ：ｍｓｇｇｅｔ｛｝が挙げられる。本願のこの実施形態はこの点において限定されるものではない。

例えば、第１の閾値は８であってよい。具体的に言うと、ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッド数が８に到達すると、ｂｉｎｄｅｒスレッドリソースの枯渇の潜在的リスクが存在する。従って、ｂｉｎｄｅｒスレッドリソースの枯渇を回避すべく、端末のプロセッサは、さらに、これらのｂｉｎｄｅｒスレッドによって呼び出された特定のＡＰＩに関する統計を収集することで、ターゲットアプリケーションによって現在占有されているこれらのｂｉｎｄｅｒスレッドが、悪意に占有されているか否かを判定してよい。

例えば、各ｈａｎｄｌｅｒオブジェクトに対し、カウンタが設定されてよく、端末は当該ｈａｎｄｌｅｒオブジェクトを呼び出すことで、ＡＰＩを呼び出す。従って、ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッド数が８以上である場合、端末は、各ｈａｎｄｌｅｒオブジェクトのカウンタに、カウントを開始するようトリガしてよい。ｂｉｎｄｅｒスレッドが１つのｈａｎｄｌｅｒオブジェクトを呼び出すたびに、ｈａｎｄｌｅｒオブジェクトのカウンタは１つずつ増える。このようにして、各ＡＰＩオブジェクトが呼び出される回数がカウントされてよい。

代替的に、端末は、さらに、メモリ内に各ｂｉｎｄｅｒスレッドと、当該ｂｉｎｄｅｒスレッドによって呼び出されるＡＰＩとの間の対応関係を記録してよい。従って、表３に示される通り、端末は、当該対応関係に基づき、ターゲットアプリケーションプロセスによって占有された各ｂｉｎｄｅｒスレッドによって特定に呼び出されたＡＰＩに関する統計を収集してよい。

ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッドの数は、同時に占有されたｂｉｎｄｅｒスレッドの数であってよく、または、予め設定された期間（例えば、３秒以内）内に占有されたｂｉｎｄｅｒスレッドの数であってよいことに留意されたい。本願のこの実施形態はこの点において限定されるものではない。

９０３．ＡＰＩ（すなわち、ターゲットＡＰＩ）が呼び出される回数が第２の閾値より大きい場合、端末は、ターゲットアプリケーションプロセスのために新しいｂｉｎｄｅｒスレッドを作成することを停止する。

例えば、第２の閾値は１６であってよい。具体的に言うと、同一のＡＰＩ（すなわち、ターゲットＡＰＩ）を呼び出すｂｉｎｄｅｒスレッドの数が１６より大きい場合、このことは、ターゲットＡＰＩが比較的負荷が大きい状態にあることを示し、ｂｉｎｄｅｒスレッドが悪意にターゲットＡＰＩを呼び出しているリスクが存在し得る。この場合、当該ｂｉｎｄｅｒスレッドリソースの利用率は比較的高く、当該ｂｉｎｄｅｒスレッドは頻繁に単一のＡＰＩを呼び出す。従って、すべての占有されたｂｉｎｄｅｒスレッドによって引き起こされるブロッキングまたはフレームフリーズを回避すべく、ターゲットアプリケーションプロセスがｂｉｎｄｅｒドライバに対し、新しいｂｉｎｄｅｒスレッドの作成を要求したとき、ｂｉｎｄｅｒドライバは、ターゲットアプリケーションプロセスの当該要求への応答を停止し、作成されるべきｂｉｎｄｅｒスレッドを待機状態に設定し、ｂｉｎｄｅｒスレッドリソースが十分になった時点で、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドを作成してよい。

随意で、作成されるべきｂｉｎｄｅｒスレッドを待機状態に設定したとき、端末はさらに、開発者が記録されたログに基づき、ターゲットアプリケーションプロセスがフレームフリーズに遭遇した原因を識別できるように、新しく作成されたｂｉｎｄｅｒスレッドの実行状態を記録するためのログ（ｌｏｇ）を挿入してよい。

同様に、ターゲットＡＰＩが呼び出される回数は、ターゲットＡＰＩが同時に呼び出される回数であってよく、または、ターゲットＡＰＩが予め設定された期間内（例えば、３秒以内）に呼び出される回数であってよい。本願のこの実施形態はこの点において限定されるものではない。

９０４．ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッドの数が、第１の閾値未満の場合、端末は、ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドを作成する。

占有されたｂｉｎｄｅｒスレッドが解放された後、ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッドの数は低減する。当該数が第１の閾値未満の値まで低減すると、このことは、ターゲットアプリケーションが使用できる利用可能なｂｉｎｄｅｒスレッドが現在存在することを示している。従って、端末は、段階９０３で作成されるべきｂｉｎｄｅｒスレッドをウェイクアップすべく、作成されるべきｂｉｎｄｅｒスレッドの状態を、待機状態から作成状態へ設定して、且つ、ｂｉｎｄｅｒスレッドの作成を開始してよい。

また、ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッドが予め設定された期間内に解放されない場合、作成されるべきｂｉｎｄｅｒスレッドは、待機状態で維持され、作成できない。この場合、ターゲットアプリケーションプロセスは、ＡＮＲ（アプリケーション不応答、Ａｐｐｌｉｃａｔｉｏｎ Ｎｏｔ Ｒｅｓｐｏｎｄｉｎｇ）メカニズムにより、ユーザに対し、ターゲットアプリケーションプロセスの実行の継続を許容するか、または、ターゲットアプリケーションプロセスを強制終了するかをプロンプトしてよい。

別の可能な実装において、ターゲットアプリケーションプロセスにより占有されたｂｉｎｄｅｒスレッドであり、且つ段階９０１でカウントされたｂｉｎｄｅｒスレッドの数が、第１の閾値以上である場合、例えば、ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッド数が８より大きい場合、このケースでは、比較的多数のｂｉｎｄｅｒスレッドが占有されているので、換言すると、ｂｉｎｄｅｒスレッドリソースの枯渇の潜在的リスクが存在するので、端末は、段階９０３、すなわち、ターゲットアプリケーションプロセスにおいて新しく作成されたｂｉｎｄｅｒスレッドの実行を停止すること、作成されるべきｂｉｎｄｅｒスレッドを待機状態に設定すること、およびｂｉｎｄｅｒスレッドリソースが十分（例えば、ターゲットアプリケーションプロセスによって占有されたｂｉｎｄｅｒスレッド数が第１の閾値未満）になった時点で、新しいｂｉｎｄｅｒスレッドを作成すること、を実行することを直接トリガされてよい。本願のこの実施形態はこの点において限定されるものではない。

段階９０１から９０４までの端末のアクションは、図１中のプロセッサ１０１が、メモリ１０３内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。

上述の機能を実装すべく、端末等は、当該機能を実行するための対応するハードウェア構造および／またはソフトウェアモジュールを含むことが理解できるであろう。当業者は、本明細書で開示した実施形態中で説明した例と組み合わせて、ユニット、アルゴリズムおよび段階がハードウェアまたはハードウェアとコンピュータソフトウェアとの組み合わせによって実装されてよいことを容易に認識すべきである。ある機能が、ハードウェアまたはコンピュータソフトウェア駆動のハードウェアにより実行されるか否かは、本技術的解決手段の特定の適用および設計上の制約により決まる。当業者は、それぞれの特定の適用のために、説明された諸機能を実装すべく異なる方法を用いてよいが、当該実装が本願の実施形態の範囲を超えるとみなされるべきではない。

本願の実施形態において、端末は、上述の方法の例に基づき、機能モジュールに分割されてよい。例えば、各機能モジュールは、各対応する機能に基づく分割により得られてよく、または、２または２より多い機能が１つの処理モジュールに統合されてよい。統合モジュールは、ハードウェアの形態で実装されてよく、または、ソフトウェア機能モジュールの形態で実装されてよい。本願のこの実施形態において、モジュール分割は例示的なものであり、論理的な機能分割に過ぎないことに留意されたい。実際の実装においては、別の分割態様が用いられてよい。

各機能モジュールは、各機能に基づく分割により取得される場合、図１０が上述の実施形態における端末の可能な概略構造図である。端末は、タイムアウト検出ユニット１００１、判定ユニット１００２、タイムアウト処理ユニット１００３およびディスプレイユニット１００４を含む。

タイムアウト検出ユニット１００１は、端末が図５中のプロシージャ５０１を実行することをサポートするよう構成されている。判定ユニット１００２は、端末が図５中のプロシージャ５０２および５０３、図８中のプロシージャ８０１および８０２、および図９中のプロシージャ９０１および９０２を実行することをサポートするよう構成されている。タイムアウト処理ユニット１００３は、端末が図５中のプロシージャ５０４、図８中のプロシージャ８０３、および図９中のプロシージャ９０３および９０４を実行することをサポートするよう構成されている。ディスプレイユニット１００４は、ターゲットシステムサービススレッドがタイムアウトした原因を表示する、または、ターゲットアプリケーションプロセスを終了させるプロンプトメッセージを表示するよう構成されている。上述した方法の実施形態における段階に関するすべての関連する内容が、対応する機能モジュールの機能の説明に引用されてよく、詳細についてはここで再度説明しない。

統合ユニットが用いられる場合、タイムアウト検出ユニット１００１、判定ユニット１００２およびタイムアウト処理ユニット１００３が処理モジュールに統合されてよく、ディスプレイユニット１００４はディスプレイモジュールとして用いられる。

この場合、図１１が上述の実施形態における端末の可能な概略構造図である。処理モジュール１１０１は、端末のアクションを制御および管理するよう構成されている。ディスプレイモジュール１１０２は、ユーザにより入力される情報、または、ユーザのために提供される情報および端末の様々なメニューを表示するよう構成されている。また、端末は、さらに、命令またはデータを格納するよう構成されたストレージモジュール１１０３、別の端末デバイスと通信するよう構成された通信モジュール１１０４等を含んでよい。

例えば、処理モジュール１１０１は、中央演算処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ，ＣＰＵ）、ＧＰＵ、汎用プロセッサ、デジタル信号プロセッサ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ，ＤＳＰ）、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ－Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ，ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ，ＦＰＧＡ）、または別のプログラマブル論理デバイス、トランジスタ論理デバイス、ハードウェアコンポーネントまたはこれらの任意の組み合わせ等のプロセッサまたはコントローラであってよい。処理モジュールは、本願で開示した内容を参照して説明した様々な例示的な論理ブロック、モジュールおよび回路を実装または実行してよい。代替的に、プロセッサは、コンピューティング機能を実装する複数のプロセッサの組み合わせ、例えば、１または複数のマイクロプロセッサの組み合わせ、または、ＤＳＰとマイクロプロセッサとの組み合わせであってよい。

ディスプレイモジュール１１０２はディスプレイであってよく、具体的には、ディスプレイは、液晶ディスプレイまたは有機発光ダイオード等の形態で構成されてよい。また、タッチパッドは、さらにディスプレイに統合されてよく、ディスプレイ上またはディスプレイ近傍のタッチイベントを収集し、収集されたタッチ情報を別のコンポーネント（例えば、プロセッサ）に送信するよう構成されている。

ストレージモジュール１１０３は、メモリであってよい。メモリは、高速ランダムアクセスメモリ（ＲＡＭ）を含んでよく、さらに、不揮発性メモリ、例えば、磁気ディスク記憶デバイス、フラッシュメモリデバイス、または別の揮発性ソリッドステートメモリを含んでよい。

通信モジュール１１０４は、送受信機、送受信機回路、入力／出力デバイスまたは通信インタフェース等であってよい。例えば、具体的に、通信モジュール１３０３はＢｌｕｅｔｏｏｔｈ（登録商標）装置、Ｗｉ－Ｆｉ（登録商標）装置または周辺機器インタフェース等であってよい。

処理モジュール１１０１がプロセッサであり、通信モジュール１１０４が無線周波数回路であり、ストレージモジュール１１０３がメモリであり、ディスプレイモジュール１１０２がディスプレイである場合、本願のこの実施形態で提供される端末は、図１に示された携帯電話１００であってよい。

上述の実施形態の全部または一部が、ソフトウェア、ハードウェア、ファームウェアまたはこれらの任意の組み合わせを用いて実装されてよい。実施形態を実装すべくソフトウェアプログラムが用いられる場合、実施形態は、コンピュータプログラムプロダクトの形態で全体的または部分的に実装されてよい。コンピュータプログラムプロダクトは、１または複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされ、コンピュータ上で実行されるとき、本願の実施形態によるプロシージャまたは機能が全部または部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワークまたは他のプログラマブル装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に格納されてよく、または、コンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に送信されてよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータサーバまたはデータセンタから、別のウェブサイト、コンピュータ、サーバまたはデータセンタへと、有線（例えば、同軸ケーブル、光ファイバまたはデジタル加入者線（ＤＳＬ））または無線（例えば、赤外線、無線およびマイクロ波等）の態様で送信されてよい。コンピュータ可読記憶媒体は、コンピュータでアクセス可能な任意の使用可能な媒体、または、サーバ若しくはデータセンタ等の１または複数の使用可能な媒体を統合したデータ記憶デバイスであってよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスクまたは磁気テープ）、光媒体（例えば、ＤＶＤ）または半導体媒体（例えば、ソリッドステートドライブ、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｉｓｋ （ＳＳＤ））等であってよい。

上述の説明は、本願の特定の実装に過ぎず、本願の保護範囲を限定することを意図するものではない。本願で開示した技術的範囲内での変形例または置換例は、本願の保護範囲に属するものとする。従って、本願の保護範囲は、特許請求の範囲に係る保護範囲によって決まるものとする。
（項目１）
端末に適用されるシステムサービスタイムアウト処理方法であって、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが上記端末で実行されており、上記システムサービスプロセスは少なくとも１つのシステムサービススレッドを含み、
上記少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき、上記端末によって、上記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定する段階であって、上記ターゲットシステムサービススレッドの上記タイムアウトは、上記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、上記ターゲットシステムサービススレッドがブロックされていることのうち少なくとも１つを含む、段階と、
上記端末によって、上記第１のアプリケーションプロセスを終了させる段階と、を備える、方法。
（項目２）
上記端末によって、上記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定する上記段階は、
上記端末によって、格納された登録情報に対し、上記ターゲットシステムサービススレッドと通信する上記第１のアプリケーションプロセスをクエリする段階であって、プロセス間通信ＩＰＣを実行するシステムサービススレッドと、アプリケーションプロセスとの間の対応関係が上記登録情報に記録される、段階を含む、項目１に記載の方法。
（項目３）
上記端末によって、上記第１のアプリケーションプロセスを終了させる上記段階の後、上記方法は、
上記端末によって、上記第１のアプリケーションプロセスを再起動する段階を備える、項目１または２に記載の方法。
（項目４）
上記端末によって、現在実行中のｂｉｎｄｅｒｂｉｎｄｅｒスレッドの総数Ｎをモニタリングする段階であって、Ｎは０以上の整数である、段階と、
ｂｉｎｄｅｒスレッドの上記総数が第１の予め設定された値より大きい場合、上記端末によって、Ｎ個の上記ｂｉｎｄｅｒスレッドの各々によりサービスされるアプリケーションプロセスを判定する段階と、
上記端末によって、すべてのアプリケーションプロセスの各々により占有されるｂｉｎｄｅｒスレッドの数をカウントする段階と、
第１のターゲットアプリケーションプロセスにより占有されるｂｉｎｄｅｒスレッドの数が第２の予め設定された値より大きい場合、上記端末によって、上記第１のターゲットアプリケーションプロセスを終了させる段階と、をさらに備える、項目１から３のいずれか一項に記載の方法。
（項目５）
第２のターゲットアプリケーションプロセスにより占有されるｂｉｎｄｅｒスレッドの数が上記第２の予め設定された値より大きく、上記第２のターゲットアプリケーションプロセスの優先度が上記第１のターゲットアプリケーションプロセスの優先度より高い場合、上記方法は、さらに、
上記端末によって、上記第２のターゲットアプリケーションプロセスを終了させる段階と、
上記端末によって、上記第２のターゲットアプリケーションプロセスを再起動させる段階と、を備える、項目４に記載の方法。
（項目６）
上記端末が上記第２のターゲットアプリケーションプロセスを終了させるとき、上記方法は、さらに、
上記端末によって、上記第２のターゲットアプリケーションプロセスの実行の進行状況を記録する段階を備え、
上記端末によって、上記第２のターゲットアプリケーションプロセスを再起動させる上記段階は、
上記端末によって、上記実行の進行状況に基づき、上記第２のターゲットアプリケーションプロセスを、上記実行の進行状況と同一の実行ステータスに回復させる段階を含む、項目５に記載の方法。
（項目７）
上記端末によって、ターゲットアプリケーションにＩＰＣサービスを提供するｂｉｎｄｅｒスレッドの数Ｍをカウントする段階であって、Ｍは０以上の整数である、段階と、
上記端末によって、上記ｂｉｎｄｅｒスレッドの数Ｍが第１の閾値以上であるとき、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する段階と、をさらに備える、項目１から６のいずれか一項に記載の方法。
（項目８）
上記端末によって、上記ｂｉｎｄｅｒスレッドの数が第１の閾値より大きいとき、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する上記段階は、
上記端末によって、Ｍ個の上記ｂｉｎｄｅｒスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェースＡＰＩに関する統計を収集する段階と、
１つのＡＰＩが呼び出される回数が第２の閾値より大きい場合、上記端末によって、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成要求への応答を停止する段階と、を含む、項目７に記載の方法。
（項目９）
上記端末によって、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する上記段階の後、上記方法は、さらに、
上記ターゲットアプリケーションに上記ＩＰＣサービスを提供する上記ｂｉｎｄｅｒスレッドの数Ｍが上記第１の閾値未満の場合、上記端末によって、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドを作成する段階を備える、項目７または８に記載の方法。
（項目１０）
上記端末によって、上記ターゲットシステムサービススレッドがタイムアウトした原因を表示する段階、または、上記第１のアプリケーションプロセスを終了させるプロンプトメッセージを表示させる段階をさらに備える、項目１から９のいずれか一項に記載の方法。
（項目１１）
上記ターゲットシステムサービススレッドがブロックされていることは、
上記ターゲットシステムサービススレッドと、上記第１のアプリケーションプロセスとの間の通信持続期間が第１の予め設定された値より大きいこと、および、実行プロシージャにおける上記ターゲットシステムサービススレッドの保留持続期間が第２の予め設定された値より大きいこと、のうちの少なくとも１つを含む、項目１から１０のいずれか一項に記載の方法。
（項目１２）
端末であって、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが上記端末で実行されており、上記システムサービスプロセスは少なくとも１つのシステムサービススレッドを含む、上記端末が、
上記少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするか否かを検出するよう構成されたタイムアウト検出ユニットであって、上記ターゲットシステムサービススレッドの上記タイムアウトは、上記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、上記ターゲットシステムサービススレッドがブロックされていることのうちの少なくとも１つを含む、タイムアウト検出ユニットと、
上記ターゲットシステムサービススレッドがタイムアウトするとき、上記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定するよう構成された判定ユニットと、
上記第１のアプリケーションプロセスを終了させるよう構成されたタイムアウト処理ユニットと、を備える、端末。
（項目１３）
上記判定ユニットは、具体的に、格納された登録情報に対し、上記ターゲットシステムサービススレッドと通信する上記第１のアプリケーションプロセスをクエリするよう構成されており、プロセス間通信ＩＰＣを実行するシステムサービススレッドと、アプリケーションプロセスとの間の対応関係が上記登録情報に記録される、項目１２に記載の端末。
（項目１４）
上記タイムアウト処理ユニットは、さらに、上記第１のアプリケーションプロセスを再起動させるよう構成されている、項目１２または１３に記載の端末。
（項目１５）
上記タイムアウト検出ユニットは、さらに、現在実行中のｂｉｎｄｅｒｂｉｎｄｅｒスレッドの総数Ｎをモニタリングするよう構成されており、Ｎは０以上の整数であり、
上記判定ユニットは、さらに、ｂｉｎｄｅｒスレッドの上記総数が第１の予め設定された値より大きい場合、Ｎ個の上記ｂｉｎｄｅｒスレッドの各々によりサービスされるアプリケーションプロセスを判定し、且つ、すべてのアプリケーションプロセスの各々により占有されるｂｉｎｄｅｒスレッドの数をカウントするよう構成されており、
上記タイムアウト処理ユニットは、さらに、第１のターゲットアプリケーションプロセスにより占有されるｂｉｎｄｅｒスレッドの数が第２の予め設定された値より大きい場合、上記第１のターゲットアプリケーションプロセスを終了させるよう構成されている、項目１２から１４のいずれか一項に記載の端末。
（項目１６）
第２のターゲットアプリケーションプロセスにより占有されるｂｉｎｄｅｒスレッドの数が上記第２の予め設定された値より大きく、上記第２のターゲットアプリケーションプロセスの優先度が上記第１のターゲットアプリケーションプロセスの優先度より高い場合、
上記タイムアウト処理ユニットは、さらに、上記第２のターゲットアプリケーションプロセスを終了させ、および、上記第２のターゲットアプリケーションプロセスを再起動させるよう構成されている、項目１５に記載の端末。
（項目１７）
上記タイムアウト処理ユニットは、具体的に、上記第２のターゲットアプリケーションプロセスの実行の進行状況を記録する、および、上記実行の進行状況に基づき、上記第２のターゲットアプリケーションプロセスを、上記実行の進行状況と同一の実行ステータスへ回復させる、よう構成されている、項目１６に記載の端末。
（項目１８）
上記判定ユニットは、さらに、ターゲットアプリケーションにＩＰＣサービスを提供するｂｉｎｄｅｒスレッドの数Ｍをカウントするよう構成されており、Ｍは０以上の整数であり、
上記タイムアウト処理ユニットは、さらに、上記ｂｉｎｄｅｒスレッドの数Ｍが第１の閾値以上であるとき、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止するよう構成されている、項目１２から１７のいずれか一項に記載の端末。
（項目１９）
上記タイムアウト処理ユニットは、具体的に、Ｍ個の上記ｂｉｎｄｅｒスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェースＡＰＩに関する統計を収集する、および、１つのＡＰＩが呼び出される回数が第２の閾値より大きい場合、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成要求への応答を停止する、よう構成されている、項目１８に記載の端末。
（項目２０）
上記タイムアウト処理ユニットは、さらに、
上記ターゲットアプリケーションに上記ＩＰＣサービスを提供する上記ｂｉｎｄｅｒスレッドの数Ｍが上記第１の閾値未満の場合、上記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドを作成するよう構成されている、項目１９に記載の端末。
（項目２１）
上記ターゲットシステムサービススレッドがタイムアウトした原因を表示する、または、上記第１のアプリケーションプロセスを終了させるプロンプトメッセージを表示する、よう構成されたディスプレイユニットをさらに備える、項目１２から２０のいずれか一項に記載の端末。
（項目２２）
上記ターゲットシステムサービススレッドがブロックされていることは、
上記ターゲットシステムサービススレッドと、上記第１のアプリケーションプロセスとの間の通信持続期間が第１の予め設定された値より大きいこと、および、実行プロシージャにおける上記ターゲットシステムサービススレッドの保留持続期間が第２の予め設定された値より大きいこと、のうちの少なくとも１つを含む、項目１２から２０のいずれか一項に記載の端末。
（項目２３）
プロセッサ、メモリ、バスおよび通信インタフェースを備える、端末であって、
上記メモリは、コンピュータ実行可能命令を格納するよう構成されており、上記プロセッサは、上記メモリに上記バスを用いて接続されており、上記端末が稼働される場合に、上記プロセッサは、上記メモリ内に格納された上記コンピュータ実行可能命令を実行し、上記端末は、項目１から１１のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行できるようにされる、端末。
（項目２４）
コンピュータ可読記憶媒体であって、上記コンピュータ可読記憶媒体は命令を格納し、上記命令が端末上で実行される場合、上記端末は、項目１から１１のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行できるようにされる、コンピュータ可読記憶媒体。
（項目２５）
命令を備えるコンピュータプログラムプロダクトであって、上記コンピュータプログラムプロダクトが端末上で実行される場合、上記端末は、項目１から１１のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行できるようにされる、コンピュータプログラムプロダクト。

Claims (17)

1. 端末に適用されるシステムサービスタイムアウト処理方法であって、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが前記端末で実行されており、前記システムサービスプロセスは少なくとも１つのシステムサービススレッドを含み、
   前記少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき、前記端末によって、前記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定する段階であって、前記ターゲットシステムサービススレッドの前記タイムアウトは、前記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、前記ターゲットシステムサービススレッドがブロックされていることのうち少なくとも１つを含む、段階と、
   前記端末によって、前記第１のアプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッドの数に基づいて前記第１のアプリケーションプロセスを終了させる段階と、を備える、方法。
2. 端末に適用されるシステムサービスタイムアウト処理方法であって、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが前記端末で実行されており、前記システムサービスプロセスは少なくとも１つのシステムサービススレッドを含み、
   前記少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき、前記端末によって、前記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定する段階であって、前記ターゲットシステムサービススレッドの前記タイムアウトは、前記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、前記ターゲットシステムサービススレッドがブロックされていることのうち少なくとも１つを含む、段階と、
   前記端末によって、前記第１のアプリケーションプロセスを終了させる段階と、
   複数のターゲットシステムサービススレッドがタイムアウトする場合に、前記端末によって、アプリケーションプロセスの優先度に基づいて、より低い優先度を有するアプリケーションプロセスを直接終了させ、より高い優先度を有するアプリケーションプロセスを再起動させる段階と、
   を備える、方法。
3. 前記端末によって、前記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定する前記段階は、
   前記端末によって、格納された登録情報に対し、前記ターゲットシステムサービススレッドと通信する前記第１のアプリケーションプロセスをクエリする段階であって、プロセス間通信（ＩＰＣ）を実行するシステムサービススレッドと、アプリケーションプロセスとの間の対応関係が前記登録情報に記録される、段階を含む、請求項１または２に記載の方法。
4. 前記端末によって、前記第１のアプリケーションプロセスを終了させる前記段階の後、前記方法は、
   前記端末によって、前記第１のアプリケーションプロセスを再起動する段階を備える、請求項１から３のいずれか一項に記載の方法。
5. 前記端末によって、現在実行中のｂｉｎｄｅｒスレッドの総数Ｎをモニタリングする段階であって、Ｎは０以上の整数である、段階と、
   ｂｉｎｄｅｒスレッドの前記総数が第１の予め設定された値より大きい場合、前記端末によって、Ｎ個の前記ｂｉｎｄｅｒスレッドの各々によりサービスされるアプリケーションプロセスを判定する段階と、
   前記端末によって、すべてのアプリケーションプロセスの各々により占有されるｂｉｎｄｅｒスレッドの数をカウントする段階と、
   第１のターゲットアプリケーションプロセスにより占有されるｂｉｎｄｅｒスレッドの数が第２の予め設定された値より大きい場合、前記端末によって、前記第１のターゲットアプリケーションプロセスを終了させる段階と、をさらに備える、請求項１から４のいずれか一項に記載の方法。
6. 第２のターゲットアプリケーションプロセスにより占有されるｂｉｎｄｅｒスレッドの数が前記第２の予め設定された値より大きく、前記第２のターゲットアプリケーションプロセスの優先度が前記第１のターゲットアプリケーションプロセスの優先度より高い場合、前記方法は、さらに、
   前記端末によって、前記第２のターゲットアプリケーションプロセスを終了させる段階と、
   前記端末によって、前記第２のターゲットアプリケーションプロセスを再起動させる段階と、を備える、請求項５に記載の方法。
7. 前記端末が前記第２のターゲットアプリケーションプロセスを終了させるとき、前記方法は、さらに、
   前記端末によって、前記第２のターゲットアプリケーションプロセスの実行の進行状況を記録する段階を備え、
   前記端末によって、前記第２のターゲットアプリケーションプロセスを再起動させる前記段階は、
   前記端末によって、前記実行の進行状況に基づき、前記第２のターゲットアプリケーションプロセスを、前記実行の進行状況と同一の実行ステータスに回復させる段階を含む、請求項６に記載の方法。
8. 前記端末によって、ターゲットアプリケーションにＩＰＣサービスを提供するｂｉｎｄｅｒスレッドの数Ｍをカウントする段階であって、Ｍは０以上の整数である、段階と、
   前記端末によって、前記ｂｉｎｄｅｒスレッドの数Ｍが第１の閾値以上であるとき、前記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する段階と、をさらに備える、請求項１から７のいずれか一項に記載の方法。
9. 前記端末によって、前記ｂｉｎｄｅｒスレッドの数が第１の閾値以上であるとき、前記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する前記段階は、
   前記端末によって、Ｍ個の前記ｂｉｎｄｅｒスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェース（ＡＰＩ）に関する統計を収集する段階と、
   １つのＡＰＩが呼び出される回数が第２の閾値より大きい場合、前記端末によって、前記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成要求への応答を停止する段階と、を含む、請求項８に記載の方法。
10. 前記端末によって、前記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドの作成を停止する前記段階の後、前記方法は、さらに、
    前記ターゲットアプリケーションに前記ＩＰＣサービスを提供する前記ｂｉｎｄｅｒスレッドの数Ｍが前記第１の閾値未満の場合、前記端末によって、前記ターゲットアプリケーションのための新しいｂｉｎｄｅｒスレッドを作成する段階を備える、請求項８または９に記載の方法。
11. 前記端末によって、前記ターゲットシステムサービススレッドがタイムアウトした原因を表示する段階、または、前記第１のアプリケーションプロセスを終了させるプロンプトメッセージを表示する段階をさらに備える、請求項１から１０のいずれか一項に記載の方法。
12. 前記ターゲットシステムサービススレッドがブロックされていることは、
    前記ターゲットシステムサービススレッドと、前記第１のアプリケーションプロセスとの間の通信持続期間が第１の予め設定された値より大きいこと、および、実行プロシージャにおける前記ターゲットシステムサービススレッドの保留持続期間が第２の予め設定された値より大きいこと、のうちの少なくとも１つを含む、請求項１から１１のいずれか一項に記載の方法。
13. 端末であって、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが前記端末で実行されており、前記システムサービスプロセスは少なくとも１つのシステムサービススレッドを含む、前記端末が、
    前記少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするか否かを検出するよう構成されたタイムアウト検出ユニットであって、前記ターゲットシステムサービススレッドの前記タイムアウトは、前記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、前記ターゲットシステムサービススレッドがブロックされていることのうちの少なくとも１つを含む、タイムアウト検出ユニットと、
    前記ターゲットシステムサービススレッドがタイムアウトするとき、前記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定するよう構成された判定ユニットと、
    前記第１のアプリケーションプロセスによって占有されるｂｉｎｄｅｒスレッドの数に基づいて前記第１のアプリケーションプロセスを終了させるよう構成されたタイムアウト処理ユニットと、を備える、端末。
14. 端末であって、システムサービスプロセスおよび少なくとも１つのアプリケーションプロセスが前記端末で実行されており、前記システムサービスプロセスは少なくとも１つのシステムサービススレッドを含む、前記端末が、
    前記少なくとも１つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするか否かを検出するよう構成されたタイムアウト検出ユニットであって、前記ターゲットシステムサービススレッドの前記タイムアウトは、前記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、前記ターゲットシステムサービススレッドがブロックされていることのうちの少なくとも１つを含む、タイムアウト検出ユニットと、
    前記ターゲットシステムサービススレッドがタイムアウトするとき、前記ターゲットシステムサービススレッドと通信する第１のアプリケーションプロセスを判定するよう構成された判定ユニットと、
    前記第１のアプリケーションプロセスを終了させるよう構成されたタイムアウト処理ユニットと、を備え、
    前記タイムアウト処理ユニットは、複数のターゲットシステムサービススレッドがタイムアウトする場合に、前記端末によって、アプリケーションプロセスの優先度に基づいて、より低い優先度を有するアプリケーションプロセスを直接終了させ、より高い優先度を有するアプリケーションプロセスを再起動させる、端末。
15. 前記判定ユニットは、具体的に、格納された登録情報に対し、前記ターゲットシステムサービススレッドと通信する前記第１のアプリケーションプロセスをクエリするよう構成されており、プロセス間通信（ＩＰＣ）を実行するシステムサービススレッドと、アプリケーションプロセスとの間の対応関係が前記登録情報に記録される、請求項１３または１４に記載の端末。
16. プロセッサ、メモリ、バスおよび通信インタフェースを備える、端末であって、
    前記メモリは、コンピュータ実行可能命令を格納するよう構成されており、前記プロセッサは、前記メモリに前記バスを用いて接続されており、前記端末が稼働される場合に、前記プロセッサは、前記メモリ内に格納された前記コンピュータ実行可能命令を実行し、前記端末は、請求項１から１２のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行できるようにされる、端末。
17. 端末に、請求項１から１２のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行させるための、コンピュータプログラム。

Images