CN114115870A - 用户接口界面实现方法及装置 - Google Patents

Abstract

本申请实施例提供了一种用户接口界面实现方法及装置，涉及终端技术领域。第一应用的应用安装包包括用于对第一应用的UI进行界面描述和界面行为定义的第一描述文件和第二描述文件；第一描述文件和第二描述文件采用不同的界面描述语言；其中，第一描述文件采用第一界面描述语言，第二描述文件采用第二界面描述语言。电子设备运行第一应用时；第一UI引擎读取、解析和执行第一描述文件，生成第一UI的第一部分；第二UI引擎读取、解析和执行第二描述文件，生成第一UI的第二部分。第一UI引擎可以为通用的操作***引擎，第二UI引擎与操作***平台不相关，能够适应多种操作***平台，且技术实现难度低。

Description

用户接口界面实现方法及装置

本申请要求于2020年08月25日提交国家知识产权局、申请号为202010862489.9、申请名称为“一种用户接口界面实现方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

本申请要求于2020年09月30日提交国家知识产权局、申请号为202011064544.6、申请名称为“一种用户接口界面实现方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

本申请要求于2020年10月22日提交国家知识产权局、申请号为202011141010.9、申请名称为“一种用户接口界面实现方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

本申请要求于2020年10月22日提交国家知识产权局、申请号为202011142718.6、申请名称为“一种用户接口界面实现方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

本申请要求于2020年11月30日提交国家知识产权局、申请号为202011381146.7、申请名称为“一种用户接口界面实现方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

本申请要求于2020年11月30日提交国家知识产权局、申请号为202011384490.1、申请名称为“一种用户接口界面实现方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及终端技术领域，尤其涉及一种用户接口界面实现方法及装置。

背景技术

开发者通常会基于某一个操作***(operator system，OS)平台开发应用程序(application，App)。在App开发过程中，一个很重要的任务就是开发App的用户接口界面(user interface，UI)。通常，开发者使用OS平台提供的软件开发包(softwaredevelopment kit，SDK)开发App的UI。UI开发主要包括界面描述和界面行为定义。界面描述是指使用界面描述语言描述UI的布局(layout)，使用的控件，以及布局和控件的视觉风格等。界面行为定义是指使用界面描述语言定义界面行为；界面行为包括UI的动态变化，以及电子设备对UI动态变化的响应(比如对用户在UI上操作的响应)。各个OS平台有其对应的界面描述语言；例如

使用xml(extensible markup language，可扩展标记语言)格式，

使用swift构建的嵌入式领域专用语言(embedded domain specific language，EDSL)进行界面描述和界面行为定义。OS平台提供的UI引擎可以解释执行UI的界面描述语言，渲染出UI呈现给用户。并且，各个OS平台还有对应的程序语言用于实现界面行为，实现UI的动态变化以及响应用户对UI的操作；例如

使用JAVA，

使用swift编程语言实现界面行为。

如何为开发者提供便利，使得开发者方便的开发出与操作***适配且功能丰富的UI，是需要解决的问题。

发明内容

本申请实施例提供一种用户接口界面实现方法及装置，可以提供丰富的UI编程能力，为开发者开发出与操作***适配且功能丰富的UI提供便利。为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种用户接口界面实现方法，包括：电子设备第一应用的应用安装包，应用安装包包括第一描述文件和第二描述文件；其中，第一描述文件和第二描述文件用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义；第一描述文件采用第一界面描述语言，第二描述文件采用第二界面描述语言；第一界面描述语言与第二界面描述语言不同。电子设备运行第一应用；其中，电子设备的第一UI引擎读取、解析和执行第一描述文件，生成第一UI的第一部分；电子设备的第二UI引擎读取、解析和执行第二描述文件，生成第一UI的第二部分；电子设备显示第一UI。

在该方法中，支持使用两种不同的界面描述语言共同开发UI。电子设备的操作***包括两个UI引擎，分别解析和执行两种不同的界面描述语言。其中一个UI引擎可以是通用OS(比如

)的UI引擎，可以解析通用的界面描述语言；另一个UI引擎是与OS平台不相关的扩展UI引擎，可以解析DSL。这样，开发者可以使用基础界面描述语言描述UI布局、包括的控件等；并且选择性使用DSL将自定义UI编程能力应用于一些控件，在UI增加一些动效等。本申请实施例提供的扩展UI引擎与OS平台不相关，故能适应多种OS平台，技术实现难度低，方便开发者使用。

在一种可能的实现方式中，电子设备的第一UI引擎生成第一UI的第一部分包括：电子设备的第一UI引擎根据第一描述文件生成第一UI中一个或多个第一控件；其中，一个或多个第一控件具备第一UI编程能力。

该第一控件即通用OS(比如

)生成的控件。第一UI编程能力是通用OS(比如

)支持的UI编程能力。比如，包括设置控件的长、宽、高，间距，颜色；选中控件，在控件上输入文字等。

在一种可能的实现方式中，电子设备的第二UI引擎生成第一UI的第二部分包括：电子设备的第二UI引擎根据第二描述文件对一个或多个第一控件应用第二UI编程能力。也就是说，开发者可以使用自定义界面描述语言在第二描述文件中对通用OS生成的控件应用自定义的UI编程能力，扩展通用OS控件的能力，丰富通用OS控件的使用效果。

在一种可能的实现方式中，电子设备的第二UI引擎生成第一UI的第二部分包括：电子设备的第二UI引擎根据第二描述文件生成第一UI中一个或多个第二控件；其中，一个或多个第二控件具备第二UI编程能力。

该第二控件为本申请实施例中OEM OS提供的自定义控件，支持自定义的第二UI编程能力，支持丰富的控件效果。

在一种可能的实现方式中，第二UI编程能力包括：视觉属性能力，布局能力，统一交互能力和动效能力中至少一种。

其中，布局能力用于描述UI中控件的布局；比如控件的形状、位置、大小等。视觉属性能力用于描述控件的视觉属性；比如，控件的颜色、灰度等视觉效果。统一交互能力用于基于用户行为提供控件响应；比如基于用户的“确认”行为执行搜索。动效能力用于在控件上显示动画效果；比如在控件上显示点击回弹动效等。

在一种可能的实现方式中，布局能力包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。其中，拉伸是指控件的宽度和高度按照不同的比例进行放大或缩小的显示能力；隐藏是指控件在显示界面中可见或不可见的显示能力；折行是指控件中的内容在显示界面中通过一行或多行显示的显示能力；均分是指控件在显示界面中均匀分布的显示能力；占比是指控件在指定方向上按照指定的百分比占据总布局的能力；延伸是指控件在UI上按照一个方向上排列显示的能力。

在一种可能的实现方式中，若第二UI引擎确定存在第二描述文件，触发第一UI引擎读取第一描述文件，第二UI引擎读取第二描述文件。也就是说，由第二UI引擎控制分发流程，触发第一UI引擎和第二UI引擎解析执行描述文件。

在一种可能的实现方式中，第一描述文件与第二描述文件在应用安装包中不同路径。第一UI引擎和第二UI引擎按照预设规则分别读取不同路径下的描述文件。

在一种可能的实现方式中，第一描述文件与第二描述文件被预置不同的标签。第一UI引擎和第二UI引擎按照预置标签分别读取相应的描述文件。

在一种可能的实现方式中，第二UI引擎还对第二界面描述语言进行语法校验；若语法校验通过，第二UI引擎解析和执行第二描述文件。

在一种可能的实现方式中，电子设备的第二UI引擎实现器件事件与第二描述文件中用户行为之间的映射；响应于器件事件，执行第二描述文件中用户行为对应的控件动作。也就是说，OEM OS可以将不同形态的电子设备触发的事件映射为同一用户行为(比如，将PC上的鼠标双击事件映射为“确认”行为，将手机上的手指单击事件映射为“确认”行为)，避免开发者针对不同形态的电子设备定义器件事件和用户行为的对应关系，带来重复劳动；使得同一描述文件可以适用于多种形态的电子设备，降低开发难度，为开发者带来便利。

在一种可能的实现方式中，第二UI引擎包括第二描述文件中字段的语法语义规范集合。这样，开发者可以按照OEM OS的语法语义规范在OEM OS平台开发UI。

在一种可能的实现方式中，第一界面描述语言为可扩展标记语言xml语言，第二界面描述语言为领域专用语言DSL。

第二方面，本申请提供一种用户接口界面实现方法，包括：显示第一应用的开发界面；第一应用的开发界面包括第一描述文件和第二描述文件；第一描述文件和第二描述文件用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义；第一描述文件采用第一界面描述语言，第二描述文件采用第二界面描述语言；第一界面描述语言与第二界面描述语言不同；响应于用户输入的第一操作，在第一描述文件中增加对第一UI的第一部分的描述；响应于用户输入的第二操作，在第二描述文件中增加对第一UI的第二部分的描述；根据第一描述文件和第二描述文件生成第一应用的应用安装包。

在该方法中，开发者可以使用两种不同的界面描述语言共同开发UI。其中一种语言是通用OS(比如

)支持的基础界面描述语言，另一种语言是自定义界面描述语言。开发者可以使用基础界面描述语言描述UI布局、包括的控件等；并且选择性使用DSL将自定义UI编程能力应用于一些控件，在UI增加一些动效等。由于自定义界面描述语言与OS平台不相关，故能适应多种OS平台，技术实现难度低，方便开发者使用。

在一种可能的实现方式中，在第一描述文件中增加对第一UI的第一部分的描述包括：在第一描述文件中增加对第一UI中一个或多个第一控件的描述；对一个或多个第一控件应用第一UI编程能力。

该第一控件为通用OS(比如

)支持的控件。第一UI编程能力是通用OS(比如

)支持的UI编程能力。比如，包括设置控件的长、宽、高，间距，颜色；选中控件，在控件上输入文字等。

在一种可能的实现方式中，在第二描述文件中增加对第一UI的第二部分的描述包括：在第二描述文件中增加对一个或多个第一控件的描述；对一个或多个第一控件应用第二UI编程能力。

也就是说，开发者可以使用自定义界面描述语言在第二描述文件中对通用OS生成的控件应用自定义的UI编程能力，扩展通用OS控件的能力，丰富通用OS控件的使用效果。

在一种可能的实现方式中，在第二描述文件中增加对第一UI的第二部分的描述包括：在第二描述文件中增加对一个或多个第二控件的描述；对一个或多个第二控件应用第二UI编程能力。该第二控件为本申请实施例中OEM OS提供的自定义控件，支持自定义的第二UI编程能力，支持丰富的控件效果。

在一种可能的实现方式中，第二UI编程能力包括：视觉属性能力，布局能力，统一交互能力和动效能力中至少一种。

在一种可能的实现方式中，布局能力包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

在一种可能的实现方式中，第一描述文件与第二描述文件在应用安装包中不同路径。这样，OEM OS的第一UI引擎和第二UI引擎可以按照预设规则分别在不同路径下读取文件，获取对应的描述文件。

在一种可能的实现方式中，第一描述文件与第二描述文件被预置不同的标签。这样，OEM OS的第一UI引擎和第二UI引擎可以按照预置标签分别读取相应的描述文件。

第三方面，本申请提供一种计算机可读存储介质，包括计算机指令，该计算机指令用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义，其中，计算机指令包括存储于第一描述文件中的第一指令，以及存储于第二描述文件中的第二指令；第一描述文件采用第一界面描述语言，第二描述文件采用第二界面描述语言；第一界面描述语言与第二界面描述语言不同；第一指令用于描述第一UI的第一部分，第二指令用于描述第一UI的第二部分。

在该方法中，开发者使用两种不同的界面描述语言共同开发UI。其中一种界面描述语言是通用OS(比如

)支持的基础界面描述语言，另一种界面描述语言是自定义界面描述语言。开发者使用基础界面描述语言描述UI布局、包括的控件等；并且选择性使用DSL将自定义UI编程能力应用于一些控件，在UI增加一些动效等。由于自定义界面描述语言与OS平台不相关，故能适应多种OS平台，技术实现难度低，方便开发者使用。

在一种可能的实现方式中，第一指令具体用于：描述第一UI中一个或多个第一控件，对一个或多个第一控件应用第一UI编程能力。

该第一控件为通用OS(比如

)支持的控件。第一UI编程能力是通用OS(比如

)支持的UI编程能力。比如，包括设置控件的长、宽、高，间距，颜色；选中控件，在控件上输入文字等。

在一种可能的实现方式中，第二指令具体用于：对一个或多个第一控件应用第二UI编程能力。在另一种可能的实现方式中，第二指令具体用于：描述第一UI中一个或多个第二控件，对一个或多个第二控件应用第二UI编程能力。

也就是说，开发者可以使用自定义界面描述语言在第二描述文件中对通用OS生成的控件应用自定义的UI编程能力，扩展通用OS控件的能力；也可以增加具备丰富控件效果的自定义控件。

在一种可能的实现方式中，第二UI编程能力包括：视觉属性能力，布局能力，统一交互能力和动效能力中至少一种。布局能力包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

在一种可能的实现方式中，第一描述文件与第二描述文件在计算机可读存储介质中不同路径。这样，OEM OS的第一UI引擎和第二UI引擎可以按照预设规则分别在不同路径下读取文件，获取对应的描述文件。

在一种可能的实现方式中，第一描述文件与第二描述文件被预置不同的标签。这样，OEM OS的第一UI引擎和第二UI引擎可以按照预置标签分别读取相应的描述文件。

第四方面，本申请提供一种计算机可读存储介质，例如，应用开发工具，该应用开发工具具体可包括计算机指令，当计算机指令在上述电子设备上运行时，可使电子设备执行上述第一方面中任意一项所述的方法。

第五方面，本申请提供一种电子设备，包括：显示屏、输入设备、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与输入设备、显示屏以及存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当电子设备运行时，处理器可执行存储器存储的一个或多个计算机程序，以使电子设备执行上述第一方面中任意一项所述的方法。

第六方面，本申请提供一种电子设备，包括：显示屏、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与显示屏以及存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当电子设备运行上述第一应用时，处理器可执行存储器存储的一个或多个计算机程序，以使电子设备执行上述第二方面中任意一项所述的方法。

本申请实施例提供一种用户接口界面实现方法及装置，可以实现一次开发，多设备部署；即开发一套界面描述文件，适用于各种不同类型的电子设备；降低开发者的开发难度。为达到上述目的，本申请采用如下技术方案：

第七方面，本申请提供一种用户接口界面实现方法，包括：第一电子设备和第二电子设备分别从服务器下载第一应用的应用安装包；并分别安装所述应用安装包。该应用安装包包括描述文件和资源文件；其中，描述文件用于对第一应用的第一UI进行界面描述和界面行为定义；资源文件包括生成第一应用的UI使用的资源。第一电子设备读取描述文件中与第一电子设备的设备类型对应的第一代码，按照第一代码的定义使用资源文件的资源生成第一电子设备的第一UI；第二电子设备读取描述文件中与第二电子设备的设备类型对应的第二代码，按照第二代码的定义使用资源文件的资源生成第二电子设备的第一UI；第一电子设备的设备类型与第二电子设备的设备类型不同。其中，电子设备的设备类型可以包括手机、智能电视、智能手表、平板电脑、笔记本电脑、上网本、大屏、车载电脑等。

在该方法中，不同类型的电子设备读取同一UI的同一个描述文件，呈现不同的UI布局。可以实现开发一套描述文件，适用于各种不同类型的电子设备，降低了开发者的开发难度。

结合第七方面，在一种可能的实现方式中，该方法还包括：第一电子设备按照描述文件中第三代码的定义生成第一电子设备的第一UI中第一控件，第一电子设备的第一UI中第一控件具备第一电子设备的操作***自定义的控件属性；第三电子设备按照描述文件中第三代码的定义生成第三电子设备的第一UI中第一控件，第三电子设备的第一UI中第一控件具备通用操作***的控件属性；其中，第三代码是第一代码的部分或全部。

在该方法中，描述文件中定义第一控件支持操作***自定义的控件属性。第一电子设备的操作***提供自定义的控件属性，第一电子设备的第一UI中第一控件具备第一电子设备的操作***自定义的控件属性；第三电子设备支持通用操作***(比如

)的控件属性，第三电子设备的第一UI中第一控件具备通用操作***的控件属性。这样，同一描述文件可以在不同的操作***中成功运行，实现了跨操作***平台运行，降低开发者开发难度。

第八方面，本申请提供一种用户接口界面实现方法，包括：第一电子设备下载第一应用的应用安装包；并安装该应用安装包；其中，应用安装包包括描述文件和资源文件；描述文件用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义；资源文件包括生成第一应用的UI使用的资源。第一电子设备读取描述文件中与第一电子设备的设备类型对应的第一代码，按照第一代码的定义使用资源文件的资源生成第一电子设备的第一UI。

在该方法中，电子设备读取描述文件中与该电子设备的设备类型相对应的代码。这样，不同的电子设备读取同一描述文件可以呈现不同的UI布局。可以实现开发一套描述文件，适用于各种不同类型的电子设备，降低了开发者的开发难度。

结合第八方面，在一种可能的实现方式中，第一电子设备按照描述文件中第三代码的定义生成第一电子设备的第一UI中第一控件，第一电子设备的第一UI中第一控件具备第一电子设备的操作***自定义的控件属性；其中，第三代码是第一代码的部分或全部。

在该方法中，描述文件中定义第一控件支持操作***自定义的控件属性。第一电子设备的操作***提供自定义的控件属性，第一电子设备的第一UI中第一控件具备第一电子设备的操作***自定义的控件属性。

结合第七方面或第八方面，在一种可能的实现方式中，第一电子设备的操作***包括自定义UI编程能力，自定义UI编程能力用于提供第一电子设备的操作***自定义的控件属性。

结合第七方面或第八方面，在一种可能的实现方式中，自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

结合第七方面或第八方面，在一种可能的实现方式中，布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

结合第七方面或第八方面，在一种可能的实现方式中，第一电子设备的第一UI包括第二控件，第二控件具备通用操作***的控件属性。也就是说，第一电子设备根据描述文件生成的第一UI中既可以包括具备第一电子设备的操作***自定义的控件属性的控件，也可以包括具备通用操作***的控件属性的控件。提供了形态更丰富的控件。

结合第七方面或第八方面，在一种可能的实现方式中，第一电子设备的第一UI包括第三控件，第三控件具备第一应用中自定义的控件属性。在该方法中，开发者可以在安装包的文件中自定义属于该第一应用的控件属性，使得UI更丰富。

结合第七方面或第八方面，在一种可能的实现方式中，描述文件包括***码，用于定义第一电子设备的第一UI中第四控件的控件属性与第一电子设备的操作***中第一数据的对应关系。该方法还包括：第一电子设备接收用户在第四控件上的第一输入；根据第一输入修改第一数据的值。

在该方法中，开发者在描述文件中定义控件的控件属性与操作***中后台数据的对应关系；电子设备的UI引擎实现根据用户输入修改后台数据的功能。避免了开发者在描述文件中描述根据用户输入修改后台数据的实现，降低了开发者的开发难度。

结合第七方面或第八方面，在一种可能的实现方式中，该方法还包括：第一电子设备的第一UI中第四控件的控件属性随着第一电子设备的操作***中第一数据的改变而改变。

在该方法中，开发者在描述文件中定义控件的控件属性与操作***中后台数据的对应关系；电子设备的UI引擎实现控件的控件属性随着电子设备的操作***中后台数据的改变而改变。UI中的控件可以随着电子设备参数的改变而改变，并且避免了开发者在描述文件中描述控件的控件属性随着电子设备参数改变而改变的实现，降低了开发者的开发难度。

第九方面，本申请提供一种用户接口界面实现方法，包括：显示第一应用的开发界面；该第一应用的开发界面包括描述文件，用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义；响应于用户输入的第一操作，在描述文件中增加与第一电子设备的设备类型对应的第一代码；响应于用户输入的第二操作，在描述文件中增加与第二电子设备的设备类型对应的第二代码；根据所述描述文件生成所述第一应用的应用安装包。其中，第一电子设备的设备类型与第二电子设备的设备类型不同。其中，电子设备的设备类型可以包括手机、智能电视、智能手表、平板电脑、笔记本电脑、上网本、大屏、车载电脑等。

在该方法中，一个描述文件中包括对应不同类型的电子设备的代码。不同类型的电子设备读取同一UI的同一个描述文件，即可呈现不同的UI布局。可以实现开发一套描述文件，适用于各种不同类型的电子设备，降低了开发者的开发难度。

结合第九方面，在一种可能的实现方式中，第一应用的应用安装包还包括资源文件，资源文件包括生成第一应用的UI使用的资源。

结合第九方面，在一种可能的实现方式中，描述文件中包括定义第一控件具备第一电子设备的操作***自定义的控件属性的第三代码，以及定义第二控件具备通用操作***的控件属性的***码。也就是说，电子设备根据描述文件生成的第一UI中既可以包括具备第一电子设备的操作***自定义的控件属性的控件，也可以包括具备通用操作***的控件属性的控件。提供了形态更丰富的控件。

结合第九方面，在一种可能的实现方式中，第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

结合第九方面，在一种可能的实现方式中，布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

第十方面，本申请提供一种计算机可读存储介质，例如，应用开发工具，该应用开发工具具体可包括计算机指令，当计算机指令在上述电子设备上运行时，可使电子设备执行上述第九方面中任意一项所述的方法。

第十一方面，本申请提供一种计算机可读存储介质，包括计算机指令，该计算机指令用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义；其中，计算机指令包括与第一电子设备的设备类型对应的第一代码以及与第二电子设备的设备类型对应的第二代码；其中第一电子设备的设备类型与第二电子设备的设备类型不同。其中，电子设备的设备类型可以包括手机、智能电视、智能手表、平板电脑、笔记本电脑、上网本、大屏、车载电脑等。

结合第十一方面，在一种可能的实现方式中，计算机指令还包括生成第一应用的UI使用的资源。

结合第十一方面，在一种可能的实现方式中，计算机指令还包括定义第一控件具备第一电子设备的操作***自定义的控件属性的第三代码，以及定义第二控件具备通用操作***的控件属性的***码。

第十二方面，本申请提供一种电子设备，包括：显示屏、输入设备、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与输入设备、显示屏以及存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当电子设备运行时，处理器可执行存储器存储的一个或多个计算机程序，以使电子设备执行上述第八方面中任意一项所述的方法。

第十三方面，本申请提供一种电子设备，包括：显示屏、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与显示屏以及存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当电子设备运行上述第一应用时，处理器可执行存储器存储的一个或多个计算机程序，以使电子设备执行上述第九方面中任意一项所述的方法。

本申请实施例提供一种用户接口界面实现方法及装置，支持应用小组件的UI上显示各种布局方式和控件类型，方便用户使用应用小组件，提高用户体验。为达到上述目的，本申请采用如下技术方案：

第十四方面，本申请提供一种用户接口界面实现方法，包括：电子设备的第一应用进程读取组件界面描述文件，并根据组件界面描述文件生成第一小组件UI数据，将第一小组件UI数据中的控件与电子设备操作***中的后台数据进行绑定；其中，组件界面描述文件用于对第一应用的应用小组件的第一UI进行界面描述和界面行为定义；然后，第一应用进程向应用小组件进程发送第一数据；应用小组件进程接收第一数据，根据第一数据获取第一小组件UI数据，并按照第一小组件UI数据显示应用小组件的第一UI。

在该方法中，应用进程和应用小组件进程都根据组件界面描述文件生成小组件UI数据。应用进程将小组件UI数据中的控件绑定后台数据，应用小组件进程将小组件UI数据显示为应用小组件UI。这样，开发者可以在组件界面描述文件中定义各种类型的控件，使得应用小组件的UI支持各种类型的控件。当用户在应用小组件的UI上进行操作时，应用进程可以根据小组件UI数据中的控件与后台数据的对应关系执行相应的业务逻辑。

在一种可能的实现方式中，第一应用进程向应用小组件进程发送的是组件界面描述文件；应用小组件进程接收到组件界面描述文件，根据组件界面描述文件生成第一小组件UI数据，并按照第一小组件UI数据显示应用小组件的第一UI。

在一种可能的实现方式中，第一应用进程向应用小组件进程发送的是第一小组件UI数据；应用小组件进程接收到第一小组件UI数据，按照第一小组件UI数据显示应用小组件的第一UI。

结合第十四方面，在一种可能的实现方式中，该方法还包括：第一应用进程按照组件界面描述文件中第一代码的定义生成第一小组件UI数据中第一控件，第一控件具备电子设备的操作***原生的控件属性。其中，操作***原生的控件包括：输入框，复选框，滑动选择器，滚动视图，单选按钮，评分条，搜索框，拖动条，或开关等。

也就是说，开发者可以在组件界面描述文件中定义操作***原生的各种控件属性，使得应用小组件的UI支持操作***原生的各种控件。

结合第十四方面，在一种可能的实现方式中，该方法还包括：第一应用进程按照组件界面描述文件中第二代码的定义生成第一小组件UI数据中第二控件，第二控件具备电子设备的操作***中自定义的控件属性。其中，自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

也就是说，开发者可以在组件界面描述文件中定义操作***中自定义的各种控件属性，使得应用小组件的UI支持操作***中自定义的各种控件。

结合第十四方面，在一种可能的实现方式中，组件界面描述文件包括第三代码，用于定义应用小组件的第一UI中第三控件的控件属性与电子设备的操作***中第一数据的对应关系，该方法还包括：电子设备接收用户在第三控件上的第一输入；根据第一输入修改第一数据的值。

结合第十四方面，在一种可能的实现方式中，应用小组件的第一UI中第三控件的控件属性随着电子设备的操作***中第一数据的改变而改变。

结合第十四方面，在一种可能的实现方式中，该方法还包括：电子设备从服务器下载第一应用的应用安装包；该应用安装包包括组件界面描述文件；电子设备使用应用安装包安装第一应用。

在该方法中，组件界面描述文件是从应用安装包获取的。

第十五方面，本申请提供一种用户接口界面实现方法，包括：显示第一应用的开发界面；第一应用的开发界面包括组件界面描述文件；组件界面描述文件用于对第一应用的应用小组件的第一UI进行界面描述和界面行为定义。响应于用户输入的第一操作，在组件界面描述文件中增加定义第一小组件UI中第一控件的第一代码；其中，第一控件具备操作***原生的控件属性；操作***原生的控件包括：输入框，复选框，滑动选择器，滚动视图，单选按钮，评分条，搜索框，拖动条，或开关等。根据组件界面描述文件生成第一应用的应用安装包。

在该方法中，开发者可以在组件界面描述文件中定义控件具备操作***原生的控件属性。使得电子设备上运行的应用小组件的UI包括各种具备操作***原生的控件属性的控件。

结合第十五方面，在一种可能的实现方式中，该方法还包括：响应于用户输入的第二操作，在组件界面描述文件中增加定义第一小组件UI中第二控件的第二代码，第二控件具备操作***中自定义的控件属性；自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。其中，布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

在该方法中，开发者可以在组件界面描述文件中定义控件具备操作***自定义的控件属性。使得电子设备上运行的应用小组件的UI包括各种具备操作***自定义的控件属性的控件。

第十六方面，本申请提供一种计算机可读存储介质，例如，应用开发工具，该应用开发工具具体可包括计算机指令，当计算机指令在上述电子设备上运行时，可使电子设备执行上述第十五方面中任意一项所述的方法。

第十七方面，本申请提供一种计算机可读存储介质，包括计算机指令，该计算机指令用于对第一应用的应用小组件的第一用户接口界面UI进行界面描述和界面行为定义；其中，计算机指令包括生成第一小组件UI中第一控件的第一代码，第一控件具备操作***原生的控件属性；操作***原生的控件包括：输入框，复选框，滑动选择器，滚动视图，单选按钮，评分条，搜索框，拖动条，或开关等。

结合第十七方面，在一种可能的实现方式中，计算机指令还包括生成第一小组件UI中第二控件的第二代码，第二控件具备操作***中自定义的控件属性；自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。其中，布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

第十八方面，本申请提供一种计算机可读存储介质。该计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行上述第十四方面中任意一项所述的方法。

第十九方面，本申请提供一种电子设备，包括：显示屏、输入设备、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与输入设备、显示屏以及存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当电子设备运行时，处理器可执行存储器存储的一个或多个计算机程序，以使电子设备执行上述第十四方面或第十五方面中任意一项所述的方法。

本申请实施例提供一种用户接口界面实现方法及装置，支持将控制设备上各种UI投屏至IoT设备进行播放，提高用户体验。为达到上述目的，本申请采用如下技术方案：

第二十方面，本申请提供一种用户接口界面实现方法，包括：第一电子设备读取第一应用的第一播放端界面描述文件，并根据第一播放端界面描述文件生成第一播放端UI数据，将第一播放端UI数据中的控件与第一电子设备操作***中的后台数据进行绑定；其中，第一播放端界面描述文件用于对在第二电子设备上播放述第一应用的第一播放端UI进行界面描述和界面行为定义；第一电子设备向第二电子设备发送第一数据；第二电子设备接收第一数据，根据第一数据获取第一播放端UI数据，按照第一播放端UI数据显示第一播放端UI。

在该方法中，控制设备和播放端都根据播放端界面描述文件生成播放端UI数据。控制设备将播放端UI数据中的控件绑定后台数据，播放端将播放端UI数据显示为播放端UI。这样，开发者可以在播放端界面描述文件中定义各种UI，使得播放端UI更丰富。还可以为不同设备类型的播放端定义不同的UI布局，使得播放端UI与播放端屏幕的尺寸和形态匹配。当用户在播放端UI上进行操作时，控制设备可以根据播放端UI数据中的控件与后台数据的对应关系执行对应的业务逻辑。

在一种可能的实现方式中，第一电子设备向第二电子设备发送的是第一播放端界面描述文件，第二电子设备根据第一播放端界面描述文件生成第一播放端UI数据，按照第一播放端UI数据显示第一播放端UI。

在一种可能的实现方式中，第一电子设备向第二电子设备发送的是第一播放端UI数据，第二电子设备接收到第一播放端UI数据，按照第一播放端UI数据显示第一播放端UI。

结合第二十方面，在一种可能的实现方式中，该方法还包括：第二电子设备接收用户在第一播放端UI上的第一操作；响应于用户在第一播放端UI上的第一操作，第二电子设备向第一电子设备发送第一指令；第一电子设备接收到第一指令，读取第二播放端界面描述文件，根据第二播放端界面描述文件生成第二播放端UI数据，将第二播放端UI数据中的控件与第一电子设备操作***中的后台数据进行绑定；其中，第二播放端界面描述文件用于对在第二电子设备上播放第一应用的第二播放端UI进行界面描述和界面行为定义；第一电子设备向第二电子设备发送第二播放端界面描述文件；第二电子设备接收第二播放端界面描述文件，根据第二播放端界面描述文件生成第二播放端UI数据，按照第二播放端UI数据显示第二播放端UI。

在该方法中，用户可以直接在播放设备上对播放端UI进行操作，控制设备执行该操作对应的业务逻辑，并向播放设备发送更新的播放端UI对应的播放端界面描述文件，播放设备根据更新的播放端界面描述文件生成更新的播放端UI。实现在播放设备上直接对播放端UI进行操作，成功切换播放端UI。

结合第二十方面，在一种可能的实现方式中，该方法还包括：第二电子设备接收用户在第一播放端UI上的第一操作；响应于用户在第一播放端UI上的第一操作，第二电子设备向第一电子设备发送第一指令；第一电子设备接收到第一指令，读取第二播放端界面描述文件；第二播放端界面描述文件用于对在第二电子设备上播放第一应用的第二播放端UI进行界面描述和界面行为定义；第一电子设备根据第二播放端界面描述文件生成第二播放端UI数据，将第二播放端UI数据中的控件与第一电子设备操作***中的后台数据进行绑定；第一电子设备向第二电子设备发送第二播放端UI数据；第二电子设备接收第二播放端UI数据，按照第二播放端UI数据显示第二播放端UI。

在该方法中，用户可以直接在播放设备上对播放端UI进行操作，控制设备执行该操作对应的业务逻辑，并向播放设备发送更新的播放端UI数据，播放设备根据更新的播放端UI数据更新播放端UI。实现在播放设备上直接对播放端UI进行操作，成功切换播放端UI。

结合第二十方面，在一种可能的实现方式中，该方法还包括：第一电子设备从服务器下载第一应用的应用安装包；应用安装包包括第一播放端界面描述文件和资源文件；资源文件包括生成第一应用的播放端UI使用的资源；第一电子设备使用应用安装包安装第一应用。

结合第二十方面，在一种可能的实现方式中，该方法还包括：第一电子设备读取第一播放端界面描述文件中与第三电子设备的设备类型对应的第一代码，按照第一代码的定义使用资源文件的资源生成第三播放端UI数据；第一电子设备读取第一播放端界面描述文件中与第四电子设备的设备类型对应的第二代码，按照第二代码的定义使用资源文件的资源生成第四播放端UI数据；其中，第四电子设备的设备类型与第三电子设备的设备类型不同。第一电子设备分别向第三电子设备和第四电子设备发送第一播放端界面描述文件和资源文件；第三电子设备根据第一播放端界面描述文件中与第三电子设备的设备类型对应的第一代码的定义使用资源文件的资源生成第三播放端UI数据；按照第三播放端UI数据显示第一播放端UI；第四电子设备根据第一播放端界面描述文件中与第四电子设备的设备类型对应的第二代码的定义使用资源文件的资源生成第四播放端UI数据；按照第四播放端UI数据显示第一播放端UI。

在该方法中，不同类型的播放设备读取同一UI的同一个播放端界面描述文件，呈现不同的播放端UI布局。可以实现开发一套播放端界面描述文件，适用于各种不同类型的播放设备，降低了开发者的开发难度。

结合第二十方面，在一种可能的实现方式中，该方法还包括：第一电子设备读取第一播放端界面描述文件中与第三电子设备的设备类型对应的第一代码，按照第一代码的定义使用资源文件的资源生成第三播放端UI数据；第一电子设备读取第一播放端界面描述文件中与第四电子设备的设备类型对应的第二代码，按照第二代码的定义使用资源文件的资源生成第四播放端UI数据；其中，第四电子设备的设备类型与第三电子设备的设备类型不同。第一电子设备向第三电子设备发送第三播放端UI数据；第三电子设备按照第三播放端UI数据显示第一播放端UI；第一电子设备向第四电子设备发送第四播放端UI数据；第四电子设备按照第四播放端UI数据显示第一播放端UI。

在该方法中，不同类型的播放设备根据同一UI的同一个播放端界面描述文件，呈现不同的播放端UI布局。可以实现开发一套播放端界面描述文件，适用于各种不同类型的播放设备，降低了开发者的开发难度。

结合第二十方面，在一种可能的实现方式中，该方法还包括：第一电子设备按照第一播放端界面描述文件中第三代码的定义生成第一播放端UI中第一控件，第一控件具备第一电子设备的操作***自定义的控件属性；其中，第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

结合第二十方面，在一种可能的实现方式中，该方法还包括：第一电子设备按照第一播放端UI数据显示第一播放端UI。在该方法中，控制设备与播放设备同步播放播放端UI，可以实现镜像投屏，控制设备与播放设备协同工作。

第二十一方面，本申请提供一种用户接口界面实现方法，包括：显示第一应用的开发界面；第一应用的开发界面包括播放端界面描述文件；播放端界面描述文件用于对在播放端播放第一应用的播放端UI进行界面描述和界面行为定义；响应于用户的第一输入，在述播放端界面描述文件中增加与第一电子设备的设备类型对应的第一代码；响应于用户的第二输入，在播放端界面描述文件中增加与第二电子设备的设备类型对应的第二代码；第一电子设备的设备类型与第二电子设备的设备类型不同；根据播放端界面描述文件生成第一应用的应用安装包。

在该方法中，一个播放端界面描述文件中包括对应不同类型的播放设备的代码。不同类型的播放设备读取同一UI的同一个播放端界面描述文件，即可呈现不同的播放端UI布局。可以实现开发一套播放端界面描述文件，适用于各种不同类型的播放设备，降低了开发者的开发难度。

结合第二十一方面，在一种可能的实现方式中，第一应用的应用安装包还包括资源文件，资源文件包括生成第一应用的播放端UI使用的资源。

结合第二十一方面，在一种可能的实现方式中，播放端界面描述文件中包括定义第一播放端UI中第一控件具备第一电子设备的操作***自定义的控件属性的第三代码；第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

第二十二方面，本申请提供一种计算机可读存储介质，例如，应用开发工具，该应用开发工具具体可包括计算机指令，当计算机指令在上述电子设备上运行时，可使电子设备执行上述第二十一方面中任意一项所述的方法。

第二十三方面，本申请提供一种计算机可读存储介质，包括计算机指令，该计算机指令用于对第一应用的第一播放端UI进行界面描述和界面行为定义；其中，计算机指令包括与第一电子设备的设备类型对应的第一代码以及与第二电子设备的设备类型对应的第二代码；其中第一电子设备的设备类型与第二电子设备的设备类型不同。其中，电子设备的设备类型可以包括手机、智能电视、智能手表、平板电脑、笔记本电脑、上网本、大屏、车载电脑等。

结合第二十三方面，在一种可能的实现方式中，计算机指令还包括生成第一应用的播放端UI使用的资源。

结合第二十三方面，在一种可能的实现方式中，计算机指令还包括定义第一播放端UI中第一控件具备第一电子设备的操作***自定义的控件属性的第三代码；第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

第二十四方面，本申请提供一种计算机可读存储介质。该计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行上述第二十方面中任意一项所述的方法。

第二十五方面，本申请提供一种电子设备，包括：显示屏、输入设备、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与输入设备、显示屏以及存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当电子设备运行时，处理器可执行存储器存储的一个或多个计算机程序，以使电子设备执行上述第二十方面或第二十一方面中任意一项所述的方法。

可以理解地，上述各个方面所提供的电子设备以及计算机可读存储介质均应用于上文所提供的对应方法，因此，其所能达到的有益效果可参考上文所提供的对应方法中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的用户接口界面实现方法的场景示意图；

图2为本申请实施例提供的电子设备的硬件结构示意图；

图3为本申请实施例提供的电子设备的软件架构示意图；

图4为一种用户接口界面实现方法的示意图；

图5为一种用户接口界面实现方法的示意图；

图6为本申请实施例提供的用户接口界面实现方法的示意图；

图7为本申请实施例提供的用户接口界面实现方法的架构示意图；

图8为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图9为本申请实施例提供的用户接口界面实现方法的流程示意图；

图10为本申请实施例提供的用户接口界面实现方法的流程示意图；

图11为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图12为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图13为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图14为本申请实施例提供的用户接口界面实现方法的示意图；

图15为本申请实施例提供的电子设备的软件架构示意图；

图16为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图17为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图18为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图19为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图20A为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图20B为本申请实施例提供的用户接口界面实现方法的流程示意图；

图20C为本申请实施例提供的用户接口界面实现方法的示意图；

图21为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图22为本申请实施例提供的用户接口界面实现方法的示意图；

图23为本申请实施例提供的用户接口界面实现方法的场景示意图；

图24A为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图24B为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图24C为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图24D为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图25为本申请实施例提供的用户接口界面实现方法的示意图；

图26为本申请实施例提供的用户接口界面实现方法的示意图；

图27为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图28为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图29A为本申请实施例提供的用户接口界面实现方法的示意图；

图29B为本申请实施例提供的用户接口界面实现方法的示意图；

图29C为本申请实施例提供的用户接口界面实现方法的示意图；

图29D为本申请实施例提供的用户接口界面实现方法的示意图；

图30为本申请实施例提供的用户接口界面实现方法的流程示意图；

图31为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图32为本申请实施例提供的用户接口界面实现方法的流程示意图；

图33为本申请实施例提供的用户接口界面实现方法的场景示意图；

图34为本申请实施例提供的用户接口界面实现方法的示意图；

图35A为本申请实施例提供的用户接口界面实现方法的示意图；

图35B为本申请实施例提供的用户接口界面实现方法的示意图；

图36为本申请实施例提供的用户接口界面实现方法的示意图；

图37A为本申请实施例提供的用户接口界面实现方法的示意图；

图37B为本申请实施例提供的用户接口界面实现方法的示意图；

图38A为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图38B为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图39A为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图39B为本申请实施例提供的用户接口界面实现方法的示意图；

图40A为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图40B为本申请实施例提供的用户接口界面实现方法的示意图；

图40C为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图40D为本申请实施例提供的用户接口界面实现方法的示意图；

图41A为本申请实施例提供的用户接口界面实现方法的流程示意图；

图41B为本申请实施例提供的用户接口界面实现方法的流程示意图；

图42A为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图42B为本申请实施例提供的用户接口界面实现方法的场景实例示意图；

图43为本申请实施例提供的一种电子设备的结构组成示意图。

具体实施方式

以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请以下各实施例中，“至少一个”、“一个或多个”是指一个、两个或两个以上。术语“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。术语“连接”包括直接连接和间接连接，除非另外说明。

请参考图1，电子设备200上安装有应用开发工具(比如，Android Studio，DevEcoStudio等)。通常，开发者使用一种界面描述语言，在应用开发工具中开发UI，形成界面描述文件。本申请中电子设备200也可称为开发者设备。界面描述文件也可称为描述文件。

UI开发主要包括界面描述和界面行为定义。界面描述是指使用界面描述语言描述UI的布局(layout)，使用的控件，以及布局和控件的视觉风格等。界面行为定义是指使用界面描述语言定义界面行为；界面行为包括UI的动态变化，以及电子设备对UI动态变化的响应(比如对用户对UI操作的响应)。各个OS平台有其对应的界面描述语言；例如

使用xml(extensible markup language，可扩展标记语言)格式，

使用swift构建的嵌入式领域专用语言(embedded domain specific language，EDSL)进行界面描述和界面行为定义。

开发者将界面描述文件打包到App的安装包，在服务器300提供的应用市场中发布App。应用市场中可以提供各个App的安装包供用户下载。例如，安装包可以为

应用程序包(Android application package，APK)文件。

以手机为电子设备100举例，用户可使用手机在应用市场中下载某一App的安装包。以视频App举例，手机下载视频App的安装包后，通过运行该安装包可将视频App安装在手机中。这样，手机也获取了安装包中的界面描述文件。手机可以按照界面描述文件构建UI。手机的OS平台提供的UI引擎解释、执行界面描述语言，渲染出UI呈现给用户。手机的显示装置(比如显示屏)上呈现出构建的UI。手机的OS平台还执行实现界面行为的编程语言，实现UI的动态变化以及响应用户对UI的操作。

示例性的，开发者在电子设备200上使用OS平台支持的界面描述语言开发视频App的UI，并发布视频App。用户使用“视频”App的安装包将视频App安装于手机，手机桌面生成“视频”图标101。用户可以点击“视频”图标101，以打开视频App。响应于用户对“视频”图标101的点击操作，手机运行视频App。手机上安装有OS平台，OS平台读取界面描述文件，解析、执行界面描述语言，按照界面描述文件中的界面描述渲染出视频App的UI，并在显示屏呈现视频App的UI 102。进一步的，界面描述文件中还可以包括对界面行为的定义。手机可以响应于用户对UI 102的操作，按照界面描述文件中定义的界面行为，执行相应的界面动作，实现界面行为。通常，OS平台还有对应的程序语言用于实现界面行为，实现UI 102的动态变化以及响应用户对UI 102的操作；例如

使用JAVA，

使用swift编程语言实现界面行为。

可以理解的，在一些实施例中，开发者可以直接在电子设备100上开发App的UI，并在电子设备100上运行该App；即电子设备200和电子设备100可以是同一个电子设备。本申请实施例对此并不进行限定。

上述电子设备100可以包括便携式计算机(如手机等)、手持计算机、平板电脑、笔记本电脑、上网本、个人电脑(personal computer，PC)、智能家居设备(比如，智能电视、智慧屏、大屏、智能音箱等)、个人数字助理(personal digital assistant，PDA)、可穿戴设备(比如，智能手表、智能手环等)、增强现实(augmented reality，AR)\虚拟现实(virtualreality，VR)设备、车载电脑等，本申请实施例对此不做任何限制。电子设备100的示例性实施例包括但不限于搭载

或者其它操作***的便携式电子设备。可以理解的是，在其他一些实施例中，上述电子设备100也可以不是便携式电子设备，而是台式计算机。

示例性的，请参考图2，其示出了一种电子设备100的结构示意图。电子设备100可包括处理器110，外部存储器接口120，内部存储器121，音频模块130，扬声器130A，麦克风130B，显示屏140，无线通信模块150，电源模块160等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元。例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的部件，也可以集成在一个或多个处理器中。在一些实施例中，电子设备100也可以包括一个或多个处理器110。

其中，控制器是电子设备100的神经中枢和指挥中心。可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

应用处理器上可以运行电子设备100的操作***，用于管理电子设备100的硬件与软件资源。比如，管理与配置内存、决定***资源供需的优先次序、控制输入与输出设备、操作网络、管理文件***、管理驱动程序等。操作***也可以用于提供一个让用户与***交互的操作界面。其中，操作***内可以安装各类软件，比如，驱动程序，应用程序(application，App)等。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了***的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路间(inter-integrated circuit，I2C)接口，集成电路间音频(integrated circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，SIM卡接口，和/或USB接口等。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储一个或多个计算机程序，该一个或多个计算机程序包括指令。处理器110可以通过运行存储在内部存储器121的上述指令，从而使得电子设备100执行本申请一些实施例中所提供的用户接口界面实现方法，以及各种应用以及数据处理等。内部存储器121可以包括代码存储区和数据存储区。其中，数据存储区可存储电子设备100使用过程中所创建的数据等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如一个或多个磁盘存储部件，闪存部件，通用闪存存储器(universal flash storage，UFS)等。在一些实施例中，处理器110可以通过运行存储在内部存储器121的指令，和/或存储在设置于处理器110中的存储器的指令，来使得电子设备100执行本申请实施例中所提供的用户接口界面实现方法，以及其他应用及数据处理。

电子设备100可以通过音频模块130，扬声器130A，麦克风130B，以及应用处理器等实现音频功能。例如音乐播放，录音等。音频模块130用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块130还可以用于对音频信号编码和解码。在一些实施例中，音频模块130可以设置于处理器110中，或将音频模块130的部分功能模块设置于处理器110中。

扬声器130A，也称“喇叭”，用于将音频电信号转换为声音信号。

麦克风130B，也称“话筒”，“传声器”，用于将声音信号转换为电信号。用户可以通过人嘴靠近麦克风130B发声，将声音信号输入到麦克风130B。

电子设备100的无线通信功能可以通过天线1，天线2以及无线通信模块150等实现。

无线通信模块150可以提供应用在电子设备100上的包括Wi-Fi，蓝牙(bluetooth，BT)，无线数传模块(例如，433MHz，868MHz，915MHz)等无线通信的解决方案。无线通信模块150可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块150经由天线1或者天线2接收电磁波，将电磁波信号滤波以及调频处理，将处理后的信号发送到处理器110。无线通信模块150还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线1或者天线2转为电磁波辐射出去。

电子设备100通过GPU，显示屏140，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏140和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏140用于显示图像，视频等。显示屏140包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏140，N为大于1的正整数。本申请实施例中，显示屏140可以用于显示UI，以及接收用户对UI的操作。

在一些实施例中，显示屏140上设置有压力传感器170A、触摸传感器170B等。压力传感器170A用于感受压力信号，可以将压力信号转换成电信号。当有触摸操作作用于显示屏140，电子设备100根据压力传感器170A检测所述触摸操作强度。电子设备100也可以根据压力传感器170A的检测信号计算触摸的位置。触摸传感器170B，也称“触控面板”，可以与显示屏140组成触摸屏，也称“触控屏”。触摸传感器170B用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。还可以通过显示屏140提供与触摸操作相关的视觉输出。

电源模块160，可以用于向电子设备100包含的各个部件供电。在一些实施例中，该电源模块160可以是电池，如可充电电池。

电子设备100的软件***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的

***为例，示例性说明电子设备100的软件结构。

图3是本发明实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将软件***分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和***库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图3所示，应用程序包可以包括相机，图库，日历，通话，地图，负一屏，WLAN，桌面，音乐，视频，短信息，等应用程序。

应用程序框架层包括OS，为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数，实现预定义的功能。比如，获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等；提供应用程序访问的数据；为应用程序提供各种资源，比如本地化字符串，图标，图片，界面描述文件，视频文件等。OS的视图***包括可视控件，例如显示文字的控件，显示图片的控件等。视图***可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。OS还可以使应用程序在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互；还可以以图表或者滚动条文本形式在***顶部状态栏出现通知，例如后台运行的应用程序的通知；还可以以对话窗口形式在屏幕上出现通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

Android runtime包括核心库和虚拟机。Android runtime负责安卓***的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

***库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子***进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

作为开源OS，在便携式电子设备上被广泛使用。同时，很多厂商也推出了自己的增强***(OEM OS)；例如，华为的EMUI，是基于

构建的。OEM OS可以提供比基础OS(比如

)更优化增强的SDK，提供厂商自定义的UI编程能力。

一种实现方法中，厂商发布的OEM OS支持

的界面描述语言(比如xml)，可以提供

的基础UI编程能力和厂商自定义的UI编程能力。请参考图4，App的UI开发语言为

适用的界面描述语言(比如xml)，用于声明

提供的基础UI编程能力。在

的界面描述语言(比如xml)中增加厂商自定义字段，用于声明厂商自定义的UI编程能力。OEM OS平台基于

提供的基础UI引擎解释和执行界面描述语言；基础UI引擎中增加对厂商自定义字段的解释和执行。OEM OS支持

提供的基础UI编程能力，并提供厂商自定义UI编程能力。这种方法中，使用

原生开发接口、界面描述语言和UI引擎，采用在

原生界面描述语言和UI引擎中增加自定义字段的方式提供厂商自定义UI编程能力。

另一种实现方法中，厂商发布的OEM OS独立于通用OS平台(比如

)，提供厂商自定义的UI编程能力。请参考图5，App的UI开发语言为厂商自定义界面描述语言。OEMOS平台提供自定义UI引擎，对自定义界面描述语言进行解析和执行；提供厂商自定义的UI编程能力。这种方法中，厂商自定义一套完整的、独立于通用OS平台的UI编程框架，可以满足开发者跨平台开发和运行App的诉求。

本申请实施例提供一种用户接口界面实现方法及装置，可以提供丰富的UI编程能力，且能够适应多种OS平台，技术实现难度低，方便开发者使用。

请参考图6，本申请实施例提供的OEM OS平台支持基础界面描述语言，以及自定义界面描述语言。基础界面描述语言是通用的OS平台支持的界面描述语言；比如，

的xml，

的swift等。本申请实施例中，自定义界面描述语言为一种领域特定语言(domain specific language，DSL)，自定义界面描述语言与通用OS平台不相关。本申请下述实施例中，自定义界面描述语言称为DSL。开发者可以使用基础界面描述语言和DSL共同开发App的UI。比如，开发者使用基础界面描述语言描述UI布局、包括的控件等；并且选择性使用DSL将自定义UI编程能力应用于一些控件，在UI增加一些动效等。比如，自定义UI编程能力可以包括布局能力，视觉属性能力，统一交互能力，动效能力等。布局能力用于描述UI中控件的布局；比如控件的形状、位置、大小等。视觉属性能力用于描述控件的视觉属性；比如，控件的颜色、灰度等视觉效果。统一交互能力用于基于用户行为提供控件响应；比如基于用户的“确认”行为执行搜索。动效能力用于在控件上显示动画效果；比如在控件上显示点击回弹动效等。

本申请实施例提供的OEM OS既可以实现通用OS平台提供的基础UI编程能力，还可以实现相对OS平台扩展的自定义UI编程能力。OEM OS平台包括基础UI引擎和扩展UI引擎。电子设备构建UI时，基础UI引擎用于解释和执行基础界面描述语言，生成基础的UI(具备基础UI编程能力)；扩展UI引擎用于解释和执行DSL，在基础的UI上叠加自定义UI编程能力。

本申请实施例提供的用户接口界面实现方法，自定义界面描述语言和扩展UI引擎仅需要覆盖自定义UI编程能力，因此厂商的发布难度低，易于扩展；并且开发者接入门槛低。自定义界面描述语言和扩展UI引擎与通用OS平台不相关，通用OS平台可以是

也可以是其他通用OS平台。自定义界面描述语言和扩展UI引擎可以方便的适用于多种通用OS平台。

开发者采用基础界面描述语言和自定义界面描述语言开发App。App在电子设备上运行时，电子设备上OEM OS的UI引擎解析和执行界面描述语言(基础界面描述语言和自定义界面描述语言)，生成UI。其中，基础UI引擎用于解释和执行基础界面描述语言，本申请实施例中OEM OS提供的扩展UI引擎，用于解析和执行自定义界面描述语言。请参考图7，在一种示例中，扩展UI引擎310包括流程控制311、DSL文件加载312、解析引擎313、执行引擎314等模块。其中，流程控制311用于控制扩展UI引擎310内各个模块的执行流程，以及扩展UI引擎310与OEM OS中其他模块的交互流程等。DSL文件加载312用于读取DSL文件。解析引擎313包括DSL语法校验、DSL解析等子模块。其中，DSL语法校验子模块用于对DSL文件中内容进行语法校验。DSL解析子模块用于解析DSL文件，将DSL文件中内容转换成与执行引擎匹配的数据格式。在一种实现方式中，如果DSL语法校验子模块对DSL文件语法校验成功，DSL解析子模块对DSL文件进行解析；如果DSL语法校验子模块对DSL文件语法校验不成功，DSL解析子模块不执行解析DSL文件。解析引擎313还可以包括DSL预处理等子模块。比如DSL预处理子模块用于对DSL文件进行预编译等。执行引擎314包括版本管理、控件构建、事件代理、解释执行引擎、语义支持库等子模块。其中，版本管理子模块用于匹配扩展UI引擎310与App中DSL文件的版本。扩展UI引擎310的版本需要与DSL文件的版本一致或者比DSL文件的版本更新，才能正常运行。控件构建子模块用于根据DSL文件内容构建UI的控件。事件代理子模块用于实现器件事件与用户行为之间的映射。比如，鼠标双击事件、显示屏上的手指单击事件都可以映射为用户在电子设备上的“确认”行为。解释执行引擎用于解释和执行DSL文件中的代码，响应于用户行为，执行DSL文件中定义的用户行为对应的动作。语义支持库包括DSL文件中所有字段的语法语义规范集合，比如，环境变量接口、公共字段、布局模板属性、视觉属性、布局属性、交互属性、动效属性等字段定义和语法。

请继续参考图7，本申请实施例中OEM OS还包括自定义UI编程能力320。自定义UI编程能力320包括DSL适配层，用于为扩展UI引擎310提供自定义UI编程能力的适配接口。自定义UI编程能力320还提供视觉属性能力，布局能力，统一交互能力，动效能力等自定义UI编程能力的实现。比如，DSL文件中声明了一个控件使能垂直拉伸能力，该自定义UI编程能力(垂直拉伸能力)的实现由自定义UI编程能力320完成；也就是说，该控件的显示窗口发生变化时，自定义UI编程能力320实现控件的垂直拉伸，不需要开发者在DSL中进行控件垂直拉伸的实现。

开发者可以使用基础界面描述语言和DSL共同开发App。基础界面描述语言的语法规则和开发工具可以沿用常规技术。本申请实施例还提供DSL的语法规则和开发工具。在一种示例中，本申请实施例提供一种开发工具，支持基础界面描述语言和DSL的语法规则，提供基础界面描述语言和DSL的编辑及编译环境。

在一些实施例中，本申请实施例提供一种开发工具，在该开发工具的开发界面，包括基础界面描述语言文件和DSL文件。示例性的，开发者打开开发工具的开发界面，在开发界面包括基础界面描述语言文件初始版和DSL文件初始版。进一步的，开发者可以在基础界面描述语言文件初始版中采用基础界面描述语言增加控件描述，还可以在DSL文件初始版中采用DSL增加控件描述。可以理解的，DSL文件初始版可以是开发工具中预置的，也可以是开发者在开发工具中添加的。在一些实例中，开发工具中还可以包括诸如DSL模板，DSL的语法规则描述文件，界面描述示例等。

在一些示例中，基础界面描述语言文件用于描述原生控件，对原生控件应用基础UI编程能力。DSL文件用于声明控件的自定义UI编程能力。比如，可以在DSL文件中对原生控件应用自定义UI编程能力；再比如，还可以在DSL文件中声明自定义控件，对自定义控件应用自定义UI编程能力。

在一种实现方式中，基础界面描述语言文件和DSL文件分别设置于开发工具文件夹的不同路径。示例性的，基础界面描述语言用一个或多个xml格式的文件承载，DSL用一个或多个json格式的文件承载。例如，如图8所示，以

平台作为通用OS平台为例，开发者在开发工具中创建一个App的文件夹app。文件夹app的res目录下集成了一个AndroidManifest.xml文件。开发者可以在该xml格式的文件中声明使用的基础UI编程能力。文件夹app的assets目录下集成了一个huawei_dsl.json文件。开发者可以在该json格式的DSL文件中声明使用的自定义UI编程能力。

可以理解的，上述将基础界面描述语言文件和DSL文件分别设置于开发工具文件夹的不同路径，仅是为了OEM OS的UI引擎可以区分基础界面描述语言文件和DSL文件。在实际应用中，也可以采用其他方式区分基础界面描述语言文件和DSL文件。比如，对基础界面描述语言文件和DSL文件预置不同的标签，OEM OS的UI引擎可以按照预置标签分别获取到基础界面描述语言文件和DSL文件。本申请实施例对此并不进行限定。

开发者在开发工具中完成App开发，进行编译后生成App的安装包。该基础界面描述语言文件和DSL文件集成到App安装包中，以使得OEM OS的UI引擎可以读取基础界面描述语言文件和DSL文件。在一种实现方式中，基础界面描述语言文件和DSL文件在App安装包中的存储位置与其在开发工具中App的文件夹中的位置一致。

在一种示例中，DSL文件使用标准的json格式；示例性的，DSL文件包括version、app和layout等内容。

其中，version表示DSL文件的版本号；示例性的，version格式为x.y.z，x指示产品，y表示产品的子***，z表示开发次数；例如，可以是101.1.003。

app内容块用于声明作用于DSL文件所在的App安装包内App全局控件的自定义UI编程能力。示例性的，app内容块格式为:

其中，feature_name为自定义UI编程能力的属性。value为自定义UI编程能力的属性值。

layout内容块用于声明作用于一个布局(layout)中控件的自定义UI编程能力。示例性的，layout内容块格式为:

其中，layoutId用于指示一个layout；比如，layoutId为一个layout的标识。widgetId用于指示layout中的一个控件；比如，widgetId是控件标识。prop_name为自定义UI编程能力的属性，表示自定义UI编程能力的一个特征；比如，自定义UI编程能力使能，自定义UI编程能力的优先级，自定义UI编程能力的参数等。value为自定义UI编程能力的属性值，属性值用于指定属性的值；比如，属性为自定义UI编程能力使能，相应的，属性值为true表示使能自定义UI编程能力，属性值为false表示不使能自定义UI编程能力。

示例性的，DSL文件中包括以下代码段：

其中，版本号为101.1.003。自定义UI编程能力zoom(缩放)的属性值为使能，即App全局的控件使能zoom(缩放)能力。App中名称为R.layout.mainpage的layout中名称为R.id.edit_text的控件使能onSearch(搜索)能力，onSearch的属性值为com.app.Search$onSearchPrice(即搜索功能的具体执行动作在com.app.Search$onSearchPrice中定义)。

可以理解的，DSL文件中可以包括更少或更多的字段。比如，DSL文件中可以包括version和layout内容块，不包括app内容块。再比如，layout内容块中可以包括多个控件的描述字段。再比如，对一个控件可以使能多个自定义UI编程能力。本申请实施例对此并不进行限定。

本申请实施例的自定义UI编程能力可以包括视觉属性能力，布局能力，统一交互能力，动效能力等。开发者可以在DSL文件中声明自定义UI编程能力，以使用OEM OS提供的自定义UI编程能力。

示例性的，UI的视觉属性体现为控件的视觉属性。OEM OS为控件定义了一套视觉参数变量，用于描述控件的视觉属性；这一套视觉参数变量可以用于多品牌或多设备视觉属性的切换。开发者描述UI的视觉属性时，使用视觉参数变量(在电子设备运行时动态获取与品牌或者电子设备本身匹配的属性值)即可，不需要开发者指定具体的变量值。在DSL文件中声明视觉参数变量即使得控件具备了相应的视觉属性能力。

DSL文件中使用视觉属性能力的示例如下：

在该示例中，控件R.id.textview的视觉属性textColor的属性值为emuiColor1；控件R.id.image的视觉属性foreground的属性值为emui_color_bg。其中，emuiColor1和emui_color_bg为视觉参数变量，在不同的品牌或设备上映射为不同的颜色值。OEM OS中预置不同的品牌或设备上视觉参数变量与颜色值的映射关系，避免了开发者在不同的品牌或设备上指定textColor以及foreground属性值的重复劳动。

OEM OS提供自适应布局能力，以构建响应式UI，使得UI的布局可以适配不同大小、形态的显示屏；避免开发者为不同的设备进行不同的布局工作。示例性的，自适应布局能力包括自动拉伸、隐藏、折行、均分、占比、延伸等布局能力。在一种示例中，OEM OS提供的自适应布局能力适用于LinearLayout布局以及布局中的控件。

下面示例性示出几种布局能力。

一、自适应布局能力总开关，用于打开或者关闭控件的自适应布局能力。在一种示例中，自适应布局能力总开关打开，才能使能布局能力中任意一种。

1、字段定义

能力	属性	字段定义	属性所属
				总开关	打开自适应布局能力	use_HwConstraintLayout	布局

其中，“能力”用于指示自定义UI编程能力。“属性”表示自定义UI编程能力的特征参数。“属性所属”表示对属性作用的分类；比如属性所属为布局，表示该属性用于对控件布局；比如属性所属为子元素，表示该属性用于描述控件。

二、自动拉伸能力。控件使能自动拉伸能力，则可以实现控件在UI根据窗口大小自动拉伸，以适应窗口大小。

1、字段定义

2、DSL文件中使用自动拉伸能力的示例

在该示例中，R.layout.linearlayout_vertical布局中使能控件的垂直拉伸能力。该布局中控件在显示窗口发生变化时，可以自动垂直拉伸，以适应显示窗口大小。

三、隐藏能力。控件使能隐藏能力，则可以在UI隐藏。

1、字段定义

2、DSL文件中使用隐藏能力的示例

在该示例中，R.layout.mainpage布局中控件R.id.container使能垂直隐藏能力。R.id.container中R.id.image1的垂直隐藏的优先级为2，R.id.image2的垂直隐藏的优先级为1。

四、折行能力。控件使能折行能力，则可以实现在UI内，控件折为多行显示。在一种示例中，折行宽度限定值可以用于指定控件在每一行显示的最大宽度。

1、字段定义

2、DSL文件中使用折行能力的示例

在该示例中，R.layout.mainpage布局中控件使能折行能力。其中，R.id.image1的折行宽度限定值160dp，R.id.image2的折行宽度限定值160dp；表示R.id.image1在每一行显示的最大宽度值为160dp，R.id.image2在每一行显示的最大宽度值为160dp。

五、均分能力。控件使能均分能力，则可以实现控件在UI内均分显示。

1、字段定义

2、DSL文件中使用均分能力的示例

在该示例中，R.layout.mainpage布局中控件使能均分能力。其中，R.id.image1均分类型为spread。

六、占比能力。控件使能占比能力，表示支持控件在指定方向上按照指定的百分比占据布局总大小。

1、字段定义

2、DSL文件中使用占比能力的示例

在该示例中，R.layout.mainpage布局中控件使能垂直占比能力。其中，R.id.image1垂直占比为33.33％。

七、延伸能力。控件使能延伸能力，则可以实现控件根据显示屏尺寸在UI上延伸显示。在一种示例中，露出值用于指定UI上可显示的最后一个控件在UI上的露出特征。

1、字段定义

2、DSL文件中使用延伸能力的示例

在该示例中，R.layout.mainpage布局中控件使能延伸能力。其中，R.id.image1使能露出特征能力，露出值为40dp。

OEM OS还提供统一交互能力，支持开发者基于行为定义控件的响应。在一种示例中，统一交互能力包括搜索、缩放等。开发者可以在DSL文件中声明统一交互能力，使得控件具备搜索、缩放等能力。

开发者基于通用OS平台开发UI时，开发者定义事件对应的行为。比如，定义鼠标双击事件对应“确认”行为，定义在显示屏上的手指单击事件对应“确认”行为，以及定义其他事件与“确认”行为的对应关系。开发者的工作量较大。本申请实施例提供的OEM OS支持开发者直接定义对“确认”行为的响应(即定义行为对应的统一交互能力)，而不需定义与“确认”行为对应的事件；事件与行为的映射关系由OEM OS完成。OEM OS将不同形态的电子设备触发的事件映射为同一行为(比如，将PC上的鼠标双击事件映射为“确认”行为，将手机上的手指单击事件映射为“确认”行为)，避免开发者针对不同形态的电子设备定义事件和行为的对应关系，带来重复劳动。

DSL文件中使用搜索能力的示例如下：

在该示例中，控件R.id.sample_text具备onSearch(搜索)能力。电子设备接收到用户在控件R.id.sample_text的“确认”行为(比如，接收到鼠标双击R.id.sample_text事件，接收到手指单击R.id.sample_text事件等)，执行在com.sample.SearchImplSample$onSearchSample中定义的搜索功能。

DSL文件中使用缩放能力的示例如下：

在该示例中，控件R.id.sample_text具备onZoom(缩放)能力。电子设备接收到用户在控件R.id.sample_text的“确认”行为(比如，接收到鼠标双击R.id.sample_text事件，接收到手指单击R.id.sample_text事件等)，执行在com.sample.ZoomImplSample$onZoomSample中定义的缩放功能。

OEM OS还提供增强的动效能力，使得控件的动效更具表现力。OEM OS提供的动效能力适用于Button及其子类；支持App全局使能，或者针对控件使能。

在一种示例中，动效能力包括Button控件的点击回弹微动效(字段定义：reboundAnimation)。

DSL文件中使用动效能力的示例如下：

在layout内容块中声明reboundAnimation，目标控件使能点击回弹微动效。

示例性的，图9示出了App运行时生成UI的一种流程示意图。

S401、扩展UI引擎的流程控制模块读取基础界面描述语言文件，并调用基础UI引擎解析和执行基础界面描述语言，构建出基础UI。

其中，基础UI的控件使用了基础UI编程能力。

S402、扩展UI引擎的流程控制模块调用DSL文件加载模块读取和加载DSL文件。

S403、解析引擎对DSL文件中内容进行语法校验、解析和预处理，获取与执行引擎匹配的数据格式。

在一种示例中，DSL语法校验子模块对DSL文件中内容进行语法校验，如果校验通过，DSL解析子模块对DSL文件中字段进行解析。进一步的，DSL预处理子模块对DSL文件进行预处理获取与执行引擎匹配的数据格式。

S404、执行引擎在S401构建的基础UI上，根据DSL文件内容，以控件为单位构建增强的UI。

在一种实现方式中，控件构建子模块从语义支持库中依次获取DSL文件中字段对应的语义处理组件。比如，从语义支持库中获取“onSearch”字段的语义处理组件SearchHandler。进一步的，控件构建子模块通过DSL适配层将自定义UI编程能力应用于控件，构建增强的UI。

示例性的，图10示出了电子设备响应用户在UI的操作的一种流程示意图。

S501、执行引擎创建一个事件代理，将事件代理通过DSL适配层注册给UI。

S502、OEM OS监听UI的用户操作事件，并上报用户操作事件至事件代理。

S503、事件代理实现事件与行为之间的映射。

S504、解释执行引擎解释和执行DSL文件中的代码，根据行为实现DSL文件中指定的响应，完成响应用户在UI的操作。

本申请实施例提供的用户接口界面实现方法，支持App中包括原生控件、自定义控件，还支持在原生控件中应用自定义UI编程能力。其中，原生控件为通用OS(比如

)支持的控件，通用OS为原生控件提供基础UI编程能力；自定义控件为通用OS不支持，OEMOS支持的控件，OEM OS为自定义控件提供自定义UI编程能力。

请参考图11，其示出了OEM OS构建原生控件的一种流程示意图。OEM OS 1101的App开发工程包中包括基础界面描述语言文件，基础UI引擎1110的流程控制1111指示解析引擎1112对基础界面描述语言文件进行处理。解析引擎1112读取、加载基础界面描述语言文件，将基础界面描述语言文件转化为与执行引擎1113匹配的数据格式。执行引擎1113根据基础界面描述语言文件内容构建基础UI，生成原生控件1130。

请参考图12，其示出了OEM OS在原生控件应用自定义UI编程能力的一种流程示意图。OEM OS 1101的App开发工程包中包括基础界面描述语言文件以及DSL文件。扩展UI引擎1120的流程控制1121指示基础UI引擎1110中的解析引擎1112对基础界面描述语言文件进行处理。解析引擎1112读取、加载基础界面描述语言文件，将基础界面描述语言文件转化为与执行引擎1113匹配的数据格式。执行引擎1113根据基础界面描述语言文件内容构建基础UI，生成原生控件1130。流程控制1121指示扩展UI引擎1120中的解析引擎1122对DSL文件进行处理。解析引擎1122读取、加载DSL文件，将DSL文件转化为与执行引擎1123匹配的数据格式。执行引擎1123根据DSL文件在原生控件1130应用自定义UI编程能力。

请参考图13，其示出了OEM OS构建自定义控件的一种流程示意图。OEM OS 1101的App开发工程包中包括基础界面描述语言文件以及DSL文件。扩展UI引擎1120的流程控制1121指示基础UI引擎1110中的解析引擎1112对基础界面描述语言文件进行处理。解析引擎1112读取、加载基础界面描述语言文件，将基础界面描述语言文件转化为与执行引擎1113匹配的数据格式。执行引擎1113根据基础界面描述语言文件内容构建基础UI，生成原生控件1130。流程控制1121指示扩展UI引擎1120中的解析引擎1122对DSL文件进行处理。解析引擎1122读取、加载DSL文件，将DSL文件转化为与执行引擎1123匹配的数据格式。执行引擎1123根据DSL文件在基础UI上生成自定义控件1140。

本申请实施例提供的OEM OS包括基础UI引擎和扩展UI引擎。电子设备构建UI时，基础UI引擎用于解释和执行基础界面描述语言，生成基础的UI(具备基础UI编程能力)；扩展UI引擎用于解释和执行DSL，在基础的UI上叠加自定义UI编程能力。本申请实施例提供的用户接口界面实现方法能够适应多种OS平台，提供丰富的UI编程能力；技术实现难度低，方便开发者使用。

本申请实施例还提供一种用户接口界面实现方法，实现难度低，方便开发者使用。

随着物联网(Internet of things，IoT)快速发展，IoT设备类型与数量均快速增长。不同的IoT设备拥有差异化的屏幕尺寸以及用户交互方式。例如，手机的屏幕尺寸大多在4-6寸左右，用户交互方式以触摸、点击显示屏为主；电视的屏幕尺寸可达50寸或更大，用户交互方式通常为遥控器操作；车机等设备具有更为广泛的屏幕形态以及用户交互方式。目前通用的OS平台(比如

)支持的开发方式为，针对同一App中的同一UI，开发者对每一种类型的电子设备设计不同的界面描述文件。显然，使用这种方法为各类设备开发差异化UI的工作量大，开发难度高。本申请实施例提供一种用户接口界面实现方法及装置，可以实现一次开发，多设备部署；即开发一套界面描述文件，适用于各种不同类型的电子设备；降低开发者的开发难度。

比如，

作为开源OS，在便携式电子设备上被广泛使用。基于

开发App的UI时，对同一App中的同一UI，开发者针对每一种类型的电子设备设计不同的界面描述文件，以实现为不同类型的电子设备开发差异化UI。

支持为每种类型的电子设备分别设立布局文件夹的方式实现多类设备UI独立开发。比如，在布局文件夹的名称中增加后缀来区分不同的布局文件夹。这样，针对同一UI，不同类型的电子设备读取不同布局文件夹中的界面描述文件，呈现不同的UI显示效果。如果需要将该App安装在其他类型的电子设备上，则需要单独为该类型的电子设备开发对应的界面描述文件(单独增加一个布局文件夹)。这样的开发方式中，开发者需要为不同类型的电子设备单独开发对应的界面描述文件，开发工作量大，难度高。

还有一些厂商提供了一些完整的、独立于

的UI编程框架。例如Flutter，ReacNative，Weex等框架。这种UI编程框架包含UI界面描述语言及对应的解析执行引擎，提供独立的界面控件库、布局引擎和渲染引擎等，可以跨设备运行，但是兼容性差。

本申请实施例提供一种用户接口界面实现方法及装置。请参考图14，开发者在电子设备200(开发者设备)中打开一种开发工具(比如，DevEco Studio)，在开发工具的开发界面生成界面描述文件。示例性的，开发者打开开发工具的开发界面，开发界面包括界面描述文件初始版。界面描述文件初始版可以是空白文件，也可以包含简单示例。可以理解的，界面描述文件初始版可以是开发工具中预置的，也可以是开发者在开发工具中添加的。在一些示例中，开发工具中还可以包括诸如界面描述语言模板，界面描述语言语法规则描述文件，界面描述示例等，本申请实施例中不再赘述。

进一步的，开发者可以在界面描述文件初始版中采用一种界面描述语言添加界面描述和界面行为定义，形成用于发布的界面描述文件。在一种实现方式中，开发者针对App中每个UI生成一个界面描述文件；比如，可以在一个文件夹中生成多个界面描述文件，每个界面描述文件对应一个UI。

在开发者设备上生成App的安装包，其中包含界面描述文件。App的安装包上传至服务器，App在服务器提供的应用市场中发布。用户可使用用户侧电子设备(上述电子设备100)在应用市场中下载App的安装包。用户侧电子设备运行App的安装包之后，获取安装包中的界面描述文件；当用户侧电子设备运行App时，按照界面描述文件在显示屏显示与该电子设备相匹配的UI。

在一种示例中，界面描述文件采用json格式。示例性的，如图14所示，App的安装包中包括文件夹“app”410。文件夹“app”410的src\main\assets目录下包括布局文件夹“layout”411，布局文件夹“layout”411中包括界面描述文件layout1.json412、layout2.json 413和layout3.json 414等，每个界面描述文件分别对应App的一个UI。手机420、车机430、电视440、手表450等不同类型的用户侧电子设备都运行“layout”411中同一个界面描述文件，并分别显示同一UI的不同显示效果。比如，手机420、车机430、电视440和手表450都解析执行layout1.json 512，并分别显示layout1.json 512对应UI的不同显示效果。

本申请实施例中，对同一App中的同一UI，开发者在一个界面描述文件中开发一套代码即可实现为不同类型的电子设备开发差异化UI。不同类型的电子设备读取同一UI的同一个界面描述文件，可以呈现不同的UI显示效果。可以实现开发一套界面描述文件，适用于各种不同类型的电子设备，降低了开发者的开发难度。

本申请实施例提供的用户接口界面实现方法，支持在界面描述文件中使用

原生的UI编程能力，以及操作***自定义的UI编程能力。

原生的UI编程能力使得控件具备

原生的控件属性，操作***自定义的UI编程能力使得控件具备扩展的视觉属性、布局属性、交互属性、动效属性和软硬件依赖属性等。电子设备运行App的安装包，获取安装包中的界面描述文件后；当用户在电子设备上运行App时，电子设备可以按照界面描述文件在显示屏呈现相应的UI，该UI中的控件可以包括

原生的控件属性，还可以包括扩展的控件属性。本申请实施例提供的自定义UI引擎支持对

原生控件属性以及操作***中扩展的所有控件属性进行解析执行。

在一种示例中，图15示出了电子设备100的一种软件架构。如图15所示，电子设备100软件***可以包括应用程序层，应用程序框架层，安卓运行时(Android runtime)和***库，以及内核层。在一种示例中，应用程序层，安卓运行时(Android runtime)和***库，以及内核层可以参考图3中

软件架构中相应的描述，此处不再赘述。本申请实施例提供的电子设备100的软件***部分复用常规技术中UI编程框架，易于学习，降低开发者的开发难度。

应用程序框架层的操作***包括自定义UI引擎11。自定义UI引擎11用于解析和执行App的界面描述文件，生成App的UI。自定义UI引擎11可以包括UI解析引擎11a，UI执行引擎11b，MVVM(model-view-viewmodel)框架11c，语法语义库11d和UI渲染引擎11e。可以理解的，应用程序框架层还可以包括更多模块，可以参考常规技术，本申请实施例对此并不进行限定。

下面结合附图对上述各模块进行详细介绍。

语法语义库11d包括界面描述文件中所有字段的语法语义规范集合，比如，变量接口、公共字段、视觉属性、布局属性、交互属性、动效属性、软硬件依赖属性等字段定义和语法。其中，布局属性是指UI中各个控件的布局；比如控件的形状、位置、大小等。视觉属性是指控件的颜色、灰度等视觉效果。交互属性是基于用户行为提供控件响应的能力；比如基于用户的“确认”行为执行搜索。动效属性是指在控件上显示动画效果；比如在控件上显示点击回弹动效等。软硬件依赖属性是指控件依赖设备的软硬件参数。

开发者需要按照语法语义库11d中定义的语法语义规范在界面描述文件中添加代码，开发UI。下面从布局编排，数据&界面绑定、交互行为编排以及差异化描述等方面对语法语义库11d中定义的语法语义规范进行介绍。

以界面描述文件采用json格式为例，示例性的，界面描述文件可以包括如下结构：

其中，meta-data包括版本号等信息。示例如下：

"meta-data":{

"version":"10.0.1008"

}

version表示界面描述文件的版本号；示例性的，version格式为x.y.z，x指示产品，y表示产品的子***，z表示开发次数。界面描述文件的版本需要与自定义UI引擎的版本匹配，比如，自定义UI引擎的版本与界面描述文件的版本一致，或者比界面描述文件的版本更新，才能成功解析界面描述文件。

import用于导入对象，model用于声明对象。示例如下：

import中导入UserInfo保存的完整路径com.myapp.UserInfo，以及Context保存的完整路径com.myapp.TestActivity；在model中声明UserInfo类型的对象user，以及Context类型的对象context；这样就可以在界面描述文件(layout-data-common和layout-data-uimode)中直接调用user和context。本申请中，UserInfo、TestActivity等文件称为资源文件；资源文件包括生成该应用的UI使用的资源，该资源可以包括开发者定义的数据结构、控件、控件属性等。

import和model的具体用法在后面结合layout-data-common、layout-data-uimode和styles中的语法语义规则详细介绍。

layout-data-common用于描述通用UI。各种类型的电子设备都解析layout-data-common中内容，按照layout-data-common中的内容布局通用UI。layout-data-uimode用于描述指定设备的UI。在一种实现方式中，layout-data-uimode中声明指定设备UI与通用UI的区别。在另一种实现方式中，layout-data-uimode中声明适用于指定设备的UI的全部条件。指定设备可以为手机、手表、车机、智能家居设备(比如，智能电视、智慧屏、智能音箱等)、大屏、笔记本电脑、台式电脑等。比如，layout-data-uimode的具体形式可以包括layout-data-phone(用于手机)，layout-data-watch(用于手表)，layout-data-television(用于电视)等。

styles用于定义App中自定义参数。开发者可以在styles中自定义参数。

一、布局编排

App中所有UI是由控件构成的。UI的布局编排即编排UI中控件的属性。

1、控件

自定义UI引擎11支持所有

原生控件以及操作***中拓展的控件，还支持开发者在App中自定义的或者通过静态包集成的控件。其中，控件具体可以包括文本控件，例如TextView控件、EditText控件等，也可以包括按钮控件，例如Button控件、ImageButton控件等，还可以包括图片控件，例如Image控件等，本申请实施例对此不做任何限制。

对于

原生控件以及操作***中拓展的控件，可以在layout-data-common或layout-data-uimode中直接调用控件名称。例如，

原生控件可以包括TextView，EditText等；操作***中拓展的控件可以包括HwButton等。一种声明控件的示例如下，在该示例中，声明了

原生控件TextView和EditText。

对于开发者在App中自定义的或者通过静态包集成的控件，需要在import中引入控件的资源包的完整包名。这样，就可以在layout-data-common或layout-data-uimode中调用。一种声明App中自定义控件的示例如下，在该示例中，先在import中引入控件MyCircleView的资源包的完整包名com.myapp.widget.MyCircleView，然后在layout-data-common中直接调用MyCircleView。

在一种实现方式中，自定义UI引擎11支持开发者对控件进行别名指定。一种示例如下，在该示例中，在import中引入MyCircleView的资源包的完整包名com.myapp.widget.MyCircleView时，将MyCircleView的名称指定为AliasName。

在一种实现方式中，在layout-data-common或layout-data-uimode中调用控件时，以ComponentName():{}的形式进行控件声明。例如，TextView():{}，表示声明了一个TextView。

2、控件的属性

自定义UI引擎11支持的控件属性包括

原生属性以及操作***中扩展的视觉属性、布局属性、交互属性、动效属性和软硬件依赖属性等。

使用ComponentName():{}方式描述一个控件时，在一种实现方式中，可以在{}中传入控件的属性及属性值，格式为“属性1:属性值1，属性2:属性值2”。示例如下，该示例中，声明了控件TextView，并在{}中传入TextView的属性textSize，textSize的属性值为@dimen/mySize。

在另一种实现方式中，可以在()中传入控件的属性及属性值。示例如下，该示例中，声明了控件TextView，并在()中传入TextView的属性text，text的属性值为@string/text_name。

{

"TextView(text:@string/text_name)":{}

}

在一种实现方式中，如果对于同一个控件，在()和{}中都传入控件属性及属性值，则忽略()中内容。

其中，控件属性的属性值可以通过以下任意一种方式赋值。直接通过字符串值指定；访问后台数据中定义的资源值；访问后台数据中声明的分类参数；或者，访问控件模型(ViewModel)对象中的值。

自定义UI引擎11支持通过namespace.propertyName方式来指定控件属性的命名空间(namespace)。在一种实现方式中，不指定命名空间表示默认为

的命名空间。在一种实现方式中，自定义UI引擎11支持使用命名空间androidhwext指向操作***中扩展资源包，使用命名空间app指向App中自定义的资源包。操作***中扩展资源包提供操作***中自定义的UI编程能力；App中自定义的资源包提供App中自定义的控件属性。

在一种实现方式中，开发者还可以定义其他命名空间。开发者定义的命名空间通过import引入，并提供定义控件属性的资源包的包名。示例如下，在该示例中，import中引入开发者定义的命名空间myspace，myspace的资源包的完整包名为com.myapp。在import中引入myspace后，即可在layout-data-common中调用myspace中属性borderWidth。

二、数据&界面绑定

自定义UI引擎11支持将UI中的元素与后台数据进行双向绑定。可以在界面描述文件(layout-data-common或layout-data-uimode)中声明并指定UI中的元素(比如控件、控件组)与后台数据之间的绑定关系。自定义UI引擎11中MVVM框架11c即可实现根据UI改变刷新后台数据，或者根据后台数据改变自动刷新对应UI。

示例性的，可以将UI中的元素与一个控件模型(ViewModel)对象绑定起来。先在import中引入ViewModel，在model中声明一个ViewModel类型的对象。然后在layout-data-common或layout-data-uimode中调用该ViewModel对象。

在一种示例中，将UI中控件属性的属性值绑定为ViewModel对象的值。示例如下，在该示例中，在import中引入UserInfo(UserInfo为一个ViewModel)的资源包的完整包名com.myapp.UserInfo，并在model中声明一个UserInfo类型的对象user；然后在layout-data-common中访问user中的数据。

在一种实现方式中，通过$model.field方式访问ViewModel对象(model)中的变量值(field)；例如上述$user.photo为访问user中变量photo，$user.name为访问user中变量name。在一种实现方式中，通过$model::function方式访问ViewModel对象(model)中的函数(function)返回值。例如上述$user::hasName为访问user中函数hasName的返回值。

上述示例中，将控件ImageView的属性imageUri(图像)与后台数据user.photo绑定起来，将一个控件TextView的属性text(文本)与后台数据user.name绑定起来，将一个控件TextView的属性text与后台数据user.age绑定起来，将控件CheckBox的属性checked(确认)与后台数据user.agreed绑定起来，将一个控件TextView的属性visible(可见)与后台数据user::hasName绑定起来。当后台数据发生变化时，控件属性的属性值发生改变，UI中控件的显示效果改变。

在一种实现方式中，可以根据后台数据获取控件的可见性，实现UI的隐藏局部的功能。当后台数据中变量变化(可见变为不可见，或不可见变为可见)，UI中控件可以随之隐藏或显示。示例如下，在该示例中，一列控件(Column)的可见性(visible)由变量user.visible的值决定。

在另一种示例中，在UI上接收用户输入，将用户输入绑定至ViewModel对象的值。示例如下，在该示例中，在import中引入UserInfo(UserInfo为一个ViewModel)的资源包的完整包名com.myapp.UserInfo，并在model中声明一个UserInfo类型的对象user；然后在layout-data-common中声明，将控件EditText的属性text(文本)的用户输入值赋值给user中的变量name。其中通过“＝”为后台数据赋值。

三、交互行为编排

自定义UI引擎11支持在界面描述文件中声明控件响应事件对应的执行动作。控件支持的事件范围由控件支持的事件监听决定。例如，按钮控件(Button)支持对点击事件的监听setOnClickListener，则可以在界面描述文件中对控件绑定onClick(点击)事件。自定义UI引擎11将事件的参数和后台数据中的响应函数返回值在控件和后台数据之间进行双向透传。示例如下，layout-data-common中声明控件Button响应于事件onClick执行后台数据context.buttonClick中定义的动作(响应函数返回值)。

自定义UI引擎11支持UI执行引擎加载控件的生命周期事件包括onPreMount、onMount、onUnmount、onPreUpdate和onUpdate等；其中，onPreMount表示控件挂载到UI之前调用；onMount表示控件挂载到UI后调用；onUnmount表示控件在UI上移除后调用；onPreUpdate表示数据变化引起UI刷新前调用；onUpdate表示当后台数据变化引起UI刷新后调用。

在一种实现方式中，事件消费与否由响应函数返回值决定。可选的，自定义UI引擎11遵循

原生的接口定义，将后台数据中的处理结果透传给控件。

四、差异化描述

1、自定义UI引擎11支持控件的属性依赖于电子设备的配置参数。

操作***中定义了电子设备配置参数的变量。界面描述文件中可以声明电子设备配置参数的变量。当电子设备运行界面描述文件时，访问电子设备的配置参数，电子设备根据其软硬件条件获取配置参数的值。这样，不同类型的电子设备运行同一界面描述文件时，由于其软硬件条件不同，配置参数不同，生成的UI不同。

在一种实现方式中，通过$env.config方式访问当前电子设备的配置参数(config)。

示例性的，电子设备的配置参数可以包括表1所示内容：

表1

示例如下，控件的dependOn属性的属性值可以赋值为配置参数中字段，用来声明控件的属性依赖某个配置参数。在该示例中，扫一扫控件(TextView)的可见性依赖于电子设备的摄像头硬件(camera_sensor)；表示若电子设备存在摄像头，则该扫一扫控件显示；若电子设备不存在摄像头，该扫一扫控件不显示。

2、layout-data-uimode用于描述指定设备的UI。

开发者可以在layout-data-uimode中声明指定设备的UI，指定设备的UI与通用UI的显示效果是有区别的。

在一种实现方式中，layout-data-uimode中声明适用于指定设备的UI的全部条件。示例性的，请参考图16，界面描述文件710包括layout-data-common 711和layout-data-watch 712等代码块。layout-data-common 711用于描述适用于各种类型电子设备的通用UI，layout-data-watch 712用于描述适用于手表的UI。如图16所示，layout-data-common 711中声明了通用UI中各个控件的属性及属性值。手机读取界面描述文件710，解析执行layout-data-common 711中内容，按照layout-data-common 711中声明的各个控件的属性及属性值生成相应的控件。示例性的，手机根据layout-data-common 711中内容块7111对应生成图片控件721，layout-data-common 711中内容块7112对应生成控件组722，layout-data-common 711中内容块7113对应生成控件组723，layout-data-common 711中内容块7114对应生成按钮控件724，layout-data-common 711中内容块7115对应生成控件组725。这样，根据内容块7111、内容块7112、内容块7113、内容块7114和内容块7115生成了手机的UI 720。

layout-data-watch 712中声明了适用于手表的UI中控件的属性及属性值。手表读取界面描述文件710，确定界面描述文件710中存在用于手表的layout-data-watch 712，则解析执行layout-data-watch 712中内容，按照layout-data-watch 712中声明的各个控件的属性及属性值生成相应的控件。示例性的，手表根据layout-data-watch 712中内容块7121对应生成图片控件731，layout-data-watch 712中内容块7122对应生成控件组732，layout-data-watch 712中内容块7123对应生成控件组733，layout-data-watch 712中内容块7124对应生成按钮控件734。这样，根据内容块7121、内容块7122、内容块7123和内容块7124生成了手表的UI 730。

这样，手表作为一种指定设备读取第二代码段(layout-data-watch 712)中内容，除手表外的电子设备读取第一代码段(layout-data-common 711)中内容；不同类型的电子设备读取同一UI的同一个界面描述文件，即可呈现不同的UI显示效果；开发一套界面描述文件，即可实现为不同类型的电子设备开发差异化UI，降低了开发者的开发难度。

在另一种实现方式中，layout-data-uimode中声明指定设备UI与通用UI的区别。示例性的，请参考图17，界面描述文件810包括layout-data-common 811和layout-data-watch 812等代码块。layout-data-common 811用于描述适用于各种类型电子设备的通用UI，layout-data-watch 812用于描述手表的UI与通用UI的差别。如图17所示，layout-data-common 811中声明了通用UI中各个控件的属性及属性值。手机读取界面描述文件810，解析执行layout-data-common 811中内容，按照layout-data-common 811中声明的各个控件的属性及属性值生成相应的控件。手机根据layout-data-common 811中内容块8111对应生成图片控件721，layout-data-common 811中内容块8112对应生成控件组722，layout-data-common 811中内容块8113对应生成控件组723，layout-data-common 811中内容块8114对应生成按钮控件724，layout-data-common 811中内容块8115对应生成控件组725。这样，根据内容块8111、内容块8112、内容块8113、内容块8114和内容块8115生成了手机的UI 720。

layout-data-watch 812中声明了手表的UI中与通用UI有区别的控件的属性及属性值。手表读取界面描述文件810，解析执行layout-data-common 811中内容；手表确定界面描述文件810中存在用于手表的layout-data-watch 812，并解析执行layout-data-watch 812中内容；手表按照layout-data-common 811和layout-data-watch 812中声明的各个控件的属性及属性值生成相应的控件。如图17所示，手表根据layout-data-common811中内容块8111对应生成图片控件731，layout-data-common 811中内容块8112对应生成控件组732，layout-data-common 811中内容块8113对应生成控件组733，layout-data-common 811中内容块8114对应生成按钮控件734。根据layout-data-watch 812的描述，将layout-data-common 811中内容块8115对应生成的控件组的可视属性(visible)的属性值设置为不可见(gone)。也就是说，在手表上不显示layout-data-common 811中内容块8115对应的控件组。如图17所示，手表的UI 730包括根据内容块8111、内容块8112、内容块8113和内容块8114生成的控件。

这样，所有类型的电子设备都读取第一代码段(layout-data-common 711)中内容，手表作为一种指定设备还读取第二代码段(layout-data-watch 712)中内容；不同类型的电子设备读取同一UI的同一个界面描述文件，即可呈现不同的UI显示效果；开发一套界面描述文件，即可实现为不同类型的电子设备开发差异化UI，降低了开发者的开发难度。

3、style

自定义UI引擎11支持开发者在style中自定义参数，用于当前的界面描述文件。示例如下，开发者在style中定义myTextStyle，并可以在layout-data-common中以$style.myTextStyle的方式调用该自定义参数。

采用本申请实施例提供的语法语义规则开发UI，语法简洁高效，开发一套界面描述文件即可适用于不同类型的电子设备，避免了为不同类型的电子设备单独开发UI，降低了开发成本。

UI解析引擎11a用于解析界面描述文件，将界面描述文件中内容转换成与UI执行引擎11b匹配的数据格式。在一些示例中，UI解析引擎11a还可以对界面描述文件中内容进行语法校验，如果对界面描述文件语法校验成功，则对界面描述文件进行解析；如果对界面描述文件语法校验不成功，则不执行解析界面描述文件。

在一种示例中，请参考图18，UI解析引擎11a读取界面描述文件，解析界面描述文件中声明(model)、风格(style)、布局(layout-data-common、layout-data-uimode)等字段内数据，预处理后保存至数据库中。使用控件解析器解析布局字段内的数据，根据布局描述的逻辑结构递归调用UI执行引擎11b实例化控件，形成UI的控件树。使用属性解析器解析各个控件的属性字段，调用UI执行引擎11b为各个控件设置属性，完成UI绘制。

其中，控件解析器和属性解析器的工作流程如图19所示。控件解析器获取控件的名称，并获取控件的属性列表。如果存在控件的标识(identity，ID)，添加控件ID；如果存在控件的风格(style)，添加控件style；实例化控件形成控件队列。如果存在子布局，递归调用子布局中的控件。解析完所有布局中的控件后，增加控件，返回生成的控件。属性解析器从控件队列中获取实例化控件，读取控件对应的属性名与属性值，并将属性(包括属性名与属性值)存入哈希表。如果存在子布局，递归调用子布局中的控件。所有控件的属性都解析完成后，将哈希表中保存的各个控件的属性值赋值给对应控件。

UI执行引擎11b用于根据UI解析引擎11a解析的数据构建UI的控件(实例化控件和属性设置)，对控件进行布局编排，生成界面描述文件中声明的界面；还可以实现器件事件与用户行为之间的映射，响应于用户行为执行界面描述文件中定义的用户行为对应的动作等。

示例性的，请参考图20A，在UI执行引擎11b中，为每一个控件构造一个构建(Builder)类，Builder类采用与

相同的继承逻辑，以实现子控件可继承父类控件的所有属性与设置方法，无需重复定义。Builder类内包含了对应控件的实体构造方法与该控件特有的视觉属性的设置方法，以完成控件实例化与属性设置。对于开发者自定义的控件，可以在UI执行引擎11b中提供一个该自定义控件的Builder类即可，接入成本低，对开发者比较友好。

在一些实施例中，对于界面描述文件中声明的

原生控件属性，UI执行引擎11b可以根据界面描述文件中的声明进行属性设置，完成控件实例化，构造出的控件具备

原生控件属性。

请参考图20B，对于界面描述文件中声明的控件的扩展属性，如果确定操作***中包括自定义UI编程能力，UI执行引擎11b根据界面描述文件中的声明进行属性设置，完成控件实例化，构造出具备扩展属性的控件；如果确定操作***中不包括自定义UI编程能力，UI执行引擎11b根据界面描述文件中声明的扩展属性映射对应的

原生控件属性，根据对应的

原生控件属性进行属性设置，完成控件实例化，构造出具备

原生控件属性的控件，该控件不具备扩展属性。

示例性的，请参考图20C，在开发者设备上生成App的安装包，其中包含界面描述文件。App的安装包上传至服务器，App在服务器提供的应用市场中发布。用户可使用用户侧电子设备(上述电子设备100)在应用市场中下载App的安装包。用户侧电子设备运行App的安装包之后，获取安装包中的界面描述文件；当用户侧电子设备运行App时，按照界面描述文件在显示屏显示与该电子设备相匹配的UI。

比如，界面描述文件中包括以下内容：

在一种示例中，平板460作为用户侧电子设备运行App。平板460的操作***中包括自定义UI编程能力。平板460的UI上，自定义控件组HwMagicLayout被成功构造，该控件组具备操作***中扩展的布局属性。示例性的，操作***中扩展的布局属性可以包括自动拉伸、隐藏、均分、占比、延伸或折行等布局属性。其中，自动拉伸是指控件的高度或宽度根据窗口大小自动放大或缩小，以适应窗口大小。隐藏是指控件在布局中可见或不可见的能力。均分是指控件中的内容在布局中均匀分布。占比是指控件在指定方向上按照指定的百分比占据布局总大小。延伸是指控件根据显示屏尺寸在UI上延伸显示。折行是指控件中的内容在布局中通过一行或多行显示。如图20C所示，平板460的UI布局具备***中扩展的布局属性。平板460竖屏显示时，控件461、控件组462、控件组463、控件464和控件组465竖向排列于一列。平板460横屏显示时，控件461、控件组462、控件组463和控件464竖向排列于第一列，控件组465排列于第二列。平板460的UI布局根据显示窗口大小、形状适应性调整。

平板460的UI上，交互能力"zoomEnable"在控件461“imageview”上生效。当平板460连接鼠标480时，可以响应于用户对控件461的放大操作(比如，鼠标480对应的光标置于控件461时，向上转动鼠标480的滚轮)，将控件461放大显示。

在另一种示例中，平板470作为用户侧电子设备运行App。平板470的操作***中不包括自定义UI编程能力。平板470的UI不支持自定义控件组HwMagicLayout，UI中控件具备

原生的线性布局(LinerLayout)属性。平板470竖屏或横屏显示时，控件471、控件组472、控件组473、控件474和控件组475竖向排列于一列。平板470的UI布局是固定的，不能根据显示窗口大小、形状适应性调整。

平板470的UI上，交互能力"zoomEnable"不可以在控件471“imageview”上生效。即平板470连接鼠标480时，如果鼠标480对应的光标置于控件471时，向上转动鼠标480的滚轮，控件471的大小保持不变。

这样，符合语法语义库11d中语法规则的界面描述文件可以在不同的操作***中成功运行，实现了跨操作***平台运行，降低开发者开发难度。

需要说明的是，UI执行引擎11b在电子设备运行界面描述文件时动态解析数据，在电子设备运行界面描述文件时获取电子设备相关参数；避免了开发者在开发工具中对界面描述文件进行预编译，生成预置数据文件；这样，可以使得UI开发不依赖编译环境，实现跨开发平台开发和运行。

MVVM框架11c用于对UI中的元素与后台数据进行双向绑定。在界面描述文件中，声明并指定UI中的元素(比如控件、控件组)与后台数据之间的绑定关系，可选的，还可以进行简单的数据实例设置之后；MVVM框架11c可以实现根据UI改变刷新后台数据，以及根据后台数据改变自动刷新对应UI。帮助开发者专注于UI设计与编排，简化UI开发过程，大幅减少开发者为实现前后端数据交互投入的开发时间。

示例性的，请参考图21，开发者在界面描述文件中声明控件字段，为控件绑定属性，并绑定后台数据对象。UI解析引擎11a对界面描述文件中的绑定行为进行解析，获取控件属性与后台数据对象的对应关系。MVVM框架11c用于实现控件与后台数据的双向绑定。当后台数据改变时，MVVM框架11c将后台数据与对应的控件属性的数据进行映射；UI执行引擎11b设置控件的属性数据，刷新UI。当UI中控件的属性数据发生改变(比如，响应于用户输入，控件的形状、文本等数据发生改变)，MVVM框架11c将控件属性的数据与后台数据进行映射；后台数据刷新。

UI渲染引擎11e用于对UI执行引擎11b生成的界面进行渲染、整理，将显示内容输出至显示屏。

本申请实施例提供的用户接口界面实现方法，不同类型的电子设备读取同一UI的同一个界面描述文件，呈现不同的UI布局。可以实现开发一套界面描述文件，适用于各种不同类型的电子设备，降低了开发者的开发难度。

在一些实施例中，请参考图22，电子设备100软件***可以包括应用程序层，应用程序框架层，安卓运行时(Android runtime)和***库，以及内核层。

应用程序层App1的界面描述文件采用json格式；App2的界面描述文件采用xml格式。

应用程序框架层的操作***包括控制单元。电子设备100运行App时，控制单元获取App的界面描述文件。示例性的，电子设备100运行App1时，控制单元获取App1的json格式界面描述文件；电子设备100运行App2时，控制单元获取App2的xml格式界面描述文件。控制单元根据界面描述文件的类型将界面描述文件分发至基础UI引擎10或自定义UI引擎11进行UI绘制。比如，控制单元获取App1的json格式界面描述文件，将App1的json格式界面描述文件分发至自定义UI引擎11进行处理。比如，控制单元获取App2的xml格式界面描述文件，将App2的xml格式界面描述文件分发至基础UI引擎10进行处理。在一种实现方式中，json格式界面描述文件和xml格式界面描述文件在应用安装包中的指定路径不同。控制单元在App1应用安装包的第一指定路径获取json格式界面描述文件，在App2应用安装包的第二指定路径获取xml格式界面描述文件。在另一种实现方式中，json格式界面描述文件和xml格式界面描述文件预置不同的标签，控制单元根据界面描述文件的预置标签确定界面描述文件的类型。

自定义UI引擎11对App1的json格式界面描述文件进行解析、执行、渲染，生成App1的UI。App1的UI中控件可以支持通用OS(比如

)原生的UI编程能力，还可以支持电子设备100操作***中自定义UI编程能力。

基础UI引擎10对App2的xml格式界面描述文件进行解析、执行、渲染，生成App2的UI。App2的UI中控件可以支持通用OS(比如

)原生的UI编程能力。

这样，电子设备100既可以运行采用json格式界面描述语言开发的App，也可以运行采用xml格式界面描述语言开发的App；实现操作***前向兼容。

本申请实施例还提供一种用户接口界面实现方法，用于应用小组件的UI。

开发者可以开发App对应的小组件。比如，手机支持在通知栏，桌面及负一屏上显示应用的小组件。通常，显示在通知栏的应用小组件称为自定义通知栏，显示在桌面的应用小组件称为桌面小部件，显示在负一屏的应用小组件称为负一屏卡片。自定义通知栏、桌面小部件和负一屏卡片可以更直观地向用户呈现应用中的信息，并且支持在不打开应用的情况下对应用执行操作，方便用户使用应用。越来越多的应用提供了小组件，供用户使用。

目前，支持在应用小组件的用户接口界面(user interface，UI)上显示的布局方式和控件类型比较少，不能满足用户多样化的需求。本申请实施例提供一种用户接口界面实现方法及装置，支持应用小组件的UI上显示各种布局方式和控件类型，方便用户使用应用小组件，提高用户体验。

通常，开发者使用一种界面描述语言，在应用开发工具中开发应用(Application，App)的UI。开发者还使用界面描述语言，在应用开发工具中开发应用小组件的UI。

请参考图23，电子设备200上安装有应用开发工具(比如，Android Studio，DevEcoStudio等)。本申请中电子设备200也可称为开发者设备。开发者在应用开发工具中开发App的UI，形成界面描述文件。本申请中界面描述文件也可称为描述文件。开发者还在应用开发工具中开发应用小组件的UI，形成组件界面描述文件。开发者将界面描述文件和组件界面描述文件打包到App的安装包，在服务器300提供的应用市场中发布App。应用市场中可以提供各个App的安装包供用户下载。例如，安装包可以为

应用程序包(Androidapplication package，APK)文件。

需要说明的是，在一种实现方式中，组件界面描述文件是独立于界面描述文件的。在另一种实现方式中，组件界面描述文件可以是界面描述文件的一部分(比如，将界面描述文件中一段代码段作为组件界面描述文件)。本申请实施例对此并不进行限定。下述实施例中，以组件界面描述文件是单独文件为例进行示例性说明。

以手机为电子设备100举例，用户可使用手机在应用市场中下载某一App的安装包。App的安装包包括界面描述文件和组件界面描述文件。以音乐App举例，手机下载音乐App的安装包后，通过运行该安装包可将音乐App安装在手机中。这样，手机也获取了安装包中的界面描述文件和组件界面描述文件。

示例性，如图23所示，手机安装了音乐App后，手机桌面包括音乐App的快捷图标-“音乐”图标103。手机可以接收用户对“音乐”图标103的点击操作，响应于用户对“音乐”图标103的点击操作，手机按照界面描述文件生成音乐App的UI，并在显示屏呈现音乐App的UI。手机还可以根据用户设置，在手机桌面上显示音乐App的小组件(称为音乐小部件)。手机按照组件界面描述文件生成音乐小部件的UI，并在显示屏显示音乐小部件的UI 104。

可以理解的，在一些实施例中，开发者可以直接在电子设备100上开发App的UI和应用小组件的UI，并在电子设备100上运行该App和应用小组件；即电子设备200和电子设备100可以是同一个电子设备。本申请实施例对此并不进行限定。

通常，在UI中呈现的元素称为控件(View)，控件能够为用户提供一定的操作功能或用于显示一定内容。示例性的，

***原生控件包括文本控件(TextView)，输入框(EditText)，按钮(Button)，图片按钮(ImageButton)，图片控件(ImageView)等。

以安卓***举例，应用中所有UI内的元素都是由控件(View)和控件组(ViewGroup)构成的。一个UI中可以包含一个或多个View或ViewGroup。View是显示在显示界面中的一个元素；ViewGroup是一个用于存放View(或ViewGroup)的布局容器。ViewGroup中可以添加新的View或ViewGroup，使得各个View之间按照一定的层次和结构关系进行排列。示例性的，开发人员可使用线性布局(LinearLayout)、表格布局(TableLayout)、相对布局(RelativeLayout)、层布局(FrameLayout)、绝对布局(AbsoluteLayout)或网格布局(GridLayout)等布局方式设计App中每个UI内的View或ViewGroup，从而生成每个UI的布局文件；比如界面描述文件或组件界面描述文件等。

目前，

***支持在应用小组件中应用的布局方式和控件种类有限，无法满足用户多样的需求。本申请实施例提供一种用户接口界面实现方法，能够支持在应用小组件中应用多样的布局方式和控件种类。

本申请实施例提供的用户接口界面实现方法，不仅支持将

***原生的线性布局(LinearLayout)、层布局(FrameLayout)、相对布局(RelativeLayout)和网格布局(GridLayout)应用于应用小组件，还支持将

***原生的表格布局(TableLayout)、绝对布局(AbsoluteLayout)等布局方式应用于应用小组件。

本申请实施例提供的用户接口界面实现方法，不仅支持将

***原生的按钮(Button)，图片控件(ImageView)，图片按钮(ImageButton)，进度条(ProgressBar)，文本控件(TextView)，列表控件(ListView)，网格控件(GridView)，堆叠控件(StackView)，控件动态加载(ViewStub)，自适应控件(AdapterViewFlipper)，切换控件(ViewFlipper)，时钟(AnalogClock)，计时器(Chronometer)等控件应用于应用小组件；还支持将

***原生的输入框(EditText)，复选框(CheckBox)，滑动选择器(Picker)，滚动视图(ScrollView)，单选按钮(RadioButton)，评分条(RatingBar)，搜索框(SearchView)，拖动条(SeekBar)，开关(Switch)等控件应用于应用小组件。

示例性的，以手机作为电子设备100，手机上使用音乐App为例。手机100可以在桌面上显示音乐App的小组件(称为音乐小部件)。如图24A所示，手机100显示音乐小部件的UI910。UI 910包括图片控件911，用于显示App设定的图片；文本控件912，用于显示播放音乐的曲目名称；搜索框913，用于接收用户的输入，并响应于用户的输入文本进行搜索；图片按钮914，用于切换音乐小部件的显示风格；拖动条915，用于根据用户操作，调节播放音乐的进度；以及其他控件。

示例性的，如图24B所示，手机100可以接收用户对搜索框913的点击操作，响应于该点击操作，在桌面上显示放大的搜索框913以及软键盘91a。用户可以使用软键盘91a输入用于搜索框913的文本。手机100根据输入搜索框913的文本进行搜索。

示例性的，如图24C所示，手机100可以接收用户对拖动条915的拖动操作，调节播放音乐的进度。

本申请实施例提供的用户接口界面实现方法，还支持将操作***中自定义的UI编程能力应用于应用小组件，使得应用小组件中的控件具备操作***中扩展的视觉属性、布局属性、交互属性、动效属性和软硬件依赖属性等。其中，布局属性是指UI中各个控件的布局；比如控件的形状、位置、大小等。视觉属性是指控件的颜色、灰度等视觉效果。交互属性是基于用户行为提供控件响应的能力；比如基于用户的“确认”行为执行搜索。动效属性是指在控件上显示动画效果；比如在控件上显示点击回弹动效等。软硬件依赖属性是指控件依赖设备的软硬件参数。示例性的，操作***中扩展的布局属性可以包括自动拉伸、隐藏、均分、占比、延伸或折行等布局属性。其中，自动拉伸是指控件的高度或宽度根据窗口大小自动放大或缩小，以适应窗口大小。隐藏是指控件在布局中可见或不可见的能力。均分是指控件中的内容在布局中均匀分布。占比是指控件在指定方向上按照指定的百分比占据布局总大小。延伸是指控件根据显示屏尺寸在UI上延伸显示。折行是指控件中的内容在布局中通过一行或多行显示。

示例性的，如图24D所示，音乐小部件的UI 910上可以包括图片按钮916，用于显示音乐的歌词。手机可以接收用户对图片按钮916的点击操作，响应于用户对图片按钮916的点击操作，手机显示当前播放音乐的歌词。图片按钮916可以在UI 910上显示或者不显示。图片按钮916是否显示依赖于当前播放音乐是否有歌词。如果当前播放音乐有对应歌词，图片按钮916在UI 910上显示；如果当前播放音乐没有对应歌词，图片按钮916不在UI 910上显示。示例性的，如图24D所示，当前播放音乐是音乐1时，UI 910上包括图片按钮916；当前播放音乐是音乐2时，UI 910上不包括图片按钮916。

本申请实施例提供的用户接口界面实现方法，还支持将开发者在App中定义的布局方式和控件种类应用于应用小组件。

开发者可以根据设计目的，将

***原生的各种布局方式和控件种类，操作***中定义的布局方式和控件种类，以及在App中定义的布局方式和控件种类应用于应用小组件，方便用户使用。

在一种实现方式中，请参考图25，App开发阶段，开发者在电子设备200(开发者设备)中打开一种开发工具(比如，DevEco Studio)，在开发工具中使用界面描述语言，按照界面描述语言的语法语义规范进行界面描述和界面行为定义，进行UI开发；形成用于发布的界面描述文件和组件界面描述文件。

示例性的，以界面描述文件和组件界面描述文件采用json格式为例。开发者可以在界面描述文件和组件界面描述文件中分别进行UI的布局编排、数据&界面绑定、交互行为编排以及差异化描述等。应用和应用小组件中所有UI是由控件构成的。UI的布局编排，即编排UI中控件的属性。数据&界面绑定，即在界面描述文件或组件界面描述文件中声明并指定UI中的元素(比如控件、控件组)与后台数据之间的绑定关系。交互行为编排，即在界面描述文件或组件界面描述文件中声明控件响应事件对应的执行动作。控件支持的事件范围由控件支持的事件监听决定。例如，按钮(Button)支持对点击事件的监听setOnClickListener，则可以在界面描述文件中对控件绑定onClick(点击)事件。差异化描述，包括为不同类型的电子设备编排不同的代码段，使得应用小组件的UI在不同类型的电子设备上显示效果不同；根据电子设备的软硬件条件获取配置参数的值，应用于控件；定义适用于App内的参数等。

比如，用户可以在音乐App的组件界面描述文件中声明图24A-图24D所示的图片控件911，文本控件912，搜索框913，图片按钮914，拖动条915和图片按钮916，对这些控件进行属性编排；使得音乐小部件的UI 910中包括这些控件。这些控件可以是

***原生的控件，也可以是操作***中定义的或音乐App中定义的控件。

开发者还可以在组件界面描述文件中对这些控件应用操作***中定义的控件属性。比如，对图片按钮916应用操作***中定义的软件依赖属性。声明图片按钮916的显示属性依赖于App当前播放的音乐包括歌词。

开发者还可以在组件界面描述文件中将控件与后台数据进行绑定。比如，将拖动条915与后台数据进行绑定；手机接收到用户对拖动条915的拖动操作，则根据用户对拖动条915的拖动操作更新后台数据中当前音乐播放进度；如果后台数据中当前音乐播放进度发生变化，则更新拖动条915。

开发者还可以在组件界面描述文件中声明这些控件响应事件对应的执行动作。比如，声明搜索框913响应于点击事件，执行搜索动作。

之后，在开发者设备上生成App的安装包，其中包含界面描述文件和组件界面描述文件。App的安装包上传至服务器，App在服务器提供的应用市场中发布。用户可使用用户侧电子设备(上述电子设备100)在应用市场中下载App的安装包。用户侧电子设备运行App的安装包之后，获取安装包中的界面描述文件和组件界面描述文件。示例性的，如图25所示，手机100运行音乐App的安装包后，在桌面上显示音乐App的图标103。手机100可以接收用户对图标103的点击操作，运行音乐App，按照界面描述文件在显示屏显示音乐App的UI。

进一步的，用户侧电子设备根据用户的设置，在通知栏，桌面或负一屏上添加应用小组件。用户侧电子设备根据组件界面描述文件生成应用小组件的UI，并在通知栏，桌面或负一屏显示应用小组件的UI。示例性的，如图25所示，手机100在桌面上显示音乐小部件的UI 910。

请参考图26，电子设备100中应用小组件进程是独立于应用进程运行的。安装于电子设备100的应用通过调用应用进程运行，应用小组件通过调用应用小组件进程运行。比如，将应用小组件设置在桌面，桌面进程即为应用小组件进程；将应用小组件设置在负一屏，负一屏显示进程即为应用小组件进程；将应用小组件设置在指定的应用中，该指定应用的进程即为应用小组件进程。

电子设备100还包括自定义UI引擎11，小组件框架12等单元。

在一些示例中，应用进程获取App的界面描述文件，调用自定义UI引擎11解析和执行App的界面描述文件，生成App的UI。自定义UI引擎11可以包括UI解析引擎11a，UI执行引擎11b，MVVM(model-view-viewmodel)框架11c等。UI解析引擎11a用于解析界面描述文件，将界面描述文件中内容转换成与UI执行引擎11b匹配的数据格式。在一些示例中，UI解析引擎11a还可以对界面描述文件中内容进行语法校验，如果对界面描述文件语法校验成功，则对界面描述文件进行解析；如果对界面描述文件语法校验不成功，则不执行解析界面描述文件。UI执行引擎11b用于根据UI解析引擎11a解析的数据构建UI的控件(实例化控件和属性设置)，对控件进行布局编排，生成界面描述文件中声明的界面；还可以实现器件事件与用户行为之间的映射，响应于用户行为执行界面描述文件中定义的用户行为对应的动作等。MVVM框架11c用于对UI中的元素与后台数据进行双向绑定。在界面描述文件中，声明并指定UI中的元素(比如控件、控件组)与后台数据之间的绑定关系，可选的，还可以进行简单的数据实例设置之后；MVVM框架11c可以实现根据UI改变刷新后台数据，以及根据后台数据改变自动刷新对应UI。帮助开发者专注于UI设计与编排，简化UI开发过程，大幅减少开发者为实现前后端数据交互投入的开发时间。

在一些示例中，应用进程获取组件界面描述文件，调用小组件框架12对组件界面描述文件进行处理，形成用于显示应用小组件UI的小组件UI数据。其中，小组件框架12包括虚拟控件构建12a、数据绑定12b、小组件服务12c和事件代理12d等模块。其中，虚拟控件构建12a通过调用UI解析引擎11a解析组件界面描述文件，对解析后的组件界面描述文件进行实例化，并调用UI执行引擎11b构造界面，构建出控件、控件组等，形成小组件UI数据。这些小组件UI数据存在于应用进程内，用于和后台数据(比如，控件模型(ViewModel))进行绑定。数据绑定12b用于将虚拟控件构建12a构造的控件或控件组的属性、交互事件等与后台数据(比如，处理业务逻辑的控件模型(ViewModel)，包含了与虚拟对象相关的数据处理逻辑)进行绑定。小组件服务12c用于对生成应用小组件UI过程中，当前处理的对象以及与该对象绑定的数据(model)进行跟踪处理；还用于管理应用进程和应用小组件进程之间的数据传输；还用于管理跨进程的事件代理，收发跨进程事件。事件代理12d用于处理应用小组件进程中事件的回传与响应。示例性的，事件代理12d中定义一个专用的事件传输类(比如HiAction)，该事件传输类支持实现Parcelable接口，可以跨进程传输(比如，调用

原生的跨进程Binder机制)。该事件传输类中存储一系列事件，每个事件包括布局标识，控件标识，事件类型等信息。当用户对应用小组件进行操作，应用小组件进程接收到该操作，触发一个交互事件，即在HiAction中新增一个事件。应用小组件进程将该新增的事件传输给应用进程。应用进程响应该事件，执行相应的动作。应用进程还调用MVVM框架进行处理；若存在数据或控件属性变化，则更新小组件UI数据，更新跨进程的界面数据与属性，进一步更新应用小组件进程的显示界面。在一种实现方式中，应用进程还将组件界面描述文件发送给应用小组件进程。应用小组件进程调用小组件框架12对组件界面描述文件进行处理，形成小组件UI数据，并显示小组件UI数据，即显示应用小组件IU。

电子设备上安装了应用，用户可以在通知栏，桌面或负一屏上添加应用对应的应用小组件。

在一些实施例中，用户不打开应用，单独添加应用对应的应用小组件。示例性的，请参考图27，手机100接收用户在桌面上的双指捏合操作，响应于桌面上的双指捏合操作，手机100显示快捷设置界面1010，快捷设置界面1010包括“窗口小工具”选项1011，用于在桌面上添加桌面小部件。手机100可以响应于用户对“窗口小工具”选项1011的点击操作，显示桌面小部件添加界面1020。桌面小部件添加界面1020包括“音乐”选项1021，用于在桌面上添加音乐小部件。手机100接收用户对“音乐”选项1021的点击操作，响应于用户对“音乐”选项1021的点击操作，手机100的桌面上显示“音乐小部件”的UI 910。

在另一些实施例中，用户在应用中添加应用对应的应用小组件。示例性的，如图28所示，用户打开手机100上的“音乐”应用的“音乐设置”界面1030，“音乐设置”界面1030包括“桌面小部件”选项1031。“桌面小部件”选项1031用于在手机桌面上添加音乐小部件。手机100接收用户对“桌面小部件”选项1031的点击操作，响应于用户对“桌面小部件”选项1031的点击操作，手机100显示“桌面小部件”界面1040。“桌面小部件”界面1040包括“风格1”选项1041和“风格2”选项1042；还包括“添加”按钮1043和“取消”按钮1044。用户可以通过点击“添加”按钮1043，将音乐小部件以“风格1”选项1041或“风格2”选项1042对应的界面添加至桌面；还可以通过点击“取消”按钮1044退出添加音乐小部件。示例性的，手机100接收用户对“添加”按钮1043的点击操作，根据用户选择，将音乐小部件以“风格2”选项1042对应的界面添加至桌面。手机100的桌面上显示“音乐小部件”的UI 910。

在一种实现方式中，请参考图29A，用户进行了添加应用小组件的操作。电子设备100的应用小组件进程接收到用户添加应用小组件的操作(比如，用户对图27中“音乐”选项1021的点击操作)，应用小组件进程通知应用进程接收到用户添加应用小组件的操作；如果应用进程为未启动状态，则电子设备100拉起应用进程，使得应用进程在后台运行。或者，电子设备100的应用进程接收到用户添加应用小组件的操作(比如，用户对图28中“添加”按钮1043的点击操作)，应用进程通知应用小组件进程接收到用户添加应用小组件的操作。

应用进程从应用安装包获取到组件界面描述文件。应用进程调用自定义UI引擎11对组件界面描述文件进行解析执行，之后调用虚拟控件构建12a进行小组件UI数据控件构建，按照组件界面描述文件中的布局编排生成控件、控件组等，形成小组件UI数据(包括控件和控件的布局等信息)。

需要说明的是，该组件界面描述文件可以是独立于界面描述文件的文件，也可以是界面描述文件中的一段代码。可选的，电子设备100获取到组件界面描述文件后，可以仅对其中的部分代码段进行解析和执行。比如，用户选择图28中“风格1”选项1041对应的音乐小部件界面，手机100在接收到用户对“添加”按钮1043的点击操作后，解析和执行组件界面描述文件中“风格1”对应的代码段；用户选择图28中“风格2”选项1042对应的音乐小部件界面，手机100在接收到用户对“添加”按钮1043的点击操作后，解析和执行组件界面描述文件中“风格2”对应的代码段。

之后，数据绑定12b调用MVVM框架11c将小组件UI数据与后台数据(比如，控件模型)进行数据绑定。这样，如果后台数据发生变化，可以刷新对应的小组件UI数据；小组件UI数据改变，可以刷新对应的后台数据。

进一步的，应用进程将组件界面描述文件发送给应用小组件进程。

应用小组件进程调用自定义UI引擎11对组件界面描述文件进行解析执行，之后调用虚拟控件构建12a进行小组件UI数据控件构建，按照组件界面描述文件中的布局编排生成控件、控件组等，形成小组件UI数据(包括控件和控件的布局等信息)；并按照该小组件UI数据进行显示，即显示应用小组件UI。由于应用进程生成小组件UI数据与应用小组件进程生成应用小组件UI使用的是同一段代码段，应用小组件UI上的控件与小组件UI数据中的控件是一一对应的。

可选的，如图29B所示，应用进程也可以在生成小组件UI数据后，将小组件UI数据发送给应用小组件进程，应用小组件进程按照该小组件UI数据进行显示，即显示应用小组件UI。这样，应用小组件UI上的控件与小组件UI数据中的控件也是一一对应的。

在通知栏，桌面或负一屏上添加应用小组件之后，用户可以在应用小组件UI上对应用进行操作。比如，用户可以拖动图24A中音乐小部件UI 910上的拖动条915，调节音乐应用当前播放音乐的播放进度。

在一种实现方式中，请参考图29C，当用户在应用小组件的UI上进行操作时，应用小组件进程接收到用户操作，将用户操作传输给事件代理12d。事件代理12d中定义了一个专用的事件传输类，该事件传输类用于跨进程传输。该事件传输类中存储多个事件，其中每个事件包括布局标识、控件标识、事件类型等信息。事件代理12d接收到用户操作后，在事件传输类中产生该操作对应的事件，将事件发送给应用进程(如果应用进程未启动，则拉起应用进程，使得应用进程在后台运行)。应用进程接收到该事件后，根据布局标识和控件标识获取对应的控件，并根据作用于该控件上的该事件执行相应的业务逻辑。由于应用小组件UI上的控件与小组件UI数据中的控件存在一一对应关系，应用进程还根据接收到的事件刷新后台数据。后台数据改变触发小组件UI数据更新，应用进程还可以将更新的小组件UI数据发送给应用小组件进程，应用小组件进程按照刷新后的小组件UI数据显示更新的应用小组件UI。

在一些实施例中，请参考图29D，应用进程启动，应用进程获取界面描述文件。应用进程调用自定义UI引擎11对界面描述文件进行解析执行，生成应用的UI，并显示该应用的UI。之后，MVVM框架11c将应用的UI与后台数据(比如，控件模型)进行数据绑定。

应用进程接收到用户添加应用小组件的操作，应用进程从应用安装包获取组件界面描述文件。应用进程调用自定义UI引擎11对组件界面描述文件进行解析执行，之后调用虚拟控件构建12a进行小组件UI数据控件构建，按照组件界面描述文件中的布局编排生成控件、控件组等，形成小组件UI数据(包括控件和控件的布局等信息)。之后，数据绑定12b调用MVVM框架11c将小组件UI数据与后台数据(比如，控件模型)进行数据绑定。进一步的，应用小组件进程根据小组件UI数据显示应用小组件的UI。

这样，电子设备100的显示屏上显示应用的UI以及对应的应用小组件的UI。

在一种示例中，请参考图30，其示出了本申请实施例提供的用户接口界面实现方法的一种流程示例。

用户进行了添加应用小组件的操作。电子设备100的应用小组件进程接收到用户添加应用小组件的操作(比如，用户对图27中“音乐”选项1021的点击操作)，应用小组件进程通知应用进程接收到用户添加应用小组件的操作；如果应用进程为未启动状态，则电子设备100拉起应用进程，使得应用进程在后台运行。或者，电子设备100的应用进程接收到用户添加应用小组件的操作(比如，用户对图28中“添加”按钮1043的点击操作)，应用进程通知应用小组件进程接收到用户添加应用小组件的操作。小组件框架、MVVM框架、后台数据等模块进行初始化。小组件框架从应用安装包中获取组件界面描述文件，并发送给虚拟控件构建模块。虚拟控件构建模块根据组件界面描述文件进行控件构建，形成小组件UI数据。数据绑定模块调用MVVM框架将小组件UI数据和后台数据进行绑定。应用进程调用小组件服务进行绑定服务，小组件服务对小组件UI数据绑定事件代理；之后，跨进程发送小组件UI数据及小组件UI数据的事件代理等信息。这样，应用小组件进程收到小组件UI数据和小组件UI数据的事件代理信息后，可以按照小组件UI数据显示应用小组件UI。

应用小组件添加成功之后，用户可以在应用小组件UI上进行操作。应用小组件进程接收到用户在应用小组件UI上的操作，事件代理增加该操作相应的事件，将事件发送给应用进程；应用进程响应于该事件执行业务逻辑，并调用MVVM框架对后台数据进行更新。当应用的业务数据发生变化，后台数据变化引起MVVM框架更新小组件UI数据。应用进程跨进程发送更新的小组件UI数据，应用小组件进程接收到更新的小组件UI数据后，可以按照更新的小组件UI数据显示更新的应用小组件UI。

本申请实施例提供的用户接口界面实现方法，应用进程根据组件界面描述文件生成小组件UI数据，并向应用小组件进程发送组件界面描述文件或小组件UI数据；应用小组件进程根据组件界面描述文件或小组件UI数据生成应用小组件UI。开发者可以在组件界面描述文件中声明

***原生的布局方式和控件类型，还可以声明操作***中自定义的控件类型和UI编程能力，以及开发者在App中定义的布局方式和控件种类。操作***支持应用小组件进程调用UI引擎对组件界面描述文件进行解析执行，生成应用小组件UI。这样，支持应用小组件的UI上显示各种布局方式和控件类型，方便用户使用应用小组件，提高用户体验。

在一些实施例中，电子设备上添加了应用小组件之后，电子设备关机。电子设备再次开机后，显示应用小组件的UI。即电子设备添加了应用小组件之后，重新加载应用小组件UI。如图31所示，手机100开机，手机100的桌面显示音乐小部件的UI 910。

在一种示例中，请参考图32，其示出了电子设备重新加载应用小组件UI方法的一种流程示例。

电子设备开机后，应用小组件进程启动。应用小组件进程从应用的安装包中获取组件界面描述文件。应用小组件进程调用自定义UI引擎对组件界面描述文件进行解析执行，构建小组件UI数据，并按照小组件UI数据显示应用小组件UI。

应用小组件重新加载成功之后，用户可以在应用小组件UI上进行操作。应用小组件进程接收到用户在应用小组件UI上的操作，事件代理增加该操作对应的事件，并拉起应用进程，使得应用进程在***后台运行，将事件发送给应用进程；应用进程响应于该事件执行相应的业务逻辑，并调用MVVM框架更新后台数据。事件交互和后台数据变化的处理流程可参考图30的相关描述，此处不再赘述。

在该场景中，应用小组件进程生成并绘制加载应用小组件UI即可。应用进程生成小组件UI数据，绑定小组件UI数据与后台数据，建立小组件UI数据与应用小组件UI的对应关系等流程可以不再执行。

本申请实施例提供的用户接口界面实现方法，电子设备的应用进程根据组件界面描述文件生成小组件UI数据，将小组件UI数据与后台数据绑定；应用小组件进程也根据组件界面描述文件获取小组件UI数据，并将小组件UI数据显示为应用小组件的UI。这样，应用小组件的UI与后台数据建立了对应关系，可以支持应用小组件的UI上显示各种布局方式和控件类型，方便用户使用应用小组件，提高用户体验。

本申请实施例还提供一种用户接口界面实现方法，用于将电子设备上的App投屏至播放设备进行播放时UI的呈现。

随着物联网(Internet of things，IoT)快速发展，IoT设备类型与数量均快速增长。消费者可以使用手机、平板电脑等设备作为IoT设备的控制设备，对IoT设备进行控制，使得控制设备和IoT设备协同工作。比如，用户在控制设备上使用App时，用户在控制设备上使用App时，可以将该App投屏至IoT设备进行播放(IoT设备称为播放设备)。比如，由于电视的屏幕尺寸较大，可以为用户带来更好的观看体验，用户可以将手机上的App投屏至电视上进行播放。由于IoT设备屏幕形态和尺寸差异巨大，如何在各种不同形态和尺寸屏幕的IoT设备上进行投屏，获得与IoT设备屏幕形态和尺寸相匹配的投屏界面，是需要解决的一个问题。

本申请实施例提供一种用户接口界面实现方法及装置，支持将控制设备上各种UI投屏至IoT设备进行播放，提高用户体验。控制设备即为上述各实施例中用户侧电子设备(电子设备100)。

本申请实施例提供一种用户接口界面实现方法，请参考图33，电子设备200上安装有应用开发工具(比如，Android Studio，DevEco Studio等)。本申请中电子设备200也可称为开发者设备。通常，开发者使用一种界面描述语言，在应用开发工具中开发App的UI以及播放端UI。可以理解的，在一些实施例中，开发者可以直接在控制设备100上开发App的UI和播放端UI，并在控制设备100上运行该App；即电子设备200和控制设备100可以是同一个电子设备。本申请实施例对此并不进行限定。

在一些实施例中，开发者在应用开发工具中开发App的UI(即电子设备安装、运行App时显示的UI)，形成界面描述文件。本申请中界面描述文件也可称为描述文件。开发者还在应用开发工具中开发App的用于播放端显示的UI(即播放端UI)，形成播放端界面描述文件。开发者将界面描述文件和播放端界面描述文件打包到App的安装包，在服务器300提供的应用市场中发布App。应用市场中可以提供各个App的安装包供用户下载。例如，安装包可以为

应用程序包(Android application package，APK)文件。

以手机为控制设备100举例，用户可使用手机在应用市场中下载某一App的安装包。以视频App举例，手机下载视频App的安装包后，通过运行该安装包可将视频App安装在手机中。这样，手机也获取了安装包中的界面描述文件和播放端界面描述文件。

可选的，在一些实施例中，也可以将界面描述文件作为播放端界面描述文件，即界面描述文件和播放端界面描述文件是同一文件。

手机可以按照界面描述文件在显示屏呈现相应的App的UI。示例性的，手机下载视频App的安装包后，桌面生成“视频”图标101。用户可以点击“视频”图标101，以打开视频App。响应于用户对“视频”图标101的点击操作，手机运行视频App。手机上安装有OS平台，OS平台的自定义UI引擎读取界面描述文件，解析、执行界面描述语言，按照界面描述文件中的界面描述渲染出视频App的UI。手机的显示装置(比如显示屏)呈现视频App的UI 105。进一步的，界面描述文件中还可以包括对界面行为的定义。手机可以响应于用户对UI 105的操作，按照界面描述文件中定义的界面行为，执行相应的界面动作，实现界面行为。通常，OS平台还有对应的程序语言用于实现界面行为，实现UI 105的动态变化以及响应用户对UI 105的操作；例如

使用JAVA，

使用swift编程语言实现界面行为。

手机还可以将视频App的各个界面投屏到播放设备1000上进行显示。比如，将视频App的主界面或播放界面投屏至播放设备1000。播放设备1000按照播放端界面描述文件中与其设备类型匹配的界面描述渲染出对应的的播放端UI。示例性的，请继续参考图33，视频App的UI 105上包括“投屏”按钮106；“投屏”按钮106用于将手机上运行的App的界面投屏至播放设备进行显示。手机接收用户对“投屏”按钮106的点击操作，响应于用户对“投屏”按钮106的点击操作，手机显示设备选择界面107。设备选择界面107包括提示信息108，用于提示用户选择一个播放设备进行投屏。设备选择界面107还包括“客厅的电视”选项109和“我的平板电脑”选项10a。用户可以点击“客厅的电视”选项109，以将视频App的UI投屏至智能电视进行显示。手机接收用户对“客厅的电视”选项109的点击操作，响应于用户对“客厅的电视”选项109的点击操作，手机将视频App的UI投屏至智能电视。智能电视显示UI 105对应的播放端UI 1001。用户还可以点击“我的平板电脑”选项10a，以将视频App的UI投屏至平板电脑进行显示。手机接收用户对“我的平板电脑”选项10a的点击操作，响应于用户对“我的平板电脑”选项10a的点击操作，手机将视频App的UI投屏至平板电脑。平板电脑显示UI 105对应的播放端UI 1002。智能电视和平板电脑的设备类型不同，屏幕尺寸和形态也不同，智能电视上的播放端UI 1001与平板电脑上的播放端UI 1002的界面布局是不同的；即播放端UI在不同设备类型的电子设备上差异化显示。

上述播放设备1000可以包括便携式计算机(如手机等)、智能家居设备(比如，智能电视、智慧屏、大屏、智能音箱等)、手持计算机、个人数字助理(personal digitalassistant，PDA)、可穿戴设备(比如，智能手表、智能手环等)、平板电脑、笔记本电脑、上网本、增强现实(augmented reality，AR)\虚拟现实(virtual reality，VR)设备、车载电脑等，本申请实施例对此不做任何限制。在一种示例中，播放设备1000可以包括图2所示结构，此处不再赘述。可以理解的是，本申请实施例图2示意的结构并不构成对播放设备1000的具体限定。在本申请另一些实施例中，播放设备1000可以包括比图2所示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图2所示的部件可以以硬件，软件或软件和硬件的组合实现。

请参考图34，控制设备100包括自定义UI引擎11，投屏框架13，传输通道适配14等单元。自定义UI引擎11提供IF1接口，投屏框架13提供IF2、IF3、IF4和IF5接口。

接口IF1-接口IF5的说明如表2所示：

表2

自定义UI引擎11解析和执行App的界面描述文件，生成App的UI。自定义UI引擎11可以包括UI解析引擎11a，UI执行引擎11b，MVVM(model-view-viewmodel)框架11c等。UI解析引擎11a用于解析界面描述文件，将界面描述文件中内容转换成与UI执行引擎11b匹配的数据格式。在一些示例中，UI解析引擎11a还可以对界面描述文件中内容进行语法校验，如果对界面描述文件语法校验成功，则对界面描述文件进行解析；如果对界面描述文件语法校验不成功，则不执行解析界面描述文件。UI执行引擎11b用于根据UI解析引擎11a解析的数据构建UI的控件(实例化控件和属性设置)，对控件进行布局编排，生成界面描述文件中声明的界面；还可以实现器件事件与用户行为之间的映射，响应于用户行为执行界面描述文件中定义的用户行为对应的动作等。MVVM框架11c用于对UI中的元素与后台数据进行双向绑定。在界面描述文件中，声明并指定UI中的元素(比如控件、控件组)与后台数据之间的绑定关系，可选的，还可以进行简单的数据实例设置之后；MVVM框架11c可以实现根据UI改变刷新后台数据，以及根据后台数据改变自动刷新对应UI。帮助开发者专注于UI设计与编排，简化UI开发过程，大幅减少开发者为实现前后端数据交互投入的开发时间。

传输通道适配14用于适配控制设备100和播放设备1000之间的数据传输通道。比如，将控制设备100的数据转换为适用于数据传输通道的格式，使得控制设备100可以通过数据传输通道向播放设备1000发送数据。

投屏框架13用于对播放端界面描述文件进行处理，形成用于显示播放端UI的播放端UI数据。投屏框架13包括虚拟控件构建13a、数据绑定13b、投屏服务13c、数据收发13d、资源传输13e、事件代理13f和生命周期13g等模块。其中，虚拟控件构建13a通过调用UI解析引擎11a和UI执行引擎11b，根据播放端界面描述文件构建控件、控件组等，形成播放端UI数据。这些播放端UI数据存在于App进程内，用于和后台数据进行绑定。数据绑定13b用于将虚拟控件构建13a构造的控件或控件组的属性、交互事件等与后台数据(比如，处理业务逻辑的控件模型(ViewModel))进行绑定。投屏服务13c用于对投屏过程中，当前处理的对象以及与该对象绑定的数据(model)进行跟踪处理；还用于管理控制设备100和播放设备1000之间的数据传输通道。数据收发13d用于控制设备100和播放设备1000之间的数据发送和接收。比如，可以定义收发代理的接口，实现控制设备100内置的默认收发器。再比如，可以在App内按照接口规范自定义适用于该App的收发器。例如，App内建立通过ContentProvider方式传输信息，则在数据收发13d中send()函数中用ContentProvider实现数据发送和接收。资源传输13e用于传输特定类型的数据资源(比如，数据量大于设定值的数据、图片、视频等)。资源传输13e用于对该特定类型的数据资源进行管理，比如发送、接收、缓存、标识、进度控制等。事件代理13f是用于传递事件的通道，以避免事件被数据传输阻塞。生命周期13g用于对投屏过程中控制设备100与播放设备1000的运行实体间联合的生命周期进行管理。示例性的，控制设备100和播放设备1000的生命周期如表3所示：

表3

示例性的，如图35A所示，控制设备100在单机运行状态，触发投屏，等待用户授权向播放设备投屏。如果用户同意授权，播放设备向控制设备发送授权指令，控制设备100进入服务端运行状态。如果用户拒绝授权，播放设备向控制设备发送拒绝授权指令，控制设备100停止投屏。控制设备100在服务端运行状态时，App切换至后台运行，则停止向播放设备推送数据；App切换至前台运行，开始向播放设备推送数据。控制设备100在服务端运行状态时，控制设备关闭App，或播放设备关闭，则停止投屏。控制设备100在服务端运行状态时，播放设备的App切换至后台运行，控制设备100进入服务端暂停状态。控制设备100在服务端暂停状态，播放设备的App切换至前台播放，控制设备100进入服务端运行状态。控制设备100在服务端暂停状态，播放设备关闭，则停止投屏。

示例性的，如图35B所示，播放设备1000收到控制设备发起的投屏请求，等待用户确认授权。如果用户确认授权，播放设备1000进入投屏运行状态；如果用户拒绝授权，播放设备1000停止运行。播放设备1000在投屏运行状态，App切换至后台运行，则进入后台驻留状态。播放设备1000在后台驻留状态，App切换至前台播放，则进入投屏运行状态。播放设备1000在投屏运行状态或后台驻留状态，播放设备关闭或控制设备关闭App，则停止运行。

请参考图36，App开发阶段，开发者在开发者设备上生成App的安装包，其中包含界面描述文件和播放端界面描述文件。开发者使用界面描述语言，按照界面描述语言的语法语义规范在开发者设备上开发界面描述文件和播放端界面描述文件，在界面描述文件和播放端界面描述文件中添加代码，进行UI开发。

开发者可以在界面描述文件和播放端界面描述文件中分别进行UI的布局编排、数据&界面绑定、交互行为编排以及差异化描述等。

App中所有UI是由控件构成的。UI的布局编排，即编排UI中控件的属性。比如，UI中的控件可以包括所有

原生控件以及操作***中拓展的控件，还支持开发者在App中自定义的或者通过静态包集成的控件。其中，控件具体可以包括文本控件，例如TextView控件、EditText控件等，也可以包括按钮控件，例如Button控件、ImageButton控件等，还可以包括图片控件，例如Image控件等，本申请实施例对此不做任何限制。控件属性包括

原生属性以及操作***中扩展的视觉属性、布局属性、交互属性、动效属性和软硬件依赖属性等。视觉属性是指控件的颜色、灰度等视觉效果。交互属性是基于用户行为提供控件响应的能力；比如基于用户的“确认”行为执行搜索。动效属性是指在控件上显示动画效果；比如在控件上显示点击回弹动效等。软硬件依赖属性是指控件依赖设备的软硬件参数。

数据&界面绑定，即在界面描述文件或播放端界面描述文件中声明并指定UI中的元素(比如控件、控件组)与后台数据之间的绑定关系。

交互行为编排，即在界面描述文件或播放端界面描述文件中声明控件响应事件对应的执行动作。控件支持的事件范围由控件支持的事件监听决定。例如，按钮控件(Button)支持对点击事件的监听setOnClickListener，则可以在界面描述文件中对控件绑定onClick(点击)事件。

差异化描述：

1、开发者可以在界面描述文件或播放端界面描述文件中声明电子设备配置参数的变量。当电子设备运行界面描述文件或播放端界面描述文件时，访问电子设备的配置参数，电子设备根据其软硬件条件获取配置参数的值。这样，不同类型的电子设备运行界面描述文件或播放端界面描述文件时，由于其软硬件条件不同，配置参数不同，生成的UI不同。

2、开发者可以在界面描述文件或播放端界面描述文件中自定义参数。以界面描述文件和播放端界面描述文件采用json格式为例，界面描述文件或播放端界面描述文件可以包括style、layout-data-common等部分。开发者在style中定义myTextStyle，并可以在layout-data-common中以$style.myTextStyle的方式调用该自定义参数。示例如下，

3、开发者可以在界面描述文件或播放端界面描述文件中针对指定设备进行代码编排。示例性的，以界面描述文件和播放端界面描述文件采用json格式为例，界面描述文件或播放端界面描述文件可以包括如下结构：

开发者可以在layout-data-common中声明通用播放端UI，各种类型的播放设备都解析layout-data-common中内容，按照layout-data-common中的内容布局通用播放端UI。layout-data-uimode用于描述指定设备的播放端UI。在一种实现方式中，layout-data-uimode中声明指定设备播放端UI与通用播放端UI的区别。指定设备结合layout-data-common和layout-data-uimode中内容进行解析执行，生成指定设备的播放端UI。在另一种实现方式中，layout-data-uimode中声明适用于指定设备的播放端UI的全部条件。指定设备按照layout-data-uimode中的内容布局其播放端UI。其中，指定设备可以为手机、手表、车机、智能家居设备(比如，智能电视、智慧屏、智能音箱等)、大屏、平板电脑、笔记本电脑或台式电脑等类型其中的一种。比如，layout-data-uimode的具体形式可以包括layout-data-phone(用于手机)，layout-data-watch(用于手表)，layout-data-television(用于智能电视)，layout-data-pad(用于平板电脑)，layout-data-car(用于车机)等。这样，不同类型的播放设备，可以根据其对应的代码段进行解析执行并构建播放端UI；实现在不同类型的播放设备上显示与播放设备的类型相匹配的播放端UI。

开发者将在开发者设备上生成的App安装包上传至服务器，App在服务器提供的应用市场中发布。用户可使用用户侧电子设备(上述控制设备100)在应用市场中下载App的安装包。控制设备运行App的安装包之后，获取安装包中的界面描述文件和播放端界面描述文件。当控制设备运行App时，按照界面描述文件在显示屏显示与该控制设备相匹配的UI。

控制设备运行App过程中，还可以将App的界面投屏至播放设备进行显示。比如，控制设备根据用户输入确定进行投屏的播放设备，向播放设备发送投屏指令，投屏指令中包括投屏界面的标识。播放设备接收到投屏指令，根据投屏界面的标识获取到对应的播放端界面描述文件，并按照播放端界面描述文件形成与其设备类型匹配的播放端UI。

示例性的，请参考图37A，控制设备100接收到用户的投屏操作(比如，手机接收到用户对图33中“我的平板电脑”选项10a的点击操作)，从App的安装包获取到当前界面对应的播放端界面描述文件。控制设备100还根据用户输入确定进行投屏的播放设备1000的设备类型(比如，手机接收到用户对图33中“客厅的电视”选项109的点击操作，则确定播放设备1000为智能电视；手机接收到用户对图33中“我的平板电脑”选项10a的点击操作，则确定播放设备1000为平板电脑)。

控制设备100的OS中的虚拟控件构建13a通过调用自定义UI引擎11解析和执行播放端界面描述文件中播放设备1000的设备类型对应的代码段，根据播放端界面描述文件中播放设备1000的设备类型对应的代码段进行控件构建，按照该代码段中的布局编排生成控件、控件组等，形成播放端UI数据。比如，播放设备1000是智能电视，控制设备100对播放端界面描述文件中与智能电视对应的代码段进行解析执行，形成向智能电视投屏的播放端UI数据；播放设备1000是平板电脑，控制设备100对播放端界面描述文件中与平板电脑对应的代码段进行解析执行，形成向平板电脑投屏的播放端UI数据。之后，数据绑定13b调用MVVM框架11c将播放端UI数据中的对象与后台数据(比如，控件模型)进行数据绑定。这样，如果后台数据发生变化可以刷新对应的播放端UI数据，播放端UI数据改变刷新对应的后台数据。进一步的，控制设备100将播放端界面描述文件以及资源文件(包括播放端界面描述文件中关联的数据资源)通过数据收发13d发送给播放设备1000。在一种实现方式中，控制设备100将播放端界面描述文件进行编码，布局信息、资源值、数据、响应事件定义等数据编码后，经数据传输通道传输至播放设备1000；特定类型的数据资源(比如，数据量大于设定值的数据、图片、视频等)，经特定数据传输通道传输至播放设备1000。可选的，特定类型的数据资源可以在发送播放端界面描述文件之前传输至播放设备1000，这样，提高了将播放端界面描述文件传输至播放设备1000的速率，缩短播放设备1000显示播放端UI的时延。控制设备100还初始化事件代理13f，建立控制设备100和播放设备1000之间的事件传输通道，用于传输事件信息。

播放设备1000通过数据收发13d接收到播放端界面描述文件以及数据资源，播放设备1000的OS中的虚拟控件构建13a通过调用自定义UI引擎11解析和执行播放端界面描述文件中播放设备1000的设备类型对应的代码段，根据播放端界面描述文件中播放设备1000的设备类型对应的代码段进行控件构建，按照该代码段中的布局编排生成控件、控件组等，形成播放端UI数据(包括控件和控件的布局等信息)；并按照该播放端UI数据进行显示，即显示播放端UI。由于控制设备100生成播放端UI数据与播放设备1000生成播放端UI数据使用的是同一段代码段，播放设备1000生成的播放端UI上的控件与控制设备100生成的播放端UI数据中的控件是一一对应的。

生成播放端UI后，播放设备1000在显示屏显示与播放设备屏幕的形态和尺寸相匹配的播放端UI。示例性的，如图36所示，智能电视作为播放设备时，智能电视解析和执行播放端界面描述文件中layout-data-television代码段，生成智能电视相应的播放端UI；平板电脑作为播放设备时，平板电脑解析和执行播放端界面描述文件中layout-data-pad代码段，生成平板电脑相应的播放端UI。

可选的，在一些实施例中，如图37B所示，控制设备100根据播放端界面描述文件中播放设备1000的设备类型对应的代码段进行控件构建，按照该代码段中的布局编排生成播放端UI数据之后，将生成的播放端UI数据发送给播放设备1000。播放设备1000接收到播放端UI数据后，根据该播放端UI数据显示播放端UI。

本申请实施例提供的用户接口界面实现方法，播放设备根据播放端界面描述文件中播放设备的设备类型对应的代码段，生成与该播放设备相对应的播放端UI。不同类型的播放设备显示的播放端UI与其屏幕的形状和尺寸相匹配。并且，开发者在开发App时，可以方便的进行播放端UI开发，在App的播放端界面描述文件中定义各种类型的控件(包括所有

原生控件以及操作***中拓展的控件，还支持开发者在App中自定义的或者通过静态包集成的控件)，支持的控件类型多样；使得各种类型的App都可以支持投屏功能，并且播放端UI支持的控件类型更丰富多样，方便用户使用。

在一种实现方式中，控制设备100的OS中的虚拟控件构建13a解析和执行播放端界面描述文件中播放设备1000的设备类型对应的代码段，根据播放端界面描述文件中播放设备1000的设备类型对应的代码段构建播放端UI数据。该播放端UI数据不在控制设备100的显示屏进行显示(即播放端UI数据存在于App进程内，不向显示进程发送)。控制设备100显示的是根据界面描述文件生成的UI。控制设备100的界面投屏至播放设备1000后，用户可以在控制设备100上进行其他操作，播放设备1000正常播放投屏内容。

示例性的，如图38A所示，手机显示“视频”App的界面1210，界面1210包括“投屏”按钮1211。手机接收用户对“投屏”按钮1211的点击操作，根据用户的输入确定播放设备。手机根据用户输入，向智能电视投屏。如图37A或图37B所示，手机根据播放端界面描述文件生成播放端UI数据，并向智能电视发送播放端界面描述文件。智能电视根据播放端界面描述文件生成播放端UI数据，并按照播放端UI数据显示播放端UI。请参考图38A，智能电视显示播放端UI 1220。

之后，用户可以继续对手机进行其他操作。示例性的，如图38A所示，手机接收用户对图片1212的点击操作，响应于用户对图片1212的点击操作，显示“视频”App的界面1230。

这样，控制设备向播放设备投屏后，可以继续执行其他功能，与播放设备播放投屏内容独立运行、互不影响，实现设备间更好地协同工作。

示例性的，如图38B所示，控制设备100的OS中的自定义UI引擎11解析和执行界面描述文件，生成应用的UI，并显示该应用的UI。MVVM框架11c将应用的UI与后台数据(比如，控件模型)进行数据绑定。

控制设备100的OS中的虚拟控件构建13a通过调用自定义UI引擎11解析和执行播放端界面描述文件中播放设备1000的设备类型对应的代码段，根据播放端界面描述文件中播放设备1000的设备类型对应的代码段进行控件构建，按照该代码段中的布局编排生成控件、控件组等，形成播放端UI数据。之后，数据绑定13b调用MVVM框架11c将播放端UI数据中的对象与后台数据(比如，控件模型)进行数据绑定。进一步的，控制设备100将播放端界面描述文件以及资源文件(包括播放端界面描述文件中关联的数据资源)通过数据收发13d发送给播放设备1000；或者将播放端UI数据发送给播放设备1000，这样播放设备1000可以根据播放端UI数据显示播放端UI。

在另一种实现方式中，控制设备100的OS中的虚拟控件构建13a解析和执行播放端界面描述文件中播放设备1000的设备类型对应的代码段，根据播放端界面描述文件中播放设备1000的设备类型对应的代码段构建播放端UI数据。App进程将播放端UI数据发送给显示进程，在控制设备100的显示屏上显示播放端UI。控制设备100和播放设备1000显示的是根据同一段代码段生成的播放端UI。

示例性的，如图39A所示，手机显示“视频”App的界面1210，界面1210包括“投屏”按钮1211。手机接收用户对“投屏”按钮1211的点击操作，根据用户的输入确定播放设备。手机根据用户输入，向智能电视投屏。如图39B所示，手机根据播放端界面描述文件生成播放端UI数据，并按照播放端UI数据显示播放端UI。手机还向智能电视发送播放端界面描述文件。智能电视根据播放端界面描述文件生成播放端UI数据，并按照播放端UI数据显示播放端UI。

如图39A所示，手机向智能电视投屏之后，手机也显示播放端UI，手机和智能电视都显示播放端UI 1220。

这样，控制设备与播放设备同步播放播放端UI，可以实现镜像投屏，控制设备与播放设备协同工作。

在一些实施例中，控制设备100接收到用户在播放端UI上的操作或业务数据发生变化时，数据绑定13b调用MVVM框架11c更新播放端UI数据。由于播放端UI的控件与播放端UI数据中控件存在一一对应关系，播放端UI数据更新触发播放端UI更新。这样，控制设备100接收到用户操作或者业务数据发生变化，播放设备1000的播放端UI可以同步更新。

示例性的，请参考图40A，手机显示“视频”App的UI 1310。手机根据用户输入，将“视频”App的UI 1310投屏至智能电视。智能电视显示“视频”App的播放端UI 1320，播放端UI 1320包括“播放”按钮1321。

用户可以在智能电视上执行开启播放视频的操作(比如，用户通过智能电视的遥控器选中“播放”按钮1321，并点击“播放”按钮1321)。智能电视接收到用户对“播放”按钮1321的点击操作，响应于用户对“播放”按钮1321的点击操作，执行播放视频，并且显示更新的UI 1320。更新后的播放端UI 1320包括“暂停”按钮1322。

在一种实现方式中，如图40B所示，事件代理13f中定义了一个专用的事件传输类，该事件传输类用于跨设备传输。该事件传输类中存储多个事件，其中每个事件包括布局标识、控件标识、事件类型等信息。播放设备1000接收到用户在播放端UI上的操作，在事件传输类中产生该操作对应的事件，并通过事件传输通道传输给控制设备100。控制设备100接收到该事件后，根据布局标识和控件标识获取对应的控件，并根据作用于该控件上的该事件执行相应的业务逻辑。由于播放端UI的控件与播放端UI数据中控件存在一一对应关系，控制设备100还更新后台数据，后台数据改变触发播放端UI数据更新。控制设备100将更新后的播放端UI数据发送给播放设备1000，播放设备1000按照更新的播放端UI数据显示更新后的播放端UI。

这样，用户可以在播放设备上控制App，由控制设备执行相应的业务逻辑，并更新播放设备上的播放端UI。在一些示例中，如果控制设备和播放设备镜像显示播放端UI，还可以同步更新控制设备上的UI，方便用户使用。并且，对于用户在播放设备上的操作，由控制设备执行相关业务逻辑，控制设备统一控制播放设备，方便管理；且避免播放设备性能较低，不支持复杂的业务逻辑处理。

在一些实施例中，播放设备1000接收到用户在播放端UI上的第二操作。播放设备1000从控制设备100获取更新的播放端界面描述文件，并生成更新的播放端UI。

示例性的，如图40C，手机显示“视频”App的UI 1330。手机根据用户输入，将“视频”App的UI 1330投屏至智能电视。智能电视显示“视频”App的播放端UI 1340。智能电视接收到用户在播放端UI 1340上的第二操作(比如，用户通过遥控器将播放端UI 1340上的焦点从“电影”移至“综艺”)。响应于用户在播放端UI 1340上的第二操作，智能电视显示更新的播放端UI，即“视频”App的播放端UI 1350。

在一种实现方式中，如图40D所示，播放设备1000接收到用户在播放端UI上的第二操作，在事件传输类中产生该第二操作对应的事件，并通过事件传输通道传输给控制设备100。控制设备100接收到该事件后，根据布局标识和控件标识获取对应的控件，并根据作用于该控件上的该事件执行相应的业务逻辑。控制设备100确定将播放端UI更新为焦点为“综艺”的播放端UI，获取焦点为“综艺”的播放端UI对应的播放端界面描述文件二。控制设备100的OS中的虚拟控件构建13a通过调用UI，解析和执行播放端界面描述文件二中播放设备1000的设备类型对应的代码段，根据播放端界面描述文件二中播放设备1000的设备类型对应的代码段进行控件构建，按照该代码段中的布局编排生成控件、控件组等，形成播放端UI数据二。之后，数据绑定13b调用MVVM框架11c将播放端UI数据二中的对象与后台数据(比如，控件模型)进行数据绑定。进一步的，控制设备100将播放端界面描述文件二以及资源文件(包括播放端界面描述文件二中关联的数据资源)通过数据收发13d发送给播放设备1000。在一种实现方式中，控制设备100将播放端界面描述文件二进行编码，布局信息、资源值、数据、响应事件定义等数据编码后，经数据传输通道传输至播放设备1000；特定类型的数据资源(比如，数据量大于设定值的数据、图片、视频等)，经特定数据传输通道传输至播放设备1000。播放设备1000通过数据收发13d接收到播放端界面描述文件二以及数据资源资源文件，播放设备1000的OS中的虚拟控件构建13a通过调用自定义UI引擎11解析和执行播放端界面描述文件二中播放设备1000的设备类型对应的代码段，根据播放端界面描述文件二中播放设备1000的设备类型对应的代码段进行控件构建，按照该代码段中的布局编排生成控件、控件组等，形成播放端UI数据二(包括控件和控件的布局等信息)；并按照该播放端UI数据二进行显示，即显示更新的播放端UI。

这样，用户可以直接在播放设备上对播放端UI进行操作，控制设备执行该操作对应的业务逻辑，并向播放设备发送更新的播放端UI对应的播放端界面描述文件，播放设备根据更新的播放端界面描述文件生成更新的播放端UI。实现在播放设备上直接对播放端UI进行操作，成功切换播放端UI。

请参考图41A，其示出了本申请实施例提供的用户接口界面实现方法中控制设备的处理流程的一种示例。控制设备安装了App后，投屏框架、MVVM框架、后台数据等进行初始化。然后资源传输模块传输App相关的数据资源，并将数据资源绑定投屏服务。投屏框架从应用安装包中获取播放端界面描述文件，并发送给虚拟控件构建模块。虚拟控件构建模块根据播放端界面描述文件进行控件构建，形成播放端UI数据；并将播放端UI数据绑定投屏服务。之后，虚拟控件构建模块通知数据绑定模块进行播放端UI数据与后台数据的绑定，数据绑定模块调动MVVM框架将播放端UI数据与后台数据进行绑定。投屏服务还绑定事件代理。进一步的，播放端界面描述文件经编码后发送给播放设备。这样，播放设备接收到编码的播放端界面描述文件后，可以根据播放端界面描述文件生成播放端UI并显示。

投屏框架接收到播放设备发送的事件，将事件发送给MVVM框架；MVVM框架根据事件更新后台数据。当App的业务数据发生变化，后台数据变化引起MVVM框架更新播放端UI数据。控制设备向播放设备发送更新的播放端UI数据。这样，播放设备接收到更新的播放端UI数据后，可以按照更新的播放端UI数据显示更新的播放端UI。

请参考图41B，其示出了本申请实施例提供的用户接口界面实现方法中播放设备的处理流程的一种示例。播放设备通过传输通道接收到控制设备发送的编码的播放端界面描述文件。投屏框架调用自定义UI引擎对播放端界面描述文件进行解析执行，形成播放端UI数据，并按照播放端UI数据显示播放端UI。事件代理模块接收到用户在播放端UI上的操作，生成对应的事件，并向控制设备传输该事件，以使得控制设备处理该事件。

本申请实施例提供一种用户接口界面实现方法，控制设备运行App的过程中，如果满足预设条件，控制设备将预设信息推送至播放设备进行播放。

以手机作为控制设备，智能手表作为播放设备为例。示例性的，如图42A，用户在手机上打开“外卖”App进行订餐，下单支付。可选的，App切换至后台运行。满足预设条件(比如，手机确定外卖订单预计再过20分钟送达；再比如，用户在智能手表上进行查询操作)时，手机将预设信息推送至智能手表进行显示。比如，如图42A所示，智能手表显示播放端UI1410；播放端UI 1410上包括“外卖订单进展”控件1411，提示信息1412。

在一种实现方式中，开发者在开发阶段定义满足预设条件时向播放端推送信息的播放端界面描述文件(或播放端界面描述文件中一段代码)。在该播放端界面描述文件中定义了智能手表的播放端UI包括控件1411和提示信息1412。手机运行“外卖”App过程(包括“外卖”App切换至后台运行)中，手机确定满足预设条件，读取指定的代码段，根据指定的代码段生成播放端UI数据，并将该指定的代码段(或生成的播放端UI数据)发送给智能手表。智能手表根据指定的代码段(或生成的播放端UI数据)生成播放端UI 1410。

示例性的，如图42B，用户在手机上使用导航App进行导航。满足预设条件(比如，改变前进方向)时，手机根据指定的代码段生成播放端UI数据，并将该指定的代码段(或生成的播放端UI数据)发送给智能手表。智能手表根据指定的代码段(或生成的播放端UI数据)生成播放端UI 1420。

进一步的，智能手表接收用户作用于智能手表的操作，生成该操作对应的事件，并将事件发送给手机进行处理。手机进行业务逻辑处理，执行相应的动作；并更新播放端UI数据。手机还将更新后的播放端UI数据发送给智能手表，智能手表根据更新后的播放端UI数据更新播放端UI。

本申请实施例提供的用户接口界面实现方法，在满足预设条件时，控制设备自动将运行的App的部分信息推送至播放设备进行播放。不同类型的播放设备可以读取该设备类型对应的代码段，可以方便的实现设备差异化布局播放端UI。并且用户可以在播放设备上控制App，由控制设备进行业务逻辑处理；这样可以提高用户的使用体验，避免播放设备性能较低，不支持复杂的业务逻辑处理。

可以理解的是，上述电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

本申请实施例可以根据上述方法示例对上述电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图43所示，本申请实施例公开了一种电子设备1500，该电子设备可以为运行上述开发工具的电子设备，或上述实施例中运行App的电子设备，或上述实施例中运行应用小组件的电子设备；该电子设备可以为上述控制设备或播放设备。该电子设备具体可以包括：显示屏1501；输入设备1502(例如鼠标、键盘或触摸屏等)；一个或多个处理器1503；存储器1504；一个或多个应用程序(未示出)；以及一个或多个计算机程序1505，上述各器件可以通过一个或多个通信总线1506连接。其中，上述一个或多个计算机程序1505被存储在上述存储器1504中并被配置为被该一个或多个处理器1503执行，该一个或多个计算机程序1505包括指令，该指令可以用于执行上述实施例中的相关步骤。在一种示例中，该电子设备1500可以为图1中电子设备100或电子设备200。在一种示例中，该电子设备1500可以为图14中开发者设备或用户侧电子设备。在一种示例中，该电子设备1500可以为图23中电子设备100或电子设备200。在一种示例中，该电子设备1500可以为图33中控制设备100或电子设备200或播放设备1000。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序代码，当处理器执行该计算机程序代码时，电子设备执行上述实施例中的方法。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述实施例中的方法。

其中，本申请实施例提供的电子设备1500、计算机可读存储介质或者计算机程序产品均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以使用硬件的形式实现，也可以使用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (87)

1.一种用户接口界面实现方法，其特征在于，包括：

电子设备安装第一应用的应用安装包，所述应用安装包包括第一描述文件和第二描述文件；所述第一描述文件和所述第二描述文件用于对所述第一应用的第一用户接口界面UI进行界面描述和界面行为定义；所述第一描述文件采用第一界面描述语言，所述第二描述文件采用第二界面描述语言；所述第一界面描述语言与所述第二界面描述语言不同；

所述电子设备运行所述第一应用；其中，所述电子设备的第一UI引擎读取所述第一描述文件，并解析和执行所述第一描述文件，生成所述第一UI的第一部分；所述电子设备的第二UI引擎读取所述第二描述文件，并解析和执行所述第二描述文件，生成所述第一UI的第二部分；

所述电子设备显示所述第一UI。

2.根据权利要求1所述的方法，其特征在于，所述电子设备的第一UI引擎生成所述第一UI的第一部分包括：

所述电子设备的第一UI引擎根据所述第一描述文件生成所述第一UI中一个或多个第一控件；所述一个或多个第一控件具备第一UI编程能力。

3.根据权利要求2所述的方法，其特征在于，所述电子设备的第二UI引擎生成所述第一UI的第二部分包括：

所述电子设备的第二UI引擎根据所述第二描述文件对一个或多个所述第一控件应用第二UI编程能力。

4.根据权利要求2或3所述的方法，其特征在于，所述电子设备的第二UI引擎生成所述第一UI的第二部分包括：

所述电子设备的第二UI引擎根据所述第二描述文件生成所述第一UI中一个或多个第二控件；所述一个或多个第二控件具备第二UI编程能力。

5.根据权利要求3或4所述的方法，其特征在于，所述第二UI编程能力包括：视觉属性能力，布局能力，统一交互能力和动效能力中至少一种。

6.根据权利要求5所述的方法，其特征在于，所述布局能力包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

7.根据权利要求1-6任意一项所述的方法，其特征在于，所述方法还包括：

所述电子设备确定存在所述第二描述文件，所述第二UI引擎触发所述第一UI引擎读取所述第一描述文件，所述第二UI引擎读取所述第二描述文件。

8.根据权利要求1-7任意一项所述的方法，其特征在于，所述第一描述文件与所述第二描述文件在所述应用安装包中不同路径。

9.根据权利要求1-8任意一项所述的方法，其特征在于，所述方法还包括：

所述第二UI引擎对所述第二界面描述语言进行语法校验；

若所述语法校验通过，所述第二UI引擎解析和执行所述第二描述文件。

10.根据权利要求1-9任意一项所述的方法，其特征在于，所述方法还包括：

所述电子设备的第二UI引擎实现器件事件与所述第二描述文件中用户行为之间的映射；

响应于所述器件事件，执行所述第二描述文件中用户行为对应的控件动作。

11.根据权利要求1-10任意一项所述的方法，其特征在于，所述第二UI引擎包括所述第二描述文件中字段的语法语义规范集合。

12.一种用户接口界面实现方法，其特征在于，包括：

显示第一应用的开发界面；所述第一应用的开发界面包括第一描述文件和第二描述文件；所述第一描述文件和所述第二描述文件用于对所述第一应用的第一用户接口界面UI进行界面描述和界面行为定义；所述第一描述文件采用第一界面描述语言，所述第二描述文件采用第二界面描述语言；所述第一界面描述语言与所述第二界面描述语言不同；

响应于用户输入的第一操作，在所述第一描述文件中增加对所述第一UI的第一部分的描述；

响应于用户输入的第二操作，在所述第二描述文件中增加对所述第一UI的第二部分的描述；

根据所述第一描述文件和所述第二描述文件生成所述第一应用的应用安装包。

13.根据权利要求12所述的方法，其特征在于，所述在所述第一描述文件中增加对所述第一UI的第一部分的描述包括：

在所述第一描述文件中增加对所述第一UI中一个或多个第一控件的描述；

对所述一个或多个第一控件应用第一UI编程能力。

14.根据权利要求13所述的方法，其特征在于，所述在所述第二描述文件中增加对所述第一UI的第二部分的描述包括：

在所述第二描述文件中增加对一个或多个所述第一控件的描述；

对一个或多个所述第一控件应用第二UI编程能力。

15.根据权利要求13或14所述的方法，其特征在于，所述在所述第二描述文件中增加对所述第一UI的第二部分的描述包括：

在所述第二描述文件中增加对一个或多个第二控件的描述；

对所述一个或多个第二控件应用第二UI编程能力。

16.根据权利要求14或15所述的方法，其特征在于，所述第二UI编程能力包括：视觉属性能力，布局能力，统一交互能力和动效能力中至少一种。

17.根据权利要求16所述的方法，其特征在于，所述布局能力包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

18.根据权利要求12-17任意一项所述的方法，其特征在于，所述第一描述文件与所述第二描述文件在所述应用安装包中不同路径。

19.一种电子设备，其特征在于，包括：

一个或多个处理器；

显示屏；

存储器；

其中，所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如权利要求1-18中任意一项所述的方法。

20.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求12-18中任意一项所述的方法。

21.一种计算机可读存储介质，其特征在于，包括计算机指令，所述计算机指令用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义，其中，

所述计算机指令包括存储于第一描述文件中的第一指令，以及存储于第二描述文件中的第二指令；

所述第一描述文件采用第一界面描述语言，所述第二描述文件采用第二界面描述语言；所述第一界面描述语言与所述第二界面描述语言不同；

所述第一指令用于描述所述第一UI的第一部分，所述第二指令用于描述所述第一UI的第二部分。

22.根据权利要求21所述的计算机可读存储介质，其特征在于，所述第一指令具体用于：

描述所述第一UI中一个或多个第一控件，对所述一个或多个第一控件应用第一UI编程能力。

23.根据权利要求22所述的计算机可读存储介质，其特征在于，所述第二指令具体用于：

对所述一个或多个第一控件应用第二UI编程能力。

24.根据权利要求22或23所述的计算机可读存储介质，其特征在于，所述第二指令具体用于：

描述所述第一UI中一个或多个第二控件，对所述一个或多个第二控件应用第二UI编程能力。

25.根据权利要求23或24所述的计算机可读存储介质，其特征在于，所述第二UI编程能力包括：视觉属性能力，布局能力，统一交互能力和动效能力中至少一种。

26.根据权利要求25所述的计算机可读存储介质，其特征在于，所述布局能力包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

27.根据权利要求21-26任意一项所述的计算机可读存储介质，其特征在于，所述第一描述文件与所述第二描述文件在所述计算机可读存储介质中不同路径。

28.一种用户接口界面实现方法，其特征在于，包括：

第一电子设备和第二电子设备分别从服务器下载第一应用的应用安装包；所述应用安装包包括描述文件和资源文件；所述描述文件用于对所述第一应用的第一用户接口界面UI进行界面描述和界面行为定义；所述资源文件包括生成所述第一应用的UI使用的资源；

所述第一电子设备和所述第二电子设备分别安装所述应用安装包；

所述第一电子设备读取所述描述文件中与所述第一电子设备的设备类型对应的第一代码，按照所述第一代码的定义使用所述资源文件的资源生成所述第一电子设备的第一UI；

所述第二电子设备读取所述描述文件中与所述第二电子设备的设备类型对应的第二代码，按照所述第二代码的定义使用所述资源文件的资源生成所述第二电子设备的第一UI；

所述第一电子设备的设备类型与所述第二电子设备的设备类型不同。

29.根据权利要求28所述的方法，其特征在于，所述方法还包括：

所述第一电子设备按照所述描述文件中第三代码的定义生成所述第一电子设备的第一UI中第一控件，所述第一电子设备的第一UI中第一控件具备所述第一电子设备的操作***自定义的控件属性；所述第三代码是所述第一代码的部分或全部；

第三电子设备按照所述描述文件中第三代码的定义生成所述第三电子设备的第一UI中第一控件，所述第三电子设备的第一UI中第一控件具备通用操作***的控件属性。

30.一种用户接口界面实现方法，其特征在于，包括：

第一电子设备下载第一应用的应用安装包；所述应用安装包包括描述文件和资源文件；所述描述文件用于对所述第一应用的第一用户接口界面UI进行界面描述和界面行为定义；所述资源文件包括生成所述第一应用的UI使用的资源；

所述第一电子设备安装所述应用安装包；

所述第一电子设备读取所述描述文件中与所述第一电子设备的设备类型对应的第一代码，按照所述第一代码的定义使用所述资源文件的资源生成所述第一电子设备的第一UI。

31.根据权利要求30所述的方法，其特征在于，所述方法还包括：

所述第一电子设备按照所述描述文件中第三代码的定义生成所述第一电子设备的第一UI中第一控件，所述第一电子设备的第一UI中第一控件具备所述第一电子设备的操作***自定义的控件属性；所述第三代码是所述第一代码的部分或全部。

32.根据权利要求29或31所述的方法，其特征在于，所述第一电子设备的操作***包括自定义UI编程能力，所述自定义UI编程能力用于提供所述第一电子设备的操作***自定义的控件属性。

33.根据权利要求32所述的方法，其特征在于，所述自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

34.根据权利要求33所述的方法，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

35.根据权利要求28-34任意一项所述的方法，其特征在于，所述第一电子设备的第一UI包括第二控件，所述第二控件具备通用操作***的控件属性。

36.根据权利要求28-35任意一项所述的方法，其特征在于，所述第一电子设备的第一UI包括第三控件，所述第三控件具备所述第一应用中自定义的控件属性。

37.根据权利要求28-36任意一项所述的方法，其特征在于，所述描述文件包括***码，所述***码用于定义所述第一电子设备的第一UI中第四控件的控件属性与所述第一电子设备的操作***中第一数据的对应关系，

所述方法还包括：

所述第一电子设备接收用户在所述第四控件上的第一输入；

根据所述第一输入修改所述第一数据的值。

38.根据权利要求37所述的方法，其特征在于，所述方法还包括：

所述第一电子设备的第一UI中第四控件的控件属性随着所述第一电子设备的操作***中第一数据的改变而改变。

39.一种用户接口界面实现方法，其特征在于，包括：

显示第一应用的开发界面；所述第一应用的开发界面包括描述文件；所述描述文件用于对所述第一应用的第一用户接口界面UI进行界面描述和界面行为定义；

响应于用户输入的第一操作，在所述描述文件中增加与第一电子设备的设备类型对应的第一代码；

响应于用户输入的第二操作，在所述描述文件中增加与第二电子设备的设备类型对应的第二代码；所述第一电子设备的设备类型与所述第二电子设备的设备类型不同；

根据所述描述文件生成所述第一应用的应用安装包。

40.根据权利要求39所述的方法，其特征在于，所述第一应用的应用安装包还包括资源文件，所述资源文件包括生成所述第一应用的UI使用的资源。

41.根据权利要求39或40所述的方法，其特征在于，

所述描述文件中包括定义第一控件具备所述第一电子设备的操作***自定义的控件属性的第三代码，以及定义第二控件具备通用操作***的控件属性的***码。

42.根据权利要求41所述的方法，其特征在于，所述第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

43.根据权利要求42所述的方法，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

44.一种电子设备，其特征在于，包括：

一个或多个处理器；

显示屏；

存储器；

其中，所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如权利要求30-43中任意一项所述的方法。

45.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求39-43中任意一项所述的方法。

46.一种计算机可读存储介质，其特征在于，包括计算机指令，所述计算机指令用于对第一应用的第一用户接口界面UI进行界面描述和界面行为定义；其中，所述计算机指令包括与第一电子设备的设备类型对应的第一代码以及与第二电子设备的设备类型对应的第二代码；所述第一电子设备的设备类型与所述第二电子设备的设备类型不同。

47.根据权利要求46所述的计算机可读存储介质，其特征在于，所述计算机指令还包括生成所述第一应用的UI使用的资源。

48.根据权利要求46或47所述的计算机可读存储介质，其特征在于，所述计算机指令还包括定义第一控件具备所述第一电子设备的操作***自定义的控件属性的第三代码，以及定义第二控件具备通用操作***的控件属性的***码。

49.一种用户接口界面实现方法，其特征在于，包括：

电子设备的第一应用进程读取组件界面描述文件，所述组件界面描述文件用于对所述第一应用的应用小组件的第一用户接口界面UI进行界面描述和界面行为定义；

所述第一应用进程根据所述组件界面描述文件生成第一小组件UI数据，将所述第一小组件UI数据中的控件与所述电子设备操作***中的后台数据进行绑定；

所述第一应用进程向应用小组件进程发送第一数据；

所述应用小组件进程接收所述第一数据，根据所述第一数据获取所述第一小组件UI数据；按照所述第一小组件UI数据显示所述应用小组件的第一UI。

50.根据权利要求49所述的方法，其特征在于，所述第一数据为所述组件界面描述文件，所述应用小组件进程根据所述第一数据获取所述第一小组件UI数据包括：

所述应用小组件进程根据所述组件界面描述文件生成所述第一小组件UI数据。

51.根据权利要求49所述的方法，其特征在于，所述第一数据为第一小组件UI数据。

52.根据权利要求50或51所述的方法，其特征在于，所述方法还包括：

所述第一应用进程按照所述组件界面描述文件中第一代码的定义生成所述第一小组件UI数据中第一控件，所述第一控件具备所述电子设备的操作***原生的控件属性。

53.根据权利要求52所述的方法，其特征在于，所述操作***原生的控件包括：

输入框，复选框，滑动选择器，滚动视图，单选按钮，评分条，搜索框，拖动条，或开关。

54.根据权利要求49-53任意一项所述的方法，其特征在于，所述方法还包括：

所述第一应用进程按照所述组件界面描述文件中第二代码的定义生成所述第一小组件UI数据中第二控件，所述第二控件具备所述电子设备的操作***中自定义的控件属性。

55.根据权利要求54所述的方法，其特征在于，所述自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

56.根据权利要求55所述的方法，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

57.根据权利要求49-56任意一项所述的方法，其特征在于，所述组件界面描述文件包括第三代码，所述第三代码用于定义所述应用小组件的第一UI中第三控件的控件属性与所述电子设备的操作***中第一数据的对应关系，

所述方法还包括：

所述电子设备接收用户在所述第三控件上的第一输入；

根据所述第一输入修改所述第一数据的值。

58.根据权利要求57所述的方法，其特征在于，所述方法还包括：

所述应用小组件的第一UI中第三控件的控件属性随着所述电子设备的操作***中第一数据的改变而改变。

59.根据权利要求49-58任意一项所述的方法，其特征在于，所述方法还包括：

所述电子设备从服务器下载所述第一应用的应用安装包；所述应用安装包包括所述组件界面描述文件；

所述电子设备使用所述应用安装包安装所述第一应用。

60.一种用户接口界面实现方法，其特征在于，包括：

显示第一应用的开发界面；所述第一应用的开发界面包括组件界面描述文件；所述组件界面描述文件用于对所述第一应用的应用小组件的第一用户接口界面UI进行界面描述和界面行为定义；

响应于用户输入的第一操作，在所述组件界面描述文件中增加定义所述第一小组件UI中第一控件的第一代码；所述第一控件具备操作***原生的控件属性；其中，所述操作***原生的控件包括：输入框，复选框，滑动选择器，滚动视图，单选按钮，评分条，搜索框，拖动条，或开关；

根据所述组件界面描述文件生成所述第一应用的应用安装包。

61.根据权利要求60所述的方法，其特征在于，所述方法还包括：

响应于用户输入的第二操作，在所述组件界面描述文件中增加定义所述第一小组件UI中第二控件的第二代码，所述第二控件具备所述操作***中自定义的控件属性；所述自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

62.根据权利要求61所述的方法，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

63.一种电子设备，其特征在于，包括：

一个或多个处理器；

显示屏；

存储器；

其中，所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如权利要求49-62中任意一项所述的方法。

64.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求60-62中任意一项所述的方法。

65.一种计算机可读存储介质，其特征在于，包括计算机指令，所述计算机指令用于对第一应用的应用小组件的第一用户接口界面UI进行界面描述和界面行为定义；

其中，所述计算机指令包括生成所述第一小组件UI中第一控件的第一代码，所述第一控件具备操作***原生的控件属性；

所述操作***原生的控件包括：输入框，复选框，滑动选择器，滚动视图，单选按钮，评分条，搜索框，拖动条，或开关。

66.根据权利要求65所述的计算机可读存储介质，其特征在于，

所述计算机指令还包括生成所述第一小组件UI中第二控件的第二代码，所述第二控件具备所述操作***中自定义的控件属性；

所述自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

67.根据权利要求66所述的计算机可读存储介质，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

68.一种用户接口界面实现方法，其特征在于，包括：

第一电子设备读取第一应用的第一播放端界面描述文件，所述第一播放端界面描述文件用于对在第二电子设备上播放所述第一应用的第一播放端用户接口界面UI进行界面描述和界面行为定义；

所述第一电子设备根据所述第一播放端界面描述文件生成第一播放端UI数据，将所述第一播放端UI数据中的控件与所述第一电子设备操作***中的后台数据进行绑定；

所述第一电子设备向所述第二电子设备发送第一数据；

所述第二电子设备接收所述第一数据，根据所述第一数据获取所述第一播放端UI数据，按照所述第一播放端UI数据显示所述第一播放端UI。

69.根据权利要求68所述的方法，其特征在于，所述第一数据为所述第一播放端界面描述文件，所述第二电子设备根据所述第一数据获取所述第一播放端UI数据包括：

所述第二电子设备根据所述第一播放端界面描述文件生成所述第一播放端UI数据。

70.根据权利要求68所述的方法，其特征在于，所述第一数据为所述第一播放端UI数据。

71.根据权利要求68-70任意一项所述的方法，其特征在于，所述方法还包括：

所述第二电子设备接收用户在所述第一播放端UI上的第一操作；

响应于用户在所述第一播放端UI上的第一操作，所述第二电子设备向所述第一电子设备发送第一指令；

所述第一电子设备接收到所述第一指令，读取第二播放端界面描述文件；所述第二播放端界面描述文件用于对在第二电子设备上播放所述第一应用的第二播放端UI进行界面描述和界面行为定义；

所述第一电子设备根据所述第二播放端界面描述文件生成第二播放端UI数据，将所述第二播放端UI数据中的控件与所述第一电子设备操作***中的后台数据进行绑定；

所述第一电子设备向所述第二电子设备发送所述第二播放端界面描述文件；

所述第二电子设备接收所述第二播放端界面描述文件，根据所述第二播放端界面描述文件生成第二播放端UI数据，按照所述第二播放端UI数据显示所述第二播放端UI。

72.根据权利要求68-70任意一项所述的方法，其特征在于，所述方法还包括：

所述第二电子设备接收用户在所述第一播放端UI上的第一操作；

响应于用户在所述第一播放端UI上的第一操作，所述第二电子设备向所述第一电子设备发送第一指令；

所述第一电子设备接收到所述第一指令，读取第二播放端界面描述文件；所述第二播放端界面描述文件用于对在第二电子设备上播放所述第一应用的第二播放端UI进行界面描述和界面行为定义；

所述第一电子设备根据所述第二播放端界面描述文件生成第二播放端UI数据，将所述第二播放端UI数据中的控件与所述第一电子设备操作***中的后台数据进行绑定；

所述第一电子设备向所述第二电子设备发送所述第二播放端UI数据；

所述第二电子设备接收所述第二播放端UI数据，按照所述第二播放端UI数据显示所述第二播放端UI。

73.根据权利要求68-72任意一项所述的方法，其特征在于，所述方法还包括：

所述第一电子设备从服务器下载第一应用的应用安装包；所述应用安装包包括第一播放端界面描述文件和资源文件；所述资源文件包括生成所述第一应用的播放端UI使用的资源；

所述第一电子设备使用所述应用安装包安装所述第一应用。

74.根据权利要求68-73任意一项所述的方法，其特征在于，所述方法还包括：

所述第一电子设备读取所述第一播放端界面描述文件中与第三电子设备的设备类型对应的第一代码，按照所述第一代码的定义使用所述资源文件的资源生成第三播放端UI数据；

所述第一电子设备读取所述第一播放端界面描述文件中与第四电子设备的设备类型对应的第二代码，按照所述第二代码的定义使用所述资源文件的资源生成第四播放端UI数据；所述第四电子设备的设备类型与所述第三电子设备的设备类型不同；

所述第一电子设备分别向所述第三电子设备和所述第四电子设备发送所述第一播放端界面描述文件和所述资源文件；

所述第三电子设备根据所述第一播放端界面描述文件中与第三电子设备的设备类型对应的第一代码的定义使用所述资源文件的资源生成第三播放端UI数据；按照所述第三播放端UI数据显示所述第一播放端UI；

所述第四电子设备根据所述第一播放端界面描述文件中与第四电子设备的设备类型对应的第二代码的定义使用所述资源文件的资源生成第四播放端UI数据；按照所述第四播放端UI数据显示所述第一播放端UI。

75.根据权利要求68-73任意一项所述的方法，其特征在于，所述方法还包括：

所述第一电子设备读取所述第一播放端界面描述文件中与第三电子设备的设备类型对应的第一代码，按照所述第一代码的定义使用所述资源文件的资源生成第三播放端UI数据；

所述第一电子设备读取所述第一播放端界面描述文件中与第四电子设备的设备类型对应的第二代码，按照所述第二代码的定义使用所述资源文件的资源生成第四播放端UI数据；所述第四电子设备的设备类型与所述第三电子设备的设备类型不同；

所述第一电子设备向所述第三电子设备发送所述第三播放端UI数据；

所述第三电子设备按照所述第三播放端UI数据显示所述第一播放端UI；

所述第一电子设备向所述第四电子设备发送所述第四播放端UI数据；

所述第四电子设备按照所述第四播放端UI数据显示所述第一播放端UI。

76.根据权利要求68-75任意一项所述的方法，其特征在于，所述方法还包括：

所述第一电子设备按照所述第一播放端界面描述文件中第三代码的定义生成所述第一播放端UI中第一控件，所述第一控件具备所述第一电子设备的操作***自定义的控件属性；

所述第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

77.根据权利要求76所述的方法，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

78.一种用户接口界面实现方法，其特征在于，包括：

显示第一应用的开发界面；所述第一应用的开发界面包括播放端界面描述文件；所述播放端界面描述文件用于对在播放端播放所述第一应用的播放端用户接口界面UI进行界面描述和界面行为定义；

响应于用户的第一输入，在所述播放端界面描述文件中增加与第一电子设备的设备类型对应的第一代码；

响应于用户的第二输入，在所述播放端界面描述文件中增加与第二电子设备的设备类型对应的第二代码；所述第一电子设备的设备类型与所述第二电子设备的设备类型不同；

根据所述播放端界面描述文件生成所述第一应用的应用安装包。

79.根据权利要求78所述的方法，其特征在于，所述第一应用的应用安装包还包括资源文件，所述资源文件包括生成所述第一应用的播放端UI使用的资源。

80.根据权利要求78或79所述的方法，其特征在于，

所述播放端界面描述文件中包括定义所述第一播放端UI中第一控件具备所述第一电子设备的操作***自定义的控件属性的第三代码；

所述第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

81.根据权利要求80所述的方法，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

82.一种电子设备，其特征在于，包括：

一个或多个处理器；

显示屏；

存储器；

其中，所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述电子设备执行时，使得所述电子设备执行如权利要求78-81中任意一项所述的方法。

83.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求78-81中任意一项所述的方法。

84.一种计算机可读存储介质，其特征在于，包括计算机指令，所述计算机指令用于对第一应用的第一播放端用户接口界面UI进行界面描述和界面行为定义；其中，所述计算机指令包括与第一电子设备的设备类型对应的第一代码以及与第二电子设备的设备类型对应的第二代码；所述第一电子设备的设备类型与所述第二电子设备的设备类型不同。

85.根据权利要求84所述的计算机可读存储介质，其特征在于，所述计算机指令还包括生成所述第一应用的播放端UI使用的资源。

86.根据权利要求84或85所述的计算机可读存储介质，其特征在于，所述计算机指令还包括定义所述第一播放端UI中第一控件具备所述第一电子设备的操作***自定义的控件属性的第三代码；

所述第一电子设备的操作***自定义的控件属性包括：视觉属性，布局属性，交互属性，动效属性和软硬件依赖属性中至少一种。

87.根据权利要求86所述的计算机可读存储介质，其特征在于，所述布局属性包括：拉伸，隐藏，折行，均分，占比和延伸中至少一种。

Images