繼前面的文章中我們解析了小程式平台的架構，本次我們将解讀在基于 Web 技術開發出來的小程式，它們都能從平台獲得哪些 APIs 支援。
小程式托管平台 — 功能展望與想法
小程式在發展的過程中，如果要具備更多原生應用的一些特征與功能，勢必繞不開 APIs 功能的提供。下面有幾點小程式發展的建議，和大家分享。
混合渲染
小程式是 Web 渲染和原生渲染的混合解決方案。但是，它們的渲染時分開進行的。例如，在小程式中有一個搜尋框，這個搜尋框可以是原生應用來渲染，然後搜尋的結果可以用 Web 來渲染。
如果有一種很好的方法可以将 Web 和本機的渲染結果結合起來，那就太好了。是以，在發展的過程中，小程式期望能有一個标準化的 API 來幫助其将原生渲染的結果內建到 Web 渲染結果中。
過渡動畫
Web 中我們經常會用到 transition，而小程式想在頁面切換時提供過渡動畫是難以做到的。是以，讓使用者有類似使用原生應用時的體驗，也是小程式發展過程中需要解決的。
規範的打包方式
小程式可以通過标準化的分發格式，為多個小程式托管平台形成打包和解析約定。目前，各個小程式托管平台提供的開發工具不同（打包方式不同），小程式在不同的小程式托管環境中解析也不同。是以，期望未來能夠統一打包的方式，并做到規範化。
例如，小程式實際上是分發過程中打包（壓縮）的檔案集合。 我們可以用統一的檔案字尾來描述一個小程式（.ma），并指定如何建立.ma檔案以及如何解析.ma檔案。
标準化小程式頁面的導航
一個小程式中的頁面，可能在另一個小應用中被引用，期望在使用者通路時被準确喚起。是以，可以定義一個标準化的協定（URI 方案）來通路小程式。
小部件
目前小程式還無法與 Android 或 Apple 應用一樣，使用者可以通過安卓應用或蘋果應該提供的小部件直接擷取資訊和/或使用 小部件完成任務，而無需打開任何 Web 或應用程式頁面。
是以，期望在發展的過程中，小程式的小部件也可以顯示在 Web 浏覽器之外的環境中，例如桌面或儀表闆。
同時，這個小部件還應具備如下功能：
- 可以顯示在主機環境中，可以是 WebView 或原生應用程式頁面。宿主環境加載一個帶有相應 URI 路徑的小部件，該路徑描述了一個包和小部件頁面。
- 可以通路本地資料或來自伺服器的資料。同時，可以與同一個包中的小程式通信。
- 應該是互動式的，這意味着它應該響應任何使用者行為/互動。小程式的小部件應該能夠打開 Web 或應用程式頁面。
性能與調優
例如，在做Web 應用測試的時候，我們會通過 TTI 名額測試應用的性能。是以，也希望在小程式上能知道小程式的頁面，它的 TTI 是何時完成的。
要解決這個問題，需要提供一個标準化事件，用于通知小程式頁面互動事件的完成。
圖形與媒體
3D
3D模型因其豐富的細節而變得越來越流行。結合 AR，它們将提供比 2D 更好的使用者體驗。相關的業務案例可能包括線上購物、廣告、教育等。但是，目前的 Web 缺乏标準和便捷的方式來處理 3D 模型。是以，建議定義一個 HTML 标簽來直接處理 3D 模型，類似于我們使用相應的 HTML 标簽處理音頻、視訊和圖像的方式。
面部跟蹤
平時在短視訊平台中，我們看到在實時視訊中，可以對人們添加面部效果。例如，全屏濾鏡、面部重塑和化妝、2D 貼紙、3D 頭飾等。而這些效果中的大多數在很大程度上依賴于來自視訊源的實時面部跟蹤。
解決這類問題，我們可以使用人臉跟蹤的 API，将視訊元素作為輸入，并在每一幀更新人臉跟蹤輸出，其中包括：
- 每張面部的邊界框
- 每張面部的 4x4 姿勢矩陣
- 歸一化 (x, y) 坐标點
- 面部的幾何資料，包括頂點、法線、紋理坐标
同時，除了面部跟蹤，手勢跟蹤也是相同的原理。
可以看到，上面的一些展望可以讓 小程式越來越具備原生應用的功能與體驗。當然，個人認為不能完全将兩者等同的發展，每個類型的應用都應具備其自身發展方向。