在2020年，我曾写过一篇文章如何构建自己的知识体系？，其中主要是对于日常技术积累的思考，偏向于方法论。
本篇文章会从工具和实际使用的角度出发，基于Obsidian探索个人知识管理的可能性，并尝试将其与Hexo博客结合起来。当然，这种工具偏好和实践具有强主观性，本文完全从我个人的实践和经历出发，没有最好的工具，只有最适合自己的。
深圳与香港仅一江之隔，虽早有打算去香港玩一圈，但因为前两三年因为疫情的原因迟迟未能成行。今年疫情放开之后，香港和内地之间通关也变得比较方便了，所以把去香港提上了日程。
周末和老婆一起去香港玩了一趟，去之前做了一些攻略和行程安排，可以作为首次去香港旅游的参考。
远程构建是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远程构建在实际使用中也存在不少的问题，无法实现从部署到构建全自动化流程，本篇文章会针对远程构建在实际的工程应用中痛点进行优化。
工欲善其事，必先利其器！以ChatGPT和Stable Diffusion为代表的AIGC工具横空出世，AI浪潮席卷了各行各业。作为开发者，如何利用AI的能力，提升做事情的效率，是个值得研究的问题。
现阶段需要注意的是，GPT回复的内容非完全准确，存在胡诌的可能。但它的潜力在于有望实现了一种通用型的AI助手。没有人能在所有领域都具备专家级别的知识，在不熟悉的领域，充分利用GPT能够显著降低上手成本。
本篇文章我会介绍，利用GPT助力工作、生活和学习的一些案例，以及使用GPT API进行二次开发应用场景的探索。文后会分享一些我在使用的Prompts，并推荐一些我觉得不错的GPT工具，以及对Azure OpenAI服务使用Cloudflare Worker封装的方案。
DevOps是一种思想，以自动化进行持续集成(CI)和持续部署(CD)为基础，优化开发、测试、运维等所有环节。强调软件开发测试运维的一体化，减少各个部门或流程之间的沟通成本从而实现快速高质量的发布和迭代。
虽然在游戏领域的开发情况和传统互联网有很大区别，但借用DevOps的概念把项目中所有的生产环节最大限度地接入自动化，能够大幅提升效率。
本篇文章会介绍，UE实现自动化的基础概念，及我在虚幻引擎自动化构建方面的一些尝试和实际的工程实践。
最近总会产生一种莫名的焦虑感，经过一段时间的自我观察和思考，我认为需要直面这些问题并尝试给出回答。
本文是对当前生活状态和问题进行研究并剖析的思想实验，总结用于指导生活和工作的思想工具。作为个人方法论，其中包含大量的主观内容。
在游戏项目开发中，会涉及到大量的开发、美术、策划以及外包等等各个方面的研发人员。出于资源安全和信息保密的考虑，通常会做一些复杂的权限控制和同步逻辑。
但抛开权限控制，仅探讨资源本身，在UE中资源是向上兼容的，用同版本号的引擎或者更高版本号的引擎可以直接打开。这意味着分发出去的资源，可以直接在另外的项目里使用。所以，该如何保证开发阶段资源的安全性是要重点关注的。
本篇文章提供一种加密工程中原始UASSET资源的思路，并介绍可以用于资源加密的基础原理。但如果公开具体的加密实现，就等同于裸奔，所以本篇文章仅提供对uasset资源结构的分析以及可用于实现加密的思路，但不会提供具体的实现代码。
在使用UnrealEngine开发工具时，有相当一部分的情况是对资源处理和数据导出需求，这些任务是需要频繁且自动化执行的，通常会把它们集成到CI/CD系统中。
在具体的实现中，就要利用UE的Commandlet机制，用命令行的形式去驱动引擎，做自定的行为。
以我开发的插件中支持的Commandlet功能为例：
Commandlet能够使它们比较方便地集成到CI/CD中，实现自动化。
本篇文章中，我将会主要介绍UE的Commandlet机制，并分析它的实现原理，以及提供一些开发技巧、我在开发过程中的一些思考等。
同时，这也是我UE插件与工具开发系列的第二篇文章，后续会持续更新，敬请期待。
之前我写了一篇文章，介绍UE默认的拆包方式(UE 热更新：拆分基础包)，但UE默认的拆包方式在大规模资源项目中不够灵活，无法满足对超大规模资源项目的精细化管理需求。
为了解决UE默认打包和资源拆分的痛点，我基于HotPatcherCore开发了一个扩展，能够能够解决默认拆包流程的缺点，足够地灵活与强大。博客中有篇文章，介绍它的整体实现机制： 一种灵活与非侵入式的基础包拆分方案。
HotChunker能够非侵入式地集成到UE默认的打包流程中，无需手动做任何的处理，只要UE默认打包，就会自动拉起HotChunker的拆包流程，实现资源的Cook、打包，以及自动Copy到StagedBuilds目录中。
本篇文章会着重介绍，使用HotChunker在进行资源拆分的配置方式和自动化构建、最大限度地降低资源冗余、以及进行并行打包的实现。
内存优化是游戏开发中经常关注的课题，为了避免App过度分配内存触发OOM被系统强杀，通常的优化手段是从使用层面入手，提升内存的利用效率，裁剪不需要的功能、控制加载的资源等等。
但还有一种情况，提升App触发OOM的阈值，让系统允许我们的App分配更多的内存。在新的IOS版本中，苹果为App引入了新的内存特性，可以允许App扩展寻址空间和提高可分配内存。
本篇文章，我将研究如何把这些特性在UE内利用起来，提高游戏在IOS平台的可分配内存总量。