我的移动混合开发之旅

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

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

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

　　混合开发技术：开发效率快，上手难度低，跨平台（一套代码可以运行在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对于混合开发来说应该是一个不错的选择。

总结

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