unity 生命周期

By now, you’ve noticed a plan for Unity involving packages, which has been steadily moving forward. The story kicked off with the ProBuilder announcement, and we’ve since followed up by introducing features of the Package Manager and improved Unity Project Management. Now, let’s dive a little deeper into the story.

到目前为止，您已经注意到Unity涉及软件包的计划，该计划一直在稳步向前发展。 这个故事从ProBuilder的宣布开始了 ，从那之后我们引入了包管理器的功能和改进的Unity项目管理 。 现在，让我们更深入地探讨这个故事。

包装，它们是什么？ (Packages, what are they?)

Packages will be everything. In the future, we expect to carve apart Unity into many pieces, each of which you will be able to update, experiment with and modify. All our new features are already planned to be delivered in this way: Scriptable Render Pipelines, Entity Component System (ECS), CineMachine, and so on.

包将一切。 将来，我们希望将Unity分成许多部分，您将可以分别对它们进行更新，试验和修改。 我们所有的新功能都已经计划以这种方式交付： 可编写脚本的渲染管道 ，实体组件系统( ECS )，CineMachine等。

Additionally, much of what lives in GitHub repos (NavMesh, Recorder, …), extensions ( GUI system, Networking, Timeline, etc.), and various Unity developed Asset Store packages will now be migrated into packages.

此外，GitHub存储库中的许多内容(NavMesh，Recorder等)，扩展(GUI系统，网络，时间轴等)以及Unity开发的各种Asset Store软件包现在都将迁移到软件包中。

We are dogfooding our own tech, and once the system feels solid and robust, we will open the door for Asset Store publishers as well as general users to get in on the packages story in the future.

我们正在苦苦试验自己的技术，一旦系统稳定可靠，我们将为Asset Store发行商和一般用户打开大门，以便将来了解包装方面的故事。

The main benefits of moving to packages revolve around speed, modularity and customer choice, and we aim to achieve this by making them:

迁移到软件包的主要好处在于 速度 ， 模块性 和 客户选择 ，我们旨在通过实现以下目标来实现：

• Referenceable or Embeddable

  可引用或可嵌入

  • Referenced, without needing to explicitly move/add files

    已引用，无需显式移动/添加文件

  • Embeddable, take a snapshot copy to have direct access to modify

    可嵌入，可制作快照副本以直接访问进行修改

  Referenceable or Embeddable

  可引用或可嵌入

• Extendable

  可扩展

  • Access to source repos (where feasible)

    访问源存储库(在可行的情况下)

  • Ability to upstream and downstream changes

    上下游变化的能力

  Extendable

  可扩展

• Easy to update

  易于更新

  • User interface makes it easy to see choices on versions and compatibility

    用户界面可轻松查看版本和兼容性的选择

  Easy to update

  易于更新

• Automatic and explicit dependencies

  自动和显式依赖

  • Clear dependency visibility and automatic dependency resolution

    清晰的依赖性可见性和自动依赖性解析

  Automatic and explicit dependencies

  自动和显式依赖

• Optional

  可选的

  • The ability to add or remove as desired (allowing for dependencies)

    可以根据需要添加或删除(允许依赖项)

  Optional

  可选的

包裹如何运作？ (How do packages work?)

We expect packages to have a set of files that can be “virtually dropped” into your project where they will simply work. They can then be referenced from your game assets and scripts as needed. Each package has a definition file (package.json) that defines the version, lists explicit dependencies on other packages and the earliest version of Unity that supports the package.

我们希望程序包具有一组文件，这些文件可以“虚拟地”放到您的项目中，它们将在其中简单地工作。 然后可以根据需要从您的游戏资产和脚本中引用它们。 每个软件包都有一个定义文件(package.json)的定义文件，该文件定义了版本，并列出了对其他软件包的明确依赖关系以及支持该软件包的Unity的最早版本。

Packages may contain:

软件包可能包含：

• Regular assets

  常规资产

• Scripts

  剧本

• Documentation

  文献资料

• Tests

  测验

这些与Asset Store套件有何不同？ (How are these different from Asset Store packages?)

	Asset Store Package	New Package
File	.unitypackage	Git repo or .tgz
Location	Imported to Asset Folder	Referenced (or embedded) via Packages folder
Dependencies	Manual	Explicit and calculable
Removal	Manual / Difficult	Remove Reference or delete embedded directory
Updatable	Error prone / Difficult	Easy
Forkable	Manual	Easy, source available (when feasible)
Full Projects	Difficult to install	Templates from New Project dialog

	资产商店包装	新包装
文件	.unitypackage	Git仓库或.tgz
位置	导入到资产文件夹	通过Packages文件夹引用(或嵌入)
依存关系	手册	明确且可计算
清除	手动/困难	删除参考或删除嵌入式目录
可更新的	容易出错/困难	简单
可叉	手册	简单，可用资源(可行时)
完整项目	难以安装	“新建项目”对话框中的模板

包装生命周期 (Packages Life Cycle)

We are aiming to keep the package concept very simple, and fundamentally there are only two real states to consider:

我们的目标是使包装概念非常简单，从根本上讲，只有两个实际状态要考虑：

• Preview == Not Production Ready, Use at your own risk.

  预览==尚未投入生产，使用风险自负。

• Released == Production Ready, fully supported.

  已发布==生产就绪，完全受支持。

One IMPORTANT extra label we apply to specific Released versions is “Verified For XXXX.Y,” indicating that a collection of specific released packages has been tested in one of the Unity release cycles.

我们应用于特定发行版的一个重要额外标签是 “已验证XXXX.Y”， 表示已在一个Unity发行周期中测试了一组特定发行包。

预习 (Preview)

This phase is idea genesis, early development, massive re-work, or in the midst of a complete update on a package. This is where development is the rawest, and changes can be significant.

这个阶段是想法的产生，早期的开发，大量的返工或在软件包的完整更新中。 这是发展最原始的地方，变化可能是重大的。

From our point of view, we are exposing the direct development of our systems to the users, who can influence the direction and offer constructive feedback as things are built. In turn, it’s the riskiest place to be in terms of trying things out. You wouldn’t want to rely on a package in preview for your project, unless you’re also ready to fork and maintain things for yourself.

从我们的角度来看，我们正在向用户公开我们系统的直接开发，这些用户可以在构建过程中影响方向并提供建设性的反馈。 反过来，在尝试方面，这是最危险的地方。 您不希望依赖项目预览中的包，除非您还准备自己分叉和维护事物。

Versions in Preview are expected to precede the major.minor.patch version it lists. For example, this is a sequence you might see:

预览版中的版本应优先于其列出的major.minor.patch版本。 例如，您可能会看到以下序列：

1.0.0-preview

1.0.0预览版

1.0.0-preview.1

1.0.0-preview.1

1.0.0-preview.2

1.0.0-preview.2

….

…。

1.0.0

1.0.0

Some teams may also follow:

一些团队可能还会关注：

0.0.1-preview

0.0.1-预览

0.0.2-preview

0.0.2-预览

0.1.0-preview

0.1.0预览

…

…

1.0.0

1.0.0

Both are acceptable, but the former has the clarity of no missed “Released” versions in between. (Arguably, 0 is by default preview versions, but we aim to be explicit.)

两者都是可以接受的，但是前者之间没有任何遗漏的“已发布”版本。 (可以说，默认情况下预览版本为0，但我们的目标是明确的。)

已发行 (Released)

A package that’s had success in preview and shows promise with the users can move to release where it gets all the polish in place. While in release, we expect the Patch version of the package to be mostly updated for bugs and tweaks, with perhaps occasional minor version bumps with small improvements. The important part is to never introduce backwards-incompatible changes during a given major version release, which would require a return to Preview for that new major version.

一个在预览中取得成功并向用户显示出希望的软件包可以移至将所有修饰都放到适当位置的版本。 在发行时，我们希望该软件包的补丁版本将针对错误和调整进行大部分更新，并且可能偶尔会出现次要版本，但会有一些小的改进。 重要的部分是，在给定的主要版本发行期间，切勿引入向后不兼容的更改，这将要求针对该新的主要版本返回到Preview。

At this point, we expect a Unity-developed package to have:

在这一点上，我们期望Unity开发的软件包具有：

• Reasonable test coverage

  合理的测试范围

• 100% API documentation coverage

  100％API文档覆盖率

• Basic user manual documentation

  基本的用户手册文档

• API reviews for

  的API评论

  • Naming conventions

    命名约定

  • Security issues

    安全问题

  • Upgrade issues

    升级问题

  API reviews for

  的API评论

• Passed our package validation tests

  通过了我们的包装验证测试

  • Checks for versioning

    检查版本

  • Checks for import errors

    检查导入错误

  Passed our package validation tests

  通过了我们的包装验证测试

已验证为XXXX.Y (Verified For XXXX.Y)

Verified For is not a state, but as per Unity Version labels, we may apply to a released package. So a specific package, for example, com.unity.postprocessing at version 2.0.0, could be “Verified for 2018.1” and “Verified for 2018.2” if nothing changed between those releases, and it has passed through the Unity release testing cycle.

验证为不是状态，但是根据Unity版本标签，我们可能适用于已发布的软件包。 因此，如果某个特定软件包(例如，版本2.0.0的com.unity.postprocessing)在两个发行版之间没有任何变化，则可以“针对2018.1验证”和“针对2018.2验证”，并且已通过Unity发行测试周期。

The Verified For label is something that can only be attached after a full Unity release testing cycle. What does that mean? Please read on.

经过验证的标签只能在完整的Unity发布测试周期后附加。 那是什么意思？ 请继续阅读。

好的，那么什么是Unity版本？ (Ok, what is a Unity release then?)

Now that we explained the lifecycle of packages, let’s dive into what Unity releases will become. Unity will slowly be shedding functionality from the core into separate packaging with clear dependencies on Unity versions as required by the APIs.

现在，我们解释了软件包的生命周期，让我们深入了解Unity发行版将成为什么。 Unity会逐渐将功能从核心转移到单独的程序包中，并按照API的要求明确地依赖于Unity版本。

As the numbers of packages proliferate, and with each package released individually, it will become harder to test the large combinations of what is available. So we will focus on a clear “verified for XXXX.Y” snapshot set that has been tested in concert for a Unity cycle.

随着软件包数量的激增以及每个软件包的单独发布，将越来越难以测试可用的大型组合。 因此，我们将关注清晰的“经过验证的XXXX.Y”快照集，该快照集已经针对Unity周期进行了测试。

This means, at the start of the Unity cycle, we will have picked the set of released packages we believe are in good standing in their candidacy, in other words, packages that have stabilized and are not under active development. These will be entered together to our builds, offered to Release QA, and tested together for the full cycle.

这意味着，在Unity周期开始时，我们将挑选出我们认为在候选资格上处于良好状态的已发布软件包，换句话说，这些软件包已经稳定并且未处于积极开发中。 这些将一起输入到我们的版本中，提供给版本QA，并一起测试整个周期。

Timing is crucial on packages joining the set. Effectively, the start of the cycle means we’ve boarded the plane and pushed back from the gate. There’s no room for late additions before the flight takes off. With this rigor, we will test our utmost to ensure that all included packages are compatible with each other within the set. In some cases, we may find an unruly package, and drop it from the final set before release as testing progresses.

定时对于加入集合的软件包至关重要。 实际上，周期的开始意味着我们已经登上飞机并从登机口向后推。 航班起飞前，没有多余的空间可以进行后期添加。 通过这种严格的测试，我们将竭尽全力以确保所包含的所有套件在套件中彼此兼容。 在某些情况下，我们可能会发现一个不合规的程序包，并随着测试的进行将其从最终版本中删除，然后再发布。

等等，这么多包！ 听起来很困惑！ (Wait, so many packages! That sounds like a lot of confusion!)

To help navigate the proliferation of packages, we added the new Package Manager UI to Unity 2018.1. We are still improving and refining this Unity Editor window, but this will help you browse, view information and choose what packages you want to include in your project.

为了帮助解决软件包的泛滥，我们在 Unity 2018.1中 添加了新的 Package Manager UI 。 我们仍在改进和完善此Unity Editor窗口，但这将帮助您浏览，查看信息并选择要包含在项目中的包。

We’re also bringing in Project Templates, which are packages that are structured in useful configurations, which you can find on your Hub or Launcher. Project Templates include relevant packages to get you started in the right way for a given purpose. In the future, we expect Asset Store publishers to create new templates, as well as studios and users themselves.

我们还引入了 Project Templates ，这些 模板 是按照有用的配置进行结构化的包，您可以在Hub或Launcher上找到它们。 项目模板包括相关的程序包，可帮助您 按照给定的目的 以 正确的方式 入门 。 将来，我们希望Asset Store发行商以及工作室和用户自己创建新模板。

Of course, every Unity release will still come with a default set of packages that we consider tested, useful and available with any new project created. As stated, one can always opt out of these selections, and still get  the general Unity features and functionality you know and love.

当然，每个Unity版本仍将带有一组默认软件包，我们认为这些软件包经过测试，有用并且可用于创建的任何新项目。 如前所述，您始终可以选择退出这些选项，而仍然获得您熟悉和喜爱的Unity常规功能。

向前走 (Going forward)

It’s an exciting time for Unity in this transition. Our R&D is excited to be aligning ourselves closer to you all, the game developers, and to share more development, features, and choices at a faster pace. I hope you all look forward to the packages to come!

在此过渡中，Unity激动人心。 我们的研发部门很高兴与大家(游戏开发人员)保持紧密联系，并以更快的速度分享更多的开发，功能和选择。 希望大家都期待收到的包裹！

常问问题 (FAQ)

Q: Can two versions of the same package be present in the same project?

问：同一项目中可以存在相同软件包的两个版本吗？

No, the project owner must resolve the issue by deciding which one  is used and then testing how things work. Unity will add some intelligent automatic conflict resolution similar to NuGet’s. However, it still ultimately boils down to the project owner’s choice.

不，项目负责人必须通过确定使用哪种解决方案然后测试其工作方式来解决该问题。 Unity将添加一些类似于NuGet的智能自动冲突解决方案。 但是，最终仍然归结为项目所有者的选择。

Q: Can a package be in multiple different states in the Package Manager?

问：程序包管理器中的程序包可以处于多个不同的状态吗？

Yes, for example, after a package has been released, a newer Preview version may become available with new features. The Package Manager will list all available known-compatible versions of a package for the editor used.

是的，例如，在发布软件包后，可能会提供具有新功能的更新的预览版。 软件包管理器将为使用的编辑器列出软件包的所有可用的已知兼容版本。

Q: Can multiple packages affect the same things and potentially cause a conflict?

问：多个软件包会影响同一事物并可能引起冲突吗？

Yes. We don’t have any examples of that yet, but it is something we do expect to occur.

是。 我们还没有任何示例，但这是我们希望发生的事情。

Q: Can I downgrade a package to a prior version?

问：我可以将软件包降级到以前的版本吗？

Possibly, but this is generally not recommended or supported. We intend to support the semver spec, and trying to step down a major or minor version may cause you to lose functionality, compatibility, and in the worst case scenario, introduce fatal crashes (for example due to utilizing older/non-existent APIs in later versions of Unity). Downgrading to a prior patch release may be safe, but it should be tested individually for your use. (As always, backup before testing.)

可能，但是通常不建议或不支持此操作。 我们打算支持 semver 规范，并且尝试退出主要或次要版本可能会导致您失去功能，兼容性，并且在最坏的情况下，会导致致命的崩溃(例如，由于使用了旧的/不存在的API)更高版本的Unity)。 降级到先前的修补程序版本可能是安全的，但应单独测试以供使用。 (与往常一样，请在测试之前进行备份。)

Q: Where do packages go in my project?

问：包在我的项目中放在哪里？

They’re referenced in the project manifest JSON file, but the actual files are elsewhere on your machine. A new person opening the project on a new machine may invoke a download to get that correct package at the specified version onto their machine to be utilized by the project.

它们在项目清单JSON文件中引用，但实际文件在您计算机上的其他位置。 在新计算机上打开项目的新人可以调用下载，以将指定版本的正确软件包下载到要由该项目使用的计算机上。

Q: How do you override a package?

问：如何覆盖软件包？

We haven’t yet finalized the details and functionality, but the general plan is to have a couple options:

我们尚未敲定细节和功能，但总体计划是有两个选择：

• Embed a package, taking a snapshot of it and laying a copy of those exact files into your project (not in the Assets folder, but in the Packages directory)

  嵌入一​​个软件包，对其进行快照，然后将这些确切文件的副本放入您的项目中(不在Assets文件夹中，而是在Packages目录中)

  • This option is useful for immediate fixes or similar temporary experiments

    此选项对于立即修复或类似的临时实验很有用

  • The project version takes precedence over the cache

    项目版本优先于缓存

  Embed a package, taking a snapshot of it and laying a copy of those exact files into your project (not in the Assets folder, but in the Packages directory)

  嵌入一​​个软件包，对其进行快照，然后将这些确切文件的副本放入您的项目中(不在Assets文件夹中，而是在Packages目录中)

• Clone the source repo, git sub repo/submodule into your project

  将源仓库，git sub repo / submodule克隆到您的项目中

  • Implementation is still in the works but allows you to fork, branch, merge changes coming downstream or even offer fixes upstream

    实施仍在进行中，但允许您分叉，分支，合并下游的更改，甚至提供上游的修复程序

  Clone the source repo, git sub repo/submodule into your project

  将源仓库，git sub repo / submodule克隆到您的项目中

Q: Does Package Manager automatically resolve and download dependencies?

问：程序包管理器是否自动解决和下载依赖项？

Yes! However, clear conflict resolution display and choice is not yet implemented.

是! 但是，尚未实现清晰的冲突解决显示和选择。

Q: Does upgrading completely replace the previous package?

问：升级是否可以完全替代以前的软件包？

Effectively yes. The new set of files in the new package version are pointed to, although any changes the package made to the Assets folder would remain. This is an advantage over the old unitypackage, which pushed things into the Assets folder and made it difficult to upgrade.

有效的是。 指向新软件包版本中的新文件集，尽管该软件包对Assets文件夹所做的任何更改都将保留。 与旧的unitypackage相比，这是一个优势，后者将内容推送到Assets文件夹中，使其难以升级。

翻译自: https://blogs.unity3d/2018/05/09/unity-packages-life-cycle/

unity 生命周期