最近为了提高版本更新的效率，搭建了jenkins环境，因为我们现在比较多的海外版本，更新频率越来越高。

导致我们前端花费了大量的时间在导UI和版本更新上，而且这些基本上都是一些重复性的工作。由于一些历史原因，每次策划的一些UI修改和调整都需要前端去导UI，然后提交SVN，测试和策划更新下来才能看到效果，非常麻烦。

所以特地花了2天的时间去做这件事，其实本身我们的框架导UI和打包都挺方便的，但是现在海外版本多，还是会比较复杂，而且人工操作容易出错。

jenkins相信做游戏的都不陌生，搭建起来其实也比较简单，去官网下载一个安装包即可，但是要适配自己的项目情况，配置一下参数是比较麻烦的，特别是要做一些自动化的操作，比如复制文件自动提交SVN等。

最麻烦的是在写批处理脚本的时候遇到的一些在jenkins上比较蛋疼的问题：

一、调用unity函数打AssetBundle的过程中发现老是会出现AB还没打完jenkins任务就执行完成了，也不是执行失败，就是提前结束了，这样导致C#里面一些自动拷贝文件的函数都没法执行下去，因为UI都没有完全导完。这个问题也是困扰了我很久，因为我特地试过脚本在BAT文件上执行是没问题的，但是就是在jenkins执行的时候出问题，后面实在是没办法就，写了一个循环每隔5秒钟去检测一次导出的LOG判断UI有没有导完，在C#导出完成的时候输入一段完成的LOG信息。

批处理调用U3D导AB的命令如下：start %UNITY_PATH% -projectPath %PROJ_PATH% -quit -batchmode -logFile %LOG_PATH% -executeMethod JenkinsExportManager.ExportHotFixOnlyJenkins

其中%LOG_PATH%即是导UI过程中unity输出的LOG路径（自己定义），在这个命令后执行循环检测：

:begin
@echo off
ping /n 5 127.0.0.1>nul
echo on
echo 正在导出，请稍后！
findstr /i /c:”export end” “%LOG_PATH%” >nul 2>nul && goto end || goto begin
:end

循环查找LOG中的“export end”字符串，如果有则UI导出完成了，可以继续往下执行，不然jenkins是无法判断导出进度的。

二、第2个坑点是我们想Jenkins上导出的UI复制到FTP共享盘上，这样策划和测试都可以用，因为Jenkins是运行在打包机上的，这台机器的配置也比较高，打包和导UI的效率比较高，他们可以使用Jenkins导出UI到FTP上，然后再从FTP复制到本地，查看UI的效果，确定没有问题了再提交SVN，这样既实现了人人可以用，又保证了安全性。

但是就在这个地方又卡了我好久，因为在Jenkins上死活识别不了共享盘的路径，明明已经做了共享盘的映射，但就是识别不了，我直接在CMD上执行是可以识别的，但是一放到Jenkins上就不行了，最后在Jenkins上执行了一次享盘映射的命令：net use X: \172.16.20.35\ftp /y 才识别上，真是奇葩。

三、第3个坑点是在Jenkins上是可以设置参数然后在命令中获取的，但是如果在设置的参数判断里面定义set命令然后给变量赋值是不起作用的，这就很奇怪了。本来是想利用不同的参数值设置不同的路径实现一些自动化操作，结果导致我只能把绝对路径全部写上。

比如在Jenkins上设置了一个region参数用来选择地区，然后在命令上做如下判断：

if "%region%"=="国内" (
   set NEWPATH=C:\ui
)

结果发现变量%NEWPATH%是空的，根本赋值不了，在if外面试可以赋值的。

对于这个问题，暂时还没有找到别的方法，只能是写死绝对路径不在Jenkins参数的判断里面去赋值。

四、第4个坑点和第一个类似，也是命令还没执行完成Jenkins就结束任务了，本来是想在导出UI完成的时候，复制一些文件到某个地方的，但是经常发现文件还没复制完成只复制了部分文件Jenkins就结束任务了。对于这个问题我也只能使用命令：

@echo off
ping /n 10 127.0.0.1>nul
echo on

来达到延迟的效果了，10代表延迟10秒才往后执行。

最终配置效果如下：

从此再也不用我们前端导UI啦！前端是万能的。

在UGUI的Text组件中，文字超出宽度会自动换行，如果有空格则会从空格处自动换行，在英文中这种方式是完全没有问题，但是某些语言比如泰文，是不需要在空格处换行的，那就需要特殊处理了，可以通过使用富文本的方式把空格替换掉，比如使用Replace(” “,”<color=#00000000>.</color>”)的方式把空格替换为一个透明的点。

如果不想使用富文本也可以使用unicode字符“\u00A0”，比如Replace(” “,”\u00A0”)替换我们常用的空格，或者使用全角空格替换半角空格。因为我们常用的空格是半角空格，这三种方式都可以实现替换空格后保留空格的效果并且不在空格处自动换行。

我们项目的发行商最近反馈泰文的换行问题，我暂时是使用的“\u00A0”替换字符的，感觉还不错，没出现其他问题。

最近在搞海外相关需求，借此机会记录一下谷歌出包和上架过程。

谷歌宣布从 2019 年 8 月 1 日 开始，在 Google Play 上发布的应用必现支持 64 位架构，这个意味着如果你要上谷歌平台就不能使用Mono的方式打包，只能选择IL2CPP，因为Mono是不支持64位的。

另外上架的应用要包含多份架构的 SO 包，导致应用大小增加，以前只有 armeabi-v7a 一种 CPU 架构，但是为支持 64 位，需要增加 arm64-v8a 架构的库。

所以谷歌宣布从2021年8月份开始，所有提交到Google Play商店的新应用必须采用AAB格式，因为AppBundle（AAB）是Google在2018年推出的动态打包方式，这种包格式以.aab为文件扩展名。

通过aab包发布到 Google Play 的应用，Google Play 能自动将 aab 根据不同维度分解为一个基础包和一系列的“拆分包”，这些拆分包其实就是一个个apk，其中有分为配置拆分包、PFD拆分包和PAD拆分包。

当用户下载应用时，Google Play 会根据用户设备的特性只下发基础包和对应的拆分包，从而减小用户下载应用的大小。

同时谷歌还要求AAB包下的Base目录大小不能超过150M不然上传不了谷歌商店，不过谷歌提供了其他目录用于存放资源和代码。

这些目录分别如下：

install-time：安装时分发

fast-follow：快速跟进式分发模式，在安装游戏完成后，自动下载。

on-demand：按需分发模式，通过google API下载

现在大部分游戏资源其实都是放在Base目录下的，也就是安卓工程的src/main/assets目录， 而且基本上是超过150M的，也就是说我们开发者需要更改自己原有的资源加载方式，把大部分资源移动到install-time，fast-follow，on-demand这3个目录中，谷歌有提供相关的API去这些目录中获取资源。

其中有专门针对Unity的API和工具：

文档地址：https://developer.android.google.cn/guide/app-bundle/asset-delivery/build-unity

如果你不想更改原来的加载方式，可以把资源全部放在install-time目录下，在这个目录下的资源不需要使用谷歌的API进行加载，而是在安装的时候会自动帮你安装到手机上。

如下，把Unity导出的工程划分为以下几个目录：

然后把src/main/assets下的资源分配到install-time，fast-follow，on-demand目录，但是要注意在这3个目录下的目录结构需要和src下的目录结构一样。

比如原来的资源存放在src\main\assets\res目录，现在你要把res下的部分资源移动到install-time目录下，那你需要在install-time目录下新建一个src\main\assets\res的目录结构，然后把src\main\assets\res的资源移动到install-time\src\main\assets\res目录下，这样就大功告成了。

只要保证原来src\main\assets目录的大小加上库文件的大小不超过150M那么打包出来AAB的base目录也不会超过150M。

AAB包的结构如下：

观察发现，base目录的大小主要是assets+lib的大小，而lib下是我们的库文件，这些是无法缩减和移动的。

其实从测试的角度上来说光打出AAB包还不算真正的结束，这个时候如果你想测试AAB包是不行的，因为AAB无法直接安装在你的手机上。

所以发行那边或者测试通常会向你要一个AAB包对应的APK包，幸好谷歌有提供相关的工具把AAB包反编译为APK。

首先要去Github下载这个工具：https://github.com/google/bundletool/releases

然后使用命令：java -jar 你下载的bundletool路径.jar build-apks –bundle=你的AAB包路径.aab –output=输出apks的路径.apks –ks=安卓签名文件路径 –ks-pass=pass:ks密码 –ks-key-alias=bf_lmzh_yn –key-pass=pass::key密码

执行后等待几分钟（根据每个人的电脑性能的不同编译时间有快有慢）会在你设置的输出目录下生成一个.apks的文件，使用解压软件打开它，standalones目录下的apk文件即是你AAB对应的APK文件，把APK和AAB一起发给发行和测试，到此出包工作才全部结束。

Unity生成的游戏包启动确实会比其他引擎慢些，即使打包的时候勾选了Splash Image选项，如果包比较大的话，安卓启动还是会黑屏一段时间才能看到画面。

这种情况是没办法从U3D游戏这边去解决的了，因为这是原生安卓的问题了，需要从SDK这边去解决，网上看到有些资料是在主Activity的onCreate里创建一个view来覆盖Splash，其实完全没必要这么复杂。

只需两步就可以解决：
1.在AndroidManifest文件中设置：

<activity
    android:name=".ui.SplashActivity"
    android:theme="@style/Theme.Splash"
    android:screenOrientation="portrait">
    <intent-filter>
          <action android:name="android.intent.action.MAIN" />
          <category android:name="android.intent.category.LAUNCHER" />
     </intent-filter>
</activity>

2.在style文件中定义：

<style name="Theme.Splash" parent="android:Theme.Holo.Light.NoActionBar.Fullscreen">
    <item name="windowNoTitle">true</item>
    <item name="android:windowContentOverlay">@null</item>
    <item name="android:windowBackground">@drawable/splash</item>
    <item name="android:windowFullscreen">true</item>
</style>

然后在src/main/res/drawable下放一张名为splash.png的启动图即可。这张启动图会在你启动APP之后立马显示出来，然后再显示Unity设置的Splash图。

不过这么做的话这张图会有一个问题，那就是和手机的屏幕分辨率不匹配的问题，有可能会拉伸和挤压的情况出现，其实只要这张图中间放一张LOGO其他地方是纯黑色或者白色是看不出来的，也可以使用.9的方式设置图片拉伸区域。

大大缩短了安卓APP的启动时间，据发行反馈这样体验更好。

今天发行那边反馈过来一个问题，是之前我们都没发现过的，当在安卓SDK登录界面的时候切换到后台或者切换其他到其他应用，再次返回游戏的时候，发现SDK登录界面后面的游戏界面黑屏了。

我的初步判断是，游戏的View应该是从后台返回到前台的时候还没被激活，因为只要点击一下SDK的登录，游戏界面就显示出来了。

查询资料发现确实是这个原因。

一、当Unity所在的Activity之上没有其他Activity时候，生命周期的变化如下：

启动App
D/MainActivity: onCreate
D/MainActivity: onStart
D/MainActivity: onResume
D/MainActivity: onWindowFocusChanged true

点Home进入后台
D/MainActivity: onPause
D/MainActivity: onWindowFocusChanged false
D/MainActivity: onStop

从后台回来
D/MainActivity: onRestart
D/MainActivity: onStart
D/MainActivity: onResume
D/MainActivity: onWindowFocusChanged true

退出应用
D/MainActivity: onWindowFocusChanged false
D/MainActivity: onPause
D/MainActivity: onStop
D/MainActivity: onDestroy

二、当Unity所在的Activity之上有其他Activity时候，生命周期的变化如下：

弹窗显示另外一个Activity
D/MainActivity: onPause
D/MainActivity: onWindowFocusChanged false

点Home进入后台
D/MainActivity: onStop

从后台回来
D/MainActivity: onRestart
D/MainActivity: onStart

关闭 弹窗Activity
D/MainActivity: onResume
D/MainActivity: onWindowFocusChanged true

三、对比两次的日志打印，我们可以发现：第二次从后台返回少了两个生命周期的调用

D/MainActivity: onResume
D/MainActivity: onWindowFocusChanged true

综上分析所得，要想做到从后台返回不黑屏，只需要在SDK的主Activity的 onStart里面调用onResume和onWindowFocusChanged方法即可。

public void onStart() {
    super.onStart();
    this.mUnityPlayer.resume();
    onWindowFocusChanged(true);
}

这样当Unity所在的Activity之上有其他Activity时候，即使切换到后台再返回游戏，也不会黑屏。

今天测试反馈了个刷屏的警告”Particle System is trying to spawn on a mesh with zero surface area“根据翻译判断是使用了体积为0的mesh,但是当我在网上查找资料的时候,网上说的是因为 ParticleSystem 中 ShapeModule 要求引用的 Mesh 必须开启 Read/Write 选项.

经过我的实验和调试发现并不是这么回事,简单的就是因为某个特效的shape类型选择了mesh然而没有指定一个mesh给他,而且选择的Mode为Edge,如下:

满足以上几个箭头所指的条件后就会不断刷如下警告:

要想去掉这些警告,可以改变shape的类型或者指定一个mesh给它,也可以改变Mode的类型为Vertex都可以去掉这些烦人的警告,具体方法需要根据自己的特效情况设置.

如果需要查找项目中有问题的特效可以使用以下编辑器脚本:

using UnityEditor;
using UnityEditor.SceneManagement;
using UnityEngine;

public static class MeshToolForParticle
{
    [MenuItem("Tools/ParticleSystem/FindScenes", false, 20)]
    public static void FindScenes()
    {
        var guids = AssetDatabase.FindAssets("t:Scene");

        foreach (var guid in guids)
        {
            string path = AssetDatabase.GUIDToAssetPath(guid);
            var scene = EditorSceneManager.OpenScene(path, OpenSceneMode.Single);
            var roots = scene.GetRootGameObjects();
            bool found = false;
            foreach (var go in roots)
            {
                found |= Find(go);
            }

            if (found)
            {
                Debug.Log(path);
            }
        }
    }

    [MenuItem("Tools/ParticleSystem/FindPrefabs", false, 20)]
    public static void FindPrefabs()
    {
        var guids = AssetDatabase.FindAssets("t:Prefab");

        foreach (var guid in guids)
        {
            string path = AssetDatabase.GUIDToAssetPath(guid);
            var prefab = AssetDatabase.LoadAssetAtPath<GameObject>(path);
            Find(prefab);
        }
    }

    private static bool Find(GameObject go)
    {
        bool found = false;
        var particles = go.GetComponentsInChildren<ParticleSystem>(true);
        foreach (var particle in particles)
        {
            if (particle.shape.enabled && particle.shape.shapeType == ParticleSystemShapeType.Mesh &&
                particle.shape.mesh == null)
            {
                string prefabPath = PrefabUtility.GetPrefabAssetPathOfNearestInstanceRoot(particle);
                Debug.LogWarning(string.Format("Path: {0}\nPrefab: {1}", particle.gameObject.GetGameObjectPath(), prefabPath));
                found = true;
            }
        }

        return found;
    }
}

把上面的脚本放到项目的Editor目录下然后点击菜单Tools/ParticleSystem/FindPrefabs,即可打印出有问题的特效名称.

使用shader置灰一张图或者一个文字的代码很简单，但是之前一直不知道它的原理是啥。

今天通过查找资料发现，其实很简单，置灰的核心代码如下：

 fixed4 frag (v2f i) : SV_Target
            ｛
                // sample the texture
                fixed4 col = tex2D(_MainTex, i.uv);
                //-----------add-------------
                // gray
                float gray = dot(col.rgb, float3(0.299, 0.587, 0.114));
                col.rgb = float3(gray, gray, gray);
                //---------------------------
                return col;
            ｝

 float gray = dot(col.rgb, float3(0.299, 0.587, 0.114));
这一句是最主要的一句，其实就是把采样出来的颜色和一个固定的颜色值做一个点乘，但是为什么是这个颜色呢？为什么要和这个颜色值做点乘返回最终的片元着色器颜色？

原理:是因为人眼对绿色的敏感度最高，对红色的敏感度次之，对蓝色的敏感度最低，因此使用不同的权重将得到比较合理的灰度图像。实验和理论推导出来的结果是0.299、0.587、0.114。
所以为图片的RGB分别乘以权重然后加起来得到一个灰色值，并且将这个灰色值作为新的RGB值
返回给最终的颜色值。 

在U3D游戏中内存管理一直都是让人比较头疼事情，现在手机游戏是越做越大，和端游一样，每次卡顿和每次的内存增长对玩家来说都是一个比较差的体验。听到过一句话，说游戏开发做久了就会变成“GC怪”，因为在游戏开发过程中，需求变化多，功能不停的迭代，内存问题也一直存在，需要不停的去优化它。

在unity2018中集成来正版的.NET4.X和C#7.3，引入了ref return 和ref locals,让值类型的操作更加便捷，在U3D2019中更是加入来增量式GC，减少来GC带来的卡顿问题。比以前的版本灵活来许多。

讲了这么多，可能很多人还不知道什么是GC，GC的全称是Garbage Collection,也就是垃圾回收的意思，是一种自动管理堆内存的机制，管理堆内存上对象的分配和释放。

一、内存管理方式

我们常用的内存管理方式有三种：

1.手动管理，像C/C++一样使用malloc/free或者new/delete来为对象分配释放内存。这张方法的优点是速度快，没有任何额外开销，缺点是要去人工了解每个对象的使用情况，这样很容易发生各种问题，比如内存泄漏，野指针和空悬指针等。

2.使用引用计数，它的思想是对象创建出来以后，维护一个针对该对象的计数，使用该对象的地方对该计数加1，使用完后减1，当计数为0时，销魂该对象。这种方法类似半自动内存管理方式，优点是可以把分配和释放的开销分布在实际使用过程当中，速度比较快，不过会存在一个循环引用的问题。引用计数是一种比较常用的内存管理方法，比如U3D中物理引擎PhysX就是使用引用计数来管理各种对象的。

3.追踪式GC器，unity使用的GC器是一种叫标记/清除的算法，它的思路是当程序需要进行垃圾回收时，从根出发标记所有可以到达的对象，然后回收没有标记的对象，这是一种全自动的内存管理方法，程序员完全不用追踪对象的使用情况，也不存在循环引用无法回收的问题。在unity中使用的是一种叫boehm-Demers-Weiser的GC器，它的特点是：

（1）stop the world ，即当GC发生时，程序的所有线程都必须停止工作，在回收时也要停掉所有线程。

（2）不分代，.NET和java会把托管堆分成多个代，新生代的内存空间非常小，而且一般来说，GC主要集中在新生代上，让每一次GC的速度很快，但是在U3D中GC是完全不分代的，只要发生GC，就会对整个托管堆进行GC。

（3）不压缩，不会对堆内存进行碎片整理，类似我们的磁盘一样，使用久了就会有很多的碎片，造成磁盘上有很多小空隙。同样在U3D中GC会造成托管堆出现很多这样的间隙，这些间隙不会合并，当申请一个新对象时，如果没有任何一个间隙大于这个新对象的大小，堆内存就会增加。

二、影响GC性能的因素

主要因素有2个：

1、可达对象的数量

2、托管堆的大小

可达对象是不会被GC回收的对象，减少这类对象的方法是减少对象的数量，如下：

将会产生10个Actor对象。

如果使用以下方法：

只产生一个对象，方法很简单，但是却很有用，如果在需要每帧去处理的对象上去使用这类优化，会得到意想不到的效果。

而优化托管堆的大小主要通过以下几个方面：

1、减少临时内存分配，因为临时内存会使内存短暂的增长，而且会产生碎片

2、防止内存泄漏，也就是存在互相引用无法回收对象的情况，或者没用到的对象，但是对它还有引用，导致释放不掉。