由于業(yè)務的需求最近在看Hybrid涯冠，只要一提到為什么需要選擇Hybrid逼庞，就總會看到這樣一個理由“IOS&Andriod開發(fā)一個APP似乎成本有點過高了，而H5的低成本赛糟、高效率、跨平臺等特性”掌逛∷疽校看到這個我總想辯解下篓像，看來你們根本不懂app不懂hybrid，所以才覺得app開發(fā)成本高遗淳。也許從表面上看app是需要開發(fā)2個端心傀，一個項目至少需要2個人并行開發(fā)拆讯。而h5只要一個人開發(fā)，如果是一樣的級別的人員開發(fā)一樣的功能宰翅，也許app的開發(fā)成本是h5的2倍爽室。但是你們不要忘記你要做的是hybrid app，你最終是要運行在app上的阔墩，你免不了要和原生交互。只要需要原生功能你的那2個原生開發(fā)人員就省不了耸彪，所以可以理解為你做一個hybrid app至少需要3個人忘苛？中間的溝通、調試等成本更是能把你拖死扎唾。除非你是要做一個web app 或是非常輕的hybrid（能不通信就不通信，能不用原生就不用）荧呐，這種的成本可能會低些狐榔。但是這種的體驗也是很差的，基本就是web app的體驗了薄腻。

也許你會說hybrid app前期搭建框架階段調試比較頻繁，后面如果這個框架是成熟的罢艾，我的成本就自然下來了。對的咐蚯，會下來很多，從3變成1.5左右矫膨。但是這個過程沒那么快期奔，你的業(yè)務開發(fā)人員要么是h5，要么是app小伙伴轉h5.他們都有學習過程呐萌，入門簡單，要深入從來都不是簡單的事情罗晕。而出現(xiàn)問題赠堵，往往都是比較底層的，需要對3個端的技術都比較深入才能比較快速的解決粤铭。而這樣的人才少之又少杂靶，大部分人一個端都沒學到精通，就再學另外一種技術吗垮。一個團隊能有1-2個就很難得了，這1-2就是為了專門解決各種極端情況怯屉，和前期框架搭建和設計饵沧。這也是為什么不能把3變成1的一個很重要的原因。大部分問題只要這個開發(fā)人員查些資料自己就能解決狼牺，但是這里的時間就很不可控。如果要做一個項目真正寫代碼的時間其實并不需要多少掠归，技術方案、技術難點的處理從來都是最重要的環(huán)節(jié)虏冻。我們現(xiàn)在原生團隊的開發(fā)效率為什么可以那么高，就是我們把這些不可控的環(huán)節(jié)都變成可控的领曼，評估的開發(fā)時間可以到小時級別领铐，基本可以等同你的編碼時間。（這里就不展開了，有時間再總結）

所以從表面上看你是可以省一些人力祝蝠，但是不要忘記hybrid app哪怕做的再極致，它的體驗只能是堪比原生细溅，在低配手機它和原生的差距還是有的儡嘶。除非你對體驗沒有特別要求，只需要快速試錯蹦狂，占領市場，那web app和輕量級的hybrid會是你不錯的選擇窜骄。

那為什么那么多大型app摆屯，已經占領了市場卻還在用hybrid 框架？我想至少有3個原因：1.現(xiàn)在都是生態(tài)型app准验，他們一些子業(yè)務需要快速試錯廷没。2.一些活動頁更新頻繁，周期短腕柜。3.方便鏈接外部業(yè)務 ?矫废；一個app的成熟或它想往生態(tài)型app發(fā)展砰蠢，它的混合開發(fā)能力也是必不可少的。所以在我看來做hybrid框架的原因絕對不是為了減少成本律杠，前期的成本絕對比純原生的要高竞惋。從長遠來看，它是趨勢也是必經之路拆宛，最徹底的hybrid是大于小程序的浑厚。換句話講，小程序是hybrid的一種钳幅，只是小程序比較激進的把開發(fā)語言都換了。如果你深入去了解小程序和Hybrid你就會發(fā)現(xiàn)诬乞，市面上所有Hybrid的技術钠导，在小程序里面都用了，小程序里面的優(yōu)化思路也同樣可以用在你現(xiàn)在的Hybrid框架里面辈双。也許就會疑惑既然小程序也是Hybrid技術，那為什么他要自定義語言换衬，不直接開發(fā)一個普通h5的單頁面嗎证芭？這樣成本不是更低？

不是的叫潦，和hybrid app一樣表面上看成本好像是低了官硝，開發(fā)人員不需要學習新語言看上去成本是低短蜕，但事實真是如此嗎傻咖？想要接近原生的體驗，它和原生交互是非常頻繁的卿操，也就是會有大量的原生API供js使用。而做過hybrid app都知道扇雕，這塊的調試是比較麻煩的窥摄。特別像小程序他的數(shù)據處理和網絡請求都在原生開線程處理，webview只是負責渲染腮鞍。所以它需要有自己的開發(fā)工具來調試莹菱，不做開發(fā)工具最差也需要一個調試工具吱瘩。由于web開發(fā)語言是一種開放式語言，這樣就決定他們的寫法的多樣性蜜徽，有些用法是影響性能的票摇，也就會影響小程序體驗，所以還需要做一些閹割矢门。開發(fā)工具也許你可以搭一個簡易的調試工具來解決，但是如果要做閹割隔躲，那自定義語言就是一種很好的選擇物延。不僅可以做閹割，還可以約束開發(fā)者的規(guī)范浑吟，包括原生的生命周期，都可以通過規(guī)范來很好的使用组力。對于開發(fā)者來說它不需要知道哪些API能用哪些不能用，不需要復雜的使用規(guī)則和調試方案蓉冈。按照小程序API開發(fā)就可以轩触，其他的都交給工具和框架。

直接更換開發(fā)語言自然有很多好處伐弹，但是對于大部分開發(fā)者來說門檻都是很高榨为，而且開發(fā)工具、編譯環(huán)境等的投入真的不小日川。所以不換語言也許會更適合大眾矩乐，把能做的優(yōu)化都先做了。由于我們的框架就公司內部再用散罕，不換語言的弊端，我們可以開發(fā)一些手腳架來輔助欧漱，也可以通過review代碼來規(guī)避。不像小程序有大量的外部開發(fā)人員參與缚甩，所以一切還是比較可控的靶草。初步的Hybrid框架先出來，后面逐步優(yōu)化裕寨，沒必要一步到位。

以上純屬個人想法宾袜，不喜勿噴，有好的想法也可以留言认轨，歡迎討論月培。