CN113626330A - Mixed-mode mobile application debugging method and system - Google Patents
Mixed-mode mobile application debugging method and system Download PDFInfo
- Publication number
- CN113626330A CN113626330A CN202110919390.2A CN202110919390A CN113626330A CN 113626330 A CN113626330 A CN 113626330A CN 202110919390 A CN202110919390 A CN 202110919390A CN 113626330 A CN113626330 A CN 113626330A
- Authority
- CN
- China
- Prior art keywords
- debugging
- websocket
- mixed
- page
- mobile application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
An embodiment of the present application provides a mixed-mode mobile application debugging system, including: the desktop client is used for uploading page codes of the mixed mode mobile application to be debugged to the node server; the node server is used for deploying the received page code into a static resource service and returning the network address of the static resource service to the desktop client; the device to be debugged is used for acquiring the network address from the desktop client, and acquiring and loading the page code from the static resource service according to the network address so as to open a page to be debugged; the desktop client is also used for opening the desktop mode adjusting window; and the desktop debugging window is used for loading a debugging tool installed in the debugging equipment to debug the page to be debugged.
Description
Technical Field
The embodiment of the application relates to the technical field of computers, in particular to a mixed-mode mobile application debugging method and system.
Background
Mixed mode mobile applications have emerged due to the needs of the market and the updating of computer application technology. The mixed mode mobile application is a mixed mode mobile application between a Native App (Native App) and a Web App (Web App). After the mixed-mode mobile application is developed, in order to find out problems existing in the development process, the mixed-mode mobile application needs to be debugged remotely. However, the inventor finds that the mixed-mode mobile application between different mobile phones and different Android versions has the problem of difference between compatibility and Native functions, and the effect of a real environment cannot be completely simulated in a PC environment, so that various compatibility problems occur on line, and user experience is influenced. In order to solve the above problems, in the prior art, it is currently desired to perform complete front-end function debugging through Chrome Devtools like Web page development, and it is necessary to use multiple technical means, such as Charles proxy, USB hardware device connection, etc., which is high in cost and complexity.
Disclosure of Invention
The embodiment of the application aims to provide a mixed-mode mobile application debugging system to solve the problems that the cost is high and the complexity of the system is high due to the fact that a plurality of technical means are needed when debugging is conducted in the prior art.
One aspect of an embodiment of the present application provides a mixed-mode mobile application debugging system, where the mixed-mode mobile application debugging system includes a debugging device, a node server, and a device to be debugged, and a desktop debugging window and a desktop client are installed in the debugging device, where:
the desktop client is used for uploading page codes of the mixed mode mobile application to be debugged to the node server;
the node server is used for deploying the received page code into a static resource service and returning the network address of the static resource service to the desktop client;
the device to be debugged is used for acquiring the network address from the desktop client, and acquiring and loading the page code from the static resource service according to the network address so as to open a page to be debugged;
the desktop client is also used for opening the desktop mode adjusting window;
and the desktop debugging window is used for loading a debugging tool installed in the debugging equipment to debug the page to be debugged.
Optionally, the desktop client is an Electron desktop client, wherein:
the Electron desktop client is used for creating a WebSocket client and a WebSocket server and establishing a first WebSocket long connection with the node server through the WebSocket client;
the Electron desktop client is further used for uploading page codes of the mixed-mode mobile application to be debugged to the node server;
the Electron desktop client is further used for establishing a second WebSocket long connection with the mode adjusting tool through the WebSocket server;
the Electron desktop client is further used for opening the desktop debugging window through the WebSocket client;
the node server is further configured to deploy the received page code to a static resource service, and return the network address of the static resource service to the Electron desktop client.
Optionally, the device to be debugged is an android device installed with the mixed-mode mobile application, and the debugging tool is a Chrome developers front debugging tool, where:
the Electron desktop client is also used for generating a corresponding identification code according to the network address;
the mixed-mode mobile application is used for scanning the identification code, acquiring and loading the page code from the static resource service according to the network address identified from the identification code, and opening the page to be debugged;
the mixed-mode mobile application is also used for starting a Webview debugging mode so that the android device calls a chrome kernel to create a Unix Domain Socket server;
the mixed-mode mobile application is also used for establishing a third WebSocket long connection with the Unix Domain Socket server side and establishing a fourth WebSocket long connection with the node server;
the Chrome Dethols fronted debugging tool is used for sending a debugging request to the WebSocket server through the second WebSocket long connection, so that the WebSocket server sends the debugging request to the Unix Domain Socket server sequentially through the WebSocket client, the channel of the first WebSocket long connection, the channel of the fourth WebSocket long connection and the channel of the third WebSocket long connection, and the debugging request is debugged on the page to be debugged.
Optionally, the mixed-mode mobile application is further configured to send, after establishing a fourth WebSocket long connection with the node server, a signal that a page debugging channel of the page to be debugged is opened to the node server through the fourth WebSocket long connection;
the node server is further configured to send the signal to the WebSocket client through the first WebSocket long connection after receiving the signal, so that the WebSocket client opens the desktop debugging window after receiving the signal.
Optionally, the Electron desktop client is further configured to request the node server to obtain session credential information;
and the node server is used for generating session credential information when receiving a session credential information acquisition request sent by the Electron desktop client, and sending the session credential information to the Electron desktop client, so that the WebSocket client establishes a first WebSocket long connection with the node server according to the session credential information.
Optionally, the node server is further configured to create a directory named by the session credential information in the static resource service after the session credential information is generated.
Optionally, the Electron desktop client is further configured to package the page code, and upload a file package obtained after the package to the node server;
and the node server is also used for decompressing the file packet and deploying the decompressed page code to a directory named by the session credential information in the static resource service.
Optionally, the Unix Domain Socket server has corresponding process identification information, and the mixed-mode mobile application is further configured to obtain process identification information of a plurality of processes currently started in the terminal device, and search the Unix Domain Socket server according to each process identification information;
the mixed-mode mobile application is further configured to initiate a handshake request to the Unix Domain Socket server, and send a protocol upgrading instruction to the Unix Domain Socket server after the handshake is successful, so as to upgrade the current communication protocol to a WebSocket protocol.
Optionally, the Electron desktop client is further configured to splice the session credential information with the network address, and generate a corresponding identification code according to character information obtained after splicing;
and the mixed-mode mobile application is also used for establishing the fourth WebSocket long connection with the node server according to the session credential information identified from the identification code.
Optionally, the Chrome devtols fronted debugging tool is further configured to obtain address information of the WebSocket server from the WebSocket client, and establish the second WebSocket long connection with the WebSocket server according to the address information.
Optionally, the Chrome Devtools fronted debugging tool is further configured to send a debugging information acquisition request of the Hybrid page to be debugged to the WebSocket server through the second WebSocket long connection, so that the WebSocket server sends the debugging information acquisition request to the Unix Domain Socket server sequentially through the WebSocket client, the channel of the first WebSocket long connection, the channel of the fourth WebSocket long connection, and the channel of the third WebSocket long connection, so as to achieve acquisition of the debugging information of the page to be debugged from the Unix Domain Socket server.
The application also provides a mixed-mode mobile application debugging method, which is applied to a debugging system comprising debugging equipment, a node server and equipment to be debugged, wherein a desktop debugging window and a desktop client are installed in the debugging equipment, and the method comprises the following steps:
uploading a page code of the mixed mode mobile application to be debugged to the node server through the desktop client;
deploying the received page code into a static resource service through the node server, and returning a network address of the static resource service to the desktop client;
acquiring the network address from the desktop client through the device to be debugged, and acquiring and loading the page code from the static resource service according to the network address to open a page to be debugged;
opening the desktop mode adjusting window through the desktop client;
and loading a debugging tool installed in the debugging equipment through the desktop debugging window to debug the page to be debugged.
The mixed-mode mobile application debugging system provided by the embodiment of the application can enable front-end developers to use Chrome devices front debugging tools to directly carry out remote debugging on Android pages on Android4.4 and various Android real machines, obtain debugging effects similar to debugging of PC pages by Chrome built-in developer tools, and does not need to use Charles agents, USB hardware equipment connection and the like, so that the cost and the complexity can be reduced.
Drawings
FIG. 1 schematically illustrates an application environment diagram of a mixed-mode mobile application debugging system;
FIG. 2 schematically illustrates a block diagram of a mixed-mode mobile application debugging system according to an embodiment of the present application;
fig. 3 schematically shows a flowchart of a mixed-mode mobile application debugging method according to an embodiment of the present application.
Detailed Description
The advantages of the present application are further illustrated below with reference to the accompanying drawings and specific embodiments.
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.
The terminology used in the present disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present disclosure. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
In the description of the present application, it should be understood that the numerical references before the steps do not identify the order of performing the steps, but merely serve to facilitate the description of the present application and to distinguish each step, and therefore should not be construed as limiting the present application.
Fig. 1 schematically illustrates an application environment diagram of a mixed-mode mobile application debugging system according to an embodiment of the present application. In an exemplary embodiment, the system of the application environment may include a terminal device 10, a device 20 that installs a mixed-mode mobile application to be debugged, and a server 30. The terminal device 10, the device 20 installed with the mixed-mode mobile application to be debugged, and the server 30 form a wireless or wired connection therebetween. The terminal device 10 may be a tablet computer, a computer, etc., and is not limited herein. The device 20 on which the mixed-mode mobile application to be debugged is installed may be an android handset, an android tablet, or an iOS simulator, for example. The server 30 may be a server or a server cluster composed of a plurality of servers, or a cloud computing center. The server 30 is used to store page code of a mixed mode mobile application to be debugged.
Referring to fig. 2, a block diagram of a mixed-mode mobile application debugging system according to an embodiment of the present application is shown. As can be seen from the figure, the mixed-mode mobile application debugging system provided in this embodiment includes a debugging device 200, a device 201 to be debugged, and a node server 202, where a desktop debugging window and a desktop client are installed in the debugging device 200, where:
the desktop client is configured to upload a page code of the mixed-mode mobile application to be debugged to the node server 202.
Specifically, the debugging device 200 refers to a device for debugging the debugging device 201 in a mixed-mode mobile application debugging system. In this embodiment, before debugging a mixed-mode mobile application (Hybrid application), a page code of the mixed-mode mobile application needs to be uploaded to the node server 202 through a desktop client in the debugging device 200.
In an exemplary embodiment, the desktop client is an Electron desktop client, and the debugging apparatus 200 further includes a local project debugging service installed in the debugging apparatus 200.
The Electron desktop client is a MacOS and Windows desktop client based on an Electron open source framework, is a debugging coupling middle layer capable of realizing debugging among a PC (computer), a node server 202, a real machine (Android mobile phone) or an emulator (iOS emulator), is a UI access layer of a desktop client user, and integrates multiple functions of a PC bottom layer system, WebSocket communication, Chromium kernel control and the like. Specifically, the Electron desktop client can implement AppleScript automation service and node-sim iOS simulator automation service, and implement automation processes of all relevant links of a page HMR (hot module replacement), including injection configuration, bridging intermediate layer, and the like.
In this embodiment, after the Electron desktop client 200 is started, it creates a WebSocket client and a WebSocket server locally on the PC.
The WebSocket client may actively initiate a connection request to the node server 202 to establish a first WebSocket long connection therebetween, and may forward data acquired from the node server 202 to the WebSocket client through the first WebSocket long connection. The WebSocket client also forwards data acquired from the WebSocket server (the data is acquired through an internal data channel between the WebSocket server and the WebSocket client) to the node server 202 through the first WebSocket long connection.
In an exemplary embodiment, in order to avoid that a device without authority is also connected to the node server 202, the Electron desktop client is further configured to request the node server 202 to obtain session credential information; the node server 202 is configured to generate session credential information when receiving a session credential information acquisition request sent by the Electron desktop client, and send the session credential information to the Electron desktop client, so that the WebSocket client establishes a first WebSocket long connection with the node server 202 according to the session credential information.
Specifically, after receiving the session credential information acquisition request, the node server 202 may randomly generate the session credential information, where the session credential information is a credential for establishing a connection with the node server 202, and only a device having the session credential may establish a connection with the node server 202.
The WebSocket server serves as a data transfer station for transmitting relevant data by using debugging data of a page to be debugged, HMR hot updating data of the page to be debugged and a Service Worker hijack request. The WebSocket server can be connected with a debugging tool (for example, a Chrome devices front debugging tool), and realizes communication between the node server 202 and the Chrome devices front debugging tool, the Webpack Service, the Hybrid application (mixed mode mobile application), the page to be debugged, and the Service Worker.
In this embodiment, after the Electron desktop client is started, it also creates a first module hot-swap client locally on the PC.
Specifically, the first module hot-replacement client is a local WebSocket client created by an Electron desktop client, and is used for communicating with the module hot-replacement server to realize the exchange of the JSON data for HMR hot-update.
In this embodiment, in order to process the page code in time by the local project debugging service, after the Electron desktop client is started, it also creates a local project packaging service locally on the PC, so as to start the local project debugging service by the local project packaging service.
Specifically, the local project packaging service is a Webpack development server created by a subprocess of an Electron client, and is used for executing starting of the local project debugging service, so that the local project debugging service processes page codes.
In this embodiment, the Electron desktop client is further configured to add, through the local project packaging service, a first script for creating a second module hot-replacement client and a second script for creating a module hot-replacement server in the page code.
Specifically, the module hot-replacement server is a WebSocket server locally created by Webpack when Webpack opens the DevServer mode, and is used for the first module hot-replacement client to connect and provide HMR hot-update JSON data.
The first script is a JavaScript script and is used for replacing a built-in module hot replacement client of the Webpack, and by adding the first script into a page code, a WebSocket long connection is established with a built-in module hot replacement server of the Webpack when the page code is loaded, so that JSON data of HMR hot update can be exchanged. In this embodiment, the second module hot-replacement client created through the first script may change a target address of the default WebSocket long connection for HMR hot-update of the page to be debugged to be an address of the node server 202, so as to forward JSON data for HMR hot-update to the node server 202.
The Webpack is a module packager and mainly aims to package JavaScript code files running on a browser.
It should be noted that the HMR hot update, i.e. module hot replacement, is a function that can replace, add or delete a module during the running of an application program without reloading the whole page. It has the following characteristics:
1. the page state is preserved (the page state includes the states of form, route, etc.).
2. Only the changed content is updated, and the packaging, page loading and page presenting speeds are higher, so that precious development time is saved.
3. When the CSS/JS generates a modification in the source code, the update is done immediately in the browser, which is almost equivalent to changing the style directly in the browser devtools.
The second script is also a JavaScript script which can be used for replacing a built-in module hot-replacement server of the Webpack, and specifically, the JavaScript script core is that a serverPath path of the built-in module hot-replacement server is changed into a self-defined path, so that a WebSocket long connection can be established with the built module hot-replacement client.
In an exemplary embodiment, when the first script and the second script are added to the page code through the local project packaging service, the configuration file code included in the page code may be analyzed to obtain a gitgnore configuration and a git file configuration, the first script and the second script are added to the configuration file obtained after the analysis, and after the addition of the first script and the second script is completed, a new project configuration file may be generated according to an existing config configuration file.
In this embodiment, after the local project package service completes adding the first script and the second script in the page code, the local project debugging service may create a module hot replacement service end according to the second script.
The local project debugging service can also pack the page codes containing the first script to generate a page code file directory.
Wherein, the local project debugging service is a Dev running service of a Webpack-based local front-end project.
The page code file directory refers to a dist file, which includes a plurality of files, for example, the dist file contains project static resources html, css, js file, and the like.
In this embodiment, the local project debugging Service is further configured to add a code segment of a third script used for loading a Service Worker to a preset file in the page code file directory, and add the third script to the page code file directory.
The Service Worker is an event-driven Worker registered under a specified source and path, and adopts JavaScript to control a related page or website, intercept and modify access and request resources, and cache resources with fine granularity. Essentially acting as a proxy server between the Web application, browser and network. It runs in the Worker context, i.e. in other threads, not the browser main thread, and therefore cannot access the page DOM and does not cause blocking, can only be carried by HTTPS, and is a thread completely asynchronous to the browser main thread.
In this embodiment, in order to intercept all HTTP/HTTPs network requests in a current page to be debugged through a Service Worker when the page to be debugged is loaded, the modification of the network request and the response result is implemented, and then the modified network request and the response result are returned to the current page to be debugged as the network request result of the current page to be debugged. In this embodiment, a code segment for loading a Service Worker script may be added in advance in the page code file directory, so that when a page code is loaded, another thread may be started through the code segment to run a third script of the Service Worker, so as to take over a current page to be debugged.
In this embodiment, the preset file is a preset file for adding code segments, and is specifically an html file in a target page code file.
In this embodiment, after the code segment is added, a third script of the JavaScript of the Service Worker may be placed under the page code file directory, so that the script of the Service Worker may be packaged together with other static resource files in the page code file directory by the Electron desktop client to generate a page code file package, and the page code file package is uploaded to the node server 202.
In an exemplary embodiment, the page code file directory including the third script may be packaged into a tar packet by the Electron desktop client, so that the Electron desktop client may upload the tar packet to the node server 202 by means of an HTTP request, and specifically, the Electron desktop client may place the tar packet into a request Body of the HTTP request.
The node server 202 is configured to deploy the received page code to a static resource service, and return a network address of the static resource service to the debugging device 201.
Specifically, the node server 202 may be deployed in a public network environment, and is configured to carry API interface services, manage WebSocket long connection data interaction, and be responsible for receiving, decompressing, managing Session credentials (Session ids) and project static resources of different clients, providing static resource services, and the like. The static resource service is a container in the node server 202 for storing page code.
In this embodiment, after receiving the page code uploaded by the debugging device 201, the node server 202 deploys the received page code to the static resource service, and returns the network address of the static resource service to the debugging device 201.
In an exemplary embodiment, when the page code received by the node server 202 is a page code file packet generated by packaging through an Electron desktop client, the node server 202 is further configured to decompress the page code file packet to generate a first code file, deploy the generated first code file to the static resource service, and return the network address of the static resource service to the Electron desktop client.
It can be understood that, when the page code received by the node server 202 exists in the form of a file package, the page code file package needs to be decompressed first, and then the decompressed first code file is deployed into the static resource service, so that the device to be debugged can obtain the first code file from the static resource service.
In an exemplary embodiment, in order to quickly find the page code (or the first code file) stored in the static resource service, the node server 202 may create a directory named by the session credential information in the static resource service after generating the session credential information, so that, when the page code file (or the first code file) is subsequently deployed, the received page code file packet may be decompressed, and the decompressed page code may be deployed in the directory named by the session credential information.
The device to be debugged 203 is configured to obtain the network address from the debugging device 201, and obtain and load the page code from the static resource service according to the network address, so as to open a page to be debugged.
Specifically, the device to be debugged 203 is a device that needs to be debugged by the debugging device 201. In this embodiment, when the device to be debugged is debugged, the device to be debugged first obtains the network address from the debugging device 201, so that the page code can be obtained and loaded from the static resource server according to the network address, and the page to be debugged is opened.
The debugging device 202 is further configured to debug the page to be debugged through a debugging tool installed in the debugging device 202.
Specifically, the debugging tool is a tool that needs to be used in a process of remotely debugging the device to be debugged 203. In this embodiment, during debugging, after the page to be debugged is opened, the debugging tool can directly perform remote page debugging on the page to be debugged. The page debugging may include page debugging operations such as an audit element, Console printing, Network view, memory management, and the like.
In an exemplary embodiment, the device to be debugged 203 may include an android device installed with the mixed-mode mobile application. The Android device refers to a device using an Android system.
The debugging tool comprises a Chrome Dettools front debugging tool, the Chrome Dettools front debugging tool is used for page debugging based on a Chrome Dettools Protocol cross-end debugging Protocol, the Protocol is used for page debugging data interaction based on JSON format data, equipment limitation is avoided, and most mainstream browsers and Webviews based on Chrome and Blink kernels in the market can be used for realizing cross-end debugging.
And the mixed-mode mobile application is used for acquiring and loading the first code file from the static resource service so as to open the page to be debugged.
Specifically, in order to enable the mixed-mode mobile application to conveniently acquire and load the first code file from the static resource service, the Electron desktop client may generate a corresponding identification code according to a network address returned by the node server 202 after receiving the network address, where the identification code may be a two-dimensional code, a barcode, or the like. In this way, when the mixed-mode mobile application needs to acquire the first code file, the barcode may be scanned to acquire the network address from the barcode, and then the first code file is acquired from a static resource service according to the network address and loaded to open the page to be debugged.
In an embodiment, in order to facilitate the subsequent mixed-mode mobile application to establish a WebSocket long connection with the node server 202, the Electron desktop client may further splice session credential information and the network address, and generate a corresponding identification code according to character information obtained after splicing; the mixed-mode mobile application is further configured to establish the fourth WebSocket long connection with the node server 202 according to the session credential information identified from the identification code.
The mixed-mode mobile application is further configured to load the third script according to the code segment in the first code file, intercept the network request of the page to be debugged through the third script, and create the second module hot-swap client according to the first script in the first code file.
Specifically, the acquired first page code includes a code segment for loading the third script (the script of the Service Worker), so that the script of the Service Worker can be loaded simultaneously in the process of loading the acquired first page code file, and the network request of the page to be debugged is intercepted by the Service Worker, so that the request address of the intercepted network request can be modified to the API Service address of the node server 202.
In an exemplary embodiment, when the Service Worker modifies the request address of the intercepted network request to the API Service address of the node server 202, the node server 202 sends the network request to the WebSocket client through the first WebSocket long connection. And after receiving the network request, the WebSocket client analyzes the domain name of the network request through the Electron desktop client, and sends the network request to a server according to the address obtained after analysis. The server may respond to the network request after receiving the network request.
The server is a server that deploys API interface services, and is usually deployed in various environments, such as testing, PRE, and formal environments, and used for front-end and back-end joint debugging at different stages.
In an exemplary embodiment, after the node server 202 receives the network request through the API service address, the node server parses the network request, and encapsulates the parsed first network request into a second network request including a request sequence number, a request address, a request mode, a request header, and a request body.
In an exemplary implementation manner, after receiving the network request, the server responds to the network request to generate a response result, and returns the response result to the Electron desktop client. In this embodiment, after receiving a response result returned by the server, the Electron desktop client may package the response result, and send the packaged first response result to the node server 202 through the WebSocket client; then, the node server 202 may analyze the received first response result, and return a second response result obtained after the analysis to the Service Worker, so that the Service Worker uses the second response result as a response result of the network request included in the page to be debugged.
In an embodiment, in order to facilitate analysis of the response result, after the Electron desktop client receives the first response result, the Electron desktop client encapsulates the received first response result into a second response result including a response serial number, a response status code, response status information, a response header, and a response body.
And the second module hot-replacement client is used for establishing a second WebSocket long connection with the node server.
Specifically, the second module hot-replacement client is a WebSocket client created when the first page code file is loaded, and is used for establishing a WebSocket long connection with the module hot-replacement server and exchanging HMR hot-update JSON data. In this embodiment, after receiving the JSON data of the HMR hot update, the second module hot-replacement client actively loads the packed hot module file to replace the local module in the page to be debugged, thereby achieving the effect of hot update.
The mixed-mode mobile application is further used for starting a Webview debugging mode so that the android device calls a chrome kernel to create a Unix Domain Socket server according to the Webview debugging mode.
Specifically, the Webview debugging mode is a mode for remotely debugging an application. The Unix Domain Socket service end is a service for providing JSON data for external connection, communication and exchange of Hybrid page debugging, the process ID format of the Unix Domain Socket service end is @ Webview _ devtools _ remote _ $ { pid }, and the pid is Webview process ID. When the Unix Domain Socket server communicates with the Hybrid application, an Inter-Process-Communication (IPC) Communication mode which is based on a file system and does not need to be transmitted through a network is adopted, and the Communication mode does not need to be subjected to processes of network packing, verification, unpacking and the like, so that the Unix Domain Socket server is more reliable and has higher efficiency.
The mixed-mode mobile application is further configured to establish a third WebSocket long connection with the Unix Domain Socket server, and to establish a fourth WebSocket long connection with the node server 202.
Specifically, when establishing the fourth WebSocket long connection with the node server 202, the mixed-mode mobile application may first identify session credential information from the identification code, and then establish the fourth WebSocket long connection with the node server 202 by means of the session credential information, so that the debugging JSON data of the page to be debugged may be exchanged with the fourth WebSocket long connection pre-node server 202.
In an exemplary embodiment, the Unix Domain Socket server has corresponding process identification information, and the mixed-mode mobile application is further configured to obtain process identification information of a plurality of processes currently started in the android device, and search the Unix Domain Socket server according to each process identification information; the mixed-mode mobile application is further configured to initiate a handshake request to the Unix Domain Socket server, and send a protocol upgrading instruction to the Unix Domain Socket server after the handshake is successful, so as to upgrade the current communication protocol to a WebSocket protocol.
Specifically, the process identification information is information for distinguishing different processes, the mixed-mode mobile application may use a localcocket library to find a process corresponding to a Unix Domain Socket server according to the process identification information of each currently opened process, then initiate a handshake request to the found process, and send an HTTP message to the Socket after the handshake is successful to upgrade a current communication protocol to a WebSocket protocol. After the upgrade is successful, the mixed-mode mobile application can perform corresponding message communication with a Unix Domain Socket Server Server based on a Websocket protocol.
The desktop client is also used for opening the desktop mode adjusting window;
and the desktop debugging window is used for loading a debugging tool installed in the debugging equipment to debug the page to be debugged.
Specifically, the desktop client may open a desktop debugging window through the WebSocket client, and load a debugging tool (e.g., the Chrome developers front debugging tool) installed in the debugging device in the desktop debugging window to debug the page to be debugged.
Specifically, the Chrome devtols Frontend debugging tool is used for debugging a front end UI of a page, can be separated from a Chrome kernel and independently run as a front end project, communicates with the Chrome kernel through a WebSocket protocol, exchanges debugging data in a JSON format, and achieves the development effect of Chrome built-in devtols.
The Chrome Dettools front debugging tool is used for establishing a fifth WebSocket long connection with the WebSocket server so as to exchange debugging data with the Chrome kernel through the fifth WebSocket long connection to debug the page to be debugged.
Specifically, when establishing a fifth WebSocket long connection with the WebSocket server, the Chrome Devtools front debugging tool may first acquire address information of the WebSocket server through the WebSocket client, and then may establish the WebSocket long connection with the WebSocket server according to the acquired address information of the WebSocket server.
In an embodiment, when the Chrome devtols fronted debugging tool realizes debugging of the page to be debugged through the fifth WebSocket long connection, the debugging request may be sent to the WebSocket server through the fifth WebSocket long connection, so that the WebSocket server may send the debugging request to the Unix Domain Socket server through the WebSocket client, the first WebSocket long connection channel, the fourth WebSocket long connection channel, and the third WebSocket long connection channel in sequence, thereby realizing debugging of the page to be debugged.
In another embodiment, when the debugging tool implements debugging on the page to be debugged through the fifth WebSocket long connection, the debugging tool may further send a debugging information acquisition request of the Hybrid page to be debugged to the WebSocket server through the fifth WebSocket long connection, so that the WebSocket server may send the debugging information acquisition request to the Unix Domain Socket server sequentially through the WebSocket client, the first WebSocket long connection channel, the fourth WebSocket long connection channel, and the third WebSocket long connection channel, thereby implementing acquisition of the debugging information of the page to be debugged from the Unix Domain Socket server and debugging operation according to the acquired debugging information.
In an exemplary embodiment, in order to debug the page to be debugged in time, the mixed-mode mobile application is further configured to send, to the node server 202 through a fourth WebSocket long connection after the fourth WebSocket long connection is established with the node server 202, a signal that a debugging channel of the page to be debugged is opened; the node server 202 is further configured to send the signal to the WebSocket client through the first WebSocket long connection after receiving the signal, so that the WebSocket client opens the desktop debugging window after receiving the signal.
In this embodiment, the desktop debugging window is opened only when a signal that the debugging channel is opened is received, so as to formally start page debugging on the page to be debugged.
The node server 202 is further configured to notify, through the first WebSocket long connection, the Electron desktop client to establish a sixth WebSocket long connection between the first module hot-swap client and the module hot-swap server after the second WebSocket long connection is established, so as to implement hot-swap of a page through the sixth WebSocket long connection.
Specifically, after the second WebSocket long connection is established, the node server 202 notifies the Electron desktop client of establishing a sixth WebSocket long connection between the first module hot-swap client and the module hot-swap server through the first WebSocket long connection, so that the second module hot-swap client can send a data request for page hot-swap to the module hot-swap server sequentially through the channel of the second WebSocket long connection, the channel of the first WebSocket long connection, and the channel of the sixth WebSocket long connection, thereby achieving acquisition of the data for page hot-swap.
In an exemplary embodiment, after the page code is modified, the Electron desktop client may further send the modified page code to the second module hot-swap client through the module hot-swap server side sequentially through the channel connected by the sixth WebSocket long link, the channel connected by the first WebSocket long link, and the channel connected by the second WebSocket long link, so as to implement hot-swap of the page according to the modified page code by the second module hot-swap client.
In an exemplary embodiment, the device to be debugged 201 further includes an iOS simulator, and the debugging tool further includes a Safari browser, where:
the Electron desktop client is also used for creating AppleScript automation services and iOS simulator automation services.
Specifically, AppleScript is a scripting language created by apple inc, is suitable for 7.1 and higher versions of MacOS, allows a user to directly control a scriptable MacOS application program and a part of built-in functions and applications of the MacOS itself, and can help the user to control the application program using the AppleScript script in the MacOS, such as a system event, a Safari browser, an iOS Simulator, and the like.
The iOS simulator automation service is used for executing an xcrun simctl command by using a node-simctl three-party library to control the iOS simulator, and comprises services of starting and closing the simulator, installing an App, opening a URL and the like.
The xcrun is a command line tool provided by an Xcode application under the MacOS, and is used for controlling the function related to the Xcode development.
The simctl is a sub-command of the xcrun tool for controlling the simulator, and provides the functions of starting, closing, installing an application, opening a URL, and the like of the simulator.
The Node-simctl is a Node version three-way library of simctl tools provided by the Appium for controlling the iOS Simulator in the Node program.
The Electron desktop client is further configured to start the iOS simulator through the iOS simulator automation service, install the mixed-mode mobile application through the iOS simulator automation service after the iOS simulator is started, and open the network address in the iOS simulator through the iOS simulator automation service after the mixed-mode mobile application is installed, so that the mixed-mode mobile application calls a WKWebview kernel to load the page to be debugged.
Specifically, the iOS simulator is software for simulating a real iOS device, in this embodiment, in order to save time required in a debugging process, the iOS simulator is automatically started through an iOS simulator automation service, the mixed-mode mobile application is installed through the iOS simulator automation service after the iOS simulator is started, and the network address is opened in the iOS simulator through the iOS simulator automation service after the mixed-mode mobile application is installed, so that the mixed-mode mobile application is automatically installed in the iOS simulator, and the page to be debugged is opened through the mixed-mode mobile application.
The wkbwebview kernel is a core part of modern WebKit API in iOS 8 and OS X Yosemite applications. It replaces UIWebView in UIKit and WebView in AppKit, providing a unified cross-dual platform API (iOS and OS).
In an exemplary embodiment, in order to avoid that a plurality of iOS simulators are turned on at the same time, in this embodiment, when the iOS simulators are turned on by the iOS simulator automation service, the Electron desktop client may first turn off all currently turned on iOS simulators by the iOS simulator automation service, and after all iOS simulators are turned off, turn on a default or user-selected iOS simulator again. Thereafter, the mixed-mode mobile application may be installed by the iOS simulator automation service.
In an exemplary embodiment, after completing installation of the mixed-mode mobile application, the Electron desktop client may further install a test environment certificate (e.g., an SSL certificate) through the iOS emulator automation service, so that the mixed-mode mobile application may access an HTTPS service of a test environment.
In an exemplary embodiment, after the Electron desktop client opens the network address in the iOS simulator through the iOS simulator automation service, the mixed-mode mobile application may be opened through a URL Schema, so that the mixed-mode mobile application may call a wkbwebview kernel to load the page to be debugged.
The URL Schema is supported by most APPs at present, and has a function of calling the APPs and opening corresponding pages when a browser in a real machine opens a URL.
From iOS 8, WKWebview replaces UIWebview gradually and becomes Webview mainly used by iOS App, and the WKWebview is based on Webkit kernel.
In an exemplary embodiment, the invoking, by the mixed-mode mobile application, the wkbwebview kernel to load the page to be debugged includes: and the mixed-mode mobile application calls the WKWebview kernel to start WKWebview kernel debugging service, and calls the WKWebview kernel to render the page to be debugged by adopting a Webkit engine.
Specifically, the wkbev kernel debugging service is a Webview debugging service in which a wkbev kernel is locally turned on, and is similar to a chrome kernel debugging service of Android. However, due to the limitation of the iOS, under a conventional condition, a third-party application cannot control the rendering and the internal debugging of the wkbev, and cannot contact the wkbev kernel debugging service, only a Safari developer tool can communicate with the service and debug, and the debugging protocol is based on a Webkit-like kernel debugging protocol. After the kernel debugging service is started, the WKWebview kernel renders the page to be debugged by adopting a Webkit engine.
The Electron desktop client is also used for opening a Safari developer tool from the Safari browser through an AppleScript automation service.
Specifically, the Electron desktop client may simulate clicking on the Safari developer tool in the Safari browser through the AppleScript automation service to open the Safari developer tool.
The Safari developer tool is a tool provided by a Safari browser and used for debugging an iOS real machine or simulator, is similar to Chrome developers tools, and can perform debugging functions such as element examination, Console printing, Network request management and the like.
The Safari developer tool is used for establishing a connection channel with the WKWebview kernel through a Safari debugging protocol and realizing debugging of a page to be debugged through the connection channel.
Specifically, after the Safari developer tool and the WKWebview kernel debugging service of the iOS simulator establish a connection channel, page debugging data can be exchanged based on Webkit-like debugging protocol communication, and complete functional page debugging is performed.
The mixed-mode mobile application debugging system can enable front-end developers to directly carry out remote debugging on Hybrid pages on Android4.4 and various Android real machines by using Chrome Dettools Frontend debugging tools in a desktop debugging window opened by an Electron desktop client, obtain debugging effects similar to debugging PC pages by using Chrome built-in developer tools, and does not need to use Charles agents, USB hardware equipment connection and the like, so that the cost and the complexity can be reduced.
Referring to fig. 3, a method for debugging a mixed-mode mobile application according to an embodiment of the present application is shown. The method is applied to a debugging system comprising debugging equipment, a node server and equipment to be debugged, wherein a desktop debugging window and a desktop client are installed in the debugging equipment, and the mixed-mode mobile application debugging system is the mixed-mode mobile application debugging system in the above embodiment and is not described in detail in this embodiment.
In this embodiment, the method includes:
step S30, uploading a page code of the mixed mode mobile application to be debugged to the node server through the desktop client;
step S31, deploying the received page code to a static resource service through the node server, and returning the network address of the static resource service to the desktop client;
step S32, the network address is obtained from the desktop client through the device to be debugged, and the page code is obtained and loaded from the static resource service according to the network address, so as to open the page to be debugged;
step S33, opening the desktop mode adjusting window through the desktop client;
and step S34, loading a debugging tool installed in the debugging equipment through the desktop debugging window to debug the page to be debugged.
The mixed-mode mobile application debugging system provided by the embodiment of the application can enable front-end developers to directly carry out remote debugging on Hybrid pages on Android4.4 and various Android real machines by using Chrome Dettools fronted debugging tools in a desktop debugging window opened by an electronic desktop client, obtain debugging effects similar to debugging of PC pages by using Chrome built-in developer tools, and does not need to use Charles agents, USB hardware equipment connection and the like, so that the cost and the complexity can be reduced.
The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on at least two network units. Some or all of the modules can be screened out according to actual needs to achieve the purpose of the scheme of the embodiment of the application. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a general hardware platform, and certainly can also be implemented by hardware. It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware related to instructions of a computer program, which can be stored in a computer readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-only memory (ROM), a Random Access Memory (RAM), or the like.
Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.
Claims (12)
1. The mixed-mode mobile application debugging system is characterized by comprising debugging equipment, a node server and equipment to be debugged, wherein a desktop debugging window and a desktop client are installed in the debugging equipment, wherein:
the desktop client is used for uploading page codes of the mixed mode mobile application to be debugged to the node server;
the node server is used for deploying the received page code into a static resource service and returning the network address of the static resource service to the desktop client;
the device to be debugged is used for acquiring the network address from the desktop client, and acquiring and loading the page code from the static resource service according to the network address so as to open a page to be debugged;
the desktop client is also used for opening the desktop mode adjusting window;
and the desktop debugging window is used for loading a debugging tool installed in the debugging equipment to debug the page to be debugged.
2. The mixed-mode mobile application debugging system of claim 1, wherein the desktop client is an Electron desktop client, wherein:
the Electron desktop client is used for creating a WebSocket client and a WebSocket server and establishing a first WebSocket long connection with the node server through the WebSocket client;
the Electron desktop client is further used for uploading page codes of the mixed-mode mobile application to be debugged to the node server;
the Electron desktop client is further used for establishing a second WebSocket long connection with the mode adjusting tool through the WebSocket server;
the Electron desktop client is further used for opening the desktop debugging window through the WebSocket client;
the node server is further configured to deploy the received page code to a static resource service, and return the network address of the static resource service to the Electron desktop client.
3. The mixed-mode mobile application debugging system of claim 2, wherein the device to be debugged is an android device on which the mixed-mode mobile application is installed, and the debugging tool is a Chrome developers fronted debugging tool, wherein:
the Electron desktop client is also used for generating a corresponding identification code according to the network address;
the mixed-mode mobile application is used for scanning the identification code, acquiring and loading the page code from the static resource service according to the network address identified from the identification code, and opening the page to be debugged;
the mixed-mode mobile application is also used for starting a Webview debugging mode so that the android device calls a chrome kernel to create a Unix Domain Socket server;
the mixed-mode mobile application is also used for establishing a third WebSocket long connection with the Unix Domain Socket server side and establishing a fourth WebSocket long connection with the node server;
the Chrome Dethols fronted debugging tool is used for sending a debugging request to the WebSocket server through the second WebSocket long connection, so that the WebSocket server sends the debugging request to the Unix Domain Socket server sequentially through the WebSocket client, the channel of the first WebSocket long connection, the channel of the fourth WebSocket long connection and the channel of the third WebSocket long connection, and the debugging request is debugged on the page to be debugged.
4. The mixed-mode mobile application debugging system of claim 3, wherein the mixed-mode mobile application is further configured to send, to the node server, a signal that a page debugging channel of the page to be debugged is opened through a fourth WebSocket long connection after the fourth WebSocket long connection is established with the node server;
the node server is further configured to send the signal to the WebSocket client through the first WebSocket long connection after receiving the signal, so that the WebSocket client opens the desktop debugging window after receiving the signal.
5. The mixed-mode mobile application debugging system of claim 2, wherein the Electron desktop client is further configured to request session credential information from the node server;
and the node server is used for generating session credential information when receiving a session credential information acquisition request sent by the Electron desktop client, and sending the session credential information to the Electron desktop client, so that the WebSocket client establishes a first WebSocket long connection with the node server according to the session credential information.
6. The mixed-mode mobile application debugging system of claim 5, wherein the node server is further configured to create a directory named by the session credential information in the static resource service after generating the session credential information.
7. The mixed-mode mobile application debugging system of claim 6, wherein the Electron desktop client is further configured to package the page code and upload a file package obtained after the packaging to the node server;
and the node server is also used for decompressing the file packet and deploying the decompressed page code to a directory named by the session credential information in the static resource service.
8. The mixed-mode mobile application debugging system of claim 3, wherein the Unix Domain Socket server has corresponding process identification information, and the mixed-mode mobile application is further configured to obtain process identification information of a plurality of processes currently started in the terminal device, and search the Unix Domain Socket server according to each process identification information;
the mixed-mode mobile application is further configured to initiate a handshake request to the Unix Domain Socket server, and send a protocol upgrading instruction to the Unix Domain Socket server after the handshake is successful, so as to upgrade the current communication protocol to a WebSocket protocol.
9. The mixed-mode mobile application debugging system of claim 3, wherein the Electron desktop client is further configured to splice the session credential information with the network address, and generate a corresponding identification code according to character information obtained after splicing;
and the mixed-mode mobile application is also used for establishing the fourth WebSocket long connection with the node server according to the session credential information identified from the identification code.
10. The mixed-mode mobile application debugging system of claim 3, wherein the Chrome devtols fronted debugging tool is further configured to obtain address information of the Websocket server from the Websocket client, and establish the second Websocket long connection with the Websocket server according to the address information.
11. The mixed-mode mobile application debugging system of any one of claims 3 to 8, wherein the Chrome Devtools fronted debugging tool is further configured to send a debugging information acquisition request of the Hybrid page to be debugged to the WebSocket server through the second WebSocket long connection, so that the WebSocket server sends the debugging information acquisition request to the Unix Domain Socket server sequentially through the WebSocket client, the channel of the first WebSocket long connection, the channel of the fourth WebSocket long connection, and the channel of the third WebSocket long connection, so as to achieve acquisition of the debugging information of the page to be debugged from the Unix Domain Socket server.
12. A mixed mode mobile application debugging method is applied to a debugging system comprising debugging equipment, a node server and equipment to be debugged, wherein a desktop debugging window and a desktop client are installed in the debugging equipment, and the method is characterized by comprising the following steps:
uploading a page code of the mixed mode mobile application to be debugged to the node server through the desktop client;
deploying the received page code into a static resource service through the node server, and returning a network address of the static resource service to the desktop client;
acquiring the network address from the desktop client through the device to be debugged, and acquiring and loading the page code from the static resource service according to the network address to open a page to be debugged;
opening the desktop mode adjusting window through the desktop client;
and loading a debugging tool installed in the debugging equipment through the desktop debugging window to debug the page to be debugged.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110919390.2A CN113626330A (en) | 2021-08-11 | 2021-08-11 | Mixed-mode mobile application debugging method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110919390.2A CN113626330A (en) | 2021-08-11 | 2021-08-11 | Mixed-mode mobile application debugging method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113626330A true CN113626330A (en) | 2021-11-09 |
Family
ID=78384468
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110919390.2A Pending CN113626330A (en) | 2021-08-11 | 2021-08-11 | Mixed-mode mobile application debugging method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113626330A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115114174A (en) * | 2022-08-02 | 2022-09-27 | 中航信移动科技有限公司 | Debugging method for weex page, storage medium and electronic equipment |
-
2021
- 2021-08-11 CN CN202110919390.2A patent/CN113626330A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115114174A (en) * | 2022-08-02 | 2022-09-27 | 中航信移动科技有限公司 | Debugging method for weex page, storage medium and electronic equipment |
| CN115114174B (en) * | 2022-08-02 | 2022-12-13 | 中航信移动科技有限公司 | Debugging method for weex page, storage medium and electronic equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11144439B2 (en) | Emulation-based testing of a microservices architecture | |
| CN106776313B (en) | Method and device for simulating service and centralized management platform | |
| CN106844137B (en) | Server monitoring method and device | |
| US10990369B2 (en) | Repurposing serverless application copies | |
| US8612947B2 (en) | System and method for remotely compiling multi-platform native applications for mobile devices | |
| CN113641582A (en) | Mixed-mode mobile application debugging method and system | |
| EP3454213B1 (en) | Function library build architecture for serverless execution frameworks | |
| US11513789B2 (en) | Application deployment method, apparatus, and system | |
| US20090082008A1 (en) | Mobile Phone Code Debugging Method and Apparatus | |
| CN112732572A (en) | Service testing method, device and system, storage medium and electronic device | |
| CN113641581B (en) | Mixed mode mobile application debugging method and system | |
| CN104821954A (en) | Cross-platform remote procedure call method | |
| CN108628626B (en) | Development environment building method, code updating method and device | |
| CN112615759B (en) | Full link voltage measurement assembly, full link voltage measurement method and device | |
| CN112231209A (en) | Parameter acquisition method and device, computer equipment and storage medium | |
| CN113641580B (en) | Mixed mode mobile application debugging method and system | |
| CN113626330A (en) | Mixed-mode mobile application debugging method and system | |
| CN104917633A (en) | Method and device simulating FOTA upgrade | |
| CN112650689A (en) | Test method, test device, electronic equipment and storage medium | |
| CN110221855B (en) | Method for app and server collaborative updating and offline running | |
| CN114915565B (en) | Network debugging method and system | |
| CN113626329A (en) | Mixed-mode mobile application debugging system | |
| CN115080109A (en) | Multi-cloud-end environment joint debugging method, device, system and equipment based on hybrid development | |
| CN112433938A (en) | Method and device for testing application of mobile terminal | |
| CN114092169A (en) | Ordering test method and system and equipment for executing ordering test method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |