Origin of Ray

前面介绍了渲染流水线的基本内容，接下来就其中的我们可以编程的部分进行介绍，开始之前我们需要先介绍一些基础概念，对其中的一些属性进行简单说明。

在看了计算机组成原理中的存储系统一章后，结合操作系统中的内存管理和文件管理，对整个计算机的存储管理有了新的理解，这里就一起杂糅着总结一下。
首先抛出几个我的总体看完以后的新的理解：

• 计算机的存储管理，是分层次的，从高速缓存到内存到外存，速度依次降低，大小逐渐增大，价格逐渐便宜。
• CPU从这三层获取数据的速度逐渐降低，我们存储管理搞了这么多骚操作，其实就是为了省钱的同时，既提高访问速度（局部性原理，层层缓存），又提高可用的地址空间（虚拟内存）
• 无论是哪个层次，所面对的问题都是地址的映射，空间的分配，以及空间不够时的置换替换策略（这三者之间是强相关的，比如分页的分配方式，地址映射就需要用到页表，请求式分页的分配方式，空间的分配和置换也是强相关的）。
• 只有存在空间不够的情况才需要置换策略，比如cache置换，比如请求式的分页的内存。像连续分配或者普通的分页式分配则不需要置换策略，空间不够就不分配，不存在把哪个内存暂时置换出来的问题。
• 各种空间管理方式之间不是独立的，是有内在的递进关系的。以内存分配为例，一开始是连续分配，但是发现连续分配很容易出现碎片化问题，就想到了不连续分配，不连续分配分为分段，分页和段页式，但是注意，到目前为止，只是内存分配的问题，整个程序还是需要一开始就完全加载到内存中。由此我们提出了虚拟内存的概念，为了配合虚拟内存，我们升级分段，分页和段页式为请求式的，页表项或者段表项中会多一些字段用于缺页时外存地址，会多一些字段用于内存置换时的标志。
• 分页/段和虚拟内存是两回事，分页是一种空间分配方式，虚拟内存是是一种逻辑上扩充内存空间的方式，只不过虚拟内存使用请求式的分页或分段而已。
• 连续分配和基本的分页分段只有分配策略，如首次适应算法，临近适应算法等，但是没有特别的置换策略，不存在程序还在运行时的置换，都是一次性全部分配，能分配则运行，运行完一次性全部卸载。而像请求式分页这种它的分配策略还牵扯到置换策略。
• 现代操作系统的内存访问路径大致是这样的：首先程序给出指令或者数据的虚拟内存相对地址，然后通过地址重定位得到虚拟内存的实际地址，然后去查询段表或者页表是否已经加载到了内存中，如果加载到了内存中，且在cache中，则直接从cache返回，如果在内存而不再cache，则从内存中加载并更新cache（可能发生替换），如果不在内存中，则从页表项中找到外存地址，加载到内存中（可能发生替换），再返回给CPU并更新cache。

最近在研究Unity性能优化相关的内容，接触了几个Unity官方自己的工具，这里总结一下它们的使用方式以及如何结合着使用。

我主要用到了以下几个工具：

• UPR（Unity Performance Report）
• Profiler
• Memory Profiler

首先总体上讲一下这三者之间的关系：Profiler是Unity Editor中自带的性能分析工具，不需要额外下载，能对CPU，GPU，内存，Render，物理，网络等等的性能数据进行搜集。而UPR则是利用了Profiler的数据进行了进一步的专业分析和统计，Memory Profiler是针对Profiler的内存数据进行了专门的分析，在运行期间可以进行内存的快照收集。

我们在将Unity打包成il2cpp+release模式的apk的之后，内部的代码是会被打包成so文件的，这个东西其实是linux的动态链接库的格式，对应的就是windows的dll或者Mac的dylib之类的东西。在android这边也可以叫做符号表，因为它内部会保存虚拟内存地址与汇编代码的的对应关系。

这样打包以后，会降低我们的包体积，而且有助于我们的代码保护不被抄袭，但是同时也会导致我们开发者看不懂报错信息，因为这些报错信息都是些虚拟内存地址，而不是函数的名字，那么对于线上发生的报错信息，我们怎么去阅读呢？

最近发现Unity项目在运行过程中消耗了很多的内存，而且会出现的很频繁的GC导致游戏的CPU过热。于是去阅读了一下官方的最佳实践文档，了解了一些Unity的内存管理的知识，稍微总结一下。

随着使用的逐渐增多，慢慢受不了在对这些概念的模糊的情况下使用了，所以找了些官方文档来学习一下C#中的这些概念，主要是为了区分委托（Delegate），事件（Event）。

其实我个人在读文档之前一直是对这些概念很模糊的，甚至一度被网上的各种博客绕晕了，甚至把Action，Func和委托都混淆了。

终于在我去读了官方的文档之后，我才对这些概念有了一些认知。

首先抛出最重要的结论，委托和事件都是为了提供后处理函数的方式，事件其实也是基于委托的多播的，而每次使用委托都要定义一个新的委托类型不方便，所以又提供了两种强类型的委托，就是Action和Func。

最近看了些关于Unity体积优化的方案的文章以及Unity官方文档，总结了一下

需求背景

游戏房间上限最大可以有count个人，当用户进入房间后，需要去远程服务器获取这count个人物的服装配置， 获取成功以后进行逐个加载。
目前的方案是一次性获取所有人物的配置，然后以一种几乎同时加载的方式去做。
这种方案最坏的情况下会同时有count个换装的任务在运行，导致count个任务之间抢占CPU，结果就是看起来卡顿。
为了使游戏的表现更加流畅，需要设计一种方案进行有优先级的批量加载。

我们都知道，计算机的核心是CPU，而CPU就是运算器和控制器，其作用就是进行数学运算。

想要理解CPU工作的原理，就要从两方面着手，一方面是计算机中的数据是如何表示的，另一方面就是在这种表示方式下，它的运算规则又是怎样的，计算机如何用电路去表示这种运算。

这周的每日一题有一道困难级别的题目，使用了一种叫做差分数组的技巧，这个技巧其实也不复杂，就是前缀和的反向操作，简单记录一下。

这是题目的链接：https://leetcode-cn.com/problems/smallest-rotation-with-highest-score/