先简单说下shader的热更新

我们在项目中使用shader，常见的，两种方式：

第一种是，给render附上一个材质，材质用某一个shader，这种情况，使用assetbundle热更新即可。

第二种是，runtime需要动态设置的shader，常使用Shader.Find()的方法来获取。这种方式，只有将shader放到Resources下，才能读取。但是Resources下的资源，是无法热更新的。

为了shader的热更，我们就不能用Shader.Find，而是要自己去实现一个类似的调用方式。如下：

我们可以这样使用

Shader targetShader = ShaderBinder.me.getShader(targetShaderName);

在使用之前，我们把需要get的shader，拖到对应的脚本上。让后将对应的prefab打包成assetbundle，在游戏开始前load出来。

shaderlab的内存优化

shaderlab的内存问题，第一个就是standard shader。有几种可能会引入standard shader：

1，import 模型的时候，自动创建的材质。

即使我们去掉import materials的勾选，还是会引入这个材质。想要彻底地去掉，需要将默认render的材质清空，或者设置一个自己定义的材质：

设置为自定义的一个材质

2，美术或者程序，在制作场景，制作资源的时候，错误地使用了默认的材质。例如，在场景中创建了一个默认的cube，这个cube，就会使用默认的材质，默认材质用的就是standard shader。

对于游戏场景，我们可以在保存场景的时候，自动替换所有场景中默认的材质。

替换掉默认材质，替换掉standard shader

通过游戏场景的保存，能大部分解决问题了。

但是，程序可能用到的材质，可能散落在各处。每个项目理论上都能找出所有真正打包需要的所有prefab，然后用上面的方法统一替换包含standard的材质即可。

通过上面的方法，我们项目，已经排除了standard shader，在真机测试中，shaderlab的内存，降到了20多M。

通过对standard的剔除，shaderlab降到了20M左右。我们在看profile的分析的时候，发现这样一种情况，在profile中，我们看到同一个shader，会有多个copy，例如下图的Diffuse。

在我的项目中，这种情况，是因为我们的prefab，或者粒子特效，用的都是unity内置的shader，这些shader，在打包assetbundle的时候，是不会被打包的。导致存在冗余，

但是，我认为上面assetbundle零冗余方案的解决方案不是太好，所以，在研究和测试后，我们有了自己的方法，去处理依赖unity内置资源的问题。

1， 下载unity的build in shader，导入到项目中（如果项目开始就这么做了，能省很多事），后续当我们在材质上选择shader的时候，用的就不是build in的shader，而是导入到工程的shader，就和我们其他shader一样，可以更改，可以热更，打包也不会冗余了。

2， 替换默认的材质。美术制作资源的时候，有时候会用默认的材质，除了Default-Material，还有Default-Particle（特效经常用），Sprites-Default。

我们不可能要求美术注意到不用默认材质，对他们要求太高了，也不科学。所以，我们需要用脚本做统一更改。我们就用之前的脚本，对需要打包的资源，做统一替换材质即可

第一个红框内，是替换默认材质，第二个红框内，是替换为导入的shader。

通过这个优化之后，我们在用profile看的时候，应该解决了90%的重复，还有很少数的重复，我没有仔细研究是哪里来的。我们花20%的精力，解决掉80%的问题，shaderlab已经从20多M，下降到5M，我觉得已经ok了。

这个方法带来的好处，除了shaderlab内存降低，也使我们不再依赖不可编辑的内置shader，让所有的shader都可改，可更新。

• 上面的方法，很好地运行了一段时间，但是在几个月后我再一次profile的时候发现，shaderlab，又涨到28M了，这次即没有standard，也没有内置shader冗余的问题。

在仔细地分析测试后，定位在我们使用的后处理shader上，我们使用的后处理是：Unity-Technologies/PostProcessing，根据筛选，我们只用到其中的bloom 和 Color Grading，只有这两个，不应该，额外增加了20M多的内存吧。

最后分析，是因为后处理的multi_compile，导致过多的shader变种，而很多变种，是我们不需要的

非常多的变种

解决方法是，根据需求，注释掉不需要的变种即可

注释掉以后（记得注释对应的shader内对应的#if 这类代码块），shaderlab从28M回到了6M多点，这就是一个合理的数据了。

最后，总结下shaderlab的内存优化：

清理standard的使用，不要让其进入打包内容

处理内置shader和默认材质的问题，替换为创建的材质和导入的shader，减少冗余。

清理复杂shader的multi_compile或者shader feature，删除或注释不需要的，减少shader变种

希望这篇简单的说明，能给大家带来帮助。