在开发游戏时，程序性能是需要着重考虑的问题，因为要尽可能覆盖最多的用户群体，就要考虑那些中低端设备的运行效果，兼容非常多配置差异的硬件，在这种情况下，怎么样分析和优化游戏的性能瓶颈是关键。
在运行时把更多的资源加载至内存中，本质上是一种空间换时间的思路。因为频繁从磁盘进行IO是非常耗时的，把资源预先加载到内存就可以实现高速读取，但是内存资源也是有限的，并不能不加限制地使用，尤其是对某些中低端移动设备而言，4G甚至更小的内存的设备目前还具有不少的占有率，所以在内存方面不能浪费，而且过高的内存占用也有可能导致被系统查杀。
内存优化本质上就是在加载效率和内存占用之间寻求一个平衡，怎么样在能满足兼容更多低配设备正常运行不触发OOM的同时尽可能地把可利用的内存使用起来，提高程序的运行效率。
准备写几篇性能优化相关的文章，本篇文章先从UE内存分析入手，介绍常用的内存分析工具和方法，以及对UE项目中能够进行的内存优化手段做一个整理，这部分内容之前以笔记的形式记录在notes/ue中，后续内存相关的内容都会补充到本篇文章。
HotPatcher项目开源这一年多以来，经过了不少的更新和优化，也被越来越多的开发者选择作为自己项目的热更新方案，期间有不少人陆陆续续询问UE4热更新相关遇到的问题，很多问题比较常见，重复询问的频率也比较多，所以我准备把一些常见的问题进行整理，方便初步上手UE4热更新方案的人能够尽快地排查问题。
本篇文章会持续更新UE4热更新和HotPatcher相关的Q&A内容，有疑问的地方也可以直接在本篇文章中评论，我会定期统一回答和整理，也可以加入我的UE4热更新群讨论遇到的问题(QQ群958363331)。
之前的热更新系列文章中介绍了UE热更新的流程和打包细节，其实有一些热更补丁优化的工程实践我觉得也可以详细介绍。
本篇文章从生成Shader的Patch入手，目的减少每次热更新时的Shader的大小，并会对引擎内部的实现细节做一些分析，解决引擎中的Shader Patch的相关问题，并基于HotPatcher的实现自动化的Shade Patch流程。
2021.11.02 UPDATE：HotPatcher已支持对Patch中所有Cook资源编译的Shader收集起来打包为Shader Library，可以替代Shader Patch的机制。详情见文章：UE热更新：Shader更新策略。
之前写了两篇UE中实现反射的文章分析，介绍了UE的反射基础概念和依赖的一些C++特性，本篇文章开始分析UE反射实现的具体流程。
C++标准中并没有反射的特性，UE使用的反射是基于标记语法和UHT扫描生成辅助代码来实现的一套机制，正如David Wheeler的那句名言一样：“All problems in computer science can be solved by another level of indirection”，UHT做的就是这样的事情，在真正执行编译之前分析标记代码并产生真正的C++代码，收集反射类型的元数据，供运行时之用。
UHT生成的代码内容很多，为了避免文章组织上的混乱，本篇文章主要讲GENERATED_BODY/UFUNCTION等反射标记通过UHT之后生成到generated.h中的真正的C++代码。
UHT生成的代码分别在generated.h和gen.cpp中，generated.h中的代码大多是定义了一些宏，用在所声明的类内通过编译器预处理来添加通用成员，gen.cpp中的代码则是UHT基于反射标记生成的用来描述类反射信息的具体代码，genrated.h和gen.cpp也是为了声明和定义分离。
在前面的文章中，介绍了基础包的拆分规则和实现，在基础的打包规则稳定之后，日常开发中的关注重点就转向侧重于项目的资产管理和包体资源审计、分析项目中的资产大小和冗余情况等。
本篇文章介绍UE中的资源打包配置、常用的资产管理方式以及资产审计工具等工程实践，热更新系列文章的资源管理篇，也是对上一篇文章UE4热更新：拆分基础包的内容补充。
在之前的几篇文章中，分别介绍了UE热更新的实现机制，以及热更的自动化流程，近期打算继续写几篇文章介绍下UE里热更新中资源包管理的流程和规则。
当然，不同类型的项目会有不同的打包策略，资源管理也没有通用的最佳策略。本篇文章主要介绍热更新流程中基础包的拆分的工程实践，涉及修改引擎实现Android/IOS通用拆分方式的方法，希望对不同业务的项目能提供一些有用的思路。
在实际的工程实践中，我们抛弃了UE自带的包拆分方案，基于HotPatcher框架实现了一套灵活的包拆分方案，详见文章：资源管理：重塑 UE 的包拆分方案。
HotPatcher是我之前开源的一个UE4热更新版本管理和资源打包工具，可以方便地进行版本间的差异分析和pak打包。之前的文章为了直观地介绍都是基于手动地在编辑器中进行配置和打包的，在真正的工程实践中，可以自动化的重复操作就要避免手动的参与，较早之前我就在插件中添加了commandlet的支持，近期修复了一些问题以及增加了很多针对commandlet的优化，本篇文章是基于HotPatcher的自动化热更新流程的工程实践。
开源，不仅仅只是需要把代码开放那么简单，而是怎么样用自己的代码去解决实际的需求、进行不断地迭代更新、以及构建开源项目的交流社区。根据过去一两年的开源经历，聊一聊我从开发者角度思考开源的观点以及对开源行为的一点想法。
在前一篇文章中，介绍了UE的反射的基础概念，这篇文章开始研究UE的反射机制的具体实现。
在介绍UE的代码之前，需要先要介绍一些C++特性，虽然UE的反射实现是大量依赖UHT的代码生成的，但是也需要C++的语法特性支持，只有把这些特性还有它们背后的含义了解清楚，才能够更好地理解UE的反射机制。
本篇文章中介绍的C++的特性和标准描述均基于ISO/IEC 14882:2014，也就是C++14标准。
反射，是指程序在运行时进行自检的的能力，在编辑器的属性面板、序列化、GC等方面非常有用。但是C++语言本身不支持反射特性，UE在C++的语法基础上通过UHT实现了反射信息的生成，从而实现了运行时的反射的目的。
在之前的文章中，有一些涉及到UE的构建系统和反射相关的内容。
涉及了UE的构建系统文章：
基于UE的反射机制来做一些奇淫巧技的文章：
UE的反射实现是依赖于构建系统中UHT来执行代码生成的，本篇文章对UE的反射做一个基础概念介绍，后续会花几篇文章完整地介绍UE里反射的实现机制。