CN111210496A

CN111210496A - Picture decoding method, device and equipment

Info

Publication number: CN111210496A
Application number: CN201811377772.1A
Authority: CN
Inventors: 叶轩; 卢强
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2018-11-19
Filing date: 2018-11-19
Publication date: 2020-05-29
Anticipated expiration: 2038-11-19
Also published as: CN111210496B

Abstract

The embodiment of the application discloses a picture decoding method, a picture decoding device, picture decoding equipment and a picture decoding medium. In addition, the decoding library built in the operating system has better performance and higher stability than the decoding library integrated in the rendering engine, so that the decoding speed can be effectively increased and the stability of picture decoding can be ensured by utilizing the decoding library built in the operating system to decode pictures.

Description

Picture decoding method, device and equipment

Technical Field

The present application relates to the field of picture processing technologies, and in particular, to a picture decoding method, apparatus, device, and computer storage medium.

Background

With the popularization of mobile equipment, the types of application programs suitable for mobile terminals are more and more, and currently, most application programs need to obtain pictures and perform texture mapping in the running process so as to provide immersive interactive experience for users; for example, in game applications, texture mapping of pictures is required, so as to provide more realistic game scenes for users and improve the immersive experience of users.

At present, when a game application program performs texture mapping to render game interface elements, a rendering engine in the game application program is often used to decode a picture to obtain a bitmap, and then texture mapping is performed based on the bitmap.

However, most of the rendering engines in the existing game applications on the market integrate excellent decoding libraries of multiple picture types to meet the requirements of high decoding rate of the game applications and support the requirements of decoding multiple picture types; however, the installation package of the whole application is too large, and the operation speed of the game application with the too large size is limited when the mobile terminal with limited memory runs, and sometimes even normal operation cannot be guaranteed. In addition, the decoding library integrated in the rendering engine sometimes presents compatibility problems with the mobile end model.

Therefore, there is a need to research a picture decoding scheme, which not only can reduce the weight of an application program, but also can satisfy the high-speed requirement of the application program on picture decoding, and ensure that the application program provides a smooth interactive picture for a user.

Disclosure of Invention

The embodiment of the application provides a picture decoding method, a picture decoding device and picture decoding equipment, a new picture decoding mode is provided, decoding of pictures does not need to be carried out by using a decoding library function built in an application program, and therefore the size of an application program installation package is reduced.

In view of this, a first aspect of the present application provides a picture decoding method, which is applied to a terminal, where an operating system and an application program are installed in the terminal, the application program includes an application logic module, a JS engine, a rendering engine, a picture downloading module, and a first picture decoder, and the method includes:

the application logic module generates a picture downloading and decoding instruction, and sends the picture downloading and decoding instruction to the JS engine, wherein the picture downloading and decoding instruction carries a downloading path corresponding to a target picture;

the JS engine receives the picture downloading and decoding instruction and sends the picture downloading and decoding instruction to the rendering engine;

the rendering engine receives the picture downloading and decoding instruction, calls the picture downloading module and sends the downloading path to the picture downloading module;

the picture downloading module downloads the target picture according to the downloading path, stores the target picture in a file system, and returns the storage address of the target picture in the file system to the rendering engine;

the rendering engine calls the first picture decoder and sends the storage address to the first picture decoder;

and the first picture decoder receives the storage address, acquires the target picture according to the storage address, and calls a decoding library built in an operating system to decode the target picture to obtain the bitmap.

A second aspect of the present application provides a picture decoding apparatus applied to a terminal, where an operating system is installed in the terminal, the apparatus including: the system comprises an application logic module, a JS engine, a rendering engine, a picture downloading module and a first picture decoding module; wherein the content of the first and second substances,

the application logic module is used for generating a picture downloading and decoding instruction and sending the picture downloading and decoding instruction to the JS engine, wherein the picture downloading and decoding instruction carries a downloading path corresponding to a target picture;

the JS engine is used for receiving the picture downloading and decoding instruction and sending the picture downloading and decoding instruction to the rendering engine;

the rendering engine is used for receiving the picture downloading and decoding instruction, and calling the picture downloading module to transmit the downloading path to the picture downloading module;

the picture downloading module is used for downloading the target picture according to the downloading path, storing the target picture in a file system, and returning the storage address of the target picture in the file system to the rendering engine;

the rendering engine is further configured to call the first picture decoder, and send the storage address to the first picture decoder;

and the first picture decoder is used for receiving the storage address, acquiring the target picture according to the storage address, and calling a decoding library built in an operating system to decode the target picture to obtain the bitmap.

A third aspect of the application provides an apparatus comprising a processor and a memory:

the memory is used for storing program codes and transmitting the program codes to the processor;

the processor is configured to perform the steps of the picture decoding method according to the first aspect as described above, according to instructions in the program code.

A fourth aspect of the present application provides a computer-readable storage medium for storing program code for performing the method for decoding pictures according to the first aspect.

A fifth aspect of the present application provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the picture decoding method of the first aspect described above.

According to the technical scheme, the embodiment of the application has the following advantages:

the embodiment of the application provides a picture decoding method, which is applied to a terminal provided with an operating system and an application program, wherein the application program comprises an application logic module, a JS engine, a rendering engine, a picture downloading module and a first picture decoding module; when the picture needs to be decoded, the application program logic module generates a picture downloading and decoding instruction and sends the picture downloading and decoding instruction to the JS engine, wherein the picture downloading and decoding instruction carries a downloading path corresponding to a target picture; after receiving the picture downloading and decoding instruction, the JS engine sends the picture downloading and decoding instruction to a rendering engine; after receiving the picture and the decoding instruction, the rendering engine calls a picture downloading module and sends a downloading path of the target picture to the picture downloading module; the picture downloading module downloads a target picture according to the downloading path, stores the target picture in a file system, and returns a storage address of the target picture in the file system to the rendering engine; the rendering engine calls a first picture decoder and sends the storage address of the target picture in the file system to the first picture decoder; and after receiving the storage address, the first picture decoder correspondingly acquires the target picture according to the storage address and calls a decoding library built in the operating system to decode the target picture to obtain the bitmap.

In the picture decoding method, the rendering engine in the application program calls the first picture decoder, the decoding library built in the operating system is called through the first picture decoder to decode the target picture, the picture decoding by using the decoding library integrated in the rendering engine is not needed any more, and on the basis, an additional decoding library is not needed to be integrated in the rendering engine of the application program in the process of developing the application program, so that the volume of an application program installation package is reduced. In addition, the decoding library built in the operating system has better performance and higher stability than the decoding library integrated in the rendering engine, so that the decoding speed can be effectively increased and the stability of picture decoding can be ensured by utilizing the decoding library built in the operating system to decode pictures.

Drawings

Fig. 1 is a schematic view of an application scenario of a picture decoding method according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a picture decoding method according to an embodiment of the present application;

fig. 3a is a schematic structural diagram of an internal module of a terminal according to an embodiment of the present disclosure;

fig. 3b is an interactive signaling diagram of a picture decoding method according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of a picture decoding apparatus according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of another picture decoding apparatus according to an embodiment of the present application;

fig. 6 is a schematic diagram of a hardware structure of a terminal device according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions of the present application better understood, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

In the prior art, when an application performs texture mapping and renders application interface elements, a target picture often needs to be decoded by a decoding library integrated in a rendering engine, and the decoding library integrated in the rendering engine usually occupies a large volume, which correspondingly increases the volume of an application installation package, and in some cases, the problem that the decoding library integrated in the rendering engine is difficult to be compatible with a terminal model may occur.

In order to solve the problems in the prior art, an embodiment of the present application provides a picture decoding method, which employs a new picture decoding manner, decodes a picture by using a decoding library built in an operating system, and does not need to decode the picture by using a decoding library integrated in a rendering engine, thereby reducing the volume of an application program installation package. The core technical idea of the picture decoding method provided by the embodiment of the present application is introduced first as follows:

It should be understood that the picture decoding method provided in the embodiment of the present application is generally applied to a terminal, and the terminal may be specifically a smart phone, a computer, a Personal Digital Assistant (PDA), a tablet computer, and the like.

It should be understood that the Application mentioned in the embodiment of the present Application is a software Application (APP) that needs to perform a picture decoding operation, and the Application may specifically be a social Application such as WeChat, QQ, and the like, and may also be a game Application such as Royal, wilderness, and the like, and no limitation is made to the Application specifically applying the picture decoding method.

In order to facilitate understanding of the technical solutions provided in the embodiments of the present application, the following provides a general description of the picture decoding method provided in the embodiments of the present application in combination with an application scenario.

Referring to fig. 1, fig. 1 is a schematic view of an application scenario of a picture decoding method provided in the embodiment of the present application.

As shown in fig. 1, when an application 110 running on the terminal 100 needs to display a target picture on a display interface thereof, an application logic module 111 of the application 110 correspondingly generates a picture downloading and decoding instruction, where the picture downloading and decoding instruction carries a downloading path corresponding to the target picture, and the application logic module 111 sends the picture downloading and decoding instruction generated by itself to a JS engine 112. After receiving the picture downloading and decoding instruction, the JS engine 112 sends the picture downloading and decoding instruction to the rendering engine 113. After receiving the picture downloading and decoding instruction, the rendering engine 113 calls the picture downloading module 114 to send a downloading path to the picture downloading module. The picture downloading module 114 downloads the target picture according to the downloading path, stores the target picture in the file system, and then returns the storage address of the target picture in the file system to the rendering engine 113. The rendering engine 113 further calls the first picture decoder 115, and sends the storage address of the target picture in the file system to the first picture decoder 115. Further, the first picture decoder 115 receives the storage address, obtains a target picture according to the storage address, and calls a decoding library built in the operating system 120 to decode the target picture to obtain a bitmap.

It should be noted that the application logic module 111, the JS engine 112, the rendering engine 113, the picture downloading module 114, and the first picture decoding module 115 all belong to function modules in an application program, and in a running process of the application program, each function module correspondingly executes an operation that needs to be executed by itself, so as to implement each function that needs to be implemented by the application program.

It should be noted that, when the first picture decoder 115 decodes the target picture, the decoding library built in the operating system 120 is directly called to decode the picture, and it is no longer necessary to decode the picture by using the decoding library integrated in the rendering engine, and on this basis, it is no longer necessary to integrate the decoding library in the rendering engine of the application program in the process of developing the application program, so that the volume of the application program installation package is reduced. In addition, the decoding library built in the operating system has better performance and higher stability than the decoding library integrated in the rendering engine, so that the decoding speed can be effectively increased and the stability of picture decoding can be ensured by utilizing the decoding library built in the operating system to decode pictures.

The following describes a picture decoding method provided by the present application by way of an embodiment.

Referring to fig. 2, fig. 2 is a schematic flowchart of a picture decoding method according to an embodiment of the present disclosure. It should be understood that the picture decoding method is applied to a terminal, an operating system and an application program are installed in the terminal, and when the picture decoding method is specifically executed to decode a picture, an application logic module, a JS engine, a rendering engine, a picture downloading module and a first picture decoder in the application program correspondingly execute operations which need to be executed.

As shown in fig. 2, the picture decoding method includes the following steps:

step 201: and the application logic module generates a picture downloading and decoding instruction, and sends the picture downloading and decoding instruction to the JS engine, wherein the picture downloading and decoding instruction carries a downloading path corresponding to the target picture.

In practical application, an application program responds to an operation of a user and correspondingly displays a corresponding display page for the user, and in general, the display page may further include pictures to be displayed for the user, where the pictures are target pictures. Taking the use of the WeChat as an example, the WeChat program responds to an operation initiated by the user to view the push content, and correspondingly displays a display page bearing the push content for the user, wherein the push content usually includes some related pictures, and the pictures are target pictures.

It should be understood that all pictures that need to be displayed on the display page belong to the target picture, and the target picture may be a picture inserted in the pushed content, a game element displayed in a game page in the form of a picture, or a picture published by the user on the social platform, and no limitation is made to the target picture.

When an application program needs to display a target picture, an application logic module in the application program correspondingly generates a picture downloading and decoding instruction aiming at the target picture, wherein the picture downloading and decoding instruction carries a downloading path corresponding to the target picture; and further, the application logic module sends the picture downloading and decoding instruction to a JS engine in the application program.

Generally, the picture downloading and decoding command is an image.src command, and the value of the command is a Uniform Resource Locator (URL) corresponding to the target picture, that is, an absolute path or a relative path corresponding to the target picture storage area.

It should be noted that the download path corresponding to the target picture points to the storage area corresponding to the target picture, and according to the download path corresponding to the target picture, the storage area corresponding to the target picture can be correspondingly obtained, so as to download the target picture from the storage area. It should be understood that the target picture may be a picture stored in the server, or may be a picture stored in the terminal, and a storage area corresponding to the target picture is not specifically limited herein.

It should be noted that the JS engine here is a runtime environment capable of processing and executing JavaScript codes, and when the JS engine runs, the JavaScript codes are first converted into an abstract syntax tree, and then the execution is interpreted on the abstract syntax tree.

It should be understood that the target picture may be one or more; under the condition that the application program only needs to display one target picture, the picture downloading and decoding instruction generated by the application logic module only comprises a storage path corresponding to the target picture; in the case that the application program needs to display multiple target pictures at the same time, the application logic module may generate a picture downloading and decoding instruction, where the picture downloading and decoding instruction includes a storage path corresponding to each target picture to be displayed, and of course, the application logic module may also generate a picture downloading and decoding instruction for each target picture, where each picture downloading and decoding instruction includes a storage path corresponding to one target picture.

It should be noted that, when the application program is a game application program, the application logic module is a game application logic module, and the game application logic module can generate a picture downloading and decoding instruction according to an operation of a user on a game interface.

Specifically, when detecting that a user triggers a specific game operation on a game interface, the game application logic module correspondingly determines whether the current game interface needs to be transformed according to the operation triggered by the user, and further determines how to transform the current game interface when determining that the current game interface needs to be transformed, in some cases, the game application program only needs to transform some elements on the game interface, such as character elements on the game interface or decorative elements on the game interface, at this time, the game elements needing to be transformed can be determined as target pictures, in other cases, the game application program needs to transform the whole game interface, and at this time, the whole game interface can be determined as the target pictures; and after determining the target picture according to the operation triggered by the user, the game application logic module correspondingly generates a picture downloading and decoding instruction for the target picture, and further sends the picture downloading and decoding instruction to a JS engine in the game application program.

The game application program may be an independent game application program, such as game applications of royal glory, wilderness survival, and the like; it may also be a game application integrated in another application, such as a mini-game application integrated in a WeChat.

Step 202: and the JS engine receives the picture downloading and decoding instruction and sends the picture downloading and decoding instruction to the rendering engine.

And after receiving the picture downloading and decoding instruction carrying the downloading path corresponding to the target picture, the JS engine further sends the picture downloading and decoding instruction to the rendering engine so as to correspondingly call the picture downloading module to download the target picture through the rendering engine.

Step 203: and the rendering engine receives the picture downloading and decoding instruction, calls the picture downloading module and sends a downloading path to the picture downloading module.

And after receiving the picture downloading and decoding instruction sent by the JS engine, a rendering engine in the application program calls a picture downloading module in the application program, and sends a downloading path corresponding to the target picture carried in the picture downloading and decoding instruction to the picture downloading module so as to correspondingly download the target picture according to the downloading path corresponding to the target picture by using the picture downloading module.

In a possible implementation manner, after receiving the picture downloading and decoding instruction, the rendering engine in the application program may transmit the picture downloading and decoding instruction to the Java layer in a reflection manner, so as to invoke the picture downloading module. Specifically, after receiving the downloaded picture and the decoding instruction, the rendering engine transmits the downloaded picture and the decoding instruction to the Java layer in a reflection manner, and the picture downloading module runs in the Java layer.

It should be noted that the reflection mechanism is a method provided by the Java layer for dynamically acquiring information and dynamically invoking an object, and during the operation process, all attributes and methods of any entity class can be known; for any object, any method and attribute of the object can be called; when a program corresponding to the reflection mechanism of the Java layer runs, the change of the program structure or variable type is allowed.

It should be understood that the rendering engine in the application program may also invoke the picture downloading module through other specified mechanisms, and the manner in which the rendering engine invokes the picture downloading module is not limited herein.

Step 204: and the picture downloading module downloads the target picture according to the downloading path, stores the target picture in the file system and returns the storage address of the target picture in the file system to the rendering engine.

After receiving the download path sent by the rendering engine, the picture download module correspondingly downloads the target picture according to the download path, stores the downloaded target picture in the file system, generates a storage address of the target picture in the file system after storing the target picture in the file system, and returns the storage address to the rendering engine.

It should be understood that, when the storage area pointed by the download path corresponding to the target picture is on the terminal supporting the operation of the application program, the picture download module correspondingly downloads the target picture from the corresponding storage area on the terminal according to the download path; when the storage area pointed by the download path corresponding to the target picture is on the server, the picture download module downloads the target picture from the storage area used for storing the target picture at the server end correspondingly through the network.

It should be understood that when only one target picture needs to be downloaded, the picture downloading module directly downloads the target picture from the corresponding storage area according to the downloading path corresponding to the target picture; when a plurality of target pictures need to be downloaded, the picture downloading module may download all the target pictures at one time according to the respective downloading paths of each target picture, and of course, the picture downloading module may also download each target picture one by one from the storage area corresponding to each target picture according to the respective downloading path of each target picture, where the manner of downloading the target pictures is not specifically limited.

It should be noted that, after the image downloading module downloads the obtained target image, the downloaded target image is stored in the file system of the terminal, it should be understood that, for terminals such as a smart phone and a tablet computer, the file system herein generally refers to a memory file system, and for terminals such as a computer, the file system herein generally refers to a storage device on the computer. After the target picture is stored, the file system correspondingly generates a storage address corresponding to the target picture and returns the storage address corresponding to the target picture to the rendering engine.

Step 205: and calling a first picture decoder by the rendering engine, and sending the storage address to the first picture decoder.

And after a rendering engine in the application program calls the picture downloading module to download the target picture, storing the downloaded target picture in the file system, and sending the storage address of the target picture in the file system to the rendering engine. And after the rendering engine acquires the storage address of the target picture in the file system, further calling a first picture decoder, and sending the storage address of the target picture in the file system to the first picture decoder, so that the first picture decoder acquires the target picture from the file system according to the storage address.

In a possible implementation manner, after acquiring a storage address of a target picture in a file system, the rendering engine may transmit the storage address to a Java layer in a reflection-based manner to invoke the first picture decoder. Specifically, after receiving a storage address of the target picture in the file system, the rendering engine transmits the storage address to the Java layer in a reflection manner, and the first picture decoder operates in the Java layer.

It should be understood that the rendering engine in the application program may also invoke the first picture decoder through other specified mechanisms, and the manner in which the rendering engine invokes the first picture decoder is not limited herein.

Step 206: and the first picture decoder receives the storage address, acquires a target picture according to the storage address, and calls a decoding library built in an operating system to decode the target picture to obtain a bitmap.

And after receiving the storage address sent by the rendering engine, the first picture decoder acquires the target picture from the file system according to the storage address, and further calls a decoding library built in the operating system to decode the acquired target picture to obtain a Bitmap (Bitmap) corresponding to the target picture.

In specific implementation, after receiving a storage address sent by a rendering engine, a first picture decoder calls a compressed file corresponding to a target picture from a file system according to the storage address (usually, the target picture is stored in the file system in the form of a compressed file), calls a decoding library built in an operating system, correspondingly calls a decoding function corresponding to the original format of the picture from the decoding library according to the original format corresponding to the target picture to decode the picture, and finally obtains a bitmap corresponding to the target picture.

It should be noted that currently common picture formats generally include png, jpeg, gif, svg, webp, bmp, and the like, and decoding functions included in a decoding library built in an operating system can cover various common picture formats, that is, all common picture formats currently can be decoded by using the decoding library built in the operating system.

When an application program runs in an Android system, a decoding library built in an operating system called by a first picture decoder is a decoding library Skia library built in the Android system, the Skia library is a bottom-layer image library of the Android system, is an open-source 2D vector image processing function library based on C + +, comprises functions of font processing, coordinate transformation, bitmap processing and the like, and pictures with picture formats such as png, jpeg, gif, svg, webp, bmp and the like can be decoded by using the Skia.

It should be understood that when the application program runs in other operating systems (such as an iOS system, a Windows system, etc.), the first picture decoder will call the decoding libraries built in the operating system accordingly, and at present, the decoding libraries built in each operating system can basically cover common picture formats, that is, decoding of various common picture formats can be realized by using the decoding libraries built in each operating system.

It should be noted that, in order to enable the downloaded target picture to be finally displayed on the display page of the application program, the method provided in the embodiment of the present application may further render the target picture according to the bitmap corresponding to the target picture by using a Graphics Processing Unit (GPU), so that the target picture is displayed on the display page.

When the Graphics processor performs rendering according to a bitmap corresponding to the target picture, the Graphics processor may perform image rendering processing on the bitmap based on an opengl (open Graphics library) Graphics image program development interface technology, so as to render the bitmap onto a display page for display. Of course, the graphics processor may also use other image rendering technologies to render the bitmap, and no limitation is made to the rendering technology specifically used by the graphics processor.

In a game application scenario, in order to ensure that game interface elements presented to a user are more realistic and bring more realistic game experience to the user, the game application program generally needs to perform texture mapping processing according to a bitmap corresponding to a target picture by using a graphics processor, so as to display the application interface elements on a screen of a terminal.

In a game application scene, a rendering engine can specify texture image data for a texture object according to a bitmap handle of a bitmap, and further, the texture object is transmitted to a graphic processor in a terminal; the graphics processor performs texture mapping based on the texture image data to display the application interface element on a screen of the terminal.

Specifically, the first picture decoder calls a decoding library built in an operating system to decode a target picture to obtain a bitmap corresponding to the target picture, the bitmap is stored in a native layer shared memory, a bitmap handle corresponding to pixel data corresponding to the bitmap is correspondingly generated, a rendering engine generates texture image data according to the bitmap handle corresponding to the bitmap, the texture image data is assigned to a pre-constructed texture object, the texture object is used for bearing the texture image data, and the texture object is sent to a graphics processor. Accordingly, the graphics processor, upon receiving the texture object, maps the texture image data onto the texture object accordingly, thereby displaying the game application interface element on the screen of the terminal.

Optionally, when the operating system is an Android system, the rendering engine may obtain bitmap information from a bitmap handle of a bitmap by using an Android bitmap _ getInfo function, where the bitmap information includes a width, a height, and a pixel format; furthermore, the rendering engine locks the pixel buffer of the bitmap by using an android bitmap _ lockPixels function to obtain a pointer of the pixel buffer, and specifies texture image data for the texture object according to the pointer and the bitmap information.

It should be noted that, in this implementation manner, the rendering engine locks the pixel cache corresponding to the bitmap to obtain the pointer corresponding to the pixel cache, and then the rendering engine can specify texture image data for the texture object according to the pointer and the bitmap information, so that a process of copying the pixel data corresponding to the bitmap is omitted, a memory space occupied by copying the pixel data is omitted, a memory space is saved, and a transmission speed of the pixel data is increased.

In the implementation manner, in order to ensure that pixel data corresponding to a bitmap which is not subjected to texture mapping processing is not released in a native layer, the rendering engine performs locking processing on a pixel buffer of the bitmap by using an android bitmap _ lockPixels function. Specifically, the rendering engine may call an Android system interface to block a pixel cache region corresponding to the bitmap in the native layer shared memory, so as to prevent the pixel cache from being erroneously released by the operating system before texture mapping processing is performed, and in the blocking process, a pointer corresponding to the bitmap is correspondingly generated, so as to indicate the pixel cache region corresponding to the bitmap in the native layer shared memory by using the pointer.

Optionally, after the graphics processor finishes rendering the bitmap, the rendering engine may release the locked pixel cache region through the Android system interface, that is, unlock and release the pixel cache region, thereby preventing the bitmap after texture mapping from continuously occupying a memory space of a native layer shared memory, and providing a sufficient storage space for the bitmap obtained by subsequent decoding. In an Android system, a rendering engine can unlock a pixel cache of a bitmap by using an Android bitmap _ unlockPixels function, so that a memory space corresponding to the bitmap is released.

It should be understood that when the application program runs in other operating systems, the rendering engine may also lock the pixel cache region of the bitmap in the native layer shared memory by using the locking function supported by the operating system, and unlock the pixel cache region of the bitmap in the native layer shared memory by using the unlocking function supported by the operating system after the rendering is completed, where the locking function and the unlocking function called by the rendering engine are not specifically limited.

It should be noted that, in some cases, a target picture that a rendering engine needs to decode may have some potential safety hazards, and a decoding library built in an operating system is directly utilized to decode such a target picture, which may bring a safety problem to a conference operating system.

Specifically, after the application program returns a storage address of a target in a file system to the rendering engine and before the rendering engine calls a first picture for decoding, the rendering engine firstly judges whether the target picture belongs to a white list, and picture types corresponding to pictures with potential safety hazards are stored in the white list; if the target picture belongs to the white list, the rendering engine calls a second picture decoder in the application program and sends the storage address of the target picture in the file system to the second picture decoder; correspondingly, after receiving the storage address, the second picture decoder acquires a target picture from the file system according to the storage address, calls a built-in decoding library of the second picture decoder, and decodes the target picture to obtain a bitmap; if the target picture does not belong to the white list, the above steps 205 to 206 are executed, that is, the rendering engine calls the first picture decoder, sends the storage address to the first picture decoder, and after receiving the storage address, the first picture decoder obtains the target picture stored in the file system according to the storage address, and calls a decoding library built in the operating system to decode the target picture to obtain the bitmap.

During specific implementation, an application program can preset a white list, and correspondingly store picture types corresponding to pictures possibly with potential safety hazards into the white list; after the rendering engine receives the storage address of the target picture in the file system, which is sent by the picture downloading module, the rendering engine firstly judges whether the picture type corresponding to the target picture belongs to the picture type stored in the white list; if the picture type corresponding to the target picture belongs to the white list, the target picture is indicated to have potential safety hazard and cannot be decoded by directly using a decoding library built in an operating system, so as to avoid safety problems brought to the operating system, a rendering engine correspondingly calls a second picture decoder, the storage address of the target picture in the file system is sent to the second picture decoder, the second picture decoder correspondingly calls a decoding library built in an application program, and the target picture is correspondingly decoded by using a decoding function in the decoding library; on the contrary, if the picture type corresponding to the target picture does not belong to the white list, it is indicated that the target picture does not have the potential safety hazard, the rendering engine may correspondingly call a first picture decoder, send the storage address of the target picture in the file system to the first picture decoder, and the first picture decoder calls a decoding library built in the system to decode the target picture.

It should be understood that the above-mentioned second picture decoder and the first picture decoder employ different decoding logics, the second picture decoder calls a decoding library built in the application program for decoding, and the first picture decoder calls a decoding library built in the operating system for decoding.

It should be noted that, in the process of developing the application, only the corresponding decoding library needs to be set for the picture type that may have the potential safety hazard, and the decoding library function is built in the application installation package, because the decoding library is only used for decoding the picture that may have the potential safety hazard, the volume of the decoding library is far smaller than the volume of the decoding library integrated in the application installation package in the prior art, that is, even if the decoding library is built in the application installation package, the volume of the application installation package is not greatly affected, that is, the volume of the application installation package is not made too large.

In order to further understand the picture decoding method provided in the embodiment of the present application, a specific description is made below with reference to the drawings on an internal module structure of the terminal for executing the picture decoding method, and the picture decoding method provided in the embodiment of the present application is generally described with reference to the internal module structure of the terminal by taking an application program as an example of a game application program.

Referring to fig. 3a, fig. 3a is a schematic structural diagram of an internal module of a terminal according to an embodiment of the present application.

As shown in fig. 3a, the terminal has installed therein an operating system 3100, application programs 3200, and a graphic processor 3300; the operating system 3100 is provided with a decoding library 3110 for decoding pictures; the application 3200 is a software application that needs to perform a picture decoding operation, and in this embodiment, the application 3200 is taken as a game application as an example, and a module structure thereof is specifically described; the graphics processor 3300 is configured to perform texture mapping processing based on the decoded bitmap.

The game application 3200 includes a game application logic module 3210, a JS engine 3220, a rendering engine 3230, a picture downloading module 3240, a first picture decoder 3250, a second picture decoder 3260, and a decoding library 3270 built in the game application logic module, the JS engine 3220, and the second picture decoder 3260. The game application logic module 3210 communicates with the JS engine 3220, and sends a picture downloading and decoding instruction to the JS engine 3220; the JS engine 3220 is in communication with the rendering engine 3230, and sends the picture downloading and decoding instruction received by itself to the rendering engine 3230; the rendering engine 3230 and the picture downloading module 3240 are communicated with each other, the rendering engine 3230 sends a downloading path carried in a picture downloading and decoding instruction to the picture downloading module 3240, and the picture downloading module 3240 sends a storage address of a target file obtained by downloading the target file to the rendering engine 3230 in a file system; the rendering engine 3230 is in communication with the first picture decoder 3250, and when determining that the target picture does not belong to the white list, sends the storage address received by itself to the first picture decoder 3250; the first picture decoder 3250 is associated with a decoding bank 3110 built into the operating system 3100, which can decode the target picture with the decoding bank 3110; the rendering engine is also communicated with a second picture decoder 3260, and when the target picture is judged to belong to the white list, the storage address received by the rendering engine is sent to the second picture decoder 3260; the second picture decoder 3260 is associated with a decoding library 3270 built in the application, which may call the decoding library 3270 to decode the target picture.

The following provides a general description of a flow of executing the picture decoding method provided by the embodiment of the present application by each module in the application shown in fig. 3a, based on the internal module structure of the terminal shown in fig. 3 a.

Referring to fig. 3b, fig. 3b is an interactive signaling diagram of a picture decoding method according to an embodiment of the present application. As shown in fig. 3b, the method comprises:

the first step is as follows: the game application logic module 3210 generates a picture downloading and decoding instruction according to the operation of the user on the game interface.

The game application logic module 3210 detects an operation of a user on a game interface in real time, and when it is detected that a certain operation performed by the user can trigger a change of a game element or a game overall interface on the game interface, the game application logic module 3210 correspondingly determines that the game element or the game overall interface that needs to be changed is a target picture, and generates a picture downloading and decoding instruction for the target picture, where the picture downloading and decoding instruction includes a downloading path of the target picture.

The second step is that: the game application logic module 3210 sends the picture download and decode instruction to the JS engine 3220.

The third step: after receiving the picture downloading and decoding instruction, the JS engine 3220 sends the picture downloading and decoding instruction to the rendering engine 3230.

The fourth step: the rendering engine 3230 calls the picture downloading module 3240, and sends a downloading path in the picture downloading and decoding instruction to the picture downloading module 3240.

The fifth step: the picture downloading module 3240 downloads the target picture according to the downloading path, stores the target picture in the file system, and accordingly obtains a storage address of the target picture in the file system.

And a sixth step: the picture download module 3240 returns the storage address of the target picture in the file system to the rendering engine 3230.

The seventh step: the rendering engine 3230 determines whether the target picture belongs to the white list, and if the target picture does not belong to the white list, then step 308 and step 309 are performed in sequence, and if the target picture belongs to the white list, then step 310 and step 311 are performed in sequence.

Eighth step: the rendering engine 3230 calls the first picture decoder 3250, and transmits a storage address of the target picture in the file system to the first picture decoder 3250.

The ninth step: the first picture decoder 3250 acquires a target picture from the storage address, calls a decoding library 3110 built in the operating system 3100, and decodes the target picture to obtain a bitmap.

The tenth step: the rendering engine 3230 calls the second picture decoder 3260, and transmits a storage address of the target picture in the file system to the second picture decoder 3260.

The eleventh step: the second picture decoder 3260 obtains the target picture according to the storage address, and calls a decoding library 3270 built in the application 3200 to decode the target picture to obtain the bitmap.

The twelfth step: the rendering engine 3230 specifies texture image data for the texture object according to the bitmap handle of the bitmap decoded in step 309 or step 311 described above, and passes the texture object to the graphics processor 3300 in the terminal, so that the graphics processor 3300 performs texture mapping based on the texture image data to display the target picture on the screen of the terminal.

The rendering engine 3230 may employ an android bitmap _ getInfo function to obtain bitmap information from a bitmap handle of a bitmap, the bitmap information including width, height, and pixel format; the android bitmap _ lockPixels function can be adopted to lock the pixel buffer of the bitmap to obtain the pointer of the pixel buffer, and texture image data is assigned to the texture object according to the pointer and the bitmap information.

For the above-described picture decoding method, the present application also provides a corresponding picture decoding apparatus, so that the above-described picture decoding method is applied and implemented in practice.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a picture decoding apparatus 400 corresponding to the picture decoding method shown in fig. 2, where the picture decoding apparatus 400 includes:

the application logic module 401 is configured to generate a picture downloading and decoding instruction, and send the picture downloading and decoding instruction to the JS engine, where the picture downloading and decoding instruction carries a downloading path corresponding to a target picture;

the JS engine 402 is used for receiving the picture downloading and decoding instruction and sending the picture downloading and decoding instruction to the rendering engine;

the rendering engine 403 is configured to receive the picture downloading and decoding instruction, and call the picture downloading module to transfer the downloading path to the picture downloading module;

a picture downloading module 404, configured to download the target picture according to the download path, store the target picture in a file system, and return a storage address of the target picture in the file system to the rendering engine;

the rendering engine 403 is further configured to invoke the first picture decoder, and send the storage address to the first picture decoder;

and the first picture decoder 405 is configured to receive the storage address, obtain the target picture according to the storage address, and call a decoding library built in an operating system to decode the target picture to obtain a bitmap.

Optionally, on the basis of the picture decoding apparatus shown in fig. 4, referring to fig. 5, fig. 5 is a schematic structural diagram of another picture decoding apparatus 500 provided in the embodiment of the present application, and the apparatus further includes a second picture decoder 501.

After the picture download module 404 returns the storage address of the target picture in the file system to the rendering engine 403, and before the rendering engine 403 calls the first picture decoder 405, the rendering engine 403 is further configured to: judging whether the target picture belongs to a white list, wherein picture types corresponding to pictures with potential safety hazards are stored in the white list;

if yes, the rendering engine 403 is further configured to call a second picture decoder 501 in the application program, and send the storage address to the second picture decoder 501; the second picture decoder 501 is configured to receive the storage address, and obtain the target picture according to the storage address; the second picture decoder 501 is further configured to call a built-in decoding library thereof, and decode the target picture to obtain a bitmap;

if not, the rendering engine 403 executes the operation of calling the first picture decoder 405 and sending the storage address to the first picture decoder 405; and the first picture decoder 405 executes the operation of receiving the storage address, obtaining the target picture according to the storage address, and calling a decoding library function built in an operating system to decode the target picture to obtain a bitmap.

Optionally, on the basis of the picture decoding apparatus shown in fig. 4, the rendering engine 403 is further configured to assign texture image data to a texture object according to the bitmap handle of the bitmap, and transfer the texture object to a graphics processor in the terminal, so that the graphics processor performs texture mapping based on the texture image data, so as to display an application interface element on a screen of the terminal.

Optionally, on the basis of the picture decoding apparatus shown in fig. 4, when the rendering engine 403 specifies texture image data for a texture object according to the bitmap handle of the bitmap, the rendering engine is specifically configured to:

acquiring bitmap information from a bitmap handle of the bitmap by adopting an android bitmap _ getInfo function, wherein the bitmap information comprises width, height and pixel format;

and locking the pixel cache of the bitmap by adopting an android bitmap _ lockPixels function to obtain a pointer of the pixel cache, and assigning texture image data for a texture object according to the pointer and the bitmap information.

Optionally, on the basis of the picture decoding apparatus shown in fig. 4, the application program is a game application program, and the application logic module 401 is a game application logic module;

and the game application logic module is used for generating the picture downloading and decoding instruction according to the operation of a user on a game interface.

The embodiment of the present application further provides a device for decoding a picture, where the device is specifically a terminal device, as shown in fig. 6, for convenience of description, only a portion related to the embodiment of the present application is shown, and details of the specific technology are not disclosed, please refer to the method portion of the embodiment of the present application. The terminal may be any terminal device including a mobile phone, a tablet computer, a Personal Digital Assistant (PDA), a Point of Sales (POS), a vehicle-mounted computer, and the like, taking the terminal as the mobile phone as an example:

fig. 6 is a block diagram illustrating a partial structure of a mobile phone related to a terminal provided in an embodiment of the present application. Referring to fig. 6, the handset includes: radio Frequency (RF) circuitry 610, memory 620, input unit 630, display unit 640, sensor 650, audio circuitry 660, wireless fidelity (WiFi) module 670, processor 680 (including a graphics processor), and power supply 690. Those skilled in the art will appreciate that the handset configuration shown in fig. 6 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

The following describes each component of the mobile phone in detail with reference to fig. 6:

the RF circuit 610 may be used for receiving and transmitting signals during information transmission and reception or during a call, and in particular, receives downlink information of a base station and then processes the received downlink information to the processor 680; in addition, the data for designing uplink is transmitted to the base station. In general, the RF circuit 610 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, the RF circuitry 610 may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to global system for Mobile communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), and the like.

The memory 620 may be used to store software programs and modules, and the processor 680 may execute various functional applications and data processing of the mobile phone by operating the software programs and modules stored in the memory 620. The memory 620 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 620 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The input unit 630 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the cellular phone. Specifically, the input unit 630 may include a touch panel 631 and other input devices 632. The touch panel 631, also referred to as a touch screen, may collect touch operations of a user (e.g., operations of the user on the touch panel 631 or near the touch panel 631 by using any suitable object or accessory such as a finger or a stylus) thereon or nearby, and drive the corresponding connection device according to a preset program. Alternatively, the touch panel 631 may include two parts of a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 680, and can receive and execute commands sent by the processor 680. In addition, the touch panel 631 may be implemented using various types, such as resistive, capacitive, infrared, and surface acoustic wave. The input unit 630 may include other input devices 632 in addition to the touch panel 631. In particular, other input devices 632 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

The display unit 640 may be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 640 may include a display panel 641, and optionally, the display panel 641 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch panel 631 can cover the display panel 641, and when the touch panel 631 detects a touch operation thereon or nearby, the touch panel is transmitted to the processor 680 to determine the type of the touch event, and then the processor 680 provides a corresponding visual output on the display panel 641 according to the type of the touch event. Although in fig. 6, the touch panel 631 and the display panel 641 are two independent components to implement the input and output functions of the mobile phone, in some embodiments, the touch panel 631 and the display panel 641 may be integrated to implement the input and output functions of the mobile phone.

The handset may also include at least one sensor 650, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that adjusts the brightness of the display panel 641 according to the brightness of ambient light, and a proximity sensor that turns off the display panel 641 and/or the backlight when the mobile phone is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally, three axes), can detect the magnitude and direction of gravity when stationary, and can be used for applications of recognizing the posture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile phone, further description is omitted here.

Audio circuit 660, speaker 661, and microphone 662 can provide an audio interface between a user and a cell phone. The audio circuit 660 may transmit the electrical signal converted from the received audio data to the speaker 661, and convert the electrical signal into an audio signal through the speaker 661 for output; on the other hand, the microphone 662 converts the collected sound signals into electrical signals, which are received by the audio circuit 660 and converted into audio data, which are processed by the audio data output processor 680 and then transmitted via the RF circuit 610 to, for example, another cellular phone, or output to the memory 620 for further processing.

WiFi belongs to short-distance wireless transmission technology, and the mobile phone can help a user to receive and send e-mails, browse webpages, access streaming media and the like through the WiFi module 670, and provides wireless broadband Internet access for the user. Although fig. 6 shows the WiFi module 670, it is understood that it does not belong to the essential constitution of the handset, and can be omitted entirely as needed within the scope not changing the essence of the invention.

The processor 680 is a control center of the mobile phone, and includes a graphic processor, which is connected to various parts of the entire mobile phone by using various interfaces and lines, and executes various functions of the mobile phone and processes data by operating or executing software programs and/or modules stored in the memory 620 and calling data stored in the memory 620, thereby monitoring the mobile phone as a whole. Optionally, processor 680 may include one or more processing units; preferably, the processor 680 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 680.

The handset also includes a power supply 690 (e.g., a battery) for powering the various components, which may preferably be logically connected to the processor 680 via a power management system, such that the power management system may be used to manage charging, discharging, and power consumption.

Although not shown, the mobile phone may further include a camera, a bluetooth module, etc., which are not described herein.

In this embodiment, an application program runs in the processor 680 included in the terminal, and each module in the application program has the following functions:

Optionally, the processor 680 may further perform the method steps of any specific implementation manner of the picture decoding method in the embodiment of the present application.

The embodiment of the present application further provides a computer-readable storage medium for storing a program code, where the program code is configured to execute any one implementation of the picture decoding method described in the foregoing embodiments.

The present application further provides a computer program product including instructions, which when run on a computer, causes the computer to execute any one of the implementation manners of the picture decoding method described in the foregoing embodiments.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. The picture decoding method is applied to a terminal, an operating system and an application program are installed in the terminal, the application program comprises an application logic module, a JS engine, a rendering engine, a picture downloading module and a first picture decoder, and the method comprises the following steps:

2. The method of claim 1, wherein after the returning the storage address of the target picture in the file system to the rendering engine and before the rendering engine calls the first picture decoder, the method further comprises:

the rendering engine judges whether the target picture belongs to a white list, and the white list stores picture types corresponding to pictures with potential safety hazards;

if so, the rendering engine calls a second picture decoder in the application program and sends the storage address to the second picture decoder; the second picture decoder receives the storage address and acquires the target picture according to the storage address; the second picture decoder calls a built-in decoding library to decode the target picture to obtain a bitmap;

if not, the step is executed again: the rendering engine calls the first picture decoder and sends the storage address to the first picture decoder; and the first picture decoder receives the storage address, acquires the target picture according to the storage address, and calls a decoding library built in an operating system to decode the target picture to obtain the bitmap.

3. The method of claim 1, further comprising:

the rendering engine appoints texture image data for a texture object according to the bitmap handle of the bitmap and transmits the texture object to a graphic processor in the terminal;

the graphics processor performs texture mapping based on the texture image data to display application interface elements on a screen of the terminal.

4. The method according to claim 3, wherein the operating system is the Android system;

the rendering engine assigning texture image data to the texture object according to the bitmap handle of the bitmap, comprising:

the rendering engine obtains bitmap information from a bitmap handle of the bitmap by adopting an android bitmap _ getInfo function, wherein the bitmap information comprises width, height and pixel format;

and the rendering engine locks the pixel cache of the bitmap by adopting an android bitmap _ lockPixels function to obtain a pointer of the pixel cache, and appoints texture image data for the texture object according to the pointer and the bitmap information.

5. The method of any one of claims 1 to 3, wherein the application is a game application and the application logic module is a game application logic module, the method further comprising:

and the game application logic module generates the picture downloading and decoding instruction according to the operation of a user on a game interface.

6. A picture decoding apparatus applied to a terminal having an operating system installed therein, the apparatus comprising: the system comprises an application logic module, a JS engine, a rendering engine, a picture downloading module and a first picture decoding module; wherein the content of the first and second substances,

7. The apparatus of claim 6, wherein the apparatus further comprises a second picture decoder;

after the picture download module returns the storage address of the target picture in the file system to the rendering engine and before the rendering engine calls the first picture decoder, the rendering engine is further configured to: judging whether the target picture belongs to a white list, wherein picture types corresponding to pictures with potential safety hazards are stored in the white list;

if so, the rendering engine is further configured to call a second picture decoder in the application program, and send the storage address to the second picture decoder; the second picture decoder is used for receiving the storage address and acquiring the target picture according to the storage address; the second picture decoder is also used for calling a built-in decoding library thereof and decoding the target picture to obtain a bitmap;

if not, the rendering engine executes the operation of calling the first picture decoder and sending the storage address to the first picture decoder; and the first picture decoder executes the operation of receiving the storage address, acquiring the target picture according to the storage address, and calling a decoding library function built in an operating system to decode the target picture to obtain a bitmap.

8. The apparatus of claim 6, further comprising:

the rendering engine is further configured to assign texture image data to a texture object according to the bitmap handle of the bitmap, and transfer the texture object to a graphics processor in the terminal, so that the graphics processor performs texture mapping based on the texture image data to display an application interface element on a screen of the terminal.

9. An apparatus, comprising a processor and a memory:

the memory is used for storing an application program code module and an operating system, wherein the application program code module comprises an application logic module, a JS engine, a rendering engine, a picture downloading module and a first picture decoding module;

the processor is configured to run the application code module to instruct the picture decoding method according to any one of claims 1 to 5 to be performed.

10. A computer-readable storage medium for storing program code for executing the picture decoding method according to any one of claims 1 to 5.

11. A computer program product comprising instructions which, when run on a computer, cause the computer to perform the picture decoding method of any one of claims 1 to 5.