Crash processing method and device of mobile application, equipment and storage medium

Abstract

The invention relates to the technical field of mobile applications, and discloses a mobile application crash processing method and device, equipment and a storage medium. The method comprises the following steps: collecting crash information of a mobile application to determine a target function corresponding to the crash information and a first version corresponding to the target function; when it is determined that the crash information meets a preset serious crash condition, triggering a version adjustment instruction; adjusting the target function from the first version to a second version based on the version adjustment instruction; and when the target function is executed, running the second version. Through the crash processing, the crash information can be quickly and stably responded to be processed, manual operation is not needed, only the target function, with the crash problem, of the first version is abandoned while other application functions of the first version are reserved, the second version corresponding to the target function is selected and operated, the corresponding crash problem is avoided, and the crash processing efficiency is improved. Efficient and stable operation of the mobile application is ensured, and the operation efficiency and reliability of the mobile application are further improved.

Description

Technical Field

[0001] The present invention relates to the technical field of mobile applications, and in particular, to a method, apparatus, device, and storage medium for handling crashes of mobile applications. Background Art

[0002] With the popularization of smart phones and mobile Internet, mobile applications have been widely used in people's daily lives and work production, and the requirements for their stability are also getting higher and higher. However, during the development, release, and version maintenance of mobile applications, due to factors such as abnormal code logic and version compatibility issues, crashes often occur, which not only interrupts the normal operations of users but also consumes a lot of time for analysis and maintenance.

[0003] For the crash problems of mobile applications, existing methods mainly adopt the "gray release" method and the "hot fix" method. Among them, the "gray release" method means that when releasing a new version of the application, the manufacturer will not immediately push the mobile application product to the market in full, but select some users for gray testing. Although this method can reduce the risks that may be brought when the new version is directly faced with all users, because the proportion of users in gray testing is usually small, it is often difficult to discover potential problems. And even if problems are discovered, a series of repair and gray testing processes are required to fully repair them. The whole cycle is long, and it cannot quickly respond to crash problems, relying heavily on manual intervention, and the whole process is time-consuming and laborious.

[0004] The "hot fix" method means that when a mobile application crashes during operation, it is a technology that directly modifies the application logic by issuing code files. Although this method can flexibly handle version crash problems, it often implements by bypassing some program logics, and can only handle some simple crash problems, and it is difficult to repair complex problems. And because the hot fix depends on the initialization of tools, it cannot effectively solve the crash problems during the startup of mobile applications, relying heavily on manual intervention, and the whole repair process is still time-consuming and laborious. Summary of the Invention

[0005] The main purpose of the present invention is to provide a method, apparatus, device, and storage medium for handling crashes of mobile applications, aiming to solve the technical problems that mobile applications respond to crash problems in a timely manner and take a long time to solve problems.

[0006] The first aspect of the present invention provides a method for handling crashes of a mobile application. The method for handling crashes of the mobile application includes: collecting crash information of the mobile application to determine a target function corresponding to the crash information and a first version corresponding to the target function; when it is determined that the crash information meets a preset severe crash condition, triggering a version adjustment instruction; based on the version adjustment instruction, adjusting the target function from the first version to a second version; and when the target function is executed, running the second version.

[0007] Optionally, in the first implementation manner of the first aspect of the present invention, before adjusting the target function from the first version to the second version based on the version adjustment instruction, it further includes: obtaining a plurality of code data and corresponding version information of a preset key version of the mobile application; defining code interfaces for implementing different application functions, and extracting a plurality of function code files corresponding to each of the code interfaces for implementing the corresponding application function from the code data; and adding each of the code interfaces to an installation package file of the mobile application for the mobile application to call the code interfaces to obtain the function code files.

[0008] Optionally, in the second implementation manner of the first aspect of the present invention, the step of running the second version when the target function is executed includes: when the target function is executed, calling the code interface to obtain the function code file corresponding to the second version; and redirecting the execution code of the target function from the first version to the second version to execute the target function based on the function code file of the second version.

[0009] Optionally, in the third implementation manner of the first aspect of the present invention, the step of collecting crash information of the mobile application to determine a target function corresponding to the crash information and a first version corresponding to the target function includes: listening to the exception stack information of the mobile application to obtain the corresponding crash information when the mobile application crashes; and performing problem transformation on the obtained crash information to determine the target function corresponding to the crash information and the first version corresponding to the target function.

[0010] Optionally, in the fourth implementation manner of the first aspect of the present invention, the step of triggering a version adjustment instruction when it is determined that the crash information meets a preset severe crash condition includes: determining a crash trend of the target function based on a plurality of the crash information within a preset time period; and when the crash trend meets a preset trend condition, determining that the crash information meets the preset severe crash condition and triggering the version adjustment instruction.

[0011] Optionally, in the fifth implementation manner of the first aspect of the present invention, after running the target function of the second version when executing the target function, the following steps are further included: when running the target function of the second version, determine whether the target function crashes in the mobile application of the second version and meets a preset severe crash condition; if the target function crashes in the mobile application of the second version and meets the preset severe crash condition, trigger a new version adjustment instruction; based on the new version adjustment instruction, determine a third version corresponding to the target function; when executing the target function again, run the target function of the third version.

[0012] Optionally, in the sixth implementation manner of the first aspect of the present invention, after defining code interfaces for implementing different application functions and extracting, from the code data, multiple function code files corresponding to each of the code interfaces for implementing the corresponding application functions, the following steps are further included:

[0013] Based on the identification field of the target function corresponding to each of the function code files and the identification field of the version information, determine a first identification field for each of the function code files; before running the second version when executing the target function, the following steps are further included: based on a preset mapping rule, map the identification field of the target function and the identification field of the second version to obtain a second identification field corresponding to the target function; determine whether the second identification field matches the first identification field; if they match, obtain the function code file corresponding to the second version.

[0014] The second aspect of the present invention further provides a crash handling device for a mobile application. The crash handling device for the mobile application includes: an analysis component, configured to collect crash information of the mobile application to determine a target function corresponding to the crash information and a first version corresponding to the target function, and trigger a version adjustment instruction when it is determined that the crash information meets a preset severe crash condition; a background component, configured to adjust the target function from the first version to a second version based on the version adjustment instruction; an execution component, configured to run the second version when executing the target function.

[0015] The third aspect of the present invention further provides a computer device. The computer device includes: a memory and at least one processor, and instructions are stored in the memory; the at least one processor invokes the instructions in the memory to enable the computer device to execute the crash handling method for the mobile application as described above.

[0016] The fourth aspect of the present invention further provides a computer-readable storage medium, and instructions are stored on the computer-readable storage medium. When the instructions are executed by a processor, the crash handling method for the mobile application as described above is implemented.

[0017] A method, apparatus, device, and storage medium for handling crashes of a mobile application provided by an embodiment of the present invention first collect crash information of the mobile application to determine a target function corresponding to the crash information and a first version corresponding to the target function. When it is determined that the crash information meets a preset severe crash condition, a version adjustment instruction is triggered, and a second version corresponding to the target function is determined based on the version adjustment instruction. Finally, when the target function is executed, the second version is run. Through the above method, the present invention can effectively adjust the function version of the target function that causes the crash, quickly respond to adjust the corresponding target function from the first version to the second version, ensure the stable operation of the corresponding function, thereby achieving a quick repair of the crash problem, improving the stability of the entire mobile application, and reducing the probability of crashes. Through function version adjustment, while retaining the functions of the first version, only the target function of the first version with crash problems is discarded, and the second version corresponding to the target function is selected and run to avoid the corresponding crash problems, and also ensure the coherence and fluency of using the mobile application. This process does not require human intervention, can effectively save labor costs, and avoid additional time and energy consumption of human resources. In this way, it is also possible to achieve direct full-scale release, crash handling during application startup, and repair of complex logic functions, effectively solving the problems of poor timeliness of the traditional version gray-scale method and the limitations of the traditional hot-fix method, which is beneficial to further improving the operation efficiency and reliability of the mobile application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a schematic flowchart of the first embodiment of the method for handling crashes of a mobile application in an embodiment of the present invention;

[0019] Figure 2 For the present invention Figure 1 It is a schematic flowchart of an embodiment of step 101 in an embodiment of the present invention;

[0020] Figure 3 For the present invention Figure 1 It is a schematic flowchart of an embodiment of step 102 in an embodiment of the present invention;

[0021] Figure 4 For the present invention Figure 1 It is a schematic flowchart of an embodiment before step 101 in an embodiment of the present invention;

[0022] Figure 5 For the present invention Figure 1 It is a schematic flowchart of an embodiment of step 104 in an embodiment of the present invention;

[0023] Figure 6 For the present invention Figure 1 It is a schematic flowchart of an embodiment after step 104 in an embodiment of the present invention;

[0024] Figure 7 Schematic diagram of functional modules of an embodiment of the crash handling device for mobile applications in an embodiment of the present invention;

[0025] Figure 8 Schematic diagram of functional modules of an embodiment of a computer device in an embodiment of the present invention. Detailed implementation manners

[0026] The terms "first", "second", "third", "fourth", etc. (if any) in the specification, claims and above-mentioned drawings of the present invention are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "comprising" or "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these process, method, product or device.

[0027] Please refer to Figure 1 , Figure 1 which is a schematic diagram of the process of the first embodiment of the crash handling method for mobile applications in an embodiment of the present invention. In this embodiment, the crash handling method for mobile applications includes:

[0028] 101. Collect crash information of the mobile application to determine the target function corresponding to the crash information and the first version corresponding to the target function;

[0029] In this embodiment, there are various ways to collect the crash information of the mobile application. For example, relevant crash information can be monitored and recorded by listening, detailed information related to the crash can be extracted by analyzing the log file, and the situation of the crash can be determined through the information fed back by the user, etc. After collecting the crash information, the target function corresponding to the crash information and the first version corresponding to the target function can be determined by means of stack trace, disassembly, static code analysis or based on the preset matching rules between the crash information and the function, so as to perform subsequent processing of the crash. Through this step, a quick response to the crash problem can be achieved, and the efficiency of crash handling can be improved.

[0030] Optionally, referring to Figure 2 , in an embodiment, collecting the crash information of the mobile application to determine the target function corresponding to the crash information and the first version corresponding to the target function can be performed according to the following steps:

[0031] 1011. Monitor the exception stack information of the mobile application to obtain the corresponding crash information when the mobile application crashes;

[0032] 1012. Transform the obtained crash information to determine the target function corresponding to the crash information and the first version corresponding to the target function.

[0033] In this optional embodiment, the exception stack information refers to the status record of the program call stack when an exception occurs, including the type of the exception, the occurrence location, and the function call sequence that causes the exception, etc. By monitoring the exception stack information of the mobile application, the corresponding crash information can be quickly and accurately obtained when the mobile application crashes.

[0034] In this optional embodiment, after obtaining the crash information, the target function corresponding to the crash and the first version corresponding to the target function can be further analyzed through the method of problem transformation. For example, the crash information can be converted into a format similar to {"errorMsg":"xxx","errorFile":"xxx","version":"xxx",time:"xxx"}, where errorMsg represents the type information of the error, such as NullPointException, OutOfMemoryException, TimeOutException, etc., errorFile represents the functional logic file where the error occurs and can be used to determine the corresponding target function, while version is the nitrogen concept version of the target function, and time represents the occurrence time of the crash exception, which is beneficial to subsequent more accurate and orderly statistical analysis.

[0035] 102. When it is determined that the crash information meets the preset severe crash condition, trigger a version adjustment instruction;

[0036] In this embodiment, the preset severe crash condition is used to reflect the severity of the crash, such as a large scale of the crash, the inability to load the mobile application due to the crash, and the crash showing a high rate of change. The condition can be set by taking into account the frequency of the crash, the proportion of the crash, the severity of user feedback, and other aspects. Once it is determined that the crash information meets the preset severe crash condition, it means that corresponding measures need to be taken immediately to handle the crash. The establishment of the severe crash condition is also set by comprehensively considering the maintenance cost and maintenance value of the mobile application. For example, due to the unreasonable setting of a certain activity, a large number of users influx cause server congestion request timeout and other problems, which are usually not solved by version adjustment, but the activity time may be relatively short, and after a certain number of users exit, other users can continue to use it normally. Then, by judging that the situation does not meet the preset severe crash condition, that is, not performing subsequent version adjustment processing, the corresponding crash problem can be solved very efficiently, and the resource consumption caused by version adjustment is also reduced, and the applicability of the crash handling method under different business decisions of the mobile application is improved, and the balance between cost and application stability is achieved under the premise of ensuring application availability.

[0037] In this embodiment, the version adjustment instruction is an instruction triggered when a serious crash occurs, and is used to instruct the subsequent steps to perform version adjustment operations, that is, to instruct to abandon the code logic of the first version of the target function, select the code logic of the second version to run, and other application functions retain their code logic corresponding to the first version. The version adjustment instruction can be in a variety of different formats, and can also be transmitted based on different communication protocols. This application does not impose specific restrictions on this, as long as it can indicate the subsequent corresponding version adjustment processing. For example, the version adjustment instruction can be a specific paragraph information in the format of a key-value pair, such as the format of the instruction can be {"bussniessName":"XXXX","revertVersion":"XXXX","reason":"XXXX","percent":"XXXX"}, where bussniessName is the business name, which can be the name of the target function or the interface name corresponding to the target function, and its corresponding value is the identification field of the target function, which can be adjusted in the specific execution logic code, revertVersion refers to the version to which the function is expected to be adjusted, that is, the second version, and its corresponding value is the identification field of the second version, reason refers to the type of problem that needs to perform the version adjustment operation, and percent is the effective percentage. On this basis, the version adjustment instruction includes the identification fields of the second version and the target function.

[0038] Optional, see Figure 3, in one embodiment, when it is determined that the crash information meets the preset severe crash condition, a version adjustment instruction is triggered, including:

[0039] 1021. Determine the crash trend of the target function based on multiple crash information within a preset time period;

[0040] 1022. When the crash trend meets the preset trend condition, determine that the crash information meets the preset severe crash condition and trigger a version adjustment instruction.

[0041] In this alternative embodiment, the crash trend can be determined by means of statistical analysis of the crash information, based on specific rules or algorithms, or based on an intelligent analysis model. The preset trend condition is the threshold range set for the parameter indicators determined by the analysis. When exceeding or falling below this threshold range, a judgment of the preset severe crash condition is made. For example, statistical analysis can be performed on the crash information obtained after problem conversion in the aforementioned step 1012. Taking the time parameter as the horizontal axis and the frequency of specific crash types in different time periods as the vertical axis, a corresponding trend graph is obtained. Then, the corresponding change trend is judged according to the overall or weighted average slope. For example, when the slope is greater than a certain threshold or the change rate of the increasing slope exceeds a certain threshold, it is judged that the crash trend meets the corresponding preset trend condition, thereby determining that the crash information meets the preset severe crash condition and triggering a version adjustment instruction.

[0042] In this embodiment, by automatically triggering a version adjustment instruction when a severe crash is detected, it is ensured that the application can quickly return to a stable state when encountering problems, thereby reducing the poor experience of users and being beneficial to improving the stability and operational fluency of the mobile application. By setting the preset severe crash condition, it is avoided to perform version adjustment processing for all crash situations, thereby saving unnecessary resource consumption and improving the processing efficiency. At the same time, by comprehensively considering factors such as the frequency, proportion, and user feedback of crashes, the maintenance decision-making can be made more flexible, and the most appropriate processing method can be selected according to the actual situation, improving the flexibility of maintenance. By reasonably setting the preset severe crash condition, both the availability of the application and the maintenance cost are ensured, enabling the mobile application to maintain good performance under different business decisions and achieving a balance between cost and stability.

[0043] 103. Based on the version adjustment instruction, adjust the target function from the first version to the second version;

[0044] In this embodiment, after the version adjustment instruction is triggered, the tasks of the subsequent version adjustment process can be determined. Therefore, the next step according to the version adjustment instruction is to obtain a second version of the target function required for the version adjustment, and adjust the target function from the first version to the second version. Among them, a target function may correspond to multiple second versions for subsequent adjustment processing, and only one of the second versions needs to be selected. There are various ways to obtain the second version of the target function, such as querying the database, accessing the server, inputting to the generation model, etc.

[0045] Optionally, refer to Figure 4 , in an embodiment, before determining the second version corresponding to the target function based on the version adjustment instruction, it further includes:

[0046] 1001. Obtain multiple code data and corresponding version information of the preset key version of the mobile application;

[0047] 1002. Define code interfaces for implementing different application functions, and extract multiple functional code files corresponding to each code interface for implementing the corresponding application functions from the code data;

[0048] 1003. Add each code interface to the installation package file of the mobile application for the mobile application to call the code interface to obtain the functional code file.

[0049] In this alternative embodiment, the preset key version refers to a version of the mobile application that can run stably and has certain differences in functions and overall configurations from the previous version. The mobile application can provide relatively stable services under the preset key version, and at the same time introduce new functions or improvements. The corresponding code data and version information can be obtained from platforms such as databases, servers, and memories storing the corresponding version codes. By obtaining the code data and version information, it is ensured that during the subsequent crash handling process, the version of the problem function can be accurately identified and located, as well as the second version required for function version adjustment.

[0050] In this alternative embodiment, the code interface is used to dock different application functions to be implemented. For example, the ISplash interface corresponding to the splash screen function, the IHome interface corresponding to the main page function, the IMine interface corresponding to the user preference settings, etc. Taking the ISplash interface as an example, when it is necessary to trigger the splash screen, the corresponding splash screen function can be completed by directly calling this interface in the mobile application. The code data corresponding to this interface is preferably extracted from the code for implementing the functions of the preset key version in this solution, so it can be distinguished by the corresponding version information. In addition, the acquisition of the code file corresponding to the code interface can specifically be obtained from some standard libraries or code libraries with polymorphic implementation methods reserved by developers.

[0051] Optionally, in one embodiment, after defining code interfaces for implementing different application functions and extracting multiple functional code files corresponding to each code interface from the code data for implementing the corresponding application functions, the method further includes: determining a first identification field for each functional code file based on the identification field of the target function corresponding to each functional code file and the identification field of the version information.

[0052] In this optional embodiment, the identification field of the target function corresponding to each functional code file is the name information or other unique identification information of the target function, and it can also be obtained by mapping the information of the splash screen function, which is used to uniquely identify the corresponding target function. The identification field of the version information is the version number, version code name, or the name after removing redundant punctuation from the version number mapping, etc., which is used to uniquely identify the information of the corresponding version. For example, if the name of a certain splash screen function is Splash, the function number is F101, the version number is 1.0.5, and the build number is 123, then the identification field of the corresponding target function can be Splash, F101, SplashF101, etc., the identification field of the version information can be 1.0.5, 105, 123, etc., and the corresponding first identification field is a combination of the two, such as Splash105, etc. The code file can also adapt to the code file format of the corresponding mobile application and determine that the file extension is Splash105.java, Splash105.cpp, Splash105.py, etc.

[0053] In this alternative embodiment, by defining these code interfaces, the code implementing specific functions in the mobile application can be encapsulated, facilitating corresponding management and invocation. Adding these code interfaces to the installation package file of the mobile application enables the application to obtain the required functional code files by invoking the corresponding interfaces during runtime, without the need to concern about the specific implementation of the code interfaces, thereby implementing the corresponding application functions. The method of obtaining the corresponding code files from multiple versions also realizes the polymorphism of the code interfaces, that is, multiple different versions of code implementation can be invoked through the code interfaces. In specific invocations, the corresponding code can be selected by setting invocation parameters for the interfaces. For example, the parameter of the aforementioned version information can be used for invocation to obtain the code. In this way, the mobile application can dynamically select the appropriate code implementation according to actual needs during runtime, thereby improving the flexibility and maintainability of the application function implementation. Taking the aforementioned ISplash interface as an example, multiple classes can be defined in this interface, such as SplashFor101, SplashFor105, and SplashFor108, etc., corresponding to the implementation methods of the corresponding functions in versions 1.0.1, 1.0.5, and 1.0.8 respectively. During specific invocations, the corresponding version information can be processed. For example, if it is necessary to invoke version 1.0.8 through the ISplash interface, then the parameter name of SplashFor108 can be obtained according to the preset rules based on the corresponding fields, thereby realizing the invocation of the class of SplashFor108 and implementing the splash screen function of version 1.0.8.

[0054] Based on the foregoing steps, in this alternative embodiment, each code interface can be added to the installation package file of the mobile application and released accordingly. This packaging process can be implemented by a specific packaging script or completed by other automated tools. Thus, when users use the corresponding mobile application, they can obtain the required functional code files by invoking the corresponding interfaces. In case of a crash, it is also possible to better adjust the subsequent functional versions of this solution, realizing the intelligent implantation of functions. This process does not require manual operation but implements the specific code logic and corresponding crash handling tasks according to the invocation of the code interfaces, providing the necessary code data and invocation interfaces for subsequent version adjustment, and realizing the dynamic acquisition of functional code files, which is extremely flexible and compatible. On this basis, the corresponding second version can be obtained by invoking the code interface. Through the code interface, the mobile application can dynamically access and load functional code files of different versions and determine the functional code files of the second version for subsequent version adjustment.

[0055] 104. When the target function is executed, run the second version.

[0056] In this embodiment, after determining the second version corresponding to the target function, when the target function is executed, the target function can select the second version to run. For example, when Function A crashes and there is no need to modify the code and release a new version, Function A can abandon the logic of the first version and then select the code logic of the second version to run the corresponding function, while other functions such as Function B, Function C, and Function D continue to run according to the logic of the first version. In this way, Function A of the second version and Functions B, C, and D of the first version in a mobile application will run simultaneously, achieving a situation similar to using two objects glued together, that is, realizing the adjustment of the function version. Among them, there are various ways to abandon the first version and run the second version when the target function runs. For example, the version program to run can be selected through a logic switch, the version to run can be selected through the dynamic loading of a configuration file, or the version can be switched through an instruction sent by a remote server, etc.

[0057] Optionally, in an embodiment, before running the second version when the target function is executed, it further includes:

[0058] (1) Based on a preset mapping rule, map the identification field of the target function and the identification field of the second version to obtain a second identification field corresponding to the target function;

[0059] (2) Determine whether the second identification field matches the first identification field;

[0060] (3) If they match, obtain the function code file corresponding to the second version.

[0061] This optional embodiment is based on the premise that the foregoing version adjustment instruction includes the second version and the identification field of the target function. In this optional embodiment, the preset mapping rule is set for the first identification field of the corresponding function code file. For example, in the first code file, the target function name is mapped to the capitalized form of the first letter after removing punctuation. For example, the function name Show_Splash is mapped to Showsplash, and the version number is mapped to a pure number representation. For example, the version number 1.0.5 is mapped to 105, and the obtained first identification field is Showsplash105. Then the corresponding preset mapping rule is to use the same mapping method, so as to better determine whether the obtained second identification field matches the first identification field. If they match, it means that the corresponding function code file can be called through the corresponding code interface for subsequent function version adjustment. On the contrary, if they do not match, it means that there may be no function code file for the corresponding version, the corresponding target function has not been determined, or the second identification field is incorrect. Through this method, the precise matching of the function code file and the version selection can be further realized.

[0062] Optionally, refer to Figure 5, in one embodiment, when the target function is executed, running the second version includes:

[0063] 1041. When the target function is executed, call the code interface to obtain the function code file corresponding to the second version;

[0064] 1042. Redirect the execution code of the target function from the first version to the second version to execute the target function based on the function code file of the second version.

[0065] In this alternative embodiment, based on the above-mentioned addition of the code interface to the installation package file of the mobile application, through the code interface, different versions of the function code files can be dynamically accessed and loaded, thus ensuring that the correct second version code can be obtained. And redirecting the execution code of the target function from the first version to the second version enables the target function to abandon the logic of the first version and instead execute the corresponding function based on the function code file of the second version. Even if there are crashes or other problems in the first version, the application can quickly switch to a stable state. The version adjustment of this process for handling crashes can be automatically completed by the mobile application throughout the process without manual intervention, greatly improving the processing efficiency and accuracy.

[0066] Through the above method, this embodiment can effectively perform function version adjustment on the target function that causes crashes, quickly respond to make the corresponding target function abandon the running logic of the first version, and select the running logic of the second version to run. At the same time, it ensures that other functions of the first version can continue to run according to the running logic of the first version, thus ensuring the stability of the corresponding target function, achieving a quick fix for the crash problem, improving the stability of the entire mobile application, and reducing the probability of crashes. Through function version adjustment, while retaining the functions of the first version, only the target functions with crash problems are discarded, avoiding crash problems caused by unknown errors introduced by the first version, and also ensuring the coherence and fluency of using the mobile application. This process does not require human intervention, can effectively save labor costs, and avoid additional time and energy consumption of human resources. In this way, direct full-scale release, crash handling at application startup, and repair of complex logic functions can also be achieved, effectively solving the problems of poor timeliness of the traditional version gray-scale method and the limitations of the traditional hot-fix method, which is beneficial to further improving the running efficiency and reliability of the mobile application.

[0067] Optionally, referring to Figure 6 , after running the target function of the second version when the target function is executed, it further includes:

[0068] 1051. When running the target function of the second version, determine whether the target function crashes in the mobile application of the second version and meets the preset severe crash condition;

[0069] 1053. If the target function crashes in the second version of the mobile application and meets the preset severe crash condition, a new version adjustment instruction is triggered;

[0070] 1053. Based on the new version adjustment instruction, determine the third version corresponding to the target function;

[0071] 1054. When the target function is executed again, run the target function of the third version.

[0072] In this alternative embodiment, after the target function runs the second version, if a crash is detected, the Yingdong application will automatically evaluate the severity of the crash. If the crash meets the preset severe crash condition, such as the crash causing the application to be unable to continue running or user data to be lost, etc., a new version adjustment instruction will be triggered. This instruction will guide the selection and determination of the third version of the target function, in the hope of avoiding or fixing the problems causing the crash through the operation of the target function of the third version. When the user tries to execute the target function again, the system will automatically run to the third version, thus preventing the same crash problem from occurring again. In this way, the system can continuously iterate and optimize the function, ensuring the stability of the mobile application and the coherence of the user experience.

[0073] In this alternative embodiment, the third version is similar to the aforementioned second version. Specifically, it can be directly obtained and determined by the fields in a version adjustment instruction as described above, or it can be obtained by further parsing the fields to obtain query fields that match the name or identifier of the third version. The iterative selection of the version can be based on a comprehensive evaluation of functional requirements, historical data, user feedback, or other relevant factors, or it can be determined by calling an interface, or by interacting with a database, a server, a generation model, etc., to determine such a third version. For example, the selection can be made in the order from the new version to the old version. The last selected second version is the previous critical version of the first version, and the third version is the previous critical version of the second version. Iteratively select the version in this way until the stable version of the target function is selected, ensuring that the relevant function is stable and reliable as a whole while having a relatively new functional experience. On this basis, when the target function is executed, run the target function of the third version, abandon the code logic corresponding to the second version of the target function, and retain other application functions in the first version or the second version to achieve functional version adjustment. Through the iteration of this method, it can be ensured that the finally iteratively selected functional version can solve the crash problem encountered in the second version, improving the stability of the application and the user experience.

[0074] To execute the corresponding steps in the above method embodiments and all possible implementation manners, the following provides an implementation manner of a crash handling device for a mobile application. Please refer to Figure 7 , Figure 7FIG. 0 is a schematic diagram of functional modules of an embodiment of a crash handling device for a mobile application in an embodiment of the present invention. In this embodiment, the crash handling device for the mobile application is applied to an electronic device, and the crash handling device for the mobile application includes:

[0075] An analysis component 201, configured to collect crash information of the mobile application to determine a target function corresponding to the crash information and a first version corresponding to the target function, and when it is determined that the crash information meets a preset severe crash condition, trigger a version adjustment instruction;

[0076] A background component 202, configured to adjust the target function from the first version to a second version based on the version adjustment instruction;

[0077] An execution component 203, configured to run the second version when the target function is executed.

[0078] Optionally, in an embodiment, the background component 202 is further configured to obtain a plurality of code data and corresponding version information of a preset critical version of the mobile application; the execution component 203 is further configured to define code interfaces for implementing different application functions, and extract a plurality of functional code files corresponding to each code interface for implementing the corresponding application function from the code data; the execution component 203 is further configured to add each code interface to the installation package file of the mobile application for the mobile application to call the code interface to obtain the functional code file.

[0079] Optionally, in an embodiment, the analysis module 201 includes a server-side analysis part and a client-side analysis part. The client part is specifically configured to monitor the exception stack information of the mobile application to obtain corresponding crash information when the mobile application crashes; the server part is specifically configured to perform problem transformation on the obtained crash information to determine the target function corresponding to the crash information and the first version corresponding to the target function.

[0080] Optionally, in an embodiment, the server part of the analysis component 201 is further specifically configured to: determine the crash trend of the target function based on a plurality of crash information within a preset time period; when the crash trend meets a preset trend condition, determine that the crash information meets the preset severe crash condition and trigger a version adjustment instruction.

[0081] Optionally, in an embodiment, the analysis component 201 is further specifically configured to: when running the target function of the second version, determine whether the target function crashes in the mobile application of the second version and meets the preset severe crash condition, and if the target function crashes in the mobile application of the second version and meets the preset severe crash condition, trigger a new version adjustment instruction; the background component 202 is further specifically configured to: determine a third version corresponding to the target function based on the new version adjustment instruction; the execution component 203 is further specifically configured to: when the target function is executed again, run the target function of the third version.

[0082] Optionally, in one embodiment, the execution component 203 is further specifically configured to: when executing the target function, call the code interface to obtain the function code file corresponding to the second version; redirect the execution code of the target function from the first version to the second version, so as to execute the target function based on the function code file of the second version.

[0083] Optionally, in one embodiment, the background component 202 is further specifically configured to: determine the first identification field of each function code file based on the identification field of the target function corresponding to each function code file and the identification field of the version information; map the identification field of the target function and the identification field of the second version based on the preset mapping rule to obtain the second identification field corresponding to the target function; determine whether the second identification field matches the first identification field; if they match, obtain the function code file corresponding to the second version.

[0084] Since the embodiments of the device part correspond to the embodiments of the above method, the introduction of the mobile application crash handling device provided in the embodiments of the present invention may refer to the above method embodiments, and the embodiments of the present invention will not be repeated here, and it has the same beneficial effects as the above mobile application crash handling method.

[0085] Optionally, in one embodiment, the execution component 203 is deployed on the client of the mobile application, and the background component 202 is deployed on the server of the mobile application; the mobile application crash handling device further includes a long connection component, and the long connection component is deployed on the client of the mobile application. The long connection component is used to establish a communication connection between the background component 202 and the execution component 203, and analyze the communication links between the client part and the server part of the component 201.

[0086] In this optional embodiment, each component can be separately deployed on the client and server of the mobile application, and a stable network communication between components is established by introducing a long connection component, so as to achieve long-term communication between the client and server of the mobile application, which is used to achieve instant communication between components. If the background component 202 needs to adjust the version of a certain function, the corresponding version adjustment instruction will be transmitted to the execution component 203 through this long connection component. In case of a crash, the corresponding crash information will be collected by the client part of the analysis component 201 and transmitted to the server part of the analysis component 202 through this long connection component. The communication method established by this long connection component can adopt the traditional three-way handshake to establish a TCP (Transmission Control Protocol) long connection method, adopt WebSocket (web socket), etc., and this application will not elaborate on this. As long as it is used for establishing a long connection communication component between the server and the client, it can be understood that it is within the protection scope of this solution.

[0087] Through the introduction of the long connection component in this alternative embodiment, the efficiency and accuracy of mobile application crash handling can be effectively improved, ensuring that when the mobile application crashes, the crash information can be quickly transmitted to the server, so as to quickly respond to and handle the crash problem. In addition, the long connection component can also maintain continuous communication between the client and the server, ensuring that when performing version adjustment operations, each component can synchronize information in real time, avoiding processing delays caused by communication delays.

[0088] The present invention also provides a computer device, which includes a memory and a processor. Computer-readable instructions are stored in the memory. When the computer-readable instructions are executed by the processor, the processor executes the crash handling method of the mobile application as described above. Figure 8 It is a schematic diagram of the functional modules of a computer device provided by an embodiment of the present invention. The computer device 300 may vary greatly due to configuration or performance, and may include one or more processors (central processing units, CPU) 310 (for example, one or more processors) and a memory 320, and one or more storage media 330 (for example, one or more mass storage devices) that store application programs 333 or data 332. Among them, the memory 320 and the storage media 330 can be short-term storage or persistent storage. The program stored in the storage media 330 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the computer device 300. Further, the processor 310 can be set to communicate with the storage media 330 and execute a series of instruction operations in the storage media 330 on the computer device 300.

[0089] The computer device 300 may also include one or more power supplies 340, one or more wired or wireless network interfaces 350, one or more input / output interfaces 360, and / or one or more operating systems 331, such as Windows Serve, Mac OS X, Unix, Linux, FreeBSD, and so on. Those skilled in the art can understand that Figure 8 The computer device structure shown does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0090] The present invention also provides a computer-readable storage medium. The computer-readable storage medium can be a non-volatile computer-readable storage medium, and can also be a volatile computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions run on a computer, the computer executes the crash handling method of the mobile application as described above.

[0091] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the devices described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein. If the integrated modules or units are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0092] The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments or perform equivalent replacements for some of the technical features. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of various embodiments of the present invention.

Claims

1. A method for handling crashes of a mobile application, characterized in that, Including: Collect the crash information of the mobile application to determine the target function corresponding to the crash information and the first version corresponding to the target function; When it is determined that the crash information meets the preset severe crash condition, trigger a version adjustment instruction; Based on the version adjustment instruction, adjust the target function from the first version to the second version; When the target function is executed, run the target function of the second version.

2. The crash handling method for a mobile application according to claim 1, wherein Before adjusting the target function from the first version to the second version based on the version adjustment instruction, it further includes: Obtain multiple code data and corresponding version information of the preset key version of the mobile application; Define code interfaces for implementing different application functions, and extract multiple function code files corresponding to each code interface for implementing the corresponding application function from the code data; Add each code interface to the installation package file of the mobile application for the mobile application to call the code interface to obtain the function code file.

3. The method for handling crashes of a mobile application according to claim 2, wherein The "When the target function is executed, run the second version" includes: When the target function is executed, call the code interface to obtain the function code file corresponding to the second version; Redirect the execution code of the target function from the first version to the second version to execute the target function based on the function code file of the second version.

4. The crash handling method for a mobile application according to claim 1, characterized in that The "Collect the crash information of the mobile application to determine the target function corresponding to the crash information and the first version corresponding to the target function" includes: Monitor the exception stack information of the mobile application to obtain the corresponding crash information when the mobile application crashes; Perform problem transformation on the obtained crash information to determine the target function corresponding to the crash information and the first version corresponding to the target function.

5. The method for handling crashes of a mobile application according to claim 1, characterized in that, The "When it is determined that the crash information meets the preset severe crash condition, trigger a version adjustment instruction" includes: Based on multiple pieces of the crash information within a preset time period, determine the crash trend of the target function; When the crash trend meets the preset trend condition, determine that the crash information meets the preset severe crash condition and trigger a version adjustment instruction.

6. The method for handling crashes of a mobile application according to claim 1, characterized in that After "When the target function is executed, run the target function of the second version", it further includes: When running the target function of the second version, determine whether the target function crashes in the mobile application of the second version and meets the preset severe crash condition; If the target function crashes in the mobile application of the second version and meets the preset severe crash condition, trigger a new version adjustment instruction; Based on the new version adjustment instruction, determine the third version corresponding to the target function; When the target function is executed again, run the target function of the third version.

7. The method for handling crashes of a mobile application according to claim 2, wherein After "Define code interfaces for implementing different application functions, and extract multiple function code files corresponding to each code interface for implementing the corresponding application function from the code data", it further includes: Determine the first identification field of each of the function code files based on the identification field of the target function corresponding to each of the function code files and the identification field of the version information; Before running the second version when the target function is executed, it further includes: Based on a preset mapping rule, map the identification field of the target function and the identification field of the second version to obtain the second identification field corresponding to the target function; Determine whether the second identification field matches the first identification field; If they match, obtain the function code file corresponding to the second version.

8. A crash handling device for a mobile application, characterized in that The crash handling device includes: An analysis component, configured to collect the crash information of the mobile application to determine the target function corresponding to the crash information and the first version corresponding to the target function, and trigger a version adjustment instruction when it is determined that the crash information meets a preset severe crash condition; A background component, configured to adjust the target function from the first version to the second version based on the version adjustment instruction; An execution component, configured to run the second version when the target function is executed.

9. A computer device, characterized in that, The computer device includes: a memory and at least one processor, and instructions are stored in the memory; The at least one processor invokes the instructions in the memory to cause the computer device to execute the crash handling method of the mobile application according to any one of claims 1-7.

10. A computer-readable storage medium having instructions stored thereon, characterized in that, When the instructions are executed by the processor, the crash handling method of the mobile application according to any one of claims 1-7 is implemented.

Images