菠菜的blog

Addressable的Lua加载优化

  • Conerlius
  • Feb 09, 2022
  • 0 views

现象

在开始排查当前情况的时候,项目工程中使用的lua代码已经达到了6M

在本地电脑中加载的时候需要5s以上的时长！据项目的反馈，手机上的加载时间有些机器需要十几秒！

png

排查过程

  • 第一步是先统计一下加载的耗时

在 AddressResource 中，在创建和加载完成的两个方法中添加计时，完成的时候打印耗时；

png

  • 确定ab的加载时间

png

ab加载耗时极少！

-定位加载过长的原因

通过断点，看到因为label需要把所有的同样label的资源都进行provider加载，使得lua的每一个文件都会进行BundledLuaProvider加载！而且还是异步的！

m_RequestOperation = bundle.LoadAssetAsync(assetPath, m_ProvideHandle.Type);
m_RequestOperation.completed += ActionComplete;

方案：

方案一：

直接将BundledLuaProvider中从ab回去资源的异步方式改为同步！

png

方案二：

lua的加载不使用addressable记载，类似于

string path = m_ProvideHandle.ResourceManager.TransformInternalId(m_ProvideHandle.Location);
if (File.Exists(path))
{
    m_RequestOperation = AssetBundle.LoadFromFileAsync(path, m_Options == null ? 0 : m_Options.Crc);
    m_RequestOperation.completed += LocalRequestOperationCompleted;
}

直接加载assetbundle，然后对ab进行操作，这样就可以自己处理了！

方案三：

使用工具，在打包lua之前，将所有的lua文件合并成为一个文件，这样的话一个lua ab就只有一个asset了（即lua之类的label加载的时候就只有一个provider需要处理！），好处在于目前的addressable不需要修改，只需要写个工具，还有在lua资源加载完后解释就可以了

方案四：

修改addressable的加载，但是里面牵连了AsyncOperationBase、AsyncOperationHandle、ProviderOperation等一系列的操作，改动过大！

方案五：

在addressable生成的catelog进行删除修改，使得一个label下只有一个asset name,这样在调用BundledLuaProvider的时候直接使用loadall就可以了！

其他：

还有不少是基于addressable的修改，但是改动都不少

结果

目前看来方案一、方案二、方案三的可行性较高！

Search