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

谷歌宣布从 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、防止内存泄漏，也就是存在互相引用无法回收对象的情况，或者没用到的对象，但是对它还有引用，导致释放不掉。