关于 Ant 启动过程的实现细节，补充了一篇新文档

[cloudwu]

https://github.com/ejoy/ant/wiki/AntExe 我补充了一篇实现细节，如果希望了解编译好的 Ant 主执行程序运行时到底发生了什么，可以阅读一下。包括了启动流程相关代码在哪里，方便通过源码阅读理解细节；vfs 是如何初始化，mount 如何设置，ltask 从哪里启动，等等。

@actboy168 请审核一下看有没有写错的地方。

@constly 看看是否对你有帮助，是否有漏掉的相关技术点需要进一步补充。

[actboy168]

ant分为本地模式和运行模式。本地模式使用exe所在目录下的main.lua作为第一个加载的lua脚本，需要指定当前目录为ant工程的根目录。运行模式的第一个lua脚本是engine/firmware/bootstrap.lua不过是编译到exe里的，不需要指定当前目录。

此外还有一个特殊的编辑器模式，本地模式下，如果项目名为editor，就会变成编辑器模式。编辑器模式相对于本地模式的特殊之处有
1.定义了全局变量__ANT_EDITOR__为arg[1]，也就是第一个参数
2.将__ANT_EDITOR__指向的目录下的.mount也会被加载
3.资源编译不会缓存结果(资源编译后被修改，再次加载时，本地模式不会重新编译，编辑器模式则会)
4.可以读取资源的原始文件，本地模式读取资源的原始文件会失败(因为已经被视为目录)

例如

ant.exe tools/editor/main.lua test/simple/

ANT_EDITOR=test/simple/
tools/editor/和test/simple/两个目录下的.mount都会被加载。

[cloudwu]

以上已更新进文档。

[actboy168]

我又补充了一些，ant的启动流程虽然经过多次简化，但还是比较复杂的。我列了下主要流经的代码，到成功加载/main.lua为止。

本地模式：

1. clibs/vfs/vfs.cpp luaL_openlibs会加载vfs c模块。
2. runtime/common/runtime.cpp里的内嵌lua。
3. !main.lua 加载和ant.exe同目录的main.lua。
4. /engine/console/bootstrap.lua 真正的初始化起点。
5. /engine/firmware/ltask.lua 初始化ltask。
6. /engine/firmware/ltask_root.lua root服务。
7. /engine/console/io.lua io服务。
8. /pkg/ant.vfs/** io服务会加载vfs lua模块。
9. /main.lua 作为一个ltask服务被加载。

运行模式

1. clibs/vfs/vfs.cpp luaL_openlibs会加载vfs c模块。
2. runtime/common/runtime.cpp里的内嵌lua。
3. /engine/firmware/bootstrap.lua真正的初始化起点。
4. /engine/firmware/ltask.lua 初始化ltask。
5. /engine/firmware/ltask_root.lua root服务。
6. /engine/firmware/io.lua io服务。
7. /engine/firmware/vfs.lua io服务会加载vfs辅助函数。
8. /main.lua 作为一个ltask服务被加载。

[cloudwu]

已补充到 wiki 文档。

[constly]

目前来讲，由于我希望我的编辑器能在运行时跑， 我会更关注vfs相关模块。
不过我这边流程还要一段时间才能跑起来，现在还不知道会遇到哪些问题，到时我会在Discussions模块发起讨论。

眼下我倒更关注：后续云大完善windows平台相关功能时，是另起一个引擎分支，还是就在现在这个库上继续呢~

[cloudwu]

ejoy 这个组织是我维护的，这个是简悦的遗产，从未正式交接给阿里。而且遗留项目都是我个人创建的，其它历史项目都转走了。

当然，如果有纠纷，我会把项目转移出去。

[constly]

明白，那就放心了~

[actboy168]

如果是windows平台，本地模式也是可以作为发布版本用的。

[cloudwu]

如果用本地模式发布 windows 版本，现在编译资产后的目标文件打包是不是还需要一些调整？似乎我们还没有一个很方便的本地模式打包的功能。

[actboy168]

目前本地模式的资源的惰性编译的，如果发布版本不想带shaderc，确实是需要一个类似运行模式查找资源的方式

[cloudwu]

补充一下本地模式和运行模式的区别：

本地模式多用于开发。本地模式直接从本地文件系统读取文件，会根据需要调用外部工具编译 Asset 。本地模式中，引擎相关的 Lua 文件必须放在正确的路径中。

运行模式多用于发布。运行模式只使用一个二进制执行文件即可运行，通过 VFS 读取游戏以及引擎的其它文件。运行模式自身无法编译 Asset ，它直接从 fileserver 或本地缓存中读取编译转换后的数据。可以通过打包模块将缓存中的数据打包为 zip 包，跟随引擎的二进制执行文件一起发布。

[constly]

我之前提“运行时”主要是受UE和Unity的影响，像这些引擎，编辑器与运行时是分开的，在编辑器下做的扩展 运行时很难直接使用。我在ant_demo中想做的就是把他们统一起来，期望达到的效果是，开发人员使用的各种内容生产工具，玩家也能使用~

[cloudwu]

目前 Ant 编辑器只是在 修改资产的源文件然后编译资产并立刻使用新版本 这个步骤和正常游戏有点区别，现在差不多改好了。但还是让引擎开了一点后门，我觉得完全贯彻现在的方案（主要涉及 VFS）的话，这些后门是不需要的。

最近一年，给编辑器开了后门也越来越少，向消灭这些后门努力。

[cloudwu]

我觉得理想中编辑器应该让 fileserver 运行在一台性能非常好（但不需要显卡）的机器上，让几个开发人员共用。这个 fileserver 就负责了新资产导入编译的流程。编辑器在客户端只有一个执行文件，多个开发人员合作开发时，就可以避免编译重复资源。

目前 vfs 已经实现了版本管理，网络映射，我觉得基础设施是够了，但距离实现上述方案还有一些工作要做。比如，需要一个系统的方法解决资产源文件上传到 fileserver 。

[constly]

大项目确实非常需要共享fileserver，类似虚幻的共享DDC。我们项目最初没开共享DDC，每周引擎更新后，项目组一片哀嚎，周一早上基本只能打酱油，等着慢慢编shader吧，另外我们项目在游戏内修改画质也会导致重编全部shader = =
现在开发/维护大的项目都是项目组员工+外包公司外派驻场员工 一起办公，驻场员工的电脑配置有可能会相对低一下，总共几百号人，共享DDC这种类似功能，可以大大提升项目组的工作效率~

[cloudwu]

fileserver 我前几个月还做了一部分的串联功能，就是把一部分请求交给另一台 fileserver 。这样就可以组成 farm ，或者选择 shader 自己编译，texture 外部共享等等。后来觉得暂时用不上就暂停了。

以后有需要完善还是很容易的。