最近总能看到类似“App已死，服务永生”、“App必死，web永生”、“App已死，微信建站已生”这样的文章。不晓得这些网络写手到底是想代表某些公司的立场、还是想要表达怎么样的一个情结，文章中语气都是如此之肯定，好像大家真的有什么仇什么怨一样。
回顾软件发展的历史，C++开始流行时，就有人因其优秀的面向对象能力而预言C语言已死；Java语言开始流行时，也有人因其出色的跨平台能力和完备的内存管理机制而预言C++已死；在web盛行的年代，更是而有人因看好这种轻量级的B/S交互模式而预言原生应用已死。可实际上呢：这么多年过去了，根据TIOBE发布的编程语言排名结果（2015年2月版本），c和c++这两类古老语言都位于前3；原生应用也在智能手机时代重新回归主流地位。科技的发展就好像大自然的进化一样，是一个极其复杂的过程。我们非要试图从某一个简单侧面去解释或者预言这个过程演变，其结果往往都是比较片面的。从大型机时代的T/S架构，到PC机时代的C/S架构,互联网时代的B/S架构，以及移动互联和大数据时代提出的IaaS、PaaS、SaaS以及BaaS架构；所有的软件架构都是为特定的技术时代和应用环境而服务的。就好像“java好还是.net好”这样的讨论，这些年来就从来没停过，都快让人听得耳朵起茧子了。可最终又如何，java和.net两者各自都发展的好好的，科技的发展会以某些人的主观倾向为转移吗? 技术本身就无所谓好坏，最多只能说哪项技术更适合你而已。所以我们在讨论哪一项技术好哪一项技术不好这类命题的时候，应该首先明确一个大前提：我们到底要做什么?
服务还是App?
我们所说的服务，通常情况下应该理解为移动互联时代里的BAAS模式的服务，也就是为移动互联网应用开发而提供的云服务。其主要内容包括：数据存储、数据推送、版本管理、数据统计等几大类服务。由此可见服务和App之间本来就是两个不同层面的东西，根本就不应该相互比较，更不应该说谁能替代谁。个别人偷换概念，甚至在文章中用微信服务号当做服务来说事，这种说法虽然有失水准，但却是别有用心的，根本不值得我们过多的讨论。
Web还是App?
去年的10月份，W3C的HTML工作组正式发布了HTML5的正式推荐标准（W3C Recommendation）。这一消息让很多人为之满心鼓舞，还有些人因此而断定web的回归以及App的灭亡。但我们当仔细浏览W3C官方规划的HTML5发展计划，可能会发现现实并没有我们想的那么乐观：
http://dev.w3.org/html5/decision-policy/html5-2014-plan.html
W3C官方公告称：“模块化一直在标准制定过程中扮演着重要角色。为了实现功能的独立、快速进化，工作组会使用所谓的‘扩展规范’(extension specifications)。有一些最终会作为独立文档公布，并成为HTML规范家族的一部分，其它则会整合到HTML5规范里，成为基础。”
目前来看HTML5.1才会是真正的HTML5，HTML5只是个妥协方案。就好像微软的windows8到windows8.1的升级一样，windows8的按时推出完全是一种市场策略，而windows8.1虽然只是一个小版本变化，却在系统体系结构层面做了巨大的调整。HTML5.1预计2016年第四季度公布后，工作组会重复上述步骤再搞一个新的HTML5.2，继续完善、丰富功能。具体时间没说，但估计得到2018年了。而从HTML5每个方案的公布到获得几大厂商浏览器的稳定支持，一般还要再等待至少1年多的时间。就算我们等到了HTML5.1或HTML5.2的到来，它就一定能够全面的解决我们移动端应用开发的问题吗？
HTML5标准在正式通过的前些年，早就已经是实时上的标准了。无论Webkit内核、还是Firefox内核、IE内核（9.0以后版本）都先后对其实现了全面的兼容。以PhoneGap产品为首基于HTML5技术的移动中间件早在2008年就出现了，事实上我们自己的中间件产品在3.0之前也是以HTML5技术为核心的。但这几年发展过来，这一类中间件技术并没有实现对原生App开发的大规模替代，反倒是有些被开发者们越来越淡忘了。这也难怪，我们真的很难从AppStore里能找到一款完全基于HTML5技术开发且让人觉得还算优秀的应用。虽然HTML5技术结合原生App开发的模式已经比较成熟，但如果想让HTML5技术完全替代原生App开发，这么多年来，其可行性目前应该仍然停留在实践的路上…
HTML5的草案最早是在2007年就被W3C接纳了，同年9月IPhone1代手机才对外发布。确切的说HTML5的最初设计根本就没有考虑现有智能手机的体系结构，不是为智能手机时代而生。我认为未来主流移动应用开发技术的改进首先会体现在以下3个方面：即UI视图的标签化，逻辑语言的脚本化以及底层技术的开放能力。初一看，HTML/HTML5技术已经天然的满足了前两条，其实则不然。浏览器DOM的实现过程和原生UI的实现过程存在着本质上的差别，这就决定了从web页面到原生页面之间根本就无法做到平滑过渡。对于底层技术的开放能力，不应该仅仅停留在简单API扩展能力上，更应该支持UI标签的扩展。或许我们可以憧憬和期待未来HTML6标准的到来，或许在移动端HTML标准根本就不是必须的，我们完全可以找到更好的替代方案。
Facebook在移动端的技术发展路线就是对以上技术发展趋势一个很好的验证。Facebook之前曾经推出了react框架，它采用的全新思路虽然基于浏览器DOM的前端UI框架，同时也完全接管了UI开发中最为复杂的局部更新部分，擅长在在复杂场景下保证高性能。尽管react框架在web体系下已经非常优秀，然而web终究是web，无论怎么改进还是达不到原生应用的效果，Facebook最终也因此放弃了HTML5方案，在移动端转入纯原生开发的模式。近期Facebook官方宣称他们将要推出react-native计划，ReactNative完全不用DOM,开发者可以使用<View>取代<div>，使用<Image>替代<img>等，可以扩展自定义标签并实现原生对接，可以通过JavaScript来写高质量的应用。在我看来，虽然react-native还尚未正式推出，但它的技术结构已经是已知中间件产品中最先进、最能代表未来发展趋势的。它所推崇的UI视图的标签化，逻辑语言的脚本化以及底层技术的开放能力和ZBuilder4.0产品有着异曲同工之默契。
为什么一定要把Web模式和原生App模式分开来对立呢？这两者本来就有着各自不同的优势。Web已经成为App的一部分，和App组件融一起各自完成其擅长的工作。 所以，Web和App都是我们需要的，要取长补短结合在一起做。
微信还是App？
谈到微信应用，自然是发自内心的佩服。国产的App产品能够做到如此之优秀的程度，确实让人折服。微信应用发展到今天，仅注册用户就已经发展到了6亿多,其市场发展的定位也远不止其早期起家时的语音通讯和即时通信那么简单了。朋友圈的分享模块，让微信占领移动社交网络的高地；公众号及开放平台，让微信成为智能手机端的信息门户；扫一扫功能，让微信成为移动端访问网页或者下载应用的标准入口；现在又微信开放了设备接入能力，不仅仅是在为O2O市场的发展做准备，更是已经开始染指个人健康设备的领域了。再加上微信钱包、微信支付、微信商城、微信游戏等重磅型的巨无霸功能，真是微信触手无处不及呀。细分析微信的这些功能，其实早已涉及到了雅虎、谷歌、Facebook、阿里巴巴和苹果等多家互联网大佬们的核心服务范围。前段时间微信又发布新功能，在广州、深圳、佛山展开试点，启动城市服务这个全新的领域。腾讯的整体布局之大，看来真是想让微信做移动互联网的“唯一应用入口”，其野心已经很明显了。
我们大可不必被微信的汹涌攻势所吓倒，冷静的思考，微信的快速膨胀快速扩展战略，其实本身也没那么可怕。每个垂直细分的行业都有自己的价值衡量标准，短期的流量如没有长期优质的服务为基础也是徒劳，只有坚持做品质做价值才是正道。就好像当年的QQ一样，即时通信带来的大量流量，确实能够带动起巨大眼球经济，比如其带动了腾讯游戏的快速发展。但是腾讯也曾投巨资尝试过做搜索引擎、做新闻资讯、做网上购物，最终还不是也都败下阵来。
凡事物极必反,今天微信确实太强太大了，强大得让人担心是否它是否早已经触及了“去中心化”的自然发展规律。人们真正离不开的是“点对点”的沟通（即时通讯），而不是点对多的沟通（社交网络）。微信的最大弱点应该就在于人们对“私密小圈子”的渴望，这恰恰也是微信早期获得成功的原因。目前为止微信的用户一直在增加，我们每一个人在微信上都能看到自己的七大姑八大姨、单位的同事、领导、各种类型的客户、还有一大批卖东西的人（说的好听一点叫搞微信营销的人）都在里面了，导致原有的私密空间变得越来越不私密，这样下去微信恐怕也将面对类似“大批用户逃离Facebook”一样的局面。国内也发生过类似的情况，当初大家一窝蜂的涌入开心网，之前没玩过这类东西嘛，热情过后又一窝蜂全部逃离出去！
放在微信里打开的即使是普通web页面，初一看也会让人觉得闪闪发光。然而移动端终究和PC端不同，长期来看各种细分功能的用户体验效果还是至关重要的。微信也有其自身的技术短板，例如：微信的web扩展应用必须有网络的环境下才能打开；微信自己的“返回”键和web应用内的“返回”键还会互相干扰等。但是没办法，微信支持的扩展能力也只限Web。微信最新版本的安装包已经有55M多了，再无限制的增加功能只会让微信越来越冗肿而加速毁灭。如果你想指望着在微信中扩展实时导航、虚拟现实、文档类解析、面部识别、3D控制、离线地图等这些功能，对不起，这些功能在微信里都是做不到的。
今天的微信已经成为移动应用的发布的重要渠道之一，大有“苹果、安卓、微信一个都不能少”的势头。无论智慧城市应用还是行业解决方案应用，我们既要保持保持苹果、安卓、微信（未来还会包括windowsPhone）等几个平台的同步发展，又要控制风险，不要把资源全部投入到其中的某一个渠道中，特别是不能把宝全都轻易的压在微信平台上，要充分考虑未来的风险。就好比在“呼机、手机、商务通一个都不能少”那个狂热的年代，那些压巨资于呼机或商务通的代理商们，最后的结局也差不多都和呼机或商务通一样，全部消失了。
微信想要做移动终端唯一入口，着实还是有很大困难的。微信只是一个普通应用而已，它再强大也必须运行在在苹果和安卓的系统上运行。特别是苹果公司，每年都在不断调整对上线App的政策要求，而微信仍在不断开放和扩展开放第三方应用，谁敢保障苹果公司哪天不会和微信翻脸。在安卓系统体系内，阿里、百度、小米、魅族这些公司都基于安卓内核在做自己云操作系统，并且这些系统在国内的市场占有率相当之高。IT生态圈的平衡发展，上下游之间即相互依赖又相互制约，长期来看主导权不可能只由微信一家说的算。正如马化腾自己所说"打败微信的肯定不会是微信，而是另外更好玩的"，科技的发展每时每刻都在不断向前推进，这也许并非危言耸听。
所以，我们要原生App也要微信，但不能只要微信。
原生开发之困惑
我们说App死不了，并不表示说App的很好吗？其实开发App是一个极其痛苦的过程。总有人找出一些理由说App已死，甚至还有些人对原生App开发模式明确给以仇视的态度，这些也都有其现实原因的，我完全能够理解。智能手机的时代确实发展的太迅猛，过程中除了对传统行业造成了强烈的冲击外，同时也造成了IT行业内部一些资源的明显失衡。客观的说，对于绝大多数的移动应用项目而言，原生开发过程绝对是一个昂贵的陷阱。目前原生开发者（特别是IOS的开发者）工资水平确实太高：刚毕业的学生，培训的2~3个月，就能要到10K的月薪。有个2~3年开发经历且有些经验的，就敢叫到20K的月薪。App应用需求爆发性增长导致了市场供求关系的现状，这让IOS原生开发人员越来越紧俏，竞争已经不仅仅是非理性，甚至已经开始有些疯狂了。在拉勾网上，招聘3~5年以上原生开发的工程师，月薪能够给到50K的居然也大有人在。最让人接受不了的是这么高的工资，居然一直都是供不应求。这让市场上的大多数公司如何忍受，让那些经验丰富的老程序员们情何以堪呀？
这让我想起了2000年互联网刚兴起那个时候的情形，在网泡沫破灭之前，刚毕业普通做网页的学生就能拿到10K工资，和现在的状况何其相似。
每一个原生应用开发的项目都是一个巨大的坑。要么等着竞争者通过移动互联技术把你打败，要么跳进坑，自己招人来开发移动应用。特别是对于面向互联网的2C应用或者企业内BYOD的应用，更是需要至少招聘IOS、Android两个以上的原生开发团队，开发成本也随之加倍。最可怕的是，需要面对大量的黑屏、闪退、屏幕适配等底层技术陷阱。再加上技术人员流失更换频率较高，业务系统维护周期较长，操作系统平台升级后的兼容性问题（例如IOS7 UI布局结构的强制调整问题、IOS8的64位内核强制升级问题）。到处都是技术陷阱，这岂是每个小项目的成本能够承受的呀。
于是乎，很多开发者就会很自然的想到了Web技术，想到了微信平台。对于一些用户范围小、要求性低的App可能是无所谓的。但对一些重要的移动应用来说，降低品质降低用户体验效果，往往会直接导致该应用的失败。
原生APP不一定非要由纯原生的开发人员才能完成。这些年我们一直在探寻移动端跨平台的中间件技术，希望能够以此来大幅度降低移动应用开发成本。
出路在哪里？
开发高品质的App本就不该是一件困难的事情，我们一直都期望着能够通过移动中间件技术平台，让普通的菜鸟也可以轻松的站到巨人肩膀上。你的应用程序逻辑使用统一的脚本语言编写并运行，而你的应用程序用户界面则完全是原生的，想一想都会觉得很酷！科技的发展需要更专业的分工与合作：有人做手机就会有人做CPU模块、做摄像头模块;同样有人做App应用，也就应该有人做底层的UI组件、做API组件。一个优秀的移动中间件产品就是应该能“让昂贵项的原生开发人员能够更专注于底层技术创新和组件封装，让应用开发人员可以更加专注于具体项目的业务需求，实现原生开发和应用开发的完美分离!”
目前已有的移动中间件开发技术主要包括：IOS、Android或WindowsPhone的纯原生开发；以Html5技术为核心的中间件开发（例如PhoneGap, HBuilder,AppCan, ApiCloud）、以OpenGL技术为核心的中间件开发(例如：CrossApp)、以代码转换和原生反射技术为核心的中间件开发(例如：Titanium，Xamarin，React Native)，以及以虚拟UI、抽象SDK、动态组件为核心的中间件开发（例如DeviceOne）。
采用纯原生代码开发App，虽然在能力上是最强大最灵活的，但却往往都要面临以下这些问题：多个平台作战、开发工期长、开发成本高；原生代码太灵活技术陷阱太多，再加上开发人员水平参差不齐，很难控制应用质量；项目中要考虑的设备机型太多，屏幕适配工作量巨大；App升级工作烦琐、哪怕是很小的缺陷修复都必须经过AppStore的审批，还可能经常被拒…
当我们考虑跨平台需求时，很自然就能想到Html5技术。如果仅仅是做一个演示demo或体验要求不高的app还勉强，然而当我们真的去尝试用Html5做真实App项目时，我们才会发现它所欠缺可不仅仅是运行效率的问题，在很各个方面与原生交互体验的差距实在是太大了。 到目前为之我们都很难从苹果商店里找到一个Html5框架做的且体验还算不错的应用，我们还在移动端项目中痛苦的尝试Html5技术的时候，怎能忽略这个事实呢？
以OpenGL技术为核心和以代码转换和原生反射技术为核心的中间件产品,实际上并不具备完整的跨平台能力。就像facebook官方说的那样，他们所要达到的目标只是”learn once, writeanywhere”而已，还不是”write once, run anywhere”。用Javascript语法仅仅是简单的调用IOS现有类库，其开发难度是可想而知的。
虚拟UI、抽象SDK、动态组件为核心的中间件，是目前最新的中间技术。目前来看，这类产品在技术上优势还是比较明显的。但由于此类产品推出时间太短，市场检验的时间还够，所以我们还只能对此采取观望和尝试的态度，后续其能否真的成为第一个值得我们依托的移动中间件平台，这还要拭目以待。
多样性的趋势是移动互联时代发展的特点，无论在智能设备端、物联网传感器端、还是各种终端上的应用，都会变得丰富多彩。然而，发展多样性并不表示不能解决碎片化的问题，相信未来每个人最常用的App应该也不会太多。包括听音乐、看视频、玩游戏这些娱乐类的应用，还有即时通信应用、城市服务应用、办公管理应用、健康管理应用、个人信息管理类应用等。每个垂直细分方向上的应用，最终可能只有1~2家能够存活。能否降低开发成本是事关发展事关生死的问题，但高品质应用对于优秀的移动应用产品来说也是至关重要的。我们期待着能够真正解决问题的移动中间件产品能够早一天到来。