此文是我们团队内部选型时候我的一点笔记，主要是给同事看的，也许对大家有点帮助，没什么新东西，主要是整理人家的文章和内容为主。
移动 App 开发技术分类
Web App
- 成本低，快速开发
- 响应式设计
- 浏览器运行很多手机特性无法访问。例如联系人，推送等
- single page app
- 销售渠道限制于浏览器
Native App
- 学习成本高，开发成本高，开发效率低
- 不同平台一道坎
Hybrid App
Hybrid App 优点
- 兼具 Native App 良好用户体验的优势和 Web App 跨平台开发的优势
- 开发成本和难度比 Native App 小
- 使得开发和日常维护过程变得集中式、更简短、更经济高效
- 既可以通过 Native 分发渠道推广产品，也可同时在微信，百度轻，UC 等移动平台推广
现状
- 国外的 Facebook，App Store
- 国内的百度搜索，淘宝客户端 Android 版。其中百度封装的不是 WebView 而是自己的浏览内核，体验更像原生客户端，更高效。
Hybrid 含义
- mobile application: 就是一个移动应用
- both browser-supported language and computer language: 同时使用网页语言和程序语言编写
- avaiable through application distribution platforms: 通过应用商店进行分发
- a target device: 区分目标平台
- install to run: 用户需要安装使用
Hybrid 类型
- 多 View 混合型
- 单 View 混合型
- Web 主体型
多 View 混合型 (中)
即 Native View 和 Web View 独立展示，交替出现。例如我们第一版本的安卓 App。
单 View 混合型 (好)
即在同一个 View 内，同时包括 Native View 和 Web View。互相之间是覆盖（层叠）的关系。
这种 Hybrid App 的开发成本较高，开发难度较大，但是体验较好。
例如百度搜索为代表的单 View 混合型移动应用，既可以实现充分的灵活性，又能实现较好的用户体验。
Web 主体型 (差)
即移动应用的主体是 Web View，主要以网页语言编写，穿插 Native 功能的 Hybrid App 开发类型。
这种类型开发的移动应用体验相对而言存在缺陷，但整体开发难度大幅降低，并且基本可以实现跨平台。
Web 主体型的移动应用用户体验的好坏，主要取决于底层中间件的交互与跨平台的能力。
国外的 appMobi、PhoneGap 国内的 AppCan 和 Rexsee 都属于 Web 主体型移动应用中间件。其中 Rexsee 不支持跨平台开发。appMobi 和 PhoneGap 除基础的底层能力更多是通过插件（Plugins）扩展的机制实现 Hybrid。而 AppCan 除了插件机制，还提供了大量的单 View 混合型的接口来完善和弥补 Web 主体型 Hybrid App 体验差的问题，接近 Native App 的体验。
中间件
App 的 Native 代码部分使用操作系统的 API 来创建嵌入式 HTML 渲染引擎，该引擎在浏览器和设备的 API 之间充当了桥梁。这座桥梁让 Hybrid App 得以充分利用现代设备所提供的全部特性。
App 开发者可以选择编写自己的桥梁，或者充分利用现成的解决方案，比如 PhoneGap。
App 的 Web 部分可能是驻留在服务器上的网页，也可能是一组 HTML、JavaScript、CSS 和媒体文件，封装到 App 代码中，存储在设备本地。
- 放置在服务器上的 HTML 代码让开发者不必经历提交和批准过程——有些 App 商店要求这个过程，就可以对 App 进行小幅更新。遗憾的是，这个方法摈弃了任何离线可用性，因为设备与网络没有连接时，无法访问设备。
- 把 Web 代码封装到 App 里面可以提高性能和可访问性，但是不允许远程更新。
- 推荐的方案是：结合使用两者。这种系统采用的架构可以把 HTML 资源放置在 Web 服务器上，以获得灵活性，但是又把它们本地缓存在移动设备上，以获得高性能。
根据我们目前的技术实力和业务需求，内部时间人力资源预算，不建议使用中间件，以下是市面主流中间件的对比。
最后选择的架构
- Ember 用于双向绑定，网络请求，视图管理等工作
- Require.js JavaScript 模块化工具，能够帮助你把整体的代码管理的井井有条（这块还没决定好）
- 开发阶段使用 Haml + Sass + Coffee
- API server 使用 Ruby Rack + Grape + Puma
题外话
为毛不用 Angular，为毛不用 jade，为毛不用 BackBone，不用 jQuery Mobile，不用 PhoneGap。。。。
我也不知道为啥不用。可能都是命吧。另外朋友们提到的一些技术，例如 jade，我是确实不了解。可能在具体的开发中，如果发现特别合适的话，就会果断使用的。另外一些，比如 jQuery Mobile，PhoneGap 和 BackBone 确实是各有缺点，不适合我们目前的需求。并不是它们不好，我相信它们都有自己适用的地方。
后记
在用 Ember 开发了 2 周之后，发现确实可以满足我们目前阶段的需求。还在疑虑的同学，可以小范围的开始上了。
参考资源
延伸阅读
以前做了 3 年多手机跨平台的平台，编写方式类似于 android, 跨平台层由 mini java 来驱动，界面描述用 xml, 在 symbian,mobile 时代用着还挺不错。
不过现在手机平台做两个就差不多了，不管从体验，还是性能，都是原生的爽。说 Native App 开发效率低，在 oc,java 来说不会有多差呀。
Hybird app 不见得开发成本低。只是更适合 web 开发者罢了。而 web 开发者远比 iOS / Android 开发者多，所以你懂的……但这不代表随便找个懂点 jQuery 的就能干活。举个栗子，做一套 UI 能够适应 iPhone / iPad 和各种主流分辨率的 Android 机型就不是件容易的事情。
而且浏览器有浏览器的坑，不下于以前前端工程师考虑桌面浏览器兼容的情况。一些对 native app 开发者完全不是问题的东西到 hybird app 中就需要各种 hack……
- 比如 Mobile Safari 键盘一弹出所有 "position: fixed" 的元素就全变 absolute 了，目前来看官方也没有修复的迹象，但 Android 的 webkit 内核没问题。
- 比如 Android 4.0 键盘弹出会遮挡 UI，而且最下面被挡住的部分死活滚动不上去。但 Mobile Safari 无此问题。而且 Andorid 2.x 貌似也没这个问题。
- 比如两者都对 div/span 上的 click 和 touch 事件无任何响应，还好可以加 "cursor: pointer" 解决。
#8 楼 @darkbaby123 你可能搞混了 Hybird app 和 Web app 的区别。所谓的混用，就是原生和 Web 技术混在一起搞。这样在跨平台的部分可以很容易。我们目前的实际使用情况是，只在小部分地方使用嵌入 HTML，JS，CSS 的办法。把这些文件当做一个资源包，比如 App 内部的社区部分，我们就改用 Ember 来做了。不过 Hybird 真的不是那么简单的一个 WebView 显示 file://XXXX 就完事了。首先找到靠谱的浏览内核，然后一个 UI 中哪里是 HTML5 哪里是原生，都要规划好。
想搞的特别好的确是任重而道远，但是对于小团队还想吃多平台的情况，这是一条 合适我们团队 的道路。
只会 jQuery 的确不行，JavaScript 功底不能差，CSS3 不能不熟。至于响应式布局的 UI。。。我们还是花钱买吧，自己搞耽误不起时间。
#8 楼 @darkbaby123 你遇到的这几个坑我都遇到过。1 太严重了，3 的话，如果用 jQuery，往不是 document 或 body 的父元素上可以绑，如：
$('.father-element').on('click', 'selector', function() {});
另外一些坑：
- webview 里加载图片太多曝内存。想象很多 app 会有一个可以无限加载更多的大图列表...
- 滚动时无事件，动画会暂停。
- 样式各“浏览器”不兼容就不骂了。
@Victor 我的意思是不管 Web app 还是 Hybird app，只要有用到浏览器，都会碰到浏览器相关的问题，而往往那些问题对 Native app 来说不需要考虑的。所以不是简单写一套代码放在里面就高枕无忧了。
我是用的 PhoneGap + Ember.js 来做的，PhoneGap 除了打包，也就是负责一些浏览器无法做到的事情（跟设备进行交互）。所以我碰到的问题大多都是浏览器相关的。虽然一些组件也可以考虑用原生代码实现，然后做成 PhoneGap plugin，但那样而言就失去了“Write once, run everywhere”的便利性了。当然 web 和 native 的比重这个涉及到很多方面的权衡，各人有各人的选择。
@ashchan 曝内存的问题我还没遇到，不过确实很多人抱怨过。不过我碰到过一个很长的 list 会导致 app 变慢，暂时解决方法是把滚动到区域外的 item 取消掉，用相同高度的空白 div 代替。滚动时无事件是什么问题？可以说说么？
#11 楼 @darkbaby123 长列表的问题，一般也采取把 off screen 的图片去掉的方法（如把 src 设成一张小图片）。但好像已经不管用了。
滚动的问题，native 的 scrollbar 在滚动时会不断发事件。在 iOS webview 里，只有在完全停止后才会发事件。另外，滚动时页面上的 gif 动画或 css animation 多会暂停。
#11 楼 @darkbaby123 Native app 当然好。但是我们开发人员有限，又想快速吃掉 iOS，移动 Web(百度轻和 UE，以及其他某某移动浏览器)。使用 Native app 我们每次迭代的周期太长了。往往是主力版本都更新好几次了，其他版本都跟不上速度。
所以部分地方使用 HTML5 来搞，可以直接把这部分移植到其他版本尤其是百度轻，UC 那些地方。
移动设备上的现有应用都没办法直接被搜索引擎索引，所以推广成本就非常高，需要自己开发，然后找各个 store，以及到处贴二维码，下载链接来推广 app。
这个本身是有问题： app 只是一种业务承载的方式，不能因为 apple 或者 google 的利益驱动，就让大家都去往这个上面靠。最后金钱，精力都消耗进去了，收获甚微，可是不做又不行，因为对手在做。在恐惧和贪婪的驱动下，我们不断去做 app。
如果 Hybrid 的 Native 部分是 google 或者百度来做，然后其中的 Html5 是开发商来做，这样用户通过搜索就可以发现商家的产品，并进行消费了。这个成本就会迅速降低下来，而搜索也收获了有价值的流量。
现阶段，搜索达不到产业要求，那么独立 Hybrid 做的产品，是不是 Html5 的部分本身就应该能被访问或者搜索，用户在搜索引擎里面检索到 Html5 页面，其中关键功能使用的时候引导下载 app 呢？这就是百度轻应用目前在做的事情