基于客户端的车辆功能图片生成方法、装置及存储介质与流程

1.本技术涉及应用程序开发技术领域，尤其涉及一种基于客户端的车辆功能图片生成方法、装置及存储介质。


背景技术：

2.在汽车app的开发中，存在着远程车辆控制的需求，这些控制功能需要通过操作符合各种状态的图标按钮来实现，例如：车锁，后备箱，前舱盖等。然而，针对每种功能的按钮，因为存在不同的状态（如关闭、已打开、进行中和不可用），需要预先生成并存储多个状态对应的颜色变体图片，这对存储空间和带宽均造成了较大的负担。
3.首先，若客户端预存所有可能状态的功能图片，一方面会导致存储空间的浪费，因为并非所有用户都会使用到所有的功能，也不一定会遇到所有的状态；另一方面，由于未来可能增加的新功能和状态无法预知，每当添加新功能或状态时，客户端需要重新发版，增加了维护的复杂性。其次，如果选择通过服务器接口下载最新功能图片，由于每个功能至少对应多种状态，故需要下载大量的图片，从而占用大量的网络带宽。若实行按需下载策略以减小带宽压力，又可能在需要图片时出现等待，若网络状况不佳，可能导致图片下载失败或者下载速度缓慢，严重影响用户体验。因此，现有的车辆功能图片生成方法存在存储空间利用低效，内存占用大，造成系统性能开销浪费，无法按需绘制，图像绘制的灵活性降低的问题。


技术实现要素：

4.有鉴于此，本技术实施例提供了一种基于客户端的车辆功能图片生成方法、装置及存储介质，以解决现有技术存在的存储空间利用低效，内存占用大，造成系统性能开销浪费，无法按需绘制，图像绘制的灵活性降低的问题。
5.本技术实施例的第一方面，提供了一种基于客户端的车辆功能图片生成方法，包括：获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个绘制元素在基准坐标系中的绘制信息；利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据，得到每个原始设计图片对应的图片规则数据；将图片规则数据下发给客户端，以使客户端对图片规则数据进行解析，并对图片规则数据中的各个绘制元素的绘制信息进行坐标转换；基于坐标转换后的绘制信息，利用图片规则数据中定义的元素绘制顺序，调用相应的功能函数对绘制元素依次进行绘制，以便生成原始设计图片对应的车辆功能图片。
6.本技术实施例的第二方面，提供了一种基于客户端的车辆功能图片生成装置，包括：拆解模块，被配置为获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个绘制元素在基准坐标系中的绘制信息；处理模块，被配置为利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据，得到每个原始设计图片对应的图片规则数据；解析模块，被配置为将图片规则数据下发给客户端，以使客户端对图片规则数据进行解析，并对图片规则数据中的各个绘制元素的绘制信息进行坐标转换；绘
制模块，被配置为基于坐标转换后的绘制信息，利用图片规则数据中定义的元素绘制顺序，调用相应的功能函数对绘制元素依次进行绘制，以便生成原始设计图片对应的车辆功能图片。
7.本技术实施例的第三方面，提供了一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现上述方法的步骤。
8.本技术实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。
9.本技术实施例采用的上述至少一个技术方案能够达到以下有益效果：通过获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个绘制元素在基准坐标系中的绘制信息；利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据，得到每个原始设计图片对应的图片规则数据；将图片规则数据下发给客户端，以使客户端对图片规则数据进行解析，并对图片规则数据中的各个绘制元素的绘制信息进行坐标转换；基于坐标转换后的绘制信息，利用图片规则数据中定义的元素绘制顺序，调用相应的功能函数对绘制元素依次进行绘制，以便生成原始设计图片对应的车辆功能图片。本技术可根据所需的实际图片尺寸直接进行绘制并生成图片，能够节约用户的带宽，减少内存占用，从而节约系统的性能开销，并且提升了车辆功能图片的生成效率，可以对图片进行按需绘制，提升图片绘制的灵活性。
附图说明
10.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
11.图1是本技术实施例提供的基于客户端的车辆功能图片生成方法的流程示意图；图2是本技术实施例在实际场景中的电池图标的原始设计图；图3是本技术实施例在实际场景中的图片规则数据的结构示意图；图4是本技术实施例在第一种情形下的图片规则数据的坐标转换示意图；图5是本技术实施例在第二种情形下的图片规则数据的坐标转换示意图；图6是本技术实施例提供的基于客户端的车辆功能图片生成装置的结构示意图；图7是本技术实施例提供的电子设备的结构示意图。
具体实施方式
12.以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
13.在当前的汽车应用程序（app）开发中，通常需要为车辆提供远程控制功能，这些功能包括但不限于：车锁、后备箱、前舱盖、车窗、寻车、充电口、车窗通风、天窗、天窗通风、遮阳帘、空调、电池等操作。在应用程序上，每种车辆控制功能都需要对应的操作按钮供用户
进行操作，这些按钮上通常都会配有相应的图像标识。而且，这些图像标识并非复杂的图形，其形状和颜色具有简单性，可以被拆分为常见的ios系统能提供的基础绘制功能，比如绘制线条、弧线、形状、颜色、阴影、透明度、文字等。
14.对于每种车控功能，在app上需要对其提供对应的操作按钮供用户操作，按钮上有对应的图片；并且，由于远程控制的实现需要一定的时间过程，因此每个按钮都可能有多种状态，例如：关闭（黑色）、已打开（金色）、进行中（渐变色）和不可用（灰色）。这意味着每种车辆控制功能都可能有多种颜色变体的图像来表示不同的状态。比如：用户在app上点击后备箱按钮，让汽车打开后备箱，但是从用户点击这个时间点，到后备箱真正打开这个时间点，中间存在一定的时间差，因为命令要从客户端通过端口发送给服务器，服务器再和汽车的中控tbox进行通信，tbox再操作汽车完成实际的指令。另外，为了表示车辆功能的不同状态，车辆控制功能的操作按钮通常也会随着状态的变化而改变颜色，并且当汽车需要补充新的功能时，比如方向盘加热功能，则需要重新生成方向盘的图片，并生成对应n种颜色的变体图像。
15.在现有技术中，目前常见的车辆控制功能图片生成方法主要包括以下两种：第一种实现方案：客户端预存一些功能的图片，但是如果尚未添加将来可能会添加的功能的话，这些功能在发版时是未知的，则客户端如果没有预存这些功能对应的图片，客户端就需要重新发版本。或者一个现有功能后期需要增加一种状态，则也要对原有图片加一种颜色变体图，也需要重新发版。而且，这种预存图片的方式，会造成存储空间的浪费，因为用户不一定会进入某个车控功能对应的页面，那么某套存储的图片其实没有用武之地。并且，当某个车控功能不再使用时，图片也还存在安装包内，造成存储空间的浪费。
16.第二种实现方案：通过服务器接口下载最新功能图片，这种方案在功能很多时，需要下载大量的图片（因为一个功能就有至少n张图片），占用带宽。如果实施按需下载，可以减小带宽，但又会在真正需要图片时进行一定的等待，如果网络不好，那就下不到图片或者下得很慢，影响用户体验。此外，由于ios设备的种类繁多且每年都有新的机型推出，服务器端提供的图片尺寸无法完全适配所有的屏幕。在展示前，图片需要经过缩放、裁剪、拉伸等操作，这些操作可能导致图片展示效果的下降。
17.综上，现有的技术方案存在存储空间利用低效，带宽及内存占用大，造成系统性能开销浪费，新功能添加困难，无法按需绘制，图像绘制的灵活性低，以及设备适配等技术问题，需要寻求新的解决方案以改进。
18.有鉴于此，本技术实施例提供了一种基于客户端的车辆功能图片生成方法。本技术通过获取车辆功能的原始设计图片，并将其拆解成绘制元素，并确定每个绘制元素在基准坐标系中的绘制信息。利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据，并将这些图片规则数据存储在服务端。将图片规则数据下发给客户端，客户端根据这些数据对原始设计图片中的各个绘制元素的绘制信息进行坐标转换，并按照元素绘制顺序依次进行绘制，以生成原始设计图片对应的车辆功能图片。在生成原始设计图片对应的车辆功能图片之后，还可以通过设置参数来改变车辆功能图片的渲染模式，得到模板图片，并可以根据需要生成不同颜色的变体图片。将生成的车辆功能图片和变体图片存储到内存中，当需要调用这些图片时，会先请求服务端获取图片规则数据，并与客户端存储的图片规则数据进行比对，进行判断，如果车辆功能图片或变体图片的图片规则数据
没有发生更新，那么将继续使用客户端存储的图片规则数据；如果发生了更新，那么将清理内存中的相关图片，并根据新的图片规则数据重新绘制车辆功能图片。
19.本技术基于客户端的车辆功能图片生成方法，利用图形绘制代码和规则数据，减少了对服务器带宽的需求，提高了系统的效率和性能，提升了用户体验，同时也更好地适应了各种设备和屏幕尺寸。此外，本技术技术方案也使得添加新的车辆功能或者更新现有功能的状态变得更为方便，无需重新发布版本，大大提升了应用程序的维护效率和用户体验。
20.下面结合附图以及具体实施例对本技术技术方案的内容进行详细描述。
21.图1是本技术实施例提供的基于客户端的车辆功能图片生成方法的流程示意图。图1的基于客户端的车辆功能图片生成方法可以由客户端与服务端组成的系统来执行。如图1所示，该基于客户端的车辆功能图片生成方法具体可以包括：s101，获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个绘制元素在基准坐标系中的绘制信息；s102，利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据，得到每个原始设计图片对应的图片规则数据；s103，将图片规则数据下发给客户端，以使客户端对图片规则数据进行解析，并对图片规则数据中的各个绘制元素的绘制信息进行坐标转换；s104，基于坐标转换后的绘制信息，利用图片规则数据中定义的元素绘制顺序，调用相应的功能函数对绘制元素依次进行绘制，以便生成原始设计图片对应的车辆功能图片。
22.首先，将美工根据车辆功能设计的原始设计图片用工具或者人工的方式，拆解成机器可以绘制的元素，例如：直线，点，形状，曲线，文字，线条颜色，填充颜色，渐变颜色，阴影等。本技术以下实施例中将这些元素统称为“绘制元素”，其中单个元素也可以泛称为“元素”。在一个示例中，如图2所示，图2是本技术实施例在实际场景中的电池图标的原始设计图，在实际应用中，可以将图2所示的车辆充电功能的原始设计图片（比如电池图标）拆解成以下绘制元素：一条短的灰色直线（代表电池正极），一条灰色曲线（代表电池边框），以及一个带颜色的矩形块（代表电量）。需要说明的是，图2采用黑色矩形块来代表电量，当然，也可以采用其他颜色来代表电量，比如绿色等。原始设计图片中线条的类型、长度、宽度、颜色、阴影等均可根据实际需求设计，本技术实施例对此不作限制。
23.本技术实施例以客户端常用的绘制坐标系作为基准坐标系，求出每一张原始设计图片的所有绘制元素所需的最小信息。android和ios客户端常用的绘制坐标系是以控件左上角为原点，x在水平方向上向右延伸为正数，y在垂直方向上向下延伸为正数（即以控件的左上角为原点，x轴向右，y轴向下）。
24.在这里，每个绘制元素在基准坐标系中的绘制信息表示绘制一个元素所需的最少信息。例如，以车辆充电功能对应的电池图标为例，这个图标的生成可能需要以下绘制信息：灰色直线：需要起点和终点的坐标，以及线宽。
25.灰色曲线：需要矩形四个角上点的坐标，以及矩形圆角的半径，还有线宽。
26.绿色矩形块：需要矩形的四个角上点的坐标。
27.灰色：需要颜色值，例如rgba或hsb等。
28.绿色渐变块：需要渐变开始色值，渐变结束色值，渲染的开始点和结束点，渐变开始的点位置和渐变结束色的点位置，以及渐变的方式（是线性渐变还是圆心渐变等）。
29.图片本身的宽和高。
30.因此，电池图标共需要以上6个绘制元素，绘制元素的坐标系原点应该是美工给出的原始设计图片的左上角，以此确定每个元素的坐标点。本技术实施例通过将原始设计图拆解为绘制元素，并记录下这些元素在基准坐标系中的位置和其他相关信息，来为图标的生成提供数据。这种方式可以减少存储空间的使用，避免了在增加新功能或改变功能状态时需要更新应用，也不需要下载大量图片，从而提高了应用的效率和用户体验。
31.在一些实施例中，利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据，包括：在服务端采用预定的数据组织规则，将同一原始设计图片的绘制信息处理成图片规则数据，并将图片规则数据存储在服务端，其中，图片规则数据中包含绘制元素的绘制信息以及元素绘制顺序。
32.具体地，在服务器端采用预定的数据组织规则（也称为数据组装规则），将同一原始设计图片的绘制信息组装成一种数据结构（即图片规则数据）。这些图片规则数据定义了各种绘制元素的绘制规则，例如电池、车锁、天窗等，然后，服务端将这些图片规则数据存储在服务器上。
33.进一步地，这些图片规则数据可以通过各种形式从服务端下发到客户端，例如，以http请求的回应数据，文件，字节流数组等形式传输。而图片规则数据的内容的组成方式也可以采用以下组成方式：如json，xml等，当然也可以采用自定义的自然语言描述，纯数字组合等方式。
34.在客户端，需要根据服务端下发的数据和组织规则，解析出这些数据，并根据图片规则数据进行相应的图片绘制。需要说明的是，无论图片规则数据的形式是易于阅读的json、xml，还是难以直接阅读的字节流，只要客户端能够根据规则解析出数据，就可以进行图片的绘制。
35.下面结合具体实施例对数据组织规则及图片规则数据的相关内容进行详细介绍，具体可以包括以下内容：在一个示例中，电池的数据可以是一个json字符串，其内容为自定义的规则，最外层是所有图片的集合（如电池、车锁、天窗等），第二层是每个图片（电池），第三层是每个图片的绘制元素，如直线、曲线等，json是用键值对形式来描述数据的。服务器可以直接把这个json字符串放在客户端的http请求的返回数据中，也可以放在一个文件中，让客户端下载。
36.{"电池": "{"直线": {"x":"20","y":"0"}" 曲线": {"左上角x":"0","左上角y":"0","右上角x":"40","右上角y":"0",
……
}
……
}"车锁": "{"曲线": {
……
}
……
}
……
}在另一个示例中，如图3所示，图3是本技术实施例在实际场景中的图片规则数据的结构示意图，该图片规则数据具体可以包括以下内容：服务端可以通过tcp协议给客户端发送一个字节流数据（每个字节byte是0-127的整数），字节流的第1-4个字节代表这个数据的总长度；第5个字节代表有多少图片；第6-10个字节代表第一个图片的数据起始位置，第11-15个字节代表第一个图片的数据结束位置（即第一个图片的数据为从多少位到多少位）；后面的字节依次代表第2个图片的数据为从多少位到多少位；在每个图片的数据中，数据的第1-5个字节代表直线数据从多少位到多少位，第6-10字节代表曲线数据从多少位到多少位，第11-15个字节代表颜色数据从多少位到多少位。
37.在另一个示例中，通过设计一个数组，数组的每个元素对应一种车辆功能图片。每个数组元素也可以认为是一个复杂的数据结构，具体可以表示为以下键值对：键1：功能是否有变体；键2：变体；变体也是一个数组，每个数组元素对应着一种变体数据，变体数据是键值对，键为该变体的颜色；键3：绘制元素绘制元素也是一个数组，每个数组元素对应着一种具体的绘制，是键值对；键a：曲线曲线也是一个复杂的数据结构，包括曲线的控制点，它不止一个所以是个数组，包括曲线的线宽，曲线的颜色等等；键x：曲线的控制点数组；键y：曲线的线宽；键z：曲线的颜色；
……
键b：线线也是一个复杂的数据结构，包括曲线的起点，途径点，终点，它不止一个所以是个数组，包括线的线宽，线的颜色，线末端的样式等等；键x：线的点数组；键y：线的线宽；
键z：线的颜色；键r：线的末端样式；
……
根据本技术实施例提供的技术方案，本技术通过将车辆功能图片的生成转移到客户端，无需预存大量的功能图片，既节省了存储空间，也方便了新功能的添加和状态变更的处理，免除了因新功能或新状态的增加而需要重新发布版本的繁琐步骤。另外，本技术能够根据图片规则数据动态的生成各种设计元素的图片，而不需要在客户端预先存储所有可能的图片，这不仅节省了存储空间，也提高了图片生成的灵活性。同时，由于图片规则数据存储在服务端，可以方便的进行修改和更新，而无需对客户端进行升级。
38.在一些实施例中，对图片规则数据中的各个绘制元素的绘制信息进行坐标转换，包括：当原始设计图片与需要绘制的车辆功能图片的尺寸比例一致时，利用车辆功能图片的尺寸与原始设计图片的尺寸之间的比值确定绘制比例，利用绘制比例将绘制信息中的坐标进行转换；当原始设计图片与需要绘制的车辆功能图片的尺寸比例不一致时，分别计算车辆功能图片与原始设计图片之间的宽度比和高度比，将宽度比和高度比中比值较小的作为绘制比例，利用绘制比例将绘制信息中的坐标进行转换。
39.具体地，本技术实施例通过将生成的图片规则数据下发给客户端，以使客户端对图片规则数据进行解析，并且利用解析后的图片规则数据进行图片绘制。首先，本技术实施例利用服务器将图片规则数据下发给服务端可以采用以下两种方式中的任意一种：第一种下发方式：如果图片规则数据的总条数不多，服务器可将所有原始设计图片的规则数据放在一起一次下发。客户端在程序启动之初，请求服务器接口，将图片规则数据下载后存储在内存中。当用户进入某个页面时，客户端根据页面上所用到的图片，再访问图片规则数据，取出这几张图片对应的规则数据，从而进行图片的绘制。
40.第二种下发方式：如果图片规则数据的总条数多，数据量比较巨大，可以对规则数据进行拆分，客户端根据需要，一次只请求服务器的一条或几条规则数据。因此，客户端的请求中需要携带参数，参数用于告知服务器获取哪一条或几条规则数据。
41.可选地，由于服务器与客户端之间的通信会受到网络状态的影响，所以为了避免无网、网络太慢的情况导致数据获取失败，客户端本地也可以维持一份服务器数据的缓存备份，例如：在客户端预制包时，保存一份服务器当时最新的配置文件数据在客户端的包中。在客户端获得服务器最新的数据后，在沙盒中保存并一份数据，以便于客户端在无网、网络太慢的情况下使用。并且每次得到服务器最新数据后都对它进行更新。
42.进一步地，客户端在获取原始设计图片对应的图片规则数据之后，将对图片规则数据中各个绘制元素的绘制信息进行坐标转换，即对图片规则数据中的线条和点的位置坐标进行转换。图片规则数据中有图片本身的原始宽和高，而实际页面展示时控件也有自己的宽和高，通常要求展示（绘制）的图片宽和高是由控件来决定的，由于它和图片本身的宽和高不一定相等，所以需要计算绘制比例，并用这个比例去乘以规则数据中坐标点值，得到绘制时需要的坐标点值。本技术实施例提供了两种不同情形下的坐标转换方法，下面结合具体实施例对这两种情形下的坐标转换方法进行详细说明，具体可以包括以下内容：如图4所示，图4是本技术实施例在第一种情形下的图片规则数据的坐标转换示意图。在第一种情形下，当原始设计图片与需要绘制的车辆功能图片的尺寸比例一致时，在这
种情形下，虽然两张图片的宽和高不一样，但是可以等比例缩放，因此，可以使用需要绘制的车辆功能图片的尺寸（即绘制尺寸）与原始设计图片的尺寸（即原始尺寸）之间的比值来确定绘制比例，即绘制比例=需要绘制的车辆功能图片的宽度/原始设计图片的宽度；同理，用高度计算也可以，因为比例是一样的。此时，实际绘制中使用的坐标点值为：x轴的值=图片规则数据中的x值
×
绘制比例，y轴的值=图片规则数据中的y值
×
比例，也就是说，实际绘制中使用的宽和高为：某条线的宽=图片规则数据中的宽度
×
绘制比例，某条线的高=图片规则数据中的高度
×
绘制比例，从而实现对图片规则数据中的坐标值的转换。
43.如图5所示，图5是本技术实施例在第二种情形下的图片规则数据的坐标转换示意图。在第二种情形下，当原始设计图片与需要绘制的车辆功能图片的尺寸比例不一致时，在这种情形下，虽然原始设计图片的宽和高与需要绘制的车辆功能图片的宽和高之间的比例不一致，但是通常情况下，要求图片能全部展示出来，并且居中显示，因此绘制比例应该选取宽和高比例中的较小值。例如：宽比例=绘制宽度/原始宽度，高比例=绘制高度/原始高度，从宽比例和高比例中选取较小值作为绘制比例。于是，实际绘制中用到的某个坐标点值为：x轴上的值=图片规则数据中的x值
×
绘制比例，y轴上的值=图片规则数据中的y值
×
绘制比例；因此，实际绘制中用到的宽和高为：某条线的宽=图片规则数据中的宽度
×
绘制比例，某条线的高=图片规则数据中的高度
×
绘制比例，从而实现对图片规则数据中的坐标值的转换。
44.需要说明的是，利用绘制比例对图片规则数据中的尺寸进行缩放之后，由于居中显示的缘故，控件需要的图片的坐标原点和图片原本的坐标原点并不一致，因此，还需要进行坐标原点的对齐调整才可以。但是ios的控件支持将图片进行居中调整，控件也即uiview的类实例或其子类实例，uiview类有属性conentmode，它的值可以设置图片是居中还是居上，还是等比缩放等等；因此，本技术实施例中，为了避免计算，可以不用进行坐标原点的对齐计算，而是将图片直接绘制出来，再对控件进行conentmode的调整即可。在实际应用中，由于计算并不复杂，也可以先进行坐标原点的调整，再直接绘制出图片，直接赋值给控件，就不用设置控件的conentmode属性了。
45.在一个示例中，坐标原点的调整计算公式如下：所取比例的轴（比如y轴）不调整，未取比例的轴（比如x轴）要加上差值；差值=绘制所需的长度-图片规则数据中的长度，并且取绝对值，于是，实际绘制中用到的某个坐标点值为：x轴上的值=x轴现在计算出的值+差值，y轴上的值不变。
46.根据本技术实施例提供的技术方案，本技术提高设备适配性：图片规则数据中包含的绘制信息进行坐标转换，使得生成的车辆功能图片能够适应各种尺寸的屏幕，无需对图片进行复杂的缩放、裁剪、拉伸等操作，保证了图片的展示效果。
47.本技术实施例在将绘制信息中的坐标进行转换之后，程序会读取服务器发来的规则数据，获取图片的总数，然后遍历每一个图片数据。每个图片数据中包含了绘制这个图片所需的所有元素信息，如线条、点、颜色、阴影等，还有图片的变体个数和变体对应的颜色。程序会根据服务器指定的绘制先后顺序，依次调用对应的功能函数来绘制这些元素。例如，如果遇到线条，就调用绘制线条的函数；如果遇到点，就调用绘制点的函数，以此类推。
48.在一个示例中，在ios系统中，提供了两种主要的绘制图片的方法。第一种方法是使用uigraphicsimagerenderer类进行绘制。首先，需要生成一个
uigraphicsimagerenderer的实例，设定它的尺寸和格式。然后，调用这个实例的image()方法进行绘制。这个方法的参数是一个函数，函数中包含了实际的绘制代码。最后，image()方法的返回值就是绘制好的图片。第二种方法是直接调用绘制上下文进行绘制，最后对绘制上下文对象调用igraphicsgetimagefromcurrentimagecontext()方法，这个方法的返回值就是所需要的图片。
49.需要说明的是，这两种图片绘制实现方法没有绝对的优劣之分，选择哪种方法主要取决于具体的需求和应用场景。在实际的绘制过程中，可以选择使用core graphics库提供的绘制工具，也可以使用uikit封装的uibezierpath类。uibezierpath类提供了绘制点，线，形状，颜色等一系列方法，本质上它也是调用了core graphics库的工具进行绘制的，并且这两种工具可以混用。
50.在一些实施例中，调用相应的功能函数对绘制元素依次进行绘制，包括：对预设的图形渲染器类的初始化函数进行调用，以生成一个图形渲染器实例，其中，初始化函数的参数包括原始设计图片的尺寸以及绘图配置信息；对图形渲染器实例中的图形绘制方法进行调用，图形绘制方法的参数为绘制代码函数，利用绘制代码函数对坐标转换后的绘制信息进行调用，以便按照元素绘制顺序依次对绘制元素进行绘制，得到车辆功能图片。
51.具体地，在第一种图片绘制实现方法中，将使用uigraphicsimagerenderer这个类来生成需要的图片。以下是对第一种图片绘制实现方法的详细解释：首先，需要创建一个uigraphicsimagerenderer实例（即图形渲染器实例）。通过调用其初始化函数.init(size:, format:)来创建这个实例。此函数接收两个参数：第一个参数是一个尺寸对象（即原始设计图片的尺寸），它表示需要绘制的图片的宽度和高度；第二个参数是一个uigraphicsimagerendererformat实例，它代表了绘图配置信息。这个绘图配置信息中包括一些参数，比如图片的透明度，设备的缩放比例和色域等。在大多数情况下，可以直接使用uigraphicsimagerendererformat的默认实例，即uigraphicsimagerendererformat.default()。
52.可选地，下面以电池图像的绘制过程为例，对使用第一种图片绘制实现方法进行图片绘制的完整实现过程进行详细介绍，具体可以包括以下内容：（1）绘制边框（这里以uikit工具为例）制作边框路径：调用uibezierpath类的初始化函数public convenienceinit(roundedrect rect: cgrect, cornerradius: cgfloat)生成一个uibezierpath实例，它代表生成一个带有圆角的矩形框，第1个参数传入矩形4个点的坐标构成的cgrect类实例，第二个参数是圆角的半径。
53.设置边框线宽：设置uibezierpath类实例的linewidth属性为所需线宽。
54.设置边框颜色：调用uicolor类的初始化方法 public init(red: cgfloat,green: cgfloat, blue: cgfloat, alpha: cgfloat)生成一个uicolor实例，参数传入对应的rgba值。
55.绘制边框曲线：调用uibezierpath类实例的stroke方法，即完成了边框的绘制。
56.（2）绘制顶部直线（这里以core graphics库工具为例）调用uigraphicsgetcurrentcontext()函数，其返回值是当前绘制上下文；这里也可以调用image(_:)方法的函数的参数（就是上面提到的
uigraphicsimagerenderercontext类型类型）的uigraphicsgetcurrentcontext属性，得到这个绘制上下文。
57.制作直线路径：对绘制上下文调用public func move(to point:cgpoint)方法，其参数传入直线的起始点坐标。
58.对绘制上下文调用public func addline(topoint: cgpoint)方法，其参数传入直线的结束点坐标。
59.设置线宽：对绘制上下文调用public func setlinewidth(_width: cgfloat)方法，设置线宽。
60.设置颜色：对绘制上下文调用public funcsetstrokecolor(_ color: cgcolor)方法，设置线条颜色。
61.绘制直线：对绘制上下文调用stroke(_:)方法，即完成了直线的绘制。
62.（3）绘制渐变区域渐变区域的绘制需要两步：裁剪和绘制。
63.首先，由于ios中渐变区域无法直接指定绘制的区域，因此需要先进行裁剪。在实际应用中，可以创建一个矩形路径，或者一个线宽为渐变区域宽度的直线，然后将这个路径转换成一个矩形区域。然后，调用绘制上下文的clip方法来裁剪这个区域。裁剪的实现过程如下：获取绘制规则中的渐变区域坐标和宽高，可以和上述（1）中类似的步骤制作一个矩形区域，也可以用上述（2）中类似的步骤制作一个线宽为渐变区域宽度的直线，然后调用绘制上下文的replacepathwithstrokedpath()方法把这个“粗粗”的直线转成一个矩形区域。调用绘制上下文的的clip（）方法即裁剪出了这块矩形区域。
64.然后，再绘制渐变区域，通过创建一个渐变对象，它定义了渐变的颜色空间（比如rgba，灰度图或cmyk），渐变的颜色数组，以及颜色的变化坐标数组。然后，根据规则数据的渐变方式，选择调用drawlineargradient方法（线性渐变）或drawradialgradient方法（圆心渐变）来绘制渐变区域。最后，调用绘制上下文的resetclip方法来恢复裁剪形状，这样便完成了电池图像的绘制。渐变区域的绘制过程如下：调用cggradient类的初始化方法public init！(colorsspace space:cgcolorspace！,colors: cfarray, locations: unsafepointer《cgfloat》！)得到一个渐变类，第一个参数传入颜色空间（即颜色的表现方式），如果是rbga就传入cgcolorspacecreatedevicergb（），如果是其他方式就传入对应的配置，如灰度图cgcolorspacecreatedevicegray()，cmyk：cgcolorspacecreatedevicecmyk（）等等；第二个参数是渐变色数组，第三个参数是渐变色的变化坐标数组读取规则数据的渐变方式，决定是调用public funcdrawlineargradient(_ gradient: cggradient, start startpoint: cgpoint, endendpoint: cgpoint, options: cggradientdrawingoptions)方法【线性渐变】还是public funcdrawradialgradient(_ gradient: cggradient, startcenter: cgpoint, startradius:cgfloat, endcenter: cgpoint, endradius: cgfloat, options:cggradientdrawingoptions)方法【圆心渐变】。完成绘制后，调用绘制上下文的的resetclip（）方法，恢复裁剪形状。
65.在一些实施例中，调用相应的功能函数对绘制元素依次进行绘制，包括：调用获取
当前图形上下文函数来获取当前绘制上下文，利用预先生成的图形渲染器实例在当前绘制上下文中进行图像绘制，完成绘制后，调用绘制上下文对象，以便利用当前绘制上下文中所绘制的内容合成图像，得到车辆功能图片。
66.具体地，在第二种图片绘制实现方法中，将直接调用绘制上下文进行绘制，最终对绘制上下文对象调用igraphicsgetimagefromcurrentimagecontext()方法，该方法的返回值就是所需绘制的图片。以下是对第二种图片绘制实现方法的详细解释：（1）调用uigraphicsgetcurrentcontext()函数：这是开始任何绘制工作的起点，uigraphicsgetcurrentcontext()是一个函数，它会返回当前的绘制上下文。在ios绘图中，图形上下文（graphics context）可以理解为是一块虚拟的画布，所有的绘图操作都在这个画布上完成。当前图形上下文通常指的是当前绘图操作的目标上下文，也就是当前绘图操作要在哪块画布上完成。函数uigraphicsgetcurrentcontext()就是用来获取这个当前图形上下文的，以便后续可以在上面进行绘图操作。
67.（2）开始绘制：在这个阶段，可以使用与在uigraphicsimagerenderer实例中相同的方法来绘制图形。这包括使用uikit库提供的工具（如uibezierpath等），或者使用core graphics库提供的工具。这两套工具都有各自的优点，可以根据需要进行选择和组合。例如，uibezierpath易于使用，可处理各种形状，而core graphics则提供了更多低级的控制（比如渐变）。
68.（3）完成绘制后，对绘制上下文对象调用igraphicsgetimagefromcurrentimagecontext()方法：完成绘制后，需要从当前的绘制上下文中获取图像。igraphicsgetimagefromcurrentimagecontext()是一个函数，它会返回当前上下文中的图像。这意味着它会将上下文中所绘制的所有内容捕获为一个uiimage对象，即获取所绘制的图形。
69.根据本技术实施例提供的技术方案，本技术利用图片规则数据来生成图片，相比于直接下载大量的图片，减小了网络带宽的压力。同时，根据服务端的图片规则数据和客户端存储的图片规则数据进行比对，可以在图片规则数据未发生更新时，继续使用客户端存储的图片规则数据，避免了不必要的数据传输。
70.在一些实施例中，在生成原始设计图片对应的车辆功能图片之后，该方法还包括：利用参数对车辆功能图片的渲染模式进行设置，得到车辆功能图片对应的模板图片，将模板图片赋值给预设的控件，当需要改变车辆功能图片的颜色以生成变体图片时，将控件的着色属性设置为变体图片对应的颜色，其中，在模板图片中忽略图片的颜色信息，保留图片的透明度信息。
71.具体地，本技术实施例还提供了车辆功能图片的变体图片的绘制方法，变体图片是指与车辆功能图片具有相同图片形状，但是不同颜色的图片。本技术实施例提供了两种生成变体图片的方法，第一种实现方法为使用模板图片来生成变体图片，下面结合具体实施例对利用模板图片生成变体图片的过程进行详细说明，具体可以包括以下内容：这种方式通常适用于全部图片颜色的替换，比如将一张图片中的全部颜色替换掉，而不是局部替换，但是局部替换也是可以实现的。ios中模板图片（template）的意思是：一张图片的颜色值会被忽略掉，只有其透明度（alpha）有用。如果把模板图片赋值给控件，则图片会利用控件的属性tintcolor来设置自己的颜色。
72.进一步地，对于前述实施例生成的车辆功能图片，由于它是uiimage类的实例。因
此，可以通过对其调用withrenderingmode(_:)方法，参数传入.alwaystemplate，便得到一张模板图片。可以直接将这张模板图片赋值给控件在客户端进行使用，需要变体的时候，设置控件的tintcolor属性为需要的颜色即可。
73.最后，对其调用withtintcolor(_:) 或者withtintcolor(_:renderingmode:)这两个个方法的第一个参数就是传入一个颜色，所以需要传入变体图片的颜色，就可以得到一个变体图片。withtintcolor(_:renderingmode:)多出来的参数也可以设置为.alwaystemplate。需要说明的是，如果有多个变体颜色，就调用多次这两个函数之一就能得到对应的多个变体图片。直接使用即可，无需对控件进行tintcolor属性设置。
74.进一步地，第二种实现方法为：在生成车辆功能图片时，渲染好变体颜色，多次调用前述实施例的步骤生成多个变体。这个方法适用于变体颜色不是整体说变就变的，而是有局部变化。当然，整体变化也可以用这个方法。在生成变体图片时，在染色这个步骤上，读取图片规则数据，得到图片规则数据规定的哪个局部需要变色，以及变体的颜色，直接进行渲染，并得到图片。由于一次只能得到一张图片，所以要重复调用得到多张变体图片。
75.例如，在一个示例中，由于变体颜色作为一个uicolor的类实例，它支持纯色、渐变色、以及由复杂图片组成的组合色，所以为了一张图片的不同区域呈现不同颜色，根据图片规则数据得到图片规则数据规定的哪个局部需要变色，以及变体的颜色，生成一个uicolor的类实例，作为前面的函数withtintcolor(_:) 或者withtintcolor(_:renderingmode:)的参数即可。
76.在一个示例中，在使用第一种实现方法时，对uigraphicsimagerenderer类实例多次调用image（_:）函数得到多张变体，每次调用只在渲染色彩的部分根据要求进行改动，其余逻辑保持不变即可。在使用第二种实现方法时，先绘制图片，对绘制上下文对象多次调用igraphicsgetimagefromcurrentimagecontext()方法得到多张变体，每次调用只在渲染色彩的部分根据要求进行改动，其余逻辑保持不变即可。
77.在一些实施例中，在生成原始设计图片对应的车辆功能图片之后，该方法还包括：将车辆功能图片以及变体图片存储到内存中，当客户端调用车辆功能图片以及变体图片时，请求服务端获取图片规则数据，将从服务端获取的图片规则数据与客户端存储的图片规则数据进行比对，判断车辆功能图片及变体图片对应的图片规则数据是否发生更新，当判断未发生更新时，继续使用客户端存储的图片规则数据，当判断发生更新时，对内存中的车辆功能图片以及变体图片进行清理，并重新绘制车辆功能图片。
78.具体地，在绘制车辆功能图片及其对应的变体图片之后，将车辆功能图片以及变体图片存储到内存中。一般情况下，在app的一次生命周期中（即程序被用户启动，到被系统或用户结束这一段时间中），在绘制完一次车辆功能图片及其变体图片后，应避免重复绘制，将已有的图片存储到内存中，下次用的时候直接读取使用。但是如果服务器在app生命周期中对图片规则数据进行了更新，此时就会出现问题，所以，需要在图片每次被使用时（通常为图片所在的控件或页面需要刷新显示时），请求服务器的图片规则数据和客户端原有的规则数据进行对比，判断该图片对应的规则数据是否有更新，如果没有就继续使用沙盒中的图，否则清理内存中的图片，重新绘制。
79.可选地，也可以把图片存储在沙盒中（沙盒就是客户端的本地持久化存储，只要不删除app，就可以一直在，当然，用户也可以管理这些存储空间）。如果存储在沙盒中，就涉及
到对图片缓存的清理动作，例如：服务器的规则数据已更新，原有的沙盒中的图片已不合法，应该删除。因此，要制定一套清理逻辑，这个逻辑可以复杂也可以简单，以下是一些可选的清理逻辑，可以使用以下清理逻辑中的一个或多个组合规则数据的清理方案，具体地：逻辑一：在程序每次退出时清理图片，这样很简单，但是和放在内存中没什么区别。
80.逻辑二：记录已存在沙盒中的图片数据，每次拿到服务器最新的规则数据后，和原有的规则数据进行对比，判断该图片对应的规则数据是否有更新，如果没有就继续使用沙盒中的图片，否则清理沙盒中的图片，重新绘制。
81.逻辑三：制定一个时间策略定期删除，例如每隔10s删除图片或者当图片存储容量达到预设体量后删除。
82.可选地，本技术还可以根据统计制定绘制和存储图片的规则，由于存储图片存在图片过期的风险，而每次在图片使用时去拉取服务器规则数据会受到网络状况的影响，如果页面刷新比较频繁，对服务器也会造成一定压力。所以要设计一种折中方案，希望可以既存储图片减少绘制次数，又可以减少请求服务器的次数。因此，在app使用过程中，统计app中每个车辆功能图片用到的次数，统计每个车辆功能图片的服务器规则数据变更的次数，当app使用一段时间后，就会得到一个统计表。然后制定如下规则。
83.在一些实施例中，该方法还包括：对每个车辆功能图片的使用次数以及每个车辆功能图片的图片规则数据的变更次数进行统计，利用预设的使用次数阈值以及变更次数阈值，对车辆功能图片进行分组，得到第一车辆功能图片、第二车辆功能图片、第三车辆功能图片以及第四车辆功能图片，利用预定的策略分别对不同分组的车辆功能图片进行处理。
84.具体地，在讲述规则前，需要补充的是，统计表可以是针对一个客户端设备进行的统计，所以这些统计数据不上传到服务器，仅针对本设备进行分析，分析出来的结果和该设备的用户习惯非常相关（比如该用户就不喜欢进入某些页面，所以那些页面对应的车辆功能的图片就用得少）。另外，统计表也可以是针对该app进行的统计，所以所有客户端的统计数据就要上传到服务器，由服务器进行大数据层面的统计分析，分析出来的结果和整体用户习惯相关。
85.进一步地，本技术实施例可以根据业务需求指定或者根据统计经验设置使用次数阈值以及变更次数阈值，并且利用使用次数阈值以及变更次数阈值将所述车辆功能图片划分到不同的分组下面，从而利用不同的策略对不同分组内的车辆功能图片进行处理。例如：统计app中每个车辆功能图片用到的次数，将使用次数超过使用次数阈值（比如30次）的车辆功能图片划分为第一使用次数图片，将使用次数低于使用次数阈值（比如30次）的车辆功能图片划分为第二使用次数图片；另外，统计每个车辆功能图片的服务器数据变更的次数，将变更次数超过变更次数阈值（比如3次）的车辆功能图片划分为第一变更次数图片，将变更次数低于变更次数阈值（比如3次）的车辆功能图片划分为第二变更次数图片。
86.在一些实施例中，利用预定的策略分别对不同分组的车辆功能图片进行处理，包括：对于第一车辆功能图片，将第一次绘制后的第一车辆功能图片存储在内存或沙盒中，并在应用程序启动或第一次使用时，从服务器获取第一车辆功能图片的图片规则数据；对于第二车辆功能图片，在使用时对第二车辆功能图片进行临时绘制，并在应用程序启动或第一次使用时，从服务器获取第二车辆功能图片的图片规则数据；对于第三车辆功能图片，将
第一次绘制后的第三车辆功能图片存储在内存或沙盒中，并在每次使用第三车辆功能图片时，从服务器获取第三车辆功能图片的图片规则数据；对于第四车辆功能图片，在使用时对第四车辆功能图片进行临时绘制，并在每次使用第四车辆功能图片时，从服务器获取第四车辆功能图片的图片规则数据。
87.具体地，本技术实施例将为不同分组的车辆功能图片配置不同的处理策略，下面结合具体实施例分别对这四类车辆功能图片的处理策略的内容进行详细说明，具体可以包括以下内容：一、针对第一车辆功能图片，即属于第一使用次数图片且属于第二变更次数图片，配置以下处理策略：第一次绘制后，直接存储在内存或沙盒中。而且不再每次在使用时去拉取服务器中的图片规则数据，改为在app启动之初拉取，或者第一次使用时拉取，当服务器的图片规则数据发生改变时，给app发送通知让其立刻去拉取最新的图片规则数据（服务器通知到app的方式包括并不限于：socket长连接，apns远程通知等）。
88.二、针对第二车辆功能图片，即属于第二使用次数图片且属于第二变更次数图片，配置以下处理策略：第二车辆功能图片对应的处理策略可以与上述第一车辆功能图片的处理策略相同，但是因为它的使用次数少，也可把第一车辆功能图片的处理策略改成：在使用时临时绘制，不存储在内存或沙盒中。
89.三、针对第三车辆功能图片，即属于第一使用次数图片且属于第一变更次数图片，配置以下处理策略：第一次绘制后，直接存储在内存或沙盒中，并且在每次使用时拉取服务器中的图片规则数据。
90.四、针对第四车辆功能图片，即属于第二使用次数图片且属于第一变更次数图片，配置以下处理策略：在使用时临时绘制第四车辆功能图片，无需将第四车辆功能图片存储到内存或沙盒中，并且在每次使用时拉取服务器中的图片规则数据。
91.需要说明的是，本技术不仅适用于车辆功能图片，也适用于一切满足如下规则的图片：图片不复杂，可以拆分为少量点，线，面，颜色，文字，阴影等构成元素；图片规则数据可能会发生变化，包括图片本身的数据，图片的变体；是否会增加新类型的图片，删除过期图片等。对于前述实施例提到的优化规则，不仅适用于车辆功能图片规则数据，也适用于其他需要服务器来更新的数据对于车辆功能图片，也不仅限于能拆分成少量点，线，面，颜色，文字，阴影等构成元素的图片，也可以是更复杂一些的图片，例如：对于一张绿色的图片，客户端根据规则数据，将其绘制在偏左侧，再翻转图片，缩小图片，绘制在偏右侧，设置比边框线条宽度为2，即可。对于图片的变体，也不仅限于颜色的改变，也可以是基于图形路径的，颜色填充方式的改变，或者增、减其他形状等元素。android和ios有相似的图片绘制类库和函数，所以本技术技术方案的思想也适用于android。
92.根据本技术实施例提供的技术方案，本技术利用车辆功能图片并非是非常的复杂图形，可以拆分为基础绘制功能的这一特点，制定了一种车辆功能图片灵活生成方案，即服
务器下发绘制规则，由客户端根据所需的实际图片尺寸直接进行绘制，并生成图片。本技术技术方案具有以下优点：（1）本技术避免了对图片进行缩放、裁剪、拉伸等处理，节约了系统的性能开销。
93.（2）系统对绘制图片和生成一张图片的不同颜色变体提供了便捷的系统api，生成速度非常快，用户无感知，所以生成图片的处理是高效的。
94.（3）服务器下发的规则只是一些很少的数字等配置，和图片相比非常小，大大节约用户的带宽，减少了内存占用。
95.（4）由于规则是服务器下发的，所以当产品的需求发生变化时，服务器可以对规则进行更新从而对图片进行更新，从而实现了灵活更新ui，无需客户端重新发版本的功能。
96.（5）可以实现按需绘制，用户没有进入的车控相关页面，就不进行对应图片生成。生成过后的图片存在内存或客户端本地沙盒，并不重复绘制，下次可以直接从内存或者沙盒中读取。并且这个步骤还可以优化为：本技术技术方案统计各个功能图片生成次数，并记录到服务器，对于经常用到的图片进行预绘制，对于不经常用到的图片进行按需绘制。
97.（6）针对每个汽车功能图片，有不同的状态，例如：寻车功能只有不可用和普通状态（因为寻车是一个点下即开始的动作，不存在进行中和关闭/打开态），因此只需要生成一个灰色图片和一个黑色图片即可。本技术技术方案的数据由服务器设置，所以针对不同的车控功能，需要生成多少张图片，每张图片对应什么颜色，都是可以灵活配置的。
98.（7）本技术生成的图片为矢量图，这种通过绘制得到的图可以进行任意尺寸的缩放而不失真，因此它保有了最好的清晰度和对比度，并且在图片相同尺寸不同的场景下，可以直接复用图片而没有任何性能或模糊问题。
99.下述为本技术装置实施例，可以用于执行本技术方法实施例。对于本技术装置实施例中未披露的细节，请参照本技术方法实施例。
100.图6是本技术实施例提供的基于客户端的车辆功能图片生成装置的结构示意图。如图6所示，该基于客户端的车辆功能图片生成装置包括：拆解模块601，被配置为获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个绘制元素在基准坐标系中的绘制信息；处理模块602，被配置为利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据，得到每个原始设计图片对应的图片规则数据；解析模块603，被配置为将图片规则数据下发给客户端，以使客户端对图片规则数据进行解析，并对图片规则数据中的各个绘制元素的绘制信息进行坐标转换；绘制模块604，被配置为基于坐标转换后的绘制信息，利用图片规则数据中定义的元素绘制顺序，调用相应的功能函数对绘制元素依次进行绘制，以便生成原始设计图片对应的车辆功能图片。
101.在一些实施例中，图6的处理模块602在服务端采用预定的数据组织规则，将同一原始设计图片的绘制信息处理成图片规则数据，并将图片规则数据存储在服务端，其中，图片规则数据中包含绘制元素的绘制信息以及元素绘制顺序。
102.在一些实施例中，图6的解析模块603当原始设计图片与需要绘制的车辆功能图片的尺寸比例一致时，利用车辆功能图片的尺寸与原始设计图片的尺寸之间的比值确定绘制比例，利用绘制比例将绘制信息中的坐标进行转换；当原始设计图片与需要绘制的车辆功
能图片的尺寸比例不一致时，分别计算车辆功能图片与原始设计图片之间的宽度比和高度比，将宽度比和高度比中比值较小的作为绘制比例，利用绘制比例将绘制信息中的坐标进行转换。
103.在一些实施例中，图6的绘制模块604对预设的图形渲染器类的初始化函数进行调用，以生成一个图形渲染器实例，其中，初始化函数的参数包括原始设计图片的尺寸以及绘图配置信息；对图形渲染器实例中的图形绘制方法进行调用，图形绘制方法的参数为绘制代码函数，利用绘制代码函数对坐标转换后的绘制信息进行调用，以便按照元素绘制顺序依次对绘制元素进行绘制，得到车辆功能图片。
104.在一些实施例中，图6的绘制模块604调用获取当前图形上下文函数来获取当前绘制上下文，利用预先生成的图形渲染器实例在当前绘制上下文中进行图像绘制，完成绘制后，调用绘制上下文对象，以便利用当前绘制上下文中所绘制的内容合成图像，得到车辆功能图片。
105.在一些实施例中，图6的绘制模块604在生成原始设计图片对应的车辆功能图片之后，利用参数对车辆功能图片的渲染模式进行设置，得到车辆功能图片对应的模板图片，将模板图片赋值给预设的控件，当需要改变车辆功能图片的颜色以生成变体图片时，将控件的着色属性设置为变体图片对应的颜色，其中，在模板图片中忽略图片的颜色信息，保留图片的透明度信息。
106.在一些实施例中，图6的绘制模块604在生成原始设计图片对应的车辆功能图片之后，将车辆功能图片以及变体图片存储到内存中，当客户端调用车辆功能图片以及变体图片时，请求服务端获取图片规则数据，将从服务端获取的图片规则数据与客户端存储的图片规则数据进行比对，判断车辆功能图片及变体图片对应的图片规则数据是否发生更新，当判断未发生更新时，继续使用客户端存储的图片规则数据，当判断发生更新时，对内存中的车辆功能图片以及变体图片进行清理，并重新绘制车辆功能图片。
107.在一些实施例中，图6的绘制模块604对每个车辆功能图片的使用次数以及每个车辆功能图片的图片规则数据的变更次数进行统计，利用预设的使用次数阈值以及变更次数阈值，对车辆功能图片进行分组，得到第一车辆功能图片、第二车辆功能图片、第三车辆功能图片以及第四车辆功能图片，利用预定的策略分别对不同分组的车辆功能图片进行处理。
108.在一些实施例中，图6的绘制模块604对于第一车辆功能图片，将第一次绘制后的第一车辆功能图片存储在内存或沙盒中，并在应用程序启动或第一次使用时，从服务器获取第一车辆功能图片的图片规则数据；对于第二车辆功能图片，在使用时对第二车辆功能图片进行临时绘制，并在应用程序启动或第一次使用时，从服务器获取第二车辆功能图片的图片规则数据；对于第三车辆功能图片，将第一次绘制后的第三车辆功能图片存储在内存或沙盒中，并在每次使用第三车辆功能图片时，从服务器获取第三车辆功能图片的图片规则数据；对于第四车辆功能图片，在使用时对第四车辆功能图片进行临时绘制，并在每次使用第四车辆功能图片时，从服务器获取第四车辆功能图片的图片规则数据。
109.应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
110.图7是本技术实施例提供的电子设备7的结构示意图。如图7所示，该实施例的电子设备7包括：处理器701、存储器702以及存储在该存储器702中并且可以在处理器701上运行的计算机程序703。处理器701执行计算机程序703时实现上述各个方法实施例中的步骤。或者，处理器701执行计算机程序703时实现上述各装置实施例中各模块/单元的功能。
111.示例性地，计算机程序703可以被分割成一个或多个模块/单元，一个或多个模块/单元被存储在存储器702中，并由处理器701执行，以完成本技术。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序703在电子设备7中的执行过程。
112.电子设备7可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备7可以包括但不仅限于处理器701和存储器702。本领域技术人员可以理解，图7仅仅是电子设备7的示例，并不构成对电子设备7的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如，电子设备还可以包括输入输出设备、网络接入设备、总线等。
113.处理器701可以是中央处理单元（central processing unit，cpu），也可以是其它通用处理器、数字信号处理器（digital signal processor，dsp）、专用集成电路（application specificintegrated circuit，asic）、现场可编程门阵列（field-programmable gate array，fpga）或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
114.存储器702可以是电子设备7的内部存储单元，例如，电子设备7的硬盘或内存。存储器702也可以是电子设备7的外部存储设备，例如，电子设备7上配备的插接式硬盘，智能存储卡（smart media card，smc），安全数字（secure digital，sd）卡，闪存卡（flash card）等。进一步地，存储器702还可以既包括电子设备7的内部存储单元也包括外部存储设备。存储器702用于存储计算机程序以及电子设备所需的其它程序和数据。存储器702还可以用于暂时地存储已经输出或者将要输出的数据。
115.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
116.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
117.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出
本技术的范围。
118.在本技术所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
119.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
120.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
121.集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（read-only memory，rom）、随机存取存储器（random access memory，ram）、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
122.以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。

技术特征：
1.一种基于客户端的车辆功能图片生成方法，其特征在于，包括：获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个所述绘制元素在基准坐标系中的绘制信息；利用预定的数据组织规则将属于同一所述原始设计图片的绘制信息处理成图片规则数据，得到每个所述原始设计图片对应的图片规则数据；将所述图片规则数据下发给客户端，以使所述客户端对所述图片规则数据进行解析，并对所述图片规则数据中的各个绘制元素的绘制信息进行坐标转换；基于坐标转换后的绘制信息，利用所述图片规则数据中定义的元素绘制顺序，调用相应的功能函数对所述绘制元素依次进行绘制，以便生成所述原始设计图片对应的车辆功能图片。2.根据权利要求1所述的方法，其特征在于，所述利用预定的数据组织规则将属于同一所述原始设计图片的绘制信息处理成图片规则数据，包括：在服务端采用预定的数据组织规则，将同一原始设计图片的绘制信息处理成图片规则数据，并将所述图片规则数据存储在服务端，其中，所述图片规则数据中包含所述绘制元素的绘制信息以及元素绘制顺序。3.根据权利要求1所述的方法，其特征在于，所述对所述图片规则数据中的各个绘制元素的绘制信息进行坐标转换，包括：当所述原始设计图片与需要绘制的车辆功能图片的尺寸比例一致时，利用车辆功能图片的尺寸与所述原始设计图片的尺寸之间的比值确定绘制比例，利用所述绘制比例将绘制信息中的坐标进行转换；当所述原始设计图片与需要绘制的车辆功能图片的尺寸比例不一致时，分别计算所述车辆功能图片与所述原始设计图片之间的宽度比和高度比，将所述宽度比和高度比中比值较小的作为绘制比例，利用所述绘制比例将绘制信息中的坐标进行转换。4.根据权利要求1所述的方法，其特征在于，所述调用相应的功能函数对所述绘制元素依次进行绘制，包括：对预设的图形渲染器类的初始化函数进行调用，以生成一个图形渲染器实例，其中，所述初始化函数的参数包括原始设计图片的尺寸以及绘图配置信息；对所述图形渲染器实例中的图形绘制方法进行调用，所述图形绘制方法的参数为绘制代码函数，利用所述绘制代码函数对所述坐标转换后的绘制信息进行调用，以便按照所述元素绘制顺序依次对所述绘制元素进行绘制，得到车辆功能图片。5.根据权利要求1所述的方法，其特征在于，所述调用相应的功能函数对所述绘制元素依次进行绘制，包括：调用获取当前图形上下文函数来获取当前绘制上下文，利用预先生成的图形渲染器实例在所述当前绘制上下文中进行图像绘制，完成绘制后，调用绘制上下文对象，以便利用所述当前绘制上下文中所绘制的内容合成图像，得到车辆功能图片。6.根据权利要求1所述的方法，其特征在于，在生成所述原始设计图片对应的车辆功能图片之后，所述方法还包括：利用参数对所述车辆功能图片的渲染模式进行设置，得到所述车辆功能图片对应的模板图片，将所述模板图片赋值给预设的控件，当需要改变所述车辆功能图片的颜色以生成
变体图片时，将所述控件的着色属性设置为所述变体图片对应的颜色，其中，在所述模板图片中忽略图片的颜色信息，保留图片的透明度信息。7.根据权利要求6所述的方法，其特征在于，在生成所述原始设计图片对应的车辆功能图片之后，所述方法还包括：将所述车辆功能图片以及所述变体图片存储到内存中，当客户端调用所述车辆功能图片以及所述变体图片时，请求服务端获取图片规则数据，将从所述服务端获取的图片规则数据与所述客户端存储的图片规则数据进行比对，判断所述车辆功能图片及所述变体图片对应的图片规则数据是否发生更新，当判断未发生更新时，继续使用所述客户端存储的图片规则数据，当判断发生更新时，对内存中的所述车辆功能图片以及所述变体图片进行清理，并重新绘制车辆功能图片。8.根据权利要求1所述的方法，其特征在于，所述方法还包括：对每个车辆功能图片的使用次数以及每个车辆功能图片的图片规则数据的变更次数进行统计，利用预设的使用次数阈值以及变更次数阈值，对所述车辆功能图片进行分组，得到第一车辆功能图片、第二车辆功能图片、第三车辆功能图片以及第四车辆功能图片，利用预定的策略分别对不同分组的车辆功能图片进行处理。9.根据权利要求8所述的方法，其特征在于，所述利用预定的策略分别对不同分组的车辆功能图片进行处理，包括：对于所述第一车辆功能图片，将第一次绘制后的所述第一车辆功能图片存储在内存或沙盒中，并在应用程序启动或第一次使用时，从服务器获取所述第一车辆功能图片的图片规则数据；对于所述第二车辆功能图片，在使用时对所述第二车辆功能图片进行临时绘制，并在应用程序启动或第一次使用时，从服务器获取所述第二车辆功能图片的图片规则数据；对于所述第三车辆功能图片，将第一次绘制后的所述第三车辆功能图片存储在内存或沙盒中，并在每次使用所述第三车辆功能图片时，从服务器获取所述第三车辆功能图片的图片规则数据；对于所述第四车辆功能图片，在使用时对所述第四车辆功能图片进行临时绘制，并在每次使用所述第四车辆功能图片时，从服务器获取所述第四车辆功能图片的图片规则数据。10.一种基于客户端的车辆功能图片生成装置，其特征在于，包括：拆解模块，被配置为获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个所述绘制元素在基准坐标系中的绘制信息；处理模块，被配置为利用预定的数据组织规则将属于同一所述原始设计图片的绘制信息处理成图片规则数据，得到每个所述原始设计图片对应的图片规则数据；解析模块，被配置为将所述图片规则数据下发给客户端，以使所述客户端对所述图片规则数据进行解析，并对所述图片规则数据中的各个绘制元素的绘制信息进行坐标转换；绘制模块，被配置为基于坐标转换后的绘制信息，利用所述图片规则数据中定义的元素绘制顺序，调用相应的功能函数对所述绘制元素依次进行绘制，以便生成所述原始设计图片对应的车辆功能图片。11.一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算
机程序，所述处理器执行所述程序时实现如权利要求1至9中任一项所述的方法。12.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至9中任一项所述的方法。

技术总结
本申请提供一种基于客户端的车辆功能图片生成方法、装置及存储介质。该方法包括：获取车辆功能的原始设计图片，将原始设计图片拆解成绘制元素，并确定每个绘制元素在基准坐标系中的绘制信息；利用预定的数据组织规则将属于同一原始设计图片的绘制信息处理成图片规则数据；将图片规则数据下发给客户端，以使客户端对图片规则数据进行解析，并对图片规则数据中的各个绘制元素的绘制信息进行坐标转换；基于坐标转换后的绘制信息，利用图片规则数据中定义的元素绘制顺序，调用相应的功能函数对绘制元素依次进行绘制，以便生成原始设计图片对应的车辆功能图片。本申请能够节约系统的性能开销，提高图片生成效率，可以按需绘制，提升图片绘制的灵活性。片绘制的灵活性。片绘制的灵活性。


技术研发人员：陈裕聪 唐如意 叶松林
受保护的技术使用者：成都赛力斯科技有限公司
技术研发日：2023.06.19
技术公布日：2023/7/21