JS代码调试方法、装置、终端及存储介质

技术领域

本申请属于计算机技术领域，尤其涉及JS代码调试方法、装置、终端及存储介质。

背景技术

JS(JavaScript)是一种直译式脚本语言，JS代码的翻译器被称为JS引擎，JS引擎用于解释和执行JS代码。在设计之初，JS主要用于web应用开发。

目前，JS被越来越多的应用到终端应用的开发中。例如，在终端应用中加载JS代码，通过终端内置的JS引擎解释和执行该JS代码，从而在终端应用中显示相应的页面，该页面可以认为是终端应用的一个项目，该页面可以为静态页面，如信息推送页面，也可以为动态页面，如游戏页面。也就是说，在终端应用未更新的情况下，通过向终端应用推送JS代码，使得终端应用具有更丰富的功能。

在基于JS开发项目后，需要对该项目进行调试，在调试通过后再进行发布。另外，在某个项目发布后，如果该项目出现问题，也需要对该项目进行调试。

目前针对终端应用的JS代码的调试过程为：获取终端应用的代码以及待调试的JS代码，利用IDE对终端应用的代码进行调试，同时利用浏览器(浏览器中集成有JS调试工具)对JS代码进行调试。其中，IDE是Integrated Development Environment的缩写，是一种用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面等工具。

可以看到，目前针对终端应用的JS代码的调试，无法脱离对终端应用的代码的调试。而在某些场景下，终端应用的代码是不易获得的，因此，目前针对终端应用的JS代码进行调试存在非常大的困难。

发明内容

有鉴于此，本申请的目的在于提供一种JS代码调试方法、装置、终端及存储介质，以实现在没有终端应用的代码的前提下，对终端应用的JS代码进行调试，使得针对终端应用的JS代码的调试更加方便、易用。

为实现上述目的，本申请提供如下技术方案：

本申请提供一种JS代码调试方法，应用于第一终端，所述方法包括：

运行应用，所述应用内置有调试器；

获得JS代码，由所述应用调用JS引擎运行所述JS代码；

接收第二终端发送的调试指令；

调用所述调试器，由所述调试器基于所述调试指令控制所述JS引擎运行所述JS代码的过程。

可选的，所述调试指令包括状态控制指令；

所述由所述调试器基于所述调试指令控制所述JS引擎运行所述JS代码的过程，包括：由所述调试器基于所述状态控制指令控制所述JS引擎运行所述JS代码的状态。

可选的，所述调试指令还包括信息获取指令；

所述由所述调试器基于所述调试指令控制所述JS引擎运行所述JS代码的过程，还包括：由所述调试器基于所述信息获取指令控制所述JS引擎读取所述JS代码的运行信息；

所述方法还包括：获取所述JS引擎读取的运行信息，向所述第二终端发送所述运行信息，以便所述第二终端显示所述运行信息。

本申请还提供一种JS代码调试方法，所述方法应用于第二终端，所述方法包括：

接收输入操作，生成调试指令；

向第一终端发送所述调试指令，以便所述第一终端的应用中内置的调试器基于所述调试指令控制JS引擎运行JS代码的过程。

可选的，所述调试指令包括状态控制指令，所述状态控制指令用于：触发所述调试器控制所述JS引擎运行所述JS代码的状态。

可选的，所述调试指令还包括信息获取指令，所述信息获取指令用于：触发所述调试器控制所述JS引擎读取所述JS代码的运行信息；

所述方法还包括：显示所述第一终端发送的运行信息。

本申请还提供一种JS代码调试装置，应用于第一终端，所述装置包括：

应用运行单元，用于运行应用，所述应用内置有调试器；

引擎调用单元，用于获得JS代码，由所述应用调用JS引擎运行所述JS代码；

指令接收单元，用于接收第二终端发送的调试指令；

控制单元，用于调用所述调试器，由所述调试器基于所述调试指令控制所述JS引擎运行所述JS代码的过程。

可选的，在所述调试指令为信息获取指令时，所述控制单元用于：调用所述调试器，由所述调试器基于所述信息获取指令控制所述JS引擎读取所述JS代码的运行信息；

所述装置还包括：运行信息发送单元，用于获取所述JS引擎读取的运行信息，向所述第二终端发送所述运行信息，以便所述第二终端显示所述运行信息。

本申请还提供一种JS代码调试装置，应用于第二终端，所述装置包括：

指令生成单元，用于接收输入操作，生成调试指令；

指令发送单元，用于向第一终端发送所述调试指令，以便所述第一终端的应用中内置的调试器基于所述调试指令控制JS引擎运行JS代码的过程。

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

运行信息接收单元，用于接收所述第一终端发送的运行信息；

显示单元，用于显示所述运行信息。

本申请还提供一种终端，包括：处理器、存储器和通信接口；

其中，所述处理器用于执行所述存储器中存储的程序；

所述存储器用于存储程序，所述程序至少用于：运行应用，所述应用内置有调试器；获得JS代码，由所述应用调用JS引擎运行所述JS代码；接收第二终端发送的调试指令；调用所述调试器，由所述调试器基于所述调试指令控制所述JS引擎运行所述JS代码的过程。

本申请还提供一种终端，包括：处理器、存储器、输入单元和通信接口；

其中，所述处理器用于执行所述存储器中存储的程序；

所述存储器用于存储程序，所述程序至少用于：接收输入操作，生成调试指令；向第一终端发送所述调试指令，以便所述第一终端的应用中内置的调试器基于所述调试指令控制JS引擎运行JS代码的过程。

本申请还提供一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现上述任意一种JS代码调试方法。

由此可见，本申请的有益效果为：

本申请公开的方案中，在第一终端的应用中内置有调试器，该调试器可以基于调试指令控制JS引擎运行该应用的JS代码的过程，这使得对终端应用的JS代码的调试不再依赖于浏览器，从而使得对终端应用的JS代码的调试不再因为浏览器的适配问题而受限于调试平台。而且，第一终端在本机运行应用的过程中，利用该应用内置的调试器控制JS引擎运行该应用的JS代码的过程，在无需该应用的代码的前提下，实现对该应用的JS代码的调试。基于以上，本申请提供的方案使得针对终端应用的JS代码的调试更加方便、易用。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请公开的JS代码调试系统的一种组成架构示意图；

图2为本申请公开的JS代码调试系统的另一种组成架构示意图；

图3为本申请公开的JS代码调试方法的一个实施例的流程图；

图4为JavaScriptCore引擎的调试类和封装类的原理示意图；

图5为本申请公开的调试器包含的类的原理示意图；

图6为本申请公开的第二终端中VS Code插件的原理示意图；

图7-1至图7-3为本申请公开的第二终端中UI界面的示意图；

图8为本申请公开的调试插件的核心类包含的数据类型的原理示意图；

图9为本申请公开的JS代码调试方法的另一个实施例的流程图；

图10为本申请公开的一种JS代码调试装置的结构示意图；

图11为本申请公开的另一种JS代码调试装置的结构示意图；

图12为本申请公开的一种终端的硬件结构图；

图13为本申请公开的另一种终端的硬件结构图。

具体实施方式

目前针对终端应用的JS代码的调试严重依赖于终端应用的代码。而终端应用的开发和终端应用中的项目的开发，往往是跨部门，甚至是跨公司的，而且基于代码安全性的考虑，会对终端应用的代码的获取进行限制，这导致终端应用的代码很难获得。这导致目前针对终端应用的JS代码的调试存在很大的难度。

而且，目前主流的JS引擎包括苹果生态下的JavaScriptCore引擎、安卓生态下的V8、以及Mozilla生态下的SpiderMonkey。在对终端应用的JS代码进行调试时，需要使用相应的浏览器。例如，在对使用JavaScriptCore作为引擎的JS代码进行调试时，必须使用苹果生态下的Safari浏览器。而Safari浏览器只能安装于使用iOS或者macOS操作系统的终端，因此，针对使用JavaScriptCore作为引擎的JS代码，只能通过使用iOS或者macOS操作系统的终端进行调试，调试平台受到很大的限制。

因此，申请人提出一种JS代码调试方法、装置、终端及存储介质，以实现在没有终端应用的代码的前提下，对终端应用的JS代码进行调试，并且针对终端应用的JS代码的调试也不再依赖于浏览器，使得针对终端应用的JS代码的调试更加方便、易用。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了便于理解，先对本申请的方案所适用的系统的组成架构进行介绍。

请参见图1，图1为本申请公开的JS代码调试系统的一种组成架构示意图。

由图1可知，JS代码调试系统包括第一终端100和第二终端200。

其中，第一终端100和第二终端200之间采用点对点的方式连接。

实施中，可以采用USB线连接第一终端100和第二终端200。另外，如果第一终端100和第二终端200均包含近距离通讯模块，那么第一终端100和第二终端200可以通过近距离通讯模块建立连接。例如，第一终端100和第二终端200通过蓝牙模块建立连接。

第一终端100可以为手机、平板电脑等移动设备，也可以为个人计算机等固定设备。第二终端200可以为个人计算机等固定设备，也可以为手机、平板电脑等移动设备。

第二终端200用于接收输入操作，基于输入操作生成相应的调试指令，并向第一终端100发送调试指令。

第一终端100安装有应用，并且该应用中内置有调试器。其中，该应用可以为购物类应用、资讯类应用、通讯类应用、视频类应用。应用中的调试器具有以下功能：解析调式指令，基于调试指令控制JS引擎运行JS代码的过程。

第一终端100运行该应用，获得待调试的JS代码，由该应用调用JS引擎运行JS代码，第一终端100在接收到第二终端200发送的调试指令时，调用应用内置的调试器，由调试器基于调试指令对JS引擎运行JS代码的过程进行控制。

其中，调试器可以对JS引擎运行JS代码的状态进行控制，如控制JS引擎在运行指定的JS代码后暂停运行，控制JS引擎恢复运行JS代码，控制JS引擎运行指定的JS代码。调试器还可以控制JS引擎读取JS代码的运行信息。

实施中，第二终端200向第一终端100发送的调试指令包括状态控制指令。第一终端100在接收到第二终端200发送的状态控制指令时，由应用内置的调试器基于该状态控制指令控制JS引擎运行JS代码的状态。

另外，第二终端200向第一终端100发送的调试指令还包括信息获取指令。第一终端100在接收到第二终端200发送的信息获取指令时，由应用内置的调试器控制JS引擎读取JS代码的运行信息。并且，第一终端100还获取JS引擎读取的运行信息，向第二终端200发送运行信息。由第二终端200显示接收到的运行信息，以便用户直观地了解终端应用的JS代码的调试过程。

请参见图2，图2为本申请公开的JS代码调试系统的另一种组成架构示意图。

由图2可知，JS代码调试系统包括第一终端100、第二终端200和中继设备300。

与图1所示的JS代码调试系统相比，第一终端100和第二终端200通过中继设备300建立连接，也就是说，中继设备300在第一终端100和第二终端200之间进行数据转发。

实施中，中继设备300可以为路由器，也可以为服务器或者服务器集群。

具体的，中继设备300接收第二终端200发送的调试指令，并将调试指令向第一终端100发送。另外，中继设备300还用于接收第一终端100发送的信息，并将该信息向第二终端200发送。

需要说明的是，在图1和图2所示的JS代码调试系统中，第二终端200生成调试指令后，需要按照预先定义的规则对调试指令进行封装，以便第一终端100能够正确理解调试指令。同样的，第一终端100生成需要反馈至第二终端200的信息后，需要按照预先定义的规则对信息进行封装，以便第二终端200能够正确的获取信息。例如，采用Java调试协议(JDWP)对调试指令和信息进行封装，所有命令前4个字节为数据长度，之后的字节为具体的数据内容，数据的格式为JSON。

另外，在第一终端100和第二终端200通过中继设备300进行通讯的场景中，第二终端200在按照预先定义的规则对调试指令进行封装后，还需要根据第二终端200与中继设备300之间的通讯协议再次进行封装；第一终端100在按照预先定义的规则对待发送的信息进行封装后，还需要根据第一终端100与中继设备300之间的通讯协议再次进行封装，从而保证顺利的数据传输。

可以看到，本申请公开的方案中，在第一终端的应用中内置有调试器，该调试器可以基于第二终端生成的调试指令控制JS引擎运行该应用的JS代码的过程，这使得对终端应用的JS代码的调试不再依赖于浏览器，从而使得对终端应用的JS代码的调试不再因为浏览器的适配问题而受限于调试平台。而且，第一终端在本机运行应用的过程中，利用该应用内置的调试器控制JS引擎运行该应用的JS代码的过程，在无需该应用的代码的前提下，实现对该应用的JS代码的调试。基于以上，本申请提供的方案使得针对终端应用的JS代码的调试更加方便、易用。

为了更好的理解本方案，下面结合图1所示的系统架构进行介绍。

参见图3，图3为本申请公开的JS代码调试方法的一个实施例的流程图。该方法包括：

步骤S301：第一终端运行应用。

其中，应用内置有调试器。该调试器用于：解析调试指令，基于调试指令控制JS引擎运行JS代码的过程。

步骤S302：第一终端获得JS代码，由该应用调用JS引擎运行JS代码。

步骤S303：第二终端接收输入操作，生成调试指令。

作为一种实施方式，第二终端显示UI界面(用户界面)，该UI界面显示有多种控件，用户通过点击控件触发第二终端生成相应的调试指令，如图7-1所示。另外，第二终端还可以在该UI界面中显示JS代码。

步骤S304：第二终端向第一终端发送调试指令。

步骤S305：第一终端调用调试器，由调试器基于该调试指令控制JS引擎运行JS代码的过程。也就是，由调试器基于该调试指令对JS引擎运行JS代码的过程进行控制。

其中，第二终端生成的调试指令包括状态控制指令和信息获取指令。

第一终端接收到状态控制指令时，步骤S305具体为，由调试器基于状态控制指令控制JS引擎运行JS代码的状态。

实施中，状态控制指令包括但不限于：Enable(开启)、Disable(关闭)、SetBreakpoint(设置断点)、RemoveBreakpoint(移除断点)、Resume(恢复，即执行至断点停止后的恢复)、SetpOver(单步跳过)、StepOut(单步跳出)和StepInto(单步跳入)。

第一终端接收到信息获取指令时，步骤S305具体为，由调试器基于信息获取指令控制JS引擎读取JS代码的运行信息。之后，第一终端获取JS引擎读取的运行信息，并向第二终端发送。由第二终端显示接收到的运行信息。

实施中，信息获取指令包括但不限于：GetProperties(获取变量信息)。也就是说，上述的运行信息包括但不限于变量信息。

第一终端接收到设置断点指令后，调用调试器，由调试器控制JS引擎，当JS代码运行至该断点时，JS引擎暂停JS代码的运行。在JS代码暂停运行后，第一终端向第二终端发送暂停通知，该暂停通知携带有此刻的栈帧信息。第二终端接收到暂停通知后，根据该栈帧信息生成GetProperties指令，并向第一终端发送GetProperties指令。第一终端的应用内置的调试器基于该GetProperties指令，控制JS引擎获取此刻的变量信息，并向第一终端发送该变量信息。由第二终端展示接收到的变量信息，另外，第二终端还可以显示栈帧信息，使得用户能够直观地了解终端应用的JS代码的调试情况。第二终端的UI界面显示的变量信息如图7-2所示，第二终端的UI界面显示的栈帧信息如图7-3所示。

另外，在JS代码暂停运行后，可以通过第二终端向第一终端发送单步运行指令，即上文中的SetpOver、StepOut和StepIn，从而由调试器控制JS引擎按照相应的规则执行JS代码。

下面对应用中的调试器进行更加详细的说明。

本申请中的调试器基于JS引擎提供的调试类和封装类实现。

以JavaScriptCore引擎为例：JavaScriptCore引擎提供的调式类包括JSC::Debugger类，封装类包括Inspector::ScriptDebugServer类，原理如图4所示。

JSC::Debugger类为调试类，其提供的调试接口主要用于：连接/断开(attach/detach)调试器、在JS代码中设置断点、通过Continue/StepOver/StepInto等指令对在断点暂停运行的JS代码进行控制，以及当断点触发后将相应的接口方法回调给子类。

Inspector::ScriptDebugServer类继承自JSC::Debugger，实现了JSC::Debugger交给子类去实现的方法，并采取注册Listener的形式将这些方法重新分发(dispatch)出去，提供给开发者更便捷友好的接口。

基于JavaScriptCore引擎提供的调试类和封装类实现的调试器，主要包括三个类：JSDebuggerImpl类、JsDebuggerWrapper类、debugserver类。调试器的原理如图5所示。

其中：

1、JSDebuggerImpl类同时继承自Inspector::ScriptDebugServer类和Inspector::ScriptDebugListener类，除了重写方法外，对外暴露Attach()和Detach()接口，并注册到服务(Server)中。JSDebuggerImpl类维护一个JSGlobalObject对象，在调试器的sourceParsed()函数中就是用它获取sourceProvider。

JSDebuggerImpl类维护一个JSDebuggerImplHandler对象，通过它将OnBreakpointHit()和OnException()事件通知出去。而JSDebuggerImplHandler的实现类就是JsDebuggerWrapper。

2、JsDebuggerWrapper类负责封装和事件分发。

具体的，JsDebuggerWrapper类对JSDebuggerImpl类进行封装。JsDebuggerWrapper类实现了JSDebuggerImplHandler接口，并将接口的回调通过JsDebuggerWrapperCallback向外分发。JsDebuggerWrapperCallback是由debugserver类创建出来的。

3、debugserver类负责和第二终端进行通信。

具体的，debugserver类封装了JsDebuggerWrapper类。debugserver类创建JsDebuggerWrapperCallback监听来自JSDebuggerImpl类的通知，并进行相应的逻辑处理。

与第二终端的通信主要包括两方面的工作：一是接收来自第二终端的调试指令。如StepOver指令，该指令将通过JsDebuggerWrapper->JSDebuggerImpl->JSC::Debugger进行传递并处理。二是接收来自JSC::Debugger的事件，如breakpointHit断点触发事件，debugserver会将相应的栈帧信息、变量信息发送给第二终端进行显示。

实施中，可以在第二终端200中设置Visual Studio Code插件，通过VisualStudio Code插件实现调试指令的生成，以及运行信息的显示。

Visual Studio Code简称为VS Code，是一个同时支持windows操作系统、Linux操作系统和macOC操作系统的代码编辑器。VS Code插件主要包括两个部分：UI界面和调试插件核心类JS-Debug，如图6所示。

其中，UI界面显示有多个控件，如图7-1所示，按照从左到右的顺序，第一个控件用于生成Continue指令，第二个控件用于生成StepOver指令，第三个控件用于生成StepInto指令，第四个控件用于生成StepOut指令，第五个控件用于生成Restart指令，第六个控件用于生成Stop指令。当用户点击控件时，第二终端生成相应的调试指令，并向第一终端发送。

第二终端每次发出StepOver指令、StepInto指令、StepOut指令之后，第一终端的JS引擎执行相应JS代码后都会暂停，并向第二终端发送携带有此刻的栈帧信息的暂停通知，第二终端接收到暂停通知后，根据暂停通知携带的栈帧信息生成GetProperties指令，向第一终端发送，以使得第一终端反馈此刻的变量信息。

例如，用户点击UI界面上的第二个控件，那么第二终端生成相应的StepOver指令，并向第一终端发送。第一终端的应用内置的调试器控制JS引擎执行某一行JS代码，然后停止在下一行。此时，调试器向第二终端发送暂停通知，该暂停通知用于指示JS引擎已暂停运行JS代码，并且该暂停通知还携带有此刻的栈帧信息(frame)。第二终端接收到暂停通知后，根据接收到的栈帧信息生成GetProperties指令，并向第一终端发送。第一终端的应用内置的调试器基于GetProperties指令，控制JS引擎获取此刻的变量信息，并向第一终端发送该变量信息。

另外，UI界面还可以显示代码行号，用户点击代码行号时，第二终端生成设置断点指令并向第一终端发送，断点的位置为被点击的代码行号，当用户再次点击该代码行号时，第二终端生成移除断点指令并向第一终端发送。

调试插件的核心类JS-Debug主要是遵循DAP(Debug Adapter Protocol，调试适配协议)进行开发实现，可支持Launch和Attach两种调试模式。调试插件的核心类JS-Debug主要定义了三种数据类型：ProtocolMessage、Arguments和Model，如图8所示。

ProtocolMessage定义了一个请求-回包(Request-Response)体系，用于实现两个功能：一是，UI界面需要什么数据，就会发送具体的调试请求Request给JS-Debug，并附带参数Arguments；二是，JS-Debug收到Request后向第一终端获取相应数据并返回Response，回复给UI界面进行展示。

Arguments表示参数类型，不同的调试请求Request需要不同的参数传入，它们统一以“XXXArguments”命名。

Model是基于VS Code提供的调试model的封装，属于自定义数据，比如：栈帧StackFrame，断点BreakPoint，变量Variable。

这里对Launch和Attach这两种调试模式进行说明：

Launch模式是主动模式。第二终端将待调试的JS代码向第一终端发送。这种调试模式主要适用于终端应用的JS代码处于开发阶段的调试。

Attach模式是被动模式。第一终端将待调试的JS代码向第二终端发送。这种调试模式主要适用于终端应用的JS代码的故障检测，也就是说，在发布终端应用的JS代码后，当发现JS代码有问题时，为了定位故障并进行故障排查针对JS代码进行调试。

为了便于理解本申请公开的方案，下面结合本申请所适用的一个应用场景进行介绍。

参见图9，图9示出了本申请公开的JS代码调试方法在一种应用场景中的流程图。其中，第一终端100和第二终端200通过USB线连接。

步骤S901：第二终端获得待调试的JS代码。其中，该JS代码用于在第一应用的界面中显示一个游戏页面，其中，该第一应用为通讯类应用，如手机QQ。

步骤S902：第二终端将待调试的JS代码向第一终端发送。其中，第一终端安装有第一应用，并且在第一应用中内置有调试器。

步骤S903：第二终端的交互界面接收用户的第一输入操作，生成enable指令。

步骤S904：第二终端向第一终端发送enable指令。

步骤S905：第一终端响应enable指令，运行第一应用，由第一应用调用JS引擎运行JS代码。

步骤S906：第二终端的交互界面接收用户的第二输入操作，生成SetBreakpoint指令。SetBreakpoint指令包含断点位置，断点位置为JS代码的代码行号。

其中，第二终端的交互界面可以显示多个控件，在交互界面的交互操作为点击控件的操作。当用户点击交互界面的控件时，第二终端生成相应的调试指令。

步骤S907：第二终端向第一终端发送SetBreakpoint指令。

步骤S908：第一终端的第一应用内置的调试器基于SetBreakpoint指令控制JS引擎，将JS代码运行至断点位置时暂停运行。

步骤S909：第一终端向第二终端发送暂停通知，该暂停通知携带有此刻的栈帧信息。

步骤S910：第二终端基于暂停通知携带的栈帧信息，生成GetProperties指令。

步骤S911：第二终端向第一终端发送GetProperties指令。

步骤S912：调试器基于GetProperties指令，控制JS引擎读取当前的变量信息。

步骤S913：第一终端向第二终端发送变量信息。

步骤S914：第二终端的交互界面显示栈帧信息和变量信息。

之后，用户可以在第二终端执行操作，以使得第二终端生成Continue指令，并将Continue指令向第一终端发送。第一终端的第一应用内置的调试器基于该Continue指令指令，控制JS引擎恢复JS代码的运行。

另一方面，本申请还提供一种JS代码调试装置，该装置应用于第一终端。请参见图10，图10为本申请公开的一种JS代码调试装置的结构示意图。该装置包括：

应用运行单元101，用于运行应用，该应用内置有调试器；

引擎调用单元102，用于获得JS代码，由该应用调用JS引擎运行JS代码；

指令接收单元103，用于接收第二终端发送的调试指令；

控制单元104，用于调用调试器，由调试器基于该调试指令控制JS引擎运行JS代码的过程。

可选的，在调试指令为状态控制指令时，控制单元104用于：调用调试器，由调试器基于状态控制指令对JS引擎运行JS代码的状态进行控制。

可选的，在调试指令为信息获取指令时，控制单元104用于：调用调试器，由调试器基于信息获取指令控制JS引擎读取JS代码的运行信息。相应的，该装置还包括：运行信息发送单元，用于获取JS引擎读取的运行信息，向第二终端发送该运行信息，以便第二终端显示该运行信息。

另一方面，本申请还提供一种JS代码调试装置，该装置应用于第二终端。请参见图11，图11为本申请公开的一种JS代码调试装置的结构示意图。该装置包括：

指令生成单元201，用于接收输入操作，生成调试指令；

指令发送单元202，用于向第一终端发送该调试指令，以便第一终端的应用中内置的调试器基于该调试指令控制JS引擎运行JS代码的过程。

可选的，该装置还包括：运行信息接收单元，用于接收第一终端发送的运行信息；显示单元，用于显示该运行信息。

另一方面，本申请还提供一种终端，该终端的硬件结构如图12所示，该终端100可以包括处理器1201、存储器1202和通信接口1203。

可选的，该终端还可以包括输入单元1204、显示器1205和通信总线1206。

处理器1201、存储器1202、通信接口1203、输入单元1204、显示器1205、均通过通信总线1206完成相互间的通信。

在本申请实施例中，该处理器1201可以为中央处理器(Central ProcessingUnit，CPU)，特定应用集成电路，数字信号处理器、现成可编程门阵列或者其他可编程逻辑器件等。

该处理器1201可以调用存储器1202中存储的程序。

存储器1202中用于存放一个或者一个以上程序，程序可以包括程序代码，该程序代码包括计算机操作指令，在本申请实施例中，该存储器1202中至少存储有用于实现以下功能的程序：

运行应用，该应用内置有调试器；获得JS代码，由该应用调用JS引擎运行JS代码；接收第二终端发送的调试指令；调用调试器，由调试器基于调试指令控制JS引擎运行JS代码的过程。

在一种可能的实现方式中，该存储器1202可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、以及至少一个功能(比如图像播放功能等)所需的应用程序等；存储数据区可存储根据计算机的使用过程中所创建的数据，比如，用户数据及图像数据等等。

此外，存储器1202可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

该通信接口1203可以为通信模块的接口，如蓝牙模块的接口、USB接口、GSM模块的接口。

当然，图12所示的终端的结构并不构成对本申请实施例中终端的限定，在实际应用中终端可以包括比图12所示的更多或更少的部件，或者组合某些部件。

另一方面，本申请还提供一种终端，该终端的硬件结构如图13所示，该终端200可以包括处理器1301、存储器1302、通信接口1303和输入单元1304。

可选的，该终端还可以包括显示器1305和通信总线1306。

处理器1301、存储器1302、通信接口1303、输入单元1304、显示器1305、均通过通信总线1306完成相互间的通信。

在本申请实施例中，该处理器1301可以为中央处理器(Central ProcessingUnit，CPU)，特定应用集成电路，数字信号处理器、现成可编程门阵列或者其他可编程逻辑器件等。

该处理器1301可以调用存储器1302中存储的程序。

存储器1302中用于存放一个或者一个以上程序，程序可以包括程序代码，该程序代码包括计算机操作指令，在本申请实施例中，该存储器1302中至少存储有用于实现以下功能的程序：

接收输入操作，生成调试指令；向第一终端发送该调试指令，以便第一终端的应用中内置的调试器基于该调试指令控制JS引擎运行JS代码的过程。

在一种可能的实现方式中，该存储器1302可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、以及至少一个功能(比如图像播放功能等)所需的应用程序等；存储数据区可存储根据计算机的使用过程中所创建的数据，比如，用户数据及图像数据等等。

此外，存储器1302可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

该通信接口1303可以为通信模块的接口，如蓝牙模块的接口、USB接口、GSM模块的接口。

当然，图13所示的终端的结构并不构成对本申请实施例中终端的限定，在实际应用中终端可以包括比图13所示的更多或更少的部件，或者组合某些部件。

另一方面，本申请还提供一种存储介质，该存储介质中存储有计算机可执行指令，其中，计算机可执行指令被处理器加载并执行时，实现以上任意一个实施例所描述的JS代码调试方法。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。