1# Lazy Import 2 3With the continuous expansion of application features, the time required for cold start increases significantly. The main reason is that a large number of modules are loaded at the early stage of startup, and a large number of redundant files that are not actually executed exist. This case not only delays the initialization process of the application, but also causes the invalid occupation of resources. Therefore, you can use the lazy import to simplify the loading process and delete unnecessary files to optimize the cold start performance and ensure smooth user experience. 4 5> **NOTE** 6> 7> The lazy import is supported since API version 12. 8> 9> To use the lazy import syntax on API version 12, you need to configure **"compatibleSdkVersionStage": "beta3"** in the project. Otherwise, the compilation fails. For details, see [DevEco Studio build-profile.json5 File Description](https://developer.huawei.com/consumer/en/doc/harmonyos-guides-V5/ide-hvigor-build-profile-0000001778834297-V5#section511142752919). 10 11 12## Features 13 14With the lazy import, unnecessary files are not loaded in the cold start phase until these files are required during application running, shortening the time required for cold start. 15 16## How to Use 17 18You can use<!--Del-->[<!--DelEnd--> Trace<!--Del-->](https://gitee.com/openharmony/docs/blob/master/en/application-dev/performance/common-trace-using-instructions.md)<!--DelEnd--> tools or logs to identify files that are not actually called during cold start. By analyzing the data, you can accurately locate the files that do not need to be pre-loaded in the startup phase, and add the **lazy** identifier for the invoking points of these files. Notice that subsequent synchronous loading may block the task execution. (If a task is clicked and lazy import is triggered, the files that are not loaded will be executed in cold start, which increases the time consumption. Therefore, you need to evaluate whether to use the **lazy** identifier. 19 20> **NOTE** 21> 22> You are not advised to blindly add **lazy** identifiers, which also increases the identification overhead during building and running. 23 24## Scenario Behavior Analysis 25 26- Use lazy import. 27 28 ```typescript 29 // main.ets 30 import lazy { a } from "./mod1"; // "mod1" is not executed. 31 import { c } from "./mod2"; // "mod2" is executed. 32 33 // ... 34 35 console.log("main executed"); 36 while (false) { 37 let xx = a; 38 } 39 40 // mod1.ets 41 export let a = "mod1 executed" 42 console.log(a); 43 44 // mod2.ets 45 export let c = "mod2 executed" 46 console.log(c); 47 48 ``` 49 50 The output is as follows: 51 52 ```typescript 53 main executed 54 ``` 55 56- Reference lazy import and native import for the same module at the same time. 57 58 ```typescript 59 // main.ets 60 import lazy { a } from "./mod1"; // "mod1" is not executed. 61 import { c } from "./mod2"; // "mod2" is executed. 62 import { c } from "./mod2"; // "mod1" is executed. 63 64 // ... 65 66 console.log("main executed"); 67 while (false) { 68 let xx = a; 69 } 70 71 // mod1.ets 72 export let a = "mod1 a executed" 73 console.log(a); 74 75 export let b = "mod1 b executed" 76 console.log(b); 77 78 // mod2.ets 79 export let c = "mod2 c executed" 80 console.log(c); 81 82 ``` 83 84 The output is as follows: 85 86 ```typescript 87 mod2 c executed 88 mod1 a executed 89 mod1 b executed 90 main executed 91 ``` 92 93 If the keyword **lazy** is deleted from **main.ets** file, the execution sequence is as follows: 94 95 ```typescript 96 mod1 a executed 97 mod1 b executed 98 mod2 c executed 99 main executed 100 ``` 101 102## Specifications 103 104Lazy import supports the following instructions: 105 106| Syntax | ModuleRequest | ImportName | LocalName | Supported by API Version 12 | 107| :--------------------------------- | :------------ | :---------- | :---------- | :------------------- | 108| import lazy { x } from "mod"; | "mod" | "x" | "x" | Yes | 109| import lazy { x as v } from "mod"; | "mod" | "x" | "v" | Yes | 110 111### Negative Example 112 113Build error is reported if use the following syntax: 114 115```typescript 116 export lazy var v; // The compiler reports an application compilation error. 117 export lazy default function f(){}; // The compiler reports an application compilation error. 118 export lazy default function(){}; // The compiler reports an application compilation error. 119 export lazy default 42; // The compiler reports an application compilation error. 120 export lazy { x }; // The compiler reports an application compilation error. 121 export lazy { x as v }; // The compiler reports an application compilation error. 122 export lazy { x } from "mod"; // The compiler reports an application compilation error. 123 export lazy { x as v } from "mod"; // The compiler reports an application compilation error. 124 export lazy * from "mod"; // The compiler reports an application compilation error. 125 126 import lazy v from "mod"; // The compiler reports an application compilation error. 127 import lazy * as ns from "mod"; // The compiler reports an application compilation error. 128 129``` 130 131If the **type** keyword is added to the syntax, an error is reported. 132 133```typescript 134 import lazy type { obj } from "./mod"; // Not supported. The compiler reports an application compilation error. 135 import type lazy { obj } from "./mod"; // Not supported. The compiler reports an application compilation error. 136 137``` 138 139### Syntax Not Recommended 140 141- In the same ets file, not all the dependency modules that require the lazy import are added lazy identifiers. 142 143 Lazy import fails and the overhead of identifying lazy import increases because of the incomplete identifiers. 144 ```typescript 145 // main.ets 146 import lazy { a } from "./mod1"; // Obtain the object a from "mod1" and add a lazy identifier. 147 import { c } from "./mod2"; 148 import { b } from "./mod1"; // Obtain the attributes in "mod1". This syntax is not added a lazy identifier, so "mod1" is executed by default. 149 150 // ... 151 ``` 152 153- The shared module is lazy imported or the dependency path contains the shared module. 154 155 Lazy import still takes effect for the shared module. For details about the constraints, see [Shared Module Development](https://gitee.com/openharmony/docs/blob/master/en/application-dev/arkts-utils/arkts-sendable-module.md). 156 157- Currently, lazy import cannot be executed in kit. 158 159- Impact of lazy import. 160 * Side effect that does not require the module to execute occurs. 161 * When objects are exported, time required for the lazy import deteriorates corresponding features. 162 * Bugs occur when the **lazy** identifier is used but the module is not executed. 163 164 You need to evaluate the impact of using the lazy import. 165 166<!--no_check-->