WO2017037817A1

WO2017037817A1 - アプリケーション実行装置およびアプリケーション実行方法

Info

Publication number: WO2017037817A1
Application number: PCT/JP2015/074573
Authority: WO
Inventors: 達也三次
Original assignee: 三菱電機株式会社
Priority date: 2015-08-31
Filing date: 2015-08-31
Publication date: 2017-03-09
Also published as: JP6272578B2; US20180143837A1; US10417008B2; JPWO2017037817A1; CN107924315A; DE112015006862T5

Abstract

本発明は、コールドブート時に早く起動し、かつカメラ映像の引き継ぎ時に表示画像にちらつきが生じないようにすることが可能なアプリケーション実行装置およびアプリケーション実行方法を提供することを目的とする。本発明によるアプリケーション実行装置は、予め定められた機能機構を有するカーネルと、カーネルにより起動され、機能機構を抽象化した抽象化機能機構を有するフレームワークと、機能機構を直接的に利用して動作する第１のアプリケーションと、抽象化機能機構を介して機能機構を間接的に利用して動作し、第１のアプリケーションの機能を有する第２のアプリケーションとを備え、第１のアプリケーションは、第２のアプリケーションよりも容量が小さいことを特徴とする。

Description

アプリケーション実行装置およびアプリケーション実行方法

　本発明は、アプリケーションを実行するアプリケーション実行装置およびアプリケーション実行方法に関する。

　後方を撮影するカメラを車両に搭載し、後方発進時にカメラで撮影された映像（以下、カメラ映像という）をディスプレイに表示する技術がある。当該技術では、後方発進時にカメラ映像を素早くディスプレイに表示することが要求されている。

　例えば、高機能ＯＳ（Operating System）を有するＣＰＵ（Central Processing Unit）以外のハードウェアで処理したカメラ映像をディスプレイに出力、または高機能ＯＳを有するＣＰＵにおけるブートローダの機能によってカメラ映像をディスプレイに出力した後に、ＣＰＵ以外のハードウェア、または高機能ＯＳにおけるカメラアプリケーションによってカメラ映像にガイド線を重畳してディスプレイに出力している。このように、まずカメラ映像を表示し、その後、ガイド線を重畳したカメラ映像を表示するという映像の引き継ぎが行われている。ここで、高機能ＯＳとは、高度な情報処理を行うＯＳのことをいい、例えばＬｉｎｕｘ（登録商標）ＯＳおよびＡｎｄｒｏｉｄＯＳ等が挙げられる。

　従来、車両後部に設置されたカメラと、映像信号に加工処理を施して画像表示手段に向けて出力する画像処理回路と、バックギヤの入力操作に連動して画像処理回路による加工処理（画像にガイド線を重畳する処理）が可能か否かを判断する判断手段とを備え、ガイド線が必要ないときはカメラ映像にガイド線を重畳する処理を施さず、ガイド線が必要なときはカメラ映像にガイド線を重畳する処理を施す車載用後方監視装置が開示されている（例えば、特許文献１参照）。

　また、メインＣＰＵの起動が完了したか否かを判定する起動判定手段と、起動判定手段でメインＣＰＵの起動が完了していないと判定した場合に、メインＣＰＵを利用せずに表示ＣＰＵによって撮像装置で得られた画像を車載表示機器に表示させる表示制御手段とを備える車両用表示装置が開示されている（例えば、特許文献２参照）。

　また、電子機器の通常の起動を指示する第１の指示部と、電子機器の一時的起動を指示する第２の指示部と、第１の演算処理部と、第２の演算処理部とを備え、第１の演算処理部は、第１の指示部により指示された場合は第１のオペレーティングシステムを実行し、第１のオペレーティングシステムの起動が完了すると第１のユーザインタフェースの処理を実行し、第２の指示部により指示された場合は第１のオペレーティングシステムおよび第１のユーザインタフェースの処理を実行せず、第２の演算処理部は、第１のオペレーティングシステムに比較して短い時間で起動される第２のオペレーティングシステムを実行し、第１の指示部により指示された場合は第２のオペレーティングシステムの起動が完了すると第２のユーザインタフェースの処理を実行し、第１のオペレーティングシステムの起動が完了したとき第２のユーザインタフェースの処理の実行を抑制する電子機器が開示されている（例えば、特許文献３参照）。

特許第４４９８７７１号公報特許第４９７８５５８号公報特許第５０２８９０４号公報

　上述の通り、車両の後方発進時にカメラ映像をディスプレイに表示する際、カメラ映像を素早く（例えば、電源ＯＮ後２秒以内に）ディスプレイに表示することが要求されている。すなわち、いかに高速にカメラ映像を表示させるためのアプリケーション（以下、カメラアプリケーションという）を起動させるかが課題となる。特に、コールドブート時の起動には時間がかかるため、コールドブート時の起動を早くする必要がある。

　特許文献１では、バックギヤがオンの時にグラフィックＬＳＩによる加工処理が可能であるか否かを判断し、グラフィックＬＳＩによる加工処理が可能でないと判断した時には、カメラの映像信号がグラフィックＬＳＩを介さずにＬＣＤパネルに直接入力される状態となるように切り替えスイッチ手段で切り替えている。従って、カメラ映像にガイド線を重畳させるハードウェアが必要となりコストがかかる。また、切り替えスイッチ手段によってカメラ映像の通過経路を切り替えているため、カメラ映像の引き継ぎ時に表示画像にちらつきが生じる。

　特許文献２では、メインＣＰＵと表示ＣＰＵとを切り替えているため、カメラ映像の通過経路が異なっている。従って、カメラ映像の引き継ぎ時に表示画像にちらつきが生じる。また、カメラ映像にガイド線を重畳させるハードウェアが必要となりコストがかかる。

　特許文献３では、第１のオペレーティングシステムと第２のオペレーティングシステムとを切り替えているため、切り替え時（カメラ映像の引き継ぎ時）に表示画像にちらつきが生じる。

　高機能ＯＳを有するＣＰＵにおけるブートローダの機能によってカメラ映像をディスプレイに出力する場合は、カメラ映像の引き継ぎ時に表示画像にちらつきが生じる。

　上記より、従来では、カメラ映像の引き継ぎ時に表示画像にちらつきが生じるという問題があった。従って、コールドブート時に高速に起動し、かつカメラ映像の引き継ぎ時に表示画像にちらつきが生じないようにすることが望まれる。

　本発明は、このような問題を解決するためにされたものであり、コールドブート時に高速に起動し、かつカメラ映像の引き継ぎ時に表示画像にちらつきが生じないようにすることが可能なアプリケーション実行装置およびアプリケーション実行方法を提供することを目的とする。

　上記の課題を解決するために、本発明によるアプリケーション実行装置は、予め定められた機能機構を有するカーネルと、カーネルにより起動され、機能機構を抽象化した抽象化機能機構を有するフレームワークと、機能機構を直接的に利用して動作する第１のアプリケーションと、抽象化機能機構を介して機能機構を間接的に利用して動作し、第１のアプリケーションの機能を有する第２のアプリケーションとを備え、第１のアプリケーションは、第２のアプリケーションよりも容量が小さいことを特徴とする。

　また、本発明によるアプリケーション実行方法は、少なくともカーネルおよびフレームワークの順に起動して第１のアプリケーションおよび第２のアプリケーションを実行するアプリケーション実行方法であって、カーネルは、予め定められた機能機構を有し、フレームワークは、カーネルにより起動され、機能機構を抽象化した抽象化機能機構を有し、第１のアプリケーションは、機能機構を直接的に利用して動作し、第２のアプリケーションは、抽象化機能機構を介して機能機構を間接的に利用して動作し、第１のアプリケーションの機能を有し、第１のアプリケーションは、第２のアプリケーションよりも容量が小さいことを特徴とする。

　本発明によると、アプリケーション実行装置は、予め定められた機能機構を有するカーネルと、カーネルにより起動され、機能機構を抽象化した抽象化機能機構を有するフレームワークと、機能機構を直接的に利用して動作する第１のアプリケーションと、抽象化機能機構を介して機能機構を間接的に利用して動作し、第１のアプリケーションの機能を有する第２のアプリケーションとを備え、第１のアプリケーションは、第２のアプリケーションよりも容量が小さいため、コールドブート時に早く起動し、かつカメラ映像の引き継ぎ時に表示画像にちらつきが生じないようにすることが可能となる。

　また、アプリケーション実行方法は、少なくともカーネルおよびフレームワークの順に起動して第１のアプリケーションおよび第２のアプリケーションを実行するアプリケーション実行方法であって、カーネルは、予め定められた機能機構を有し、フレームワークは、カーネルにより起動され、機能機構を抽象化した抽象化機能機構を有し、第１のアプリケーションは、機能機構を直接的に利用して動作し、第２のアプリケーションは、抽象化機能機構を介して機能機構を間接的に利用して動作し、第１のアプリケーションの機能を有し、第１のアプリケーションは、第２のアプリケーションよりも容量が小さいため、コールドブート時に早く起動し、かつカメラ映像の引き継ぎ時に表示画像にちらつきが生じないようにすることが可能となる。

　本発明の目的、特徴、態様、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。

本発明の実施の形態１によるアプリケーション実行装置に係るハードウェア構成の一例を示すブロック図である。本発明の実施の形態１によるアプリケーション実行装置のソフトウェア構成の一例を示すブロック図である。本発明の実施の形態１によるアプリケーション実行装置のソフトウェア構成の一例を示すブロック図である。本発明の実施の形態１によるアプリケーション実行装置に係るハードウェア構成の一例を示すブロック図である。本発明の実施の形態１によるアプリケーション実行装置の起動順序の一例を示す図である。本発明の実施の形態１によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態１によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態１によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態１によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態１によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態２によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態２によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態３によるアプリケーション実行装置のソフトウェア構成の一例を示すブロック図である。本発明の実施の形態３によるアプリケーション実行装置のソフトウェア構成の一例を示すブロック図である。本発明の実施の形態３によるフレーム制御機構と表示機構との関係を示す図である。本発明の実施の形態３によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態３によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態３によるアプリケーション実行装置の動作の一例を示す図である。本発明の実施の形態３によるアプリケーション実行装置の動作の一例を示す図である。従来のノーマルカメラアプリケーションのみを動作させた場合の一例を示す図である。従来技術によるハードウェア構成の一例を示すブロック図である。従来技術によるソフトウェア構成の一例を示すブロック図である。

　本発明の実施の形態について、図面に基づいて以下に説明する。

　＜実施の形態１＞
　まず、本発明の実施の形態１によるアプリケーション実行装置の構成について説明する。

　図１は、本実施の形態１によるアプリケーション実行装置に係るハードウェア構成の一例を示すブロック図である。なお、図１では、カメラ１で撮影されたカメラ映像をディスプレイ４に表示させるアプリケーションを実行するアプリケーション実行装置に係るハードウェア構成の一例を示している。

　図１に示すように、カメラ１で撮影されたカメラ映像は、キャプチャ２でＣＰＵ３に適したフォーマットに変換される。キャプチャ２で変換されたカメラ映像は、ＣＰＵ３でガイド線などの描画情報が付加されて、ディスプレイ４に出力される。ＣＰＵ３は、カメラ映像と、ガイド線など描画情報が付加されたカメラ映像との切り替えを行う。本実施の形態１によるアプリケーション実行装置は、ＣＰＵ３の動作によって実現される。

　図１に示すハードウェア構成は、通常のカメラ映像をディスプレイに出力するハードウェア構成（高速起動を必要としないハードウェア構成）と同様であり、高速起動を行うためのハードウェアを別個備えていない。本実施の形態１では、図１に示すハードウェア構成によって高速起動を実現している。

　図２１は、従来技術によるハードウェア構成の一例を示すブロック図である。なお、図２１は、特許文献１，２のハードウェア構成を概略的に示したものである。

　図２１に示すように、ＣＰＵ２８の起動前において、カメラ２５で撮影されたカメラ映像は、キャプチャ２６、グラフィック２７、スイッチ２９、およびディスプレイ３０の経路を通ってディスプレイ３０に出力される。このとき、ディスプレイ３０には、カメラ２５で撮影されたカメラ映像が表示される。

　また、ＣＰＵ２８が起動すると、カメラ２５で撮影されたカメラ映像は、キャプチャ２６、グラフィック２７、ＣＰＵ２８、およびスイッチ２９の経路を通ってディスプレイ３０に出力される。このとき、ディスプレイ３０には、ＣＰＵ２８でガイド線の重畳処理が施されたカメラ映像が表示される。

　上記より、図２１に示す従来技術では、スイッチ２９でカメラ映像の通過経路を切り替えているため、カメラ映像の引き継ぎ時にちらつきが生じる。

　図２は、本実施の形態１によるアプリケーション実行装置のソフトウェア構成の一例を示すブロック図である。なお、図２では、図１のＣＰＵ３で実行されるソフトウェア構成を示している。

　図２に示すように、ＣＰＵ３は、カーネル５、フレームワーク７、ネイティブカメラアプリケーション９、およびノーマルカメラアプリケーション１０を実行する機能を有している。

　カーネル５は、ディスプレイ４に表示する機能である表示機構６を有している。また、カーネル５は、ディスプレイ４に表示させるためのドライバ（図２の例では、ディスプレイドライバ、キャプチャドライバ）、ハードウェアリソース（図２の例では、ＣＰＵ３に備えられている、ディスプレイ４に繋がるデバイス）を有している。表示機構６は、ドライバの上位に存在している。なお、本実施の形態１では、カーネル５はＬｉｎｕｘカーネルであるものとして説明するが、これに限るものではない。また、表示機構６は、ＡｎｄｒｏｉｄＯＳのＳｕｒｆａｃｅＦｌｉｎｇｅｒおよびＨａｒｄｗａｒｅＣｏｍｐｏｓｅｒであってもよい。

　フレームワーク７は、カーネルが有する表示機構６、ドライバ、ハードウェアリソースを抽象化した抽象化表示機構８を有している。

　ネイティブカメラアプリケーション９は、カメラ映像をディスプレイ４に表示するためのアプリケーションであり、表示機構６を直接的に利用して動作する。また、ネイティブカメラアプリケーション９は、カメラ映像を出力または出力しない程度の基本的な機能のみを有し、カメラ映像にガイド線を重畳させる機能は有していない。すなわち、ネイティブカメラアプリケーション９は、後述するノーマルアプリケーション１０が有する機能のうちの特定の機能を有している。

　ノーマルカメラアプリケーション１０は、カメラ映像をディスプレイ４に表示するためのアプリケーションであり、抽象化表示機構８を介して表示機構６を間接的に利用して動作する。また、ノーマルカメラアプリケーション１０は、カメラ映像にガイド線を重畳する機能等の複雑な機能を有している。

　図３は、本実施の形態１によるアプリケーション実行装置のソフトウェア構成の一例を示すブロック図である。なお、図３に示すソフトウェア構成は、図２に示すソフトウェア構成を一般化したものである。

　図３に示すように、カーネル５は、図２の表示機構６を含む機能機構１１を有している。また、カーネル５は、図２で説明したドライバおよびハードウェアリソースを含む、ペリフェラル群のドライバおよびハードウェアリソースを有している。

　フレームワーク７は、機能機構１１、ドライバ、およびハードウェアリソースを抽象化した抽象化機能機構１２を有している。

　ネイティブアプリケーション１３（第１のアプリケーション）は、機能機構１１を直接的に利用して動作する。また、ノーマルアプリケーション１４（第２のアプリケーション）は、ネイティブアプリケーション１３の機能を有し、抽象化機能機構１２を介して機能機構１１を間接的に利用して動作する。ネイティブアプリケーション１３は、ノーマルアプリケーション１４が有する機能のうちの特定の機能を有している。

　図２２は、従来技術によるソフトウェア構成の一例を示すブロック図である。なお、図２２は、特許文献３のソフトウェア構成を概略的に示したものである。

　図２２に示すように、ＯＳ３１は、表示機構３２を有しており、アプリケーション３３は、表示機構３２を利用して動作する。また、ＯＳ３４は、表示機構３５を有しており、アプリケーション３６は、表示機構３５を利用して動作する。なお、アプリケーション３３，３６は、ディスプレイに映像を表示させるためのアプリケーションであるものとする。

　図２２に示す従来技術では、アプリケーション３３，３６ごとにＯＳ３１，３４が異なっているため、アプリケーション３３，３６の切り替え時にはＯＳ３１，３４を切り替える必要がある。このとき、アプリケーション３３，３６ごとに表示機構３２，３５が異なっているため、アプリケーション３３，３６の切り替え時に映像のちらつきが生じる。

　図４は、本実施の形態１によるアプリケーション実行装置に係るハードウェア構成の一例を示すブロック図である。なお、図４では、図１のＣＰＵ３周辺のハードウェア構成を示している。

　図４に示すように、ＣＰＵ３には、ＮＯＲ型フラッシュメモリ１５、ｅＭＭＣ（embedded Multi Media Card）１６、およびＤＲＡＭ（Dynamic Random Access Memory）１７が接続されている。なお、ＮＯＲ型フラッシュメモリ１５、ｅＭＭＣ１６、およびＤＲＡＭ１７は、図１では図示を省略している。

　ＮＯＲ型フラッシュメモリ１５は、ブートローダ１８を格納している。なお、ＮＯＲ型フラッシュメモリ１５は、小規模容量のストレージであればよく、例えばＲＯＭ（Read Only Memory）等であってもよい。

　ｅＭＭＣ１６は、カーネル５と、フレームワーク７と、ネイティブカメラアプリケーション９およびノーマルカメラアプリケーション１０を含むアプリケーション（図示せず）とを格納している。なお、ｅＭＭＣ１６は、大規模容量のストレージであればよく、例えばハードディスク等であってもよい。

　ＣＰＵ３は、カーネル５、フレームワーク７、およびブートローダ１８のうちの少なくとも１つをＤＲＡＭ１７にロードして動作させる。なお、図２のネイティブカメラアプリケーション９およびノーマルカメラアプリケーション１０と、図３のネイティブアプリケーション１３およびノーマルアプリケーション１４とは、ｅＭＭＣ１６に格納されている。

　次に、アプリケーション実行装置の全体的な動作について、図５～８を用いて説明する。

　図５に示すように、アプリケーション実行装置は、ブートローダ１８、カーネル５、フレームワーク７の順に起動することによって動作する。以下、ブートローダ１８、カーネル５、およびフレームワーク７起動の詳細について説明する。

　図６に示すように、ＣＰＵ３は、ＮＯＲ型フラッシュメモリ１５に格納されているプログラムを用いて、ＮＯＲ型フラッシュメモリ１５に格納されているブートローダ１８をＤＲＡＭ１７にロードする。ロードされたブートローダ１８は、ＤＲＡＭ１７で起動して動作する。ここで、ＮＯＲ型フラッシュメモリ１５に格納されているプログラムは、ブートローダ１８をＤＲＡＭ１７にロードする機能を有している。

　図７に示すように、ブートローダ１８は、ｅＭＭＣ１６に格納されているカーネル５をＤＲＡＭ１７にロードする。ロードされたカーネル５は、ＤＲＡＭ１７で起動して動作する。具体的には、カーネル５は、ドライバ、ハードウェアリソース、および機能機構を初期化展開する。

　図８に示すように、カーネル５は、ｅＭＭＣ１６に格納されているフレームワーク７をＤＲＡＭ１７にロードする。ロードされたフレームワーク７は、ＤＲＡＭ１７で起動して動作する。具体的には、フレームワーク７は、抽象化機能機構および他のソフトウェアコンポーネント（抽象化された他の機能機構）を初期化展開する。

　上記において、高機能ＯＳは、フレームワーク７で構成される。カーネル５およびフレームワーク７は、ＤＲＡＭ１７で協調的に動作する。一方、ブートローダ１８は、高機能ＯＳのローディングが終われば、ＤＲＡＭ１７から排出されて動作しない。ブートローダ１８と高機能ＯＳとはシステムが異なる。なお、本実施の形態１では、高機能ＯＳ（フレームワーク７）はＡｎｄｒｏｉｄＯＳであるものとして説明するが、これに限るものではない。

　次に、アプリケーション実行装置の詳細な動作について説明する。

　図９は、ＣＰＵ３が図３に示す各機能を有する場合における、アプリケーション実行装置の動作の一例を示す図である。

　図９に示すように、ＣＰＵ３の電源ＯＮ後、ブートローダ１８は、カーネル５をＤＲＡＭ１７にロードする。カーネル５は、ＤＲＡＭ１７で起動する（図６，７参照）。

　ＣＰＵ３は、ネイティブアプリケーション１３をＤＲＡＭ１７にロードし、ネイティブアプリケーション１３を起動する。ネイティブアプリケーション１３は、カーネル５の機能機構１１を直接的に利用して、予め定められた機能を実行する。

　ネイティブアプリケーション１３の起動後、カーネル５は、フレームワーク７をＤＲＡＭ１７にロードする。フレームワーク７は、ＤＲＡＭ１７で起動する（図８参照）。

　フレームワーク７の起動後、ＣＰＵ３は、ノーマルアプリケーション１４をＤＲＡＭ１７にロードし、ノーマルアプリケーション１４を起動する。ノーマルアプリケーション１４は、フレームワーク７の抽象化機能機構１２を介して、カーネル５の機能機構１１を間接的に利用して、予め定められた機能を実行する。

　上記において、ネイティブアプリケーション１３は、ＤＲＡＭ１７にロードし展開されるため、ロード時間は、ネイティブアプリケーション１３の容量に依存する。ＣＰＵ３の電源ＯＮから短時間でネイティブアプリケーション１３を起動するためには、ネイティブアプリケーション１３の機能を最小限にして、ネイティブアプリケーション１３のプログラム容量を抑える（すなわち、ネイティブカメラアプリケーション９は、ノーマルカメラアプリケーション１０よりも容量を小さくする）必要がある。これにより、ネイティブアプリケーション１３のロード時間が最適化されて、ＣＰＵ３の電源ＯＮからネイティブアプリケーション１３による動作までの時間が短縮する。

　なお、ネイティブアプリケーション１３は、ノーマルアプリケーション１４の実行後に、任意のタイミングで動作を終了する。任意のタイミングとしては、ノーマルアプリケーション１４が動作し始めた時であってもよく、ノーマルアプリケーション１４が完全に動作した時（ノーマルアプリケーション１４の動作後）であってもよい。

　図１０は、ＣＰＵ３が図２に示す各機能を有する場合における、アプリケーション実行装置の動作の一例を示す図である。

　図１０に示すように、ＣＰＵ３の電源ＯＮ後、ブートローダ１８は、カーネル５をＤＲＡＭ１７にロードする。カーネル５は、ＤＲＡＭ１７で起動する（図６，７参照）。

　ＣＰＵ３は、ネイティブカメラアプリケーション９をＤＲＡＭ１７にロードし、ネイティブカメラアプリケーション９を起動する。ネイティブカメラアプリケーション９は、カーネル５の表示機構６を利用して、カメラ映像をディスプレイ４に出力する。

　ネイティブカメラアプリケーション９の起動後、カーネル５は、フレームワーク７をＤＲＡＭ１７にロードする。フレームワーク７は、ＤＲＡＭ１７で起動する（図８参照）。

　フレームワーク７の起動後、ＣＰＵ３は、ノーマルカメラアプリケーション１０をＤＲＡＭ１７にロードし、ノーマルカメラアプリケーション１０を起動する。ノーマルカメラアプリケーション１０は、フレームワーク７の抽象化表示機構８を介して、カーネル５の表示機構６を間接的に利用して、ガイド線などの付加情報を重畳したカメラ映像をディスプレイ４に表示する。

　上記において、ネイティブカメラアプリケーション９は、ＤＲＡＭ１７にロードし展開されるため、ロード時間は、ネイティブカメラアプリケーション９の容量に依存する。ＣＰＵ３の電源ＯＮから短時間でネイティブカメラアプリケーション９を起動するためには、ネイティブカメラアプリケーション９の機能を最小限にして、ネイティブカメラアプリケーション９のプログラム容量を抑える（すなわち、ネイティブカメラアプリケーション９は、ノーマルカメラアプリケーション１０よりも容量を小さくする）必要がある。これにより、ネイティブカメラアプリケーション９のロード時間が最適化されて、ＣＰＵ３の電源ＯＮからネイティブカメラアプリケーション９による動作までの時間が短縮する。

　また、ネイティブカメラアプリケーション９およびノーマルカメラアプリケーション１０は、同一の表示機構６を直接的または間接的に利用して動作している。従って、ネイティブカメラアプリケーション９によるカメラ映像から、ノーマルカメラアプリケーション１０によるカメラ映像への切り替え時に、表示画面のちらつきが生じない。

　なお、ネイティブカメラアプリケーション９は、ノーマルカメラアプリケーション１０の実行後に、任意のタイミングで動作を終了する。任意のタイミングとしては、ノーマルカメラアプリケーション１０が動作し始めた時であってもよく、ノーマルカメラアプリケーション１０が完全に動作した時（ノーマルカメラアプリケーション１０の動作後）であってもよい。

　以上のことから、本実施の形態１によれば、ネイティブアプリケーション１３（またはネイティブカメラアプリケーション９）の機能を最小限にすることによって、コールドブート時に高速に起動することができる。また、ネイティブカメラアプリケーション９と、ノーマルカメラアプリケーション１０とで同一の機能機構１１（または表示機構６）を利用することによって、カメラ映像の引き継ぎ時に表示画像にちらつきが生じないようにすることが可能となる。

　＜実施の形態２＞
　実施の形態１では、フレームワーク７における全ての抽象化機能機構１２を動作させるために、カーネル５における全ての機能機構１１を起動させる必要がある。従って、カーネル５は、全てのドライバ、全てのハードウェアリソース、および全ての機能機構を初期化展開することになり、カーネルの初期化展開に時間を要する（図９参照）。

　本発明の実施の形態２では、ネイティブアプリケーションの動作に必要な機能機構等を先に起動することを特徴としている。その他の構成および動作は、実施の形態１と同様であるため、ここでは詳細な説明を省略する。

　図１１は、ＣＰＵ３が図３に示す各機能を有する場合における、アプリケーション実行装置の動作の一例を示す図である。

　図１１に示すように、ＣＰＵ３の電源ＯＮ後、ブートローダ１８は、カーネル５をＤＲＡＭ１７にロードする。カーネル５は、ＤＲＡＭ１７で起動する（図６，７参照）。このとき、カーネル５は、機能機構１１のうちのネイティブアプリケーション１３に必要なドライバ、ハードウェアリソース、および機能機構を初期化展開する。

　ＣＰＵ３は、ネイティブアプリケーション１３をＤＲＡＭ１７にロードし、ネイティブアプリケーション１３を起動する。ネイティブアプリケーション１３は、カーネル５の機能機構１１のうちのネイティブアプリケーション１３に必要な機能機構を直接的に利用して、予め定められた機能を実行する。

　ネイティブアプリケーション１３の実行後、カーネル５は、機能機構１１のうちのネイティブアプリケーション１３に必要ないドライバ、ハードウェアリソース、および機能機構を初期化展開する。

　その後の動作（ノーマルアプリケーション１４の起動等）については、実施の形態１と同様（図９参照）であるため説明を省略する。

　上記より、ＣＰＵ３の電源ＯＮからネイティブアプリケーション１３による動作までの時間を短縮することが可能となる。

　図１２は、ＣＰＵ３が図２に示す各機能を有する場合における、アプリケーション実行装置の動作の一例を示す図である。

　図１２に示すように、ＣＰＵ３の電源ＯＮ後、ブートローダ１８は、カーネル５をＤＲＡＭ１７にロードする。カーネル５は、ＤＲＡＭ１７で起動する（図６，７参照）。このとき、カーネル５は、機能機構１１のうちのネイティブカメラアプリケーション９に必要なドライバ、ハードウェアリソース、および表示機構６を初期化展開する。

　ＣＰＵ３は、ネイティブカメラアプリケーション９をＤＲＡＭ１７にロードし、ネイティブカメラアプリケーション９を起動する。ネイティブカメラアプリケーション９は、カーネル５の表示機構６を直接的に利用して、カメラ映像をディスプレイ４に出力する。

　ネイティブカメラアプリケーション９の実行後、カーネル５は、機能機構１１のうちのネイティブカメラアプリケーション９に必要ないドライバ、ハードウェアリソース、および機能機構（表示機構６以外の機能機構）を初期化展開する。

　その後の動作（ノーマルカメラアプリケーション１０の起動等）については、実施の形態１と同様（図１０参照）であるため説明を省略する。

　上記より、ＣＰＵ３の電源ＯＮからネイティブカメラアプリケーション９による動作までの時間を短縮することが可能となる。

　以上のことから、本実施の形態２によれば、ネイティブアプリケーション１３（またはネイティブカメラアプリケーション９）に必要な機能機構を先に起動して、ネイティブアプリケーション１３（またはネイティブカメラアプリケーション９）を実行することによって、コールドブート時に高速に起動することができる。

　なお、実施の形態１のように、ネイティブアプリケーション１３（またはネイティブカメラアプリケーション９）は、ノーマルアプリケーション１４（またはノーマルカメラアプリケーション１０）よりも容量が小さくてもよい。

　＜実施の形態３＞
　図１３，１４は、本発明の実施の形態３によるアプリケーション実行装置のソフトウェア構成の一例を示すブロック図である。なお、図１３はアプリケーション実行装置の全体の構成を示し、図１４は主にカーネル５の詳細な構成を示している。その他の構成および動作は、実施の形態１と同様であるため、ここでは詳細な説明を省略する。なお、図１３では、図２にフレーム制御機構１９を備える構成について示しているが、図３にフレーム制御機構１９を備える構成であってもよい。

　図１３に示すように、本実施の形態３によるアプリケーション実行装置は、フレーム制御機構１９を備えることを特徴としている。

　図１４に示すように、表示機構６は、ウィンドウフレーム２０～２２およびミキサ２３を有している。また、カーネル５は、ディスプレイドライバ２４を有している。

　フレーム制御機構１９は、ネイティブアプリケーションの１つであり、ウィンドウフレーム２０～２２を抽象化したものである。フレーム制御機構１９は、ネイティブアプリケーションおよびノーマルアプリケーションの各々に対してウィンドウフレーム２０～２２のいずれかを割り当てる制御を行う。

　ウィンドウフレーム２０～２２は、ネイティブアプリケーションおよびノーマルアプリケーションで構成された画面デザインである、描画ウィンドウと、当該描画ウィンドウにおけるレイヤとを格納する領域である。なお、本実施の形態３では、表示機構６が３つのウィンドウフレームを有する場合について説明するが、ウィンドウフレームは３つに限らず複数あればよい。

　ミキサ２３は、複数のアプリケーションを重ね合わせる機能を有している。ディスプレイドライバ２４は、カメラ映像をディスプレイ４に出力する機能を有している。

　図１５は、フレーム制御機構１９と表示機構６との関係を示す図である。

　フレーム制御機構１９は、ネイティブアプリケーション、またはフレームワーク７の抽象化表示機構８による、表示機構６の任意のウィンドウフレームへのアクセスを管理制御する。すなわち、特定のウィンドウフレームの用途は、フレーム制御機構１９で管理制御することが可能である。

　次に、本実施の形態３によるアプリケーション実行装置の動作について、図１６～１８を用いて説明する。なお、以下では、アプリケーション実行装置が図１３に示す構成である場合について説明する。

　図１６は、ネイティブカメラアプリケーション９が動作する場合を示している。図１６に示すように、フレーム制御機構１９は、ネイティブカメラアプリケーション９に対して、表示機構６のウィンドウフレーム２０を割り当てる。ネイティブカメラアプリケーション９が動作すると、カメラ映像は、ウィンドウフレーム２０およびミキサ２３を通り、カーネル５のディスプレイドライバ２４の駆動によってディスプレイ４に出力される。このとき、ネイティブカメラアプリケーション９は、表示機構６のどのウィンドウフレームを用いているのかを把握しなくてよい。

　図１７は、カメラ映像をディスプレイ４に出力する機能を有しない（ノーマルカメラアプリケーション１０以外の）任意のノーマルアプリケーションが動作する場合を示している。図１７に示すように、フレーム制御機構１９は、フレームワーク７の抽象化表示機構８に対して、表示機構６のウィンドウフレーム２２を割り当てる。ノーマルアプリケーションが動作すると、当該ノーマルアプリケーションで描画された画像は、ウィンドウフレーム２２およびミキサ２３を通り、カーネル５のディスプレイドライバ２４の駆動によってディスプレイ４に出力される。このとき、フレームワーク７の抽象化表示機構８は、表示機構６のどのウィンドウフレームを用いているのかを把握しなくてよい。

　図１６および図１７が同時に実行されている場合において、ウィンドウフレーム２０にはネイティブカメラアプリケーション９の動作によるカメラ映像が入力され、ウィンドウフレーム２２にはノーマルカメラアプリケーション１０以外の任意のノーマルアプリケーションの動作による画像が入力される。

　表示機構６のミキサ２３は、ネイティブカメラアプリケーション９の動作によるカメラ映像のみをディスプレイ４に出力するか、任意のノーマルアプリケーションの動作による画像のみをディスプレイ４に出力するか、ネイティブカメラアプリケーション９の動作によるカメラ映像および任意のノーマルアプリケーションの動作による画像を重ね合わせてディスプレイ４に出力するかのいずれかを行う。このように、ネイティブカメラアプリケーション９の動作によるカメラ映像と、任意のノーマルアプリケーションの動作による画像との出力を切り替える、または重畳することが可能となる。

　図１８は、ノーマルカメラアプリケーション１０が動作する場合を示している。図１８に示すように、フレーム制御機構１９は、ノーマルカメラアプリケーション１０に対して、フレームワーク７の抽象化表示機構８を介して表示機構６のウィンドウフレーム２０を割り当てる。ノーマルカメラアプリケーション１０が動作すると、カメラ映像は、ウィンドウフレーム２０およびミキサ２３を通り、カーネル５のディスプレイドライバ２４の駆動によってディスプレイ４に出力される。

　上記より、フレーム制御機構１９は、フレーム制御機構１９の上位の状態であるネイティブカメラアプリケーション９およびノーマルカメラアプリケーション１０に関わらず、ハードウェアリソースに従ってウィンドウフレームを制御する。図１６，１８の例では、ネイティブカメラアプリケーション９およびノーマルカメラアプリケーション１０においてハードウェアリソースであるカメラ映像が共通であるため、同一のウィンドウフレーム２０が割り当てられる。

　実施の形態１（図１０参照）で説明したように、ネイティブカメラアプリケーション９からノーマルカメラアプリケーション１０に切り替える（カメラ映像を引き継ぐ）際は、フレーム制御機構１９の制御によってウィンドウフレーム２０を用いてカメラ映像を出力し続けているため、切り替え時の表示画像のちらつき（カメラ映像の乱れ）は発生しない。

　図１９は、図１６，１８に示す動作をまとめたシーケンス図である。

　図１９に示すように、カーネル５が起動すると、ディスプレイドライバ２４、表示機構６、フレーム制御機構１９は初期化処理を行う。フレーム制御機構１９は、初期化処理中に、表示機構６からウィンドウリストを取得する。

　フレーム制御機構１９の初期化処理が完了すると、ネイティブカメラアプリケーション９は、フレーム制御機構１９からウィンドウ情報を取得した後、ウィンドウ１を獲得する。このとき、表示機構６は、メモリからフレームバッファを獲得する。これにより、ネイティブカメラアプリケーション９の動作によって、カメラ映像がキャプチャされる。なお、ウィンドウ１は、図１６の例ではウィンドウフレーム２０に対応する。また、メモリは、例えば図４のＤＲＡＭ１７に対応する。また、カメラ映像のキャプチャは、例えば図１のキャプチャ２が行う。

　カーネル５が動作状態になると、抽象化表示機構８は、初期化処理中に、フレーム制御機構１９からウィンドウ情報を取得する。抽象化表示機構８の初期化処理が完了すると、ノーマルカメラアプリケーション１０は、抽象化表示機構８からウィンドウ情報を取得した後、ネイティブカメラアプリケーション９に対して停止要求を行う。その後、ノーマルカメラアプリケーション１０は、抽象化表示機構８からウィンドウ１を獲得する。

　ノーマルカメラアプリケーション１０は、表示機構６からウィンドウ２を獲得し、当該ウィンドウ２を用いてガイド線等の描画を行う。なお、ウィンドウ２は、例えばウィンドウフレーム２２（図１７参照）であってもよい。

　上記より、ネイティブカメラアプリケーション９からノーマルカメラアプリケーション１０への切り替えが行われる（すなわち、カメラ映像の引き継ぎが行われる。）。このとき、ネイティブカメラアプリケーション９とノーマルカメラアプリケーション１０とは共通のウィンドウ１を利用しているため、カメラ画像でのちらつきが生じない。

　図２０は、従来のノーマルカメラアプリケーションのみを動作させた場合の一例を示す図である。図２０に示すように、ノーマルカメラアプリケーションは、図１９に示すようなネイティブカメラアプリケーションと共通のウィンドウを用いるカメラ映像の引き継ぎを行わない。従って、従来では、ノーマルカメラアプリケーションの動作によるカメラ映像への引き継ぎ時にちらつきが生じる。

　以上のことから、本実施の形態３によれば、ネイティブカメラアプリケーション９およびノーマルカメラアプリケーション１０に対して同一のウィンドウフレームを割り当てることによって、カメラ映像の引き継ぎ時に表示画像にちらつきが生じないようにすることが可能となる。

　なお、実施の形態１のように、ネイティブカメラアプリケーション９は、ノーマルカメラアプリケーション１０よりも容量が小さくてもよい。

　また、実施の形態２のように、ネイティブカメラアプリケーション９に必要な機能機構（表示機構６）を先に起動して、ネイティブカメラアプリケーション９を実行するようにしてもよい。

　なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。

　本発明は詳細に説明されたが、上記した説明は、すべての態様において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。

　１　カメラ、２　キャプチャ、３　ＣＰＵ、４　ディスプレイ、５　カーネル、６　表示機構、７　フレームワーク、８　抽象化表示機構、９　ネイティブカメラアプリケーション、１０　ノーマルカメラアプリケーション、１１　機能機構、１２　抽象化機能機構、１３　ネイティブアプリケーション、１４　ノーマルアプリケーション、１５　ＮＯＲ型フラッシュメモリ、１６　ｅＭＭＣ、１７　ＤＲＡＭ、１８　ブートローダ、１９　フレーム制御機構、２０，２１，２２　ウィンドウフレーム、２３　ミキサ、２４　ディスプレイドライバ、２５　カメラ、２６　キャプチャ、２７　グラフィック、２８　ＣＰＵ、２９　スイッチ、３０　ディスプレイ、３１　ＯＳ、３２　表示機構、３３　アプリケーション、３４　ＯＳ、３５　表示機構、３６　アプリケーション。

Claims

　予め定められた機能機構を有するカーネルと、
　前記カーネルにより起動され、前記機能機構を抽象化した抽象化機能機構を有するフレームワークと、
　前記機能機構を直接的に利用して動作する第１のアプリケーションと、
　前記抽象化機能機構を介して前記機能機構を間接的に利用して動作し、前記第１のアプリケーションの機能を有する第２のアプリケーションと、
を備え、
　前記第１のアプリケーションは、前記第２のアプリケーションよりも容量が小さいことを特徴とする、アプリケーション実行装置。
　前記機能機構は複数存在し、
　前記カーネルは、前記第１のアプリケーションの動作に必要な前記機能機構のみを起動した後、前記第１のアプリケーションの動作に必要ない他の前記機能機構を起動することを特徴とする、請求項１に記載のアプリケーション実行装置。
　前記機能機構は、表示機構を含むことを特徴とする、請求項１に記載のアプリケーション実行装置。
　前記表示機構に含まれる複数のウィンドウフレームを制御するフレーム制御機構をさらに備え、
　前記フレーム制御機構は、前記第１のアプリケーションおよび前記第２のアプリケーションの各々の動作時に、同一の前記ウィンドウフレームを割り当てるように制御することを特徴とする、請求項３に記載のアプリケーション実行装置。
　前記第１のアプリケーションは、前記第２のアプリケーションの実行後に動作を終了することを特徴とする、請求項１に記載のアプリケーション実行装置。
　前記カーネルは、Ｌｉｎｕｘカーネルであることを特徴とする、請求項１に記載のアプリケーション実行装置。
　前記フレームワークは、ＡｎｄｒｏｉｄＯＳであることを特徴とする、請求項１に記載のアプリケーション実行装置。
　前記表示機構は、ＡｎｄｒｏｉｄＯＳのＳｕｒｆａｃｅＦｌｉｎｇｅｒおよびＨａｒｄｗａｒｅＣｏｍｐｏｓｅｒであることを特徴とする、請求項３に記載のアプリケーション実行装置。
　少なくともカーネルおよびフレームワークの順に起動して第１のアプリケーションおよび第２のアプリケーションを実行するアプリケーション実行方法であって、
　前記カーネルは、予め定められた機能機構を有し、
　前記フレームワークは、前記カーネルにより起動され、前記機能機構を抽象化した抽象化機能機構を有し、
　前記第１のアプリケーションは、前記機能機構を直接的に利用して動作し、
　前記第２のアプリケーションは、前記抽象化機能機構を介して前記機能機構を間接的に利用して動作し、前記第１のアプリケーションの機能を有し、
　前記第１のアプリケーションは、前記第２のアプリケーションよりも容量が小さいことを特徴とする、アプリケーション実行方法。