Smartperf-Host is an intuitive performance and power optimization tool that offers in-depth data mining and fine-grained data visualization. In this tool, you can gain visibility into a multitude of metrics in terms of CPU scheduling, frequency, process and thread time slices, heap memory, frame rate, and more, in swimlanes. Better yet, you can analyze the collected data intuitively on the GUI.
While OpenHarmony provides default UX styles for window title bars, it allows device vendors to develop custom window title bars to meet specific needs.
## Development Guidelines
### How to Develop
Perform the following steps:
1. In **MaximizeMode** (in **frameworks/core/components/common/layout/constants.h**), define the enums, for example, **MODE_AVOID_SYSTEM_BAR** and **MODE_FULL_FILL**.
```cpp
enumclassMaximizeMode:uint32_t{
MODE_AVOID_SYSTEM_BAR,
MODE_FULL_FILL,
MODE_RECOVER,
};
```
2. In **ContainerModalViewFactory::GetView** (in **foundation/arkui/ace_engine/frameworks/core/components_ng/pattern/container_modal/container_modal_view_factory.h**), add the creation of the custom window title bar based on the current value of **MaximizeMode**.
In the preceding example, vendor enhance creates a custom title bar branch based on the value of **MaximizeMode** (**MaximizeMode::MODE_AVOID_SYSTEM_BAR** or **MaximizeMode::MODE_FULL_FILL**).
3. Create a folder in the **foundation/arkui/ace_engine/frameworks/core/components_ng/pattern/container_modal** directory to store your custom title bar code.
> The structure of the **container_modal** folder is as follows:
```shell
├── container_modal_accessibility_property.cpp
├── container_modal_accessibility_property.h
├── container_modal_pattern.cpp
├── container_modal_pattern.h
├── container_modal_view.cpp
├── container_modal_view_factory.h
├── container_modal_view.h
└── enhance
├── container_modal_pattern_enhance.cpp
├── container_modal_pattern_enhance.h
├── container_modal_view_enhance.cpp
└── container_modal_view_enhance.h
```
The **container_modal_\*** files in the **container_modal** folder contain the code related to the default title bar view. You can add your custom code files in the created folder, **enhance** in this example.
4. Complete build configuration for the new .cpp files in **foundation/arkui/ace_engine/frameworks/core/components_ng/pattern/BUILD.gn**.
When your development of the custom title bar is complete, debug and verify the title bar.
### Debugging and Verification
Before the verification, prepare the following files (which must be stored in the same path):
> The **window_manager_config_open.xml** file contains various configuration items. Before the verification, you must change the default value of **MaximizeMode** to the one you have defined, that is, the value obtained by **MaximizeMode maximizeMode = GetWindowManager()->GetWindowMaximizeMode()**. The system loads the corresponding title bar according to the value.
Then, debug the custom title bar as follows:
1. Burn the image that contains the custom title bar code to the device.
2. Run the **open_maximize.bat** script.
3. Run the demo to check whether the title bar works properly.
The Distributed Manager Service sets up a distributed service platform in OpenHarmony by using a proxy between the primary and secondary devices. With the Distributed Manager Service, the primary device \(OpenHarmony-powered smart TV\) can start a Feature Ability \(FA\) deployed on the secondary device \(a memory-constrained OpenHarmony device such as an IP camera or a lite wearable\).
For example, if a user presses the **Remind Me** button for a TV program on the smart TV, the smart TV will start the corresponding reminder FA on the lite wearable to remind the user when the particular TV program is available.
## Basic Concepts<a name="section982651246"></a>
- FA
Feature Ability, representing an ability with a UI for interacting with users
- Remote startup
Cross-device FA startup, which is the counterpart of local FA startup
## Available APIs<a name="section125479541744"></a>
The following table describes the API that can be used by smart TVs to remotely start an FA. This API is provided in the **AbilitySlice** class. For details, see the Java API reference for OpenHarmony application development.
**Table 1** API for remotely starting an FA on the distributed network
<tdclass="cellrowborder"valign="top"width="42.61%"headers="mcps1.2.3.1.2 "><pid="p13562171015712"><aname="p13562171015712"></a><aname="p13562171015712"></a>Remotely starts an FA based on the specified <strongid="b8984536181113"><aname="b8984536181113"></a><aname="b8984536181113"></a>Want</strong> information. If the name and type of the <strongid="b599520304618"><aname="b599520304618"></a><aname="b599520304618"></a>want</strong> parameter are different from those used in the integrated development environment (IDE), use the parameter name and type in the IDE.</p>
<tdclass="cellrowborder"valign="top"width="69%"headers="mcps1.2.4.1.3 "><pid="p10555172211377"><aname="p10555172211377"></a><aname="p10555172211377"></a>When you use <strongid="b1013275220199"><aname="b1013275220199"></a><aname="b1013275220199"></a>startAbility(Want want)</strong> to remotely start an FA, you must first specify the <strongid="b1125035416223"><aname="b1125035416223"></a><aname="b1125035416223"></a>deviceId</strong>, <strongid="b16473135811222"><aname="b16473135811222"></a><aname="b16473135811222"></a>bundleName</strong>, and <strongid="b157931324230"><aname="b157931324230"></a><aname="b157931324230"></a>abilityName</strong> attributes of the target FA in the <strongid="b34832152239"><aname="b34832152239"></a><aname="b34832152239"></a>Want</strong> object.</p>
</td>
</tr>
</tbody>
</table>
## Limitations and Constraints<a name="section1165911177314"></a>
- The primary device can remotely start an FA of the secondary device, but the secondary device cannot remotely start an FA of the primary device.
- Before the remote startup, ensure that the two OpenHarmony devices are on the same network segment and can ping each other on the distributed network. Otherwise, the remote startup fails.
- Currently, only the FAs that have the same public key \(that is, the same Huawei certificate\) can be started between the primary and secondary devices.
## How to Develop<a name="section34171333656"></a>
To enable the primary device \(smart TV\) to start an FA of the secondary device \(assuming that the target FA has been developed\), perform the following steps:
1. Complete FA development for the smart TV on DevEco Studio.
2. Obtain the IDs of online secondary devices.
```
// Import the header files required for device selection.
remote_device_id = deviceInfoListOnline[0].GetDeviceId(); // Obtain the ID of the first device in the online device list.
}
```
3. Create a **Want** instance. You should first create an **ElementName** object with **deviceId**, **bundleName**, **abilityName** specified and add this object to the **Want** instance. Then, set the multi-device startup flag **Want.FLAG\_ABILITYSLICE\_MULTI\_DEVICE** to the **Want** instance to enable remote FA startup.
```
// Import related header files.
import ohos.aafwk.ability.Ability;
import ohos.aafwk.content.Want;
import ohos.bundle.ElementName;
// Start the remote FA on the secondary device.
Want want = new Want(); // Create a Want instance that encapsulates information about the remote FA to start.
// Use the device ID obtained in step 2 and specify the FA information.
ElementName name = new ElementName(remote_device_id, "com.huawei.remote_package_name", "remote_class_name");
want.setElement(name); // Add information about the target FA for startup to the Want instance.
want.setFlags(Want.FLAG_ABILITYSLICE_MULTI_DEVICE); // Set the multi-device startup flag. If this flag is not set, remote FA startup will be unavailable.
startAbility(want); // Start the specified FA based on the want parameter. If the name and type of the want parameter are different from those used in the IDE, use the parameter name and type in the IDE.
