CN109918075A - 利用打包插件的sdk打包方法、打包插件及相应终端 - Google Patents

Abstract

本发明提供一种利用打包插件的SDK打包方法、打包插件及相应终端，该方法包括：当检测到对宿主项目的打包操作时，通过打包插件获取插件配置信息；根据插件配置信息确定宿主项目中相应的目标文件，并基于目标文件打包生成内核包；将内核包打包为外壳包，以生成SDK，本发明利用打包插件执行项目打包，仅需简单的插件配置信息，无需将脚本文件一一分散，就可以很方便地引入，轻松进行项目间移植的同时也方便维护；且插件可对任务栈Task进行统一管理，使用人员不必关心各个Task实际的功能，只需配置参数即可，显著提高代码的可读性，相较于现有的打包脚本打包方式，显著减少了打包SDK的运行时间，提高了SDK的打包效率。

Description

利用打包插件的SDK打包方法、打包插件及相应终端

技术领域

本发明涉及计算机技术领域，具体而言，本发明涉及一种利用打包插件的SDK打包方法、打包插件及相应终端。

背景技术

SDK(Software Development Kit，软件开发工具包)是指辅助开发某一特定的应用软件时提供的相关文档、范例和开发工具的集合，包括用于调试和其他用途的实用工具。它可以简单的为某个程序设计语言提供应用程序接口API的一些文件，也可能包括能与某种嵌入式系统通讯的复杂的硬件，还可能包括示例代码、支持性的技术注解或者其他的为基本参考资料澄清疑点的支持文档。

一般SDK的打包是基于现有编程语言开发工具提供的原始脚本实现的。这种打包脚本在使用时要将脚本代码分散到项目中的各个位置，并需要做适应性的修改。且打包脚本的不同模块下的任务栈Task命名可以重复，脚本的开发人员往往容易在不同的模块中为功能类似的Task进行相同的命名。

然而，因为打包脚本的分散，在项目间进行移植存在一定的难度，每次移植相当于重新编写脚本代码。且与项目的配置混在一起，维护起来费时费力，而且很容易因维护造成bug。另外，如果存在多个相同名称的Task，大大降低了脚本的可读性，在项目级别很难一眼看出某个Task到底在哪个模块起了什么样的作用。

发明内容

为克服上述技术问题或者至少部分地解决上述技术问题，特提出以下技术方案：

本发明提供一种利用打包插件的SDK打包方法，所述打包插件已预先集成到宿主项目中，该方法包括：

当检测到对所述宿主项目的打包操作时，通过所述打包插件获取插件配置信息；

根据所述插件配置信息确定所述宿主项目中相应的目标文件，并基于所述目标文件打包生成内核包；

将所述内核包打包为外壳包，以生成SDK。

可选地，所述基于所述目标文件打包生成内核包的步骤之前，包括：

删除预定文件路径下所述打包插件的历史打包遗留文件。

可选地，所述将所述内核包打包生成外壳包的步骤之前，包括：

根据所述插件配置信息，对生成的内核包进行混淆处理。

具体地，所述将所述内核包打包为外壳包，以生成SDK的步骤，包括：

基于所述宿主项目所在的操作系统相应的编译语言，对所述内核包进行编译生成可执行文件；

将所述可执行文件复制到所述宿主项目的资源文件夹中，并打包生成外壳包。

可选地，所述将所述外壳包复制到所述宿主项目所在的操作系统相应的资源文件夹中的步骤，还包括：

根据所述插件配置信息，对所述外壳包进行重命名。

可选地，该方法还包括：

将根据所述插件配置信息确定的相关文档与打包完成的SDK进行压缩。

本发明还提供一种打包插件，所述打包插件已预先集成到宿主项目中，包括：

信息获取模块，用于当检测到对所述宿主项目的打包操作时，获取插件配置信息；

内核包生成模块，用于根据所述插件配置信息确定所述宿主项目中相应的目标文件，并基于所述目标文件打包生成内核包；

外壳包生成模块，用于将所述内核包打包为外壳包，以生成SDK。

可选地，该装置还包括：

删除模块，用于删除预定文件路径下所述打包插件的历史打包遗留文件。

可选地，该装置还包括：

混淆模块，用于根据所述插件配置信息，对生成的内核包进行混淆处理。

具体地，所述外壳包生成模块具体用于基于所述宿主项目所在的操作系统相应的编译语言，对所述内核包进行编译生成可执行文件；以及，

所述外壳包生成模块具体用于将所述可执行文件复制到所述宿主项目的资源文件夹中，并打包生成外壳包。

可选地，所述外壳包生成模块还具体用于根据所述插件配置信息，对所述外壳包进行重命名。

可选地，该装置还包括：

压缩模块，用于将根据所述插件配置信息确定的相关文档与打包完成的SDK进行压缩。

本发明还提供一种终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一项所述的SDK打包方法。

本发明还提供一种可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一项所述的SDK打包方法。

本发明提供的利用打包插件的SDK打包方法、打包插件及相应终端，当检测到对宿主项目的打包操作时，通过打包插件获取插件配置信息；根据插件配置信息确定宿主项目中相应的目标文件，并基于目标文件打包生成内核包；将内核包打包为外壳包，以生成SDK，本发明利用打包插件执行项目打包，仅需简单的插件配置信息，无需将脚本文件一一分散，就可以很方便地引入，轻松进行项目间移植的同时也方便维护；且插件可对任务栈Task进行统一管理，使用人员不必关心各个Task实际的功能，只需配置参数即可，显著提高代码的可读性，相较于现有的打包脚本打包方式，显著减少了打包SDK的运行时间，提高了SDK的打包效率。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明一个实施例提供的利用打包插件的SDK打包方法的流程示意图；

图2为本发明一个实施例提供的打包插件运行的流程示意图。

图3为本发明另一实施例提供的利用打包插件的SDK打包方法的流程示意图；

图4为本发明一个实施例提供的打包插件的框架示意图。

图5为本发明另一实施例提供的打包插件的框架示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

考虑到一般的SDK打包基于现有编程语言开发工具提供的原始脚本实现的，例如Android Studio提供的原始脚本，在使用过程中存在移植困难、可读性差、可维护性差等缺陷，本发明实施例提供插件化方式进行SDK项目打包，打包后的SDK供Android平台的开发人员使用。

下面结合附图具体介绍本发明实施例的技术方案。

本发明实施例提供了一种利用打包插件的SDK打包方法，其中，编写的打包插件已预先集成到宿主项目中，该打包插件以项目构建工具Gradle为基础进行编写。宿主项目能够调用打包插件运行相应的打包功能，这时候打包插件就能够在宿主项目上执行其运行逻辑，因此利用打包插件的SDK打包方法即为该打包插件的运行方法，如图1所示，该方法包括：

步骤S110：当检测到对宿主项目的打包操作时，通过打包插件获取插件配置信息。

其中，插件配置信息是根据打包用户的需求配置的，用于定制化地对项目进行打包。

本发明实施例中，打包插件中可以携带插件配置信息的输入窗口，以提供给打包用户设置相关参数的模板，使得获取的插件配置信息在打包插件中对应统一的接口，提高打包插件的运行效率。

具体地，插件配置信息可以包括打包插件运行过程中各阶段所需的配置信息。当检测到对宿主项目的打包操作时，打包插件通过生成BuildJarExtension与BuildSdkExtension对象来分别保存不同类型的插件配置信息。

实际应用中，当检测到对宿主项目的打包操作时，打包插件获取插件配置信息可以包括获取用户实时输入的插件配置信息，或者获取用户预先输入并存储的插件配置信息。

本发明实施例中，通过继承自org.gradle.api.Plugin的PackImpl类来获取插件配置信息。除此之外，PackImpl还用于连接宿主项目与打包插件，在后续各步骤中将打包插件定义的Task提供给宿主项目，并安排各Task的时序，参见图2，示出了各Task的运行流程。

步骤S120：根据插件配置信息确定宿主项目中相应的目标文件，并基于目标文件打包生成内核包；

该步骤中，打包插件会初始化一个MakeJarTask任务来执行内核jar的打包工作，该任务由继承自org.gradle.api.tasks.bundling.Jar的MakeJarTask类生成。

根据插件配置信息确定宿主项目中相应的目标文件，即打包用户指定的项目文件，将其打进jar文件，生成的即为内核包。

步骤S130：将内核包打包为外壳包，以生成SDK。

该步骤中，打包插件会初始化一个BuildDexTask任务来执行外壳jar的打包工作，该任务由继承自org.gradle.api.tasks.Exec的BuildDexTask类生成。

将内核jar打进另一个jar文件中，生成的即为外壳包。

具体地，BuildDexTask可以基于宿主项目所在的操作系统相应的编译语言，对内核包进行编译生成可执行文件。

作为示例地，若在Windows系统下，可以采用cmd及jdk；若在Mac OS系统下，可以采用shell及jdk；在此不一一列举。在本发明实施例中，SDK供Android平台的开发人员使用，内核包经编译后，生成Dex文件，为Android平台上的可执行文件。

随后，将可执行文件复制到宿主项目的资源文件夹中，并打包生成外壳包。

其中，宿主项目的资源文件夹可以是assets文件夹，存放在assets文件夹中的文件不会再被编译，在打包插件运行过程中通过BuildDexTask将其直接打入外壳jar。

其中，可以初始化一个CopyTask任务来执行打包过程中的复制工作，该任务由继承自org.gradle.api.DefaultTask的CopyTask类生成。

可选地，通过ProguardJarTask任务再对外壳jar进行混淆处理，处理过程参见对内核jar的混淆，再次不在赘述。

实际应用中，CopyTask任务还可以执行外壳包的重命名工作。根据插件配置信息，对外壳包进行重命名。

根据插件配置信息，可以确定客户指定的最终SDK的命名方式，对外壳包进行重命名。

此时，SDK已经打包完成。

本发明实施例提供的利用打包插件的SDK打包方法，利用打包插件执行项目打包，仅需简单的插件配置信息，无需将脚本文件一一分散，就可以很方便地引入，轻松进行项目间移植的同时也方便维护；且插件可对任务栈Task进行统一管理，使用人员不必关心各个Task实际的功能，只需配置参数即可，显著提高代码的可读性，相较于现有的打包脚本打包方式，显著减少了打包SDK的运行时间，提高了SDK的打包效率。

本发明另一实施例中，提供了一种更为优化的利用打包插件的SDK打包方法，如图3所示，包括：

步骤S310：当检测到对宿主项目的打包操作时，通过打包插件获取插件配置信息。

其中，插件配置信息是根据打包用户的需求配置的，用于定制化地对项目进行打包。

本发明实施例中，打包插件中可以携带插件配置信息的输入窗口，以提供给打包用户设置相关参数的模板，使得获取的插件配置信息在打包插件中对应统一的接口，提高打包插件的运行效率。

具体地，插件配置信息可以包括打包插件运行过程中各阶段所需的配置信息。当检测到对宿主项目的打包操作时，打包插件通过生成BuildJarExtension与BuildSdkExtension对象来分别保存不同类型的插件配置信息。

实际应用中，当检测到对宿主项目的打包操作时，打包插件获取插件配置信息可以包括获取用户实时输入的插件配置信息，或者获取用户预先输入并存储的插件配置信息。

本发明实施例中，通过继承自org.gradle.api.Plugin的PackImpl类来获取插件配置信息。除此之外，PackImpl还用于连接宿主项目与打包插件，在后续各步骤中将打包插件定义的Task提供给宿主项目，并安排各Task的时序。

步骤S320：删除预定文件路径下打包插件的历史打包遗留文件。

该步骤中，打包插件会初始化一个ClearJarTask任务来执行文件的删除工作，该任务由继承自org.gradle.api.tasks.Delete的ClearJarTask类生成。

其中，历史打包遗留文件为打包插件为其他项目打包过程在系统中遗留的文件，即非本次宿主项目的打包所需要的文件。可能包括历史SDK目录结构，历史SDK相关文件的名称信息、属性信息，打包插件历史进程状态信息、历史打包过程中生成的临时文件等，不限于上述类型。

在本次打包之前及时清理历史打包遗留文件，避免把历史打包遗留文件打包进本次宿主项目的jar包中。

为提高清理效率，确定可能存在历史打包遗留文件的预定文件路径，并在打包插件中记录。在本次打包之前通过查找预定文件路径下的历史打包遗留文件并删除，达到清除的目的。

步骤S330：根据插件配置信息确定宿主项目中相应的目标文件，并基于目标文件打包生成内核包；

该步骤中，打包插件会初始化一个MakeJarTask任务来执行内核jar的打包工作，该任务由继承自org.gradle.api.tasks.bundling.Jar的MakeJarTask类生成。

根据插件配置信息确定宿主项目中相应的目标文件，即打包用户指定的项目文件，将其打进jar文件，生成的即为内核包。

步骤S340：根据插件配置信息，对生成的内核包进行混淆处理。

为了提升SDK的安全性，在不影响生成的SDK可以正常运行的前提性，对内核包进行混淆处理，增加被破译的难度。

该步骤中，打包插件会初始化一个ProguardJarTask任务来执行内核包的混淆处理工作，该任务由继承自proguard.gradle.ProGuardTask的ProguardJarTask类生成。

根据插件配置信息，可以确定用户指定的需要进行混淆的内核包以及各个内核包的混淆方式。其中，打包插件中包含各种混淆方式的具体执行内容。比如，首尾对调的混淆方式、相同间隔对调的混淆方式，内核包中各种元素改写成无意义的名字等，本发明实施例的方式对此不作限定。

步骤S350：将内核包打包为外壳包，以生成SDK。

该步骤中，打包插件会初始化一个BuildDexTask任务来执行外壳jar的打包工作，该任务由继承自org.gradle.api.tasks.Exec的BuildDexTask类生成。

将内核jar打进另一个jar文件中，生成的即为外壳包。

具体地，BuildDexTask可以基于宿主项目所在的操作系统相应的编译语言，对内核包进行编译生成可执行文件。

作为示例地，若在Windows系统下，可以采用cmd及jdk；若在Mac OS系统下，可以采用shell及jdk；在此不一一列举。在本发明实施例中，SDK供Android平台的开发人员使用，内核包经编译后，生成Dex文件，为Android平台上的可执行文件。

随后，将可执行文件复制到宿主项目的资源文件夹中，并打包生成外壳包。

作为示例地，宿主项目的资源文件夹可以是assets文件夹，存放在assets文件夹中的文件不会再被编译，在打包插件运行过程中通过BuildDexTask将其直接打入外壳jar。

其中，可以初始化一个CopyTask任务来执行打包过程中的复制工作，该任务由继承自org.gradle.api.DefaultTask的CopyTask类生成。

可选地，通过ProguardJarTask任务再对外壳jar进行混淆处理，处理过程参见对内核jar的混淆，再次不在赘述。

实际应用中，CopyTask任务还可以执行外壳包的重命名工作。根据插件配置信息，对外壳包进行重命名。

根据插件配置信息，可以确定客户指定的最终SDK的命名方式，对外壳包进行重命名。

此时，SDK已经打包完成。

步骤S360：将根据插件配置信息确定的相关文档与打包完成的SDK进行压缩。

该步骤中，打包插件会初始化一个MakeZipTask任务来执行SDK的压缩工作，该任务由继承自org.gradle.api.DefaultTask的MakeZipTask类生成。

其中，根据插件配置信息确定用户指定的提供给开发人员的相关文档，用于指导和帮助开发人员使用该SDK。比如包括开发者文档、使用示例等，可以根据具体项目进行配置，在此不做限制。

需要说明的是，使用示例也会包含SDK的相关内容，可通过CopyTask任务将打包完的SDK拷贝到使用示例的文件夹下，以生成指导开发人员的Demo例子。

压缩后的包含SDK的压缩包，为提供给开发人员的最终完整格式。

本发明实施例提供的利用打包插件的SDK打包方法，利用打包插件执行项目打包，仅需简单的插件配置信息，无需将脚本文件一一分散，就可以很方便地引入，轻松进行项目间移植的同时也方便维护；且插件可对任务栈Task进行统一管理，使用人员不必关心各个Task实际的功能，只需配置参数即可，显著提高代码的可读性，相较于现有的打包脚本打包方式，显著减少了打包SDK的运行时间，提高了SDK的打包效率。

本发明实施例中，提供了一种打包插件，打包插件已预先集成到宿主项目中，该打包插件以项目构建工具Gradle为基础进行编写。宿主项目能够调用打包插件运行相应的打包功能，这时候打包插件就能够在宿主项目上执行其运行逻辑，如图4所示，该打包插件包括：

信息获取模块410，用于当检测到对宿主项目的打包操作时，获取插件配置信息；

内核包生成模块420，用于根据插件配置信息确定宿主项目中相应的目标文件，并基于目标文件打包生成内核包；

外壳包生成模块430，用于将内核包打包为外壳包，以生成SDK。

本发明实施例所提供的装置可以为设备上的特定硬件或者加载于设备上的软件或固件等。本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容，在此不再赘述。

本发明实施例提供的打包插件执行项目打包操作，仅需简单的插件配置信息，无需将脚本文件一一分散，就可以很方便地引入，轻松进行项目间移植的同时也方便维护；且插件可对任务栈Task进行统一管理，使用人员不必关心各个Task实际的功能，只需配置参数即可，显著提高代码的可读性，相较于现有的打包脚本打包方式，显著减少了打包SDK的运行时间，提高了SDK的打包效率。

本发明另一实施例中，提供了一种更为优化的打包插件，如图5所示，包括：

信息获取模块510，用于当检测到对宿主项目的打包操作时，获取插件配置信息；

删除模块520，用于删除预定文件路径下打包插件的历史打包遗留文件。

内核包生成模块530，用于根据插件配置信息确定宿主项目中相应的目标文件，并基于目标文件打包生成内核包；

混淆模块540，用于根据插件配置信息，对生成的内核包进行混淆处理。

外壳包生成模块550，用于将内核包打包为外壳包，以生成SDK。

其中，外壳包生成模块550具体用于基于宿主项目所在的操作系统相应的编译语言，对内核包进行编译生成外壳包；

以及，外壳包生成模块550具体用于将外壳包复制到宿主项目所在的操作系统相应的资源文件夹中。

可选地，外壳包生成模块还具体用于根据插件配置信息，对外壳包进行重命名。

进一步地，打包插件还包括：

压缩模块560，用于将根据插件配置信息确定的相关文档与打包完成的SDK进行压缩。

本发明实施例所提供的装置可以为设备上的特定硬件或者加载于设备上的软件或固件等。本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容，在此不再赘述。

本发明实施例提供的打包插件执行项目打包操作，仅需简单的插件配置信息，无需将脚本文件一一分散，就可以很方便地引入，轻松进行项目间移植的同时也方便维护；且插件可对任务栈Task进行统一管理，使用人员不必关心各个Task实际的功能，只需配置参数即可，显著提高代码的可读性，相较于现有的打包脚本打包方式，显著减少了打包SDK的运行时间，提高了SDK的打包效率。

本发明实施例还提供一种终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一实施例所述的方法。

该终端可以为包括计算机、手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑等任意终端设备。

其中，存储器可用于存储软件程序以及模块，处理器通过运行存储在存储器的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器可主要包括存储程序区和存储数据区。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器是控制中心，利用各种接口和线路连接整个终端的各个部分，通过运行或执行存储在存储器内的软件程序和/或模块，以及调用存储在存储器内的数据，执行各种功能和处理数据，从而对终端进行整体监控。可选的，处理器可包括一个或多个处理单元；优选的，处理器可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器中。

本发明实施例还提供一种可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一实施例所述的SDK打包方法。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种利用打包插件的SDK打包方法，其特征在于，所述打包插件已预先集成到宿主项目中，该方法包括：

当检测到对所述宿主项目的打包操作时，通过所述打包插件获取插件配置信息；

根据所述插件配置信息确定所述宿主项目中相应的目标文件，并基于所述目标文件打包生成内核包；

将所述内核包打包为外壳包，以生成SDK。

2.根据权利要求1所述的SDK打包方法，其特征在于，所述基于所述目标文件打包生成内核包的步骤之前，包括：

删除预定文件路径下所述打包插件的历史打包遗留文件。

3.根据权利要求1所述的SDK打包方法，其特征在于，所述将所述内核包打包生成外壳包的步骤之前，包括：

根据所述插件配置信息，对生成的内核包进行混淆处理。

4.根据权利要求1所述的SDK打包方法，其特征在于，所述将所述内核包打包为外壳包，以生成SDK的步骤，包括：

基于所述宿主项目所在的操作系统相应的编译语言，对所述内核包进行编译生成可执行文件；

将所述可执行文件复制到所述宿主项目的资源文件夹中，并打包生成外壳包。

5.根据权利要求4所述的SDK打包方法，其特征在于，所述将所述外壳包复制到所述宿主项目所在的操作系统相应的资源文件夹中的步骤，还包括：

根据所述插件配置信息，对所述外壳包进行重命名。

6.根据权利要求1所述的SDK打包方法，其特征在于，还包括：

将根据所述插件配置信息确定的相关文档与打包完成的SDK进行压缩。

7.一种打包插件，其特征在于，所述打包插件已预先集成到宿主项目中，包括：

信息获取模块，用于当检测到对所述宿主项目的打包操作时，获取插件配置信息；

内核包生成模块，用于根据所述插件配置信息确定所述宿主项目中相应的目标文件，并基于所述目标文件打包生成内核包；

外壳包生成模块，用于将所述内核包打包为外壳包，以生成SDK。

8.根据权利要求7所述的打包插件，其特征在于，所述外壳包生成模块具体用于基于所述宿主项目所在的操作系统相应的编译语言，对所述内核包进行编译生成可执行文件；以及，

所述外壳包生成模块具体用于将所述可执行文件复制到所述宿主项目的资源文件夹中，并打包生成外壳包。

9.一种终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-6任一项所述的SDK打包方法。

10.一种可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1-6任一项所述的SDK打包方法。