微信小程序的運行機制與安全機制解決方案詳解

瞭解小程序的由來

在小程序沒有出來之前,最初微信WebView逐漸成為移動web重要入口,微信發佈瞭一整套網頁開發工具包,稱之為 JS-SDK,給所有的 Web 開發者打開瞭一扇全新的窗戶,讓所有開發者都可以使用到微信的原生能力,去完成一些之前做不到或者難以做到的事情。

但JS-SDK 的模式並沒有解決使用移動網頁遇到的體驗不良的問題,比如受限於設備性能和網絡速度,會出現白屏的可能。因此又設計瞭一個增強版JS-SDK,也就是“微信 Web 資源離線存儲”,但在復雜的頁面上依然會出現白屏的問題,原因表現在頁面切換的生硬和點擊的遲滯感。這個時候需要一個 JS-SDK 所處理不瞭的,使用戶體驗更好的一個系統,小程序應運而生。

  • 快速的加載
  • 更強大的能力
  • 原生的體驗
  • 易用且安全的微信數據開放
  • 高效和簡單的開發

小程序與普通網頁開發的區別

小程序的開發同普通的網頁開發相比有很大的相似性,小程序的主要開發語言也是 JavaScript,但是二者還是有些差別的。

普通網頁開發可以使用各種瀏覽器提供的 DOM API,進行 DOM 操作,小程序的邏輯層和渲染層是分開的,邏輯層運行在 JSCore中,並沒有一個完整瀏覽器對象,因而缺少相關的DOM API和BOMAPI。

普通網頁開發渲染線程和腳本線程是互斥的,這也是為什麼長時間的腳本運行可能會導致頁面失去響應,而在小程序中,二者是分開的,分別運行在不同的線程中。

網頁開發者在開發網頁的時候,隻需要使用到瀏覽器,並且搭配上一些輔助工具或者編輯器即可。小程序的開發則有所不同,需要經過申請小程序帳號、安裝小程序開發者工具、配置項目等等過程方可完成。

小程序運行機制

小程序啟動會有兩種情況,一種是「冷啟動」,一種是「熱啟動」。假如用戶已經打開過某小程序,然後在一定時間內再次打開該小程序,此時無需重新啟動,隻需將後臺狀態的小程序切換到前臺,這個過程就是熱啟動;冷啟動指的是用戶首次打開或小程序被微信主動銷毀後再次打開的情況,此時小程序需要重新加載啟動。

  • 小程序沒有重啟的概念
  • 當小程序進入後臺,客戶端會維持一段時間的運行狀態,超過一定時間後,會被微信主動銷毀

小程序更新機制

小程序冷啟動時如果發現有新版本,將會異步下載新版本的代碼包,並同時用客戶端本地的包進行啟動,即新版本的小程序需要等下一次冷啟動才會應用上。 如果需要馬上應用最新版本,可以使用 wx.getUpdateManager API 進行處理。

小程序安全

作為開發者,無論是前端開發者,還是後端開發者,瞭解常見的安全問題,以及常見的解決方案是非常必要的。

1.反編譯

非常多原創的微信小程序,被技術人員通過反編譯技術或者工具,將完整的代碼反編譯出來。這項技術自小程序發佈初期到現在都一直存在。多數開發者反編譯項目用作學習,但也有不少公司,直接利用反編譯市場上的現有的小程序,快速搭建屬於自己的產品,謀取利益。

對於這樣的問題,微信官方並沒有做出太多反制措施。畢竟小程序模擬的是瀏覽器,一般的前端項目,在瀏覽器端右鍵即可查看源碼,在控制臺可以查看網絡請求等更加詳細的信息。

在小程序代碼中,不要寫入敏感數據,將敏感數據全部放在服務端。客戶端要使用時,通過接口進行請求。反編譯後的代碼都是些前端樣式,這些並沒有太重要。畢竟一般的前端程序員復刻一個小程序項目,也隻是時間問題。

2.接口鑒權

開發者很容易通過抓包,第三方工具等方式獲取到小程序的網絡請求。小程序開發者應當在後臺接口被調用時,對本次調用進行權限校驗,包括自建後臺接口和雲函數,否則容易發生越權問題和數據泄漏。

對於敏感數據、開發能力相關接口需要在後臺進行鑒權,通常可檢驗openid,IP地址,自定義登錄態等信息。

鑒權的邏輯應該放在後臺進行,不應在小程序中以隱藏頁面、按鈕等方式來代替。

常見的鑒權示例如下:

//自建後臺鑒權
function actionDelete(){
    $item_id = $_POST["item_id"]; 
    $openid = $_POST["openid"];
    $ip = $_SERVER['REMOTE_ADDR'];
    $user_role = $_SESSION["user_role"];
    if ($openid === "xxx" &&
        $ip === "192.168.0.101" &&
        $user_role === "admin") {
            // 進行刪除操作
            // ...
            return 0;
        } else {
            // 記錄非法請求
            // ...
            return -1;
        }
}
//雲函數鑒權
exports.main = async (event, context) => {
   const { OPENID, APPID, UNIONID } = cloud.getWXContext();
   if (OPENID === "xxx") {
         // 進行刪除操作
         // ...
   } else {
         // 記錄非法請求
         // ...
   }
}

3.代碼管理

當使用 git、 svn 等版本管理工具時,會產生 .git 等目錄。某些編輯器或軟件也會在運行過程中生成臨時文件。若這些目錄或文件被帶到生產環境,則可能發生源碼泄漏。

4.內容安全

對於包含用戶輸入內容,如評論、修改昵稱、頭像等功能。開發者需要自行調用信息過濾接口,判定內容是否有違規內容。對於沒有配置相應功能的小程序,會被警告然後限制搜索。我之前開發過的一款社區類目小程序就因為這個原因,被封禁瞭好久。

5.敏感數據安全

對於存儲在本地的敏感數據,如用戶信息,openid等數據,開發者應當對敏感數據自行加密存儲。

小程序雙線程架構

什麼是雙線程架構?

一條線程負責處理邏輯層一條線程負責處理渲染層。線程之間通過native層通信。

為什麼要選擇雙線程架構

1.最重要的點: 這個一個基於安全於管控的方案

2.其次:比純web更好的交互體驗,

3.原生版本迭代更為便捷 小程序選擇的是webview+原生組件的形式,hybrid方式,既享受到瞭webview頁面的低門檻和在線更新,🈶️可以使用部分流暢的native原生組件,並且最重要的是空對開發的內容進行一定程度按的管控,同時在安全問題從設計層面就予以瞭解決。

為什麼說小程序有著相對較好的交互體驗

首先說小程序的交互體驗肯定是比不上原生app的,app的響應速度肯定是最快的,相對指的的h5 web,網頁開發的渲染線程和腳本線程是互斥的,二者是共享一個線程的,也就是說在運行腳本線程的時候可能會讓頁面失去響應,所以這也是為什麼我們在開發網頁的時候需要將script腳本的引入放在body的後面然後winow.onload去知道已經渲染完的節點。而在小程序中渲染線程和邏輯(腳本)線程相互獨立,不能直接幹擾對方,渲染線層和邏輯線程可以同時運行。聯想一下,這是不是從設計層面就規避瞭react16推出fiber架構所為瞭解決的最重要的問題問題(一次大的更新任務會長時間占據著當前線程的資源,導致頁面無法響應帶來的交互問題!)。

在版本迭代上小程序又有哪些優勢呢

我們都知道原生渲染的體驗優勢,這也是為什麼會出現誇端框架的weex,react native ,flutter的框架去直接生成原生應用的方式來進行開發,但是小程序是依賴於宿主環境的,小程序的發版不可能說隨著微信的大版本去迭代,如果是這樣我覺得就和小程序分質治理的理念不合瞭,也會有很多的弊端,並且也不能發揮web的優勢。

那麼web的優勢是什麼呢?–答案是在線更新。–(有啥bug隨時修完!甚至產品經理都感知不到!),小程序也是在線更新,但是小程序比h5多瞭另外一項優勢–底層資源的動態註入。h5的腳本資源都是通過請求獲取的,獲取完瞭之後還要解析,然後再去運行實際的業務層面的代碼。而在小程序中在初始化的時候,native(原生層)就會將WXSDK(設備信息,hls流視頻處理工具,基礎版本庫等)動態的加載註入到新打開的頁面中,由於小程序的pageFrame(快速渲染設計)技術,在後續打開的頁面中,直接讀取緩存中準備數據,直接省去的解析的過程。小程序這些優化直接的效果是(包體積變小,減少瞭網絡請求sdk的時間。)

小程序現在版本迭代的模式下,忽略微信審核的環節的話,基本上可以做到99%用戶的在線更新。但是並不完全,在有新版本迭代的情況下,雖然微信不支持強制更新,但是我們可以在交互層面上,強提示交互讓用戶更新。但是不知何種原因(估計是用戶微信版本和小程序基礎庫版本的問題)無法做到100%,這是從後臺監控的sdk所反饋的數據。

新生物種-以小程序為載體的輕應用方案

自2017年上線以來,小程序就一直是互聯網巨頭的“兵傢必爭之地”,騰訊、阿裡、百度、字節等都期望借助小程序的能力建設來豐富自傢的生態,將自傢的主流平臺打造成為超級App。

但,時至今日,互聯網巨頭的蜂擁而至卻反而為小程序開發者和品牌商傢提供瞭更多元的選擇,使得旗下的小程序應用不需要局限在單一平臺生態之下。

雖然互聯網大廠並未將這部分小程序運行能力技術開放出來,但是我們也不必望而生羨,市面上早就推出瞭類似的技術能力,我們一般稱之為小程序容器技術。

今天要給大傢分享的也正是目前在 GitHub 很熱門的前端容器技術 —— FinClip 。

隻需簡單集成  FinClip SDK , 即可在 iPhone、Android、Windows、Linux、macOS、統信等平臺下的應用中運行你的小程序。

而且 FinClip SDK 極其輕量,應用在集成後安裝包的體積僅僅增大瞭不到 3MB。

下面這個功能特性對於研發人員應該會比較友好, FinClip 支持微信小程序語法 WXML,也就是說微信小程序代碼可以直接在 FinClip 復用,無需再二次開發,體驗與微信端保持一致。

FinClip 還自研瞭一個 小程序 IDE 開發工具,界面與微信小程序的開發工具類似,自帶調試和真機預覽,簡單易上手。

你可以在這個 FIDE 裡面,對現有項目進行二次開發,擴展功能和接口。

同時,它還支持 小程序一鍵轉換成 App,可以將已有小程序代碼導出為 IOS 與 Android 中可用的工程文件,並上架至各應用市場 。由於導出的工程文件自動集成瞭 FinClip SDK ,所以直接擁有小程序的運行能力,後續可在這個 APP 上繼續上架更多小程序,自建自己的小程序生態。

並且 FIDE 中還包含各類擴展插件和接口(支付、人臉識別、音視頻、OCR 等),開發者可自主勾選所需的支持插件,從而增強所生成 App 原生能力。

在小程序開發前,需要瞭解相應的問題,以預防可能出現的問題。在開發完成後,也要對可能出現問題的地方進行排查,防止出現不要用的損失。

到此這篇關於微信小程序的運行機制與安全機制解決方案詳解的文章就介紹到這瞭,更多相關小程序的運行機制內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: