Hybird伤身情歌

为一个新产品做技术选型，从性能考量上当然是上原生比较好，但是在经历过维护多套代码随着业务的复杂度和版本迭代而带来的痛苦后，本人是不太乐意上的，加之考虑到公司可抽调到的人力资源来算，最终还是决定用回Hybird。

然而，Hybird当前可选型的基本只有这几个：ionic、NativeScript（NS）、React Native（RN）、weex，以及新出的flutter，涵盖Hybrid发展以来的三代技术。

第一代Hybird技术，使用webview渲染+URLScheme+Cordova/Phonegap调用原生交互，sencha touch、ionic是其中代表之一。抛开缺点先不说，其UI基本全是网页，开发方便、三端通用，这些优点导致了一批框架涌现，一时成百家争鸣状态，而此间所谓框架，只是换个方式重复造轮子而已。此时国内的状态，也如同现今的区块链一样，一窝蜂跟进仿照，而不是尝试解决其痛点。

技术创新是有必要的，是时代发展的需要，但是对于老瓶装新酒，我觉得该用批判的态度去看待，它们有时不是因为有创新想法，而只是因为我不甘于用别人那套，我不想受制于人，我也是大厂我也能做，我要与众不同，于是又造了一套轮子。

第一代Hybird技术成也webview，败也webview，渲染性能是瓶颈，部分功能受限，流畅度略欠缺，国外的Telerik在看腻了一堆轮子后，推出了思想较为进步、代表下一代Hybird技术的NativeScript，其思想是使用js调用原生api，很接近于原生android开发，几个月后，同样是国外的Facebook推出了另一个划时代产品ReactNative，利用虚拟Dom，使用js桥接调用原生UI渲染，从此Hybird技术正式进入了第二代。

如果说第一代Hybird是春秋时代、百家争鸣的话，那第二代Hybird就是战国时代，只有几个强大框架，长期时间，第二代就是“吃饭、睡觉、打郑国（原生）”，乐此不疲，开发人员各自站队，我说你的不好，你说我的不足，打了那么久，坑还是一如既往的多，完善的进度好比万里长征。像NativeScript，我没太指望靠卖UI为生的公司能提供多少优美开源的组件；像ReactNative，还没有发布1.0正式版本，每个版本可能都有差异化，不能很好向下兼容；而Weex，好比热带雨林。

在看腻了它们打闹后，莫名其妙赔了一通的Google说我不和你们一般见识，我自己玩，推出了用Dart语言开发的flutter，从此打开了第三代Hybird技术的大门。一群吃瓜群众一脸懵逼：“这是什么鬼？”，其实flutter思想是挺好的，编译成原生代码来跨平台调用原生资源，然而，其UI构建方式，我想团队乃至很多人会像我一样，吃习惯了甜豆腐脑、咸肉粽的表示吃不习惯啊……加之现在社区还不完善，遇到问题不好找到解决方案，不能贸贸然地应用到产品上。

既想提高下开发效率，又想提高下用户体验，兜兜转转，没有一个特别称心满意的框架，You can you up，I can‘t just BB，常说现在科学比较发达了，对于程序猿来说，找一个坑少好用的Hybird框架怎么这么难呢？

……
找一个最爱的深爱的想爱的亲爱的框架
来告别伤身
一个多情的痴情的绝情的无情的框架
来给我伤痕
孤单的人那么多 快乐的没有几个
不要爱过了错过了留下了伤身的我
独自唱情歌
为了爱孤军奋斗
早就吃够了爱情的苦
在爱中失落的人到处有
而我不是最后一个
爱要越挫越勇 爱要肯定执着
每一个伤身的人得看透
想爱就别怕伤痛
……

爱一个框架好难……