Html5+開發之旅-從入門到放棄

寫在前面的話

2017年12月18日更新
Hybrid App系列文章已經清空，正在整理一個全新的系列，待續...

2017年2月19日更新
補上最近從新整理的Hybrid App系列文章。裏面包含JSbridge原理介紹以及一個完整的JSbridge源碼項目示例。

一些相關常識

文中的Html5+是市面上一種比較流行的Hybrid開發方案，經過這套方案，能夠用HTML,JS和CSS寫出一個完整的原生APP，而且性能與原生相比較接近。

久久未能出爐的經驗總結

從16年8月下旬開始，就漸漸的遠離Dcloud的Html5+開發了(由於當初工做緣由，在公司弄了一套本身的混合開發方案)。

原計劃是在10月份左右就先總結一下Html5+一年多來的開發經驗，避免留下遺憾。可是卻因爲種種緣由，一直拖延，知道如今...

當初給本身找點藉口是沒時間，之後再寫。如今回想來，這個藉口確實有點着急，試想我有時間學口琴，吉它，英語，日語，爲什麼會沒時間來寫一篇總結博文？也許僅僅是我心裏對它不重視而已。

正常來講，隨着時間的流逝，這個念頭或許就消逝了，到最後也不會出爐一篇感想。但此刻的我要終結這個現象，我要馬上立刻寫一篇總結，以此銘記消逝在這上面的時間。

這無關信仰，僅僅由於我想要善始善終

我經歷的Html5+開發

第一彈:初識Html5+開發

於2015年9月份，在第一份工做時，身爲Android原生開發的我因爲公司需求，初次接觸了Dcloud公司的Html5+開發模式。

第一次接觸Html5+開發模式，確實被驚豔了。那時僅侷限在Android原生世界中的我知道了原來JS能夠也寫出原生APP。同時也被Hbuild這款IDE深深吸引了，以爲它功能特別強大。因而這時候便開始火燒眉毛的學習起來Html5+開發。

第二彈:磕磕碰碰完成第一個項目，踏入前端大門

固然，此時我面臨着一些阻礙:

• 沒有H5基礎，JS和CSS還沒有入門
• 沒有前輩指導，孤軍一人，萬事靠搜索
• Html5+的新人手冊有點不足

固然，對於一個合格的程序員來講，良好的學習能力是必備的，全部這都不是問題，所以從0自學，大概1個月後，磕磕碰碰的開發出了項目的第一版。

第一版的項目雖然能正常運行，可是代碼慘不忍睹，因而以後在完善項目功能的同時又對整個項目進行了屢次重構。

最終，在11月份左右時，項目的終版也出來了，整個項目經歷了3次大重構，無數次小需求修改。部分功能截圖以下:

統計下來:

• 整個項目主體功能開發歷時3個月左右(9,10,11)
• 整個項目包括兩個版本社工端和居民端，其中社工端頁面數110左右，居民端頁面數60左右(項目算較大了)
• 項目包含的功能基本涵蓋h5+ api大部份內容，包括IO操做等等，甚至其中的CA證書功能，還包括了Native.js和原生通訊。
• 項目的開發人員 是兩個 沒有任何JS和CSS經驗的Android原生人員 + 1和頁面重構人員(沒有CSS經驗只能讓重構人員重構頁面)
• 整個項目的APP端開發工做預計花費預算爲 2OW左右(主要都是開發人員人力花費時間)*

第一個項目作下來整體評價:

• 優勢
• 開發效率比原生要高出不少(兩個開發人員開發這個項目只花費了3個月，期間需求修改了無數次，還包括了他們從0入門的學習時間)
• 相比原生更節約預算成本(若是換爲原生開發，預算得2以上，並且這麼屢次需求修改，預算估計更是額外會超出不少)*
• 性能相比原生不足，可是能夠接收(項目屬於工具類APP，沒有用到花哨的動畫，性能在低端機上差很少是原生的70%左右，在高系統的機型上，更是幾乎能夠忽略這個性能差別)
• 缺點
• 依賴於H5+SDK，某些功能出Bug只能依賴於官方修復(好比其中的一個在特殊機型上的語音識別功能Bug，最終也沒能解決)

第三彈:逐漸脫離項目業務開發，本身搭建開發框架

在完成了第一個Html5+模式開發的APP後，發現這種模式相比起原生開發有很大的優點，因而接下來又有多個項目基於Html5+模式進行開發。

固然隨着業務的拓展，慢慢的公司裏專門進行Html5+開發的人員也愈來愈多，從剛開始的原生Android轉向H5開發，到後來純碎就是隻會JS，不會Android的人進行開發，從剛開始的只兼容Android與iOS，到後來的兼容Android,iOS，瀏覽器。總體模式也愈來愈跨平臺化。

這時候，我也慢慢從項目開發中抽出身來，開始爲公司的跨平臺開發搭建一個簡陋的開發框架，用來統一代碼風格，簡化開發。

總體框架的發展過程:

• 2016年1月:將一堆經常使用工具類組合在一塊兒，造成了一個框架雛形V1.0版本
• 2016年2月:使用sea.js重構框架，採用模塊化開發，部分API支持H5兼容。達到跨平臺開發效果，推出V2.0版本
• 別問我爲何不用ES6開發==。這是有歷史緣由+公司自己侷限形成的
• 2016年6月:框架基本功能都已經完善，重構優化部分工具類，同時推出配套的在線文檔，推出框架V3.0版本
• 以後全部的更新都是基於3.0版本的

總體的框架代碼結構如圖:(相關文檔能夠參考文章最後的連接)

第四彈:H5+跨平臺開發的高速發展

從15年9月份，一直到16年8月份，公司接手的小型APP基本都是用Html5+模式開發的(基於那個簡陋框架，固然了，我基本都沒參與開發了)，統計下來以下:(固然實際上那些微信，原生等項目就不統計了)

• 基於Html5+模式開發記錄在冊的APP有21個(還有一些APP是其它部分開發的就沒有記錄了)
• 項目大可能是小型APP(就是屬於那種作PC項目而後附贈APP的那種)，有幾個例外(好比園區項目，是一個大型APP項目，涉及到多端，功能也很是多)
• 更多能夠參考腦圖統計 http://naotu.baidu.com/file/231d8deb41def6424f2f62785a3e6038?token=2755a64a06b8dee2

第五彈:業務轉型，無奈捨棄H5+

到了16年8月，總體跨平臺開發已經比較成熟，那個簡陋框架也在慢慢完善，通過了多個項目的驗證，而且在線文檔也同步推出，正在慢慢完善。正常來講接下來應該就是Html5+項目業務代碼的堆積時段了，接下來應該是告訴的開發H5+項目。

可是，這時候整個公司層面對Html5+跨平臺開發方案進行了一次評審，一番討論下來，最終決定捨棄已有的H5+方案，轉而本身弄一套更符合公司業務的混合開發方案，遺棄理由大概以下:

• Html5+的SDK沒有徹底開源(雖然號稱H5+是一套開源的Hybrid方案，但實際上它目前只有mui和部分sdk開源，而不開源會有不少的影響)
• 當遇到SDK底層bug時，因爲沒有開源，全部沒法自行解決修復，只能向Dcloud官方提bug，而這塊常常會影響到項目開發
• 曾經遇到過一個問題，某個安全檢測軟件(客戶要求)，檢測出了一堆的bug(實際上是軟件自身也有點問題)，bug指向都是h5+的sdk，而沒有開源，因此沒法及時解決，整個項目受到了必定的影響
• 一些其它的影響，好比局部修改某些sdk功能時就沒法作到
• 固然了這些問題在已有的較爲成熟的Hybrid方案中都存在，因此公司層面決定棄用
• Html5+ SDK與公司已有的移動的框架存在一些功能重合問題，並且很差直接整合進入框架。好比公司不少項目都是要結合原生模塊的，H5+結合原生模塊與公司已有框架確實比較費力，與公司的匹配度沒法達到最高
• 公司業務特殊，在向某些客戶介紹，吹噓方案時，以爲自主研發的方案與框架能顯得更有技術力量(這是一個比較無語的緣由...)

因而從16年8月份開始，就開始逐漸捨棄h5+方案，轉而研發搭建公司自主的混合開發框架

另外，這裏支持下Dcloud，在整個Hybrid界，H5+是一個相對來講較優的方案。相對來講仍是有必定的技術自由度的，好比與它的老對手APICloud相比:

• H5+適合於有必定開發經驗的開發人員，H5+只提供底層，中間層的開發框架是須要開發者自行搭建的，所以開發者能夠有不少工做來作，對於一些技術控來講，這些都是必須的。並且Hbuild的優化我的感受仍是要好一點的。
• APICloud適合於新手，小白，對於沒有任何移動經驗的新手來講，APICloud能讓他快速開發一個APP，產生必定的成就感，另外我的感受就是API營銷的較好，其它更多因爲沒有深刻了解也無從評價。

第六彈:時光飛逝，再回首，悵然若夢

從15年9月正式接觸H5+開發，到16年8月捨棄h5+，再到如今17年2月。原來不知不覺之間，已通過去了1年半了。

總的來講，H5+開發對我來講更像是一個轉化器，一年前，我以一個純Android原生人員的身份進入這個領域，一年多後，我以前端界綜合人士從另外一端出來。

也許就像一些前輩說的同樣，咱們的人生就是大井套小井，咱們從一個小的井底之蛙，變成一個大的井底之蛙，雖然咱們心裏可能一直在沾沾自喜本身已經跳出了之前的小井，但其實咱們殊不知依然處於另外一口大井之中。

技術如此，人生也如此。驕傲也好，成就也罷，也許對於整我的生來講，它們真的不值一提。咱們能作到就是恪守本心，不忘初心的一直走下去。

附錄

博客

初次發佈於2017.02.16於我的博客上

http://www.dailichun.com/2017/02/15/html5plusDecelop.html

源碼與文檔

基於h5+的跨平臺開發框架