Cordova 是什麼

水一篇，在 黒之染：Cordova是什麼？ 問題中長答案的整理：

---

簡單講就是可讓你用豐富的前端經驗寫移動應用的東西。

1. 它不會把你的前端頁面變成 ios 原生的 objective-c 或者 android 的 java 代碼，你的界面仍是網頁呈現的，渲染在 android 的 android.webkit.WebView 或 iOS 的 UIWebView 中。

2. 不太像殼，更像是膠水，由於它不像框架同樣團團包住你寫的那部份內容，只是在運行在 WebView 中的 javascript 代碼和原生代碼之間建了一座溝通的橋樑， Ionic 這種東西才更像是殼。這個橋怎麼搭下面寫。

3. 不是前端框架， 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 插件，目錄結構打開，大體是這樣：

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需求自行權衡