开发概览：非托管插件开发（Native/Unmanaged Plugin）

时间：2022-04-28 21:03:01 | 来源：行业动态

时间：2022-04-28 21:03:01 来源：行业动态

Unity是基于Microsoft .Net Framework开发的游戏引擎2，它采用了开源的.NET Platform，并依赖此框架来实现跨硬件设备和运行时（操作系统）的目标，也是所谓的Write once, run anywhere。在语言方面，Unity选择C#作为主要的脚本编程语言，虽然.NET平台本身支持的语言有很多种。

进一步，Unity支持Mono和ILC2PP两种脚本框架（Scripting Backends）。特别的，Unity Editor采用的是Mono脚本框架。

一般的，游戏类库开发者可以选择直接用C#语言开发，目标类库可以实现基于.NET Framework基础功能之上的高级功能，这类插件称之为Managed Plugin（托管插件）。由于环信IM核心SDK已经基于C 开发，因此我们选择另一种Native Plugin（本地插件）的方式，正是它把我们引向了迷宫之旅。两种类型的Plugin介绍，参见3。

不幸的是，Unity网站上关于Native Plugin的相关介绍少只又少，想要了解它的具体细节还要去参考Microsoft MSDN文档。作为中规中矩的文档介绍，微软的文档是合格的，但是，当你真正上手编程时就会发现，这些远远不够：下面记录的一些坑点就很难在相应的文档中得到直接的提示；而要通过Google大法，结合其他程序员留下的蛛丝马迹，再加上自己不断的调试来最终确认。

在微软文档上下文中，Unity Native Plugin有个另外的名字：Unmanaged Plugin，即非托管插件。简单来讲，Managed Plugin生存在.NET Framework的运行时环境（类似于Java的JVM），而Unmanaged Plugin则生存在这个运行时环境之外，也即和运行时环境是兄弟的关系。如果你原本的类库实现满足微软的COM（Component Object Model）规范，那自然最好是使用COM Interop4的互操作方式；而环信IM SDK本身是纯C 实现，因此采用了Platform Invoke5（简称P/Invoke）方式，本文剩下的内容均是基于P/Invoke。

下图则概要描述了Managed和Unmanaged区域代码之间互相操作的方式：

更具体的，为了实现对于Unmanaged DLL function的调用，只需要简单的4步6：

　　1、确认DLL类库中需要被操作的函数;

　　2、创建一个C#类来关联被操作的这些函数(给函数穿上一个马甲，以便集中管理和反复调用);

　　3、使用DllImport标志在受管侧(C#)定义函数原型;

　　4、在受管侧随意调用相关非托管区域函数。

上图中，Standard marshalling service即负责将数据在两个区域进行封装/解封装传送（marshall/unmarshall)，它主要定义了数据在两个不同内存区域进行拷贝（Copy）和引用（Reference）的规则7，而迷宫中的坑主要是和这些具体规则有关。