1、手机App的三类开发技术
按照开发技术，手机App 可以分成三大类。
- 原生应用（native application，简称 native App）
- Web 应用（web application，简称 Web App）
- 混合应用（hybrid application，简称 hybrid App）
这三类 App 的技术模型都不一样，各有优缺点。企业一般会选择其中一种作为主要技术栈，构建自己的手机 App。
H5 这个词，可以理解成就是混合 App 模型，只不过它特指混合 App 的前端部分。 因为混合 App 的前端就是 HTML5 网页，所以简称 H5。
2、原生应用 native App
2.1 native App概念
原生 App 是专门为特定手机平台开发的应用程序 ，无法在其他平台运行。一个手机软件如果要同时支持苹果手机和安卓手机，就需要为它们各写一个原生 App。
原生 App 使用与手机操作系统相同的语言。iOS 的原生 App 使用 Objective-C 语言或 Swift 语言，安卓使用 Java 语言或 Kotlin 语言。由于跟底层系统的语言和技术模型一致，所以原生 App 的性能和用户体验都很好。
2.2 native App优点
原生 App 的优点主要是两个：（1）较好的性能和体验；（2）可以使用系统的所有硬件和软件 API，比如 GPS、摄像头、麦克风、加速计、通知推送等等，能充分发挥系统的潜力。
2.3 native App缺点
原生 App 的缺点主要是成本，每个手机平台都要建立一个独立的开发团队，如iOS 和安卓两个开发团队。
第二个缺点是，原生 App 使用底层操作系统的语言，都是很重的编译型语言，开发和调试成本相对较高，时间周期长。
第三个缺点是，原生 App 必须下载安装才能使用，只要升级版本，就必须重新下载安装。用户往往不愿意更新版本，厂商被迫不得不长期支持很久以前的旧版本。
3、Web 应用Web App
3.1 Web App概念
Web App 是使用网页做的应用程序，必须在浏览器中使用。 比如，你在浏览器中收发邮件，就是在使用 Web App。
Web App 主要使用网页技术，即 HTML、JavaScript 和 CSS。2008年，w3c 组织发布了 HTML 第5版，简称 HTML 5，该版本大大增强了网页的功能，使得网页可以当作应用程序使用，而不仅仅是展示文字和图片，这就是 Web App 的由来。
3.2 Web App优点和缺点
Web App 的优点是：（1）不需要下载安装，打开浏览器就能使用，而且总是使用最新版本；（2）对于开发者来说，Web App 写起来比较快，调试容易，不需要应用商店的批准就能发布。
Web App 的主要缺点有两个。首先，浏览器提供的 API（即 Web API）很有限（目前只有相机、GPS、电池等少数几个），大部分系统硬件都不能通过网页访问，也无法直接读取硬盘文件，所以 Web App 无法充分利用平台的硬件。
第二个缺点是，网页通过浏览器渲染，性能不如原生 App，不适合做性能要求较高的页面。
3.3 Web App 的劣势
Web App 需要打开浏览器才能使用，这意味着，用户必须记住如何导航到它，要么直接输入网址，要么翻找书签。这使得进入 Web App，远不如原生 App 方便。这点很致命，事实表明，用户偏好原生 App。
- 不能从手机的首屏直接进入。
- 缺乏手机状态栏和锁屏时的通知推送能力。
- 不支持脱机访问（即断网也能使用）
3.4 渐进式 Web App技术
Chrome 团队开发了渐进式 Web App（Progressive Web App，缩写 PWA）。
可以把网站缓存在手机里面，供离线时使用，还能在手机首屏生成图标，直接点击进入，并且有通知推送能力，也不带有浏览器的地址栏和状态栏，跟原生 App 的使用体验非常接近
4、混合应用hybrid App
4.1 hybrid App概念
混合 App （hybrid App）顾名思义就是原生 App 与 Web App 的结合。它的壳是原生 App，但是里面放的是网页。 可以理解成，混合 App 里面隐藏了一个浏览器，用户看到的实际上是这个隐藏浏览器渲染出来的网页。
混合 App 的原生外壳称为"容器"，内部隐藏的浏览器，通常使用系统提供的网页渲染控件（即 WebView 控件），也可以自己内置一个浏览器内核。结构上，混合 App 从上到下分成三层：HTML5 网页层、网页引擎层（本质上是一个隔离的浏览器实例）、容器层。
4.2 API Bridge
不同于普通网页，混合 App 里面的网页，可以调用底层系统所有的 API。奥秘就在于外层容器提供了 API Bridge，充当底层 API 的中介，允许内部的网页调用底层。
所谓 API Bridge 就是容器在底层接口和网页之间，建立一座桥梁，让双方通信。容器一旦接到网页的请求，就根据请求去调用底层系统的 API，然后再返回结果给网页。API Bridge 往往以 JavaScript 语言提供，方便网页调用，这时又称为 JSbridge。
不同容器的 API Bridge 是不一样的。为某个容器写的网页，不能放在另一个容器使用，也无法在浏览器使用，除非网页脚本做了兼容处理。
容器提供的 API Bridge 必须跟着平台更新。比如，iOS 发了新版本，有了新的硬件 API，容器也必须跟着推出新版的 API Bridge。如果容器没有跟上，开发者为了使用新的硬件，就只能想办法自己来写缺失的 API Bridge。
4.3 hybrid App优点
混合 App 同时具有原生 App 和 Web App的优点，又可以避免它们的一些缺点。
（1）跨平台
Web 技术是跨平台的，开发者只写一次页面，就能支持多个平台。也就是说，混合 App 只需要一个团队就够了，开发成本较低。
（2）灵活性
混合 App 的灵活性大，很容易集成多种功能。一方面，混合 App 很容易加载外部的 H5 页面，实现 App 的插件结构；另一方面，Web 页面可以方便地调用外部的 Web 服务。
（3）开发方便
Web 页面的调试和构建，远比原生控件简单省时。页面的更新也容易，只要在服务器上发布新版本，触发容器内更新就可以了。
4.4 hybrid App缺点
混合 App 的主要缺点是，由于存在网页引擎的中间层，所以性能比较欠缺，不仅不如原生 App，而且由于 WebView 不是全功能浏览器，可能比 Web App 都要慢一些。
另一个缺点是，由于页面跨平台，就无法使用只有特定平台提供的功能，导致体验不如纯的原生 App。
4.5 微信小程序——针对微信容器的 H5 开发
所谓小程序，可以看作是针对特定容器的 H5 开发。微信本身是一个容器，开放自己的接口（JSbridge），外部开发者使用规定的语法，编写页面，容器可以动态加载这些页面。
小程序对于外部开发者的好处是，有了流量入口，可以直接调用微信的各种功能（比如支付）
5、hybrid App混合开发的相关方法
5.1 Android
5.1.1 提供给web端调用的方法：
--fnname:方法名
web端通过 window.AndroidJSBridge.fnName('xxxx') 调用
window.AndroidJSBridge.XX为固定写法，后面加方法名，参数类型为字符串，传入对象时，要转一下JSON.strinify
var result = window.AndroidJSBridge.fnName('xxxx');
log(result);
5.1.2 web提供给native的方法
方法必须绑定在window对象下
window.fnName = function (str) {
return 'web提供给native的方法';
}
5.2 IOS
5.2.1 提供给web端调用的方法：
固定写法 window.webkit.messageHandlers.xxx.postMessage({...})
window.webkit.messageHandlers.fnName.postMessage({
msg: str
});
5.2.2 web提供给native的方法
方法必须绑定在window对象下
window.fnName = function (str) {
return 'web提供给native的方法';
}
