1.3 小程序与原生App（iOS、Android）的优劣对比
前文讲过，小程序也属于App的一种，那么它和我们现在流行的原生App（iOS、Android）相比，有什么区别和优势呢？
首先，从技术上来讲，目前App的主流开发方式有三种：Web App、Native App和Hybrid App。我们举几个例子来看看：
• Web App
在微信“发现”里面有一个“购物”入口，点击进去打开的是京东的移动购物页面，这个页面实际上就是一个Web App。支付宝的众多小服务也是Web App，还有“海底捞”在微信中的排号应用，这类App其实就是我们经常在PC上浏览的网页，只不过
加入了响应式的设计让它适合在移动端显示和运行，所采用的技术依然是JavaScript、CSS和HTML。相对于其他两种App，Web App具有开发简单、高效，更新灵活、跨平台，大量的网页应用稍作调整即可放在移动端运行。但缺点与优点并存，Web App性能、体验极差（对，是极差），无法使用照相机、系统通知、本地缓存等原生特性。
• Native App
也称为原生App。这种App不是采用JavaScript、CSS及HTML开发，而是使用Objective-C（iOS）或者Java（Android）开发。微信、支付宝、斗鱼TV等都属于这类App，是目前主流的开发方式。Native App具有性能、体验非常良好，组件支持完善、接口丰富等特点。但Native App最大的缺点在于，不能跨平台，有多少个平台就要开发多少个版本，现在主要有iOS和Android两个主流平台，还好Windows Phone已没了踪影。
• Hybrid App
也称为混合式App。Hybrid App看上去像一个Native App，但实质上Native技术在这里只是作为一个容器，将Web App包裹了起来，在容器内部实质上运行的还是网页。Hybrid App更像是Web App与Native App的混合体。与纯粹的Web App相比，Hybrid App会有一部分访问原生组件（相机、加速器）的能力。事实上，目前主流的应用中，纯粹的原生App很少，绝大多数都属于混合式App。比如，我们常见的京东、淘宝等电商类App，由于商品及业务变化非常频繁，需要经常调整，所以这类App的主要页面都是采用Web技术来构建，只是用Native包装了一下。那我们如何界定，哪些App属于“原生”，哪些App属于“混合”呢？答案是：看Web页面在App中所占的比例，如果绝大多数页面都采用Web技术构建，那么我们称为混合式App；而如果只有少数页面采用Web技术，我们称为原生应用。举个例子，今日头条这类新闻应用中绝大多数页面都采用原生技术实现，笔者倾向于称它为Native App；而对于淘宝、京东等App，笔者更倾向于是Hybrid App。Hybrid App具有接近于Native App的体验、开发效率高、跨平台等特性。
有一些开发者认为微信服务号里的网页应用也属于Hybrid App，这种说法也不无道理。因为这些网页应用也属于微信这个Native应用的一部分，同样运行在微信内置的浏览器中，但这是一个App所有者的问题。对于微信，确实是Native App中加入了部分“网页”，具有Hybrid App的特点。但我们上面讲到，目前主流App里很少有纯粹的Native App，是不是算作Hybrid App，应该看Web页面在App中的所占比例。微信是一个以社交为主要业务的App，微信中的绝大多数核心社交与聊天功能都是原生的，所以我们还是称微信为Native App。但是，对于服务号应用的开发者，微信并不是开发者开发的，开发者只拥有其服务号。而且服务号应用所用到的所有技术都只局限在Web技术里，从这一点来讲，服务号的应用应该归属于Web App的范畴。
此外，我们说Hybrid App具有一部分可以访问原生设备组件的能力。微信的JS-SDK确实提供了一些如拍照、录音、扫一扫等功能的接口，但相比于其他Hybrid App能调用的原生功能，实在是有限。从这个角度来讲，也应该将这些服务号的应用归属到Web App中。
其实，到底归属于什么并不重要。互联网技术中的概念层出不穷，对很多事物的定义本来就不是很明确。这里用一些篇幅解释3种主流类型的App，是希望大家在对比小程序和其他类型App时，能有一个较完整的知识背景。
那么小程序属于以上3种的哪一种？严格意义上来说，它不属于以上3种中的任何一种，在实现技术上小程序同传统的Hybrid还是有很大的不同的。小程序采用JavaScript和CSS这类常见的Web技术开发，但它又不使用HTML，它同Web没有直接的联系。小程序实际上是将一系列自己定义的组件编译成了对应平台（iOS、Android、PC）的相应可运行组件，以提高运行性能。如果一定要将小程序归并到以上3类App中，可能Hybrid App更合适：非原生，但使用到了Web技术（JavaScript和CSS）。
相比于Native App，小程序具有Hybrid App的一些优势：
• 跨平台（对于iOS和Android两个平台只需要开发一套程序）。
• 具备接近于Native App的体验（注意只是接近）。
• 对原生组件有访问能力。
• 具备缓存能力。
• 上手容易，开发逻辑较为简单。
同时，小程序还具有一些它独有的特点：
• 小程序在设计时就做了很多约定式的规范：比如简单的文件结构、默认的文件命名、内置好的Tab栏与导航栏等，这让小程序的初学者更容易上手和理解。
• 开发环境很干净，你无须安装任何除开发工具外的其他软件。当然现在这个工具简陋的可怕，很多常见的IDE功能都不具备，但相比于其他Hybrid App的环境要求，小程序这点真的很棒。
• 发布和部署流程非常简单，几乎是“傻瓜式”，点击几下就可以将应用发布到腾讯云。
• 小程序之所以在公布后引起了互联网圈儿和开发者们极高的关注度，原因并不在技术上，无数开发者、创业者看中的是微信天然的关系链与获客能力。这也是小程序最大的优势。
但是，世间没有完美的事物，计算机世界里也没有完美的技术，你以为的优势在另一方面却成了缺点。我们一起来看下：
• 小程序为了简化复杂性，做了一些UI上的设计规范，确实方便了很多对UI要求不高的应用。但这也限制了那些对UI要求极高的产品发挥。
• 小程序很遗憾地不支持现有的HTML DOM结构，而是自己给出了一系列的组件，造就了一个封闭的开发环境，这直接导致了现有的经典JavaScript框架、类库都无法使用。小程序现在的生态几乎是荒芜一片，等待着开发者们去耕耘（挑战与机遇并存，正因为没有，才有机会）。如果你想用小程序实现一组图形来展现股票或者天气的曲线，目前来看，相当烦琐。你无法使用经典的echart或者highchart，你只能自己用Canvas来一点点地绘制。
• 截止到笔者编写本书时，小程序还不支持WebView，这是相当头疼的一个问题。现在很多新闻类型的应用，都是将文章数据静态化成HTML存储在服务器或者是CDN中，然后再利用WebView直接加载这个HTML来显示。不支持WebView直接导致了很多内容型应用没办法加载已存在的大量HTML页面。内容型应用现在大量的静态化页面需要被转化（已有一些第三方的组件实现了HTML转WXML，基本思路是用正则表达式替换HTML，但效果并不能让人满意）。至于微信会不会官方支持，这个很难抉择。不支持WebView对现在的静态化HTML页面是致命的打击；但兼容WebView就意味着在小程序里你还可以运行Web App，而Web App很难去监管，性能体验也不够好，这对于小程序的发展是不利的。也许开放一个只解析CSS不允许运行JavaScript的WebView可能是个不错的选择，微信如何平衡这个问题，我们拭目以待。
• 小程序只实现了模板化并没有实现自定义组件，这是最令人不满意的地方。如果我们想实现一个自定义逻辑的组件，通常希望把这个组件的标签、样式以及业务逻辑打包在一起，然后可以放在项目中多个地方使用。外部客户端调用组件时，只需要传入组件所需要的参数，由组件自己来完成数据获取、转化、绑定并和UI层通信等操作。但小程序里的template只能将标签和样式（WXML和WXSS文件）提取出来作为一个“模板”，却无法把组件的业务逻辑（js文件）放在一起。也就是说，组件的业务逻辑不能够写在组件的模块儿中，只能写在“调用”组件的业务代码中，这就无法很好地复用组件的业务代码。原因我们会在后面讲到模板“template”时再来详细讲解。
我们用表1-1来对比小程序和现在主流App的优劣势。
表1-1 小程序和现在主流App的优劣对比
