[發(fā)明專利]基于Weex的快遞服務(wù)APP更新方法、裝置、設(shè)備及存儲(chǔ)介質(zhì)

在審

• 申請?zhí)枺?/td>: 202011005363.6
• 申請日: 2020-09-22
• 公開（公告）號(hào): CN112256296A
• 公開（公告）日: 2021-01-22
• 發(fā)明（設(shè)計(jì)）人: 林振欽;朱曉輝
• 申請（專利權(quán)）人: 上海東普信息科技有限公司
• 主分類號(hào): G06F8/65
• 分類號(hào): G06F8/65;G06F8/71;G06F9/445
• 代理公司: 上海漢聲知識(shí)產(chǎn)權(quán)代理有限公司 31236
• 代理人: 胡晶

一種基于Weex的快遞服務(wù)APP更新方法、裝置、設(shè)備及存儲(chǔ)介質(zhì)，其中，更新方法包括步驟：響應(yīng)用戶的應(yīng)用啟動(dòng)指令，對快遞服務(wù)APP配置文件所配置的Weex頁面對應(yīng)的JS Bundle文件、及快遞服務(wù)APP配置文件所對應(yīng)的灰度發(fā)布配置文件進(jìn)行預(yù)先下載，并保存至本地存儲(chǔ)；根據(jù)用戶發(fā)起的頁面訪問請求獲取所關(guān)聯(lián)的JS Bundle文件，并依據(jù)獲取的JS Bundle文件對訪問的快遞服務(wù)APP的Weex頁面進(jìn)行更新。本申請的技術(shù)方案可以實(shí)現(xiàn)一套代碼同時(shí)運(yùn)行在android、ios、web三端，減少開發(fā)成本，提高開發(fā)效率；可以實(shí)現(xiàn)熱更新，實(shí)現(xiàn)代碼動(dòng)態(tài)下發(fā)的功能；支持預(yù)加載，提高頁面加載速度，性能媲美原生；支持多種灰度策略，方便A/B測試，支持不同網(wǎng)點(diǎn)，優(yōu)先嘗鮮新功能；快速開發(fā)新業(yè)務(wù)，方便驗(yàn)證。

技術(shù)領(lǐng)域

本發(fā)明涉及快遞技術(shù)領(lǐng)域，具體涉及一種基于Weex的快遞服務(wù)APP更新方法、裝置、設(shè)備及存儲(chǔ)介質(zhì)。

背景技術(shù)

用戶在業(yè)務(wù)上對互聯(lián)網(wǎng)產(chǎn)品(例如快遞服務(wù)APP)體驗(yàn)、迭代速度、效果驗(yàn)證等方面的優(yōu)化訴求越來越強(qiáng)烈，因此，互聯(lián)網(wǎng)產(chǎn)品通常需要不停的升級(jí)更新以更好的實(shí)現(xiàn)其功能和滿足用戶需求。傳統(tǒng)的互聯(lián)網(wǎng)產(chǎn)品需要修復(fù)bug或者發(fā)布新功能都是通過應(yīng)用商店來發(fā)版，需要用戶升級(jí)安裝APP。一方面受限于第三方應(yīng)用商店審核周期長問題，另一方面，bug的修復(fù)不能及時(shí)的在用戶無感的條件下修復(fù)。

近年來，互聯(lián)網(wǎng)行業(yè)中涌現(xiàn)出一些互聯(lián)網(wǎng)產(chǎn)品動(dòng)態(tài)化方案，具體如下：

(1)基于H5的熱更新方案

APP內(nèi)嵌套H5頁面這種方式，可以隨時(shí)的動(dòng)態(tài)的修改H5頁面的內(nèi)容，可以實(shí)現(xiàn)新業(yè)務(wù)的隨時(shí)隨地發(fā)布，實(shí)現(xiàn)新業(yè)務(wù)立即觸達(dá)用戶的效果。缺點(diǎn)也是比較明顯的，對網(wǎng)絡(luò)要求比較高，性能相比原生App差距比較大，用戶體驗(yàn)不及原生APP。

(2)React Native跨平臺(tái)熱更新

React Native是由Facebook開發(fā)的一款跨平臺(tái)框架，可以實(shí)現(xiàn)一套代碼同時(shí)運(yùn)行在Android和IOS端，底層是通過原生控件進(jìn)行渲染，性能遠(yuǎn)超H5，同時(shí)可以實(shí)現(xiàn)熱更新的效果。缺點(diǎn)是：RN通過JS訪問平臺(tái)UI組件，所以需要通過Bridge橋接器將JS轉(zhuǎn)換到原生，在UI被頻繁操作時(shí)可能導(dǎo)致性能問題。

(3)原生熱修復(fù)方案

面向移動(dòng)設(shè)備的線上修復(fù)服務(wù)，為APP線上版本提供靜默更新，細(xì)粒度修復(fù)能力，幫助開發(fā)者實(shí)時(shí)修復(fù)線上問題，敏捷發(fā)布輕量級(jí)功能。優(yōu)點(diǎn)是：無需APP升級(jí)版本，通過補(bǔ)丁下發(fā)，即可靜默方式完成線上變更，常用于快速修復(fù)線上缺陷。缺點(diǎn)是：由于是在應(yīng)用運(yùn)行期間發(fā)生了變動(dòng)，如果修改了某個(gè)方法的邏輯，就會(huì)導(dǎo)致它在修復(fù)前后的邏輯不一致，引發(fā)一些詭異的錯(cuò)誤。因此熱替換方式的熱修復(fù)只適用于修復(fù)一些簡單的BUG，如果要做一些功能方面的更新，不建議采用。

(4)原生插件化

將Apk(APP安裝包)按照功能模塊劃分，不同的功能打包成不同的Apk，然后應(yīng)用的主Apk按需加載對應(yīng)功能的Apk，用戶只需要安裝應(yīng)用的主Apk即可，主Apk相當(dāng)于一個(gè)殼，它會(huì)按需加載其他功能模塊的Apk。優(yōu)點(diǎn)是：通過這種模式，不僅解決了Apk體積大的問題，而且當(dāng)某個(gè)功能模塊需要變化時(shí)，也只需要修改對應(yīng)功能的代碼，打包功能Apk并更新即可，這樣不僅可以讓用戶及時(shí)更新，而且更新的代價(jià)也很小。同時(shí)可以做到功能APK熱插拔的效果。缺點(diǎn)是：由于需要大量Hook的系統(tǒng)源碼，所以需要對系統(tǒng)的apk代碼加載和資源加載流程以及系統(tǒng)其他源碼有足夠深的了解，加上Android系統(tǒng)的不同版本的兼容性問題，導(dǎo)致不同系統(tǒng)版本的源碼有所差異，就會(huì)導(dǎo)致我們的插件化方案有兼容性問題，維護(hù)成本高。

(5)小程序方案