[Ubuntu-phone] MeeGo applauncherd: faster application startup and more

[Alberto Mardegan]

On 06/17/2013 12:35 PM, Thomas Voß wrote:
> On Mon, Jun 17, 2013 at 10:02 AM, Michael Zanetti
> <michael.zanetti at canonical.com> wrote:
>> Basically instead of launching your app normally, you give it as an argument
>> to a the so called invoker (/usr/bin/invoker) which has all the common stuff
>> already loaded and forks to your application.

To be precise: /usr/bin/invoker just takes the application name and 
parameters and sends them to applauncherd (via a socket). Applauncherd 
has *already* forked into a new "empty" process, which is just waiting 
for the invoker data to load the application.
So, what is left to do is just the application loading -- the forking is 
already done.

> Ack, here is where the upstart-launcher would come into play.

I don't know much about upstart, but my understanding is that the 
functionality of the /usr/bin/invoker (it's a very small process) could 
go into upstart-launcher.

[...]
>> to create a new QApplication. I don't exactly know the details what they do
>> inside that MDeclarativeCache. I guess one thing is to monitor the state of
>> the created QML view and make the splash screen go away when ready.
>>
>
> This is something we would need to investigate further. Alberto, can
> you take a look at MDeclarativeCache and try to summarize the benefits
> it provides?

I think I explained it in my other message (point 2), but I'll try to be 
more clear: the booster process, which is the "empty" process waiting 
for a connection from the invoker to load the real application binary, 
is linked (or has dlopen()ed) quite a few common libraries, and has 
already instantiated a QGuiApplication and a QQuickWindow. This means 
that all the initializations performed by QGuiApplication (don't ask me 
what it does, I have no idea :-) ) and QQuickWindow (this is quite 
heavy: it initializes the QQmlEngine, and consequently the javascript 
engine) are already done by the time that the user starts an application.
What happens when the user starts an application, is that the invoker
informs the booster process of what binary needs to be loaded. The 
booster process sets up the security context and loads the real 
application binary, then invokes its main() method (with proper argc and 
argv), and all works.
Now, to take the pre-initialization into use, the application binary 
needs not to instantiate new QGuiApplication and QQuickWindow, but just 
obtain them from the booster (which provides a couple of static 
functions to retrieve the already instantiated objects).

Note that the objects which we want to pre-load are completely up to us. 
Suppose that we found out that there's another class whose 
initialization time is quite consistent, we can have the booster 
pre-create it (if the object's constructor takes no arguments, or if we 
can provide them later). Likewise, an application is not forced to use 
our cached objects; indeed, there might be cases where they don't work 
(the QApplication doesn't work with more than 32 command line arguments, 
for instance), so corner cases are covered as well.

Please read the two links from my initial post (especially the second 
one); I think they explain the feature much better than how I could do. :-)

Ciao,
   Alberto