本发明涉及数据处理领域，特别是涉及一种创建界面元素的方法、装置、存储介质及移动终端。
背景技术
原生(即native)开发是开发人员最熟悉的应用软件(application，简称为app)开发模式了。原生开发可以访问设备中的所有功能，运行速度更快，性能更高，而且可以启用优秀的离线处理和存储能力等，提供最佳的用户体验，最优质的用户界面，最华丽的交互。原生开发人员众多，开发环境成熟，有许多的开源库提供开发人员调用，可以方便实现各种设计效果。但原生每开发一个界面(即activity)都需要预先进行注册，否则使用该activity的时候会引起app的崩溃。
因此，在对app中activity的界面元素(即view)进行更改时，现有技术采用了两种方法，一种是app在原生开发基础之上再接入reactnative框架(一种开发框架)做业务的更新迭代，另一种是用html5开发的app某些界面实现局部动态化。其中，reactnative是可以实现界面的新增和内容的更新，html5只能实现其界面内容的更新。
虽然现有技术都能够实现界面元素的更改，但无论采用上述哪种方法，都只是在原生语言的app中进行的更改，都需要对更改的界面进行注册，等到发布app的新版本时呈现给用户，在不发布新版本app的情况下无法对app界面中的界面元素进行更改，用户体验较差。
技术实现要素：
本发明实施例提供一种创建界面元素的方法、装置、存储介质及移动终端，用以解决现有技术的如下问题：在不发布新版本app的情况下无法对app界面中的界面元素进行更改，用户体验较差。
为解决上述技术问题，一方面，本发明实施例提供一种创建界面元素的方法，包括：预定应用接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；预定应用通过将配置文件对应的原生界面元素进行封装，生成预定解析器；预定应用的原生语言组件通过预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数，并基于反射构建机制按照功能函数和配置参数创建界面元素。
可选的，基于反射构建机制按照功能函数和配置参数创建界面元素，包括：原生语言组件获取配置参数中的界面元素名称，按照反射构建机制构建初始界面元素；原生语言组件将初始界面元素的界面元素id赋值为配置参数中的预设唯一id；原生语言组件依次按照配置参数中的参数为界面元素id赋值后的初始界面元素设置界面元素参数，以创建界面元素。
可选的，原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数之后，还包括：原生语言组件获取配置参数中的界面元素的预设唯一id，并根据预设唯一id确定界面元素的系统id；原生语言组件检测系统id是否存在已创建的界面元素；在系统id不存在已创建的界面元素的情况下，原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素。
可选的，原生语言组件检测系统id是否存在已创建的界面元素之后，还包括：在系统id存在已创建的界面元素的情况下，按照配置参数修改已创建的界面元素对应的界面元素参数，以更新已创建的界面元素。
可选的，基于反射构建机制按照功能函数和配置参数创建界面元素之后，还包括：原生语言组件将创建好的界面元素添加到界面元素对应的父节点界面元素中，以在预定应用的预定界面中呈现界面元素。
另一方面，本发明实施例还提供一种创建界面元素的装置，包括：接收模块，用于接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；解析器生成模块，用于通过预定应用将配置文件对应的原生界面元素进行封装，生成预定解析器；解析模块，用于通过预定应用的原生语言组件中的预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；处理模块，用于通过预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；调用模块，用于通过原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数；创建模块，用于通过原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素。
可选的，创建模块包括：构建单元，用于通过原生语言组件获取配置参数中的界面元素名称，按照反射构建机制构建初始界面元素；第一设置单元，用于通过原生语言组件将初始界面元素的界面元素id赋值为配置参数中的预设唯一id；第二设置单元，用于通过原生语言组件依次按照配置参数中的参数为界面元素id赋值后的初始界面元素设置界面元素参数，以创建界面元素。
可选的，还包括：确定模块，用于通过原生语言组件获取配置参数中的界面元素的预设唯一id，并根据预设唯一id确定界面元素的系统id；检测模块，用于通过原生语言组件检测系统id是否存在已创建的界面元素；创建模块，还用于在系统id不存在已创建的界面元素的情况下，通过原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素。
可选的，创建模块，还用于在系统id存在已创建的界面元素的情况下，按照配置参数修改已创建的界面元素对应的界面元素参数，以更新已创建的界面元素。
可选的，还包括：添加模块，用于通过原生语言组件将创建好的界面元素添加到界面元素对应的父节点界面元素中，以在预定应用的预定界面中呈现界面元素。
另一方面，本发明实施例还提供一种存储介质，存储有计算机程序，计算机程序被处理器执行时实现上述创建界面元素的方法的步骤。
另一方面，本发明实施例还提供一种移动终端，至少包括存储器、处理器，存储器上存储有计算机程序，处理器在执行存储器上的计算机程序时实现上述创建界面元素的方法的步骤。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广，解决了现有技术的如下问题：在不发布新版本app的情况下无法对app界面中的界面元素进行更改，用户体验较差。
附图说明
图1是本发明第一实施例中创建界面元素的方法的流程图；
图2是本发明第二实施例中创建界面元素的方法的流程图；
图3是本发明第三实施例中创建界面元素的方法的流程图；
图4是本发明第四实施例中创建界面元素的方法的流程图；
图5是本发明第五实施例中创建界面元素的装置的结构示意图；
图6是本发明第六实施例中创建界面元素的装置的结构示意图；
图7是本发明第七实施例中创建界面元素的装置的结构示意图；
图8是本发明第八实施例中创建界面元素的装置的结构示意图；
图9是本发明实施例中du框架的native侧与js侧进行交互的示意图；
图10是本发明实施例中预定解析器、原生界面元素及xml文件的关系示意图。
具体实施方式
为了解决现有技术的如下问题：在不发布新版本app的情况下无法对app界面中的界面元素进行更改，用户体验较差；本发明提供了一种创建界面元素的方法、装置、存储介质及移动终端，以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。
本发明第一实施例提供了一种创建界面元素的方法，该方法的流程如图1所示，包括步骤s101至s105：
s101，预定应用接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要由服务器动态下发的，而使得预定应用能够实现动态化更新的动态化更新框架接收该动态下发的业务数据包，因此，业务数据包包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如：javascript。
当预定应用接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
s102，预定应用通过将配置文件对应的原生界面元素进行封装，生成预定解析器；
预定应用通过将配置文件对应的原生界面元素进行封装，以生成预定解析器，其中，该预定解析器与动态化更新框架适配，使得该预定解析器可以对从服务器动态获取的配置文件进行解析；
其中，该原生界面元素是该预定应用通过版本升级生成的。
s103，预定应用的原生语言组件通过预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中。
在接收到业务数据包之后，预定应用就可以通过预定解析器对该业务数据包中的配置文件进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
s104，预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件。
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的转换后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该业务逻辑数据。
s105，原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数，并基于反射构建机制按照功能函数和配置参数创建界面元素。
当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该转换后的业务逻辑，进而可以根据该逻辑调用对应的功能函数来实现创建界面元素的功能，具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第二实施例提供了一种创建界面元素的方法，该方法的流程如图2所示，包括步骤s201至s208：
s201，预定应用接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要由服务器动态下发的，而预定动态化更新框架即可接收该动态下发的业务数据包，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当预定应用接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
s202，预定应用通过将配置文件对应的原生界面元素进行封装，生成预定解析器；
预定应用通过将配置文件对应的原生界面元素进行封装，以生成预定解析器，其中，该预定解析器与动态化更新框架适配，使得该预定解析器可以对从服务器动态获取的配置文件进行解析；
其中，该原生界面元素是该预定应用通过版本升级生成的。
s203，预定应用的原生语言组件通过预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；
在接收到业务数据包之后，预定应用就可以通过预定解析器对该业务数据包中的配置文件进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
s204，预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的转换后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该业务逻辑数据。
s205，原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数；
s206，原生语言组件获取配置参数中的界面元素名称，按照反射构建机制构建初始界面元素；
该初始界面元素相当于只根据一个名字构建一个界面元素，但界面元素具体是什么样的还并未知晓。
s207，原生语言组件将初始界面元素的界面元素id赋值为配置参数中的预设唯一id；
当为初始界面元素赋值预设唯一id后，该初始界面元素就具有了一个标识号，为后续创建好的界面元素提供查找基础。
s208，原生语言组件依次按照配置参数中的参数为界面元素id赋值后的初始界面元素设置界面元素参数，以创建界面元素。
上述s206至s208即为基于反射构建机制按照功能函数和配置参数创建界面元素的过程。
上述过程中，当业务逻辑数据进行逻辑转换后，原生语言程序原生语言组件则可以识别该业务逻辑，进而可以根据该逻辑调用对应的功能函数来实现创建界面元素的功能，具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第三实施例提供了一种创建界面元素的方法，该方法的流程如图3所示，包括步骤s301至s309：
s301，预定应用接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要由服务器动态下发的，而预定动态化更新框架即可接收该动态下发的业务数据包，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当预定应用接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
s302，预定应用通过将配置文件对应的原生界面元素进行封装，生成预定解析器；
预定应用通过将配置文件对应的原生界面元素进行封装，以生成预定解析器，其中，该预定解析器与动态化更新框架适配，使得该预定解析器可以对从服务器动态获取的配置文件进行解析；
s303，预定应用的原生语言组件通过预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；
在接收到业务数据包之后，预定应用就可以通过预定解析器对该业务数据包中的配置文件进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
s304，预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的转换后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该业务逻辑数据。
s305，原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数。
s306，原生语言组件获取配置参数中的界面元素的预设唯一id，并根据预设唯一id确定界面元素的系统id；
s307，原生语言组件检测系统id是否存在已创建的界面元素。如果不存在，则执行s307，否则，执行s308。该过程即确定预定应用中是否存在该系统id对应的已经创建的界面元素。通过系统id检测是否存在已创建的界面元素的过程能够更加快速的执行系统流程，操作过程较为快速；
s308，在系统id不存在已创建的界面元素的情况下，原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素；
s309，在系统id存在已创建的界面元素的情况下，按照配置参数修改已创建的界面元素对应的界面元素参数，以更新已创建的界面元素。
上述过程实现时，当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该业务逻辑，进而可以根据该逻辑调用对应的功能函数来实现创建界面元素的功能，具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第四实施例提供了一种创建界面元素的方法，该方法的流程如图4所示，包括步骤s401至s406：
s401，预定应用接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要由服务器动态下发的，而预定动态化更新框架即可接收该动态下发的业务数据包，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当预定应用接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
s402，预定应用通过将配置文件对应的原生界面元素进行封装，生成预定解析器；
预定应用通过将配置文件对应的原生界面元素进行封装，以生成预定解析器，其中，该预定解析器与动态化更新框架适配，使得该预定解析器可以对从服务器动态获取的配置文件进行解析；
s403，预定应用的原生语言组件通过预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；
在接收到业务数据包之后，预定应用就可以通过预定解析器对该业务数据包中的配置文件进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
s404，预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的转换后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该业务逻辑数据。
s405，原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数，并基于反射构建机制按照功能函数和配置参数创建界面元素；
当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该业务逻辑，进而可以根据该逻辑调用对应的功能函数来实现创建界面元素的功能，具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
s406，原生语言组件将创建好的界面元素添加到界面元素对应的父节点界面元素中，以在预定应用的预定界面中呈现界面元素。
至此，界面元素创建完成，可以呈现在界面上并且可以正常使用。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第五实施例提供了一种创建界面元素的装置，该装置的结构示意如图5所示，包括：
接收模块10，用于接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；解析器生成模块101，用于通过预定应用将配置文件对应的原生界面元素进行封装，生成预定解析器；解析模块20，与接收模块10耦合，用于通过预定应用的原生语言组件中的预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；处理模块30，与解析模块20耦合，用于通过预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；调用模块40，与处理模块30耦合，用于通过原生语言组件按照转换之后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数；创建模块50，与调用模块40耦合，用于通过原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素。
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要动态下发的，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当接收模块10接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
而原生语言组件中的预定解析器，是由预定应用将原生界面元素封装至与动态化更新框架适配而生成的。在接收到业务数据包之后，解析模块20就可以通过该解析器对数据进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，处理模块30会通过第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的转换之后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该转换之后的业务逻辑数据。
当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该转换后的业务逻辑，进而调用模块40可以根据该逻辑调用对应的功能函数，使得创建模块50来实现创建界面元素的功能。具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第六实施例提供了一种创建界面元素的装置，该装置的结构示意如图6所示，包括：
接收模块10，用于接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；解析器生成模块101，用于通过预定应用将配置文件对应的原生界面元素进行封装，生成预定解析器；解析模块20，与接收模块10耦合，用于通过预定应用的原生语言组件中的预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；处理模块30，与解析模块20耦合，用于通过预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；调用模块40，与处理模块30耦合，用于通过原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数；创建模块50，与调用模块40耦合，用于通过原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素；其中，创建模块50包括：构建单元501，用于通过原生语言组件获取配置参数中的界面元素名称，按照反射构建机制构建初始界面元素；第一设置单元502，与构建单元501耦合，用于通过原生语言组件将初始界面元素的界面元素id赋值为配置参数中的预设唯一id；第二设置单元503，与第一设置单元502耦合，用于通过原生语言组件依次按照配置参数中的参数为界面元素id赋值后的初始界面元素设置界面元素参数，以创建界面元素。
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要动态下发的，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当接收模块10接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
而原生语言组件中的预定解析器，是由预定应用将原生界面元素封装至与动态化更新框架适配而生成的。在接收到业务数据包之后，解析模块20就可以通过该解析器对数据进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，处理模块30会通过第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的转换之后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该转换之后的业务逻辑数据。
当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该转换后的业务逻辑，进而调用模块40可以根据该逻辑调用对应的功能函数，使得创建模块50来实现创建界面元素的功能。具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第七实施例提供了一种创建界面元素的装置，该装置的结构示意如图7所示，包括：
接收模块10，用于接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；解析器生成模块101，用于通过预定应用将配置文件对应的原生界面元素进行封装，生成预定解析器；解析模块20，与接收模块10耦合，用于通过预定应用的原生语言组件中的预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；处理模块30，与解析模块20耦合，用于通过预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及其业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；调用模块40，与处理模块30耦合，用于通过原生语言组件按照业务逻辑数据对应的流程依次通过功能函数索引调用功能函数；确定模块60，与调用模块40耦合，用于通过原生语言组件获取配置参数中的界面元素的预设唯一id，并根据预设唯一id确定界面元素的系统id；检测模块70，与确定模块60耦合，用于通过原生语言组件检测系统id是否存在已创建的界面元素；创建模块50，与检测模块70耦合，用于在系统id不存在已创建的界面元素的情况下，通过原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素；还用于在系统id存在已创建的界面元素的情况下，按照配置参数修改已创建的界面元素对应的界面元素参数，以更新已创建的界面元素。
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要动态下发的，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当接收模块10接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
而原生语言组件中的预定解析器，是由预定应用将原生界面元素封装至与动态化更新框架适配而生成的。在接收到业务数据包之后，解析模块20就可以通过该解析器对数据进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，处理模块30会通过第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，以便能够将转换之后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该业务逻辑数据。
当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该转换之后的业务逻辑，进而调用模块40可以根据该逻辑调用对应的功能函数，使得创建模块50来实现创建界面元素的功能。具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第八实施例提供了一种创建界面元素的装置，该装置的结构示意如图8所示，包括：
接收模块10，用于接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；解析器生成模块101，用于通过预定应用将配置文件对应的原生界面元素进行封装，生成预定解析器；解析模块20，与接收模块10耦合，用于通过预定应用的原生语言组件中的预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；处理模块30，与解析模块20耦合，用于通过预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及其业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；调用模块40，与处理模块30耦合，用于通过原生语言组件按照业务逻辑数据对应的流程依次通过功能函数索引调用功能函数；创建模块50，与调用模块40耦合，用于通过原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素；添加模块80，与创建模块50耦合，用于通过原生语言组件将创建好的界面元素添加到界面元素对应的父节点界面元素中，以在预定应用的预定界面中呈现界面元素。
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要动态下发的，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当接收模块10接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
而原生语言组件中的预定解析器，是由预定应用将原生界面元素封装至与动态化更新框架适配而生成的。在接收到业务数据包之后，解析模块20就可以通过该解析器对数据进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，处理模块30会通过第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的转换之后的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该转换之后的业务逻辑数据。
当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该业务逻辑，进而调用模块40可以根据该逻辑调用对应的功能函数，使得创建模块50来实现创建界面元素的功能。具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
在本发明实施例中，预定应用通过该经封装原生界面元素而生成的预定解析器对从服务器动态获取的业务逻辑数据进行解析，并结合从服务器动态获取的配置文件，实现了通过反射构建机制创建界面元素，同时，也实现了结合预定应用的原生界面元素完成预定应用的界面更新，并使得用户能够具有原生系统的体验效果，而且，使得预定应用在动态化更新时界面元素的选择种类更多一些。。其中，第一预定语言是与原生语言不同的语言，其可以动态下发，因此预定应用能够随时接收到包含有业务逻辑数据及配置文件的业务数据包，进而可以随时结合该经封装原生界面元素而生成的预定解析器，实现使用业务数据包中的业务逻辑数据和配置参数来通过反射构建机制创建界面元素。
此外，本实施例能够随时接收业务数据包，并结合该经封装原生界面元素而生成的预定解析器实现动态的创建界面元素，不需要等到发布新版本的app就能够更改界面元素，用户体验较好，也较适合商业推广。
本发明第九实施例提供了一种存储介质，存储有计算机程序，计算机程序被处理器执行时实现如下步骤，本领域技术人员可以根据如下步骤编写对应的程序代码。
s11，预定应用接收来自服务器的业务数据包，其中，业务数据包包括：配置文件及通过第一预定语言设置的业务逻辑数据，而且，第一预定语言与预定应用的原生语言不同；
s13，预定应用的原生语言组件通过预定解析器对配置文件进行解析，并将解析得到的配置参数存储在预设存储空间中；
s14，预定应用的第一预定语言组件将业务逻辑数据按照原生语言进行逻辑转换，并将转换后的业务逻辑数据及转换后的业务逻辑数据对应的功能函数索引通过预定传输通道发送至原生语言组件；
s15，原生语言组件按照转换后的业务逻辑数据对应的流程依次通过功能函数索引调用功能函数；
s16，基于反射构建机制按照功能函数和配置参数创建界面元素。
本发明实施例为了能够自动让预定应用中界面的界面元素更改，因此在服务器侧会设置一个业务数据包，并将该业务数据包发送至预定应用。具体实现时，该业务数据包是需要由服务器动态下发的，而预定动态化更新框架即可接收该动态下发的业务数据包，因此，其包括的数据中应该是含有能够动态下发的语言编写的数据。由于配置文件通常都是采用xml编写的，是不具备动态下发能力的，因此，在设置时，需要第一预定语言为可以动态下发的语言，例如可以是javascript。
当预定应用接收到该业务数据包后，就可以利用该业务数据包中的业务逻辑数据和配置文件了。
而原生语言组件中的预定解析器，是由预定应用将原生界面元素封装至与动态化更新框架适配而生成的。在接收到业务数据包之后，就可以对该数据进行解析了，进而得到界面元素的配置参数。当获取到该配置参数后，并不是马上使用获取到的所有参数，而是将这些参数放置到一个容器中，即存储在预设存储空间中，该预设存储空间在程序设置时可以作为一个类对象实例存在。
解析出来的配置参数通常是能够构建界面元素的所有信息，例如至少包括名称、属性集合、子节点、父节点、预设唯一id、系统id等。在开发人员设置程序时，通常还会在配置文件中包括可以生成界面元素的功能函数索引，以便更方便的创建界面元素。
由于业务逻辑数据是通过第一预定语言编写的，因此，在原生语言组件识别该业务逻辑数据时，也是无法识别的，因此，第一预定语言组件会在接收到业务数据包后，将业务逻辑数据按照原生语言进行逻辑转换，以便能够将对应的业务逻辑告知原生语言组件，使得原生语言组件也能够识别该转换之后的业务逻辑数据。
当业务逻辑数据进行逻辑转换后，原生语言组件则可以识别该转换之后的业务逻辑，进而可以根据该逻辑调用对应的功能函数来实现创建界面元素的功能，具体实现时，每一个流程涉及到的功能函数都是按照逻辑调用的，调用该功能函数时，可以根据功能函数对应的功能获取对应的配置参数，进而按照反射构建机制一步步根据配置参数创建所需要的界面元素。上述创建界面元素的过程可以是对已有界面元素进行更新而创建界面元素，也可以是对不存在的界面元素进行的创建过程。
计算机程序在被处理器执行基于反射构建机制按照功能函数和配置参数创建界面元素的步骤时，具体实现如下步骤：原生语言组件获取配置参数中的界面元素名称，按照反射构建机制构建初始界面元素；原生语言组件将初始界面元素的界面元素id赋值为配置参数中的预设唯一id；原生语言组件依次按照配置参数中的参数为界面元素id赋值后的初始界面元素设置界面元素参数，以创建界面元素。
计算机程序在被处理器执行原生语言组件按照业务逻辑数据对应的流程依次通过功能函数索引调用功能函数的步骤之后，还被处理器执行以下步骤：原生语言组件获取配置参数中的界面元素的预设唯一id，并根据预设唯一id确定界面元素的系统id；原生语言组件检测系统id是否存在已创建的界面元素；在系统id不存在已创建的界面元素的情况下，原生语言组件基于反射构建机制按照功能函数和配置参数创建界面元素。
计算机程序在被处理器执行原生语言组件检测系统id是否存在已创建的界面元素的步骤之后，还被处理器执行以下步骤：在系统id存在已创建的界面元素的情况下，按照配置参数修改已创建的界面元素对应的界面元素参数，以更新已创建的界面元素。
计算机程序在被处理器执行基于反射构建机制按照功能函数和配置参数创建界面元素的步骤之后，还被处理器执行以下步骤：原生语言组件将创建好的界面元素添加到界面元素对应的父节点界面元素中，以在预定应用的预定界面中呈现界面元素。
下面结合一个编程过程中涉及到的具体实例对上述过程进行说明，但并不对上述实施例构成限定。
现有技术实现不进行应用版本更新而对activity中内容(界面元素)的更新是一个难题，而如果使用原生开发来实现activity的动态增加会比较困难，因此，在使用du框架进行动态的增加activity的时候对其界面的元素的控制，本实施例提供了一种类似android原生中把xml配置映射成界面view的技术，具体实现如下。
本发明实施例采用了du框架，du框架是类似与react-native的热更新框架，react-native是将所有的开发放在了js(javascript的缩写)中。du框架也是类似的设计，图9为du框架中native侧与js侧进行交互的示意图。根据图9所示，du框架是通过一组协议来实现js和native的通信，从而达到通过js(相当于上述的第一预定语言组件)来控制native(相当于上述的原生语言组件)的组件交互。其中，该协议包括：protocol协议，而且，js只是用来做逻辑控制，涉及到view(即界面元素)的展现还是native在做。在考虑view的实现过程中，本发明实施例先将界面布局写入xml(相当于上述的配置文件)中，然后在activity中oncreate方法(一个功能函数)中进行xml文件(相当于上述的配置文件)路径设置，再在oncreate方法中对xml文件内容进行解析生产视图view然后添加到activity的跟布局view中。同样我们采用类似的方法实现view的生产和添加，但是在实现的过程中，因为du框架和原生本质的不同。本实施例在涉及整套自定义配置文件转化为view的解决方案中有很多与原生不同之处。
(1)布局文件xml的加载。
在android原生开发过程中，我们只需要将r文件中res/layout目录下局xml文件所生成的id作为参数传递到oncreate方法中。但是在du框架中，xml文件在asset目录下不能通过r文件以id作为索引的方式快速查找。所以，本实施例启动原生activity的时候传递的是服务器动态后缓存在asset目录下的xml文件的路径地址，通知要将启动该activity对应的activity.js文件的路径传递给原生activity，这样有界面和业务逻辑处理的activity才算与原生相同。
(2)xml文件映射出view。
xml文件映射出view的过程也是仿android原生的设计。通过本实施例设计的layoutparser类(一段程序)的parselayoutxml方法(改程序对应的一个功能)将传递的xml文件路径所在的文件找到，并利用经将原生界面元素进行封装而得到的预定解析器proxy解析xml文件，以解析出每个xml文件中的view。其中，该对应的预定解析器proxy与xml文件具有相同的id。而且，在解析的过程中，会将整个xml文件中的内容生成一个templateviewvo类对象实例(相当于预设存储空间)来存储xml文件中的配置参数。接下来，通过递归的方式将xml文件中生成的templateviewvo类对象实例中的所有view节点遍历出来，方便以后业务逻辑对界面元素的操作。
其中，该预定解析器proxy是该进行动态化更新的预定应用通过将原生界面元素进行封装生成的。
图10为预定解析器、原生界面元素及xml文件的关系示意图。如图10所示，预定应用通过对原生界面元素进行封装，以适配du框架，从而生成对应的预定解析器proxy，而该预定解析器proxy对与该预定解析器proxy具有相同id的xml文件进行解析，以得到相应的view。
android原生开发中对view的操作都是根据r文件中生成的id找到view树种的相同id节点的view进行操作。本实施例在设计视图操作的时候也有类似的id方便以便于视图的操作。在上一步预定解析器proxy解析器每解析出一个节点的时候，便会从0x30000000开始构造出一个自增的id值赋给当前templateviewvo类对象实例中的viewid属性。这样就也可以根据view的id和所有view的templateviewvo类对象实例对应起来操作每一个view。
每一个view的信息我们都存储在templateviewvo类对象实例中了，这样下一步就是构造出所有的view。通过templateviewvo类对象实例中存储的name属性值反射构造出对应的view，然后再给view的id赋值viewid。下一步，将所有的templateviewvo类对象实例中的属性标签以及对应的值解析，并赋值给view对应的各个属性。最后一步，创建view对应的proxy类(即代理类，是一段程序，可以将最终构造的view呈现在界面上)，这些代理类和view类的对应关系我们在xml文件中已经声明了的，所以也可以根据templateviewvo类对象实例的name属性值反射获取对应的proxy类实例对象赋值给templateviewvo类对象实例的baseproxy属性，并将其与改view进行绑定，可以按照view继承的层次在proxy层继承实现view所有的属性解析和赋值。每当一个view构造完毕我们都会add到该view的根view上，当前最初传递的根view是activity的contentview。这样整个界面xml文件所有声明的view元素都就展示在activity中了。
最后，为了方便根据viewidstring(字符串)寻找对应的view，我们将viewidstring作为key(关键值)，将对应的templateviewvo类对象实例作为value(索引值)存储在一个当前activity实例的map(集合)中。
(3)js端操作native生产的所有view元素。
在js端进行开发的时候不知道view对应的id，所以我们只能根据当前activity的xml文件界面中view对应的viewidstring来想办法与原生的view做关系映射。本实施例可以通过protocol协议利用当前原生activity缓存的以viewidstring作为key将对应的templateviewvo类对象实例作为value存储的数据集map，从中获取对应的view的所有信息，然后根据js端传递过来的参数名和参数列表对view的方法进行反射调用。
本实施例使用du框架中的这种自定义配置文件转化为系统视图文件的实现方法，能够使开发的应用产品的性能体验有类似于原生的效果，并且能够使android开发者能很快的接入现在的项目中并熟练上手开发新需求。
实现时，上述存储介质可以设置在移动终端中，作为移动终端存储器的全部或部分存在，本领域技术人员可以根据实际需求进行设置。
可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述实施例记载的方法步骤。可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
尽管为示例目的，已经公开了本发明的优选实施例，本领域的技术人员将意识到各种改进、增加和取代也是可能的，因此，本发明的范围应当不限于上述实施例。