移动端混合开发框架分析.docx
《移动端混合开发框架分析.docx》由会员分享，可在线阅读，更多相关《移动端混合开发框架分析.docx（18页珍藏版）》请在冰豆网上搜索。
移动端混合开发框架分析
移动端架构分析
1移动端常见开发模式
目前主流应用程序大体分为三类：
NativeApp、HybridApp、WebApp。
1.1纯NativeApp
NativeAPP指的是使用原生程式编写运行的第三方应用程序，一般依托于操作系统如iOS、Android、WP，有很强的交互，是一个完整的App，可拓展性强。
需要用户下载安装使用。
也叫本地app。
NativeApp因为位于平台层上方，向下访问和兼容的能力会比较好一些，可以支持在线或离线，消息推送或本地资源访问，摄像拨号功能的调取。
但是由于设备碎片化，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〕、WindowsRunTime框架〔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.2HybridApp
HybridAPP指的是半原生半Web的混合类App。
需要下载安装，部分页面看上去类似NativeApp，但只有很少的UIWebView，访问的内容是Web。
HybridApp主要以JS+Native两者相互调用为主，从开发层面实现“一次开发，多处运行”的机制，成为真正适合跨平台的开发。
HybridApp同时使用网页语言与程序语言开发，通过应用商店区分移动操作系统分发，用户需要安装使用的移动应用。
总体特性更接近NativeApp但是和WebApp区别较大。
只是因为同时使用了网页语言编码，所以开发成本和难度比NativeApp要小很多。
因此说，HybridApp兼具了NativeApp的所有优势，也兼具了WebApp使用HTML5跨平台开发低成本的优势。
HybridApp按网页语言与程序语言的混合，通常分为三种类型：
多View混合型，单View混合型，Web主体型。
1.2.1多View混合型
即NativeView和WebView独立展示，NativeView与WebView交替的场景出现。
这种应用混合逻辑相对简单。
即在需要的时候，将WebView当成一个独立的View（Activity）运行起来，在WebView内完成相关的展示操作。
这种移动应用主体通常是NativeApp，Web技术只是起到补充作用。
开发难度和NativeApp基本相当。
1.2.1.1主流框架
Native部分使用操作系统原生框架+JSBridge。
Web融合部分国内阿里系使用最广的框架WindVane+HybridAPI等〔后续章节详细介绍〕。
1.2.1.2优势
〔1〕、高效、扩展性强、支持多团队并行开发
〔2〕、衔接Android/iOS原生导航交互，完美的用户体验
〔3〕、业务实现更灵活，复杂业务可通过Native实现，频繁变化或简单业务通过Web实现，更好的满足移动端业务多样性、快速迭代要求
〔4〕、轻量级的框架，框架侵入性弱，各个业务高度独立，第三方业务快速接入
〔5〕、使用JSBridge来实现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主体型
即移动应用的主体是WebView，主要以网页语言编写，穿插Native功能的HybridApp开发类型。
这种类型开发的移动应用体验相对而言存在缺陷，但整体开发难度大幅降低，并且基本可以实现跨平台。
Web主体型的移动应用用户体验的好坏，主要取决于底层中间件的交互与跨平台的能力。
国外的appMobi、PhoneGap和国内的WeX5、AppCan和Rexsee都属于Web主体型移动应用中间件。
其中Rexsee不支持跨平台开发。
appMobi和PhoneGap除基础的底层能力更多是通过插件〔Plugins〕扩展的机制实现Hybrid。
AppCan除了插件机制，还提供了大量的单View混合型的接口来完善和弥补Web主体型HybridApp体验差的问题，接近NativeApp的体验。
而WeX5则在揉合PhoneGap和Bootstrap等主流技术的基础上，对性能进一步做了深度优化，不但完全具备NativeApp对本地资源的调用能力，性能体验也不输原生；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还提供AdobeAIRApp以及在线的培训课程，帮助开发者了解原生API并在他们自己的平台上开发移动App。
4、Kinvey
Kinvey同样是一个为移动应用开发者提供后台创建服务的平台。
Kinvey强调加速移动应用开发与销售的“即取即用”理念。
Kinvey的中间层与数据层均托管在多个云服务提供商处，包括Rackspace、Amazon与Microsoft。
所有通过Kinvey存储的数据都会有四种方式备份：
AmazonEC2、WindowsAzure、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内，同时包括NativeView和WebView。
互相之间是覆盖（层叠）的关系。
这种HybridApp的开发成本较高，开发难度较大，但是体验较好。
如XX搜索为代表的单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.3WebApp
WebApp指采用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四种主要开发模式比照
WebApp
网页应用
HybridApp
Web主体型
HybridApp
多View混合型
NativeApp
原生应用
开发成本
低
中
Native部分成本高
Web部分成本低
高
维护更新
简单
简单
Native部分复杂
Web部分简单
复杂
体验
差
中
优
优
性能
慢
慢
较快
快
原生界面
模拟
模拟
部分模拟
原生
官方市场认可
不认可
认可
认可
认可
安装
不需要
需要
需要
需要
跨平台
优
优
Web部分跨平台优
差
App级别
轻量级
轻量级
超级App，支持App中嵌套MicroApp
重量级
适应性
一般
中，对复杂应用支持较差
优
一般
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、WindowsPhone四大智能操作系统.AppCan-SDK是AppCan平台专为开发者提供的IDE开发环境,集成了:
1、移动UI框架2、设备API3、调试模拟器4、离线打包服务5、应用云端管理使移动开发更加方便快捷.
与Phonegap支持单一webview使用div为单位开发移动应用不同。
AppCan支持多窗口机制，让开发者可以像最传统的网页开发一样，通过页面链接的方式灵活的开发移动应用。
基于这种机制，开发者可以开发出大型的移动应用，而不是只能开发简易类型的移动应用。
AppCan提供强大的设备调用能力，、短信、相机、LBS、传感器、数据库等常用的功能，开发者可以通过JS接口调用，轻松构建移动应用。
AppCan是Web占主体型Native为辅的开发框架。
2.1.2.2框架实现
HTML5：
支持HTML5开发，CSS3实现布局优化及交互提升
原生体验：
引入部分原生UI控件与交互支持〔如ActionSheet等〕
开发工具：
基于Eclipse的开发工具，集成UI控件与应用管理
模拟器：
提供给用全功能模拟器，方便开发调试
UI框架：
提供强大的UI框架，更加易于实现页面布局与交互
设备API：
支持各种设备调用，如、相机、传感器、定位等
本地打包：
无需配置环境，无需编译，本地一键打包
云端打包：
提供云端打包服务，提供更加个性化的选择
多窗口机制：
常见应用只支持单一窗口，多窗口可以有效提高交互体验
插件机制：
支持第三方原生插件，支持JS插件
支付支持：
相比国外中间件更具本土优势，NotPaypalbut'ZhiFuBao'
代码加密：
基于密钥的加密方式，无法破解，像混编一样保护html代码
统计分析：
应用分平台安装数统计，应用启动和使用情况统计
开放平台：
更具本土优势，已经对接Sina、QQ、XX等开放平台
技术支持：
技术支持及时响应，重视开发者建议和反馈
2.1.2.3架构图
生态结构：
移动端框架：
2.2跨平台原生应用
2.2.1BeeFramework
2.2.1.1简介
BeeFramework是一款iOS快速开发框架，允许开发者使用Objective-C和XML/CSS来进行iPhone和iPad开发，由GavinKwoe和QFish开发并维护。
其早期原型曾经被应用在QQ空间和QQ游戏大厅等多款精品APP中。
BeeFramework包含丰富的组件和工具。
BeeFramework解决了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.2NativeScript
2.2.2.1简介
一个开源的框架，可以使用JavaScript开发跨平台、真正原生的iOS,Android和Windows移动App。
开发人员使用NativeScript提供的库来构建应用UI，其抽象了各种原生平台之间的不同。
2.2.2.2框架实现
NativeScript运行时
NativeScript使用JavaScript虚拟机，在Android上采用GoogleV8JavaScript引擎，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函数调用的代码newandroid.text.format.Time（），V8会产生一个回调。
也就是说V8有一个回调，让NativeScript拦截函数调用，然后用自定义的C++代码执行一些动作，并返回一个新的结果。
在Android中的情况下，NativeScript运行的C++代码不能直接访问JavaAPI，如android.text.format.Time。
然而，Android的JNI，或Java本地接口，提供了C++和Java之间的桥接能力，所以NativeScript使用JNI完成转发。
在iOS中这个桥梁是不必要的，因为C++代码可以直接调用Objective-C的API。
2.2.2.3结构图
2.2.3ReactNative
2.2.3.1简介
ReactNative使你能够使用基于JavaScript和React一致的开发体验在本地平台上构建世界一流的应用程序体验。
ReactNative把重点放在所有开发人员关心的平台的开发效率上——开发者只需学习一种语言就能轻易为任何平台高效地编写代码。
Facebook在多个应用程序产品中使用了ReactNative，并将继续为ReactNative投资。
2.2.3.2框架实现
原生的iOS组件
可使用标准平台组件，比方iOS平台上的UITabBar和UINavigationController。
这可以让你的应用程序拥有和原生平台一致的外观和体验，并保持较高的品质。
使用相应的React组件，如iOS标签栏和iOS导航器，这些组件可以轻松并入你的应用程序中。
异步执行
JavaScript应用代码和原生平台之间所有的操作都是异步执行，并且原生模块也可以使用额外线程。
这意味着我们可以解码主线程图像，并将其在后台保存至磁盘，在不阻塞UI的情况下进行文本和布局的估量计算，等等。
因此，ReactNative应用程序的流畅度和响应性都非常好。
通信也是完全可序列化的，当运行完整的应用程序时，这允许我们使用ChromeDeveloperTools来调试JavaScript，或者在模拟器中，或者在真机上。
触摸处理
iOS有一个非常强大的系统称为ResponderChain，可以用来响应复杂视图层级中的事件，但是在Web中并没有类似功能的工具。
ReactNative可实现类似的响应系统并提供高水平的组件，比方TouchableHighlight，无需额外配置即可与滚动视图和其他元素适度整合。
弹性框和样式
布局视图应该是简单的，所以我们将Web平台上的弹性框模块引入了ReactNative。
弹性框可用来搭建最常用的UI布局，比方代用边缘和填充的堆叠和嵌入。
ReactNative还支持常见的Web样式，比方fontWeight和StyleSheet抽象，它们提供了一种优化机制来宣称你所有的样式和布局在组件中的应用是正确的，且组件把它们应用到了内网中。
Polyfills
ReactNative的重点是改变视图代码编写的方式。
接下来，我们注意网络中普遍的并把那些API放在适当的地方。
可以使用npm安装JavaScript库，这些库用于融入到ReactNative中的顶级功能，比方XMLHttpRequest，window.requestAnimationFrame及navigator.geolocation。
我们正在扩大可用的API，并致力于为开源社区做出奉献。
可扩展性
使用ReactNative无需编写一行原生代码即可创建出一款不错的应用程序，并且ReactNative可通过自定义原生视图和模块来进行扩展--也就是说你可以重用你已经构建的任何内容，并且可导入和使用你最喜欢的原生库。
为了在iOS中
升级会员 