IOS-Hybrid（混合开发）

1.1.     APP三种开发模式

智能手机之普及不用多说，手机APP渗投到各个行业：电商（淘宝、京东等）、金融（各手机行业、P2P借贷等）、医疗（智慧医疗）、交通（滴滴、Uber等）、教育（慕课网等）、餐饮（饿了吗、美团等）……反正只要是个企业，无论规模大小，都已经订制或将要订制自己的APP。这么多APP无外乎就三种模式：Native App、Web App、Hybrid App。

1.1.1.     Native App

Native App，原生APP，使用原生（即Android或iOS）开发的APP。两年多以前这非常流行，到现在为止，原生开发人员数量众多，一抓一大票，技术成熟，好多培训机构都抱着老掉牙的API翻来覆去的讲——尤其是Android。Sorry，说错话了……使用原生开发有其优势：应用的性能好，适配起来相对容易。学习成本要看人，个人觉得技术点不多，门槛相对稍高，但入门后学习起来就很轻松——网络资料实在是太多了。

但原生APP最头疼的有三个问题：

1、无法跨平台：Android和iOS都需要开发各自平台的版本——开发成本高；

2、升级麻烦：每次升级都要下载安装包，Android还好，反正不需要审核，下载就下载吧，但iOS就麻烦了，发布每个版本还得经过App Store的审核，这导致第三个问题；

3、Android和iOS很难同步发布。

1.1.2.     Web App

所谓的Web App，就是把手机当做一个浏览器（Android使用WebView，iOS使用UIWebView），做几个页面挂在服务器端，类似于一个小网站。这样说虽然不太贴切，但实际上给人的感觉就是这样的。虽然开发成本大大降低，但页面访问速度慢、操作体验差。于是第三种模式诞生了。

1.1.3.     Hybrid App

乍一看和Web App没啥差别，但涉及到的技术成本、开发成本、学习成本比Web App高，它综合了Web App的开发速度和Native App的高性能体验。之所以说学习成本高，是因为开发高性能的Hybrid App有难度，网络资料少。我是两年半前开始接触混合模式开发的，当时如何做好屏幕适配、提高UI响应速度、如何最大化使用原生功能等内容，网络几乎没有资料。网上能搜索到的都是很粗略的东西，或者就是Hello World级别的东西，涉及到稍微细节一点的东西几乎没有。由于本系列文章都只讲Hybrid，故在此不再啰嗦了。

三种开发模式各自的特点如下面的表格所示：

	Native App	Hybrid App	Web App
原生功能体验	优秀	接近优秀	差
性能	非常快	快	慢
跨平台开发成本	昂贵	合理	便宜
碎片化适配	非常严重	严重	严重
编程技术支持	短缺	非常短缺	通用人才
版本升级维护	保守	低延时	开放
安全	强	中	弱

1.2.     Hybrid App所需技术

Hybrid App由于需要保证运行性能与开发速度，需要如下技术支持，本系列博文均会按照Demo的开发顺序依次描述本人的开发心得和教训，希望能起到一个抛砖引玉的作用。

1.2.1.     Native技术

Native技术主要用于提供原生支持，要做到跨平台，就需要掌握部分Android和iOS的知识，除了多线程，文件存储等基础知识，Android需要非常熟练的掌握WebView、WebSettings、WebChromeClient、WebClient四大对象。iOS需要非常熟练掌握UIWebView对象。

1.2.2.     Web技术

1、 HTML5

熟练掌握HTML5的各个标签，如何编写最优的文档结构。

2、 CSS

熟练掌握CSS2和CSS3的新特性，能按照效果图编写最高性能的样式。

使用SCSS生成CSS，将CSS可编程化。

3、 JavaScript

实现业务逻辑控制。个人理解JavaScript主要包含两大内容：DOM编程和面向对象编程。大部分JS开发人员就只掌握DOM编程，诸如document.getElementById()等，但面向对象是很重要的一个方面。

4、 性能和开发

模块化编程：编写可复用的组建；

CSS渲染：了解浏览器的CSS渲染引擎才能编写更高效率的样式；

JS解析：了解浏览器的JS解析引擎才能优化JS脚本；

HTTP协议：熟练掌握HTTP请求的各个内容；

AJAX：和服务器端的交互大都采用AJAX。

1.3.     流行框架

1.3.1.     Hybrid 框架

Cordova/PhoneGap：侧重于JS与原生的交互，开发简单，但性能差，如触摸时反应不灵敏。

AppCan：性能还行，使用简单，但要提交代码给AppCan的服务器才能打包，相信有追求的企业是不会把自己的代码提交给第三方，把打包权利交给第三方的。

Ionic Framework：在Cordova的基础上增加一些UI/JS方面的东西，样式还不错，但同样具有Cordova的不足。

1.3.2.     UI/JS框架

jQuery Mobile：上手简单，组件丰富，但性能超级差，闪屏现象严重。

Senche Touch：简单看过，没有使用过，貌似UI很漂亮，学习成本高。

React Native：FB推出的，当年FB是最早尝试Hybrid的，但性能超差，于是APP放弃了Hybrid，走原生的道路。在大家都不看好H5时，FB暗中深入挖掘H5，三年之后推出了这个框架，非常推荐各位去学习其中的思想。

GMU：百度推出的，这个不错。

1.3.3.     UI/JS库

这个就多了，jQuery、Zepto、Swiper、iScroll、RequireJS、AngularJS……

1.3.4.     个人建议

由于移动端是一个重视性能和用户体验的终端，大量采用框架存在一些问题：

1、 扩展、维护、定制成本，这个非常需要考虑，或许框架提供的UI风格和自己设计的UI风格差异大，导致设计围绕框架转，不符合产品的需求。

2、 既然是框架，强调的是覆盖面广度和功能的全面，会有很多无用的东西，带来累赘；

3、 框架本身存在BUG，或许需要开发人员面对一些能力之外的问题。

总之，如果只追求像山寨作坊一样快速产出、不计性能的开发产品，那使用现成的框架是不二选择。但如果追求性能和真正的产品，建议使用库，不要使用框架。但是很多框架的实现思想都很优秀，虽然不建议使用，但我们应该多接触学习其中的思想，才能写更好的代码。仅仅建议而已，不中听请忽略。

1.4.     系列大纲

本系列博文将按照我近三年来开发Hybrid App过程中的体会进行编写，以一个APP完整开发为线索，形成一套完整的混合模式开发的解决方案。

1、 JS和原生交互架构

2、 WEB端基础知识准备

3、 UI适配方案

4、 UI组件开发及封装

5、 JS模块化开发

6、 升级、部署方案

1.4.     混合开发分类‘

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

多View混合型

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

单View混合型

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

Web主体型

即移动应用的主体是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具备完全的跨端运行能力，可以无需任何修改直接运行在各种前端环境上。

 

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

多主体共存型（灵活型）

这是一种新型的开发模式，即支持Web主体型的应用，又支持以Native主体的应用，也支持两者混合的开发模式。比如kerkee框架[2]  ，它具有跨平台、用户体验好、性能高、扩展性好、灵活性强、易维护、规范化、具有Debug环境、彻底解决跨域问题等特点。用户体验与Native App媲美。功能方面，开发者可随意扩展接口。