欢迎访问循迹研究室，这是一个专注于游戏开发的技术站点。我在Github上的开源项目：github.com/hxhb及项目介绍。
博客内的文章，有C++系列，UnrealEngine的热更新、插件和工具开发、资源管理系列，以及循迹研究系列等。
在工作之余研究和开发的技术方案与成果预览：展示柜，如果您对其中某些项目感兴趣可以发邮件到imzlp@foxmail.com。
除本站外，我还创建了一个由社区驱动的虚幻引擎中文知识库站点https://ue5wiki.com/，托管在Github Pages上。欢迎投稿技术内容，为建设虚幻中文技术社区添砖加瓦！投稿规则请看：Wiki内容编写格式与规则。
在游戏项目中，当我们在打包各个平台时，总希望每个平台的包能够最小化便于分发，而且上架某些平台还有明确的大小要求。
对于UE而言，它包含了巨量代码以及大量的插件，Build阶段还将生成反射的胶水代码，在编译时产生了大量的代码段。以Android平台为例，将导致libUE4.so的大小急剧增长，对于包体和运行时内存都造成了压力。
再加上一些引擎必要和额外带入的资源也能占据上百M，空APK的大小很容易达到数百M的规模！不仅仅为了符合上架平台的要求，从包体和内存优化的角度，也有必要对UE包的大小进行裁剪。
本篇文章会以Android为例，从各个方面介绍UE包中的可裁剪部分的优化思路与实践，同时优化APK大小和Native库的运行时内存占用，其中的策略也可以复用在其他平台。
近期遇到了一个极为诡异的bug，分别有两张地图，其中一张地图A的PAK放在引擎自动挂载路径下可以进入，但是在热更目录不行，另一张地图B则完全相反，在自动挂载目录异常，但是在热更目录正常。
乍一看这个问题完全难以捉摸，两个互斥的行为出现在同一个表现逻辑中。而且热更挂载与自动挂载只是时机不同，优先级不同而已，按理说应该不会出现这个问题。
虽然最终这个问题可以在业务侧逻辑解决，但是这个表现也牵扯到了引擎中另一个极为隐蔽的路径，搞懂为什么以及它的原理是十分必要的。所以，我根据这种表现分析了引擎的代码，并得出了合理的结论，并制定一种检测和规避这种问题的方法。
本篇文章默认读者具有一些UE热更新的基础知识，如有疑问可查阅本博客中热更新系列的其他文章。
对于个人知识管理，我非常热衷于搞一套自己的local-first和开源的self-host的服务，这样就能不依赖任何平台、数据完全自主可控、服务可随时迁移。不管是Obsidian、Hexo博客、以及本篇文章介绍的memos，都是这个选择标准。
本文的主角，memos是一个开源的轻量级笔记的服务，可以像发微博的方式记笔记，支持TAG标记和引用。具有账号系统和权限管理，网页访问随时登录，笔记可以公开或私有，非常灵活。我选择它是因为可以跟Obsidian互为补充，Obsidian还是太重了，在PC上好用但移动端体验不佳。所以我需要一个轻量级、随时可用的一种笔记服务。
本篇文章会介绍，如何在VPS上用Docker部署一个Memos服务，并结合Nginx绑定域名、Certbot签发以及自动更新SSL证书和定时备份memos数据库，还有我为该服务做的一些配置优化。
在之前的文章中，主要在介绍HotPatcher如何应用在热更新流程里。但是HotPatcher并不只是能实现热更的需求，更是一个灵活的资源打包框架。
当项目开发进行到一定阶段，海量的资源需要进包，等待一次完整出包的时间会很久。如果真机出现问题，修复->打包->验证，这个串行流程就会变动极为冗长。经常会遇到脚本、数据或者某些的资源错误，导致包的异常。
这种情况下，再完整出一个包就等待数个小时的时间，导致测试无法进行冒烟跑测。就算重新出包也难保一定没有其他遗漏的问题，否则又要重来一遍。
基于这种痛点，我们迫切地需要一种在开发阶段能够快速地修复包内资源问题，进行快速验证的方法。而HotPatcher提供了这样的功能，如果能充分利用起来，就不必等待完整出包。
本篇文章会介绍，如何利用HotPatcher提供的编辑器功能，来快速打包预设配置和特定资源。加速资源在真机上的验证流程，大幅提升测试效率。
距离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年我曾经写过一篇文字：对开源的一些思考与想法，而过去这两年间，我对于维护开源项目的又有些新的想法，一起做个总结。
元旦期间，我的iPhone12跌落导致了一些故障，勉强能用。但前段时间电池也鼓包很容易自动关机，已经彻底不能用了。换了备机之后，搁置了一段时间。
最近想起来，因为还能正常开机，且主要功能还能正常使用，所以推测应该还是部分故障，不是整体损坏。完全报废有些可惜，只能换不锈钢盆了。
自己动手拆机分析了下故障原因，并尝试购买配件修理解决，本篇文章记录拆机和解决过程。
今年春节在深圳过年，计划大湾区旅行的下一站为澳门。而且从深圳去澳门也算比较方便，于是规划成行。做了一些攻略和行程安排，可以作为首次去澳门旅游的参考。
在前一篇文章UE中资源自修正的设计与实现方案中，我介绍了利用ResScannerUE的资产检查进行过滤，然后自动化处理的实现方案。
在通常情况下，如果想要检查资源内的某个属性，就需要把资产加载进来，获取对象：
但是，如果想要批量地检查资源的属性，用这种形式挨个加载资源的耗时很久，尤其是在没有DDC的情况下，加载资源就会触发DDC缓存的构建，这部分耗时很久，对于机器性能占比也较高。
而且随着资产规模的扩大，如果想要完整扫描一遍工程里的所有资源，耗时就会异常夸张。所以，我设想能否实现一种无需加载资源，但能够获取资源内属性的方法。
经过研究发现，通过一种取巧的方法做到这一点，利用了反射、资产序列化、以及AssetRegistry的特性组合起来。并且是非侵入式的，无需修改任何现有资源类型的代码。
本篇文章会介绍其实现原理，以及对引擎中相关逻辑的分析，并介绍该机制在工程中的实际应用。
在先前的文章中，我曾介绍了在UE中利用ResScannerUE进行资源的多阶段与自动化检查的实现和执行效率优化。
已经能够实现非常灵活地配置资源检查和及时提醒，具有非常强大的规则表达能力。但它们还都仅限于发现问题予以提醒的阶段，虽然有强制约束不能提交，但仍需人工地去处理。尤其是具有大量存量资源的情况下，手动处理的人力耗时非常大。
基于这种情况下，我设计了一种自动化修正资源的机制，能够在规范制定之后自动修复资源，确保被扫描出来资源的都被设置为正确的状态。
补齐了我这套资源检查方案中的最后一块拼图，并且可以应用在各个阶段的扫描过程，按需执行。本篇文章会介绍它的设计思路与实现机制，以及一些在项目中实际的应用场景。
集成UE到原生Xcode iOS工程
基于字典的Shader压缩方案
Pak的运行时重组热更方案
UE中多阶段的自动化资源检查方案
精确灵活的基础包拆分方案
UE中人体姿态追踪