Html5+开发之旅-从入门到放弃

写在前面的话

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次大重构,无数次小需求修改。部分功能截图如下:

Html5+开发之旅-从入门到放弃

统计下来:

  • 整个项目主体功能开发历时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版本的

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

Html5+开发之旅-从入门到放弃

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

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

第五弹:业务转型,无奈舍弃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+的跨平台开发框架

相关推荐