@@ -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).
> The value of **@tc.require** must start with AR/SR or issue, for example, **issueI56WJ7**.
- The following uses base_object_test.cpp as an example to describe how to compile a multi-thread test case:
- The following uses **base_object_test.cpp** as an example to describe how to compile a multi-thread test case:
```
// The test case file header comment and test case comment are the same as those in the single-thread test case example.
...
...
@@ -345,9 +345,10 @@ The test framework supports multiple types of tests and provides different test
The procedure is as follows:
1. Add comment information to the test case file header.
> **NOTE**<br>The standard is the same as that of the single-thread test case.
> **NOTE**
>
> The standard is the same as that of the single-thread test case.
2. Add the test framework header file and namespace.
```
#include <gtest/gtest.h>
#include <gtest/hwext/gtest-multithread.h>
...
...
@@ -364,9 +365,11 @@ The test framework supports multiple types of tests and provides different test
class AAFwkBaseObjectTest : public testing::Test {......}
```
> **NOTE**<br>The standard is the same as that of the single-thread test case.
5. Add implementation of the test cases, including test case comments and logic.
> **NOTE**
>
> The standard is the same as that of the single-thread test case.
```
// Step 1 Set the function to be tested to return the factorial result.
...
...
@@ -416,7 +419,9 @@ The test framework supports multiple types of tests and provides different test
// 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:
...
...
@@ -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.
> The test report folder is automatically generated.
...
...
@@ -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:
