MindSpore Lite is an AI engine that implements AI model inference for different hardware devices. It has been used in a wide range of fields, such as image classification, target recognition, facial recognition, and character recognition.
This document describes the general development process for implementing MindSpore Lite model inference. For details about how to use native APIs to implement model inference, see [Using MindSpore Lite for Model Inference](../napi/mindspore-lite-guidelines.md).
## Basic Concepts
Before getting started, you need to understand the following basic concepts:
**Tensor**: a special data structure that is similar to arrays and matrices. It is basic data structure used in MindSpore Lite network operations.
**Float16 inference mode**: a mode that uses half-precision inference. Float16 uses 16 bits to represent a number and therefore it is also called half-precision.
## Available APIs
APIs involved in MindSpore Lite model inference are categorized into context APIs, model APIs, and tensor APIs. For more APIs, see [@ohos.ai.mindSporeLite](../reference/apis/js-apis-mindSporeLite.md).
| API | Description |
| ------------------ | ----------------- |
|loadModelFromFile(model: string, options: Context): Promise<Model>|Loads a model from a file.|
|getInputs(): MSTensor[]|Obtains the model input.|
|predict(inputs: MSTensor[]): Promise<MSTensor>|Performs model inference.|
| getData(): ArrayBuffer | Obtains tensor data.|
| setData(inputArray: ArrayBuffer): void | Sets the tensor data.|
## How to Develop
The development process consists of the following main steps:
1. Prepare the required model. You can download the required model directly or obtain the model by using the model conversion tool. The required data is read from the `bin` file.
- If the downloaded model is in the `.ms` format, you can use it directly for inference. This document uses `mnet.caffemodel.ms` as an example.
- If the downloaded model uses a third-party framework, such as TensorFlow, TensorFlow Lite, Caffe, or ONNX, you can use the [model conversion tool](https://www.mindspore.cn/lite/docs/en/r2.0/use/downloads.html#1-8-1) to convert it to the `.ms` format.
2. Create a context, and set parameters such as the number of runtime threads and device type.
3. Load the model. In this example, the model is read from the file.
4. Load data. Before executing a model, you need to obtain the model input and then fill data in the input tensor.
5. Perform inference and print the output. Call the **predict** API to perform model inference.
$ hdc shell aa start -a EntryAbility -b com.example.myapptfjs
```
2. Use the hdc tool to connect to the rk3568 development board and push `mnet.caffemodel.ms` to the sandbox directory on the device. `mnet\_caffemodel\_nhwc.bin` is stored in the `rawfile` directory of the local project.
3. Click **Test\_MSLiteModel\_predict** on the screen of the rk3568 development board to run the test case. The following information is displayed in the HiLog printing result:
```shell
08-27 23:25:50.278 31782-31782/? I C03d00/JSAPP: =========MSLITE predict start=====
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: 0.10046602040529252
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: 0.07535600662231445
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: 0.06326554715633392
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: 0.0015114173293113708
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: -0.026745859533548355
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: -0.055590517818927765
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: -0.05325715243816376
08-27 23:25:51.487 31782-31782/? I C03d00/JSAPP: -0.04629542678594589
...
08-27 23:25:52.881 31782-31782/? I C03d00/JSAPP: 0.23317644000053404
08-27 23:25:52.881 31782-31782/? I C03d00/JSAPP: 0.17999525368213654
08-27 23:25:50.372 31782-31782/? I C03d00/JSAPP: =========MSLITE predict success=====
hiTraceMeter provides APIs for system performance tracing. You can call the APIs provided by the hiTraceMeter module in your own service logic to effectively track service processes and check the system performance.
> **NOTE**
> - This development guide is applicable only when you use Native APIs for application development. For details about APIs, see [API Reference](../reference/native-apis/_hitrace.md).
> - For details about how to use ArkTS APIs for application development, see [Development Guidelines](hitracemeter-guidelines.md) and [API Reference](../reference/apis/js-apis-hitracemeter.md).
## Available APIs
| API| Description|
| -------- | -------- |
| void OH_HiTrace_StartTrace(const char* name) | Starts a synchronous time slice trace.|
| void OH_HiTrace_FinishTrace() | Ends a synchronous time slice trace.|
| void OH_HiTrace_StartAsyncTrace(const char* name, int32_t taskId) | Starts an asynchronous time slice trace.|
| void OH_HiTrace_FinishAsyncTrace(const char* name, int32_t taskId) | Ends an asynchronous time slice trace.|
| taskId | number | No | ID used to indicate the association of APIs in a trace. If multiple traces with the same name need to be performed at the same time or a trace needs to be performed multiple times concurrently, different task IDs must be specified in **startTrace**.|
| count | number | No | Value of the variable. |
## Development Example
1. Add the link of **libhitrace_ndk.z.so** to **CMakeLists.txt**.
```
target_link_libraries(entry PUBLIC libhitrace_ndk.z.so)
```
2. Reference the **hitrace** header file in the source file.
```c++
#include "hitrace/trace.h"
```
3. Open the hdc shell and run the **hitrace --trace_begin app** command to enable the trace function.
```shell
capturing trace...
```
4. Perform a performance trace. The following uses asynchronous trace as an example.
```c++
OH_HiTrace_StartAsyncTrace("hitraceTest",123);
OH_HiTrace_FinishAsyncTrace("hitraceTest",123);
```
5. Run the **hitrace --trace_dump | grep hitraceTest** command to view the trace result.
@@ -85,7 +85,7 @@ The development process consists of the following main steps:
The required model can be downloaded directly or obtained using the model conversion tool.
- If the downloaded model is in the `.ms` format, you can use it directly for inference. The following uses the **mobilenetv2.ms** model as an example.
- If the downloaded model uses a third-party framework, such as TensorFlow, TensorFlow Lite, Caffe, or ONNX, you can use the [model conversion tool](https://www.mindspore.cn/lite/docs/zh-CN/r1.5/use/downloads.html#id1) to convert it to the .ms format.
- If the downloaded model uses a third-party framework, such as TensorFlow, TensorFlow Lite, Caffe, or ONNX, you can use the [model conversion tool](https://www.mindspore.cn/lite/docs/en/r1.5/use/downloads.html#id1) to convert it to the .ms format.
2. Create a context, and set parameters such as the number of runtime threads and device type.
...
...
@@ -280,7 +280,3 @@ The development process consists of the following main steps:
The following sample is provided to help you better understand how to use MindSpore Lite:
-[Simple MindSpore Lite Tutorial](https://gitee.com/openharmony/third_party_mindspore/tree/OpenHarmony-3.2-Release/mindspore/lite/examples/quick_start_c)
hiTraceMeter provides APIs for system performance tracing.
You can call the APIs provided by hiTraceMeter in your own service logic to effectively track service processes and check the system performance.
\@syscap SystemCapability.HiviewDFX.HiTrace
**Since**
10
## Summary
### File
| Name| Description|
| -------- | -------- |
| [trace.h](trace_8h.md) | Defines APIs of the HiTraceMeter module for performance trace.<br>**File to include**: <hitrace/trace.h><br>**Library**: libhitrace_ndk.z.so|
### Functions
| Name| Description|
| -------- | -------- |
| [OH_HiTrace_StartTrace](#oh_hitrace_starttrace)(const char \*name) | Marks the start of a synchronous trace.|
| [OH_HiTrace_FinishTrace](#oh_hitrace_finishtrace)(void) | Marks the end of a synchronous trace.|
| [OH_HiTrace_StartAsyncTrace](#oh_hitrace_startasynctrace)(const char \*name, int32_t taskId) | Marks the start of an asynchronous trace.|
| [OH_HiTrace_FinishAsyncTrace](#oh_hitrace_finishasynctrace)(const char \*name, int32_t taskId) | Marks the end of an asynchronous trace.|
| [OH_HiTrace_CountTrace](#oh_hitrace_counttrace)(const char \*name, int64_t count) | Traces the value change of an integer variable based on its name.|
This API is called in the callback function after an asynchronous trace is complete. It is used with **OH_HiTrace_StartAsyncTrace** in pairs. Its name and task ID must be the same as those of **OH_HiTrace_StartAsyncTrace**.
**Parameters**
| Name| Description|
| -------- | -------- |
| name | Name of the asynchronous trace.|
| taskId | ID of the asynchronous trace. The start and end of an asynchronous trace task do not occur in sequence. Therefore, the start and end of an asynchronous trace need to be matched based on the task name and the unique task ID together.|
**Since**
10
### OH_HiTrace_FinishTrace()
```
void OH_HiTrace_FinishTrace (void )
```
**Description**
Marks the end of a synchronous trace.
This API must be used with **OH_HiTrace_StartTrace** in pairs. During trace data parsing, the system matches it with the **OH_HiTrace_StartTrace** API recently invoked in the service process.
This API is called to implement performance trace in asynchronous manner. The start and end of an asynchronous trace task do not occur in sequence. Therefore, a unique **taskId** is required to ensure proper data parsing. It is passed as an input parameter for the asynchronous API. This API is used with **OH_HiTrace_FinishAsyncTrace** in pairs. The two APIs that have the same name and task ID together form an asynchronous trace. If multiple trace tasks with the same name need to be performed at the same time or a trace task needs to be performed multiple times concurrently, different task IDs must be specified in **OH_HiTrace_StartTrace**. If the trace tasks with the same name are not performed at the same time, the same taskId can be used.
**Parameters**
| Name| Description|
| -------- | -------- |
| name | Name of an asynchronous trace.|
| taskId | ID of the asynchronous trace. The start and end of an asynchronous trace task do not occur in sequence. Therefore, the start and end of an asynchronous trace need to be matched based on the task name and the unique task ID together.|
**Since**
10
### OH_HiTrace_StartTrace()
```
void OH_HiTrace_StartTrace (const char * name)
```
**Description**
Marks the start of a synchronous trace.
This API is used with **OH_HiTrace_FinishTrace** in pairs. The two APIs can be used in nested mode. The stack data structure is used for matching during trace data parsing.
| [OH_HiTrace_StartTrace](_hitrace.md#oh_hitrace_starttrace)(const char \*name) | Marks the start of a synchronous trace.|
| [OH_HiTrace_FinishTrace](_hitrace.md#oh_hitrace_finishtrace)(void) | Marks the end of a synchronous trace.|
| [OH_HiTrace_StartAsyncTrace](_hitrace.md#oh_hitrace_startasynctrace)(const char \*name, int32_t taskId) | Marks the start of an asynchronous trace.|
| [OH_HiTrace_FinishAsyncTrace](_hitrace.md#oh_hitrace_finishasynctrace)(const char \*name, int32_t taskId) | Marks the end of an asynchronous trace.|
| [OH_HiTrace_CountTrace](_hitrace.md#oh_hitrace_counttrace)(const char \*name, int64_t count) | Traces the value change of an integer variable based on its name.|
@@ -26,7 +26,7 @@ For details about the requirements on the Linux environment, see [Quick Start](.
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate thermal log customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
1. Create the thermal folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default thermal log configuration folder](https://gitee.com/openharmony/drivers_peripheral/tree/master/thermal/interfaces/hdi_service/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
...
...
@@ -50,8 +50,6 @@ The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/ma
| Configuration Item| Description| Data Type| Value Range|
| -------- | -------- | -------- | -------- |
| interval | Interval for recording temperature tracing logs, in ms.| int | >0 |
| width | Width of the temperature tracing log, in characters.| int | >0 |
| outpath | Path for storing temperature tracing logs.| string | N/A|
**Table 2** Description of the node configuration
...
...
@@ -63,7 +61,7 @@ The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/ma
| value | path | Path for obtaining the thermal zone temperature.|
6. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/interfaces/hdi_service/profile/BUILD.gn) file in the default thermal log configuration folder to pack the `thermal_hdi_config.xml` file to the `//vendor/etc/thermal_config/hdf` directory. The configuration is as follows:
6. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/interfaces/hdi_service/profile/BUILD.gn) file in the default thermal log configuration folder to pack the thermal_hdi_config.xml file to the `//vendor/etc/thermal_config/hdf` directory. The configuration is as follows:
```shell
import("//build/ohos.gni")
...
...
@@ -97,7 +95,7 @@ The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/ma
ohos_prebuilt_etc("thermal_hdf_config") {
source = "thermal_hdi_config.xml"
relative_install_dir = "thermal_config/hdf"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_hdi_config.xml file in the vendor directory.
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_service_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
...
...
@@ -151,7 +149,7 @@ The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/ma
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` and `etc` are folder names, and `thermal_hdf_config` and `param_files` are the build targets.
In the preceding code, //vendor/hihope/rk3568/thermal/ is the folder path, profile and etc are folder names, and thermal_hdf_config and param_files are the build targets.
9. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
| ArkUI | UX changed | [The hover effect of the \<Button> component is changed from scale-up by 100% to 105% to overlay of 0% to 5% opacity.](changelogs-arkui.md)|
| ArkUI | UX changed | [The alignment mode of multi-line text in toasts is changed from center-aligned to left-aligned.](changelogs-arkui.md)|
| Bundle management subsystem | Mechanism changed | [The HAP is no longer decompressed during HAP installation.](changelogs-bundlemanager.md)|
| Globalization | API added | [The getStringSync and getStringByNameSync APIs are added.](changelogs-global.md)|
| Globalization | Behavior changed | [The meaning of the return value for the API used to obtain the rawfile descriptor is changed.](changelogs-global.md)|
| Security-HUKS | Behavior changed | [HuksKeyStorageType must be passed in for key derivation or key agreement.](changelogs-huks.md) |
| Security-HUKS | Behavior changed | [Permission is required for Using attestKeyItem.](changelogs-huks.md) |
| Web | Input parameter added | [The input parameter type Resource is added for the setResponseData API.](changelogs-web.md) |
