【文献】
ASCII.jp編集部,[online],来年のスマホはこうなる?Android 4.0の新機能を見る,2011年10月19日,[平成27年3月5日検索],URL,http://ascii.jp/elem/000/000/643/643618/
【文献】
できるシリーズ編集部,Optimus Pad 初版,株式会社インプレスジャパン,2011年 6月11日,第1版,p.10,29
【文献】
Tarandeep Singh,[online],Android 3.0 HoneyComb Features, Screenshots,2011年 1月27日,[平成27年3月5日検索],URL,http://geeknizer.com/android-3-0-honeycomb-features-screenshots/
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0010】
本発明の目的、技術的解決手段、長所を明瞭にするために、添付の図面を参照して、本発明の複数の実施例が以下においてさらに詳細に説明される。
【0011】
本発明において提供される、アプリケーションの画面のスクリーンショットをとるための方法を紹介する前に、まず、本発明に関する基礎知識を手短に紹介する。
【0012】
アクティビティ(Activity)は、アンドロイドプラットフォームの標準のコンポーネントである。実際、アクティビティは、アクティビティクラスから導出されるアプリケーションにおける単一の画面であり、複数のビュー(View)により形成されるユーザインタフェース(UI)を表示し、複数のイベントに応答する。
【0013】
履歴アクティビティ(History Activity)とは、ユーザにより一度開始された(複数の)アクティビティのことであり、バックグラウンドで動作中のタスクの中のアクティビティを含む。
【0014】
「SurfaceView」は、アンドロイドプラットフォームの特殊なビュークラスである。これは、3Dビュークラスである「GLSurfaceView」及び「RSSurfaceView」の親クラスである。これら2つの3Dビュークラス双方は、それらの独立した描画スレッド上で動作する。従って、「SurefaceView」は、その他の共通のビュークラスとは異なる。
【0015】
「LiveWallpaper」とは、アンドロイドプラットフォームのライブ壁紙のことであり、これは、通常、「RSSurfaceView」ビュークラスにより実行される。
【0016】
「ActivityManagerService」とは、アクティビティの管理サービスのことであり、アンドロイドプラットフォーム上での重要なシステムサービスである。
【0017】
「WindowManagerService」とは、ウィンドウ管理サービスのことであり、アンドロイドプラットフォームの重要なシステムサービスである。
【0018】
「TaskManager」とは、タスクマネージャのことであり、これは、タスク表示、切り替え及び消去といった機能を含むアンドロイドアプリケーションプログラムである。
【0019】
図1は、本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法のフローチャートである。この実施例は、携帯端末により実行される。
図1を参照すると、本実施例は、具体的には、以下の内容を含む:
【0020】
101.指定されたアプリケーションの画面を閉じるための指令を受信する。
【0021】
この実施例では、携帯端末において、少なくとも1つのアプリケーションが動作しており、かつ当該アプリケーションは、現時点においてフルスクリーン状態であってもよい。指定されたアプリケーションの画面を閉じるための指令は、バックグラウンドで実行するように指定されたアプリケーションを切り替えるための切替指令である、又は前景で実行するように別のアプリケーションを切り替えるための切替指令である、又は指定されたアプリケーションを終了するための終了指令である。指令が、バックグラウンドで実行するように指定されたアプリケーションを切り替えるための切替指令である場合、当該指令は、携帯端末のユーザにより手動で開始されてもよく、そして当該指令は、例えば、指定されたアプリケーションを最小化する。また、指令は、現在の状態に従って開始されてもよい。例えば、指定されたアプリケーションが20分間アイドル状態である場合に、バックグラウンドで実行するように指定されたアプリケーションを切り替えるための切替指令が開始される。
【0022】
当業者は、アプリケーションのアクティビティのライフサイクルが以下の内容を含むことを知っているかもしれない:
アクティビティが開始された場合であり、かつコンストラクター関数「Activity()」が開始された後、システムは、グローバル状態(global state)と「onCreate()メソッドにおけるアクティビティのリソースを設定するために、「onCreate()」メソッドを呼び出し、その後「onStart()」メソッドを呼び出す。「onStart()」メソッドが実行された後においては、まだ、アクティビティをスクリーン上で視認可能である。「onResume()」メソッドが実行され、この時、アクティビティは、ループにおける待機ウィンドウイベント(wait window event)内となる。ウィンドウを部分的に視認可能な場合、つまり、アクティビティが前景にはない場合、アクティビティの「onFreeze()」メソッドが呼び出される。当該メソッドは、アクティビティのいくつかの内部状態を維持する。その後、ウィンドウは、アクティビティが前景に現れるまで、一時停止され、そしてアクティビティの「onResume()」メソッドが呼び出される。アクティビティのウィンドウが見えない場合、そのことは、アクティビティの「onStop()」メソッドが呼び出されることを示す。アクティビティのウィンドウが閉じられるまでは、アクティビティの「onRestart()」メソッドは呼び出されず、そして、その後「onStart()」メソッドが繰り返される。システムがリソースを再利用する場合、又はアクティビティの「finish()」メソッドが呼び出された場合、アクティビティは停止され、そして当該アクティビティにより占有されるリソースを解放するために「onDestroy()」が呼び出される。
【0023】
102.指定された領域のスクリーンショットを取得するために、指定されたアプリケーションの画面の指定された領域を取り込む。
【0024】
本実施例において、指定された領域は、アプリケーションの全画面であってもよく、或いは携帯端末により事前設定された領域であってもよく、このことについては、本発明の本実施例においては限定されない。指定された領域のスクリーンの取り込みを実行することにより、ステータスバーのビューが取得されてもよく、必要に応じて、さらに、スクリーンショットがステータスバーを含むか否かを判定してもよい。
【0025】
本実施例のステップ102は、指定されたアプリケーションの画面を閉じるための指令が受信された後であり、かつ指定されたアプリケーションの画面が閉じられる前に実行されることに注意すべきである。従来技術におけるステップ101のアクティビティのライフサイクルの説明と比較すると、従来技術における画面の取り込みは、「onStop()」メソッドが呼び出された後に実行されるのに対して、本発明の画面の取り込みは、「onPause()」メソッドが呼び出された後であり、かつ「onStop()」メソッドが呼び出される前に実行される。
【0026】
103.指定された領域のスクリーンショットを保存し、そして指定されたアプリケーションの画面を閉じる。
【0027】
本実施例において、指定された領域のスクリーンショットが保存された後、携帯端末は、指定されたアプリケーションの画面を閉じ、そして受信した指令に従って、指定されたアプリケーションを終了するか、又はバックグラウンドで実行するように指定されたアプリケーションを切り替える。
【0028】
ステップ103の後において、本実施例は、
指定されたアプリケーションを見るための指令が受信された場合に、指定された領域のスクリーンショットを取得し、かつ指定された領域のスクリーンショットを表示する;
ことをさらに含む。
【0029】
本実施例において提供される方法において、アプリケーションの画面のアクティビティが閉じられる前であり、かつ、まだ当該アクティビティのウィンドウを視認可能である場合に、当該アクティビティの最終的な実際の画面を取得するために、アプリケーションの画面のスクリーンショットがとられる。このようにして、アプリケーションの画面が閉じられた後にスクリーンショットをとることに起因する高いメモリの使用率を回避し、その結果、画面のキャプチャ効率が向上され、そしてメモリの使用率及び呼び出し回数が低減される。
【0030】
図2は、本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法のフローチャートである。この方法は、携帯端末により実行され、かつ指定されるアプリケーションは、現在、当該携帯端末において動作している。
図2を参照すると、本実施例は、具体的には、以下の内容を含む:
【0031】
201.携帯端末は、指定されたアプリケーションの画面を閉じるための指令を受信する。
【0032】
ステップ201の原則は、ステップ101のそれと同じであり、ここにおいて再度の説明は行わない。
【0033】
202.携帯端末は、ローカルディスプレイの大きさ及び事前に設定されたズーム比に従って、指定されたアプリケーションの画面の指定された領域を拡大し、そして当該指定された領域のスクリーンショットを取得するための拡大を行った後、サムネイルを取り込む。
【0034】
本実施例において、ローカルディスプレイの大きさとは、当該携帯端末のディスプレイの大きさのことである。一般的に、アプリケーションの画面の大きさは、ローカルディスプレイの大きさと同じであり、つまり、スクリーンショットの本来の大きさは、ローカルディスプレイの大きさである。指定されたアプリケーションの画面の指定された領域は、ブラウジングの習慣に従って、携帯端末のユーザにより設定されてもよい。そして、指定された領域は、指定されたアプリケーションの画面の全画面領域であってもよく、或いは指定されたアプリケーションの画面の所定の領域であってもよい。事前に設定されたズーム比は、ブラウジングの習慣等に従って、携帯端末のユーザにより設定されてもよく、それについては本発明の本実施例においては特に限定されない。ステップ202は、具体的には:携帯端末が、ローカルディスプレイの大きさ及び事前に設定されたズーム比を取得するステップ、拡大後にサムネイルを取得するために、事前に設定されたズーム比に従って、ローカルディスプレイの大きさを、指定されたアプリケーションの画面の本来の大きさとして用いることにより、指定されたアプリケーションの画面の指定された領域を拡大するステップ、及び当該指定された領域のスクリーンショットを取得するための拡大の後、サムネイルを取り込むステップとを含む。
【0035】
スクリーンショットをとるための具体的な方法は、「drawFB()」を呼び出すことにより実行されてもよい。当業者は、「drawFB()」が描画メソッドであり、この描画メソッドにおいて、ディスプレイの現在の画像は、事前に設定された表示装置を呼び出すことで取得され、当該事前に設定された表示装置のバッファピクセルが読み出され、そして当該バッファピクセルを用いることにより、ビットマップ画像が生成されることを知っているかもしれない。描画を行うために、「drawFB()」が当該事前に設定された表示装置を用いるため、「drawFB()」の領域は、ディスプレイのステータスバーにも及び、これにより画面取り込みの領域が拡大される。
【0036】
例えば、「drawFB()」関数は、具体的には、以下のように表現されてもよい:
static void drawFB(JNIEnv*env,jobject jcanvas,SkCanvas*canvas){
struct fb_var_screeninfo vinfo;
int fd;
int offset;
int bpp;
int size;
int w;
int h;
unsigned i;
unsigned bytespp;
unsigned char*buf;
fd=open(“/dev/graphics/fb0”,O_RDONLY);//Open an fb device
if(fd<0){
return;
}
if(ioctl(fd,FBIOGET_VSCREENINFO,&vinfo)<0){//Read parameters of the fb device
close(fd);
return;
}
fcntl(fd,F_SETFD,FD_CLOEXEC);
bytespp=vinfo.bits_per_pixel/8;
bpp=vinfo.bits_per_pixel;
size=vinfo.xres*vinfo.yres*bytespp;
w=vinfo.xres;
h=vinfo.yres;
/*HACK:for several of our 3d cores a specific alignment
*is required so the start of the fb may not be an integer number of lines
*from the base. As a result we are storing the additional offset in
*xoffset. This is not the correct usage for xoffset, it should be added
*to each line, not just once at the beginning
*/
offset=vinfo.xoffset*bytespp;
offset+=vinfo.xres*vinfo.yoffset*bytespp;
lseek(fd,offset,SEEK_SET);
buf=(unsigned char*)malloc(size);
if(buf==NULL){
close(fd);
return;
}
memset(buf,0,size);
read(fd,buf,size);//Read fb pixel data
SkBitmap*bitmap=new SkBitmap();//Create a bitmap
{
SkAutoLockPixels alp(*bitmap);
//Config KRGB_565_Config if one pixel is described by two Bytes
if (TWO_BYTES==bytespp){
bitmap−>setConfig(SkBitmap::kRGB_565_Config,w,h);
}else{
bitmap−>setConfig(SkBitmap::kARGB_8888_Config,w,h);
}
bitmap−>setPixels(buf);//Set pixel data of the bitmap as pixels obtained from the fb device
canvas−>drawBitmap(*bitmap,0,0,NULL);//Draw a bitmap on a canvas
close(fd);//Close the fb device
free(buf);//Release buf memory
bitmap−>setPixels(NULL,NULL);//Release the pixel data
}
delete bitmap;//Recycle the bitmap instance
}
【0037】
203.指定された領域のスクリーンショットを保存し、そして指定されたアプリケーションの画面を閉じる。
【0038】
本実施例において、指定された領域のスクリーンショットを取得するために、指定されたアプリケーションの画面の指定された領域が取り込まれ、そして指定された領域のスクリーンショットが保存された後、指定されたアプリケーションのスクリーンが閉じられる。指定されたアプリケーションの画面を閉じるステップは、スクリーンショットがとられた後に実行される。これにより、スクリーンショットの完全性及び有効性が確保され、指定されたアプリケーションの画面が閉じられた後にスクリーンショットをとることによるブランクの画面が回避され、そしてGLSurfaceViewクラスのビュー要素又はRSSurfaceViewクラスのビュー要素により形成されるアクティビティ、又はLiveWallpaperクラスの壁紙のバックグラウンドを含むアクティビティに対して、画面の取り込みを正確に実行することができる。
【0039】
204.指定されたアプリケーションを見るための指令が受信された場合、指定された領域のスクリーンショットを取得し、かつ指定された領域のスクリーンショットを表示する。
【0040】
本実施例において、指定されたアプリケーションを見るための指令は、履歴アプリケーションを見るための指令、又はバックグラウンドで実行中のアプリケーションを見るための指令であってもよい。当該指令は、携帯端末のタスクマネージャを起動することによって開始されてもよい。例えば、携帯端末のタスクマネージャが起動された場合、バックグラウンドで実行中のアプリケーションの指定された領域のスクリーンショットが表示され、かつ保存される。これにより、携帯端末のユーザは、バックグラウンドで実行中のアプリケーションを直接見ることができ、そしてバックグラウンドで実行中のアプリケーションの最終的な動作状態を知ることができる。当該指令は、履歴アプリケーション全て又はバックグラウンドで動作中の複数のアプリケーションに対するもの、又は所定の履歴アプリケーション又はバックグラウンドで動作中のアプリケーションに対するものであってもよく、これについては本発明の本実施例においては限定されない。本実施例において、携帯端末は、受信した操作指令に従って、指定されたアプリケーションに対する閲覧、切り替え、及び解除等の動作を実行してもよい。閲覧とは、指定されたアプリケーションの最終的な動作状態を見ることをいう。切り替えとは、指定されたアプリケーションの前景での実行からバックグラウンドでの実行への切り替え、又は指定されたアプリケーションのバックグラウンドでの実行から前景での実行への切り替えのことである。そして、解除とは、指定されたアプリケーションの指定された領域のスクリーンショットを削除することである。
【0041】
上記実施例は、タブレットコンピュータ、セットトップボックス、又は固定局などのアンドロイドプラットフォームを使用する組み込み製品に対して適用されてもよい。
【0042】
例えば、従来技術において、新しいアクティビティが前景に現れた場合、それ以前のアクティビティは、「onPause()」ライフ状態に入り、そしてこの時、古いアクティビティは、まだ、視認可能である。古いアクティビティのウィンドウを視認可能である場合、古いアクティビティは、「onStop()」ライフ状態に入る。アンドロイドプラットフォームの画面取り込みアルゴリズムは、「onStop()」ライフ状態において取り込みを実行する。そして、ウィンドウが視認できないため、画面のサムネイルを取得するために、古いアクティビティを再描画する必要がある。これは、効率を下げるだけでなく、古いアクティビティの最終的な実際の画面の取得を困難にする。従って、本発明の本実施例においては、「onPause()」ライフ状態において、スクリーンショットがとられる。
図3を参照すると、
図3は、本発明の実施例に従う、JAVA(登録商標)環境における、携帯端末内のアプリケーションの画面のスクリーンショットをとるための方法の例のフローチャートである。本発明において説明される「onCreate()」、「onStart()」、「onRestart()」、「onResume()」、「drawFB()」、「onPause()」、「onStop()」、及び「onDestroy()」は、全て、具体的には実行されず、かつ特定のアプリケーションの中で上書きすることで実行される必要のある抽象的関数である。アクティビティのライフサイクルは、以下の手順を含む:アクティビティが起動された場合、「onCreate()」、「onStart()」、及び「onResume()」が順次呼び出され、これによりアクティビティは正常に動作する。アクティビティの画面が切り替えられた場合、画面の取り込みを実行するために「drawFB()」が呼び出され、その後、「onStop()」が呼び出され、そしてこの時、アクティビティは既に見えなくなっている。その後、以下の3つの状況のいずれかが生じ得る:「onDestroy()」が呼び出され、そしてアクティビティは停止される;他のアクティビティがメモリを必要とする場合、処理は強制終了され、そして当該他のアクティビティに対して「onCreate()」が呼び出される;又はアクティビティが、再度、前景に現れた場合、「onRestart()」が呼び出される。
【0043】
本実施例において提供される方法によれば、アプリケーションのアクティビティが閉じられる前であり、かつ、まだ当該アクティビティのウィンドウが視認可能である場合、当該アクティビティの最終的な実際の画面を取得するために、アプリケーションの画面のスクリーンショットがとられる。このように、アプリケーションの画面が閉じられた後にスクリーンショットをとることによる高いメモリの使用率が回避され、従って、画面のキャプチャ効率が向上され、そしてメモリの使用率及び呼び出しの回数が低減される。
【0044】
図4は、本発明の実施例に従う、携帯端末内のアプリケーションの画面のスクリーンショットをとるための装置の概略構成図である。
図4を参照すると、本実施例は、具体的には:
指定されたアプリケーションの画面を閉じるための指令を受信する受信モジュール401;
指定された領域のスクリーンショットを取得するために、指定されたアプリケーションの指定された領域を取り込むスクリーンショットモジュール402;及び
指定された領域のスクリーンショットを保存し、かつ指定されたアプリケーションの画面を閉じる保存モジュール403;
を備える。
【0045】
スクリーンショットモジュール402は:
ローカルディスプレイの大きさ及び現在のズーム比に従って、指定されたアプリケーションの画面の指定された領域を拡大するズーム部;及び
指定された領域のスクリーンショットを取得するための拡大の後、サムネイルを取り込むスクリーンショット部;
を備える。
【0046】
装置は、さらに:
指定されたアプリケーションを閲覧するための指令を受信した場合に、指定された領域のスクリーンショットを取得し、かつ指定された領域のスクリーンショットを表示する表示モジュール;
を備える。
【0047】
指定されたアプリケーションの画面を閉じるための指令は、バックグラウンドで実行するように指定されたアプリケーションを切り替える切替指令、又は前景で実行するように別のアプリケーションを切り替える切替指令、又は指定されたアプリケーションを終了するための終了指令である。
【0048】
本実施例において提供される装置は、具体的には、携帯端末であってもよく、かつ方法についての実施例と同様な概念に基づいている。装置の具体的な実装の手順に関して、その詳細については、方法の実施例を参照することが可能であり、ここでは再度の説明は行われない。
【0049】
本発明の複数の実施例により提供される上記複数の技術的解決手段の全て又はその一部分は、関連するハードウェアに指示するプログラムによって実現されてもよい。当該プログラムは、可読記憶媒体に記憶されてもよい。当該記憶媒体は、ROM、RAM、磁気ディスク、又は光学ディスクなどの、プログラムコードを記憶可能な如何なる媒体を含んでもよい。
【0050】
上記の説明は、本発明の単なる例示的な実施例であり、本発明を限定することを意図するものではない。本発明の原理内で行われる、如何なる変更、均等な置き換え、又は改良も、本発明の保護範囲内に属するものとされなければならない。
【0051】
[関連出願の相互参照]
本出願は、2011年10月26日に中国特許庁に出願された「METHOD AND APPARATUS FOR TAKING SCREENSHOT OF SCREEN OF APPLICATION IN MOBILE TERMINAL」と題する中国特許出願第201110329295.3の優先権を主張し、参照することにより、その全内容をここに援用する。