我們一直都認為桌面應用中的瀏覽器是HTML5的“天下”，事實上，技術的進步，會給我們技術人帶來持續不斷的驚喜。小程式的技術及生態，似乎在重複著HTML5當初繁盛一時的技術景象，未來發展如何，讓我們拭目以待。

眾所周知的小程式，都知道其誕生地是微信。最開始的願景，是希望透過自定義一套全新的介面開發模式，來實現將微信能力安全、可控的開放使用。與此同時，微信團隊也希望能夠透過小程式規避掉之前用 Web 開發會遇到的各種問題，比如渲染卡頓、載入白屏時間長等問題，提供類似於原生的體驗、安全易用的微信資料開放、更多端能力的提供、簡單高效的開發方式。

其核心是前端容器化，分為UI和資料兩個層面。

• UI層面容器化，微信的解決方案很簡單，就是重新建立一套元件，完全拋棄 DOM 的標準元件。這樣就可以做到 UI 上的完全可控和安全。
• 資料層面容器化，本質上就是 JS 的沙盒，避免開發者直接拿到 UI 及其資料，這也就誕生了小程式和別的差別最大的地方——雙執行緒架構。

這個架構簡單科普一下，分為：

• 邏輯層: 執行在端內建立的 JS 執行緒中，使用者的業務程式碼在該執行緒中執行，如你的 js 程式碼
• 渲染層: 執行在端建立的 WebView 中，使用者的模板和樣式程式碼在其中執行，如你的 wxml、wxss 程式碼

那麼為什麼要如此設計呢？其實最最主要地目的就是為了"安全"（並不是為了保障渲染的更順暢）是的，這是一個加了引號的安全，這裡的安全是對小程式的平臺方來說的。任何軟體平臺都有它的遊戲規則，比如 UI 介面的一致性，網路請求域的收斂，平臺功能限制等，只是小程式稍有不同的是雖然是基於 web 技術，但並不想讓開發者使用到全量的 web 技術。所以把使用者的程式碼放到一個脫離 web 的執行緒中去執行就是一個最穩妥的方案了。

技術標準及業務生態的演變

不得不說，小程式無論在技術標準還是業務生態發展，經歷過近幾年的發展，都已經有質的飛躍。相比於十幾年前的HTML5技術和生態，有過之而無不及。
1、先說說技術標準
從Web 1.0進化到2.0之後的十幾年間，移動App都是各大軟體提供商用於爭奪消費者碎片化時間的主戰場。HTML5這種標準化的、普適的文字化內容編碼格式，被廣泛應用，並最終成為了網際網路的基石之一。Web2.0向3.0的進化過程中，軟體技術標準的擴充套件，小程式類技術的編碼和內容格式，整體基於HTML5基礎上，更加輕量，也更加開放有生命力。
從標準的角度看，當前網際網路上的小程式類技術，幾乎都借鑑了這個領域的先行者微信的規範。可以說，微信小程式就是這個領域的“既成事實”標準。故此網際網路系列全球標準的制定者W3C，也正在透過其Mini-Apps工作組制定國際標準。

2、再說說小程式業務生態
從2017年微信推出小程式開始，經過四年發展，各大網際網路巨頭紛紛推出自己的小程式應用平臺，小程式成為真正意義上的“網際網路新技術標準”。截至2021年上半年，全網小程式數量突破700萬個，其中，微信小程式是行業主流，數量超過430萬個，佔比高達約61.43%。

PC端執行小程式已成為事實

雖然大家都預設在智慧裝置中執行小程式的能力是一線網際網路企業的“專利”，事實上，已經有第三方公司開發了小程式引擎，並能夠跑在手機、Windows、Mac、Linux、統信、麒麟等智慧裝置作業系統上，FinClip小程式容器技術便是其中之一。這意味著，移動端、PC 端、IOT等智慧終端都能執行小程式了。

跨端框架，在一些大廠的小程式平臺中，有開始出現框架反制小程式引擎的問題。比如開發者想要對小程式自定義元件的時序進行一些最佳化，讓其更加符合現代框架標準，卻發現強依賴了這個框架的時序，導致開發者根本無法將最佳化立馬上線，因為一旦最佳化，用了跨端框架的小程式幾乎全部無法執行。

體驗了一下FinClip，並不會出現這種情況，反而對跨端框架非常的友好（據他們的官網開發者文件中介紹，FinClip支援包括 uniapp、 Taro、kbone 等第三方框架整合的小程式，感興趣的同學可以瀏覽下： 小程式容器開發文件）