VST音频插件架构分析

前言

Virtual Studio Technology (VST)，可以翻译为虚拟工作室技术，是一种音频插件软件接口，由德国Steinberg公司发布，用于在Digital Audio Workstation (DAW，可以译为数字音频工作站)中集成合成器和效果器。

现在主要还在用的是VST 2和VST 3这两个版本，VST 2是对VST 1的扩充，所以一块讲；但VST 3则是相当于一个全新的架构，所以要和VST 2分开来讲。

官方提供了VST的SDK，其中VST 2的已经没有了（但是可以在其他地方找到），只有VST 3的可以在官网找到。不过本文并不分析完整的SDK，而是分析其架构，所以只会分析SDK中关于VST的API部分。

你可以在这里找到VST 3的官方英文文档，也可以在这里找到VST 3 SDK的下载链接，其API也在SDK中；或者可以去他们的GitHub仓库去Clone完整SDK代码。

如果你需要VST 2 SDK，可以去这个GitHub仓库下载，有需要的建议还是下了，万一以后真没了也不好说。不过VST 2我是真的找不到文档了。

不得不说，Steinberg为了强推VST 3而抛弃VST 2，甚至下架其SDK以及停止授权等行为，确实饱受诟病，不过这是人家公司自己的选择，而我们依然可以接着用，甚至用竞争对手的技术，随他怎么搞呢，反正哪个流行用哪个就是了。只不过唯一的问题就是如果销售的插件或者DAW带有VST 2，估计得给人家告死，所以想拿来卖只能用VST 3，当然如果开源免费的话肯定无所谓。

本文要分析的所有代码均来自pluginterfaces文件夹。

目录

VST 2

核心文件就是在pluginterfaces/vst2.x文件夹下的aeffect.h和aeffectx.h，其中第一个是VST 1的，第二个是VST 2的补充，所以其整体架构就是延续了VST 1的，因此先分析一下aeffect.h的东西。

跳过前面无聊的部分，我们直奔主题——几个重要回调函数和核心结构体（删了部分注释和条件编译，同时不考虑VST 2.4不使用的内容，也就是标了DECLARE_VST_DEPRECATED的）：

// 主机回调，这个是需要由主机实现一系列的opcode，然后给插件调用的
typedef VstIntPtr (VSTCALLBACK *audioMasterCallback) (AEffect* effect, VstInt32 opcode, VstInt32 index, VstIntPtr value, void* ptr, float opt);
// 调度函数，插件实现一系列的opcode，提供给主机调用的
typedef VstIntPtr (VSTCALLBACK *AEffectDispatcherProc) (AEffect* effect, VstInt32 opcode, VstInt32 index, VstIntPtr value, void* ptr, float opt);
// 音频处理函数，插件实现，由主机提供输入和输出缓冲区，以及要处理的采样数，通常在单独的线程调用
typedef void (VSTCALLBACK *AEffectProcessProc) (AEffect* effect, float** inputs, float** outputs, VstInt32 sampleFrames);
// 同上，但是缓冲区的double类型的浮点数，而不是float类型的，有更高的精度
typedef void (VSTCALLBACK *AEffectProcessDoubleProc) (AEffect* effect, double** inputs, double** outputs, VstInt32 sampleFrames);
// 参数设置函数，主机提供一个索引和一个参数值，插件负责保存对应的参数
typedef void (VSTCALLBACK *AEffectSetParameterProc) (AEffect* effect, VstInt32 index, float parameter);
// 参数获取函数，主机提供一个索引，插件返回该索引对应参数的值
typedef float (VSTCALLBACK *AEffectGetParameterProc) (AEffect* effect, VstInt32 index);

// 前面几个回调函数的第一个参数需要的结构体
struct AEffect
{
    VstInt32 magic; // "VstP"，按32位整数保存，注意'V'是在地址高位的，即0x56737450
    AEffectDispatcherProc dispatcher; // AEffectDispatcherProc函数指针
    AEffectProcessProc DECLARE_VST_DEPRECATED (process);
    AEffectSetParameterProc setParameter; // AEffectSetParameterProc函数指针
    AEffectGetParameterProc getParameter; // AEffectGetParameterProc函数指针
    VstInt32 numPrograms; // 预设的数量
    VstInt32 numParams;   // 参数的数量
    VstInt32 numInputs;   // 输入通道数量
    VstInt32 numOutputs;  // 输出通道数量
    VstInt32 flags; // 见VstAEffectFlags
    VstIntPtr resvd1; // 给主机留着的，置0
    VstIntPtr resvd2; // 同上
    VstInt32 initialDelay; // 大概是某些算法有延迟，这个参数告诉主机延迟的采样数，一般就0
    VstInt32 DECLARE_VST_DEPRECATED (realQualities);
    VstInt32 DECLARE_VST_DEPRECATED (offQualities);
    float    DECLARE_VST_DEPRECATED (ioRatio);
    void* object; // 指针，指向SDK里的类，不用SDK的话可以自定义使用，每个实例都不一样
    void* user;   // 留给插件开发者自由分配的指针
    VstInt32 uniqueID; // 每个插件要一个独一无二的标志，得找Steinberg申请，现在也没啥用了，尽可能独一无二
    VstInt32 version;  // 插件的版本
    AEffectProcessProc processReplacing; // 替换模式的process函数，这个替换应该是指输入输出缓冲区是同一个
    AEffectProcessDoubleProc processDoubleReplacing; // 同上，但是使用double类型的采样
    char future[56]; // 留给未来的（然而没有了），置0
};

// 上面AEffect里flags需要的标志位
enum VstAEffectFlags
{
    effFlagsHasEditor     = 1 << 0, // 插件有编辑器（UI界面）
    effFlagsCanReplacing  = 1 << 4, // 支持processReplacing，必须要设置
    effFlagsProgramChunks = 1 << 5, // 没用过，感觉没啥用
    effFlagsIsSynth       = 1 << 8, // 合成器得设置这个
    effFlagsNoSoundInStop = 1 << 9, // 没用过，大概是说插件保证process的时候输入为0就不会输出声音
    effFlagsCanDoubleReplacing = 1 << 12, // 支持processDoubleReplacing，可选
    DECLARE_VST_DEPRECATED (effFlagsHasClip) = 1 << 1,
    DECLARE_VST_DEPRECATED (effFlagsHasVu)   = 1 << 2,
    DECLARE_VST_DEPRECATED (effFlagsCanMono) = 1 << 3,
    DECLARE_VST_DEPRECATED (effFlagsExtIsAsync)   = 1 << 10,
    DECLARE_VST_DEPRECATED (effFlagsExtHasBuffer) = 1 << 11
};

注意回调函数那边的VSTCALLBACK其实就是C语言默认的函数调用约定，前面有定义，但实际上用C开发的话没必要。这几个回调函数里，一般情况下除了音频处理的函数需要在单独的线程中进行，其它的都是在UI线程进行的。

结构体主要提供插件的基本信息以及一些回调函数的指针，根据需要设置就行了，还有这个flags必须设置effFlagsCanReplacing，因为大部分插件都是有界面的，所以基本上都要设置effFlagsHasEditor，如果是合成器就设置effFlagsIsSynth，不然默认是效果器，最后这个effFlagsCanDoubleReplacing看需不需要双精度浮点数吧，建议是要的，因为现在大部分软件和插件都是64位的，一般64位CPU处理double很快而且精度更高，大部分DAW内部也是用double类型的数据。

插件的入口函数一般是这么定义的：

AEffect *VSTPluginMain(audioMasterCallback hostCallback)
{
    new MyPlugin(hostCallback)->getAEffect();
}

这里的MyPlugin是一个C++的类，参数就是audioMasterCallback的回调，然后调用getAEffect获取该类对应的AEffect结构体指针，每个插件的实例都要这样，不然插件之间会影响。

入口函数的名称除了VSTPluginMain也可以是main，一般只要前者，记得要在DLL导出，不同编译器有不同的方法。

接着说几个关键opcode，插件必须要实现的或者是实现基本功能需要的，否则插件跑不起来，opcode的定义在aeffect.h和aeffectx.h里，分别是枚举AEffectOpcodes和AudioMasterOpcodesX。

• effGetVstVersion，一定要实现，返回2400，不然主机（大概率）会认为这个插件是老版本的
• effGetParamLabel、effGetParamDisplay、effGetParamName，可选，和参数的显示有关，可以在DAW看到
• effSetSampleRate、effSetBlockSize，有些效果需要采样率、块大小之类的参数
• effCanBeAutomated，参数是否可以被自动化，挺有用的
• effEditGetRect、effEditOpen、effEditClose，界面相关的，有插件界面肯定要实现
• effEditIdle，主机在UI线程调用，用来给插件更新界面用的
• effGetChunk、effSetChunk，保存或设置所有参数的值，给主机用来实现插件参数状态的保存

除了插件要实现opcode，有些功能需要调用主机提供的回调函数，在枚举AudioMasterOpcodes和AudioMasterOpcodesX中。

• audioMasterAutomate，比如用户拖动界面的控件，调用这个告诉主机这个参数可以被自动化
• audioMasterBeginEdit、audioMasterEndEdit，在用户开始修改参数到结束修改参数时调用，通常是鼠标按下到松开
• audioMasterGetDirectory，向主机询问插件DLL的路径，一般用来加载资源用

所以你只要实现最基本的AEffect结构体，实现几个核心回调函数，就可以实现一个最简单的VST 2.4插件了。

至于其他没提到的opcode，还有一大堆结构体、常量，不在本文讨论之列。

这样看来，VST 2架构的本质就是用到了C风格的回调函数，这很像Windows的窗口机制（WndProc函数）。

VST 3

VST 3之于VST 2，和VST 2与VST 1的关系完全不同，前者更像是重写的架构，而不是后者一样的扩充。

VST 3是由一组类似于COM的接口和一系列数据结构组成的。

如果说详细点，VST 3是由VST MA和VST 3 API组成的，分别在pluginterfaces/base和pluginterfaces/vst这两个文件夹里。

熟悉COM的看这个应该没什么问题， 不熟悉的话建议先了解一下COM技术，会稍微好一点。

与COM的IUnknown不同，VST自己定义了FUnknown，不过其实是ABI兼容的，VST的所有和COM类似的部分都是自己定义的，目的就是去除对Windows平台（COM有关头文件）的依赖，实现跨平台。

class FUnknown
{
public:
    virtual tresult PLUGIN_API queryInterface (const TUID _iid, void** obj) = 0;
    virtual uint32 PLUGIN_API addRef () = 0;
    virtual uint32 PLUGIN_API release () = 0;

    static const FUID iid;
};
DECLARE_CLASS_IID (FUnknown, 0x00000000, 0x00000000, 0xC0000000, 0x00000046)

类型tresult类似于HRESULT，其实就是一个32位整数，0表示OK，其余都是一个负数，表示各种错误。

类型TUID是这么定义的typedef int8 TUID[16];，其实和GUID是兼容的。

类型FUID是一个类，但是没有虚函数，其实可以理解为仅有一个TUID成员的带方法的高级结构体。

调用约定是PLUGIN_API，在Windows我平台是stdcall，在其他平台是cdecl。

源代码文件里好多东西，真正有用的其实不多，当然用C++搞这个COM接口确实蛋疼，毕竟语言级别的支持没有，比如每个接口都有的静态常量iid，实际上Steinberg是自己实现了一个FObject对象来实现的各种功能，还有一堆宏。不过实现的方法有很多，如果说把VST 3的接口翻译到别的语言，有些功能实现起来可能会轻松不少。

接下来是VST MA里的重要接口，IPluginBase，这个接口可以说是VST 3所有插件的基础了。

class IPluginBase: public FUnknown
{
public:
    // 初始化，给的接口必须可以获取IHostApplication，同时插件应该在这个方法里实现内存分配等任务，而不是构造函数里
    virtual tresult PLUGIN_API initialize (FUnknown* context) = 0;
    // 终止，之前分配的内存在这里销毁
    virtual tresult PLUGIN_API terminate () = 0;

    static const FUID iid;
};
DECLARE_CLASS_IID (IPluginBase, 0x22888DDB, 0x156E45AE, 0x8358B348, 0x08190625)

主机保证会在需要的时候调用initialize，同时确保会调用terminate让插件释放资源。

之后会讲到的几个VST 3接口，都是在其基础之上的，不过在此之前，最后讲一下VST MA里最后一个关键接口——IPluginFactory，很显然，用的工厂模式。

class IPluginFactory : public FUnknown
{
public:
    // 获取插件工厂信息
    virtual tresult PLUGIN_API getFactoryInfo (PFactoryInfo* info) = 0;
    // 获取类的数量，一般都是2
    virtual int32 PLUGIN_API countClasses () = 0;
    // 获取索引index的类的信息
    virtual tresult PLUGIN_API getClassInfo (int32 index, PClassInfo* info) = 0;
    // 根据类的16位UID和接口的16位UID创建实例，FIDString就是char *
    virtual tresult PLUGIN_API createInstance (FIDString cid, FIDString _iid, void** obj) = 0;

    static const FUID iid;
};

DECLARE_CLASS_IID (IPluginFactory, 0x7A4D811C, 0x52114A1F, 0xAED9D2EE, 0x0B43BF9F)

其中PFactoryInfo和PClassInfo如下：

struct PFactoryInfo
{
    enum FactoryFlags
    {
        kNoFlags                 = 0,
        kClassesDiscardable      = 1 << 0, // 工厂的类可变，主机得累死，一般不用
        kLicenseCheck            = 1 << 1, // 最新版已经弃用了，应该是检查许可证
        kComponentNonDiscardable = 1 << 3, // 组件不会被卸载，直到进程退出
        kUnicode                 = 1 << 4  // 组件支持Unicode，其实是UTF-16，基本都要支持，要国际化的嘛
    };
    enum
    {
        kURLSize = 256,
        kEmailSize = 128,
        kNameSize = 64
    };
    char8 vendor[kNameSize]; // 供应商名称
    char8 url[kURLSize];     // 供应商网站
    char8 email[kEmailSize]; // 供应商电子邮箱
    int32 flags; // 上面的FactoryFlags
};

struct PClassInfo
{
    enum ClassCardinality
    {
        kManyInstances = 0x7FFFFFFF // 允许多个实例，也就是加载好几个
    };
    enum
    {
        kCategorySize = 32,
        kNameSize = 64
    };
    TUID cid; // 这个类的UID，自己随机生成一个就行了，基本确保唯一性
    int32 cardinality; // 设置上面那个kManyInstances
    char8 category[kCategorySize]; // 类的类别，比如"Audio Module Class"、"Component Controller Class"这种
    char8 name[kNameSize]; // 类的名称，自己起一个
};

这个工厂后来还扩充了IPluginFactory2和IPluginFactory3，接口如下：

class IPluginFactory2 : public IPluginFactory
{
public:
    // 获取PClassInfo2的类信息
    virtual tresult PLUGIN_API getClassInfo2 (int32 index, PClassInfo2* info) = 0;

    static const FUID iid;
};

DECLARE_CLASS_IID (IPluginFactory2, 0x0007B650, 0xF24B4C0B, 0xA464EDB9, 0xF00B2ABB)

struct PClassInfo2
{
    TUID cid; // 兼容PClassInfo结构体
    int32 cardinality; // 同上
    char8 category[PClassInfo::kCategorySize]; // 同上
    char8 name[PClassInfo::kNameSize]; // 同上
    enum {
        kVendorSize = 64,
        kVersionSize = 64,
        kSubCategoriesSize = 128
    };
    uint32 classFlags; // 目前仅针对"Audio Module Class"，有kDistributable和kSimpleModeSupported
    char8 subCategories[kSubCategoriesSize]; // 子类别，比如"Fx"这种，有具体的常量定义
    char8 vendor[kVendorSize]; // 供应商名称
    char8 version[kVersionSize]; // 版本，比如"1.0.0.0"
    char8 sdkVersion[kVersionSize]; // VST版本，有常量定义，比如"VST 3.7.8"
};

class IPluginFactory3 : public IPluginFactory2
{
public:
    // 没啥好说的
    virtual tresult PLUGIN_API getClassInfoUnicode (int32 index, PClassInfoW* info) = 0;
    // 主机提供一个上下文接口，应该也是实现了IHostApplication
    virtual tresult PLUGIN_API setHostContext (FUnknown* context) = 0;

    static const FUID iid;
};

DECLARE_CLASS_IID (IPluginFactory3, 0x4555A2AB, 0xC1234E57, 0x9B122910, 0x36878931)

// 相比于PClassInfo2，就一些char8换成了char16，没啥好说的
struct PClassInfoW
{
    TUID cid;
    int32 cardinality;
    char8 category[PClassInfo::kCategorySize]; // 这个没变，因为有常量定义，只能是ASCII字符串
    char16 name[PClassInfo::kNameSize];
    enum {
        kVendorSize = 64,
        kVersionSize = 64,
        kSubCategoriesSize = 128
    };
    uint32 classFlags;
    char8 subCategories[kSubCategoriesSize];
    char16 vendor[kVendorSize];
    char16 version[kVersionSize];
    char16 sdkVersion[kVersionSize];
};

实际开发中，一般只要自己设置PClassInfo2，然后转成PClassInfoW就行了，如果用Steinberg提供的工具的话，甚至都不用写这些代码。

作为插件，在动态链接库里需要导出名为GetPluginFactory的函数，用来获得工厂对象，一个可能的实现如下：

SMTG_EXPORT_SYMBOL IPluginFactory* PLUGIN_API GetPluginFactory ()
{
    static MyPluginFactory *gFactory = nullptr;
    if (!gFactory) {
        gFactory = new MyPluginFactory;
    }
    else {
        gFactory->addRef();
    }
    return gFactory;
}

在Windows平台，还有可选的InitDll和ExitDll，可选是因为Windows有DllMain，可以实现加载/卸载时的资源申请/释放操作，但是Linux和macOS就不这样了。在Linux平台，使用ModuleEntry和ModuleExit；而在macOS平台，使用BundleEntry和BundleExit。主机必须在加载插件后调用XxxEntry，且在卸载前调用XxxExit。

主机获取到了插件的工厂之后，就会去依次调用几个方法获取相关信息，同时还会尝试调用queryInterface来获取IPluginFatory2和IPluginFactory3的对象，最后调用createInstance来创建IComponent和IEditController的对象。

主机一般会先调用createInstance获取IComponent，然后通过queryInterface获取IAudioProcessor。

Steinberg建议插件的音频处理部分和参数控制部分分离，这个需要在classFlags里设置kDistributable，如果没有设置，那么主机就会尝试通过IComponent对象接着获取IEditController，否则就重新调用createInstance。分离的好处是灵活，不分离好处是代码简单，因为这几个接口都可以在同一个类里面实现。

可以参考一下Audio Processor调用过程图和Edit Controller调用过程图。

关于IComponent、IAudioProcessor和IEditController就不多介绍了，和底层架构关系不大，已经是特定功能的接口了。

要实现其他功能的话，比如GUI，还得有IPlugView和IPlugFrame，如果要在GUI控制参数的话还要IComponentHandler，还有好多接口以及各种各样的结构体，反正突出一个字——乱。

其实到这里，我也只是讲了VST 3那么多机制的冰山一角，当然底层架构基本就算是说完了，剩下的就是在这套架构的基础上增加的各种各样的功能了。

VST 2和VST 3的对比

在开始对比之前，我想先说一下历史，来捋一下时间线。

COM是微软在1993年首次提出的，VST 1.0是在1996年推出的，在90年代那会，COM逐渐流行起来，然后在1999年推出了VST 2，接下来几年就不断更新，到了2006年的2.4就不动了，随后就是2008年的VST 3。2013年，Steinberg宣布不再维护VST 2 SDK，但是开发者基本不受影响，直到2018年，Steinberg准备停止VST 2的支持，也就意味着18年之后，任何开发者如果没有在之前和Steinberg签了协议的话，就不能开发商业的VST 2插件了。而到了2022年，Steinberg更是直接宣布他家软件将最后支持VST 2插件24个月，然后就会移除VST 2的支持，然后就引起了骂声一片。

奇怪的是，明明1993年就有了COM，为啥2008年的VST 3才用了这个呢？事实上并不奇怪，因为VST 1到VST 2那段时间，VST插件可以说是非常火爆的，即使Steinberg在自己的软件Cubase和Nuendo已经用了类似COM的技术，也就是VST MA，但是想要推广开来还是需要时间的，所以他们也只能硬着头皮先更新VST 2再说。不过由于VST 2不符合Steinberg的利益需要了，所以他们推出了新架构的VST 3，但是实际上如果接着扩充VST 2，未尝不可实现现在的一下新功能，只不过VST 2的架构势必会变得更加臃肿——增加更多opcode，弃用一些老的opcode，甚至增加新的回调函数。

但不论如何，对于广大开发者而言，VST 3相比于VST 2并没有什么升级，而是换了一种Steinberg喜欢的开发方式而已，插件该有的功能基本都有，没有的很多主机也不会去实现，而且给VST 2接着打补丁也是可以实现的，况且VST 3更庞大，更复杂。但是Steinberg偏不，强推新的VST 3，甚至到现在打算完全放弃支持旧的VST 2。

可以看看国外的这篇文章，或者国内有人发布的翻译版本，基本说了二者的一些区别与好坏。

国外也有人讨论关于VST 3为数不多的好功能——样本精确自动化（提供采样点和参数的列表，能提高参数自动化时的精度，同时性能损失较少），不过大部分DAW很难支持，因为其他的插件格式不一定有这个功能，况且目前也有DAW（说的就是某水果形状的软件）做了减小单次处理的样本数量这样的方法来提高参数自动化的精度（对有些插件来说这样会出现问题）。当然这个功能确实非常不错，但是实际上在VST 2的架构上扩充，未尝不能实现。

从技术架构的角度出发，显然VST 2更加通用，兼容性更好，因为插件的底层就是C风格的回调函数，这适用于绝大多数的语言，所以可以很轻松地在其他语言实现，比如现在比较火的Rust、Zig这类的。

而VST 3的SDK则是和C++深度绑定，虽然官方也提供了C风格的接口，实际上就是微软COM的早期模式，用C语言的结构体来模拟现在C++的虚函数表。但是和C++的过度耦合，使得其他语言很难实现，但是也不是没有，比如Rust也有人做过。

至于我为什么会对这俩玩意这么熟悉，那就得回到2021年，那会对VST 2插件的开发有些兴趣，又不想用C/C++这样的技术开发，想用我之前比较熟悉的Object Pascal开发，同时配合Delphi的VCL或者Lazarus的LCL库可以轻松实现GUI界面的开发，尤其是LCL可以轻松跨平台。

所以在那年陆陆续续花了几个月就搞清楚了VST 2的架构，就是用最基础的C风格的回调构建代码，写了一些基础的插件，当然是因为DSP那块不是很熟悉，也不会复杂的算法。

后来考虑到VST 2确实也比较老了，加上我又没赶上当时最后一波的机会（2018年之后就无法获取VST 2专用授权许可证了），所以也不可能再发布VST 2的任何插件了，所以就将目光转向了VST 3（在专用授权许可证之外，还可以选用GPLv3许可证），然后就断断续续花了两年时间，到最近（2023年7月）才终于完成最后一步——摸清架构，写出基础插件。花了这么久的时间，主要还是C++的代码翻起来太难受了，加上代码量巨大，光是翻译成Object Pascal的接口部分代码，就将近4000行，再加上还有实现一个基础插件还需要1000多行的代码，这和VST 2完全不能比（接口1000多行，基础插件几百行）。

如果你有兴趣，可以光顾一下我的GitHub，关于VST 2和VST 3的Pascal版本的链接就放这里了：

• VST 2：https://github.com/DrPeaboss/vst24pas
• VST 3：https://github.com/DrPeaboss/vst3-pas

结语

VST 2和VST 3是两个独立的技术路线，只因创造者Steinberg换了他们的口味，导致VST 2这一简单好用且流行的格式被迫随着时间而逐渐淡出人们视野。当然VST 3也不是一无是处，毕竟COM技术也是微软多年实践验证过的，也没什么问题。而且Steinberg提供了高度封装的VST 3 SDK，以及AAX、AU等其他格式的包装器，还有一系列的工具，使得实际的开发得到了简化（当然大部分人可能用JUCE这种库）。

但是Steinberg做的不好的就是想要强行改变开发者习惯，在VST 2用的好好的情况下，居然用各种手段迫使开发者转换到VST 3来，而且甚至还想要放弃支持VST 2。强如微软也依然保持着基本的兼容性，甚至MIDI 2.0也是对MIDI 1.0的补充，要知道MIDI 1.0那是1983年的古老标准了。不是谁都是苹果，可以有那么强的实力随意破坏向后兼容性。

希望Steinberg好自为之，接着支持原有的VST 2，好好经营VST 3，同时不要再让未来可能的VST 4也这样了。

本栏目推荐文章
• API架构风格
• 自定义jQuery插件Step by Step
• 如何让Visual Studio Tools for Unity插件用于调试你自己的Mono嵌入应用程序
• Chrome 浏览器插件 V3 版本 Manifest.json 文件中 Action 的类型（Types）、方法（Methods）和事件（Events）的属性和参数解析
• 小程序开发：将改造后的步骤条插件移植到自己的小程序
• 小程序开发：在插件市场寻找步骤条组件并二开
• B站视频一键下载插件
• 银行业数据架构的前世今生
• 浅谈6种流行的API架构风格
• idea 热部署插件 JRebel

架构 插件 音频 VST架构 插件 音频vst 架构 手表 音频 智能 audiovstplayer插件 播放器 音频 vst 实例vst vst实例 架构 插件 代码 amp爬虫 架构 插件 实例drag drop vst 节点 实例node vst