水一篇，在 黒之染：Cordova是什么？ 问题中长答案的整理：
简单讲就是可以让你用丰富的前端经验写移动应用的东西。
- 它不会把你的前端页面变成 ios 原生的 objective-c 或者 android 的 java 代码，你的界面还是网页呈现的，渲染在 android 的
android.webkit.WebView或 iOS 的UIWebView中。 - 不太像壳，更像是胶水，因为它不像框架一样团团包住你写的那部分内容，只是在运行在 WebView 中的 javascript 代码和原生代码之间建了一座沟通的桥梁， Ionic 这种东西才更像是壳。这个桥怎么搭下面写。
- 不是前端框架， bootstrap、angularjs、jqueryUI 这些是前端框架，可以和 Cordova 协作，但都不必要。
Cordova 原理
给两个链接： - webView:shouldStartLoadWithRequest:navigationType: public void addJavascriptInterface (Object object, String name)
第一个是 Cordova 在 iOS 上的原理，第二个是在 Android 上的原理。（不知道现在还是不是，我之前看的资料版本有点低）
第一个是 iOS 上 UIWebView 将要开始跳转地址的时候被调用，进而根据传入的地址作出反映。第二个是 Android 上用于使一个 Java 对象可以在 JS 中被访问，并调用其方法。
这就开启了两个平台上 JS 和原生代码之间的沟通窗口，这就是原理。 Cordova 在这个基础上构建了完善的一套体系，让我们可以以一种简单标准的流程写 Hybird 应用，它来负责这个 JS 与原生代码的沟通工作。
到这看得出，其实 原生代码是避不开的 ，想要利用系统的各项功能必须要写对应不同系统支持的不同语言的原生代码。但有很多写 Cordova 的程序员不懂这些也能写出东西来，靠的就是 丰富的插件 。
随便找一个 Cordova 插件，目录结构打开，大致是这样：
代码语言：javascript复制xxx@xxx:~/.../cordova-plugin-device
> tree
.
├── README.md
├── package.json
├── plugin.xml
├── src
│ ├── android
│ │ └── Device.java
│ ├── ios
│ │ ├── CDVDevice.h
│ │ └── CDVDevice.m
│ ├── ...
│ └── wp
│ └── Device.cs
└── www
└── device.js看到 src 文件夹底下的 ios、android、wp 这些文件夹了么，里面装的就是各个平台上的原生代码。用打包工具 build 的时候，就会对应的帮你复制到各个平台的项目文件夹去，并做好配置。
比如我写一个调用摄像头拍照片的插件，支持 android 与 iOS 两个平台，我就要针对这两个平台编写 两份 完成同样功能的原生代码，然后给一个统一的 JS 接口，由 Cordova 把这个接口暴露给写 Cordova 应用的人。他们就可以只用 JS 完成我写的插件承诺能够做到的功能，也就是拍一张照片。
也就是说 Cordova 写的应用理论上可以做到任何原生应用能做到的功能，而不是很多人误解的“局限很大”，确实是有局限，但不是局限在可能性上。
只用上面提到的两个“窗口”足以让你做到这里说的使用 JS 调用原生平台功能，但 Cordova 把这个过程简化、标准化，甚至生态化了。丰富的插件、活跃的社区还有详尽的文档，这些都极大方便了 Hybird 应用的开发过程。就好像只用 1010 可以构建整个互联网，但我们仍然需要操作系统一样。
所以真要一句话说到点上的话。。。就是可以让你用前端经验写移动应用的东西。
性能问题
界面部分是渲染在webview中的网页，通常来说应用逻辑也是js编写。性能是个大问题，但跨平台开发的便捷性又是个大优势。
好像为了追求性能，桌面应用可以用汇编编写核心代码一样，Cordova应用如果有哪部分成为了性能瓶颈也可以针对性用原生重写。
所以只要团队开发资源足够，逻辑代码部分的性能不是主要问题。但网页界面的性能就没什么好办法了（至少我没有。。。）
很多花哨的网站界面，普通点的电脑带着都费劲。对于移动设备上性能堪忧的webview来说，多加一个css的阴影可能都是得斤斤计较的支出了，这些遗憾只能看app需求自行权衡
