移动端混合开发框架分析

移动端架构分析
目录
移动端架构分析 (1)
1移动端常见开发模式 (5)
1.1纯N ATIVE A PP (5)
1.1.1主流框架 (5)
1.1.2优势 (6)
1.1.3劣势 (6)
1.1.4主流应用 (6)
1.2H YBRID A PP (6)
1.2.1多View混合型 (7)
1.2.1.1主流框架 (7)
1.2.1.2优势 (7)
1.2.1.3劣势 (7)
1.2.1.4主流应用 (7)
1.2.1.5发展趋势 (7)
1.2.2Web主体型 (8)
1.2.2.1主流框架平台 (8)
1.2.2.2优势 (9)
1.2.2.3劣势 (9)
1.2.2.5发展趋势 (10)
1.2.3单View混合型 (10)
1.2.3.1主流框架 (10)
1.2.3.2优势 (10)
1.2.3.3劣势 (10)
1.2.3.4主流应用 (10)
1.3W EB A PP (10)
1.3.1主流框架 (11)
1.3.2优势 (11)
1.3.3劣势 (11)
1.3.4主流应用 (11)
1.4四种主要开发模式对比 (11)
2移动前端主流框架分析 (12)
2.1W EB和N ATIVE混合 (12)
2.1.1WindVane+Hybrid+Native (12)
2.1.1.1简介 (12)
2.1.1.2框架实现 (12)
2.1.1.3架构图 (13)
2.1.2AppCan (13)
2.1.2.1简介 (13)
2.1.2.2框架实现 (13)
2.2跨平台原生应用 (15)
2.2.1BeeFramework (15)
2.2.1.1简介 (15)
2.2.1.2框架实现 (15)
2.2.1.3架构图 (16)
2.2.2Native Script (17)
2.2.2.1简介 (17)
2.2.2.2框架实现 (17)
2.2.2.3结构图 (18)
2.2.3React Native (18)
2.2.3.1简介 (18)
2.2.3.2框架实现 (18)
2.2.3.3架构图 (20)
3数梦移动端开发框架选择...................................... 错误!未定义书签。

3.1开发模式选择 (20)
3.1.1为什么不选择Native (20)
3.1.2玩什么不选择WebApp或Web主体型Hybird (21)
3.1.3选择多页面混合型Hybird (21)
3.2选择类W IND V ANE框架 (21)
3.2.1玩什么不选择React Native (21)
3.2.2玩什么选择类WindVane框架 (21)
1移动端常见开发模式
目前主流应用程序大体分为三类：Native App 、Hybrid App、Web App。

1.1纯Native App
Native APP 指的是使用原生程式编写运行的第三方应用程序，一般依托于操作系统如iOS、Android、WP，有很强的交互，是一个完整的App，可拓展性强。

需要用户下载安装使用。

也叫本地app。

Native App因为位于平台层上方，向下访问和兼容的能力会比较好一些，可以支持在线或离线，消息推送或本地资源访问，摄像拨号功能的调取。

但是由于设备碎片化，App 的开发成本要高很多，维持多个版本的更新升级比较麻烦，用户的安装门槛也比较高。

但是比较乐观的是，AppStore培养了一种比较好的用户付费模式，所以在Apple的生态圈里，开发者的盈利模式是一种明朗状态，其他market也在往这条路上靠拢。

1.1.1主流框架
iOS：
（1）、Cocoa 环境+Foundation 和UIKit 框架
（2）、使用Objective-C 和Swift 做为主要开发语言（兼容C/C++）
Android：
（1）、Java虚拟机环境
（2）、使用Java 作为主要开发语言（支持C/C++）
WindowsPhone：
（1）、Windows RunTime 框架（WP10）
（2）、使用原生C++、C# 和Silverlight 做为主要开发语言
1.1.2优势
（1）、打造完美的用户体验
（2）、性能稳定
（3）、操作速度快，上手流畅
（4）、访问本地资源（通讯录，相册）
（5）、设计出色的动效，转场
（6）、拥有系统级别的贴心通知或提醒
（7）、用户留存率高
1.1.3劣势
（1）、开发成本高，可移植性差，需要维护iOS、Android、WP等多个平台（不同平台有不同的开发语言和界面适配）
（2）、维护成本高（例如一款App已更新至V5版本，但仍有用户在使用V2，V3，V4版本，需要更多的开发人员维护之前的版本）
（3）、更新缓慢，根据不同平台，提交–审核–上线等等不同的流程，需要经过的流程较复杂
1.1.4主流应用
够快云库、微信电话本、美图秀秀等中量级应用。

1.2Hybrid App
Hybrid APP指的是半原生半Web的混合类App。

需要下载安装，部分页面看上去类似Native App，但只有很少的UI Web View，访问的内容是Web 。

Hybrid App主要以JS+Native两者相互调用为主，从开发层面实现“一次开发，多处运行”的机制，成为真正适合跨平台的开发。

Hybrid App同时使用网页语言与程序语言开发，通过应用商店区分移动操作系统分发，用户需要安装使用的移动应用。

总体特性更接近Native App但是和Web App区别较大。

只是因为同时使用了网页语言编码，所以开发成本和难度比Native App要小很多。

因此说，Hybrid App兼具了Native App的所有优势，也兼具了Web App使用HTML5跨平台开发低成本的优势。

Hybrid App按网页语言与程序语言的混合，通常分为三种类型：多View混合型，单View混合型，Web主体型。

1.2.1多View混合型
即Native View 和Web View 独立展示，Native View 与WebView 交替的场景出现。

这种应用混合逻辑相对简单。

即在需要的时候，将WebView 当成一个独立的View(Activity) 运行起来，在WebView 内完成相关的展示操作。

这种移动应用主体通常是Native App，Web 技术只是起到补充作用。

开发难度和Native App 基本相当。

1.2.1.1主流框架
Native部分使用操作系统原生框架+JSBridge。

Web融合部分国内阿里系使用最广的框架WindVane+HybridAPI等（后续章节详细介绍）。

1.2.1.2优势
（1）、高效、扩展性强、支持多团队并行开发
（2）、衔接Android/iOS原生导航交互，完美的用户体验
（3）、业务实现更灵活，复杂业务可通过Native 实现，频繁变化或简单业务通过Web 实现，更好的满足移动端业务多样性、快速迭代要求
（4）、轻量级的框架，框架侵入性弱，各个业务高度独立，第三方业务快速接入
（5）、使用JS Bridge 来实现HTML5页面与原生框架的数据交互：JS<->Native，性能和安全性更佳
（6）、扩展丰富，能实现超级App
1.2.1.3劣势
（1）、技术要求高，需要开发人员同时懂Native和WebApp开发
（2）、重量级架构，架构搭建需要较长时间
（3）、开源社区相关框架少，成熟框架如WindVane等不开源
1.2.1.4主流应用
目前使用最常用的开发模式，市场上能见到的超级App 基本都是用这种开发模式，如微信、支付宝、淘宝等；其他如钉钉、新闻客户端等移动端App
1.2.1.5发展趋势
2014-2015最新发展趋势，同时在Web和Native融合的基础上加入ReactNative或NativeScript等跨平台构建原生应用框架（见后续介绍）。

1.2.2Web主体型
即移动应用的主体是Web View，主要以网页语言编写，穿插Native功能的Hybrid App开发类型。

这种类型开发的移动应用体验相对而言存在缺陷，但整体开发难度大幅降低，并且基本可以实现跨平台。

Web主体型的移动应用用户体验的好坏，主要取决于底层中间件的交互与跨平台的能力。

国外的appMobi、PhoneGap和国内的WeX5、AppCan 和Rexsee都属于Web主体型移动应用中间件。

其中Rexsee不支持跨平台开发。

appMobi 和PhoneGap除基础的底层能力更多是通过插件（Plugins）扩展的机制实现Hybrid。

AppCan除了插件机制，还提供了大量的单View混合型的接口来完善和弥补Web主体型Hybrid App体验差的问题，接近Native App的体验。

而WeX5则在揉合PhoneGap和Bootstrap等主流技术的基础上，对性能进一步做了深度优化，不但完全具备Native App 对本地资源的调用能力，性能体验也不输原生；WeX5所开发出来的app具备完全的跨端运行能力，可以无需任何修改直接运行在各种前端环境上。

1.2.2.1主流框架平台
1、Appcelerator
Appcelerator的Titanium开发平台使开发者可以通过HTML、PHP、JavaScript、Ruby、Python等Web编程语言开发手机、平板和桌面的原生App。

其优势在于它可以让用户轻松地访问超过300个API以及定位信息。

此外，Appcelerator提供针对特定行为或事件定制的统计。

App的数据既可储存在云端，也可储存在设备上。

2、APICloud
APICloud是一款“云端一体”的移动开发平台，信仰“云端一体”的理念，重新定义了移动应用开发。

APICloud为开发者从“云”和“端”两个方向提供API，简化移动应用开发技术，让移动应用的开发周期从一个月缩短到7天。

APICloud由“云API”和“端API”两部分组成，可以帮助开发者快速实现移动应用的开发、测试、发布、管理和运营的全生命周期管理。

3、PhoneGap
PhoneGap是一个免费且开源的开发环境，使开发者可以开发出在Android、Palm、黑莓、iPhone、iTouch及iPad等设备上运行的App。

其使用的是HTML和JavaScript 等标准的Web开发语言。

开发者使用PhoneGap进行开发，可调用加速计、GPS/定位、
照相机、声音等功能。

PhoneGap还提供Adobe AIR App以及在线的培训课程，帮助开发者了解原生API 并在他们自己的平台上开发移动App。

4、Kinvey
Kinvey同样是一个为移动应用开发者提供后台创建服务的平台。

Kinvey强调加速移动应用开发与销售的“即取即用”理念。

Kinvey的中间层与数据层均托管在多个云服务提供商处，包括Rackspace、Amazon与Microsoft。

所有通过Kinvey存储的数据都会有四种方式备份：Amazon EC2、Windows Azure、Rackspace以及Kinvey自己的服务器，假如其中一两个出现了故障，用户的数据依然安然无恙。

5、ExMobi
ExMobi通过全面的数据集成技术和丰富的跨平台客户端展现能力，将业务系统快速、安全、高效的移植于移动终端。

ExMobi从开发（IDE环境）、集成（IT系统对接、云服务）、打包（各个操作系统的应用打包）、发布（应用的运行）、管理（日志管理，更新管理）上提供了一套完整的解决方案。

并通过专业的培训和支撑渠道为开发者提供可持续的学习和交流空间，扫除开发障碍。

1.2.2.2优势
（1）、可跨平台，兼容iOS、Android、WP等多个平台
（2）、易用性，会Web开发即可转型App开发
（3）、可利用成熟javascript框架
（4）、程序升级简单
（5）、维护难度低
1.2.2.3劣势
（1）、运行速度慢
（2）、不适合部分程序，如复杂的动画、3D功能、音频视频以及复杂的界面逻辑等（3）、调用平台资源差，功能受限平台实现
（4）、资源占用大，如内存、CPU、网络带宽等
（5）、调试难度大
（6）、不利于多人协作开发
1.2.2.4主流应用
12306客户端、中国工商银行客户端等功能较单一的轻量级应用。

1.2.2.5发展趋势
虽然跨平台复用代码是一个火热的话题，但是基于Html5 的PhoneGap等Hybrid 框架没有被大多数人接受（运行速度慢、交互差是主要原因），目前更多的方案是Web和Native多View混合或用各种办法产生原生的UI 界面（如BeeFramework、NativeScript、ReactNative等）。

1.2.3单View混合型
即在同一个View内，同时包括Native View和Web View。

互相之间是覆盖(层叠)的关系。

这种Hybrid App的开发成本较高，开发难度较大，但是体验较好。

如百度搜索为代表的单View混合型移动应用，既可以实现充分的灵活性，又能实现较好的用户体验。

1.2.3.1主流框架
基本没有特别成型的框架，主要为部分App做Web嵌套，完成广告、宣传等功能。

Native部分同NativeApp。

Web部分同WebApp。

1.2.3.2优势
（1）、能解决广告、宣传等模块变化过快问题，满足市场需求
（2）、有NativeApp的大部分优点
1.2.3.3劣势
（1）、开发难度大，Native和Web 代码混合，技术难度基本等同Native开发
（2）、维护难度大等Native常见的缺点
1.2.3.4主流应用
目前纯粹使用单View混合型的App较少（部分App 的部分页面会用这种开发模式），主要应用场景如App中添加广告、宣传等。

1.3Web App
Web App 指采用Html5语言写出的App，不需要下载安装。

类似于现在所说的轻应用。

生存在浏览器中的应用，基本上可以说是触屏版的网页应用。

1.3.1主流框架
jQueryMobile、AngularJS等。

1.3.2优势
（1）开发成本低
（2）更新快
（3）更新无需通知用户，不需要手动升级
（4）能够跨多个平台和终端
1.3.3劣势
（1）临时性的入口
（2）无法获取系统级别的通知，提醒，动效等等
（3）用户留存率低
（4）设计受限制诸多
（5）体验较差
1.3.4主流应用
微信公众号/订阅号应用、支付宝服务窗应用等轻量级应用。

1.4四种主要开发模式对比
2移动前端主流框架分析
2.1Web和Native混合
2.1.1WindVane+Hybrid+Native
2.1.1.1简介
WindVane是阿里内部一种移动端Web和Native混合框架，主要为解决多平台统一交互体验、动态部署（插件化）等问题，降低开发成本，提升前端开发效率。

WindVane 是对Native代码的一种扩展，基础服务仍然以Native代码为主。

2.1.1.2框架实现
可定制化UI组件
资源本地缓存，资源预置打包服务
Web与本地功能模块通信交互
Web调用本地功能的JSBridge通信服务
2.1.1.3架构图
2.1.2AppCan
2.1.2.1简介
AppCan移动应用快速开发平台是基于HTML5技术的跨平台快速开发解决方案,开发者使用HTML5+CSS3+JavaScript技术可以快速的开发与本地应用相媲美的移动应用,同时支持iOS、Android、Symbian、Windows Phone四大智能操作系统.AppCan-SDK是AppCan平台专为开发者提供的IDE开发环境,集成了:1、移动UI框架2、手机设备API 3、调试模拟器4、离线打包服务5、应用云端管理使移动开发更加方便快捷.
与Phonegap支持单一webview使用div为单位开发移动应用不同。

AppCan支持多窗口机制，让开发者可以像最传统的网页开发一样，通过页面链接的方式灵活的开发移动应用。

基于这种机制，开发者可以开发出大型的移动应用，而不是只能开发简易类型的移动应用。

AppCan提供强大的设备调用能力，电话、短信、相机、LBS、传感器、数据库等常用的手机功能，开发者可以通过JS接口调用，轻松构建移动应用。

AppCan是Web占主体型Native为辅的开发框架。

2.1.2.2框架实现
HTML5：支持HTML5开发，CSS3实现布局优化及交互提升
原生体验：引入部分原生UI控件与交互支持（如Action Sheet等）
开发工具：基于Eclipse的开发工具，集成UI控件与应用管理
模拟器：提供应用全功能模拟器，方便开发调试
UI框架：提供强大的UI框架，更加易于实现页面布局与交互
设备API：支持各种手机设备调用，如电话、相机、传感器、定位等
本地打包：无需配置环境，无需编译，本地一键打包
云端打包：提供云端打包服务，提供更加个性化的选择
多窗口机制：常见应用只支持单一窗口，多窗口可以有效提高交互体验插件机制：支持第三方原生插件，支持JS插件
支付支持：相比国外中间件更具本土优势，Not Paypal but 'ZhiFuBao' 代码加密：基于密钥的加密方式，无法破解，像混编一样保护html代码统计分析：应用分平台安装数统计，应用启动和使用情况统计
开放平台：更具本土优势，已经对接Sina、QQ、百度等开放平台
技术支持：技术支持及时响应，重视开发者建议和反馈
2.1.2.3架构图
生态结构：
移动端框架：
2.2跨平台原生应用
2.2.1BeeFramework
2.2.1.1简介
Bee Framework是一款iOS快速开发框架，允许开发者使用Objective-C和XML/CSS 来进行iPhone和iPad开发，由Gavin Kwoe和QFish开发并维护。

其早期原型曾经被应用在QQ空间和QQ游戏大厅等多款精品APP中。

Bee Framework包含丰富的组件和工具。

Bee Framework解决了iOS开发者长期困扰的各种问题，诸如：分层架构如何设计，层与层之间消息传递与处理，网络操作及缓存，异步及多线程，以及适配产品多变的UI布局需求。

2.2.1.2框架实现
代码注入
借助于OC语言特性，Bee将核心逻辑注入到NSObject基类中去，在使用Bee时，大多数情况下可以不必修改现有类继承关系，这样设计是把双刃剑，也有可能与您现有方法名冲突。

基于MVC模型
典型的MVC架构，清楚的分为View、Controller、Model三个层次，业务数据、业务逻辑、界面展现、交互逻辑完全分离。

事件驱动
对于Controller、Model均与状态无关（Stateless），因此由三种Event驱动：Message、Request、Notification。

对于View，我们抛弃掉了老旧的Delegate（语言级实现方式），引入新概念UISignal（框架级实现方式）用来驱动界面交互事件或状态改变。

UISignal
UISignal拥有极强的路由能力，可以在UIView <-> UIView <-> UIViewController <-> UINavigationController <-> UIViewController 之间完成复杂且高效的的UI信号路由。

2.2.1.3架构图
2.2.2Native Script
2.2.2.1简介
一个开源的框架，可以使用JavaScript开发跨平台、真正原生的iOS, Android 和Windows 移动App。

开发人员使用NativeScript提供的库来构建应用UI，其抽象了各种原生平台之间的不同。

2.2.2.2框架实现
NativeScript运行时
NativeScript使用JavaScript虚拟机，在Android上采用Google V8 JavaScript引擎，iOS上采用JavaScriptCore引擎。

通过JS解析引擎，在JavaScript和原生语言之间的转换，建立跨平台桥梁。

JavaScript虚拟机管理
V8 知道Android是什么（同理JavaScriptCore也知道iOS是什么），因为NativeScript 在运行时进行了注入，因为V8拥有一堆让你配置JavaScript环境的API。

在JavaScript 中您可以使用自定义的C++代码来分析CPU使用率，管理的JavaScript垃圾收集，等等一大堆API
面对这些API的是几个“Context”类，可以让你操纵全局变量，从而有可能为NativeScript注入一个全局的android对象。

这实际上使用了与Node.js的相同运行机制，使全局API可用- 如require() - NativeScript使用它注入可以让你访问本地代码的API。

JavaScriptCore的也有类似的机制。

Metadata（元数据）
对于NativeScript，反射是让NativeScript可以调用每个平台上的API的基石。

因为从性能角度来看重构这些API是很困难的，NativeScript会提前做掉这些，并在Android/iOS预编绎过程中嵌入预先生成的元数据。

调用本地代码
NativeScript如何调用本机代码的答案就在于JavaScript虚拟机的API。

我们上次使用V8的API是注入全局变量。

这一次，我们将着眼于在JavaScript回调中调用给定的C++代码。

例如，JavaScript函数调用的代码new android.text.format.Time()，V8会产生一个回调。

也就是说V8有一个回调，让NativeScript拦截函数调用，然后用自定义的C ++代码执行一些动作，并返回一个新的结果。

在Android中的情况下，NativeScript运行的C++代码不能直接访问Java API，如android.text.format.Time。

然而，Android的JNI ，或Java本地接口，提供了C++和Java之间的桥接能力，所以NativeScript使用JNI完成转发。

在iOS中这个桥梁是不必要的，因为C++代码可以直接调用Objective-C的API。

2.2.2.3结构图
2.2.3React Native
2.2.
3.1简介
React Native 使你能够使用基于JavaScript 和React 一致的开发体验在本地平台上构建世界一流的应用程序体验。

React Native 把重点放在所有开发人员关心的平台的开发效率上——开发者只需学习一种语言就能轻易为任何平台高效地编写代码。

Facebook 在多个应用程序产品中使用了React Native，并将继续为React Native 投资。

2.2.
3.2框架实现
原生的iOS 组件
可使用标准平台组件，比如iOS 平台上的UITabBar 和UINavigationController。

这可以让你的应用程序拥有和原生平台一致的外观和体验，并保持较高的品质。

使用相应的React 组件，如iOS 标签栏和iOS 导航器，这些组件可以轻松并入你的应用程序中。

异步执行
JavaScript 应用代码和原生平台之间所有的操作都是异步执行，并且原生模块也可以使用额外线程。

这意味着我们可以解码主线程图像，并将其在后台保存至磁盘，在不阻塞UI 的情况下进行文本和布局的估量计算，等等。

因此，React Native 应用程序的流畅度和响应性都非常好。

通信也是完全可序列化的，当运行完整的应用程序时，这允许我们使用Chrome Developer Tools 来调试JavaScript，或者在模拟器中，或者在真机上。

触摸处理
iOS 有一个非常强大的系统称为Responder Chain，可以用来响应复杂视图层级中的事件，但是在Web 中并没有类似功能的工具。

React Native 可实现类似的响应系统并提供高水平的组件，比如TouchableHighlight，无需额外配置即可与滚动视图和其他元素适度整合。

弹性框和样式
布局视图应该是简单的，所以我们将Web 平台上的弹性框模块引入了React Native。

弹性框可用来搭建最常用的UI 布局，比如代用边缘和填充的堆叠和嵌入。

React Native 还支持常见的Web 样式，比如fontWeight 和StyleSheet 抽象，它们提供了一种优化机制来宣称你所有的样式和布局在组件中的应用是正确的，且组件把它们应用到了内网中。

Polyfills
React Native 的重点是改变视图代码编写的方式。

接下来，我们注意网络中普遍的并把那些API 放在适当的地方。

可以使用npm 安装JavaScript 库，这些库用于融入到React Native 中的顶级功能，比如XMLHttpRequest，window.requestAnimationFrame 及navigator.geolocation。

我们正在扩大可用的API，并致力于为开源社区做出贡献。

可扩展性
使用React Native 无需编写一行原生代码即可创建出一款不错的应用程序，并且React Native 可通过自定义原生视图和模块来进行扩展--也就是说你可以重用你已经构建的任何内容，并且可导入和使用你最喜欢的原生库。

为了在iOS 中创建一个简单的模块，需要创建一个新的类来实现RCTBridgeModule 协议，并将你想要在RCT_EXPORT_METHOD 中对JavaScript 可用的功能包装起来。

另外，类本身必须可以用RCT_EXPORT_MODULE() 显式导出；
调用流程（iOS为例）
JS调用OC模块方法的详细流程，包括callback回调。

这时需要细化一下上述的调用流程图：
2.2.
3.3架构图
3技术选型
3.1开发模式选择
3.1.1为什么不选择Native
（1）、App开发周期长，无法适应频繁变化的业务需求
（2）、灵活性差，模块化复杂，很难做到千人千面
（3）、App之间的互联规范必须通过H5的桥接
3.1.2玩什么不选择WebApp或Web主体型Hybird
（1）、弱网体验差，页面加载时间长
（2）、体验交互差
（3）、天生短板，复杂应用实现难度非常大且效果不好
（4）、资源消耗大，CPU、内存、流量
（5）、Web主体型Hybrid已经慢慢被主流开发者抛弃（体验差、速度慢）
3.1.3选择多页面混合型Hybird
（1）、灵活性强，快速适应变化，无序的需求与有序的研发
（2）、可靠，基础框架使用Native实现
（3）、离线HTML/CSS/JS，极速Web体验
（4）、业务与平台解耦、业务独立性强，适应多人协调开发
（5）、模式成熟，微信、淘宝、支付宝等大型App都使用类似的模式
3.2选择类WindVane框架
由于Native Script、BeeFramework等框架使用人数较少或框架通用性等问题（如Native Script虽然在iOS和Android都使用JS开发，但是采用代码注入的方式实现，由于iOS和Android API的差异，实际上并不能实现真正意义上的跨平台；而BeeFramework 仅仅实现了iOS，通用性更差），不在此讨论之列。

3.2.1玩什么不选择React Native
（1）、学习成本、项目管理成本高
（2）、新框架不成熟（2015-03 FB开源React Native Web&iOS、2015-09开源React Native Android）
（3）、缺少大型应用经验（国内相关资料少）
3.2.2玩什么选择类WindVane框架
（1）、适合做大型App，App中嵌套MicroApp，业务契合度大
（2）、已经经过淘宝、支付宝等大型App实践，iOS和Android原生支持JSBridge，相关资料或开源框架多
（2）、部分基础服务可以共用代码
4技术选型
4.1开发模式选型
4.1.1UI开发需求
UI支持Native+Web两种开发模式，对于性能要求高界面复杂的页面使用Native实现，对于变化频繁的业务使用Web方式实现，最大程序保证UI开发的灵活性。

4.1.2应用开发效率
4.1.3跨平台兼容性
基础框架基于操作系统原生语言，业务使用HTML5+JS，保证业务良好的跨平台兼容性，实现一次开发，编译到不同的平台的应用程序包，并发布。

4.1.4产品现状、前景
目前Native主体混合型是各大互联网公司的首选，模式成熟，微信、淘宝、支付宝等大型App都使用类似的模式。

各大操作系统平台厂商（包括iOS、Android等主流平台）也优化JS和原生语言之间的通信机制。

4.1.5未来发展
框架选型。