具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或模块的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或模块,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。
首先,对本申请实施例的部分用语进行解释:
多端(又称为跨端):是指开发文件的多端适用,无需针对不同的端进行单独的代码编写过程,例如开发文件可在电脑端和手机端进行多端适用,可在多种原生(Native)***上进行多端适用,其中,原生***比如安卓(Android)和iOS。
可视化组件:页面上通常包括多个可视化组件,可视化组件可包括多个视图元素,比如包括标题、文本、图像等,单个可视化组件可以用来展示比较独立、完整的业务内容,比如,用来展示聊天消息的弹框、用于展示商品信息的页面卡片。
模板文件:基于特定领域编程语言(Domain Specific Language,DSL)实现的程序文件,用于描述可视化组件中视图元素的位置、样式等布局信息。
模板文件的动态发布:开发人员将模板文件上传至服务端后,用户终端的客户端可从服务端更新模板文件,即模板文件的更新无需等待用户终端的客户端版本的更新。
原生视图元素类型:是指视图元素在原生***中的原生类型,同一视图元素在不同的原生***中对应的原生类型不同。
由于可视化组件面临多端显示的需求,开发人员通常要为可视化组件开发分别适用于不同端的原生组件,增加了开发成本,降低了开发效率。在业务需求的总量逐渐增多、业务需求变化频繁、人力有限、Weex1.0技术(一种前端开发技术)逐渐被淘汰等情况下,亟需提高可视化组件的跨端能力、提高开发人效、降低开发成本以及减少资源浪费。
为满足上述需求,本申请实施例提出了一种可视化组件处理方法。在该方法中,页面上可视化组件的模板文件包括第一文件和第二文件,第一文件中包含可视化组件中视图元素的元素类型和不同的视图元素之间的层级关系,第二文件中包含视图元素的布局信息和样式信息。在终端上,可基于可视化组件的模板文件和类型对应关系,确定可视化组件中的视图元素适用于页面所在终端的目标信息,基于视图元素的目标信息,在页面上显示可视化组件。其中,类型对应关系包括视图元素的元素类型与终端的原生视图元素类型的对应关系,视图元素的目标信息包括视图元素的层级关系、目标布局信息、目标样式信息以及原始视图元素类型。可见,可视化组件的模板文件是多端适用的,开发人员无需针对不同的原生***开发单独的原生组件,提高了可视化组件的跨端能力,提高了开发人效(即开发效率),降低了开发成本,同时还减少了资源浪费。
示例性的,图1为本申请实施例提供的应用场景示意图,如图1所示,开发人员针对可视化组件开发模板文件,通过服务端将模板文件传输至用户的终端进行端上渲染。其中,可视化组件的模板文件可以适用于不同的终端,如图1所示的手机端和个人电脑(personalcomputer,简称PC)端。在图1中,手机端和PC端可基于可视化组件的模板文件,进行可视化组件的布局(如图1中的布局转换)和渲染,在页面上显示出可视化组件,例如,图1中页面渲染后页面上显示有包含图像和标题的可视化组件。其中,在布局和渲染的过程中,可基于模板文件,转换得到视图元素适用于终端(如适用于手机端、PC端)的布局信息、原生视图元素类型等,基于这些转换后的信息,在终端显示可视化组件。
上述只是示例性的一个应用场景。本申请实施例可以应用于互联网中任何可视化组件处理场景中,比如可视化组件在安卓端与iOS端的跨端显示。
下面,结合上述图1示出的应用场景,通过具体实施例对本申请的技术方案进行详细说明。需要说明的是,下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。
需要说明的是,本申请实施例的方法执行主体为电子设备,电子设备例如为终端,终端可以是个人数字处理(personal digital assistant,简称PDA)设备、具有无线通信功能的手持设备(例如智能手机、平板电脑)、计算设备(例如PC)、车载设备、可穿戴设备(例如智能手表、智能手环)、智能家居设备(例如智能显示设备)等。
参考图2,图2为本申请实施例提供的可视化组件处理方法的流程示意图一。本申请实施例提供一种可视化组件处理方法,具体包括以下步骤:
S201、在终端上,确定页面上可视化组件的模板文件。
其中,模板文件包括第一文件和第二文件,第一文件中包含可视化组件中视图元素的元素类型和不同的视图元素之间的层级关系,第二文件中包含视图元素的布局信息和视图元素的样式信息。视图元素的元素类型比如文本、图像等类型。不同的视图元素之间的层级关系可包括并列关系、嵌套关系等。可将视图元素看作矩形的区域,区域与区域之间可以是并列的,也是嵌套的,例如,视图元素A和视图元素B在页面上是并排排列的,则视图元素A与视图元素B的层级关系为并列关系;在页面上视图元素C位于视图元素D中,则视图元素C与视图元素D的层级关系为嵌套关系。视图元素的布局信息可包括视图元素的排列方式(例如横向排列或者竖向排列)、视图元素的宽度设置方式、视图元素的高度的设置方式等。视图元素的宽度设置方式比如:视图元素的宽度占页面宽度的50%或者占满整个页面宽度;或者,最后一个视图元素的宽度占比为1减去该视图元素所在行的其他视图元素的宽度占比之和。视图元素的样式信息比如视图元素的背景颜色、字体等。
在第一文件中和第二文件中,还可包括视图元素的ID,在可视化组件的所有视图元素中,各个视图元素的ID唯一。在第一文件中,可通过编程语言描述各个视图元素的ID和元素类型,并描述不同视图元素之间的层级关系。在第二文件中,可通过键-值映射方式描述视图元素的布局信息和样式信息的对应关系,其中,在键-值映射方式中,键为视图元素的ID,与键对应的值为视图元素的布局信息和样式信息。
其中,页面为在终端的原生***中运行的应用程序的客户端页面。
本实施例中,终端可响应于页面的显示请求,获取页面上一个或多个可视化组件的模板文件,以在显示页面的同时在页面上显示可视化组件。比如,在用户打开应用程序的客户端时,获取客户端的主页面上可视化组件的模板文件。
S202、根据模板文件和类型对应关系,确定视图元素的目标信息。
其中,类型对应关系包括视图元素的元素类型与终端的原生视图元素类型的对应关系。视图元素的元素类型为开发人员为视图元素定义的类型,终端的原生视图元素类型取决于终端的原生***,同一元素类型在原生***不同的终端对应的原生视图元素类型不同。所以,在可视化组件的布局过程中,原生***不同的终端采用的类型对应关系不同。
其中,视图元素的目标信息包括视图元素的层级关系、视图元素的目标布局信息、视图元素的目标样式信息以及视图元素对应的原生视图元素类型。
本实施例中,可基于模板文件和类型对应关系,将模板文件中视图元素的元素类型,转换为页面所在终端能够识别出的原生视图元素类型,即根据类型对应关系和视图元素的元素类型,确定视图元素对应的原生视图元素类型。由于终端的原生***可以识别的布局方式包括绝对布局和相对布局,在视图元素的布局信息符合绝对布局或者相对布局的情况下,可保持视图元素的布局信息不变,在视图元素的布局不符合绝对布局和相对布局的情况下,可基于模板文件中不同视图元素的层级关系和视图元素的布局信息,对视图元素进行绝对布局转换或者相对布局转换,得到视图元素的目标布局。从而,使得视图元素在类型和布局上均能够被终端的原生***所识别。
其中,在根据类型对应关系和视图元素的元素类型,确定视图元素对应的原生视图元素类型的过程中,可在类型对应关系中,确定与视图元素的元素类型对应的原生视图元素类型,将该原生视图类型确定为视图元素对应的原生视图类型。
其中,视图元素的目标样式信息可以与第二文件中视图元素的样式信息相同。
S203、基于视图元素的目标信息,在页面上显示可视化组件。
本实施例中,视图元素的目标信息中包含视图元素对应的原生视图元素类型、不同的视图元素之间的层级关系、视图元素的目标布局信息和视图元素的目标样式信息,其中,在视图元素的目标布局信息中,视图元素的布局方式采用绝对布局方式或者相对布局方式。在得到视图元素的目标信息之后,在显示页面的同时,按照视图元素的目标信息中视图元素对应的原生视图元素类型、视图元素的目标布局信息、视图元素的目标样式信息,以及不同的视图元素之间的层级关系,在页面上显示可视化组件。
本申请实施例中,确定页面上可视化组件的模板文件,基于模板文件和类型对应关系,确定可视化组件中视图元素适用于页面所在终端的目标信息,基于视图元素的目标信息,在页面上显示可视化组件。从而,基于多端适用的模板文件,实现可视化组件在页面上的显示,开发人员无需针对不同端开发单独的原生组件,提高了可视化组件的跨端能力,提高了开发人效,降低了开发成本,减少了资源浪费。
在一些实施例中,在S202中,可基于模板文件和类型对应关系,构建了描述可视化组件的视图元素的目标信息的树结构,使得视图元素的布局过程更为形象和准确,其中,树结构中节点之间的位置关系,生动形象地反映了视图元素之间的层级关系。作为示例的,参考图3,图3为本申请实施例提供的可视化组件处理方法中可视化组件从开发到端上渲染的流程示例图一,设计人员设计可视化组件的设计稿,开发人员基于该设计稿开发可视化组件的模板文件,可视化组件的模板文件经过本实施例提供的可视化组件处理方法,得到描述视图元素的目标信息的树状结构,之后,再基于该树状结构,在页面上进行可视化组件的显示,即实现可视化组件的端上渲染。
基于上述构建树状结构的构思,参照图4,图4为本申请实施例提供的可视化组件处理方法的流程示意图二。如图4所示,可视化组件处理方法包括如下步骤:
S401、在终端上,确定页面上可视化组件的模板文件,模板文件包括第一文件和第二文件,第一文件中包含可视化组件中视图元素的元素类型和不同的视图元素之间的层级关系,第二文件中包含视图元素的布局信息和视图元素的样式信息。
其中,S401的实现原理和技术效果可参照前述实施例,在此不再赘述。
S402、根据第一文件中视图元素的层级关系和第二文件中视图元素的布局信息,构建虚拟节点树,虚拟节点树的节点为视图元素。
其中,虚拟节点树的节点为可视化组件中的视图元素,即虚拟节点树中的节点与可视化组件中的视图元素一一对应。
其中,虚拟节点树中不同节点之间的位置关系反映可视化组件中不同视图元素之间的层级关系。比如,位于同一层的节点所对应的视图元素之间的层级关系为并列关系,父节点所对应的视图元素与子节点所对应的视图元素之间的层级关系为嵌套关系。
本实施例中,可从第一文件中解析出可视化组件中不同的视图元素之间的层级关系,从第二文件中解析出可视化组件中视图元素的布局信息,可将不同视图元素之间的层级关系转换为树状结构,将视图元素的布局信息确定为虚拟结构树中相应节点的布局信息。
根据不同视图元素之间的层级关系,确定不同节点之间的位置关系,并根据节点与视图元素的对应关系,为节点绑定对应视图元素的布局信息,最终得到带有视图元素的布局信息的虚拟节点树。因此,在虚拟节点树中,每个节点对应有属性信息,节点的属性信息包括节点的布局信息。此外,节点的属性信息还可包括节点的ID,节点的ID即视图元素在模板文件中的ID,节点的ID既能够唯一区别节点,又可以建立节点与视图元素的对应关系。
S403、对虚拟节点树进行绝对布局处理,得到更新后的虚拟节点树,更新后的虚拟节点树中的节点携带有视图元素的目标布局信息。
其中,第二文件中视图元素的布局信息所采用的布局方式,取决于开发人员在开发模板文件时所采用的布局模块,该布局方式可能不是终端的原生***所能够识别的绝对布局方式和相对布局方式。所以,可考虑将视图元素的布局信息转换为按照绝对布局方式进行布局的布局信息,或者转换为按照相对布局的布局信息。
在本实施例中,选择将视图元素的布局信息转换为按照绝对布局方式进行布局的布局信息,即将虚拟节点树中节点的布局信息转换为按绝对方式进行布局的布局信息。具体的,可利用预设的绝对布局转换库,对携带视图元素的布局信息的虚拟节点树进行绝对布局转换,得到节点基于绝对布局方式进行布局的虚拟节点树(即绝对转换后虚拟节点树中节点的布局信息采用的布局方式为绝对布局方式),即更新后的虚拟节点树。对布局转换后虚拟节点树中节点的布局信息即与节点对应的视图元素的目标布局信息,为了方便理解,将绝对布局转换后虚拟节点树中节点的布局信息称为节点的目标布局信息。
其中,绝对布局转换库是预先开发的绝对布局转换工具,其输入为带有视图元素的布局信息的虚拟节点树,其输出为节点基于绝对布局方式进行布局的虚拟节点树,可通过调用绝对布局转换库提供的接口的方式,调用绝对布局转换库。
可选的,在第二文件中,视图元素的布局信息是基于弹性布局模块(FlexBox)进行布局的,绝对布局转换库可为StretchKit。其中,FlexBox又称为弹性框布局模块,能够更轻松地设计灵活的响应式布局结构;StretchKit是使用Rust语言编写的跨平台跨端的底层库,为StretchKit传入一个虚拟节点树,通过StretchKit内部的布局计算,就可以得到基于节点基于绝对布局方式进行布局的虚拟节点树。
其中,第一文件的文件格式可为JS对象简谱(JavaScript Object Notation,JSON)格式,第二文件的文件格式可为层叠样式表(Cascading Style Sheets,CSS)。在第二文件中,按照CSS规范描述了视图元素的布局信息和样式信息。
本可选方式中,原生***无法识别基于FlexBox实现的布局信息视图元素和基于JSON文件描述的布局信息,所以可基于第一文件中视图元素的层级关系和第二文件中视图元素的布局信息,构建虚拟节点树,之后,将调用StretchKit对FlexBox布局下的虚拟节点树进行绝对布局处理,得到节点按照绝对布局方式布局的虚拟节点树,即更新后的虚拟节点树。其中,调用StretchKit对FlexBox布局下的虚拟节点树进行绝对布局处理的过程中,包括非常多的环节,包括基准值的确定、主轴尺寸的计算、交叉轴尺寸的计算等等,该过程为StretchKit内部自有的逻辑计算过程,在此不一一赘述。
选择基于Rust语言编写的Stretch,来解析FlexBox布局下的虚拟节点树(该虚拟节点树中节点的布局信息是基于FlexBox进行布局的)并将其转换为绝对布局下的虚拟节点树(该虚拟节点树中节点的布局信息是基于绝对布局方式进行布局的),充分利用了Stretch作为跨端布局计库所具备的跨端能力、堪比C++的计算速度、无垃圾回收(GarbageCollection,GC)和无内存浪费等优点,提高了虚拟节点树的布局转换过程的跨端能力、效率、稳定性和准确性,减少了资源浪费。
在S401和S402中,对模板文件进行解析(比如对第一文件进行解析、对第二文件进行解析)的过程中,模板文件基本处于不变状态,且该环节的产物(视图元素的布局信息、样式信息等)可以通过多级缓存的方式进行数据复用,所以解析过程中中央处理器(CentralProcessing Unit,CPU)的计算开销是可控的。
S404、根据类型对应关系和更新后的虚拟节点树,创建视图树并确定视图树中节点的原生视图元素类型,虚拟节点树中的节点为视图元素。
本实施例中,在得到节点基于绝对布局方式进行布局的虚拟节点树之后,可根据类型对应关系、虚拟节点树中节点的元素类型和虚拟节点树中节点的目标布局信息,创建视图树。具体的,可对该虚拟节点树的节点进行一一遍历,针对遍历到的节点,在类型对应关系中,确定与该节点的元素类型对应的原生视图元素类型,创建该原生视图元素类型的节点,还可确定该原生视图元素类型的节点的目标布局信息为虚拟节点树中遍历到的节点的目标布局信息,之后继续遍历虚拟节点树中的下一个节点。如此,得到原生视图元素类型的多个节点,由原生视图元素类型的多个节点构成视图树。对于终端的原生***而言,视图树中节点的原生视图元素类型和节点的绝对布局方式均是可识别的。
其中,视图树中节点的属性信息还可包括节点的ID,与虚拟节点树中相应节点的ID相同,视图树中节点的ID也为对应的视图元素在模板文件中的ID。在遍历虚拟节点树中的节点,以构建视图树中原生视图元素类型的节点的过程中,可基于虚拟节点树中节点的ID,从第一文件中获得相应视图元素的元素类型,在类型对应关系中,确定与该元素类型对应的原生视图元素类型,构建该原生视图元素类型的节点。
S405、根据视图树和第二文件中视图元素的样式信息,更新视图树,其中,更新后的视图树可携带有视图元素的目标信息。
本实施例中,在得到视图树之后,视图树上携带了视图元素的原生视图类型、视图元素符合绝对布局的目标布局信息和视图元素的层级关系,但缺少视图元素的样式信息。所以,可从第二文件中获取视图元素的样式信息,可基于视图元素的样式信息,确定视图树上相应节点的样式信息,即将视图树和视图元素的样式信息结合,得到更新的视图树。
在一种可能的实现方式中,如图4所示,S405包括:S4051、根据视图元素的样式信息,为视图树中相应的节点绑定样式信息。
本实现方式中,可对视图树中的节点进行一一遍历,针对遍历到的节点,根据节点的ID,在可视化组件的多个视图元素的样式信息中,确定节点对应的视图元素的样式信息,将该样式信息确定为节点的样式信息,即为节点绑定相应的样式信息,之后,继续遍历下一个节点,直至遍历完视图树中的所有节点。此时,在视图树中,除了节点的ID、原生视图类型、布局信息之外,节点的属性信息还包括节点的样式信息。
S406、基于视图元素的目标信息,在页面上显示可视化组件。
其中,S406的实现原理和技术效果可参照前述实施例,不再赘述。
本申请实施例中,基于可视化组件的模板文件和类型对应关系,构建虚拟节点树、对虚拟节点树进行绝对布局处理、将采用绝对布局方式的虚拟节点树转换为视图树并为视图树增加视图元素的样式信息,得到终端的原生***可识别的视图元素的目标信息,基于视图元素的目标信息,在页面上显示可视化组件。从而,实现可视化组件的模板文件在终端的原生***中的适用,实现可视化组件的跨端能力,整个过程的计算开销可控,而且还可以进一步利用FlexBox和StretchKit提高布局计算的效率和较少资源浪费。
基于前述任一实施例,可选的,可视化组件的模板文件还包括第三文件,第三文件包含视图元素的数据绑定逻辑,其中,数据绑定逻辑即数据获取逻辑,用于描述如何从数据源(比如从服务器记载的数据)中获取视图元素的资源数据。
基于可视化组件的模板文件还包括第三文件,参照图5,图5为本申请实施例提供的可视化组件处理方法的流程示意图三。如图5所示,可视化组件处理方法包括如下步骤:
S501、在终端上,确定页面上可视化组件的模板文件,模板文件包括第一文件和第二文件,第一文件中包含可视化组件中视图元素的元素类型和不同的视图元素之间的层级关系,第二文件中包含视图元素的布局信息和视图元素的样式信息。
S502、根据第一文件中视图元素的层级关系和第二文件中视图元素的布局信息,构建虚拟节点树,虚拟节点树的节点为视图元素。
S503、对虚拟节点树进行绝对布局处理,得到更新后的虚拟节点树,更新后的虚拟节点树中的节点携带有视图元素的目标布局信息。
S504、根据类型对应关系和更新后的虚拟节点树,创建视图树并确定视图树中节点的原生视图元素类型,虚拟节点树中的节点为视图元素。
S505、根据视图元素的样式信息,为视图树中相应的节点绑定样式信息。
其中,S501~S505的实现原理和技术效果可参照前述实施例,不再赘述。
S506、根据第三文件中视图元素的数据绑定逻辑,确定用于渲染视图元素的资源数据。
S507、根据视图元素的资源数据,为视图树中相应的节点绑定资源数据。
其中,在第三文件中,视图元素的数据绑定逻辑由两个部分构成:取值逻辑和扩展逻辑。取值逻辑和扩展逻辑都可以使用表达式来构建,表达式可支持常量运算、关系表达式、取值运算、变量运算等多种运算。取值逻辑是指利用取值表达式从数据源(包含多个视图元素需要显示的内容)中取出视图元素中需要显示的内容,比如,在文本类型的视图元素中需要显示标题内容“你好”,可以通过取值表达式从数据源中取出该标题内容“你好”。扩展逻辑是指利用扩展表达式来更新视图元素的布局信息和样式信息,以达到更新视图元素的布局信息和样式信息的目的。比如,在第二文件中视图元素的颜色为红色,在布局过程中可通过扩展表达式将视图元素的颜色改变为白色。
本实施例中,针对单个视图元素,可根据视图元素的数据绑定逻辑,结合与页面相关的数据源和数据绑定逻辑中的表达式,确定视图元素的资源数据,将视图元素的资源数据,与视图树中与视图元素对应的节点进行绑定。
可选的,第三文件的文件格式可以采用JSON格式。
S508、基于最终的视图树,在页面上显示可视化组件。
本实施例中,可根据视图树中节点的层级关系、原生视图元素类型、目标布局信息、样式信息、资源数据,进行可视化组件中视图元素的绘制,得到绘制后的可视化组件,在页面上显示绘制后的可视化组件。
本申请实施例中,基于可视化组件的模板文件和类型对应关系,构建虚拟节点树、对虚拟节点树进行绝对布局处理、将采用绝对布局方式的虚拟节点树转换为视图树,并为视图树绑定视图元素的样式信息、资源数据,得到最终的视图树,基于最终的视图树,在页面上显示可视化组件。从而,结合树、绝对布局转换、视图元素类型、数据绑定等,实现可视化组件的模板文件在终端的原生***中的适用,并完善了可视化组件的显示效果。
作为示例的,参考图6,本申请实施例提供的可视化组件处理方法中可视化组件从开发到端上渲染的流程示例图二,如图6所示,将包含第一文件、第二文件和第三文件的模板文件下发至终端(如图6所示的手机和PC),其中,第一文件可以为采用FlexBox布局实现,且文件格式为JSON格式;第二文件的格式可为CSS格式;第三文件的格式可为JSON格式。在终端中,可采用用于绝对布局转换的底层库(尤其可以采用StretchKit),对视图元素基于FlexBox(即弹性框布局模块)的布局进行绝对布局转换,之后再进行视图元素类型转换、样式绑定、数据绑定、绘制操作,实现页面上可视化组件的显示。
可选的,在为视图树中的节点绑定相应的样式信息之后,和/或为视图树中的节点绑定资源数据之前,还可为视图树中的节点绑定相应的事件(比如点击事件、长点击事件)、动画等。其中,节点对应的事件、动画即与节点对应的视图元素的事件、动画,视图元素的事件和动画可以记载在第二文件或者第三文件中。在为节点绑定相应的样式信息、事件、动画等数据的过程中,会与页面所属应用程序的基础库进行交互,以通过应用程序的基础库来支撑样式信息、事件和动画等的实现。
可选的,考虑到可能部分视图元素需要进行布局的自适应调整,在构建视图树、为视图树中的节点绑定样式信息、资源数据等数据的过程中(相当于渲染过程),若确定节点对应的视图元素需要进行布局的自适应调整(比如在节点的资源数据中标记了节点对应的视图元素需要进行布局的自适应调整),则可返回至虚拟树构建过程(相当于布局过程)重新确定视图元素的目标布局信息,从而,提高视图元素布局的准确性。
可选的,在完成对视图树的处理之后:基于视图树进行视图数据的上下文存储,将上下文存储的视图数据传递至页面进行显示。其中,上下文存储可包括状态存储和参数存储,状态存储是指存储可视化组件是否准备好渲染,参数存储是指存储可视化组件中视图元素的原生视图元素类型、层级关系、布局信息、样式信息等。在可视化组件的状态为准备好渲染时,将可视化组件的上下文存储的视图数据传递至页面进行显示。从而,通过上下文存储的方式,提高对可视化组件显示的管理效果。
为提高可视化组件的渲染效率,降低计算资源消耗,还可采取如下性能优化措施:
优化措施之一:多次遍历节点以及各种绑定操作存在大量的CPU计算,如果能够减少遍历次数,减少节点数量,就能够提升性能。考虑到可视化组件的模板文件中可能会设计多个无意义的视图元素,这类视图元素仅在第一文件中有相应的元素类型、层级关系,而没有对应的样式信息、数据绑定逻辑、事件、动画等,这类视图元素可以不进行渲染,以达到减少遍历次数、减少节点数据,提升性能的效果。在一种可选方式中,可根据第二文件,在视图元素中确定不具备样式信息的目标视图元素,对目标视图元素进行移除。
本可选方式中,可通过对所有目标视图元素进行图层合并的方式,对目标视图元素进移除。比如,将所有目标视图元素的图层合并为一个图层。如此,可以省去遍历次数、减少节点数据,还可以省去大量的绑定操作,提高布局效率。
优化措施之二:在处理能力不佳的终端上,图像处理器(Graphics ProcessingUnit,GPU)无法及时处理上载的图像,或者GPU在处理图像时效率较慢,导致可视化组件的显示效率较低,为了解决这个问题,在一种可选方式中,可根据视图元素的目标信息,将所有视图元素绘制在同一张图像上,在页面上,对图像进行显示。
本可选方式中,可根据虚拟节点树,构建轻量级的视图树,在轻量级的视图树中,每个节点对应一个轻量级视图,轻量级视图中保存有与节点对应的视图元素的原生视图元素类型、布局信息、样式信息等,之后可将所有的轻量级视图绘制到一个位图(Bitmap)上。之后,再将该位图传递给GPU进行渲染。如此,CPU只需要将所有视图元素绘制成的一张单图传递至GPU处理,减少了CPU与GPU的交互次数,较少了GPU的处理量,提高了可视化组件的显示效率,尤其是达到了提升低端机上可视化组件的显示效率的目标。
传统方式中,用户需要更新客户端(即下载新版的客户端)才能够更新页面上可视化组件,无法实现可视化组件的动态下发,导致可视化组件的更新不便,在业务需求变化频繁的情况下该方式的劣势明显。基于前述任一实施例,可采用优化方案进一步实现可视化组件的模板文件的动态下发,提高可视化组件更新的灵活性。
参考图7,图7为本申请实施例提供的可视化组件处理方法的流程示意图四。如图7所示,可视化组件处理方法包括如下步骤:
S701、终端响应于显示页面的请求,在本地已下载的远程模板文件中和/或在本地资源目录下,获取可视化组件的模板文件。
其中,模板文件可为来自于本地数据库的模板文件(即从本地资源目录下获取的模板文件,)或者来自于服务端的远程模板文件。来自与本地数据库的模板文件存储在终端的存储器中,用于实现页面上较为基础的可视化组件的显示,这类模板文件在客户端更新时随之更新。本地已下载的远程模板文件即已同步至本地的远程模板文件,远程模板文件可在页面所在的客户端启动或者在接收到页面显示请求时,从服务端下载得到,可动态更新。
开发人员在开发模板文件后,可将模板文件传入服务端,以供终端下载。终端可在页面所在客户端运行(比如页面所在客户端启动时)过程中,从服务端下载远程模板文件。
进一步的,响应于页面所在的客户端启动或者响应于访问页面的请求,向服务端请求页面上可视化组件的远程模板文件,在服务端上,确定终端此次请求页面上可视化组件的远程模板文件的时刻与终端是上次请求该页面上可视化组件的远程模板文件的时刻之间的时间段,获取在该时间段内更新的远程模板文件,将该时间段内更新的远程模板文件发送至终端,从而,通过两次请求之间的时间间隔中增量的远程模板文件发送给终端,实现终端上远程模板文件的动态更新,提高了模板文件更新的灵活性、便捷性和效率
本实施例中,终端在接收到显示页面的请求后(比如,用户进入应用程序的首页,触发显示应用程序的首页的请求),可从本地已同步下载的远程模板文件中和/或在远程资源目标下,确定页面上可视化组件的模板文件。
在一种可能的实施方式中,终端响应于显示页面的请求,确定页面上可视化组件的模板文件的存储路径;在本地已下载的远程模板文件中/或本地资源目录下,确定该存储路径下是否存在模板文件;若该存储路径下存在模板文件,则从该存储路径下获得可视化组件的模板文件;若该存储路径下不存在模板文件,则可从服务端请求下载可视化组件的模板文件。从而,通过先本地查找再远程下载的方式,提高模板文件的获取效率。
进一步的,终端可响应于显示页面的请求,确定页面上可视化组件的模板文件对应的标识信息,标识信息包括业务标识和模板标识;根据业务标识和模板标识,确定模板文件的存储路径。从而,通过业务标识和模板标识,提高模板文件的查找效率。
其中,模板文件对应的标识信息可以预先设置在可视化组件的属性信息中。标识信息中的业务标识又可以理解为模板文件的分组标识,是考虑到在实际情况中存在不同的业务场景而设置的,比如首页场景、推荐场景、用户页面场景等。在开发过程中,可根据模板文件所使用的业务场景,对模板文件进行分组处理,得到模板文件的业务标识,比如,适用于首页场景的模板文件的业务标识为01,适用于推荐场景的模板文件的业务标识为02。标识信息中的模板标识用于唯一标识模板文件。在终端上,可根据模板文件的业务标识和模板标识对模板文件进行管理。具体的,可先根据模板文件的业务标识,确定模板文件所属的模板文件组,再基于模板文件的模板标识,在模板文件所属的模板文件组中,确定模板文件对应的存储路径,继而基于存储路径获取模板文件。从而,提高模板文件获取效率。
可选的,可采用模板管理器对模板文件进行管理,以提高模板文件的管理效果,进而提高模板文件动态下发的效率和有序性。
其中,模板管理器可包括如下至少一种:内存模板管理器、远程模板管理器、本地模板管理器。内存模板管理器用于管理已经加载至内存中并处于使用状态的模板文件;远程模板管理器用于管理本地已下载的远程模板文件;本地模板管理器用于位于本地资源目录下的模板文件。从而,通过对内存中的、远程的、本地的模板文件进行分门别类的管理,提高对可视化组件的模板文件的管理效果。
本可选方式中,通过模板管理器,可在应用程序的生命周期内,对位于内存中的模板文件、本地已下载的远程模板文件、位于本地资源目录下的模板文件的缓存状态(比如模板文件是否可用)和加载顺序(比如先从内存中加载,再从本地加载,最后从远程加载)进行管理,同时保证终端获取的模板文件符合业务环境和版本要求,实现模板文件的动态下发,并提高模板文件动态下发的准确性和效率。
S702、在终端上,确定页面上可视化组件的模板文件,模板文件包括第一文件和第二文件,第一文件中包含可视化组件中视图元素的元素类型和不同的视图元素之间的层级关系,第二文件中包含视图元素的布局信息和视图元素的样式信息。
S703、根据模板文件和类型对应关系,确定视图元素的目标信息,类型对应关系包括视图元素的元素类型与终端的原生视图元素类型的对应关系。
S704、基于视图元素的目标信息,在页面上显示可视化组件。
其中,S702~S704的实现原理和技术效果可参照前述实施例,不再赘述。
本申请实施例中,终端响应于显示页面的请求,在本地已下载的远程模板文件中和/或在本地资源目录下,获取可视化组件的模板文件,根据可视化组件的模板文件,进行视图元素的布局和渲染,实现页面上可视化组件的显示。可见,模板文件可以从远端动态下发,而且单个可视化组件的布局和显示可以独立实现,而无需依赖页面所在客户端的版本更新和重选下载,有效地提高了可视化组件的更新便捷性和灵活性。
参考图8,图8为本申请实施例提供的可视化组件处理方法的方案架构示意图。如图8所示,可视化组件处理方法的方案架构如下:
1、从左到右,可视化组件处理方法的方案架构可分为“业务支撑”和“研发支撑”,业务支撑是指基于可视化组件处理的业务需求进行方案的架构,研发支撑是指在研发技术上对可视化组件处理的实现所提供的技术支持。
2、从下到上,业务支撑可分为“基础依赖”、“核心支撑”、“业务与容器”以及“应用落地”这四个层级。
在第一个层级中,“基础依赖”用于提供实现可视化组件处理方法的底层执行环境,在“基础依赖”中包括基础的技术依赖、页面解析渲染框架、显示框架、资源库和用于绝对布局转换的底层库(尤其可以采用StretchKit)。其中,页面解析渲染框架可用于支撑多端的页面解析和渲染的页面解析渲染框架,比如支持手机、平板(Pad)、Mac电脑、互联网电视业务平台(Over The Top,OTT)上页面解析和渲染的OneArch框架,显示框架用于确保各个视图元素正确显示,资源库可为可视化组件的解析、渲染提供资源。
在第二个层级中,“核心支撑”负责以下处理操作:模板文件的管理(比如内存中模板文件的管理、本地的模板文件的管理、远程的模板文件的管理等)、模板文件的布局解析(比如虚拟节点树的创建)、模板文件的渲染(比如视图树的构建、可视化组件的显示)。“核心支撑”可提供底层的应用程序编程接口(Application Programming Interface,API),以供上层(比如容器层)调用,以实现上述对模板文件的处理。
在第三个层级中,“业务与容器层”属于“核心支撑”与“业务落地”之间的接口层。在“业务与容器层”中包括“业务层”和“容器层”:“业务层”用于对“核心支撑”所提供的API进行较高层次封装,可以用多种编程语言实现的封装接口,开发人员基于这些封装接口,通过简单的几行代码就可以实现可视化组件的模板文件的处理,提高模板文件的开发效率,进而提高业务需求的落地效率;“容器层”是基于业务层的二次封装,用于提供更契合业务场景的封装接口,比如,在“容器层”对埋点逻辑(比如用户点击一个按键之后触发相应的时间发送到客户端,客户端向服务端上报相应消息)、响应式逻辑(比如响应于用户的拖拉操作,在相应位置显示可视化组件)、路由跳转逻辑(比如响应于用户的点击操作,跳转至另一页面)等逻辑进行实现,从而,开发人员只需要调用这些逻辑的封装接口,大大减少了可视化组件的开发代码量和二次开发工作量。
在第四个层级中,“应用落地”可包括可视化组件处理方法的应用场景和应用设备,其中,应用场景可以应用于不同的应用程序,比如,视频应用程序、电商应用程序等;应用设备可以包括手机、平板、OTT、Mac电脑等。
3、在研发支撑中,可以开发模板文件的开发工具、模板文件的预览工具、模板文件的调试和可视化工具、模板文件的质量监控工具等多种配套工具,以实现模块文件的开发、预览、推送、调试等功能,尤其是可以通过调试工具实现模板文件的秒级生效,使得开发者及时查看到模板文件的显示效果并及时对模板文件进行调整。
参考图9,图9为本申请实施例提供的可视化组件处理***900的结构示意图,如图9所示,可视化组件处理***900包括模板管理模块901、布局模块902和渲染模块903:
模板管理模块901,用于管理可视化组件的模板文件,模板文件包括第一文件和第二文件,第一文件中包含可视化组件中视图元素的元素类型和不同的视图元素之间的层级关系,第二文件中包含视图元素的布局信息和视图元素的样式信息;
布局模块902和渲染模块903,用于基于模板文件和类型对应关系,确定视图元素的目标信息,并基于视图元素的目标信息,在页面上显示可视化组件。其中,类型对应关系包括视图元素的元素类型与终端的原生视图元素类型的对应关系。
其中,布局模块902用于确定视图元素的目标信息中的层级关系和目标布局信息,渲染模块903用于视图元素的目标信息中的原生视图元素类型和样式信息。
其中,如图9所示,模板文件由开发人员开发得到。
在本申请的一个实施例中,模板管理模块901用于包括管理可视化组件的模板文件的状态(比如模块文件是否可用)和/或模块文件的加载顺序(即获取顺序)。具体的,如图9所示,模板管理模块901可用于远程模板文件的同步、本地模块文件的加载以及模板文件的状态管理,从而,可基于模板管理模块901实现模板文件的动态下发。
进一步的,模板管理模块901又可以称为模板管理器,如图10所示,模板管理器可包括内存模板管理器、远程模板管理器和本地模板管理器,各个管理器分别对应有数据库,以用于存储各个管理器分别管理的模板文件,其中,模板管理器、内存模板管理器、远程模板管理器和本地模板管理器可以参照前述实施例的描述。其中,图10为可视化组件处理***900中模板管理模块901和布局模块902的结构示意图。
如图10所示,远程模板管理器可基于业务环境和版本需求,对服务端下发的远程模板文件进行条件检查,将满足合业务环境和版本需求的远程模板文件同步加载至终端。其中,远程模板管理器可以在闲时任务(比如在客户端启动后的一段时间内)进行远程模板文件的同步,并采用非阻塞队列的方式将远程模板文件加载至内存中以备使用。
在本申请的一个实施例中,模板管理模块901具体用于:响应于显示页面的请求,在本地已下载的远程模板文件中和/或在本地资源目录下,获取可视化组件的模板文件。
在本申请的一个实施例中,布局模块902具体用于:根据第一文件中视图元素的层级关系和第二文件中视图元素的布局信息,构建虚拟节点树,虚拟节点树的节点为视图元素;对虚拟节点树进行绝对布局处理,得到更新后的虚拟节点树,更新后的虚拟节点树中的节点携带有视图元素的目标布局信息。
如图9所示,在布局模块902中,对模板文件进行解析,构建虚拟节点树,并通过布局计算(即绝对布局处理),得到节点符合绝对布局的虚拟节点树,具体可参照前述方法实施例,不再赘述。从而,通过绝对布局转换,得到适合原生***的布局信息。
如图10所示,模板管理器将模板文件传递至布局模块902,在布局模块中对模板文件进行解析(前述实施例中对第一文件、第二文件、第三文件的解析)、构建虚拟节点树、通过布局计算的方式得到布局产物,即节点符合绝对布局的虚拟节点树。
在本申请的一个实施例中,在根据第一文件中视图元素的层级关系和第二文件中视图元素的布局信息,构建虚拟节点树之前,布局模块902还用于:根据第二文件,在视图元素中确定不具备样式信息的目标视图元素;对目标视图元素进行移除。
在本申请的一个实施例中,渲染模块903具体用于:根据类型对应关系和更新后的虚拟节点树,创建视图树并确定视图树中节点的原生视图元素类型,视图树中的节点为视图元素;根据视图树和第二文件中视图元素的样式信息,更新视图树,更新的视图树携带有视图元素的目标信息。
在本申请的一个实施例中,渲染模块903具体用于:根据视图元素的样式信息,为视图树中相应的节点绑定样式信息。
在本申请的一个实施例中,模板文件还包括第三文件,第三文件中包含视图元素的数据绑定逻辑,在根据视图元素的样式信息,为视图树中节点增加样式信息之后,渲染模块903还用于:根据视图元素的数据绑定逻辑,确定用于渲染视图元素的资源数据;根据视图元素的资源数据,为视图树中相应的节点绑定资源数据。
如图9所示,在渲染模块903中,基于虚拟节点树,构建视图树,还用于为视图树进行样式绑定(即为视图树中的节点添加样式信息)、数据绑定(即为视图树中的节点添加资源数据)、事件绑定(比如为视图树中的节点绑定点击、长点击等时间)和动画绑定(比如为视图树中的节点绑定短视频)。
进一步的,如图9所示,可视化组件处理***900还包括基础库904,是用于作为渲染模块的资源,支撑为节点绑定的样式信息、事件、动画的实现,基础库属于页面所属应用程序,由后端开发人员开发得到,在此对基础库的具体实现不做限制。
进一步的,可视化组件处理***900还包括表达式模块905,用于实现第三文件中每个视图元素的视图绑定逻辑中表达式的运算,表达式模块905例如包括常量运算、关系表达式、取值运算和变量运算。其中,第三文件和表达式可参照前述实施例,在此不再赘述。
进一步的,如图9所示,布局模块902将虚拟节点树传递至渲染模块903,以在渲染模块903中对虚拟节点树做进一步处理,渲染模块903在处理虚拟节点树的过程中,如果发现有节点对应的视图元素需要进行布局的自适应调整,则可以向布局模块发送布局的自适应调整指令,以触发布局模块902对该节点重选进行布局。
如图11所示,布局模块902(图11未示出)将虚拟节点树传递至渲染模块903,在渲染模块中,可遍历虚拟节点树构建视图树(例如采用递归方式构建),接着,为视图树绑定样式信息、数据、事件、动画,得到最终的视图树,也即可视化组件最终的视图。
如图11所示,在绑定资源数据的过程中可采用表达式模块905进行数据运算处理得到资源数据,将运算处理的资源数据返回至渲染模块903。在图11中,作为示例的,可依次通过JSON表达式、布尔表达式、数字表达式、字符串表达式、拼接表达式、条件表达式、文本表达式、函数表达式等多个表达式进行运算,得到资源数据。其中,图11为可视化组件处理***900中渲染模块903和表达式模块905的结构示意图。
在一些实施例中,渲染模块903还用于:根据视图元素的目标信息,将视图元素绘制在同一张图像上;在页面上,对图像进行显示。
在一些实施例中,如图9所示,可视化组件处理***900还包括上下文存储模块906,其中,上下文存储模块906包括状态存储和参数存储,具体可参照前述实施例,不再赘述。
本申请实施例提供的可视化组件处理***,用于执行上述任一方法实施例中的技术方案,其实现原理和技术效果类似,在此不再赘述。
参考图12,图12为本申请实施例提供的可视化组件处理装置120的结构框图。如图12所示,本申请实施例提供的可视化组件处理装置120包括:确定单元121、处理单元122和显示单元123:
确定单元121,用于在终端上,确定页面上可视化组件的模板文件,模板文件包括第一文件和第二文件,第一文件中包含可视化组件中视图元素的元素类型和不同的视图元素之间的层级关系,第二文件中包含视图元素的布局信息和视图元素的样式信息;
处理单元122,用于根据模板文件和类型对应关系,确定视图元素的目标信息,类型对应关系包括视图元素的元素类型与终端的原生视图元素类型的对应关系,目标信息包括视图元素的层级关系、视图元素的目标布局信息、视图元素的目标样式信息以及视图元素对应的原生视图元素类型;
显示单元123,用于基于视图元素的目标信息,在页面上显示可视化组件。
在本申请的一个实施例中,处理单元122具体用于:根据第一文件中视图元素的层级关系和第二文件中视图元素的布局信息,构建虚拟节点树,虚拟节点树的节点为视图元素;对虚拟节点树进行绝对布局处理,得到更新后的虚拟节点树,更新后的虚拟节点树中的节点携带有视图元素的目标布局信息;根据类型对应关系和更新后的虚拟节点树,创建视图树并确定视图树中节点的原生视图元素类型,视图树中的节点为视图元素;根据视图树和第二文件中视图元素的样式信息,更新视图树,更新的视图树携带有视图元素的目标信息。
在本申请的一个实施例中,在根据视图树和第二文件中视图元素的样式信息,更新视图树的过程中,处理单元122具体用于:根据视图元素的样式信息,为视图树中相应的节点绑定样式信息。
在本申请的一个实施例中,模板文件还包括第三文件,第三文件中包含视图元素的数据绑定逻辑,在根据视图元素的样式信息,为视图树中相应的节点绑定样式信息之后,处理单元122还用于:根据视图元素的数据绑定逻辑,确定用于渲染视图元素的资源数据;根据视图元素的资源数据,为视图树中相应的节点绑定资源数据。
在本申请的一个实施例中,在根据第一文件中视图元素的层级关系和第二文件中视图元素的布局信息,构建虚拟节点树之前,处理单元122还用于:根据第二文件,在视图元素中确定不具备样式信息的目标视图元素;对目标视图元素进行移除。
在本申请的一个实施例中,显示单元123具体用于:根据视图元素的目标信息,将视图元素绘制在同一张图像上;在页面上,对图像进行显示。
在本申请的一个实施例中,确定单元121具体用于:终端响应于显示页面的请求,在本地已下载的远程模板文件中和/或在本地资源目录下,获取可视化组件的模板文件。
本申请实施例提供的可视化组件处理装置,用于执行上述任一方法实施例中的技术方案,其实现原理和技术效果类似,在此不再赘述。
图13为本申请实施例提供的电子设备的硬件结构示意图。如图13所示,本申请实施例的电子设备130可以包括:至少一个处理器131(图13中仅示出了一个处理器);以及,与至少一个处理器通信连接的存储器132。其中,存储器132存储有可被至少一个处理器131执行的指令,指令被至少一个处理器131执行,以使电子设备130能够执行前述任一方法实施例中的技术方案。
可选的,存储器132既可以是独立的,也可以跟处理器131集成在一起。
当存储器132是独立于处理器131之外的器件时,电子设备130还包括:总线133,用于连接存储器132和处理器131。
可选的,电子设备130为移动终端。
本申请实施例提供的电子设备可以执行前述任一方法实施例的技术方案,其实现原理和技术效果类似,在此不再赘述。
本申请实施例还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机程序,当计算机程序被处理器执行时用于实现前述任一方法实施例中的技术方案。
本申请实施例提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现前述任一方法实施例中的技术方案。
本申请实施例还提供了一种芯片,包括:处理模块与通信接口,该处理模块能执行前述方法实施例中的技术方案。
进一步地,该芯片还包括存储模块(如,存储器),存储模块用于存储指令,处理模块用于执行存储模块存储的指令,并且对存储模块中存储的指令的执行使得处理模块执行前述方法实施例中的技术方案。
应理解,上述处理器可以是中央处理单元(英文:Central Processing Unit,简称:CPU),还可以是其他通用处理器、数字信号处理器(英文:Digital Signal Processor,简称:DSP)、专用集成电路(英文:Application Specific Integrated Circuit,简称:ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速RAM存储器,也可能还包括非易失性存储NVM,例如至少一个磁盘存储器,还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。
总线可以是工业标准体系结构(Industry Standard Architecture,ISA)总线、外部设备互连(Peripheral Component,PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture,EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示,本申请附图中的总线并不限定仅有一根总线或一种类型的总线。
上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits,简称:ASIC)中。当然,处理器和存储介质也可以作为分立组件存在于电子设备中。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。