WO2018103245A1 - 一种界面卡顿监测方法、装置及可读取存储介质 - Google Patents

一种界面卡顿监测方法、装置及可读取存储介质 Download PDF

Info

Publication number
WO2018103245A1
WO2018103245A1 PCT/CN2017/079611 CN2017079611W WO2018103245A1 WO 2018103245 A1 WO2018103245 A1 WO 2018103245A1 CN 2017079611 W CN2017079611 W CN 2017079611W WO 2018103245 A1 WO2018103245 A1 WO 2018103245A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface
monitored
terminal
determining
memory
Prior art date
Application number
PCT/CN2017/079611
Other languages
English (en)
French (fr)
Inventor
张磊
Original Assignee
武汉斗鱼网络科技有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 武汉斗鱼网络科技有限公司 filed Critical 武汉斗鱼网络科技有限公司
Publication of WO2018103245A1 publication Critical patent/WO2018103245A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3024—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a central processing unit [CPU]

Definitions

  • the present invention relates to the field of terminal technologies, and in particular, to an interface card monitoring method and apparatus, and a readable storage medium.
  • the commonly used method is that the tester performs multiple tests on the terminal device, and the tester finds the stuck in the test process.
  • the developer reproduces the problem to obtain the log information of the terminal when the card is stuck, and then analyzes the cause of the occurrence of the card.
  • an embodiment of the present invention provides an interface card monitoring method, where the method includes:
  • log information in a time period between the sending time and the receiving time, where the log information includes the central processor occupation information, when it is determined that the interface to be monitored has an interface jam.
  • the memory occupation information and the debugging information of the currently running program are included in the log information.
  • the embodiment of the present invention provides the first possible implementation manner of the foregoing first aspect, wherein the determining, according to the sending time, the receiving time, and the interface jam threshold, determining the waiting Monitor the terminal for interface jams, including:
  • the embodiment of the present invention provides the second possible implementation manner of the foregoing first aspect, wherein the method further includes:
  • the embodiment of the present invention provides the third possible implementation manner of the foregoing first aspect, wherein the sending the log file to the server includes:
  • the log file is smaller than the preset threshold, the log file is saved in the terminal to be monitored.
  • the embodiment of the present invention provides the fourth possible implementation manner of the foregoing first aspect, wherein the interface of the terminal to be monitored is determined according to performance indicators of a central processing unit and a memory of the terminal to be monitored.
  • the Carton threshold including:
  • the embodiment of the present invention provides the fifth possible implementation manner of the foregoing first aspect, wherein, according to the performance indicators of the central processing unit and the memory, Determining the hardware score of the terminal to be monitored, including:
  • the embodiment of the present invention provides the sixth possible implementation manner of the foregoing first aspect, wherein the rating according to the central processing unit and the memory rating Determining the hardware score of the terminal to be monitored, including:
  • the embodiment of the present invention provides the seventh possible implementation manner of the foregoing first aspect, wherein the message sender Handler of the interface thread sends a monitoring message to the message queue corresponding to the interface thread.
  • an interface card monitoring device where the device includes:
  • a determining module configured to determine an interface jam threshold of the terminal to be monitored according to a performance indicator of a central processor and a memory of the terminal to be monitored;
  • the first sending module is configured to send a monitoring message to the message queue corresponding to the interface thread in real time or periodically, and record the sending time of the monitoring message, where the monitoring message carries a message identifier;
  • the processing module is configured to process the message in the message queue in sequence, and when receiving the processing request of the monitoring message carrying the message identifier, record the receiving time of the processing request corresponding to the monitoring message;
  • the determining module is configured to determine, according to the sending time, the receiving time, and the interface jam threshold, whether the interface to be monitored has an interface jam;
  • Obtaining a module configured to: when it is determined that the interface to be monitored has an interface jam, obtain log information of the time period between the sending time and the receiving time of the to-be-monitored terminal, where the log information includes the
  • the central processor occupies information, the memory occupation information, and debugging information of the currently running program.
  • the embodiment of the present invention provides the first possible implementation manner of the foregoing second aspect, wherein the determining module includes:
  • a first determining unit configured to determine a time difference between the sending time and the receiving time
  • a comparing unit configured to compare the time difference value with the interface carding threshold
  • the second determining unit is configured to determine that the interface to be monitored has an interface jam when the time difference is greater than or equal to the interface jam threshold.
  • the embodiment of the present invention provides the second possible implementation manner of the foregoing second aspect, wherein the device further includes:
  • Writing to the module configured to write the obtained log information into a log file of the terminal to be monitored;
  • a sending module configured to send the log file to a server.
  • the embodiment of the present invention provides a third possible implementation manner of the foregoing second aspect, wherein the sending module includes:
  • a comparing unit configured to compare the size of the log file with a preset threshold
  • a sending unit configured to send the log file to a server when the log file is greater than or equal to the preset threshold
  • the storage unit is configured to save the log file in the to-be-monitored terminal when the log file is smaller than the preset threshold.
  • the embodiment of the present invention provides the fourth possible implementation manner of the foregoing second aspect, wherein the determining module includes:
  • a scoring unit configured to determine a hardware score of the to-be-monitored terminal according to performance indicators of the central processor and the memory;
  • the threshold determining unit is configured to determine an interface jam threshold of the to-be-monitored terminal according to the hardware score.
  • the embodiment of the present invention provides the fifth possible implementation manner of the foregoing second aspect, wherein the determining unit determines the hardware score of the terminal to be monitored, including:
  • the embodiment of the present invention provides the sixth possible implementation manner of the foregoing second aspect, wherein the determining unit determines the hardware rating of the terminal to be monitored, including:
  • the embodiment of the present invention provides the seventh possible implementation manner of the foregoing second aspect, wherein the first sending module sends a monitoring message to the interface thread by using a message sender Handler of the interface thread. Corresponding message queue.
  • an embodiment of the present invention provides a readable storage medium stored in an electronic terminal, where the readable storage medium includes a plurality of instructions, and the multiple instructions are configured to implement the interface jam Monitoring method.
  • the embodiment of the invention provides an interface card monitoring method and device, and a readable storage medium.
  • the method realizes automatic monitoring of the interface jam, and when the interface jam is detected, the log during the jam is obtained.
  • the information is convenient for developers to analyze the causes of the Caton, and avoids the log information during the cardoting by recurring the problem, saving a lot of manpower and time.
  • Embodiment 1 is a flowchart of an interface card monitoring method provided by Embodiment 1 of the present invention.
  • FIG. 2 is a flowchart of determining whether an interface jam occurs in an interface card monitoring method according to Embodiment 1 of the present invention
  • FIG. 3 is a flowchart of determining a hardware score of a terminal to be monitored in an interface card monitoring method provided by Embodiment 1 of the present invention
  • FIG. 4 is a schematic structural diagram of an interface card monitoring device according to Embodiment 2 of the present invention.
  • an embodiment of the present invention provides an interface card monitoring method and apparatus, which are described below by way of embodiments.
  • the embodiment of the invention provides a method for monitoring the interface jam. As shown in FIG. 1 , when the interface is used for the interface jam monitoring, the method includes the steps S110-S150, as follows.
  • S110 Determine an interface threshold of the terminal to be monitored according to performance indicators of the central processing unit and the memory of the terminal to be monitored.
  • the terminal to be monitored may be, but is not limited to, a mobile phone, a tablet computer, a computer, or the like.
  • the terminal There are many reasons for causing the terminal to be stuck. It is mainly affected by the performance of the terminal hardware. When the amount of tasks that the terminal needs to handle is the same, if the hardware performance of the terminal is high, the terminal can complete the task in a short time. If the hardware performance of the terminal is very low, the terminal takes a long time to complete the above task.
  • the termination of the terminal interface is mainly determined by the central processing unit (CPU) and the memory on the terminal. Therefore, in the embodiment of the present invention, the central processing unit and the memory interface are mainly considered. Influence, according to the performance indicators of the central processor and the memory, determine the interface threshold of the terminal to be monitored.
  • the determining, according to the performance indicators of the central processing unit and the memory, the threshold of the interface to be monitored specifically: determining the hardware score of the terminal to be monitored according to the performance indicators of the central processor and the memory; determining the Monitor the interface's interface jam threshold.
  • the central processor and the memory are the most affected by the card. Therefore, in the present invention, the hardware score of the terminal to be monitored is determined according to the performance indicators of the central processor and the memory.
  • determining the hardware score of the terminal to be monitored according to the performance indicators of the central processing unit and the memory includes steps S210-S240, as follows.
  • S230 Determine a memory score according to a performance indicator of the memory and a scoring rule of the memory.
  • S240 Determine a hardware score of the terminal to be monitored according to a score of the central processing unit and a score of the memory.
  • the two most important factors are the frequency of the central processor and the number of cores. Therefore, in the embodiment of the present invention, when scoring the central processing unit, the main frequency and the number of cores of the central processing unit are mainly considered.
  • the probability of causing the interface to be stuck is smaller, that is, the higher the hardware score of the central processing unit, the more the number of cores of the central processing unit is, the smaller the probability of causing the interface to be jammed, that is, The higher the hardware score of the central processor.
  • the scoring rule of the central processor can be set according to the probability of causing the interface to be stuck, that is, the larger the main frequency, the higher the score of the central processor, and in a specific embodiment, the central processor of the different main frequency corresponds.
  • the scores are shown in Table 1.
  • the corresponding score is 20 minutes.
  • the corresponding score of the central processor is 30 minutes, when the primary frequency is greater than or equal to At 2G, the CPU scores 50 points.
  • the above table 1 only gives a scoring rule of the main frequency, and does not limit the score corresponding to each frequency band.
  • the score corresponding to each frequency band may also be other values, as long as the main frequency is satisfied, the score is more The principle of high can be.
  • the scoring rules corresponding to the number of core processors of different cores are as shown in Table 2.
  • the score corresponding to the central processing unit is 20 points, and when the number of cores is greater than 1 and less than or equal to 2, the central processing unit corresponds The score is 30 points.
  • the CPU scores 40 points When the number of cores is greater than 4 and less than or equal to 8, the CPU scores 50 points.
  • Table 2 only gives a scoring rule corresponding to the number of cores, and does not limit the scores corresponding to each core.
  • the scores corresponding to the different numbers of cores may also be other values, as long as the number of cores is satisfied.
  • the principle of higher scores can be.
  • Table 1 and Table 2 above show a possible scoring rule. If the central processor of the terminal to be monitored has a clock frequency of 2.51G and the number of cores is 8 cores, the terminal to be monitored can be obtained from Table 1 above.
  • the CPU's main frequency score is 50 points
  • the memory of the terminal to be monitored directly affects the capacity of the terminal to be monitored.
  • the larger the capacity of the terminal to be monitored the lower the probability of causing the interface to be stuck.
  • the smaller the capacity of the terminal to be monitored the higher the probability of causing the interface to be stuck.
  • the larger the memory of the terminal to be monitored the lower the probability of causing the interface to be stuck.
  • the higher the memory score the smaller the memory of the terminal to be monitored, the higher the probability of causing the interface to be stuck, and the lower the memory score.
  • the memory corresponding scoring rules are as shown in Table 3.
  • the memory score of the terminal device is 20 points, and when the memory capacity is greater than 512 M and less than or equal to 1 G, the memory corresponding score is 40 points.
  • the memory corresponding score is 60 points.
  • the memory corresponding score is 80 points.
  • the memory corresponding score It is 100 points.
  • Table 3 above only gives one of the possible memory scoring rules, and does not limit the specific score corresponding to each stage of memory.
  • the corresponding memory score of each stage can also be other values, memory. As long as the memory is larger, the memory score is higher.
  • the single-score score of the central processor and the memory of the terminal to be monitored can be separately determined, and then the hardware score of the terminal to be monitored is determined according to the score of the central processor and the score of the memory, which specifically includes: determining the central processing separately The weight of the device and the memory; the hardware score of the terminal to be monitored is determined according to the score of the central processor, the weight of the central processor, the score of the memory, and the weight of the memory.
  • the central processor compared with the memory, the central processor has a greater impact on the interface jam, so the weight of the central processor is greater than the weight of the memory.
  • the hardware score of the terminal to be monitored can be calculated by the following formula.
  • M is the hardware score of the terminal to be monitored
  • a is the score of the central processor
  • b% is the weight of the central processor
  • c is the score of the memory
  • d% is the weight of the memory.
  • the system can be calculated according to the above formula.
  • the hardware rating of the terminal is 88.
  • the interface card threshold of the terminal to be monitored is determined according to the hardware score of the terminal to be monitored.
  • the response speed of the terminal to be monitored varies with the hardware performance. For the same amount of tasks, if the end If the hardware performance of the terminal is high, the amount of the task can be completed in a short period of time. If the hardware performance of the terminal is low, it takes a long time to complete the above task. Therefore, when the interface to be monitored is subjected to interface jam monitoring.
  • the interface card threshold is set according to the hardware performance of the terminal to be monitored, that is, the interface threshold of the terminal to be monitored is determined according to the hardware score of the terminal to be monitored.
  • the interface threshold of the terminal If the hardware score of the terminal is high, you can set the interface threshold of the terminal to be smaller. If the hardware score of the terminal is lower, you can set the interface threshold to be larger.
  • the foregoing only provides a correspondence between the hardware score and the interface card threshold.
  • the different hardware scores may also correspond to other interface thresholds.
  • the embodiment of the present invention does not have the specific interface.
  • the Karton threshold and the division of the hardware score are defined.
  • the interface threshold of the terminal to be monitored After determining the hardware score of the terminal to be monitored, according to the hardware score of the terminal to be monitored and the corresponding relationship, the interface threshold of the terminal to be monitored can be determined.
  • S120 Send a monitoring message to the message queue corresponding to the interface thread in real time or periodically, and record the sending time of the monitoring message, where the monitoring message carries a message identifier.
  • the application is applied to the Android system, and when the interface monitoring is performed on the terminal to be monitored, the monitoring message needs to be sent to the message queue corresponding to the interface thread in real time or periodically.
  • the monitoring message may be an empty message, and the message carried by the monitoring message may be an identifier (ID) of the monitoring message.
  • ID identifier
  • the sending time of the message is recorded.
  • the message sender Handler of the interface thread may send a monitoring message to the message queue corresponding to the interface thread.
  • the interface thread includes a thread with a message loop (Lopper), and the Lopper of the message loop is the core logic of the message loop.
  • Lopper works in interface threads, and the main task is to loop through the message.
  • Lopper performs message processing by means of wireless loop. When Lopper finds a message, it will take the message and send it to the message queue. If no message is found, it will poll poll in place.
  • the Handler is a tool for sending a message
  • the constructor of the Handler gets the instance object of the Handler. You need to use the Lopper object in the constructor. You can get the Lopper object by calling the Lopper.getLopper function.
  • the monitoring message may be sent to the message queue of the interface thread by using the sendEmptyMessage function in the Handler.
  • the above can record the sending time of the above monitoring message through the Handler's system.currenttimemillis function.
  • S130 Process the messages in the message queue in sequence, and when receiving the processing request that carries the monitoring message of the message identifier, record the receiving time of the processing request corresponding to the monitoring message.
  • the terminal to be monitored continuously distributes the message in the message queue to the message processing function corresponding to the Handler according to the order of the message in the message queue, and the message processing function corresponding to the Handler follows the received message.
  • the sequence processes the message.
  • the message processing function corresponding to the Handler processes the monitoring message, and records the monitoring message and the processing request. Reception time.
  • the message processing function corresponding to the Handler may be a handlerMessage.
  • S140 Determine, according to the sending time, the receiving time, and the interface jam threshold, whether the interface to be monitored has an interface jam.
  • the foregoing determining whether the interface to be monitored has an interface jam according to the sending time, the receiving time, and the interface jam threshold includes steps S310-S330, as follows.
  • t2-t1 is determined as the time difference value.
  • the time difference is compared with the interface jam threshold of the terminal to be monitored. If the time difference is less than the interface jam threshold, it indicates that the interface to be monitored does not have an interface jam, and no processing is performed; if the time difference is If the value is greater than or equal to the interface threshold, it indicates that the interface to be monitored has an interface jam.
  • the time period between the above-mentioned transmission time and the reception time is determined to be an interface jam, that is, the time period is the interface jam period.
  • the occupancy information of the central processing unit can be obtained by calling the top command, and the occupied memory is used.
  • the information can be obtained by calling the dumpsys memory command.
  • the debugging information of the above running program may include debugging information added by the developer when the program is developed, and the debugging information of the above time period may be obtained by calling the logcat command.
  • the obtained log information is written to the log file of the terminal to be monitored; the log file is sent to the server.
  • the log file is not sent to the server every time the log information is written to the log file. Therefore, the log file is sent to the server, including:
  • the log file is sent to the server;
  • the log file is smaller than the preset threshold, the log file is saved in the terminal to be monitored.
  • the preset threshold is a preset value, and the value may be set to 1M, and may be set to other values.
  • the specific size of the preset threshold is not limited in the embodiment of the present invention.
  • the log file When the size of the log file is greater than or equal to a preset threshold, in order to save upload traffic, the log file is compressed, and the compressed file is sent to the server, so that the developer can analyze the appearance of the interface according to the log file. the reason.
  • the log file is first saved in the monitoring terminal.
  • the size of the log file is greater than or equal to the preset threshold, and then the log file is sent to the server.
  • the interface card monitoring method provided by the embodiment of the invention realizes the automatic monitoring of the interface jam, and when the interface jam is detected, the log information during the jam is obtained, which is convenient for the developer to cause the cause of the jam.
  • the analysis avoids the log information during the cardoting by recurring the problem, saving a lot of manpower and time.
  • An embodiment of the present invention provides an interface card monitoring device. As shown in FIG. 4, the device includes a determining module 410, a first sending module 420, a processing module 430, a determining module 440, and an obtaining module 450.
  • the determining module 410 is configured to determine an interface jam threshold of the terminal to be monitored according to performance indicators of the central processing unit and the memory of the terminal to be monitored.
  • the determining module 410 may include: a scoring unit and a threshold determining unit.
  • the scoring unit is configured to determine a hardware score of the to-be-monitored terminal according to the performance indicators of the central processor and the memory.
  • the manner in which the scoring unit determines the hardware score of the terminal to be monitored includes:
  • the manner in which the scoring unit determines the hardware score of the terminal to be monitored includes:
  • the threshold determining unit is configured to determine an interface jam threshold of the to-be-monitored terminal according to the hardware score.
  • the first sending module 420 is configured to send a monitoring message to the message queue corresponding to the interface thread in real time or periodically, and record the sending time of the monitoring message, where the monitoring message carries a message identifier.
  • the first sending module 420 sends a monitoring message to the message queue corresponding to the interface thread by using the message sender Handler of the interface thread.
  • the processing module 430 is configured to process the messages in the message queue in sequence, and when receiving the processing request that carries the monitoring message of the message identifier, record the receiving time of the processing request corresponding to the monitoring message.
  • the determining module 440 is configured to determine whether the interface to be monitored has an interface jam according to the sending time, the receiving time, and the interface jam threshold.
  • the determining module 440 determines whether the interface to be monitored has an interface jam according to the sending time, the receiving time, and the interface jam threshold.
  • the first determining unit, the comparing unit, and the second determining unit are implemented by using the first determining unit, the comparing unit, and the second determining unit.
  • the first determining unit is configured to determine a time difference between the sending time and the receiving time; the comparing unit is configured to compare the time difference value with an interface carding threshold; the second determining unit is configured to be configured as described above When the time difference is greater than or equal to the interface threshold, it is determined that the interface to be monitored has an interface jam.
  • the obtaining module 450 is configured to: when determining that the interface to be monitored has an interface jam, obtain log information in a time period between the sending time and the receiving time of the terminal to be monitored, where the log information includes central processor occupation information and memory occupation information. And debugging information of the currently running program.
  • the foregoing apparatus may further include: a writing module and a sending module.
  • the writing module is configured to write the obtained log information into a log file of the terminal to be monitored.
  • the sending module is configured to send the log file to a server.
  • the foregoing sending module may include: a comparing unit, a sending unit, and a storage unit.
  • the comparing unit is configured to compare the size of the log file with a preset threshold.
  • the sending unit is configured to send the log file to the server when the log file is greater than or equal to the preset threshold.
  • the storage unit is configured to save the log file in the to-be-monitored terminal when the log file is smaller than the preset threshold.
  • the interface card monitoring device provided by the embodiment of the invention realizes the automatic monitoring of the interface jam, and when the interface jam is detected, the log information during the jam is obtained, which is convenient for the developer to cause the cause of the jam.
  • the analysis avoids the log information during the cardoting by recurring the problem, saving a lot of manpower and time.
  • the interface card monitoring device provided by the embodiment of the present invention may be specific hardware on the device or software or firmware installed on the device.
  • the implementation principle and the technical effects of the device provided by the embodiments of the present invention are the same as those of the foregoing method embodiments.
  • the device embodiment is not mentioned, reference may be made to the corresponding content in the foregoing method embodiments.
  • a person skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working processes of the foregoing system, the device and the unit can refer to the corresponding processes in the foregoing method embodiments, and details are not described herein again.
  • the disclosed apparatus and method may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some communication interface, device or unit, and may be electrical, mechanical or otherwise.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in the embodiment provided by the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the functions may be stored in a computer readable storage medium if implemented in the form of a software functional unit and sold or used as a standalone product.
  • the technical solution of the present invention which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including
  • the instructions are used to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种界面卡顿监测方法、装置及可读存储介质，所述界面卡顿监测方法包括根据待监测终端的中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值（S110）；实时或定期发送监测消息给界面线程对应的消息队列，并记录发送时间，该监测消息携带有消息标识（S120）；对消息队列中的消息按序进行处理，当接收到上述监测消息的处理请求时，记录接收时间（S130）；根据发送时间、接收时间和界面卡顿阈值，判断是否出现界面卡顿（S140）；当确定出现界面卡顿时，获取待监测终端在出现卡顿时间段内的日志信息（S150）。该方法实现了界面卡顿的自动监测，且在监测到出现界面卡顿时，获取卡顿期间的日志信息，方便开发人员分析引起卡顿的原因，避免了通过问题复现获取卡顿期间的日志信息，节省了大量的人力和时间。

Description

一种界面卡顿监测方法、装置及可读取存储介质
本申请要求于2016年12月08日提交中国专利局、申请号为CN201611123865.2、发明名称为“一种界面卡顿监测方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及终端技术领域，具体而言，涉及一种界面卡顿监测方法、装置及可读取存储介质。
背景技术
当用户在使用手机、平板电脑及电脑等终端设备时，经常会出现界面卡顿现象，比如说，当用户在玩游戏的时候，或者听歌的时候经常会出现画面滞帧，这就是卡顿现象，卡顿现象也就是人们通常所述的“卡”。
而引起界面卡顿的原因有很多，现有技术中，为了分析出现界面卡顿的原因，通常采用的方法就是由测试人员对终端设备进行多次测试，当测试人员在测试过程中发现卡顿现象时，由开发人员对问题进行复现，以获取出现卡顿时终端的日志信息，进而分析出现卡顿的原因。
但是，采用现有技术中的方法进行界面卡顿的测试，需要投入大量的测试人员对终端设备进行反复测试，导致人力资源的浪费，并且，当出现卡顿时，为了获取出现卡顿时的日志信息，还得由开发人员对问题进行复现，耗费大量的时间。
发明内容
有鉴于此，本发明实施例的目的在于提供一种界面卡顿监测方法、装置及可读取存储介质，以试图解决或者缓解上述出现的问题。
第一方面，本发明实施例提供了一种界面卡顿监测方法，其中，所述方法包括：
根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值；
实时或定期发送监测消息给界面线程对应的消息队列，并记录所述监测消息的发送时间，所述监测消息携带有消息标识；
对所述消息队列中的消息按序进行处理，当接收到携带有所述消息标识的所述监测消息的处理请求时，记录所述监测消息对应的处理请求的接收时间；
根据所述发送时间、所述接收时间和所述界面卡顿阈值,判断所述待监测终端是否出现界面卡顿；
当确定所述待监测终端出现界面卡顿时，获取所述待监测终端在所述发送时间和所述接收时间之间的时间段内的日志信息，所述日志信息包括所述中央处理器占用信息、所述内存占用信息及当前运行程序的调试信息。
结合第一方面，本发明实施例提供了上述第一方面的第一种可能的实现方式，其中，所述根据所述发送时间、所述接收时间和所述界面卡顿阈值,判断所述待监测终端是否出现界面卡顿，包括：
确定所述发送时间和所述接收时间之间的时间差值；
将所述时间差值与所述界面卡顿阈值进行比较；
当所述时间差值大于或等于所述界面卡顿阈值时，确定所述待监测终端出现界面卡顿。
结合第一方面，本发明实施例提供了上述第一方面的第二种可能的实现方式，其中，所述方法还包括：
将获取的所述日志信息生成待监测终端的日志文件；
将所述日志文件发送给服务器。
结合第一方面的第二种可能的实现方式，本发明实施例提供了上述第一方面的第三种可能的实现方式，其中，所述将所述日志文件发送给服务器，包括：
将所述日志文件的大小与预设阈值进行比较；
当所述日志文件大于或等于所述预设阈值时，将所述日志文件发送给服务器；
当所述日志文件小于所述预设阈值时，将所述日志文件保存在所述待监测终端。
结合第一方面，本发明实施例提供了上述第一方面的第四种可能的实现方式，其中，所述根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值，包括：
根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分；
根据所述硬件评分，确定所述待监测终端的界面卡顿阈值。
结合第一方面的第四种可能的实现方式，本发明实施例提供了上述第一方面的第五种可能的实现方式，其中，所述根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分，包括：
分别确定所述中央处理器和所述内存的评分规则；
根据所述中央处理器的性能指标和所述中央处理器的评分规则，确定所述中央处理器 的评分；
根据所述内存的性能指标和所述内存的评分规则，确定所述内存的评分；
根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分。
结合第一方面的第五种可能的实现方式，本发明实施例提供了上述第一方面的第六种可能的实现方式，其中，所述根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分，包括：
分别确定所述中央处理器和所述内存的权重；
根据所述中央处理器的评分、所述中央处理器的权重、所述内存的评分和所述内存的权重，确定所述待监测终端的硬件评分。
结合第一方面，本发明实施例提供了上述第一方面的第七种可能的实现方式，其中，通过所述界面线程的消息发送者Handler发送监测消息给所述界面线程对应的消息队列。
第二方面，本发明实施例提供了一种界面卡顿监测装置，其中，所述装置包括：
确定模块，配置成根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值；
第一发送模块，配置成实时或定期发送监测消息给界面线程对应的消息队列，并记录所述监测消息的发送时间，所述监测消息携带有消息标识；
处理模块，配置成对所述消息队列中的消息按序进行处理，当接收到携带有所述消息标识的所述监测消息的处理请求时，记录所述监测消息对应的处理请求的接收时间；
判断模块，配置成根据所述发送时间、所述接收时间和所述界面卡顿阈值,判断所述待监测终端是否出现界面卡顿；
获取模块，配置成当确定所述待监测终端出现界面卡顿时，获取所述待监测终端在所述发送时间和所述接收时间之间的时间段内的日志信息，所述日志信息包括所述中央处理器占用信息、所述内存占用信息及当前运行程序的调试信息。
结合第二方面，本发明实施例提供了上述第二方面的第一种可能的实现方式，其中，所述判断模块，包括：
第一确定单元，配置成确定所述发送时间与所述接收时间之间的时间差值；
比较单元，配置成将所述时间差值与所述界面卡顿阈值进行比较；
第二确定单元，配置成当所述时间差值大于或等于所述界面卡顿阈值时，确定所述待监测终端出现界面卡顿。
结合第二方面，本发明实施例提供了上述第二方面的第二种可能的实现方式，其中，所述装置还包括：
写入模块，配置成将获取的所述日志信息写入待监测终端的日志文件；
发送模块，配置成将所述日志文件发送给服务器。
结合第二方面，本发明实施例提供了上述第二方面的第三种可能的实现方式，其中，所述发送模块包括：
比较单元，配置成将所述日志文件的大小与预设阈值进行比较；
发送单元，配置成当所述日志文件大于或等于所述预设阈值时，将所述日志文件发送给服务器；
存储单元，配置成当所述日志文件小于所述预设阈值时，将所述日志文件保存在所述待监测终端。
结合第二方面，本发明实施例提供了上述第二方面的第四种可能的实现方式，其中，所述确定模块包括：
评分单元，配置成根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分；
阈值确定单元，配置成根据所述硬件评分，确定所述待监测终端的界面卡顿阈值。
结合第二方面，本发明实施例提供了上述第二方面的第五种可能的实现方式，其中，所述评分单元确定所述待监测终端的硬件评分的方式，包括：
分别确定所述中央处理器和所述内存的评分规则；
根据所述中央处理器的性能指标和所述中央处理器的评分规则，确定所述中央处理器的评分；
根据所述内存的性能指标和所述内存的评分规则，确定所述内存的评分；
根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分。
结合第二方面，本发明实施例提供了上述第二方面的第六种可能的实现方式，其中，所述评分单元确定所述待监测终端的硬件评分的方式，包括：
分别确定所述中央处理器和所述内存的权重；
根据所述中央处理器的评分、所述中央处理器的权重、所述内存的评分和所述内存的权重，确定所述待监测终端的硬件评分。
结合第二方面，本发明实施例提供了上述第二方面的第七种可能的实现方式，其中，所述第一发送模块通过所述界面线程的消息发送者Handler发送监测消息给所述界面线程对应的消息队列。
第三方面，本发明实施例提供了一种存储于电子终端的可读取存储介质，其中，所述可读取存储介质包括多条指令，所述多条指令被配置成实现上述界面卡顿监测方法。
本发明实施例提供了一种界面卡顿监测方法、装置及可读取存储介质，该方法实现了界面卡顿的自动监测，并且，在监测到出现界面卡顿时，会获取卡顿期间的日志信息，方便开发人员对引起卡顿的原因进行分析，避免了通过问题复现来获取卡顿期间的日志信息，节省了大量的人力和时间。
为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本发明实施例1所提供的一种界面卡顿监测方法的流程图；
图2示出了本发明实施例1所提供的一种界面卡顿监测方法中判断是否出现界面卡顿的流程图；
图3示出了本发明实施例1所提供的一种界面卡顿监测方法中确定待监测终端的硬件得分的流程图；
图4示出了本发明实施例2所提供的一种界面卡顿监测装置的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有 其他实施例，都属于本发明保护的范围。
考虑到现有技术中，在检测终端是否出现界面卡顿时，通常采用的方法就是由测试人员对终端设备进行多次测试，当测试人员在测试过程中发现卡顿现象时，由开发人员对问题进行复现，以获取出现卡顿时终端的日志信息，进而分析出现卡顿的原因，但是，这样需要投入大量的测试人员，导致人力资源的浪费，并且，当出现卡顿时，为了获取出现卡顿时的日志信息，还得由开发人员对问题进行复现，耗费大量的时间。基于此，本发明实施例提供了一种界面卡顿监测方法及装置，下面通过实施例进行描述。
实施例1
本发明实施例提供了一种界面卡顿监测方法，如图1所示，采用该方法进行界面卡顿监测时，包括步骤S110-S150，具体如下。
S110，根据待监测终端的中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值。
上述待监测终端可以是，但不仅限于手机、平板电脑、计算机等。
引起终端卡顿的原因很多，主要还是受终端硬件性能高低的影响，当终端需要处理的任务量相同时，如果终端的硬件性能很高，则终端可以在很短的时间内完成该任务量，如果终端的硬件性能很低，则终端需要较长的时间才能完成上述任务量。
而终端界面出现卡顿，主要还是由终端上的中央处理器(Central Processing Unit，CPU)和内存来决定的，因此，在本发明实施例中，主要考虑中央处理器和内存对界面卡顿的影响，根据中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值。
其中，根据中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值，具体包括：根据中央处理器和内存的性能指标，确定待监测终端的硬件评分；根据上述硬件评分，确定待监测终端的界面卡顿阈值。
由于终端设备中，对卡顿影响最大的就是中央处理器和内存，因此，本发明中，根据中央处理器和内存的性能指标，确定待监测终端的硬件评分。
其中，作为一个实施例，如图2所示，根据中央处理器和内存的性能指标，确定待监测终端的硬件评分，包括步骤S210-S240，具体如下。
S210，分别确定中央处理器和内存的评分规则；
S220，根据中央处理器的性能指标和中央处理器的评分规则，确定中央处理器的评分；
S230，根据内存的性能指标和内存的评分规则，确定内存的评分；
S240，根据中央处理器的评分和内存的评分，确定待监测终端的硬件评分。
其中，对于中央处理器而言，最重要的两个因素就是中央处理器的主频和内核数量， 因此，在本发明实施例中，在对中央处理器进行评分时，主要考虑中央处理器的主频和内核数量。
当中央处理器的主频越高时，引起界面卡顿的概率越小，即中央处理器的硬件评分越高，当中央处理器的内核数量越多时，引起界面卡顿的概率越小，即中央处理器的硬件评分越高。
因此，可以按照引起界面卡顿的概率，设定中央处理器的评分规则，即主频越大，中央处理器的得分越高，在某个具体实施例中，不同主频的中央处理器对应的分数，如表1所示。
表1
主频 0-1G 1-2G 2G+
分数 20分 30分 50分
在上述表1中，当主频小于或等于1G时，对应的分数为20分，当主频大于1G且小于或等于2G时，中央处理器对应的得分为30分，当主频大于或等于2G时，中央处理器对应的得分为50分。
当然，上述表1中只是给出了一种主频的评分规则，并没有对各个频段对应的分数进行限定，上述各个频段对应的分数还可以是其它值，只要满足主频越大，分数越高的原则即可。
在某些具体实施例中，不同内核数量的中央处理器对应的评分规则，如表2所示。
表2
内核数量 1核心 2核心 4核心 8核心
分数 20分 30分 40分 50分
其中，在上述表2中，当中央处理器的内核数量小于或等于1个时，中央处理器对应的得分为20分，当内核数量大于1且小于或等于2个时，中央处理器对应的得分为30分，当内核数量大于2且小于或等于4时，中央处理器对应的得分为40分，当内核数量大于4且小于或等于8时，中央处理器对应的得分为50分。
当然，上述表2中只是给出了一种内核数量对应的评分规则，并没有对各个核心对应的分数进行限定，上述不同数量的内核对应的分数还可以是其它数值，只要满足内核数量越多，分数越高的原则即可。
上述表1和表2给出了一种可能的评分规则，如果待监测终端的中央处理器的主频为2.51G，内核的数量为8核，从上述表1中可以得出待监测终端的中央处理器的主频的得分为50分，内核的得分为50分，因此，待监测终端的中央处理器的评分为50+50＝100分， 即中央处理器的评分为主频得分和内核得分之和。
待监测终端内存直接影响的是待监测终端的容量，而待监测终端的容量越大，引起界面卡顿的概率越低，待监测终端的容量越小，引起界面卡顿的概率越高，即待监测终端的内存越大，引起界面卡顿的概率越低，内存的评分越高，待监测终端的内存越小，引起界面卡顿的概率越高，内存的评分越低。
因此，在确定内存的评分规则时，需要满足内存的容量越大，内存的评分越高的原则即可，在某个具体实施例中，内存对应的评分规则如表3所示。
表3
内存容量 512M 512M-1G 1G-2G 2G-4G 6G+
分数 20分 40分 60分 80分 100分
其中，在上述表3中，当终端设备的内容容量小于或等于512M时，终端设备的内存得分为20分，当内存容量大于512M且小于或等于1G时，内存对应的得分为40分，当内存容量大于1G且小于或等于2G时，内存对应的得分为60分，当内存容量大于2G且小于或等于4G时，内存对应的得分为80分，当内存容量大于6G时，内存对应的得分为100分。
当然，上述表3只是给出了其中一种可能的内存的评分规则，并没有对每个阶段内存对应的具体的分数进行限定，上述每个阶段对应的内存的得分还可以是其它数值，内存的评分规则只要满足内存越大，内存得分越高即可。
通过上述过程，可以分别确定的待监测终端的中央处理器和内存的单项评分，之后，则根据中央处理器的评分和内存的评分，确定待监测终端的硬件评分，具体包括：分别确定中央处理器和内存的权重；根据上述中央处理器的评分、中央处理器的权重、内存的评分和内存的权重，确定待监测终端的硬件评分。
其中，与内存相比较，中央处理器对引起界面卡顿的影响更大，因此，中央处理器的权重大于内存的权重。
当确定了中央处理器和内存的权重后，可以通过如下公式计算待监测终端的硬件评分，
M＝a×b％+c×d％
其中，在上述公式中，M为待监测终端的硬件评分，a为中央处理器的评分，b％为中央处理器的权重，c为内存的评分，d％为内存的权重。
比如说，在某个实施例中，如果中央处理器的评分为90，内存的评分为80，中央处理器的权重为80％，内存的权重为20％，则根据上式可以计算出待监测终端的硬件评分为88。
当确定了待监测终端的硬件评分后，根据待监测终端的硬件评分确定待监测终端的界面卡顿阈值。
待监测终端的响应速度随着硬件性能的高低而有所不同，对于相同的任务量，如果终 端的硬件性能较高，则可以在较短时间内完成该任务量，如果终端的硬件性能较低，则需要较长的时间才能完成上述任务量，因此，在对待监测终端进行界面卡顿监测时，需要根据待监测终端硬件性能设定界面卡顿阈值，即根据待监测终端的硬件评分，确定待监测终端的界面卡顿阈值。
如果终端的硬件评分较高，可以将终端的界面卡顿阈值设小一些，如果终端的硬件评分较低，可以将界面卡顿阈值设大一些。
当用户在使用终端设备时，如果终端设备的界面在1-2S内没有反应，用户通过肉眼就可以感受到终端的界面卡顿现象，因此，可以建立硬件评分与界面卡顿阈值之间的对应关系，其中，一种可能的对应关系具体如下：
60+：界面卡顿阈值1S
40<x≤60：界面卡顿阈值1.5S
20<x≤40:界面卡顿阈值2S
x≤20:界面卡顿阈值2.5S
当然，上述只是给出了其中一种硬件评分和界面卡顿阈值之间的对应关系，上述不同的硬件评分还可以对应其它数值的界面卡顿阈值，本发明实施例并没有对上述具体的界面卡顿阈值以及硬件评分的划分进行限定。
当确定了待监测终端的硬件评分后，根据待监测终端的硬件评分以及上述对应关系，就可以确定出待监测终端的界面卡顿阈值。
S120，实时或定期发送监测消息给界面线程对应的消息队列，并记录该监测消息的发送时间，该监测消息携带有消息标识。
优选地，在本实施例中，以应用于安卓***为例，在对待监测终端进行界面卡顿监测时，需要实时或定期发送监测消息给界面线程对应的消息队列。
其中，上述监测消息可以是空消息，该监测消息携带的消息表示可以是该监测消息的编码(Identity，ID)。
当发送监测消息给界面线程对应的消息队列后，记录该消息的发送时间。
其中，在本发明实施例中，可以通过界面线程的消息发送者Handler发送监测消息给界面线程对应的消息队列。
在安卓***中，界面线程包括一个有消息循环的线程(Lopper)，消息循环的Lopper是消息循环的核心逻辑。Lopper工作在界面线程，主要任务是进行消息循环。Lopper通过无线循环的方式进行消息处理，当Lopper发现有消息后，就会将消息取出来发送到消息队列中，如果没有发现消息，则在原地进行轮询查询。
在安卓***中，Handler是专门用于发送消息的工具，在本发明实施例中，可以通过 Handler的构造函数得到Handler的实例对象。在构造函数中需要使用Lopper对象，可以通过调用Lopper.getLopper函数来获取Lopper对象。
具体的，在本实施例中，可以通过Handler中的sendEmptyMessage函数发送监测消息给界面线程的消息队列中。
上述可以通过Handler的system.currenttimemillis函数记录上述监测消息的发送时间。
S130，对消息队列中的消息按序进行处理，当接收到携带有消息标识的监测消息的处理请求时，记录监测消息对应的处理请求的接收时间。
对于消息队列中的消息，待监测终端会不断的将消息队列中的消息按照消息的在消息队列中的顺序分发给Handler对应的消息处理函数进行处理，Handler对应的消息处理函数按照接收到的消息的顺序对消息进行处理，当接收到上述携带有消息标识的监测消息时以及对该消息进行处理的请求时，Handler对应的消息处理函数对该监测消息进行处理，并记录该监测消息以及处理请求的接收时间。
其中，上述Handler对应的消息处理函数可以是handlerMessage。
S140，根据上述发送时间、接收时间和界面卡顿阈值，判断待监测终端是否出现界面卡顿。
其中，作为一个实施例，如图3所示，上述根据发送时间、接收时间和界面卡顿阈值，判断待监测终端是否出现界面卡顿，包括步骤S310-S330，具体如下。
S310，确定上述发送时间和接收时间之间的时间差值；
S320，将上述时间差值与界面卡顿阈值进行比较；
S330，当上述时间差值大于或等于界面卡顿阈值时，确定待监测终端出现界面卡顿。
其中，如果上述记录的发送时间为t1,记录的接收时间为t2，则将t2-t1确定为上述时间差值。
将上述时间差值与待监测终端的界面卡顿阈值进行比较，如果上述时间差值小于界面卡顿阈值，则说明待监测终端没有出现界面卡顿，这时不做任何处理；如果上述时间差值大于或等于界面卡顿阈值，则说明待监测终端出现界面卡顿情况。
S150，当确定待监测终端出现界面卡顿时，获取待监测终端在上述发送时间和接收时间之间的时间段内的日志信息，该日志信息包括中央处理器的占用信息、内存的占用信息及当前运行程序的调试信息。
上述发送时间和接收时间之间的时间段确定为出现界面卡顿，即该时间段为界面卡顿期间。
其中，上述中央处理器的占用信息可以通过调用top命令来获取，上述内存的占用信 息可以通过调用dumpsys memory命令来获取。
上述运行程序的调试信息可以包括开发人员在开发该程序时添加的调试信息，可以通过调用logcat命令来获取上述时间段的调试信息。
当获取了上述日志信息后，将获取的日志信息写入待监测终端的日志文件；将上述日志文件发送给服务器。
其中，为了节省待监测终端的功耗，并不是每次将日志信息写入日志文件后，都将该日志文件发送给服务器，因此，将日志文件发送给服务器，具体包括：
将上述日志文件的大小与预设阈值进行比较；
当上述日志文件大于或等于预设阈值时，将上述日志文件发送给服务器；
当上述日志文件小于预设阈值时，将日志文件保存在待监测终端。
上述预设阈值为预先设置的一个数值，该数值可以设置为1M，也可以设置为其它数值，本发明实施例并不对上述预设阈值的具体大小进行限定。
当上述日志文件的大小大于或等于预设阈值时，为了节省上传流量，将上述日志文件进行压缩，并将压缩后的文件发送给服务器，这样开发者可以根据该日志文件分析出现界面卡顿的原因。
如果，上述日志文件的大小小于预设阈值，将该日志文件先保存在监测终端，当再次写入日志信息，使得日志文件的大小大于或等于预设阈值时，再将日志文件发送给服务器。
本发明实施例提供的界面卡顿监测方法，实现了界面卡顿的自动监测，并且，在监测到出现界面卡顿时，会获取卡顿期间的日志信息，方便开发人员对引起卡顿的原因进行分析，避免了通过问题复现来获取卡顿期间的日志信息，节省了大量的人力和时间。
实施例2
本发明实施例提供了一种界面卡顿监测装置，如图4所示，该装置包括确定模块410、第一发送模块420、处理模块430、判断模块440以及获取模块450。
其中，上述确定模块410，配置成根据待监测终端的中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值。
可选地，上述确定模块410可以包括：评分单元及阈值确定单元。
上述评分单元，配置成根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分。
可选地，上述评分单元确定所述待监测终端的硬件评分的方式，包括：
分别确定所述中央处理器和所述内存的评分规则；
根据所述中央处理器的性能指标和所述中央处理器的评分规则，确定所述中央处理器 的评分；
根据所述内存的性能指标和所述内存的评分规则，确定所述内存的评分；
根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分。
可选地，上述评分单元确定所述待监测终端的硬件评分的方式，包括：
分别确定所述中央处理器和所述内存的权重；
根据所述中央处理器的评分、所述中央处理器的权重、所述内存的评分和所述内存的权重，确定所述待监测终端的硬件评分。
上述阈值确定单元，配置成根据所述硬件评分，确定所述待监测终端的界面卡顿阈值。
上述第一发送模块420，配置成实时或定期发送监测消息给界面线程对应的消息队列，并记录上述监测消息的发送时间，该监测消息携带有消息标识。
可选地，上述第一发送模块420通过所述界面线程的消息发送者Handler发送监测消息给所述界面线程对应的消息队列。
上述处理模块430，配置成对消息队列中的消息按序进行处理，当接收到携带有上述消息标识的监测消息的处理请求时，记录上述监测消息对应的处理请求的接收时间。
上述判断模块440，配置成根据上述发送时间、上述接收时间和上述界面卡顿阈值，判断待监测终端是否出现界面卡顿。
其中，上述判断模块440根据上述发送时间、上述接收时间和上述界面卡顿阈值，判断待监测终端是否出现界面卡顿，是通过第一确定单元、比较单元和第二确定单元来实现的，具体包括：
上述第一确定单元，配置成确定发送时间和接收时间之间的时间差值；上述比较单元，配置成将上述时间差值与界面卡顿阈值进行比较；上述第二确定单元，配置成当上述时间差值大于或等于界面卡顿阈值时，确定待监测终端出现界面卡顿。
上述获取模块450，配置成当确定待监测终端出现界面卡顿时，获取待监测终端在发送时间和接收时间之间的时间段内的日志信息，该日志信息包括中央处理器占用信息、内存占用信息及当前运行程序的调试信息。
可选地，上述装置还可以包括：写入模块及发送模块。
上述写入模块，配置成将获取的所述日志信息写入待监测终端的日志文件。
上述发送模块，配置成将所述日志文件发送给服务器。
可选地，上述发送模块可以包括：比较单元、发送单元及存储单元。
上述比较单元，配置成将所述日志文件的大小与预设阈值进行比较。
上述发送单元，配置成当所述日志文件大于或等于所述预设阈值时，将所述日志文件发送给服务器。
上述存储单元，配置成当所述日志文件小于所述预设阈值时，将所述日志文件保存在所述待监测终端。
本发明实施例提供的界面卡顿监测装置，实现了界面卡顿的自动监测，并且，在监测到出现界面卡顿时，会获取卡顿期间的日志信息，方便开发人员对引起卡顿的原因进行分析，避免了通过问题复现来获取卡顿期间的日志信息，节省了大量的人力和时间。
本发明实施例所提供的界面卡顿监测装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，前述描述的***、装置和单元的具体工作过程，均可以参考上述方法实施例中的对应过程，在此不再赘述。
在本发明所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的 技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (17)

  1. 一种界面卡顿监测方法，其特征在于，所述方法包括：
    根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值；
    实时或定期发送监测消息给界面线程对应的消息队列，并记录所述监测消息的发送时间，所述监测消息携带有消息标识；
    对所述消息队列中的消息按序进行处理，当接收到携带有所述消息标识的所述监测消息的处理请求时，记录所述监测消息对应的处理请求的接收时间；
    根据所述发送时间、所述接收时间和所述界面卡顿阈值，判断所述待监测终端是否出现界面卡顿；
    当确定所述待监测终端出现界面卡顿时，获取所述待监测终端在所述发送时间和所述接收时间之间的时间段内的日志信息，所述日志信息包括所述中央处理器占用信息、所述内存占用信息及当前运行程序的调试信息。
  2. 根据权利要求1所述的方法，其特征在于，所述根据所述发送时间、所述接收时间和所述界面卡顿阈值，判断所述待监测终端是否出现界面卡顿，包括：
    确定所述发送时间和所述接收时间之间的时间差值；
    将所述时间差值与所述界面卡顿阈值进行比较；
    当所述时间差值大于或等于所述界面卡顿阈值时，确定所述待监测终端出现界面卡顿。
  3. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    将获取的所述日志信息写入待监测终端的日志文件；
    将所述日志文件发送给服务器。
  4. 根据权利要求3所述的方法，其特征在于，所述将所述日志文件发送给服务器，包括：
    将所述日志文件的大小与预设阈值进行比较；
    当所述日志文件大于或等于所述预设阈值时，将所述日志文件发送给服务器；
    当所述日志文件小于所述预设阈值时，将所述日志文件保存在所述待监测终端。
  5. 根据权利要求1-4任意一项所述的方法，其特征在于，所述根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值，包括：
    根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分；
    根据所述硬件评分，确定所述待监测终端的界面卡顿阈值。
  6. 根据权利要求5所述的方法，其特征在于，所述根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分，包括：
    分别确定所述中央处理器和所述内存的评分规则；
    根据所述中央处理器的性能指标和所述中央处理器的评分规则，确定所述中央处理器的评分；
    根据所述内存的性能指标和所述内存的评分规则，确定所述内存的评分；
    根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分。
  7. 根据权利要求6所述的方法，其特征在于，所述根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分，包括：
    分别确定所述中央处理器和所述内存的权重；
    根据所述中央处理器的评分、所述中央处理器的权重、所述内存的评分和所述内存的权重，确定所述待监测终端的硬件评分。
  8. 根据权利要求1-7任意一项所述的方法，其特征在于，通过所述界面线程的消息发送者Handler发送监测消息给所述界面线程对应的消息队列。
  9. 一种界面卡顿监测装置，其特征在于，所示装置包括：
    确定模块，配置成根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值；
    第一发送模块，配置成实时或定期发送监测消息给界面线程对应的消息队列，并记录所述监测消息的发送时间，所述监测消息携带有消息标识；
    处理模块，配置成对所述消息队列中的消息按序进行处理，当接收到携带有所述消息标识的所述监测消息的处理请求时，记录所述监测消息对应的处理请求的接收时间；
    判断模块，配置成根据所述发送时间、所述接收时间和所述界面卡顿阈值,判断所述待监测终端是否出现界面卡顿；
    获取模块，配置成当确定所述待监测终端出现界面卡顿时，获取所述待监测终端在所述发送时间和所述接收时间之间的时间段内的日志信息，所述日志信息包括所述中央处理器占用信息、所述内存占用信息及当前运行程序的调试信息。
  10. 根据权利要求9所述的装置，其特征在于，所述判断模块，包括：
    第一确定单元，配置成确定所述发送时间与所述接收时间之间的时间差值；
    比较单元，配置成将所述时间差值与所述界面卡顿阈值进行比较；
    第二确定单元，配置成当所述时间差值大于或等于所述界面卡顿阈值时，确定所述待监测终端出现界面卡顿。
  11. 根据权利要求9或10所述的装置，其特征在于，所述装置还包括：
    写入模块，配置成将获取的所述日志信息写入待监测终端的日志文件；
    发送模块，配置成将所述日志文件发送给服务器。
  12. 根据权利要求11所述的装置，其特征在于，所述发送模块包括：
    比较单元，配置成将所述日志文件的大小与预设阈值进行比较；
    发送单元，配置成当所述日志文件大于或等于所述预设阈值时，将所述日志文件发送给服务器；
    存储单元，配置成当所述日志文件小于所述预设阈值时，将所述日志文件保存在所述待监测终端。
  13. 根据权利要求9-12任意一项所述的装置，其特征在于，所述确定模块包括：
    评分单元，配置成根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分；
    阈值确定单元，配置成根据所述硬件评分，确定所述待监测终端的界面卡顿阈值。
  14. 根据权利要求13所述的装置，其特征在于，所述评分单元确定所述待监测终端的硬件评分的方式，包括：
    分别确定所述中央处理器和所述内存的评分规则；
    根据所述中央处理器的性能指标和所述中央处理器的评分规则，确定所述中央处理器的评分；
    根据所述内存的性能指标和所述内存的评分规则，确定所述内存的评分；
    根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分。
  15. 根据权利要求14所述的装置，其特征在于，所述评分单元确定所述待监测终端的硬件评分的方式，包括：
    分别确定所述中央处理器和所述内存的权重；
    根据所述中央处理器的评分、所述中央处理器的权重、所述内存的评分和所述内存的权重，确定所述待监测终端的硬件评分。
  16. 根据权利要求9-15任意一项所述的装置，其特征在于，所述第一发送模块通过所述界面线程的消息发送者Handler发送监测消息给所述界面线程对应的消息队列。
  17. 一种存储于计算机的可读取存储介质，其特征在于，包括多条指令，所述多条指令被配置成实现如权利要求1-8任一项所述的方法。
PCT/CN2017/079611 2016-12-08 2017-04-06 一种界面卡顿监测方法、装置及可读取存储介质 WO2018103245A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611123865.2 2016-12-08
CN201611123865.2A CN106776253B (zh) 2016-12-08 2016-12-08 一种界面卡顿监测方法及装置

Publications (1)

Publication Number Publication Date
WO2018103245A1 true WO2018103245A1 (zh) 2018-06-14

Family

ID=58881678

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/079611 WO2018103245A1 (zh) 2016-12-08 2017-04-06 一种界面卡顿监测方法、装置及可读取存储介质

Country Status (2)

Country Link
CN (1) CN106776253B (zh)
WO (1) WO2018103245A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111367741A (zh) * 2020-02-28 2020-07-03 Oppo广东移动通信有限公司 用户界面卡顿检测方法与装置、电子设备
CN111984544A (zh) * 2020-09-08 2020-11-24 网易（杭州）网络有限公司 设备性能测试方法、装置、电子设备及存储介质
CN113190426A (zh) * 2020-07-02 2021-07-30 北京睿知图远科技有限公司 一种大数据评分***稳定性监控方法
CN113807179A (zh) * 2021-08-13 2021-12-17 广东广宇科技发展有限公司 同行行为判断方法及***

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107273278B (zh) * 2017-06-02 2019-10-25 Oppo广东移动通信有限公司 卡顿确定方法、装置及终端
WO2019000233A1 (zh) * 2017-06-27 2019-01-03 华为技术有限公司 一种卡顿检测方法及装置
CN109508280B (zh) * 2017-09-14 2022-08-02 展讯通信（上海）有限公司 监控ui卡顿的方法、装置及终端
CN107766222B (zh) * 2017-10-31 2021-01-01 努比亚技术有限公司 黑屏检测方法、移动终端及计算机可读存储介质
CN109840195B (zh) * 2017-11-29 2023-05-12 腾讯科技（武汉）有限公司 网页性能分析方法、终端设备及计算机可读存储介质
CN107977275B (zh) * 2017-12-05 2022-10-21 腾讯科技（深圳）有限公司 基于消息队列的任务处理方法及相关设备
CN108319974B (zh) * 2018-01-22 2022-10-28 腾讯科技（深圳）有限公司 数据处理方法、装置、存储介质和电子装置
CN108519923A (zh) * 2018-03-01 2018-09-11 北京三快在线科技有限公司 一种卡顿检测方法及装置和电子设备
CN108512695B (zh) * 2018-03-12 2021-06-01 腾讯音乐娱乐科技（深圳）有限公司 监控应用卡顿的方法及装置
CN110618904A (zh) * 2018-06-20 2019-12-27 广州优视网络科技有限公司 卡顿检测方法和装置
CN109840189A (zh) * 2018-12-15 2019-06-04 中国平安人寿保险股份有限公司 卡顿信息收集方法、装置、计算机装置、及可读存储介质
CN109960659B (zh) * 2019-03-29 2022-11-01 阿波罗智联(北京)科技有限公司 用于检测应用程序的方法和装置
CN112015612B (zh) * 2019-05-28 2023-04-14 杭州萤石软件有限公司 一种获取卡顿信息的方法及装置
CN112015613A (zh) * 2019-05-31 2020-12-01 阿里巴巴集团控股有限公司 一种信息检测方法及其装置
CN110309032A (zh) * 2019-07-05 2019-10-08 上海富欣智能交通控制有限公司 数据管理方法、装置及电子设备
CN111045926B (zh) * 2019-11-05 2023-04-14 北京字节跳动网络技术有限公司 一种应用程序卡顿的检测方法、装置、介质和电子设备
CN110908864B (zh) * 2019-11-11 2024-05-10 腾讯科技（深圳）有限公司 一种设备卡顿的处理方法、装置、设备和介质
CN113535442A (zh) * 2020-04-13 2021-10-22 Oppo广东移动通信有限公司 一种终端卡顿的分析方法、装置以及计算机存储介质
CN111949511A (zh) * 2020-07-09 2020-11-17 厦门美柚股份有限公司 应用程序的卡顿处理方法、装置、终端及存储介质
CN118245331A (zh) * 2024-05-27 2024-06-25 荣耀终端有限公司 数据采集方法和电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104216811A (zh) * 2013-05-30 2014-12-17 腾讯科技（深圳）有限公司 应用程序的日志收集方法和***
CN104268055A (zh) * 2014-09-01 2015-01-07 腾讯科技（深圳）有限公司 一种程序异常的监控方法和装置
US20150188795A1 (en) * 2014-01-01 2015-07-02 Bank Of America Corporation Client events monitoring
CN105677573A (zh) * 2016-02-26 2016-06-15 厦门美图移动科技有限公司 一种卡顿检测方法、装置及计算设备
CN106155863A (zh) * 2016-07-25 2016-11-23 北京小米移动软件有限公司 终端预期行为控制方法及终端

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8543868B2 (en) * 2010-12-21 2013-09-24 Guest Tek Interactive Entertainment Ltd. Distributed computing system that monitors client device request time and server servicing time in order to detect performance problems and automatically issue alerts
CN105589783A (zh) * 2014-11-18 2016-05-18 广州市动景计算机科技有限公司 应用程序卡顿问题数据获取方法及装置
CN104965773B (zh) * 2015-07-09 2019-06-04 网易（杭州）网络有限公司 终端、卡顿检测方法、装置及游戏卡顿检测方法、装置
CN105243007B (zh) * 2015-10-13 2018-09-11 广东欧珀移动通信有限公司 移动终端中内存的老化测试方法和装置
CN105389258B (zh) * 2015-12-10 2020-08-14 腾讯科技（深圳）有限公司 一种程序检测方法及装置
CN105913088A (zh) * 2016-04-13 2016-08-31 厦门美图移动科技有限公司 一种卡顿识别方法、装置及计算设备
CN106095363B (zh) * 2016-06-03 2019-04-26 Oppo广东移动通信有限公司 一种终端卡顿的改善方法、装置以及终端

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104216811A (zh) * 2013-05-30 2014-12-17 腾讯科技（深圳）有限公司 应用程序的日志收集方法和***
US20150188795A1 (en) * 2014-01-01 2015-07-02 Bank Of America Corporation Client events monitoring
CN104268055A (zh) * 2014-09-01 2015-01-07 腾讯科技（深圳）有限公司 一种程序异常的监控方法和装置
CN105677573A (zh) * 2016-02-26 2016-06-15 厦门美图移动科技有限公司 一种卡顿检测方法、装置及计算设备
CN106155863A (zh) * 2016-07-25 2016-11-23 北京小米移动软件有限公司 终端预期行为控制方法及终端

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111367741A (zh) * 2020-02-28 2020-07-03 Oppo广东移动通信有限公司 用户界面卡顿检测方法与装置、电子设备
CN111367741B (zh) * 2020-02-28 2022-07-08 Oppo广东移动通信有限公司 用户界面卡顿检测方法与装置、电子设备
CN113190426A (zh) * 2020-07-02 2021-07-30 北京睿知图远科技有限公司 一种大数据评分***稳定性监控方法
CN113190426B (zh) * 2020-07-02 2023-10-20 北京睿知图远科技有限公司 一种大数据评分***稳定性监控方法
CN111984544A (zh) * 2020-09-08 2020-11-24 网易（杭州）网络有限公司 设备性能测试方法、装置、电子设备及存储介质
CN111984544B (zh) * 2020-09-08 2024-03-22 网易（杭州）网络有限公司 设备性能测试方法、装置、电子设备及存储介质
CN113807179A (zh) * 2021-08-13 2021-12-17 广东广宇科技发展有限公司 同行行为判断方法及***
CN113807179B (zh) * 2021-08-13 2024-04-02 广东广宇科技发展有限公司 同行行为判断方法及***

Also Published As

Publication number Publication date
CN106776253B (zh) 2020-08-04
CN106776253A (zh) 2017-05-31

Similar Documents

Publication Publication Date Title
WO2018103245A1 (zh) 一种界面卡顿监测方法、装置及可读取存储介质
US10893064B2 (en) Identifying service issues by analyzing anomalies
CN110275958B (zh) 网站信息识别方法、装置和电子设备
CN107423085B (zh) 用于部署应用的方法和装置
WO2017096734A1 (zh) 一种程序检测方法及装置
US10922206B2 (en) Systems and methods for determining performance metrics of remote relational databases
WO2019169978A1 (zh) 资源推荐方法及装置
CN108111554B (zh) 一种访问队列的控制方法及装置
WO2017036394A1 (zh) WiFi资源的处理方法和***
CN109803152A (zh) 违规审核方法、装置、电子设备以及存储介质
CN105630683B (zh) 一种云测试体系架构
CN110875059B (zh) 收音结束的判断方法、装置以及储存装置
US9832259B2 (en) Method and apparatus for cell configuration
CN109302423B (zh) 一种漏洞扫描能力测试方法和装置
US11709756B2 (en) Dynamic distributed tracing instrumentation in a microservice architecture
CN105373460A (zh) 监控消息的告警方法和***
CN104809054B (zh) 实现程序测试的方法和***
WO2021093367A1 (zh) 模型训练和风险识别方法、装置及设备
CN106844423A (zh) 一种数据检测的方法及装置
CN107018039B (zh) 测试服务器集群性能瓶颈的方法和装置
CN109067864B (zh) 通知消息推送方法、装置及电子设备
WO2022262472A1 (zh) 帧率处理方法、装置、存储介质以及终端
CN110719367A (zh) 一种云手机好友推荐方法、装置、设备及存储介质
KR102464688B1 (ko) 모니터링 결과의 이벤트 등급 결정 방법 및 장치
CN103106103B (zh) 请求信息分类方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17878474

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17878474

Country of ref document: EP

Kind code of ref document: A1