由于業(yè)務(wù)的需求最近在看Hybrid，只要一提到為什么需要選擇Hybrid，就總會(huì)看到這樣一個(gè)理由“IOS&Andriod開發(fā)一個(gè)APP似乎成本有點(diǎn)過高了，而H5的低成本、高效率、跨平臺(tái)等特性”。看到這個(gè)我總想辯解下，看來你們根本不懂a(chǎn)pp不懂hybrid，所以才覺得app開發(fā)成本高。也許從表面上看app是需要開發(fā)2個(gè)端，一個(gè)項(xiàng)目至少需要2個(gè)人并行開發(fā)。而h5只要一個(gè)人開發(fā)，如果是一樣的級(jí)別的人員開發(fā)一樣的功能，也許app的開發(fā)成本是h5的2倍。但是你們不要忘記你要做的是hybrid app，你最終是要運(yùn)行在app上的，你免不了要和原生交互。只要需要原生功能你的那2個(gè)原生開發(fā)人員就省不了，所以可以理解為你做一個(gè)hybrid app至少需要3個(gè)人？中間的溝通、調(diào)試等成本更是能把你拖死。除非你是要做一個(gè)web app 或是非常輕的hybrid（能不通信就不通信，能不用原生就不用），這種的成本可能會(huì)低些。但是這種的體驗(yàn)也是很差的，基本就是web app的體驗(yàn)了。

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

所以從表面上看你是可以省一些人力，但是不要忘記hybrid app哪怕做的再極致，它的體驗(yàn)只能是堪比原生，在低配手機(jī)它和原生的差距還是有的。除非你對(duì)體驗(yàn)沒有特別要求，只需要快速試錯(cuò)，占領(lǐng)市場(chǎng)，那web app和輕量級(jí)的hybrid會(huì)是你不錯(cuò)的選擇。

那為什么那么多大型app，已經(jīng)占領(lǐng)了市場(chǎng)卻還在用hybrid 框架？我想至少有3個(gè)原因：1.現(xiàn)在都是生態(tài)型app，他們一些子業(yè)務(wù)需要快速試錯(cuò)。2.一些活動(dòng)頁更新頻繁，周期短。3.方便鏈接外部業(yè)務(wù) ?；一個(gè)app的成熟或它想往生態(tài)型app發(fā)展，它的混合開發(fā)能力也是必不可少的。所以在我看來做hybrid框架的原因絕對(duì)不是為了減少成本，前期的成本絕對(duì)比純?cè)囊摺拈L(zhǎng)遠(yuǎn)來看，它是趨勢(shì)也是必經(jīng)之路，最徹底的hybrid是大于小程序的。換句話講，小程序是hybrid的一種，只是小程序比較激進(jìn)的把開發(fā)語言都換了。如果你深入去了解小程序和Hybrid你就會(huì)發(fā)現(xiàn)，市面上所有Hybrid的技術(shù)，在小程序里面都用了，小程序里面的優(yōu)化思路也同樣可以用在你現(xiàn)在的Hybrid框架里面。也許就會(huì)疑惑既然小程序也是Hybrid技術(shù)，那為什么他要自定義語言，不直接開發(fā)一個(gè)普通h5的單頁面嗎？這樣成本不是更低？

不是的，和hybrid app一樣表面上看成本好像是低了，開發(fā)人員不需要學(xué)習(xí)新語言看上去成本是低，但事實(shí)真是如此嗎？想要接近原生的體驗(yàn)，它和原生交互是非常頻繁的，也就是會(huì)有大量的原生API供js使用。而做過hybrid app都知道，這塊的調(diào)試是比較麻煩的。特別像小程序他的數(shù)據(jù)處理和網(wǎng)絡(luò)請(qǐng)求都在原生開線程處理，webview只是負(fù)責(zé)渲染。所以它需要有自己的開發(fā)工具來調(diào)試，不做開發(fā)工具最差也需要一個(gè)調(diào)試工具。由于web開發(fā)語言是一種開放式語言，這樣就決定他們的寫法的多樣性，有些用法是影響性能的，也就會(huì)影響小程序體驗(yàn)，所以還需要做一些閹割。開發(fā)工具也許你可以搭一個(gè)簡(jiǎn)易的調(diào)試工具來解決，但是如果要做閹割，那自定義語言就是一種很好的選擇。不僅可以做閹割，還可以約束開發(fā)者的規(guī)范，包括原生的生命周期，都可以通過規(guī)范來很好的使用。對(duì)于開發(fā)者來說它不需要知道哪些API能用哪些不能用，不需要復(fù)雜的使用規(guī)則和調(diào)試方案。按照小程序API開發(fā)就可以，其他的都交給工具和框架。

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

以上純屬個(gè)人想法，不喜勿噴，有好的想法也可以留言，歡迎討論。