Unified loading file application generation method, loading method, and storage medium

Abstract

The application discloses a unified loading file application program generation method, a loading method and a storage medium, and belongs to the technical field of iOS file loading. An engineering corresponding to a target application program is created, a second compilation target of a type of class is created, the engineering is compiled and packaged, an installation package of the target application program is generated, two external methods of encapsulating a resource path searching and loading picture in the class are found, a bundle where resource files are located is found, and corresponding resource file paths or pictures are returned to a calling party according to the returned bundle. The application is based on the bundle path characteristics of a dynamic library / static library during packaging to determine the path, and then loading is completed. The application further provides a computer readable storage medium. The application provides a unified and efficient way to load resource files in various modules, so that modular development and communication are more efficient, and the problem of part of the lag caused by loading resource files on line is solved.

Description

Technical Field

[0001] This invention relates to a unified method for generating, loading, and storing file applications, and particularly to a unified method for generating, loading, and storing file applications in dynamic or static libraries in iOS, belonging to the field of iOS file loading technology. Background Technology

[0002] When an iOS app project is modularized using CocoaPods, each module corresponds to a pod library, and each pod library uses a bundle file to store resource files (the bundle file is created manually or generated at compile time by specifying parameters in the podspec of the CocoaPods component). However, there is a lack of a unified method for correctly loading images and files placed in the pod library bundle.

[0003] When an app project is modularized using CocoaPods, the lack of a unified way to load module resource files causes the following problems: (1) Different modules are completed by different developers or different departments. If there is no unified and universal loading method, each module needs to be implemented once, which affects development efficiency and increases the communication cost between module users and providers.

[0004] (2) Some modules extract the common loading method, but the internal implementation uses two for loops to traverse and search (traverse the mainBundle in APP and traverse the bundles in all dynamic libraries in Frameworks), which is inefficient and causes some online lag.

[0005] (3) When loading resource files across modules, for example, if module A uses a resource file in module B, module A needs to add a dependency on module B, and then find the file based on the relative path of a class and resource bundle in module B. Adding module dependencies will cause module coupling, and the loading method is not easy to use.

[0006] Currently, the methods for loading or finding resource files provided in the iOS system's Fundation library are not applicable, specifically the following two: (1) Without the bundle parameter, it is suitable for loading files in the mainBundle of the project. After modularization, the resource files of each module are placed in their respective bundles, not in the mainBundle, so it is not applicable.

[0007] (2) With the bundle parameter, it is suitable for loading files in the specified bundle. If it is loading files in the bundle of your own pod library, you can initialize the resource file bundle according to the bundle where the class is located and the relative path. However, if you want to load the bundle file in another pod library, since the other pod library may not be a library that your own pod library depends on, it is not possible to initialize the resource file bundle according to the bundle where the class is located in the other pod library.

[0008] The existing technology, titled "A Method and Apparatus for Loading Resource Files," mentions applications developed based on the React Native framework. Its approach involves pre-dividing resources into general files and business files, reading them as general file streams and business file streams at application startup, merging them into a resource file stream, loading it into memory, and then passing it to the executor to complete the loading. This invention is applicable to all iOS apps, not limited to those developed based on the React Native framework; furthermore, it does not use stream-related methods. Summary of the Invention

[0009] To address the problems existing in the prior art, the purpose of this invention is to provide a unified method for generating, loading, and storing file applications.

[0010] This invention provides a unified method for generating file loading applications, the method comprising: Create a project corresponding to the target application, wherein the project contains a first compilation target of type application; Create a second compilation target of type class in the project; The project is compiled and packaged to generate an installation package for the target application. The installation package includes an application set corresponding to the first compilation target and classes corresponding to the second compilation target. The first compilation target includes the main program target content of the application; The second compilation target class encapsulates two external methods: finding the resource path and loading the image. It finds the bundle where the resource file is located. The final path of the bundle file in the installation package IPA can be determined. If it is a static library, the bundle path is the mainBundle path appended with " / bundleName.bundle"; if it is a dynamic library, its bundle path is the mainBundle path appended with " / Frameworks / pod library name.framework / bundle name.bundle". Based on the returned bundle, it obtains the corresponding resource file path or image and returns it to the caller.

[0011] The main program target content includes code files; the first compilation target content includes the code files, or the first compilation target content includes the code files and library files, or the first compilation target content includes the code files, library files, and resource files.

[0012] This method can also perform preprocessing: placing the resource files of each module in its own bundle file or using CocoaPods to generate a bundle.

[0013] The method for finding the bundle containing the resource file is to search for the corresponding bundle based on the pod library and the custom bundle name; if no name is specified, the pod name will be used as the bundle name for the search.

[0014] This invention also provides a unified method for loading files, comprising the following steps: Create a new class that encapsulates two external methods: finding the resource path and loading the image. Locate the bundle containing the resource files. The final path of the bundle file in the installation package (ipa) is determinable. For a static library, the bundle path is the mainBundle path appended with " / bundleName.bundle"; for a dynamic library, the bundle path is the mainBundle path appended with " / Frameworks / pod_library_name.framework / bundle_name.bundle". The corresponding resource file path or image is obtained from the returned bundle and returned to the caller; The caller loads the file.

[0015] This method also includes steps such as pre-placing the resource files of each module in its own bundle file or using CocoaPods to generate a bundle. The method for finding the bundle containing the resource file is to search for the corresponding bundle based on the pod library and the custom bundle name; if no name is specified, the pod name is used as the bundle name for searching by default.

[0016] The present invention also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the methods described above.

[0017] This invention determines the path based on the characteristics of the bundle path when packaging dynamic and static libraries, thereby completing the loading. The beneficial effects of this invention are: it provides a unified and relatively efficient way to load resource files in various modules, making modular development and communication more efficient, and solving some of the stuttering issues caused by loading resource files in online systems. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a unified file loading application generation method according to an example of the present invention.

[0019] Figure 2 This is a flowchart illustrating a unified file loading method according to the present invention. Detailed Implementation

[0020] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. These specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0021] Figure 1 This is a flowchart illustrating a unified file loading application generation method according to the present invention, such as... Figure 1 As shown, a unified file loading application generation method includes the following steps: S1: Create a project corresponding to the target application, wherein the project contains a first compilation target of type application; S2: Create a second compilation target of type class in the project; S3: Compile and package the project. S4: Generate the installation package of the target application, wherein the installation package includes an application set corresponding to the first compilation target and a class corresponding to the second compilation target; wherein, The first compilation target includes the main program target content of the application; The second compilation target class encapsulates two external methods: finding the resource path and loading the image. It finds the bundle where the resource file is located. The final path of the bundle file in the installation package IPA can be determined. If it is a static library, the bundle path is the mainBundle path appended with " / bundleName.bundle"; if it is a dynamic library, its bundle path is the mainBundle path appended with " / Frameworks / pod library name.framework / bundle name.bundle". Based on the returned bundle, it obtains the corresponding resource file path or image and returns it to the caller.

[0022] The main program target content includes code files; the first compilation target content includes the code files, or the first compilation target content includes the code files and library files, or the first compilation target content includes the code files, library files, and resource files.

[0023] The generation method also includes preprocessing S0: placing the resource files of each module in its own bundle file or using CocoaPods to generate the bundle.

[0024] The method for finding the bundle containing the resource file is to search for the corresponding bundle based on the pod library and the custom bundle name; if no name is specified, the pod name will be used as the bundle name for the search.

[0025] The resource files are resources required during program execution, including but not limited to images, audio, video, multilingual string files, nib files, data files, configuration files, etc. Furthermore, Figure 2 This is a flowchart illustrating a unified file loading method according to an example of the present invention, such as... Figure 2 The flowchart shown below illustrates a unified method for loading files, which includes the following steps: S11: Create a new class, such as LAPodHelper, and encapsulate two external methods in the class: finding resource paths and loading images; S12: The first step of both methods is to find the bundle where the resource file is located. Therefore, it is extracted into a method to find the corresponding bundle based on the pod library and the custom bundle name. However, in actual development, the bundle name and the pod name are usually the same. Therefore, if the bundle name is not passed, the pod name will be used as the bundle name to find the bundle by default. The key to the search method is that regardless of whether the module is integrated as a dynamic or static library, the final path of its bundle file in the installation package (ipa) can be determined. If it is a static library, the bundle path is the mainBundle path appended with " / bundleName.bundle"; if it is a dynamic library, the bundle path is the mainBundle path appended with " / Frameworks / pod_library_name.framework / bundle_name.bundle".

[0026] S13: Based on the bundle returned by S12, obtain the corresponding resource file path or image and return it to the caller; S14: The caller loads the file.

[0027] This method also includes S0 preprocessing: the steps of pre-placing the resource files of each module in its own bundle file (as agreed upon in advance) or using CocoaPods to generate the bundle. The method for finding the bundle containing the resource file is to search for the corresponding bundle based on the pod library and the custom bundle name; if no name is specified, the pod name is used as the bundle name for searching by default.

[0028] First, this invention allows us to use CocoaPods for modularization. To centralize resource files, we can agree that all resource files are placed in their respective module bundles (resource files: resources needed during program execution, such as images, audio, video, multi-language string files, nib files, data files, configuration files, etc.). Second, for an app project, the final output of a pod library module is either a dynamic library or a static library. Their bundle paths are determined at compile time: dynamic libraries are "mainBundle path / Frameworks / pod library name.framework / bundle name.bundle", and static libraries are "mainBundle path / bundle name.bundle". Therefore, the corresponding bundle can be initialized based on this explicit path, allowing for efficient retrieval of the corresponding bundle at runtime. Another advantage of this approach is that it eliminates the need to determine the bundle through classes within the module, reducing dependencies between modules. Finally, in development, resource files are generally divided into two categories: images and non-images. For images, we use a UIImage object initialized based on the image name; for non-images, the key is to find the path, because the system already has a unified method for subsequent read and write operations. Therefore, encapsulating two methods—getting the image and getting the file path—can meet the requirements.

[0029] The present invention also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the method described above.

[0030] This invention determines the path based on the bundle path characteristics of dynamic and static libraries during packaging, thereby completing the loading process. This invention provides a unified and relatively efficient way to load resource files within various modules, making modular development and communication more efficient, and resolving some online lag issues caused by loading resource files.

Claims

1. A unified method for generating file loading applications, characterized in that, The method includes: Create a project corresponding to the target application, wherein the project contains a first compilation target of type application; In the project, a second compilation target of type class is created. The second compilation target serves as an interface for uniformly loading resource files within each module. The project is compiled and packaged to generate an installation package for the target application. The installation package includes an application set corresponding to the first compilation target and classes corresponding to the second compilation target. The first compilation target includes the main program target content of the application; The second compilation target class encapsulates two external methods: finding resource paths and loading images. It locates the bundle containing the resource file based on the pod library and a custom bundle name. This search does not depend on the target module's class but is based on the fixed path of the bundle within the installation package. The final path of the bundle file in the installation package (IPA) is determinable: for a static library, the bundle path is the mainBundle path appended with " / bundleName.bundle"; for a dynamic library, the bundle path is the mainBundle path appended with " / Frameworks / pod library name.framework / bundle name.bundle". Based on the returned bundle, the corresponding resource file path or image is retrieved and returned to the caller.

2. The unified loading file application generation method as described in claim 1, characterized in that, The main program target content includes code files; the first compilation target content includes the code files, or the code files and library files, or the code files, library files, and resource files.

3. The unified loading file application generation method as described in claim 1, characterized in that, The method also includes preprocessing: placing the resource files of each module in its own bundle file or using CocoaPods to generate a bundle.

4. The unified loading file application generation method as described in claim 1, characterized in that, If not specified, the pod name will be used as the bundle name for lookup by default.

5. A unified method for loading files, characterized in that, Includes the following steps: Create a new class that encapsulates two external methods: finding resource paths and loading images. This class serves as the interface for uniformly loading resource files from various modules. The method involves locating the bundle containing the resource file based on the pod library and a custom bundle name. This search does not depend on the target module's classes but is based on the fixed path of the bundle within the installation package. The final path of the bundle file in the installation package (IPA) is determinable. For a static library, the bundle path is the mainBundle path appended with " / bundleName.bundle"; for a dynamic library, the bundle path is the mainBundle path appended with " / Frameworks / pod library name.framework / bundle name.bundle". The corresponding resource file path or image is obtained from the returned bundle and returned to the caller; The caller loads the file.

6. The method for loading a unified loading file as described in claim 5, characterized in that, This method also The steps include placing the resource files of each module in its own bundle file beforehand or using CocoaPods to generate the bundle.

7. The method for loading a unified loading file as described in claim 5, characterized in that, If not specified, the pod name will be used as the bundle name for lookup by default.

8. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the method as described in any one of claims 1 to 7.

Images