安卓系统的应用调试方法、装置、存储介质及电子设备

技术领域

本公开涉及计算机技术领域，具体地，涉及一种安卓系统的应用调试方法、装置、存储介质及电子设备。

背景技术

目前，安卓系统上存在越来越多的展示类应用，例如，游戏、用于三维展示与交互的应用、能够进行VR(Virtual Reality，虚拟现实技术)展示与交互的应用，这一类应用均需要渲染引擎按照一定的渲染逻辑，将美术资源(例如，模型、图像、视频等多媒体数据)在一定的时机渲染加载到页面的指定位置，以实现展示。

在开发这类应用的过程中，需要反复地调试渲染逻辑、更换美术资源，以求达到最好的展示效果。调试流程一般为：将渲染引擎框架、渲染逻辑和美术资源编译并打包成一个APK(Android application package，安卓应用程序包)，之后将安卓机上的旧版本APK卸载，并安装新打包的这一版APK，启动新APK用于调试。但是，由于打包、卸载、安装APK都需要耗费时间，且一般耗时较长，每次调试都需要等待较长时间才能获得本次调试的验证结果，调试效率低，进而导致开发效率受到影响。

发明内容

本公开的目的是提供一种安卓系统的应用调试方法、装置、存储介质及电子设备，以提升安卓系统的应用调试效率。

为了实现上述目的，根据本公开的第一方面，提供一种安卓系统的应用调试方法，所述方法包括：

若接收到针对目标应用的调试指令，判断是否存在针对所述目标应用的更新信息，所述更新信息包括对所述目标应用的渲染逻辑和/或美术资源的更新内容；

若确定存在所述更新信息，根据所述更新信息获得更新文件，并将所述更新文件发送至安卓设备的指定存储位置；

控制安装于所述安卓设备的引擎框架包开始运行，以进行本次调试，其中，所述引擎框架包封装有所述目标应用所对应的渲染引擎的框架、且不包含渲染逻辑和美术资源，并且，所述引擎框架包在运行过程中从所述安卓设备的指定存储位置获取所述目标应用的渲染逻辑和美术资源。

可选地，对所述目标应用的渲染逻辑的更新内容为渲染逻辑代码；

所述根据所述更新信息获得更新文件，并将所述更新文件发送至安卓设备的指定存储位置，包括：

若所述更新信息中包括对所述目标应用的渲染逻辑的更新内容，对所述渲染逻辑代码进行编译，获得编译后的文件；

将所述编译后的文件发送至所述安卓设备中用于存储渲染逻辑的第一存储位置。

可选地，对所述目标应用的美术资源的更新内容为多媒体数据；

所述根据所述更新信息获得更新文件，并将所述更新文件发送至安卓设备的指定存储位置，包括：

若所述更新信息中包括对所述目标应用的美术资源的更新内容，确定所述多媒体数据对应的第二存储位置；

将所述多媒体数据发送至所述第二存储位置。

可选地，所述方法还包括：

若在发送所述多媒体数据之前识别到所述第二存储位置存储有原始数据，利用所述多媒体数据替换所述原始数据。

可选地，若确定存在所述更新信息，在所述控制安装于所述安卓设备的引擎框架包开始运行的步骤之前，所述方法还包括：

确认所述更新文件已成功存储至所述安卓设备的指定存储位置。

可选地，所述方法还包括：

若确定不存在所述更新信息，直接控制所述引擎框架包开始运行，以进行本次调试。

可选地，所述方法还包括：

将与所述目标应用所对应的渲染引擎的框架封装为引擎框架包；

将所述引擎框架包发送至所述安卓设备；

在所述安卓设备上安卓所述引擎框架包。

根据本公开的第二方面，提供一种安卓系统的应用调试装置，所述装置包括：

判断模块，用于若接收到针对目标应用的调试指令，判断是否存在针对所述目标应用的更新信息，所述更新信息包括对所述目标应用的渲染逻辑和/或美术资源的更新内容；

更新模块，用于若确定存在所述更新信息，根据所述更新信息获得更新文件，并将所述更新文件发送至安卓设备的指定存储位置；

第一控制模块，用于控制安装于所述安卓设备的引擎框架包开始运行，以进行本次调试，其中，所述引擎框架包封装有所述目标应用所对应的渲染引擎的框架、且不包含渲染逻辑和美术资源，并且，所述引擎框架包在运行过程中从所述安卓设备的指定存储位置获取所述目标应用的渲染逻辑和美术资源。

可选地，对所述目标应用的渲染逻辑的更新内容为渲染逻辑代码；

所述更新模块包括：

编译子模块，用于若所述更新信息中包括对所述目标应用的渲染逻辑的更新内容，对所述渲染逻辑代码进行编译，获得编译后的文件；

第一发送子模块，用于将所述编译后的文件发送至所述安卓设备中用于存储渲染逻辑的第一存储位置。

可选地，对所述目标应用的美术资源的更新内容为多媒体数据；

所述更新模块包括：

确定子模块，用于若所述更新信息中包括对所述目标应用的美术资源的更新内容，确定所述多媒体数据对应的第二存储位置；

第二发送子模块，用于将所述多媒体数据发送至所述第二存储位置。

可选地，所述更新模块还包括：

替换子模块，用于若在发送所述多媒体数据之前识别到所述第二存储位置存储有原始数据，利用所述多媒体数据替换所述原始数据。

可选地，所述装置还包括：

确认模块，用于若确定存在所述更新信息，在所述第一控制模块控制安装于所述安卓设备的引擎框架包开始运行之前，确认所述更新文件已成功存储至所述安卓设备的指定存储位置。

可选地，所述装置还包括：

第二控制模块，用于若确定不存在所述更新信息，直接控制所述引擎框架包开始运行，以进行本次调试。

可选地，所述装置还包括：

封装模块，用于将与所述目标应用所对应的渲染引擎的框架封装为引擎框架包；

发送模块，用于将所述引擎框架包发送至所述安卓设备；

安装模块，用于在所述安卓设备上安卓所述引擎框架包。

根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本公开第一方面所述方法的步骤。

根据本公开的第四方面，提供一种电子设备，包括：

存储器，其上存储有计算机程序；

处理器，用于执行所述存储器中的所述计算机程序，以实现本公开第一方面所述方法的步骤。

通过上述技术方案，若接收到针对目标应用的调试指令，判断是否存在针对目标应用的更新信息，更新信息包括对目标应用的渲染逻辑和/或美术资源的更新内容，若确定存在更新信息，根据更新信息获得更新文件，并将更新文件发送至安卓设备的指定存储位置，控制安装于安卓设备的引擎框架包开始运行，以进行本次调试。其中，引擎框架包封装有目标应用所对应的渲染引擎的框架、且不包含渲染逻辑和美术资源，并且，引擎框架包在运行过程中从安卓设备的指定存储位置获取目标应用的渲染逻辑和美术资源。由此，将渲染引擎的框架与渲染逻辑、美术资源分离开来，将渲染引擎的框架单独封装为引擎框架包并安装于安卓设备上，在调试过程中，若渲染逻辑或美术资源存在更新，则将更新的内容推送至指定的存储位置，以供引擎框架包运行时通过该存储位置加载展示内容。这样，在应用调试过程中，若存在更新，仅需对指定存储位置的数据进行增量更新，更新机制更加灵活，并且，无需频繁打包、卸载、重装APK，省去了打包、卸载、重装APK所花费的时间，有利于提升调试效率，进而有利于提升应用的开发效率。

本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：

图1是根据本公开的一种实施方式提供的安卓系统的应用调试方法的流程图；

图2是根据本公开的另一种实施方式提供的安卓系统的应用调试方法的流程图；

图3是根据本公开的一种实施方式提供的安卓系统的应用调试装置的框图；

图4是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。

图1是根据本公开的一种实施方式提供的安卓系统的应用调试方法的流程图。本公开提供的方法可以应用于具有调试控制能力的设备，以利用本方法提供的一系列步骤对安卓系统的应用进行调试，本公开对该设备不做限定。如图1所示，该方法可以包括以下步骤：

在步骤11中，若接收到针对目标应用的调试指令，判断是否存在针对目标应用的更新信息；

在步骤12中，若确定存在更新信息，根据更新信息获得更新文件，并将更新文件发送至安卓设备的指定存储位置；

在步骤13中，控制安装于安卓设备的引擎框架包开始运行，以进行本次调试。

下面首先对渲染逻辑和美术资源进行解释说明。

渲染逻辑用于描述渲染内容的行为和加载时机，在渲染过程中，渲染引擎依据渲染逻辑将美术资源在合适的时机加载到页面的指定位置。示例地，渲染引擎可以为用户提供编辑器，用户可以在该编辑器内编辑渲染逻辑代码，以指定渲染内容的行为和加载时机。

美术资源为渲染出指定效果或页面所需要的资源，它包含有渲染逻辑元素所需要的模型、图像数据等，在渲染过程中，美术资源受渲染引擎的控制进行展示。示例地，美术资源可以为模型、图像、视频、音频等多媒体数据。

在步骤11中，若接收到针对目标应用的调试指令，判断是否存在针对目标应用的更新信息。

其中，更新信息包括对目标应用的渲染逻辑和/或美术资源的更新内容。如前文中给出的关于渲染逻辑和美术资源的说明，可知对目标应用的渲染逻辑为渲染逻辑代码，对目标应用的美术资源的更新内容为多媒体数据。

示例地，调试指令可以由用户操作触发，或者，可以在执行预先写好的调试脚本时触发。

若接收到针对目标应用的调试指令，说明当前触发了一次新的调试，为了保证此次调试能够展示应用的最新效果，在调试前，需要确认此次调试对渲染逻辑或美术资源是否存在更新。

示例地，如前文所述，渲染引擎提供的编辑器可以供用户编写渲染逻辑代码，因此，可以检测编辑器中的渲染逻辑代码是否存在更新，以判断是否存在针对目标应用的渲染逻辑的更新信息。

示例地，美术资源可以由用户更改，因此，可以通过检测到用户是否存在对美术资源的改动操作，以判断是否存在针对目标因共用的美术资源的更新信息。

在步骤12中，若确定存在更新信息，根据更新信息获得更新文件，并将更新文件发送至安卓设备的指定存储位置。

若确定存在更新信息，需要根据更新信息向安卓设备的指定存储位置同步更新内容，以使此次调试是针对最新更新内容所做的调试。

在一种可能的实施方式中，对目标应用的渲染逻辑的更新内容为渲染逻辑代码，相应地，步骤12可以包括以下步骤：

若更新信息中包括对目标应用的渲染逻辑的更新内容，对渲染逻辑代码进行编译，获得编译后的文件；

将编译后的文件发送至安卓设备中用于存储渲染逻辑的第一存储位置。

若更新信息中包括对目标应用的渲染逻辑的更新内容，说明渲染逻辑代码存在更新，而渲染逻辑代码经过编译后，才能够被安卓设备识别、读取。因此，可以对渲染逻辑代码进行编译，以获得编译后的文件。示例地，可以将渲染逻辑代码编译为支持运行时加载的动态链接库，其中，动态链接库可以使用指定的名称、路径等，便于渲染时能够被渲染引擎框架找到并正确加载。

在获得编译后的文件后，就可以将编译后的文件发送至安卓设备中用于存储渲染逻辑的第一存储位置，从而，使安卓设备中的第一存储位置能够存储最新的渲染逻辑。在渲染过程中，安卓设备上对应于目标设备的渲染引擎(即，引擎框架包)将从第一存储位置处获取渲染逻辑，用于加载。

在另一种可能的实施方式中，对目标应用的美术资源的更新内容为多媒体数据，相应地，步骤12可以包括以下步骤：

若更新信息中包括对目标应用的美术资源的更新内容，确定多媒体数据对应的第二存储位置；

将多媒体数据发送至第二存储位置。

若更新信息中包括对目标应用的美术资源的更新内容，说明美术资源存在更新，而由于展示类资源的美术资源通常较多，虽然存储在同一目录下，但是不同类的美术资源在目录中的位置可能存在区别，因此，需要确定多媒体数据对应的第二存储位置(即，在安卓设备中的存储位置)。美术资源在安卓设备中的存储位置是在编写代码时就规定好的，因此，多媒体数据对应的第二存储位置是可以直接获得的。

在确定第二存储位置后，就可以将多媒体数据发送至第二存储位置。这样，安卓设备中的第二存储位置能够存储最新的美术资源。在渲染过程中，安卓设备上对应于目标设备的渲染引擎(即，引擎框架包)将从第二存储位置处获取该多媒体数据，用于加载。

可选地，若在发送多媒体数据之前识别到第二存储位置存储有原始数据，可以利用多媒体数据替换原始数据，也就是利用多媒体数据覆盖掉原始数据。而若在发送多媒体数据之前第二存储位置并未存储有数据，则直接将多媒体数据存储即可。

需要说明的是，更新信息中可能涉及到不止一处美术资源的更新，可能涉及到多个多媒体数据，因而，针对每个多媒体数据，均可以执行上述步骤，以确定各个多媒体数据各自对应的第二存储位置，并完成数据发送。

在步骤13中，控制安装于安卓设备的引擎框架包开始运行，以进行本次调试。

其中，引擎框架包封装有目标应用所对应的渲染引擎的框架、且不包含渲染逻辑和美术资源，并且，引擎框架包在运行过程中从安卓设备的指定存储位置获取目标应用的渲染逻辑和美术资源。

在本公开提供的方法中，将渲染引擎的框架与渲染逻辑、美术资源相分离，将渲染引擎的框架封装为引擎框架包(不包含渲染逻辑和美术资源)，同时将渲染逻辑、美术资源存储于安卓设备的指定存储位置，例如，存储于安卓设备的SD(Secure Digital，安全数码)卡。

可选地，本公开可以通过如下方式实现引擎框架包在安卓设备上的安装：

将与目标应用所对应的渲染引擎的框架封装为引擎框架包；

将引擎框架包发送至安卓设备；

在安卓设备上安卓引擎框架包。

通常情况下，该步骤在针对目标应用的调试初始阶段完成。首先，将与目标应用所对应的渲染引擎的框架封装为引擎框架包，之后，将引擎框架包发送至安卓设备，而后，在安卓设备上安卓引擎框架包。引擎框架包中封装了渲染引擎的框架，在运行时，能够从安卓设备的指定存储位置获取目标应用的渲染逻辑和美术资源，用于加载。

由于引擎框架包仅封装了渲染引擎的基本渲染能力，而不包含其他的数据，无论目标应用做何种修改，引擎框架包都是不需要改动的，因此，仅需要安装一次，就可以应对后续的调试，在后续的调试过程中无需重复地卸载、安装。

也就是说，在步骤12之后，可以控制安装于安卓设备的引擎框架包开始运行，以进行本次调试。之后，调试人员可以根据本次的渲染结果得到验证结果，以完成本次调试。后续若有新的调试需求，可以重新执行本公开方法的一系列步骤。

可选地，若确定存在更新信息，在步骤13之前，本公开提供的方法还可以包括以下步骤：

确认更新文件已成功存储至安卓设备的指定存储位置。

也就是说，若存在更新信息，经由步骤12，更新文件会被发送至安卓设备的指定存储位置，文件发送与存储需要一定的时间，若更新文件未存储完毕就开启此次调试，本次调试将是无效的。因此，在步骤13之前，可以确认更新文件是否已成功存储至安卓设备的指定存储位置，在确认更新文件已成功存储至安卓设备的指定存储位置的秦光霞，再控制引擎框架包运行，以开始本次调试。

图2是根据本公开的另一种实施方式提供的安卓系统的应用调试方法的流程图。如图2所示，该方法可以包括以下步骤：

在步骤21中，若接收到针对目标应用的调试指令，判断是否存在针对目标应用的更新信息；

若确定存在更新信息，执行步骤22，若确定不存在更新信息，直接执行步骤24；

在步骤22中，根据更新信息获得更新文件，并将更新文件发送至安卓设备的指定存储位置；

在步骤23中，确认更新文件是否成功存储至安卓设备的指定存储位置；

若确认更新文件已成功存储至指定存储位置，执行步骤24；

在步骤24中，控制安装于安卓设备的引擎框架包开始运行，以进行本次调试。

也就是说，若确定不存在更新信息，直接控制引擎框架包开始运行，以进行本次调试。

其中，步骤21的说明可参见步骤11，确定存在更新信息情况下的处理流程可以参考前文的步骤12、步骤13等相关描述，此处不赘述。

通过上述技术方案，若接收到针对目标应用的调试指令，判断是否存在针对目标应用的更新信息，更新信息包括对目标应用的渲染逻辑和/或美术资源的更新内容，若确定存在更新信息，根据更新信息获得更新文件，并将更新文件发送至安卓设备的指定存储位置，控制安装于安卓设备的引擎框架包开始运行，以进行本次调试。其中，引擎框架包封装有目标应用所对应的渲染引擎的框架、且不包含渲染逻辑和美术资源，并且，引擎框架包在运行过程中从安卓设备的指定存储位置获取目标应用的渲染逻辑和美术资源。由此，将渲染引擎的框架与渲染逻辑、美术资源分离开来，将渲染引擎的框架单独封装为引擎框架包并安装于安卓设备上，在调试过程中，若渲染逻辑或美术资源存在更新，则将更新的内容推送至指定的存储位置，以供引擎框架包运行时通过该存储位置加载展示内容。这样，在应用调试过程中，若存在更新，仅需对指定存储位置的数据进行增量更新，更新机制更加灵活，并且，无需频繁打包、卸载、重装APK，省去了打包、卸载、重装APK所花费的时间，有利于提升调试效率，进而有利于提升应用的开发效率。

图3是根据本公开的一种实施方式提供的安卓系统的应用调试装置的框图。如图3所示，该装置30可以包括：

判断模块31，用于若接收到针对目标应用的调试指令，判断是否存在针对所述目标应用的更新信息，所述更新信息包括对所述目标应用的渲染逻辑和/或美术资源的更新内容；

更新模块32，用于若确定存在所述更新信息，根据所述更新信息获得更新文件，并将所述更新文件发送至安卓设备的指定存储位置；

第一控制模块33，用于控制安装于所述安卓设备的引擎框架包开始运行，以进行本次调试，其中，所述引擎框架包封装有所述目标应用所对应的渲染引擎的框架、且不包含渲染逻辑和美术资源，并且，所述引擎框架包在运行过程中从所述安卓设备的指定存储位置获取所述目标应用的渲染逻辑和美术资源。

可选地，对所述目标应用的渲染逻辑的更新内容为渲染逻辑代码；

所述更新模块32包括：

编译子模块，用于若所述更新信息中包括对所述目标应用的渲染逻辑的更新内容，对所述渲染逻辑代码进行编译，获得编译后的文件；

第一发送子模块，用于将所述编译后的文件发送至所述安卓设备中用于存储渲染逻辑的第一存储位置。

可选地，对所述目标应用的美术资源的更新内容为多媒体数据；

所述更新模块32包括：

确定子模块，用于若所述更新信息中包括对所述目标应用的美术资源的更新内容，确定所述多媒体数据对应的第二存储位置；

第二发送子模块，用于将所述多媒体数据发送至所述第二存储位置。

可选地，所述更新模块32还包括：

替换子模块，用于若在发送所述多媒体数据之前识别到所述第二存储位置存储有原始数据，利用所述多媒体数据替换所述原始数据。

可选地，所述装置30还包括：

确认模块，用于若确定存在所述更新信息，在所述第一控制模块控制安装于所述安卓设备的引擎框架包开始运行之前，确认所述更新文件已成功存储至所述安卓设备的指定存储位置。

可选地，所述装置30还包括：

第二控制模块，用于若确定不存在所述更新信息，直接控制所述引擎框架包开始运行，以进行本次调试。

可选地，所述装置30还包括：

封装模块，用于将与所述目标应用所对应的渲染引擎的框架封装为引擎框架包；

发送模块，用于将所述引擎框架包发送至所述安卓设备；

安装模块，用于在所述安卓设备上安卓所述引擎框架包。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图4是根据一示例性实施例示出的一种电子设备700的框图。如图4所示，该电子设备700可以包括：处理器701，存储器702。该电子设备700还可以包括多媒体组件703，输入/输出(I/O)接口704，以及通信组件705中的一者或多者。

其中，处理器701用于控制该电子设备700的整体操作，以完成上述的安卓系统的应用调试方法中的全部或部分步骤。存储器702用于存储各种类型的数据以支持在该电子设备700的操作，这些数据例如可以包括用于在该电子设备700上操作的任何应用程序或方法的指令，以及应用程序相关的数据，例如联系人数据、收发的消息、图片、音频、视频等等。该存储器702可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。多媒体组件703可以包括屏幕和音频组件。其中屏幕例如可以是触摸屏，音频组件用于输出和/或输入音频信号。例如，音频组件可以包括一个麦克风，麦克风用于接收外部音频信号。所接收的音频信号可以被进一步存储在存储器702或通过通信组件705发送。音频组件还包括至少一个扬声器，用于输出音频信号。I/O接口704为处理器701和其他接口模块之间提供接口，上述其他接口模块可以是键盘，鼠标，按钮等。这些按钮可以是虚拟按钮或者实体按钮。通信组件705用于该电子设备700与其他设备之间进行有线或无线通信。无线通信，例如Wi-Fi，蓝牙，近场通信(Near FieldCommunication，简称NFC)，2G、3G、4G、NB-IOT、eMTC、或其他5G等等，或它们中的一种或几种的组合，在此不做限定。因此相应的该通信组件705可以包括：Wi-Fi模块，蓝牙模块，NFC模块等等。

在一示例性实施例中，电子设备700可以被一个或多个应用专用集成电路(Application Specific Integrated Circuit，简称ASIC)、数字信号处理器(DigitalSignal Processor，简称DSP)、数字信号处理设备(Digital Signal Processing Device，简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述的安卓系统的应用调试方法。

在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的安卓系统的应用调试方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器702，上述程序指令可由电子设备700的处理器701执行以完成上述的安卓系统的应用调试方法。

以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。

此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。