[0117] 通过以上所述可见，在具体实现时，为了让Dynative能完整解析界面各种数据， 服务器端下发的界面数据需要包含传统native界面开发时需要的所有信息，主要包括界 面布局信息和界面数据内容信息，数据内容信息还包括静态信息以及动态逻辑信息。例如， 在某一具体实现的例子中，Dynative服务端下发的数据结构可以如下所示：
[0119] 其中，layout中存放了整个界面的布局信息，用来描述该界面中包括哪些组件，各 个组件在界面中的位置、尺寸等，Dynative解析器可以将该部分数据解析映射成各个移动 的真实界面元素。
[0120] 例如，layout的具体数据结构可以为：
[0122] Context中存放了界面静态数据，如果某组件展示的数据不需要另外调网络接口 获取，就可以直接将静态数据存放在这里，Dynative在使用界面数据时会从这里取。
[0123] 例如，Context的具体数据结构可以为：
[0126] function中包含了该界面使用到的脚本函数，脚本函数的功能包括调用某个网络 接口获取界面数据、响应用户点击操作跳到其他界面等等。
[0127] 例如，function的具体数据结构可以为：
[0129] 需要说明的是，本申请实施例中所述的组件可以包括原子组件以及容器组件两 种。其中，所谓的原子组件是指最小的组件，一般用来展现某种特定形式的内容，如文本组 件用来显示文本信息，图片组件用来展现图片等；所谓容器组件是用来管理组件的一种特 殊组件，对其管理的所有子组件的生命周期负责，包括解析、布局、绘制等等。为了解决布局 定义复用的问题，在本申请实施例中，还可以允许开发者在界面数据中定义复合组件，所谓 复合组件是使用原子组件和容器组件拼装成的各种组件，一般跟实际业务紧密联系。在实 际应用中，只要定义出一个复合组件，界面中任何地方都可以引用，而不需要在各个地方重 复定义相同的界面布局。
[0130] 例如，在实际应用的例子中，复合组件可以是通过lib进行定义，具体的数据结构 可以如下所示：
[0131]
[0134] 在以上实例中，定义了一个名为fourfoldimage的复合组件，该复合组件的功能 是，每行显示两个原子组件，并在第8行至第13行定义了第一个原子组件的类型等，在第14 至第19行定义了第二个原子组件的类型，两种均为图片组件；因此，在layout中就可以使 用该复合组件，其中，在第31行以及第45行各使用了一次该复合组件，并指定具体显示的 图片地址，最终的显示效果可以如图1所示。
[0135] 需要说明的是，在存在复合组件的情况下，服务器端下发的界面数据的完整数据 结构可以如下：
[0137] 另外，关于前文介绍的文本组件、图片组件等都属于系统组件（包括原子组件和 容器组件），在定义这些组件时，都需要指定其type类型名称，例如，在前述例子中的第5 行、第10行都分别指定了 type名称信息。但是，在使用复合组件时，为了与原子组件进行 区分，使用了 ref作为关键字，如前述例子中的第31行以及第45行。对于Dynative解析 器而言，在对界面数据信息解析时，如果发现type关键字，则可以确定其定义了一个系统 组件（包括原子组件和容器组件），如果发现ref关键字，则确定其使用了 一个复合组件，然 后根据ref后的复合组件名称，到libs中找到对应的复合组件信息，并根据复合组件信息 中定义的原子组件信息，进行后续向原生组件的映射等操作。
[0138] 按照以上方式定义完界面数据之后，可以将其保存在服务器端，后续在需要展现 该界面时，就可以使用Dynative对界面数据进行解析渲染。其中，具体在对界面数据进行 解析时，Dynative的一项主要工作就是将界面数据中定义的各种组件映射为移动终端中的 原生组件，在存在动态脚本的情况下，将动态脚本中的各种基本元素映射成移动终端中的 原生API，并将原生API函数确定为该组件的内容数据，以便当动态脚本的执行事件被触发 时，使用原生代码对这种原生API进行调用。为了完成这种映射，还需要预先保存协议中的 各个组件信息与具体移动终端中的原生组件之间的对应关系，另外还需要预先保存协议中 为动态脚本定义的各种基本元素的类型取值与移动终端中的原生API函数之间的对应关 系。
[0139] 因此，具体实现时，可以为移动终端App的开发者提供SDK包，这种SDK包中可以 包括Dynative渲染引擎（该引擎是的处理逻辑可以是与无关的），以及界面数据中的组件 信息与终端设备中的原生组件之间的对应关系、界面数据中存在动态脚本的情况下，还包 括脚本中定义的各种基本元素的类型取值与移动终端中的原生API函数之间的对应关系 (上述两种对应关系信息是与相关的，例如，同样的功能在不同的中会对应不同的原生组 件）。换而言之，该渲染引擎的主要作用就是，根据SDK中保存的对应关系，将界面数据中定 义的组件信息，映射中当前移动终端中的原生组件，将界面数据中定义的动态脚本映射成 当前移动终端中的原生API函数，并调用当前移动终端中的原生代码，对原生组件进行渲 染展示。也就是说，相对于webkit而言，Dynative是一种轻量级的渲染引擎，主要起到了 界面数据与原生代码之间的中介作用，不再需要Webview的中转。
[0140] 如前文所述，上述两种对应关系是与相关的，例如，同样是文本组件，在Android 中，对应的原生组件是textview，而在iOS中，对应的原生组件是lable，等等。因此，为了 实现正确的转换，可以分别针对不同的移动终端提供不同的SDK包，在不同的SDK包中，前 述对应关系是不同的。例如，对于Android而言，界面数据中的组件信息与终端设备中的原 生组件之间的对应关系可以如表5所示：
[0144] 对于iOS而言，这种对应关系可以如表6所示：
[0147] 对于Android而言，界面数据中的动态脚本定义的各种基本元素的类型取值与移 动终端中的原生API函数之间的对应关系，可以如表7所示：
[0150] 对于iOS而言，这种对应关系可以如表8所示：
[0151] 表 8
[0154] 备注：以上组件和API中只列举了两三个例子来说明原理，实际上SDK中会包含多 种组件及API的映射逻辑。
[0155] 其中，为了能够直接调用移动终端中的原生代码，在为某移动终端开发SDK包时， SDK包可以是使用该移动终端设备中原生应用所使用的编码语言进行开发的。例如，对 于iOS而言，其原生App -般是用ObjectC语言开发的，则为iOS提供的SDK包也可以用 Ob jectC语言开发，而Android的原生App -般是用Java语言开发的，因此，为Android提 供的SDK包也可以是用Java语言进行开发。总之，对于为不同移动终端开发的SDK包而言， 各自使用的语言可能是不同的，各自保存的组件信息与原生组件之间的对应关系也可能不 同，但Dynative内核的实现逻辑是相同的。
[0156] 这样，App开发者可以按照一定的格式编写App的界面数据，但是，不需要将这种 界面数据代码打包到安装包中，而是仅保存在服务器中即可。在需要将其App发布到某具 体的移动终端中时，可以将本申请实施例为该移动终端开发的SDK包集成到App的客户端 安装包中。例如，在向Android发布时，可以将Android对应的SDK包集成到App中，在向 iOS发布时，可以将iOS对应的SDK包集成到App中，等等。当然，对应不同的，在服务器中 只需要保存同一份界面数据即可，相应的，不同的SDK包中的Dynative内核，可以按照各自 保存的对应关系，进行从界面数据到原生组件、原生API函数的映射，并且Dynative内核还 可以直接进行与进行交互，调用中的原生代码，直接进行原生组件的渲染展现，而不需要经 过类似webview的中转，实现起来更加方便灵活。
[0157] 可见，在本申请实施例中，对于移动终端App而言，由于所有的界面数据都是仅保 存在服务器端，因此，在需要进行App的升级、bug修复等操作时，直接对服务器保存的界面 数据进行修改即可，不必再向终端设备下发升级信息等，因此，可以使得用户更及时的使用 到更新后的版本。另一方面，由于客户端中集成了本申请实施例的SDK包，其中的Dynative 内核是使用与原生应用相同的语言开发的，因此，既可以将界面数据映射成中的原生组件， 还可以直接调用的原生代码实现对原生组件的渲染展示，因此，不再需要依赖于浏览器的 webkit内核，也不再需要通过webview进行中转，所以，可以更加灵活方便的访问本地的 各种服务和资源，包括本地文件系统或网络跨域等，例如，如果某应用需要调用移动终端设 备中的相机功能，则可能直接在界面数据中进行定义，Dynative内核可以将其映射成中的 API，并利用该API进行调用，等等。另外，还可以顺畅的使用移动终端上的各种特性，包括 传感器技术等。
[0158] 下面对Dynative进行界面展现过程中的具体实现方式进行详细地介绍。
[0159] 实施例一
[0160] 参见图2,本申请实施例一首先提供了一种应用界面渲染方法，该实施例一主要 从客户端的角度对本申请实施例的方案进行介绍。其中，开发者为提供的应用的界面数据 保存在服务器中，应用的客户端中设有SDK包，在优选的实现方式下，所述SDK包可以是使 用当前移动终端设备中原生应用所使用的编码语言进行开发的，该SDK包中包括一渲染引 擎，以及界面数据中定义的组件信息与当前终端设备中的原生组件之间的对应关系，具体 的，该方法可以通过该渲染引擎完成以下步骤：
[0161] S201 :在接收到展示应用的指定界面的请求时，向服务器请求该应用的所述指定 界面的界面数据；
[0162] 所谓的指定界面可以是应用的主界面，或者其他子界面，等等。在接收到展示指定 界面的请求时，由于界面数据并没有跟随安装包一起下载到终端设备，因此，可以首先向服 务器请求该界面的界面数据。关于界面数据的具体定义方式已经在前文中进行了介绍。
[0163] S202:接收到服务器返回的界面数据后，对所述界面数据进行解析，获得所述界面 数据中定义的组件信息；
[0164] 由于用json等语言定义的界面数据无法直接被终端设备识别，因此，在接收到服 务器返回的界面数据之后，Dynative内核就可以对该界面数据进行解析，并且可以直接映 射成当前终端设备中的原生组件。也