欢迎访问循迹研究室，Github上的开源项目：github.com/hxhb以及项目介绍，热更新方案的系列文章：Unreal Engine#热更新。
一些在工作之余研究和开发的技术方案与成果预览：展示柜，如果您对其中某些项目感兴趣可以发邮件到imzlp@foxmail.com。
除本站外，我还创建了一个由社区驱动的虚幻引擎中文知识库站点https://ue5wiki.com/，托管在Github Pages上。欢迎投稿技术内容，为建设虚幻中文技术社区添砖加瓦！投稿规则请看：Wiki内容编写格式与规则。
之前我写了一篇文章，介绍UE默认的拆包方式(UE 热更新：拆分基础包)，但UE默认的拆包方式在大规模资源项目中不够灵活，无法满足对超大规模资源项目的精细化管理需求。
为了解决UE默认打包和资源拆分的痛点，我基于HotPatcherCore开发了一个扩展，能够能够解决默认拆包流程的缺点，足够地灵活与强大。博客中有篇文章，介绍它的整体实现机制： 一种灵活与非侵入式的基础包拆分方案。
HotChunker能够非侵入式地集成到UE默认的打包流程中，无需手动做任何的处理，只要UE默认打包，就会自动拉起HotChunker的拆包流程，实现资源的Cook、打包，以及自动Copy到StagedBuilds目录中。
本篇文章会着重介绍，使用HotChunker在进行资源拆分的配置方式和自动化构建、最大限度地降低资源冗余、以及进行并行打包的实现。
内存优化是游戏开发中经常关注的课题，为了避免App过度分配内存触发OOM被系统强杀，通常的优化手段是从使用层面入手，提升内存的利用效率，裁剪不需要的功能、控制加载的资源等等。
但还有一种情况，提升App触发OOM的阈值，让系统允许我们的App分配更多的内存。在新的IOS版本中，苹果为App引入了新的内存特性，可以允许App扩展寻址空间和提高可分配内存。
本篇文章，我将研究如何把这些特性在UE内利用起来，提高游戏在IOS平台的可分配内存总量。
在使用UnrealEngine进行项目开发的过程中，经常会开发和接入各种类型的插件来对引擎进行扩展，从而实现不同的需求。对于开发者而言，对运行机制的理解优于工具的使用。所以对于插件的接入和开发，有必要了解其原理。
之前我也开发了一些UE的工具和插件，我希望写一个相关的系列文章，把UE插件与工具开发相关具有共性的技术内容做一些总结，并分享一些我开发插件时的一些思考和功能脚手架。尽可能用最少的代码、最小的侵入式和最佳的实现策略，来实现需要的功能。
随着HotPatcher的开发以及我对于资源管理方面的技术的研究，围绕着HotPatcher实现的功能越来越多，实现也越来越复杂，加上引擎的不断更新，一个大而全的插件对引擎的兼容性越来越难以维护。
随着新一代引擎UE5的到来，HotPatcher同样会跟进UE5中支持，并针对UE5的特性开发新的功能。我希望它不仅仅只是一个资源打包工具，而是包含资源管理、审计、打包、热更新、包体优化、构建提升等等全方位的资源管理方案，并且作为一个开放式的资源处理框架。
本篇文章会介绍HotPatcher的模块化进展，对现有功能的支持。以及如何利用HotPatcher强大的打包能力根据项目需求进行自定义的模块化扩展。最后，会介绍HotPatcher项目后续的开发计划。
2022年的Unreal Open Day是Epic官方以线下活动+线上直播的形式进行的，很开心今年参加了线下的Unreal Open Day活动。
今年我录制了一场线上的技术演讲，也去上海直播现场参加了线下活动，很荣幸再次获得了Epic授予的杰出社区贡献者奖项，对我是认可也是激励，期待UE技术社区能发展的越来越好，成为最为活跃的游戏开发者社区。
本篇文章做一个简单的记录，把 UOD 2022的资料做一下整理，也把我参加 UOD 的视频、演讲 PPT，以及相关的资料做一个总结，还有一些在 UOD 直播现场拍的照片。
UE默认的资源管理较为复杂，默认情况下是根据在ProjectSetting里配置的地图、目录、PrimaryAsset的配置，以及对一些条件的组合检测来执行资源打包过程的。并且，UE的Cook是根据运行时的动态加载来实时添加资源打到包中的，这导致打包的资源进包过程几乎等同于黑盒。
博客中介绍默认的进包资源规则及基础包拆分的文章：
本篇文章提供了一种新的思路，利用HotPatcher的精确Cook和打包机制，实现了一个HotChunker的Mod，能够对引擎的非侵入式，直接复用UE默认打包过程、简单清晰地进行拆分基础包。本篇文会具体介绍使用方式以及实现原理。
技术文章是能够有效锻炼表达能力和进行技术积累的方法。与单纯的技术笔记不同，我认为的技术文章应该是对实际的问题或新技术思路的解决方案，而不是技术点的简单堆砌。
对于如何写一篇我认为合格的技术文章， 最近做了一些思考，本篇文章会探讨我写文章时的一些思路和步骤，以及工具推荐和CI/CD自动化发布的实现。
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的压缩效率和优化思路。
在大型项目中，资源的规模非常庞大，涉及的制作团队也非常广泛，场景、角色、UI、动画、特效、蓝图、数据表格等等，随之而来就是资源量和资源规范的管理难以把控。
对于制定的资源规格，美术制作人员难以覆盖100%的情况，会存在不经意间漏掉，大多数情况下都是包内发现问题后再处理，而且对于存量的资源，需要耗费大量的人力处理，难以审查和修复。
基于这种痛点，我之前开发了一个资源扫描工具，可以方便地编辑规则对项目内的资源进行扫描。
近期，我对插件做了全方面地升级，增强了编辑时和自动化检查的能力，本篇文章会介绍如何利用ResScannerUE实现编辑时、提交时、CI定时或Hook任务、Cook时等各个阶段的资源扫描，把错误地资源尽可能地在制作时暴露出来并提示解决，避免包内资源异常。
在插件的具体实现上，也针对扫描速度做了很多优化，尽可能把检查变成一个无感知的行为，文章内会具体介绍。
集成UE到原生Xcode iOS工程
UE中人体姿态追踪
基于字典的Shader压缩方案
Pak的运行时重组热更方案
UE中多阶段的自动化资源检查方案
精确灵活的基础包拆分方案