了解小程序的由來

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

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

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

小程序與普通網(wǎng)頁開發(fā)的區(qū)別

小程序的開發(fā)同普通的網(wǎng)頁開發(fā)相比有很大的相似性，小程序的主要開發(fā)語言也是 JavaScript，但是二者還是有些差別的。

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

普通網(wǎng)頁開發(fā)渲染線程和腳本線程是互斥的，這也是為什么長時間的腳本運行可能會導(dǎo)致頁面失去響應(yīng)，而在小程序中，二者是分開的，分別運行在不同的線程中。

網(wǎng)頁開發(fā)者在開發(fā)網(wǎng)頁的時候，只需要使用到瀏覽器，并且搭配上一些輔助工具或者編輯器即可。小程序的開發(fā)則有所不同，需要經(jīng)過申請小程序帳號、安裝小程序開發(fā)者工具、配置項目等等過程方可完成。

小程序運行機制

小程序啟動會有兩種情況，一種是「冷啟動」，一種是「熱啟動」。假如用戶已經(jīng)打開過某小程序，然后在一定時間內(nèi)再次打開該小程序，此時無需重新啟動，只需將后臺狀態(tài)的小程序切換到前臺，這個過程就是熱啟動；冷啟動指的是用戶首次打開或小程序被微信主動銷毀后再次打開的情況，此時小程序需要重新加載啟動。

• 小程序沒有重啟的概念
• 當(dāng)小程序進入后臺，客戶端會維持一段時間的運行狀態(tài)，超過一定時間后，會被微信主動銷毀

小程序更新機制

小程序冷啟動時如果發(fā)現(xiàn)有新版本，將會異步下載新版本的代碼包，并同時用客戶端本地的包進行啟動，即新版本的小程序需要等下一次冷啟動才會應(yīng)用上。 如果需要馬上應(yīng)用最新版本，可以使用 wx.getUpdateManager API 進行處理。

小程序安全

作為開發(fā)者，無論是前端開發(fā)者，還是后端開發(fā)者，了解常見的安全問題，以及常見的解決方案是非常必要的。

1.反編譯

非常多原創(chuàng)的微信小程序，被技術(shù)人員通過反編譯技術(shù)或者工具，將完整的代碼反編譯出來。這項技術(shù)自小程序發(fā)布初期到現(xiàn)在都一直存在。多數(shù)開發(fā)者反編譯項目用作學(xué)習(xí)，但也有不少公司，直接利用反編譯市場上的現(xiàn)有的小程序，快速搭建屬于自己的產(chǎn)品，謀取利益。

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

在小程序代碼中，不要寫入敏感數(shù)據(jù)，將敏感數(shù)據(jù)全部放在服務(wù)端?？蛻舳艘褂脮r，通過接口進行請求。反編譯后的代碼都是些前端樣式，這些并沒有太重要。畢竟一般的前端程序員復(fù)刻一個小程序項目，也只是時間問題。

2.接口鑒權(quán)

開發(fā)者很容易通過抓包，第三方工具等方式獲取到小程序的網(wǎng)絡(luò)請求。小程序開發(fā)者應(yīng)當(dāng)在后臺接口被調(diào)用時，對本次調(diào)用進行權(quán)限校驗，包括自建后臺接口和云函數(shù)，否則容易發(fā)生越權(quán)問題和數(shù)據(jù)泄漏。

對于敏感數(shù)據(jù)、開發(fā)能力相關(guān)接口需要在后臺進行鑒權(quán)，通?？蓹z驗openid，IP地址，自定義登錄態(tài)等信息。

鑒權(quán)的邏輯應(yīng)該放在后臺進行，不應(yīng)在小程序中以隱藏頁面、按鈕等方式來代替。

常見的鑒權(quán)示例如下：

//自建后臺鑒權(quán)
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;
        }
}

//云函數(shù)鑒權(quán)
exports.main = async (event, context) => {
   const { OPENID, APPID, UNIONID } = cloud.getWXContext();
   if (OPENID === "xxx") {
         // 進行刪除操作
         // ...
   } else {
         // 記錄非法請求
         // ...
   }
}

3.代碼管理

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

4.內(nèi)容安全

對于包含用戶輸入內(nèi)容，如評論、修改昵稱、頭像等功能。開發(fā)者需要自行調(diào)用信息過濾接口，判定內(nèi)容是否有違規(guī)內(nèi)容。對于沒有配置相應(yīng)功能的小程序，會被警告然后限制搜索。我之前開發(fā)過的一款社區(qū)類目小程序就因為這個原因，被封禁了好久。

5.敏感數(shù)據(jù)安全

對于存儲在本地的敏感數(shù)據(jù)，如用戶信息，openid等數(shù)據(jù)，開發(fā)者應(yīng)當(dāng)對敏感數(shù)據(jù)自行加密存儲。

小程序雙線程架構(gòu)

什么是雙線程架構(gòu)？

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

為什么要選擇雙線程架構(gòu)

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

2.其次：比純web更好的交互體驗，

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

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

首先說小程序的交互體驗肯定是比不上原生app的，app的響應(yīng)速度肯定是最快的，相對指的的h5 web，網(wǎng)頁開發(fā)的渲染線程和腳本線程是互斥的，二者是共享一個線程的，也就是說在運行腳本線程的時候可能會讓頁面失去響應(yīng)，所以這也是為什么我們在開發(fā)網(wǎng)頁的時候需要將script腳本的引入放在body的后面然后winow.onload去知道已經(jīng)渲染完的節(jié)點。而在小程序中渲染線程和邏輯（腳本）線程相互獨立，不能直接干擾對方，渲染線層和邏輯線程可以同時運行。聯(lián)想一下，這是不是從設(shè)計層面就規(guī)避了react16推出fiber架構(gòu)所為了解決的最重要的問題問題（一次大的更新任務(wù)會長時間占據(jù)著當(dāng)前線程的資源，導(dǎo)致頁面無法響應(yīng)帶來的交互問題?。?。

在版本迭代上小程序又有哪些優(yōu)勢呢

我們都知道原生渲染的體驗優(yōu)勢，這也是為什么會出現(xiàn)夸端框架的weex,react native ，flutter的框架去直接生成原生應(yīng)用的方式來進行開發(fā)，但是小程序是依賴于宿主環(huán)境的，小程序的發(fā)版不可能說隨著微信的大版本去迭代，如果是這樣我覺得就和小程序分質(zhì)治理的理念不合了，也會有很多的弊端，并且也不能發(fā)揮web的優(yōu)勢。

那么web的優(yōu)勢是什么呢？–答案是在線更新。–（有啥bug隨時修完！甚至產(chǎn)品經(jīng)理都感知不到?。?，小程序也是在線更新，但是小程序比h5多了另外一項優(yōu)勢–底層資源的動態(tài)注入。h5的腳本資源都是通過請求獲取的，獲取完了之后還要解析，然后再去運行實際的業(yè)務(wù)層面的代碼。而在小程序中在初始化的時候，native(原生層)就會將WXSDK(設(shè)備信息，hls流視頻處理工具，基礎(chǔ)版本庫等)動態(tài)的加載注入到新打開的頁面中，由于小程序的pageFrame（快速渲染設(shè)計）技術(shù)，在后續(xù)打開的頁面中，直接讀取緩存中準(zhǔn)備數(shù)據(jù)，直接省去的解析的過程。小程序這些優(yōu)化直接的效果是（包體積變小，減少了網(wǎng)絡(luò)請求sdk的時間。）

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

新生物種-以小程序為載體的輕應(yīng)用方案

自2017年上線以來，小程序就一直是互聯(lián)網(wǎng)巨頭的“兵家必爭之地”，騰訊、阿里、百度、字節(jié)等都期望借助小程序的能力建設(shè)來豐富自家的生態(tài)，將自家的主流平臺打造成為超級App。

但，時至今日，互聯(lián)網(wǎng)巨頭的蜂擁而至卻反而為小程序開發(fā)者和品牌商家提供了更多元的選擇，使得旗下的小程序應(yīng)用不需要局限在單一平臺生態(tài)之下。

雖然互聯(lián)網(wǎng)大廠并未將這部分小程序運行能力技術(shù)開放出來，但是我們也不必望而生羨，市面上早就推出了類似的技術(shù)能力，我們一般稱之為小程序容器技術(shù)。

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

只需簡單集成  FinClip SDK , 即可在 iPhone、Android、Windows、Linux、macOS、統(tǒng)信等平臺下的應(yīng)用中運行你的小程序。

而且 FinClip SDK 極其輕量，應(yīng)用在集成后安裝包的體積僅僅增大了不到 3MB。

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

FinClip 還自研了一個 小程序 IDE 開發(fā)工具，界面與微信小程序的開發(fā)工具類似，自帶調(diào)試和真機預(yù)覽，簡單易上手。

你可以在這個 FIDE 里面，對現(xiàn)有項目進行二次開發(fā)，擴展功能和接口。

同時，它還支持 小程序一鍵轉(zhuǎn)換成 App，可以將已有小程序代碼導(dǎo)出為 IOS 與 Android 中可用的工程文件,并上架至各應(yīng)用市場 。由于導(dǎo)出的工程文件自動集成了 FinClip SDK ，所以直接擁有小程序的運行能力，后續(xù)可在這個 APP 上繼續(xù)上架更多小程序，自建自己的小程序生態(tài)。

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

在小程序開發(fā)前，需要了解相應(yīng)的問題，以預(yù)防可能出現(xiàn)的問題。在開發(fā)完成后，也要對可能出現(xiàn)問題的地方進行排查，防止出現(xiàn)不要用的損失。

到此這篇關(guān)于微信小程序的運行機制與安全機制解決方案詳解的文章就介紹到這了,更多相關(guān)小程序的運行機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！