Qtopia Home - Classes - Hierachy - Annotated - Functions - Qt Embedded |

# Writing Applications that Startup Quickly

- Introduction
- Delaying code execution.
- Using Quicklaunch
  - Design
    - Stub Application
    - Quick Launcher
    - Making Applications Quick Launchable
  - Initial Results

## Introduction

Application startup time is critical on consumer devices. This document describes techniques for making Qtopia applications startup as quickly as possible.

## Delaying code execution.

Making an application startup quickly is closely related to how much code is executed during the startup process. Some of the common operations that can affect startup time are:

- Loading/parsing configuration files.
- Creating user interface components (dialogs, etc.)
- Reading data files.

The simplest way to improve startup time is to defer some of these operations until after the UI is visible. If possible, perform the operation on demand, for example, do not create a dialog until it is actually needed:

    MainWidget::MainWidget( QWidget *parent, const char *name, WFlags f )
        : QMainWindow( parent, name, f ), settingsDialog(0)
    {
    }

    void MainWidget::showSettings()
    {
        // If settingsDialog has not yet been created, create it now.
        if ( !settingsDialog )
            settingsDialog = new SettingsDialog( this );
        settingsDialog-&gt;exec();
    }

If the operation is required immediately after the application is visible, a single shot timer may be used to start the processing after the main widget is visible:

    MainWidget::MainWidget( QWidget *parent, const char *name, WFlags f )
        : QMainWindow( parent, name, f ), settingsDialog(0)
    {
        // After the event queue has been processed and the mainwindow is
        // visible, load the data.
        QTimer::singleShot(0, this, SLOT(loadData()));
    }

    void MainWidget::loadData()
    {
        // Open data file and populate data view.
    }

## Using Quicklaunch

Old Qtopia versions suffered from slow startup times primarily for the following reasons:

1. Loading and linking dynamic libraries
2. Constructing QPE/Application
3. Constructing widgets
4. Loading data files

The Quick Launcher funcionality aims to eliminate 1, 2, and some of 3.

### Design

#### Stub Application

To eliminate loading/linking and QPEApplication construction, a stub application will be run in advance of an application being requested. When the stub application is started, it will:

- Link to the most common libraries
- Construct QPEApplication
- Pre-load the default font and initialize other data where possible.
- Execute the event loop and wait for a request to run an application.

When the stub application is requested to run an application, it will:

- Load the quick-launchable application's library and run the entry point function.
- Change identity to that of the requested application - i.e. it will be subscribed to the QPE/Application/exename QCop channel.
- Unsubscribe from the quick launcher QCop channel.
- Return to the event loop.

At this point, the stub application should behave exactly as if it were started via the normal process.

#### Quick Launcher

The Quick Launcher will become part of the AppLauncher class in the server process (qpe). The AppLauncher is already responsible for launching Qtopia applications, and monitoring their status.

The AppLauncher will attempt to always have one Stub Application running in readiness for a request to run an application.

When a request to run an application is made:

- If the application is not quick launchable, it will be started normally.
- If a Stub Application is not already running, it will be started normally.
- Otherwise, the stub application is sent a message via QCop to start the application.
- After a short delay (2 seconds) a new Stub Application will be started to handle the next request.

Since the stub applications are child processes of the server process, AppLauncher will continue to function normally, i.e. it can catch SIGCHILD signals and handle application exit as it does currently.

If the server is running as root, it will set the priority of the Stub Application low while it is being started to ensure that it does not take processor cycles needed by foreground processes. It will be given normal priority when a request to load a new application is received.

#### Making Applications Quick Launchable

An application is made quick launchable by implementing the Quick Launcher entry and exit functions:

- void qtopiaInit( int argc, char *argv[] )
- void qtopiaDestroy()

Usually the qtopiaInit() function will simply construct the application's main widget and show it as the current documentation suggests. The qtopiaDestroy() function frees any memory allocated by qtopiaInit().

For Example, the Qtopia documentation suggests this implementation for main():

    int main( int argc, char **argv )
    {
        QPEApplication a( argc, argv );

        Main m;
        a.showMainWidget(&m);

        return a.exec();
    }

A quick launch enabled applciation would look like:

    static Main *m = 0;

    void qtopiaInit( int argc, char *argv[] )
    {
        m = new Main();
        qApp-&gt;showMainWidget(m);
    }

    void qtopiaDestroy()
    {
        delete m;
    }

    QTOPIA_MAIN

The QTOPIA_MAIN macro is implemented as:

    int main( int argc, char **argv )
    {
        QPEApplication a( argc, argv );
        qtopiaInit( argc, argv );
        int rv = a.exec();
        qtopiaDestroy();
        return rv;
    }

### Initial Results

The initial results of the design described above are:

Application | Qtopia 1.6.0 (sec) | + QuickLauncher (sec)
--- | --- | ---
Calendar | 1.9 | 0.8
Contacts | 2.2 | 1.1
Email | 2.4 | 1.2
Image Viewer | 1.4 | 0.9
Media Player | 2.3 | 0.4/1.3*
Tasks | 2.0 | 1.1
Today | 1.8 | 0.8
Clock | 1.6 | 0.6

* The Media Player delays its main GUI construction, so the initial window displays in 0.4 seconds and the full GUI is displayed in 1.3 seconds