System and method for identifying picture loading source in Android application program
By transforming the image library and registering life cycle listeners in Android applications, establishing the relationship between image requests and pages, the problem of difficult to track the image loading sources within the App is solved, efficient image loading optimization and resource management are achieved, and the User experience.
Patent Information
- Application Number
- CN202411364761.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-27
- Publication Date
- 2024-12-27
AI Technical Summary
In the mobile Internet industry, it is difficult to accurately track the source of the image loading of the app, which leads to difficulty in optimization, increases the workload of business and operation and maintenance personnel, and is difficult to determine resource waste and responsibilities, which affects the user experience.
In Android applications, the image library is transformed through the tracking system, the image request is associated with the image View, the class name of the Fragment is marked with the Tag module, the image loading tracking module traverses the view tree upward, the page alias obtains the module registration lifecycle listener, and establishes a The relationship between image request and page is achieved to accurately track the source of image loading.
It realizes accurate tracking of business modules and pages initiated by image loading within the App, saves working time and costs, has an accuracy of more than 95%, and quickly locates image loading problems or performance bottlenecks.
Smart Images
Figure CN119201530A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of computer technology, and in particular relates to a system and method for identifying a picture loading source in an Android application. Background Art
[0002] Over the past decade, the mobile Internet industry has experienced rapid development, but as time goes by, the industry and its many internal segments have gradually faced challenges in user growth. First, the growth of mobile Internet users is affected by the saturation of Internet penetration. In developed areas, almost everyone already owns a smartphone and is connected to the Internet, which means that the growth rate of new users is relatively slow. Secondly, fierce competition in many segments within the industry also limits the possibility of user growth.
[0003] In an App, a good experience of image loading is essential for refined operations. By optimizing the speed and quality of image loading, the user experience can be significantly improved. High-quality images that load quickly can quickly attract users' attention, increase user retention time, and encourage users to have a deeper understanding of products or services. Within a company, due to the wide range of businesses, Apps often cover many business modules. This often leads to a common problem: it is difficult to accurately find which specific business module initiated the loading of a certain image. In this case, once an image loading problem or performance bottleneck occurs, optimization will become extremely difficult. In the existing technology, from the perspective of the client, the image library is modified in the App. When the business module calls the image library to initiate image loading, Business developers are required to pass the corresponding business identifiers. This approach will cause a huge workload for business developers. From the server perspective, the operation and maintenance personnel deploy the image server or image directory separately according to the business. Business differentiation on the image link path requires the operation and maintenance personnel to pay attention to and follow up on the business development, which increases the workload of the operation and maintenance personnel. The separate deployment of image servers or image directories will cause a waste of resources. The workload of promoting the transformation of the original images is huge because it involves multiple business modules. The initiation of image loading may be scattered in various modules, making it difficult for the maintenance personnel to determine the responsibility, thereby delaying the resolution of the problem and affecting the user experience. In order to solve this problem, it is particularly necessary to establish a mechanism to track the business module that initiates image loading. Summary of the invention
[0004] The purpose of the present invention is to provide a system and method for identifying the source of image loading in an Android application to solve the problems raised in the above background technology.
[0005] In order to achieve the above object, the present invention provides the following technical solution: a system for identifying the source of image loading in an Android application, comprising:
[0006] Tracking system: used to track the source of image loading;
[0007] The tracking system includes:
[0008] Association module: used to transform the image library in the Android application and associate the image request with the image View;
[0009] Tag module: used to modify the onCreateView method of Fragment by inserting code when compiling an Android application, and add a Tag to the View returned by this method. The Tag marks the class name of the Fragment, so that the Fragment to which it belongs can be determined by checking the Tag of the View at runtime;
[0010] Image loading tracking module: used to find the corresponding image View through the image request when the image request ends, and traverse the view tree upward to check whether each parent View has the tag of the top-level View of the Fragment;
[0011] Page alias acquisition module: used to register the Activity lifecycle listener to obtain the alias of the Activity page, and to obtain the alias of the Fragment page by modifying the Fragment lifecycle method through plug-in code during compilation.
[0012] Preferably, the association module ensures that the image request can be traced back to the specific image View by saving a reference to the image View in the image request object. When the image View is removed from the page, the image needs to be disassociated from the image View.
[0013] A method for identifying the source of image loading in an Android application, the specific steps are as follows:
[0014] Step 1:
[0015] Modify the image library in the Android application and associate the image request with the image View. The main thing is to save and reference the image View as a member variable of the image request to ensure that the image View can be found from the image request. It should be noted that the association relationship can only be established when the image View is added to the interface. The image View is added to the interface mainly by listening to the onAttachedToWi ndow method of the View. The image View is removed from the interface mainly by listening to the onDetachedFromWi ndow method of the View. This modification is applicable to all Android image libraries and has a low modification cost. This step establishes an association relationship between the image request and the image View.
[0016] Step 2:
[0017] When compiling the Android application, modify the onCreateView method of the Fragment through the plug-in code, tag the View returned by this method, and mark the class name of the Fragment to which it belongs. This View is the top-level View of the Fragment page;
[0018] Step 3:
[0019] When the Android application is running, when the image request ends, the image View is found from the image request, and then the image View is traversed upward, mainly through the View's getParent method to obtain its parent View, and determine whether the View has the tag in step 2. If so, the page where the View is located is the corresponding Fragment page. If the tagged View is not found in the end, the page where the View is located is the corresponding Activity page. All Views will always be attached to an Activity page in the end, so even if the Fragment page is not found, the page where the image View is located will eventually be an Activity page. This step establishes an association relationship between the image View and the page it is on, mainly establishing an association relationship between the image View and the class name of the page it is on.
[0020] Step 4:
[0021] Register the Activity page life cycle listener through the Android application's Appli cation's registryActivityLifecycleCallbacks method to listen to the Activity page life cycle and obtain the Activity page's alias. This step associates the Activity page with its alias, mainly by associating the Activity page class name with its alias.
[0022] Step 5:
[0023] When the Android application is compiled, the life cycle method of the Fragment is modified by inserting code to obtain the alias of the Fragment page. This step associates the Fragment page with its alias, mainly by associating the Fragment page class name with its alias.
[0024] Step 6:
[0025] By connecting the above steps in series, a link can be formed: image request - image view - the page where the image view is located - the alias of the page where the image view is located. In this way, the page that initiates the image loading can be known from the image request;
[0026] Step 7:
[0027] The alias of a page is usually existing because the operations staff need to collect statistics on the page data to analyze the business situation. The business of the page can be understood from the alias of the page.
[0028] Preferably, when tagging the View in step 2, it is necessary to ensure that the tag of the top-level View of the Fragment is unique to avoid confusion.
[0029] Preferably, the method of traversing upward in step 3 can be performed by using a recursive method to traverse upward until a View with a Tag is found or the root View is reached.
[0030] Preferably, the Activity page lifecycle listener in step 4 needs to register and unregister the listener at an appropriate time to avoid memory leaks caused by failure to remove the listener at an appropriate time.
[0031] Preferably, after the insertion of the code in step 5 is completed, sufficient testing and verification needs to be performed to ensure that the alias can be correctly set and obtained, and the life cycle behavior of the Fragment is not affected.
[0032] Preferably, if there is no alias for the page in step 7, the business of the page can also be known through the class name of the page. The prefix of the class name is usually the package name, and the package names of different businesses are different.
[0033] Preferably, the image View and the page where it is located in step 1 have their own life cycles. When establishing an association relationship, it is necessary to ensure that these components are active. If the image View or the page where it is located has been destroyed, then attempting to establish an association relationship may result in a null pointer exception or other runtime errors.
[0034] The beneficial effects of the present invention are as follows:
[0035] This solution provides a solution for tracking business modules and business pages initiated by image loading within an App. Through steps one, two, and three, the system mechanism and plug-in technology of Android are used for unified processing, and the relationship between the image request and the page initiated by the image loading is automatically established. Steps four and five are used for unified processing by the system mechanism and plug-in technology of Android, and the relationship between the page and the page alias is automatically established. Through the above steps, the relationship between the image request and the page loaded with the image and the page alias is automatically established, which saves a lot of work time and cost for business and operation and maintenance, and the accuracy can reach more than 95%. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] Figure 1 It is a complete flow chart of the present invention;
[0037] Figure 2 It is a schematic diagram of the structure of the tracking system of the present invention. DETAILED DESCRIPTION
[0038] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0039] like Figure 1 to Figure 2 As shown, an embodiment of the present invention provides a system for identifying a source of image loading in an Android application, including:
[0040] Tracking system: used to track the source of image loading;
[0041] The tracking system includes:
[0042] Association module: used to transform the image library in the Android application and associate the image request with the image View;
[0043] Tag module: used to modify the onCreateView method of Fragment by inserting code when compiling an Android application, and add a Tag to the View returned by this method. The Tag marks the class name of the Fragment, so that the Fragment to which it belongs can be determined by checking the Tag of the View at runtime;
[0044] Image loading tracking module: used to find the corresponding image View through the image request when the image request ends, and traverse the view tree upward to check whether each parent View has the tag of the top-level View of the Fragment;
[0045] Page alias acquisition module: used to register the Activity lifecycle listener to obtain the alias of the Activity page, and to obtain the alias of the Fragment page by modifying the Fragment lifecycle method through plug-in code during compilation.
[0046] Starting from the image request, the page where the image is located is found through the image View, and the alias of the page is further obtained, and then the image request is traced back to the specific page and its business that initiated the image loading.
[0047] The association module ensures that the image request can be traced back to the specific image View by saving a reference to the image View in the image request object. When the image View is removed from the page, the image needs to be disassociated from the image View.
[0048] By monitoring the onAttachedToWi ndow and onDetachedFromWi ndow methods, ensure that the association between the image request and the image View is established when the View is added to the interface and is released when the View is removed from the interface to avoid memory leaks and ensure effective resource management.
[0049] A method for identifying the source of image loading in an Android application, the specific steps are as follows:
[0050] Step 1:
[0051] Modify the image library in the Android application and associate the image request with the image View. The main thing is to save and reference the image View as a member variable of the image request to ensure that the image View can be found from the image request. It should be noted that the association relationship can only be established when the image View is added to the interface. The image View is added to the interface mainly by listening to the onAttachedToWi ndow method of the View. The image View is removed from the interface mainly by listening to the onDetachedFromWi ndow method of the View. This modification is applicable to all Android image libraries and has a low modification cost. This step establishes an association relationship between the image request and the image View.
[0052] Step 2:
[0053] When the Android application is compiled, the onCreateView method of the Fragment is modified by inserting code, and the View returned by this method is tagged with the class name of the Fragment to which it belongs. This View is the top-level View of the Fragment page.
[0054] Step 3:
[0055] When the Android application is running, when the image request ends, the image View is found from the image request, and then the image View is traversed upwards, mainly through the getParent method of View to obtain its parent View, and determine whether the View has the tag in step 2. If so, the page where the View is located is the corresponding Fragment page. If the tagged View is not found in the end, the page where the View is located is the corresponding Activity page. All Views will always be attached to an Activity page in the end, so even if the Fragment page is not found, the page where the image View is located will eventually be an Activity page. This step establishes an association relationship between the image View and the page it is on, mainly establishing an association relationship between the image View and the class name of the page it is on.
[0056] Step 4:
[0057] Register the Activity page lifecycle listener through the Android application's Application's registerActivityL ifecyc l eCallbacks method to listen to the Activity page lifecycle and obtain the Activity page's alias. This step associates the Activity page with its alias, mainly by associating the Activity page class name with its alias.
[0058] Step 5:
[0059] When the Android application is compiled, the life cycle method of the Fragment is modified by inserting code to obtain the alias of the Fragment page. This step associates the Fragment page with its alias, mainly by associating the Fragment page class name with its alias.
[0060] Step 6:
[0061] By connecting the above steps in series, a link can be formed: image request - image view - the page where the image view is located - the alias of the page where the image view is located. In this way, the page that initiates the image loading can be known from the image request;
[0062] Step 7:
[0063] The alias of a page is usually existing because the operations staff need to collect statistics on the page data to analyze the business situation. The business of the page can be understood from the alias of the page.
[0064] By transforming the image library in the Android application, the image View is saved and referenced as a member variable of the image request, thereby associating the image request with the image View. Then, by utilizing Android's system mechanism and plug-in technology, an association relationship is established between the image View and the page where it is located, and a relationship between the page and the page alias is automatically established. In this way, the business modules and business pages initiated by the image loading within the App can be tracked, so as to quickly locate the person responsible for the image loading problem or performance problem.
[0065] When tagging the View in step 2, you need to ensure that the tag of the top-level View of the Fragment is unique to avoid confusion.
[0066] By tagging the returned View and marking the Fragment class name to which it belongs, it is easy to quickly identify the Fragment to which the image View belongs during runtime.
[0067] Among them, the method of traversing upward in step three can be traversed upward by using a recursive method until a View with a Tag is found or the root View is reached.
[0068] By traversing upward through the image View, it is possible to accurately identify whether the page where the image View is located is a Fragment or an Activity, and which specific Fragment or Activity it is.
[0069] Among them, the Activity page lifecycle listener in step 4 needs to register and unregister the listener at the appropriate time to avoid memory leaks caused by failure to remove the listener at the appropriate time.
[0070] Through the registerActivityLifecycleCal lbacks method of Appli icat ion, a listener is registered to monitor the life cycle changes of Activity, and the alias of Activity can be obtained at runtime, which plays a key role in subsequent data statistics and analysis.
[0071] Among them, after completing the insertion in step 5, sufficient testing and verification are required to ensure that the alias can be set and obtained correctly and the life cycle behavior of the Fragment is not affected.
[0072] By modifying the Fragment lifecycle method through plug-in code during compilation to obtain the Fragment alias, the usage of the Fragment page can be more accurately tracked and analyzed, helping developers understand user behavior and optimize product experience.
[0073] If there is no alias for the page in step seven, the business of the page can also be known through the class name of the page. The prefix of the class name is usually the package name, and the package names of different businesses are different.
[0074] In the absence of a page alias, you can use the page class name to learn about the page's business and then track the business module that initiates image loading.
[0075] In step 1, the image View and the page it is on have their own life cycles. When establishing an association, you need to ensure that these components are active. If the image View or the page it is on has been destroyed, attempting to establish an association may result in a null pointer exception or other runtime errors.
[0076] By associating the image View with the page it is on, you can ensure that when tracing the source of the image loading, you can accurately locate the page on which the image was loaded.
[0077] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.
[0078] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.
Claims
1. A system for identifying the source of image loading in an Android application, characterized in that ,include: Tracking system: used to track the source of image loading; The tracking system includes: Association module: used to transform the image library in the Android application and associate the image request with the image View; Tag module: used to modify the onCreateView method of Fragment by inserting code when compiling an Android application, and add a Tag to the View returned by this method. The Tag marks the class name of the Fragment, so that the Fragment to which it belongs can be determined by checking the Tag of the View at runtime; Image loading tracking module: used to find the corresponding image View through the image request when the image request ends, and traverse the view tree upward to check whether each parent View has the tag of the top-level View of the Fragment; Page alias acquisition module: used to register the Activity lifecycle listener to obtain the alias of the Activity page, and to obtain the alias of the Fragment page by modifying the Fragment lifecycle method through plug-in code during compilation.
2. A system for identifying the source of image loading in an Android application according to claim 1, characterized in that: The association module ensures that the image request can be traced back to the specific image View by saving the reference to the image View in the image request object. When the image View is removed from the page, the image needs to be disassociated from the image View.
3. A method for identifying the source of image loading in an Android application, characterized in that , the specific steps are as follows: Step 1: Modify the image library in the Android application and associate the image request with the image View. The main purpose is to save and reference the image View as a member variable of the image request to ensure that the image View can be found from the image request. It should be noted that the association relationship can only be established when the image View is added to the interface. The image View is added to the interface and mainly listens to the onAttachedToWindow method of the View. The image View is removed from the interface and mainly listens to the onDetachedFromWindow method of the View. This modification is applicable to all Android image libraries and has a low modification cost. This step establishes an association relationship between the image request and the image View; Step 2: When compiling an Android application, modify the onCreateView method of the Fragment through insertion code, tag the View returned by this method, and mark the class name of the Fragment to which it belongs. This View is the top-level View of the Fragment page; Step 3: When the Android application is running, when the image request ends, the image View is found from the image request, and then the image View is traversed upwards, mainly through the View's getParent method to obtain its parent View, and determine whether the View has the tag in step 2. If so, the page where the View is located is the corresponding Fragment page. If the tagged View is not found in the end, the page where the View is located is the corresponding Activity page. All Views will always be attached to an Activity page in the end, so even if the Fragment page cannot be found, the page where the image View is located will eventually be an Activity page. This step establishes an association relationship between the image View and the page it is on, mainly establishing an association relationship between the image View and the class name of the page it is on. Step 4: Register the Activity page lifecycle listener through the registerActivityLifecycleCallbacks method of the Android application's Application to listen to the Activity page lifecycle and obtain the alias of the Activity page. This step associates the Activity page with its alias, mainly by associating the Activity page class name with its alias. Step 5: When the Android application is compiled, the life cycle method of the Fragment is modified by inserting code to obtain the alias of the Fragment page. This step establishes an association between the Fragment page and its alias, mainly establishing an association between the Fragment page class name and its alias; Step 6: Connecting the above steps in series, a link can be formed: image request - image view - the page where the image view is located - the alias of the page where the image view is located. In this way, the page that initiates the image loading can be known from the image request; Step 7: The alias of a page is usually existing because the operations staff need to collect statistics on the page data to analyze the business situation. The business of the page can be understood from the alias of the page.
4. The method of identifying the source of image loading in an Android application according to claim 3, characterized in that: When tagging the View as described in step 2, you need to ensure that the tag of the top-level View of the Fragment is unique to avoid confusion.
5. The method of identifying the source of image loading in an Android application according to claim 3, characterized in that: The upward traversal method described in step 3 can be traversed upward by using a recursive method until a View with a Tag is found or the root View is reached.
6. The method of identifying the source of image loading in an Android application according to claim 3, characterized in that: The Activity page lifecycle listener described in step 4 needs to be registered and unregistered at the appropriate time to avoid memory leaks caused by failure to remove the listener at the appropriate time.
7. The method of identifying the source of image loading in an Android application according to claim 3, characterized in that: After completing the insertion as described in step 5, sufficient testing and verification are required to ensure that the alias can be set and obtained correctly and the life cycle behavior of the Fragment is not affected.
8. The method of identifying the source of image loading in an Android application according to claim 3, characterized in that: As described in step 7, if there is no alias for the page, the business of the page can also be known through the class name of the page. The prefix of the class name is usually the package name, and the package names of different businesses are different.
9. The method of identifying the source of image loading in an Android application according to claim 3, characterized in that: The image View and the page it is on in step 1 have their own life cycles. When establishing an association, you need to ensure that these components are active. If the image View or the page it is on has been destroyed, attempting to establish an association may result in a null pointer exception or other runtime errors.