#Miniapp Launch Process

Before optimizing startup performance, you need to understand the miniapp startup flow. Understanding each phase's role and time cost helps developers choose the right optimization strategies.

The startup phases are not entirely sequential — some run in parallel. Total startup time is not simply the sum of each phase.

#Launch Flow Overview

The miniapp startup process includes the following phases:

sequenceDiagram
    autonumber
    participant User as User
    participant Runtime as Client
    participant Service as Logic Layer Injection
    participant View as View Layer
    participant Net as Network

    User->>Runtime: Open miniapp

    par Resource preparation
        Runtime->>Runtime: Runtime initialization
    and
        Runtime->>Net: Fetch miniapp info
    and
        Runtime->>Net: Download package
    end

    Runtime->>Service: Inject logic layer code
    Runtime->>View: Inject view layer code

    Service->>Service: Execute App/Page lifecycle

    Service->>View: setData(initial data)
    View-->>User: First screen rendered

    Service->>Net: Async data request
    Net-->>Service: Data returned
    Service->>View: setData(page update)

#1. Resource Preparation

#1.1 Runtime Initialization

The miniapp runtime environment includes:

• Miniapp process
• Client native system components and UI elements (navigation bar, tabBar, etc.)
• WebView container for page rendering
• JavaScript engine
• Miniapp base library

Some components (such as the JavaScript engine and base library) must be ready before executing miniapp code; others initialize in parallel during startup.

To reduce the impact of runtime preparation on startup time, the client preloads the runtime environment based on user behavior patterns and device resource availability before the miniapp starts.

#1.2 Fetching Miniapp Info

The client fetches basic miniapp information (version, config, permissions, etc.) from the server. This information is cached locally and updated through a specific mechanism.

#Impact on Startup Time

• First visit or version updates increase startup time due to info fetching
• Time is mainly affected by network conditions
• Frequent version releases increase the proportion of synchronous requests during startup; plan release cadence accordingly

#1.3 Package Download

The miniapp package must be downloaded at startup. Similar to info fetching, the package has a caching mechanism:

#Impact on Startup Time

• Download time is a major bottleneck in the startup process
• Determined by network conditions and compressed package size
• Developers should minimize package size; see Package Size Optimization

#2. Code Injection

#2.1 Logic Layer Code Injection

During startup the miniapp framework loads config and code from the package and injects it into the JavaScript engine. This triggers:

• App.onLaunch lifecycle
• App.onShow lifecycle

#Impact on Startup Time

• Code volume and complexity: More code and more complex logic means longer injection time
• Synchronous API calls: Calling synchronous APIs during startup blocks the injection process
• Complex computation: Running heavy computations at startup extends injection time

#2.2 View Layer Code Injection

Styles and template code are compiled into JavaScript and injected into the view layer. Logic layer and view layer injection run in parallel.

#Impact on Startup Time

Injection time depends on page structure complexity and the number of custom components used.

#3. Home Page Rendering

After logic layer injection is complete, the framework:

1. Initializes the page component tree based on the user's target page
2. Fires Page.onLoad; developers can set initial data here
3. Sends initial render data to the view layer and fires Page.onShow
4. The view layer renders the first screen
5. Fires Page.onReady after first screen render is complete

Page.onReady signals the end of the miniapp startup flow.

#Impact on Startup Time

• First page rendering is the final phase of startup
• Time depends on page structure complexity and number of components
• See First Screen Render Optimization

#4. First Screen Content Display

After the home page renders, the miniapp loading indicator disappears. However, if the main first-screen content depends on async network requests, users may still see an empty page or skeleton screen until the request returns and setData updates the page.

#Impact on Startup Time

Async data requests are not counted in the startup time metric, but they delay when users see complete content, affecting actual experience.

#Lifecycle Sequence Summary

App.onLaunch → App.onShow → Page.onLoad → Page.onShow → Page.onReady
     ↑                            ↑                           ↑
Logic layer done            Page initialized          First screen done

#FAQ

#Why is the first open much slower than subsequent opens?

The first open requires synchronous download of the package and fetching of miniapp info. Subsequent opens use local cache, skipping the download step.

#Why does startup time vary greatly across devices?

• Different device performance (CPU, memory)
• Different process management mechanisms across operating systems
• Low-end devices are more likely to have their preloaded runtime reclaimed by the system

#Related Documents

• Package Size Optimization
• Code Injection Optimization
• First Screen Render Optimization