(57)【特許請求の範囲】
【請求項１】
携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法であって：
指定されたアプリケーションの画面を閉じるための指令を受信するステップ；
指定された領域のスクリーンショットを取得するために、前記指定されたアプリケーションの画面の前記指定された領域を取り込むステップ；及び
前記指定された領域のスクリーンショットを保存し、かつ前記指定されたアプリケーションの画面を閉じるステップ；
とを備え、
前記指定された領域のスクリーンショットを取得するために、前記指定されたアプリケーションの画面の前記指定された領域を取り込むステップは：
ローカルディスプレイの大きさ及び事前に設定されたズーム比に従って、前記ローカルディスプレイの大きさを前記指定されたアプリケーションの本来の画面の大きさとして用いることにより前記指定されたアプリケーションの画面の前記指定された領域を拡大し、かつ前記指定された領域のスクリーンショットを取得するための拡大の後に、サムネイルを取り込むステップ；
を含むことを特徴とする、方法。
【請求項２】
前記指定された領域のスクリーンショットを保存し、かつ前記指定されたアプリケーションの前記画面を閉じるステップの後、
前記指定されたアプリケーションを閲覧するための指令を受信した場合に、前記指定された領域のスクリーンショットを取得し、かつ前記指定された領域のスクリーンショットを表示するステップ
を含むことを特徴とする、請求項１に記載の方法。
【請求項３】
前記指定されたアプリケーションの前記画面を閉じるための指令は、
バックグラウンドで実行するように前記指定されたアプリケーションを切り替えるための切替指令、又は前景で実行するように他のアプリケーションを切り替えるための切替指令、又は前記指定されたアプリケーションを終了するための終了指令
であることを特徴とする、請求項１又は２に記載の方法。
【請求項４】
携帯端末内のアプリケーションの画面のスクリーンショットをとるための装置であって：
指定されたアプリケーションの画面を閉じるための指令を受信する受信モジュール；
指定された領域のスクリーンショットを取得するために、前記指定されたアプリケーションの前記画面の前記指定された領域を取り込むスクリーンショットモジュール；及び
前記指定された領域のスクリーンショットを保存し、かつ前記指定されたアプリケーションの画面を閉じる保存モジュール；
を備え、
前記スクリーンショットモジュールは：
ローカルディスプレイの大きさ及び事前に設定されたズーム比に従って、前記ローカルディスプレイの大きさを前記指定されたアプリケーションの本来の画面の大きさとして用いることにより、前記指定されたアプリケーションの画面の前記指定された領域を拡大するズーム部；及び
前記指定された領域のスクリーンショットの取得のための拡大の後、サムネイルを取り込むスクリーンショット部；
を備えることを特徴とする、装置。
【請求項５】
前記装置は：
前記指定されたアプリケーションを閲覧するための指令を受信した場合に、前記指定された領域のスクリーンショットを取得し、かつ前記指定された領域のスクリーンショットを表示する表示モジュール
をさらに備えることを特徴とする、請求項４に記載の装置。
【請求項６】
前記指定されたアプリケーションの画面を閉じるための指令は、
バックグラウンドで実行するように前記指定されたアプリケーションを切り替えるための切替指令、又は前景で実行するように他のアプリケーションを切り替えるための切替指令、又は前記指定されたアプリケーションを終了するための終了指令である
ことを特徴とする、請求項４又は５に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯端末の分野に関連し、特に、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法及び装置に関連する。
【背景技術】
【０００２】
携帯端末の発展に伴い、多くのスマートフォンには、アンドロイドシステムが搭載されている。アンドロイド（Ａｎｄｒｏｉｄ）（商標）は、モバイルプログラムを開発するためのＧｏｏｇｌｅ（登録商標）のオープンソース・ソフトウェア・プラットフォームであり、オペレーティングシステム、ミドルウェア及びいくつかの重要なアプリケーションが含まれている。アクティビティ（Ａｃｔｉｖｉｔｙ）は、アンドロイドプラットフォームの標準のコンポーネントである。実際、アクティビティは、アプリケーションの中の単一のスクリーンであり、アクティビティクラスから導出され、イベントに対するビュー（Ｖｉｅｗ）及びレスポンスで形成されるユーザインタフェース（ＵＩ）を表示するものである。
【０００３】
従来技術を分析した後、発明者は、従来技術には少なくとも以下のような欠点があることを見出した。
【０００４】
従来技術において、アンドロイドプラットフォームのタスクマネージャやホームデスクトップアプリケーションプログラム（Ｈｏｍｅ  ｄｅｓｋｔｏｐ  ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍ）等のアプリケーションシナリオを管理する際には、バックグラウンドで実行中のアプリケーションの画面だけを取得することが可能であり、記録されている全てのアプリケーションの画面を取得することはできない。その結果、ユーザは、切り替え先のアプリケーションを容易には見出すことができず、従って、アプリケーションの切り替えの際には、ユーザインターフェース（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ、ＵＩ）は、あまり有効ではなく、表示が間接的になり、そして操作性が悪くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の複数の実施例は、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法及び装置を提供する。その技術的解決手段は以下の通りである：
【課題を解決するための手段】
【０００６】
携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法であって：
指定されたアプリケーションの画面を閉じるための指令を受信するステップ；
指定された領域のスクリーンショットを取得するために、前記指定されたアプリケーションの前記画面の前記指定された領域を取り込むステップ；及び
前記指定された領域の前記スクリーンショットを保存し、かつ前記指定されたアプリケーションの前記画面を閉じるステップ；
とを備えることを特徴とする、方法。
【０００７】
携帯端末内のアプリケーションの画面のスクリーンショットをとるための装置であって：
指定されたアプリケーションの画面を閉じるための指令を受信する受信モジュール；
指定された領域のスクリーンショットを取得するために、前記指定されたアプリケーションの前記画面の前記指定された領域を取り込むスクリーンショットモジュール；及び
前記指定された領域の前記スクリーンショットを保存し、かつ前記指定されたアプリケーションの前記画面を閉じる保存モジュール；
とを備えることを特徴とする、方法。
【０００８】
本発明の複数の実施例における技術的解決手段は、以下の有益な効果を有する。アプリケーションのアクティビティが閉じられる前であって、当該アクティビティのウィンドウがまだ視認可能である場合において、当該アクティビティの実際の最終的な画面を取得するために、そのアプリケーションの画面のスクリーンショットがとられる。このようにして、そのアプリケーションの画面が閉じられた後にスクリーンショットをとることに起因する高いメモリ使用率を回避し、その結果、画面キャプチャ効率が改善され、そしてメモリ使用率及び呼び出し回数が低減される。
【図面の簡単な説明】
【０００９】
本発明又の複数の実施例又は従来技術における技術的解決手段をより明瞭に示すために、当該複数の実施例又は従来技術を説明するために必要な添付図面を以下に簡単に紹介する。以下の説明における添付図面は、本発明のいくつかの実施例のみを示すことは明らかであり、そして当業者は、創造的努力なしで、これらの添付図面から、その他の図面をさらに導出することが可能である。
【図１】本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットを取るための方法のフローチャートである。
【図２】本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法のフローチャートである。
【図３】本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法のＪａｖａ（登録商標）環境における例のフローチャートである。
【図４】本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための装置の概略構成図である。
【発明を実施するための形態】
【００１０】
本発明の目的、技術的解決手段、長所を明瞭にするために、添付の図面を参照して、本発明の複数の実施例が以下においてさらに詳細に説明される。
【００１１】
本発明において提供される、アプリケーションの画面のスクリーンショットをとるための方法を紹介する前に、まず、本発明に関する基礎知識を手短に紹介する。
【００１２】
アクティビティ（Ａｃｔｉｖｉｔｙ）は、アンドロイドプラットフォームの標準のコンポーネントである。実際、アクティビティは、アクティビティクラスから導出されるアプリケーションにおける単一の画面であり、複数のビュー（Ｖｉｅｗ）により形成されるユーザインタフェース（ＵＩ）を表示し、複数のイベントに応答する。
【００１３】
履歴アクティビティ（Ｈｉｓｔｏｒｙ  Ａｃｔｉｖｉｔｙ）とは、ユーザにより一度開始された（複数の）アクティビティのことであり、バックグラウンドで動作中のタスクの中のアクティビティを含む。
【００１４】
「ＳｕｒｆａｃｅＶｉｅｗ」は、アンドロイドプラットフォームの特殊なビュークラスである。これは、３Ｄビュークラスである「ＧＬＳｕｒｆａｃｅＶｉｅｗ」及び「ＲＳＳｕｒｆａｃｅＶｉｅｗ」の親クラスである。これら２つの３Ｄビュークラス双方は、それらの独立した描画スレッド上で動作する。従って、「ＳｕｒｅｆａｃｅＶｉｅｗ」は、その他の共通のビュークラスとは異なる。
【００１５】
「ＬｉｖｅＷａｌｌｐａｐｅｒ」とは、アンドロイドプラットフォームのライブ壁紙のことであり、これは、通常、「ＲＳＳｕｒｆａｃｅＶｉｅｗ」ビュークラスにより実行される。
【００１６】
「ＡｃｔｉｖｉｔｙＭａｎａｇｅｒＳｅｒｖｉｃｅ」とは、アクティビティの管理サービスのことであり、アンドロイドプラットフォーム上での重要なシステムサービスである。
【００１７】
「ＷｉｎｄｏｗＭａｎａｇｅｒＳｅｒｖｉｃｅ」とは、ウィンドウ管理サービスのことであり、アンドロイドプラットフォームの重要なシステムサービスである。
【００１８】
「ＴａｓｋＭａｎａｇｅｒ」とは、タスクマネージャのことであり、これは、タスク表示、切り替え及び消去といった機能を含むアンドロイドアプリケーションプログラムである。
【００１９】
図１は、本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法のフローチャートである。この実施例は、携帯端末により実行される。図１を参照すると、本実施例は、具体的には、以下の内容を含む：
【００２０】
１０１．指定されたアプリケーションの画面を閉じるための指令を受信する。
【００２１】
この実施例では、携帯端末において、少なくとも１つのアプリケーションが動作しており、かつ当該アプリケーションは、現時点においてフルスクリーン状態であってもよい。指定されたアプリケーションの画面を閉じるための指令は、バックグラウンドで実行するように指定されたアプリケーションを切り替えるための切替指令である、又は前景で実行するように別のアプリケーションを切り替えるための切替指令である、又は指定されたアプリケーションを終了するための終了指令である。指令が、バックグラウンドで実行するように指定されたアプリケーションを切り替えるための切替指令である場合、当該指令は、携帯端末のユーザにより手動で開始されてもよく、そして当該指令は、例えば、指定されたアプリケーションを最小化する。また、指令は、現在の状態に従って開始されてもよい。例えば、指定されたアプリケーションが２０分間アイドル状態である場合に、バックグラウンドで実行するように指定されたアプリケーションを切り替えるための切替指令が開始される。
【００２２】
当業者は、アプリケーションのアクティビティのライフサイクルが以下の内容を含むことを知っているかもしれない：
アクティビティが開始された場合であり、かつコンストラクター関数「Ａｃｔｉｖｉｔｙ（）」が開始された後、システムは、グローバル状態（ｇｌｏｂａｌ  ｓｔａｔｅ）と「ｏｎＣｒｅａｔｅ（）メソッドにおけるアクティビティのリソースを設定するために、「ｏｎＣｒｅａｔｅ（）」メソッドを呼び出し、その後「ｏｎＳｔａｒｔ（）」メソッドを呼び出す。「ｏｎＳｔａｒｔ（）」メソッドが実行された後においては、まだ、アクティビティをスクリーン上で視認可能である。「ｏｎＲｅｓｕｍｅ（）」メソッドが実行され、この時、アクティビティは、ループにおける待機ウィンドウイベント（ｗａｉｔ  ｗｉｎｄｏｗ  ｅｖｅｎｔ）内となる。ウィンドウを部分的に視認可能な場合、つまり、アクティビティが前景にはない場合、アクティビティの「ｏｎＦｒｅｅｚｅ（）」メソッドが呼び出される。当該メソッドは、アクティビティのいくつかの内部状態を維持する。その後、ウィンドウは、アクティビティが前景に現れるまで、一時停止され、そしてアクティビティの「ｏｎＲｅｓｕｍｅ（）」メソッドが呼び出される。アクティビティのウィンドウが見えない場合、そのことは、アクティビティの「ｏｎＳｔｏｐ（）」メソッドが呼び出されることを示す。アクティビティのウィンドウが閉じられるまでは、アクティビティの「ｏｎＲｅｓｔａｒｔ（）」メソッドは呼び出されず、そして、その後「ｏｎＳｔａｒｔ（）」メソッドが繰り返される。システムがリソースを再利用する場合、又はアクティビティの「ｆｉｎｉｓｈ（）」メソッドが呼び出された場合、アクティビティは停止され、そして当該アクティビティにより占有されるリソースを解放するために「ｏｎＤｅｓｔｒｏｙ（）」が呼び出される。
【００２３】
１０２．指定された領域のスクリーンショットを取得するために、指定されたアプリケーションの画面の指定された領域を取り込む。
【００２４】
本実施例において、指定された領域は、アプリケーションの全画面であってもよく、或いは携帯端末により事前設定された領域であってもよく、このことについては、本発明の本実施例においては限定されない。指定された領域のスクリーンの取り込みを実行することにより、ステータスバーのビューが取得されてもよく、必要に応じて、さらに、スクリーンショットがステータスバーを含むか否かを判定してもよい。
【００２５】
本実施例のステップ１０２は、指定されたアプリケーションの画面を閉じるための指令が受信された後であり、かつ指定されたアプリケーションの画面が閉じられる前に実行されることに注意すべきである。従来技術におけるステップ１０１のアクティビティのライフサイクルの説明と比較すると、従来技術における画面の取り込みは、「ｏｎＳｔｏｐ（）」メソッドが呼び出された後に実行されるのに対して、本発明の画面の取り込みは、「ｏｎＰａｕｓｅ（）」メソッドが呼び出された後であり、かつ「ｏｎＳｔｏｐ（）」メソッドが呼び出される前に実行される。
【００２６】
１０３．指定された領域のスクリーンショットを保存し、そして指定されたアプリケーションの画面を閉じる。
【００２７】
本実施例において、指定された領域のスクリーンショットが保存された後、携帯端末は、指定されたアプリケーションの画面を閉じ、そして受信した指令に従って、指定されたアプリケーションを終了するか、又はバックグラウンドで実行するように指定されたアプリケーションを切り替える。
【００２８】
ステップ１０３の後において、本実施例は、
指定されたアプリケーションを見るための指令が受信された場合に、指定された領域のスクリーンショットを取得し、かつ指定された領域のスクリーンショットを表示する；
ことをさらに含む。
【００２９】
本実施例において提供される方法において、アプリケーションの画面のアクティビティが閉じられる前であり、かつ、まだ当該アクティビティのウィンドウを視認可能である場合に、当該アクティビティの最終的な実際の画面を取得するために、アプリケーションの画面のスクリーンショットがとられる。このようにして、アプリケーションの画面が閉じられた後にスクリーンショットをとることに起因する高いメモリの使用率を回避し、その結果、画面のキャプチャ効率が向上され、そしてメモリの使用率及び呼び出し回数が低減される。
【００３０】
図２は、本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法のフローチャートである。この方法は、携帯端末により実行され、かつ指定されるアプリケーションは、現在、当該携帯端末において動作している。図２を参照すると、本実施例は、具体的には、以下の内容を含む：
【００３１】
２０１．携帯端末は、指定されたアプリケーションの画面を閉じるための指令を受信する。
【００３２】
ステップ２０１の原則は、ステップ１０１のそれと同じであり、ここにおいて再度の説明は行わない。
【００３３】
２０２．携帯端末は、ローカルディスプレイの大きさ及び事前に設定されたズーム比に従って、指定されたアプリケーションの画面の指定された領域を拡大し、そして当該指定された領域のスクリーンショットを取得するための拡大を行った後、サムネイルを取り込む。
【００３４】
本実施例において、ローカルディスプレイの大きさとは、当該携帯端末のディスプレイの大きさのことである。一般的に、アプリケーションの画面の大きさは、ローカルディスプレイの大きさと同じであり、つまり、スクリーンショットの本来の大きさは、ローカルディスプレイの大きさである。指定されたアプリケーションの画面の指定された領域は、ブラウジングの習慣に従って、携帯端末のユーザにより設定されてもよい。そして、指定された領域は、指定されたアプリケーションの画面の全画面領域であってもよく、或いは指定されたアプリケーションの画面の所定の領域であってもよい。事前に設定されたズーム比は、ブラウジングの習慣等に従って、携帯端末のユーザにより設定されてもよく、それについては本発明の本実施例においては特に限定されない。ステップ２０２は、具体的には：携帯端末が、ローカルディスプレイの大きさ及び事前に設定されたズーム比を取得するステップ、拡大後にサムネイルを取得するために、事前に設定されたズーム比に従って、ローカルディスプレイの大きさを、指定されたアプリケーションの画面の本来の大きさとして用いることにより、指定されたアプリケーションの画面の指定された領域を拡大するステップ、及び当該指定された領域のスクリーンショットを取得するための拡大の後、サムネイルを取り込むステップとを含む。
【００３５】
スクリーンショットをとるための具体的な方法は、「ｄｒａｗＦＢ（）」を呼び出すことにより実行されてもよい。当業者は、「ｄｒａｗＦＢ（）」が描画メソッドであり、この描画メソッドにおいて、ディスプレイの現在の画像は、事前に設定された表示装置を呼び出すことで取得され、当該事前に設定された表示装置のバッファピクセルが読み出され、そして当該バッファピクセルを用いることにより、ビットマップ画像が生成されることを知っているかもしれない。描画を行うために、「ｄｒａｗＦＢ（）」が当該事前に設定された表示装置を用いるため、「ｄｒａｗＦＢ（）」の領域は、ディスプレイのステータスバーにも及び、これにより画面取り込みの領域が拡大される。
【００３６】
例えば、「ｄｒａｗＦＢ（）」関数は、具体的には、以下のように表現されてもよい：
ｓｔａｔｉｃ  ｖｏｉｄ  ｄｒａｗＦＢ（ＪＮＩＥｎｖ＊ｅｎｖ，ｊｏｂｊｅｃｔ  ｊｃａｎｖａｓ，ＳｋＣａｎｖａｓ＊ｃａｎｖａｓ）｛
ｓｔｒｕｃｔ  ｆｂ＿ｖａｒ＿ｓｃｒｅｅｎｉｎｆｏ  ｖｉｎｆｏ；
ｉｎｔ  ｆｄ；
ｉｎｔ  ｏｆｆｓｅｔ；
ｉｎｔ  ｂｐｐ；
ｉｎｔ  ｓｉｚｅ；
ｉｎｔ  ｗ；
ｉｎｔ  ｈ；
ｕｎｓｉｇｎｅｄ  ｉ；
ｕｎｓｉｇｎｅｄ  ｂｙｔｅｓｐｐ；
ｕｎｓｉｇｎｅｄ  ｃｈａｒ＊ｂｕｆ；
ｆｄ＝ｏｐｅｎ（“／ｄｅｖ／ｇｒａｐｈｉｃｓ／ｆｂ０”，Ｏ＿ＲＤＯＮＬＹ）；／／Ｏｐｅｎ  ａｎ  ｆｂ  ｄｅｖｉｃｅ
ｉｆ（ｆｄ＜０）｛
ｒｅｔｕｒｎ；
｝
ｉｆ（ｉｏｃｔｌ（ｆｄ，ＦＢＩＯＧＥＴ＿ＶＳＣＲＥＥＮＩＮＦＯ，＆ｖｉｎｆｏ）＜０）｛／／Ｒｅａｄ  ｐａｒａｍｅｔｅｒｓ  ｏｆ  ｔｈｅ  ｆｂ  ｄｅｖｉｃｅ
ｃｌｏｓｅ（ｆｄ）；
ｒｅｔｕｒｎ；
｝
ｆｃｎｔｌ（ｆｄ，Ｆ＿ＳＥＴＦＤ，ＦＤ＿ＣＬＯＥＸＥＣ）；
ｂｙｔｅｓｐｐ＝ｖｉｎｆｏ．ｂｉｔｓ＿ｐｅｒ＿ｐｉｘｅｌ／８；
ｂｐｐ＝ｖｉｎｆｏ．ｂｉｔｓ＿ｐｅｒ＿ｐｉｘｅｌ；
ｓｉｚｅ＝ｖｉｎｆｏ．ｘｒｅｓ＊ｖｉｎｆｏ．ｙｒｅｓ＊ｂｙｔｅｓｐｐ；
ｗ＝ｖｉｎｆｏ．ｘｒｅｓ；
ｈ＝ｖｉｎｆｏ．ｙｒｅｓ；
／＊ＨＡＣＫ：ｆｏｒ  ｓｅｖｅｒａｌ  ｏｆ  ｏｕｒ  ３ｄ  ｃｏｒｅｓ  ａ  ｓｐｅｃｉｆｉｃ  ａｌｉｇｎｍｅｎｔ
＊ｉｓ  ｒｅｑｕｉｒｅｄ  ｓｏ  ｔｈｅ  ｓｔａｒｔ  ｏｆ  ｔｈｅ  ｆｂ  ｍａｙ  ｎｏｔ  ｂｅ  ａｎ  ｉｎｔｅｇｅｒ  ｎｕｍｂｅｒ  ｏｆ  ｌｉｎｅｓ
＊ｆｒｏｍ  ｔｈｅ  ｂａｓｅ．  Ａｓ  ａ  ｒｅｓｕｌｔ  ｗｅ  ａｒｅ  ｓｔｏｒｉｎｇ  ｔｈｅ  ａｄｄｉｔｉｏｎａｌ  ｏｆｆｓｅｔ  ｉｎ
＊ｘｏｆｆｓｅｔ．  Ｔｈｉｓ  ｉｓ  ｎｏｔ  ｔｈｅ  ｃｏｒｒｅｃｔ  ｕｓａｇｅ  ｆｏｒ  ｘｏｆｆｓｅｔ，  ｉｔ  ｓｈｏｕｌｄ  ｂｅ  ａｄｄｅｄ
＊ｔｏ  ｅａｃｈ  ｌｉｎｅ，  ｎｏｔ  ｊｕｓｔ  ｏｎｃｅ  ａｔ  ｔｈｅ  ｂｅｇｉｎｎｉｎｇ  
＊／
ｏｆｆｓｅｔ＝ｖｉｎｆｏ．ｘｏｆｆｓｅｔ＊ｂｙｔｅｓｐｐ；
ｏｆｆｓｅｔ＋＝ｖｉｎｆｏ．ｘｒｅｓ＊ｖｉｎｆｏ．ｙｏｆｆｓｅｔ＊ｂｙｔｅｓｐｐ；
ｌｓｅｅｋ（ｆｄ，ｏｆｆｓｅｔ，ＳＥＥＫ＿ＳＥＴ）；
ｂｕｆ＝（ｕｎｓｉｇｎｅｄ  ｃｈａｒ＊）ｍａｌｌｏｃ（ｓｉｚｅ）；
ｉｆ（ｂｕｆ＝＝ＮＵＬＬ）｛
ｃｌｏｓｅ（ｆｄ）；
ｒｅｔｕｒｎ；
｝
ｍｅｍｓｅｔ（ｂｕｆ，０，ｓｉｚｅ）；
ｒｅａｄ（ｆｄ，ｂｕｆ，ｓｉｚｅ）；／／Ｒｅａｄ  ｆｂ  ｐｉｘｅｌ  ｄａｔａ
ＳｋＢｉｔｍａｐ＊ｂｉｔｍａｐ＝ｎｅｗ  ＳｋＢｉｔｍａｐ（）；／／Ｃｒｅａｔｅ  ａ  ｂｉｔｍａｐ
｛
ＳｋＡｕｔｏＬｏｃｋＰｉｘｅｌｓ  ａｌｐ（＊ｂｉｔｍａｐ）；
／／Ｃｏｎｆｉｇ  ＫＲＧＢ＿５６５＿Ｃｏｎｆｉｇ  ｉｆ  ｏｎｅ  ｐｉｘｅｌ  ｉｓ  ｄｅｓｃｒｉｂｅｄ  ｂｙ  ｔｗｏ  Ｂｙｔｅｓ
ｉｆ  （ＴＷＯ＿ＢＹＴＥＳ＝＝ｂｙｔｅｓｐｐ）｛
ｂｉｔｍａｐ−＞ｓｅｔＣｏｎｆｉｇ（ＳｋＢｉｔｍａｐ：：ｋＲＧＢ＿５６５＿Ｃｏｎｆｉｇ，ｗ，ｈ）；
｝ｅｌｓｅ｛
ｂｉｔｍａｐ−＞ｓｅｔＣｏｎｆｉｇ（ＳｋＢｉｔｍａｐ：：ｋＡＲＧＢ＿８８８８＿Ｃｏｎｆｉｇ，ｗ，ｈ）；
｝
ｂｉｔｍａｐ−＞ｓｅｔＰｉｘｅｌｓ（ｂｕｆ）；／／Ｓｅｔ  ｐｉｘｅｌ  ｄａｔａ  ｏｆ  ｔｈｅ  ｂｉｔｍａｐ  ａｓ  ｐｉｘｅｌｓ  ｏｂｔａｉｎｅｄ  ｆｒｏｍ  ｔｈｅ  ｆｂ  ｄｅｖｉｃｅ
ｃａｎｖａｓ−＞ｄｒａｗＢｉｔｍａｐ（＊ｂｉｔｍａｐ，０，０，ＮＵＬＬ）；／／Ｄｒａｗ  ａ  ｂｉｔｍａｐ  ｏｎ  ａ  ｃａｎｖａｓ
ｃｌｏｓｅ（ｆｄ）；／／Ｃｌｏｓｅ  ｔｈｅ  ｆｂ  ｄｅｖｉｃｅ
ｆｒｅｅ（ｂｕｆ）；／／Ｒｅｌｅａｓｅ  ｂｕｆ  ｍｅｍｏｒｙ
ｂｉｔｍａｐ−＞ｓｅｔＰｉｘｅｌｓ（ＮＵＬＬ，ＮＵＬＬ）；／／Ｒｅｌｅａｓｅ  ｔｈｅ  ｐｉｘｅｌ  ｄａｔａ
｝
ｄｅｌｅｔｅ  ｂｉｔｍａｐ；／／Ｒｅｃｙｃｌｅ  ｔｈｅ  ｂｉｔｍａｐ  ｉｎｓｔａｎｃｅ
｝
【００３７】
２０３．指定された領域のスクリーンショットを保存し、そして指定されたアプリケーションの画面を閉じる。
【００３８】
本実施例において、指定された領域のスクリーンショットを取得するために、指定されたアプリケーションの画面の指定された領域が取り込まれ、そして指定された領域のスクリーンショットが保存された後、指定されたアプリケーションのスクリーンが閉じられる。指定されたアプリケーションの画面を閉じるステップは、スクリーンショットがとられた後に実行される。これにより、スクリーンショットの完全性及び有効性が確保され、指定されたアプリケーションの画面が閉じられた後にスクリーンショットをとることによるブランクの画面が回避され、そしてＧＬＳｕｒｆａｃｅＶｉｅｗクラスのビュー要素又はＲＳＳｕｒｆａｃｅＶｉｅｗクラスのビュー要素により形成されるアクティビティ、又はＬｉｖｅＷａｌｌｐａｐｅｒクラスの壁紙のバックグラウンドを含むアクティビティに対して、画面の取り込みを正確に実行することができる。
【００３９】
２０４．指定されたアプリケーションを見るための指令が受信された場合、指定された領域のスクリーンショットを取得し、かつ指定された領域のスクリーンショットを表示する。
【００４０】
本実施例において、指定されたアプリケーションを見るための指令は、履歴アプリケーションを見るための指令、又はバックグラウンドで実行中のアプリケーションを見るための指令であってもよい。当該指令は、携帯端末のタスクマネージャを起動することによって開始されてもよい。例えば、携帯端末のタスクマネージャが起動された場合、バックグラウンドで実行中のアプリケーションの指定された領域のスクリーンショットが表示され、かつ保存される。これにより、携帯端末のユーザは、バックグラウンドで実行中のアプリケーションを直接見ることができ、そしてバックグラウンドで実行中のアプリケーションの最終的な動作状態を知ることができる。当該指令は、履歴アプリケーション全て又はバックグラウンドで動作中の複数のアプリケーションに対するもの、又は所定の履歴アプリケーション又はバックグラウンドで動作中のアプリケーションに対するものであってもよく、これについては本発明の本実施例においては限定されない。本実施例において、携帯端末は、受信した操作指令に従って、指定されたアプリケーションに対する閲覧、切り替え、及び解除等の動作を実行してもよい。閲覧とは、指定されたアプリケーションの最終的な動作状態を見ることをいう。切り替えとは、指定されたアプリケーションの前景での実行からバックグラウンドでの実行への切り替え、又は指定されたアプリケーションのバックグラウンドでの実行から前景での実行への切り替えのことである。そして、解除とは、指定されたアプリケーションの指定された領域のスクリーンショットを削除することである。
【００４１】
上記実施例は、タブレットコンピュータ、セットトップボックス、又は固定局などのアンドロイドプラットフォームを使用する組み込み製品に対して適用されてもよい。
【００４２】
例えば、従来技術において、新しいアクティビティが前景に現れた場合、それ以前のアクティビティは、「ｏｎＰａｕｓｅ（）」ライフ状態に入り、そしてこの時、古いアクティビティは、まだ、視認可能である。古いアクティビティのウィンドウを視認可能である場合、古いアクティビティは、「ｏｎＳｔｏｐ（）」ライフ状態に入る。アンドロイドプラットフォームの画面取り込みアルゴリズムは、「ｏｎＳｔｏｐ（）」ライフ状態において取り込みを実行する。そして、ウィンドウが視認できないため、画面のサムネイルを取得するために、古いアクティビティを再描画する必要がある。これは、効率を下げるだけでなく、古いアクティビティの最終的な実際の画面の取得を困難にする。従って、本発明の本実施例においては、「ｏｎＰａｕｓｅ（）」ライフ状態において、スクリーンショットがとられる。図３を参照すると、図３は、本発明の実施例に従う、ＪＡＶＡ（登録商標）環境における、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法の例のフローチャートである。本発明において説明される「ｏｎＣｒｅａｔｅ（）」、「ｏｎＳｔａｒｔ（）」、「ｏｎＲｅｓｔａｒｔ（）」、「ｏｎＲｅｓｕｍｅ（）」、「ｄｒａｗＦＢ（）」、「ｏｎＰａｕｓｅ（）」、「ｏｎＳｔｏｐ（）」、及び「ｏｎＤｅｓｔｒｏｙ（）」は、全て、具体的には実行されず、かつ特定のアプリケーションの中で上書きすることで実行される必要のある抽象的関数である。アクティビティのライフサイクルは、以下の手順を含む：アクティビティが起動された場合、「ｏｎＣｒｅａｔｅ（）」、「ｏｎＳｔａｒｔ（）」、及び「ｏｎＲｅｓｕｍｅ（）」が順次呼び出され、これによりアクティビティは正常に動作する。アクティビティの画面が切り替えられた場合、画面の取り込みを実行するために「ｄｒａｗＦＢ（）」が呼び出され、その後、「ｏｎＳｔｏｐ（）」が呼び出され、そしてこの時、アクティビティは既に見えなくなっている。その後、以下の３つの状況のいずれかが生じ得る：「ｏｎＤｅｓｔｒｏｙ（）」が呼び出され、そしてアクティビティは停止される；他のアクティビティがメモリを必要とする場合、処理は強制終了され、そして当該他のアクティビティに対して「ｏｎＣｒｅａｔｅ（）」が呼び出される；又はアクティビティが、再度、前景に現れた場合、「ｏｎＲｅｓｔａｒｔ（）」が呼び出される。
【００４３】
本実施例において提供される方法によれば、アプリケーションのアクティビティが閉じられる前であり、かつ、まだ当該アクティビティのウィンドウが視認可能である場合、当該アクティビティの最終的な実際の画面を取得するために、アプリケーションの画面のスクリーンショットがとられる。このように、アプリケーションの画面が閉じられた後にスクリーンショットをとることによる高いメモリの使用率が回避され、従って、画面のキャプチャ効率が向上され、そしてメモリの使用率及び呼び出しの回数が低減される。
【００４４】
図４は、本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための装置の概略構成図である。図４を参照すると、本実施例は、具体的には：
指定されたアプリケーションの画面を閉じるための指令を受信する受信モジュール４０１；
指定された領域のスクリーンショットを取得するために、指定されたアプリケーションの指定された領域を取り込むスクリーンショットモジュール４０２；及び
指定された領域のスクリーンショットを保存し、かつ指定されたアプリケーションの画面を閉じる保存モジュール４０３；
を備える。
【００４５】
スクリーンショットモジュール４０２は：
ローカルディスプレイの大きさ及び現在のズーム比に従って、指定されたアプリケーションの画面の指定された領域を拡大するズーム部；及び
指定された領域のスクリーンショットを取得するための拡大の後、サムネイルを取り込むスクリーンショット部；
を備える。
【００４６】
装置は、さらに：
指定されたアプリケーションを閲覧するための指令を受信した場合に、指定された領域のスクリーンショットを取得し、かつ指定された領域のスクリーンショットを表示する表示モジュール；
を備える。
【００４７】
指定されたアプリケーションの画面を閉じるための指令は、バックグラウンドで実行するように指定されたアプリケーションを切り替える切替指令、又は前景で実行するように別のアプリケーションを切り替える切替指令、又は指定されたアプリケーションを終了するための終了指令である。
【００４８】
本実施例において提供される装置は、具体的には、携帯端末であってもよく、かつ方法についての実施例と同様な概念に基づいている。装置の具体的な実装の手順に関して、その詳細については、方法の実施例を参照することが可能であり、ここでは再度の説明は行われない。
【００４９】
本発明の複数の実施例により提供される上記複数の技術的解決手段の全て又はその一部分は、関連するハードウェアに指示するプログラムによって実現されてもよい。当該プログラムは、可読記憶媒体に記憶されてもよい。当該記憶媒体は、ＲＯＭ、ＲＡＭ、磁気ディスク、又は光学ディスクなどの、プログラムコードを記憶可能な如何なる媒体を含んでもよい。
【００５０】
上記の説明は、本発明の単なる例示的な実施例であり、本発明を限定することを意図するものではない。本発明の原理内で行われる、如何なる変更、均等な置き換え、又は改良も、本発明の保護範囲内に属するものとされなければならない。
【００５１】
［関連出願の相互参照］
本出願は、２０１１年１０月２６日に中国特許庁に出願された「ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＴＡＫＩＮＧ  ＳＣＲＥＥＮＳＨＯＴ  ＯＦ  ＳＣＲＥＥＮ  ＯＦ  ＡＰＰＬＩＣＡＴＩＯＮ  ＩＮ  ＭＯＢＩＬＥ  ＴＥＲＭＩＮＡＬ」と題する中国特許出願第２０１１１０３２９２９５．３の優先権を主張し、参照することにより、その全内容をここに援用する。
【図１】
0005887419.tif 000002
【図２】
0005887419.tif 000003
【図３】
0005887419.tif 000004
【図４】
0005887419.tif 000005