写在前面的话

2017年12月18日更新
Hybrid App系列文章已经清空，正在整理一个全新的系列，待续...

2017年2月19日更新
补上最近重新整理的Hybrid App系列文章。里面包含JSbridge原理介绍以及一个完整的JSbridge源码项目示例。

一些相关常识

文中的Html5+是市面上一种比较流行的Hybrid开发方案，通过这套方案，可以用HTML,JS和CSS写出一个完整的原生APP，并且性能与原生相比较接近。

久久未能出炉的经验总结

从16年8月下旬开始，就渐渐的远离Dcloud的Html5+开发了(因为当初工作原因，在公司弄了一套自己的混合开发方案)。

原计划是在10月份左右就先总结一下Html5+一年多来的开发经验，避免留下遗憾。但是却由于种种原因，一直拖延，知道现在...

当初给自己找点借口是没时间，以后再写。现在回想来，这个借口确实有点着急，试想我有时间学口琴，吉它，英语，日语，为何会没时间来写一篇总结博文？也许仅仅是我内心对它不重视而已。

正常来说，随着时间的流逝，这个念头或许就消逝了，到最后也不会出炉一篇感想。但此刻的我要终结这个现象，我要立刻马上写一篇总结，以此铭记消逝在这上面的时间。

这无关信仰，仅仅因为我想要有始有终

我经历的Html5+开发

第一弹:初识Html5+开发

于2015年9月份，在第一份工作时，身为Android原生开发的我由于公司需求，初次接触了Dcloud公司的Html5+开发模式。

第一次接触Html5+开发模式，确实被惊艳了。那时仅局限在Android原生世界中的我知道了原来JS可以也写出原生APP。同时也被Hbuild这款IDE深深吸引了，觉得它功能特别强大。于是这时候便开始迫不及待的学习起来Html5+开发。

第二弹:磕磕碰碰完成第一个项目，踏入前端大门

当然，此时我面临着一些阻碍:

• 没有H5基础，JS和CSS尚未入门
• 没有前辈指导，孤军一人，万事靠搜索
• Html5+的新人手册有点不足

当然，对于一个合格的程序员来说，良好的学习能力是必备的，所有这都不是问题，因此从0自学，大概1个月后，磕磕碰碰的开发出了项目的初版。

初版的项目虽然能正常运行，但是代码惨不忍睹，于是之后在完善项目功能的同时又对整个项目进行了多次重构。

最终，在11月份左右时，项目的终版也出来了，整个项目经历了3次大重构，无数次小需求修改。部分功能截图如下:

统计下来:

• 整个项目主体功能开发历时3个月左右(9,10,11)
• 整个项目包括两个版本社工端和居民端，其中社工端页面数110左右，居民端页面数60左右(项目算较大了)
• 项目包含的功能基本涵盖h5+ api大部分内容，包括IO操作等等，甚至其中的CA证书功能，还包括了Native.js和原生通信。
• 项目的开发人员 是两个 没有任何JS和CSS经验的Android原生人员 + 1和页面重构人员(没有CSS经验只能让重构人员重构页面)
• 整个项目的APP端开发工作预计花费预算为 2OW左右(主要都是开发人员人力花费时间)*

第一个项目做下来总体评价:

• 优点
• 开发效率比原生要高出很多(两个开发人员开发这个项目只花费了3个月，期间需求修改了无数次，还包括了他们从0入门的学习时间)
• 相比原生更节约预算成本(如果换为原生开发，预算得2以上，而且这么多次需求修改，预算估计更是额外会超出很多)*
• 性能相比原生不足，但是可以接收(项目属于工具类APP，没有用到花哨的动画，性能在低端机上差不多是原生的70%左右，在高系统的机型上，更是几乎可以忽略这个性能差异)
• 缺点
• 依赖于H5+SDK，某些功能出Bug只能依赖于官方修复(比如其中的一个在特殊机型上的语音识别功能Bug，最终也没能解决)

第三弹:逐渐脱离项目业务开发，自己搭建开发框架

在完成了第一个Html5+模式开发的APP后，发现这种模式相比起原生开发有很大的优势，于是接下来又有多个项目基于Html5+模式进行开发。

当然随着业务的拓展，慢慢的公司里专门进行Html5+开发的人员也越来越多，从刚开始的原生Android转向H5开发，到后来纯碎就是只会JS，不会Android的人进行开发，从刚开始的只兼容Android与iOS，到后来的兼容Android,iOS，浏览器。整体模式也越来越跨平台化。

这时候，我也慢慢从项目开发中抽出身来，开始为公司的跨平台开发搭建一个简陋的开发框架，用来统一代码风格，简化开发。

整体框架的发展过程:

• 2016年1月:将一堆常用工具类组合在一起，形成了一个框架雏形V1.0版本
• 2016年2月:使用sea.js重构框架，采用模块化开发，部分API支持H5兼容。达到跨平台开发效果，推出V2.0版本
• 别问我为什么不用ES6开发==。这是有历史原因+公司本身局限造成的
• 2016年6月:框架基本功能都已经完善，重构优化部分工具类，同时推出配套的在线文档，推出框架V3.0版本
• 之后所有的更新都是基于3.0版本的

整体的框架代码结构如图:(相关文档可以参考文章最后的链接)

第四弹:H5+跨平台开发的高速发展

从15年9月份，一直到16年8月份，公司接手的小型APP基本都是用Html5+模式开发的(基于那个简陋框架，当然了，我基本都没参与开发了)，统计下来如下:(当然实际上那些微信，原生等项目就不统计了)

• 基于Html5+模式开发记录在册的APP有21个(还有一些APP是其它部分开发的就没有记录了)
• 项目大多是小型APP(就是属于那种做PC项目然后附赠APP的那种)，有几个例外(比如园区项目，是一个大型APP项目，涉及到多端，功能也非常多)
• 更多可以参考脑图统计 http://naotu.baidu.com/file/231d8deb41def6424f2f62785a3e6038?token=2755a64a06b8dee2

第五弹:业务转型，无奈舍弃H5+

到了16年8月，整体跨平台开发已经比较成熟，那个简陋框架也在慢慢完善，经过了多个项目的验证，并且在线文档也同步推出，正在慢慢完善。正常来说接下来应该就是Html5+项目业务代码的堆积时段了，接下来应该是告诉的开发H5+项目。

但是，这时候整个公司层面对Html5+跨平台开发方案进行了一次评审，一番讨论下来，最终决定舍弃已有的H5+方案，转而自己弄一套更符合公司业务的混合开发方案，遗弃理由大概如下:

• Html5+的SDK没有完全开源(虽然号称H5+是一套开源的Hybrid方案，但实际上它目前只有mui和部分sdk开源，而不开源会有很多的影响)
• 当遇到SDK底层bug时，由于没有开源，所有无法自行解决修复，只能向Dcloud官方提bug，而这块经常会影响到项目开发
• 曾经遇到过一个问题，某个安全检测软件(客户要求)，检测出了一堆的bug(其实是软件自身也有点问题)，bug指向都是h5+的sdk，而没有开源，所以无法及时解决，整个项目受到了一定的影响
• 一些其它的影响，比如局部修改某些sdk功能时就无法做到
• 当然了这些问题在已有的较为成熟的Hybrid方案中都存在，所以公司层面决定弃用
• Html5+ SDK与公司已有的移动的框架存在一些功能重合问题，而且不好直接整合进入框架。比如公司很多项目都是要结合原生模块的，H5+结合原生模块与公司已有框架确实比较费力，与公司的匹配度无法达到最高
• 公司业务特殊，在向某些客户介绍，吹嘘方案时，觉得自主研发的方案与框架能显得更有技术力量(这是一个比较无语的原因...)

于是从16年8月份开始，就开始逐渐舍弃h5+方案，转而研发搭建公司自主的混合开发框架

另外，这里支持下Dcloud，在整个Hybrid界，H5+是一个相对来说较优的方案。相对来说还是有一定的技术自由度的，比如与它的老对手APICloud相比:

• H5+适合于有一定开发经验的开发人员，H5+只提供底层，中间层的开发框架是需要开发者自行搭建的，因此开发者可以有很多工作来做，对于一些技术控来说，这些都是必须的。而且Hbuild的优化个人感觉还是要好一点的。
• APICloud适合于新手，小白，对于没有任何移动经验的新手来说，APICloud能让他快速开发一个APP，产生一定的成就感，另外个人感觉就是API营销的较好，其它更多由于没有深入了解也无从评价。

第六弹:时光飞逝，再回首，怅然若梦

从15年9月正式接触H5+开发，到16年8月舍弃h5+，再到现在17年2月。原来不知不觉之间，已经过去了1年半了。

总的来说，H5+开发对我来说更像是一个转化器，一年前，我以一个纯Android原生人员的身份进入这个领域，一年多后，我以前端界综合人士从另一端出来。

也许就像一些前辈说的一样，我们的人生就是大井套小井，我们从一个小的井底之蛙，变成一个大的井底之蛙，虽然我们内心可能一直在沾沾自喜自己已经跳出了以前的小井，但其实我们却不知依然处于另一口大井之中。

技术如此，人生也如此。骄傲也好，成就也罢，也许对于整个人生来说，它们真的不值一提。我们能做到就是恪守本心，不忘初心的一直走下去。

附录

博客

初次发布于2017.02.16于个人博客上

http://www.dailichun.com/2017/02/15/html5plusDecelop.html

源码与文档

基于h5+的跨平台开发框架