【引言】近年来随着移动设备类型的变多，操作系统的变多，用户需求的增加，对于每个项目启动前，大家都会考虑到的成本，团队成员，技术成熟度，时间，项目需求等一堆的因素。因此，开发 App 的方案已经变得越来越多了。曾经有一段 HTML5 的小浪潮，无数的人参与或者看到过一个讨论：原生开发还是混合开发，又或者是 Web 开发？到底最佳实践是怎样的，笔者认为只有实践过的人才会知道。尤其是在这个充满各种变数的移动互联网时代。
【摘要】笔者将从Hybrid App的开发现状出发，阐述Hybrid App的优缺点，同时对比Hybrid App与Native App的各自特性，最后探讨一下Hybrid App**** 的新思想方向。
Hybrid App 现状分析
Web App
毫无疑问 Web App 就是成本最低，最快速地解决方案了。尤其是近两年非常流行的响应式设计，Web App 市场提供了非常好的实践场地。最近典型的 Web App 最佳案例是 Sun 天气应用了，其细节处理让人赞不绝口。
一般来说，拥有下面特点的就是一个 Web App 了：使用浏览器运行；纯 Web 前端架构，很多重要手机特性无法访问，例如联系人以及 Push notification 之类的；Single Page App；销售渠道多限于浏览器。
Hybrid App
所谓的 Hybrid App 其实会有不同的分支。而且会和 Native 应用有重合的地方。下面就说三种不同的解决方案。
方案一：使用 PhoneGap 、 AppCan 之类的中间件，以 WebView 作为用户界面层，以 Javascript 作为基本逻辑，以及和中间件通讯，再由中间件访问底层 API 的方式，进行应用开发。这种架构一般会非常依赖 WebView 层的性能。
方案二：使用 Adobe Air、RubyMotion、Appcelerator 或者是 Xamarin 这种非官方语言的工具，打包成原生应用的方式开发。为什么笔者会将它们定义为 Hybrid App，主要是它们并没有很单纯地使用原生提供的语言进行开发，而是通过对开发者提供友好的开发工具，并折中地把这种开发语言转换成原生语言，最终打包出整个应用，所以也属于混合应用范畴。
方案三：在开发原生应用的基础上，嵌入 WebView 但是整体的架构使用原生应用提供，一般这样的开发由 Native 开发人员和 Web 前端开发人员组成。Native 开发人员会写好基本的架构以及 API 让 Web 开发人员开发界面以及大部分的渲染。保证到交互设计，以及开发都有一个比较折中的效果出来，优化得好也会有很棒的效果。（当年 Facebook Three20 就使用该方案）
因此，Hybrid App 有以下的特性：
- 开发时可能不采用或者大部分不采用原生语言，但是却有所有原生应用的特性；
- 架构方案会和原生有出入，基本由工具而定；
- 具有跨平台特性；
- 一般开发相对原生开发的方式要简单。
Native App
Native App 毫无疑问是最可靠的方案。但是学习成本，人才成本，开发效率以及照顾不同平台的特性去考虑，都成为了开发人员心目中的一道坎。至于说这道坎是不可逾越的还是一道让你提高的坎，笔者觉得完全取决于你自己。基于种种因素的考虑，估计很多人就会选择折中的方案到了 Hybrid App 的开发行列当中，包括笔者自己也是这样过来的。
下面更多的内容都将围绕 Hybrid App 开发展开讨论。
Hybrid App 在开发当中的优点和缺点
在 Hybrid App 的开发过程中，几种不同的方案笔者都有经历过。当然也经历到了 Native App 的开发阶段。在如此纠结复杂的过程中给了笔者不少的经验，下面笔者也会就自身的经验和大家分享这些方案当中的优缺点。对于初入行的朋友，笔者是从 Web 前端入行的，毕竟门槛较低，而且能够快速地培养自己的信心以及对代码的感觉。深入后就开始接触到移动开发这块了。所以会先从 Hybrid App 的第一种方案说起吧。
方案一（Web 架构为重）
优点：
- 全 Web 开发，一定程度上有利于 Web 前端技术人员快速地构建页面样式；
- 有利于在不同的平台上面展示同一个交互层；
- 便于调试，开发的时候可以通过浏览器的方式进行调试，工具丰富。
缺点:
- 虽然说你可以专注在界面以及交互开发上了，但是这页会成为一个缺点，比如说要仿造一个 iOS 的默认设置界面，就需要大量的 html 以及 css 代码了，而且效果不一定和 iPhone 上面的界面一样好；
- 正因为这是跨平台的开发，所以还是这句话：兼容是前端的痛。了解过在 Android 机器上面的 Web 开发就知道这个痛了。比如前些年在 Android 设备上面写圆角，border-radius:10px，在 Android 的设备上面会出现毛边。
- 便于调试其实是在 Web 界面层的。但是实际上做 Hybrid App 开发的时候，你会遇到需求，进入手机的底层请求，做某些处理。比如说如果该应用有 Push Notification 服务的话，你就需要到底层，获取 Push Notification 发生时的数据，以及做相应的交互处理。当然类似 PhoneGap 这类框架，已经有很好的插件机制去帮助你解决类似的问题，当然还有 Game Center 之类的插件，具体的话可以到 Github 去关注 PhoneGap 官方的账户，资源非常丰富；
方案二（编译转换方式）
优点：
- 利用自己熟悉的语言，进行应用开发，比如 RubyMotion，就是使用 Ruby 语言去做 iOS 开发，开发起来的话，代码量是数量级地下降啊。
- 部分开发工具提供跨平台的功能，让你的应用能够快速地发布到不同的平台上面。比如 Mono 社区的 Xamarin，就是典型的例子了。使用 C#语言，能够把你的应用发布到 iOS，Android 以及 WinPhone 市场上面；
- 开发出来的程序运行高效。大部分这种架构的应用，其实还是非常依赖底层的东西的，而且包括界面的东西，都是使用原生的 API，效率就当然要比类似于 PhoneGap 这种架构要好了；
缺点：
严重依赖于其工具厂商提供的工具包，调试的时候就要有全套的工具。当然一般来说这些厂商都会以收费的形式发布他们的工具，相应的也有客服提供技术支持。遇到系统升级，第三方 sdk 升级，开发工具出现 bug 等，那么就要等待工具厂商解决了。相当于把风险压在对方身上了，自己却要承担责任。
方案三（Native 架构为重）
优点：
- 这无疑是最稳定的 Hybrid App 开发方式了，交互层的效率上由 Native 的东西解决了，而且架构上基本就是在 App 内写网页，连 App Store 都是采用了该种方案；
- 开发时分工非常明确，底层的由 iOS 开发人员处理，上层的由 Web 前端开发人员处理；
- 有效的在线参数配置方式，以便于及时在线替换界面；
缺点：
- 团队至少需要两个工程师，一个是 Web 的，一个是 iOS 的。当然如果开发人员会两种技术也可独立承担；
- 还是运行效率，要权衡好多少界面采用 Web 来渲染，毕竟 WebView 的效率会相对降低，以前 Facebook 就是因为 Web 的渲染效率低下，把整个应用改为原生的解决方案。当然这里面可以通过优化来解决。但是优化也是有限度的，如 Ruby 创始人 Matz 所说优化要恰当（包括花的时间，技巧等），而且有时候的优化达到的回报率不一定达到你自己的期望。
Hybrid App 和 Native App 开发对比
因为方案三中的思想基本上就是原生应用的开发思想了。这里要做的对比应该不算大，因此笔者不会做太多的阐述介绍两者的不同。但是如果是偏重 Web 架构的，或者是以方案二这种透过特殊工具开发的，就和原生开发有对比了。这次笔者暂时会以方案一拿来讨论。讨论中主要会以架构，代码管理上来讨论，当然也会说到部分细节。
架构讨论：
因为这是偏重于 Web 开发的应用，这里面就需要开发人员有很强烈的大型 Web 前端架构思想在里面。提到这里可能马上浮现在你脑海中的词语就是：angular.js，require.js，sea.js，backbone.js 等。没错，这些工具都能够帮助你快速地梳理好思路，管理好你的 Web 应用。对开发者最友好的，发挥空间最大的非 PhoneGap 莫属了。所以笔者就会以 PhoneGap 应用展开讨论。（因为类似 Sencha 也有提供方案，但是 Sencha 本身是一个重量级的框架，而且有自己的思想在里头，加上他本身也提供开发工具，在这里就不适合讨论了。对于开发者来说可以根据自己的需求选择好工具）
从工具上看：
用于双向绑定，网络请求，视图管理等工作。
javascript 模块化工具，在使用较多的交互对象，PhoneGap 插件的时候，你就会发现一个强大的模块化工具会在开发的时候提供极好的帮助。能够帮助你把整体的代码，管理得井井有条。
模板引擎。笔者个人比较推荐使用 Jade，而且笔者本人也在博客中多次写到 Jade 在不同场景下使用的技巧的有关文章。主要是 jade 的语法太简洁了，而且面向 JS 开发人员非常友好。如果你还没有开始使用模板引擎，赶紧加入这个队列吧，你已经落后了。
如果你暂时还没有一个设计师，但是又急于构造一个应用出来。jquery mobile 就提供了多套不同风格的模板，供你使用，而且还含有不同的交互动画等。而且也是跨平台的。当然实际场景中，笔者觉得你会花很多时间在写 css 上面，因为设计总是天马行空的。当然你还有很多工具啦，例如 sass，以及 less.js 等。
PhoneGap.js 或者 Cordova.js
做 Phonegap 开发必须使用的代码库，用于和 PhoneGap 框架通讯。现在这个库已经改名了，是 Cordova。具体为什么改名，得问 Adobe 咯。
PhoneGap 的插件能够帮助你快速地抵达手机的其他 API 上面，直接使用 Javascript 来操控这些底层的 API。例如调用 Push Notification 的相应发生的事件。
从代码目录上面看混合应用中的 Web 层：
/js mainView.js settingView.js networkObject.js renderObject.js /lib /PhoneGapPlugins push-notification-plugin.js pickerView.js PhoneGap.js zepto.js jquerymobile.js iscroll.js angular.js jade.js /css /mainView listItemTemplate.css questionListTemplate.css /settingView /personView /layout navigationBar.css tabButton.css app.css /template /mainView listItemTemplate.txt questionListTemplate.txt /settingView /personView /layout navigationBarTemplate.txt tabButtonTemplate.txt index.html app.js require.js
从代码的目录上面看，就是经典的静态网页文件的目录，非常简单。下面就用一句话来说说整个应用的运作过程吧：
打开 PhoneGap 应用 -> 进入 index.html -> 运行 require.js -> 加载应用资源 -> app.js 控制整个应用 -> angular.js 进行事件绑定以及视图渲染 -> 视图渲染的时候会将数据和加载好的视图模板（template 目录下的代码）处理 -> 经过 jade 模板引擎 -> 渲染到相应的位置上
就是如此简单。
看完了简单的 PhoneGap 应用后，笔者们来看看简单 iOS 应用在开发时候的代码目录吧。思路上还是非常相似的。在这里面，笔者不会深入代码部分去讨论具体的实现以及细节上的东西。
demoApp /Resource navigationBar.png <a href="mailto:navigationBar@2x.png">navigationBar@2x.png</a> /demoApp AppDelegate.h AppDelegate.m /SettingViewController settingViewController.h settingViewController.m /MainViewController mainViewController.h mainViewController.m /Supporting Files demoApp-Info.plist InfoPlist.strings ... /plugin /AFNetworking AFHTTPClient.h AFHTTPClient.m AFHTTPRequestOperation.h AFHTTPRequestOperation.m ... /Frameworks CoreData.framework UIKit.framework /Products demoApp.app
Objective-C 是一种通用、高级、面向对象的编程语言。Objective-C 是承自 Smalltalk 的信息传递模型（message passing）。Objective-C 里，与其说对象互相调用方法，不如说对象之间互相传递信息更为精确。Objective-C 强调面对对象编程，且 Objective-C 中强制要求将类的（interface）与实现（implementation）分为两个部分。类的定义文件遵循 C 语言之惯例以 .h 为后缀，实现文件以 .m 为后缀。所以你会看到大量的类文件在里头，整个工程就是有不同的类构成的。（当然可能这么描述不太准确，但是便于大家理解）
这就和丰富的 Web 前端有很大区别了，在 Web 前端开发里有 HTML，CSS，JS 三剑客，必须要用好这三个东西才可以把整个应用才可构建出来。但是在 Native 应用中，就很单一了。你只需要把握好 Objective-C 就可以了。因此对于原生应用来说，开发时只要遵守好规范，即使是一个新手参与开发，也可以快速地上手，看懂代码。因为模式已经定好，大家使用同一套的 API。按着流程走就好了。当然学习 Objective-C 需要过程，但是对于拥有 C 语言，Java 语言经验的开发者来说，是非常简单的事情。
当然，原生开发的缺点也很明显了，就是满足不了你的跨平台需求。
从代码目录上面看，其实也基本上看到笔者为什么使用多种 JS 库以及框架的原因了。主要的目的就是为了构建一个可维护的，具有规范性的 Web 应用。因为本身 Javascript 这门语言非常灵活，100 个人可以具有 100 种风格，加上没有专门对于 Javascript 开设的课程，在过往都容易存在对这门语言的误解。基于种种的原因，就要约束好一个应用的代码风格，架构。此外，Javascript 本身没有类的概念，所以在 Javascript 的面向对象编程中：Javascript 的数据和成员封装很简单。没有类，完全是对象操作。这和 Objective-C 有很大不同。这个时候必须要有一种心态处理好整个 Web 应用：就是尽可能地抽象成对象，你的工作就是对象与对象之间存在交流。
另外有一些点是值得开发者注意的。对于原生应用来说，不管是 iOS 的，还是 Android 的，都会提供一套原生界面的库。以 Objective-C 为例子。如果笔者需要调用 Alert，笔者只需要编写：UIAlertView * alertView = [[UIAlertViewalloc]init];，就把这个 view 声明好了。再去执行相应的方法，就可以了。但是对于 Web 应用来说，就需要编写
，一堆的 css 代码和 html 代码去实现。当然你会询问笔者，直接写 alert() 不就可以了吗？要是真这么简单的话，建议你在 iOS 的 WebView 中编写一下 alert，实现：title 是提示，内容是：alert view，确定按钮的文字是：好的。你就知道 WebView 的限制在哪里了。
因此要完成 JS 在 Web App 开发当中的最佳实践，肯定要学习优秀的思想和实现方法了。在这篇文章里面，笔者们暂时先不去做这种深入的讨论。而是先把例子抛给大家，也许会在下一次讨论的时候，再详细深入以下这两个项目。
第一个是斯坦福的 iOS 开发公开课中的例子，使用 objective-c 实现，一个简单的卡牌游戏。这是经典的 mvc 开发了。项目地址如下： https://github.com/lbj96347/Stanford-W2013-CardGame ，如果您正在使用 Mac，那恭喜你，可以马上编译这个游戏进行测试以及代码浏览。
第二个是使用 JavaScript 编写的例子，实现同样的需求，做一个简单的卡牌游戏。但是使用的是 HTML+CSS+JS 开发。同样学习了继承以及 mvc 的思想。项目地址是： https://github.com/lbj96347/JSMatchismo ，再次恭喜你，不管使用什么电脑，都可以随时浏览代码以及运行该游戏。
Hybrid App 的新思想
这两年多以来，因为市场的不同，也出现了不一样的需求，各个技术都有了新的发展。对于 Hybrid App 来说，其实都有了一些新的解决方案。为了解决问题其实最终思想都会被还原成以下几个点上：
- 根据需求，选择工具；
- 用适当的工具做适当的事情，有针对性地解决问题；
- 世界是平衡的，对于开发者来说，做的有用功越多，用户体验就越好，反之越差；
- 跨平台是一个"幌子"，什么都做得到不代表什么都做得好
这也是笔者体验最深的几个点。而且你会发现 Hybrid 技术也基本在跟随这几个点来走。
根据需求，选择工具
如果你使用过 Jquery Mobile，你做过过场动画（就是从一个 view 去到另一个 view），过场动画在 iOS 的 navigationController 中很常见，而且很简单，效果很好很流畅。在 Jquery Mobile 中使用 ajax，css 去实现了，核心代码可能就几十行。可能跟 iOS 里面的差不多（如果包含动画），但是实际出来的效果却差强人意。会出现类似的问题：页面抖动，感觉不连贯，在部分的设备下运行缓慢。如果你的应用要求的体验并不是很高，例如一些新闻展示类应用，更强调排版。这里小小的体验差距，就可以忽略了。（因为英国 BBC 就是这么干的），但是如果你的应用非常强调体验细节，这里的解决方案可能就不适合了。或许你要做优化，但是优化的时间可能足以够你去学习更多的东西了。这样的话，你是继续选择用一个不成熟的工具，还是选择去学习一种新的语言呢？所以还是根据需求而定吧。
另外一个例子。曾经有人跟笔者提及到，在使用 HTML 和 CSS 编写应用界面时确实很爽，但是效率不咋的。那为什么不尝试把应用内容直接搬到 Canvas 里面呢？构造一套足够强大的工具，一套足够彪悍的 UI 组件，把整个应用运行于 Canvas 中。这种想法是很好的，但是其实里面的短板页就出现了，Canvas 的性能虽高，但是里面的元素组件多了你可以保证效果高？所有的东西都会依赖于 JavaScript，这对于 Javascript 来说要构造足够强悍的面向对象的组件，也非简单之事，抛弃了 CSS 和 HTML，意味着内部的设计组件能够高度定制，松耦合做得非常好。完全是实现了一套新的 xcode 和 ui 库啊。这就不是在解决一两个问题了。既然有这么一个工具，笔者为什么不选择更好的，例如 Xamarin。
用适当的工具做适当的事情
做游戏的朋友估计就深有体会了。为了解决 Canvas 性能的问题，越来越多的人和应用厂商（尤其是浏览器厂商），提供一种解决方案就是希望将 Canvas API 和系统底层的 API 打通。意味着你只需要编写 Canvas 代码，实际做渲染的时候使用的是系统底层的东西，整体上提高了性能。例如 Ejecta http://impactjs.com/ejecta 这个东西。
对于开发人员来说用 Javascript 编写游戏逻辑以及做各种控制都非常舒服，而且因为用的 API 相同，放到 PC 上（放开性能问题），同样可以运行。这就真的做到了跨平台，但是又不缺乏效率。让笔者感触最深的就是 @大城小胖在做混合应用（做游戏）时的做法，小胖的游戏架构。JS 负责逻辑，引擎。JS Binding 绑定原生 OpenGL，让原生的来做复杂的渲染处理。HTML CSS 可以处理 UI（比如一些 Button）。这就是典型的：让工具去做其擅长的事情。
跨平台是一个"幌子"
为什么这么说？笔者不是一直希望大家能够跨平台么？是的。但是要真的认清这个坎。从 IE 兼容，到目前多个浏览器的乱战，到 iOS 以及 Android 设备 Web 上的兼容，这不就是一个历史的例子嘛。跨平台不是不好，只是在一个时代里，你能够达到怎样的效果，真的是很难估量的。就好比你出国旅游，如果两国关系非常好，而且很多惯例法律一致，对你来说不会造成太多负担。但是如果语言不一样，生活习惯什么的都不同，你就很难适应。同样是人，你很难在不同的环境下生存。真正的跨平台，就意味着大家求同。这绝对不是一两天的事情，也非简单的事情。
那为什么还要跨平台。业务需求嘛。在这里必须就要遵守根据需求选择工具，用适当的工具做适当的事情，根据实际情况来作开发。如果可以，笔者觉得很有必要都了解一遍，这样的话各种开发的思想就会影响到你，你就能够分辨到什么是好什么是坏，做更好的选择。例如笔者刚刚说到的过场动画的例子。其实完全可以使用笔者说的混合应用中，方案三，去解决这个问题。你无非就是希望用 navigationController 做一个漂亮的过场动画嘛，在 iOS 中几句代码就实现了。
再说一个例子吧，如果你正在做一个 todo-list 的应用，其实无非就是简单存储数据以及做一些相关界面渲染。在使用原生的控件的话，有大堆的代码要写，而且还要处理好内存问题。但是其实如果使用 Web 的方式实现，比如 backbone.js 。总体代码可能 100 行左右。就把整个应用实现了，包括本地存储。你要做的事情就是把整个界面搭建得漂亮些。可能就 1 个小时的工作。但是如果用原生开发，很难保证到一个小时内完成，因为调试编译都需要时间吧？况且还有界面呢。
所以要认清跨平台这个"幌子"，并非所有的问题都用同一个方法处理。笔者们要融汇贯通嘛！
总结和笔者的感受
对于做 Web App 的坑，其实挺多的。这里无法一一表达。但是相信实践过就会知道如何更好地绕过这些坑（例如笔者说的过场动画的例子）。那么对于开发者来说要有坚强的毅力，努力去实践，满足自己永远不能满足的好奇心，因为最终的经验会给你带来不一样的感受，stay hungry。同时笔者们必须保持一颗学习的心，不断地吸收有营养的思想，学习新的知识，不要太容易满足，stay foolish。每一种语言都会有其中的思想，每一种工具都有自己解决问题的方法论。多尝试就能够给自己带来更优秀的架构，更优秀的应用，提供给用户更好的体验。当然，也会有更好的回报。
关于作者
李秉骏（@CashLee 李秉骏），HTML5 技术活跃分子，HTML5 梦工场高级成员，投入 Web 开发多年。高中开始编写独立运营的电子商务网站。近年多进行移动应用前后端的开发，并尝试将混合应用开发技术运用于实践当中。
关注 IT 趋势，承载前沿、深入、有温度的内容。感兴趣的读者可以搜索 ID：laocuixiabian，或者扫描下方二维码加关注。
.jpg)
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 1 条评论