看了bang的博客對微信小程序的技術方案有了更深入的理解：
微信小程序必須要符合兩個剛需：管控 & 體驗
管控：
對于一個可以發布“小應用”的平臺，微信必須對其下發布的“小應用”用著絕對的管控能力。
體驗：
作為一個小程序需要讓其體驗接近原聲，普通H5的體驗不能達到這一需求。括頁面切換，啟動速度，頁面的整體體驗，相對于原生都是無法相比的。
針對于以上兩個剛需，微信小程序是這樣做的：
對于管控：
（1）DLS：想要對開發者進行管控，最好的方法就是自己設計一套框架，讓開發者按照自己框架的規范進行編碼，利用這套DLS（針對某一特定的領域設計的計算機語言）可以更好的針對不同的需求去優化。
（2）JS環境：寫過小程序的開發者都了解，小程序中是無法調用任何DOM API的，為什么呢？是因為小程序實現了js的運行環境與瀏覽器分離，運行在單獨的js引擎上，脫離了瀏覽器，一切DOM操作在你的JS中是無法操作的，而小程序的核心JS是運行在瀏覽器中的，這樣做的好處和壞處是什么呢？
好處:
（1）避免開發者進行DOM操作，因為開發者可能會通過不同的方式進行上線后，繞過檢查，注入js文件，自由操作DOM接口去修改的界面和內容，變成和審核時候不一樣的小程序來達到自己的目的，這中現象和之前iOS的熱更新原理是一樣的，在APP上線后，通過js腳本，去修改界面的樣式，內容，或者調用官方私有API來做一些非法的操作，這種現象對于蘋果，微信這種超級平臺是很不敬的，同時對其安全也是有很大威脅的，它不會允許這種不可控的事件在自己的眼皮底下發生。但是熱更新對于原生APP來說還是一個非常重要的需求。
（2）js和頁面渲染并行執行，不會出現由于js執行而卡住頁面的現象，提高渲染的性能。
壞處：
（1）做過iOS和JS交互的同學應該清楚大致流程，在iOS中執行JS需要講JS代碼轉化為字符串，所以，小程序中的js要傳輸給原聲webview使用，需要進行轉換為字符串來執行。
（2）iOS上原生的WKWebView的JS引擎比javaScriptCore框架做了很多的優化（使用和Safari相同的JS引擎），小程序上的js則無法享受這一優點。
對于體驗：
（1）因為小程序是寄生在原生下的應用，通過native接口，我們可以用js調用一些原生的組件和方法，做出一些H5無法完成的任務和體驗。
（2）退出小程序后，小程序后，小程序可以在后臺運行5分鐘，用戶再次打開時，不需要重洗渲染小程序。
（3）同時得益于在原生環境下，小程序可以預加載多個WKWebView，可以省去WKWebView加載時間，提高用戶體驗。
這之間的取舍就是對于業務和技術之間的取舍。在對用戶體驗影響不大的情況下，對于技術上的取舍在業務上至關重要。
以上是通過bang的博客以及自己的理解記下的。
以下是自己最于最近的現象的一些見解嘮叨：
（1）微信小程序平臺的管理機制：小程序的管控機制其實很大程度上是效仿蘋果對于旗下應用的管控機制。蘋果對自家的應用或者語言的監控可謂是家長對于孩子般的照顧了，當然這和其自身利益和自身價值是分不開的，對于前階段蘋果對于混合開發的動作（當然這和安全隱患有著關系，如JSPatch調用私有API），大家可以搜索一下2016年之前和2016年之后Object-C和Swift的語言排行，相信可以看到一下原因。所以對旗下產品的管控對于其自身利益又著很大的作用。
（2）支付寶小程序和微信小程序：支付寶小程序剛推出時，我看了一下它的文檔，確實和小程序很像，抄襲理念也是自然的了。這個我不考慮，只是寫一些對與兩個超級平臺的不同看法（純屬個人見解，歡迎一起分享討論），兩個小程序確實存在著競爭，但是我認為（不考慮兩個巨頭對于市場的戰略競爭），兩個不同的平臺都擁有著自己不同優勢產品細分領域下的深層的挖掘，比如說，在微信小程序上，我們可以對其社交進行不同的細分，這種場景對于支付寶來說并不合適的，但是在支付寶小程序中，金融類領域相對于微信來說是其優勢，在支付寶中對其進行深層次的挖掘也會帶來不一樣的效益。其實關鍵在于兩家超級平臺對于旗下優勢產品的大數據層次的開放程度，這些數據對寄生或者共存在其生態下的商戶來說是可遇不可求的。這些數據和資源足可以再次創造多個的美團和餓了么了，對于小公司的吸引力是很大的。所以個人認為支付寶和小程序勝出關鍵在于對數據的開發和不同時間節點的營銷了，不同時間節點的營銷同樣是很重要的，這個就是天時了。一個產品的成功，不僅僅靠的技術，理念，甚至體驗，因為這些都是可以改變的，但是天時足可以影響一個產品的成敗。天時，地利，人和才是其成功的關鍵。關于兩個超級平臺的發展，我們只能靜靜地觀察了，因為對于吃瓜群眾的我而言，現在只能說說理解，發發牢騷（其實很多人都是了），但是我感覺這對個人的成長也是有很大的好處的。