本願の実施形態は、通信技術の分野、特に、システムサービスタイムアウト処理方法および装置に関する。
現在、ユーザは、携帯電話、ウェアラブルデバイスおよびタブレットコンピュータ等の端末の円滑な実行に対しますます高い要求を有する。しかしながら、より多くの機能が端末に実装可能になるにつれ、実行中のアプリケーションプログラムによって占有されるリソースはますますフラグメント化され、その結果、ユーザの端末の使用中に、フレームフリーズあるいは場合によってはスクリーンフリーズを引き起こし、ユーザエクスペリエンスに大きな影響を及ぼしている。
通常、端末はウォッチドッグ(watchdog)メカニズムを用いて、端末で提供されているシステムサービスがタイムアウトしたかどうかをモニタリングし得る。例えば、Android(登録商標)システムでは、watchdogは、システムサービス(system server)プロセス内のスレッド(thread)、および、system serverプロセス内に常駐する、例えばウィンドウマネージャサービス(window manager server)およびアクティビティマネージャシステムサービス(activity manager system service)等の様々なシステムサービスのスレッドとして実行されてよい。watchdogは、system serverプロセス内のこれらのスレッドをモニタリングしてよい。スレッドがブロックされ、watchdogが予め設定された時間内に当該スレッドから応答を受信しない場合は、watchdogは端末に対し、Android(登録商標)システム全体を再起動するようトリガする。
換言すると、system server内のスレッドがブロックされていることを検出すると、watchdogは端末に対し再起動をトリガする。強制ブロッキングによるこの回復方式は、ユーザに対し、現在のシナリオにおけるすべてのデータを失わせることを生じさせ、また、ユーザは端末が再起動するまで待機する必要がある。
本願の実施形態は、システムサービスのタイムアウト時に、端末でのフレームフリーズまたはスクリーンフリーズの可能性を低減し、ユーザエクスペリエンスを向上させるためのシステムサービスタイムアウト処理方法および装置を提供する。
上述の目的を達成すべく、以下の技術的解決手段が本願の実施形態において用いられる。
第1の態様により、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが、本方法が適用される端末上で実行され、システムサービスプロセスは、少なくとも1つのシステムサービススレッドを含む。具体的には、方法は、少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき(ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されたロックオブジェクトが予め設定された時間内に解放されないこと、およびターゲットシステムサービススレッドがブロックされることのうちの少なくとも1つを含む)、端末によって、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセス(特に、第1のアプリケーションプロセスおよび第2のアプリケーションプロセスは、少なくとも1つのアプリケーションプロセス内の2つの異なるアプリケーションプロセスである)を判定する段階と、端末によって、第1のアプリケーションプロセスを終了させる段階と、を備える。
このようにして、第1のアプリケーションプロセスが終了された後、第1のアプリケーションプロセスと通信するターゲットシステムサービススレッドによって占有されるターゲットロックオブジェクトは解放され得、ターゲットシステムサービススレッドのブロッキングは除去され、端末上で実行中の別のシステムサービススレッドは影響を受けない。これにより、端末でのフレームフリーズまたはスクリーンフリーズの可能性が低減され、ユーザエクスペリエンスが向上する。
具体的に、ターゲットシステムサービススレッドがブロックされることは、ターゲットシステムサービススレッドと第1のアプリケーションプロセスとの間の通信の持続期間が第1の予め設定された値より大きいこと、および、実行プロシージャにおけるターゲットシステムサービススレッドの保留持続期間が第2の予め設定された値より大きいこと、のうちの少なくとも1つを含んでよい。
可能な設計方法において、システムサービスプロセスは、さらにwatchdogスレッドを含む。方法は、さらに、watchdogスレッドによって、電気信号を上述のシステムサービススレッドにシーケンシャルに送信する段階と、上述のシステムサービススレッド中のターゲットシステムサービススレッドによってフィードバックされる応答信号が予め設定された時間内に受信されない場合、端末によって、ターゲットシステムサービススレッドはタイムアウトすると判定する段階と、を備える。換言すると、端末は、既存のwatchdogメカニズムに基づき、本願のシステムサービスタイムアウト処理方法を実装してよく、実装の複雑さが低減され、システムリソースが節約される。
可能な設計方法において、端末によって、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定する段階は、端末によって、格納された登録情報に対し、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスをクエリする段階を含み、IPCを実行するシステムサービススレッドと、第1のアプリケーションプロセスとの間の対応関係が登録情報に記録されている。
可能な設計方法において、端末によって、第1のアプリケーションプロセスを終了させる段階の後、方法は、端末によって、第1のアプリケーションプロセスを再起動する段階を含み、この結果、ユーザは、再起動された第1のアプリケーションプロセス上で処理を継続できる。
可能な設計方法において、方法は、さらに、端末が現在実行中のbinderスレッドの総数Nをモニタリングすることを含み、Nは0以上の整数である。binderスレッドの総数が第1の予め設定された値より大きい場合、端末は、N個のbinderスレッドの各々によってサービスされているアプリケーションプロセスを判定する。さらに、端末は、すべてのアプリケーションプロセスの各々によって占有されているbinderスレッド数をカウントする。第1のターゲットアプリケーションプロセスにより占有されるbinderスレッドの数が第2の予め設定された値より大きい場合、このことは、第1のターゲットアプリケーションプロセスが多くのbinderリソースを占有し過ぎており、端末でフレームフリーズまたはスクリーンフリーズが生じるリスクが比較的高い状態をもたらすことを示している。従って、端末は、第1のターゲットアプリケーションプロセスを終了させて、第1のターゲットアプリケーションプロセスによって占有されているbinderスレッドを解放してよい。解放されたbinderスレッドは、プロセス間通信を待機する別のプロセス(または別のスレッド)によって用いられてよい。
可能な設計方法において、第2のターゲットアプリケーションプロセスによって占有されるbinderスレッドの数が第2の予め設定された値より大きく、第2のターゲットアプリケーションプロセスの優先度が第1のターゲットアプリケーションプロセスの優先度より高い場合、方法はさらに、端末によって、第2のターゲットアプリケーションプロセスを終了させる段階と、端末によって、第2のターゲットアプリケーションプロセスを再起動させる段階と、を含む。換言すると、比較的多くのbinderスレッドが複数の端末によって占有される場合、端末は、より低い優先度を持つアプリケーションプロセスを解放し、より高い優先度を持つアプリケーションプロセスを確保して、より高い優先度を持つアプリケーションプロセスが終了(または再起動)された後の端末の実行ステータスおよびユーザエクスペリエンスが悪影響を受けることを回避してよい。
可能な設計方法において、端末が第2のターゲットアプリケーションプロセスを終了させるとき、方法は、さらに、端末によって、第2のターゲットアプリケーションプロセスの実行の進行状況を記録する段階を備え、端末によって、第2のターゲットアプリケーションプロセスを再起動する段階は、端末によって、実行の進行状況に基づき、第2のターゲットアプリケーションプロセスを、実行の進行状況と同一の実行ステータスに回復させる段階を含む。このようにして、第2のターゲットアプリケーションプロセスを再起動させるとき、端末は、記録された実行の進行状況に基づき第2のターゲットアプリケーションプロセスを再起動前のステータスに回復させてよく、その結果、アプリケーションプロセスの再起動の前後に、サービスは割り込まれることがないので、ユーザエクスペリエンスが向上する。
可能な設計方法において、方法は、さらに、端末がターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mをカウントし、Mは0以上の整数である、ことを含む。binderスレッドの数Mが第1の閾値以上である場合、このことは、binderスレッドリソースの枯渇の潜在的リスクが存在することを示しており、端末は、ターゲットアプリケーションのための新しいbinderスレッドの作成を停止して、binderスレッドリソースの枯渇を回避してよい。
可能な設計方法において、binderスレッドの数が第1の閾値より大きい場合、端末によってターゲットアプリケーションのための新しいbinderスレッドの作成を停止する段階は、端末がM個のbinderスレッドの各々により呼び出されるAPIに関する統計を収集することを含む。1つのAPIが呼び出される回数が第2の閾値より大きい場合、このことは、当該APIは比較的負荷が重い状態にあり、binderスレッドが悪意でAPIを呼び出しているリスクが存在する可能性があることを示している。この場合、比較的多数のbinderスレッドリソースが占有されており、binderスレッドは頻繁に単一のAPIを呼び出す。従って、端末は、ターゲットアプリケーションのための新しいbinderスレッドの作成要求への応答を停止して、悪意の占有により引き起こされるbinderスレッドリソースの枯渇を回避してよい。
可能な設計方法において、端末によって、ターゲットアプリケーションのための新しいbinderスレッドの作成を停止する段階の後、方法は、さらに、ターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mが第1の閾値未満の場合、端末によって、ターゲットアプリケーションのために新しいbinderスレッドを作成する段階を含む。
可能な設計方法において、方法は、さらに、端末によって、ターゲットシステムサービススレッドがタイムアウトする原因を表示する段階、または、第1のアプリケーションプロセスを終了させるプロンプトメッセージを表示する段階を含む。
可能な設計方法において、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。具体的には、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスは、方法が適用される端末上で実行される。システムサービスプロセスは、少なくとも1つのシステムサービススレッドを含む。具体的には、方法は、第1のシステムサービススレッドがターゲットロックオブジェクトを占有するとき、第1のタイマが計時を開始するようトリガされることを含む。第1のタイマが期限切れになったときに、第1のシステムサービススレッドがまだターゲットロックオブジェクトを解放しない場合は、端末は、ターゲットロックオブジェクトを占有する第1のシステムサービススレッドの識別子を取得するようトリガされる。さらに、端末は、第1のシステムサービススレッドの識別子に基づき、第1のシステムサービススレッドと通信するターゲットアプリケーションプロセスを判定し、ターゲットアプリケーションプロセスを終了させる。
別の可能な設計方法において、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。具体的には、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが、方法が適用される端末上で実行され、システムサービスプロセスは、少なくとも1つのシステムサービススレッドを含む。具体的に、方法は、第1のシステムサービススレッドが、第1のアプリケーションプロセスと通信することを含む。第2のアプリケーションプロセスが第1のシステムサービススレッドによって提供されるシステムサービスを要求するとき、第2のタイマが計時を開始するようトリガされる。第2のタイマが期限切れになったときに、第1のシステムサービススレッドがまだ第1のアプリケーションプロセスと通信中の場合、端末は、第1のアプリケーションプロセスを終了させるようトリガされる。
第2の態様により、本願の一実施形態は、端末を提供する。システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが端末上で実行され、システムサービスプロセスは少なくとも1つのシステムサービススレッドを含む。端末は、少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするか否かを検出するよう構成されたタイムアウト検出ユニットと、ターゲットシステムサービススレッドがタイムアウトするとき、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定するよう構成された判定ユニットであって、ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されるロックオブジェクトが予め設定された時間内に解放されないこと、および、ターゲットシステムサービススレッドがブロックされていることのうちの少なくとも1つを含む、判定ユニットと、第1のアプリケーションプロセスを終了させるよう構成されたタイムアウト処理ユニットと、を備える。
可能な設計方法において、具体的に、判定ユニットは、格納された登録情報に対し、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスをクエリするよう構成されており、プロセス間通信IPCを実行するシステムサービススレッドと、第1のアプリケーションプロセスとの間の対応関係が登録情報に記録されている。
可能な設計方法において、タイムアウト処理ユニットは、さらに、第1のアプリケーションプロセスを再起動させるよう構成されている。
可能な設計方法において、タイムアウト検出ユニットは、さらに、現在実行中のbinderbinderスレッドの総数Nをモニタリングするよう構成されており、Nは0以上の整数であり、判定ユニットは、さらに、binderスレッドの総数が第1の予め設定された値より大きい場合、N個のbinderスレッドの各々によってサービスされるアプリケーションプロセスを判定し、且つ、すべてのターゲットアプリケーションプロセスの各々によって占有されるbinderの数をカウントするよう構成されており、タイムアウト処理ユニットサは、さらに、第1のターゲットアプリケーションプロセスによって占有されるbinderスレッドの数が第2の予め設定された値より大きい場合、第1のターゲットアプリケーションプロセスを終了させるよう構成されている。
可能な設計方法において、第2のターゲットアプリケーションプロセスによって占有されるbinderスレッドの数が第2の予め設定された値より大きく、第2のターゲットアプリケーションプロセスの優先度が第1のターゲットアプリケーションプロセスの優先度より高い場合、タイムアウト処理ユニットは、さらに、第2のターゲットアプリケーションプロセスを終了させる、および、第2のターゲットアプリケーションプロセスを再起動させるよう構成されている。
可能な設計方法において、具体的に、タイムアウト処理ユニットは、第2のターゲットアプリケーションプロセスの実行の進行状況を記録し、実行の進行状況に基づき、第2のターゲットアプリケーションプロセスを、実行の進行状況と同一の実行ステータスに回復させるよう構成されている。
可能な設計方法において、判定ユニットは、さらに、ターゲットアプリケーションにIPCサービスを提供するbinderの数Mをカウントするよう構成されており、Mは0以上の整数であり、タイムアウト処理ユニットは、さらに、binderスレッドの数Mが第1の閾値以上である場合、ターゲットアプリケーションのための新しいbinderスレッドの作成を停止するよう構成されている。
可能な設計方法において、具体的に、タイムアウト処理ユニットは、M個のbinderスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェースAPIに関する統計を収集するよう構成されており、1つのAPIが呼び出される回数が第2の閾値より多い場合、ターゲットアプリケーションのための新しいbinderスレッドの作成要求に応答することを停止するよう構成されている。
可能な設計方法において、タイムアウト処理ユニットは、さらに、ターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mが第1の閾値未満の場合、ターゲットアプリケーションのための新しいbinderスレッドを作成するよう構成されている。
可能な設計方法において、端末は、さらに、ターゲットシステムサービススレッドがタイムアウトする原因を表示する、または第1のアプリケーションプロセスを終了させるプロンプトメッセージを表示するよう構成されたディスプレイユニットを備える。
第3の態様により、本願の一実施形態は、端末を提供する。端末は、プロセッサ、メモリ、バスおよび通信インタフェースを含む。メモリは、コンピュータ実行可能命令を格納するよう構成されており、プロセッサはバスを用いてメモリに接続されており、端末が稼働される場合、プロセッサは、メモリ内に格納されたコンピュータ実行可能命令を実行し、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の1つを実行できるようにされる。
第4の態様により、本願の一実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を格納し、当該命令が上述の端末のうちの任意の1つで実行されると、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の1つを実行できるようにされる。
第5の態様により、本願の一実施形態は、命令を含むコンピュータプログラムプロダクトを提供する。コンピュータプログラムプロダクトが、上述の端末のうちの任意の1つで実行されると、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の1つを実行できるようにされる。
第2の態様から第5の態様までの任意の設計によりもたらされる技術的効果については、第1の態様における異なる設計方法によりもたらされる技術的効果を参照されたい。ここに詳細を再度説明することはしない。
本願の実施形態による、端末の第1の概略構造図である。
本願の一実施形態によるAndroid(登録商標)システムの第1の概略アーキテクチャ図である。
本願の一実施形態によるAndroid(登録商標)システムの第2の概略アーキテクチャ図である。
本願の一実施形態によるAndroid(登録商標)システムの第3の概略アーキテクチャ図である。
本願の一実施形態によるシステムサービスタイムアウト処理方法の第1の概略フローチャートである。
本願の一実施形態による、システムサービスタイムアウト処理方法のアプリケーションシナリオの第1の概略図である。
本願の一実施形態による、システムサービスタイムアウト処理方法のアプリケーションシナリオの第2の概略図である。
本願の一実施形態による、システムサービスタイムアウト処理方法の第2の概略フローチャートである。
本願の一実施形態によるシステムサービスタイムアウト処理方法の第3の概略フローチャートである。
本願の一実施形態による、端末の第2の概略構造図である。
本願の一実施形態による、端末の第3の概略構造図である。
以下で言及する「第1」および「第2」という用語は、説明のためのものに過ぎず、相対的重要性のを示すもの若しくは暗示、あるいは、示された技術的特徴の数の暗示として理解されるべきではない。従って、「第1」または「第2」として限定される特徴は、1または複数の特徴を明示的または暗黙的に含んでよい。本願の実施形態の説明において、別途の記載がない限り、「複数」は、2または2より多いことを意味する。
本願の実施形態で提供されるシステムサービスタイムアウト処理方法を明確に説明するために、まず、後続の実施形態に現れ得るいくつかの概念について説明する。
プロセス(process)とは、アプリケーションプログラムのデータセット上で実行中のアクティビティであり、オペレーティングシステム(例えば、Android(登録商標)システム)が割り当ておよびリソーススケジューリングを行う基本単位である。各プロセスは、アドレス空間を占有する。アプリケーションプログラムは、オペレーティングシステム上で、対応する機能を実装するための1または複数のプロセスとして実行される。
スレッド(thread)とは、1プロセスの1エンティティであり、プロセスより小さく、独立して実行可能な基本単位である。スレッドは、あるプロセスのすべてのリソースを、同一プロセスに属する他の複数のスレッドと共有可能である。1つのスレッドが、別のスレッドを作成およびキャンセルできる。1つのプロセス内の複数のスレッドが並列に実行可能である。
オブジェクトロッキングとは、一度に1つのスレッドのみがメソッドまたは変数にアクセスすることを保証するメカニズムである。Java(登録商標)言語では、あるスレッドがシンクロナイズドコードにアクセスすると、当該コードが属するロックオブジェクトが取得される必要がある。さもなければ、当該スレッドは、当該ロックオブジェクトが解放されるまで、待機(またはブロック)されることになる。シンクロナイズドコードとは、キーワード"synchronized"で修飾されたメソッドまたはステートメントブロックである。
換言すると、オブジェクトロッキングとは、最大で1つのスレッドがロックを取得できることを意味する排他処理である。スレッドAが、スレッドBが保持するロックオブジェクトの取得を試みると、スレッドAは待機する必要がある、またはブロックされる必要がある。スレッドAは、スレッドBがロックを解放するまで、対応するメソッドまたは変数にアクセスすべく、ロックオブジェクトを取得できない。
通常、スレッドブロッキングとは、実行プロシージャ内のスレッドの保留持続期間が予め設定された値より大きい場合に生じるタイムアウトを指す。例えば、スレッドAの実行プロシージャで、実行を継続するために、スレッドBの実行結果が入力パラメータとして用いられる必要がある。この場合、スレッドAがスレッドBの実行結果を取得しない場合、実行は保留される。スレッドAが予め設定された時間内にスレッドBの実行結果を取得しない場合、Aスレッドはブロックされる。代替的に、スレッドブロッキングとは、スレッドがあるプロセスとの通信時に、当該スレッドがそのプロセスによって、長期間占有されることを原因として、当該スレッドが別のプロセスのためのサービスを提供できない現象を指してよい。
現在、端末は、watchdogメカニズムに基づき、オペレーティングシステム内のいくつかのスレッドおよびロックオブジェクトをモニタリングし得る。モニタリングされるスレッドがブロックされている場合、または、モニタリングされるロックオブジェクトが長期間解放されない場合、端末は、保留またはスクリーンフリーズを回避すべく、オペレーティングシステム全体を再起動するようトリガされ得る。
しかしながら、オペレーティングシステム全体を再起動することによるフリーズの除去は、スレッドがブロックされる、またはロックオブジェクトが正常に解放されないという問題を解決できるが、オペレーティングシステム内で正常に実行中の別のスレッドおよびロックオブジェクトも強制的に終了される。実行中のアプリケーションプログラムの大量のデータが失われることは間違いない。また、ユーザエクスペリエンスも犠牲になる。
従って、本願の実施形態では、既存のwatchdogトリガメカニズムに基づき、モニタリングされるスレッドがブロックされていること、または、モニタリングされるロックオブジェクトが長期間解放されないことを検出したときに、端末がまず、ブロックされているスレッドまたはロックオブジェクトを占有するスレッド(またはプロセス)と通信中のアプリケーションプロセスを判定してよい。さらに、端末は、アプリケーションプロセスの終了または再起動等の回復ポリシーを用いて、現在のスレッドがブロックされている、またはロックオブジェクトが解放できないという問題を解決してよい。このようにすると、オペレーティングシステムにおけるブロックされていない、または、ロックオブジェクトを正常に解放するスレッドの実行中のプロシージャは影響を受けることがなく、スレッドブロッキングまたはロックオブジェクト解放エラーにより引き起こされるフリーズの問題も解決されてよく、これによりユーザエクスペリエンスが大きく向上する。
上述のアプリケーションプロセスは、端末のアプリケーションレイヤでのアプリケーションプログラムのプロセスであってよく、または、バックグランドで実行中のデーモン(daemon)プロセスであってよい。このことは、本願の実施形態において限定されるものではない。
本願の一実施形態で提供されるシステムサービスタイムアウト処理方法は、携帯電話、ウェアラブルデバイス、拡張現実(augmented reality,AR)/仮想現実(virtual reality,VR)デバイス、タブレットコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ(ultra−mobile personal computer,UMPC)、ネットブックまたはパーソナルデジタルアシスタント(personal digital assistant,PDA)等の任意の端末に適用されてよい。以降の実施形態において、特定の形態の端末に限定されないのはもちろんである。
図1に示される通り、本願の実施形態における端末は、携帯電話100であってよい。以下に、携帯電話100を例に用いて、実施形態について詳細に説明する。当該図に示される携帯電話100は、端末の一例に過ぎず、携帯電話100は、図に示されるものより多いまたは少ないコンポーネントを有してよく、2または2より多いコンポーネントが組み合わされてよく、あるいは異なるコンポーネント構成が用いられてよいことを理解されたい。
図1に示される通り、具体的に携帯電話100は、プロセッサ101、無線周波数(radio frequency,RF)回路102、メモリ103、タッチスクリーン104、Bluetooth(登録商標)装置105、1または複数のセンサ106、ワイヤレスフィディリティ(wireless fidelity,Wi−Fi)装置107、位置特定装置108、オーディオ回路109、周辺機器インタフェース110および電力システム111等のコンポーネントを含んでよい。これらのコンポーネントは、1または複数の通信バスまたは信号ケーブル(図1に不図示)を用いて互いに通信してよい。当業者であれは、図1に示されるハードウェア構造は、携帯電話に対する限定を構成せず、携帯電話100は、図に示されるものより多いまたは少ないコンポーネントを含んでよく、いくつかのコンポーネントは組み合わされてよく、あるいは異なるコンポーネント構成が用いられてよいことを理解するであろう。
以下に、図1を参照して、携帯電話100のコンポーネントについて詳細に説明する。
プロセッサ101は、携帯電話100の制御センターである。プロセッサ101は、様々なポートおよび配線を用いて携帯電話100の様々な部分に接続され、メモリ103内に格納されたアプリケーションプログラムを稼働または実行し、メモリ103内に格納されたデータを呼び出して、携帯電話100の様々な機能を実行して、データを処理する。いくつかの実施形態において、プロセッサ101は、1または複数の処理ユニットを含んでよい。例えば、プロセッサ101は、Huawei Technologies Co.,Ltd製のKirin 960チップであってよい。本願のいくつかの実施形態において、プロセッサ101はさらに、収集された指紋を検証するよう構成された指紋検証チップを含んでよい。
無線周波数回路102は、情報の送信および受信プロシージャにおいて、またはコールプロシージャにおいて、無線信号を送信および受信するよう構成されてよい。特に、基地局からダウンリンクデータを受信した後、無線周波数回路102は、ダウンリンクデータをプロセッサ101に処理させるために送信してよい。また、無線周波数回路102は、関連するアップリンクデータを基地局に送信する。一般に、無線周波数回路は、アンテナ、少なくとも1つの増幅器、送受信機、カプラ、低雑音増幅器およびデュプレクサ等を含むが、これらに限定されるものではない。また、無線周波数回路102は、さらに、無線通信を通して別のデバイスと通信してよい。グローバルシステムフォーモバイルコミュニケーション、汎用パケット無線サービス、符号分割多重アクセス、広帯域符号分割多重アクセス、ロングタームエボリューション、電子メールおよびショートメッセージサービス等を含む無線通信における任意の通信規格またはプロトコルが用いられてよく、これらに限定されるものではない。
メモリ103は、アプリケーションプログラムおよびデータを格納するよう構成されている。プロセッサ101は、携帯電話100の様々な機能を実行し、および、データを処理するために、メモリ103内に格納されたアプリケーションプログラムおよびデータを実行する。メモリ103は、主に、プログラム格納領域およびデータ格納領域を含む。プログラム格納領域は、オペレーティングシステムと、少なくとも1つの機能(例えば、サウンド再生またはイメージ再生機能)により必要とされるアプリケーションプログラムとを格納してよい。データ格納領域は、携帯電話100の使用を基に作成されたデータ(例えば、オーディオデータまたは電話帳)を格納してよい。また、メモリ103は、高速ランダムアクセスメモリ(random access memory,RAM)を含んでよく、さらに、磁気ディスク記憶デバイス、フラッシュメモリデバイス等の不揮発性メモリ、または別の揮発性ソリッドステートメモリを含んでよい。メモリ103は、Apple社が開発したiOS(登録商標)オペレーティングシステムおよびGoogle社が開発したAndroid(登録商標)オペレーティングシステム等の様々なオペレーティングシステムを格納してよい。メモリ103は独立していてよく、通信バスを用いてプロセッサ101に接続される。代替的に、メモリ103はプロセッサ101に統合されてよい。
具体的に、タッチスクリーン104は、タッチパッド104−1およびディスプレイ104‐2を含んでよい。
タッチパッド104−1は、携帯電話100のユーザにより、携帯電話100上でまたはその近傍で行われたタッチイベント(例えば、ユーザにより、指またはスタイラス等の好適なオブジェクトを用いてタッチパッド104−1上でまたはその近傍で、行われた操作)を収集してよく、収集されたタッチ情報を別のコンポーネント(プロセッサ101等)に送信してよい。ユーザにより、タッチパッド104−1の近傍で行われたタッチイベントは、フローティングタッチと呼ばれてよい。フローティングタッチとは、ユーザがオブジェクト(例えば、アイコン)を選択、移動またはドラッグするために、タッチパッドを直接タッチする必要がないこと、および、ユーザが所望の機能を実行するために端末の付近にいるだけでよいことを意味してよい。また、タッチパッド104−1は、抵抗タイプ、静電容量タイプ、赤外線タイプまたは表面弾性波タイプ等の複数のタイプで実装されてよい。
ディスプレイ(ディスプレイスクリーンとも言う)104‐2は、ユーザにより入力された情報またはユーザに対し提供される情報、および携帯電話100の様々なメニューを表示するよう構成されてよい。ディスプレイ104−2は、液晶ディスプレイまたは有機発光ダイオード等の形態で構成されてよい。タッチパッド104−1は、ディスプレイ104−2を覆ってよい。タッチパッド104−1上またはその近傍でのタッチイベントを検出すると、タッチパッド104−1は、タッチイベントのタイプを判定すべく、そのタッチイベントをプロセッサ101に転送する。次に、プロセッサ101は、タッチイベントのタイプに基づき、対応するビジュアル出力をディスプレイ104−2に提供してよい。図1中のタッチパッド104−1およびディスプレイスクリーン104−2は、携帯電話100の入力および出力機能を実装するための2つの独立したコンポーネントとして用いられるが、いくつかの実施形態においては、携帯電話100の入力および出力機能を実装すべく、タッチパッド104−1およびディスプレイスクリーン104−2が統合されてよい。タッチスクリーン104は、材料の複数のレイヤを積層することで形成されることが理解可能である。本願のこの実施形態において、タッチパッド(レイヤ)およびディスプレイスクリーン(レイヤ)のみが表示されており、別のレイヤは本願のこの実施形態において記載されていない。また、タッチパッド104−1は、ベゼルレス画面の形態で、携帯電話100の前面に構成されてよく、ディスプレイスクリーン104−2も、ベゼルレス画面の形態で携帯電話100の前面に構成されてよい。このようにして、ベゼルレス構造が携帯電話の前面に実装されてよい。
また、携帯電話100は、さらに、指紋認識機能を有してよい。例えば、指紋認識部112が、携帯電話100の裏面(例えば、背面カメラの下方)に構成されてよく、または、指紋認識部112は、携帯電話100の前面(例えば、タッチスクリーン104の下方)に構成されてよい。別の例では、指紋収集コンポーネント112は、指紋認識機能を実装すべく、タッチスクリーン104に配置されてよく、すなわち、指紋収集コンポーネント112は、携帯電話100の指紋認識機能を実装すべく、タッチスクリーン104に統合されてよい。この場合、指紋収集コンポーネント112はタッチスクリーン104内に構成されてよく、タッチスクリーン104の一部であってよい、または、別の態様でタッチスクリーン104内に構成されてよい。本願のこの実施形態における指紋収集コンポーネント112の主なコンポーネントは、指紋センサである。指紋センサは、任意のタイプの感知技術を用いてよく、このようなものとして、光感知技術、静電容量感知技術、圧電感知技術または超音波感知技術等が含まれるが、これらに限定されるものではない。
携帯電話100は、さらに、携帯電話100と別の短距離端末(例えば、携帯電話またはスマートウォッチ)との間でデータを交換するよう構成されたBluetooth(登録商標)装置105を含んでよい。本願のこの実施形態において、Bluetooth(登録商標)装置は、集積回路またはBluetooth(登録商標)チップ等であってよい。
携帯電話100は、さらに、光学センサ、モーションセンサおよび別のセンサ等の少なくとも1つのセンサ106を含んでよい。具体的には、光学センサは、環境光センサおよび近接センサを含んでよい。環境光センサは、周囲光の輝度に基づき、タッチスクリーン104のディスプレイの輝度を調整してよい。近接センサは、携帯電話100が耳に近づけられたとき、ディスプレイの電源をオフにしてよい。モーションセンサのタイプとしての加速度計センサが、全方向(通常、3軸)における加速度の値を検出してよく、センサの静止時の重力の値および方向を検出してよく、携帯電話の姿勢(ランドスケープモードとポートレイトモードとの間の画面切り替え、関連するゲームまたは磁力計の姿勢較正等)を識別するためのアプリケーションプログラム、振動の識別に関連する機能(歩数計またはノック等)等において用いられてよい。ジャイロスコープ、バロメータ、湿度計、温度計および赤外線センサ等の他センサが、さらに、携帯電話100上に配置されてよい。詳細については、ここで説明はしない。
Wi−Fi(登録商標)装置107は、携帯電話100に対し、Wi−Fi(登録商標)関連の規格プロトコルに準拠するネットワークアクセスを提供するよう構成されている。携帯電話100は、ユーザが電子メールを送信および受信する、ウェブページを閲覧する、ストリーミングメディアにアクセスする等を補助すべく、Wi−Fi(登録商標)装置107を用いて、Wi−Fi(登録商標)アクセスポイントにアクセスしてよい。Wi−Fi(登録商標)装置107は、ユーザに無線ブロードバンドインターネットアクセスを提供する。いくつかの他の実施形態においては、Wi−Fi(登録商標)装置107は、Wi−Fi(登録商標)無線アクセスポイントとして用いられてよく、別の端末に対し、Wi−Fi(登録商標)ネットワークアクセスを提供してよい。
位置特定装置108は、携帯電話100に地理的位置を提供するよう構成されている。具体的に、位置特定装置108は、全地球測位システム(global positioning system,GPS)、Beidou衛星測位システムまたはロシアのGLONASS等の位置特定システムの受信機であってよいことが理解できるであろう。位置特定システムによって送信された地理的位置を受信した後、位置特定装置108は、当該情報を処理させるためにプロセッサ101に送信し、または、当該情報を格納させるためにメモリ103に送信する。いくつかの他の実施形態においては、位置特定装置108は、さらに、アシスト型全地球測位システム(assisted global positioning system,AGPS)の受信機であってよい。AGPSシステムは、位置特定装置108が測距サービスおよび位置特定サービスを完了するのを補助するアシストサーバとして機能する。この場合、アシスト位置特定サーバは、端末、例えば携帯電話100の位置特定装置108(すなわち、GPS受信機)と、無線通信ネットワークを通して通信し、位置特定補助を提供する。いくつかの他の実施形態においては、位置特定装置108は、Wi−Fi(登録商標)アクセスポイントに基づく位置特定技術であってよい。各Wi−Fi(登録商標)アクセスポイントは、グローバル一意メディアアクセス制御(media access control,MAC)アドレスを有し、端末は、Wi−Fi(登録商標)が有効になっている場合、周囲のWi−Fi(登録商標)アクセスポイントのブロードキャスト信号をスキャンし、収集することができる。従って、端末は、Wi−Fi(登録商標)アクセスポイントによってブロードキャストされたMACアドレスを取得できる。端末は、Wi−Fi(登録商標)アクセスポイントを識別可能なかかるデータ(例えば、MACアドレス)を、無線通信ネットワークを通してロケーションサーバに送信する。ロケーションサーバは、各Wi−Fi(登録商標)アクセスポイントの地理的位置を取得し、Wi−Fi(登録商標)ブロードキャスト信号の強度を参照して端末の地理的位置を計算し、端末の地理的位置を、端末の位置特定装置108に送信する。
音声回路109、スピーカ113およびマイク114は、ユーザと携帯電話100との間のオーディオインタフェースを提供してよい。可聴周波数回路109は、受信したオーディオデータから変換された電気信号をスピーカ113に送信してよく、スピーカ113は当該電気信号を出力するための音声信号に変換する。また、マイク114は、収集された音声信号を電気信号に変換し、可聴周波数回路109は、当該電気信号を受信した後に当該電気信号をオーディオデータに変換し、その後、オーディオデータを例えば別の携帯電話に送信するために、オーディオデータをRF回路102に出力する、またはさらなる処理のためにオーディオデータをメモリ103に出力する。
周辺機器インタフェース110は、外部入/出力デバイス(キーボード、マウス、外部ディスプレイ、外部メモリおよび加入者識別モジュールカード等)用の様々なインタフェースを提供するよう構成されている。例えば、携帯電話100は、ユニバーサルシリアルバス(universal serial bus,USB)インタフェースを用いてマウスに接続され、ユーザ識別モジュールカードのカードスロット上の金属コンタクトを用いて、電気通信事業者が提供するユーザ識別モジュールカード(subscriber identification module,SIM)カードに接続される。周辺機器インタフェース110は、外部入/出力周辺デバイスを、プロセッサ101およびメモリ103に結合するよう構成されてよい。
携帯電話100は、さらに、電力を様々なコンポーネントに提供する電源装置111(例えば、バッテリまたは電力管理チップ)を含んでよい。バッテリは、充電管理、放電管理および電力消費管理等の機能が電源装置111を用いて実装されるように、電力管理チップを用いてプロセッサ101に論理的に接続されてよい。
図1には図示されていないが、携帯電話100は、さらに、カメラ(前面カメラおよび/または背面カメラ)、フラッシュライト、マイクロプロジェクション装置および近距離無線通信(near field communication,NFC)等を含んでよい。詳細については、ここに説明はしない。
さらに、携帯電話100は、Android(登録商標)またはiOS等のオペレーティングシステムを実行してよい。本願のこの実施形態はこの点において限定されるものではない。
Android(登録商標)オペレーティングシステムを例に用いると、図2に示される通り、Android(登録商標)オペレーティングシステムは、降順に、アプリケーションプログラムレイヤ201(すなわち、APPレイヤ)、アプリケーションプログラムフレームワークレイヤ202(すなわち、frameworkレイヤ)、システムランタイムライブラリレイヤ203(すなわち、libraryレイヤ)およびLinux(登録商標)カーネルレイヤ204の4つのレイヤに分割されてよい。
Linux(登録商標)カーネルレイヤ204は、携帯電話100のセキュリティ(security)制御、メモリ管理(memory management)、プログラム管理(process management)、ネットワークスタック(network stack)およびドライバモデル(driver model)等の機能に用いられてよい。Linux(登録商標)カーネルレイヤ204はまた、ハードウェア(例えば、CPU、ネットワークインタフェースカードおよびメモリ)とソフトウェアスタックとの間の抽象化レイヤとしても機能し、特定のハードウェアの詳細情報を非表示にして、上位レイヤ(システムランタイムライブラリレイヤ203、アプリケーションプログラムフレームワークレイヤ202およびアプリケーションプログラムレイヤ201)に対し統合サービスを提供してよい。
システムランタイムライブラリレイヤ203は、メディアライブラリ、システムCライブラリおよびディスプレイ管理ライブラリ(surface manager)等のいくつかのC/C++ライブラリを含む。これらのライブラリは、Android(登録商標)システム内の異なるコンポーネントによって用いられてよい。システムランタイムライブラリレイヤ203は、frameworkレイヤ202を用いて、開発者にサービスを提供してよい。
frameworkレイヤ202は、アプリケーションプログラムへのフルアクセスを可能にするアプリケーションプログラミングインタフェース(application programming interface,API)フレームワークを開発者に提供する。具体的には、frameworkレイヤ202は、アプリケーションプログラムを開発するための多くのAPIを提供し、および関連するサービスの要求を満たすAPPが、対応するAPIを呼び出して構築されてよい。
アプリケーションプログラムレイヤ201は、主に、Java(登録商標)言語を用いてコンパイルされたAPPを含む。当該APPで操作スクリーンを操作するとき、ユーザは、frameworkレイヤ202内の関連するAPIを呼び出すことで、システムランタイムライブラリレイヤ203またはLinux(登録商標)カーネルレイヤ204とやり取りして、操作スクリーンに対応する機能を実装する。
図3に示される通り、システムサービス(system server)プロセスは、frameworkレイヤ202で実行される。system serverプロセスは、携帯電話100にほとんどすべてのシステムサービスを提供してよく、これには、例えば、電力マネージャサービス(power manager service,PMS)、アクティビティマネージャサービス(activity manager service,AMS)、ウィンドウマネージャサービス、(window manager service,WMS)、Bluetooth(登録商標)サービス(bluetooth service)、ネットワーク管理サービス(network management service,NMS)、および入力マネージャサービス(input manager service,IMS)が含まれる。
また図3に示される通り、これらのシステムサービスは、system serverプロセス内にスレッド(以降、システムサービススレッドと称される)として常駐してよく、これらのシステムサービススレッドは、アプリケーションプログラムレイヤ201におけるサードパーティのアプリケーションのプロセスまたはデーモン(daemon)プロセスと、プロセス間通信(inter−process communication,IPC)を実装してよい。例えば、WeChatアプリケーションのプロセスは、実行中のプロシージャにおいてinput manager serviceスレッドと通信して、input manager serviceのAPIを呼び出して、WeChatアプリケーションで入力メソッドサービスを提供してよい。
例えば、具体的に、システムサービススレッド(例えば、input manager serviceスレッド)は、binderサービスまたはsocket(ソケット)サービスを用いて、別のアプリケーションのプロセスと通信してよい。
binderサービスを例に用いると、図4に示される通り、3つのモジュール、サーバ、binderドライバおよびクライアントがbinderサービスアーキテクチャ内に提供される。APPレイヤ201で実行中のアプリケーションプロセスはクライアントとして用いられてよく、frameworkレイヤ202によって提供される各システムサービスは、サーバとして用いられてよい。binderドライバは、Linux(登録商標)カーネルレイヤ204に配置されてよく、binderサービスを用いて通信する複数のプロセス(またはスレッド)の各ペアの識別子がbinderドライバ内に記録される。
クライアント(例えば、WeChatプロセス)が関連するシステムサービスを呼び出すために、サーバ(例えば、input manager serviceスレッド)にアクセスを試みるとき、クライアントは、transact()ファンクションを用いてbinderドライバを呼び出してよく、binderドライバは、呼び出しメッセージをサーバのシステムサービススレッドに送信する。binderドライバにより送信された呼び出しメッセージを受信した後、サーバのシステムサービススレッドはbinderスレッドを開始し、onTransact()ファンクションのパラメータに基づき、サーバのサービスコードを実行して、対応するシステムサービスを実装する。
システムサービススレッドが別のプロセスと通信するとき、システムサービススレッドは、ブロックされてよく、または、システムサービススレッドによって占有されるロックオブジェクトは長期間解放されない可能性がある。例えば、WeChatアプリケーションのあるプロセスが実行プロシージャ内で無限ループに入った場合、WeChatアプリケーションの当該プロセスと通信するシステムサービススレッドAはブロックされる。既存のwatchdogメカニズムが用いられる場合、携帯電話100は再起動するようにトリガされる。この結果、携帯電話100のすべての現在実行中のデータが失われる。
本願のいくつかの実施形態において、ロックオブジェクトが占有される場合、端末は、第1のタイマを有効化して計時を開始するようトリガされてよい。第1のタイマが期限切れになったとき、ロックオブジェクトがまだ占有されていれば、ロックオブジェクトはタイムアウトする。この場合、端末は、ロックオブジェクトを占有するシステムサービススレッド(例えば、第1のシステムサービススレッド)の識別子を取得するようトリガされてよい。さらに、端末は、第1のシステムサービススレッドの識別子に基づき、binderドライバを用いて、第1のシステムサービススレッドと通信するターゲットアプリケーションプロセスを判定してよく、当該ターゲットアプリケーションプロセスを終了させてよい。ターゲットアプリケーションプロセスが終了された後、ターゲットアプリケーションプロセスと通信する第1のシステムサービススレッドは解放される。従って、また第1のシステムサービススレッドによって占有されたロックオブジェクトも解放され、その結果、要求を有する別のシステムサービススレッドが当該ロックオブジェクトを継続して用いてよい。
代替的に、本願のいくつかの他の実施形態において、複数のアプリケーションプロセスが端末上で実行されてよく、これらのアプリケーションプロセスは、1または複数のシステムサービススレッドと通信して、関連するシステムサービスを実装してよい。第1のアプリケーションプロセスがシステムサービススレッド(例えば、第1のシステムサービススレッド)と通信するとき、第1のシステムサービススレッドは、別のアプリケーションプロセス(例えば、第2のアプリケーションプロセス)にサービスを提供できない。従って、第1のアプリケーションプロセスが第1のシステムサービススレッドを占有した後、端末は、第2のタイマを有効化して計時を開始するようトリガされてよい。第2のタイマが期限切れになったときに、第1のシステムサービススレッドがまだ占有されている、換言すると、第1のシステムサービススレッドがブロックされている場合、端末は、第1のシステムサービススレッドと現在通信中の特定のプロセス、すなわち、第1のアプリケーションプロセスを判定し、且つ、第1のアプリケーションプロセスを終了するようトリガされてよい。第1のアプリケーションプロセスが終了された後、第1のアプリケーションプロセスと通信中の第1のシステムサービススレッドは解放され、その後、要求を有する別のアプリケーションプロセスが、解放された第1のシステムサービススレッドと通信して、関連するシステムサービスを実装してよい。
また、上述の実施形態からわかるように、端末が、第1のシステムサービススレッドと通信中のアプリケーションプロセスを終了させた後、端末を実行中の別のシステムサービススレッドまたはアプリケーションプロセスは影響を受けることはなく、これにより、端末のフレームフリーズまたはスクリーンフリーズの可能性を低減し、ユーザエクスペリエンスを向上させる。
別の実施形態においては、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが端末で実行され、システムサービスプロセスは少なくとも1つのシステムサービススレッドを含む。少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき、端末は、当該ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定し、ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されたロックオブジェクトが予め設定された時間内に解放されないこと、ターゲットシステムサービススレッドがブロックされること、のうちの少なくとも1つを含み、端末は第1のアプリケーションプロセスを終了させる。
本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。説明を簡単にするため、本願のこの実施形態においては、システムサービススレッドのタイムアウトは、system serverプロセス内のシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないことを意味してよい、または、system serverプロセス内のシステムサービススレッドのブロッキング持続期間が予め設定された持続期間に到達したことを意味してよい。図5に示される通り、方法は、具体的に、以下の段階を含む。
501.端末は、ターゲットシステムサービススレッドがタイムアウトするか否かをモニタリングする。
ターゲットシステムサービススレッドは、system serverプロセス内で実行される任意のシステムサービススレッドであってよく、例えば、ターゲットロックオブジェクト(例えば、inputmanagerservice.thisまたはactivitymanagerservice.this等の任意のロックオブジェクト)を占有するシステムサービススレッドであってよく、または、別のスレッド(またはプロセス)と通信中のシステムサービススレッドであってよい。本願のこの実施形態はこの点において限定されるものではない。
具体的に、端末は、ここでも既存のwatchdogモニタリングメカニズムを用いてよく、端末のプロセッサは、いくつかのシステムサービススレッドによって占有されるロックオブジェクトおよび当該システムサービススレッドをモニタリングする。
例えば、プロセッサは、watchdogスレッドを用いて、ターゲットロックオブジェクトが予め設定された時間(例えば、60秒)内に解放されるか否かをモニタリングしてよい。ターゲットロックオブジェクトが60秒以内に解放されない場合、このことは、ターゲットロックオブジェクトを占有しているシステムサービススレッド(すなわち、ターゲットシステムサービススレッド)がタイムアウトすること、換言すると、ターゲットシステムサービスがタイムアウトすることを示している。
可能な実装において、プロセッサは、ターゲットシステムサービススレッドが、アプリケーションプロセスによって占有されているか否かをモニタリングしてよく、ターゲットシステムサービススレッドがあるアプリケーションプロセスによって占有されており、且つ占有持続期間が予め設定された閾値以上である場合、プロセッサは、ターゲットシステムサービススレッドがタイムアウトすると判定してよい。
別の例では、プロセッサは、さらに、watchdogスレッドを用いて、システムサービススレッドによって報告されたブロッキングイベントが存在するか否かをモニタリングしてよい。システムサービススレッドによって報告されたブロッキングイベントが受信されると、このことは、システムサービススレッド(この場合、システムサービススレッドはターゲットシステムサービススレッドである)がブロックされていること、換言すると、ターゲットシステムサービスがタイムアウトすることを示している。
本願のいくつかの実施形態において、端末内のwatchdogスレッドは、ロックオブジェクトを占有するシステムサービススレッドをシーケンシャルにポーリングしてよい。例えば、それぞれ異なるシステムサービススレッドによって占有されたロックオブジェクトが現在5つ存在する。watchdogスレッドは、5つのシステムサービススレッドにシーケンシャルに電気信号を送信する(すなわち、フィードドッグ、feed dog)。電気信号を受信したシステムサービススレッドは、予め設定された時間内にwatchdogスレッドに応答を返す必要がある(すなわち、キックドッグ、kick dog)。応答を受信した後、watchdogスレッドは、シーケンシャルに、次のシステムサービススレッドのためにフィードドッグする。システムサービススレッド(例えば、システムサービススレッドA)が予め設定された時間内に応答をwatchdogスレッドに返さない場合、システムサービススレッドAによって占有されたロックオブジェクトはタイムアウトすると判定されてよい。この場合、システムサービススレッドAがターゲットシステムサービススレッドであり、システムサービススレッドAによって占有されたロックオブジェクトがターゲットロックオブジェクトである。
本願のいくつかの実施形態において、端末内のwatchdogスレッドは、ロックオブジェクトを占有していない様々なシステムサービススレッドをシーケンシャルにポーリングして、システムサービススレッドがブロックされているか否かを検出してよい。例えば、watchdogスレッドは、ロックオブジェクトを占有していない現在実行中の4つのシステムサービススレッドに、電気信号をシーケンシャルに送信してよい(すなわち、フィードドッグ)。電気信号を受信したシステムサービススレッドは、予め設定された時間内に、応答をwatchdogスレッドに返す必要がある(すなわち、キックドッグ)。システムサービススレッド(例えば、システムサービススレッドB)が、予め設定された時間内に応答をwatchdogスレッドに返さない場合、システムサービススレッドBはブロックされていると判定されてよい。
502.ターゲットシステムサービススレッドがタイムアウトするとき、端末は、ターゲットシステムサービススレッドの識別子を取得する。
ターゲットシステムサービススレッドのブロッキングにより、ターゲットシステムサービススレッドのタイムアウトが生じる場合、ターゲットシステムサービススレッドは、ブロッキングイベントをwatchdogスレッドに報告する。ブロッキングイベントは、端末がターゲットシステムサービススレッドの識別子を取得するように、ブロッキングイベントの識別子、例えば、ターゲットシステムサービススレッドのID番号を保持してよい。代替的に、端末は、getThreadId()ファンクションを呼び出すことで、ターゲットシステムサービススレッドのID番号を取得してよい。
ターゲットロックオブジェクトのタイムアウトにより、ターゲットシステムサービススレッドのタイムアウトが生じる場合、このことは、ターゲットロックオブジェクトを占有するターゲットシステムサービススレッドが、システムリソース(例えば、メモリリソース)を占有し続けており、システムリソースを解放しないことを示している。従って、その後、別のスレッドが関連するサービスを実装するために、そのターゲットロックオブジェクトを取得できない。この場合、可能性として、端末のフレームフリーズあるいはスクリーンフリーズすら生じ得る。
従って、ターゲットロックオブジェクトがタイムアウトするとき、端末は、Java(登録商標)ネイティブインタフェース(Java(登録商標)Native Interface,JNI)インタフェースを呼び出して、ターゲットロックオブジェクトを占有する特定のターゲットシステムサービススレッドの識別子を検索してよい。例えば、端末のプロセッサは、JNIインタフェース内のGetLockOwnerThreadId()ファンクションを呼び出してよい。当該ファンクションの戻り値は、ターゲットロックオブジェクトを占有するターゲットシステムサービススレッドのID番号(すなわち、ターゲットシステムサービススレッドの識別子)である。例えば、GetLockOwnerThreadId()ファンクションの戻り値が01であり、01がwindow manager service(ウィンドウマネージャサービス)スレッドのID番号である場合、ターゲットシステムサービススレッドは、window manager serviceスレッドである。
代替的に、ターゲットシステムサービススレッドの識別子は、端末におけるスレッドを一意に識別可能なターゲットシステムサービススレッドの名前等のパラメータであってよいことが理解され得ることはもちろんである。本願のこの実施形態はこの点において限定されるものではない。
503.端末は、ターゲットシステムサービススレッドの識別子に基づき、ターゲットシステムサービススレッドと通信するアプリケーションプロセスをクエリする。
ターゲットシステムサービススレッドがタイムアウトする原因は、ターゲットシステムサービススレッドと通信するアプリケーションプロセスがブロックされている、または、無限ループに入っている等であってよい。従って、段階503において、タイムアウトするターゲットシステムサービススレッドを判定した後、端末のプロセッサは、さらに、ターゲットシステムサービススレッドの識別子に基づき、ターゲットシステムサービススレッドと通信する特定のアプリケーションプロセスをメモリ内でクエリしてよい。
ターゲットシステムサービススレッドが、binderサービスを用いてアプリケーションプロセスと通信する例を用いる。ここでも図4に示される通り、各システムサービススレッドのID番号等の登録情報がbinderドライバに記録されるので、system serverプロセス内の各システムサービススレッドは、前もってbinderドライバに登録してよい。
例えば、binderドライバに登録するとき、window manager serviceスレッドは、window manager serviceスレッドのID番号およびwindow manager serviceスレッドのファンクション、例えば、window(ウィンドウ)作成ファンクションを報告してよい。この後、アプリケーションプログラムレイヤ201におけるAPP1プロセスが、当該作成ファンクションを用いる必要がある場合、window manager serviceスレッドと通信するためのプロセス間通信要求が、binderドライバに対し開始されてよい。プロセス間通信要求を受信した後、binderドライバは登録情報に基づき、window manager serviceスレッドに対し、対応するWindowを作成するよう要求して、APP1プロセスとwindow manager serviceスレッドとの間のIPC通信プロシージャを完了させてよい。
換言すると、binderドライバは、IPC通信を実行する各システムサービススレッドとアプリケーションプロセスとの間の対応関係を維持するよう構成されてよい。
例えば、表1に示される通り、サードパーティのアプリケーションプロセス(またはdaemonプロセス)のプロセス間通信要求を受信した後は毎回、binderドライバは、上述の登録情報内に、サードパーティのアプリケーションプロセス(またはdaemonプロセス)と、サードパーティのアプリケーションプロセス(またはdaemonプロセス)と通信するシステムサービススレッドとの間の対応関係を記録してよい。段階503において、ターゲットシステムサービススレッドの識別子を判定した後、端末は、表1に示された登録情報から、ターゲットシステムサービススレッド(例えば、window manager serviceスレッド)と通信するアプリケーションプロセスが、WeChatアプリケーションプロセスであることを見つけてよい。WeChatアプリケーションプロセスの識別子は11である。
また、ターゲットシステムサービススレッドが登録情報に記録されていない場合、このことは、ターゲットシステムサービススレッドがIPC通信を実行しない可能性があること、または、ターゲットシステムサービススレッドがサードパーティのアプリケーションプロセス(またはdaemonプロセス)と別の態様(例えば、socketサービスを用いる)で通信する可能性があることを示している。
例えば、ターゲットシステムサービススレッドは、socketサービスを用いてアプリケーションプロセスと通信してよい。本願のこの実施形態において、システムサービススレッドが、socketサービスに基づきアプリケーションプロセスと通信する場合、端末は、当該アプリケーションプロセスの識別子を能動的に記録してよい。このように、ターゲットシステムサービスがタイムアウトする場合、例えば、ターゲットシステムサービススレッドとアプリケーションプロセスとの間のsocket接続の確立がタイムアウトする場合、端末は、ターゲットシステムサービススレッドと通信するアプリケーションプロセスの記録された識別子をクエリして、ターゲットシステムサービスのタイムアウトを生じさせた特定のアプリケーションプロセスを判定してよい。
504.端末は、上述のアプリケーションプロセスを終了させて、ターゲットシステムサービススレッドのタイムアウトにより生じたフレームフリーズを除去する。
端末が、ターゲットシステムサービススレッドと通信する特定のアプリケーションプロセスを判定した後、端末のプロセッサは、当該アプリケーションプロセスを終了(kill)させてよい。アプリケーションプロセスが終了された後、アプリケーションプロセスと通信中のターゲットシステムサービススレッドが解放される。このように、ターゲットシステムサービススレッドによって占有されているターゲットロックオブジェクトは解放されてよく、元々ブロックされていたターゲットシステムサービススレッドが対応するシステムサービスの提供を継続してよく、これにより、システムサービスのタイムアウトにより生じるブロッキングまたはスクリーンフリーズの可能性を低減させる。
さらに、端末がアプリケーションプロセスを終了させた後、プロセッサはさらに、ユーザが再起動されたAPPで処理を継続できるように、当該アプリケーションプロセスを再起動、例えば、WeChatアプリケーションを再起動してよい。
このように、アプリケーションプロセスが終了または再起動された後、当該アプリケーションプロセスと通信中のターゲットシステムサービススレッドによって占有されたターゲットロックオブジェクトは解放されてよく、ターゲットシステムサービススレッドのブロッキングが除去され、端末における別のシステムサービスの実行中のプロシージャは影響を受けない。
アプリケーションプロセスを直接終了または再起動することに加え、代替的に、当業者はアプリケーションプロセスを回復するための回復ポリシーを設定してよいことはもちろんである。例えば、複数のシステムサービススレッドがタイムアウトする場合、アプリケーションプロセスの優先度に基づき、端末は、より低い優先度を有するアプリケーションプロセスを直接終了させ、より高い優先度を有するアプリケーションプロセスを再起動させてよい。
また、アプリケーションプロセスを終了させるとき、端末は、さらに、現在のアプリケーションプロセスの実行の進行状況を記録してよい。このようにして、アプリケーションプロセスを再起動させた後、端末は、当該アプリケーションプロセスを、記録された実行の進行状況に基づき、元のステータスに回復させてよい。例えば、WeChatアプリケーションプロセスがアプリケーションプロセスであり、WeChatアプリケーションプロセスを終了させるとき、端末は、ユーザAとのチャット情報を実行の進行状況として記録してよい。このようにして、WeChatアプリケーションプロセスを再起動させるとき、端末は、WeChatアプリケーションプロセスを、記録された実行の進行状況に基づき、再起動前のステータスに回復させてよく、その結果、サービスは、アプリケーションプロセスの再起動の前後で割り込まれることがなく、これにより、ユーザエクスペリエンスを向上させる。
さらに、アプリケーションプロセスを回復させるとき、端末は、UIインタフェースを用いて、ユーザに対し待機を依頼するプロンプトメッセージをユーザに示して、ユーザが、端末が現在フリーズしていると誤認識することを防いでよい。例えば、図6の(a)に示される通り、アプリケーションプロセスを再起動するとき、端末は、ユーザに対し、アプリケーションプロセスが再起動中であることを通知してよい。図6の(b)に示される通り、アプリケーションプロセスを終了させた後、端末は、ユーザに対し、アプリケーションプロセスが、当該アプリケーションプロセスによって生じたシステムサービスのタイムアウトにより終了されたことを通知してよい。代替的に、図6の(c)に示される通り、ターゲットシステムサービスのタイムアウトを生じさせたアプリケーションプロセスを判定した後、端末は、さらに、プロンプトメッセージダイアログボックス内に、アプリケーションプロセスを終了させるか否かを示すプロンプトメッセージを表示させてよい。ユーザがアプリケーションプロセスを終了させると決定した場合、端末は、アプリケーションプロセスを終了する。
代替的に、アプリケーションプロセスを終了させるとき、端末は、さらに、UIインタフェース上に表示されたアプリケーションプロセスのアプリケーションインタフェーススナップショットを保存してよい。例えば、図7に示される通り、アプリケーションプロセスがWeChatプロセスである場合、WeChatプロセスが終了される前に、UIインタフェース上に現在表示されているWeChatアプリケーションのアプリケーションインタフェース71のスナップショットがローカルに保存されてよい。ここでも図7に示される通り、WeChatプロセスを再起動させるとき、端末は、WeChatプロセスの終了時に保存されたアプリケーションインタフェース71のスナップショットをまず表示させて、同時にバックグランドでWeChatプロセスを起動してよい。例えば、端末はアプリケーションインタフェーススナップショットを2秒間表示させ、アプリケーションインタフェーススナップショットの表示と同時にWeChatプロセスを再起動させる。このようにすると、WeChatプロセスの再起動の時間を視覚的に短くでき、これにより、ユーザエクスペリエンスを向上させる。
代替的に、システムサービスタイムがタイムアウトするたびに、端末は、タイムアウトを生じさせた特定のシステムサービスおよびアプリケーションプロセスを記録してよい。あるアプリケーションプロセスが頻繁にタイムアウトを生じさせる場合、このことは、当該アプリケーションプロセスの実行により生じるフレームフリーズのリスクが比較的高いことを示している。この後、当該アプリケーションプロセスを実行するときに、端末は、追加のシステムリソースを当該アプリケーションプロセスに割り当てる、現在の冗長プロセスを消去する等によって、当該アプリケーションプロセスにより生じるタイムアウトを防いでよい。もちろん、端末がフレームフリーズのリスクが比較的高いといった後続のシナリオを予測し、および、端末がフレームフリーズのリスクが比較的高いシナリオにおいてアプリケーションプロセスによって生じるタイムアウトを前もって防ぐように、端末は、さらに、タイムアウトが生じるたびに特定の実行中のシナリオ、例えば、決済シナリオまたはコールシナリオに関する統計を収集してよい。
端末は、タイムアウトが引き起こされるたびに、タイムアウトを生じさせた特定の記録済みシステムサービスおよびアプリケーションプロセスをサーバに履歴データとして報告してよく、サーバは、ビッグデータ統計に基づき、当該端末に対し、予測ポリシー、または、前もって防止される必要のある、容易にタイムアウトを生じさせるアプリケーションプロセスを判定することが理解できるであろう。本願のこの実施形態はこの点において限定されるものではない。
段階501から504までの端末のアクションは、図1中のプロセッサ101が、メモリ103内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。
システムサービススレッドおよびアプリケーションプロセスが、binderサービスプロセスに基づき、プロセス間通信を実行する場合、端末は、プロセス間通信サービスを実装するためのbinderスレッドを割り当てる。binderスレッド数が多すぎる場合、binderサーバにおけるbinderリソースが枯渇する。その結果、プロセス間通信を要求する別のプロセスは、binderスレッドを申請できない。従って、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。図8に示される通り、方法は以下の段階を含む。
801.binderスレッドの総数が予め設定された値に到達したとき、端末は、各binderスレッドによってサービスされるアプリケーションプロセスを判定する。
具体的に、端末のプロセッサは、現在の端末でbinderサービスを提供するbinderスレッドの総数をカウントしてよい。一般に、オペレーティングシステムによってサポート可能なbinderスレッド数は固定であり、例えば16である。従って、カウントされたbinderスレッドの総数が16である場合、すなわち、binderスレッドがいっぱいであるとき、プロセッサは、さらに、16個のbinderスレッドの各々によってサービスされるアプリケーションプロセスを判定するようトリガされてよい。
例えば、binderドライバが、サードパーティのアプリケーションプロセス(またはdaemonプロセス)によって送信されたプロセス間通信要求を受信した後、毎回binderドライバは、binderリソースプールから、1または複数のbinderスレッドをサードパーティのアプリケーションプロセス(またはdaemonプロセス)に割り当てて、プロセス間通信サービスを実装する。表2に示される通り、互いに通信するシステムサービススレッドと、サードパーティのアプリケーションプロセス(またはdaemonプロセス)との各ペアの対応関係に加え、binderドライバは、さらに、登録情報内に、システムサービススレッドと、サードパーティのアプリケーションプロセスとの各ペアにIPCサービスを提供するbinderスレッドの識別子を記録してよい。従って、段階801において、端末は、表2に示された登録情報において、各binderスレッドによってサービスされるアプリケーションプロセスをクエリしてよい。
802.端末は、すべてのアプリケーションプロセスの各々によって占有されるbinderスレッド数をカウントする。
プロセス間通信を実行するために、1つのアプリケーションプロセスが複数のbinderスレッドを占有する可能性があるので、プロセッサは、各binderスレッドによってサービスされるアプリケーションプロセスに基づき、1つのアプリケーションプロセスによって占有されるbinderスレッド数をカウントしてよい。例えば、上述の16個のbinderスレッドでは、WeChatアプリケーションプロセスが8個のbinderスレッドを占有し、音楽アプリケーションプロセスが5個のbinderスレッドを占有し、ブラウザアプリケーションプロセスが3個のbinderスレッドを占有する。
803.端末は、各アプリケーションプロセスによって占有されるbinderスレッドの数に基づき、少なくとも1つのアプリケーションプロセスを終了させる。
例えば、端末は、最大数のbinderスレッドを占有しているアプリケーションプロセス、例えば、WeChatアプリケーションプロセスを終了または再起動して、WeChatアプリケーションプロセスによって占有されている8個のbinderスレッドを解放してよい。解放されたbinderスレッドは、プロセス間通信を待機中の別のプロセス(または別のスレッド)によって用いられてよい。
代替的に、端末は、さらに、現在すべてが占有されているbinderスレッドを解放すべく、アプリケーションプロセスを終了または再起動してよく、ここで当該アプリケーションプロセスによって占有されているbinderスレッド数は、予め設定された値より大きい。代替的に、端末はさらに、アプリケーションプロセスの優先度に基づき、より低い優先度を有するアプリケーションプロセスによって占有されているbinderスレッドが解放されるように、より低い優先度を有するアプリケーションプロセスを解放してよく、より高い優先度を有するアプリケーションプロセスを確保して、より高い優先度を有するアプリケーションプロセスが終了(または再起動)された後に端末の実行の実行ステータスおよびユーザエクスペリエンスが影響を受けることを回避してよい。
もちろん、代替的に、ユーザは、binderスレッドがすべて占有されたとき終了されるべきアプリケーションプロセスのホワイトリストまたはブラックリストを手動で設定してよい。このようにして、binderスレッドがすべて占有されたとき、ホワイトリスト内のアプリケーションプロセスは確保されてよく、一方でブラックリスト内のアプリケーションプロセスが終了または再起動されてよい。
当業者が、binderスレッドがすべて占有された場合の実際の経験または実際のアプリケーションシナリオに基づき、アプリケーションプロセス回復ポリシーを設定してよいことを理解されたい。本願のこの実施形態はこの点において限定されるものではない。
また、段階801から803までの端末のアクションは、図1中のプロセッサ101が、メモリ103内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。
さらに、binderスレッドがすべて占有された場合に引き起こされる端末のフレームフリーズを防ぐべく、本願の一実施形態は、さらに、システムサービスタイムアウト処理方法を提供する。図9に示される通り、方法は、以下の段階を含む。
901.端末は、ターゲットアプリケーションプロセスによって占有されるbinderスレッド数をカウントする。
ターゲットアプリケーションプロセスは、端末のAPPレイヤにインストールされた任意のアプリケーションプロセスであってよい。本願のこの実施形態はこの点において限定されるものではない。
通常、1つのプロセスは複数のスレッドを含むので、ターゲットアプリケーションプロセスの実行中、当該プロセスは、別のプロセス(例えば、システムサービスプロセス)と通信する必要がある。この場合、binderドライバは、ターゲットアプリケーションプロセス内にプロセス間通信を実装するためのbinderスレッドを作成する。従って、段階701において、端末は、プロセッサを用いて、ターゲットアプリケーションプロセスによって現在占有されているbinderスレッド数を定期的にカウントしてよい。
例えば、端末は、IPCスレッド状態(IPC Thread State)にtransact()ファンクションが入った時点で、ターゲットアプリケーションプロセスによって作成されたbinderスレッドをカウントして、ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数を取得してよい。
902.ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数が第1の閾値以上である場合、端末は、これらのbinderスレッドによって呼び出された特定のAPIに関する統計の収集を開始する。
APIは、1または複数の予め定められたファンクションであり、アプリケーションプログラムおよび開発者が、ソフトウェアまたはハードウェアに基づき、グループのルーティンにアクセス可能になる能力を提供する。このようにして、アプリケーションプログラムはソースコードにアクセスする必要がなく、開発者は、端末内の動作メカニズムの詳細を理解していなくても、対応する機能を実装できる。具体的に、APIは、Linux(登録商標)またはWindows(登録商標)システムにおける任意のAPIであってよく、例えば、ファイルオープンに用いられるAPI:open{}、書き込みに用いられるAPI:write{}またはメッセージキューへのアクセスに用いられるAPI:msgget{}が挙げられる。本願のこの実施形態はこの点において限定されるものではない。
例えば、第1の閾値は8であってよい。具体的に言うと、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が8に到達すると、binderスレッドリソースの枯渇の潜在的リスクが存在する。従って、binderスレッドリソースの枯渇を回避すべく、端末のプロセッサは、さらに、これらのbinderスレッドによって呼び出された特定のAPIに関する統計を収集することで、ターゲットアプリケーションによって現在占有されているこれらのbinderスレッドが、悪意に占有されているか否かを判定してよい。
例えば、各handlerオブジェクトに対し、カウンタが設定されてよく、端末は当該handlerオブジェクトを呼び出すことで、APIを呼び出す。従って、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が8以上である場合、端末は、各handlerオブジェクトのカウンタに、カウントを開始するようトリガしてよい。binderスレッドが1つのhandlerオブジェクトを呼び出すたびに、handlerオブジェクトのカウンタは1つずつ増える。このようにして、各APIオブジェクトが呼び出される回数がカウントされてよい。
代替的に、端末は、さらに、メモリ内に各binderスレッドと、当該binderスレッドによって呼び出されるAPIとの間の対応関係を記録してよい。従って、表3に示される通り、端末は、当該対応関係に基づき、ターゲットアプリケーションプロセスによって占有された各binderスレッドによって特定に呼び出されたAPIに関する統計を収集してよい。
ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数は、同時に占有されたbinderスレッドの数であってよく、または、予め設定された期間(例えば、3秒以内)内に占有されたbinderスレッドの数であってよいことに留意されたい。本願のこの実施形態はこの点において限定されるものではない。
903.API(すなわち、ターゲットAPI)が呼び出される回数が第2の閾値より大きい場合、端末は、ターゲットアプリケーションプロセスのために新しいbinderスレッドを作成することを停止する。
例えば、第2の閾値は16であってよい。具体的に言うと、同一のAPI(すなわち、ターゲットAPI)を呼び出すbinderスレッドの数が16より大きい場合、このことは、ターゲットAPIが比較的負荷が大きい状態にあることを示し、binderスレッドが悪意にターゲットAPIを呼び出しているリスクが存在し得る。この場合、当該binderスレッドリソースの利用率は比較的高く、当該binderスレッドは頻繁に単一のAPIを呼び出す。従って、すべての占有されたbinderスレッドによって引き起こされるブロッキングまたはフレームフリーズを回避すべく、ターゲットアプリケーションプロセスがbinderドライバに対し、新しいbinderスレッドの作成を要求したとき、binderドライバは、ターゲットアプリケーションプロセスの当該要求への応答を停止し、作成されるべきbinderスレッドを待機状態に設定し、binderスレッドリソースが十分になった時点で、ターゲットアプリケーションのための新しいbinderスレッドを作成してよい。
随意で、作成されるべきbinderスレッドを待機状態に設定したとき、端末はさらに、開発者が記録されたログに基づき、ターゲットアプリケーションプロセスがフレームフリーズに遭遇した原因を識別できるように、新しく作成されたbinderスレッドの実行状態を記録するためのログ(log)を挿入してよい。
同様に、ターゲットAPIが呼び出される回数は、ターゲットAPIが同時に呼び出される回数であってよく、または、ターゲットAPIが予め設定された期間内(例えば、3秒以内)に呼び出される回数であってよい。本願のこの実施形態はこの点において限定されるものではない。
904.ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数が、第1の閾値未満の場合、端末は、ターゲットアプリケーションのための新しいbinderスレッドを作成する。
占有されたbinderスレッドが解放された後、ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数は低減する。当該数が第1の閾値未満の値まで低減すると、このことは、ターゲットアプリケーションが使用できる利用可能なbinderスレッドが現在存在することを示している。従って、端末は、段階703で作成されるべきbinderスレッドをウェイクアップすべく、作成されるべきbinderスレッドの状態を、待機状態から作成状態へ設定して、且つ、binderスレッドの作成を開始してよい。
また、ターゲットアプリケーションプロセスによって占有されたbinderスレッドが予め設定された期間内に解放されない場合、作成されるべきbinderスレッドは、待機状態で維持され、作成できない。この場合、ターゲットアプリケーションプロセスは、ANR(アプリケーション不応答、Application Not Responding)メカニズムにより、ユーザに対し、ターゲットアプリケーションプロセスの実行の継続を許容するか、または、ターゲットアプリケーションプロセスを強制終了するかをプロンプトしてよい。
別の可能な実装において、ターゲットアプリケーションプロセスにより占有されたbinderスレッドであり、且つ段階701でカウントされたbinderスレッドの数が、第1の閾値以上である場合、例えば、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が8より大きい場合、このケースでは、比較的多数のbinderスレッドが占有されているので、換言すると、binderスレッドリソースの枯渇の潜在的リスクが存在するので、端末は、段階703、すなわち、ターゲットアプリケーションプロセスにおいて新しく作成されたbinderスレッドの実行を停止すること、作成されるべきbinderスレッドを待機状態に設定すること、およびbinderスレッドリソースが十分(例えば、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が第1の閾値未満)になった時点で、新しいbinderスレッドを作成すること、を実行することを直接トリガされてよい。本願のこの実施形態はこの点において限定されるものではない。
段階901から904までの端末のアクションは、図1中のプロセッサ101が、メモリ103内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。
上述の機能を実装すべく、端末等は、当該機能を実行するための対応するハードウェア構造および/またはソフトウェアモジュールを含むことが理解できるであろう。当業者は、本明細書で開示した実施形態中で説明した例と組み合わせて、ユニット、アルゴリズムおよび段階がハードウェアまたはハードウェアとコンピュータソフトウェアとの組み合わせによって実装されてよいことを容易に認識すべきである。ある機能が、ハードウェアまたはコンピュータソフトウェア駆動のハードウェアにより実行されるか否かは、本技術的解決手段の特定の適用および設計上の制約により決まる。当業者は、それぞれの特定の適用のために、説明された諸機能を実装すべく異なる方法を用いてよいが、当該実装が本願の実施形態の範囲を超えるとみなされるべきではない。
本願の実施形態において、端末は、上述の方法の例に基づき、機能モジュールに分割されてよい。例えば、各機能モジュールは、各対応する機能に基づく分割により得られてよく、または、2または2より多い機能が1つの処理モジュールに統合されてよい。統合モジュールは、ハードウェアの形態で実装されてよく、または、ソフトウェア機能モジュールの形態で実装されてよい。本願のこの実施形態において、モジュール分割は例示的なものであり、論理的な機能分割に過ぎないことに留意されたい。実際の実装においては、別の分割態様が用いられてよい。
各機能モジュールは、各機能に基づく分割により取得される場合、図10が上述の実施形態における端末の可能な概略構造図である。端末は、タイムアウト検出ユニット1001、判定ユニット1002、タイムアウト処理ユニット1003およびディスプレイユニット1004を含む。
タイムアウト検出ユニット1001は、端末が図5中のプロシージャ501を実行することをサポートするよう構成されている。判定ユニット1002は、端末が図5中のプロシージャ502および503、図8中のプロシージャ801および802、および図9中のプロシージャ901および902を実行することをサポートするよう構成されている。タイムアウト処理ユニット1003は、端末が図5中のプロシージャ504、図8中のプロシージャ803、および図9中のプロシージャ903および904を実行することをサポートするよう構成されている。ディスプレイユニット1004は、ターゲットシステムサービススレッドがタイムアウトした原因を表示する、または、ターゲットアプリケーションプロセスを終了させるプロンプトメッセージを表示するよう構成されている。上述した方法の実施形態における段階に関するすべての関連する内容が、対応する機能モジュールの機能の説明に引用されてよく、詳細についてはここで再度説明しない。
統合ユニットが用いられる場合、タイムアウト検出ユニット1001、判定ユニット1002およびタイムアウト処理ユニット1003が処理モジュールに統合されてよく、ディスプレイユニット1004はディスプレイモジュールとして用いられる。
この場合、図11が上述の実施形態における端末の可能な概略構造図である。処理モジュール1101は、端末のアクションを制御および管理するよう構成されている。ディスプレイモジュール1102は、ユーザにより入力される情報、または、ユーザのために提供される情報および端末の様々なメニューを表示するよう構成されている。また、端末は、さらに、命令またはデータを格納するよう構成されたストレージモジュール1103、別の端末デバイスと通信するよう構成された通信モジュール1104等を含んでよい。
例えば、処理モジュール1101は、中央演算処理装置(Central Processing Unit,CPU)、GPU、汎用プロセッサ、デジタル信号プロセッサ(Digital Signal Processor,DSP)、特定用途向け集積回路(Application−Specific Integrated Circuit,ASIC)、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array,FPGA)、または別のプログラマブル論理デバイス、トランジスタ論理デバイス、ハードウェアコンポーネントまたはこれらの任意の組み合わせ等のプロセッサまたはコントローラであってよい。処理モジュールは、本願で開示した内容を参照して説明した様々な例示的な論理ブロック、モジュールおよび回路を実装または実行してよい。代替的に、プロセッサは、コンピューティング機能を実装する複数のプロセッサの組み合わせ、例えば、1または複数のマイクロプロセッサの組み合わせ、または、DSPとマイクロプロセッサとの組み合わせであってよい。
ディスプレイモジュール1102はディスプレイであってよく、具体的には、ディスプレイは、液晶ディスプレイまたは有機発光ダイオード等の形態で構成されてよい。また、タッチパッドは、さらにディスプレイに統合されてよく、ディスプレイ上またはディスプレイ近傍のタッチイベントを収集し、収集されたタッチ情報を別のコンポーネント(例えば、プロセッサ)に送信するよう構成されている。
ストレージモジュール1103は、メモリであってよい。メモリは、高速ランダムアクセスメモリ(RAM)を含んでよく、さらに、不揮発性メモリ、例えば、磁気ディスク記憶デバイス、フラッシュメモリデバイス、または別の揮発性ソリッドステートメモリを含んでよい。
通信モジュール1104は、送受信機、送受信機回路、入力/出力デバイスまたは通信インタフェース等であってよい。例えば、具体的に、通信モジュール1303はBluetooth(登録商標)装置、Wi−Fi(登録商標)装置または周辺機器インタフェース等であってよい。
処理モジュール1101がプロセッサであり、通信モジュール1104が無線周波数回路であり、ストレージモジュール1103がメモリであり、ディスプレイモジュール1102がディスプレイである場合、本願のこの実施形態で提供される端末は、図1に示された携帯電話100であってよい。
上述の実施形態の全部または一部が、ソフトウェア、ハードウェア、ファームウェアまたはこれらの任意の組み合わせを用いて実装されてよい。実施形態を実装すべくソフトウェアプログラムが用いられる場合、実施形態は、コンピュータプログラムプロダクトの形態で全体的または部分的に実装されてよい。コンピュータプログラムプロダクトは、1または複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされ、コンピュータ上で実行されるとき、本願の実施形態によるプロシージャまたは機能が全部または部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワークまたは他のプログラマブル装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に格納されてよく、または、コンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に送信されてよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータサーバまたはデータセンタから、別のウェブサイト、コンピュータ、サーバまたはデータセンタへと、有線(例えば、同軸ケーブル、光ファイバまたはデジタル加入者線(DSL))または無線(例えば、赤外線、無線およびマイクロ波等)の態様で送信されてよい。コンピュータ可読記憶媒体は、コンピュータでアクセス可能な任意の使用可能な媒体、または、サーバ若しくはデータセンタ等の1または複数の使用可能な媒体を統合したデータ記憶デバイスであってよい。使用可能な媒体は、磁気媒体(例えば、フロッピーディスク、ハードディスクまたは磁気テープ)、光媒体(例えば、DVD)または半導体媒体(例えば、ソリッドステートドライブ、Solid State Disk (SSD))等であってよい。
上述の説明は、本願の特定の実装に過ぎず、本願の保護範囲を限定することを意図するものではない。本願で開示した技術的範囲内での変形例または置換例は、本願の保護範囲に属するものとする。従って、本願の保護範囲は、特許請求の範囲に係る保護範囲によって決まるものとする。
本願の実施形態は、通信技術の分野、特に、システムサービスタイムアウト処理方法および装置に関する。
現在、ユーザは、携帯電話、ウェアラブルデバイスおよびタブレットコンピュータ等の端末の円滑な実行に対しますます高い要求を有する。しかしながら、より多くの機能が端末に実装可能になるにつれ、実行中のアプリケーションプログラムによって占有されるリソースはますますフラグメント化され、その結果、ユーザの端末の使用中に、フレームフリーズあるいは場合によってはスクリーンフリーズを引き起こし、ユーザエクスペリエンスに大きな影響を及ぼしている。
通常、端末はウォッチドッグ(watchdog)メカニズムを用いて、端末で提供されているシステムサービスがタイムアウトしたかどうかをモニタリングし得る。例えば、Android(登録商標)システムでは、watchdogは、システムサービス(system server)プロセス内のスレッド(thread)、および、system serverプロセス内に常駐する、例えばウィンドウマネージャサービス(window manager server)およびアクティビティマネージャシステムサービス(activity manager system service)等の様々なシステムサービスのスレッドとして実行されてよい。watchdogは、system serverプロセス内のこれらのスレッドをモニタリングしてよい。スレッドがブロックされ、watchdogが予め設定された時間内に当該スレッドから応答を受信しない場合は、watchdogは端末に対し、Android(登録商標)システム全体を再起動するようトリガする。
換言すると、system server内のスレッドがブロックされていることを検出すると、watchdogは端末に対し再起動をトリガする。強制ブロッキングによるこの回復方式は、ユーザに対し、現在のシナリオにおけるすべてのデータを失わせることを生じさせ、また、ユーザは端末が再起動するまで待機する必要がある。
本願の実施形態は、システムサービスのタイムアウト時に、端末でのフレームフリーズまたはスクリーンフリーズの可能性を低減し、ユーザエクスペリエンスを向上させるためのシステムサービスタイムアウト処理方法および装置を提供する。
上述の目的を達成すべく、以下の技術的解決手段が本願の実施形態において用いられる。
第1の態様により、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが、本方法が適用される端末上で実行され、システムサービスプロセスは、少なくとも1つのシステムサービススレッドを含む。具体的には、方法は、少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき(ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されたロックオブジェクトが予め設定された時間内に解放されないこと、およびターゲットシステムサービススレッドがブロックされることのうちの少なくとも1つを含む)、端末によって、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセス(特に、第1のアプリケーションプロセスおよび第2のアプリケーションプロセスは、少なくとも1つのアプリケーションプロセス内の2つの異なるアプリケーションプロセスである)を判定する段階と、端末によって、第1のアプリケーションプロセスを終了させる段階と、を備える。
このようにして、第1のアプリケーションプロセスが終了された後、第1のアプリケーションプロセスと通信するターゲットシステムサービススレッドによって占有されるターゲットロックオブジェクトは解放され得、ターゲットシステムサービススレッドのブロッキングは除去され、端末上で実行中の別のシステムサービススレッドは影響を受けない。これにより、端末でのフレームフリーズまたはスクリーンフリーズの可能性が低減され、ユーザエクスペリエンスが向上する。
具体的に、ターゲットシステムサービススレッドがブロックされることは、ターゲットシステムサービススレッドと第1のアプリケーションプロセスとの間の通信の持続期間が第1の予め設定された値より大きいこと、および、実行プロシージャにおけるターゲットシステムサービススレッドの保留持続期間が第2の予め設定された値より大きいこと、のうちの少なくとも1つを含んでよい。
可能な設計方法において、システムサービスプロセスは、さらにwatchdogスレッドを含む。方法は、さらに、watchdogスレッドによって、電気信号を上述のシステムサービススレッドにシーケンシャルに送信する段階と、上述のシステムサービススレッド中のターゲットシステムサービススレッドによってフィードバックされる応答信号が予め設定された時間内に受信されない場合、端末によって、ターゲットシステムサービススレッドはタイムアウトすると判定する段階と、を備える。換言すると、端末は、既存のwatchdogメカニズムに基づき、本願のシステムサービスタイムアウト処理方法を実装してよく、実装の複雑さが低減され、システムリソースが節約される。
可能な設計方法において、端末によって、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定する段階は、端末によって、格納された登録情報に対し、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスをクエリする段階を含み、IPCを実行するシステムサービススレッドと、第1のアプリケーションプロセスとの間の対応関係が登録情報に記録されている。
可能な設計方法において、端末によって、第1のアプリケーションプロセスを終了させる段階の後、方法は、端末によって、第1のアプリケーションプロセスを再起動する段階を含み、この結果、ユーザは、再起動された第1のアプリケーションプロセス上で処理を継続できる。
可能な設計方法において、方法は、さらに、端末が現在実行中のbinderスレッドの総数Nをモニタリングすることを含み、Nは0以上の整数である。binderスレッドの総数が第1の予め設定された値より大きい場合、端末は、N個のbinderスレッドの各々によってサービスされているアプリケーションプロセスを判定する。さらに、端末は、すべてのアプリケーションプロセスの各々によって占有されているbinderスレッド数をカウントする。第1のターゲットアプリケーションプロセスにより占有されるbinderスレッドの数が第2の予め設定された値より大きい場合、このことは、第1のターゲットアプリケーションプロセスが多くのbinderリソースを占有し過ぎており、端末でフレームフリーズまたはスクリーンフリーズが生じるリスクが比較的高い状態をもたらすことを示している。従って、端末は、第1のターゲットアプリケーションプロセスを終了させて、第1のターゲットアプリケーションプロセスによって占有されているbinderスレッドを解放してよい。解放されたbinderスレッドは、プロセス間通信を待機する別のプロセス(または別のスレッド)によって用いられてよい。
可能な設計方法において、第2のターゲットアプリケーションプロセスによって占有されるbinderスレッドの数が第2の予め設定された値より大きく、第2のターゲットアプリケーションプロセスの優先度が第1のターゲットアプリケーションプロセスの優先度より高い場合、方法はさらに、端末によって、第2のターゲットアプリケーションプロセスを終了させる段階と、端末によって、第2のターゲットアプリケーションプロセスを再起動させる段階と、を含む。換言すると、比較的多くのbinderスレッドが複数の端末によって占有される場合、端末は、より低い優先度を持つアプリケーションプロセスを解放し、より高い優先度を持つアプリケーションプロセスを確保して、より高い優先度を持つアプリケーションプロセスが終了(または再起動)された後の端末の実行ステータスおよびユーザエクスペリエンスが悪影響を受けることを回避してよい。
可能な設計方法において、端末が第2のターゲットアプリケーションプロセスを終了させるとき、方法は、さらに、端末によって、第2のターゲットアプリケーションプロセスの実行の進行状況を記録する段階を備え、端末によって、第2のターゲットアプリケーションプロセスを再起動する段階は、端末によって、実行の進行状況に基づき、第2のターゲットアプリケーションプロセスを、実行の進行状況と同一の実行ステータスに回復させる段階を含む。このようにして、第2のターゲットアプリケーションプロセスを再起動させるとき、端末は、記録された実行の進行状況に基づき第2のターゲットアプリケーションプロセスを再起動前のステータスに回復させてよく、その結果、アプリケーションプロセスの再起動の前後に、サービスは割り込まれることがないので、ユーザエクスペリエンスが向上する。
可能な設計方法において、方法は、さらに、端末がターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mをカウントし、Mは0以上の整数である、ことを含む。binderスレッドの数Mが第1の閾値以上である場合、このことは、binderスレッドリソースの枯渇の潜在的リスクが存在することを示しており、端末は、ターゲットアプリケーションのための新しいbinderスレッドの作成を停止して、binderスレッドリソースの枯渇を回避してよい。
可能な設計方法において、binderスレッドの数が第1の閾値より大きい場合、端末によってターゲットアプリケーションのための新しいbinderスレッドの作成を停止する段階は、端末がM個のbinderスレッドの各々により呼び出されるAPIに関する統計を収集することを含む。1つのAPIが呼び出される回数が第2の閾値より大きい場合、このことは、当該APIは比較的負荷が重い状態にあり、binderスレッドが悪意でAPIを呼び出しているリスクが存在する可能性があることを示している。この場合、比較的多数のbinderスレッドリソースが占有されており、binderスレッドは頻繁に単一のAPIを呼び出す。従って、端末は、ターゲットアプリケーションのための新しいbinderスレッドの作成要求への応答を停止して、悪意の占有により引き起こされるbinderスレッドリソースの枯渇を回避してよい。
可能な設計方法において、端末によって、ターゲットアプリケーションのための新しいbinderスレッドの作成を停止する段階の後、方法は、さらに、ターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mが第1の閾値未満の場合、端末によって、ターゲットアプリケーションのために新しいbinderスレッドを作成する段階を含む。
可能な設計方法において、方法は、さらに、端末によって、ターゲットシステムサービススレッドがタイムアウトする原因を表示する段階、または、第1のアプリケーションプロセスを終了させるプロンプトメッセージを表示する段階を含む。
可能な設計方法において、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。具体的には、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスは、方法が適用される端末上で実行される。システムサービスプロセスは、少なくとも1つのシステムサービススレッドを含む。具体的には、方法は、第1のシステムサービススレッドがターゲットロックオブジェクトを占有するとき、第1のタイマが計時を開始するようトリガされることを含む。第1のタイマが期限切れになったときに、第1のシステムサービススレッドがまだターゲットロックオブジェクトを解放しない場合は、端末は、ターゲットロックオブジェクトを占有する第1のシステムサービススレッドの識別子を取得するようトリガされる。さらに、端末は、第1のシステムサービススレッドの識別子に基づき、第1のシステムサービススレッドと通信するターゲットアプリケーションプロセスを判定し、ターゲットアプリケーションプロセスを終了させる。
別の可能な設計方法において、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。具体的には、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが、方法が適用される端末上で実行され、システムサービスプロセスは、少なくとも1つのシステムサービススレッドを含む。具体的に、方法は、第1のシステムサービススレッドが、第1のアプリケーションプロセスと通信することを含む。第2のアプリケーションプロセスが第1のシステムサービススレッドによって提供されるシステムサービスを要求するとき、第2のタイマが計時を開始するようトリガされる。第2のタイマが期限切れになったときに、第1のシステムサービススレッドがまだ第1のアプリケーションプロセスと通信中の場合、端末は、第1のアプリケーションプロセスを終了させるようトリガされる。
第2の態様により、本願の一実施形態は、端末を提供する。システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが端末上で実行され、システムサービスプロセスは少なくとも1つのシステムサービススレッドを含む。端末は、少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするか否かを検出するよう構成されたタイムアウト検出ユニットと、ターゲットシステムサービススレッドがタイムアウトするとき、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定するよう構成された判定ユニットであって、ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されるロックオブジェクトが予め設定された時間内に解放されないこと、および、ターゲットシステムサービススレッドがブロックされていることのうちの少なくとも1つを含む、判定ユニットと、第1のアプリケーションプロセスを終了させるよう構成されたタイムアウト処理ユニットと、を備える。
可能な設計方法において、具体的に、判定ユニットは、格納された登録情報に対し、ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスをクエリするよう構成されており、プロセス間通信(IPC)を実行するシステムサービススレッドと、第1のアプリケーションプロセスとの間の対応関係が登録情報に記録されている。
可能な設計方法において、タイムアウト処理ユニットは、さらに、第1のアプリケーションプロセスを再起動させるよう構成されている。
可能な設計方法において、タイムアウト検出ユニットは、さらに、現在実行中のbinderスレッドの総数Nをモニタリングするよう構成されており、Nは0以上の整数であり、判定ユニットは、さらに、binderスレッドの総数が第1の予め設定された値より大きい場合、N個のbinderスレッドの各々によってサービスされるアプリケーションプロセスを判定し、且つ、すべてのターゲットアプリケーションプロセスの各々によって占有されるbinderの数をカウントするよう構成されており、タイムアウト処理ユニットサは、さらに、第1のターゲットアプリケーションプロセスによって占有されるbinderスレッドの数が第2の予め設定された値より大きい場合、第1のターゲットアプリケーションプロセスを終了させるよう構成されている。
可能な設計方法において、第2のターゲットアプリケーションプロセスによって占有されるbinderスレッドの数が第2の予め設定された値より大きく、第2のターゲットアプリケーションプロセスの優先度が第1のターゲットアプリケーションプロセスの優先度より高い場合、タイムアウト処理ユニットは、さらに、第2のターゲットアプリケーションプロセスを終了させる、および、第2のターゲットアプリケーションプロセスを再起動させるよう構成されている。
可能な設計方法において、具体的に、タイムアウト処理ユニットは、第2のターゲットアプリケーションプロセスの実行の進行状況を記録し、実行の進行状況に基づき、第2のターゲットアプリケーションプロセスを、実行の進行状況と同一の実行ステータスに回復させるよう構成されている。
可能な設計方法において、判定ユニットは、さらに、ターゲットアプリケーションにIPCサービスを提供するbinderの数Mをカウントするよう構成されており、Mは0以上の整数であり、タイムアウト処理ユニットは、さらに、binderスレッドの数Mが第1の閾値以上である場合、ターゲットアプリケーションのための新しいbinderスレッドの作成を停止するよう構成されている。
可能な設計方法において、具体的に、タイムアウト処理ユニットは、M個のbinderスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェース(API)に関する統計を収集するよう構成されており、1つのAPIが呼び出される回数が第2の閾値より多い場合、ターゲットアプリケーションのための新しいbinderスレッドの作成要求に応答することを停止するよう構成されている。
可能な設計方法において、タイムアウト処理ユニットは、さらに、ターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mが第1の閾値未満の場合、ターゲットアプリケーションのための新しいbinderスレッドを作成するよう構成されている。
可能な設計方法において、端末は、さらに、ターゲットシステムサービススレッドがタイムアウトする原因を表示する、または第1のアプリケーションプロセスを終了させるプロンプトメッセージを表示するよう構成されたディスプレイユニットを備える。
第3の態様により、本願の一実施形態は、端末を提供する。端末は、プロセッサ、メモリ、バスおよび通信インタフェースを含む。メモリは、コンピュータ実行可能命令を格納するよう構成されており、プロセッサはバスを用いてメモリに接続されており、端末が稼働される場合、プロセッサは、メモリ内に格納されたコンピュータ実行可能命令を実行し、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の1つを実行できるようにされる。
第4の態様により、本願の一実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を格納し、当該命令が上述の端末のうちの任意の1つで実行されると、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の1つを実行できるようにされる。
第5の態様により、本願の一実施形態は、命令を含むコンピュータプログラムプロダクトを提供する。コンピュータプログラムプロダクトが、上述の端末のうちの任意の1つで実行されると、端末は、上述のシステムサービスタイムアウト処理方法のうちの任意の1つを実行できるようにされる。
第2の態様から第5の態様までの任意の設計によりもたらされる技術的効果については、第1の態様における異なる設計方法によりもたらされる技術的効果を参照されたい。ここに詳細を再度説明することはしない。
本願の実施形態による、端末の第1の概略構造図である。
本願の一実施形態によるAndroid(登録商標)システムの第1の概略アーキテクチャ図である。
本願の一実施形態によるAndroid(登録商標)システムの第2の概略アーキテクチャ図である。
本願の一実施形態によるAndroid(登録商標)システムの第3の概略アーキテクチャ図である。
本願の一実施形態によるシステムサービスタイムアウト処理方法の第1の概略フローチャートである。
本願の一実施形態による、システムサービスタイムアウト処理方法のアプリケーションシナリオの第1の概略図である。
本願の一実施形態による、システムサービスタイムアウト処理方法のアプリケーションシナリオの第2の概略図である。
本願の一実施形態による、システムサービスタイムアウト処理方法の第2の概略フローチャートである。
本願の一実施形態によるシステムサービスタイムアウト処理方法の第3の概略フローチャートである。
本願の一実施形態による、端末の第2の概略構造図である。
本願の一実施形態による、端末の第3の概略構造図である。
以下で言及する「第1」および「第2」という用語は、説明のためのものに過ぎず、相対的重要性のを示すもの若しくは暗示、あるいは、示された技術的特徴の数の暗示として理解されるべきではない。従って、「第1」または「第2」として限定される特徴は、1または複数の特徴を明示的または暗黙的に含んでよい。本願の実施形態の説明において、別途の記載がない限り、「複数」は、2または2より多いことを意味する。
本願の実施形態で提供されるシステムサービスタイムアウト処理方法を明確に説明するために、まず、後続の実施形態に現れ得るいくつかの概念について説明する。
プロセス(process)とは、アプリケーションプログラムのデータセット上で実行中のアクティビティであり、オペレーティングシステム(例えば、Android(登録商標)システム)が割り当ておよびリソーススケジューリングを行う基本単位である。各プロセスは、アドレス空間を占有する。アプリケーションプログラムは、オペレーティングシステム上で、対応する機能を実装するための1または複数のプロセスとして実行される。
スレッド(thread)とは、1プロセスの1エンティティであり、プロセスより小さく、独立して実行可能な基本単位である。スレッドは、あるプロセスのすべてのリソースを、同一プロセスに属する他の複数のスレッドと共有可能である。1つのスレッドが、別のスレッドを作成およびキャンセルできる。1つのプロセス内の複数のスレッドが並列に実行可能である。
オブジェクトロッキングとは、一度に1つのスレッドのみがメソッドまたは変数にアクセスすることを保証するメカニズムである。Java(登録商標)言語では、あるスレッドがシンクロナイズドコードにアクセスすると、当該コードが属するロックオブジェクトが取得される必要がある。さもなければ、当該スレッドは、当該ロックオブジェクトが解放されるまで、待機(またはブロック)されることになる。シンクロナイズドコードとは、キーワード"synchronized"で修飾されたメソッドまたはステートメントブロックである。
換言すると、オブジェクトロッキングとは、最大で1つのスレッドがロックを取得できることを意味する排他処理である。スレッドAが、スレッドBが保持するロックオブジェクトの取得を試みると、スレッドAは待機する必要がある、またはブロックされる必要がある。スレッドAは、スレッドBがロックを解放するまで、対応するメソッドまたは変数にアクセスすべく、ロックオブジェクトを取得できない。
通常、スレッドブロッキングとは、実行プロシージャ内のスレッドの保留持続期間が予め設定された値より大きい場合に生じるタイムアウトを指す。例えば、スレッドAの実行プロシージャで、実行を継続するために、スレッドBの実行結果が入力パラメータとして用いられる必要がある。この場合、スレッドAがスレッドBの実行結果を取得しない場合、実行は保留される。スレッドAが予め設定された時間内にスレッドBの実行結果を取得しない場合、スレッドAはブロックされる。代替的に、スレッドブロッキングとは、スレッドがあるプロセスとの通信時に、当該スレッドがそのプロセスによって、長期間占有されることを原因として、当該スレッドが別のプロセスのためのサービスを提供できない現象を指してよい。
現在、端末は、watchdogメカニズムに基づき、オペレーティングシステム内のいくつかのスレッドおよびロックオブジェクトをモニタリングし得る。モニタリングされるスレッドがブロックされている場合、または、モニタリングされるロックオブジェクトが長期間解放されない場合、端末は、保留またはスクリーンフリーズを回避すべく、オペレーティングシステム全体を再起動するようトリガされ得る。
しかしながら、オペレーティングシステム全体を再起動することによるフリーズの除去は、スレッドがブロックされる、またはロックオブジェクトが正常に解放されないという問題を解決できるが、オペレーティングシステム内で正常に実行中の別のスレッドおよびロックオブジェクトも強制的に終了される。実行中のアプリケーションプログラムの大量のデータが失われることは間違いない。また、ユーザエクスペリエンスも犠牲になる。
従って、本願の実施形態では、既存のwatchdogトリガメカニズムに基づき、モニタリングされるスレッドがブロックされていること、または、モニタリングされるロックオブジェクトが長期間解放されないことを検出したときに、端末がまず、ブロックされているスレッドまたはロックオブジェクトを占有するスレッド(またはプロセス)と通信中のアプリケーションプロセスを判定してよい。さらに、端末は、アプリケーションプロセスの終了または再起動等の回復ポリシーを用いて、現在のスレッドがブロックされている、またはロックオブジェクトが解放できないという問題を解決してよい。このようにすると、オペレーティングシステムにおけるブロックされていない、または、ロックオブジェクトを正常に解放するスレッドの実行中のプロシージャは影響を受けることがなく、スレッドブロッキングまたはロックオブジェクト解放エラーにより引き起こされるフリーズの問題も解決されてよく、これによりユーザエクスペリエンスが大きく向上する。
上述のアプリケーションプロセスは、端末のアプリケーションレイヤでのアプリケーションプログラムのプロセスであってよく、または、バックグランドで実行中のデーモン(daemon)プロセスであってよい。このことは、本願の実施形態において限定されるものではない。
本願の一実施形態で提供されるシステムサービスタイムアウト処理方法は、携帯電話、ウェアラブルデバイス、拡張現実(augmented reality,AR)/仮想現実(virtual reality,VR)デバイス、タブレットコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ(ultra−mobile personal computer,UMPC)、ネットブックまたはパーソナルデジタルアシスタント(personal digital assistant,PDA)等の任意の端末に適用されてよい。以降の実施形態において、特定の形態の端末に限定されないのはもちろんである。
図1に示される通り、本願の実施形態における端末は、携帯電話100であってよい。以下に、携帯電話100を例に用いて、実施形態について詳細に説明する。当該図に示される携帯電話100は、端末の一例に過ぎず、携帯電話100は、図に示されるものより多いまたは少ないコンポーネントを有してよく、2または2より多いコンポーネントが組み合わされてよく、あるいは異なるコンポーネント構成が用いられてよいことを理解されたい。
図1に示される通り、具体的に携帯電話100は、プロセッサ101、無線周波数(radio frequency,RF)回路102、メモリ103、タッチスクリーン104、Bluetooth(登録商標)装置105、1または複数のセンサ106、ワイヤレスフィディリティ(wireless fidelity,Wi−Fi)装置107、位置特定装置108、オーディオ回路109、周辺機器インタフェース110および電力システム111等のコンポーネントを含んでよい。これらのコンポーネントは、1または複数の通信バスまたは信号ケーブル(図1に不図示)を用いて互いに通信してよい。当業者であれは、図1に示されるハードウェア構造は、携帯電話に対する限定を構成せず、携帯電話100は、図に示されるものより多いまたは少ないコンポーネントを含んでよく、いくつかのコンポーネントは組み合わされてよく、あるいは異なるコンポーネント構成が用いられてよいことを理解するであろう。
以下に、図1を参照して、携帯電話100のコンポーネントについて詳細に説明する。
プロセッサ101は、携帯電話100の制御センターである。プロセッサ101は、様々なポートおよび配線を用いて携帯電話100の様々な部分に接続され、メモリ103内に格納されたアプリケーションプログラムを稼働または実行し、メモリ103内に格納されたデータを呼び出して、携帯電話100の様々な機能を実行して、データを処理する。いくつかの実施形態において、プロセッサ101は、1または複数の処理ユニットを含んでよい。例えば、プロセッサ101は、Huawei Technologies Co.,Ltd製のKirin 960チップであってよい。本願のいくつかの実施形態において、プロセッサ101はさらに、収集された指紋を検証するよう構成された指紋検証チップを含んでよい。
無線周波数回路102は、情報の送信および受信プロシージャにおいて、またはコールプロシージャにおいて、無線信号を送信および受信するよう構成されてよい。特に、基地局からダウンリンクデータを受信した後、無線周波数回路102は、ダウンリンクデータをプロセッサ101に処理させるために送信してよい。また、無線周波数回路102は、関連するアップリンクデータを基地局に送信する。一般に、無線周波数回路は、アンテナ、少なくとも1つの増幅器、送受信機、カプラ、低雑音増幅器およびデュプレクサ等を含むが、これらに限定されるものではない。また、無線周波数回路102は、さらに、無線通信を通して別のデバイスと通信してよい。グローバルシステムフォーモバイルコミュニケーション、汎用パケット無線サービス、符号分割多重アクセス、広帯域符号分割多重アクセス、ロングタームエボリューション、電子メールおよびショートメッセージサービス等を含む無線通信における任意の通信規格またはプロトコルが用いられてよく、これらに限定されるものではない。
メモリ103は、アプリケーションプログラムおよびデータを格納するよう構成されている。プロセッサ101は、携帯電話100の様々な機能を実行し、および、データを処理するために、メモリ103内に格納されたアプリケーションプログラムおよびデータを実行する。メモリ103は、主に、プログラム格納領域およびデータ格納領域を含む。プログラム格納領域は、オペレーティングシステムと、少なくとも1つの機能(例えば、サウンド再生またはイメージ再生機能)により必要とされるアプリケーションプログラムとを格納してよい。データ格納領域は、携帯電話100の使用を基に作成されたデータ(例えば、オーディオデータまたは電話帳)を格納してよい。また、メモリ103は、高速ランダムアクセスメモリ(random access memory,RAM)を含んでよく、さらに、磁気ディスク記憶デバイス、フラッシュメモリデバイス等の不揮発性メモリ、または別の揮発性ソリッドステートメモリを含んでよい。メモリ103は、Apple社が開発したiOS(登録商標)オペレーティングシステムおよびGoogle社が開発したAndroid(登録商標)オペレーティングシステム等の様々なオペレーティングシステムを格納してよい。メモリ103は独立していてよく、通信バスを用いてプロセッサ101に接続される。代替的に、メモリ103はプロセッサ101に統合されてよい。
具体的に、タッチスクリーン104は、タッチパッド104−1およびディスプレイ104‐2を含んでよい。
タッチパッド104−1は、携帯電話100のユーザにより、携帯電話100上でまたはその近傍で行われたタッチイベント(例えば、ユーザにより、指またはスタイラス等の好適なオブジェクトを用いてタッチパッド104−1上でまたはその近傍で、行われた操作)を収集してよく、収集されたタッチ情報を別のコンポーネント(プロセッサ101等)に送信してよい。ユーザにより、タッチパッド104−1の近傍で行われたタッチイベントは、フローティングタッチと呼ばれてよい。フローティングタッチとは、ユーザがオブジェクト(例えば、アイコン)を選択、移動またはドラッグするために、タッチパッドを直接タッチする必要がないこと、および、ユーザが所望の機能を実行するために端末の付近にいるだけでよいことを意味してよい。また、タッチパッド104−1は、抵抗タイプ、静電容量タイプ、赤外線タイプまたは表面弾性波タイプ等の複数のタイプで実装されてよい。
ディスプレイ(ディスプレイスクリーンとも言う)104‐2は、ユーザにより入力された情報またはユーザに対し提供される情報、および携帯電話100の様々なメニューを表示するよう構成されてよい。ディスプレイ104−2は、液晶ディスプレイまたは有機発光ダイオード等の形態で構成されてよい。タッチパッド104−1は、ディスプレイ104−2を覆ってよい。タッチパッド104−1上またはその近傍でのタッチイベントを検出すると、タッチパッド104−1は、タッチイベントのタイプを判定すべく、そのタッチイベントをプロセッサ101に転送する。次に、プロセッサ101は、タッチイベントのタイプに基づき、対応するビジュアル出力をディスプレイ104−2に提供してよい。図1中のタッチパッド104−1およびディスプレイスクリーン104−2は、携帯電話100の入力および出力機能を実装するための2つの独立したコンポーネントとして用いられるが、いくつかの実施形態においては、携帯電話100の入力および出力機能を実装すべく、タッチパッド104−1およびディスプレイスクリーン104−2が統合されてよい。タッチスクリーン104は、材料の複数のレイヤを積層することで形成されることが理解可能である。本願のこの実施形態において、タッチパッド(レイヤ)およびディスプレイスクリーン(レイヤ)のみが表示されており、別のレイヤは本願のこの実施形態において記載されていない。また、タッチパッド104−1は、ベゼルレス画面の形態で、携帯電話100の前面に構成されてよく、ディスプレイスクリーン104−2も、ベゼルレス画面の形態で携帯電話100の前面に構成されてよい。このようにして、ベゼルレス構造が携帯電話の前面に実装されてよい。
また、携帯電話100は、さらに、指紋認識機能を有してよい。例えば、指紋認識部112が、携帯電話100の裏面(例えば、背面カメラの下方)に構成されてよく、または、指紋認識部112は、携帯電話100の前面(例えば、タッチスクリーン104の下方)に構成されてよい。別の例では、指紋収集コンポーネント112は、指紋認識機能を実装すべく、タッチスクリーン104に配置されてよく、すなわち、指紋収集コンポーネント112は、携帯電話100の指紋認識機能を実装すべく、タッチスクリーン104に統合されてよい。この場合、指紋収集コンポーネント112はタッチスクリーン104内に構成されてよく、タッチスクリーン104の一部であってよい、または、別の態様でタッチスクリーン104内に構成されてよい。本願のこの実施形態における指紋収集コンポーネント112の主なコンポーネントは、指紋センサである。指紋センサは、任意のタイプの感知技術を用いてよく、このようなものとして、光感知技術、静電容量感知技術、圧電感知技術または超音波感知技術等が含まれるが、これらに限定されるものではない。
携帯電話100は、さらに、携帯電話100と別の短距離端末(例えば、携帯電話またはスマートウォッチ)との間でデータを交換するよう構成されたBluetooth(登録商標)装置105を含んでよい。本願のこの実施形態において、Bluetooth(登録商標)装置は、集積回路またはBluetooth(登録商標)チップ等であってよい。
携帯電話100は、さらに、光学センサ、モーションセンサおよび別のセンサ等の少なくとも1つのセンサ106を含んでよい。具体的には、光学センサは、環境光センサおよび近接センサを含んでよい。環境光センサは、周囲光の輝度に基づき、タッチスクリーン104のディスプレイの輝度を調整してよい。近接センサは、携帯電話100が耳に近づけられたとき、ディスプレイの電源をオフにしてよい。モーションセンサのタイプとしての加速度計センサが、全方向(通常、3軸)における加速度の値を検出してよく、センサの静止時の重力の値および方向を検出してよく、携帯電話の姿勢(ランドスケープモードとポートレイトモードとの間の画面切り替え、関連するゲームまたは磁力計の姿勢較正等)を識別するためのアプリケーションプログラム、振動の識別に関連する機能(歩数計またはノック等)等において用いられてよい。ジャイロスコープ、バロメータ、湿度計、温度計および赤外線センサ等の他センサが、さらに、携帯電話100上に配置されてよい。詳細については、ここで説明はしない。
Wi−Fi(登録商標)装置107は、携帯電話100に対し、Wi−Fi(登録商標)関連の規格プロトコルに準拠するネットワークアクセスを提供するよう構成されている。携帯電話100は、ユーザが電子メールを送信および受信する、ウェブページを閲覧する、ストリーミングメディアにアクセスする等を補助すべく、Wi−Fi(登録商標)装置107を用いて、Wi−Fi(登録商標)アクセスポイントにアクセスしてよい。Wi−Fi(登録商標)装置107は、ユーザに無線ブロードバンドインターネットアクセスを提供する。いくつかの他の実施形態においては、Wi−Fi(登録商標)装置107は、Wi−Fi(登録商標)無線アクセスポイントとして用いられてよく、別の端末に対し、Wi−Fi(登録商標)ネットワークアクセスを提供してよい。
位置特定装置108は、携帯電話100に地理的位置を提供するよう構成されている。具体的に、位置特定装置108は、全地球測位システム(global positioning system,GPS)、Beidou衛星測位システムまたはロシアのGLONASS等の位置特定システムの受信機であってよいことが理解できるであろう。位置特定システムによって送信された地理的位置を受信した後、位置特定装置108は、当該情報を処理させるためにプロセッサ101に送信し、または、当該情報を格納させるためにメモリ103に送信する。いくつかの他の実施形態においては、位置特定装置108は、さらに、アシスト型全地球測位システム(assisted global positioning system,AGPS)の受信機であってよい。AGPSシステムは、位置特定装置108が測距サービスおよび位置特定サービスを完了するのを補助するアシストサーバとして機能する。この場合、アシスト位置特定サーバは、端末、例えば携帯電話100の位置特定装置108(すなわち、GPS受信機)と、無線通信ネットワークを通して通信し、位置特定補助を提供する。いくつかの他の実施形態においては、位置特定装置108は、Wi−Fi(登録商標)アクセスポイントに基づく位置特定技術であってよい。各Wi−Fi(登録商標)アクセスポイントは、グローバル一意メディアアクセス制御(media access control,MAC)アドレスを有し、端末は、Wi−Fi(登録商標)が有効になっている場合、周囲のWi−Fi(登録商標)アクセスポイントのブロードキャスト信号をスキャンし、収集することができる。従って、端末は、Wi−Fi(登録商標)アクセスポイントによってブロードキャストされたMACアドレスを取得できる。端末は、Wi−Fi(登録商標)アクセスポイントを識別可能なかかるデータ(例えば、MACアドレス)を、無線通信ネットワークを通してロケーションサーバに送信する。ロケーションサーバは、各Wi−Fi(登録商標)アクセスポイントの地理的位置を取得し、Wi−Fi(登録商標)ブロードキャスト信号の強度を参照して端末の地理的位置を計算し、端末の地理的位置を、端末の位置特定装置108に送信する。
音声回路109、スピーカ113およびマイク114は、ユーザと携帯電話100との間のオーディオインタフェースを提供してよい。可聴周波数回路109は、受信したオーディオデータから変換された電気信号をスピーカ113に送信してよく、スピーカ113は当該電気信号を出力するための音声信号に変換する。また、マイク114は、収集された音声信号を電気信号に変換し、可聴周波数回路109は、当該電気信号を受信した後に当該電気信号をオーディオデータに変換し、その後、オーディオデータを例えば別の携帯電話に送信するために、オーディオデータをRF回路102に出力する、またはさらなる処理のためにオーディオデータをメモリ103に出力する。
周辺機器インタフェース110は、外部入/出力デバイス(キーボード、マウス、外部ディスプレイ、外部メモリおよび加入者識別モジュールカード等)用の様々なインタフェースを提供するよう構成されている。例えば、携帯電話100は、ユニバーサルシリアルバス(universal serial bus,USB)インタフェースを用いてマウスに接続され、ユーザ識別モジュールカードのカードスロット上の金属コンタクトを用いて、電気通信事業者が提供するユーザ識別モジュールカード(subscriber identification module,SIM)に接続される。周辺機器インタフェース110は、外部入/出力周辺デバイスを、プロセッサ101およびメモリ103に結合するよう構成されてよい。
携帯電話100は、さらに、電力を様々なコンポーネントに提供する電源装置111(例えば、バッテリまたは電力管理チップ)を含んでよい。バッテリは、充電管理、放電管理および電力消費管理等の機能が電源装置111を用いて実装されるように、電力管理チップを用いてプロセッサ101に論理的に接続されてよい。
図1には図示されていないが、携帯電話100は、さらに、カメラ(前面カメラおよび/または背面カメラ)、フラッシュライト、マイクロプロジェクション装置および近距離無線通信(near field communication,NFC)等を含んでよい。詳細については、ここに説明はしない。
さらに、携帯電話100は、Android(登録商標)またはiOS等のオペレーティングシステムを実行してよい。本願のこの実施形態はこの点において限定されるものではない。
Android(登録商標)オペレーティングシステムを例に用いると、図2に示される通り、Android(登録商標)オペレーティングシステムは、降順に、アプリケーションプログラムレイヤ201(すなわち、APPレイヤ)、アプリケーションプログラムフレームワークレイヤ202(すなわち、frameworkレイヤ)、システムランタイムライブラリレイヤ203(すなわち、libraryレイヤ)およびLinux(登録商標)カーネルレイヤ204の4つのレイヤに分割されてよい。
Linux(登録商標)カーネルレイヤ204は、携帯電話100のセキュリティ(security)制御、メモリ管理(memory management)、プログラム管理(process management)、ネットワークスタック(network stack)およびドライバモデル(driver model)等の機能に用いられてよい。Linux(登録商標)カーネルレイヤ204はまた、ハードウェア(例えば、CPU、ネットワークインタフェースカードおよびメモリ)とソフトウェアスタックとの間の抽象化レイヤとしても機能し、特定のハードウェアの詳細情報を非表示にして、上位レイヤ(システムランタイムライブラリレイヤ203、アプリケーションプログラムフレームワークレイヤ202およびアプリケーションプログラムレイヤ201)に対し統合サービスを提供してよい。
システムランタイムライブラリレイヤ203は、メディアライブラリ、システムCライブラリおよびディスプレイ管理ライブラリ(surface manager)等のいくつかのC/C++ライブラリを含む。これらのライブラリは、Android(登録商標)システム内の異なるコンポーネントによって用いられてよい。システムランタイムライブラリレイヤ203は、frameworkレイヤ202を用いて、開発者にサービスを提供してよい。
frameworkレイヤ202は、アプリケーションプログラムへのフルアクセスを可能にするアプリケーションプログラミングインタフェース(application programming interface,API)フレームワークを開発者に提供する。具体的には、frameworkレイヤ202は、アプリケーションプログラムを開発するための多くのAPIを提供し、および関連するサービスの要求を満たすAPPが、対応するAPIを呼び出して構築されてよい。
アプリケーションプログラムレイヤ201は、主に、Java(登録商標)言語を用いてコンパイルされたAPPを含む。当該APPで操作スクリーンを操作するとき、ユーザは、frameworkレイヤ202内の関連するAPIを呼び出すことで、システムランタイムライブラリレイヤ203またはLinux(登録商標)カーネルレイヤ204とやり取りして、操作スクリーンに対応する機能を実装する。
図3に示される通り、システムサービス(system server)プロセスは、frameworkレイヤ202で実行される。system serverプロセスは、携帯電話100にほとんどすべてのシステムサービスを提供してよく、これには、例えば、電力マネージャサービス(power manager service,PMS)、アクティビティマネージャサービス(activity manager service,AMS)、ウィンドウマネージャサービス、(window manager service,WMS)、Bluetooth(登録商標)サービス(bluetooth service)、ネットワーク管理サービス(network management service,NMS)、および入力マネージャサービス(input manager service,IMS)が含まれる。
また図3に示される通り、これらのシステムサービスは、system serverプロセス内にスレッド(以降、システムサービススレッドと称される)として常駐してよく、これらのシステムサービススレッドは、アプリケーションプログラムレイヤ201におけるサードパーティのアプリケーションのプロセスまたはデーモン(daemon)プロセスと、プロセス間通信(inter−process communication,IPC)を実装してよい。例えば、WeChatアプリケーションのプロセスは、実行中のプロシージャにおいてinput manager serviceスレッドと通信して、input manager serviceのAPIを呼び出して、WeChatアプリケーションで入力メソッドサービスを提供してよい。
例えば、具体的に、システムサービススレッド(例えば、input manager serviceスレッド)は、binderサービスまたはsocket(ソケット)サービスを用いて、別のアプリケーションのプロセスと通信してよい。
binderサービスを例に用いると、図4に示される通り、3つのモジュール、サーバ、binderドライバおよびクライアントがbinderサービスアーキテクチャ内に提供される。APPレイヤ201で実行中のアプリケーションプロセスはクライアントとして用いられてよく、frameworkレイヤ202によって提供される各システムサービスは、サーバとして用いられてよい。binderドライバは、Linux(登録商標)カーネルレイヤ204に配置されてよく、binderサービスを用いて通信する複数のプロセス(またはスレッド)の各ペアの識別子がbinderドライバ内に記録される。
クライアント(例えば、WeChatプロセス)が関連するシステムサービスを呼び出すために、サーバ(例えば、input manager serviceスレッド)にアクセスを試みるとき、クライアントは、transact()ファンクションを用いてbinderドライバを呼び出してよく、binderドライバは、呼び出しメッセージをサーバのシステムサービススレッドに送信する。binderドライバにより送信された呼び出しメッセージを受信した後、サーバのシステムサービススレッドはbinderスレッドを開始し、onTransact()ファンクションのパラメータに基づき、サーバのサービスコードを実行して、対応するシステムサービスを実装する。
システムサービススレッドが別のプロセスと通信するとき、システムサービススレッドは、ブロックされてよく、または、システムサービススレッドによって占有されるロックオブジェクトは長期間解放されない可能性がある。例えば、WeChatアプリケーションのあるプロセスが実行プロシージャ内で無限ループに入った場合、WeChatアプリケーションの当該プロセスと通信するシステムサービススレッドAはブロックされる。既存のwatchdogメカニズムが用いられる場合、携帯電話100は再起動するようにトリガされる。この結果、携帯電話100のすべての現在実行中のデータが失われる。
本願のいくつかの実施形態において、ロックオブジェクトが占有される場合、端末は、第1のタイマを有効化して計時を開始するようトリガされてよい。第1のタイマが期限切れになったとき、ロックオブジェクトがまだ占有されていれば、ロックオブジェクトはタイムアウトする。この場合、端末は、ロックオブジェクトを占有するシステムサービススレッド(例えば、第1のシステムサービススレッド)の識別子を取得するようトリガされてよい。さらに、端末は、第1のシステムサービススレッドの識別子に基づき、binderドライバを用いて、第1のシステムサービススレッドと通信するターゲットアプリケーションプロセスを判定してよく、当該ターゲットアプリケーションプロセスを終了させてよい。ターゲットアプリケーションプロセスが終了された後、ターゲットアプリケーションプロセスと通信する第1のシステムサービススレッドは解放される。従って、また第1のシステムサービススレッドによって占有されたロックオブジェクトも解放され、その結果、要求を有する別のシステムサービススレッドが当該ロックオブジェクトを継続して用いてよい。
代替的に、本願のいくつかの他の実施形態において、複数のアプリケーションプロセスが端末上で実行されてよく、これらのアプリケーションプロセスは、1または複数のシステムサービススレッドと通信して、関連するシステムサービスを実装してよい。第1のアプリケーションプロセスがシステムサービススレッド(例えば、第1のシステムサービススレッド)と通信するとき、第1のシステムサービススレッドは、別のアプリケーションプロセス(例えば、第2のアプリケーションプロセス)にサービスを提供できない。従って、第1のアプリケーションプロセスが第1のシステムサービススレッドを占有した後、端末は、第2のタイマを有効化して計時を開始するようトリガされてよい。第2のタイマが期限切れになったときに、第1のシステムサービススレッドがまだ占有されている、換言すると、第1のシステムサービススレッドがブロックされている場合、端末は、第1のシステムサービススレッドと現在通信中の特定のプロセス、すなわち、第1のアプリケーションプロセスを判定し、且つ、第1のアプリケーションプロセスを終了するようトリガされてよい。第1のアプリケーションプロセスが終了された後、第1のアプリケーションプロセスと通信中の第1のシステムサービススレッドは解放され、その後、要求を有する別のアプリケーションプロセスが、解放された第1のシステムサービススレッドと通信して、関連するシステムサービスを実装してよい。
また、上述の実施形態からわかるように、端末が、第1のシステムサービススレッドと通信中のアプリケーションプロセスを終了させた後、端末で実行中の別のシステムサービススレッドまたはアプリケーションプロセスは影響を受けることはなく、これにより、端末のフレームフリーズまたはスクリーンフリーズの可能性を低減し、ユーザエクスペリエンスを向上させる。
別の実施形態においては、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが端末で実行され、システムサービスプロセスは少なくとも1つのシステムサービススレッドを含む。少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき、端末は、当該ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定し、ターゲットシステムサービススレッドのタイムアウトは、ターゲットシステムサービススレッドによって占有されたロックオブジェクトが予め設定された時間内に解放されないこと、ターゲットシステムサービススレッドがブロックされること、のうちの少なくとも1つを含み、端末は第1のアプリケーションプロセスを終了させる。
本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。説明を簡単にするため、本願のこの実施形態においては、システムサービススレッドのタイムアウトは、system serverプロセス内のシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないことを意味してよい、または、system serverプロセス内のシステムサービススレッドのブロッキング持続期間が予め設定された持続期間に到達したことを意味してよい。図5に示される通り、方法は、具体的に、以下の段階を含む。
501.端末は、ターゲットシステムサービススレッドがタイムアウトするか否かをモニタリングする。
ターゲットシステムサービススレッドは、system serverプロセス内で実行される任意のシステムサービススレッドであってよく、例えば、ターゲットロックオブジェクト(例えば、inputmanagerservice.thisまたはactivitymanagerservice.this等の任意のロックオブジェクト)を占有するシステムサービススレッドであってよく、または、別のスレッド(またはプロセス)と通信中のシステムサービススレッドであってよい。本願のこの実施形態はこの点において限定されるものではない。
具体的に、端末は、ここでも既存のwatchdogモニタリングメカニズムを用いてよく、端末のプロセッサは、いくつかのシステムサービススレッドによって占有されるロックオブジェクトおよび当該システムサービススレッドをモニタリングする。
例えば、プロセッサは、watchdogスレッドを用いて、ターゲットロックオブジェクトが予め設定された時間(例えば、60秒)内に解放されるか否かをモニタリングしてよい。ターゲットロックオブジェクトが60秒以内に解放されない場合、このことは、ターゲットロックオブジェクトを占有しているシステムサービススレッド(すなわち、ターゲットシステムサービススレッド)がタイムアウトすること、換言すると、ターゲットシステムサービスがタイムアウトすることを示している。
可能な実装において、プロセッサは、ターゲットシステムサービススレッドが、アプリケーションプロセスによって占有されているか否かをモニタリングしてよく、ターゲットシステムサービススレッドがあるアプリケーションプロセスによって占有されており、且つ占有持続期間が予め設定された閾値以上である場合、プロセッサは、ターゲットシステムサービススレッドがタイムアウトすると判定してよい。
別の例では、プロセッサは、さらに、watchdogスレッドを用いて、システムサービススレッドによって報告されたブロッキングイベントが存在するか否かをモニタリングしてよい。システムサービススレッドによって報告されたブロッキングイベントが受信されると、このことは、システムサービススレッド(この場合、システムサービススレッドはターゲットシステムサービススレッドである)がブロックされていること、換言すると、ターゲットシステムサービスがタイムアウトすることを示している。
本願のいくつかの実施形態において、端末内のwatchdogスレッドは、ロックオブジェクトを占有するシステムサービススレッドをシーケンシャルにポーリングしてよい。例えば、それぞれ異なるシステムサービススレッドによって占有されたロックオブジェクトが現在5つ存在する。watchdogスレッドは、5つのシステムサービススレッドにシーケンシャルに電気信号を送信する(すなわち、フィードドッグ、feed dog)。電気信号を受信したシステムサービススレッドは、予め設定された時間内にwatchdogスレッドに応答を返す必要がある(すなわち、キックドッグ、kick dog)。応答を受信した後、watchdogスレッドは、シーケンシャルに、次のシステムサービススレッドのためにフィードドッグする。システムサービススレッド(例えば、システムサービススレッドA)が予め設定された時間内に応答をwatchdogスレッドに返さない場合、システムサービススレッドAによって占有されたロックオブジェクトはタイムアウトすると判定されてよい。この場合、システムサービススレッドAがターゲットシステムサービススレッドであり、システムサービススレッドAによって占有されたロックオブジェクトがターゲットロックオブジェクトである。
本願のいくつかの実施形態において、端末内のwatchdogスレッドは、ロックオブジェクトを占有していない様々なシステムサービススレッドをシーケンシャルにポーリングして、システムサービススレッドがブロックされているか否かを検出してよい。例えば、watchdogスレッドは、ロックオブジェクトを占有していない現在実行中の4つのシステムサービススレッドに、電気信号をシーケンシャルに送信してよい(すなわち、フィードドッグ)。電気信号を受信したシステムサービススレッドは、予め設定された時間内に、応答をwatchdogスレッドに返す必要がある(すなわち、キックドッグ)。システムサービススレッド(例えば、システムサービススレッドB)が、予め設定された時間内に応答をwatchdogスレッドに返さない場合、システムサービススレッドBはブロックされていると判定されてよい。
502.ターゲットシステムサービススレッドがタイムアウトするとき、端末は、ターゲットシステムサービススレッドの識別子を取得する。
ターゲットシステムサービススレッドのブロッキングにより、ターゲットシステムサービススレッドのタイムアウトが生じる場合、ターゲットシステムサービススレッドは、ブロッキングイベントをwatchdogスレッドに報告する。ブロッキングイベントは、端末がターゲットシステムサービススレッドの識別子を取得するように、ブロッキングイベントの識別子、例えば、ターゲットシステムサービススレッドのID番号を保持してよい。代替的に、端末は、getThreadId()ファンクションを呼び出すことで、ターゲットシステムサービススレッドのID番号を取得してよい。
ターゲットロックオブジェクトのタイムアウトにより、ターゲットシステムサービススレッドのタイムアウトが生じる場合、このことは、ターゲットロックオブジェクトを占有するターゲットシステムサービススレッドが、システムリソース(例えば、メモリリソース)を占有し続けており、システムリソースを解放しないことを示している。従って、その後、別のスレッドが関連するサービスを実装するために、そのターゲットロックオブジェクトを取得できない。この場合、可能性として、端末のフレームフリーズあるいはスクリーンフリーズすら生じ得る。
従って、ターゲットロックオブジェクトがタイムアウトするとき、端末は、Java(登録商標)ネイティブインタフェース(Java(登録商標)Native Interface,JNI)インタフェースを呼び出して、ターゲットロックオブジェクトを占有する特定のターゲットシステムサービススレッドの識別子を検索してよい。例えば、端末のプロセッサは、JNIインタフェース内のGetLockOwnerThreadId()ファンクションを呼び出してよい。当該ファンクションの戻り値は、ターゲットロックオブジェクトを占有するターゲットシステムサービススレッドのID番号(すなわち、ターゲットシステムサービススレッドの識別子)である。例えば、GetLockOwnerThreadId()ファンクションの戻り値が01であり、01がwindow manager service(ウィンドウマネージャサービス)スレッドのID番号である場合、ターゲットシステムサービススレッドは、window manager serviceスレッドである。
代替的に、ターゲットシステムサービススレッドの識別子は、端末におけるスレッドを一意に識別可能なターゲットシステムサービススレッドの名前等のパラメータであってよいことが理解され得ることはもちろんである。本願のこの実施形態はこの点において限定されるものではない。
503.端末は、ターゲットシステムサービススレッドの識別子に基づき、ターゲットシステムサービススレッドと通信するアプリケーションプロセスをクエリする。
ターゲットシステムサービススレッドがタイムアウトする原因は、ターゲットシステムサービススレッドと通信するアプリケーションプロセスがブロックされている、または、無限ループに入っている等であってよい。従って、段階503において、タイムアウトするターゲットシステムサービススレッドを判定した後、端末のプロセッサは、さらに、ターゲットシステムサービススレッドの識別子に基づき、ターゲットシステムサービススレッドと通信する特定のアプリケーションプロセスをメモリ内でクエリしてよい。
ターゲットシステムサービススレッドが、binderサービスを用いてアプリケーションプロセスと通信する例を用いる。ここでも図4に示される通り、各システムサービススレッドのID番号等の登録情報がbinderドライバに記録されるので、system serverプロセス内の各システムサービススレッドは、前もってbinderドライバに登録してよい。
例えば、binderドライバに登録するとき、window manager serviceスレッドは、window manager serviceスレッドのID番号およびwindow manager serviceスレッドのファンクション、例えば、window(ウィンドウ)作成ファンクションを報告してよい。この後、アプリケーションプログラムレイヤ201におけるAPP1プロセスが、当該作成ファンクションを用いる必要がある場合、window manager serviceスレッドと通信するためのプロセス間通信要求が、binderドライバに対し開始されてよい。プロセス間通信要求を受信した後、binderドライバは登録情報に基づき、window manager serviceスレッドに対し、対応するWindowを作成するよう要求して、APP1プロセスとwindow manager serviceスレッドとの間のIPC通信プロシージャを完了させてよい。
換言すると、binderドライバは、IPC通信を実行する各システムサービススレッドとアプリケーションプロセスとの間の対応関係を維持するよう構成されてよい。
例えば、表1に示される通り、サードパーティのアプリケーションプロセス(またはdaemonプロセス)のプロセス間通信要求を受信した後は毎回、binderドライバは、上述の登録情報内に、サードパーティのアプリケーションプロセス(またはdaemonプロセス)と、サードパーティのアプリケーションプロセス(またはdaemonプロセス)と通信するシステムサービススレッドとの間の対応関係を記録してよい。段階503において、ターゲットシステムサービススレッドの識別子を判定した後、端末は、表1に示された登録情報から、ターゲットシステムサービススレッド(例えば、window manager serviceスレッド)と通信するアプリケーションプロセスが、WeChatアプリケーションプロセスであることを見つけてよい。WeChatアプリケーションプロセスの識別子は11である。
また、ターゲットシステムサービススレッドが登録情報に記録されていない場合、このことは、ターゲットシステムサービススレッドがIPC通信を実行しない可能性があること、または、ターゲットシステムサービススレッドがサードパーティのアプリケーションプロセス(またはdaemonプロセス)と別の態様(例えば、socketサービスを用いる)で通信する可能性があることを示している。
例えば、ターゲットシステムサービススレッドは、socketサービスを用いてアプリケーションプロセスと通信してよい。本願のこの実施形態において、システムサービススレッドが、socketサービスに基づきアプリケーションプロセスと通信する場合、端末は、当該アプリケーションプロセスの識別子を能動的に記録してよい。このように、ターゲットシステムサービスがタイムアウトする場合、例えば、ターゲットシステムサービススレッドとアプリケーションプロセスとの間のsocket接続の確立がタイムアウトする場合、端末は、ターゲットシステムサービススレッドと通信するアプリケーションプロセスの記録された識別子をクエリして、ターゲットシステムサービスのタイムアウトを生じさせた特定のアプリケーションプロセスを判定してよい。
504.端末は、上述のアプリケーションプロセスを終了させて、ターゲットシステムサービススレッドのタイムアウトにより生じたフレームフリーズを除去する。
端末が、ターゲットシステムサービススレッドと通信する特定のアプリケーションプロセスを判定した後、端末のプロセッサは、当該アプリケーションプロセスを終了(kill)させてよい。アプリケーションプロセスが終了された後、アプリケーションプロセスと通信中のターゲットシステムサービススレッドが解放される。このように、ターゲットシステムサービススレッドによって占有されているターゲットロックオブジェクトは解放されてよく、元々ブロックされていたターゲットシステムサービススレッドが対応するシステムサービスの提供を継続してよく、これにより、システムサービスのタイムアウトにより生じるブロッキングまたはスクリーンフリーズの可能性を低減させる。
さらに、端末がアプリケーションプロセスを終了させた後、プロセッサはさらに、ユーザが再起動されたAPPで処理を継続できるように、当該アプリケーションプロセスを再起動、例えば、WeChatアプリケーションを再起動してよい。
このように、アプリケーションプロセスが終了または再起動された後、当該アプリケーションプロセスと通信中のターゲットシステムサービススレッドによって占有されたターゲットロックオブジェクトは解放されてよく、ターゲットシステムサービススレッドのブロッキングが除去され、端末における別のシステムサービスの実行中のプロシージャは影響を受けない。
アプリケーションプロセスを直接終了または再起動することに加え、代替的に、当業者はアプリケーションプロセスを回復するための回復ポリシーを設定してよいことはもちろんである。例えば、複数のシステムサービススレッドがタイムアウトする場合、アプリケーションプロセスの優先度に基づき、端末は、より低い優先度を有するアプリケーションプロセスを直接終了させ、より高い優先度を有するアプリケーションプロセスを再起動させてよい。
また、アプリケーションプロセスを終了させるとき、端末は、さらに、現在のアプリケーションプロセスの実行の進行状況を記録してよい。このようにして、アプリケーションプロセスを再起動させた後、端末は、当該アプリケーションプロセスを、記録された実行の進行状況に基づき、元のステータスに回復させてよい。例えば、WeChatアプリケーションプロセスがアプリケーションプロセスであり、WeChatアプリケーションプロセスを終了させるとき、端末は、ユーザAとのチャット情報を実行の進行状況として記録してよい。このようにして、WeChatアプリケーションプロセスを再起動させるとき、端末は、WeChatアプリケーションプロセスを、記録された実行の進行状況に基づき、再起動前のステータスに回復させてよく、その結果、サービスは、アプリケーションプロセスの再起動の前後で割り込まれることがなく、これにより、ユーザエクスペリエンスを向上させる。
さらに、アプリケーションプロセスを回復させるとき、端末は、UIインタフェースを用いて、ユーザに対し待機を依頼するプロンプトメッセージをユーザに示して、ユーザが、端末が現在フリーズしていると誤認識することを防いでよい。例えば、図6の(a)に示される通り、アプリケーションプロセスを再起動するとき、端末は、ユーザに対し、アプリケーションプロセスが再起動中であることを通知してよい。図6の(b)に示される通り、アプリケーションプロセスを終了させた後、端末は、ユーザに対し、アプリケーションプロセスが、当該アプリケーションプロセスによって生じたシステムサービスのタイムアウトにより終了されたことを通知してよい。代替的に、図6の(c)に示される通り、ターゲットシステムサービスのタイムアウトを生じさせたアプリケーションプロセスを判定した後、端末は、さらに、プロンプトメッセージダイアログボックス内に、アプリケーションプロセスを終了させるか否かを示すプロンプトメッセージを表示させてよい。ユーザがアプリケーションプロセスを終了させると決定した場合、端末は、アプリケーションプロセスを終了する。
代替的に、アプリケーションプロセスを終了させるとき、端末は、さらに、UIインタフェース上に表示されたアプリケーションプロセスのアプリケーションインタフェーススナップショットを保存してよい。例えば、図7に示される通り、アプリケーションプロセスがWeChatプロセスである場合、WeChatプロセスが終了される前に、UIインタフェース上に現在表示されているWeChatアプリケーションのアプリケーションインタフェース71のスナップショットがローカルに保存されてよい。ここでも図7に示される通り、WeChatプロセスを再起動させるとき、端末は、WeChatプロセスの終了時に保存されたアプリケーションインタフェース71のスナップショットをまず表示させて、同時にバックグランドでWeChatプロセスを起動してよい。例えば、端末はアプリケーションインタフェーススナップショットを2秒間表示させ、アプリケーションインタフェーススナップショットの表示と同時にWeChatプロセスを再起動させる。このようにすると、WeChatプロセスの再起動の時間を視覚的に短くでき、これにより、ユーザエクスペリエンスを向上させる。
代替的に、システムサービスタイムがタイムアウトするたびに、端末は、タイムアウトを生じさせた特定のシステムサービスおよびアプリケーションプロセスを記録してよい。あるアプリケーションプロセスが頻繁にタイムアウトを生じさせる場合、このことは、当該アプリケーションプロセスの実行により生じるフレームフリーズのリスクが比較的高いことを示している。この後、当該アプリケーションプロセスを実行するときに、端末は、追加のシステムリソースを当該アプリケーションプロセスに割り当てる、現在の冗長プロセスを消去する等によって、当該アプリケーションプロセスにより生じるタイムアウトを防いでよい。もちろん、端末がフレームフリーズのリスクが比較的高いといった後続のシナリオを予測し、および、端末がフレームフリーズのリスクが比較的高いシナリオにおいてアプリケーションプロセスによって生じるタイムアウトを前もって防ぐように、端末は、さらに、タイムアウトが生じるたびに特定の実行中のシナリオ、例えば、決済シナリオまたはコールシナリオに関する統計を収集してよい。
端末は、タイムアウトが引き起こされるたびに、タイムアウトを生じさせた特定の記録済みシステムサービスおよびアプリケーションプロセスをサーバに履歴データとして報告してよく、サーバは、ビッグデータ統計に基づき、当該端末に対し、予測ポリシー、または、前もって防止される必要のある、容易にタイムアウトを生じさせるアプリケーションプロセスを判定することが理解できるであろう。本願のこの実施形態はこの点において限定されるものではない。
段階501から504までの端末のアクションは、図1中のプロセッサ101が、メモリ103内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。
システムサービススレッドおよびアプリケーションプロセスが、binderサービスプロセスに基づき、プロセス間通信を実行する場合、端末は、プロセス間通信サービスを実装するためのbinderスレッドを割り当てる。binderスレッド数が多すぎる場合、binderサーバにおけるbinderリソースが枯渇する。その結果、プロセス間通信を要求する別のプロセスは、binderスレッドを申請できない。従って、本願の一実施形態は、システムサービスタイムアウト処理方法を提供する。図8に示される通り、方法は以下の段階を含む。
801.binderスレッドの総数が予め設定された値に到達したとき、端末は、各binderスレッドによってサービスされるアプリケーションプロセスを判定する。
具体的に、端末のプロセッサは、現在の端末でbinderサービスを提供するbinderスレッドの総数をカウントしてよい。一般に、オペレーティングシステムによってサポート可能なbinderスレッド数は固定であり、例えば16である。従って、カウントされたbinderスレッドの総数が16である場合、すなわち、binderスレッドがいっぱいであるとき、プロセッサは、さらに、16個のbinderスレッドの各々によってサービスされるアプリケーションプロセスを判定するようトリガされてよい。
例えば、binderドライバが、サードパーティのアプリケーションプロセス(またはdaemonプロセス)によって送信されたプロセス間通信要求を受信した後、毎回binderドライバは、binderリソースプールから、1または複数のbinderスレッドをサードパーティのアプリケーションプロセス(またはdaemonプロセス)に割り当てて、プロセス間通信サービスを実装する。表2に示される通り、互いに通信するシステムサービススレッドと、サードパーティのアプリケーションプロセス(またはdaemonプロセス)との各ペアの対応関係に加え、binderドライバは、さらに、登録情報内に、システムサービススレッドと、サードパーティのアプリケーションプロセスとの各ペアにIPCサービスを提供するbinderスレッドの識別子を記録してよい。従って、段階801において、端末は、表2に示された登録情報において、各binderスレッドによってサービスされるアプリケーションプロセスをクエリしてよい。
802.端末は、すべてのアプリケーションプロセスの各々によって占有されるbinderスレッド数をカウントする。
プロセス間通信を実行するために、1つのアプリケーションプロセスが複数のbinderスレッドを占有する可能性があるので、プロセッサは、各binderスレッドによってサービスされるアプリケーションプロセスに基づき、1つのアプリケーションプロセスによって占有されるbinderスレッド数をカウントしてよい。例えば、上述の16個のbinderスレッドでは、WeChatアプリケーションプロセスが8個のbinderスレッドを占有し、音楽アプリケーションプロセスが5個のbinderスレッドを占有し、ブラウザアプリケーションプロセスが3個のbinderスレッドを占有する。
803.端末は、各アプリケーションプロセスによって占有されるbinderスレッドの数に基づき、少なくとも1つのアプリケーションプロセスを終了させる。
例えば、端末は、最大数のbinderスレッドを占有しているアプリケーションプロセス、例えば、WeChatアプリケーションプロセスを終了または再起動して、WeChatアプリケーションプロセスによって占有されている8個のbinderスレッドを解放してよい。解放されたbinderスレッドは、プロセス間通信を待機中の別のプロセス(または別のスレッド)によって用いられてよい。
代替的に、端末は、さらに、現在すべてが占有されているbinderスレッドを解放すべく、アプリケーションプロセスを終了または再起動してよく、ここで当該アプリケーションプロセスによって占有されているbinderスレッド数は、予め設定された値より大きい。代替的に、端末はさらに、アプリケーションプロセスの優先度に基づき、より低い優先度を有するアプリケーションプロセスによって占有されているbinderスレッドが解放されるように、より低い優先度を有するアプリケーションプロセスを解放してよく、より高い優先度を有するアプリケーションプロセスを確保して、より高い優先度を有するアプリケーションプロセスが終了(または再起動)された後に端末の実行の実行ステータスおよびユーザエクスペリエンスが影響を受けることを回避してよい。
もちろん、代替的に、ユーザは、binderスレッドがすべて占有されたとき終了されるべきアプリケーションプロセスのホワイトリストまたはブラックリストを手動で設定してよい。このようにして、binderスレッドがすべて占有されたとき、ホワイトリスト内のアプリケーションプロセスは確保されてよく、一方でブラックリスト内のアプリケーションプロセスが終了または再起動されてよい。
当業者が、binderスレッドがすべて占有された場合の実際の経験または実際のアプリケーションシナリオに基づき、アプリケーションプロセス回復ポリシーを設定してよいことを理解されたい。本願のこの実施形態はこの点において限定されるものではない。
また、段階801から803までの端末のアクションは、図1中のプロセッサ101が、メモリ103内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。
さらに、binderスレッドがすべて占有された場合に引き起こされる端末のフレームフリーズを防ぐべく、本願の一実施形態は、さらに、システムサービスタイムアウト処理方法を提供する。図9に示される通り、方法は、以下の段階を含む。
901.端末は、ターゲットアプリケーションプロセスによって占有されるbinderスレッド数をカウントする。
ターゲットアプリケーションプロセスは、端末のAPPレイヤにインストールされた任意のアプリケーションプロセスであってよい。本願のこの実施形態はこの点において限定されるものではない。
通常、1つのプロセスは複数のスレッドを含むので、ターゲットアプリケーションプロセスの実行中、当該プロセスは、別のプロセス(例えば、システムサービスプロセス)と通信する必要がある。この場合、binderドライバは、ターゲットアプリケーションプロセス内にプロセス間通信を実装するためのbinderスレッドを作成する。従って、段階901において、端末は、プロセッサを用いて、ターゲットアプリケーションプロセスによって現在占有されているbinderスレッド数を定期的にカウントしてよい。
例えば、端末は、IPCスレッド状態(IPC Thread State)にtransact()ファンクションが入った時点で、ターゲットアプリケーションプロセスによって作成されたbinderスレッドをカウントして、ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数を取得してよい。
902.ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数が第1の閾値以上である場合、端末は、これらのbinderスレッドによって呼び出された特定のAPIに関する統計の収集を開始する。
APIは、1または複数の予め定められたファンクションであり、アプリケーションプログラムおよび開発者が、ソフトウェアまたはハードウェアに基づき、グループのルーティンにアクセス可能になる能力を提供する。このようにして、アプリケーションプログラムはソースコードにアクセスする必要がなく、開発者は、端末内の動作メカニズムの詳細を理解していなくても、対応する機能を実装できる。具体的に、APIは、Linux(登録商標)またはWindows(登録商標)システムにおける任意のAPIであってよく、例えば、ファイルオープンに用いられるAPI:open{}、書き込みに用いられるAPI:write{}またはメッセージキューへのアクセスに用いられるAPI:msgget{}が挙げられる。本願のこの実施形態はこの点において限定されるものではない。
例えば、第1の閾値は8であってよい。具体的に言うと、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が8に到達すると、binderスレッドリソースの枯渇の潜在的リスクが存在する。従って、binderスレッドリソースの枯渇を回避すべく、端末のプロセッサは、さらに、これらのbinderスレッドによって呼び出された特定のAPIに関する統計を収集することで、ターゲットアプリケーションによって現在占有されているこれらのbinderスレッドが、悪意に占有されているか否かを判定してよい。
例えば、各handlerオブジェクトに対し、カウンタが設定されてよく、端末は当該handlerオブジェクトを呼び出すことで、APIを呼び出す。従って、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が8以上である場合、端末は、各handlerオブジェクトのカウンタに、カウントを開始するようトリガしてよい。binderスレッドが1つのhandlerオブジェクトを呼び出すたびに、handlerオブジェクトのカウンタは1つずつ増える。このようにして、各APIオブジェクトが呼び出される回数がカウントされてよい。
代替的に、端末は、さらに、メモリ内に各binderスレッドと、当該binderスレッドによって呼び出されるAPIとの間の対応関係を記録してよい。従って、表3に示される通り、端末は、当該対応関係に基づき、ターゲットアプリケーションプロセスによって占有された各binderスレッドによって特定に呼び出されたAPIに関する統計を収集してよい。
ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数は、同時に占有されたbinderスレッドの数であってよく、または、予め設定された期間(例えば、3秒以内)内に占有されたbinderスレッドの数であってよいことに留意されたい。本願のこの実施形態はこの点において限定されるものではない。
903.API(すなわち、ターゲットAPI)が呼び出される回数が第2の閾値より大きい場合、端末は、ターゲットアプリケーションプロセスのために新しいbinderスレッドを作成することを停止する。
例えば、第2の閾値は16であってよい。具体的に言うと、同一のAPI(すなわち、ターゲットAPI)を呼び出すbinderスレッドの数が16より大きい場合、このことは、ターゲットAPIが比較的負荷が大きい状態にあることを示し、binderスレッドが悪意にターゲットAPIを呼び出しているリスクが存在し得る。この場合、当該binderスレッドリソースの利用率は比較的高く、当該binderスレッドは頻繁に単一のAPIを呼び出す。従って、すべての占有されたbinderスレッドによって引き起こされるブロッキングまたはフレームフリーズを回避すべく、ターゲットアプリケーションプロセスがbinderドライバに対し、新しいbinderスレッドの作成を要求したとき、binderドライバは、ターゲットアプリケーションプロセスの当該要求への応答を停止し、作成されるべきbinderスレッドを待機状態に設定し、binderスレッドリソースが十分になった時点で、ターゲットアプリケーションのための新しいbinderスレッドを作成してよい。
随意で、作成されるべきbinderスレッドを待機状態に設定したとき、端末はさらに、開発者が記録されたログに基づき、ターゲットアプリケーションプロセスがフレームフリーズに遭遇した原因を識別できるように、新しく作成されたbinderスレッドの実行状態を記録するためのログ(log)を挿入してよい。
同様に、ターゲットAPIが呼び出される回数は、ターゲットAPIが同時に呼び出される回数であってよく、または、ターゲットAPIが予め設定された期間内(例えば、3秒以内)に呼び出される回数であってよい。本願のこの実施形態はこの点において限定されるものではない。
904.ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数が、第1の閾値未満の場合、端末は、ターゲットアプリケーションのための新しいbinderスレッドを作成する。
占有されたbinderスレッドが解放された後、ターゲットアプリケーションプロセスによって占有されたbinderスレッドの数は低減する。当該数が第1の閾値未満の値まで低減すると、このことは、ターゲットアプリケーションが使用できる利用可能なbinderスレッドが現在存在することを示している。従って、端末は、段階903で作成されるべきbinderスレッドをウェイクアップすべく、作成されるべきbinderスレッドの状態を、待機状態から作成状態へ設定して、且つ、binderスレッドの作成を開始してよい。
また、ターゲットアプリケーションプロセスによって占有されたbinderスレッドが予め設定された期間内に解放されない場合、作成されるべきbinderスレッドは、待機状態で維持され、作成できない。この場合、ターゲットアプリケーションプロセスは、ANR(アプリケーション不応答、Application Not Responding)メカニズムにより、ユーザに対し、ターゲットアプリケーションプロセスの実行の継続を許容するか、または、ターゲットアプリケーションプロセスを強制終了するかをプロンプトしてよい。
別の可能な実装において、ターゲットアプリケーションプロセスにより占有されたbinderスレッドであり、且つ段階901でカウントされたbinderスレッドの数が、第1の閾値以上である場合、例えば、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が8より大きい場合、このケースでは、比較的多数のbinderスレッドが占有されているので、換言すると、binderスレッドリソースの枯渇の潜在的リスクが存在するので、端末は、段階903、すなわち、ターゲットアプリケーションプロセスにおいて新しく作成されたbinderスレッドの実行を停止すること、作成されるべきbinderスレッドを待機状態に設定すること、およびbinderスレッドリソースが十分(例えば、ターゲットアプリケーションプロセスによって占有されたbinderスレッド数が第1の閾値未満)になった時点で、新しいbinderスレッドを作成すること、を実行することを直接トリガされてよい。本願のこの実施形態はこの点において限定されるものではない。
段階901から904までの端末のアクションは、図1中のプロセッサ101が、メモリ103内に格納された命令またはソフトウェアを実行させて、端末に対し、システムサービスタイムアウト処理方法を完了するように命令することで実行されてよい。
上述の機能を実装すべく、端末等は、当該機能を実行するための対応するハードウェア構造および/またはソフトウェアモジュールを含むことが理解できるであろう。当業者は、本明細書で開示した実施形態中で説明した例と組み合わせて、ユニット、アルゴリズムおよび段階がハードウェアまたはハードウェアとコンピュータソフトウェアとの組み合わせによって実装されてよいことを容易に認識すべきである。ある機能が、ハードウェアまたはコンピュータソフトウェア駆動のハードウェアにより実行されるか否かは、本技術的解決手段の特定の適用および設計上の制約により決まる。当業者は、それぞれの特定の適用のために、説明された諸機能を実装すべく異なる方法を用いてよいが、当該実装が本願の実施形態の範囲を超えるとみなされるべきではない。
本願の実施形態において、端末は、上述の方法の例に基づき、機能モジュールに分割されてよい。例えば、各機能モジュールは、各対応する機能に基づく分割により得られてよく、または、2または2より多い機能が1つの処理モジュールに統合されてよい。統合モジュールは、ハードウェアの形態で実装されてよく、または、ソフトウェア機能モジュールの形態で実装されてよい。本願のこの実施形態において、モジュール分割は例示的なものであり、論理的な機能分割に過ぎないことに留意されたい。実際の実装においては、別の分割態様が用いられてよい。
各機能モジュールは、各機能に基づく分割により取得される場合、図10が上述の実施形態における端末の可能な概略構造図である。端末は、タイムアウト検出ユニット1001、判定ユニット1002、タイムアウト処理ユニット1003およびディスプレイユニット1004を含む。
タイムアウト検出ユニット1001は、端末が図5中のプロシージャ501を実行することをサポートするよう構成されている。判定ユニット1002は、端末が図5中のプロシージャ502および503、図8中のプロシージャ801および802、および図9中のプロシージャ901および902を実行することをサポートするよう構成されている。タイムアウト処理ユニット1003は、端末が図5中のプロシージャ504、図8中のプロシージャ803、および図9中のプロシージャ903および904を実行することをサポートするよう構成されている。ディスプレイユニット1004は、ターゲットシステムサービススレッドがタイムアウトした原因を表示する、または、ターゲットアプリケーションプロセスを終了させるプロンプトメッセージを表示するよう構成されている。上述した方法の実施形態における段階に関するすべての関連する内容が、対応する機能モジュールの機能の説明に引用されてよく、詳細についてはここで再度説明しない。
統合ユニットが用いられる場合、タイムアウト検出ユニット1001、判定ユニット1002およびタイムアウト処理ユニット1003が処理モジュールに統合されてよく、ディスプレイユニット1004はディスプレイモジュールとして用いられる。
この場合、図11が上述の実施形態における端末の可能な概略構造図である。処理モジュール1101は、端末のアクションを制御および管理するよう構成されている。ディスプレイモジュール1102は、ユーザにより入力される情報、または、ユーザのために提供される情報および端末の様々なメニューを表示するよう構成されている。また、端末は、さらに、命令またはデータを格納するよう構成されたストレージモジュール1103、別の端末デバイスと通信するよう構成された通信モジュール1104等を含んでよい。
例えば、処理モジュール1101は、中央演算処理装置(Central Processing Unit,CPU)、GPU、汎用プロセッサ、デジタル信号プロセッサ(Digital Signal Processor,DSP)、特定用途向け集積回路(Application−Specific Integrated Circuit,ASIC)、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array,FPGA)、または別のプログラマブル論理デバイス、トランジスタ論理デバイス、ハードウェアコンポーネントまたはこれらの任意の組み合わせ等のプロセッサまたはコントローラであってよい。処理モジュールは、本願で開示した内容を参照して説明した様々な例示的な論理ブロック、モジュールおよび回路を実装または実行してよい。代替的に、プロセッサは、コンピューティング機能を実装する複数のプロセッサの組み合わせ、例えば、1または複数のマイクロプロセッサの組み合わせ、または、DSPとマイクロプロセッサとの組み合わせであってよい。
ディスプレイモジュール1102はディスプレイであってよく、具体的には、ディスプレイは、液晶ディスプレイまたは有機発光ダイオード等の形態で構成されてよい。また、タッチパッドは、さらにディスプレイに統合されてよく、ディスプレイ上またはディスプレイ近傍のタッチイベントを収集し、収集されたタッチ情報を別のコンポーネント(例えば、プロセッサ)に送信するよう構成されている。
ストレージモジュール1103は、メモリであってよい。メモリは、高速ランダムアクセスメモリ(RAM)を含んでよく、さらに、不揮発性メモリ、例えば、磁気ディスク記憶デバイス、フラッシュメモリデバイス、または別の揮発性ソリッドステートメモリを含んでよい。
通信モジュール1104は、送受信機、送受信機回路、入力/出力デバイスまたは通信インタフェース等であってよい。例えば、具体的に、通信モジュール1303はBluetooth(登録商標)装置、Wi−Fi(登録商標)装置または周辺機器インタフェース等であってよい。
処理モジュール1101がプロセッサであり、通信モジュール1104が無線周波数回路であり、ストレージモジュール1103がメモリであり、ディスプレイモジュール1102がディスプレイである場合、本願のこの実施形態で提供される端末は、図1に示された携帯電話100であってよい。
上述の実施形態の全部または一部が、ソフトウェア、ハードウェア、ファームウェアまたはこれらの任意の組み合わせを用いて実装されてよい。実施形態を実装すべくソフトウェアプログラムが用いられる場合、実施形態は、コンピュータプログラムプロダクトの形態で全体的または部分的に実装されてよい。コンピュータプログラムプロダクトは、1または複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされ、コンピュータ上で実行されるとき、本願の実施形態によるプロシージャまたは機能が全部または部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワークまたは他のプログラマブル装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に格納されてよく、または、コンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に送信されてよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータサーバまたはデータセンタから、別のウェブサイト、コンピュータ、サーバまたはデータセンタへと、有線(例えば、同軸ケーブル、光ファイバまたはデジタル加入者線(DSL))または無線(例えば、赤外線、無線およびマイクロ波等)の態様で送信されてよい。コンピュータ可読記憶媒体は、コンピュータでアクセス可能な任意の使用可能な媒体、または、サーバ若しくはデータセンタ等の1または複数の使用可能な媒体を統合したデータ記憶デバイスであってよい。使用可能な媒体は、磁気媒体(例えば、フロッピーディスク、ハードディスクまたは磁気テープ)、光媒体(例えば、DVD)または半導体媒体(例えば、ソリッドステートドライブ、Solid State Disk (SSD))等であってよい。
上述の説明は、本願の特定の実装に過ぎず、本願の保護範囲を限定することを意図するものではない。本願で開示した技術的範囲内での変形例または置換例は、本願の保護範囲に属するものとする。従って、本願の保護範囲は、特許請求の範囲に係る保護範囲によって決まるものとする。
(項目1)
端末に適用されるシステムサービスタイムアウト処理方法であって、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが上記端末で実行されており、上記システムサービスプロセスは少なくとも1つのシステムサービススレッドを含み、
上記少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするとき、上記端末によって、上記ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定する段階であって、上記ターゲットシステムサービススレッドの上記タイムアウトは、上記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、上記ターゲットシステムサービススレッドがブロックされていることのうち少なくとも1つを含む、段階と、
上記端末によって、上記第1のアプリケーションプロセスを終了させる段階と、を備える、方法。
(項目2)
上記端末によって、上記ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定する上記段階は、
上記端末によって、格納された登録情報に対し、上記ターゲットシステムサービススレッドと通信する上記第1のアプリケーションプロセスをクエリする段階であって、プロセス間通信IPCを実行するシステムサービススレッドと、アプリケーションプロセスとの間の対応関係が上記登録情報に記録される、段階を含む、項目1に記載の方法。
(項目3)
上記端末によって、上記第1のアプリケーションプロセスを終了させる上記段階の後、上記方法は、
上記端末によって、上記第1のアプリケーションプロセスを再起動する段階を備える、項目1または2に記載の方法。
(項目4)
上記端末によって、現在実行中のbinderbinderスレッドの総数Nをモニタリングする段階であって、Nは0以上の整数である、段階と、
binderスレッドの上記総数が第1の予め設定された値より大きい場合、上記端末によって、N個の上記binderスレッドの各々によりサービスされるアプリケーションプロセスを判定する段階と、
上記端末によって、すべてのアプリケーションプロセスの各々により占有されるbinderスレッドの数をカウントする段階と、
第1のターゲットアプリケーションプロセスにより占有されるbinderスレッドの数が第2の予め設定された値より大きい場合、上記端末によって、上記第1のターゲットアプリケーションプロセスを終了させる段階と、をさらに備える、項目1から3のいずれか一項に記載の方法。
(項目5)
第2のターゲットアプリケーションプロセスにより占有されるbinderスレッドの数が上記第2の予め設定された値より大きく、上記第2のターゲットアプリケーションプロセスの優先度が上記第1のターゲットアプリケーションプロセスの優先度より高い場合、上記方法は、さらに、
上記端末によって、上記第2のターゲットアプリケーションプロセスを終了させる段階と、
上記端末によって、上記第2のターゲットアプリケーションプロセスを再起動させる段階と、を備える、項目4に記載の方法。
(項目6)
上記端末が上記第2のターゲットアプリケーションプロセスを終了させるとき、上記方法は、さらに、
上記端末によって、上記第2のターゲットアプリケーションプロセスの実行の進行状況を記録する段階を備え、
上記端末によって、上記第2のターゲットアプリケーションプロセスを再起動させる上記段階は、
上記端末によって、上記実行の進行状況に基づき、上記第2のターゲットアプリケーションプロセスを、上記実行の進行状況と同一の実行ステータスに回復させる段階を含む、項目5に記載の方法。
(項目7)
上記端末によって、ターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mをカウントする段階であって、Mは0以上の整数である、段階と、
上記端末によって、上記binderスレッドの数Mが第1の閾値以上であるとき、上記ターゲットアプリケーションのための新しいbinderスレッドの作成を停止する段階と、をさらに備える、項目1から6のいずれか一項に記載の方法。
(項目8)
上記端末によって、上記binderスレッドの数が第1の閾値より大きいとき、上記ターゲットアプリケーションのための新しいbinderスレッドの作成を停止する上記段階は、
上記端末によって、M個の上記binderスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェースAPIに関する統計を収集する段階と、
1つのAPIが呼び出される回数が第2の閾値より大きい場合、上記端末によって、上記ターゲットアプリケーションのための新しいbinderスレッドの作成要求への応答を停止する段階と、を含む、項目7に記載の方法。
(項目9)
上記端末によって、上記ターゲットアプリケーションのための新しいbinderスレッドの作成を停止する上記段階の後、上記方法は、さらに、
上記ターゲットアプリケーションに上記IPCサービスを提供する上記binderスレッドの数Mが上記第1の閾値未満の場合、上記端末によって、上記ターゲットアプリケーションのための新しいbinderスレッドを作成する段階を備える、項目7または8に記載の方法。
(項目10)
上記端末によって、上記ターゲットシステムサービススレッドがタイムアウトした原因を表示する段階、または、上記第1のアプリケーションプロセスを終了させるプロンプトメッセージを表示させる段階をさらに備える、項目1から9のいずれか一項に記載の方法。
(項目11)
上記ターゲットシステムサービススレッドがブロックされていることは、
上記ターゲットシステムサービススレッドと、上記第1のアプリケーションプロセスとの間の通信持続期間が第1の予め設定された値より大きいこと、および、実行プロシージャにおける上記ターゲットシステムサービススレッドの保留持続期間が第2の予め設定された値より大きいこと、のうちの少なくとも1つを含む、項目1から10のいずれか一項に記載の方法。
(項目12)
端末であって、システムサービスプロセスおよび少なくとも1つのアプリケーションプロセスが上記端末で実行されており、上記システムサービスプロセスは少なくとも1つのシステムサービススレッドを含む、上記端末が、
上記少なくとも1つのシステムサービススレッド内のターゲットシステムサービススレッドがタイムアウトするか否かを検出するよう構成されたタイムアウト検出ユニットであって、上記ターゲットシステムサービススレッドの上記タイムアウトは、上記ターゲットシステムサービススレッドによって占有されているロックオブジェクトが予め設定された時間内に解放されないこと、および、上記ターゲットシステムサービススレッドがブロックされていることのうちの少なくとも1つを含む、タイムアウト検出ユニットと、
上記ターゲットシステムサービススレッドがタイムアウトするとき、上記ターゲットシステムサービススレッドと通信する第1のアプリケーションプロセスを判定するよう構成された判定ユニットと、
上記第1のアプリケーションプロセスを終了させるよう構成されたタイムアウト処理ユニットと、を備える、端末。
(項目13)
上記判定ユニットは、具体的に、格納された登録情報に対し、上記ターゲットシステムサービススレッドと通信する上記第1のアプリケーションプロセスをクエリするよう構成されており、プロセス間通信IPCを実行するシステムサービススレッドと、アプリケーションプロセスとの間の対応関係が上記登録情報に記録される、項目12に記載の端末。
(項目14)
上記タイムアウト処理ユニットは、さらに、上記第1のアプリケーションプロセスを再起動させるよう構成されている、項目12または13に記載の端末。
(項目15)
上記タイムアウト検出ユニットは、さらに、現在実行中のbinderbinderスレッドの総数Nをモニタリングするよう構成されており、Nは0以上の整数であり、
上記判定ユニットは、さらに、binderスレッドの上記総数が第1の予め設定された値より大きい場合、N個の上記binderスレッドの各々によりサービスされるアプリケーションプロセスを判定し、且つ、すべてのアプリケーションプロセスの各々により占有されるbinderスレッドの数をカウントするよう構成されており、
上記タイムアウト処理ユニットは、さらに、第1のターゲットアプリケーションプロセスにより占有されるbinderスレッドの数が第2の予め設定された値より大きい場合、上記第1のターゲットアプリケーションプロセスを終了させるよう構成されている、項目12から14のいずれか一項に記載の端末。
(項目16)
第2のターゲットアプリケーションプロセスにより占有されるbinderスレッドの数が上記第2の予め設定された値より大きく、上記第2のターゲットアプリケーションプロセスの優先度が上記第1のターゲットアプリケーションプロセスの優先度より高い場合、
上記タイムアウト処理ユニットは、さらに、上記第2のターゲットアプリケーションプロセスを終了させ、および、上記第2のターゲットアプリケーションプロセスを再起動させるよう構成されている、項目15に記載の端末。
(項目17)
上記タイムアウト処理ユニットは、具体的に、上記第2のターゲットアプリケーションプロセスの実行の進行状況を記録する、および、上記実行の進行状況に基づき、上記第2のターゲットアプリケーションプロセスを、上記実行の進行状況と同一の実行ステータスへ回復させる、よう構成されている、項目16に記載の端末。
(項目18)
上記判定ユニットは、さらに、ターゲットアプリケーションにIPCサービスを提供するbinderスレッドの数Mをカウントするよう構成されており、Mは0以上の整数であり、
上記タイムアウト処理ユニットは、さらに、上記binderスレッドの数Mが第1の閾値以上であるとき、上記ターゲットアプリケーションのための新しいbinderスレッドの作成を停止するよう構成されている、項目12から17のいずれか一項に記載の端末。
(項目19)
上記タイムアウト処理ユニットは、具体的に、M個の上記binderスレッドの各々によって呼び出されるアプリケーションプログラミングインタフェースAPIに関する統計を収集する、および、1つのAPIが呼び出される回数が第2の閾値より大きい場合、上記ターゲットアプリケーションのための新しいbinderスレッドの作成要求への応答を停止する、よう構成されている、項目18に記載の端末。
(項目20)
上記タイムアウト処理ユニットは、さらに、
上記ターゲットアプリケーションに上記IPCサービスを提供する上記binderスレッドの数Mが上記第1の閾値未満の場合、上記ターゲットアプリケーションのための新しいbinderスレッドを作成するよう構成されている、項目19に記載の端末。
(項目21)
上記ターゲットシステムサービススレッドがタイムアウトした原因を表示する、または、上記第1のアプリケーションプロセスを終了させるプロンプトメッセージを表示する、よう構成されたディスプレイユニットをさらに備える、項目12から20のいずれか一項に記載の端末。
(項目22)
上記ターゲットシステムサービススレッドがブロックされていることは、
上記ターゲットシステムサービススレッドと、上記第1のアプリケーションプロセスとの間の通信持続期間が第1の予め設定された値より大きいこと、および、実行プロシージャにおける上記ターゲットシステムサービススレッドの保留持続期間が第2の予め設定された値より大きいこと、のうちの少なくとも1つを含む、項目12から20のいずれか一項に記載の端末。
(項目23)
プロセッサ、メモリ、バスおよび通信インタフェースを備える、端末であって、
上記メモリは、コンピュータ実行可能命令を格納するよう構成されており、上記プロセッサは、上記メモリに上記バスを用いて接続されており、上記端末が稼働される場合に、上記プロセッサは、上記メモリ内に格納された上記コンピュータ実行可能命令を実行し、上記端末は、項目1から11のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行できるようにされる、端末。
(項目24)
コンピュータ可読記憶媒体であって、上記コンピュータ可読記憶媒体は命令を格納し、上記命令が端末上で実行される場合、上記端末は、項目1から11のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行できるようにされる、コンピュータ可読記憶媒体。
(項目25)
命令を備えるコンピュータプログラムプロダクトであって、上記コンピュータプログラムプロダクトが端末上で実行される場合、上記端末は、項目1から11のいずれか一項に記載のシステムサービスタイムアウト処理方法を実行できるようにされる、コンピュータプログラムプロダクト。