@@ -6,7 +6,7 @@ Following these practices, you can reduce your application's startup time, respo
- Improving application startup and response time
-[Speeding Up Application Cold Start](../performance/improve-application-startup-and-response/improve-application-cold-start-speed.md)
-[Speeding Up Application Cold Start](improve-application-startup-and-response/improve-application-cold-start-speed.md)
Application startup latency is a key factor that affects user experience. To speed up the application cold start, you are advised to perform optimization in the following four phases:
...
...
@@ -18,16 +18,16 @@ Following these practices, you can reduce your application's startup time, respo
4. Home page loading and drawing
-[Speeding Up Application Response](../performance/improve-application-startup-and-response/improve-application-response.md)
-[Speeding Up Application Response](improve-application-startup-and-response/improve-application-response.md)
A premium interaction experience requires quick response to user input. To improve your application's response time, you are advised to prevent the main thread from being blocked by non-UI tasks and reduce the number of component to be refreshed.
A premium interaction experience requires quick response to user input. To improve your application's response time, you are advised to prevent the main thread from being blocked by non-UI tasks and reduce the number of components to be refreshed.
The smoothness of rendering the layout to the screen affects the user perceived quality. It is recommended that you minimize nesting in your code to shorten the render time.
Whether animations in your application run smoothly is a key factor that affects user experience. You are advised to use the system-provided animation APIs to reduce frame loss.
@@ -4,7 +4,7 @@ Application startup latency is a key factor that affects user experience. When a
## Analyzing the Time Required for Application Cold Start
The cold start process of OpenHarmony applications can be divided into four phases: application process creation and initialization, application and ability initialization, ability lifecycle, and home page loading and drawing, as shown in the following figure.
The cold start process of OpenHarmony applications can be divided into four phases: application process creation and initialization, application and ability initialization, ability lifecycle, and home page loading and drawing, as shown below.
@@ -43,7 +43,7 @@ With regard to the icon of the startup page, the recommended maximum resolution
## 2. Shortening Time Required for Application and Ability Initialization
In this phase of application and ability initialization, resources are loaded, VMs are created, application and ability related objects are created and initialized, and dependent modules are loaded.
In this phase of application and ability initialization, resources are loaded, virtual machines are created, application and ability related objects are created and initialized, and dependent modules are loaded.
### Minimizing the Number of Imported Modules
...
...
@@ -57,7 +57,7 @@ In this phase of ability lifecycle, the ability lifecycle callbacks are executed
In the application startup process, the system executes the ability lifecycle callbacks. Whenever possible, avoid performing time-consuming operations in these callbacks. You are advised to perform time-consuming operations through asynchronous tasks or execute them in other threads.
In these lifecycle callbacks, perform only necessary operations. For details, see [UIAbility Lifecycle](https://gitee.com/openharmony/docs/blob/master/en/application-dev/application-models/uiability-lifecycle.md).
In these lifecycle callbacks, perform only necessary operations. For details, see [UIAbility Lifecycle](../../application-models/uiability-lifecycle.md).
## 4. Shortening Time Required for Home Page Loading and Drawing
Compared with the worker thread, [TaskPool](https://gitee.com/sqsyqqy/docs/blob/master/en/application-dev/reference/apis/js-apis-taskpool.md) provides the task priority setting and automatic thread pool management mechanism. The following is an example:
Compared with the worker thread, [TaskPool](../../reference/apis/js-apis-taskpool.md) provides the task priority setting and automatic thread pool management mechanism. The following is an example:
For more details, see [Property Animator](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/arkui-ts/ts-animatorproperty.md).
For more details, see [Property Animation](../../reference/arkui-ts/ts-animatorproperty.md).
## Using System-Provided Explicit Animation APIs
...
...
@@ -139,4 +139,4 @@ struct AnimateToExample {
}
```
For more details, see [Explicit Animation](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/arkui-ts/ts-explicit-animation.md).
For more details, see [Explicit Animation](../../reference/arkui-ts/ts-explicit-animation.md).
@@ -412,12 +415,14 @@ The test framework supports multiple types of tests and provides different test
factorial_test();
printf("Factorial_test_002 END\n");
}
// Add the multi-thread API MTEST_ADD_TASK(THREAD_ID,ThreadTestFunc). Multiple threads are registered but are not executed in this test case. Instead, they are executed later in a unified manner. This API is applicable to the multi-thread test in the scenario where multiple test cases are combined.
// THREAD_ID is used to distinguish threads and starts from 0. You can also use a random thread ID by passing in RANDOM_THREAD_ID. In this scenario, each thread ID is unique.
// Add the multi-thread API MTEST_POST_RUN() to execute the previously registered threads in a unified manner.
// Add the multi-thread API MTEST_ADD_TASK(THREAD_ID,ThreadTestFunc). Multiple threads are registered but are not executed in this test case. Instead, they are executed later in a unified manner. This API is applicable to the multi-thread test in the scenario where multiple test cases are combined.
// THREAD_ID is used to distinguish threads and starts from 0. You can also use a random thread ID by passing in RANDOM_THREAD_ID. In this scenario, each thread ID is unique.
// Add the multi-thread API MTEST_POST_RUN() to execute the previously registered threads in a unified manner.
```
> **NOTE**<br>The comments for multi-thread test cases are the same as those of single-thread test cases.
> **NOTE**
>
> The comments for multi-thread test cases are the same as those of single-thread test cases.
- About C++ test case templates:
The following test case templates are provided for your reference.
...
...
@@ -590,7 +595,7 @@ The test framework supports multiple types of tests and provides different test
> - Use the **ohos_js_unittest** template to define the JavaScript test suite. Pay attention to the difference between JavaScript and C++.
> - The file generated for the JavaScript test suite must be in .hap format and named after the test suite name defined here. The test suite name must end with **JsTest**.
...
...
@@ -861,7 +866,7 @@ The following provides templates for different languages for your reference.
>- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory. **preparer** indicates the action to perform before the test suite is executed.
>- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory. **src="out"** indicates that the test resources are in the **out/release/$(*part*)** directory.
...
...
@@ -1103,7 +1108,7 @@ Before executing test cases, you need to modify the configuration in **developer
> If HDC is connected to the device before the test cases are executed, you only need to configure the device IP address and port number, and retain the default settings for other parameters.
...
...
@@ -1115,7 +1120,7 @@ Test cases cannot be built on Windows. You need to run the following command to
>- **product-name**: specifies the name of the product to be compiled.
>- **build-target**: specifies the test case to build. **make_test** indicates all test cases. You can specify the test cases based on requirements.
...
...
@@ -1127,7 +1132,7 @@ When the build is complete, the test cases are automatically saved in **out/ohos
2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory.
| log/plan_log_xxxx_xx_xx_xx_xx_xx.log | Test case logs. |
| summary_report.html | Test report summary. |
| details_report.html | Detailed test report. |
| log/plan_log_xxxx_xx_xx_xx_xx_xx.log | Test case logs. |
| summary_report.html | Test report summary. |
| details_report.html | Detailed test report. |
...
...
@@ -1372,6 +1377,7 @@ When GCDA data is available, you can execute the test cases as follows for subsy
run -tp partname
run -tp partname1 partname2
2. Before compiling the version, modify the compilation options. Add **-- coverage** to the **cflags**, **cflags_cc**, and **ldflags** options in the **build.gn** file of the involved subsystem.
ldflags = [ "--coverage" ]
...
...
@@ -1379,6 +1385,7 @@ When GCDA data is available, you can execute the test cases as follows for subsy
C++: cflags_cc = [ "--coverage" ]
**Recommended**: You can also refer to the mode for the window subsystem. For details, see the files in this [pull request](https://gitee.com/openharmony/window_window_manager/pulls/1274/files).
3. To execute coverage test cases, perform the following to install the dependencies:
1. Run the **sudo apt install lcov** command to install lcov.
...
...
@@ -1403,7 +1410,9 @@ When GCDA data is available, you can execute the test cases as follows for subsy
run -t UT -ss *Subsystem name* -tp **Part name** -cov coverage
run -t UT MST ST -tp *Part name* -cov coverage
Note: The **-cov coverage** parameter must be added to the preceding commands.
> **NOTE**
>
> The **-cov coverage** parameter must be added to the preceding commands.
6. Obtain the coverage report from the following paths:
