移动端动态方案--VideoOS技术选择及具体实施-CSDN博客

背景

动态化作为移动端的一个重要技术分支，一直是大家积极探索的方向。目前移动端流行的动态化方案，按技术方向分为以下两种：

跨平台动态语言方案，利用js，lua等脚本语言做native功能的拓展，需要定义各个跨语言的bridge。代表性的方案有Facebook的React Native，阿里的Weex，它们都是采用了JavaScript与Native之间的桥接，使JavaScript开发的App拥有近似于原生应用的性能。
利用JVM或者iOS的Runtime来做动态生成代码或动态修改代码后做代码注入。代表性的方案有已经被App Store禁止的JSPatch。

但是Facebook的React Native和阿里的Weex接入以后会显著增加App包的大小，还有环境搭建问题，不适合SDK的开发，只适合App开发。

通过对比几种动态化方案，最后选择阿里的LuaView方案来实现平台的SDK。LuaView是由lua与Native控件之间的桥接来实现的，相对于其他解决方案来说，是一个轻量级的解决方案。而且Lua语言可扩展性强、简单、高效、占用体积小、启动速度快、学习简单等诸多优势，有着许多成功案例，是动态化方案首选。

LuaView设计原则

LuaView以UI视图构建能力为基础，实现了原生Native UI桥接到Lua Api，使用Lua脚本语言开发应用功能，同时能够达到原生应用的性能和效果。

LuaView SDK整体架构

如图，LuaView SDK的整体架构可以表示为四层。

第一、二层依次是OS层和Framework层，分别代表了Android、iOS以及对应的系统框架层。

第三层有Lua虚拟机，脚本管理模块，安全控制模块和核心Lib库。Android使用的是LuaJ虚拟机，iOS使用的是LuaC虚拟机，这两个虚拟机都是目前两种语言中用的最广泛，最稳定的虚拟机。脚本管理模块负责Lua脚本的管理，包括脚本的解包、验证、加解密、解压缩等工作。安全控制模块负责Lua脚本的安全校验工作，包括脚本完整性校验和脚本安全校验等。LuaView的核心Lib库，包括Lua UI Lib（主要是所有的UI组件，如View、Button、Label、Image等）和Lua Non-UI Lib（主要包括Network、Json、Gesture）。

最上层是Lua业务脚本以及Lua层的lib库。

LuaView的两个重要的设计原则

两端一致性

LuaView的一条重要设计原则就是iOS和Android两端逻辑只写一份代码，API设计的时候考虑了两端的共性，对于两端不同的地方，则由Native部分实现。现在，LuaView SDK中Lua API基本完成两端接口的统一，保证API一致性，同一份脚本在两端运行的结果也是相同的。

简单易用

LuaView的另一个设计原则是保持Lua语言的简单和易用。在核心UI库上，所有的API做到精简，尽量使用脚本实现避免使用Native实现。所有API使用Lua原生语法，并且两端的接口保持一致风格，方便开发。

VideoOS

VideoOS是一款针对视频的互动娱乐系统，添加到视频系统中，给视频赋能，既可以增加视频的收入，也可以增加视频的娱乐性。

VideoOS整体架构

VideoOS移动端是在LuaView SDK的基础上，扩展了VP UI和VP Non-UI，以及添加了视频互动娱乐模块。VideoOS移动端使用LuaView的动态化，可以动态的添加新的互动娱乐模块，以及修改现有的互动娱乐模块。

VideoOS移动端架构

VideoOS首先会对比本地版本和服务器版本，若是两个版本不一致，将服务器版本更新到本地，并写入本地文件Cache中。在系统运行互动娱乐模块时，LuaCore按照模板的文件名，在文件Cache中查找，找到脚本文件以后，即可加载运行脚本文件，展示具体的互动类型。具体的流程如下：

VideoOS移动端运行流程

应用 VideoOS中所有互动娱乐应用，如云图、中插、气泡、投票等，都是采用统一的策略，将应用的共有属性抽像为相同的参数，差异化的内容，则在应用中自己处理。这样客户端收到投递的广告时，将统一处理应用数据，按照应用数据时间，展示应用，控制应用展示的频次，在这个阶段系统并不知道处理的是哪个应用。应用展示时，根据应用数据展示具体的应用效果，所有的差异化的内容都在这个阶段处理。同时，将应用中的各种事件，如展示、点击、关闭等，还有需要对接平台处理的操作，抽象为统一的参数，这样所有的应用都有一样的事件处理机制。以上的这些特性，可以极大的增加系统的扩展性，如果系统需要新的应用，只需要按照上面的策略，统一添加投递和事件处理的参数，实现特异化的内容，就可以添加到系统中了。