CWHISME

# 前言 本篇笔记主要包含原书第一部分，第一章～第七章，从变量定义到类结束。 这次仔细从头开始看，包括最基础的语法都给重新过了一遍，虽然可能看得稍微有点快，而且做不到看完就熟稔了，不过至少重点记录了笔记，后续翻看一下，总能回忆不少印象。 说实话的话，补完这几章，再去看 UE 的 C++ 代码的时候，看起来就感觉更轻松些了 —— 毕竟理论知识确实是基础，自然比全然不知道的情况下去总结经验来得强。 这本书还是有点厚，不知道这次国庆节抽出的时间看不看得完。 像编译器一样来思考和理解 C++ 本书主要为 C++11 标准 # 第一章...

# 前言 说实话，关于正经游戏模式的书还是有点少，这本算是少数中的其中之一。 整本书看下来，发现书里并没有按照类似常规 “23 种设计模式” 这种概念来讲述，有不少其实都不存在于常规设计模式当中： 比如双缓冲、空间分区、脏标记等... 确实跟书名更符一点，讲的是 “游戏编程模式”，而不是单纯的设计模式。 不过，要说是是游戏程序设计方面的书籍，本书肯定是算的。总之值得一看。 # 介绍 设计模式相关的书籍，主要是为了做到如何更好组织程序 编写超出大脑思考范围的程序，需要更好的设计与组织。 宝藏埋在代码深处，而许多人正在它们之上路过。 作者将其描述的模式分为：序列型、行为型、解藕型、优化型 #...

# 前言 前几天 Unity 公布了新的 收费政策，然后整个开发者社区都沸腾了，处处都是 讨论的声音，不管最后实际生效政策如何 (2023.9.18 官方似乎更新了公告，说会对『运行费』政策进行修改)，这种杀鸡取卵的行为必然都会造成以后开发选择的考虑点。 之前本来还打算专一 Unity 的，比如前些日子都还一直在研究 HDRP，算是基本把 HDRP 物理光照、各种调参熟悉得七七八八了，结果就听到这么个消息... 简直是... 如果真的实施，人家独立开发只怕都会把这个作为一个很大比例权重考虑进去了，毕竟哪个游戏开发者没有想做个好玩 (爆款) 的大作的梦想呢？ 之前一直都关注 UE，比如 UE...

# 前言 本文包含原书第七章至第十五章，也就是本书最后一部分。 主要为对象资源释放、线程局部存储、托管指针、ref 类型、非托管类型、非托管约束、 Span<T> 、 Memory<T> 、Unsafe 类、面向数据设计 等高级主题。 这是本书的最后一份笔记，没想到整体看完这本书花了 2 月有余... 说来惭愧，这两个月花了太多时间在其它东西上去了：玩游戏，比如最近的蔚蓝档案、或者在家看 HDRP 相关的教程。 虽然除了玩游戏也不能说全无相关，但确实是这次没有专心看书了，导致时间线被严重拉长 ——...

# 前言 本文包含原书第七章至第十一章，主要为 .NET 垃圾回收过程的详细描述 # 第七章 垃圾回收 - 简介 # 高层视图 .NET GC 的两种模式： 工作站模式：最大限度减少 GC 引入的延迟，GC 频率更高 非并发：GC 时应用程序所有托管线程都挂起 服务器模式：最大限度提高应用程序的吞吐量，GC 频率更低 并发：GC 的某些部分在托管现在还在工作时执行 # GC 过程示例 垃圾回收是在特定代的上下文中发生，该代称为被判决的代。 可决定同时回收比当前被判决代更小的代 # 第 0 代被判决的垃圾回收： 仅检查第 0 代中对象的可达性 第 0 代变为空...

# 前言 本篇包含原书第五章和第六章，主要讲了 .NET 内存分区和内存分配方式 小对象通过指针快速分配 (多数情况下) 大对象通过空闲列表分配 (因此最好避免) 并提出了一些优化方式：避免分配，包括显式和隐式分配等 # 第五章 内存分区 # 分区策略 总体上有： 大小 生存期 可变性 类型 种类 简单来说，.NET 根据『大小』和『生存期』作为分区策略。 # 按大小分区 .NET 根据大小处理不同对象，分为两类： 小对象堆 (SOH)：所有小于 85000 字节的对象在此分区创建 大对象堆 (LOH)：所有大于或等于 85000 字节的对象在此创建 区别在于，默认情况下小对象堆在...

# 前言 本篇包含原书的第三章和第四章，第三章主要讲了一些测试工具使用，我自己也看得也比较囫囵吞枣 (毕竟个人是搞 Unity3D，这块多数工具基本都是没用的，当然部分理论依然还是可以参考的)。 其次是第四章的 .NET基础知识 ，这一章名字说是基础知识，实际上还是比较深入的，比如各个字段的内存区域、详细描述了为什么值类型 更快 等等。评价是 比较重要 。 # 第三章 内存测量 # 尽早测量 与其过早地专注于优化，不如先测量评估一下我们是否有这方面的需求。 # 开销和侵入性 开销：额外消耗 侵入性：游戏应用程序本身功能 # 采样与跟踪 跟踪：诊断数据在特定的、被关注的时间触发时收集...

# 前言 前两天公司其他同事在推荐让试一试 WXAssetBundle，看看性能是不是真的有所提升，然后顺便就看到微信官方推荐使用 Addressables 系统进行资源加载 (其实之前就有瞄到这文档，只是当时项目重点不在这，所以没怎么注意) 当然微信虽然推荐 Addressables ，也提到如果自己进行维护管理的 AB 包 性能肯定会比 AA (Addressables) 包更好 —— AA 包较大项目时生成的未压缩的 catalog...

# 第二章 底层内存管理 # 硬件 处理器 (CPU)：计算机的主单元，负责执行指令。包含算数逻辑单元 (ALU)、浮点单元 (FPU)、寄存器和指令来执行流水线 (负责高效执行被切分成一组更精简指令集的操作指令，并在可能的时候并行执行它们) 前端总线 (front side bus,fsb)：连接 CPU 和北桥的数据总线 北桥 (northbridge)：主要包含内存控制单元，负责控制内存和 CPU 之间的数据通信 RAM (随机存取存储器)：也叫易失性存储器 内存总线 (memory bus)：连接 RAM 和北桥的数据总线 南桥 (southbridge)：处理计算机所有 I/O...

# 前言 最开始是因为项目的一个问题：微信的 Unity 转小游戏，转出来的 XXXX.webgl.data.unityweb.bin.txt(首包资源文件) 文件极大，其中占据数量最多的是一系列的 MonoScript ，且经过对比检查，其它占用够大的 Shader、图片或冗余资源都被我一一处理过了，但是呢这个文件依然很大。 达到什么程度呢？公司其它项目转出来只有 7M，而我们的达到了 16M？！这正常吗？不正常吧！ 最麻烦的一点是：经过 AssetStudio 打开看之后，排头的只有寥寥几个资源，而且都不算大： 与只有 7M 资源的对比， AssetStudio...