156

我们的移动混合开发之旅 - 西安王磊

 5 years ago
source link: http://www.cnblogs.com/vipstone/p/7659319.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

我的移动混合开发之旅

在移动开发这片热土上,除了原生之外,也有一些公司在尝试着新技术、新模式,这是混合开发诞生和延续意义以及价值。

原生开发和混合开发的优缺点也已经是一个老生常谈的事儿了,在这里我就简单来说一下:

  原生开发优点:灵活、主流、成熟、解决问题成本等优点;

  混合开发技术:开发效率快,上手难度低,跨平台(一套代码可以运行在ios/android)上;

缺点就不用多说了,他们本身的优点也是牵制对方的缺点。

进入主题

  而我们本文重点要说的是我们在将近3年的实践当中,对与混合开发的一些思考与总结,希望可以帮助一些公司在混合开发技术框架选型上少走一些弯路,当然本文所述的所有信息都是我对于这些技术一些自己的理解,对你只是有参考作用,不能完全替代和帮助框架师对于技术的选型,俗话说的好:“明白了很多道理,依然过不好这一生.”,有些坑还是要自己踩的,不然也不会懂得什么叫“刻骨铭心”!

框架进阶之路

  我们这三年的时间,做的是一款综合类app,里面主要的功能有:新闻、工具(十余款)、聊天、朋友圈,功能可以说比较多。

  而我们使用的混合开发框架有:

  • DCloud
  • DeviceOne
  • Xamarin
  • React Native

下来我们说这四款框架的优缺点;

1、DCloud

  DCloud作为我们最早(2015年)使用的WebApp框架,可以说让我们用的非常的不舒服,DCloud是我们精心选择的第一款混合开发框架,对比了同类的webapp框架还算优秀,有自己的开发工具HBuilder,有很好的模板和Demo让我们能很快的上手写代码,配合官方MUI(DCloud的UI解决方案),咋一看用起来还可以,然而在我们的实践中还暴露了很多问题,下面我来列举一下:

  • 门槛比较低(懂Js和Html的程序员对照着api很快能够上手);
  • 有一整套的解决方案,开发工具+UI库;
  • 使用的是传统H5技术,在性能上尤其是低端android机上有瓶颈,高端机操作上也有明显的延迟;
  • 打包是在线打包,服务器经常挂,至少2015年是这样,结果你着急上东西,却迟迟打不出来app,有一定的制约和风险性;
  • 文档不是很全,有些东西不太好找;
  • 页面生命周期执行函数存在概率事件,这个事情当时纠结了很久,官方的回复也是有一定的几率执行或者不执行,2015年是这样,现在的情况不明;

  总体来说:DCloud看起来入门很容易,但是想要写好需要很好的js功底,普通水平的js写出来的app用户体验非常有局限性,基于上面的问题,我们决定换掉它。

2、DeviceOne

  DeviceOne(下文简称do)是我们国内北京的一个公司做的,他也有自己的开发工具,是基于eclipse改的,编译器可以说很不好用,不时的需要重新启动一下,而do和DCloud的最大区别是,do不是webapp,所以在性能上do是远远胜于DCloud的,do在UI上采用的是“组件商店”的概念,在说这个概念之前先要说说do的基本原理,do开发使用的是js语言,是标准的js函数,而js方法调用的组件,全部是用原生封装好的,所以你使用的每个组件:第一、可以在开发工具上拖拉拽;第二、官方开发了他们开发组件的接口每个人都可以给他们写组件,下来具体说说他们的优缺点:

  • 开发效率极高,组件拖拉拽就可以;
  • 开发门槛低,会js即可;
  • 执行效率高;
  • 开发质量、开发的功能,受组件的制约,组件有bug你写出来的app就有bug,组件没有的功能,你app也实现不了;
  • deviceone的打包次数和下载次数有限制,超出的需要收取费用;
  • 使用的是在线打包,服务器偶尔也会挂;  
  • 有些组件有问题,找官方处理,他们会让你写错误示例的demo,刚开始写一个两个还好,最后给do写错误demo成了工作的一部分了,影响工作效率;
  • 使用的人不多,网上的资料/替代方案相对匮乏;

总体来说:do性能和模式都是ok的,只是开发app受外界因素影响比较多,资料比较少,替代方案几乎没有。

3、Xamarin

  经历了两次框架更换之后,我们把希望寄托给了微软的Xamarin,用它的一个好处是可以使用C#开发,对于C#出身的程序员来说,简直是梦寐以求的事情,在一个好处就是他有一个“好粑粑”,以之前我们对于C#的信任,让我们对于Xamarin的技术,也不自觉的产生了好感,以至于我们错误了低估了他能带给我们的“麻烦”。

  • 可以使用C#语言开发;
  • 本地打包,不在受其他平台服务器的制约;
  • 调试方便,vs开发工具打断点容易;
  • 国内资料少,资料都是国外的;
  • 应用群体少,成熟解决方案少,很多第三方组件不支持,我们在绑定三方的组件比如:极光推送、相册选择、友盟统计、百度地图等ios绑定上耗费了大量的时间和经历;
  • 开发成本高,C#程序员也来越少也越来越难招;
  • ios意外的闪退比较多,而且原因不好找;

总体来说:开发成本相对于之前两款框架来说,耗费的成本要高很多,Xamarin本身的功能也有限,使用的人数少,导致资料和解决方案少,开发成本和解决问题的成本很高,有很多组件没有很好的封装,集成起来也相对麻烦很多。

4、React Native

  我们目前正在使用的框架,Facebook和JD的开发框架,在混合开发技术领域属于正统的,主流的框架,网上的资料多,基于React技术JSX技术相对成熟,开发成本低会js稍加学习一下JSX的语法即可,基于npm生态系统,所有nodejs可以使用的三方包,都可以使用,可以使用es5/es6/es7的语法开发app,非常舒服,第三方组件和绑定原生库都非常的简单方便,网上的资料也非常多。

  • 开发门槛低(会js稍加学习jsx语法即可);
  • 资料多,解决问题成本低;
  • 开发效率高,第三方集成组件多;
  • 有好的开发生态圈,性能好,背靠npm有万级以上的优秀开源三方组件支持;
  • 初学者,配置较多,开发环境配置不是很方便;
  • Facebook的更新频率比较快,版本存在一定的差异,有些老的资料可能并不适用于现在的版本;

总体来说:React Native对于混合开发来说应该是一个不错的选择。

总结

所有的经历,到最后都会变为经验,拥抱变化,不断的尝试和学习新的技能,会让你收益匪浅,墨守成规已经不在适应这个物竞天择的世界。成长的道路上会遇到很多坎坷和挫折,但不管这些试错成本有多大,他最后产生的价值,要远远大于固步自封与墨守成规带来的后果。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK