JP6873772B2 - 情報処理装置、情報処理装置の制御方法及びアプリケーション管理方法 - Google Patents

Description

本発明は、情報処理装置に、組み込みアプリケーションが複数インストールされ、それらが実行される実行環境における複数のアプリケーションの状態を管理する情報処理装置、情報処理装置の制御方法、及びアプリケーション管理方法に関する。

情報機器には、アプリケーションがすでに中に複数組み込まれているものがある。これらの情報機器の組み込みアプリケーションの実行環境においては、一般的に、これら複数のアプリケーションが使用できるリソースの総量に制限がある。これは、情報機器自体のリソースの量に依存しており、組み込みアプリケーションの実行環境において、アプリケーションが立ち上がると、それにともなって、情報機器内のメモリーなどのリソースが消費されていくからである。

例えば、Java（登録商標）で作られたＵＩアプリケーションでは、ＵＩの表示時にオブジェクトの参照が行われ、メモリーが使用される。オブジェクトの参照によって使用されたメモリー領域は、ＵＩアプリケーションによるオブジェクトの参照が切れた後は、ガベージコレクションなどの仕組みにより回収される。しかし、オブジェクトの参照が切れられないと、アプリケーションによって確保されたメモリー領域は解放されず、抱え込まれたままとなる。

近年アプリケーションを組み込んだ情報機器の機能拡張は、アプリケーションの機能拡張を伴うことが多く、各アプリケーションの拡大の一途をたどっている。このままアプリケーションの拡大化が続くと、アプリケーションによって確保されたまま開放されないメモリー領域も増大化していく可能性がある。

使用可能なリソースが限られる組み込みアプリケーションの実行環境においても、アプリケーションが複数起動する場合が想定される。このような環境で、アプリケーションが複数起動する場合は、アプリケーションの起動を管理するために、アプリケーションの管理手段により不要なアプリケーションを終了させ、メモリー領域などのリソースを開放する手段が必要となってくる。

例えば、スマートフォン等においてもアプリケーションを複数起動する場合が想定されているが、この場合には、ユーザがアプリケーションを終了させるための手段が提供されるのが一般的である。これは、使用するユーザが特定の個人として限定可能であるがゆえに可能なことである。
一方、画像形成装置のような複数のユーザがアクセスするような情報処理装置では、各ユーザに自由にアプリケーションを終了させるような手段を与えると、他のユーザの使用状況に関係なくユーザがアプリケーションを終了できてしまうという課題が生じる。

また、スマートフォンにおいては、アプリケーションの動作を監視して、正常な挙動でなくなった場合には、アプリケーションを再起動することにより、安定的な稼働を実現する技術があった（特許文献１）。
しかしながら、複数のユーザが使用する組み込みＵＩアプリケーションにおいては、ＵＩアプリケーションを終了させる、又は再起動させるための手段がなかった。そのため、参照しているオブジェクトへの参照を切断することもできず、リソースを抱え込み続けるといった課題があった。

特許5729767号広報

本発明は、情報処理装置のユーザビリティを損なうことなく、装置内のリソースの消費を少なくするための手段を提供することを目的とする。

本発明は、複数の動作するアプリケーションを管理する情報処理装置であって、ＵＩアプリケーションの起動を検知する検知手段と、前記ＵＩアプリケーションが、クリア実行通知を、受信可能か否かを判定する第１の判定手段と、前記ＵＩアプリケーションの画面が遷移した場合に、前記ＵＩアプリケーションがクリア実行を拒否する宣言を行っているいか否かを判定する第２の判定手段と、前記第2の判断手段によって、前記ＵＩアプリケーションがクリア実行を拒否する宣言を行っていないと判定した場合に、前記ＵＩアプリケーションの再起動処理を行うアプリケーション処理手段とを、有することを特徴とする。

本発明により、アプリケーションを削除することなく、情報処理装置の内部リソースの消費を少なくするようアプリケーションを管理することが可能となる。
また、情報処理装置のユーザビリティを損なうことなく、アプリケーションが抱え続けるリソースを解放対象とし、リソースを回収することが可能となる。

本発明の全体構成を示す図である。 本発明の画像形成装置のハードウェア構成を示す図である。 本発明の実施例のアプリケーションの実行環境の構成を示す図 本発明の実施例のアプリケーションのファイル構成を示した図 本発明の実施例１の処理フローを示した図 本発明におけるアプリケーションの状態遷移を示す図 本発明の実施例２の処理フローを示した図 本発明の実施例２の説明を補足するための図 本発明の実施例３の処理フローを示した図 本発明の実施例４の処理フローを示した図

以下、本発明を実施するための形態について図面を用いて説明する。
図１は、本発明の実施例の全体構成を示した図である。
画像形成装置100は、本発明の情報処理装置の一例としての画像形成装置である。画像形成装置100は、ネットワーク130を通して、情報処理装置110と通信可能に接続する。

アプリケーションＡ(101)、アプリケーションＢ(102)、アプリケーションＣ(103)はそれぞれ画像形成装置100上で動作するアプリケーションを示す。画像形成装置100上では、一つ又は複数のアプリケーションを動作させることが可能である。図１では、アプリケーションが３つの場合について示している。ユーザ及び管理者には、画像形成装置100の基本機能、アプリケーションA〜C(101〜103)、画像形成装置100及びその上で動作するアプリケーションを管理するための手段が提供される。また、ユーザは、画像形成装置100を、直接操作する、又はネットワーク130を経由して、情報処理装置110から間接的に操作することが可能である。

図２は画像形成装置100のハードウェア構成を示したブロック図である。
画像形成装置100は、コア部200、ＵＩパネル表示部201、記憶装置202、ネットワークインターフェース部203、スキャナー部204、プリンター部205、フィニッシャー部206から構成される。

コア部200内には不図示のＣＰＵやＲＡＭが搭載されている。該ＣＰＵは、記憶装置202に格納されている画像形成装置100に搭載のＯＳ、アプリケーション実行基盤、アプリケーション等のプログラムをＲＡＭ上に展開し、該プログラムをＲＡＭから読み込むことにより実行する。ＵＩパネル表示部201は、コア部200で処理された内容を表示し、またパネル表示部に設けられた入力手段からユーザからの入力を受け付ける。記憶装置202は、コア部200で処理されるプログラムやデータファイルを格納する。

画像形成装置100のネットワーク接続については、ネットワークインターフェース部203を介してネットワーク130に接続される。コア部200には、スキャナー機能を持つスキャナー部204、印刷機能を持つプリンター部205、フィニッシング機能を持つフィニッシャー部206が接続され、これらはコア部200によって動作が制御されている。

図３は、本実施例の画像形成装置における、各アプリケーションA〜C(101〜103)を実行するための実行環境のブロック図である。
アプリケーション実行基盤301は、アプリケーションを動作させる基盤である。
アプリケーションA〜C(101〜103)のインストール、アンインストール、実行、停止等の処理は、アプリケーション実行基盤301上で動作するアプリケーション管理フレームワーク302によって管理される。
アプリケーション管理フレームワーク302が、アプリケーションのインストール処理を行う場合は、まず、アプリケーションのアプリケーションリソース宣言ファイル403（図４(a)）を参照する。そして、アプリケーション管理フレームワーク302は、該ファイル中に宣言されているリソース上限値が、現在のアプリケーションの実行環境内のリソースの空き容量に収まるか否かを判定する。アプリケーション管理フレームワーク302は、その判定結果に基づき、空き容量に収まる場合は、アプリケーションのインストール処理を実行し、そうでない場合は、エラーを返す処理を行う。

ＵＩ制御モジュール303は、アプリケーションA〜C(101〜103)がＵＩ画面を構成する際の制御を行い、基本となる画面から各アプリケーションの画面遷移を管理する。
サポートライブラリ304は、アプリケーションA〜C(101〜103)が画像形成装置100の種々の機能を利用するためのライブラリーである。

図４(a)は、本実施例におけるアプリケーションA〜C(101〜103)を構成するファイルについて示した図である。
アプリケーションA〜C(101〜103)は、基本的に、アプリケーション実行コードファイル401、アプリケーション固定データファイル402、アプリケーションリソース宣言ファイル403の３つのファイルを少なくとも包含している。
アプリケーション実行コードファイル401はアプリケーションの実行コード等を含むファイルである。
アプリケーション固定データファイル402はアプリケーションが保持する定数や文字列等の固定データを収めたファイルである。
アプリケーションリソース宣言ファイル403はアプリケーションの情報や、アプリケーションが使用するリソースを宣言するためのファイルである。

図４(b)は、アプリケーションリソース宣言ファイル403の内部構成を示した図である。
アプリケーションリソース宣言ファイル403は、アプリケーションＩＤ、アプリケーションの名称、アプリケーションが使用するリソース等のアプリケーションの情報を含んでいる。図４(b)は、一例として装置内の画像のプレビューを表示するアプリケーションを示している。
ApplicationID(411)には、アプリケーション固有ＩＤ"apli-imag-view"、ApplicationName(412)には、"Preview App"のアプリケーション名が記載されていることが読み取れる。

また、ApplicationResource(413)には、アプリケーションが使用する各リソースの上限の値が格納されている。
本図の例では、アプリケーションの使用するストレージ、メモリー、スレッド、ファイルディスクリプター、ソケットの上限値を、バイト単位もしくは数値で記載している。

図５は、本発明のアプリケーション管理フレームワーク302の動作を示すフローチャートである。該アプリケーション管理フレームワーク302は、コア部200内のＣＰＵが、プログラムを実行することで実現される。
まず、ステップS501で、ＵＩ制御モジュール303が、ＵＩパネル表示部201にてＵＩアプリケーションのアイコンが押下されたことを検知し、アプリケーション管理フレームワーク302がＵＩ画面を有するアプリケーションであるＵＩアプリケーション（図中「ＵＩアプリ」と略す。）の起動を実行する。

そして、ステップS502にて、ＣＰＵは、該ＵＩアプリケーションが、アプリケーション管理フレームワーク302からのクリア実行通知を受信可能なアプリケーションか否かを判断する。ここで、クリア実行通知を受信可能なＵＩアプリケーションは、クリア実行通知を受信すると、アプリケーション管理フレームワーク302によりＵＩを初期設定に戻す等の処理が行われる。例えば、システム本体がしばらく使用されずスリープに入るような場合には、コピー実行時のカラーモノクロ印刷設定や両面印刷設定といった設定内容をデフォルト状態に戻す処理が行われる。これらの処理は、クリア実行通知がトリガーとなって実行される。

前述のクリア実行通知を受信可能なアプリケーションか否かの判断は、具体的には、該ＵＩアプリケーションが、アプリケーション管理フレームワーク302からのクリア実行通知のイベントのリスナーとしてアプリケーション管理フレームワーク302が管理する領域に登録されているいか否かで、判断することができる。
クリア実行通知のイベントのリスナーに登録されている場合は、ＣＰＵは、ＵＩ画面を記憶することなく、デフォルトの画面に戻すことができるアプリケーションであると判断する。それは、アプリケーション管理フレームワーク302が該ＵＩアプリケーションの初期化を行っても影響が無いアプリケーションであると、ＣＰＵは判断していることになる。
ＣＰＵは、該ＵＩアプリケーションが、アプリケーション管理フレームワーク302からのクリア実行通知を受信可能なアプリケーションであると判断した場合は、ステップS503へ処理を進める。クリア実行通知を受信可能でないＵＩアプリケーションと判断した場合は、該ＵＩアプリケーションに対して処理を行わずに、本フローチャートを終了する。

ステップS503で、ＵＩ制御モジュール303が、ＵＩアプリケーションの使用終了したことによるＵＩパネル表示部のＵＩ画面遷移（例えば、ＵＩアプリケーションの画面から初期画面に遷移する。）を検知した場合(Yes)、ステップS504へ進む。
ステップS504で、ＣＰＵは、該ＵＩアプリケーションがＵＩを初期設定に戻す等のクリア実行可能な状態か否かを判断する。
一般に、例えば複数アプリケーションが動作するシステムにおいては、ジョブの処理中といった途中で処理を停止できない場合に、アプリケーションには状態クリアや動作停止を禁止する手段が提供されている。ここでは、途中で処理を停止できない場合に、ＵＩアプリケーションは、クリア実行を拒否する宣言をする。

よって、ステップS504 では、ＵＩアプリケーションから前述のようなクリア実行を拒否する宣言があるか否かを判断することとなる。該ＵＩアプリケーションからクリア実行を拒否する宣言がない場合は、ステップS505へ進む。一方、クリア実行を拒否する宣言がされていれば、該宣言の解消されるのを待機し、クリア実行を拒否する宣言が解消されたらステップS505へ進む。
ステップS505では、アプリケーション管理フレームワーク302は、該ＵＩアプリケーションの使用が終了したと判断し、該ＵＩアプリケーションの再起動処理を実行する。そして、本フローチャートを終了する。

［再起動処理］
次に、図５のステップS505のアプリケーションの再起動処理について、図６を用いて説明する。
図６は本システムにおけるアプリケーションの内部状態とそのライフサイクルの一例を概念的に示した図である。本システムは、アプリケーションソフトウェアやコンポーネントを遠隔からインストール・起動・停止・アンインストールなどの管理ができるJavaベースのサービスプラットフォームであるOSGiに準ずるものとしている。

本システムにおいて、ＵＩアプリケーションのインストール処理が開始されると、ＣＰＵが実行するアプリケーション管理フレームワーク302は該ＵＩアプリケーションのアプリケーションリソース宣言ファイル403を参照する。そして、該アプリケーションリソース宣言ファイル403から該アプリケーションの名称、ＩＤ及び使用リソースの情報を取得する。

該ＵＩアプリケーションをインストールすることが可能な場合には、該ＵＩアプリケーションの情報を内部に登録し、インストール済(601)の状態とする。そして、ＣＰＵが実行するアプリケーション管理フレームワーク302はユーザからの指示に基づいて、又は自動的にアプリケーションの起動処理を実行する。

アプリケーションの起動処理では、ＣＰＵにより、アプリケーション自体の起動に必要なクラスのロードが行われ、依存関係が解消された停止中(602)の状態となる。
その後、アプリケーション管理フレームワーク302は開始処理を開始し、該ＵＩアプリケーションを、開始処理中(603)の状態に遷移する。開始処理中(603)の状態では、ＵＩアプリケーションはＵＩ制御モジュール303に対して、アプリケーションのＵＩ表示登録処理を行う。ＵＩ表示登録処理が行われると、ＵＩ制御モジュール303はＵＩパネル表示部201に該ＵＩアプリケーションのアイコンを表示する。
これらの処理が終わるとアプリケーション管理フレームワーク302は、該ＵＩアプリケーションを開始済(604)の状態とする。

先の図５で示したフローチャートは、ＵＩパネル表示部201にて開始済(604)の状態にあるＵＩアプリケーションのアイコンが押下され、該ＵＩアプリケーションが起動して、該アプリケーションのＵＩが表示されるところから始まっている。その後、ＵＩアプリケーションが使用終了することに伴い画面が遷移して、再起動処理に移行する。
そして、図５のステップS505のＵＩアプリケーションの再起動処理において、アプリケーション管理フレームワーク302は、まず、該ＵＩアプリケーションの停止処理を開始する。停止処理を開始すると、アプリケーション管理フレームワーク302は、該ＵＩアプリケーションを、停止処理中(605)の状態に遷移する。

停止処理中(605)の状態では、該ＵＩアプリケーションが、ＵＩ制御モジュール303に対してＵＩ表示削除処理を行う。ＵＩ表示削除処理が行われると、ＵＩ制御モジュール303は、該ＵＩアプリケーションのアイコンを削除し、ＵＩパネル表示部への登録を解除する。
ＵＩ表示削除処理が完了すると、アプリケーション管理フレームワーク302は、該ＵＩアプリケーションを停止中(602)の状態に遷移させる。

そして、アプリケーション管理フレームワーク302は、ＵＩアプリケーションを再び開始処理中(603)の状態に遷移させ、再度ＵＩパネル表示部へのＵＩ表示登録処理を実行し、開始済(604)の状態に遷移させる。
この再起動処理により、ＵＩアプリケーションのＵＩが一度、表示されていない状態に戻ることになり、それまで使用していたＵＩオブジェクトなどのリソース参照を切り、メモリーを開放することが可能となる。

前述の再起動処理では、停止処理中(605)及び開始処理中(603)の状態で、ＵＩパネル表示部201に対する削除処理及び登録処理を行っている。これとは異なり、再起動であることをＵＩ制御モジュール303に通知することで、ＵＩパネルに対する削除処理及び登録処理を省略することでも同様の処理が行えるようにしても良い。

実施例１では、再起動処理を行うことにより、ＵＩアプリケーションで使用していたリソースの開放を行った。しかし、この再起動処理で回収されるリソースが少ないような場合や、画像形成装置内のリソースの状況によっては、回収されるリソースが十分ではなく、更なるリソースの回収を必要とする場合もある。
実施例２では、更に多くのリソースを回収可能とするための動作について以下に示す。

本実施例のアプリケーション管理フレームワーク302の動作について図７のフローチャートを用いて説明する。図７のフローチャートにおいて、図５と共通のステップについては、同じ番号を付し、説明も簡略化する。
本フローチャートに示す処理は、ＣＰＵが本発明に係るプログラムであるアプリケーション管理フレームワーク302を実行することで実現されるものである。

本フローチャートは、実施例１と同様に、最初にＵＩ制御モジュール303が、ＵＩアプリケーションの起動を検知する(S501)。その後、ステップS502〜S503の処理を実行し、ステップS504に進む。
ステップS504で、アプリケーション管理フレームワーク302が、ＵＩアプリケーションがクリア実行可能と判断した場合に、ステップS707へ進む。
一方、クリア実行可能でなければ、可能になるまで待機し、可能になったらステップS707へ進む。
ステップS707では、ＵＩアプリケーションの起動時間を取得する。このＵＩアプリケーションの起動時間は、ＵＩアプリケーションが内包するjarファイルの数及びサイズと、ロードするクラスの数といったアプリケーションの情報から算出される。
なお、アプリケーション管理フレームワーク302のログから該ＵＩアプリケーションの起動時間を取得しても良い。

そして、ステップS708で、ＣＰＵは、該ＵＩアプリケーションの起動時間が所定時間以内になるかを判定する。所定時間とは、アプリケーションの起動までにユーザが待機可能な時間を仮定した時間であり、この時間内にアプリケーションが起動できれば、ユーザへの影響は少ないと判定する時間である。この所定時間は、予めシステムにて決められている時間でも良いし、ユーザが入力して設定可能としても良い。
ステップS708において、ＣＰＵが、アプリケーションの起動が所定時間内に収まると判定した場合(Yes)は、ステップS709に進む。収まらないと判断した場合はステップS505に進んで、アプリケーション管理フレームワーク302は、ＵＩアプリケーションを再起動する。

次に、ステップS709で、アプリケーション管理フレームワーク302は機器内のリソース使用量を、アプリケーション実行基盤301より取得し、使用量が規定値を超えているかを判定する。
ステップS709において、画像形成装置内のリソース使用量の状況が規定値を超えていると判断した場合には、ステップS710に進み、アプリケーション管理フレームワーク302は、ＵＩアプリケーションの終了処理を行う。リソース使用量の状況が規定値を超えていないと判断した場合は、ステップS505に進みＵＩアプリケーションの再起動処理を行う。

［ＵＩアプリケーションの終了処理］
次に、アプリケーション終了処理について、図６と図８を用いて説明する。
実施例２の終了処理（S710）では、開始済み(604)の状態からアプリケーションの終了を判定して、停止処理中(605)、停止中(602)の状態を経て、アンインストール済(606)の状態に遷移する。

開始済み(604)の状態からアプリケーションの終了を判定した際に行われる停止処理について、図８とあわせて説明する。図８(a)はアプリケーション管理フレームワーク302とＵＩ制御モジュール303とＵＩアプリケーションＡ間の通知の概略を示した図である。

まず、アプリケーション管理フレームワーク302はアプリケーションの終了処理を開始する際に、ＵＩ制御モジュール303に終了処理の対象となるＵＩアプリケーションＡ101の情報及びアプリケーションが終了となることを通知する(n801)。
続いて、アプリケーション管理フレームワーク302は、終了処理の対象となるＵＩアプリケーションＡ101に対して、停止処理を指示する(n802)。
終了処理の対象となるＵＩアプリケーションＡ101は、停止処理の指示(n802)を受けると、ＵＩ制御モジュール303に対して、ＵＩ表示削除処理を依頼する(n803)。

ＵＩアプリケーションＡ101からのＵＩ表示削除処理の依頼を受けると、ＵＩ制御モジュール303は、アプリケーション管理フレームワーク302から渡された情報をもとに、図８(b)に示すＵＩ登録テーブル811を更新する。ＵＩ登録テーブル(UI Registration Table)811が更新されることによりＵＩ表示は削除される。
続いて、ＵＩ制御モジュール303は、インストールされたパッケージを他の領域に退避させる(n804)。

図８(b)に示すＵＩ登録テーブル811は、ＵＩ制御モジュール303が管理するテーブルであり、アプリケーションのアイコンＩＤとアプリケーションＩＤと、各アプリケーションの状態を関連付けるテーブルである。
前述のＵＩ表示登録処理やＵＩ表示削除処理の際にテーブルは更新され、ここではapli-imag-view、及びsend-deve-imagのアプリケーションを登録していることを示す(812)。

そして、退避処理(n804)ではＵＩアプリケーションＡ101(test-uiap-apli)の情報は表示登録テーブルからは削除することなく、状態変更して状態をHoldにし(813)、ＵＩアプリケーションＡ101に削除完了を返す(n805)。
ＵＩアプリケーションは、アプリケーション管理フレームワーク302に対して停止処理が完了した旨通知を行う(n806)。
そして、アプリケーション管理フレームワーク302は該ＵＩアプリケーションＡを停止中(602)の状態に遷移させ、該ＵＩアプリケーションＡのアンインストール処理を行い、アンインストール済(606)の状態に遷移させる。
この時、アプリケーション管理フレームワーク302の内部状態としてはアプリケーションをインストールしていない状態となるが、ＵＩ上にはアイコンが登録されている状態(Hold)となる。

次に、この状態から、ＵＩパネル表示部201にてＵＩアプリケーションＡ101のアイコンが押下された場合の動作を説明する。
ＵＩパネル表示部上のアイコンの押下をＵＩ制御モジュール303が検知すると、ＵＩ制御モジュール303は押下されたアイコンのＩＤを取得し、ＵＩ登録テーブル811を参照する。

ＵＩ登録テーブル811に該アイコンのＩＤが登録（regist）されていれば、該当するアプリケーションの実行をアプリケーション管理フレームワーク302に通知し、該アプリケーションのＵＩをロードする。
ＵＩ登録テーブル811に該アイコンのＩＤがHoldとして登録されていた場合(813)は退避したアプリケーションのパッケージのパス（/Tmp/UI-App/-01.nlm）を、アプリケーション管理フレームワーク302に通知する。そして、アプリケーション管理フレームワーク302は、該当するアプリケーションのインストール処理を開始する。

そして、インストール済(601)、停止中(602)、開始処理中(603)の状態を経て、開始済(604)の状態に遷移させ、さらに該ＵＩアプリケーションＡ101のＵＩをロードする。
なお、開始処理中のアプリケーションからＵＩ制御モジュール303へのＵＩパネル登録処理は、既に登録済みであるため、ＵＩ登録テーブルは状態(813)の内容を更新するのみとなる。

このようにして、終了と判定したアプリケーションを再起動処理するのではなく、終了処理し、アンインストールすることで、アプリケーションが開始のために使用するリソースを消費しないままにできる。
また、本実施例では起動に掛る時間を許容できる時間内に制限し、画像形成装置内のリソースが少なくなっていると判断した際に終了処理を行うことで、ユーザビリティを大きく損なうことを回避している。

実施例３では、アプリケーション管理フレームワーク302の更に別の動作について、図9を用いて説明する。
実施例１，２の例では、アプリケーションの終了を検知し、アプリケーションからクリア拒否の宣言が無い場合に、再起動処理又は終了処理を実行することにより、アプリケーションが消費していたリソースを開放する例を示した。
しかしながら、例えば、終了処理を実行した場合には、アプリケーションの起動に少なからず時間がかかってしまう。ユーザが頻繁に起動を行うような使い方をされるアプリケーションの場合、アプリケーションの起動時間が積み重なり、ユーザビリティが低下することにも繋がりかねない。

以下の実施例３の処理では、起動が頻繁に行われるアプリケーションについては、終了処理及び再起動処理を直ちに実行するのではなく、アプリケーションの使用間隔に基づいて、所定時間は、該アプリケーションを開始済の状態にしておくものである。再度ユーザがアプリケーションを使用する場合には、直ちに利用できることから、ユーザビリティ低下を回避することができる。そして、アプリケーションの使用間隔が所定時間を超えている場合には、終了処理又は再起動処理を行うことにより、アプリケーションが抱えているリソースの開放を行うことができる。
本フローチャートに示す処理は、ＣＰＵが本発明に係るプログラムであるアプリケーション管理フレームワーク302を実行することで実現されるものである。

まず、ＣＰＵが実行するＵＩ制御モジュール303が、アプリケーションの使用の終了を検知する(S901)。
アプリケーションの使用終了時刻からタイマーをスタートさせ経過時間Kを計時を開始する(S902)。
続いて、アプリケーション管理フレームワーク302は、ログから該アプリケーションの前回の終了時刻を取得する(S903)。
そして、今回の該アプリケーションの起動時刻を取得して、前回アプリケーションの終了から今回の起動までの経過時間Aを算出し取得する(S904)。経過時間Aは、該アプリケーションの使用間隔を示すものとなる。

そして、アプリケーションの終了検知からの経過時間Kと、経過時間Aを比較し、経過時間Kが、経過時間Aを超えたと判定(S905)した場合に、前述のようなアプリケーションの再起動処理を実行する(S906)。この時、再起動処理だけでなく、実施例２に示すようにアプリケーションの起動時間と機器内リソースの状況から判断し、該アプリケーションの終了処理を実行しても良い。
なお、本実施例では、タイマーを用いて、アプリケーション終了からの経過時間Kを求めているが、アプリケーションの使用終了時刻と、現在の時刻を参照することにより、経過時間Kを求める構成としてもよい。

実施例１及び実施例２の例では、アプリケーションの終了を検知し、即時に再起動処理又は終了処理を実行していた。しかしながら、再起動処理や終了処理を行った後の実行では、処理に少なからず時間がかかる。そのため、ユーザが連続で使用するようなケースであれば、ユーザを待たせることになりユーザビリティを損ねることにつながりかねない。
しかしながら、上記の実施例３の処理を実行することで、そのようなユーザビリティを損ねることを回避することが可能となる。

本発明のアプリケーション管理フレームワーク302の動作の別の実施例を、図１０を用いて説明する。
実施例３では、アプリケーションの再起動処理ないし終了処理を実行するまでに所定時間持たせるような処理とした。しかしながら、例えば、ユーザが意図せずＵＩアプリケーションを起動してしまったような、いわゆる操作ミスによるアプリケーションの起動がなされた場合もある。このような場合には、実施例３のように再起動もしくは終了処理を実行するまでに所定時間持たせるような処理とすると、こんどは不要なアプリケーションが意図せずリソースを占有するということになりかねない。実施例４では、ユーザの意図しない操作を検知することにより、操作ミスにより起動したアプリケーションを直ちに終了できるようにしたものについて説明する。
本フローチャートに示す処理は、ＣＰＵが本発明に係るプログラムであるアプリケーション管理フレームワーク302を実行することで実現されるものである。

本フローチャートはステップS501と同様に、まずステップS1001において、ＵＩ制御モジュール303がＵＩアプリケーションの起動を検知する。
続くステップS1002で、ＵＩ制御モジュール303は、該ＵＩアプリケーションに対してユーザ操作の有無を判定する。ユーザ操作があれば(Yes)、何も処理をせずに終了する。
一方、ユーザ操作がない場合は(No)、ステップS1003に進む。ステップS1003では、画面遷移を検知するまで待機し、画面遷移を検知した場合は、ステップS1004に進む。

ステップS1004において、ＵＩ制御モジュール303は、該ＵＩアプリケーションのＵＩ表示時間を取得し、該ＵＩ表示時間が規定時間（閾値）以上であったか否かを判定する。ＵＩアプリケーションの表示時間が規定時間以上であった場合は、処理を終了する。
一方、該ＵＩアプリケーションのＵＩ表示の表示時間が規定時間未満であった場合には、該ＵＩアプリケーションの起動は、ユーザのオペレーションミスであったと判定し、不要な起動であったと判断し、ステップS1005に進む。

ステップS1005において、アプリケーション管理フレームワーク302は、該ＵＩアプリケーションの再起動処理を実行し、本フローチャートの処理を終了する。なお、再起動処理の代わりに実施例2のようにＵＩアプリケーションの終了処理であってもよい。
以上、本実施例によれば、ユーザにとって不要なＵＩアプリケーションが起動され続けることによりリソースの消費される回避することが可能となる。

(その他の実施例)
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ＡＳＩＣ)によっても実現可能である。

100 画像形成装置
101 情報処理装置
130 ネットワーク
302 アプリケーション管理フレームワーク
303 ＵＩ制御モジュール

Claims (13)

1. 複数の動作するアプリケーションを管理する情報処理装置であって、
   前記アプリケーションが使用終了した場合に、前記アプリケーションがクリア実行を拒否する宣言をしているか判定する第１の判定手段と、を有し、
   前記第１の判定手段によって、前記アプリケーションがクリア実行を拒否する宣言をしていないと判定した場合に、前記アプリケーションの再起動処理を行うことを特徴とする情報処理装置。
2. 前記アプリケーションが、クリア実行通知の受信可能であるか判定する第２の判定手段を更に有し、
   前記第２の判定手段により、前記アプリケーションが、クリア実行通知の受信可能でないと判断された場合は、再起動処理を行わないことを特徴とする請求項１に記載の情報処理装置。
3. アプリケーションの使用終了は、表示部に表示されるＵＩが遷移することにより検知することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記アプリケーションがクリア実行を拒否する宣言を実行していないと判定した際に、該アプリケーションの起動にかかる時間を取得する第１の取得手段と、
   前記取得した該アプリケーションの起動時間が、所定時間を超えるか判定する第３の判定手段と、を更に有し、
   前記第３の判定手段により、該アプリケーションの起動時間が所定時間を超えないと判定された場合に、該アプリケーションの終了処理を行うことを特徴する請求項１〜３の何れか1項に記載の情報処理装置
5. 前記第１の取得手段は、アプリケーションが内包するファイルの数、サイズ、ロードするクラスの数を含むアプリケーションの情報から算出することを特徴とする請求項４に記載の情報処理装置。
6. 情報処理装置のリソースの使用量を取得し、規定値を超えているか判定する第４の判定手段を更に有し、
   前記第４の判定手段により、情報処理装置のリソース使用量が規定値を超えている場合に、該アプリケーションの終了処理を行うことを特徴する請求項４又は５に記載の情報処理装置。
7. 前記アプリケーションの使用終了を検知した際に、経過時間を計時する計時手段と、
   前記アプリケーションの使用間隔を取得する第２の取得手段と、
   該アプリケーションの前記使用間隔と前記経過時間とを比較する比較手段と、を更に有し、
   前記比較手段によって、前記経過時間が前記使用間隔より大きくなったと判断した場合、アプリケーションの再起動処理を実行することを特徴とする請求項１〜６のいずれか1項に記載の情報処理装置。
8. 前記使用間隔は、前回の前記アプリケーションの使用終了時刻と今回の起動時刻とから取得することを特徴とする請求項７に記載の情報処理装置。
9. 前記使用間隔は、前記アプリケーションの起動と終了にかかるログから取得することを特徴とする請求項７に記載の情報処理装置。
10. 前記アプリケーションのＵＩを表示する時間が閾値よりも小さいか判定する第５の判定手段と、
    前記第５の判定手段により、ＵＩを表示する時間が閾値より小さいと判定された場合は、前記アプリケーションの再起動処理を行うことを特徴とする請求項１〜９のいずれか１項に記載の情報処理装置。
11. 前記アプリケーションのＵＩを表示する時間が閾値よりも小さいか判定する第５の判定手段と、
    前記第５の判定手段により、ＵＩを表示する時間が閾値より小さいと判定された場合は、前記アプリケーションの終了処理を行うことを特徴とする請求項１〜９のいずれか１項に記載の情報処理装置。
12. 複数の動作するアプリケーションを管理する情報処理装置の制御方法であって、
    前記アプリケーションの画面が遷移した場合に、前記アプリケーションがクリア実行を拒否する宣言をしているか判定する第１の判定ステップと、
    前記第１の判定ステップにおいて、前記アプリケーションがクリア実行を拒否する宣言をしていないと判定した場合に、前記アプリケーションの再起動処理を行う処理ステップと、
    を、有することを特徴とする情報処理装置の制御方法。
13. 複数の動作するアプリケーションを管理する情報処理装置のアプリケーション管理方法であって、
    前記アプリケーションの画面が遷移した場合に、前記アプリケーションがクリア実行を拒否する宣言をしているか判定する第１の判定ステップと、
    前記第１の判定ステップにおいて、前記アプリケーションがクリア実行を拒否する宣言をしていないと判定した場合に、前記アプリケーションの再起動処理を行う処理ステップと、
    を、有することを特徴とするアプリケーション管理方法。

Images