diff --git a/en/application-dev/windowmanager/window-guidelines.md b/en/application-dev/windowmanager/window-guidelines.md index 3dbbb4b74066f85a609c53a5a5a1206834c7a8ba..e312f4c415e9067f42ef632a99b73fa853357bdf 100644 --- a/en/application-dev/windowmanager/window-guidelines.md +++ b/en/application-dev/windowmanager/window-guidelines.md @@ -12,7 +12,7 @@ For details about the APIs, see [Window](../reference/apis/js-apis-window.md). | API | Description | | :----------------------------------------------------------- | :--------------------------------------------- | | create(id: string, type: WindowType, callback: AsyncCallback\): void | Creates a subwindow. | -| moveTo(x: number, y: number): Promise\ | Moves the window position. A positive value of **x** indicates that the window moves to the right, and a positive value of **y** indicates that the window moves downwards.| +| moveTo(x: number, y: number): Promise\ | Moves the window. A positive value of **x** indicates that the window moves to the right, and a positive value of **y** indicates that the window moves downwards.| | resetSize(width: number, height: number): Promise\ | Changes the window size. | | hide(): Promise\ | Hides the window. | | destroy(): Promise\ | Destroys the window. | diff --git a/en/application-dev/windowmanager/window-overview.md b/en/application-dev/windowmanager/window-overview.md index 170a6eaf76ac73b33b73355ad0039d8d76617ab3..8e776a43741d11ca3bb1d047f3ea5d330fd90586 100644 --- a/en/application-dev/windowmanager/window-overview.md +++ b/en/application-dev/windowmanager/window-overview.md @@ -1,13 +1,13 @@ # Window Overview The Window Manager subsystem provides basic capabilities of window management. It is the basis for UI display. -The Window Manager subsystem enables multiple applications to use the same physical screen for display and interaction. For each application, you need to design the interaction interface in the fixed window area. A window acts as a display container of the application interface, and the Window Manager subsystem organizes the interaction interfaces into a form visible to end users. +The Window Manager subsystem enables multiple applications to simultaneously display on the same screen and interact with users. For each application, you need to design the interaction interface in the fixed window area. A window acts as a display container of the application UI, and the Window Manager subsystem organizes the interaction UIs into a form visible to end users. ## Basic Concepts -** Immersive**: The colors of the application interface, status bar, and navigation bar are the same to achieve the visual integrity. +**Immersive**: The colors of the application UI, status bar, and navigation bar are the same to achieve the visual integrity. ## Working Principles -To display a UI on a screen, the application and system need to request a window object from the Window Manager subsystem. This object generally represents a rectangular area on the screen and has attributes such as the position, width, height, and overlay layer. The object also loads the root node of the UI framework in the interface. The UI of the application is loaded and displayed in the window through the root node. +To display a UI on a screen, the application and system need to request a window object from the Window Manager subsystem. This object generally represents a rectangular area on the screen and has attributes such as the position, width, height, and overlay layer. The object also loads the root node of the UI framework, through which the application UI is loaded and displayed in the window. diff --git a/en/readme/ARK-Runtime-Subsystem.md b/en/readme/ARK-Runtime-Subsystem.md index 442914d30a797fa96c93b2f156662f00eac9298a..b6b996810926a8694574e94a2c24cfc537bbe6ba 100644 --- a/en/readme/ARK-Runtime-Subsystem.md +++ b/en/readme/ARK-Runtime-Subsystem.md @@ -1,6 +1,6 @@ # ArkCompiler JS Runtime -Introduction +## Introduction ArkCompiler is a built-in componentized and configurable multi-language compilation and runtime platform of OpenHarmony. It contains core components such as the compiler, toolchain, and runtime. It supports compilation and running of high-level programming languages on the multi-chip platform. It accelerates the running of the OpenHarmony standard operating system and its applications and services on mobile phones, PCs, tablets, TVs, automobiles, and smart wearables. ArkCompiler JS Runtime provides the capability of compiling and running the JavaScript (JS) language on the OpenHarmony operating system. @@ -33,7 +33,7 @@ ArkCompiler JS Runtime consists of four subsystems: JS Compiler Subsystem consists of the Stub compiler, optimized compilation framework based on the Circuit IR, and code generator. - JS Runtime subsystem - + JS Runtime Subsystem contains various modules related to JS runtime: - Memory management: object allocator and garbage collector (CMS-GC and Partial-Compressing-GC for concurrent marking and partial memory compression) - Analysis tools: DFX tool and CPU and heap profiling tool @@ -49,16 +49,16 @@ ArkCompiler JS Runtime consists of four subsystems: - Native support for TS. The common way to process TS in the industry is to convert TS into JS and execute JS code with JS runtime. ts2abc is planned to analyze and obtain the TS type information when compiling the TS source code and send the information to ArkCompiler JS Runtime. ArkCompiler JS Runtime directly uses the type information to statically generate inline caching to accelerate bytecode execution. The TS Ahead of Time (AOT) compiler directly converts the source code into high-quality machine code based on the TS type information sent from ts2abc, which greatly improves the running performance. -- Lightweight Actor concurrency model: ECMAScript does not provide concurrency specifications. The Actor concurrency model is commonly used in JS engines in the industry to implement concurrent processing. In this model, executors do not share data and communicate with each other using the messaging mechanism. The JS Actor model (web-worker) in the industry has defects such as slow startup and high memory usage. ArkCompiler JS Runtime is required to provide the Actor implementation that features fast startup and low memory usage to better leverage the device's multi-core feature to improve performance. Now ARK-JS is able to share immutable objects, methods, and bytecodes (built-in code blocks and constant strings in the future) in Actor instances based on the Actor memory isolation model to accelerate the startup of JS Actor, reduce memory overhead, and implement the lightweight Actor concurrency model. +- Lightweight Actor concurrency model: ECMAScript does not provide concurrency specifications. The Actor concurrency model is commonly used in JS engines in the industry to implement concurrent processing. In this model, executors do not share data and communicate with each other using the messaging mechanism. The JS Actor model (web-worker) in the industry has defects such as slow startup and high memory usage. ArkCompiler JS Runtime is required to provide the Actor implementation that features fast startup and low memory usage to better leverage the device's multi-core feature to improve performance. Now ArkCompiler JS Runtime is able to share immutable objects, methods, and bytecodes (built-in code blocks and constant strings in the future) in Actor instances based on the Actor memory isolation model to accelerate the startup of JS Actor, reduce memory overhead, and implement the lightweight Actor concurrency model. -- Cross-language interaction of TS/C++: In the API implementation, it is common for C/C++ code to access and operate TS objects in OpenHarmony. ArkCompiler JS Runtime is planned to statically generate a C/C++ header file that contains the TS object layout description and the C/C++ implementation library for operating the TS object based on the class declaration and runtime conventions in the TS program. The C/C++ code usually includes the TS object layout description header file and the corresponding implementation library to implement the direct operation on the TS object. The TS type or its internal layout is not always fixed. Therefore, in the code implementation for TS object operations, type check is used. If the object type or layout changes during runtime, the common slow path is rolled back. +- Cross-language interaction of TS and C++: In the API implementation, it is common for C/C++ code to access and operate TS objects in OpenHarmony. ArkCompiler JS Runtime is planned to statically generate a C/C++ header file that contains the TS object layout description and the C/C++ implementation library for operating the TS object based on the class declaration and runtime conventions in the TS program. The C/C++ code usually includes the TS object layout description header file and the corresponding implementation library to implement the direct operation on the TS object. The TS type or its internal layout is not always fixed. Therefore, in the code implementation for TS object operations, type check is used. If the object type or layout changes during runtime, the common slow path is rolled back. ## Directory Structure ``` /ark ├── js_runtime # JS runtime module -├── runtime_core # Runtime common module +├── runtime_core # Runtime core subsystem └── ts2abc # JS frontend tool ```