The invoker program and the applauncherd daemon help applications launch faster and save memory through shared resources and application type specific initialisations. The invoker uses a socket connection to request application launch, and applications are forked from the daemon process so that they can share memory with the daemon (and each other) using copy-on-write. The invoker also provides application specific splash screen support, and provides a single instance facility that allows only one instance of an application to be running at a time.
The following table shows what services are available for different kinds of applications.
| boosting | splash | single instance | |
|---|---|---|---|
| QML | x | x | x |
| Qt | x(1) | x | x |
| MeeGo Touch | x | x | x |
| other | - | x | x |
(1) Only library preloading.
All functionality of the launcher daemon is accessed using the invoker program. The daemon is usually started automatically as part of the UI session (for example, upstart in MeeGo 1.2 Harmattan).
The applauncherd daemon process links in a set of libraries so that the launched applications do not need to do linking and symbol resolution for the libraries at startup. In addition, startup latency is reduced by doing some initialisations before application launch.
When applauncherd is started, it forks off a number of booster processes, one for each application type supported by the launcher. The boosters first do some application type specific but application independent initialisation if applicable. For example, the QML booster instantiates a QApplication and a QDeclarativeView, and stores the instances in MDeclarativeCache. Each booster then starts listening on its dedicated socket.
Applications are launched by using the invoker program. The invoker sends the path of the application binary to the desired booster process, along with data on its running environment (for example, command line arguments and environment variables). The booster process loads the binary, initialises its environment, and finally calls the main() function in the binary. If the booster process had instantiated some objects, they can be picked up from the cache instead of constructing them at startup. For example, a QML application runner written in C++ can pick up the QApplication and QDeclarativeView instances from MDeclarativeCache.
This section gives a quick introduction on invoker usage and boosting applications.
Note: The QML booster and single instance support are currently included in the Qt Quick application template provided by the Qt SDK. To enable these features in your application, select Make application boostable checkbox when creating a new project with the template.
In order to boost Qt Quick applications with invoker, some changes in the application and the way it is built are needed. The process is similar for MeeGo Touch applications and plain Qt applications, for details see appropriate documentation below. The applauncherd-dev package needs to be installed to get the necessary headers and libraries.
In the following example a QML application uses a simple C++ based runner. The first step is to modify the application so that it picks up instances of QApplication and QDeclarativeView from MDeclarativeCache. To do this, the include directive for MDeclarativeCache is needed, and the lines where the classes are instantiated need to be modified:
#include <MDeclarativeCache>
QApplication *app = MDeclarativeCache::qApplication(argc, argv);
QDeclarativeView *window = MDeclarativeCache::qDeclarativeView();
All the boosters except the exec booster need the application binary to be compiled as Position Independent Executable (PIE). This is achieved by using -fPIC when compiling and -rdynamic -pie when linking. A minimal QML helloworld could be compiled as linked as follows.
c++ -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -fPIC -I/usr/include/applauncherd -o main.o -c main.cpp c++ main.o -o qml-helloworld -rdynamic -pie -lmdeclarativecache -lQtCore -lQtDeclarative
The resulting binary can now be launched using the invoker as follows. The --type=d command parameter specifies that this is a QML application.
invoker --type=d ./qml-helloworld
Normally the compiler and linker flags are provided automatically either by using pkg-config directly, or using it via CMake or qmake.
It is also a good idea to hide any unnecessary symbols in the application binary to speed up opening it in the booster. For instructions, see Using the QML booster and Using the MeeGo Touch booster.
The invoker can be used to get a splash screen for the application and to implement single instance behaviour. If the exec booster is used, no modifications to the application source code are needed. For more details, see Using the exec booster and Enabling a splash screen for an application. Note that the exec booster facilitates the use of the splash screen and single instance. If you need to reduce application startup time significantly, use other boosters instead.
Simply specify the name of the splash image on the invoker command line as follows.
invoker --type=e --splash=/usr/share/images/myAppSplash.jpg /usr/bin/myApp
To request single instance behaviour, use the following command line option:
invoker --type=e --single-instance /usr/bin/myApp
This causes invoker to look for a running instance of the application using a simple lock file based mechanism. If an already running instance is found, it is brought to the foreground instead of launching a new instance of the application. See Enabling single instance support for an application for more information.
The options can also be combined, in which case the splash screen is only shown when a new instance of the application is started:
invoker --type=e --single-instance --splash=/usr/share/images/myAppSplash.jpg /usr/bin/myApp
See Tips and tricks.