Hybrid App的兴起是现阶段移动互联网产业的一种偶然。移动互联网的热潮刮起后，众多公司前赴后继的进入。但是很快发现移动应用的开发人员太少，所以导致疯狂的人才争夺。市场机制下移动应用开发人才的待遇扶摇直上，最终变成众多企业无法负担养一个具备跨平台开发能力的专业移动应用开发团队。而HTML5的出现让Web App露出曙光，HTML5开发移动应用的跨平台和廉价优势让众多想进入移动互联网领域的公司开始心动。可是当下基于HTML5的Web App更是雾里看花，在用户入口习惯、分发渠道和应用体验这三个核心问题没解决之前，Web App也很难得以爆发。正是在这样是机缘巧合下，基于HTML5低成本跨平台开发优势又兼具Native App特质的Hybrid App技术杀入混战，并且很快吸引了众人的目光。大幅的降低了移动应用的开发成本，可以通过现有应用商店模式发行，在用户桌面形成独立入口等等这些，让Hybrid App成为解决移动应用开发困境不错的选择，也成为现阶段Web App的代言人。Hybrid App像刺客一样，在Native App和Web App混战之时，偶然间的在移动应用开发领域占有了一席之地。

2.2. 如何实现网页语言与程序语言的混合编辑

Hybrid App通常分为三种类型：多View混合型，单View混合型，Web主体型。

2.2.1. 多View混合型

即Native View和Web View独立展示，交替出现。目前常见的Hybrid App是Native View与WebView交替的场景出现。这种应用混合逻辑相对简单。即在需要的时候，将WebView当成一个独立的View（Activity）运行起来，在WebView内完成相关的展示操作。这种移动应用主体通常是Native App，Web技术只是起到补充作用。开发难度和Native App基本相当。

2.2.2. 单View混合型

即在同一个View内，同时包括Native View和Web View。互相之间是覆盖（层叠）的关系。这种Hybrid App的开发成本较高，开发难度较大，但是体验较好。如百度搜索为代表的单View混合型移动应用，既可以实现充分的灵活性，又能实现较好的用户体验。

2.2.3. Web主体型

即移动应用的主体是Web View，主要以网页语言编写，穿插Native功能的Hybrid App开发类型。这种类型开发的移动应用体验相对而言存在缺陷，但整体开发难度大幅降低，并且基本可以实现跨平台。Web主体型的移动应用用户体验的好坏，主要取决于底层中间件的交互与跨平台的能力。国外的appMobi、PhoneGap国内的AppCan和Rexsee都属于Web主体型移动应用中间件。其中Rexsee不支持跨平台开发。appMobi和PhoneGap除基础的底层能力更多是通过插件（Plugins）扩展的机制实现Hybrid。而AppCan除了插件机制，还提供了大量的单View混合型的接口来完善和弥补Web主体型Hybrid App体验差的问题，接近Native App的体验。

从分析可见，Hybrid App中的Web主体型只要能够解决用户体验差的问题，就可以变成最佳Hybrid App解决方案类型。

2.3. Hybrid App的瓶颈与未来编辑

国内外Hybrid App的开发框架众多。如何选择又成为一个难题。下面对开发者比较关心的集中知名跨平台开发移动应用中间件进行列表和对比，以便选择最适合您的移动应用中间件。

PhoneGap是相对比较早进入公众视线的一种选择。但是，开发者简单的基于PhoneGap来开发移动应用肯定会发现结果和Web App比较差的用户体验类似。这也是为什么基于PhoneGap有实用性的移动应用主要集中在iOS上。可是PhoneGap这种现状弱化了HTML5的跨平台价值。

AppCan在技术架构上和PhoneGap类似是Web主体型中间件，但是通过结合了一些原生交互效果能够达到iOS、Android平台都比较一致的用户体验。但是相比PhoneGap的开源，AppCan相对封闭的路线显得过于谨慎。

Titanium是一种基于翻译机制的跨平台中间件，能够开发出具有Native体验的移动应用，但是因为翻译机制的限制导致移动应用开发不能像真正的HTML5开发一样灵活。哪怕一个按钮也不能像普通HTML一样来编写，而必须按照Titanium约定的特定格式。

Hybrid App这个领域虽然还处于比较初期的阶段，但是已经有很多优秀的公司和技术团队在致力于跨平台开发移动应用中间件技术的研究，给了开发者众多选择。开发者可以根据实际的项目需求来选择中间件。Web App虽被浏览器厂商和搜索引擎公司所推崇，但存在用户体验差、盈利模式不明确等现阶段无法解决的问题，或最终夭折。Hybrid App正在被越来越多的公司和开发者所认同，势必会成为新世界的王。

3. Web App、Hybrid App、Native APP对比

	Web App（网页应用）	Hybrid App（混合应用）	Native App（原生应用）
开发成本	低	中	高
维护更新	简单	简单	复杂
体验	差	优	优
Store或market认可	不认可	认可	认可
安装	不需要	需要	需要
跨平台	优	优	差

4. 实现方式activexFlash ，

ActiveX可以自己写

Flash Player ActiveX是Adobe写好了

要想功能不受限制当然是自己做ActiveX比较好.但是自己的又没有adobe的那么多功能函数包支持,所以很难两全其美啊. 结合使用吧.

除非使用AIR，自己操作文件和Socket才有可能支持，单纯运行在浏览器里的SWF，理论上是做不到的

...

我觉得应该还是Flash Player ActiveX的限制过多。很多的ActiveX的权限都比Flash Player要大。例如Yahoo相册的上传控件，就可以预览要上传的图片。而Flash Player就做不到。目前网上支持断点续传功能的上传组件基本上都是基于ActiveX（例如这个），它又是怎么做到的呢？

能跨平台的子有swf跟个applet兰....林吧还是applet吧...

5. applet，Js , html5

6. NPAPI是电脑上大部分非ie浏览器都支持的一种浏览器扩展，类似ie的activex技术。

如果你有一个模块需要支持所有浏览器，那么支持activex和npapi之后，基本上就全支持了。

npapi是写plugin的，而不是写extension的。它可以用于实现flash插件，但是不能用来实现adblock。

NPAPI大的部分要使用本地语言来实现,bgen ativex雅十能使用js走ok.. WinShell NPAPI插件走十dll...

Ff 扩展的话daosh秭使用xml,js走ok兰...

7. URL协议的方式(跨平台的)，我们将某种URL的协议注册给某个程序来进行处理，

比如将tencent://这样的协议注册给QQ程序来进行处理，当浏览器需要访问这样的协议的时候就转给QQ程序进行处理。这种URL协议的方式是可以跨平台的，比如在Windows上你需要添加注册表项

这个好使用..试达过..

REGEDIT4

[HKEY_CLASSES_ROOT\atihttp]

@="URL:atihttp Protocol"

"URL Protocol"=""

[HKEY_CLASSES_ROOT\atihttp\shell]

[HKEY_CLASSES_ROOT\atihttp\shell\open]

[HKEY_CLASSES_ROOT\atihttp\shell\open\command]

@="\"D:\\Windows\\System32\\notepad.exe\" \"%1\""

走十注册的时候儿360有提示了...

7.1. Registering the Application Handling the Custom URI Scheme

To register an application to handle a particular URI scheme, add a new key, along with the appropriate subkeys and values, to HKEY_CLASSES_ROOT. The root key must match the URI scheme that is being added. For instance, to add an "alert:" scheme, add an alert key to HKEY_CLASSES_ROOT, as follows:

HKEY_CLASSES_ROOT alert URL Protocol = ""

HKEY_CLASSES_ROOT alert (Default) = "URL:Alert Protocol" URL Protocol = "" DefaultIcon (Default) = "alert.exe,1" shell open command (Default) = "C:\Program Files\Alert\alert.exe" "%1"

7.2. Launching the Handler

By adding the above settings to the registry, navigating to URIs such as alert:Hello%20World would cause an attempt to launch alert.exe with the complete URI on the command line. Internet Explorer percent-decodes the URI, but the Windows Run... command does not. If a URI contains percent-encoded spaces, it may be split across more than one argument on the command line.

For example, if the link above is followed through Internet Explorer, the command line would be:

"C:\Program Files\Alert\alert.exe" "alert:Hello World"

7.3. 协议Handler存在检测处理

这样当你点这个图标的时候，就会呼出QQ程序，但是如果我根本没有安装程序呢？那么什么都不会出现。

所以我们需要在启动url协议之前，检测处理相应url协议的程序是否安装了，如果没有安装就跳到软件的下载页面或者软件的web版。

那么现在的问题就是如何检测本机是否已经安装了对应程序，和1中类似，在IE中我们可以通过ActiveX的方式来检测，但是在其他浏览器中我们无法进行，我们肯定需要浏览器和本地api进行交互，好在我们有NPAPI这个跨平台跨浏览器的标准接口，所以我们可以开发一个浏览器的插件，使用js和 npapi插件进行交互，npapi插件再调用本地api来检查程序是否安装(比如在windows中查看注册表，或者mac中查看系统是否有程序能够响应相应的URL)。然后js中根据判断的返回值来进行下一步操作。

PS：腾讯的QQ目前好像只支持IE上的URL启动，而没有通过NPAPI插件的方式解决跨浏览器的问题。

8. 二、插件检测

可以使用Javascript来检测一个插件是不是已经安装了，下面是测试代码：

function DetectFFPlugin()

{

    var mimetype = navigator.mimeTypes["application/mozilla-npgnet-scriptable-plugin"];

    if(mimetype)

    {

        var plugin = mimetype.enabledPlugin;

        if(plugin)

        {

            document.writeln("Plugin had been installed and be enabled.");

        }

    }

    else

    {

        document.writeln("Sorry, Plugin has NOT been installed.");

    }

}

嗯，看到这里，觉得这个检测很有用。当检测用户尚未安装时，可以指导用户到哪哪哪去下载安装（转向一个漂亮点儿的页面），当检测已经安装了，就动态加载插件代码。不错。：）

9. 参考

从URL启动程序：也谈谈旺旺的页面启动_战九SEO.htm

Registering an Application to a URI Scheme (Windows).htm

Firefox插件开发 Hello World！ - 蛋疼先生的手札 - ITeye技术网站.htm

【原创】我的Firefox插件开发之旅（5）——编译和测试第一个Plugin例子：npruntime - 我的玻璃盒子 - C++博客.htm

hybrid app_百度百科.htm

码农公寓

1. 关键字

2. hybrid App

2.1. Hybrid App为什么会兴起编辑