在作移動端開發的時候，一些應該知道的知識

原由

一天在羣裏面朋友問了一個這麼一個問題：

看了以後本身梳理了一遍，在此和你們分享一下，這個就要從客戶端開發的過程來說了；

原生開發

在移動互聯網剛興起的時候，最初的開發模式是經過swift或java開發原生應用，有一些網頁跳轉的處理，ios使用UIWebView（ios8以後增長了WKWebView），安卓使用的是webview；這個時候業務模式還不是特別複雜，用戶也沒有那麼多，迭代時間的的長短也不是特別強烈。 隨着業務的發展，這種開發模式逐漸就出現了一下問題

• 業務逐漸變得龐大，原生開發須要更多的人員
• 業務變得更加複雜，多端的功能開發徹底是重複的
• ios審覈發版的時間限制，可能只是一個小的UI的修改，都須要從新發版

hybrid （native+H5）

基於上面的這些困擾，出現了一相似PhoneGap、Ionic的hrbrid應用，他們的做用是把h5開發好的頁面，經過打包封裝處理到webview裏面，最後瀏覽操做的其實仍是h5，只不過這個過程h5能夠調取一下原生的功能，而這個h5調用原生功能實現的底層概念叫作jsbridge，或者說jsbridge是native原生與h5通訊實現的一個過程。而這PhoneGap、Ionic之類的應用的核心就是它們實現了這麼一個過程，而且把接口暴露出來，上層h5調用就好；
簡單來講，PhoneGap框架流程就如下三步：
一、js 經過prompt接口往anroid native 發送消息
二、android 本地攔截WebChromeClient 對象的 onJsPrompt函數，截獲消息
三、android本地截獲到消息之後，經過Pluginmanager把消息分發到目的插件，同時經過jsMessageQueue收集須要返回給js的數據；

引用網上的一張圖，一塊兒來看看PhoneGap底層框架類圖~~

可是這個模式在取決於WebView的解析渲染效率，在頭幾年硬件還不死特別硬的時候，h5的渲染及交互不是特別友好，會出現卡頓；

RN、weex （DSL）

因爲hybrid的開發成本一套多用和h5發版不須要審覈的因素，facebook研究處理相應模式的框架，把對於性能影響的渲染的步驟作了處理，無論是RN仍是Weex，他們的開發語言都是js、html、css，只不過在編譯的時候，好比RN轉換成了相應的Virtual DOM以後，在native的底層實現了一套把virtual DOM轉換成原生組件的機制，這個過程是把virtual DOM轉換成了相似JSON的語言形式，最後經過本身的解析模式給實現成native的組件，這個性能天然也就會好不少，可是這個實現相似的JSON，也能夠叫作DSL，sql語句其實也會DSL，包括html也算是一套DSL語言。
而在ios裏面有一個JavaScriptCore的框架，經過它就能實現JS和OC（經過它能夠調用和渲染原生模塊）交互

總結

架構的模式還在不斷的演進，好比最近又流行起來了hybrid的模式。上面的幾個問題經過這篇文章也作了個大概的簡述，更加深刻的東西，還須要不斷學習；

歡迎關注玄說前端公衆號，後續將推出系列文章《一個大型圖形化應用0到1的過程》，此帳戶也將同步更新