了解小程序的由來(lái)

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

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

• 快速的加載
• 更強(qiáng)大的能力
• 原生的體驗(yàn)
• 易用且安全的微信數(shù)據(jù)開(kāi)放
• 高效和簡(jiǎn)單的開(kāi)發(fā)

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

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

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

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

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

小程序運(yùn)行機(jī)制

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

• 小程序沒(méi)有重啟的概念
• 當(dāng)小程序進(jìn)入后臺(tái)，客戶端會(huì)維持一段時(shí)間的運(yùn)行狀態(tài)，超過(guò)一定時(shí)間后，會(huì)被微信主動(dòng)銷毀

小程序更新機(jī)制

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

小程序安全

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

1.反編譯

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

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

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

2.接口鑒權(quán)

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

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

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

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

//自建后臺(tái)鑒權(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") {
            // 進(jìn)行刪除操作
            // ...
            return 0;
        } else {
            // 記錄非法請(qǐng)求
            // ...
            return -1;
        }
}

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

3.代碼管理

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

4.內(nèi)容安全

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

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

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

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

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

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

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

1.最重要的點(diǎn)： 這個(gè)一個(gè)基于安全于管控的方案

2.其次：比純web更好的交互體驗(yàn)，

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

為什么說(shuō)小程序有著相對(duì)較好的交互體驗(yàn)

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

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

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

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

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

新生物種-以小程序?yàn)檩d體的輕應(yīng)用方案

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

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

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

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

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

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

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

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

你可以在這個(gè) FIDE 里面，對(duì)現(xiàn)有項(xiàng)目進(jìn)行二次開(kāi)發(fā)，擴(kuò)展功能和接口。

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

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

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

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

最新評(píng)論