1. 为什么在 Ubuntu 20.04 上折腾 Unreal 4.24 值得单独写一篇Ubuntu 20.04 是 LTS 版本里生命周期相当长的一个很多做图形、仿真、数字孪生、虚拟制片的朋友工作机或者渲染节点至今还跑着它。而 Unreal Engine 4.24 是一个比较特殊的分水岭版本它把 Chaos 物理和破坏系统正式推到台前Niagara 也趋于稳定同时它又是最后一个对老版本编译工具链相对宽容、对显卡驱动要求没那么苛刻的 4.x 大版本之一。换句话说很多存量项目、教学课件、实验室环境都锁死在 4.24 上你没法随便升到 4.27 或者 UE5因为一升级材质节点、插件 ABI、着色器缓存全得重来。问题在于Epic 官方对 Linux 的支持一直是“能用但别指望太顺”。Ubuntu 20.04 自带的 GCC 9、Python 3.8、Clang 10跟 4.24 当年主推的 GCC 7/8、Python 2.7/3.6 之间存在明显的代差。你直接照着官方文档走大概率会在编译第三方库、生成工程文件、启动编辑器这几个环节里反复卡住。网上能搜到的教程要么是 18.04 时代的要么是 UE5 的中间这段空白恰好是踩坑最密集的区域。这篇内容就是把我自己在 Ubuntu 20.04 上从零把 4.24 跑起来的过程完整复盘一遍。适合三类人看一是手里有 4.24 项目必须在本机或服务器上编译的开发者二是想学 UE 但机器只有 Linux、又不想装双系统的学生和独立开发者三是需要批量部署渲染节点的运维同学。我会把每一步“为什么这么做”讲清楚而不是甩一堆命令让你复制。全程不涉及任何网络代理相关内容所有依赖都走系统源和官方发布包。2. 装之前先把这几个前置条件想明白2.1 硬件与驱动的现实门槛Unreal 4.24 的 Linux 编辑器对显卡的要求比很多人想象中要高。官方最低标的是支持 Vulkan 的显卡但实际跑起来如果你只有核显或者入门级独显编辑器能打开但视口操作会卡到怀疑人生。我实测下来GTX 1060 6G 是能比较舒服地跑 4.24 编辑器的底线显存低于 4G 的话稍微复杂点的场景就会频繁触发显存回收视口一卡一卡的。驱动这块Ubuntu 20.04 自带的 nouveau 开源驱动是绝对不行的必须装厂商闭源驱动。NVIDIA 的话建议用 470 或 510 系列的长期支持分支太新的驱动有时候反而会和 4.24 的 Vulkan 后端闹别扭。装驱动最稳的方式是通过系统自带的“附加驱动”工具或者用ubuntu-drivers devices看推荐版本然后apt install对应的nvidia-driver-xxx。装完一定要nvidia-smi确认能正常输出并且vulkaninfo能看到设备列表这两个命令都通过了再往下走。提示如果你是在虚拟机里折腾趁早放弃。UE4 编辑器在虚拟机里跑 Vulkan 基本是残废状态除非你搞 GPU 直通那个复杂度又是另一个话题了。2.2 磁盘空间和文件系统的小细节4.24 的源码编译加上引擎自带的衍生数据轻松吃掉 100G 以上。我建议单独挂一块 SSD 给引擎和项目用至少留 150G 余量。文件系统用 ext4 就行别用 NTFS 或者 exFAT因为编译过程中会产生大量小文件NTFS 的权限映射和大小写敏感性会让你在链接阶段遇到莫名其妙的错误。另外Linux 下 UE4 对文件路径大小写是敏感的而很多从 Windows 迁移过来的项目里资源引用路径大小写是乱的。这个问题在 4.24 上尤其明显因为它的资源加载器对大小写不匹配的容忍度比后续版本低。如果你是从 Windows 拷项目过来建议先用脚本把所有路径统一成小写或者至少保证.uproject里引用的路径和实际文件大小写完全一致。2.3 编译工具链的版本选择逻辑这是整个安装过程里最核心的决策点。4.24 官方推荐用 Clang 6.0 到 8.0 之间的版本但 Ubuntu 20.04 默认源里是 Clang 10。直接用 Clang 10 编译会在编译libWebRTC和部分 PhysX 相关模块时报错错误信息通常是关于-Werror把一些新的警告当成了错误。我的做法是装一个 Clang 8 的独立版本不覆盖系统默认的 Clang。具体来说从 LLVM 官方发布页下载预编译的 clangllvm 8.0.1 包解压到/opt/llvm-8然后在编译脚本里通过环境变量指定CLANG_PATH和LLVM_PATH。这样系统里其他工具不受影响UE4 编译时又能用上它期望的版本。GCC 的话4.24 对 GCC 9 的兼容性比 Clang 10 好一些但如果你要用到一些依赖 Clang 的插件还是统一用 Clang 8 最省心。3. 从源码到可运行编辑器的完整链路3.1 获取源码与依赖安装的先后顺序很多人一上来就git clone整个仓库然后发现子模块拉不全或者拉完了编译缺一堆系统库。正确的顺序是先装系统依赖再拉源码。系统依赖这块除了官方文档列的那一串build-essential、libssl-dev、libx11-dev之类Ubuntu 20.04 上还需要额外补几个libvulkan-dev、vulkan-tools、libglfw3-dev、libsdl2-dev。这几个在 18.04 时代要么是自带的要么版本够用但在 20.04 上如果不显式装编译到图形后端时会报找不到头文件。源码获取有两种方式一种是直接下载 Epic 发布的 Linux 二进制包那个解压就能用但 4.24 的 Linux 二进制包功能有阉割比如不支持 C 项目热重载也不带完整的调试符号。另一种是从 GitHub 上的源码仓库拉然后自己编译。我强烈建议走源码编译这条路虽然耗时但后续装插件、改引擎源码、调试崩溃都方便得多。拉源码的时候git clone要加--depth 1和-b 4.24指定分支不然整个历史拉下来几十个 G。拉完之后git submodule update --init --recursive这一步不能省而且最好在网络稳定的时段做因为子模块里有些仓库体积不小。3.2 Setup.sh 和 GenerateProjectFiles.sh 到底做了什么源码拉下来之后根目录有两个脚本Setup.sh和GenerateProjectFiles.sh。很多人不知道这两个脚本的区别稀里糊涂跑完就编译结果各种报错。Setup.sh干的事情是下载平台相关的二进制依赖比如 PhysX 的预编译库、WebRTC 的静态库、还有一些第三方 SDK。这些文件不在 git 仓库里因为体积太大所以脚本会从 Epic 的 CDN 拉。这一步如果中断下次重跑它会续传但有时候会卡在某个文件上不动这时候可以看Setup.sh的输出找到卡住的文件名手动用wget或者curl下载到对应目录再重跑脚本。GenerateProjectFiles.sh则是根据你当前的系统环境生成 Makefile 或者 Ninja 构建文件。这一步会检测你的 Clang 版本、Python 版本、mono 版本。如果它检测到的版本不符合预期会在输出里给警告但不会直接退出。我的建议是在跑这个脚本之前先把clang --version、python --version、mono --version都确认一遍确保 Clang 是 8.xPython 是 3.84.24 对 Python 3.8 的支持比 3.9 好mono 是 6.x 以上。跑GenerateProjectFiles.sh的时候可以加-makefile参数强制生成 Makefile因为默认它可能生成 Ninja 文件而 Ninja 在 4.24 上偶尔会有依赖顺序问题。Makefile 虽然编译慢一点但稳定性更好。3.3 编译参数怎么调才不翻车编译命令是make但直接make会把你机器上所有核心跑满内存不够的话会在链接阶段 OOM。我一般用make -j$(nproc-2)留两个核心给系统避免桌面卡死。如果内存只有 16G建议-j4就够了因为 UE4 的链接阶段单个进程就能吃掉 4-6G 内存。编译目标选UE4Editor就行不用编UE4Game或者ShaderCompileWorker那些可以等编辑器跑起来之后再按需编。编译时间取决于 CPU我在一台 8 核 16 线程的机器上完整编完大概 40 分钟到 1 小时。第一次编译一定会遇到几个错误最常见的是libWebRTC的符号冲突和PhysX的-Werror问题。libWebRTC的报错通常是undefined reference to std::__cxx11::basic_string之类的这是因为 WebRTC 预编译库是用老版本 ABI 编的而你的 Clang 8 默认用新 ABI。解决办法是在Engine/Source/Programs/UnrealBuildTool里找到 WebRTC 的构建配置加上-D_GLIBCXX_USE_CXX11_ABI0这个宏。PhysX 的-Werror问题则是找到对应的Build.cs文件把bEnableUndefinedIdentifierWarnings之类的开关关掉或者直接在编译参数里加-Wno-error。注意改引擎源码里的构建配置时一定要记下你改了哪些文件因为下次更新引擎或者重新拉源码时这些改动会丢。我习惯把改动做成 patch 文件存着重装时直接git apply。4. 编辑器跑起来之后那些让人头疼的配置4.1 首次启动的着色器编译与缓存策略第一次启动 UE4Editor 的时候它会编译几千个着色器这个过程可能持续 20 分钟到半小时界面看起来像卡死了其实是在后台跑ShaderCompileWorker。这时候千万别强杀进程否则缓存写一半下次启动还得重来。着色器缓存默认放在~/.config/Epic/UnrealEngine/4.24/ShaderCache下面。如果你有多台机器或者经常重装系统可以把这个目录备份下来下次直接拷回去能省很多时间。另外可以在Engine/Config/ConsoleVariables.ini里把r.ShaderDevelopmentMode0和r.ShaderCompileWorker.NumCores设成你 CPU 核心数的一半左右这样编译着色器时不会把机器完全占死。还有一个坑是Ubuntu 20.04 的tmp目录默认是 tmpfs挂在内存里。着色器编译过程中会产生大量临时文件如果内存不够大/tmp会被写满导致编译失败。我的做法是在Engine/Config/BaseEngine.ini里把ShaderCompilerWorkingDirectory指到一个磁盘上的目录比如/home/yourname/ue4tmp避免占用内存。4.2 Vulkan 与 OpenGL 后端的切换逻辑4.24 在 Linux 下默认走 Vulkan但有些老显卡或者驱动版本对 Vulkan 支持不完整这时候可以切到 OpenGL。切换方式是在启动编辑器时加-opengl参数或者在Engine/Config/BaseEngine.ini里把DefaultGraphicsRHI改成OpenGL。不过 OpenGL 后端在 4.24 上问题更多比如视口闪烁、材质预览不刷新、某些后处理效果失效。所以除非 Vulkan 完全跑不起来否则不建议切。如果你遇到 Vulkan 初始化失败先检查vulkaninfo能不能正常输出然后确认驱动版本是不是太老。有时候升级到最新的长期支持驱动就能解决。另外多显卡笔记本上UE4 可能会默认用核显跑导致性能极差。可以在nvidia-settings里把 UE4Editor 强制指定为独显或者用prime-select切到独显模式。这个在 Ubuntu 20.04 上比 18.04 好弄一些但依然需要手动配。4.3 项目路径与权限的常见坑Linux 下 UE4 对项目路径的权限要求比较严格如果项目放在/root或者/opt下面编辑器可能会因为权限问题无法写入中间文件。我建议把项目放在用户主目录下的一个专门目录里比如~/UnrealProjects并且确保这个目录的属主是你自己权限至少是755。还有一个问题是如果你用sudo跑过编辑器或者编译脚本会在Engine和项目目录里留下 root 属主的文件后续用普通用户操作时就会报权限错误。解决办法是sudo chown -R $USER:$USER把整个引擎和项目目录的属主改回来。这个坑我踩过不止一次尤其是用sudo make install装了什么系统级依赖之后顺手用sudo跑了编译脚本结果后面一堆文件写不进去。5. 插件与 C 项目的编译避坑5.1 第三方插件的 ABI 兼容性检查4.24 的插件生态里很多插件是预编译好的二进制形式只提供 Windows 的.dll和 Linux 的.so。如果你拿到的插件只有 Windows 版本那在 Linux 下要么找源码自己编要么放弃。即使有 Linux 的.so也要注意它是用哪个 Clang 版本编的。如果插件是用 Clang 10 编的而你的引擎是用 Clang 8 编的加载时可能会报undefined symbol错误。检查插件 ABI 兼容性的办法是用nm -D看.so的符号表确认它依赖的libstdc版本和你的系统一致。更稳妥的做法是拿到插件源码放到Engine/Source或者项目的Plugins目录下跟着引擎一起编译。这样虽然慢但兼容性有保证。5.2 C 项目热重载在 Linux 下的替代方案Windows 下 UE4 的 C 热重载很方便改完代码点一下编译编辑器里就能看到变化。但 Linux 下这个功能基本不可用4.24 的 Linux 编辑器不支持热重载。替代方案是改完 C 代码后关闭编辑器重新make编译再启动编辑器。这个过程很繁琐但没办法。为了提高效率我一般把 C 逻辑尽量拆成小的模块改哪个模块就只编那个模块对应的 target而不是整个UE4Editor。比如make UE4Editor-MyProject-Editor-Linux-Debug这样只编项目相关的部分能省不少时间。另外可以用Live Coding的早期版本但 4.24 的 Live Coding 在 Linux 上还不成熟我试过几次崩溃概率太高不建议在生产环境用。5.3 打包发布时的依赖收集在 Linux 下打包 UE4 项目默认会生成一个LinuxNoEditor目录里面包含可执行文件和资源。但这个目录里的可执行文件依赖系统里的libstdc、libvulkan等库如果目标机器上没有这些库就跑不起来。4.24 的打包工具不会自动把系统库拷进去需要手动处理。我的做法是写一个脚本用ldd分析可执行文件的依赖把非系统核心的库拷到LinuxNoEditor/Engine/Binaries/Linux下面然后在启动脚本里设置LD_LIBRARY_PATH指向这个目录。这样打包出来的东西才能在没有装开发环境的机器上跑。提示打包前记得把Engine/Config/BaseEngine.ini里的bUseShaderCompression和bShareShaderCode根据目标机器情况调一下不然包体可能大得离谱。6. 性能调优与日常维护的实战心得6.1 编译缓存的清理时机UE4 的编译缓存放在Engine/Intermediate和Engine/Saved下面时间长了能占几十个 G。但不要随便删因为删了之后下次编译又是全量。我一般只在遇到编译错误、怀疑缓存损坏时才清理。清理的时候删Intermediate/Build下面的对应平台目录就行不用整个Intermediate都删。另外DerivedDataCache目录也是吃空间大户它存的是资源导入后的中间格式。如果项目资源变动不大这个目录可以保留如果经常切换项目或者引擎版本建议定期清理不然它会无限膨胀。6.2 编辑器卡顿的排查思路Linux 下 UE4 编辑器卡顿最常见的原因是显卡驱动和 Vulkan 后端配合不好。排查步骤是先看nvidia-smi里编辑器的 GPU 占用率如果很低但视口就是卡那可能是走了软件渲染。检查vulkaninfo里有没有报错然后看编辑器的日志Saved/Logs/MyProject.log搜Vulkan关键字看有没有device lost或者out of memory之类的错误。另一个常见原因是着色器编译没跑完后台还在编译这时候视口操作会一顿一顿的。等ShaderCompileWorker进程消失之后再操作就流畅了。如果长时间不消失可能是某个着色器编译卡死了可以手动杀掉ShaderCompileWorker进程然后在编辑器里点Recompile Shaders重来。6.3 长期维护的版本锁定策略如果你把 4.24 作为长期使用的版本建议把整个引擎目录做一个完整的备份包括Engine/Binaries、Engine/Intermediate、Engine/Saved和DerivedDataCache。这样即使系统重装把备份拷回去重新跑一下Setup.sh和GenerateProjectFiles.sh就能快速恢复环境不用从头编译。另外把编译时用到的 Clang 8、mono、Python 3.8 这些依赖也一起备份或者记录下确切的版本号和下载地址。因为过一段时间之后这些老版本的下载链接可能会失效到时候再找就麻烦了。我自己的做法是建一个ue4-env目录把所有依赖的安装包和引擎备份都放进去整个目录打个压缩包存到移动硬盘里这样不管换什么机器半天之内就能把环境搭起来。最后说一个我自己的习惯每次成功编译出一个能用的编辑器之后立刻用git tag在引擎源码仓库里打一个标签记录下当时的 commit hash 和编译参数。这样以后如果编译环境出了问题可以快速回滚到已知可用的状态而不是在一堆改动里大海捞针。这个习惯帮我省了至少两次重装系统的功夫。