CN116450057A

CN116450057A - Vehicle function picture generation method and device based on client and storage medium

Info

Publication number: CN116450057A
Application number: CN202310720452.6A
Authority: CN
Inventors: 陈裕聪; 唐如意; 叶松林
Original assignee: Chengdu Seres Technology Co Ltd
Current assignee: Chongqing Selis Phoenix Intelligent Innovation Technology Co ltd
Priority date: 2023-06-19
Filing date: 2023-06-19
Publication date: 2023-07-18
Anticipated expiration: 2043-06-19
Also published as: CN116450057B

Abstract

The application provides a vehicle function picture generation method and device based on a client and a storage medium. The method comprises the following steps: acquiring an original design picture of a vehicle function, disassembling the original design picture into drawing elements, and determining drawing information of each drawing element in a reference coordinate system; processing drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule; the picture rule data are issued to the client so that the client analyzes the picture rule data and coordinate transformation is carried out on drawing information of each drawing element in the picture rule data; and based on the drawing information after coordinate conversion, calling corresponding function functions to draw the drawing elements in sequence by utilizing the element drawing sequence defined in the picture rule data so as to generate a vehicle function picture corresponding to the original design picture. The method and the device can save the performance cost of the system, improve the picture generation efficiency, draw according to the requirement and improve the flexibility of picture drawing.

Description

Vehicle function picture generation method and device based on client and storage medium

Technical Field

The present disclosure relates to the field of application program development technologies, and in particular, to a method and an apparatus for generating a vehicle function picture based on a client, and a storage medium.

Background

In the development of automotive apps, there is a need for remote vehicle control, which control functions need to be implemented by operating icon buttons conforming to various states, such as: locks, trunk, front hatch, etc. However, for each function button, since there are different states (e.g., closed, opened, neutral, and unavailable), color variant pictures corresponding to a plurality of states need to be generated and stored in advance, which places a large burden on both storage space and bandwidth.

Firstly, if the client pre-stores all the function pictures in possible states, on one hand, the waste of storage space is caused, because not all the users can use all the functions, and all the states are not necessarily met; on the other hand, the client needs to reissue each time a new function or state is added, increasing the complexity of maintenance, since new functions and states that may be added in the future are unpredictable. Secondly, if the latest function picture is selected to be downloaded through the server interface, a large number of pictures need to be downloaded because each function at least corresponds to a plurality of states, thereby occupying a large amount of network bandwidth. If the on-demand downloading strategy is implemented to reduce bandwidth pressure, waiting may occur when the picture is needed, and if the network condition is not good, the picture downloading failure or slow downloading speed may be caused, so that the user experience is seriously affected. Therefore, the existing vehicle function picture generation method has the problems that the storage space is low in utilization efficiency, the memory occupation is large, the system performance overhead is wasted, the drawing can not be performed as required, and the flexibility of image drawing is reduced.

Disclosure of Invention

In view of this, the embodiments of the present application provide a method, an apparatus, and a storage medium for generating a vehicle function image based on a client, so as to solve the problems in the prior art that the storage space is inefficient, the memory occupation is large, the system performance overhead is wasted, the image cannot be drawn as required, and the flexibility of image drawing is reduced.

In a first aspect of an embodiment of the present application, a method for generating a vehicle function picture based on a client is provided, including: acquiring an original design picture of a vehicle function, disassembling the original design picture into drawing elements, and determining drawing information of each drawing element in a reference coordinate system; processing drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule to obtain picture rule data corresponding to each original design picture; the picture rule data are issued to the client so that the client analyzes the picture rule data and coordinate transformation is carried out on drawing information of each drawing element in the picture rule data; and based on the drawing information after coordinate conversion, calling corresponding function functions to draw the drawing elements in sequence by utilizing the element drawing sequence defined in the picture rule data so as to generate a vehicle function picture corresponding to the original design picture.

In a second aspect of the embodiments of the present application, there is provided a vehicle function picture generating device based on a client, including: the disassembly module is configured to acquire an original design picture of the vehicle function, disassemble the original design picture into drawing elements and determine drawing information of each drawing element in a reference coordinate system; the processing module is configured to process drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule to obtain picture rule data corresponding to each original design picture; the analysis module is configured to issue the picture rule data to the client so that the client analyzes the picture rule data and performs coordinate conversion on the drawing information of each drawing element in the picture rule data; the drawing module is configured to call corresponding function functions to draw the drawing elements in sequence by utilizing element drawing sequences defined in the picture rule data based on the drawing information after coordinate conversion so as to generate a vehicle function picture corresponding to the original design picture.

In a third aspect of the embodiments of the present application, there is provided an electronic device including a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the above method when executing the program.

In a fourth aspect of the embodiments of the present application, there is provided a computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of the above method.

The above-mentioned at least one technical scheme that this application embodiment adopted can reach following beneficial effect:

the method comprises the steps of disassembling an original design picture of a vehicle function into drawing elements by acquiring the original design picture, and determining drawing information of each drawing element in a reference coordinate system; processing drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule to obtain picture rule data corresponding to each original design picture; the picture rule data are issued to the client so that the client analyzes the picture rule data and coordinate transformation is carried out on drawing information of each drawing element in the picture rule data; and based on the drawing information after coordinate conversion, calling corresponding function functions to draw the drawing elements in sequence by utilizing the element drawing sequence defined in the picture rule data so as to generate a vehicle function picture corresponding to the original design picture. The method and the device can directly draw and generate the picture according to the required actual picture size, can save the bandwidth of a user, reduce the memory occupation, thereby saving the performance cost of a system, improving the generation efficiency of the vehicle function picture, drawing the picture according to the requirement, and improving the drawing flexibility of the picture.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following description will briefly introduce the drawings that are needed in the embodiments or the description of the prior art, it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic flow chart of a method for generating a vehicle function picture based on a client according to an embodiment of the present application;

FIG. 2 is an original design of a battery icon in an actual scenario for an embodiment of the present application;

fig. 3 is a schematic structural diagram of picture rule data in an actual scene according to an embodiment of the present application;

fig. 4 is a schematic diagram of coordinate transformation of picture rule data in the first case according to the embodiment of the present application;

fig. 5 is a schematic diagram of coordinate transformation of picture rule data in the second case according to the embodiment of the present application;

fig. 6 is a schematic structural diagram of a client-based vehicle function picture generating device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

In current automotive application (App) development, it is often desirable to provide remote control functions for a vehicle, including but not limited to: the vehicle lock, the trunk, the front hatch cover, the vehicle window, the vehicle searching, the charging port, the ventilation of the vehicle window, the skylight, the ventilation of the skylight, the sunshade curtain, the air conditioner, the battery and the like. In the application program, each vehicle control function needs corresponding operation buttons for users to operate, and the buttons are usually provided with corresponding image identifications. Moreover, these image identifications are not complex graphics, and their shapes and colors have simplicity and can be broken down into basic drawing functions that common iOS systems can provide, such as drawing lines, arcs, shapes, colors, shadows, transparency, text, etc.

For each car control function, corresponding operation buttons are required to be provided on the App for the user to operate, and corresponding pictures are arranged on the buttons; also, since the implementation of remote control requires a certain time course, each button may have various states, such as: closed (black), open (gold), in progress (gradient color), and unavailable (gray). This means that each vehicle control function may have images of various color variations to represent different states. Such as: the user clicks a trunk button on the App to open the trunk, but from the point when the user clicks the trunk to the point when the trunk is actually opened, a certain time difference exists in the middle, because a command is sent from the client to the server through the port, the server communicates with the central control TBox of the automobile, and the TBox operates the automobile again to complete an actual instruction. In addition, in order to represent different states of the vehicle functions, the operation buttons of the vehicle control functions also generally change color with the change of the states, and when the vehicle needs to be supplemented with a new function, such as a steering wheel heating function, it is necessary to regenerate a picture of the steering wheel and generate variant images corresponding to n colors.

In the prior art, the current common vehicle control function picture generation method mainly comprises the following two steps:

the first implementation scheme is as follows: the client pre-stores pictures of some functions, but if functions possibly added in future are not added, the functions are unknown in the process of publishing, and if the pictures corresponding to the functions are not pre-stored in the client, the client needs to resend the version. Or a state needs to be added at the later stage of the existing function, a color variant diagram is added to the original picture, and the original picture needs to be reissued. Moreover, the mode of pre-storing pictures can cause the waste of storage space, because a user can not necessarily enter a page corresponding to a certain car control function, and then a certain set of stored pictures is practically useless. And when a certain car control function is not used any more, the pictures also exist in the installation package, so that the waste of storage space is caused.

The second implementation scheme is as follows: the latest function pictures are downloaded through the server interface, and when the functions are many, a large number of pictures (at least n pictures are needed for one function) need to be downloaded, so that the scheme occupies bandwidth. If the downloading is carried out according to the requirement, the bandwidth can be reduced, but certain waiting can be carried out when the picture is really needed, and if the network is not good, the picture is not reached or is slow to be reached, so that the user experience is affected. In addition, since iOS devices are of a wide variety and new models are introduced each year, the size of the picture provided by the server cannot be fully adapted to all screens. Before display, the pictures need to be subjected to operations such as zooming, cutting, stretching and the like, and the operations may cause the reduction of the display effect of the pictures.

In summary, the existing technical scheme has the technical problems of low utilization of storage space, large bandwidth and memory occupation, waste of system performance overhead, difficulty in adding new functions, incapability of drawing on demand, low flexibility of image drawing, equipment adaptation and the like, and needs to find new solutions for improvement.

In view of this, the embodiment of the application provides a vehicle function picture generation method based on a client. According to the method, the original design picture of the vehicle function is obtained and disassembled into the drawing elements, and drawing information of each drawing element in a reference coordinate system is determined. And processing drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule, and storing the picture rule data in a server. And the picture rule data are issued to the client, the client performs coordinate conversion on the drawing information of each drawing element in the original design picture according to the data, and the drawing is sequentially performed according to the element drawing sequence, so that the vehicle function picture corresponding to the original design picture is generated. After the vehicle function picture corresponding to the original design picture is generated, the rendering mode of the vehicle function picture can be changed through setting parameters, so that a template picture is obtained, and variant pictures with different colors can be generated according to requirements. Storing the generated vehicle function pictures and variant pictures into a memory, when the pictures are required to be called, requesting a server to acquire picture rule data, comparing the picture rule data with picture rule data stored by a client, judging, and if the picture rule data of the vehicle function pictures or the variant pictures are not updated, continuing to use the picture rule data stored by the client; if the updating occurs, the relevant pictures in the memory are cleaned, and the vehicle function pictures are redrawn according to the new picture rule data.

According to the vehicle function picture generation method based on the client, the graphics drawing codes and the rule data are utilized, the requirement on the bandwidth of the server is reduced, the efficiency and the performance of the system are improved, the user experience is improved, and meanwhile, various devices and screen sizes are well adapted. In addition, the technical scheme also makes adding new vehicle functions or updating the state of the existing functions more convenient, and version reissuing is not needed, so that the maintenance efficiency and user experience of the application program are greatly improved.

The following describes the technical scheme of the present application in detail with reference to the accompanying drawings and specific embodiments.

Fig. 1 is a flowchart of a method for generating a vehicle function picture based on a client according to an embodiment of the present application. The client-based vehicle function picture generation method of fig. 1 may be performed by a system composed of a client and a server. As shown in fig. 1, the method for generating a vehicle function picture based on a client specifically includes:

s101, acquiring an original design picture of a vehicle function, disassembling the original design picture into drawing elements, and determining drawing information of each drawing element in a reference coordinate system;

s102, processing drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule to obtain picture rule data corresponding to each original design picture;

S103, the picture rule data are issued to the client so that the client analyzes the picture rule data and performs coordinate conversion on drawing information of each drawing element in the picture rule data;

and S104, based on the drawing information after coordinate conversion, calling corresponding function functions to draw the drawing elements in sequence by utilizing the element drawing sequence defined in the picture rule data so as to generate a vehicle function picture corresponding to the original design picture.

First, an original design picture designed by an art designer according to a vehicle function is disassembled into elements which can be drawn by a machine by using a tool or a manual mode, for example: straight lines, points, shapes, curves, text, line colors, fill colors, gradient colors, shadows, etc. These elements are collectively referred to as "drawing elements" in the following embodiments of the present application, wherein a single element may also be referred to generally as an "element". In one example, as shown in fig. 2, fig. 2 is an original design drawing of a battery icon in an actual scene according to an embodiment of the present application, in an actual application, the original design drawing of the vehicle charging function shown in fig. 2 (such as the battery icon) may be disassembled into the following drawing elements: a short gray line (representing the battery positive electrode), a gray curve (representing the battery border), and a colored rectangular block (representing the power). It should be noted that fig. 2 uses black rectangular blocks to represent the electric quantity, and of course, other colors may be used to represent the electric quantity, such as green. The types, lengths, widths, colors, shadows, etc. of the lines in the original design picture can be designed according to actual requirements, and the embodiment of the application is not limited.

In the embodiment of the application, the drawing coordinate system commonly used by the client is used as a reference coordinate system, so that the minimum information required by all drawing elements of each original design picture is obtained. The common drawing coordinate system of Android and iOS clients takes the upper left corner of the control as the origin, x extends rightward as a positive number in the horizontal direction, and y extends downward as a positive number in the vertical direction (i.e. takes the upper left corner of the control as the origin, and the x axis is rightward and the y axis is downward).

Here, the drawing information of each drawing element in the reference coordinate system represents minimum information required to draw one element. For example, taking a battery icon corresponding to a vehicle charging function as an example, the generation of this icon may require the following drawing information:

gray straight line: coordinates of the start point and the end point, and line width are required.

Gray curve: the coordinates of the points at the four corners of the rectangle are required, as well as the radius of the rounded corners of the rectangle, and also the line width.

Green rectangular block: coordinates of points at four corners of a rectangle are required.

Grey: color values are required, such as RGBA or HSB, etc.

Green gradual change block: a gradation start color value, a gradation end color value, a start point and an end point of rendering, a point position of a gradation start and a point position of a gradation end color, and a manner of gradation (whether linear gradation or center gradation, etc.) are required.

The width and height of the picture itself.

Therefore, the battery icon requires more than 6 drawing elements in total, and the origin of the coordinate system of the drawing elements should be the upper left corner of the original design picture given by the art designer, so as to determine the coordinate point of each element. The embodiment of the application provides data for generating the icon by disassembling the original design drawing into drawing elements and recording the positions of the elements in the reference coordinate system and other relevant information. The method can reduce the use of storage space, avoids the need of updating the application when adding new functions or changing the function state, and does not need to download a large number of pictures, thereby improving the efficiency of the application and the user experience.

In some embodiments, processing drawing information belonging to the same original design picture into picture rule data using a predetermined data organization rule includes: and processing the drawing information of the same original design picture into picture rule data by adopting a preset data organization rule at the server, and storing the picture rule data at the server, wherein the picture rule data comprises drawing information of drawing elements and element drawing sequences.

Specifically, a predetermined data organization rule (also referred to as a data assembly rule) is adopted at the server side, and drawing information of the same original design picture is assembled into a data structure (i.e., picture rule data). These picture rule data define drawing rules of various drawing elements, such as a battery, a car lock, a sunroof, etc., and then the server stores these picture rule data on the server.

Further, the picture rule data may be transmitted from the server to the client in various forms, such as in the form of response data of HTTP requests, files, byte stream arrays, and the like. The following composition may be used for the composition of the content of the picture rule data: such as json, xml, etc., and of course, custom natural language descriptions, pure digital combinations, etc. may also be used.

At the client, the data are analyzed according to the data and the organization rules issued by the server, and corresponding picture drawing is performed according to the picture rule data. It should be noted that, no matter whether the form of the picture rule data is json, xml which are easy to read or byte stream which are difficult to read directly, the client can draw the picture as long as the client can parse the data according to the rule.

The following details of the related content of the data organization rule and the picture rule data are described in connection with specific embodiments, and may specifically include the following:

in one example, the data of the battery may be a json string, the content of which is a custom rule, the outermost layer is a set of all pictures (such as battery, car lock, sunroof, etc.), the second layer is each picture (battery), the third layer is a drawing element of each picture, such as straight line, curve, etc., and json describes the data in the form of key value pairs. The server may directly put the json string in the return data of the HTTP request of the client, or may put the json string in a file, so that the client downloads the json string.

{

"Battery": {

"straight line": {

"x":"20","y":"0"

}

"curve": {

"upper left corner x" means "0", "upper left corner y" means "0", "upper right corner x" means "40", "upper right corner y" means "0", … … "

}

……

}

"vehicle lock": {

"curve": {

……

}

……

}

……

}

In another example, as shown in fig. 3, fig. 3 is a schematic structural diagram of picture rule data in an actual scene according to an embodiment of the present application, where the picture rule data may specifically include the following:

the server can send a Byte stream data (each Byte is an integer of 0-127) to the client through TCP protocol, and the 1 st-4 th Byte of the Byte stream represents the total length of the data; byte 5 represents how many pictures there are; the 6 th to 10 th bytes represent the data start position of the first picture, and the 11 th to 15 th bytes represent the data end position of the first picture (i.e., how many bits the data of the first picture is from to how many bits); the following bytes represent in turn from how many bits to how many bits the data of the 2 nd picture is; in the data of each picture, the 1 st to 5 th bytes of data represent how many bits the straight line data is from to, the 6 th to 10 th bytes represent how many bits the curve data is from to, and the 11 th to 15 th bytes represent how many bits the color data is from to.

In another example, by designing an array, each element of the array corresponds to a vehicle function picture. Each array element can also be considered as a complex data structure, and can be expressed specifically as the following key-value pairs:

Bond 1: whether there is a variant in function;

bond 2: variants;

the variant is also an array, each array element corresponds to a variant data, the variant data is a key value pair, and the key is the color of the variant;

key 3: drawing elements

The drawing element is also an array, and each array element corresponds to a specific drawing and is a key value pair;

bond A: curve of curve

The curve is also a complex data structure including control points for the curve, which is more than one, and therefore an array, including line width of the curve, color of the curve, etc.;

bond X: a control point array of the curve;

bond Y: line width of the curve;

bond Z: the color of the curve;

……

bond B: wire (C)

A line is also a complex data structure including a start point, a path point, an end point of a curve, more than one and therefore an array, including line width of the line, color of the line, pattern of line ends, etc.;

bond X: a point group of lines;

bond Y: line width of the line;

bond Z: color of the line;

bond R: end pattern of line;

……

according to the technical scheme provided by the embodiment of the application, the generation of the vehicle function pictures is transferred to the client, a large number of function pictures are not required to be pre-stored, the storage space is saved, the addition of new functions and the processing of state change are also facilitated, and the complicated step of re-releasing versions due to the addition of new functions or new states is avoided. In addition, the method and the device can dynamically generate the pictures of various design elements according to the picture rule data without storing all possible pictures in the client side in advance, so that the storage space is saved, and the flexibility of picture generation is improved. Meanwhile, since the picture rule data is stored in the server, modification and updating can be conveniently performed without upgrading the client.

In some embodiments, coordinate converting drawing information of each drawing element in the picture rule data includes: when the size proportion of the original design picture is consistent with that of the vehicle function picture to be drawn, determining the drawing proportion by utilizing the ratio between the size of the vehicle function picture and that of the original design picture, and converting coordinates in drawing information by utilizing the drawing proportion; when the size ratio of the original design picture to the vehicle function picture to be drawn is inconsistent, the width ratio and the height ratio between the vehicle function picture and the original design picture are calculated respectively, the smaller ratio of the width ratio and the height ratio is used as the drawing ratio, and the coordinates in the drawing information are converted by using the drawing ratio.

Specifically, the embodiment of the application enables the client to analyze the picture rule data by issuing the generated picture rule data to the client, and performs picture drawing by utilizing the analyzed picture rule data. Firstly, in the embodiment of the present application, the server is used to issue the picture rule data to the server, which may be any one of the following two manners:

the first issuing mode is as follows: if the total number of the picture rule data is not large, the server can put all the rule data of the original design pictures together and issue the rule data at one time. The client requests the server interface at the beginning of the program start, downloads the picture rule data and stores the picture rule data in the memory. When a user enters a certain page, the client accesses the rule data of the pictures according to the pictures used on the page, and takes out the rule data corresponding to the pictures, thereby drawing the pictures.

The second way of issuing: if the total number of the picture rule data is large, the data volume is huge, the rule data can be split, and the client only requests one or more pieces of rule data of the server at a time according to the requirement. Therefore, the request of the client needs to carry parameters, and the parameters are used for informing the server of which piece or pieces of regular data to acquire.

Optionally, since the communication between the server and the client is affected by the network status, in order to avoid failure of data acquisition caused by no network and too slow network, the client may also maintain a cached copy of the server data locally, for example: when the client pre-packages, a server keeps the latest configuration file data in the client package. After the client obtains the latest data of the server, the data are stored and a part of the data are stored in a sandbox, so that the client can conveniently use the data under the condition of no network and too slow network. And updates the server after each time it gets the latest data.

Further, after obtaining the picture rule data corresponding to the original design picture, the client performs coordinate conversion on the drawing information of each drawing element in the picture rule data, namely, converts the position coordinates of the lines and the points in the picture rule data. The original width and height of the picture itself are included in the picture rule data, and the width and height of the control are also included in the actual page display, so that the width and height of the picture to be displayed (drawn) are generally required to be determined by the control, and the drawing proportion is required to be calculated because the width and height of the picture are not necessarily equal to each other, and the coordinate point value in the rule data is multiplied by the proportion, so that the coordinate point value required in drawing is obtained. The embodiment of the application provides two coordinate conversion methods under different situations, and the following details of the two coordinate conversion methods in the two situations are described in connection with specific embodiments, which may specifically include the following:

As shown in fig. 4, fig. 4 is a schematic diagram of coordinate transformation of picture rule data in the first case according to the embodiment of the present application. In the first case, when the original design picture is identical to the size ratio of the vehicle function picture to be drawn, in this case, although the width and the height of the two pictures are different, they are scaled in equal proportion, and therefore, the ratio between the size of the vehicle function picture to be drawn (i.e., the drawing size) and the size of the original design picture (i.e., the original size) can be used to determine the drawing ratio, i.e., the drawing ratio = the width of the vehicle function picture to be drawn/the width of the original design picture; similarly, height calculations are possible because the proportions are the same. At this time, the coordinate point values used in the actual drawing are: value of X axis = X value in picture rule data X scale, value of Y axis = Y value in picture rule data X scale, that is, width and height used in actual rendering are: width of a certain line=width in picture rule data×drawing ratio, height of a certain line=height in picture rule data×drawing ratio, thereby realizing conversion of coordinate values in picture rule data.

As shown in fig. 5, fig. 5 is a schematic diagram of coordinate transformation of picture rule data in the second case according to the embodiment of the present application. In the second case, when the original design picture is inconsistent with the size ratio of the vehicle function picture to be drawn, in this case, although the ratio between the width and the height of the original design picture and the width and the height of the vehicle function picture to be drawn are inconsistent, it is generally required that the pictures can be fully displayed and centrally displayed, and therefore the drawing ratio should take a smaller value of the width and the height ratio. For example: wide scale=drawing width/original width, high scale=drawing height/original height, and a smaller value is selected from the wide scale and the high scale as the drawing scale. Then, a certain coordinate point value used in the actual drawing is: value on X axis = X value in picture rule data X scale, value on Y axis = Y value in picture rule data X scale; thus, the width and height used in actual rendering are: width of a certain line=width in picture rule data×drawing ratio, height of a certain line=height in picture rule data×drawing ratio, thereby realizing conversion of coordinate values in picture rule data.

After the size in the rule data of the picture is scaled by the drawing scale, the coordinate origin of the picture required by the control is not consistent with the original coordinate origin of the picture due to the centered display. However, the iOS control supports centering adjustment of the picture, the control is namely a class instance of uiiview or a sub-class instance thereof, the uiiview class has an attribute contentmede, and the value of the uiiview class can set whether the picture is centered or scaled in an equal ratio and the like; therefore, in the embodiment of the present application, in order to avoid calculation, the alignment calculation of the origin of coordinates may be omitted, and instead, the picture may be directly drawn, and then the control may be adjusted by the contentmede. In practical application, because the calculation is not complex, the coordinate origin can be adjusted first, then the picture is directly drawn and directly assigned to the control, and the contentMode attribute of the control is not required to be set.

In one example, the adjustment calculation formula for the origin of coordinates is as follows:

the scaled axis (e.g., y-axis) is not adjusted, and the un-scaled axis (e.g., x-axis) is added with the difference; difference = length required for drawing-length in picture rule data, and takes absolute value, then a certain coordinate point value used in actual drawing is: value on X axis = value now calculated on X axis + difference value, value on Y axis unchanged.

According to the technical scheme provided by the embodiment of the application, the suitability of equipment is improved: the drawing information contained in the picture rule data is subjected to coordinate conversion, so that the generated vehicle function picture can adapt to screens with various sizes, complex operations such as zooming, cutting and stretching are not required to be performed on the picture, and the display effect of the picture is ensured.

After converting coordinates in the drawing information, the program reads rule data sent by the server, obtains the total number of pictures, and then traverses each picture data. Each picture data contains all element information required for drawing the picture, such as lines, points, colors, shadows and the like, as well as the number of variants of the picture and colors corresponding to the variants. The program can sequentially call the corresponding function functions to draw the elements according to the drawing sequence specified by the server. For example, if a line is encountered, a function is called that draws the line; if a point is encountered, a function is called that draws the point, and so on.

In one example, in an iOS system, two main methods of drawing pictures are provided. The first method is to draw using the uighics imagerenderer class. First, an instance of uighlicimagerenderer needs to be created, its size and format set. Then, the image () method of this instance is called for drawing. The parameters of this method are a function that contains the actual rendering code. Finally, the return value of the image () method is the drawn picture. The second method is to directly call the drawing context to draw, and finally call the iggraphicsigetimagefrom currentimagecontext () method to the drawing context object, and the return value of the method is the required picture.

It should be noted that, the two methods for implementing drawing the picture have no absolute advantages and disadvantages, and the selection of which method depends mainly on specific requirements and application scenes. In the actual rendering process, a rendering tool provided by the Core Graphics library can be selected, and a uibezier path class encapsulated by UIKit can be also used. The uibrezier path class provides a series of methods of drawing points, lines, shapes, colors, etc., which are also essentially drawn by a tool that invokes the Core Graphics library, and the two tools can be mixed together.

In some embodiments, invoking the corresponding function to sequentially draw the drawing elements includes: calling an initialization function of a preset graphic renderer class to generate a graphic renderer instance, wherein parameters of the initialization function comprise the size of an original design picture and drawing configuration information; and calling a graph drawing method in the graph renderer example, wherein parameters of the graph drawing method are drawing code functions, and calling drawing information converted by coordinates by using the drawing code functions so as to draw drawing elements in sequence according to an element drawing sequence, thereby obtaining a vehicle function picture.

Specifically, in the first picture drawing implementation method, the class uighics imagerenderer will be used to generate the required pictures. The following is a detailed explanation of the first picture drawing implementation method:

first, a uighlicimagerenderer instance (i.e., a graphics renderer instance) needs to be created. This instance is created by calling its initialization function. This function receives two parameters: the first parameter is a size object (i.e., the size of the original design picture) that represents the width and height of the picture that needs to be drawn; the second parameter is an instance of uighaphics imagerendererformat, which represents drawing configuration information. Included in this drawing configuration information are parameters such as transparency of the picture, scaling and color gamut of the device, etc. In most cases, the default instance of uigericimagerendererformat, i.e., uigericimagerendererformat (), can be used directly.

Optionally, taking a drawing process of a battery image as an example, a complete implementation process of drawing a picture by using the first picture drawing implementation method is described in detail, which may specifically include the following:

(1) Drawing frame (UIKit tool for example here)

Manufacturing a frame path: an initialization function public convenienceinit (roundrect: CGRect, corer radius: cgflow) of the UIBezierPath class is called to generate an UIBezierPath instance, which represents generating a rectangular box with rounded corners, the 1 st parameter is passed into the CGRect class instance consisting of coordinates of 4 points of the rectangle, and the second parameter is the radius of the rounded corners.

Setting a frame line width: the lineWidth attribute of the uibrezier path class instance is set to the desired lineWidth.

Setting the color of a frame: and calling an initialization method public init (red: CGFloat, green: CGFloat, blue: CGFloat, alpha: CGFloat) of the UIColor class to generate a UIColor instance, and transmitting the parameters into corresponding RGBA values.

Drawing a frame curve: and calling a stroke method of the UIBezierPath class instance, namely finishing drawing of the frame.

(2) Drawing a top straight line (here taking Core Graphics library tools as an example)

Calling a UIGgraphicGetCurrentContext () function, wherein the return value of the function is the current drawing context; the UIG_GetCurrentContext attribute of the function of the image (i.e., the UIG_ImageRenderContext type mentioned above) can also be called here to get this drawing context.

Making a straight line path: and calling a public function move (to point) method for the drawing context, wherein parameters of the method are transmitted into the starting point coordinates of the straight line.

The method public func addLine (topoint) is called for the drawing context, whose parameters are passed into the end point coordinates of the line.

Setting line width: the line width is set by calling public func setLineWidth (_width: CGFloat) method to the rendering context.

Setting the color: the drawing context is called public funcsetStrokeColor (color: CGColor) method, setting the line color.

Drawing a straight line: and calling a stroke (a) method for the drawing context, namely finishing drawing of the straight line.

(3) Drawing a gradient region

The drawing of the gradient region requires two steps: clipping and drawing.

First, since the gradation region in iOS cannot directly specify the drawn region, clipping is required first. In practice, a rectangular path may be created, or a line with a line width that is the width of the transition region, and then the path is converted into a rectangular region. The clip method of the drawing context is then called to crop this region. The clipping implementation process is as follows:

the coordinates and width and height of the gradient region in the drawing rule are obtained, a rectangular region can be manufactured in a similar step as in the step (1), a straight line with the line width being the width of the gradient region can be manufactured in a similar step as in the step (2), and then the displacePathWithStrokedPath () method of the drawing context is called to convert the thick straight line into the rectangular region. This rectangular region is cut out by calling the clip () method of the drawing context.

The fade area is then redrawn, by creating a fade object that defines the fade's color space (e.g., RGBA, gray scale, or CMYK), the fade's color array, and the color's change coordinate array. Then, according to the gradual change mode of the rule data, the gradual change area is drawn by selectively calling the drawLinear gradient method (linear gradual change) or the drawLinear gradient method (circle center gradual change). Finally, the resetClip method of the drawing context is called to restore the clipping shape, thus completing the drawing of the battery image. The drawing process of the gradual change region is as follows:

an initialization method public init of the CGGradient class is called-! (colorsSpace space: CGColorSpace: cgcolorspacereadedevicecmyk (), and so on; the second parameter is an gradient array, the third parameter is a gradient mode of reading rule data by a gradient change coordinate array, and the decision is to call public funcdrawLinearGradient (gradient: CGgradient, start point: CGPoint, enddPoint: CGPoint, options: CGgradient with operations) method [ linear gradient ] or public funcdrawRadialGradient (gradient: CGgradient, start center: CGPoint, start radius: CGflow, endchannel: CGflow, options: CGgradient with the center of the circle) method [ circle gradient ]. After drawing is completed, a resetClip () method of the drawing context is called, and the clipping shape is restored.

In some embodiments, invoking the corresponding function to sequentially draw the drawing elements includes: and calling and acquiring a current graphic context function to acquire a current drawing context, drawing an image in the current drawing context by utilizing a pre-generated graphic renderer instance, and calling a drawing context object after drawing is completed so as to synthesize an image by utilizing the drawn content in the current drawing context, thereby obtaining a vehicle function picture.

Specifically, in the second picture drawing implementation method, the drawing context is directly called to draw, and finally, the iggraphicsgetimagefromcurrentimagecontext () method is called to the drawing context object, and the return value of the method is the picture to be drawn. The following is a detailed explanation of the second picture drawing implementation method:

(1) Call uighaphicsgetcurrentcontext () function: this is the starting point for starting any drawing work, uighaphicsigttcurrentcontext () is a function that returns the current drawing context. In iOS drawing, a graphic Context (graphic Context) can be understood to be a virtual canvas on which all drawing operations are performed. The current graphics context generally refers to the target context of the current drawing operation, i.e., on which canvas the current drawing operation is to be completed. The function uighaphicsgetcurrentcontext () is used to obtain this current graphics context so that drawing operations can be performed thereon later.

(2) Drawing is started: at this stage, the graphics can be drawn using the same method as in the uighaphics imagerenderer instance. This includes tools provided using the UIKit library (e.g., uibrezier path, et al), or tools provided using the Core Graphics library. Both tools have their own advantages, which can be selected and combined as desired. For example, uibrezier path is easy to use, and can handle a variety of shapes, while Core Graphics provides more low level control (e.g., fading).

(3) After the drawing is completed, an iggraphicsgetimagefromcurrentimagecontext () method is called for the drawing context object: after the rendering is completed, an image needs to be acquired from the current rendering context. Iggraphics getimagefromcurrentimagecontext () is a function that returns an image in the current context. This means that it captures all the content drawn in the context as one UIImage object, i.e. gets the drawn graph.

According to the technical scheme provided by the embodiment of the application, the picture is generated by using the picture rule data, and compared with the method for directly downloading a large number of pictures, the method reduces the pressure of network bandwidth. Meanwhile, the picture rule data stored in the client can be continuously used when the picture rule data is not updated according to the comparison between the picture rule data of the server and the picture rule data stored in the client, so that unnecessary data transmission is avoided.

In some embodiments, after generating the vehicle function picture corresponding to the original design picture, the method further includes: setting a rendering mode of the vehicle function picture by using parameters to obtain a template picture corresponding to the vehicle function picture, assigning the template picture to a preset control, and setting the coloring attribute of the control to the color corresponding to the variant picture when the color of the vehicle function picture needs to be changed to generate the variant picture, wherein the color information of the picture is ignored in the template picture, and the transparency information of the picture is reserved.

Specifically, the embodiment of the application also provides a drawing method of a variant picture of the vehicle function picture, wherein the variant picture refers to a picture which has the same picture shape as the vehicle function picture but is different in color. The embodiment of the application provides two methods for generating a variant picture, wherein a first implementation method is to generate the variant picture by using a template picture, and the following details of a process for generating the variant picture by using the template picture are described in connection with a specific embodiment, which may specifically include the following:

this approach is generally applicable to replacement of all picture colors, such as replacing all colors in a picture instead of partial replacement, but partial replacement is also possible. The template picture (template) in iOS means: the color value of a picture is ignored and only its transparency (alpha) is useful. If the template picture is assigned to the control, the picture can set the color of the picture by using the attribute tintColor of the control.

Further, for the vehicle function picture generated by the foregoing embodiment, since it is an example of the UIImage class. Thus, by calling the withRenderingMode method, the parameter is passed in. The template picture can be directly assigned to the control for use at the client, and when the modification is needed, the tintColor attribute of the control is set to be the needed color.

Finally, the first parameter of the two methods, namely, the withTintcolor (:) or the withTintcolor (:) is to transfer a color, so that the color of the variant picture needs to be transferred, and a variant picture can be obtained. The parameter of the withTintcolor (: rendering mode) may also be set to. It should be noted that if there are multiple variant colors, one of the two functions is called multiple times to obtain a corresponding multiple variant pictures. The method can be directly used without setting the tintColor attribute of the control.

Further, the second implementation method is as follows: when the vehicle function picture is generated, variant colors are rendered, and the steps of the embodiment are called for multiple times to generate multiple variants. This method is applicable to variants where the color is not wholly variable but is locally variable. Of course, overall variations may also be used in this way. When the variant picture is generated, the picture rule data is read in the step of dyeing to obtain which part specified by the picture rule data needs to be discolored and the variant color, and the picture is directly rendered. Since only one picture can be obtained at a time, multiple variant pictures are repeatedly called.

For example, in one example, since variant colors are a class instance of UIColor that supports solid colors, gradient colors, and combined colors composed of complex pictures, it is sufficient to obtain which part specified by picture rule data needs to be color-changed according to picture rule data in order for different areas of a picture to be presented with different colors, and the variant colors, generate a class instance of UIColor as a parameter of the foregoing function wittingcolor (:) or wittingcolor (:) as well.

In one example, when the first implementation method is used, the image (_:) function is called for multiple times for the uighics imagerenderer class instance to obtain multiple variants, each call is changed only in the color rendering part according to the requirement, and the rest logic is kept unchanged. When the second implementation method is used, firstly, drawing pictures, calling the IGgraphicsGetImageFromCurrentImageContext () method for drawing context objects for a plurality of times to obtain a plurality of variants, and only changing the part of the color to be rendered according to the requirement when calling each time, wherein the rest logic is kept unchanged.

In some embodiments, after generating the vehicle function picture corresponding to the original design picture, the method further includes: and storing the vehicle function picture and the variant picture into a memory, requesting the server to acquire picture rule data when the client calls the vehicle function picture and the variant picture, comparing the picture rule data acquired from the server with the picture rule data stored by the client, judging whether the picture rule data corresponding to the vehicle function picture and the variant picture are updated, continuously using the picture rule data stored by the client when judging that the vehicle function picture and the variant picture are not updated, cleaning the vehicle function picture and the variant picture in the memory when judging that the vehicle function picture is updated, and redrawing the vehicle function picture.

Specifically, after the vehicle function picture and the corresponding variant picture thereof are drawn, the vehicle function picture and the variant picture are stored in the memory. In general, in a life cycle of an App (i.e., a period from when a program is started by a user to when it is terminated by a system or a user), after a vehicle function picture and its variant pictures are drawn once, repeated drawing should be avoided, and the existing pictures are stored in a memory and directly read for use when the next use is performed. However, if the server updates the rule data of the picture in the life cycle of the App, a problem occurs at this time, so that when the picture is required to be used each time (usually when the control or page where the picture is located needs to be refreshed and displayed), the rule data of the picture of the server is compared with the original rule data of the client, whether the rule data corresponding to the picture is updated or not is judged, if the rule data is not updated, the picture in the sandbox is continuously used, otherwise, the picture in the memory is cleaned, and the picture is redrawn.

Alternatively, the pictures can also be stored in a sandbox (sandbox is a local persistent storage of the client, which can be always present as long as the app is not deleted, although the user can manage these storage spaces as well). If stored in a sandbox, cleaning actions on the picture cache are involved, such as: the regular data of the server is updated, the pictures in the original sandboxes are illegal, and the pictures should be deleted. Thus, to formulate a set of cleanup logic, which may be complex or simple, the following are some optional cleanup logic, one or more of which may be used to combine the cleanup scheme of rule data, specifically:

Logic one: the pictures are cleaned up each time the program exits, which is simple but not different from being put in memory.

Logic II: recording the picture data in the existing sandbox, comparing the latest rule data with the original rule data after the latest rule data of the server is taken each time, judging whether the rule data corresponding to the picture is updated or not, if not, continuing to use the picture in the sandbox, otherwise, cleaning the picture in the sandbox, and redrawing.

And (3) logic III: a time policy is formulated to delete the pictures periodically, for example, every 10s or when the picture storage capacity reaches a preset volume.

Optionally, the rules for drawing and storing the pictures can be formulated according to statistics, and because the stored pictures have the risk of overdue pictures, pulling the rule data of the server each time when the pictures are used can be influenced by network conditions, and if the page refreshing is more frequent, certain pressure can be caused on the server. A compromise is designed, so that it is desirable to store both pictures and reduce the number of draws, but also reduces the number of times the server is requested. Therefore, in the application process, the number of times of using each vehicle function picture in the application is counted, the number of times of changing the server rule data of each vehicle function picture is counted, and when the application is used for a period of time, a counting table is obtained. The following rules are then formulated.

In some embodiments, the method further comprises: counting the use times of each vehicle function picture and the change times of picture rule data of each vehicle function picture, grouping the vehicle function pictures by utilizing a preset use times threshold and a preset change times threshold to obtain a first vehicle function picture, a second vehicle function picture, a third vehicle function picture and a fourth vehicle function picture, and respectively processing the vehicle function pictures in different groups by utilizing a preset strategy.

Specifically, before the rule is taught, it is required to supplement that the statistics table may be statistics performed for a client device, so that these statistics are not uploaded to the server, and only the analysis is performed for the device, and the analysis result is very relevant to the habit of the user of the device (for example, the user does not like to enter certain pages, so that the pictures of the vehicle functions corresponding to those pages are less). In addition, the statistics table may be statistics for the App, so that the statistics data of all clients need to be uploaded to the server, and the server performs statistical analysis on a large data layer, and the analyzed result is related to the overall user habit.

Further, the embodiment of the application can set the use frequency threshold and the change frequency threshold according to service requirements or according to statistical experience, and divide the vehicle function pictures under different groups by using the use frequency threshold and the change frequency threshold, so that the vehicle function pictures in the different groups are processed by using different strategies. For example: counting the number of times each vehicle function picture in the App is used, dividing the vehicle function picture with the use number exceeding the use number threshold (such as 30 times) into a first use number picture, and dividing the vehicle function picture with the use number lower than the use number threshold (such as 30 times) into a second use number picture; in addition, the number of times of server data change per vehicle function picture is counted, the vehicle function picture whose change number exceeds a change number threshold (for example, 3 times) is divided into a first change number picture, and the vehicle function picture whose change number is lower than the change number threshold (for example, 3 times) is divided into a second change number picture.

In some embodiments, processing the vehicle function pictures of different groups respectively by using a predetermined strategy includes: for the first vehicle function picture, storing the first vehicle function picture after the first drawing in a memory or a sandbox, and acquiring picture rule data of the first vehicle function picture from a server when an application program is started or used for the first time; temporarily drawing the second vehicle function picture when the second vehicle function picture is used, and acquiring picture rule data of the second vehicle function picture from a server when an application program is started or used for the first time; for the third vehicle function picture, storing the first drawn third vehicle function picture in a memory or a sandbox, and acquiring picture rule data of the third vehicle function picture from a server when the third vehicle function picture is used each time; for the fourth vehicle function picture, temporary drawing is performed on the fourth vehicle function picture when in use, and picture rule data of the fourth vehicle function picture is acquired from the server every time the fourth vehicle function picture is used.

Specifically, the embodiments of the present application will configure different processing policies for different groups of vehicle function pictures, and the following details of the content of the processing policies of the four types of vehicle function pictures are described in detail with reference to specific embodiments, which may specifically include the following:

1. the following processing strategies are configured for the first vehicle function picture, namely the first usage frequency picture and the second change frequency picture:

after the first drawing, the drawing is directly stored in a memory or a sandbox. And the picture rule data in the server is not pulled every time when the server is used, and is pulled at the beginning of the start of the App, or pulled when the picture rule data of the server is used for the first time, a notification is sent to the App to enable the App to pull the latest picture rule data immediately (the mode of notifying the App to the server comprises but not limited to Socket long connection, APNS remote notification and the like).

2. The following processing strategies are configured for a second vehicle function picture, namely, a second usage number picture and a second change number picture:

the processing strategy corresponding to the second vehicle function picture may be the same as that of the first vehicle function picture, but because of its low number of uses, the processing strategy of the first vehicle function picture may be changed to: the temporary drawing is performed when in use and is not stored in a memory or a sandbox.

3. The following processing strategies are configured for a third vehicle function picture, namely a first usage frequency picture and a first change frequency picture:

after the first drawing, the drawing is directly stored in a memory or a sandbox, and the picture rule data in the server is pulled when each use is performed.

4. The following processing strategies are configured for a fourth vehicle function picture, namely, a second usage frequency picture and a first change frequency picture:

the fourth vehicle function picture is temporarily drawn when in use, without storing the fourth vehicle function picture in a memory or a sandbox, and the picture rule data in the server is pulled when each use.

It should be noted that the application is not only applicable to vehicle function pictures, but also to all pictures satisfying the following rules: the picture is not complex, and can be split into a small number of constituent elements such as points, lines, planes, colors, characters, shadows and the like; the picture rule data may change, including the data of the picture itself and the variation of the picture; whether new types of pictures can be added, deleting expired pictures, etc. The optimization rules mentioned in the foregoing embodiments are applicable not only to the vehicle function picture rule data, but also to other data that needs to be updated by a server

The vehicle function picture is not limited to the picture which can be divided into a small number of points, lines, surfaces, colors, characters, shadows and other constituent elements, and can be a more complex picture, for example: and for a green picture, the client draws the picture on the left side according to the rule data, turns over the picture, reduces the picture, draws the picture on the right side, and sets the width of the line of the frame to be 2. For the variation of the picture, not only the color change, but also the graphical path-based, a change in the color filling mode, or addition or subtraction of other shapes, etc. The Android and the iOS have similar picture drawing class libraries and functions, so the technical scheme is also applicable to Android.

According to the technical scheme provided by the embodiment of the application, the vehicle function picture is not a very complex picture, and can be split into the characteristic of basic drawing functions, so that a flexible generation scheme of the vehicle function picture is formulated, namely, a server issues a drawing rule, and a client directly draws according to the required actual picture size and generates the picture. The technical scheme of the application has the following advantages:

(1) The method and the device avoid the processes of zooming, cutting, stretching and the like on the pictures, and save the performance cost of the system.

(2) The system provides a convenient system API for drawing pictures and generating different color variants of one picture, the generation speed is very high, and the user does not feel, so the process of generating the pictures is efficient.

(3) The rule issued by the server is only configured by few numbers and the like, is very small compared with the picture, so that the bandwidth of the user is greatly saved, and the memory occupation is reduced.

(4) Because the rule is issued by the server, when the demand of the product changes, the server can update the rule to update the picture, thereby realizing the function of flexibly updating the UI without the need of the client to resend the version.

(5) Drawing according to the requirement can be realized, and corresponding picture generation is not performed without entering a vehicle control related page by a user. And the generated picture is stored in a memory or a client local sandbox, and is not drawn repeatedly, and can be directly read from the memory or the sandbox next time. And this step can also be optimized as: according to the technical scheme, the generation times of each functional picture are counted and recorded to the server, the frequently used pictures are pre-drawn, and the pictures which are not frequently used are drawn as required.

(6) For each car function picture, there are different states, for example: the vehicle searching function is only unavailable and in normal state because a seek is a one-point-at-start action, there is no neutral off/on state) and therefore only one gray picture and one black picture need be generated. According to the technical scheme, the data are set by the server, so that the number of pictures which correspond to different colors can be flexibly configured according to different vehicle control functions.

(7) The picture generated by the method is a vector picture, and the picture obtained by drawing can be scaled in any size without distortion, so that the picture has the best definition and contrast, and the picture can be directly multiplexed without any performance or blurring problem under the scene that the pictures are the same in size and different in size.

The following are device embodiments of the present application, which may be used to perform method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

Fig. 6 is a schematic structural diagram of a vehicle function picture generating device based on a client according to an embodiment of the present application. As shown in fig. 6, the client-based vehicle function picture generation device includes:

the disassembly module 601 is configured to obtain an original design picture of the vehicle function, disassemble the original design picture into drawing elements, and determine drawing information of each drawing element in a reference coordinate system;

the processing module 602 is configured to process drawing information belonging to the same original design picture into picture rule data by using a predetermined data organization rule, so as to obtain picture rule data corresponding to each original design picture;

The parsing module 603 is configured to issue the picture rule data to the client, so that the client parses the picture rule data and performs coordinate conversion on drawing information of each drawing element in the picture rule data;

the drawing module 604 is configured to call a corresponding function to draw the drawing elements in turn based on the drawing information after coordinate conversion by using the element drawing sequence defined in the picture rule data, so as to generate a vehicle function picture corresponding to the original design picture.

In some embodiments, the processing module 602 of fig. 6 processes, at the server, drawing information of the same original design picture into picture rule data using a predetermined data organization rule, and stores the picture rule data at the server, where the picture rule data includes drawing information of drawing elements and an element drawing order.

In some embodiments, when the size ratio of the original design picture and the vehicle function picture to be drawn is consistent, the parsing module 603 of fig. 6 determines the drawing ratio by using the ratio between the size of the vehicle function picture and the size of the original design picture, and converts the coordinates in the drawing information by using the drawing ratio; when the size ratio of the original design picture to the vehicle function picture to be drawn is inconsistent, the width ratio and the height ratio between the vehicle function picture and the original design picture are calculated respectively, the smaller ratio of the width ratio and the height ratio is used as the drawing ratio, and the coordinates in the drawing information are converted by using the drawing ratio.

In some embodiments, the drawing module 604 of fig. 6 invokes an initialization function of a preset graphics renderer class to generate a graphics renderer instance, where parameters of the initialization function include a size of an original design picture and drawing configuration information; and calling a graph drawing method in the graph renderer example, wherein parameters of the graph drawing method are drawing code functions, and calling drawing information converted by coordinates by using the drawing code functions so as to draw drawing elements in sequence according to an element drawing sequence, thereby obtaining a vehicle function picture.

In some embodiments, the drawing module 604 of fig. 6 invokes the get current graphics context function to get the current drawing context, performs image drawing in the current drawing context using the pre-generated graphics renderer instance, and invokes the drawing context object after drawing is completed to compose an image using the content drawn in the current drawing context, resulting in a vehicle function picture.

In some embodiments, after generating the vehicle function picture corresponding to the original design picture, the drawing module 604 of fig. 6 sets a rendering mode of the vehicle function picture by using parameters to obtain a template picture corresponding to the vehicle function picture, assigns the template picture to a preset control, and sets a coloring attribute of the control to a color corresponding to the variant picture when the color of the vehicle function picture needs to be changed to generate the variant picture, wherein color information of the picture is ignored in the template picture, and transparency information of the picture is reserved.

In some embodiments, the drawing module 604 of fig. 6 stores the vehicle function picture and the variant picture in the memory after generating the vehicle function picture corresponding to the original design picture, when the client invokes the vehicle function picture and the variant picture, requests the server to acquire the picture rule data, compares the picture rule data acquired from the server with the picture rule data stored in the client, determines whether the picture rule data corresponding to the vehicle function picture and the variant picture is updated, and when it is determined that the update does not occur, continues to use the picture rule data stored in the client, and when it is determined that the update occurs, cleans the vehicle function picture and the variant picture in the memory, and redraws the vehicle function picture.

In some embodiments, the drawing module 604 of fig. 6 counts the number of times of use of each vehicle function picture and the number of times of change of the picture rule data of each vehicle function picture, groups the vehicle function pictures by using a preset use number threshold and a preset change number threshold, and obtains a first vehicle function picture, a second vehicle function picture, a third vehicle function picture and a fourth vehicle function picture, and processes the vehicle function pictures of different groups by using a predetermined policy.

In some embodiments, the drawing module 604 of fig. 6 stores the first vehicle function picture after the first drawing in a memory or a sandbox for the first vehicle function picture, and obtains picture rule data of the first vehicle function picture from the server when the application is started or used for the first time; temporarily drawing the second vehicle function picture when the second vehicle function picture is used, and acquiring picture rule data of the second vehicle function picture from a server when an application program is started or used for the first time; for the third vehicle function picture, storing the first drawn third vehicle function picture in a memory or a sandbox, and acquiring picture rule data of the third vehicle function picture from a server when the third vehicle function picture is used each time; for the fourth vehicle function picture, temporary drawing is performed on the fourth vehicle function picture when in use, and picture rule data of the fourth vehicle function picture is acquired from the server every time the fourth vehicle function picture is used.

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not limit the implementation process of the embodiment of the present application in any way.

Fig. 7 is a schematic structural diagram of an electronic device 7 according to an embodiment of the present application. As shown in fig. 7, the electronic device 7 of this embodiment includes: a processor 701, a memory 702 and a computer program 703 stored in the memory 702 and executable on the processor 701. The steps of the various method embodiments described above are implemented by the processor 701 when executing the computer program 703. Alternatively, the processor 701, when executing the computer program 703, performs the functions of the modules/units of the apparatus embodiments described above.

Illustratively, the computer program 703 may be partitioned into one or more modules/units, which are stored in the memory 702 and executed by the processor 701 to complete the present application. One or more of the modules/units may be a series of computer program instruction segments capable of performing a specific function for describing the execution of the computer program 703 in the electronic device 7.

The electronic device 7 may be a desktop computer, a notebook computer, a palm computer, a cloud server, or the like. The electronic device 7 may include, but is not limited to, a processor 701 and a memory 702. It will be appreciated by those skilled in the art that fig. 7 is merely an example of the electronic device 7 and is not meant to be limiting as the electronic device 7 may include more or fewer components than shown, or may combine certain components, or different components, e.g., the electronic device may further include an input-output device, a network access device, a bus, etc.

The processor 701 may be a central processing unit (Central Processing Unit, CPU) or other general purpose processor, digital signal processor (Digital Signal Processor, DSP), application specific integrated circuit (Application SpecificIntegrated Circuit, ASIC), field programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 702 may be an internal storage unit of the electronic device 7, for example, a hard disk or a memory of the electronic device 7. The memory 702 may also be an external storage device of the electronic device 7, for example, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like provided on the electronic device 7. Further, the memory 702 may also include both internal storage units and external storage devices of the electronic device 7. The memory 702 is used to store computer programs and other programs and data required by the electronic device. The memory 702 may also be used to temporarily store data that has been output or is to be output.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in this application, it should be understood that the disclosed apparatus/computer device and method may be implemented in other ways. For example, the apparatus/computer device embodiments described above are merely illustrative, e.g., the division of modules or elements is merely a logical functional division, and there may be additional divisions of actual implementations, multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

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

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated modules/units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application implements all or part of the flow in the methods of the above embodiments, or may be implemented by a computer program to instruct related hardware, and the computer program may be stored in a computer readable storage medium, where the computer program may implement the steps of the respective method embodiments described above when executed by a processor. The computer program may comprise computer program code, which may be in source code form, object code form, executable file or in some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth. It should be noted that the content of the computer readable medium can be appropriately increased or decreased according to the requirements of the jurisdiction's jurisdiction and the patent practice, for example, in some jurisdictions, the computer readable medium does not include electrical carrier signals and telecommunication signals according to the jurisdiction and the patent practice.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; 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 scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. The vehicle function picture generation method based on the client side is characterized by comprising the following steps of:

acquiring an original design picture of a vehicle function, disassembling the original design picture into drawing elements, and determining drawing information of each drawing element in a reference coordinate system;

processing drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule to obtain picture rule data corresponding to each original design picture;

the picture rule data are issued to a client so that the client analyzes the picture rule data and performs coordinate conversion on drawing information of each drawing element in the picture rule data;

And based on the drawing information after coordinate conversion, calling corresponding function functions to draw the drawing elements in sequence by utilizing the element drawing sequence defined in the picture rule data so as to generate the vehicle function picture corresponding to the original design picture.

2. The method according to claim 1, wherein the processing drawing information belonging to the same original design picture into picture rule data using a predetermined data organization rule includes:

and processing drawing information of the same original design picture into picture rule data by adopting a preset data organization rule at the server, and storing the picture rule data at the server, wherein the picture rule data comprises drawing information of the drawing elements and element drawing sequences.

3. The method according to claim 1, wherein the coordinate converting of the drawing information of each drawing element in the picture rule data includes:

when the size proportion of the original design picture is consistent with that of the vehicle function picture to be drawn, determining a drawing proportion by utilizing the ratio between the size of the vehicle function picture and the size of the original design picture, and converting coordinates in drawing information by utilizing the drawing proportion;

When the size ratio of the original design picture to the vehicle function picture to be drawn is inconsistent, the width ratio and the height ratio between the vehicle function picture and the original design picture are calculated respectively, the smaller ratio of the width ratio and the height ratio is used as the drawing ratio, and the coordinates in the drawing information are converted by using the drawing ratio.

4. The method according to claim 1, wherein the calling the corresponding function to sequentially draw the drawing elements includes:

calling an initialization function of a preset graphic renderer class to generate a graphic renderer instance, wherein parameters of the initialization function comprise the size of an original design picture and drawing configuration information;

and calling a graph drawing method in the graph renderer example, wherein parameters of the graph drawing method are drawing code functions, and the drawing code functions are utilized to call the drawing information after coordinate conversion so as to draw the drawing elements in sequence according to the element drawing sequence, so that a vehicle function picture is obtained.

5. The method according to claim 1, wherein the calling the corresponding function to sequentially draw the drawing elements includes:

And calling and acquiring a current graphic context function to acquire a current drawing context, drawing an image in the current drawing context by utilizing a pre-generated graphic renderer instance, and calling a drawing context object after drawing is completed so as to synthesize an image by utilizing the drawn content in the current drawing context to obtain a vehicle function picture.

6. The method of claim 1, wherein after generating the vehicle function picture corresponding to the original design picture, the method further comprises:

setting a rendering mode of the vehicle function picture by using parameters to obtain a template picture corresponding to the vehicle function picture, assigning the template picture to a preset control, and setting the coloring attribute of the control to be the color corresponding to the variant picture when the color of the vehicle function picture needs to be changed to generate the variant picture, wherein the color information of the picture is ignored in the template picture, and the transparency information of the picture is reserved.

7. The method of claim 6, wherein after generating the vehicle function picture corresponding to the original design picture, the method further comprises:

And storing the vehicle function picture and the variant picture into a memory, requesting a server to acquire picture rule data when a client calls the vehicle function picture and the variant picture, comparing the picture rule data acquired from the server with the picture rule data stored by the client, judging whether the picture rule data corresponding to the vehicle function picture and the variant picture are updated, continuously using the picture rule data stored by the client when judging that the vehicle function picture and the variant picture are not updated, and cleaning the vehicle function picture and the variant picture in the memory and redrawing the vehicle function picture when judging that the vehicle function picture is updated.

8. The method according to claim 1, wherein the method further comprises:

counting the use times of each vehicle function picture and the change times of picture rule data of each vehicle function picture, grouping the vehicle function pictures by utilizing a preset use times threshold and a preset change times threshold to obtain a first vehicle function picture, a second vehicle function picture, a third vehicle function picture and a fourth vehicle function picture, and respectively processing the vehicle function pictures in different groups by utilizing a preset strategy.

9. The method of claim 8, wherein the processing the different groups of vehicle function pictures with the predetermined policy respectively comprises:

for the first vehicle function picture, storing the first vehicle function picture after first drawing in a memory or a sandbox, and acquiring picture rule data of the first vehicle function picture from a server when an application program is started or used for the first time;

temporarily drawing the second vehicle function picture when the second vehicle function picture is used, and acquiring picture rule data of the second vehicle function picture from a server when an application program is started or used for the first time;

for the third vehicle function picture, storing the first drawn third vehicle function picture in a memory or a sandbox, and acquiring picture rule data of the third vehicle function picture from a server when the third vehicle function picture is used each time;

and temporarily drawing the fourth vehicle function picture when the fourth vehicle function picture is used, and acquiring picture rule data of the fourth vehicle function picture from a server every time the fourth vehicle function picture is used.

10. A client-based vehicle function picture generation device, characterized by comprising:

the disassembly module is configured to acquire an original design picture of the vehicle function, disassemble the original design picture into drawing elements and determine drawing information of each drawing element in a reference coordinate system;

the processing module is configured to process drawing information belonging to the same original design picture into picture rule data by utilizing a preset data organization rule to obtain picture rule data corresponding to each original design picture;

the analysis module is configured to send the picture rule data to a client so that the client analyzes the picture rule data and performs coordinate conversion on drawing information of each drawing element in the picture rule data;

and the drawing module is configured to call corresponding function functions to draw the drawing elements in sequence by utilizing the element drawing sequence defined in the picture rule data based on the drawing information after coordinate conversion so as to generate a vehicle function picture corresponding to the original design picture.

11. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of any one of claims 1 to 9 when the program is executed.

12. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1 to 9.