移动开发中HTML5能否替代本地程序？

     <p>        随着移动设备越来越先进，对 HTML5 的支持度越来越高，我们进军移动领域的时候，都会遇到一个问题，是选择 HTML5 和还是 Native (用原生代码编写的本地程序)？HTML5的前景无疑是诱人的，一句“Write once, run anywhere”就可以秒杀一切。笔者最近两年来对 HTML5 与 Native 有较为深入的研究，觉得两者之间不能仅仅是二分法来选择，还要根据企业自身的情况、团队的构成、公司的战略以及产品的特点来综合选择。</p>    <p>        HTML5的发展前景我无疑是非常看好的，各大公司也不遗余力的推动，目前主流的三大智能机操作系统 iOS、Android 和 WIndows Phone 都已经支持大部分的 HTML5 特性。而移动设备硬件军备竞赛也为 HTML5 扫清硬件障碍。按照现在的发展速度，我判断是在三年以内甚至更快，移动设备运行 HTML5 将会完全没有压力，无论是标准还是硬件。现在主流的智能机已经配置双核浏览器和 1G 及以上的内存，今年再出智能机没这个配置你都不好意思发布了。</p>    <p>        <strong>谈谈 HTML5</strong></p>    <p>        1. HTML5 可以让你摆脱对平台的依赖，用户打开浏览器，直接就可以访问你的应用，而不需要经过各种 Store 的审核。</p>    <p>        2. 实时更新，通常平台的审核都需要七个工作日左右的时间，如果你发布之后发现问题怎么办？Web 方式就不存在这种问题。</p>    <p>        3. Write once, run anywhere?</p>    <p>        这是多少程序员的梦想，也曾经是 Java 让人心动的地方，但真正做过跨平台解决方案的人都知道，这只是一句口号而已，跨平台没那么容易玩转的。没错，HTML5可以实现 Write once, run anywhere，但我们总不能写一个 Hello World 来 run anywhere 吧。不同平台有自己的特性，不同平台用户也有自己的操作习惯，如果你想讨好所有人，也就意味着你无法讨好任何人。</p>    <p>        4. 减少开发工作量或者让开发变得更简单？</p>    <p>        对老板来说，这是一个非常诱人话题，因为工作量的减少就意味着节省更多的钱，没有老板不喜欢用更少的钱办更多的事。而且目前一个非常大的问题 是，移动设备开发人员特别是 iOS 开发人员非常不好找，因为技术好的都自己做应用了，人家自己也能赚个月薪上万甚至更多，为什么要进你的公司？怎么说也是自己的事业，拥有无限可能，还可以 充分享受自由。但如果可以充分利用 HTML5，那么我们就可以招聘 Web 前端的开发人员来构建移动应用，这样就不愁招人的有问题。因为在许多人的眼里，HTML5/CSS/Javascript 都是没多大技术含量的东西，实在找不到人，找些实习生学学也就会了。</p>    <p>        但问题是，工作量真的会减少吗？技术门槛真的那么低么？答案是 NO！</p>    <p>        我曾经花了半年的时间去开发一个基于 HTML5 的移动框架，用来模拟 Native 应用，让 HTML5 应用看起来尽可能看起来像本地应用，注意：是像。这有点像 jTouch，但不一样的是，它能和 Native 程序很好地交互，并且能调用本地资源等等特性。但最后结果确不是那么令人满意，比如 HTML5 在动画切换的时候，有时候候会有一些莫名其妙的问题，当然你可以告诉我把动画效果关了，但这看起来很死板，最后我不得不关闭某些动画。而用 Objective-c编写程序就没这么多事了，几句简单的代码可以实现很酷的动画，用 HTML5 需要更多的代码，甚至根本无法实现。</p>    <p>        而且移动设备上的 HTML5 开发对开发人员的技术有非常高的要求，不是一般的 Web 前端人员能解决的，通常拥有这样技术的人才，工资水平也不会比 Native 开发人员低多少。如果你仅仅是要开发一个移动设备上的网站，这会简单很多，但如果你希望模拟 Native 应用，并且拥有较高的效率和优雅的用户体验，这就很有技术含量了。不要小看 Javascript 这类 Web 开发语言，通常我的看法是越简单的语言越会体现出技术人员的水平，特别是规划设计能力。</p>    <p>        5. 其它问题，资源调用的限制，比如说在 iOS 中有 Javascript 运行不能超过 15 秒的限制，不能调用本地硬件设备(如相机等)，无法使用推送服务等。</p>    <p>        <strong>如何选择？</strong></p>    <p>        是否这样，我们就不要选择 HTML5 了呢？我在前面说过：“要根据企业自身的情况、团队的构成、公司的战略以及产品的特点来综合选择”，我最近在关于 HTML5 讨论的微博上也有谈到：“HTML5是战略性方向，非死book 和 Google 已经布局，Google Mobile 在 iPhone 上的体验可以媲美 Native。基本上 Native+Web App 可以秒杀多数应用，如果不愿意受制于各种 Store，单独的 Web App 也是一个不错的方向。对于游戏类和对硬件环境依赖严重的应用，只能是是 Native”，相关链接：<a href="/misc/goto?guid=4958330024938848108">摘录微博——对移动互联网的一些看法</a>。仅管有这样那样的问题，但 HTML5 是一种趋势，在未来三至五年，HTML5将会取代很多本地应用，但就像多年前我们一直在谈B/S架构取代C/S架构一样，这需要一个过程。</p>    <p>        通常在 HTML 与 Native 之间，我们有三种选择——HTML5、Native App 以及 HTML5+Native，HTML5就是指纯 Web 的移动应用，用户需要打开浏览器，然后输入应用的网址访问。Native 指的是基于特定平台开发的应用。Native+HTML5实际上是一种加壳的方式，将 HTML5 用和浏览器封装起来，但这对用户是不可见的，用户没有任何异物感，和 Store 上下载的 App 没有什么两样。</p>    <p>        就我个人而言，我是比较推崇 HTML5+Native 的，这种加壳的方式，可以让你享受 Native 与 HTML5 的双重好处，但缺点是对技术含量要求较高。当然我这里指的不是简单地把 HTML5 封装到一个浏览器里面，Native 与 HTML5 会有许多的交互，实际上这有点像混合硬盘，我们即便享受 SSD 的快速，但我们又想获得机械硬盘的高性价比。我认为在5-10年内，这都会是一种不错的解决方案，当 HTML5 和硬件发展到一定水平之后，我们再完全转向 HTML5 成本也会非常低的。</p>    <p>        <strong>如何做？</strong></p>    <p>        假定现有一个对本地环境依赖不那么严重的项目，如微博客户端，各种社交美食甚至 LBS 应用，我们都可以采用 HTML5+Native。如图所示，我们可以将核心的代码 Core 层用封装起来，这个代码和平台无关，主要是业务逻辑以及和 Shell 的交互，代码用 Web 语言编写。在 Core 层上我们再根据不同的移动平台制作不同的 UI。最后我们将上述两层放到各平台的 Shell 中，这个 Shell 主要是由浏览器来完成工作，当然还包括一些硬件操作和读取本地资源，如 GPS、重力感应、相机调用、地图、推送通知或者 IAP 等。</p>    <p style="text-align:center;"><img title="html5+native" alt="移动开发中HTML5能否替代本地程序？" src="https://simg.open-open.com/show/8540c6bf9221e86ab9ada8e2a4f72b6e.jpg" width="417" height="249" /></p>    <p>        我们可以把 Web 的升级部分部署到服务器上，用户运行 App 后，App 会向服务器讲求获取最新的 Web 程序并下载运行，这样可以达到跳过各种 Store 的更新审核，达到快速更新的目的。而且假如用户无法访问互联网，我们可以让用户使用上一个版本的程序，不会像纯 Web App 那样要求用户一定要联网。</p>    <p>        <strong>好处</strong></p>    <p>        1. 用户可以离线使用</p>    <p>        2. 更新下载量及少，可以全部更新，也可以选择替换部分文件</p>    <p>        3. 代码很安全安全，众所周知 Web 应用有一个很大的问题就是代码安全的问题，但现在我们可以将 Web 代码全部加密，本地应用解密后再运行，大大的提供了代码的安全性。</p>    <p>        4. 可以通过浏览器作为中介充分利用 Native 的好处，比如说可以使用 GPS、照相机、本地相册、读取本地联系人，也可以使用推送功能等，最重要的是，某些 Web 无法实现的功能，我们可以利用 Native 来实现。</p>    <p>        5. 跨平台，多数核心代码不用重写，Javascript 的代码用得好的话，在许多地方都可以用到，包括移动应用、移动网站、PC 网站、各种浏览器插件，甚至可以用 WebKit 封装作为跨平台的应用程序。诚然，这种方式并非完全跨平台，但这样也足以减少很多工作量了，特别是后期的维护。而且完全的跨平台是没有意义的，不同平台有 自己的风格，为了更好的用户体验，界面层还是需要针对性开发的。</p>    <p>        <strong>坏处</strong></p>    <p>        我觉得最大的坏处是技术难度高，如果仅仅是简单的浏览器封装几个 HTML 文件，那没什么技术难度，但如果要打造一个系统级的东西，这就很有技术难度了。这要求有人要了解三个主流平台的浏览器特性，通晓 Native 程序的开发，要精通 HTML5/CSS3/Javascript，最重要的是，要有较强的架构设计能力。</p>    <p>        如果要再找一个坏处的话，就是它不能满足所有的需要，它并不能代替 Native，但我认为他可以替代大部的 Native。</p>    <p>        <strong>适合我们吗？</strong></p>    <p>        首先从产品的角度考虑，你的产品是否严重依赖于本地环境，比如说图像处理和华丽的游戏之类的。第二要考虑的是你的技术团队的构成，如果你们的团 队有一个能解决这些问题的牛人，并且有一些清通 Web 前端的人，那我觉得你可以考虑用这种方式。技术选型非常重要，稍有不慎，后患无穷。第三个要考虑你们公司的战略，对 HTML5 未来发展的看法，愿意在移动互联网上付出多少代价，是否愿意做前瞻性的事，是否愿意在前期投入较多的资源，是否允许试错等等。</p>    <p>        本文来自涂雅[<a href="/misc/goto?guid=4958330025778347613" rel="noindex" target="_blank">http://iove.net/</a>]，原文链接：<a title="移动开发中 HTML5 能否替代本地程序？" href="/misc/goto?guid=4958330026578668285" rel="noindex" target="_blank">http://iove.net/archives/2991.html</a>，网站转载请注明来源于涂雅并保留原文链接，否则视为侵权。</p>