CN106557424B - Memory test method, tested terminal, test client and system - Google Patents

Abstract

The application provides a memory test method, a tested terminal, a test client and a system, when the running condition of a certain application program on the tested terminal, namely a target application program, needs to be obtained, the test client injects a library file aiming at the target application program into a target process of the target application program so as to call a detection interface which is not exported by an engine of the target application program, thus, when the target application program runs on the tested terminal, the tested terminal can obtain at least one type of resource object data aiming at the target application program through the detection interface, such as data of resource objects of a map, a video, a model and the like, and then the tested terminal can send the obtained resource object data to the test client for output, so that developers can accurately know the data of various resource objects of the target application program during the actual application of the tested terminal, therefore, the performance of the target application program is optimized in a targeted manner, and the optimization efficiency is improved.

Description

memory test method, tested terminal, test client and system

Technical Field

The present application relates to the field of performance optimization applications, and more particularly, to a memory test method, a terminal under test, a test client, and a system.

Background

At present, as the requirement of a user for the function of application program implementation is higher and higher, the memory occupied by the application program in the operation of the mobile terminal is gradually increased, so that the performance optimization of the application program becomes a major factor in the development process of the application program in the face of limited system resources of the mobile terminal.

In practical application, most of the memory of the application program is occupied by various resources, and in a traditional memory test, the total memory occupied by the application process during the running period of the application program can only be obtained, and the situation of memory occupation by the refined type resources cannot be accurately positioned, so that developers cannot perform targeted optimization on the performance of the application program according to the memory test result.

Disclosure of Invention

In view of this, the present application provides a memory testing method, a tested terminal, a testing client, and a system, which implement the memory occupation of specific types of resource objects during the running process of a target application program, facilitate developers to perform targeted optimization on the performance of the target application program, and improve the performance optimization efficiency of the target application program.

In order to achieve the above object, the present application provides the following technical solutions:

The embodiment of the application provides a memory test method, which is applied to a tested terminal and comprises the following steps:

Establishing communication connection with a test client loaded on a test terminal;

Receiving a dynamic library file sent by the test client aiming at a target application program in the tested terminal;

Injecting the dynamic library file into an application process of the target application program and executing the dynamic library file, and calling engine interfaces corresponding to different resource objects one to one;

Running the target application program, and acquiring various resource object data aiming at the target application program through a called engine interface;

and sending the obtained various resource object data of the target application program to the test client for output.

the embodiment of the application also provides another memory testing method, which is applied to a testing client, wherein the testing client is loaded on a testing terminal, and the method comprises the following steps:

After the test client is started, establishing communication connection with a tested terminal;

Determining a target application program which meets the preset requirement in the tested terminal;

injecting the dynamic library file corresponding to the target application program into the application program of the target application program so as to enable the tested terminal to execute the dynamic library file and call engine interfaces corresponding to different resource objects one to one;

when the target application program is operated by the tested terminal, receiving various resource object data of the target application program, which are obtained and sent by the tested terminal;

And detecting a data viewing instruction aiming at any resource object, and outputting corresponding resource object data according to a preset mode.

the embodiment of the present application further provides a terminal to be tested, a plurality of applications are provided on the terminal to be tested, and the terminal to be tested further includes:

the communication module is used for establishing communication connection with a test client loaded on a test terminal and receiving a dynamic library file sent by the test client aiming at a target application program in the tested terminal;

the processing module is used for injecting the dynamic library file into an application process of the target application program and executing the dynamic library file, and calling engine interfaces corresponding to different resource objects one to one;

And the data acquisition module is used for acquiring various resource object data aiming at the target application program through a called engine interface during the running of the target application program, and sending the acquired various resource object data of the target application program to the test client for output through the communication module.

the embodiment of the present application further provides a test client, where the test client is loaded on a test terminal, and the test client includes:

The first communication module is used for establishing communication connection with a tested terminal after the test client is started;

the target application program determining module is used for determining a target application program meeting preset requirements in a tested terminal, and injecting a dynamic library file corresponding to the target application program into the application program of the target application program through the first communication module so that the tested terminal executes the dynamic library file and calls engine interfaces corresponding to different resource objects one by one; when the target application program is operated by the tested terminal, various resource object data of the target application program, which are obtained and sent by the tested terminal, are received through the first communication module;

and the output module is used for detecting the data viewing instruction aiming at any resource object and outputting corresponding resource object data according to a preset mode.

an embodiment of the present application further provides a memory test system, where the system includes: the system comprises a test terminal and a tested terminal, wherein the test terminal is loaded with a test client;

The testing client is used for establishing communication connection with the tested terminal after being started, determining a target application program meeting preset requirements in the tested terminal, and injecting a dynamic library file corresponding to the target application program into the application program of the target application program;

The tested terminal is used for receiving a dynamic library file sent by the testing client aiming at a target application program in the tested terminal, injecting the dynamic library file into an application process of the target application program and executing the dynamic library file, calling engine interfaces corresponding to different resource objects one to one, obtaining various resource object data aiming at the target application program through the called engine interfaces during the running of the target application program, and sending the obtained various resource object data of the target application program to the testing client so that the testing client detects a data viewing instruction aiming at any resource object and outputs the corresponding resource object data according to a preset mode.

based on the above technical solution, in the embodiment of the present application, when it is required to obtain an operation condition of a target application program, which is one application program on a terminal to be tested, the test client injects a library file for the target application program into a target process of the target application program, so as to invoke a detection interface that is not exported by an engine of the target application program, so that when the target application program is operated on the terminal to be tested, the terminal to be tested can obtain at least one type of resource object data for the target application program through the detection interface, such as data of resource objects like maps, videos, models, etc., and then the terminal to be tested can send the obtained resource object data to the test client for output, so that developers can accurately know data of various resource objects of the target application program during actual application of the terminal to be tested, so as to perform targeted optimization on performance of the target application program, the optimization efficiency is improved.

drawings

in order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

fig. 1 is a structural diagram of a memory test system according to an embodiment of the present disclosure;

Fig. 2 is a hardware structure diagram of a test terminal according to an embodiment of the present disclosure;

Fig. 3 is a signaling flowchart of a memory testing method according to an embodiment of the present application;

fig. 4(a) to (e) are diagrams illustrating test windows output by test terminals at different stages in a memory test process according to an embodiment of the present application;

Fig. 4(f) is an exemplary diagram of a test report generated by a memory test method according to an embodiment of the present application;

fig. 5 is a partial flowchart of another memory testing method according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of deriving resource objects by an Object base class according to an embodiment of the present disclosure;

fig. 7 is a block diagram of a tested terminal according to an embodiment of the present disclosure;

fig. 8 is a block diagram of another structure of a terminal under test according to an embodiment of the present disclosure;

fig. 9 is a block diagram of a test client according to an embodiment of the present disclosure;

Fig. 10 is a block diagram of another test client provided in the embodiment of the present application;

fig. 11 is a block diagram of a structure of another testing client provided in an embodiment of the present application;

fig. 12 is a block diagram of a structure of another test client according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

To facilitate an understanding of the various embodiments below, some of the terms or names referred to herein are explained as follows:

unity: it is a multi-platform, comprehensive game development tool developed by Unity Technologies that allows players to easily create types of interactive content such as three-dimensional video games, building visualizations, real-time three-dimensional animations, etc., and is a fully integrated professional game engine. Unity is similar to software that takes advantage of interactive graphical development environments as the first place, such as Director, Blender, game engine, Virtools, or TorqueGame Builder. Its editor runs under Windows and Mac OS X and can publish games to Windows, Mac, Wii, iPhone, WebGL (requiring HTML5), Windows phone 8 and Android platforms. And the Unity web player plug-in can also be used for releasing a web game and supporting the web browsing of Mac and Windows. Its web player is also supported by Mac widgets.

and (3) SO injection: an SO is put into the address space of a process to make it part of that process. The injected SO may then call a function of the target application process in the injected SO.

Resource object: in the running process of the Unity game, the resources exist in the form of resource objects after being loaded, and the memory space is occupied. Resource object types include, but are not limited to, models, maps, audio, video, animation, and the like.

Fig. 1 is a schematic structural diagram of an application memory test system according to an embodiment of the present application, where the system may include: the testing system comprises a tested terminal 100 and a testing terminal 200, wherein the testing terminal 200 is loaded with a testing client, and an application program to be tested is arranged on the tested terminal 100.

in practical applications, the system may further include a server 300 corresponding to the testing client and a server 300 corresponding to the application program to be tested (not shown in fig. 1), where the server may be a group of multiple servers or may be implemented by a single server.

optionally, when the application program to be tested is various game software, the application server may be a service device providing a game service for a user, and the game client may be an application program for completing a memory test of the game software. For example, the tool for testing and tuning the performance of the Unity game provides a complete set of testing schemes, and can carry out the Natrix of the true machine performance test on the Unity game under the condition of a passive code.

in which Natrix can be compatible with the universal Unity version, i.e. the engine version. In the memory test scheme provided by the application, the memory occupation condition in the running process of the Unity game can be checked in real time on the test terminal, namely, various resource object data of the Unity game are obtained in real time and analyzed to generate a test report, and risk assessment and the like are carried out based on the test report, so that the performance of the Unity game is optimized accordingly.

In practical application, the tested terminal can be a mobile terminal such as a mobile phone and a tablet computer, and the testing terminal can be a computer device different from the tested terminal.

as shown in fig. 2, a hardware structure diagram of a test terminal provided in the embodiment of the present application is provided, where the test terminal may include a processor 1, a communication interface 2, a display 3, a memory 4, and a communication bus 5;

the processor 1, the communication interface 2, the display 3 and the memory 4 can complete mutual communication through a communication bus 5;

optionally, the communication interface 2 may be an interface of a wireless communication module and an interface of a wired communication module, such as a USB interface, an interface of a GSM module, an interface of a WIFI module, and the like;

in practical application of the present application, a communication channel may be established between the interface of the wireless communication module and the wireless communication module of the server 30, so as to implement data transmission between the test terminal and the server 30, and of course, the interface of the wireless communication module may also be used to implement data transmission between the test terminal and the server 30.

In addition, the present application may further utilize an interface of the wired communication module to be connected with an interface of the wired communication module of the terminal to be tested, so as to implement communication connection between the test terminal and the terminal to be tested, and further implement communication between the test client and the target application program of the terminal to be tested, which may be specifically referred to the description of the corresponding portion of the method embodiment below.

the processor 1 is used for executing application programs, such as testing clients and the like. In the present application, the processor 1 may be a central processing unit CPU, or an application Specific Integrated circuit asic, or one or more Integrated circuits configured to implement the embodiments of the present invention.

A display 3 for displaying different test windows output by the test client operated by the processor 1, the test progress and data generated by the test, such as an operation interface, a test interface and the like of the test client operated in the test terminal

in this application, display 3 can be touch-sensitive screen or liquid crystal display, and this application does not limit this, and when the display structure is different, the mode of selecting operation such as test object can corresponding adjustment in the test procedure.

The memory 4 is used for storing information such as relevant program codes of the application program executed by the processor 1 and can also cache various data generated in the execution process of the application program, and the application is not limited to the memory; the application program may include program code including computer operating instructions, among other things.

in the present application, the memory 4 may comprise a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

In this application, the hardware structure of the terminal to be tested and the hardware structure type of the test terminal may also include a processor, a communication interface, a display, a memory, and the like, which are different from the test terminal in that the processor of the terminal to be tested is used to execute an application program such as game software, instead of the test client, and the corresponding memory stores related information of the application program such as game software, such as program codes. Therefore, the present application does not describe the hardware structure of the terminal under test in detail herein.

In addition, the hardware structures of the server 30 and the application server may include a processor, a communication interface, a memory, and a communication bus, and the corresponding functions of each part may refer to the description of the hardware structure of the test terminal, which is not described in detail herein.

based on the schematic structural diagram of the memory test system shown in fig. 1, fig. 2 shows a hardware structure diagram of a test terminal, and also describes hardware structures of a tested terminal and a corresponding server, and functions corresponding to the implementation support, the following embodiments of the present application are proposed.

as shown in fig. 3, a signaling flowchart of a memory testing method provided in the embodiment of the present application is shown, where the method may include:

Step S11, the test client operates in the test terminal and establishes communication connection with the tested terminal;

In practical application, when the memory usage of the application program in the test terminal needs to be tested, a user may double-click an icon of the test client on the test terminal to start the test client, and at this time, in order to facilitate a developer to know the test progress, a test window connected to the test terminal may be output on the test terminal, as shown in fig. 4(a), but not limited to the output form shown in fig. 4 (a).

The developer can carry out communication connection between the tested terminal and the testing terminal according to the testing window output by the testing terminal, and the testing client can establish communication connection with the tested terminal after detecting the tested terminal connected with the testing terminal.

Optionally, the test terminal and the communication interface of the terminal to be tested may be connected by a data transmission line, for example, a USB cable may be used to connect the USB port of the test terminal and the USB port of the terminal to be tested, and the type of the communication interface for communicating the test terminal and the terminal to be tested is not limited in the present application.

as shown in fig. 4(b), after the testing client successfully establishes a communication connection with the tested terminal, a prompt message of contents such as "the tested terminal is connected, please select an application program to start testing" and the like may be added to the testing window shown in fig. 4(a), so as to instruct the developer to perform the subsequent testing steps.

step S12, the test client detects and outputs all application programs meeting the preset requirements in the tested terminal;

after the test client determines that the communication connection with the tested terminal is established, all the application programs meeting the preset requirements on the tested terminal can be searched systematically, and the searched application programs and the related information thereof are displayed.

In this embodiment, after this step is reached, the test window displayed by the test terminal may be changed from the test window shown in fig. 4(b) to the test window shown in fig. 4(c), and the displayed information of the application program may include the name of the application program, the installation path, the engine version number used, and the like, and the content of the displayed information is not limited in this application.

optionally, the preset requirement may refer to an application program using a preset engine, and may include all engine version numbers that are unique to the preset engine, and then, in the actual detection, all application programs that meet the preset requirement may be determined based on the engine version numbers, that is, an application program using any one of the engine version numbers.

Step S13, the test client detects the selection instruction aiming at the currently displayed application program and determines the target application program of the test;

in the test window obtained as shown in fig. 4(c), a developer may select an application program that needs to test the memory as a target application program according to the current test requirement, so as to perform a memory test on the target application program in the following.

optionally, after the target application program is determined, the tested terminal may further verify whether an engine version number used by the target application program belongs to a preset engine, and if not, may prompt the developer to reselect a new target application program, so as to further ensure that the tested target application program uses the preset engine.

step S14, the test client injects the dynamic library file corresponding to the target application program into the application process of the target application program;

in this embodiment, for application programs of different versions, dynamic library files of corresponding release versions (release versions) are usually set, such as dynamic link libraries like libuty. Therefore, after determining the target application program to be tested, the testing client may search for the libuty.so of the release version corresponding to the target application program, and may inject the libuty.so of the debug version (debug version) of the target application program itself into the application process corresponding to the target application program in a socket communication manner.

Optionally, the liblader.so may be injected into an application process of a target application program of the terminal to be tested, specifically, a register of the target process may be obtained by calling a ptrace system function, and a dynamic library function such as dlopen/dlsym is called in the target process, so that the current target process loads a specified dynamic library file. It should be noted that the specific implementation of SO injection is not limited in the present application.

The liblader.so file may be used to call an engine unextended interface, that is, a test interface, used by the target application program, and specifically may call an unextended interface of the libuty.so file of the target process, so that the libuty.so of the self-debugging version, which is unextended by the target application program, is replaced with the libuty.so of the release version of the target application program, which is sent by the test terminal, through the unextended interface, but is not limited thereto.

Step S15, the tested terminal executes the injected dynamic library file and calls the engine interfaces corresponding to various resource objects one by one;

it should be noted that, for different applications using the same engine, the types of resource objects in the actual running process are generally the same, and the engine interfaces corresponding to the same type of resource for different applications are the same. The dynamic library file may include the libuty.

In this embodiment, after the reference process of the target application program of the terminal to be tested injects the corresponding dynamic library file, the dynamic library file may be executed to complete the initialization operation, so as to prepare for the subsequent testing of the memory of the target application program.

executing the dynamic library file may include replacing some core files of the target application program with files corresponding to the injected dynamic library file, such as replacing a debug version of the target application program itself with a debug version of the target application program, which is a published version of the target application program in the injected dynamic library file; the hook (hook) in the dynamic library file can also be installed to the application process of the target application program of the tested terminal, namely, the hook function is written into the function library corresponding to the application process.

Of course, according to actual needs, the dynamic library file may further include other information contents, and the corresponding initialization operation may further include other initialization contents, which are not described in detail herein.

Optionally, because the initialization process of the terminal under test is automatically executed after it receives the library file, in order to enable the developer to know the initialization situation, it may also display whether the terminal under test is initialized and whether the initialization is completed in a window currently output by the test terminal, and may start to perform testing and other information, as shown in fig. 4(d), but not limited to the prompting content and manner shown in fig. 4 (d).

step S16, the tested terminal detects a trigger instruction aiming at the target application program and controls the target application program to run;

In practical applications, after it is determined that the terminal under test is initialized, a developer may start a target application program, and in order to provide test accuracy and reliability, the developer may implement various functions of the target application program on the terminal under test during the test, so as to obtain more comprehensive resource object data.

in addition, after controlling the target application program to run on the terminal under test, the developer may click the start button shown in fig. 4(d), thereby formally starting the memory test of the target application program.

Optionally, when the target application is a game, the game is automatically pulled up after the initialization operation is completed, and the game is started only after the game is successfully pulled up.

Step S17, the tested terminal obtains various resource object data aiming at the target application program through the called engine interface;

As described above, each type of resource object has an engine interface corresponding to it one to one, and during the running of the target application, the generated data of each type of resource object passes through the engine interface corresponding to the type of resource object, so the terminal under test can obtain the data of the corresponding type of resource object by monitoring the engine interface.

It should be noted that, the specific content included in the obtained resource object data is not limited in the present application, and may be the number of resource objects, memory occupied by the resource objects, or other performance parameters, and the specific detection process may refer to the description of the corresponding embodiment below, which is not described herein again.

Step S18, the tested terminal sends the obtained resource object data of each type of the target application program to the testing client;

Optionally, the application may still use a socket communication mode to send the obtained resource object data of each resource object related to the target application to the test client.

in the actual transmission process of the resource object data, the terminal to be tested can transmit the obtained resource object data to the test client in real time, or transmit the obtained resource object data according to a certain period, or transmit the obtained resource object data to the test client after collecting all resource object data in the whole operation period of the target application program, and the like.

step S19, the test client detects a data viewing instruction for any resource object, and outputs the resource object data corresponding to the resource object in a preset manner.

After starting testing the resource objects of the target application, the testing client may display a testing window as shown in fig. 4(e) at the testing terminal, but is not limited to the output form as shown in fig. 4 (e). As shown in fig. 4(e), the name of each resource object may be displayed in the subject column of the test window, and a developer may click on a certain resource object, such as "Audio", according to actual viewing needs, so that the data display area of the test window presents data about the Audio resource object.

optionally, the data of each resource object received by the test client may be stored in the test terminal storage or the memory of the test client, and a graph as shown in fig. 4(e) may be generated for the data of the resource object of different resource objects according to needs, so as to more intuitively know the specific situation of each resource object of the target application program.

the data table of the resource object may be in the form as shown in fig. 4(e) or may be a graph, and the specific output form of each resource object data is not limited in the present application.

optionally, screenshot storage may be performed on the resource object data currently displayed by the test terminal according to needs, and classified storage may be performed on the data of different resource objects, but the present invention is not limited to this.

in summary, according to the application process of the target application program of the tested terminal, the corresponding dynamic library file is injected, namely the release version dynamic library file different from the debugging version of the target application program, the engine interface corresponding to each resource object is called, and in the running process of the target application program, the corresponding resource object data of each engine interface is obtained and presented at the testing terminal, so that a developer can visually know the memory occupation condition of subdivided resources in the actual running of the target application program, accurately position the resources with excessively high memory occupation, and pertinently realize the performance optimization of the target application program.

As another embodiment of the present application, on the basis of the above embodiment, after the test client obtains each resource object data during the running of the target application, the test terminal may synchronize the resource object data to the server, and the server analyzes the resource object data to obtain the test result, and after the test is finished, the developer or other users may view the test result for the target application on the test terminal from the web page.

Specifically, the server may extract required data, such as peak data of each resource object data, from each resource object data to determine whether each resource object data of the target application satisfies a pre-stored determination criterion, and then generate a test report according to the determination result for a developer to refer to and optimize the performance of the target application. Taking the example that the Audio Clip occupies the memory, the generated test report may be as shown in fig. 4(f), but is not limited thereto

Optionally, the pre-stored determination criteria may be determined through empirical data testing, for example, using Unity hand tour, the determination criteria may be determined according to Unity official advice and experience data of Unity hand tour, as shown in the following table, but is not limited thereto.

Watch 1

Resource item	judgment criteria
		Total memory usage	peak value<150MB
mono heap memory	peak value<40MB
		Drawcall	Peak value<250
rendering Triangle number	Peak value<100000
		Skinned Mesh Render	Peak value<50
Rigdbody	Peak value<50
		Collision body	(static Collision + dynamic Collision) Peak<100
Texture memory footprint	Peak value<50MB
		Skinned Mesh Render memory footprint	Peak value<15MB
Audio Clip memory footprint	peak value<15MB

The test report may include a comprehensive description of the test result of the target application program in the terminal under test, more detailed data, icons, and brief analysis, and the specific content included in the test report is not limited in the present application.

In practical application, in order to enable other users to see the memory test result of the target application program running on the tested terminal, a developer may select a Web-side data viewing manner on the test terminal, and send a corresponding URL (uniform resource Locator) address to the terminals of the other users, so that the other users can log in the URL address and view the contents of the test data, the test report and the like.

As another embodiment of the present application, the generation process of the test report may be implemented on a test terminal, that is, the test terminal generates the test report of the target application by using the received resource object data for the target application, and the specific process is similar to the generation process of the test report, and the detailed description of the implementation is omitted here.

optionally, for the above embodiment, the specific obtaining manner adopted by the terminal to be tested to obtain each resource object data during the running period of the target application may be different according to the difference of the resource objects, and the following only takes the statistics of the number of the resource objects and the statistics of the memory occupied by the resource objects as examples to describe the specific resource object data obtaining process, and for the obtaining manners of other resource object data, the two obtaining manners may be referred to and determined according to the characteristics of the resource objects, and the details of the application are not described herein.

Since the process of acquiring resource object data is implemented by the terminal under test during the running of the target application, on the basis of the above embodiment, this embodiment will be described from the perspective of the terminal under test, and as shown in the flowchart shown in fig. 5, for the step of acquiring resource object data by the terminal under test, reference may be made to the description of the corresponding part of the content of the memory test signaling flow described above, which is not described herein again.

Fig. 5 shows a partial flowchart of another memory testing method provided in the embodiment of the present application, where the method may be used for a terminal under test, specifically, a statistical method for memory occupied by a resource object, and may include the following steps:

Step S21, statically analyzing the dynamic library file to obtain the offset address of the target function in the dynamic library file;

Optionally, the objective function may be a GetRunTimeMemorySize () function, and the function may be implemented by an Object base class, or may be implemented by each resource subclass itself, which is not limited in this application.

Taking the target application as a Unity game, the Unity game resource class is derived from the Object base class, and the resource objects such as Mesh, Audio, Texture, etc. are inherited from the NameObject class as shown in fig. 6, but not limited to the embodiment illustrated herein.

Step S22, determining the operation address of the target function by using the base address and the offset address of the dynamic library file;

The method and the device can add the base address of the dynamic library file and the obtained offset address to obtain the address of the target function in operation, namely the operation address.

in step S23, the operation address is converted into a function pointer of the target function, and the target function is called by using the function pointer.

step S24, the target function is executed to obtain the memory data occupied by various resource objects of the currently executed target application program.

therefore, the memory data occupied by the resource object can be obtained by calling the target function injected into the dynamic library file of the target application program, and the memory data is sent to the test client for display, so that developers can intuitively know the memory occupied by various resource objects during the running of the target application program.

Taking an application program meeting preset requirements as a Unity game, a tested terminal as a mobile phone, a testing terminal as a computer, and a testing client as a Natrix client as an example, the following description is given to the embodiment of the present application:

When the memory test of the Unity game on the mobile phone is needed, the developer starts a Natrix client installed on the computer, so as to output a test interface as shown in fig. 4(a), the developer can connect the mobile phone to a communication interface on the computer through a data line according to the prompt, so as to establish a communication connection with the Natrix client, the computer outputs the test interface as shown in fig. 4(b), then the Natrix client can detect all game APPs developed by the Unity on the mobile phone and output a game selection window as shown in fig. 4(c), the developer can select the game APP to be tested according to the test requirement, then the Natrix client can carry out some initialization work on the mobile phone according to the selected game APP and the Unity version number, such as replacing some core files, installing HOOK and the like, and after the initialization is completed, the game will be pulled up, such as the test window shown in fig. 4 (d).

After determining that the selected game APP is successfully pulled up, the developer can start the game APP, and click the start button in fig. 4(d), so that the mobile phone starts to collect various resource object data in the process of performing various game operations on the game APP, and transmits the data to the Natrix client for storage, as shown in fig. 4(e), the Natrix client can perform graph drawing on the received various resource object data, and the developer can click the tag in the title bar to select data of a certain resource object to be viewed.

After the collection of various resource object data of the game APP is completed, a stop button can be clicked, and then a background server of the Natrix client generates a test report for the game APP according to the stored various resource object data, and can send the test report to a preset mailbox address of a developer or other users so as to check the test report.

The test may include a comprehensive description of the test, more detailed data, graphs, and brief analysis, such as a test report shown in fig. 4(f), but is not limited thereto.

in summary, the memory testing method described above can be used to test all Unity games on the mobile phone, and the detailed description of the method is omitted here.

as shown in fig. 7, a structural block diagram of a terminal to be tested provided by the present application is provided, where the terminal to be tested may be a mobile terminal such as a mobile phone and a tablet computer, and the present application does not limit the specific product type, and moreover, the terminal to be tested may be provided with a plurality of application programs, and further includes:

the communication module 11 is used for establishing communication connection with a test client loaded on the test terminal and receiving a dynamic library file sent by the test client aiming at a target application program in the tested terminal;

In this embodiment, the communication module may be a socket communication module, so that the terminal under test communicates with the test client in a socket communication manner, but is not limited thereto.

optionally, the dynamic library file corresponding to the target application program may be a release version libuty.so file in the SO library, which is different from a debug version libuty.so file that is not called by the target application program itself, and the specific function may refer to the description of the corresponding part of the method embodiment.

the processing module 12 is configured to inject the dynamic library file into an application process of the target application program, execute the dynamic library file, and call engine interfaces corresponding to different resource objects one to one;

The specific process of SO injection is not limited, and as to the process of initializing by the processing module 12 using the received dynamic library file, reference may be made to the description of the corresponding part of the above method embodiment, which is not described herein again.

and the data acquisition module 13 is configured to, during running of the target application program, acquire various resource object data for the target application program through the called engine interface, and send the acquired various resource object data of the target application program to the test client through the communication module 11 for output.

Therefore, the test client can directly inject the dynamic library file corresponding to the target application program to be tested into the application process of the target application program, so that the tested terminal automatically completes initialization operation, and the engine interface is called by using the dynamic library file in the process of starting the target application program and realizing each function of the target application program, so that various resource object data during the running period of the target application program are obtained and fed back to the test client for output, and therefore developers can visually know the memory occupation condition of various resource objects during the running process of the target application program at the tested terminal, the developers can conveniently and specifically optimize the performance of the target application program, and the optimization efficiency is greatly improved.

optionally, on the basis of the foregoing embodiment, in order to count the number of resource objects during the running period of the target application, the data obtaining module 13 may specifically include:

And the resource object quantity counting unit is used for determining the total number of various resource objects of the currently running target application program by utilizing the HOOK function in the dynamic library file.

It should be noted that, in the present application, the statistical method for resource objects by using the HOOK function is not limited, and may be implemented by referring to the characteristics of the HOOK function itself, and the embodiment is not described in detail herein.

optionally, in order to count the memory occupied by each resource object, as shown in fig. 8, the data obtaining module 13 in the foregoing embodiment may further include:

An objective function retrieving unit 131, configured to retrieve an objective function in the dynamic library file;

in this embodiment, the objective function may be a GetRunTimeMemorySize () function, but is not limited to this, and may be determined according to the test requirement. Wherein the GetRunTimeMemorySize () function is a private function not derived from the above dynamic library file.

In this embodiment, as shown in fig. 8, the objective function retrieving unit 131 may include:

an analyzing unit 1311, configured to statically analyze the dynamic library file, to obtain an offset address of the target function in the dynamic library file;

A function pointer determining unit 1312, configured to determine a running address of the target function by using the base address of the dynamic library file and the offset address, and convert the running address into a function pointer of the target function;

a function calling unit 1313, configured to call the target function using the function pointer.

The memory data obtaining unit 132 is configured to run the target function, and obtain memory data occupied by various resource objects of the currently running target application.

In addition, it should be noted that the tested terminal may also obtain other performance data of the target application program by using other information in the dynamic library file, such as the number of DrawCall, memory occupied by Mono, and the like, and the specific implementation process may be determined according to the characteristics of the tested performance data itself and by combining the above-described test methods for the two performance data, and the application does not limit the specific test mode.

as shown in fig. 9, a block diagram of a test client provided in this embodiment of the present application is a structure diagram of the test client, where the test client may be loaded on a test terminal, and the test terminal may be a computer device, and the present application does not limit a specific product type of the test client, and then the test client may include:

The first communication module 21 is configured to establish a communication connection with the terminal to be tested after the test client is started;

as described in the corresponding part of the above method embodiment, when a certain type of application program in the terminal under test needs to be tested, the terminal under test can be connected to the test terminal after the test client is started on the test terminal, thereby implementing communication between the terminal under test and the test client.

The test client may communicate with the terminal to be tested in a socket communication manner, but is not limited thereto.

The target application program determining module 22 is configured to determine a target application program meeting preset requirements in the terminal to be tested, and inject a dynamic library file corresponding to the target application program into the application program of the target application program through the first communication module, so that the terminal to be tested executes the dynamic library file, and invokes engine interfaces corresponding to different resource objects one to one; when the target application program is operated by the tested terminal, various resource object data of the target application program, which are obtained and sent by the tested terminal, are received through the first communication module;

Alternatively, in practical applications, as shown in fig. 10, the target application determination module 22 may include:

the detection unit 221 is configured to detect and display all application programs meeting requirements in the terminal to be detected;

The determining unit 222 is configured to obtain selection instructions for all currently displayed application programs, and determine a target application program for the current test.

For the process of determining the target application in the terminal to be tested, reference may be made to the description of the corresponding part of the above method embodiment, and this embodiment is not described in detail here.

In practical application, after the test client determines the target application program, the dynamic library file corresponding to the target application program can be called through the calling module.

and the output module 23 is configured to detect a data viewing instruction for any resource object, and output corresponding resource object data according to a preset manner.

In this embodiment, after receiving various resource object data of the target application program, the testing client may analyze the various resource object data to obtain corresponding various resource object data graphs and the like, such as the output form of the resource object data shown in fig. 4(e), but is not limited to this.

optionally, the output module 23 may further output a test window, as shown in fig. 4(a) to (d), where the test window may include a completed memory test step and a prompt message for indicating a next memory test step.

In summary, the test client establishes communication connection with the target application program of the tested terminal, and sends the dynamic library file corresponding to the target application program to the application of the target application program, so that after the tested terminal completes initialization, and during the period of realizing various functions of the target application program, the tested terminal uses the dynamic library file to call an engine interface, acquires various resource object data, and feeds the data back to the test client in real time for display, so that developers can intuitively know the memory occupation condition of various resource objects in the running process of the target application program at the tested terminal, the developers can accordingly optimize the performance of the target application program in a targeted manner, and the optimization efficiency is greatly improved.

Optionally, on the basis of the above test client embodiment, as shown in fig. 11, the test client may further include:

And the second communication module 24 is configured to synchronize the received various resource object data to the server, so that the server analyzes the various resource object data and generates a test report for the target application program.

For the specific process of analyzing various resource objects by the server and generating the test report, reference may be made to the description of the corresponding part of the above method embodiment, and this implementation is not described herein again.

in addition, in order to enable other users to view the test data of the target application in real time, as shown in fig. 12, the test client may further include:

a data viewing mode switching module 25, configured to trigger the test client to switch to a web page data viewing mode;

And the third communication module 26 is configured to send the switched URL address to the second terminal, so that the second terminal displays various resource object data received by the test client.

based on the method, after the terminal of the other user, namely the second terminal receives the URL address, the terminal can enter the webpage test interface which is the same as the test terminal, and the test process of the test client to the target application program in the tested terminal can be known in real time.

the embodiment of the present application further provides a memory test system, where the parameters are shown in the structural diagram of fig. 1, and the test system may include: the system comprises a tested terminal 100 and a test terminal 200, wherein the test terminal 200 is loaded with a test client;

the testing client is used for establishing communication connection with the tested terminal after being started, determining a target application program meeting preset requirements in the tested terminal, and injecting a dynamic library file corresponding to the target application program into the application program of the target application program;

the terminal 200 under test is configured to receive a dynamic library file sent by the test client for a target application program in the terminal under test, inject the dynamic library file into an application process of the target application program and execute the dynamic library file, call engine interfaces corresponding to different resource objects one to one, obtain, during running the target application program, various resource object data for the target application program through the called engine interfaces, and send the obtained various resource object data of the target application program to the test client, so that the test client detects a data viewing instruction for any resource object and outputs corresponding resource object data according to a preset manner.

Optionally, in order to implement data sharing, the test system may further include a server 300, where:

The server 300 is configured to synchronize various resource object data for the target application received by the testing client, analyze the various resource object data, and generate a testing report for the target application.

It should be noted that, for the specific function implementation process of each component in the embodiment of the present system, reference may be made to the description of the corresponding part in the foregoing method embodiment, and this implementation is not described herein again.

in summary, in the embodiment of the application, the real-time memory occupation situation of each subdivided resource of the target application can be obtained in the running process of the target application, that is, various resource object data is obtained, so that a developer can accurately position a resource object with excessively high memory occupation in a real application scene according to a test result, and the performance optimization efficiency of the target application is greatly improved.

finally, it should be noted that, in the embodiments, relational terms such as first, second and the like may be used solely to distinguish one operation, unit or module from another operation, unit or module without necessarily requiring or implying any actual such relationship or order between such units, operations or modules. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method or system that comprises the element.

the embodiments in the present description are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description.

those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

the previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (17)

1. a memory test method is applied to a tested terminal, and the method comprises the following steps:

establishing communication connection with a test client loaded on a test terminal;

Receiving a dynamic library file sent by the test client aiming at a target application program in the tested terminal;

Injecting the dynamic library file into an application process of the target application program and executing the dynamic library file, and calling engine interfaces corresponding to different resource objects one to one;

Running the target application program, and acquiring various resource object data aiming at the target application program through a called engine interface, wherein the resource object data comprises at least one of the resource object number and the memory statistics occupied by the resource objects;

sending the obtained various resource object data of the target application program to the test client for output;

Obtaining various resource object data for the target application program through the called engine interface, wherein the obtaining includes:

Statically analyzing a dynamic library file to obtain an offset address of a target function in the dynamic library file;

determining the operation address of the target function by using the base address of the dynamic library file and the offset address, and converting the operation address into a function pointer of the target function;

calling a target function by using the function pointer;

And operating the target function to obtain the memory data occupied by various resource objects of the currently operated target application program.

2. The method of claim 1, wherein obtaining, through the invoked engine interface, various resource object data for the target application comprises:

and determining the total number of various resource objects of the currently running target application program by using the HOOK function in the dynamic library file.

3. A memory test method is applied to a test client, wherein the test client is loaded on a test terminal, and the method comprises the following steps:

after the test client is started, establishing communication connection with a tested terminal;

Determining a target application program which meets the preset requirement in the tested terminal;

injecting the dynamic library file corresponding to the target application program into an application process of the target application program so that the tested terminal executes the dynamic library file and calls engine interfaces corresponding to different resource objects one to one;

When the target application program is operated by the tested terminal, receiving various resource object data of the target application program, which are obtained and sent by the tested terminal, wherein the resource object data comprise at least one of the number of resource objects and the memory statistics occupied by the resource objects, and various resource data objects of the target application program are obtained by the tested terminal through a called engine interface;

detecting a data viewing instruction aiming at any resource object, and outputting corresponding resource object data according to a preset mode;

The specific process of obtaining various resource data objects of the target application program through the calling engine interface comprises the following steps:

statically analyzing a dynamic library file to obtain an offset address of a target function in the dynamic library file;

determining the operation address of the target function by using the base address of the dynamic library file and the offset address, and converting the operation address into a function pointer of the target function;

calling a target function by using the function pointer;

And operating the target function to obtain the memory data occupied by various resource objects of the currently operated target application program.

4. The method of claim 3, further comprising:

and synchronizing the received various resource object data to a server through the test terminal so that the server analyzes the various resource object data and generates a test report aiming at the target application program.

5. the method of claim 3, further comprising:

Triggering the test client to switch to a webpage data viewing mode;

And sending the switched URL address to a second terminal so that the second terminal displays various resource object data received by the test client.

6. The method according to claim 3, wherein the determining the target application meeting the preset requirement in the tested terminal comprises:

Detecting and displaying all application programs meeting requirements in the tested terminal;

And obtaining selection instructions aiming at all the currently displayed application programs, and determining the target application program of the test.

7. the method according to claim 3, wherein after determining the target application meeting the preset requirement in the tested terminal, the method further comprises:

And calling a dynamic library file corresponding to the target application program.

8. The method according to claim 3, wherein the establishing of the communication connection with the terminal under test is specifically:

And establishing communication connection with the tested terminal by adopting a socket communication mode.

9. The method according to any one of claims 3-8, further comprising:

and outputting a test window, wherein the test window comprises the completed memory test step and prompt information for indicating the next memory test step.

10. The terminal under test is characterized in that a plurality of application programs are arranged on the terminal under test, and the test terminal further comprises:

the communication module is used for establishing communication connection with a test client loaded on a test terminal and receiving a dynamic library file sent by the test client aiming at a target application program in the tested terminal;

The processing module is used for injecting the dynamic library file into an application process of the target application program and executing the dynamic library file, and calling engine interfaces corresponding to different resource objects one to one;

The data acquisition module is used for acquiring various resource object data aiming at the target application program through a called engine interface during the running of the target application program, wherein the resource object data comprises at least one of the number of resource objects and the memory statistics occupied by the resource objects, and the acquired various resource object data of the target application program is sent to the test client end through the communication module for output;

Wherein the data acquisition module comprises:

The target function calling unit is used for calling a target function in the dynamic library file;

The memory data acquisition unit is used for operating the target function and acquiring memory data occupied by various resource objects of the currently operated target application program;

wherein the objective function calling unit includes:

The analysis unit is used for statically analyzing the dynamic library file to obtain an offset address of the target function in the dynamic library file;

A function pointer determining unit, configured to determine an operation address of the target function by using the base address of the dynamic library file and the offset address, and convert the operation address into a function pointer of the target function;

And the function calling unit is used for calling the target function by using the function pointer.

11. the terminal under test of claim 10, wherein the data acquisition module comprises:

And the resource object quantity counting unit is used for determining the total number of various resource objects of the currently running target application program by utilizing the HOOK function in the dynamic library file.

12. A test client, wherein the test client is loaded on a test terminal, and wherein the test client comprises:

the first communication module is used for establishing communication connection with a tested terminal after the test client is started;

the target application program determining module is used for determining a target application program meeting preset requirements in a tested terminal, and injecting a dynamic library file corresponding to the target application program into an application process of the target application program through the first communication module, so that the tested terminal executes the dynamic library file and calls engine interfaces corresponding to different resource objects one by one; when the target application program is operated by the tested terminal, various resource object data of the target application program, which are obtained and sent by the tested terminal, are received through the first communication module, wherein the resource object data comprise at least one of the number of resource objects and memory statistics occupied by the resource objects, and various resource data objects of the target application program are obtained by the tested terminal through a called engine interface;

The output module is used for detecting a data viewing instruction aiming at any resource object and outputting corresponding resource object data according to a preset mode;

the specific process of obtaining various resource data objects of the target application program through the calling engine interface comprises the following steps:

Statically analyzing a dynamic library file to obtain an offset address of a target function in the dynamic library file;

Determining the operation address of the target function by using the base address of the dynamic library file and the offset address, and converting the operation address into a function pointer of the target function;

Calling a target function by using the function pointer;

And operating the target function to obtain the memory data occupied by various resource objects of the currently operated target application program.

13. The test client according to claim 12, wherein the test client further comprises:

And the second communication module is used for synchronizing the received various resource object data to the server so that the server analyzes the various resource object data and generates a test report aiming at the target application program.

14. The test client according to claim 12, wherein the test client further comprises:

the data viewing mode switching module is used for triggering the test client to switch to a webpage data viewing mode;

And the third communication module is used for sending the switched URL address to the second terminal so as to enable the second terminal to display various resource object data received by the test client.

15. the testing client of claim 12, wherein the target application determination module comprises:

the detection unit is used for detecting and displaying all application programs meeting the requirements in the terminal to be detected;

And the determining unit is used for obtaining selection instructions aiming at all the currently displayed application programs and determining the target application program of the test.

16. A memory test system, the system comprising: the system comprises a test terminal and a tested terminal, wherein the test terminal is loaded with a test client;

The test client is used for establishing communication connection with the tested terminal after being started, determining a target application program meeting preset requirements in the tested terminal, and injecting a dynamic library file corresponding to the target application program into an application process of the target application program;

The tested terminal is used for receiving a dynamic library file sent by the testing client aiming at a target application program in the tested terminal, injecting the dynamic library file into an application process of the target application program and executing the dynamic library file, calling engine interfaces corresponding to different resource objects one to one, obtaining various resource object data aiming at the target application program through the called engine interfaces during the running of the target application program, wherein the resource object data comprises at least one of resource object number and memory statistics occupied by the resource objects, and sending the obtained various resource object data of the target application program to the testing client so that the testing client detects a data viewing instruction aiming at any resource object and outputs corresponding resource object data according to a preset mode;

obtaining various resource object data for the target application program through the called engine interface, wherein the obtaining includes:

Statically analyzing a dynamic library file to obtain an offset address of a target function in the dynamic library file;

Determining the operation address of the target function by using the base address of the dynamic library file and the offset address, and converting the operation address into a function pointer of the target function;

Calling a target function by using the function pointer;

And operating the target function to obtain the memory data occupied by various resource objects of the currently operated target application program.

17. the system of claim 16, further comprising:

And the server is used for synchronizing various resource object data aiming at the target application program and received by the testing client, analyzing the various resource object data and generating a testing report aiming at the target application program.