背景

Unity WebGL生成的wasm过程是从C#代码经过IL2CPP转换成为C++代码，再由Emscripten编译成为wasm代码包。对于微信小游戏这种对包体大小敏感的平台，wasm代码包往往占据了大量的体积，而其中有不少并不合理的代码占用。

本文介绍如何获取wasm代码包，使用twiggy分析每个函数的内存大小，以及如何利用符号表将混淆后的函数名还原为C#方法名，从而精确定位每个C#代码的wasm占用情况。

unity使用Addressables进行资源管理很方便但是有一个很值得诟病的问题, 那就是catalog文件过大, 对于一个持续运营的项目来说catalog文件可能超过10M, 导致初始化Addressables时间较长, 峰值内存上涨明显.

本文通过分析catalog文件中主要的内容占用和内存开销, 提出一些可行的(已实践)方案.

一. catalog相关的开销分析

catalog 开销主要来自两个部分:

1. 初始化Addressables 的时间开销, 使用Addressables需要确保catalog 加载完成, 对于部分网络情况不佳的用户造成卡顿较长的体验;
2. 加载catalog文件的内存开销, 使用json格式的Addressables加载时会产生两倍于自身大小的内存开销.

加载catalog的时间开销和网络情况密切相关, 实际测试下来一个1M的catalog文件经过传输和加载到内存, 整体时间超过1s. 主要的开销来源是文件的大小.

内存上的开销主要是加载文本本身和反序列化数据之后的结果上的内存开销.

// TODO

项目背景

项目使用unity做游戏，并使用addressables方案管理资源，基于spine作为很多unity的骨骼动画实现方案，在我们的项目中有一些不合理的地方：

1. 使用ScriptableObject作为桥接SkeletonData和Unity的方案，导致skel文件在加载完成之后不会卸载,这导致Spine动画很多的情况下会导致很多的Native资源占用;
2. Spine动画使用的地方很多，但是大部分时候只会播放一个动画;

为此我们实现了两个Spine方案上的改动：

1. SkeletonData加载完成之后手动卸载skel.bytes文件;
2. 按照动画名字拆分Spine文件中的动画，按需加载Spine动画文件;

kafka 学习

windows 上的 kafka 学习和安装相关的问题

go strings.Builder 使用

从三色旗到快排

仿写 vue - 实现数据拦截和简单的依赖收集

简单仿写 vue

vue proxy实现

之前尝试实现vue数据劫持，里面有一些方法实现不是很好，经过查阅lua.org，实现了基本操作的劫持；