Application development method and device, electronic equipment and storage medium

Abstract

The invention relates to an application development method and device, electronic equipment and a storage medium, and relates to the field of software engineering. The method comprises the following steps: determining an adaptive target dynamic library and a code execution path according to hardware information and operating system information of target equipment; obtaining a development code of a target application input by a developer through target equipment; compiling the development code based on the target dynamic library and the code execution path; and in response to compilation completion, determining a target application based on the packaging information and the development code input by the developer through the target equipment. By applying the method and the device, the defects in the aspects of architecture compatibility and platform adaptability are overcome, so that the development of the application program is more convenient.

Description

Technical Field

[0001] The present application relates to the field of software engineering technology, and in particular to an application development method, device, electronic device and storage medium. Background Art

[0002] With the rapid development of information technology and the country's emphasis on independent and controllable information security, more and more desktop application software needs to be migrated from foreign operating systems and hardware environments to domestic platforms to reduce dependence on foreign technologies. However, the existing desktop application development framework is insufficient in terms of architecture compatibility and platform adaptability, which makes the application programs often face problems such as low compatibility, high adaptation costs, and unstable performance during the localization migration process. These problems complicate the migration process and seriously increase the software development cost, migration cost, and subsequent maintenance cost. Summary of the invention

[0003] Embodiments of the present disclosure provide an application development method, device, electronic device, and storage medium.

[0004] In a first aspect, an embodiment of the present disclosure provides an application development method, comprising: determining an adapted target dynamic library and a code execution path based on hardware information and operating system information of a target device; obtaining development code of a target application input by a developer through the target device; compiling the development code based on the target dynamic library and the code execution path; in response to completion of the compilation, determining a target application based on packaging information and the development code input by the developer through the target device.

[0005] In a second aspect, an embodiment of the present disclosure provides an application development device, comprising: a determination unit, configured to determine an adapted target dynamic library and a code execution path based on hardware information and operating system information of a target device; an acquisition unit, configured to acquire a development code of a target application input by a developer through a target device; a compilation unit, configured to compile the development code based on the target dynamic library and the code execution path; and a development unit, configured to determine a target application based on packaging information and the development code input by the developer through the target device in response to completion of the compilation.

[0006] In a third aspect, an embodiment of the present disclosure provides an electronic device, comprising a memory, a processor, a bus, and a computer program stored in the memory and executable on the processor, wherein the processor implements the application development method described in the first aspect when executing the computer program.

[0007] In a fourth aspect, an embodiment of the present disclosure provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the application development method described in the first aspect.

[0008] By applying the technical solution disclosed in the present invention, the adapted target dynamic library and code execution path can be determined according to the hardware information and operating system information of the target device. After obtaining the development code of the target application input by the developer through the target device, the development code can be compiled based on the target dynamic library and the code execution path. After the compilation is completed, it can be packaged according to the packaging information input by the developer through the target device, thereby obtaining the target application and completing the development of the target application. Compared with the prior art, the solution disclosed in the present invention makes up for the deficiencies in architecture compatibility and platform adaptability, making the development of application programs more convenient.

[0009] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure.

[0011] Figure 1 An exemplary system architecture diagram in which an embodiment of the application development method of the present disclosure can be applied;

[0012] Figure 2 A flowchart of an embodiment of the application development method disclosed herein;

[0013] Figure 3 A flowchart of another embodiment of the application development method disclosed herein;

[0014] Figure 4 A schematic diagram of the structure of the application development framework in the application development method disclosed in the present invention;

[0015] Figure 5 A schematic diagram of the structure of an embodiment of the application development device disclosed in the present invention;

[0016] Figure 6 A schematic diagram of the structure of an embodiment of an electronic device disclosed herein. DETAILED DESCRIPTION

[0017] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present disclosure belongs.

[0018] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present disclosure. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, it indicates the presence of features, steps, operations, devices, components and / or combinations thereof.

[0019] In the absence of conflict, the embodiments in the present disclosure and the features in the embodiments may be combined with each other.

[0020] In order to make the technical solutions and advantages of the present disclosure more clearly understood, the present disclosure is further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0021] Figure 1 An exemplary system architecture 100 is shown to which an embodiment of the application development method or application development apparatus of the present disclosure can be applied.

[0022] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0023] The user can use the terminal devices 101, 102, 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications, such as application development applications, can be installed on the terminal devices 101, 102, 103. The user can input the development code through the terminal devices 101, 102, 103 and operate the application development application to compile the development code and develop the application.

[0024] Terminal devices 101, 102, 103 can be hardware or software. When terminal devices 101, 102, 103 are hardware, they can be various electronic devices, including but not limited to smart phones, tablet computers, car computers, laptop computers, desktop computers, etc. When terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software or software modules (for example, to provide distributed services), or they can be implemented as a single software or software module. No specific limitation is made here.

[0025] The server 105 may be a server that provides various services, such as a background server that provides support for application development applications installed on the terminal devices 101, 102, 103. The background server may provide corresponding algorithms and feedback to the terminal devices 101, 102, 103 when the user calls certain functional modules through each terminal device 101, 102, 103.

[0026] It should be noted that the server 105 can be hardware or software. When the server 105 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or it can be implemented as a single server. When the server 105 is software, it can be implemented as multiple software or software modules (for example, for providing distributed services), or it can be implemented as a single software or software module. No specific limitation is made here.

[0027] It should be noted that the application development method provided in the embodiment of the present disclosure is generally executed by the terminal devices 101, 102, 103. Accordingly, the application development apparatus is generally provided in the terminal devices 101, 102, 103.

[0028] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0029] Figure 2 FIG. 200 shows a process 200 of an embodiment of the application development method of the present disclosure. Figure 2 As shown, the application development method of this embodiment may include the following steps:

[0030] Step 201, determining the adapted target dynamic library and code execution path according to the hardware information and operating system information of the target device.

[0031] In this embodiment, the execution subject of the application development method (for example Figure 1 The terminal devices 101, 102, 103 shown in the figure can first obtain the hardware information and operating system information of the target device. Then, according to the hardware information and operating system information, determine the adapted target dynamic library and code execution path. Here, the target device can be a device that installs the application development framework. The execution subject can be the target device itself. The hardware information may include the CPU architecture, such as X86-64, ARM64, MIPS64EL, etc. The operating system information may include the operating system used by the target device, such as Linux, Tongxin, Galaxy Kirin, etc.

[0032] The execution subject can determine the hardware information and operating system information in a variety of ways. For example, the hardware information can be obtained through the API provided by the operating system. Taking the Linux operating system and domestic operating systems such as Tongxin and Kylin as examples, the CPU architecture can be determined by reading the / proc / cpuinfo file or using the uname command. Taking the Windows operating system as an example, the IsProcessorFeaturePresent function can be used to detect the CPU architecture. In addition, the CPU architecture can also be determined through compiler macros when compiling the code.

[0033] In this embodiment, different dynamic libraries and code execution paths can be adapted for different hardware information and operating system information. After determining the hardware information and operating system information of the target device, the adapted target dynamic library and code execution path can be determined.

[0034] Step 202: Acquire the development code of the target application input by the developer through the target device.

[0035] Developers can use the application development framework installed in the target device to develop applications. Specifically, the development code of the target application can be entered in the interface of the application development framework. The target application here is the application to be developed by the developer. The development code can be in the language that the developer is good at using. The application development framework can perform language mapping on the above language, so as to achieve understanding of the development code.

[0036] Step 203, compile the development code based on the target dynamic library and the code execution path.

[0037] After the development code is obtained, the development code can be compiled based on the target dynamic library and the code execution path. Specifically, the target dynamic library can be loaded and the development code can be compiled according to the code execution path.

[0038] Step 204 , in response to the compilation being completed, determining a target application based on the packaging information and development code input by the developer through the target device.

[0039] After the development code is compiled, the packaging information input by the developer through the target device can be further obtained. The packaging information can include the hardware information and operating system information adapted by the target application. It is understandable that the hardware information adapted by the target application can be different from the hardware information of the target device, and the operating system information adapted by the target application can be different from the operating system information of the target device.

[0040] After the development code is compiled, the target application can be determined based on the above packaging information and the development code. Specifically, the development code can be packaged, and a file package that matches the packaging information format can be input as the target application. It is understandable that during the packaging process, user permissions can be set for the development code. In this way, other developers can view or modify the development code based on user permissions. In addition, an encryption algorithm can be called to encrypt the development code during the packaging process, which can further enhance the security of the development code. In some specific practices, in order to further enhance the security of the development code, the development code can be signed and verified.

[0041] The application development method provided by the above-mentioned embodiment of the present disclosure can determine the adapted target dynamic library and code execution path according to the hardware information and operating system information of the target device. After obtaining the development code of the target application input by the developer through the target device, the development code can be compiled based on the target dynamic library and the code execution path. After the compilation is completed, it can be packaged according to the packaging information input by the developer through the target device, so as to obtain the target application and complete the development of the target application. Compared with the prior art, the solution of the present disclosure makes up for the deficiencies in architecture compatibility and platform adaptability, making the development of application programs more convenient.

[0042] Continue to see Figure 3 , which shows a process 300 of another embodiment of the application development method according to the present disclosure. Figure 3 As shown, the method in this embodiment may include the following steps:

[0043] Step 301, determine the first dynamic library according to the hardware information and the preset first mapping relationship; determine the second dynamic library according to the operating system information and the preset second mapping relationship; determine the target dynamic library according to the first dynamic library and the second dynamic library; determine the code execution path according to the hardware information and the third mapping relationship.

[0044] Since different hardware corresponds to different dynamic libraries, different operating systems correspond to different dynamic libraries. In this embodiment, a correspondence between hardware information and dynamic libraries can be established in advance, which is called a first mapping relationship. A correspondence between operating system information and dynamic libraries can also be established in advance, which is called a second mapping relationship. In addition, a correspondence between hardware information and code execution paths can also be established in advance, which is called a third mapping relationship.

[0045] Then, the first dynamic library can be determined according to the hardware information of the target device and the preset first mapping relationship. Then, the second dynamic library can be determined according to the operating system information of the target device and the preset second mapping relationship. The first dynamic library and the second dynamic library are combined to obtain the target dynamic library. Finally, the code execution path can be determined according to the hardware information and the third mapping relationship.

[0046] Step 302: Acquire the development code of the target application input by the developer through the target device.

[0047] Step 303, load the target dynamic library; and conditionally compile the development code according to the code execution path.

[0048] After determining the target dynamic library, the target dynamic library can be loaded. Specifically, when the application development framework is running in the target device, the first dynamic library can be loaded. During the operation of the application development framework in the target device, the second dynamic library can be loaded according to the operating system. Then, the development code is conditionally compiled according to the code execution path. Conditional compilation can be used to implement code for different CPU architectures. Whenever compiling, the compiler will compile the corresponding code according to the CPU architecture. In some specific practices, the conditional compilation function of C / C++ can be used to select the implementation code for different CPU architectures through compilation instructions (such as #ifdef).

[0049] Step 304, in response to detecting a call request for a preset function module, determining a required memory block size according to the call request; and allocating memory for the call request according to the memory block size.

[0050] In this embodiment, the application development framework may include multiple functional modules. Different functional modules may implement different functions, such as implementing a function of calling an encryption algorithm, implementing a function of signature verification, implementing a function of file operation, and the like.

[0051] If a call request to the above-mentioned functional module is detected, the required memory block size can be determined according to the call request. Specifically, the call request can be analyzed to determine the memory block size required for processing the above-mentioned call request. Then, memory can be allocated for the call request according to the above-mentioned memory block size. Specifically, a memory as large as the above-mentioned memory block size can be divided from the memory for allocation. When allocating memory, a memory allocator can be used to allocate memory. In this embodiment, a dedicated memory allocator and a dedicated memory allocation strategy can be designed for different CPU architectures, and the memory allocator can allocate memory according to the above-mentioned memory allocation strategy.

[0052] In some optional implementations of this embodiment, when allocating memory, a memory pool design may be used. Specifically, if the size of the above-mentioned memory block is larger than the size of each memory block in the preset memory pool, it means that each memory block in the memory pool cannot meet the memory needs. In this case, according to the above-mentioned memory block size, memory blocks are divided from the memory for allocation. If the size of the memory block is less than or equal to the size of any memory block in the memory pool, it means that there are memory blocks in the memory pool that can meet the memory needs, and a memory block can be selected from the memory pool for allocation.

[0053] Memory pools can effectively reduce memory fragmentation caused by frequent allocation and release. By creating memory pools for objects of different sizes, memory blocks can be quickly allocated and reused to reduce allocation overhead. The size of each memory block in a memory pool can be a power of 2. Such small blocks can efficiently manage small objects and reduce memory waste. For call requests for large memory blocks, large block allocation can be used to avoid fragmentation caused by accumulation of small blocks.

[0054] In some optional implementations of this embodiment, a memory pool can be established in advance. Specifically, the cache line can be determined first according to the hardware information. Then, according to the cache line, multiple memory blocks are divided from the paper memory and stored in the memory pool. A cache line is the smallest data block stored in the cache, usually 64 bytes in size. A cache line is the basic component unit of the cache and is used to increase the speed of data access. Since the CPU accesses the main memory at a slow speed, the use of cache lines can significantly reduce the number of times the CPU accesses the main memory, thereby improving the overall system performance. For example, the CPU architecture is x86-64 and ARM64, and the cache line size is 64 bytes. The CPU architecture is MIPS64EL, and the cache line size is 32 bytes. When dividing the memory blocks, they can be aligned to the cache lines, which can reduce cache misses and improve allocation efficiency, thereby reducing performance losses.

[0055] Step 305: In response to determining that the call request has been processed, the allocated memory block is returned to the memory pool.

[0056] If the call request is processed, the allocated memory block can be returned to the memory pool, which can reduce cache misses and improve allocation efficiency, thereby reducing performance loss.

[0057] Step 306 , in response to the compilation being completed, determining a target application based on the packaging information and development code input by the developer through the target device.

[0058] Continue to see Figure 4, which shows a schematic diagram of a structure of an application development framework according to the present disclosure. In the application development framework of the present disclosure, four main layers may be included: a hardware abstraction layer (HAL), an operating system abstraction layer (OSAL), a security protection layer, and an application layer.

[0059] Hardware Abstraction Layer (HAL): Shields the differences between different CPU architectures through hardware abstraction interfaces, and provides unified instruction encapsulation for architectures such as x86-64, ARM64, MIPS64EL, LoongArch64, and SW_64. Use C / C++ conditional compilation (such as #ifdef ARCH_X86_64) and dynamic library loading technology to complete hardware compatibility adaptation during compilation. At the same time, optimize memory management strategies according to the characteristics of different hardware architectures to effectively improve memory utilization. The hardware abstraction layer (HAL) encapsulates the specific implementation details of different CPU architectures and provides a unified interface so that upper-level applications do not need to care about the differences in the underlying hardware. For example, HAL_MemoryAllocate(), HAL_ThreadCreate(), etc., to ensure that each architecture can be called through these interfaces.

[0060] Operating System Abstraction Layer (OSAL): Provides a unified system call interface between different domestic operating systems (UOS, Kylin, etc.) and foreign operating systems (Windows, MacOS, Ubuntu, etc.), shielding system API differences. The OSAL layer encapsulates standardized interfaces based on system calls to ensure compatibility between different operating systems. The OS Abstraction Layer (OSAL) shields the differences between operating systems and provides a unified interface, allowing applications to run on multiple operating systems (such as Windows, MacOS, Linux and domestic operating systems such as UOS, Kylin, etc.). Through unified interface design, conditional compilation, dynamic library loading, system call encapsulation, file and network abstraction, OSAL can achieve seamless adaptation between various desktop operating systems, shield operating system differences, provide a consistent development interface for upper-layer applications, and support fast and reliable cross-platform application development. Define a set of interfaces, such as OS_FileOpen(), OS_CreateThread(), OS_AllocateMemory(), etc., to handle common operating system functions such as file operations, thread management, memory management, network communication, etc., for upper-layer applications to call, without the need to understand the implementation of specific operating systems.

[0061] Security protection layer: Built-in domestic encryption algorithm support and security interfaces such as permission verification and signature verification, adapting to domestic security standards and ensuring data encryption and transmission security. Specifically, the security protection layer can include domestic encryption algorithm modules, permission verification modules, and signature verification modules.

[0062] The domestic encryption algorithm module can be built with a domestic encryption algorithm library, supporting SM2 (public key encryption and signature), SM3 (hash algorithm) and SM4 (symmetric encryption), ensuring that the algorithm complies with the standards of the National Cryptography Administration. Use conditional compilation (such as #ifdef) and platform detection to ensure that these algorithms can be called smoothly on different architectures and operating systems. Encapsulate the domestic encryption algorithm API and provide a general interface for developers to call without having to pay attention to the underlying implementation details.

[0063] The permission verification module supports role-based access control (RBAC). User roles and corresponding access rights are defined in the permission module to ensure that users with different permissions can only access corresponding data and functions. It also supports dynamic adjustment of permissions through interfaces, and can modify and configure user permissions in real time. The permission verification API interface is encapsulated and provided for developers to call through interfaces such as CheckAccess() to simplify permission management operations.

[0064] The signature verification module uses the SM2 algorithm to implement digital signatures and verification. Developers can attach signatures to sensitive data or files, and the receiving end confirms the legitimacy of the data through the signature verification interface. The signature and verification API is encapsulated to support multi-language calls, allowing developers to directly call the signature and verification functions.

[0065] The national secret algorithm module, permission verification module, and signature verification module are encapsulated into an API to ensure that developers do not need to worry about the underlying algorithm and can directly call the API for encryption, decryption, signing, verification and other operations.

[0066] Application layer: provides a unified API interface for application developers, and has built-in support for multiple development languages ​​(such as Java, C++, Python). Developers can achieve multi-language compatibility through the interface of this layer and quickly build desktop applications.

[0067] When generating the above interfaces, you can use the interface description language (IDL) to generate a general interface, which can generate interface codes in different programming languages ​​so that each language can call the functions of the framework. This is the basic layer of the unified calling method. These general interfaces can be the core functional interfaces of the application development framework. The generated interface code will support languages ​​such as Python, Java, and C++, so that developers in different languages ​​can call the framework using the syntax they are familiar with. For example, suppose the framework has a function called doTask(). We use IDL to describe the functional interface of doTask(). The generated interface code allows Python and Java developers to call doTask() using a unified syntax in their respective environments.

[0068] At the same time, a dynamic plugin manager can also be integrated to support dynamic languages ​​(such as Python, etc.) because they cannot directly use static interfaces. This layer extends the function of IDL generating interfaces by generating plugins at runtime, especially providing support for dynamic languages. Using just-in-time compilation (JIT) technology, interface plugins are created and loaded when the framework is running. In this way, even without static compiler support, these dynamic languages ​​can load the generated plugins and directly call the framework functions like C++. For example, suppose we call the framework function in Python. When the framework starts, the plugin manager will generate a dynamic library file (such as myFrameworkLib.so), which Python can directly load through ctypes or cffi, so that Python developers can call the core functions of the framework without writing additional code.

[0069] Furthermore, lightweight WebAssembly integration, WebAssembly modules, are used to optimize multi-language support for performance-intensive tasks. This step provides cross-language support for tasks with high computational requirements, making these operations more performant when called in multiple languages. WebAssembly is a cross-language, cross-platform binary format that can improve the efficiency of computing-intensive tasks. We compile some high-performance functional modules (such as graphics processing) into WebAssembly so that they can be called in multiple languages.

[0070] Precompile some functions of the framework (such as complex computing logic) into WebAssembly modules. WebAssembly can be loaded and called by multiple languages ​​such as JavaScript and Python, thereby reducing binding development work and improving performance. Using WebAssembly modules in JavaScript, you can load the framework's .wasm file through WebAssembly.instantiate and call it directly. Similarly, in Python, you can load .wasm files through the wasmer library to complete computationally intensive tasks with native efficiency.

[0071] The application development method provided by the above-mentioned embodiment of the present disclosure can greatly reduce the adaptation workload of developers on different hardware architectures and operating systems by providing an abstraction layer and a compatibility layer. The framework provides a consistent calling method for multiple languages ​​through a unified API interface, shielding the underlying differences between the operating system and the hardware, making the development, update and maintenance of the application more convenient and efficient, and shortening the development cycle. In cross-platform migration, the application can quickly adapt to the new platform without large-scale reconstruction, greatly reducing the migration cost. Supporting multiple programming languages ​​such as Java, C++, Python, developers can directly use familiar languages ​​to call the framework API without learning new languages ​​or refactoring codes. This design effectively reduces the training and development costs of the development team, especially in the process of localization migration, avoiding the cost of code rewriting, and providing convenience for seamless porting of applications. Supporting multiple hardware architectures such as x86-64, ARM64, MIPS64EL, LoongArch64, SW_64, and compatible with domestic operating systems (such as Tongxin UOS, Galaxy Kirin) and foreign mainstream operating systems (such as Windows, MacOS, Ubuntu). In the localization migration, it can adapt to different platforms without rewriting the underlying code, which greatly reduces the cost of migration. In addition, it has built-in national encryption algorithms (such as SM2, SM3, and SM4), and is equipped with permission verification and signature verification functions. It ensures the security of data transmission and storage through a unified security API interface, which complies with national encryption standards. At the same time, it protects the integrity and security of data through permission and signature verification, which is particularly suitable for fields with high data security requirements such as government, finance, and railways to ensure the security of sensitive information. The permission verification and signature verification functions provided effectively prevent unauthorized access and injection of malicious code, enhancing the overall security and reliability of the application. In multi-user, multi-permission application scenarios, these functions ensure the security and stable operation of the system and provide strong support for the protection of sensitive data. The hardware abstraction layer of the application development framework uses conditional compilation and dynamic library loading to adapt to different architectures during compilation and runtime. And through optimized memory management strategies for different CPU architectures (such as memory pools and cache alignment), it reduces memory fragmentation, reduces resource consumption, improves operating efficiency, and meets the needs of high-performance applications. The cross-platform compatibility and multi-language support of the application development framework give it good scalability and can adapt to the needs of new hardware architectures and operating systems in the future. In the context of the continuous development of the domestic information technology ecosystem, the flexibility of the framework ensures its applicability and adaptability in the future technology environment.

[0072] Further references Figure 5 As an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of an application development device, which is similar to Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0073] like Figure 5 As shown, the application development device 500 of this embodiment includes: a determination unit 501 , an acquisition unit 502 , a compilation unit 503 and a development unit 504 .

[0074] The determination unit 501 is configured to determine the adapted target dynamic library and code execution path according to the hardware information and operating system information of the target device.

[0075] The acquisition unit 502 is configured to acquire the development code of the target application input by the developer through the target device.

[0076] The compiling unit 503 is configured to compile the development code based on the target dynamic library and the code execution path.

[0077] The development unit 504 is configured to determine the target application based on the packaging information and development code input by the developer through the target device in response to the completion of the compilation.

[0078] In addition, in the technical solution of the present application, an electronic device is also proposed.

[0079] Figure 6 A schematic structural diagram of an electronic device provided by an embodiment of the present disclosure is shown.

[0080] like Figure 6 As shown, the electronic device may include a processor 601, a memory 602, a bus 603, and a computer program stored in the memory 602 and executable on the processor 601, wherein the processor 601 and the memory 602 communicate with each other through the bus 603. The steps of the above method implemented when the processor 601 executes the computer program include, for example: determining an adapted target dynamic library and a code execution path according to hardware information and operating system information of the target device; obtaining the development code of the target application input by the developer through the target device; compiling the development code based on the target dynamic library and the code execution path; in response to the completion of the compilation, determining the target application based on the packaging information and the development code input by the developer through the target device.

[0081] In addition, in one embodiment of the present disclosure, a non-transitory computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above method are implemented, for example, including: determining an adapted target dynamic library and a code execution path based on hardware information and operating system information of the target device; obtaining the development code of the target application input by the developer through the target device; compiling the development code based on the target dynamic library and the code execution path; in response to the completion of the compilation, determining the target application based on the packaging information and the development code input by the developer through the target device.

[0082] In summary, in the technical solution disclosed in the present invention, the adapted target dynamic library and code execution path can be determined according to the hardware information and operating system information of the target device. After obtaining the development code of the target application input by the developer through the target device, the development code can be compiled based on the target dynamic library and the code execution path. After the compilation is completed, it can be packaged according to the packaging information input by the developer through the target device, thereby obtaining the target application and completing the development of the target application. Compared with the prior art, the solution disclosed in the present invention makes up for the deficiencies in architecture compatibility and platform adaptability, making the development of application programs more convenient.

[0083] The above description is only a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present disclosure shall be included in the scope of protection of the present disclosure.

Claims

1. An application development method, comprising: Determine the adapted target dynamic library and code execution path based on the hardware information and operating system information of the target device; Acquire a development code of a target application input by a developer through the target device; Compiling the development code based on the target dynamic library and the code execution path; In response to the compilation being completed, the target application is determined based on the packaging information input by the developer through the target device and the development code.

2. The method according to claim 1, wherein: Determining the adapted target dynamic library and code execution path according to the hardware information and operating system information of the target device includes: Determine a first dynamic library according to the hardware information and a preset first mapping relationship, wherein the first mapping relationship is used to represent a corresponding relationship between the hardware information and the dynamic library; Determine a second dynamic library according to the operating system information and a preset second mapping relationship, wherein the second mapping relationship is used to represent a correspondence between the operating system information and the dynamic library; Determining the target dynamic library according to the first dynamic library and the second dynamic library; The code execution path is determined according to the hardware information and the third mapping relationship.

3. The method according to claim 1, wherein: The compiling the development code based on the target dynamic library and the code execution path includes: Loading the target dynamic library; The development code is conditionally compiled according to the code execution path.

4. The method according to claim 3, wherein: The method further comprises: In response to detecting a call request for a preset function module, determining a required memory block size according to the call request; Allocate memory for the call request according to the memory block size.

5. The method according to claim 4, wherein: The allocating memory for the call request according to the memory block size includes: In response to determining that the memory block size is larger than the size of each memory block in a preset memory pool, dividing the memory block from the memory for allocation according to the memory block size; In response to determining that the memory block size is less than or equal to the size of any memory block in the preset memory pool, a memory block is selected from the memory pool for allocation.

6. The method according to claim 5, wherein: The method further comprises: Determine a cache line according to the hardware information; According to the cache line, a plurality of memory blocks are divided from the memory and stored in the memory pool.

7. The method according to claim 5, wherein: The method further comprises: In response to determining that the call request has been processed, the allocated memory block is returned to the memory pool.

8. An application development device, comprising: A determination unit is configured to determine an adapted target dynamic library and a code execution path according to hardware information and operating system information of a target device; an acquisition unit, configured to acquire a development code of a target application input by a developer through the target device; A compiling unit, configured to compile the development code based on the target dynamic library and the code execution path; The development unit is configured to determine the target application based on the packaging information input by the developer through the target device and the development code in response to the completion of the compilation.

9. An electronic device comprising a memory, a processor, a bus, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the application development method according to any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the application development method according to any one of claims 1 to 7 is implemented.

Images