写了几个 APP，最初是打算用纯 Native 的，可是我自身的 Android、IOS 知识并不能支撑我用纯 Native 构建项目，可项目又迫在眉睫。还好有前辈指点了一下，可以采用 Hybrid APP（混合开发），一路磕磕绊绊的完成了项目。看了不少资料，从菜鸟的角度来总结下 Hybrid APP（混合开发）
概述
Hybrid App（混合模式移动应用）是指介于 Web App（套壳）、Native App（原生）这两者之间的 app ，兼具“ Native App 良好用户交互体验的优势 ”和“ Web App 跨平台开发的优势 ”。
也就是说，Hybrid App 是运用既包含类似移动端浏览器打开网站的相关技术，又包含原生应用调取底层接口（摄像头、传感器等等）的相关技术开发出来的应用。
分类
依照 HTML 代码的占比可以对 Hybrid App 进行划分。
80% ~ 100%
这个方案的主要工作量在于写一个兼容性好的H5页面，包括分辨率、性能、浏览器支持等问题。如果对于分别多平台（不光iOS、Android，可能还有移动网页版和微信公众平台）做Native应用来说，肯定总成本是低的。
选择这个方案的好处是如果能一套H5代码搞定多平台的话相当省时省力。如果H5代码写的好的话，其实在主流机型上的适配和体验也都过得去。
这个方案的缺点也很明显，在低配机上性能很差，如果H5代码写的不好，兼容性问题一堆，功能、安全性也受到很大的限制。
但随着Native APP开发的成本逐年提高，预算有限情况下，选择这种方式做开发的公司也是有的。当然，还有种情况是本来公司做APP只是为了交差，成本越低越好，这和十年前每个单位基本都必须有一个网站，结果诞生了无数奇葩网站的情况一样。
40% ~ 80%
应用中包含了Native代码，并且实现了部分H5体验不好、或者难以实现的逻辑（比如定位、埋点、本地持久存储、体感等）。有些情况下，程序的底层框架、核心逻辑、界面框架也会用Native来完成，H5只用来实现业务逻辑，H5代码占比在40%~80%左右。
制作这样的APP，一般会用到一个Hybrid框架来做bridge，同时也不用自己去做JSApi。市面上的框架实在太多，主流的几个上面也提到了，wex5、bootstrap和cordova等。我也不想花时间去比较各自的好坏，因为这类文章网上已经很多了，而且框架变化太快，值得注意的是在选择开源库的时候，要选一个社区活跃、更新比较及时比较好。剩下的需要Native实现的业务逻辑、tab+navigation界面等，自己稍微做一下就行了。
这个方案的好处是比较兼顾开发成本、跨平台和体验。如果业务的H5代码使用在线地址的话，其实就可以做到很大程度的内容动态化。再深入一点的话，在本地缓存一下JS和Resource，甚至做一个差量更新系统，其实流量也不会太厉害。
这个方案的局限性还是在于用户体验和性能，在低端机型上，H5的性能不是一个好的框架可以弥补的。同时，开发时间来说，这样的方式比起全Native优势不大，主要的好处在于做到最简单的动态化而非成本。
大量的传统行业+外包开发的APP采用的是这样的模式，比如人人都会用到的手机银行。这样的模式比较适合业务比较稳定、同时容易抽象的系统，对于乙方来说，比较能够复用已有的技术方案，对于甲方来说，对体验、交互创新没太多需求，业务结构稳定，但单个业务变化很快，使用这样的方式，其实是很适合的。
20% ~ 40%
这类实现方式，和上一类的区别在于，它针对不同的业务场景使用了不同的技术方案。如果是业务复杂、用户使用频繁、体验要求高的业务模块，就使用Native开发；如果是用户较少，体验要求不高，但变化频繁的业务模块，使用H5进行开发。
这种编码方式其实能玩出很多花活，比如资源足够情况下可以对某些模块即做Native也做H5版本，通过服务端下发Router指定打开哪一个，这样一方面可以做A/B testing，另一方面也可以在Native代码出错时做failback。
至于劣势么，主要在于整个APP的复杂性，和对于多类型业务模块的兼容、信息传递等。开发成本在这个时候，甚至已经大于纯Native应用了。
业内很多大型APP使用的都是这种方式，比如Ctrip，Alipay等。
0% ~ 20%
第四类应用理论上讲已经不太能归类到Hybrid开发的范畴了。这类应用使用了页面动态化框架，可以让Native通过执行动态化的脚本（可以本地也可以下发），但渲染出Native的界面和逻辑。最出名的框架就是Facebook的React Native了，当然，每个大厂都会有自己造的轮子，比如阿里系的Weex，但影响力比起RN都小了一点…
这类技术方案是现在移动客户端的技术热点之一，很多高级工程师和专家级别的从业人士都花了大量的时间使用、改进、设计这样的方案来兼顾性能、开发成本和动态化，从今天看来，还没有一个很完美的解决方案。
使用（或者说试水）这样方式做开发的厂商已经很多很多了，这里就不举例了。
优点
- 门槛低。只要了解前端三大件，就可以进行开发，不需要掌握 Android、IOS 相关知识。像我在开发中使用的 MUI 框架，再加上与其搭配的 Hbuilder IDE，对 Hybrid App 开发的新手绝对是一个福音。
- 速度快。如果应用中 HTML、CSS、JS 代码占比极大，那么，写应用界面就和写网页没区别，速度极快。
- 跨平台。一套代码搞定多平台，不用为了多个平台而准备多套代码。当然，适配及体验是肯定不如 Native ，但代码写的好的话，其实在主流机型上的适配和体验也都不错。
缺点
- 拓展难。这就意味着到后期，整个APP的复杂性，和对于多类型业务模块的兼容、信息传递等。开发成本在这个时候，甚至已经大于纯Native应用了。
- 体验差。Hybrid App 始终不是 Native App 。就目前的技术而言，Hybrid App 在适配、体验及底层调用仍然赶不上 Native App 。大部分 Native App ，其实还是非常依赖底层的，而且包括界面的东西，都是使用原生的API，效率就当然要比 Hybrid App 要好。
总结
综上所述，如果想以低成本，并且对 APP 的要求不高的话， Hybrid App 是一个很好的选择。