环信IM Unity SDK 2.0正式发布 大大提升开发效率 (5)

有两个基本的方法来解决Double Free的问题：

1、按照官方文档建议，在Unmanaged侧通过使用CoTaskMemAlloc来分配内存，通过此种方法分配的内存，除非显式调用了CoTaskMemFree方法（在Unmanaged侧或者Managed侧均可以调用），InteropMarshaller会严格保证不去释放该内存。使用这种方法可以灵活的在任意一侧分配内存，并在合适的时候在另一侧释放内存。

2、但上面这种方法貌似仅适用于Windows平台，在macOS下没有办法使用（需要引用win32base.dll相关实现）。在macOS下仅能通过在Mananged侧调用Marshal.AllocCoTaskMem()方法分配内存，并通过Marshal.FreeCoTaskMem()来在同一侧进行释放（按照此方法分配的内存指针传入Unmanaged侧后，不要进行任何释放即可）。另外有一个不太可靠的workaround是：在Unmanaged一侧创建的内存指针尽量通过IntPtr传递，并在可能的时候将对象中一些指针类型的属性值置空，以避免DoubleFree的发生。

坑四：virtual函数带来的内存布局变化

vptr和vtable是C++的一个概念：当你定义的类型中有虚函数存在时，内存对象的第一个位置会存放一个vptr指针，该指针指向vtable（虚函数表）。因此当你开始创建的自定义类型一开始没有虚函数时（包括虚析构函数virtual~MyClass()），一切运行正常。有一天你重构此类型，增加了一些虚函数：DUANG，一切都崩塌了！原因就在于Unmanaged侧内存对象的排列规则变了，原有的对象字段都被新加入的vptr往后面移位了。此时可能你唯一能做的就是通过Layout.Explicit来手工对齐每一个字段新的位置。

其它坑

坑一：针对M1芯片编译

对于M1芯片的macOS系统，编译环信IM Unity SDK时候需要注意几个问题：

1、XCode编译时需要Excluded Architecture中排除arm64架构（很奇葩的设置，不是应该排除x86吗？）

相关报道: