-
Notifications
You must be signed in to change notification settings - Fork 177
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'origin/2022' into _organizing_intro
- Loading branch information
Showing
4 changed files
with
49 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,37 +1,65 @@ | ||
## Component lifecycle | ||
<!-- ## Component lifecycle --> | ||
## 组件生命周期 | ||
|
||
<!-- | ||
Component instances are created and destroyed when they are added and removed | ||
in the component topology. This can happen in one of two ways: | ||
--> | ||
在组件拓扑中添加和移除组件实例时,会创建和销毁组件实例。这可以通过以下两种方式之一发生: | ||
|
||
<!-- | ||
* **Statically**: The instance is declared in the component manifest as a child | ||
of another component in the tree. Static components are only created and | ||
destroyed when an update changes the component topology. | ||
--> | ||
* **静态地**:该实例在组件清单中被声明为树中另一个组件的子组件。静态组件仅当一个更新改变了组件拓扑时才会创建和销毁。 | ||
<!-- | ||
* **Dynamically**: The instance is added or removed in a component `collection` | ||
at runtime using the `fuchsia.component.Realm` protocol. Dynamic components are | ||
destroyed on system shutdown. | ||
--> | ||
* **动态地**:实例在运行时使用 `fuchsia.component.Realm` 协议在组件 `collection` 中添加或移除。动态组件在系统关闭时销毁。 | ||
|
||
<!-- | ||
Once a component is destroyed, the framework removes its persistent state | ||
(such as local storage). | ||
--> | ||
一旦组件被销毁,框架就会移除它的持久状态(比如本地存储)。 | ||
|
||
<!-- | ||
The framework starts a component instance when another component attempts to | ||
open a channel to it — known as **binding**. Binding happens **implicitly** when | ||
connecting to a capability exposed by the component. Binding to a component that | ||
is already started connects to the currently running instance. | ||
--> | ||
当一个组件尝试打开到另一组件的通道时(这称为**绑定**(binding)),框架会启动后者的一个组件实例。当连接到由组件所暴露的能力时,绑定会**隐式**发生。对已经启动的组件进行绑定,会连接到其当前运行的实例。 | ||
|
||
<!-- | ||
<aside class="key-point"> | ||
Components are initially <strong>stopped</strong> when they are created. A | ||
component must be successfully <strong>resolved</strong> by a component resolver | ||
before it can <strong>start</strong>. | ||
</aside> | ||
--> | ||
<aside class="key-point">组件在创建时,最初是<strong>停止的</strong>。组件必须先由组件解析器成功<strong>解析</strong>,然后才能<strong>启动</strong>。</aside> | ||
|
||
<!-- | ||
Components may stop themselves by exiting the program (as defined by the | ||
component's `runner`), or the framework may stop the component as part of | ||
system shutdown. Before being destroyed, the framework moves components to a | ||
**shutdown** state to indicate that it cannot be started again. | ||
--> | ||
组件可能会通过退出程序(由组件的 `runner` 定义)自行停止,或者可能由框架在系统关闭时停止。在被销毁之前,框架将组件移动到**关闭**状态以表示它不能再次启动。 | ||
|
||
<!-- | ||
![Diagram showing how components have two distinct states: instance and | ||
execution. Together, these states describe the "component lifecycle."] | ||
(/get-started/images/components/component-lifecycle.png){: width="662"} | ||
--> | ||
![该图显示了组件如何具有两种不同的状态:实例和执行。这些状态描述了“组件生命周期”。](/get-started/images/components/component-lifecycle.png){: width="662"} | ||
|
||
<!-- | ||
Note: For more details on component states and execution, see | ||
[component lifecycle](/concepts/components/v2/lifecycle.md). | ||
--> | ||
注意:要获取关于组件状态和执行的更多详细信息,请参阅[组件生命周期](/concepts/components/v2/lifecycle.md)。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,19 +1,31 @@ | ||
<!-- | ||
The Fuchsia **Test Runner Framework** enables developers to build tests for | ||
components using a variety of languages and runtimes and execute them on a | ||
target device. The framework provides **test runner** components that implement | ||
the `fuchsia.test.Suite` protocol and integrate with common language-specific | ||
testing frameworks such as GoogleTest (C++). | ||
--> | ||
Fuchsia **测试运行器框架**(Test Runner Framework)使开发者能够使用各种语言和运行时为组件构建测试,并在目标设备上执行它们。该框架提供了实现 `fuchsia.test.Suite` 协议的**测试运行器**组件,并与通用的特定语言的测试框架(如 GoogleTest (C++))集成。 | ||
|
||
<!-- | ||
The `test_manager` component is responsible for running tests on a Fuchsia | ||
device. It examines components implementing the test suite protocol and launches | ||
them as child components. This means that `test_manager` is also responsible for | ||
providing capabilities to each test suite, creating what is commonly called the | ||
**test realm**. | ||
--> | ||
`test_manager` 组件负责在 Fuchsia 设备上运行测试。它检查实现测试套件协议的组件,并将它们作为子组件启动。这意味着 `test_manager` 也负责为每个测试套件提供能力,即创建通常所谓的**测试领域**。 | ||
|
||
<!-- | ||
![Diagram showing how the Test Runner Framework provides interfaces for | ||
developers to expose test suites and for developer tools to execute tests on | ||
the Fuchsia device.] | ||
(/get-started/images/components/test-realm.png){: width="714"} | ||
--> | ||
![图中显示了测试运行器框架如何为开发者提供接口来公开测试套件,以及开发者工具如何在 Fuchsia 设备上执行测试。](/get-started/images/components/test-realm.png){: width="714"} | ||
|
||
<!-- | ||
Developer tools such as `ffx test` communicate with the `test_manager` on the | ||
device to execute test suites and retrieve the results. | ||
--> | ||
`ffx test` 等开发者工具与设备上的 `test_manager` 进行通信,以执行测试套件并取回结果。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,10 @@ | ||
<!-- | ||
[Integration testing](https://en.wikipedia.org/wiki/Integration_testing){:.external} | ||
focuses on validating your component's behavior as it interacts with other | ||
components on the system. Because of this, integration tests are typically built | ||
separately from the main component and may declare the component under test | ||
and other dependencies as children. Depending on the nature of the test, | ||
dependency components may be provided as mocks or stubs to promote that the test | ||
cases remain hermetic. | ||
--> | ||
[集成测试](https://en.wikipedia.org/wiki/Integration_testing){:.external} 侧重于验证组件的行为,因为它会与系统上其他组件进行交互。正因为如此,集成测试通常与主组件分开构建,并且可能将被测组件和其他依赖组件声明为子组件。根据测试的性质,依赖组件可以作为模拟(mock)或存根(stub)提供,以促进测试用例保持封闭性。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters