DE112015006860T5

DE112015006860T5 - Applikationsausführungsvorrichtung und Applikationsausführungsverfahren

Info

Publication number: DE112015006860T5
Application number: DE112015006860.0T
Authority: DE
Inventors: Tatsuya Mitsugi
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2015-08-31
Filing date: 2015-08-31
Publication date: 2018-05-17
Also published as: JP6272579B2; CN107924316A; WO2017037818A1; JPWO2017037818A1; US20180293079A1; US10613874B2

Abstract

Eine Aufgabe der vorliegenden Erfindung ist es, eine Applikationsausführungsvorrichtung und ein Applikationsausführungsverfahren bereitzustellen, die einen raschen Startup bei kaltem Booten ermöglichen, und die das Auftreten eines Flackerns in einem Anzeigebild zum Zeitpunkt der Kamerabildübergabe verhindern können. Die Applikationsausführungsvorrichtung gemäß der vorliegenden Erfindung beinhaltet einen Kernel, der einen vorbestimmten Funktionsmechanismus enthält, ein Framework, das vom Kernel gestartet wird, und das einen abstrahierten Funktionsmechanismus enthält, der durch Abstrahieren des Funktionsmechanismus erhalten wird, eine erste Applikation, die durch direkte Verwendung des Funktionsmechanismus arbeitet und eine zweite Applikation, die durch indirektes Verwenden des Funktionsmechanismus über den abstrahierten Funktionsmechanismus arbeitet, und welche eine Funktion der ersten Applikation beinhaltet, enthält, wobei der Funktionsmechanismus einen Funktionsmechanismus beinhaltet, der für den Betrieb der ersten Applikation erforderlich ist und einen anderen Funktionsmechanismus, welcher für den Betrieb der ersten Applikation nicht erforderlich ist, und wobei der Kernel nur den Funktionsmechanismus startet, der für den Betrieb der ersten Applikation erforderlich ist, und dann einen anderen Funktionsmechanismus startet, der für den Betrieb der ersten Applikation nicht erforderlich ist.

Description

Technisches Gebiet
Die vorliegende Erfindung bezieht sich auf eine Applikationsausführungsvorrichtung und ein Applikationsausführungsverfahren zum Ausführen einer Applikation.
Hintergrund
Es gibt eine Technik zum Montieren, an einem Fahrzeug, einer Kamera zum Aufnehmen der Rückseite und von Anzeigen eines Videos (nachfolgend als ein Kamerabild bezeichnet), welches durch die Kamera aufgenommen ist, auf einer Anzeige zum Zeitpunkt eines Rückwärtsstarts. Die Technik erfordert, dass das Kamerabild zum Zeitpunkt des Rückwärtsstarts rasch auf der Anzeige angezeigt wird.
Beispielsweise wird ein Kamerabild, welches durch andere Hardware als eine Zentraleinheit (CPU) mit einem fortschrittlichen Betriebssystem (BS) prozessiert ist, an einer Anzeige ausgegeben, oder ein Kamerabild wird an die Anzeige durch eine Bootladerfunktion der CPU, die das fortschrittliche BS aufweist, ausgegeben, und dann wird das Kamerabild an die Anzeige ausgegeben, nach Überlagerung einer Führungslinie durch die andere Hardware als die CPU oder einer Kamera-Applikation des fortschrittlichen BS. Auf diese Weise wird Videoübergabe zuerst des Anzeigens eines Kamerabildes und dann Anzeigen eines Kamerabildes, auf welchem eine Führungslinie überlagert ist, durchgeführt. Hier ist ein fortschrittliches BS ein BS, das Informationsverarbeitung auf hohem Niveau durchführt, und es kann beispielsweise ein Linux (registrierte Marke) BS, ein AndroidOS und dergleichen angeführt werden.
Konventioneller Weise wird eine Fahrzeug-Rücküberwachungs-Vorrichtung offenbart, die eine an einem Heckbereich eines Fahrzeugs installierte Kamera, eine Bildverarbeitungsschaltung zum Verarbeiten eines Videosignals und zum Ausgeben des Signals an ein Bildanzeigemittel, und Bestimmungsmittel zum Bestimmen, ob eine Verarbeitung (Prozess des Überlagerns einer Führungslinie auf ein Bild) durch die Bildverarbeitungsschaltung durchgeführt werden kann, in Koordination mit der Eingabebetätigung des Rückwärtsgangs enthält, wobei ein Prozess des Überlagerns einer Führungslinie auf ein Kamerabild in einem Fall nicht durchgeführt wird, bei dem eine Führungslinie nicht notwendig ist, und ein Prozess des Überlagerns einer Führungslinie auf ein Kamerabild in einem Fall durchgeführt wird, bei dem eine Führungslinie notwendig ist (siehe beispielsweise Patentdokument 1).
Auch wird eine Anzeigevorrichtung für ein Fahrzeug offenbart, wobei die Anzeigevorrichtung ein Startbestimmungsmittel zum Bestimmen, ob ein Starten/Herauffahren einer Haupt-CPU abgeschlossen ist oder nicht, und ein Anzeigesteuermittel zum Veranlassen, in einem Fall, bei dem das StartBestimmungsmittel feststellt, dass der Start der Haupt-CPU nicht abgeschlossen ist, eines durch eine Bildaufnahmevorrichtung erhaltenen Bilds durch eine Anzeige-CPU ohne Verwendung der Haupt-CPU zu veranlassen, auf einer Fahrzeuganzeigegerätschaft angezeigt zu werden (siehe beispielsweise Patentdokument 2).
Weiterhin wird eine elektronische Gerätschaft offenbart, die eine erste Anweisungseinheit zum Erteilen einer Anweisung für normales Starten einer elektronischen Gerätschaft, eine zweite Anweisungseinheit zum Erteilen einer Anweisung für zeitweiliges Starten der elektronischen Gerätschaft, eine erste Arithmetik-Verarbeitungseinheit und eine zweite Arithmetik-Verarbeitungseinheit beinhaltet, wobei in einem Fall, bei dem eine Anweisung durch die erste Anweisungseinheit erteilt wird, die erste Arithmetik-Verarbeitungseinheit ein erstes Betriebssystem ausführt und die Verarbeitung einer ersten Anwenderschnittstelle ausführt, wenn das Starten des ersten Betriebssystems abgeschlossen ist, und in einem Fall, bei dem eine Anweisung durch die zweite Anweisungseinheit erteilt wird, die erste arithmetische Verarbeitungseinheit das erste Betriebssystem oder die erste Anwenderschnittstelle nicht ausführt, und wobei die zweite arithmetische Verarbeitungseinheit ein zweites Betriebssystem ausführt, das in einer kürzeren Zeit als das erste Betriebssystem gestartet wird, und in einem Fall, bei dem eine Anweisung durch die erste Anweisungseinheit erteilt wird, die zweite arithmetische Verarbeitungseinheit die Verarbeitung einer zweiten Anwenderschnittstelle ausführt, wenn das Starten des zweiten Betriebssystems abgeschlossen ist und die Ausführung der Verarbeitung der zweiten Anwenderschnittstelle unterdrückt, wenn das Starten des ersten Betriebssystems abgeschlossen ist (siehe beispielsweise Patentdokument 3).
Dokumente des Stands der Technik
Patentdokumente

Patentdokument 1: Japanisches Patent Nr. 4498771 (B2
Patentdokument 2: Japanisches Patent Nr. 4978558 (B2)
Patentdokument 3: Japanisches Patent Nr. 5028904 (B2)

Zusammenfassung der Erfindung
Durch die Erfindung zu lösende Probleme
Wie oben beschrieben, wenn ein Kamerabild auf einer Anzeige zum Zeitpunkt eines Fahrzeugs, das rückwärts anfährt, angezeigt wird, ist es erforderlich, dass das Kamerabild rasch auf der Anzeige angezeigt wird (beispielsweise innerhalb von zwei Sekunden nach Einschalten des Stroms). Das heißt, eine Applikation zum Anzeigen eines Kamerabilds (nachfolgend als eine Kamera-Applikation bezeichnet) so rasch als möglich zu starten, wird ein wichtiges Problem. Insbesondere erfordert das Starten bei kaltem Booten Zeit und das Starten bei kaltem Booten ist schnell zu machen.
Im Patentdokument 1 wird bestimmt, ob eine Verarbeitung durch einen Graphik-LSI möglich ist, wenn der Rückwärtsgang EIN ist, und falls eine Verarbeitung durch den Graphik-LSI als nicht möglich festgestellt wird, wird ein Umschalten durch Schaltmittel durchgeführt, um einen Zustand zu erzielen, bei dem ein Videosignal einer Kamera direkt an einem LCD-Paneel eingegeben wird, ohne Verwendung des Graphik-LSI. Entsprechend ist Hardware zum Überlagern einer Führungslinie auf ein Kamerabild notwendig, was zu einem Anstieg bei den Kosten führt. Auch, weil die Laufroute eines Kamerabilds durch das Schaltmittel umgeschaltet wird, wird im Anzeigebild zum Zeitpunkt der Kamerabildübergabe ein Flackern verursacht.
Im Patentdokument 2, weil das Umschalten zwischen der Haupt-CPU und der Anzeigen-CPU durchgeführt wird, sind die Laufrouten von Kamerabildern unterschiedlich. Entsprechend wird ein Flackern in einem Anzeigebild zum Zeitpunkt der Kamerabildübergabe verursacht. Auch ist eine Hardware zum Überlagern einer Führungslinie auf ein Kamerabild notwendig, was zu einem Anstieg bei den Kosten führt.
In Patentdokument 3 wird ein Umschalten zwischen dem ersten Betriebssystem und dem zweiten Betriebssystem durchgeführt und somit wird ein Flackern im Anzeigebild zum Zeitpunkt des Umschaltens (zur Zeit einer Kamerabildübergabe) verursacht.
Im Falle der Ausgabe eines Kamerabilds an eine Anzeige durch eine Boot-Lader-Funktion einer CPU, die ein fortschrittliches BS aufweist, wird ein Flackern beim Anzeigebild zum Zeitpunkt der Kamerabildübergabe verursacht.
Wie oben beschrieben, gibt es konventioneller Weise ein Problem, dass ein Flackern in einem Anzeigebild zum Zeitpunkt der Kamerabildübergabe verursacht wird. Daher ist es wünschenswert, dass der Start bei hoher Geschwindigkeit bei kaltem Booten durchgeführt wird und das Auftreten von Flackern in einem Anzeigebild zum Zeitpunkt der Kamerabildübergabe wird wünschenswerter Weise verhindert.
Die vorliegende Erfindung ist gemacht worden, um die oben beschriebenen Probleme zu lösen und hat als Aufgabe, eine Applikations-Ausführvorrichtung und ein Applikations-Ausführverfahren bereitzustellen, die ein rasches Starten beim einem kalten Booten ermöglichen, und die das Auftreten von Flackern in einem Anzeigebild zum Zeitpunkt der Kamerabildübergabe verhindern können.
Mittel zum Lösen der Probleme
Um die oben beschriebenen Probleme zu lösen, beinhaltet eine Applikationsausführungsvorrichtung gemäß der vorliegenden Erfindung einen „Kernel“, der einen vorbestimmten Funktionsmechanismus enthält, ein „Framework“ (Rahmenwerk), welches durch den Kernel gestartet wird und das einen abstrahierten Funktionsmechanismus enthält, der durch Abstrahieren des Funktionsmechanismus erhalten wird, eine erste Applikation, die arbeitet, indem sie direkt den Funktionsmechanismus verwendet, und eine zweite Applikation, die indirekt arbeitet, indem sie den Funktionsmechanismus durch den abstrahierten Funktionsmechanismus verwendet, und die eine Funktion der ersten Applikation enthält, wobei der Funktionsmechanismus einen Funktionsmechanismus, der zum Betrieb der ersten Applikation erforderlich ist und einen anderen Funktionsmechanismus, der zum Betrieb der ersten Applikation nicht erforderlich ist, beinhaltet, und wobei der Kernel nur den Funktionsmechanismus startet, der für den Betrieb der ersten Applikation erforderlich ist und dann einen anderen Funktionsmechanismus startet, der für den Betrieb der ersten Applikation nicht erforderlich ist.
Auch ist ein Applikationsausführungsverfahren gemäß der vorliegenden Erfindung ein Applikationsausführungsverfahren zum sequentiellen Starten zumindest eines Kernels und eines Frameworks und zum Ausführen einer ersten Applikation und einer zweiten Applikation, wobei der Kernel einen vorbestimmten Funktionsmechanismus beinhaltet, wobei das Framework durch den Kernel gestartet wird, und einen abstrahierten Funktionsmechanismus beinhaltet, der durch Abstrahieren des Funktionsmechanismus erhalten wird, wobei die erste Applikation durch direktes Verwenden des Funktionsmechanismus arbeitet, wobei die zweite Applikation durch indirektes Verwenden des Funktionsmechanismus durch den abstrahierten Funktionsmechanismus arbeitet und eine Funktion der ersten Applikation beinhaltet, wobei der Funktionsmechanismus einen Funktionsmechanismus beinhaltet, der für den Betrieb der ersten Applikation erforderlich ist und einen anderen Funktionsmechanismus, der für den Betrieb der ersten Applikation nicht erforderlich ist, und wobei der Kernel nur den Funktionsmechanismus startet, der für den Betrieb der ersten Applikation erforderlich ist, und dann einen anderen Funktionsmechanismus startet, welcher für den Betrieb der ersten Applikation nicht erforderlich ist.
Effekte der Erfindung
Gemäß der vorliegenden Erfindung beinhaltet die Applikationsausführungsvorrichtung einen Kernel, der einen vorbestimmten Funktionsmechanismus beinhaltet, ein Framework, das durch den Kernel gestartet wird und das einen abstrahierten Funktionsmechanismus enthält, der durch Abstrahieren des Funktionsmechanismus erhalten wird, eine erste Applikation, die arbeitet, indem sie direkt den Funktionsmechanismus verwendet, und eine zweite Applikation, die arbeitet, indem sie den Funktionsmechanismus durch den abstrahierten Funktionsmechanismus indirekt verwendet, und die eine Funktion der ersten Applikation enthält, wobei der Funktionsmechanismus mehrfach existiert, und wobei der Kernel nur den Funktionsmechanismus startet, der für den Betrieb der ersten Applikation erforderlich ist, und dann einen anderen Funktionsmechanismus startet, der für den Betrieb der ersten Applikation nicht erforderlich ist, und somit kann ein rasches Starten bei kalten Booten durchgeführt werden und auch kann das Auftreten von Flackern in einem Anzeigebild zum Zeitpunkt der Kamerabildübergabe verhindert werden.
Auch ist das Applikationsausführungsverfahren ein Applikationsausführungsverfahren zum sequentiellen Starten zumindest eines Kernels und eines Frameworks und zum Ausführen einer ersten Applikation und einer zweiten Applikation, wobei der Kernel einen vorbestimmten Funktionsmechanismus beinhaltet, wobei das Framework durch den Kernel gestartet wird, und einen abstrahierten Funktionsmechanismus beinhaltet, der durch Abstrahieren des Funktionsmechanismus erhalten wird, wobei die erste Applikation durch direktes Verwenden des Funktionsmechanismus arbeitet, wobei die zweite Applikation durch indirektes Verwenden des Funktionsmechanismus über den abstrahierten Funktionsmechanismus arbeitet, und eine Funktion der ersten Applikation beinhaltet, wobei der Funktionsmechanismus mehrfach existiert, und wobei der Kernel nur den Funktionsmechanismus startet, der zum Betrieb der ersten Applikation erforderlich ist und dann einen anderen Funktionsmechanismus startet, der für den Betrieb der ersten Applikation nicht erforderlich ist, und somit kann ein rasches Starten bei kaltem Booten durchgeführt werden und kann auch das Auftreten von Flackern in einem Anzeigebild zum Zeitpunkt der Kamerabildübergabe verhindert werden.
Die Aufgaben, Merkmale, Aspekte und Vorteile der vorliegenden Erfindung werden aus der nachfolgenden detaillierten Beschreibung und den anhängigen Zeichnungen ersichtlicher werden.
Figurenliste

1 ist ein Blockdiagramm, das ein Beispiel einer Hardware-Konfiguration einer Applikationsausführungsvorrichtung gemäß einer ersten Ausführungsform der vorliegenden Erfindung zeigt.
2 ist ein Blockdiagramm, das ein Beispiel einer Software-Konfiguration der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
3 ist ein Blockdiagramm, das ein Beispiel der Software-Konfiguration der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
4 ist ein Blockdiagramm, das ein Beispiel der Hardware-Konfiguration der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
5 ist ein Diagramm, das ein Beispiel einer Reihenfolge des Startens der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
6 ist ein Diagramm, das ein Beispiel eines Betriebs der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
7 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
8 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
9 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
10 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform der vorliegenden Erfindung zeigt.
11 ist ein Diagramm, das ein Beispiel des Betriebs einer Applikationsausführungsvorrichtung gemäß einer zweiten Ausführungsform der vorliegenden Erfindung zeigt.
12 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der zweiten Ausführungsform der vorliegenden Erfindung zeigt.
13 ist ein Blockdiagramm, das ein Beispiel einer Software-Konfiguration einer Applikationsausführungsvorrichtung gemäß einer dritten Ausführungsform der vorliegenden Erfindung zeigt.
14 ist ein Blockdiagramm, das ein Beispiel einer Software-Konfiguration einer Applikationsausführungsvorrichtung gemäß der dritten Ausführungsform der vorliegenden Erfindung zeigt.
15 ist ein Diagramm, welches eine Beziehung zwischen einem Rahmensteuermechanismus und einem Anzeigemechanismus gemäß der dritten Ausführungsform der vorliegenden Erfindung zeigt.
16 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der dritten Ausführungsform der vorliegenden Erfindung zeigt.
17 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der dritten Ausführungsform der vorliegenden Erfindung zeigt.
18 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der dritten Ausführungsform der vorliegenden Erfindung zeigt.
19 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung gemäß der dritten Ausführungsform der vorliegenden Erfindung zeigt.
20 ist ein Diagramm, das ein Beispiel eines Falls zeigt, bei dem nur eine konventionelle, normale Kamera-Applikation betrieben Wird.
21 ist ein Blockdiagramm, da ein Beispiel einer Hardware-Konfiguration gemäß einer konventionellen Technik zeigt.
22 ist ein Blockdiagramm, das ein Beispiel einer Software-Konfiguration gemäß einer konventionellen Technik zeigt.

Beschreibung von Ausführungsformen
Ausführungsformen der vorliegenden Erfindung werden unten unter Bezugnahme auf die Zeichnungen beschrieben.
Erste Ausführungsform
Zuerst wird eine Konfiguration einer Applikationsausführungsvorrichtung gemäß einer ersten Ausführungsform der vorliegenden Erfindung beschrieben.
1 ist ein Blockdiagramm, das ein Beispiel einer Hardware-Konfiguration der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform zeigt. Zusätzlich zeigt 1 ein Beispiel einer Hardware-Konfiguration einer Applikationsausführungsvorrichtung, die eine Applikation ausführt, um zu veranlassen, dass eigentlich ein in der Kamera 1 aufgenommenes Kamerabild auf einer Anzeige 4 angezeigt wird.
Wie in 1 gezeigt, wird ein durch die Kamera 1 aufgenommenes Kamerabild durch einen Aufnehmer 2 in ein für eine CPU 3 geeignetes Format umgewandelt. Das durch den Aufnehmer 2 umgewandelte Kamerabild wird an die Anzeige 4 nach Hinzufügen von Zeicheninformation wie etwa einer Führungslinie durch die CPU 3 ausgegeben. Die CPU 3 schaltet zwischen einem Kamerabild und einem Kamerabild um, zu welchem Zeicheninformation, wie etwa eine Führungslinie, hinzugefügt ist. Die Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform wird durch Betrieb der CPU 3 realisiert.
Die in 1 gezeigte Hardware-Konfiguration ist die gleiche wie eine Hardware-Konfiguration zum Ausgeben eines normalen Kamerabilds an einer Anzeige (Hardware-Konfiguration, die ein rasches Starten nicht erfordert), und beinhaltet keine getrennte Hardware zum Durchführen eines raschen Startens. In der ersten Ausführungsform wird das rasche Starten durch die in 1 gezeigte Hardware-Konfiguration realisiert.
21 ist ein Blockdiagramm, welches ein Beispiel einer Hardware-Konfiguration gemäß einer konventionellen Technik zeigt. Zusätzlich zeigt 21 schematisch eine Hardware-Konfiguration gemäß den Patentdokumenten 1 und 2.
Wie in 21 gezeigt, bevor eine CPU 28 gestartet wird, wird ein durch eine Kamera 25 aufgenommenes Kamerabild an einer Anzeige 30 über einen Pfad eines Aufnehmers 26, einer Graphik 27, eines Schalters 29 und der Anzeige 30 ausgegeben. Zu dieser Zeit wird ein durch die Kamera 25 aufgenommenes Kamerabild auf der Anzeige 30 angezeigt.
Weiterhin, wenn die CPU 28 gestartet wird, wird ein durch die Kamera 25 aufgenommenes Kamerabild an die Anzeige 30 über einen Pfad des Aufnehmers 26, der Graphik 27, der CPU 28 und des Schalters 29 ausgegeben. Zu dieser Zeit wird ein Kamerabild, das einem Führungslinien-Überlagerungsprozess durch die CPU 28 unterworfen ist, auf der Anzeige 30 angezeigt.
Wie oben beschrieben, wird gemäß der in 21 gezeigten konventionellen Technik der Laufpfad eines Kamerabildes durch den Schalter 29 umgeschaltet und somit wird zum Zeitpunkt der Kamerabildübergabe ein Flackern verursacht.
2 ist ein Blockdiagramm, das ein Beispiel einer Software-Konfiguration der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform zeigt. Zusätzlich zeigt 2 eine Software-Konfiguration, welche durch die CPU 3 in 1 durchgeführt wird.
Wie in 2 gezeigt, weist die CPU 3 Funktionen des Ausführens eines Kernel 5, eines Framework 7, einer nativen Kamera-Applikation 9 und einer normalen Kamera-Applikation 10 auf.
Der Kernel 5 beinhaltet einen Anzeigemechanismus 6, der eine Funktion zum Durchführen der Anzeige auf der Anzeige 4 ist. Auch beinhaltet der Kernel 6 einen Treiber zum Durchführen der Anzeige auf der Anzeige 4 (im Beispiel von 2 ein Anzeigentreiber und ein Aufnehmertreiber), und eine Hardware-Ressource (im Beispiel in 2 eine Vorrichtung, die an der CPU 3 vorgesehen ist und die mit der Anzeige 4 verbunden ist). Der Anzeigemechanismus 6 ist auf einem oberen Niveau des Treibers. Zusätzlich beschreibt die erste Ausführungsform den Kernel 5, ein Linux-Kernel zu sein, aber dies ist nicht beschränkend. Auch kann der Anzeigemechanismus 6 SurfaceFlinger und Hardware Composer von AndroidOS sein.
Das Framework 7 beinhaltet einen abstrahierten Anzeigemechanismus 8, der durch Abstrahieren des Anzeigemechanismus 6 erhalten wird, den Treiber und die Hardware-Ressource, die dem Kernel bereitgestellt wird.
Die native Kamera-Applikation 9 ist eine Applikation zum Anzeigen eines Kamerabilds auf der Anzeige 4 und arbeitet durch direkte Verwendung des Anzeigemechanismus 6. Darüber hinaus beinhaltet die native Kamera-Applikation 9 nur eine Basisfunktion des Ausgebens oder Nichtausgebens eines Kamerabildes und beinhaltet nicht eine Funktion zum Überlagern einer Führungslinie auf einem Kamerabild. Das heißt, dass die native Kamera-Applikation 9 eine spezifische Funktion aus Funktionen der später beschriebenen normalen Applikation 10 beinhaltet.
Die normale Kamera-Applikation 10 ist eine Applikation zum Anzeigen eines Kamerabildes auf der Anzeige 4 und arbeitet durch indirekte Verwendung des Anzeigemechanismus 6 über den abstrahierten Anzeigemechanismus 8. Darüber hinaus beinhaltet die normale Kamera-Applikation 10 eine komplexe Funktion, wie etwa eine Funktion zum Überlagern einer Führungslinie auf ein Kamerabild.
3 ist ein Blockdiagramm, das ein Beispiel der Software-Konfiguration der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform zeigt. Zusätzlich ist die Software-Konfiguration, die in 3 gezeigt ist, die in 2 gezeigte Software-Konfiguration nach Generalisierung.
Wie in 3 gezeigt, beinhaltet der Kernel 5 einen Funktionsmechanismus 11, der den Anzeigemechanismus 6 in 2 enthält. Auch beinhaltet der Kernel 5 Treiber und Hardware-Ressourcen in einer Peripheriegruppe, einschließlich des Treibers und der Hardware-Ressource, die unter Bezugnahme auf 2 beschrieben sind.
Das Framework 7 beinhaltet einen abstrahierten Funktionsmechanismus 12, der durch Abstrahieren des Funktionsmechanismus 11, des Treibers und der Hardware-Ressource erhalten wird.
Eine native Applikation 13 (erste Applikation) arbeitet unter direkter Verwendung des Funktionsmechanismus 11. Auch weist eine normale Applikation 14 (zweite Applikation) die Funktion der nativen Applikation 13 auf und arbeitet durch indirekte Verwendung des Funktionsmechanismus 11 über den abstrahierten Funktionsmechanismus 12. Die native Applikation 13 beinhaltet eine spezifische Funktion aus Funktionen der normalen Applikation 14.
22 ist ein Blockdiagramm, das ein Beispiel einer Software-Konfiguration gemäß einer konventionellen Technik zeigt. Zusätzlich zeigt 22 schematisch eine Software-Konfiguration gemäß Patentdokument 3.
Wie in 22 gezeigt, beinhaltet ein BS 31 einen Anzeigemechanismus 32 und eine Applikation 33 arbeitet unter Verwendung des Anzeigemechanismus 32. Auch beinhaltet ein BS 34 einen Anzeigemechanismus 35 und eine Applikation 36 arbeitet unter Verwendung des Anzeigemechanismus 35. Zusätzlich sind die Applikationen 33, 36 Applikationen, um zu veranlassen, dass ein Video auf einer Anzeige angezeigt wird.
Gemäß der in 22 gezeigten konventionellen Technik, weil das BS 31, 34 sich für jede Applikation 33, 36 unterscheidet, ist das BS 31, 34 zum Zeitpunkt des Umschaltens der Applikation 33, 36 umzuschalten. Zu dieser Zeit, weil der Anzeigemechanismus 32, 35 für jede Applikation 33, 36 unterschiedlich ist, wird ein Flackern im Video zum Zeitpunkt des Umschaltens der Applikation 33, 35 verursacht.
4 ist ein Blockdiagramm, das ein Beispiel der Hardware-Konfiguration der Applikationsausführungsvorrichtung gemäß der ersten Ausführungsform zeigt. Zusätzlich zeigt 4 eine Hardware-Konfiguration der CPU 3 in 1 und ihre Peripherie.
Wie in 4 gezeigt, sind ein NOR-Flash-Speicher 15, eine embedded Multi Media Card (eMMC) 16, und ein Direkt-Zugriffspeicher (DRAM) 17 mit der CPU 3 verbunden. Zusätzlich sind der NOR-Flash-Speicher 15, die eMMC 16 und das DRAM 17 in 1 weggelassen.
Der NOR-Flash-Speicher 15 speichert einen Bootlader 18. Zusätzlich ist es ausreichend, falls der NOR-Flash-Speicher 15 eine kleine Speicherkapazität aufweist und der NOR-Flash-Speicher 15 kann beispielsweise Nurlesespeicher (ROM) oder dergleichen sein.
Die eMMC 16 speichert den Kernel 5, das Framework 7 und Applikationen (nicht gezeigt) einschließlich der nativen Kamera-Applikation 9 und der normalen Kamera-Applikation 10. Zusätzlich ist es ausreichend, falls die eMMC 16 ein Speicher großer Kapazität ist, und die eMMC 16 kann beispielsweise eine Festplatte oder dergleichen sein.
Die CPU 3 lädt zumindest eines von Kernel 5, Framework 7 und Bootlader 18 in das DRAM 17, um zu arbeiten. Zusätzlich sind die native Kamera-Applikation 9 und die normale Kamera-Applikation in 2, und die native Kamera-Applikation 13 und die normale Applikation 14 in 3 in der eMMC 16 gespeichert.
Als Nächstes wird der Gesamtbetrieb der Applikationsausführungsvorrichtung unter Bezugnahme auf 5 bis 8 beschrieben.
Wie in 5 gezeigt, arbeitet die Applikationsausführungsvorrichtung durch sequentielles Starten des Bootladers 18, des Kernel 5 und des Framework 7. Nachfolgend werden Details des Start des Bootladers 18, des Kernel 5 und des Framework 7 angegeben.
Wie in 6 gezeigt, lädt die CPU 3 in den NOR-Flash-Speicher 15 gespeicherten Bootlader 18 in das RAM 17 unter Verwendung eines in den NOR-Flash-Speicher 15 gespeicherten Programms. Der geladene Bootlader 18 arbeitet durch Starten am DRAM 17. Hier weist das in dem NOR-Flash-Speicher 15 gespeicherte Programm eine Funktion zum Laden des Bootladers 18 in das DRAM 17 auf.
Wie in 7 gezeigt, lädt der Bootlader 18 den in dem eMMC 16 gespeicherten Kernel 5 in das DRAM 17. Der geladene Kernel 5 arbeitet durch Starten am DRAM 17. Spezifischer initialisiert der Kernel 5 und entfaltet den Treiber, die Hardware-Ressource und den Funktionsmechanismus.
Wie in 8 gezeigt, lädt der Kernel 5 das in der eMMC 16 gespeicherte Framework 7 in das DRAM 17. Das geladene Framework 7 arbeitet durch Starten am DRAM 17. Spezifischer initialisiert und entwickelt das Framework 7 den abstrahierten Funktionsmechanismus und andere Software-Komponenten (andere abstrahierte Funktionsmechanismen).
In der obigen Beschreibung ist das fortschrittliche BS durch das Framework 7 konfiguriert. Der Kernel 5 und das Framework 7 arbeiten kooperativ am DRAM 17. Andererseits, wenn das Laden des fortschrittlichen BS abgeschlossen ist, wird der Bootlader 18 aus dem DRAM entladen und arbeitet nicht. Der Bootlader 18 und das fortschrittliche BS sind von unterschiedlichen Systemen. Zusätzlich beschreibt die erste Ausführungsform das fortschrittliche BS (Framework 7) als AndroidOS zu sein, aber dies ist nicht beschränkend.
Als Nächstes wird ein Betrieb der Applikationsausführungsvorrichtung im Detail beschrieben.
9 ist ein Diagramm, das ein Beispiel der Operation der Applikationsausführungsvorrichtung zeigt, wobei die CPU 3 jede in 3 gezeigte Funktion beinhaltet.
Wie in 9 gezeigt, nachdem der Strom der CPU 3 eingeschaltet ist, lädt der Bootlader 18 den Kernel 5 in das DRAM 17. Der Kernel 5 startet im DRAM 17 (siehe 6, 7). Zu dieser Zeit initialisiert und entwickelt der Kernel 5 einen Treiber, eine Hardware-Ressource und einen Funktionsmechanismus, der durch die native Applikation 13 benötigt wird, aus dem Funktionsmechanismus 11.
Die CPU 3 lädt die native Applikation 13 in das DRAM 17 und startet die native Applikation 13. Die native Applikation 13 führt eine vorbestimmte Funktion unter direkter Verwendung eines Funktionsmechanismus, der von der nativen Applikation 13 benötigt wird, aus dem Funktionsmechanismus 11 des Kernel 5 durch.
Nachdem die native Applikation 13 ausgeführt ist, initialisiert und entwickelt der Kernel 5 einen Treiber, eine Hardware-Ressource und einen Funktionsmechanismus, welche nicht von der nativen Applikation 13 benötigt werden, aus dem Funktionsmechanismus 11.
Die Zeit ab dem Einschalten der CPU 3 bis zum Betrieb der nativen Applikation 13 kann somit reduziert werden.
10 ist ein Diagramm, das ein Beispiel des Betriebs der Applikationsausführungsvorrichtung zeigt, wobei die CPU 3 jede in 2 gezeigte Funktion enthält.
Wie in 10 gezeigt, nachdem der Strom der CPU 3 eingeschaltet ist, lädt der Bootlader 18 den Kernel 5 in das DRAM 17. Der Kernel 5 startet im DRAM 17 (siehe 6, 7). Zu dieser Zeit initialisiert und entwickelt der Kernel 5 einen Treiber, eine Hardware-Ressource und einen Anzeigemechanismus 6, der von der nativen Kamera-Applikation 9 benötigt wird, aus dem Funktionsmechanismus 11.
Die CPU 3 lädt die native Kamera-Applikation 9 in das DRAM 17 und startet die native Kamera-Applikation 9. Die native Kamera-Applikation 9 gibt ein Kamerabild an die Anzeige 4 unter direkter Verwendung des Anzeigemechanismus 6 des Kernel 5 aus.
Nachdem die native Kamera-Applikation 9 ausgeführt wird, initialisiert und entwickelt der Kernel 5 einen Treiber, eine Hardware-Ressource und einen Funktionsmechanismus (Funktionsmechanismus außer dem Anzeigemechanismus 6), der von der nativen Kamera-Applikation 9 nicht benötigt wird, vom Funktionsmechanismus 11.
Die Zeit ab Einschalten der CPU 3 bis zum Betrieb der nativen Kamera-Applikation 9 kann somit reduziert werden.
Wie oben beschrieben, kann gemäß der ersten Ausführungsform ein rasches Starten bei kaltem Booten durch vorab Starten eines Funktionsmechanismus realisiert werden, der von der nativen Applikation 13 (oder der nativen Kamera-Applikation 9) benötigt wird, und dann Ausführen der nativen Applikation 13 (oder der nativen Kamera-Applikation 9). Auch, weil die native Kamera-Applikation 9 und die normale Kamera-Applikation 10 denselben Funktionsmechanismus 11 (oder den Anzeigemechanismus 6) verwenden, kann das Auftreten von Flackern im Anzeigebild zum Zeitpunkt einer Kamerabildübergabe verhindert werden.
Zweite Ausführungsform
Eine zweite Ausführungsform der vorliegenden Erfindung dient dazu, die Funktion der nativen Applikation zu minimieren. Andere Konfigurationen und Operationen sind die gleichen wie jene in der ersten Ausführungsform und eine detaillierte Beschreibung derselben wird weggelassen.
11 ist ein Diagramm, das ein Beispiel der Operation der Applikationsausführungsvorrichtung zeigt, wobei die CPU 3 jede in 3 gezeigte Funktion beinhaltet.
Wie in 11 gezeigt, nachdem der Strom der CPU 3 eingeschaltet wird, lädt der Bootlader 18 den Kernel 5 in das DRAM 17. Der Kernel 5 startet am DRAM 17 (siehe 6, 7). ?
Die CPU 3 lädt die native Applikation 13 in das DRAM 17 und startet die native Applikation 13. Die native Applikation 13 führt eine vorbestimmte Funktion durch direkte Verwendung des Funktionsmechanismus 11 des Kernel 5 durch.
Nachdem die native Applikation 13 gestartet ist, lädt der Kernel 5 das Framework 7 in das DRAM 17. Das Framework 7 startet am DRAM 17 (siehe 8).
Nachdem das Framework 7 gestartet ist, lädt die CPU 3 die normale Applikation 14 in das DRAM 17 und startet die normale Applikation 14. Die normale Applikation 14 führt eine vorbestimmte Funktion aus, indem der Funktionsmechanismus 11 des Kernel 5 durch den abstrahierten Funktionsmechanismus 12 des Frameworks 7 indirekt verwendet wird.
In der obigen Beschreibung wird die native Applikation 13 in das DRAM 17 geladen und wird entwickelt und somit ist die Ladezeit von dem Umfang der nativen Applikation 13 abhängig. Um die native Applikation 13 in einer kurzen Zeit nach Einschalten der CPU 3 zu starten, muss die Funktion der nativen Applikation 13 minimiert werden und muss der Programmumfang der nativen Applikation 13 reduziert werden (d.h., dass der Umfang der nativen Kamera-Applikation 9 kleiner zu machen ist als derjenige der normale Kamera-Applikation 10). Dies optimiert die Ladezeit der nativen Applikation 13 und die Zeit ab dem Einschalten der CPU 3 bis zum Betrieb der nativen Applikation 13 wird reduziert.
Zusätzlich wird der Betrieb der nativen Applikation 13 zu einem beliebigen Zeitpunkt nach Ausführung der normalen Applikation 14 beendet. Der beliebige Zeitpunkt kann die Zeit des Startens des Betriebs der normalen Applikation 14 sein oder die Zeit, beispielsweise wenn die normale Applikation 14 komplett abgelaufen ist (nach Betrieb der normalen Applikation 14).
12 ist ein Diagramm, das ein Beispiel der Operation der Applikationsausführungsvorrichtung zeigt, wobei die CPU 3 jede in 2 gezeigte Funktion beinhaltet.
Wie in 12 gezeigt, nachdem der Strom der CPU 3 eingeschaltet ist, lädt der Bootlader 18 den Kernel 5 in das DRAM 17. Der Kernel 5 startet am DRAM 17 (siehe 6, 7).
Die CPU 3 lädt die native Kamera-Applikation 9 in das DRAM 17 und startet die native Kamera-Applikation 9. Die native Kamera-Applikation 9 gibt ein Kamerabild an die Anzeige 4 unter Verwendung des Anzeigemechanismus 6 des Kernel 5 aus.
Nachdem die native Kamera-Applikation 9 gestartet ist, lädt der Kernel 5 das Framework 7 in das DRAM 17. Das Framework 7 startet am DRAM 17 (siehe 8).
Nachdem das Framework 7 gestartet ist, lädt die CPU 3 die normale Kamera-Applikation 10 in das DRAM 17 und startet die normale Kamera-Applikation 10. Die normale Kamera-Applikation 10 zeigt auf der Anzeige 4 ein Kamerabild an, welchem zusätzliche Information wie etwa eine Führungslinie überlagert sind, durch indirektes Verwenden des Anzeigemechanismus 6 des Kernel 5 über den abstrahierten Anzeigemechanismus 8 des Frameworks 7.
In der obigen Beschreibung wird die native Kamera-Applikation 9 in das DRAM 17 geladen und entwickelt und somit hängt die Ladezeit vom Umfang der nativen Kamera-Applikation 9 ab. Um die native Kamera-Applikation 9 in einer kurzen Zeit nach Einschalten der CPU 3 zu starten, ist die Funktion der nativen Kamera-Applikation 9 zu minimieren und ist das Programmvolumen der nativen Kamera-Applikation 9 zu reduzieren (d.h., der Umfang der nativen Kamera-Applikation 9 ist kleiner zu machen als dasjenige der normalen Kamera-Applikation 10). Dies optimiert die Ladezeit der nativen Kamera-Applikation 9 und die Zeit ab dem Einschalten der CPU 3 bis zum Betrieb der nativen Kamera-Applikation 9 wird reduziert.
Auch arbeiten die native Kamera-Applikation 9 und die normale Kamera-Applikation 10 direkt oder indirekt unter Verwendung desselben Anzeigemechanismus 6. Entsprechend wird kein Flackern im Anzeigebildschirm zum Zeitpunkt des Umschaltens von einem Kamerabild durch die native Kamera-Applikation 9 zu einem Kamerabild durch die normale Kamera-Applikation 10 verursacht.
Zusätzlich wird der Betrieb der nativen Kamera-Applikation 9 zu einem beliebigen Zeitpunkt nach Ausführen der normalen Kamera-Applikation 10 beendet. Das beliebige Timing kann der Zeitpunkt des Startens des Betriebs der normalen Kamera-Applikation 10 sein oder der Zeitpunkt, beispielsweise wenn die normale Kamera-Applikation 10 vollständig abgearbeitet ist (nach Betrieb der normalen Kamera-Applikation 10).
Wie oben beschrieben, kann gemäß der zweiten Ausführungsform ein rasches Starten bei kaltem Booten durch Minimieren der Funktion der nativen Applikation 13 (oder von der nativen Kamera-Applikation 9) realisiert werden.
Zusätzlich, wie in der ersten Ausführungsform, kann die native Kamera-Applikation 9 durch Starten eines Funktionsmechanismus (Anzeigemechanismus 6) vorab ausgeführt werden, der von der nativen Kamera-Applikation 9 benötigt wird,.
Dritte Ausführungsform
13 und 14 sind Blockdiagramme, die ein Beispiel einer Software-Konfiguration einer Applikationsausführungsvorrichtung gemäß einer dritten Ausführungsform der vorliegenden Erfindung zeigen. Zusätzlich zeigt 13 eine Gesamtkonfiguration der Applikationsausführungsvorrichtung und zeigt 14 hauptsächlich eine detaillierte Konfiguration des Kernels 5. Andere Konfigurationen und Operationen sind die gleichen wie jene in der ersten Ausführungsform und eine detaillierte Beschreibung derselben ist weggelassen. Zusätzlich zeigt 13 die Konfiguration in 2, versehen mit einem Rahmensteuermechanismus 19, aber der Rahmensteuermechanismus 19 kann alternativ an der Konfiguration in 3 vorgesehen sein.
Wie in 13 gezeigt, enthält die Applikationsausführungsvorrichtung gemäß der dritten Ausführungsform den Rahmensteuermechanismus 19.
Wie in 14 gezeigt, beinhaltet der Anzeigemechanismus 6 Fensterrahmen 20 bis 22 und einen Mischer 23. Auch beinhaltet der Kernel 5 den Anzeigetreiber 24.
Der Rahmensteuermechanismus 19 ist eine von nativen Applikationen und ist abstrahierte Fensterrahmen 20 bis 22. Der Rahmensteuermechanismus 19 führt eine Steuerung des Zuweisens eines der Fensterrahmen 20 bis 22 zu jeder einer nativen Applikation einer normalen Applikation durch.
Jeder der Fensterrahmen 20 bis 22 ist eine Region, die ein Zeichenfenster und eine Schicht im Zeichenfenster speichert und die ein Bildschirm-Design ist, das konfiguriert ist durch eine native Applikation und eine normale Applikation. Zusätzlich beschreibt die dritte Ausführungsform einen Fall, bei dem der Anzeigemechanismus 6 drei Fensterrahmen enthält, aber es reicht aus, falls es eine Mehrzahl von Fensterrahmen gibt, ohne auf drei beschränkt zu sein.
Der Mischer 23 beinhaltet eine Funktion des Überlagerns einer Mehrzahl von Applikationen. Der Anzeigetreiber 24 beinhaltet eine Funktion zum Ausgeben eines Kamerabildes an die Anzeige 4 .
15 ist ein Diagramm, das eine Beziehung zwischen dem Rahmensteuermechanismus 19 und dem Anzeigemechanismus 6 zeigt.
Der Rahmensteuermechanismus 19 verwaltet und steuert den Zugriff durch eine native Applikation oder den abstrahierten Anzeigemechanismus 8 des Frameworks 7 auf einen beliebigen Fensterrahmen des Anzeigemechanismus 6. Das heißt, die Verwendung eines spezifischen Fensterrahmens kann durch den Rahmensteuermechanismus 19 verwaltet und gesteuert werden.
Als Nächstes wird der Betrieb der Applikationsausführungsvorrichtung gemäß der dritten Ausführungsform unter Bezugnahme auf 16 bis 18 beschrieben. Zusätzlich wird nachfolgend ein Fall beschrieben, bei dem die Applikationsausführungsvorrichtung die in 13 gezeigte Konfiguration aufweist.
16 zeigt einen Fall des Betriebs der nativen Kamera-Applikation 9. Wie in 16 gezeigt, weist der Rahmensteuermechanismus 19 den Fensterrahmen 20 des Anzeigemechanismus 6 der nativen Kamera-Applikation 9 zu. Wenn die native Kamera-Applikation 9 arbeitet, passiert ein Kamerabild den Fensterrahmen 20 und Mischer 23 und wird an der Anzeige 4 durch Antreiben des Anzeigetreibers 24 des Kernels 5 ausgegeben. Zu dieser Zeit muss die native Kamera-Applikation 9 nicht erfassen, welcher Fensterrahmen des Anzeigemechanismus 6 verwendet wird.
17 zeigt einen Fall des Betriebs einer beliebigen normalen Applikation (außer der normalen Applikation 10), nicht einschließlich der Funktion zum Ausgeben eines Kamerabilds an die Anzeige 4. Wie in 17 gezeigt, weist der Rahmensteuermechanismus 19 den Fensterrahmen 22 des Anzeigemechanismus 6 dem abstrahierten Anzeigemechanismus 8 des Frameworks 7 zu. Wenn eine normale Applikation arbeitet, passiert ein durch die normale Applikation gezeichnetes Bild den Fensterrahmen 22 und den Mischer 23 und wird an die Anzeige 4 durch Betreiben des Anzeigetreibers 24 des Kernel 5 ausgegeben. Zu dieser Zeit muss der abstrahierte Anzeigemechanismus 8 des Frameworks 7 nicht erfassen, welcher Fensterrahmen des Anzeigemechanismus 6 verwendet wird.
In dem Fall der simultanen Ausführung von 16 und 17 wird ein Kamerabild durch den Betrieb der nativen Kamera-Applikation 9 an den Fensterrahmen 20 ausgegeben und wird ein Bild des Betriebs einer beliebigen normalen Applikation, die nicht die normale Kamera-Applikation 10 ist, an dem Fensterrahmen 20 eingegeben.
Der Mischer 23 des Anzeigemechanismus 6 gibt nur das Kamerabild durch den Betrieb der nativen Kamera-Applikation 9 an die Anzeige 4 aus, oder gibt nur das Bild durch den Betrieb der beliebigen normalen Applikation an die Anzeige 4 aus, oder führt eine Ausgabe an die Anzeige 4 nach Überlagern des Kamerabildes durch den Betrieb der nativen Kamera-Applikation 9 mit dem Bild durch den Betrieb der beliebigen normale Applikation durch. Auf diese Weise können ein Kamerabild durch den Betrieb der nativen Kamera-Applikation 9 und ein Bild durch den Betrieb einer beliebigen normalen Applikation ausgegeben werden, indem voneinander umgeschaltet wird, oder indem sie einander überlagert werden.
18 zeigt einen Fall des Betriebs der normalen Kamera-Applikation 10. Wie in 18 gezeigt, weist der Rahmensteuermechanismus 19 den Fensterrahmen 20 des Anzeigemechanismus 6 der normalen Kamera-Applikation 10 durch den abstrahierten Anzeigemechanismus 8 des Framework 7 zu. Wenn die normale Kamera-Applikation 10 arbeitet, passiert ein Kamerabild den Fensterrahmen 20 und den Mischer 23 und wird an die Anzeige 4 durch Antreiben des Anzeigetreibers 24 des Kernel 5 ausgegeben.
Wie oben beschrieben, steuert der Rahmensteuermechanismus 19 die Fensterrahmen anhand von Hardware-Ressourcen, ohne Berücksichtigung der nativen Kamera-Applikation 9 und der normalen Kamera-Applikation 10 auf oberen Niveaus des Rahmensteuermechanismus 19. In dem Beispiel in 16 und 18 ist das Kamerabild, welches die Hardware-Ressource ist, zwischen der nativen Kamera-Applikation 9 und der normalen Kamera-Applikation 10 gemein, und somit wird derselbe Fensterrahmen 20 zugewiesen.
Wie in der ersten Ausführungsform beschrieben (siehe 12), zum Zeitpunkt des Umschaltens von der nativen Kamera-Applikation 9 zur normalen Kamera-Applikation 10 (zum Zeitpunkt der Kamerabildübergabe) wird die Ausgabe des Kamerabildes unter Verwendung des Fensterrahmens 20 unter der Steuerung des Rahmensteuermechanismus 19 fortgesetzt und somit wird ein Flackern im Anzeigebild (Störung im Anzeigebild) zum Zeitpunkt des Umschaltens nicht verursacht.
19 ist ein Sequenzdiagramm, das kollektiv in 16 und 18 gezeigte Operationen zeigt.
Wie in 19 gezeigt, wenn der Kernel 5 gestartet wird, führen der Anzeigetreiber 24, der Anzeigemechanismus 6 und der Rahmensteuermechanismus 19 Initialisierungsprozesse durch. Der Rahmensteuermechanismus 19 erfasst eine Fensterliste aus dem Anzeigemechanismus 6 während des Initialisierungsprozesses.
Wenn der Initialisierungsprozess des Rahmensteuermechanismus 19 abgeschlossen ist, erfasst die native Kamera-Applikation 9 Fenster-Information aus dem Rahmensteuermechanismus 19 und erhält dann ein Fenster 1. Zu dieser Zeit erhält der Anzeigemechanismus 6 einen Rahmenpuffer aus einem Speicher. Ein Kamerabild wird somit durch den Betrieb der nativen Kamera-Applikation 9 aufgenommen. Zusätzlich korrespondiert im Beispiel von 16 das Fenster 1 zum Fensterrahmen 20.
Auch korrespondiert der Speicher beispielsweise zum DRAM 17 in 4. Darüber hinaus wird beispielsweise das Kamerabild durch den Aufnehmer 2 in 1 aufgenommen.
Wenn der Kernel 5 in einen Betriebszustand gebracht wird, erfasst der abstrahierte Anzeigemechanismus 8 die Fensterinformation aus dem Rahmensteuermechanismus 19 während des Initialisierungsprozesses. Wenn der Initialisierungsprozess des abstrahierten Anzeigemechanismus 8 abgeschlossen ist, erfasst die normale Kamera-Applikation 10 die Fenster-Information aus dem abstrahierten Anzeigemechanismus 8 und erteilt dann eine Stopp-Aufforderung der nativen Kamera-Applikation 9. Dann erhält die normale Kamera-Applikation 10 das Fenster 1 aus dem abstrahierten Anzeigemechanismus 8.
Die normale Kamera-Applikation 10 erhält ein Fenster 2 aus dem Anzeigemechanismus 6 und führt eine Zeichnung einer Führungslinie oder dergleichen unter Verwendung des Fensters 2 durch. Zusätzlich kann das Fenster 2 beispielsweise ein Fensterrahmen 22 sein (siehe 17).
Umschalten von der nativen Kamera-Applikation 9 zur normalen Kamera-Applikation 10 wird in der obigen Weise durchgeführt (d.h. die Kamerabildübergabe wird durchgeführt). Zu dieser Zeit, weil die native Kamera-Applikation 9 und die normale Kamera-Applikation 10 das gemeinsame Fenster 1 verwenden, wird kein Flackern in dem Kamerabild verursacht.
20 ist ein Diagramm, das ein Beispiel eines Falls zeigt, bei dem nur eine konventionelle normale Kamera-Applikation betrieben wird. Wie in 20 gezeigt, führt die normale Kamera-Applikation keine Kamerabildübergabe unter Verwendung eines gemeinsamen Fensters mit der nativen Kamera-Applikation durch, wie in 19 gezeigt. Entsprechend wird ein Flackern konventioneller Weise zum Zeitpunkt einer Übergabe zum Kamerabild durch den Betrieb der normalen Kamera-Applikation verursacht.
Wie oben beschrieben, kann gemäß der dritten Ausführungsform das Auftreten von Flackern im Anzeigebild zum Zeitpunkt der Kamerabildübergabe verhindert werden, indem derselbe Fensterrahmen der nativen Kamera-Applikation 9 und der normalen Kamera-Applikation 10 zugewiesen wird.
Zusätzlich, wie in der ersten Ausführungsform, kann der Umfang der nativen Kamera-Applikation 9 kleiner sein als derjenige der normalen Kamera-Applikation 10.
Auch in der zweiten Ausführungsform kann die native Kamera-Applikation 9 durch das Starten eines Funktionsmechanismus (Anzeigemechanismus 6) ausgeführt werden, vorab, der durch die native Kamera-Applikation 9 benötigt wird.
Zusätzlich können die Ausführungsformen frei kombiniert werden oder können Ausführungsformen modifiziert oder weggelassen werden, wie angemessen innerhalb des Schutzumfangs der vorliegenden Erfindung.
Obwohl die vorliegende Erfindung oben im Detail beschrieben worden ist, ist die Beschreibung nur beispielhaft in jeglichem Aspekt gegeben und die vorliegende Erfindung ist nicht darauf beschränkt. Es versteht sich, dass eine indefinite Anzahl von Beispielmodifikationen, die nicht illustriert ist, innerhalb des Schutzumfangs der vorliegenden Erfindung vorstellbar ist.
Bezugszeichenliste

1: Kamera
2: Aufnehmer
3: CPU
4: Anzeige
5: Kernel
6: Anzeigemechanismus
7: Framework
8: Abstrahierter Anzeigemechanismus
9: Native Kamera-Applikation
10: Normale Kamera-Applikation
11: Funktionsmechanismus
12: Abstrahierter Funktionsmechanismus
13: Native Applikation
14: Normale Applikation
15: NOR-Flash-Speicher
16: eMMC 16
17: DRAM
18: Bootlader
19: Rahmensteuermechanismus
20,: 21, 22 Fensterrahmen
23: Mischer
24: Anzeigetreiber
25: Kamera
26: Aufnehmer
27: Graphik
28: CPU
29: Schalter
30: Anzeige
31: BS
32: Anzeigemechanismus
33: Applikation
34: BS
35: Anzeigemechanismus
36: Applikation

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

JP 4498771 [0006]
JP 4978558 [0006]
JP 5028904 [0006]

Claims

Applikationsausführungsvorrichtung, umfassend: einen Kernel, der einen vorbestimmten Funktionsmechanismus enthält; ein Framework, welches durch den Kernel gestartet wird und das einen abstrahierten Funktionsmechanismus enthält, der durch Abstrahieren des Funktionsmechanismus erhalten wird, eine erste Applikation, die arbeitet, indem sie direkt den Funktionsmechanismus verwendet; und eine zweite Applikation, die indirekt arbeitet, indem sie den Funktionsmechanismus durch den abstrahierten Funktionsmechanismus verwendet, und die eine Funktion der ersten Applikation enthält, wobei der Funktionsmechanismus einen Funktionsmechanismus, der zum Betrieb der ersten Applikation erforderlich ist, und einen anderen Funktionsmechanismus, der zum Betrieb der ersten Applikation nicht erforderlich ist, beinhaltet, und wobei der Kernel nur den Funktionsmechanismus startet, der für den Betrieb der ersten Applikation erforderlich ist und dann einen anderen Funktionsmechanismus startet, der für den Betrieb der ersten Applikation nicht erforderlich ist.
Applikationsausführungsvorrichtung gemäß Anspruch 1, wobei ein Umfang der ersten Applikation kleiner ist als ein Umfang der zweiten Applikation.
Applikationsausführungsvorrichtung gemäß Anspruch 1, wobei der Funktionsmechanismus einen Anzeigemechanismus beinhaltet.
Applikationsausführungsvorrichtung gemäß Anspruch 3, weiter umfassend einen Rahmensteuermechanismus, der eine Vielzahl von Fensterrahmen steuert, die in dem Anzeigemechanismus enthalten sind, wobei der Rahmensteuermechanismus die Steuerung so durchführt, dass derselbe Fensterrahmen zum Zeitpunkt des Betriebs sowohl der ersten Applikation als auch der zweiten Applikation zugewiesen wird.
Applikationsausführungsvorrichtung gemäß Anspruch 1, wobei der Betrieb der ersten Applikation beendet wird nach Ausführung der zweiten Applikation.
Applikationsausführungsvorrichtung gemäß Anspruch 1, wobei der Kernel ein Linux-Kernel ist.
Applikationsausführungsvorrichtung gemäß Anspruch 1, wobei das Framework AndroidOS ist.
Applikationsausführungsvorrichtung gemäß Anspruch 3, wobei der Anzeigemechanismus SurfaceFlinger und Hardware Composer von AndroidOS ist.
Applikationsausführungsverfahren zum sequentiellen Starten zumindest eines Kernels und eines Frameworks und zum Ausführen einer ersten Applikation und einer zweiten Applikation, wobei der Kernel einen vorbestimmten Funktionsmechanismus beinhaltet, wobei das Framework durch den Kernel gestartet wird, und einen abstrahierten Funktionsmechanismus beinhaltet, der durch Abstrahieren des Funktionsmechanismus erhalten wird, wobei die erste Applikation durch direktes Verwenden des Funktionsmechanismus arbeitet, wobei die zweite Applikation durch indirektes Verwenden des Funktionsmechanismus durch den abstrahierten Funktionsmechanismus arbeitet und eine Funktion der ersten Applikation beinhaltet, wobei der Funktionsmechanismus einen Funktionsmechanismus beinhaltet, der für den Betrieb der ersten Applikation erforderlich ist, und einen anderen Funktionsmechanismus, der für den Betrieb der ersten Applikation nicht erforderlich ist, und wobei der Kernel nur den Funktionsmechanismus startet, der für den Betrieb der ersten Applikation erforderlich ist, und dann einen anderen Funktionsmechanismus startet, welcher für den Betrieb der ersten Applikation nicht erforderlich ist.