/*! \mainpage Optimising application startup \section introduction Introduction The \c invoker program and the \c applauncherd daemon help applications launch faster and save memory through shared resources and application type specific initialisations. The \c 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 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 single instance
QML x x
Qt x(1) x
other - x
(1) Only library preloading. All functionality of the launcher daemon is accessed using the \c invoker program. The daemon is usually started automatically as part of the UI session (for example, \c upstart in MeeGo 1.2 Harmattan). The \c 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 \c applauncherd is started, it forks off a number of \a 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 \c QApplication and a \c QDeclarativeView, and stores the instances in MDeclarativeCache. Each booster then starts listening on its dedicated socket. Applications are launched by using the \c 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 \c 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 \c QApplication and \c QDeclarativeView instances from MDeclarativeCache. \section gettingstarted Getting started This section gives a quick introduction on \c 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. \subsection boostingqtquick Boosting Qt Quick applications In order to boost Qt Quick applications with \c invoker, some changes in the application and the way it is built are needed. The process is similar for plain Qt applications, for details see appropriate documentation below. The \c 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 \c QApplication and \c 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: \code #include \endcode \code QApplication *app = MDeclarativeCache::qApplication(argc, argv); QDeclarativeView *window = MDeclarativeCache::qDeclarativeView(); \endcode All the boosters except the exec booster need the application binary to be compiled as Position Independent Executable (PIE). This is achieved by using \c -fPIC when compiling and \c -rdynamic \c -pie when linking. A minimal QML helloworld could be compiled as linked as follows. \code 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 \endcode The resulting binary can now be launched using the invoker as follows. The \c --type=d command parameter specifies that this is a QML application. \code invoker --type=d ./qml-helloworld \endcode Normally the compiler and linker flags are provided automatically either by using \ref usingpkgconfig "pkg-config" directly, or using it via \ref usingcmake "CMake" or \ref usingqmake "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 \ref qmlboost "Using the QML booster" \subsection gettingstartedebooster Single instance The \c invoker can be used to implement single instance behaviour. If the \a exec \a booster is used, no modifications to the application are needed. For more details, see \ref eboost "Using the exec booster". Note that the \a exec booster facilitates single instance launching. If you need to reduce application startup time significantly, use other boosters instead. \code invoker --type=e /usr/bin/myApp \endcode This causes \c 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 \ref singleinstance "Enabling single instance support for an application" for more information. \section reference Further information - How to enable boosted startup for different types of applications: - \subpage qmlboost "Using the QML booster" - \subpage qtboost "Using the Qt booster" - \subpage eboost "Using the exec booster" - \subpage singleinstance "Enabling single instance support for an application" \section tipsntricks Tips and tricks See \subpage tipsandtricks. */