weixin_49669470的博客

本文和传统的内存优化不一样，不是讲如何降低内存占用，而是讲编程开发中要注意的内存问题以及一些内存技术的演变与原理。对惹，这里有一个游戏开发交流小组，希望大家可以点击进来一起交流一下开发经验呀1: Application进程的内存分段应用程序的内存分为: 代码段, 数据段, 栈, 堆。代码段:用来存放代码的二进制指令与一些常量和常量字符串, 进程启动以后划分出来，把代码指令加载到代码段,一直占用内存，并且只读不可修改。

3D物体的渲染顺序是引擎自动计算出来的，尽可能的在3D场景里面让物体使用同一个材质,尽可能的在同一个渲染队列里面使用同一个材质,尽可能的在3D场景里面使用同一个种shader,不要根据物体渲染的需顺序来回切换shader(Set Pass Call开销很大)。2D UI物体尽可能的安排同一个图集的物体在一起，如任务系统UI，尽量的让任务系统这些UI物体在一个图集里,这样可以合批渲染;将多个物体的纹理合并到一起,如游戏地图上的障碍物，可以将这些障碍物与地图的纹理合并到一起，这样地图和障碍物可以由合批的可能。

比如一个算法是用递归写的，由于递归的层次比较深，导致栈溢出，这时候我们可以减少栈的内存使用或调整编译器来配置更大的栈。答案是不会,因为进程A内存泄漏，进程A中泄漏的内存不能用了，一段时间后，OS会判定 进程A泄漏的内存块对应的物理内存页长时间没有用，当物理内存吃紧的时候，会把这个物理内存页判断为”长时间不用”的物理内存页，就把泄漏对应的物理内存页的数据交换到磁盘，然后释放物理页给其它的进程B使用，所以进程A的内存泄漏，不会从根本上影响其它进程的内存使用(OS做内存页交换的开销肯定会有)。

渲染优化: 看下pass的次数与set pass 次数, pass 次数，比如阴影这些都会导致多次pass,多光源这些会导致多次pass, 我们可以通过定制渲染管线,优化shader代码, 优化光照计算等，从Shader+渲染管线级别来做好渲染优化，现在比较火的UPR渲染，也可以参考我写的《URP 实战系列》的教程。物理引擎优化: 这块化没有太多的空间了，用其它的技术去替代不用物理引擎，减少物理引擎的迭代参数,减少计算量，减少物理刚体的数目。其它的一些具体的优化手段，针对不同的问题来做一一的处理就可以了。

Base 摄像机是最先被绘制的,场景中只有一个Base摄像机有效,如果要做多个摄像机共存，我们需要把创建一个Overlay模式摄像机(可以添加组件或复制其它摄像机)，并在Base摄像机的Stack List上添加这个Overlay模式摄像机。相比于内置的向前渲染管线，UPR渲染管线首先重新定义了摄像机的策略。上一节从项目的目录结构与示例场景的内容分析了UPR渲染管线项目的基本组成，接下来分析URP的主要机制，并通过与内置的向前渲染管线做对比，来比较它们的与不同。最后多个摄像机的绘制画面就能出现在屏幕上。..

创建完成以后，我们就能看到一个标准的基于URP渲染的项目与开发环境(Packages下都有URP的渲染管线代码与Shader，项目目录下有一些URP相关的一些设置等。接下来看下URP项目文件夹,URP项目组织其实和普通的差不多，Packages下安装好了URP相关的依赖,在Assets下和普通的稍有不同，主要在于URP的配置文件，一起来看下。现在越来越多的手游开发都采用URP渲染管线，来代替之前Unity引擎默认的向前渲染管线，本节通过以下几个方面来阐述URP渲染管线,对URP渲染管线有个全面认识。...

排序在游戏开发中是一种十分重要的算法，特别是对于海量的数据，高效的排序算法,是核心与关键，排行榜也是一样的,我们要对全服所有的排行榜的玩家做排序，每次玩家的数据有变化，就会引发排序,最终让我们把排行榜的排名拉取下来。排序算法的性能非常关键点,主流的排序算法都是非常成熟的，对于海量的服务器数据而言，排序算法也有核心的实现模块，这里我们是基于redis来做排序，redis提供了一个有序列表的功能，内部实现了海量数据的排序,我们只要把数据提交给redis的。a减少显示的UI节点的数目，提升渲染性能。...

这局又是HybridCLR(wolong)huatuo完胜,使用HybridCLR(wolong)huatuo热更方案的时候，你不用管哪些要热更，哪些不用热更新,只要按照模块利用Unity的ADF机制来生成不同的项目,并生成对应的.dll,底层打包的时候，都统一用il2cpp转成nativecode,如果新版本哪个.dll要更新了，只要把生成的新版本的.dll放服务器上，那么就从服务器装载进来到il2cppvm中，这样就可以解释执行。(2)发布新版本的时，新版本的性能与老版本热更;...

上一节我们安装huatuo的开发环境，然后运行示例项目，体验了huatuo做热更新,这节课我们来分析示例项目的源码，掌握huatuo做热更新的主要的步骤，让你自己的项目很好的基于huatuo来组织热更新。你也可以按照这个标准来划分,也可以继续分更小的颗粒度，比如游戏逻辑，可以拆分为战斗,任务等。所以我们在使用huatuo做热更新的时候它首先做的是项目拆分,示例代码中利用Unity的ADF机制，将项目分成了几个工程如下默认的代码工程，新建代码默认会被拉入到这个工程编译;...

接下来我们来试试热更新,示例项目扩展了一个菜单，可以打包出所有项目的IL指令代码的.dll,这个菜单扩展为”Huatuo”--->“CompileDall”,这样就可以把当前的所有项目的.dll全部打出来，不管你是否热更新。我们正式项目的时候，可以把这些.dll利用AOT一起编译，如果要热更某个库，先判断一下是否服务器上有最新的.dll，如果有就可以在运行的时候加载这个，否则就跑默认的AOT后的代码就可以了(获得更好的AOT级别的性能,毕竟解释执行IL指令,性能也有开销)。......

我们来拿xLua或ILRuntime热更方案来举例，这些方案都有一条原则，尽量减少与UnityC#层的交互，但是这种交互又避免不了而且量大，比如我们要在逻辑热更代码里面访问UnityC#的GameObject对象数据，最终在运行的时候，GameObject会在AOT模式下的原生内存数据结构对象。huatuo第2个优势是我们的逻辑代码更新后(1.0版本到2.0版本)，如果你发布新版本2.0(重新安装新版本的app)，可以直接把更新的逻辑,直接使用AOT编译出来，不用解释执行,从而获得AOT的性能。...

今天给大家分享一下腾讯游戏《轩辕传奇》的服务器架构，讲服务器架构如果只是得一个结果，把架构示意图展示一下，这种没有什么意义，今天我想从一个每个人都会写的最简单的架构模型，如何一步一步的演变成《轩辕传奇》分区分世界的架构。功能扩展性切分与运维扩展性切分最简单的游戏服务器，一个进程搞定所有的功能，比如支持500人同时在线，开一个服A对应的玩家称ClientA, Server一个进程,架构如下: ClientA------>Server。如果再开第二个服B，如何处理？方案1: Server 一个进程同