android開發是否被h5代替？

首先亮明觀點:H5 替代原生（native）是不可能的。

我們先要弄明白Android是什麼？它最初是基於Linux的為小型移動設備定製的操作系統，發展到現在已經不是當初的那個Android了(你大爺還是你大爺，你大媽已經不是你大媽了)。現在Android 包括 :1手機平板等移動設備操作系統；2:汽車(android auto);3:智能手錶等穿戴設備(Android Wear)4:物聯網設備(Android Thing) 4:電視等智能家居(Android TV).也許還有其他，我瞭解的就這些了。

我們現在一般把Android開發只是理解為為手機等移動設備開發APP這個概念，因為現在很大一部分Android開發人員是在幹這方面的事情。其實大家從我上面對Android的簡單介紹也會發現，H5替代原生開發是不可能的。你能想象用H5(HTML5 JavaScript CSS)來開發物聯網相關是多麼彆扭和低效。

說說樓主關心的移動開發這塊，現在主流的開發是混合開發(hybrid)。原生搭架子，H5當內容。這也是人類趨利避害的表現。原生開發成本遠大於H5,特別是在升級維護，動態修復等方面。更麻煩的是現在移動操作系統領域是雙寡頭局面(Android 和iOS) 需要同時建立兩個開發團隊，而H5只需要一個團隊。其實試圖使用web的技術來進行開發移動端開發很早就有人在嘗試，畢竟web的發展已經好多年了，積累了巨量開發人員，他們肯定希望使用自己已經成熟的技能在新的領域開發。但是剛開始時候失敗了，因為硬件水平跟不上啊，效果奇差，最近兩年硬件水平飛速發展，已經具備了混合開發的條件。而且這個局面會持續很長時間，樓主需要了解混合開發這方面的知識。

現在前端非常活躍，JavaScript已經連續幾年成為最活躍的開發語言了，甚至出現了使用純JavaScript開發的框架 React Native

React Native lets you build mobile apps using only JavaScript

結論就是:在移動端，H5的開發比例會不斷上升，但是取代絕對不可能。在Android的其他應用領域，H5還有很長的路要走。

雖然開發起來的確很快很舒服，但和原生比起來純H5APP還是有很多問題，主要聚集在以下幾個方面：

1、動畫

動畫有很多種，比如側邊欄菜單的滑入滑出、元素的響應動畫、頁面切換之間的過場等等，在H5之下的眾多實現方法都沒有辦法達到純原生的性能。一般這些的話有幾種不同的選擇：css3動畫，javascript動畫，原生動畫。

css3動畫非常的消耗性能，如果某一個元素用到css3動畫可能還看不出來，但大面積或過場使用css3動畫會讓app低端手機體驗非常差。最好的選擇一般是通過框架調用底層的動畫，但不管怎麼樣等於在原來的代碼上包上了一層，性能還是不可避免的受到影響。

比如在一個新頁面的載入上，如果調用底層動畫要考慮的問題有兩個，一個是本身資源頁面的渲染問題，另一個是遠程數據的獲取。即便是這些動畫能夠很快的響應，但大量的css頁面會導致渲染卡頓，滑入時可能會有白屏/機器卡頓的現象。為了解決這些性能問題又必須要用到預加載或模擬動畫。即便是這樣，滑入滑出的動畫在低端的安卓機器上還是有很多問題，如果獲取服務端數據處理的方式不合適，卡頓白屏的現象會更嚴重。具體看下面的數據獲取方式。

2、獲取服務端數據

首先要接受的是，這裡的數據獲取都是在資源頁面上異步完成的，因為只有這樣才能讓這些資源頁面完成預加載或者渲染。但是異步拿到的數據在填入頁面中時可能會涉及DOM操作，眾所周知，DOM操作非常消耗性能，如果頁面小還好，頁面稍大數據稍微複雜一點，頻繁的DOM操作會導致明顯的閃白。

在手機平臺上，android有可能被h5打敗，傳統的安卓開發週期長故障多成本高三大弊端，而web app的誕生解決了這三個問題，而且應用響應速度更快，目前的淘寶，美團，大眾點評都是web app。web app採用h5語言編寫，底層封裝有調動手機硬件的函數，而且h5語言簡單易學，目前正在快速佔領應用市場。手機也是一種嵌入式系統，在工業控制的眾多複雜芯片中都會嵌入linux系統，在圖形化操作界面上有大量調節應用，但是h5是針對網頁開發的，標籤式設計富有層次結構，工業控制更多偏重對硬件的調度，因此h5在短期內並不會取代android在工業中應用，但假以時日經過改良修改後的h5語言一定能勝任，所以這是時間問題。

我是做安卓的，這個問題公說公有理婆說婆有理啊，我肯定說H5不可能取代移動端啊，畢竟有些方面H5實現起來效果還是沒原生好，這點不可否認，大家可以看看淘寶和京東有些頁面就知道了。做前端的小夥伴肯定說假以時日，前端工程師肯定搶你們飯碗，這也不是不可能，假如當初諾基亞那個wp系統能堅持到現在，那麼現在原生開發就要3種開發人員了，以後如果有4種，5種系統同時流行呢（估計不太可能），但是這勢必會增加開發成本，那麼用H5開發的優點也就呈現出來了。所以我們做移動端的對這個問題也不用太過激，有點憂患意識，畢竟在成本的限制下，有時候公司還是會考慮H5的，所以有空學學H5之類的，給自己多鋪一條路。小菜鳥的一點看法，大神勿噴哈

寫過一些純H5的APP，雖然開發起來的確很快很舒服，但和原生比起來純H5APP還是有很多問題，主要聚集在以下幾個方面：

1、動畫

動畫有很多種，比如側邊欄菜單的滑入滑出、元素的響應動畫、頁面切換之間的過場等等，在H5之下的眾多實現方法都沒有辦法達到純原生的性能。一般這些的話有幾種不同的選擇：css3動畫，javascript動畫，原生動畫。

css3動畫非常的消耗性能，如果某一個元素用到css3動畫可能還看不出來，但大面積或過場使用css3動畫會讓app低端手機體驗非常差。最好的選擇一般是通過框架調用底層的動畫，但不管怎麼樣等於在原來的代碼上包上了一層，性能還是不可避免的受到影響。

比如在一個新頁面的載入上，如果調用底層動畫要考慮的問題有兩個，一個是本身資源頁面的渲染問題，另一個是遠程數據的獲取。即便是這些動畫能夠很快的響應，但大量的css頁面會導致渲染卡頓，滑入時可能會有白屏/機器卡頓的現象。為了解決這些性能問題又必須要用到預加載或模擬動畫。即便是這樣，滑入滑出的動畫在低端的安卓機器上還是有很多問題，如果獲取服務端數據處理的方式不合適，卡頓白屏的現象會更嚴重。具體看下面的數據獲取方式。

2、獲取服務端數據

首先要接受的是，這裡的數據獲取都是在資源頁面上異步完成的，因為只有這樣才能讓這些資源頁面完成預加載或者渲染。但是異步拿到的數據在填入頁面中時可能會涉及DOM操作，眾所周知，DOM操作非常消耗性能，如果頁面小還好，頁面稍大數據稍微複雜一點，頻繁的DOM操作會導致明顯的閃白。

而且最重要的一點是，如果頁面加載進來之後數據更新的速度太慢，也會讓頁面模板等待很長時間，對用戶體驗又不友好，總不能每次打開都像瀏覽器一樣等待刷新是吧。

這個問題如果沒有得到解決，H5APP是很難承擔大規模數據的頁面，在它們之中頻繁切換更是難上加難，那麼肯定有人也會想到用MVVM的方式，其實我也寫過一些基於MVVM的H5APP，相對來說它們獲取數據和更新數據的方式更敏捷更科學，但寫的過程中又要注意很多H5獨有的問題，這些問題在下面的頁面切換裡來講。

3、頁面切換

上面我們看到了幾種不錯的實現方式，比如預加載和模擬動畫，甚至有批量的預加載，批量的截圖模擬動畫等等，雖然看起來很友好解決了不少問題，但事實上如果頁面足夠多就會引發另一個問題：頁面的生存週期。

試想一下，如果引導頁或者主頁面緩存了5個子頁面的資源，在跳轉到響應的子頁面時又會緩存這些子頁面的下級頁面資源，如此反覆肯定會佔據大量內存使APP的體驗下降。那麼怎麼知道那些頁面是需要的，最多緩存多少頁面，什麼時候結束哪些頁面的生存週期呢？在我用過的很多H5APP的框架裡都沒有對這些問題有一個完美的解答，因此在頁面較多內容較多的APP中可能會因這些資源分配的問題降低性能。

這時候我們回過頭來再看看MVVM的數據加載問題，實際上不管哪個MVVM框架，寫過的人都知道管理這種新型的前端代碼最重要的問題是內存的問題，你既要保證代碼寫的足夠優雅沒有任何內存洩露問題，也要考慮到在頁面生存週期結束時它們的控制器/頁面資源是否得到釋放，這對全局有沒有什麼影響，在多個請求時也要合理的分配資源，甚至是複用這些父級頁面傳過來的緩存資源等等。較小的APP可能並不會有這些問題，如果你想用純H5來開發大型APP，這很可能會浪費你很多時間——而且結果還不會讓你滿意。

4、Android/iOS的區別

很多人都說純H5APP一次編寫就能編譯Android/iOS兩種不同的APP，大大降低了成本。實際上這個觀點本身就是值得懷疑的，如果你寫過這類APP就能明白我在說什麼，它們既不省事，又存在很多BUG，調試時尤其繁瑣。

舉一個很簡單的例子，Android和iOS在返回上一頁的處理方式上就有明顯的區別，iOS的頂部bar在全屏下怎樣處理，Android機器出現smart bar怎樣處理頁面的佈局，調用底層硬件時怎樣區分不同的場景等等，你需要寫一個又一個機型和系統的判斷，然後分別在Android和iOS下調試，最後你卻發現這並沒有卵用，累的要死卻什麼沒學到，只有一堆不知道什麼時候會過時的經驗。

現在做H5混合APP開發的人很多，但是純H5卻很年輕，很多問題都沒有很好的解決，這幾個是我在做這些APP時考慮最多的問題。當然大家也不必擔心，隨著ES6的推行，硬件發展越來越快，純H5APP未必沒有一席之地。最後說一個很少人注意到的H5優勢，大家大談H5APP時都是快速開發、低成本、多平臺等等，但我卻覺得它和很多APP開發方式相比有一個不同之處——圖文混合的排版。

正是這些複雜多變的CSS樣式消耗了性能，但是它帶來了排版的多樣性，能夠細緻到每一個字寬行高和風格的像素級處理，才是H5的優異之處。

H5想要代替Native應用只是一些前端程序員的一廂情願而已。H5實際上是在Native App上的一個層，性能瓶頸難以突破，並且無法擺脫對原生代碼的依賴（不要覺得用H5就不用寫原生代碼，很多功能要用原生的寫完了給H5調用的）。

目前來看，在這個方面最好的方案是React Native。RN實際上不算H5，前端語言依舊是採用原生風格，只不過邏輯代碼可以使用JS來寫，在一定程度上能夠達到跨平臺編譯。而且因為是Native應用+V8引擎的模式，性能可以比肩原生應用

大量新生移動設備的興起，改變了互聯網的未來。在技術的發展上，HTML5會取代App應用嗎？或者說能夠在多大程度上取代呢？在HTML5規範中，已經加入了相機、磁力羅盤、GPS信息的支持。很多新興瀏覽器也已經開始支持這些新特性。能否用一個統一的HTML5來替代android和ios並行開發的雙重成本呢？以下譯自Michael Mahemoff的一篇文章，詳細分析了HTML5能否取代Android和iOS應用程序。

　　介紹

　　移動應用程序(App)和HTML5都是目前最火的技術，二者之間也有不少重疊之處。在移動設備瀏覽器裡運行的html5的web頁面，也可以重新打包成不同平臺上運行的app。目前很多瀏覽器都有很好的跨平臺支持，（譯註：firefox居然可以在android中使用和windows下同樣的瀏覽器內核），HTML5的web方案，對開發者來說更為方便。完成一次，即可多平臺使用。但這確實可行嗎？仍然有許多必要原因，使得開發者選擇了app開發。很明顯，很多人已經在這麼做了。本文將詳細分析兩種方案的優劣。

　　功能豐富

　　正方：App裡可以開發出更豐富的功能

　　我們把移動功能分成兩類。程序本身和程序與系統的結合。比如android裡，加入widget圖標或者通知提醒之類的。App對這兩者都沒問題。不用多說，這是肯定的。

　　反方：APP是挺強，但Web也正在迎頭跟進

　　確實很多原生app實現的功能是HTML5望塵莫及的。不管你的web做的再牛，如果停留在一個沒有攝像頭支持的沙盒中，很多場合還是玩不轉。幸運的是，現在沒有這樣的沙盒限制了。如果你需要你的web照相片，可以做一個負責照像的app，再把你的web打包進這個應用裡面。開源的PhoneGap框架是這麼幹的。這樣widget，手機提醒也都沒問題了。

　　但這種混合開發的問題在於，增加了複雜性，而且不象傳統web那樣可以直接在瀏覽器裡運行。這個問題短時間內恐怕沒轍。好在現在網絡標準在不斷的高速擴充，先進的瀏覽器也在一直跟進。Android 3.1已經支持camera了。iOS瀏覽器也支持WebSocket和設備方向檢測了。

　　總得來說，移動設備在發展，而web也同樣在快速變化。桌面瀏覽器本身，有5家主要瀏覽器開發商在改進現有標準，豐富新的功能。所以原生App在快速前進，同時，web也在縮小差距。

　　運行效率

　　正方：原生APP速度更快

　　原生APP沒有瓶頸，而且可以直接調用GPU加速、使用多線程。

　　反方：現如今Web已經快多了，而且多數應用也用不著那麼快。

　　這說法有點落伍了。Chrome發佈之時帶來的Javascript V8，給Web速度帶來的飛躍。而現在，計算速度變得更快了：

　　圖片處理引擎已經使用web加速。現在硬件加速也已經開始應用了。看看用上硬件加速的canvas（圖表來源）

　　要開發3D遊戲的就不用抬槓了，但對於平而來說，新聞、郵件、時間管理、社交網絡，這些用Web都夠用了。試試Steve Souders的手機性能測試工具。 另外，越來越多的框架結合WebGL，可以發揮OpenGL的優勢了。比如ImpactJS，幫助開發JS遊戲。

　　開發感受

　　正方：原生APP好寫

　　原生APP使用強壯的程序語言（Java, Objective C, C++）。適合寫複雜程序，經過歷史驗證，API豐富。在桌面環境可以方便的用模擬器測試。而Web程序的runtimes和亂七八糟的各路瀏覽器讓人頭大。

　　反方：一般都是Web更簡單，特別是需要兼容不同設備的時候。

　　Web最初的功能只限於文檔展示，而不是程序應用，貌似最近倆星期才有了JS。但有了JS後，web的世界馬上就不一樣了。更何況web不只是靜止的，HTML5，CSS3，EcmaScript Harmony（誰知道這是什麼？）都給開發者極大幫助。你是喜歡C++，java, JavaScript，那你的個人愛好，也是基於你已經攢下的代碼。但是現在沒人能否認JavaScript也和前者站在同一擂臺上。

　　瀏覽器/runtime的互不兼容（碎片），反過來看做APP也是一樣。用Java寫了Android app，然後又要面對iOS的Objective C。如果能寫一個程序，馬上能在Android和iOS上運行，多省事啊。這咱還沒提WebOS, BlackBerry，Windows Mobile呢。當然，這是理論上的。要是想讓程序在每個平臺都跑得很漂亮，得做不少調試和妥協。這對很多原生APP也是一樣的。不同OS版本，不同的設備。。。

　　所謂的Web碎片化，一直都是如此。但好消息是現在已經有很多不錯的解決辦法。Modernizr庫，用得好的話，可以幫你兼容一大批主流設備，不管是啥系統，哪個牌子的。看看我們2011年的Google IO演示。

　　用戶體驗

　　正方：原生APP更切合原有平臺

　　操作感受的定義之一，就是用戶希望在你的程序裡，用與系統連貫統一的方式來操作。不同的平臺，都有一些約定俗成的習慣。比如長按按鈕會有啥反應。你不能指望用一套統一的HTML5 App去滿足所有用戶。

　　此外，整個平臺的操作感受都由用平臺自有的軟件庫協調。直接調用平臺工具包就能直接免費獲得完整支持。

　　反方：我們Web有自己的傳統，你要特想做原有平臺那種感覺的web，也一樣能做出來

　　前面說了，Web開發的方式，是先做一個大體適合所有平臺的版本，然後再針對不同平臺不斷改進。當這些改進主要是針對功能時，你可以選擇幾個你最關心的平臺做優化。類似於瀏覽器檢測。技術論壇裡的悲催技術員們，經常抱怨這事。太多不同的瀏覽器版本了。不過如果你優先關注兩三種主流平臺，是值得為他們多花點時間做做優化。

　　web本來就有自己的操作感受。我們也可以說，不同的默認瀏覽器以及運行環境造就了獨特的"Web感受"。從更廣的角度看，這本身就是一種用戶公認的方式。此外，還有很多成功的案例並不遵循移動設備的原生操作習慣，人家也成功了。想想你最喜歡的手機遊戲的界面？很多更傳統的app也是一樣，比如Twitter客戶端。

　　傳播途徑

　　正方：原生應用更容易接觸客戶

　　象Google Play和Apple Store這樣的app發佈機制這幾年勢不可擋，推動了整個移動行業。每個程序員都能在市場裡發佈自己的應用。用戶都擠在市場裡瀏覽，搜索，接受推薦。不僅如此，只要你的程序夠好，現有用戶的打分會幫助你說服更多新的客戶。

　　反方：其實web才容易接觸到客戶

　　通過web找到內容，這是經過論證的可靠途徑。利用URL，每一項發佈的內容都有一個獨立的地址，包括在網站上發佈的應用程序。搜索引擎幫助發現內容，其他網站提供鏈接，還有一些類似應用市場的分類網站。用戶還可以郵件、短信、在社交網站分享你的鏈接。你的應用鏈接可以直接在不同設備上直接打開。

　　web上還沒有一個統一的評分系統，但這個情況也在發生改變。往下看。。。

　　收費

　　正方：App收費：應天意，順民生

　　“六歲孩子午飯時做app，$3一個，賣出幾百萬”。最近常聽看到這樣的新聞。各種大小廠商也跟著蜂擁而至，等著圈錢。應用商點幫開發商直接收費。最簡單的辦法，一次性收費。也有在app裡再另行收費或者做訂閱收費的，這幫助開發商贏得長期穩定的回報。

　　此外，傳統網站的廣告、贊助，在app裡也同樣適用。

　　反方：網站賺錢，從來都不是問題。現在機會還越來越多

　　Web能成為現在社會的推動力，有能力用多種方式取得回報，這是基本條件。雖然使用付費並不普遍。但SaaS的模式已經相當普及了。成功案例包括Google Apps，37Signals的系列產品，各類郵件的收費版。另外，直接收費並不是web應用的唯一模式。廣告、會員鏈接，贊助，其他產品服務的交叉推廣都是可選的模式。

　　看著能在應用市場裡直接賺錢而眼紅的Web開發商們，你們不能直接把你的URL發進市場，但是做一個瀏覽web的app的殼子來連到自己的web上怎麼樣？現在市場中如果不說數以千計，至少也有上百的app這麼幹了。有些包裝的好的，你甚至察覺不到他是一個web程序。

　　以後應用市場會直接支持web程序嗎？這個現在還不好說，但去年Google已經建了個Chrome web store。雖然還只能從桌面電腦放問，但這已經挑起了瀏覽器廠商的興趣。現在還只是個初步概念，但看起來挺有前途。

　　結論

　　現在還看不出完勝的一方。有些應用適合做app，有一些適合用html5。目前的情況，原生APP肯定是一個很重要的選擇。上面提到的混合式開發，可能是一個不錯的妥協方案。能用web的時候用app調用web。web實現不了的功能用app開發。

　　如果你選擇web方式，要在web標準和不斷的改進上用心。web技術本身的優點就是能兼容大批不同的操作系統和設備。消極的看，你也可以這是碎片，但web就是一切通吃。

不可能是被取代，你們看到的android開始都是基於手機上的APP開發 android的系統是開放性的系統除了手機上的android，還有智能穿戴 和工控系統，我們公司做醫療的，做的醫療設備上的系統和軟件都是android，在win的穩定性和對硬件控制不行 .C和彙編的開發成本太高維護起來比較麻煩。現在很多類似智能機器人和各種需要系統的設備裡面配套的都是android 系統。就硬件來說，比windows系統的要便宜 ，硬件設備的佔地面積小。設備外觀比較小巧科幻。開發維護成本少，開源設計，在看android系統，不要僅僅看看android的手機應用，其他智能設備的應用的市場更加廣闊。

目前替代是不可能的，前面很多問答已經說了，身為安卓開發人員我來說行業內的趨勢，以後的趨勢是H5與安卓端結合，一些多變的頁面，比如活動頁面，詳情頁面或者一些對性能要求比較低的頁面都會採用H5來完成，而要求性能較高的頁面還是會採用原生開發。

目前安卓端新進的無經驗的人員非常不好找工作，大公司除外，因為近一年移動互聯網熱度降了下來，導致很多公司壓縮移動端開發人員，而有幾年經驗的就比較不受影響。

我做了android超過7年，不得不說，從2-3年前就已經開始擁抱h5了，但肯定不能說h5要代替android，缺少了android程序員，h5人員根本無法獨立做出完整可靠高效的app。兩種技術要結合，程序員兩種技術都要會。