在游戏项目中，当我们在打包各个平台时，总希望每个平台的包能够最小化便于分发，而且上架某些平台还有明确的大小要求。对于UE而言，它包含了巨量代码以及大量的插件，Build阶段还将生成反射的胶水代码，在编译时产生了大量的代码段。以Android平台为例，将导致libUE4.so的大小急剧增长，对于包体和运行时内存都造成了压力。再加上一些引擎必要和额外带入的资源也能占据上百M，空APK的大小很容易达到数百M的规模！不仅仅为了符合上架平台的要求，从包体和内存优化的角度，也有必要对UE包的大小进行裁剪。本篇文章会以Android为例，从各个方面介绍UE包中的可裁剪部分的优化思路与实践，同时优化APK大小和Native库的运行时内存占用，其中的策略也可以复用在其他平台。 ...继续阅读 (12)

近期遇到了一个极为诡异的bug，分别有两张地图，其中一张地图A的PAK放在引擎自动挂载路径下可以进入，但是在热更目录不行，另一张地图B则完全相反，在自动挂载目录异常，但是在热更目录正常。乍一看这个问题完全难以捉摸，两个互斥的行为出现在同一个表现逻辑中。而且热更挂载与自动挂载只是时机不同，优先级不同而已，按理说应该不会出现这个问题。虽然最终这个问题可以在业务侧逻辑解决，但是这个表现也牵扯到了引擎中另一个极为隐蔽的路径，搞懂为什么以及它的原理是十分必要的。所以，我根据这种表现分析了引擎的代码，并得出了合理的结论，并制定一种检测和规避这种问题的方法。本篇文章默认读者具有一些UE热更新的基础知识，如有疑问可查阅本博客中热更新系列的其他文章。 ...继续阅读 (29)

对于个人知识管理，我坚持不依赖任何中心化的平台服务，任何平台一旦具有盈利和监管压力，广告和内容审查不可避免。而且个人的数据，我也不想“贡献”给第三方平台。所以，我非常热衷于搞一套自己的local-first和开源的self-host的服务，这样就能不依赖任何平台、数据完全自主可控、服务可随时迁移。不管是Obsidian、Hexo博客、以及本篇文章介绍的memos，都是这个选择标准。本文的主角，memos是一个开源的轻量级笔记的服务，可以像发微博的方式记笔记，支持TAG标记和引用。具有账号系统和权限管理，网页访问随时登录，笔记可以公开或私有，非常灵活。我选择它是因为可以跟Obsidian互为补充，Obsidian还是太重了，在PC上好用但移动端体验不佳。所以我需要一个轻量级、随时可用的一种笔记服务。本篇文章会介绍，如何在VPS上用Docker部署一个Memos服务，并结合Nginx绑定域名、Certbot签发以及自动更新SSL证书和定时备份memos数据库，还有我为该服务做的一些配置优化。 ...继续阅读 (79)

在之前的文章中，主要在介绍HotPatcher如何应用在热更新流程里。但是HotPatcher并不只是能实现热更的需求，更是一个灵活的资源打包框架。当项目开发进行到一定阶段，海量的资源需要进包，等待一次完整出包的时间会很久。如果真机出现问题，修复->打包->验证，这个串行流程就会变动极为冗长。经常会遇到脚本、数据或者某些的资源错误，导致包的异常。这种情况下，再完整出一个包就等待数个小时的时间，导致测试无法进行冒烟跑测。就算重新出包也难保一定没有其他遗漏的问题，否则又要重来一遍。基于这种痛点，我们迫切地需要一种在开发阶段能够快速地修复包内资源问题，进行快速验证的方法。而HotPatcher提供了这样的功能，如果能充分利用起来，就不必等待完整出包。本篇文章会介绍，如何利用HotPatcher提供的编辑器功能，来快速打包预设配置和特定资源。加速资源在真机上的验证流程，大幅提升测试效率。 ...继续阅读 (54)

距离HotPatcher的上次版本发布，已经过去了大半年的时间，对UE4的支持较好，但对UE5的支持欠缺，群里也频繁有人询问适配情况。HotPatcher的上个Release版本是20230604发布的v81.0，只兼容了UE5.1.0，并且不支持WP和Nanite，后续Epic又推出了UE5.2和5.3，但插件并未适配。虽然可以自己修改编译错误，但功能支持在UE5里算是半成品状态。趁着清明假期爆肝了几天，我对HotPatcher做了全面优化与适配支持，可以兼容UE4.21~UE5的最新版本，并且发布了一个新的Release版本：v82.0。本篇文章的后半部分会介绍HotPatcher在UE5中的适配情况、注意事项、以及更新日志。另外，在2020年我曾经写过一篇文字：对开源的一些思考与想法，而过去这两年间，我对于维护开源项目的又有些新的想法，一起做个总结。 ...继续阅读 (61)

元旦期间，我的iPhone12跌落导致了一些故障，勉强凑合能用，但前段时间电池也鼓包很容易自动关机，已经彻底不能用了。换了备机之后，搁置了一段时间。最近想起来，因为还能正常开机，且主要功能还能正常使用，所以推测应该还是部分故障，不是整体损坏。完全报废有些可惜，只能换不锈钢盆了。自己动手拆机分析了下故障原因，并尝试购买配件修理解决，本篇文章记录拆机和解决过程。 ...继续阅读 (72)

在前一篇文章UE中资源自修正的设计与实现方案中，我介绍了利用ResScannerUE的资产检查进行过滤，然后自动化处理的实现方案。在通常情况下，如果想要检查资源内的某个属性，就需要把资产加载进来，获取对象：但是，如果想要批量地检查资源的属性，用这种形式挨个加载资源的耗时很久，尤其是在没有DDC的情况下，加载资源就会触发DDC缓存的构建，这部分耗时很久，对于机器性能占比也较高。而且随着资产规模的扩大，如果想要完整扫描一遍工程里的所有资源，耗时就会异常夸张。所以，我设想能否实现一种无需加载资源，但能够获取资源内属性的方法。经过研究发现，通过一种取巧的方法做到这一点，利用了反射、资产序列化、以及AssetRegistry的特性组合起来。并且是非侵入式的，无需修改任何现有资源类型的代码。本篇文章会介绍其实现原理，以及对引擎中相关逻辑的分析，并介绍该机制在工程中的实际应用。 ...继续阅读 (71)

通常，UE4开发者获取UE4引擎的方式有两种：从Epic Games Launcher安装从Github上Clone代码本地编译从EpicGamesLauncher安装的是公版引擎，不能修改代码重新编译，可以在根据选择安装支持的平台、调试符号等。自己从Github上Clone代码进行编译的则是源码版引擎，有些功能只能在源码版中使用（比如Standalone Application），但是如果在项目中修改了引擎的代码，导致每个人都需要Clone一遍源码编译一遍引擎，这个过程十分耗时，而且源码版引擎的占用的磁盘空间十分巨大，达到上百G。在当需要把引擎部署到多台构建机时，编译引擎的时间和空间是冗余的，所以需要通过一台机器编译引擎，然后其他的机器只需要拉取编译后的引擎即可，实现与安装版引擎一样的行为。本篇文章主要介绍BuildGraph的工作流程，以及对引擎默认构建脚本InstalledEngineBuild.xml的分析；如何使用BuildGraph从源码配置、编译并导出支持Android/IOS打包的二进制引擎、以及如何裁剪和加速整个的构建流程。 ...继续阅读 (77)

在先前的文章中，我曾介绍了在UE中利用ResScannerUE进行资源的多阶段与自动化检查的实现和执行效率优化。UE中多阶段的自动化资源检查方案基于ResScannerUE的资源检查自动化实践UE资源合规检查工具ResScannerUE已经能够实现非常灵活地配置资源检查和及时提醒，具有非常强大的规则表达能力。但它们还都仅限于发现问题予以提醒的阶段，虽然有强制约束不能提交，但仍需人工地去处理。尤其是具有大量存量资源的情况下，手动处理的人力耗时非常大。基于这种情况下，我设计了一种自动化修正资源的机制，能够在规范制定之后自动修复资源，确保被扫描出来资源的都被设置为正确的状态。补齐了我这套资源检查方案中的最后一块拼图，并且可以应用在各个阶段的扫描过程，按需执行。本篇文章会介绍它的设计思路与实现机制，以及一些在项目中实际的应用场景。 ...继续阅读 (77)

如果让我挑一个近期在工作当中使用UE感觉最无意义和折磨的事情，那一定是根据一大串字符串路径，在ContentBrowser里找到它。由于无法快速地直接跳转到目录和资源，每次逐级点开一个深层目录都给我带来一种浪费人生的感觉。基于这种痛点，我写了一个小工具，可以极大地缓解这种手动焦虑。我把它命名为j2（jump to），是一个极简的ContentBrowser跳转工具，开源在github上：hxhb/JumpTo。本片文章会介绍该项目的用法，以及构想解决方法的思考过程和逐步的代码实现。虽然功能本身是一个极简的插件，但对于实际痛点的发现、分析和解决过程值得记录。 ...继续阅读 (79)

在2020年，我曾写过一篇文章如何构建自己的知识体系？，其中主要是对于日常技术积累的思考，偏向于方法论。本篇文章会从工具和实际使用的角度出发，基于Obsidian探索个人知识管理的可能性，并尝试将其与Hexo博客结合起来。当然，这种工具偏好和实践具有强主观性，本文完全从我个人的实践和经历出发，没有最好的工具，只有最适合自己的。 ...继续阅读 (65)

本篇文章的主要内容是介绍UE在Mac上的开发环境部署、配置iOS远程出包、UPL在iOS上的应用（介入ipa出包过程）、工具和开发技巧、以及分析相关的引擎代码等内容，记录了一些在项目中遇到的坑，主要从我之前的笔记中整理而来，后续Mac和iOS相关的内容也都会更新到这篇文章里。 ...继续阅读 (63)

远程构建是UE中非常方便好用的一种打包IOS方式，能够只在Mac上编译代码，不COOK资源，能够极大地降低对于Mac硬件的需求。而且，Mac的售价颇高，传统模式下，如果需要部署多个独立的IOS包构建流程，通常就需要采购多台独立的Mac机器分别部署，硬件成本较高。况且，IOS的开发环境往往需要随着IOS系统迭代进行更新。每年WWDC发布新版本IOS，就会需要新版本的XCode支持，新版本XCode又依赖新版本的MacOS，套娃式的链式依赖。如果Mac的构建环境增多，那么更新这些机器的构建环境也会变为一个繁琐的重复任务。远程构建IOS也能够比较好的解决这个问题，一台独立的Mac，可以同时给多个IOS构建流程提供支持，如果需要更新环境也只需要处理一台即可。而且编译代码的耗时相对固定，且能够进行增量编译，理论上来说只要不是所有的机器同时执行全量编译，那么对于Mac的性能压力就没有那么大。博客中也有开启远程构建IOS的文章：UE 开发笔记：Mac/iOS 篇，可以参考基础配置启用。但UE默认实现的IOS远程构建在实际使用中也存在不少的问题，无法实现从部署到构建全自动化流程，本篇文章会针对远程构建在实际的工程应用中痛点进行优化。 ...继续阅读 (88)

深圳与香港仅一江之隔，虽早有打算去香港玩一圈，但因为前两三年因为疫情的原因迟迟未能成行。今年疫情放开之后，香港和内地之间通关也变得比较方便了，所以把去香港提上了日程。周末和老婆一起去香港玩了一趟，去之前做了一些攻略和行程安排，可以作为首次去香港旅游的参考。 ...继续阅读 (75)

工欲善其事，必先利其器！以ChatGPT和Stable Diffusion为代表的AIGC工具横空出世，AI浪潮席卷了各行各业。作为开发者，如何利用AI的能力，提升做事情的效率，是个值得研究的问题。现阶段需要注意的是，GPT回复的内容非完全准确，存在胡诌的可能。但它的潜力在于有望实现了一种通用型的AI助手。没有人能在所有领域都具备专家级别的知识，在不熟悉的领域，充分利用GPT能够显著降低上手成本。本篇文章我会介绍，利用GPT助力工作、生活和学习的一些案例，以及使用GPT API进行二次开发应用场景的探索。文后会分享一些我在使用的Prompts，并推荐一些我觉得不错的GPT工具，以及对Azure OpenAI服务使用Cloudflare Worker封装的方案。 ...继续阅读 (72)

DevOps是一种思想，以自动化进行持续集成(CI)和持续部署(CD)为基础，优化开发、测试、运维等所有环节。强调软件开发测试运维的一体化，减少各个部门或流程之间的沟通成本从而实现快速高质量的发布和迭代。虽然在游戏领域的开发情况和传统互联网有很大区别，但借用DevOps的概念把项目中所有的生产环节最大限度地接入自动化，能够大幅提升效率。本篇文章会介绍，UE实现自动化的基础概念，及我在虚幻引擎自动化构建方面的一些尝试和实际的工程实践。 ...继续阅读 (77)

最近总会产生一种莫名的焦虑感，经过一段时间的自我观察和思考，我认为需要直面这些问题并尝试给出回答。本文是对当前生活状态和问题进行研究并剖析的思想实验，总结用于指导生活和工作的思想工具。作为个人方法论，其中包含大量的主观内容。 ...继续阅读 (73)

在游戏项目开发中，会涉及到大量的开发、美术、策划以及外包等等各个方面的研发人员。出于资源安全和信息保密的考虑，通常会做一些复杂的权限控制和同步逻辑。但抛开权限控制，仅探讨资源本身，在UE中资源是向上兼容的，用同版本号的引擎或者更高版本号的引擎可以直接打开。这意味着分发出去的资源，可以直接在另外的项目里使用。所以，该如何保证开发阶段资源的安全性是要重点关注的。本篇文章提供一种加密工程中原始UASSET资源的思路，并介绍可以用于资源加密的基础原理。但如果公开具体的加密实现，就等同于裸奔，所以本篇文章仅提供对uasset资源结构的分析以及可用于实现加密的思路，但不会提供具体的实现代码。 ...继续阅读 (71)

在使用UnrealEngine开发工具时，有相当一部分的情况是对资源处理和数据导出需求，这些任务是需要频繁且自动化执行的，通常会把它们集成到CI/CD系统中。在具体的实现中，就要利用UE的Commandlet机制，用命令行的形式去驱动引擎，做自定的行为。以我开发的插件中支持的Commandlet功能为例：HotPatcher：导出基础包信息、打包补丁ResScannerUE：变动资源的增量扫描HotChunker：独立打包ChunklibZSTD：训练Shader字典ExportNavMesh：导出NavMesh数据Commandlet能够使它们比较方便地集成到CI/CD中，实现自动化。本篇文章中，我将会主要介绍UE的Commandlet机制，并分析它的实现原理，以及提供一些开发技巧、我在开发过程中的一些思考等。同时，这也是我UE插件与工具开发系列的第二篇文章，后续会持续更新，敬请期待。 ...继续阅读 (76)

之前我写了一篇文章，介绍UE默认的拆包方式(UE 热更新：拆分基础包)，但UE默认的拆包方式在大规模资源项目中不够灵活，无法满足对超大规模资源项目的精细化管理需求。为了解决UE默认打包和资源拆分的痛点，我基于HotPatcherCore开发了一个扩展，能够能够解决默认拆包流程的缺点，足够地灵活与强大。博客中有篇文章，介绍它的整体实现机制：一种灵活与非侵入式的基础包拆分方案。HotChunker能够非侵入式地集成到UE默认的打包流程中，无需手动做任何的处理，只要UE默认打包，就会自动拉起HotChunker的拆包流程，实现资源的Cook、打包，以及自动Copy到StagedBuilds目录中。本篇文章会着重介绍，使用HotChunker在进行资源拆分的配置方式和自动化构建、最大限度地降低资源冗余、以及进行并行打包的实现。 ...继续阅读 (81)

内存优化是游戏开发中经常关注的课题，为了避免App过度分配内存触发OOM被系统强杀，通常的优化手段是从使用层面入手，提升内存的利用效率，裁剪不需要的功能、控制加载的资源等等。但还有一种情况，提升App触发OOM的阈值，让系统允许我们的App分配更多的内存。在新的IOS版本中，苹果为App引入了新的内存特性，可以允许App扩展寻址空间和提高可分配内存。本篇文章，我将研究如何把这些特性在UE内利用起来，提高游戏在IOS平台的可分配内存总量。 ...继续阅读 (70)

在使用UnrealEngine进行项目开发的过程中，经常会开发和接入各种类型的插件来对引擎进行扩展，从而实现不同的需求。对于开发者而言，对运行机制的理解优于工具的使用。所以对于插件的接入和开发，有必要了解其原理。之前我也开发了一些UE的工具和插件，我希望写一个相关的系列文章，把UE插件与工具开发相关具有共性的技术内容做一些总结，并分享一些我开发插件时的一些思考和功能脚手架。尽可能用最少的代码、最小的侵入式和最佳的实现策略，来实现需要的功能。 ...继续阅读 (88)

随着HotPatcher的开发以及我对于资源管理方面的技术的研究，围绕着HotPatcher实现的功能越来越多，实现也越来越复杂，加上引擎的不断更新，一个大而全的插件对引擎的兼容性越来越难以维护。随着新一代引擎UE5的到来，HotPatcher同样会跟进UE5中支持，并针对UE5的特性开发新的功能。我希望它不仅仅只是一个资源打包工具，而是包含资源管理、审计、打包、热更新、包体优化、构建提升等等全方位的资源管理方案，并且作为一个开放式的资源处理框架。本篇文章会介绍HotPatcher的模块化进展，对现有功能的支持。以及如何利用HotPatcher强大的打包能力根据项目需求进行自定义的模块化扩展。最后，会介绍HotPatcher项目后续的开发计划。 ...继续阅读 (74)

2022年的Unreal Open Day是Epic官方以线下活动+线上直播的形式进行的，很开心今年参加了线下的Unreal Open Day活动。今年我录制了一场线上的技术演讲，也去上海直播现场参加了线下活动，很荣幸再次获得了Epic授予的杰出社区贡献者奖项，对我是认可也是激励，期待UE技术社区能发展的越来越好，成为最为活跃的游戏开发者社区。本篇文章做一个简单的记录，把 UOD 2022的资料做一下整理，也把我参加 UOD 的视频、演讲 PPT，以及相关的资料做一个总结，还有一些在 UOD 直播现场拍的照片。 ...继续阅读 (58)

UE默认的资源管理较为复杂，默认情况下是根据在ProjectSetting里配置的地图、目录、PrimaryAsset的配置，以及对一些条件的组合检测来执行资源打包过程的。并且，UE的Cook是根据运行时的动态加载来实时添加资源打到包中的，这导致打包的资源进包过程几乎等同于黑盒。博客中介绍默认的进包资源规则及基础包拆分的文章：UE 资源管理：引擎打包资源分析UE 热更新：拆分基础包本篇文章提供了一种新的思路，利用HotPatcher的精确Cook和打包机制，实现了一个HotChunker的Mod，能够对引擎的非侵入式，直接复用UE默认打包过程、简单清晰地进行拆分基础包。本篇文会具体介绍使用方式以及实现原理。 ...继续阅读 (81)

技术文章是能够有效锻炼表达能力和进行技术积累的方法。与单纯的技术笔记不同，我认为的技术文章应该是对实际的问题或新技术思路的解决方案，而不是技术点的简单堆砌。对于如何写一篇我认为合格的技术文章， 最近做了一些思考，本篇文章会探讨我写文章时的一些思路和步骤，以及工具推荐和CI/CD自动化发布的实现。 ...继续阅读 (72)

ASTC是Adaptive Scalable Texture Compression的简称，是在移动端流行的贴图压缩方案。当平台使用ASTC打包时，UE默认使用Intel ISPC Texture Compressor压缩贴图，但它具有一些局限性，只支持8x8及以上的压缩规格，10x10和12x12则不支持，如果在项目中指定它们，也是会使用8x8的规格。除ISPC外，引擎中也提供了ARM的astc-encoder压缩方式，可以支持8x8以下的规格，但默认未启用，而且引擎中的集成压缩效率非常低，在大规模资源中，使用astc-encoder压缩贴图对Cook耗时是非常大的挑战。本篇文章分析UE中贴图使用ASTC压缩的配置以及实现方式，以及引擎中astc-encoder的压缩效率和优化思路。 ...继续阅读 (77)

在大型项目中，资源的规模非常庞大，涉及的制作团队也非常广泛，场景、角色、UI、动画、特效、蓝图、数据表格等等，随之而来就是资源量和资源规范的管理难以把控。对于制定的资源规格，美术制作人员难以覆盖100%的情况，会存在不经意间漏掉，大多数情况下都是包内发现问题后再处理，而且对于存量的资源，需要耗费大量的人力处理，难以审查和修复。基于这种痛点，我之前开发了一个资源扫描工具，可以方便地编辑规则对项目内的资源进行扫描。UE 中利用反射为资产建立属性缓存UE 中资源自修正的设计与实现方案UE 中多阶段的自动化资源检查方案基于ResScannerUE的资源检查自动化实践UE资源合规检查工具ResScannerUE近期，我对插件做了全方面地升级，增强了编辑时和自动化检查的能力，本篇文章会介绍如何利用ResScannerUE实现编辑时、提交时、CI定时或Hook任务、Cook时等各个阶段的资源扫描，把错误地资源尽可能地在制作时暴露出来并提示解决，避免包内资源异常。在插件的具体实现上，也针对扫描速度做了很多优化，尽可能把检查变成一个无感知的行为，文章内会具体介绍。 ...继续阅读 (73)

在文章基于 ZSTD 字典的 Shader 压缩方案中，我介绍了一种利用ZSTD字典压缩UE的ShaderCode的方法，可以极大地提升ShaderLibrary的压缩比。但训练字典和使用字典进行压缩的流程仍然比较复杂，并不是一个高效的工程实现：需关闭引擎默认的Shader压缩Cook一遍项目才能Dump每个Unique Shader的ShaderCode基于Dump出的ShaderCode文件，使用ZSTD程序训练字典再次执行完整的Cook过程，使用字典进行压缩，生成最终的shaderbytecode根据上述的流程，需要变动引擎才能实现Dump ShaderCode；其次是流程的割裂，Dump ShaderCode之后需要拉起zstd程序执行训练才能得到字典；最后，仍需要再Cook一遍工程，使用训练出的字典压缩Shader。并且在关掉Shader的压缩后会导致使用LZ4压缩的DDC Cache Miss，重复Cook执行的时间开销巨大，在海量Shader的项目中耗时无法接受。基于这种痛点，我研究并实现了一种高效的字典训练方法，无需修改引擎，并且十分快速地训练字典和基于字典压缩。能够直接从ushaderbytecode中训练字典，并生成使用ZSTD+字典压缩的ushaderbytecode，极大地提升了处理效率，完全Plugin-Only的实现，接入成本几乎为零，后续将作为HotP ...继续阅读 (68)

Pak是UE中的UFS中的一环（Unreal File System），是在应用层构造的一种虚拟文件系统。用于把游戏相关的资源、文件打包至一个Pak文件中，避免在运行时对游戏资源的访问创建出大量的文件句柄，并且可以做读缓存（PakCache），提升加载效率。并且，在UFS中，可以控制每个Pak的优先级，可以用来控制文件系统中文件的优先级。在通过UFS加载文件时，优先级高的Pak中的文件会被首先命中，就可以替换掉低优先级的文件，这也是UE实现热更新的关键，详见之前的热更新系列文章。但默认情况下，Pak的打包都是在UE端进行的，PakUtilities和UnrealPak都是开发端的功能，运行时不存在，这意味着不能在运行时创建出Pak文件。但Pak本身是Archive的文件形式，理论上是可以进行运行时重组的。本篇文章就从Pak的创建、文件格式、UFS分析、运行时重组可行性等方面着手，探讨运行时重组Pak的实现细节以及应用方向。 ...继续阅读 (68)