Web 和 Native

2016-01-20

PC 时代：B/S 和 C/S

客户端的技术路线选择在 PC 时代就上演过一次。那时的客户端是个人电脑，绝大部分电脑运行着 Windows 系统，还有少量的 Linux，和 Mac 系统。如果想开发一个通过服务器提供信息或服务的应用。当时的开发者需要在 Browser/Server，和 Client/Server 这两种技术路线之间做选择。由于服务器是完全控制在开发者手中，所以选择什么服务器技术对于用户并不可见。很多开发者在开发初期选择了一种后端技术，在后期换成了另外一种技术，例如，Twitter 从一开始的 Ruby 迁移到 Scala 和 Java。这种替换对用户没有什么的影响。所以，这两个技术路线选择的显性差别主要体现在客户端的选择上。是选择 B 还是 C 呢？

Browser/Server

如果选择 Browser/Server，则意味着在客户端，开发者基于浏览器向用户提供服务。用户需要先在自己的个人电脑上安装浏览器，再通过在浏览器中输入特定的域名访问相应站点。

选择这个技术路线不仅是选择了浏览器作为客户端的开发平台，更是选择了从服务器，到通信协议，再到客户端的一整套技术。除了基于浏览器开发用户界面，开发者还需要实现一个 HTTP 服务器，当然这就意味着使用 HTTP 协议作为服务器和客户端通信协议。

在 Browser/server 技术构架下，浏览器是一个开放的平台化软件。平台化意味着任何开发者只要遵守特定的技术规范（主要是 HTTP 和 HTML）都可以开发基于浏览器的应用。开放意味着技术标准和规范是公开透明的，由中立方推动的（现在这个组织是 W3C）。所以，网景可以基于 HTTP 和 HTML 开发 Netscape 浏览器。微软也可以推出 IE。除这两家之外，还不少玩家，例如 Netscape 的继任者 FireFox，Apple 的 Safari，以及 Google 的 Chrome 等等。大部分情况下，开发者开发的网站在这些浏览器下都能正常使用。

基于这个技术构架逐渐发展出一系列标准和规范：DNS，TCP/IP，HTTP，FTP，POP3，SMTP，WWW 等解决了服务器和浏览器之间的通讯标准；为了在浏览器中开发交互界面出现了 HTML，CSS，JavaScript 这三项分工明确又良好配合的技术；这些技术就构成了今天互联网的技术基础。我们也常称这些技术为 Web 技术。我们在浏览器的地址栏中输入: www.google.com 就可以搜索整个世界的信息，就建立在这种技术构架之上。

Client/Server

如果选择 Client/Server，就稍微困难一些，因为这意味着开发者需要自己开发客户端软件包，并向用户分发软件包，用户安装软件才使用开发者提供的服务。这种技术构架下，除了服务器技术之外，通讯协议和界面开发技术也都控制在开发者手中。开发者可以自由选择所有的技术实现。这种自由同时也带来了额外的负担。因为，开发者无法利用开放和标准化所带来的庞大生态，而需自己实现从服务器到客户端的整套技术。开发者可能需要重复制定和 HTTP 类似的协议，需要重复实现浏览器的部分功能。也就是我们常说的重复造轮子。这些工作无疑加大了软件开发的难度。

但是，有时候这种选择也是必要的。因为基于 HTTP 和 HTML 的 Browser/server（或者说 Web）技术有一定的使用场景。它并不能解决所有问题。如果，我们要开发的应用并不适合 Web 技术的使用场景，就需要考虑选择 Client/Server 构架。例如 QQ，Skype 这种即时通讯软件。由于 HTTP 协议并没有被设计成即时通信协议，所以，即时通信软件一般都会使用 Client/Server。通信部分使用对即时通信支持更好的私有协议，比如 XMPP，或者 MQTT。

结果

这两种技术路线竞争的结果现在我们已经知道了。大部分的开发者都选择了 B/S 构架。现在使用 PC 的用户将大部分时间花在了浏览器之中。

这个结果其实应该跟一家破产的公司–网景，密不可分。早期的网景推出了 Netscape 浏览器，这款浏览器简单易用，使得非技术人员的普通用户也可以方便地浏览网页。Netscape 推出之后便大受欢迎。微软这时才看出浏览器会是互联网的入口，马上通过收购快速开发了 IE，并将 IE 和 Windows 捆绑销售。通过操作系统的优势地位，微软赢得了浏览器之争。这个过程中，由于 IE 和 Netscape 的竞争大大推动了互联网技术的发展。浏览器越来越强大，足以应付大部分的使用场景。由于互联网技术的开放性，使得开发者可以享受到开放和标准化带来的种种好处。例如，各种 HTTP 服务器框架，HTTP 协议越来越健壮，浏览器也越来越强大。而且这一切还都是免费的。开发者可以专注于自己的服务，而无需像选择 Client/Server 路线的开发者那样还需要为各种底层技术操心。同时，技术和标准的开放性使得应用提供商不用担心受制于人。由于 WWW 标准，整个互联网并不掌握在某个人或某个公司手中。你只要有一个域名就能对全球用户提供服务。对比一下，现在 iOS 应用的发布渠道只有 App Store，就能感受到规范的开放性对于整个生态的影响。由于这些无法抵挡的诱惑，大部分开发者都选择基于浏览器开发自己的应用。

虽然赢得了浏览器之争，但对于微软而言，代价是沉重的。微软失去了对 Windows 上应用开发技术的控制权。大部分开发者都选择基于浏览器开发，而不是使用微软提供的工具。如果没有浏览器，开发者将会不得不选择微软提供的技术来开发应用。这就如同现在的 Apple 对于 iOS 开发者的控制，以及 Google 对 Android 开发者的控制一样。那样的话，整个互联网也许就掌握在微软手中了。

所以，网景虽然在竞争中落败，而后消失。但从今天来看，这个失败者并不算很失败，它仍然深刻改变了世界的图景。很多人也认为这种改变是正面的。

移动时代：Web 和 Native

当我们开始用上手机时，我们就进入了移动时代。当我们开始用手机上网时，我们就进入了移动互联网时代。随着手机的功能不断变强，我们的手机有了越来越来多的除通话之外的其他功能。本质上，手机是一台小一号的个人电脑，手机的各种功能也是一款款软件。那么，这些功能该用何种技术实现呢？我们在 PC 时代遇到过的问题，在移动时代，需要再问一次。B/S 与 C/S 之争重新开始了。只是我们现在习惯称这两种技术为 Web 和 Native。Web 是 B/S 在移动时代的延续，Native 则是 C/S 的延续。

前智能手机时代

iPhone 可以说一款跨时代的手机。它是第一款人们正真乐于使用的智能手机。所以，可以以 iPhone 的出现为界限。在 iPhone 之前，我们可以称之为“前智能手机时代”。这个时期，除了大部分功能手机（Feature Phone）使用的基于 Linux 的操作系统之外，当时称得上智能操作系统的有：Windows Mobile，Symbian，Blackberry。当时手机制造商林立，这些玩家中，即使是最大的诺基亚影响力也有限。

J2ME

J2ME 应该是这个时期移动设备上唯一一个获得了一定程度成功的跨平台解决方案。在前智能手机的时代，操作系统控制在各个生成厂商手中，市场中没有拥有绝对话语权的厂商。除了 Symbian，基本没有值得开发者为其定制开发的操作系统了。这种情况下，跨平台解决方案几乎是移动开发的唯一选择。为了能在当时各种性能受限的功能机上运行，J2ME 在设计上就做了很多折衷。J2ME 可以视为 Java 的桌面版本的裁剪版。虽然受限于硬件的发展，当时的开发者使用 J2ME 仍然做出了不少精彩的应用，并且可以运行在当时绝大多数的手机上。这是 Native 技术路线提出的第一个还不错解决方案。

WAP

当然 Web 这边也有努力。当时我们已经有了大量可以在 PC 上访问的网站。自然会希望用户也可以通过手机使用现有的网站。但由于移动网络通信能力的限制，手机功能也不强。便推出了一个 HTML 的裁剪版：WAP。网站提供了一个阉割了大部分功能的版本。用户使用手机上孱弱的浏览器访问 WAP 站点，获取有限服务。

J2ME 和 WAP 这两种技术路线都是由于时代限制而做了大量折衷的产物。使用它们开发的应用所提供的用户体验都不太好。但比较而言，用 J2ME 开发的应用相对于 WAP 可用性更好一些。WAP 由于其糟糕的体验而显得有些尴尬。J2ME 是更主流选择。看起来 Native 在移动时代初期搬回了一局。

Web 技术在客户端的实现需要在各种操作系统之上提供一个标准统一的容器：浏览器。浏览器提供统一的客户端开发平台，但也限制一部分功能，阻碍了开发者直接与底层操作系统。在 PC 上，硬件功能强大，各种操作系统的人机交互相对统一。浏览器对性能的影响并不致命。但在移动时代初期，手机还在发展初期，功能弱小，各种操作系统的交互差异巨大。在孱弱的手机上再塞一个浏览器使得手机操作系统的计算资源更为吃紧。所以，通过浏览器开发应用虽然可以继承 PC 时代 Web 技术的各种便利。但是在硬件性能有限的情况下，浏览器的存在对用户体验的限制太过致命了。绕过浏览器，直接在系统上开发可以更多地榨取硬件的性能，获得更好的用户体验。这是这个阶段为何 Native 技术更流行的原因。

智能手机时代

iOS 和 Android

iPhone 之后，用户开始正真向移动互联网转移。Android 则大大推动了这个趋势。所以，可以说 iPhone 重新定义了智能手机，而 Android 普及了智能手机。

现在，越来越多的人不再使用 PC，而是把更多的时间花在手机上。新环境也催生出了一大批基于移动环境提供服务的新公司。例如 Twitter 的出现是由于大家在手机上更乐于发送短文本。越来越多的公司开始重视移动业务，投入大量的资源为用户提供更好的移动使用体验。

iPhone 和 Android 手机的性能已经大大超过了诺基亚时代的手机。但是这一时期，技术的发展仍然延续着 Native 优于 Web 的态势。一方面，手机的性能虽有发展，但仍然没有发展到可以忽略浏览器所带来的负担。另一方面，不同于 Windows 在 PC 时代的垄断地位，在移动操作系统领域，Apple 和 Google 之间存在激烈的竞争。他们也都吸取了微软的教训，在策略上向可控的 Native 技术倾斜，远离开放的 Web 技术，力图建立符合自身利益的生态系统，把开发者牢牢控制在自己手中。这使得开发者需要使用它们发布的开发工具（iOS SDK，Xcode，Android SDK）开发应用，使用它们的渠道（App Store，Android Market）发布应用，遵守它们制定的游戏规则。这方面在 Apple 方面显得尤其严重。

但是随着硬件和操作系统的进化，以及移动互联网的发展，形势逐渐出现了变化。现在（2015年左右）的手机除了屏幕尺寸和续航能力方面仍然不足之外，计算能力（CPU）已可以媲美台式电脑了。我们用上了大量基于移动的新服务，越来越多的公司将原来在桌面上提供的服务都搬到手机上。结果就是，移动应用越来越复杂了。开发者逐渐发现，硬件和系统的发展使得提供优秀的使用体验的困难逐渐减弱了。另一方面，随着移动应用越来越复杂，开发效率的问题开始显现，并变得越来越严重。大家自然会回头从 PC 时代的 Web 技术寻找各种可能性。这是因为 Web 技术相比 Native 技术具有某些优势：

• HTML，CSS，JavaScript 的组合被证明在用户界面开发方面具有很高的效率；
• 可以跨平台，iOS 和 Android 可以使用一套代码；
• 可越过发布渠道自主更新应用。

这些优势都是有关开发效率的。Web 技术具有这些优势的原因是，开放的标准发展出来的庞大生态，而且这个生态从 PC 时代发展至今已积累多年，开发者可以利用生态中产出的各种成果，而省去很多重复工作。

但是今非昔比，我们现在已经无法退回到使用浏览器的时代。一方面是，移动应用的分发渠道已经形成，用户已经习惯在 App Store 和 Android Market 下载应用，而不是在手机浏览器中输入域名。另一方面，浏览器需要重新定义一套移动设备的交互方式，这项工作由 W3C 推动，但显然这个组织无法跟上 Apple 和 Google 推动各自原生系统发展的速度。这应该是由于移动操作系统还在快速发展之中，还未到可以大量标准化的时候。无论如何结果就是，现在使用纯粹的 Web 技术开发的应用，无论在用户的接受程度上，还是使用体验上都不如 Native 技术开发的应用。

所以，各路开发者们开始思考折衷的方式。就是仍然在 Native 的主体框架下，在合适的地方部分使用 Web 技术。下面介绍其中几种尝试。

Hybrid

混合开发的直白的解释是，Native 和 Web 技术都要用。但形式上，应用仍然和浏览器无关，用户还是需要在 App Store 和 Android Market 下载应用。只是在开发时，开发者以 Native 代码为主体框架，在合适的地方部分使用 Web 技术。比如，一个 iOS 应用中，在合适的 UIViewController 中放置一个 UIWebview（一个浏览器引擎，只拥有渲染 HTML，CSS 和执行 JavaScript 的核心功能）。这样，部分用户界面就可以使用 Web 技术实现。

在不同的产品中的 Hybrid 技术，Native 和 Web 代码比例并不确定，可视场景灵活决定。这样就可以在合适的部分使用 Web 技术，获取开发效率提升的好处，而在需要密集计算的地方（比如，动画，页面切换）又可以使用 Native 技术，以避免 Web 技术的弱点，提供良好的体验。当然，这样的灵活性并不是免费的，开发者需要为这样的开发模式提供一些基础设施，并为其带来的一些问题做好准备，比如：

• 开发者需要提供 Native 和 Web 代码之间的相互通信机制。
• 开发者需要处理 HTML，CSS 和 JavaScript 等前端资源文件的缓存和更新。
• Webview 的 Crash Report 并不清晰。这给提高应用的质量带来了挑战。

Hybrid 虽然需要做一些额外的工作，但其展现了可贵的灵活性。让开发者可以在开发效率和使用体验之间做自主的取舍，这正是现阶段的技术发展状况所需要的。所以，这也是现阶段的各大公司的主流选择。

PhoneGap

PhoneGap 仍然是一种 Hybrid 技术。它的主要工作是提供了一套 JavaScript API，使得在各个移动操作系统中可以使用统一的 API 调用系统的某些功能，例如，获取位置，打电话等。使用 PhoneGap 仍然需要一个 Native 的壳子，这个壳子主要作用是包裹一个操作系统提供的 Webview（浏览器引擎）。PhoneGap 将它提供的 JavaScript API 注入这个 Webview。开发者就可以使用 JavaScript 调用手机的系统功能，并同时使用 HTML，CSS 和 JavaScript 开发用户界面。

PhoneGap 的出现其实是在为 W3C 没有无法快速制定和推广移动时代的 Web 标准而做的补丁。其思想是，补足了这些可以调用系统功能的 API，再加上在 Webview 中提供完整的 Web 开发环境。开发者就可以像开发网站一样开发移动应用了。理论上确实如此，但现实是完全在 Webview 中开发移动应用仍不现实。这是因为现阶段 Web 技术除了调用系统功能不方便之外，更重要的缺点是不适合很多计算密集的场景。而 PhoneGap 又无法提供普通 Hybrid 那种 Native 和 Web 之间自由搭配的灵活性。

所以，PhoneGap 可能只是一种尝试，现阶段并不适合在大型移动应用中使用。如果未来某一天 Web 技术可以做出足够好的用户体验，那么更明智的选择也许是转向浏览器了。这样可以拥抱彻底的开放标准，而不是守在一个带着 Native 外壳的浏览器引擎中。

Appcelerator（Titanium）

Appcelerator 之前被称为 Titanium，现在改了一个暗示其和移动开发更有联系的名字。这是一个类似 Google 的 GWT 的项目。只不过 Appcelrator 做的是将 JavaScript 转换为可以在 iOS 运行的 Objective-C 或者可以在 Android 上运行的 Java。

本质上，Appcelerator 并不是一种 Web 技术，只是提供了提供一个使用 JavaScript 开发移动应用的方案。除了 JavaScript 之外，开发者甚至不能使用 HTML 和 CSS。和 Web 唯一有联系只是，Appcelerator 选择了一门前端开发者普遍采用的语言：JavaScript。 Appcelerator 的优势是，开发者可以使用其提供工具自动为 iOS 和 Android 两个平台生成两套代码。也就是说它是一个移动方面的跨平台解决方案。

其劣势也非常明显，开发者无法直接和系统底层沟通，需要等待 Appcelerator 提供 JavaScript API 才能追上 iOS 或者 Android 的进化。

很多开发者都对代码转换工具心存疑虑。作为一种跨平台的解决方案，开发者付出的代价很沉重：需要把自己的开发灵活性再一次交给另外一个厂商（基于系统开发就已经受制于 Apple 和 Google 了）。这类工具还常常不是开源的，而是商业项目。所以，就像 Google 的 GWT 一样，这类项目常常无法成为主流的解决方案。

React Native

在说 React Native 之前，需要先聊聊 React。 React 是 Facebook 推出的一款 JavaScript 库。Facebook 声称他们创造 React 是为了解决一个问题：构建随着时间变化数据不断变化的大规模应用程序。大家普遍认为这个库对这个问题解决得还不错。React 在 Facebook 和 Instagram 已经得到广泛使用。2013年，Facebook 将其开源。现在越来越多的前端开发者开始使用 React 开发 Web 应用。React 使得前端开发更趋于组件化，这使得前端代码的可重用，可维护，和可测试性更好了。并且通过使用 Virtual DOM 减轻有复杂交互的大型 Web 页面的运行性能问题。可以说，React 是一个引入了不错开发理念的框架.要强调的是，它仍然是一个前端框架，这一点和 jQuery 类似。

React Native 则是一个移动开发框架。2015年，Facebook 将其开源，现已支持 iOS 和 Android 两大操作系统。仅从名字就可以知道 React Native 和 React 关系紧密。Facebook 声称：React Native 的目的是使得使用 React Native 开发出来的应用既拥有 Native 的用户体验，又有 React 的开发效率。React Native 继承了 React 的整套设计哲学，可以认为 React Native 提供了一个用 React 写移动应用的方案。但是 React Native 时语法要求稍微严格一些：

• React Native 只支持 JSX 标签而不支持 HTML；
• React Native 只支持 css-layout 实现的部分 css 语法，而这只是 css 的一个子集。

实现原理上，React Native 并没有运行在浏览器引擎中。不像大部分前端框架的主要任务是简化 DOM 树的处理，React Native 和 DOM 没有关系。React Native 重写了大部分的系统 UI 组件，并在框架内处理好了 JavaScript 和原生组件之间的调用和通信。开发者可以通过 React 的风格 JavaScript 代码使用这些 React Native UI 组件构建应用的交互界面。可以认为 React Native 实现了一个简略的渲染引擎，并且仍然使用 React 的来作为这个渲染引擎的编程语言。所以 React Native 的思想和 Filpboard 的 React Canvas 是类似的。Flipboard 也自己实现了一个渲染引擎，只是结果都是以 HTML Canvas 形式输出。由于没有复杂庞大的 DOM，性能得到了提升。如果我是 Filpboard 的开发者，应该会转向 React Native。这个迁移的难度并不会太大，却可以获得来自 React/React Native 团队的原厂支持。

虽然使用了 React，但是使用 React Native 开发出来的应用其实就是一个 Native 应用。但是，整个开发方式却是 Web 式的。React 的成功对 React Native 会有一定的推动作用。但现在下结论还为时尚早，仍需更多时间和项目实践，才能确定 React Native 是否是解决移动开发效率和性能矛盾的良方。但无论结果如何，这都是一次有益的尝试。React Native 的实践也许能帮助我们回答这个问题：我们是否可以通过 Web 方式开发出 Native 的移动应用？

未来

PC 时代的 B/S 和 C/S 技术路线之争，浏览器占了上峰，使得互联网呈现出现在的面貌。

移动时代 Web 和 Native 的技术路线之争仍未尘埃落定。在这种情况下，Hybrid 模式所提供的在 Native 和 Web 之间灵活切换的能力仍然是开发者所需要的。React Native 也许会是一个不错的方向，但仍需更多时间才能看清楚。但无论如何，在现阶段的移动开发中， Native 的因素仍然太多，Web 的因素仍然太少。发展的趋势应该会是逐渐向 Web 倾斜。因为，硬件和系统都在发展，体验问题会慢慢缓解，但生产力永远是珍贵的，无论何时我们都在追求更高的开发效率。

和 PC 时代一样，未来移动互联网呈现出何种面貌将取决于 Web 和 Native 之争的结果。