Origin of Ray

最近在开发一个Unity人物形象的SDK，目标是该SDK可以动态下载最新的人物和服装的模型而不用让提前内置在SDK中。

一开始我打算采用的方案是传统的比较成熟的Addressables去打包bundle的方式，但是bundle的划分是个问题，而且这种方式需要每次把模型导入unity然后再出包，再更新catalog，整个流程比较繁琐。

所以我就在想，能不能直接从远程加载FBX和贴图，然后直接使用FBX进行加载就好，这样整个发版流程会简单很多。

经过一番查找，找到了TriLib这个仓库，他可以很方便的从远程加载模型。但是也有一些问题，为了定位这些问题，特意阅读了下源码，这里总结下，其实感觉整个仓库的逻辑是比较简单清晰的。

我们正式开始学习一些能够应用的Shader，这次我们就从光照模型开始。本文中的代码和概念解读自《Unity Shader 入门精要》.

本文主要讲解书中的几种光照模型的原理和代码分析。

前面的几篇博客讲了游戏渲染的基本原理和如何在Unity里写一个Shader，这篇博客先插入两个概念：

• Unity中不同物体之间的渲染顺序何覆盖关系是怎样的，也就是渲染顺序。
• Unity的渲染路径又是什么，和渲染顺序有什么关系？

在内置渲染管线中，表面着色器是编写与光照交互的着色器的一种简化方式。

编写与光照交互的着色器非常复杂。有不同的光源类型，不同的阴影选项，不同的渲染路径（前向和延迟渲染）；着色器应该以某种方式应对所有这些复杂性。

表面着色器是一种代码生成方法，与使用低级顶点/像素着色器程序相比，可以更轻松地编写光照着色器。

在Unity中，我们使用HLSL的语法来写Shader Program，不过一开始Unity采用的是CG语法，因此会使用 Unity 某些关键字的名称 (CGPROGRAM) 和文件扩展名 (.cginc)。虽然Unity 不再使用 Cg，但这些名称仍在使用。

上一篇博客了解了一些Unity Shader的概念，继续看一下如何编写一个Shader。

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

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

• 计算机的存储管理，是分层次的，从高速缓存到内存到外存，速度依次降低，大小逐渐增大，价格逐渐便宜。
• 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这边也可以叫做符号表，因为它内部会保存虚拟内存地址与汇编代码的的对应关系。

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