html5将来会取代native app 吗，我现在学native app,比如android,会不会白学了，以后被淘汰？
本人大四毕业生，准备进军移动互联，很是迷茫，到底学native app还是HTML5，听说以后html5会取代native趋势，我怕现在学了native，要是以后html5火了起来，我不是白学了.还是现在开始学html5？纠结苦闷中！望好心人指点一二！
按投票排序
作为程序猿，你难道还有指望学一门技术过一生的想法？
从长远来看，API和语言全部都会白学。
十年前，2004年的时候我也有这样的疑问，到底学win32原生程序开发还是web程序开发，那时候win32还是如火如荼，各种独立软件开发者都到海外卖软件，月入万把刀都是没有问题的，还有各种公司在招进销存ERP、CRM等企业软件开发人员，和现在的APP开发火爆现象非常相像而web程序开发还正在起步，但是需求量很大，各种企业都要建网站（类似现在的各种企业都要有微信公众号），门户网站越做越大，各种博客系统、论坛系统、CMS系统蓬勃发展，网页开发语言也逐渐成熟，甚至一度扬言取代win32程序，把所有系统都web化，对了，flash开发也是火得不行当时我纠结点也是和撸主一样，万一花时间学win32开发，到后来不流行，没有用了怎么办？一个是正在火的win32原生程序开发，一个是眼看就要火的web开发，真是左右为难，生怕选错语言娶错姑娘，一次不正确的选择几百万人民币就不见了似的，茶不思饭不想夜不能寐，只能终日打魔兽得以解忧偶然一次机会在图书馆看到一本delphi入门开发，然后看到界面，屌爆了有没有，全英文，而且开发界面华丽丽的，第一眼我就看上了它，是的，我决定了你以为我在学开发吗，我是赤裸裸的装x，就是要比你们VB6，C语言的IDE的界面漂亮，全英文，是的，我也看不懂，但是没关系，我的小伙们们也不懂，这就够了，至此踏上了程序员的不归路-2005年07年毕业之后去了一家软件开发公司，做桌面程序开发，自己也在做工具软件，加了各种用户，经常发生QQ消息卡死电脑的情况，win32软件开发还是那么的火爆，正当庆幸自己选择正确的时候，老板让我负责的第一个项目居然是开发一套教务管理系统，在线版，Shit！！！！但是也不能跟钱过不去啊，只好找找web开发哪家强了，那时候流行WordPress、Drupal，开发出来的网站非常漂亮，web2.0嘛，项目完成后也把PHP学会了，顺带的学了mysql和JavaScript和html，其中的艰辛有空在哭诉、、、、09年，我左手delphi、右手php，胸口mysql，我还有什么不懂的，还有什么项目拿不下来的，正准备接任CTO走上人生巅峰迎娶白富美，跳槽了到了新公司，第一个项目是，asp网站维护，Shit again！！！！其中艰辛、、、、省略3万字、、、、10年，我又多了asp、sql server两项武器，接下来，你们懂的，APP很火哦~//=============== 程序员的分割线 ==================楼主请不用纠结学啥语言在哪个平台，编程的思想是通用的，触类旁通，在需要的时候学习其他语言是非常容易的，没有哪种语言真正的消失，汇编现在还是硬件开发的首选，c\c++语言开发网络游戏各种服务器程序，java、php、.net都自有它的用处，在适合是时候用适合的语言去解决问题html5和native app之间，选择你觉得最屌的，看得顺眼的就行，反正如果以APP开发为生的话，你早晚两个都会的
你可以找一家网站的wap页面和客户端对比一下。对于h5来说，浏览器接收文本需要时间，解析文本和渲染出界面需要时间，而且是每次访问都要这么做一遍。native的界面被编译之后保存于中间代码里面。谁快还不明白么。
现在的新浪微博是这样吧？根本没法用！也不知道他们是怎么测试的，你只要回复其中一条然后回退的时候就会发现刷屏到最新了。要看还得继续撸到下面，然后如此反复。。。
当年语音识别技术出来的时候所有人都说有一天界面和按钮将不复存在但是你看，他们现在不是还活的好好的
不必那么纠结，现在最流行采用的一般是hybrid 方式，比如淘宝、微信、qq都是，h5只是作为其中的一部分（插件、某些经常变动且对性能要求没那么高的页面），主框架都用原生语言------ ------ ------ ------ ------h5到后面说到底还是写js（现有框架封装得很好，比如ext），顺便学点html，css，拼装、调用、调试（最坑爹），方向：可以往前端走（js往深了学也是各种高大上，如果能让页面渲染速度提高10%，你也是刁刁的）------ ------ ------ ------ ------ -----用原生需要写，比如android用的java，开发难度确实大一点，但从学习的角度看，不管是复杂数据结构或者java语言特性（多线程，网络，序列化，安全…），还是面向对象的编程思想，值得。方向：后端，多了去了（java在大数据方面用途很广我会乱说？）如果有一天说h5占领了app开发主流，你因为学了java/object-c找不到工作，相信我，问题绝对不是出在你学错了语言ps:大四了才来纠结，之前你学啥了
人總會死的，什麼都是徒勞。
当我还是本科生的时候 甚至前一段时间 也有这个疑问
要不要要学某一门技术 有没有用 我想跟你说我今天的看法
我们不如逆向思维
想想为什么会出现这门技术？这门技术要解决什么问题（这个问题一定要是之前的技术没有解决的）？ 如果是一个标准 那么一定是大家 共有的需求
如果是一个大型的公司提出的技术 比如Google的GO语言 是不是说 这个公司在面对客户 现实 等等情况时有不足 准备推出某种技术 语言 等等去解决这个问题 呢。逆袭思维在技术上的应用 我认为是 从原来的 技术是什么 做什么
到 为什么 会产生这种技术。接着思考下去：当你的Literature Review做了前面的问题 你就知道 这个技术是为了专门解决那种情况产生的 和 产生时的context。 之后要做的就是 。。。。。（你自己想咯）理清思路再出发 磨刀不误砍柴工
所谓技不压身，年轻人不要这么功利嘛
已有帐号？
无法登录？
社交帐号登录当前访客身份：游客 [
当前位置：
透过微信应用号，看HTML5与Native进入融合时代
本文作者：邹达，APICloud CTO，10年来一直专注于移动浏览器引擎研究，参与过国内外多个浏览器引擎，Javascript引擎和跨平台应用引擎架构和开发。&
如果说以前的微信公众号还是一个媒体化的平台，那么2016年的公众号会有一种新的形态，叫应用号。应用号预示着比公众号更强大的功能、更优质的体验以及更丰富的服务。应用号的出现是微信产品的一次重大升级，无论是为了体现用户价值观？还是追求产品商业化？作为一名技术人员，我不想过多讨论，而是更愿意从技术的角度来分析一些其中Web技术的发展。微信做为一款超级App，有着巨大的入口流量，需要不断的产生动态的内容，Web技术在微信中一直发挥中重要的作用。如果说公众号还是标准Web技术＋简单桥接扩展，那么在应用号中，Web技术将依靠更强大的Web执行容器在微信中发挥更大的作用。我们可以来看看在微信中Web与Native技术的结合过程，从嵌入系统Webview, 到X5增强浏览器引擎，到功能扩展的JS-SDK，再到刚刚发布的weUI，再到应用号。微信团队一直推进着Web技术在Native App中融合与发展。
随着移动设备的快速更新换代，以HTML5为代表的Web技术在NativeApp中有了越来越多的应用场景。一方面是Native App开发团队在保证功能和性能的同时，需要提高开发效率，降低运营成本；另一方面是App用户在满足需求和体验的同时，需要更快的获取动态的内容；这些都需要Web技术在App开发中发挥越来越多的作用和价值。但这种价值绝对不能称为脱离或颠覆。在今天，更多的是“融合”！
我从06年开始做了10年浏览器引擎和跨平台App引擎。见证了这10年来，Web技术在Native
App中不断的应用和发展。从功能机到智能机，从k-java到移动App，从WebBrowser到Webkit，我们可以将Web技术在Native App中的发展分为5个阶段，内置、嵌入、桥接、混合、融合。
一&内置自定义Web容器时代
2010年之前，那时还是feature phone为主流的时代，硬件配置低，系统功能弱，手机应用以内置为主。但SP业务已得到长足的发展，用户需要动态获取内容来满足资讯和娱乐的需求。这个时期Web技术在Native应用中的使用方式是Native应用开发商与浏览器厂商合作，在应用中内置某个厂商的浏览器引擎，作为Web的执行容器。应用从服务器端动态下载web文件，解压后交给Web容器离线运行。内容和功能都很简单，通常就是图片＋文字的排版，以及按键交互。形式如图书、杂志、小游戏以及小工具等。这类需求也驱动了当时一些主流浏览器厂商去思考浏览器的在传统价值以外的作用，并积极参与到W3C Widget规范的制订。这一时期也是移动浏览器厂商的黄金时代。二
嵌入系统Webview时代
2010年，Android系统在国内兴起，iPhone也逐渐普及，以Android和iOS为主的原生应用生态系统开始不断的培养用户到AppStore下载应用，以及以独立App作为入口的使用习惯。这一时期App开发需求也逐渐增长，但是竞争还不算激烈。客户可以接受原生的开发成本和周期。应用开发商利润丰厚，开发者纷纷开始学习Android和iOS App开发。系统自带浏览器的功能和性能已经超过当时的第三方浏览器。在App中通过嵌入系统Webview来展示本地或服务器端的界面已经比较常见。这一时期Web技术的应用以内容展示为主，所能完成的功能被限制在标准浏览器支持的范围内。而传统浏览器厂商依靠Lisence收费的商业模式终结，并且逐渐淡出市场。
三&Webview的桥接扩展时代
2011年， Android和iOS在手机系统中逐渐已经占据了统治地位。App开发需求迅速增长，竞争加剧，原生开发人员供不应求，客户开始考虑成本和周期，开发商开始考虑效率和利润。开发者开始思考Webview在展示内容之外是否还可以完成部分App功能。由于系统内置的都是Webkit引擎，支持标准的Web技术，并且支持开放扩展。国内外以Phone Gap为代表的厂商开始了对Webview的桥接扩展，并且形成一套完整的调用机制，在JS中可以任意调用原生接口。这种桥接扩展主要集中于设备功能，提供的是一种能力，但是更多具体的映射还需要开发者自己来完成。由于没有涉及窗口系统、交互响应、动画效果，事件管理以及应用生命周期管理等的扩展，所以虽然开发出的App基本功能可以满足需求，但是性能和体验太差。此时通过Webview＋桥接扩展的方式，原生工程师和Web工程师一起协作已经可以完成一款 App的开发了。这一时期标准Web技术（HTML，CSS，JS）和桥接扩展机制在移动App中的使用趋势也造成了一批传统的使用非标准web技术（自定义XML标签和JS语法）的移动中间件厂商的消亡。四
移动应用开发平台的Hybrid App时代
从2012年开始，App创业火爆，App需求持续增长，有了更多的应用场景和行业结合：LBS，IoT，O2O，社交、视频等等。一方面是使用HTML＋CSS进行界面布局存在Dom树更新及单层渲染的性能问题，而且标准JavaScript规范支持的能力非常有限，需要大量的扩展来满足行业需求；另一方面是原生开发模式成本高、效率低，行业呼唤更高效的跨平台开发模式。
这一时期，国内外跨平台技术也是层出不穷，不断涌现出新的产品，但我们可以其他们分为两类：&
·&&&&&&&&
一类是继续坚持使用HTML＋CSS进行界面布局，通过对页面渲染进行优化和对标准JS进行原生扩展来实现跨平台App开发。
·&&&&&&&&
另一类是放弃使用HTML＋CSS的界面布局，选择一种第三方的中间语言（如JS，C#等）来映射成Android和iOS的系统调用，从而实现跨平台。这种方式的界面布局需要通过中间语言组合系统UI组件来完成，目前看渲染性能是比HTML＋CSS的方式要好些，但这样也失去了HTML＋CSS布局的标准性和灵活便捷。
本文探讨的主要是Web技术在App中的发展过程，不可能没有HTML和CSS，所以这里我们将集中讨论第一类的跨平台产品（Web＋Native混合）。像ReactNative虽然他所选择的第三方语言是JS，但是他也可以选择其他语言，由于HTML和CSS已经不是其界面布局的方式，所以我认为其已经脱离了标准的Web的技术，这里不再过多讨论。
此时国内HTML5也逐渐火热，大量的Web程序员期待进入Native App的开发领域。此时，面向Web工程师的移动应用开发平台（Web＋Native混合）开始出现，提供了一站式的跨平台App开发和管理服务，形成了一种新的Web技术与Native App相结合的模式。
HybridApp是一个以Web技术为主的Native App开发模式，开发者不需要具备任何的Native技能，使用标准的web技术，通过调用平台的扩展API，就可以开发出独立的跨平台App。并且能保证App的功能、性能和体验。Hybrid App引擎需要在桥接扩展的基础上提供更多的功能，如：
应用生命周期和统一事件管理；
优化交互响应、动画效果、数据缓存等；
Web界面与Native组件的混合渲染；
丰富的独立功能模块与聚合开放平台API；
对主流HTML编辑器进行扩展来支持App开发；
App安全机制及Web代码全包加密；这一时期出现了优秀跨平台App引擎，如APICloud DeepEngine，通过Deep Engine在降低开发成本，提高开发效率的同时，可以开发出满足客户需要和用户运行体验的商用App。基于APICloud，客户也开发出了安装量过千万的主流优质应用。五 基于SuperWebview的融合时代
进入2016年，虽然Hybrid App已经被行业广泛认可，但是目前Native还仍是主流的开发模式，大多数优质App都是原生的。如何能在这些Native App中使用Web技术？如何能在这些主流App中使用Web技术完成部分功能的同时，又能保证App的性能和体验？如何能让Native工程师和Web工程师能更好的协作？
对于这些问题，我们不能只是嵌入一个系统Webview，或引入一套桥接扩展机制，而是需要一个功能强大完整的超级Webview，并且是为每一个应用根据实际配置动态生成专属的SDK。这种超级Webview应具备的如下功能：
功能强大，具备MVC架构和性能优化；
聚合API，支持扩展模块和开放平台服务；
动态生成，根据配置，为每个应用动态生成专属的SDK；
云修复，实现应用内更新功能。
方便协作，保持Web和Native开发的独立性，降低融合成本，提高效率。APICloud在2016年开年推出的这款超越性产品——SuperWebview，SuperWebview的出现必将加速Web技术在Native App中的融合，并且在优质的Native App，甚至超级App中发挥更大的作用。任何一款Native App在集成SuperWebview之后，都可以大幅缩短迭代周期，支持功能的动态增加。由Web技术实现部分的功能更新无需再反复提交AppStore审核。用户也无需重新下载安装。开发一款App，到底谁当主角？是Native＋Web，还是Web＋Native？那要看谁更适合当主角，谁当主角才能把戏演好。一部好戏不能只有一个主角，配合互补才能演出好戏。
NativeApp伴随着移动设备而生，Web技术也是自出生就与Native App互补和共存。APICloud从未想过“颠覆”，只是想提供一种实实在在的高效的App开发方式，让Web技术和NativeApp能够更好的融合，发挥出各自应有的优势和价值。超越源于融合！
想通过手机客户端（支持 Android、iPhone 和 Windows Phone）访问开源中国：
旧一篇： 4个月前
新一篇： 4个月前
你也许会喜欢
这是软文？
2楼：陨落人间 来自
扯那么多，背后苦逼的还是程序猿。
3楼：54mark
申请必须得有各种证。。。
5楼：yoke白板
说了半天还是宣传自己
6楼：Smile月光
引用来自“yoke白板”的评论说了半天还是宣传自己+1
7楼：想入肥菲
宣传自己没有错，不过把一个webview忽悠成这样就不好了吧
8楼：西迷岛主
APICloud之前还剽窃过数字天堂的代码，广告倒是打的挺猛的嘛
9楼：mark35
微信的野心太大
10楼：齐德龙
引用来自“想入肥菲”的评论宣传自己没有错，不过把一个webview忽悠成这样就不好了吧+1
11楼：手机游客
17:52 (非会员)
够了，表示用过一些厂和公司的应用，在数据量过大webview不靠谱，手机卡、应用崩溃、还有出现数据展现部分丢失(重点要说的是有一款APP使用的webview技术，用几分钟就崩溃，烦死了)，要我说用原生的UI技术做多么好，webview就应该做他擅长的领域。像我这样对稳定性和效率有要求的人来说，内嵌html、css、js开发的桌面和移动应用都是垃圾。
12楼：robinjiang 来自
13楼：zonghua 来自
火狐失败了，微信成功了
14楼：muyexiudong 来自
同一屋檐下
15楼：muyexiudong 来自
引用来自“zonghua”的评论火狐失败了，微信成功了 推销
16楼：muyexiudong 来自
17楼：muyexiudong 来自
18楼：muyexiudong 来自
引用来自“想入肥菲”的评论宣传自己没有错，不过把一个webview忽悠成这样就不好了吧测试
19楼：eechen
微信应用号 = 浏览器 + 快捷方式 ?你的应用就是快捷方式,只不过区别在于你能通过微信调用一些系统API,而不需要区分Android和iOS.作为PHPer,我自己做的Android小应用:调用PHP起一个PHP内置HTTP服务器,再起一个WebView来访问,用WebView来交互,用本地PHP访问文件系统和网络(PHP cURL/file_get_contents),用随机UserAgent来识别WebView,就这么简单.
20楼：梁金堂
next flash!!!
与内容无关的评论将被删除，严重者禁用帐号
本周热点资讯
本站最新资讯