Timeline中粒子系统受FixedTime影响问题

1）Timeline中粒子系统受FixedTime影响问题
2）函数体内局部变量在GC的时候无法释放
3）Mac版本升级至10.15后，Unity导入新的MP3文件卡住或者闪退
4）升级到MacOS Catalina后Unity出现空白错误
5）如何获取已打包好的APP的Unity开发版本号

---

Timeline

Q：新建工程后，新创建一个Timeline和ParticleSystem，将ParticleSystem放入Timeline中，调大系统的FixedTime，在Editor运行状态下会明显发现粒子系统播放时出现卡顿（如果只是在Timeline预览是正常的）。看API和相关接口均未发现有相关的说明。请问这个是正常状态吗？如果希望粒子系统不受物理时间影响应该如何操作呢？Unity版本2018.4.0与2019.2.9均发现该问题。

A： 解决方案：
1、不勾选Control Particle Systems选项，这样Timeline只负责粒子系统的生命周期管理，不会驱动粒子系统播放，相应的坏处就是在不运行游戏时不能预览粒子的效果了。

2、修改官方代码，重写一个播放粒子的轨道。

原因查找：
使用dnSpy打开UnityEngine.Timeline.dll，查看ControlPlayableAsset的代码。可以看到当updateParticels为true时，会把ParticleSystem收集起来，传入SearchHiearchyAndConnectParticleSystem方法中。

然后在上述方法中，会为每个粒子系统创建一个ParticleControlPlayable，在之后的逻辑会把这些Playable连接到这个Timeline系统的output上。

在ParticleControlPlayable类中，可以看到在PrepareFrame方法中，会调用粒子系统的Simulate方法。

Timeline就是在这里驱动粒子系统播放的。

这里调用的ParticleSystem.Simulate方法的原型如下图：

发现最后一个fixedTimeStep参数默认为true。

所以在这里更新粒子系统默认就使用了FixedTimestep。把反编译的代码拷贝出来，修改一下类名，自己重写一个播放粒子的轨道和片断，测试即可。

感谢张首峰@UWA问答社区提供了回答

---

GC

Q：当前我们有一个模块使用协程调用，UnityWebRequest以及FileStream来实现安卓上从StreamingAsset 拷贝文件到 PersistentDataPath中，代码如下：

 public static IEnumerator CopyStreamingToPersistentPathByUnityWebRequestItor(string str)
    {
        string des = Application.persistentDataPath + "/data.cache";

        using (UnityWebRequest www = UnityWebRequest.Get(str))
        {
            yield return www.SendWebRequest();

            if (!string.IsNullOrEmpty(www.error))
            {
                Debug.LogError("WWW Error : " + str);
            }
            else
            {
                Debug.Log("WWW Successful");
                byte[] bytes = www.downloadHandler.data;
                FileStream fileStream = new FileStream(des, FileMode.Create);
                if (fileStream != null && fileStream.CanWrite)
                {
                    fileStream.Write(bytes, 0, bytes.Length);
                    fileStream.Flush();
                    fileStream.Close();
                    fileStream.Dispose();
                    Debug.Log("Copy to " + des);
                }
                else
                {
                    fileStream.Close();
                    fileStream.Dispose();
                    Debug.LogError("Copy Faild");
                }
            }
        }
    }

然后使用UWA GOT检测发现这块byte[]始终驻留在内存中，即使在执行完协程后调用GC.Collect也无法回收该byte数组，不知道有没有相关的解决方案？

A1：重写DownloadHandlerScript，使用流的方式直接写入目标地址就可以了。对于UnityWebRequest的DownloadHandler，小文件没问题，大文件就要出事。如果加载一个20MB的文件，那么不仅Mono堆分配20MB，Native Heap也分配同样大小的byte数组，而且Native 中会不断刷新数组大小直到满足。采用Stream方式缓存，Mono堆大小就只取决于缓存池的大小，Native heap也不会撑大，可以大幅度降低PSS。
感谢题主Wangtao@UWA问答社区提供了回答

---

Crash

Q：Mac版本：10.15 ；Unity版本：2018.2.11f1
详细描述：未升级Mac版本前，新MP3文件正常导入，可以正常识别文件。升级后，如果在Unity开着的情况下拖入文件，Unity会直接闪退（如图1），重新打开显示资源未识别（如图2）。如果Unity在关着的状态下，放入MP3文件，打开项目一直显示正在导入且不会完成，删除MP3文件后才能正常打开项目。怀疑升级Mac后Unity还是使用了Mac旧的API，但是项目又暂时不能升级Unity版本，问下这种情况有什么好的解决方案吗？大家有碰过这种情况吗？

图1

图2

A：这个官方论坛上有相关的问题：
https://forum.unity.com/threads/installing-unity-on-macos-catalina.689089/
升级Unity版本即可。
感谢阎杨将@UWA问答社区提供了回答

---

Editor

Q：我们最近升级了Mac系统到最新的Catalina，然后打开自己的工程以后一直有一个空白的错误，清不掉也点不开，Unity的版本是2017.4.10，跟Unity论坛上这个人的错误是一样的。
https://forum.unity.com/threads/macos-catalina-blank-error-appears-with-no-info.761903/

我看ISSUE TRACKER上有这样一个问题：
https://issuetracker.unity3d.com/issues/macos-empty-error-appears-in-the-console-window-when-certain-files-are-present-in-the-project-with-macos-catalina?_ga=2.1691889.1595892744.1571291033-1700034320.1508724105

是说2017不会修复吗？求助有人遇到相同的问题吗？

（PS：.net版本从3.5调到4.6就没了，不过感觉不是解决办法。）

A：发现T4M里面有个js脚本，工程里面不能有js脚本，删除了就好了。
感谢题主关@UWA问答社区提供了回答

---

Unity版本号获取

Q：有什么办法可以获取已打包好的APP的Unity开发版本号吗？比如通过Assembly-CSharp.dll可否读出Unity版本号？

A：如果AssetBundle没加密混淆，可以用AssetStudio打开AssetBundle、AssetStudio的标题栏，会显示该AssetBundle的版本号。换言之，AssetBundle里应该存有相应的Unity版本号。
感谢noah@UWA问答社区提供了回答

---

今天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题也许都只是冰山一角，我们早已在UWA问答网站上准备了更多的技术话题等你一起来探索和分享。欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。

官网：www.uwa4d.com
官方技术博客：blog.uwa4d.com
官方问答社区：answer.uwa4d.com
UWA学堂：edu.uwa4d.com
官方技术QQ群：793972859（原群已满员）