微信迷妳程序
微信小程序的需求是第三方開發者可以接入，可以使用微信提供的接口開發嵌入微信的應用。對於這個需求，最簡單的解決方案就是讓外部開發者開發純H5應用，在微信的H5容器中打開，容器提供微信原生接口。在小程序出現之前，已經有很多這樣的服務接入，比如在JD.COM購物，錢包裏的各種好友評論/滴滴出行等。，都可以認為是壹個“小程序”，嵌入微信，可以調用微信原生接口。是不是應該按照這個模式，把相應的接口開放給第三方，然後提供壹個入口？
事實上，這種簡單的解決方案無法滿足需求。在產品方面，微信小程序還有另外兩個非常重要的要求:
控制。作為壹個平臺，它必須能夠控制被訪問的應用程序，並盡可能精確地控制應用程序的內容和類型。畢竟如果有非法的應用平臺，是有責任的。H5方法太自由了，開發者可以隨時改變整個應用程序的內容。平臺很難察覺到這些變化，也無法控制。另外，H5的開發質量參差不齊，平臺無法掌控，這對於壹向潔癖的微信來說是無法接受的。
體驗。作為壹個“小程序”，我們需要把體驗做到接近原生，但是這些普通的H5頁面，比如在JD.COM購物的體驗並不是很好，包括啟動速度/頁面切換流暢度，都是原生體驗無法比擬的。
小程序所有的技術方案都是服務於這兩個需求的。
控制
為了滿足管控的需要，技術上微信做了兩件事:小程序框架和分離的JS運行環境。
框架/DSL
H5太自由了。首先要做的就是限制它的自由。怎麽會？自然是框架陷阱，讓開發者只能按照框架的規則進行開發。我應該使用什麽樣的框架？
在PCSNS時代，臉書做開放平臺的時候也有類似的場景。為了讓第三方開發者在臉書平臺上開發，同時限制開發者的權利，臉書要求開發者使用壹套定制的DSL(FBML)進行開發，而這個DSL怎麽寫，最終能轉換成什麽，怎麽實現，都是平臺說了算，也方便靜態代碼分析和審核。
小程序可以借鑒這個設計思路。接口不是用HTML開發的，而是定制了壹套DSL，這樣就可以用審計/靜態代碼分析/域名限制等壹系列措施輕松控制，這就是小程序框架的來源。這個框架使用wxml描述界面，wxss描述風格，js處理邏輯和數據，然後通過壹系列工具將這些轉換成HTML/CSS/JS在webview上顯示，並處理界面交互和數據更新。
這樣，用壹個框架來限制開發模式，再造壹層DSL，除了管控之外還有壹個好處，就是容易進行針對性的優化。DSL最終轉換成什麽，如何渲染，由框架決定，上層並不知曉。可以用webview渲染，有條件的話可以用類似RN的方案實現渲染層。
JS環境
通過框架定義了開發模式之後，在管控上還有壹個問題，就是如何限制應用端類JS語言調用domAPI？小程序在webview上運行時，渲染時需要通過JS操作dom。如果applet框架和應用JS代碼都有操作dom的權限，應用就有可能通過各種方式繞過上線後的檢查，註入JS調用dom接口修改頁面結構和內容，成為與審核不同的應用。如何限制應用程序調用dom的JS權限？微信想到了更具創新性的解決方案，即JS運行時環境與瀏覽器分離，運行在單獨的JS引擎上。
沒有瀏覽器，JS自然沒有權限調用dom，任何與webview接口相關的API都無法獲取。而小程序框架的核心JS運行在webview上，可以自由操作dom。通過applet框架定義的機制，應用端通過wxml/wxss定義固定的渲染風格，而JS端只關心數據綁定，數據可以通過native bridge從JS引擎傳輸到webview。JS端不能做任何渲染相關的操作，可以對渲染的內容有完全的控制權。
獨立的JS運行環境在滿足管理和控制要求的同時，也帶來了壹些利弊。其優點如下:
多個頁面可以* *享受壹個JS運行環境，數據也可以輕松* * *享受，整個小程序生命周期* *享受同壹個上下文，更貼近APP的開發體驗。
JS和頁面渲染分開並行執行，這樣JS執行時頁面渲染不會被阻塞，渲染性能會得到提升。
缺點是:
伴隨著數據序列化和傳輸的開銷，數據需要從JS傳輸到webview進行視圖層渲染，傳輸前需要序列化成字符串格式。
iOS上WKWebview的JS引擎比JavaScriptCore有更多的JIT優化，執行速度快很多倍。小程序的JS在JavaScriptCore上運行是享受不到這種優化的。
由於控制需求過於迫切，這種方案的缺點是可以接受的。
經驗
小程序的兩個主要技術點——框架和JS操作的分離——來源於管控需求，體驗需求由各種細節化的性能優化組成，在很多文章中也有分析。這裏，簡單地說，它們包括:
離線打包:整個小程序打包分發，不需要打開每壹個頁面去請求，減少二次打開時間和頁面切換時間。
預加載:在後臺多預加載壹個wkwebview，節省了用戶打開小程序時初始化wkwebview的時間。另外，對於小程序中的頁面切換，得益於框架的設計，可以預渲染模板，切換時可以填充數據，加快了渲染速度。
緩存:退出小程序後不會立即銷毀，而是繼續在後臺運行5分鐘，期間用戶會快速切換回小程序。
視覺:小程序的首次加載通過加載和動畫過渡，拒絕黑屏，給人壹種快捷的感覺，同時提高了小程序的辨識度。
剩下的都是圍繞小程序這個平臺來構建的，比如組件、原生接口、IDE、後臺管理、版本管理、訪問控制等基礎支持。
支付寶小程序
策略
微信小程序上線的時候，主場景是線下。希望商家可以開發小程序，做點餐、買票之類的即時應用，提升線下商家體驗。支付寶作為線下戰場的主要競爭對手，自然也要跟進。
支付寶做壹個小程序應該怎麽做？可以根據自己的情況定義另壹個技術體系，讓第三方接入。但在這種情況下，如果第三方想同時接入微信和支付寶，需要開發兩套程序，成本非常高。微信有先發優勢和平臺優勢，很可能變成只開發微信小程序，放棄接入支付寶小程序，所以最好的辦法就是降低這裏的接入成本，讓微信小程序的代碼在支付寶小程序上復用。所以支付寶小程序的外部框架/API/組件必須與微信小程序接近或壹致，沒有技術上的選擇，所以我們可以看到支付寶小程序公測版的很多文檔都與微信壹致。
實現
支付寶小程序框架的對外接口和微信是壹樣的，而且因為管理/安全和體驗的要求是壹樣的，所以有些策略也是類似的，比如獨立的JS環境，離線打包，緩存策略等。，但是小程序框架的實現和微信完全不壹樣。小程序框架作為屏蔽實現細節的DSL層，可以由框架底層通過任何技術手段自由定制。這裏的底層架構是基於螞蟻前端團隊多年的積累，最終在react的基礎上實現web小程序。
反應性
除了和微信壹致的外部web小程序，已經嘗試了ReactNative小程序的內部版本。渲染層不適合webview，但是用RN來渲染，這也是小程序DSL層帶來的好處。底層渲染引擎可以輕松替換實現方案，甚至同時存在多個方案。
很多人問為什麽不用weex？根據我的理解，第壹，螞蟻的前端技術棧基於react，切換成本高，另壹個RN相對成熟，社區支持度高，不斷更新，相對友好。
RN本身是不跨平臺的，iOS/Android有自己的編寫方法。在RN的使用上，很多業內人士已經實現了基於RN的跨三端或兩端的開發模式(如JDReact)，即壹次性開發，可以支持RN在iOS/Android兩端做原生渲染，也支持回退到webview渲染。這裏的小程序也可以算是這樣的方案。上層通過自定義DSL開發業務，部署時通過工具轉換成三個平臺的不同代碼，運行在三個平臺上。
內部應用
小程序是壹套外部解決方案，主要用於接入第三方應用，因為如前所述，框架中的很多技術方案都是為了滿足第三方管理和安全的需求而設計的，很多與小程序相關的體驗優化其實都可以用純H5來實現。用web小程序發展內部業務並沒有帶來什麽好處，反而增加了學習成本。但是RN小程序不壹樣。它有壹些優點，包括:
相比webview，RN的性能優勢明顯，秒開率高，交互更流暢。
相比單純使用RN開發，使用小程序可以屏蔽平臺差異，壹次性實現跨平臺開發。
小程序有開發環境/IDE/包管理等支撐基礎設施支持，不需要重復構建。
對於業務開發者來說，小程序並不是壹套全新的開發方法，可以在行業內重用。對於框架實現者來說，RN也是業內流行的開源解決方案，擁有強大的社區支持。對內對外，避免了另造壹套只能內部使用的技術體系，大大降低了技術成本。
由於這些原因，螞蟻財富中壹些本應由H5實施的業務也試圖更多地使用小程序來改善用戶體驗。目前，基於RN版小程序開發的部分業務已經穩定上線運行，未來將繼續嘗試將RN版小程序打造成高性能、穩定的三端統壹動態解決方案。