網(wǎng)站 ICP 備案已施行了很久，我們也非常清楚必須在進行 ICP 備案后，網(wǎng)站才能在大陸范圍合法運營，并且用戶可以通過域名正常訪問網(wǎng)站。

但是月初出了新規(guī)，明年起，國內(nèi)的 App 也要像網(wǎng)站一樣進行備案了。想必大家也是早已經(jīng)聽到過這個刷屏的新聞，隨便說一聲小程序也是。

在管理日益強化的背景下，開發(fā)者也會隨之而來面臨到一些新困境和變化。

對開發(fā)者的影響

1、提高了開發(fā)門檻

小規(guī)模個人開發(fā)者難以單獨完成備案流程，可能需要通過阿里、騰訊等公司平臺進行合作或服務(wù)，一般情況會下放備案入口給云廠商。

2、影響開發(fā)的周期

開發(fā)者還密切相關(guān)的是備案規(guī)則會要求提供安裝包的MD5值，那么也就是意味著形式上可能會讓每次更新都備案一次。

3、強調(diào)信息安全

備案將信息安全作為重要評估標準，開發(fā)者再進行用戶隱私信息獲取的過程中，需要注意產(chǎn)品中信息收集及使用情況符合隱私保護規(guī)定，切勿過度的收集信息。

當然還有一個可能性就是 App 備案不是版本審核，而是像網(wǎng)站一樣審核期間需要處于不能訪問的狀態(tài)，最后不管網(wǎng)站呈現(xiàn)的什么內(nèi)容，主要就是最前面的審核資質(zhì)流程。

但是不管最后落地的備案規(guī)則具體是什么樣子的，對于技術(shù)本身來說，辦法肯定會比困難更多。如果每一次更新發(fā)版都要填寫一次備案表格，那么尋找符合規(guī)則的開發(fā)模式也是一個必然選擇。

開發(fā)模式選擇

從我的角度思考，以后 App 熱更新能力會成為一個必選項，而熱更新又有兩條路子可以走：

1、混合應(yīng)用

Webview 加載網(wǎng)頁做 Hybrid 混合應(yīng)用，其實也就是大家比較熟知的「原生+ HTML5」模式了，它的工作原理是App 的服務(wù)器端要監(jiān)測這些內(nèi)容的更新，然后向設(shè)備端的 App 以某種技術(shù)手段發(fā)送內(nèi)容更新的通知，然后里面的一些組件，需要向客戶端通過網(wǎng)絡(luò)同步一些頁面內(nèi)容碎片，并且把這些下載的內(nèi)容，通常是 HTML 和JavaScript，注入到之前挖好的這些洞洞里。

另外中間網(wǎng)絡(luò)同步的技術(shù)方案有很多，例如通過雙向的 Web-Socket，或者通過 HTTPlongpolling ，或者通過SSE，或者通過 PushtoPull，又或者其他自定義的技術(shù)手段例如 CMS 實現(xiàn)。設(shè)備端通常通過 HMR 熱模塊替換和代碼注入等方式讓更新的代碼在本地生效展示，避免 App 重啟。

另一個混合應(yīng)用開發(fā)的辦法是「原生+小程序」，其實我更推薦這種方法，一是小程序在國內(nèi)已經(jīng)非常成熟而且整體的體驗度會遠高于 HTML5 ，至少卡頓、白屏的情況不會經(jīng)常性的出現(xiàn)。二是這個模式已經(jīng)在微信、支付寶等超級 App 已經(jīng)驗證過，確實這類輕量的技術(shù)會在熱更新上更加靈活，只需要配合管理后臺的上下架就能實現(xiàn)。目前這種技術(shù)稱為小程序容器技術(shù)，市場上比較成熟例如 FinClip ，屬于開箱即用的，對開發(fā)者會比較友好。

另外也有純粹的 Web App 這種模式就不推薦大家了，一是性能不好對于設(shè)備、網(wǎng)絡(luò)的要求比較高，二是這種模式只適合一些非常簡單的業(yè)務(wù)，這里也就不做過多的說明。

2、類加載機制

走 Java Classload 類加載機制，核心的原理就是從網(wǎng)絡(luò)流讀取字節(jié)碼加載 Class，即通過類加載器讀取.class文件中的二進制字節(jié)流，并將其轉(zhuǎn)換成Java虛擬機中的 Class 對象。主要的過程包括加載、驗證、準備、解析和初始化。

當然這個機制會比上面的更加復(fù)雜一些，整體的內(nèi)容也會比較系統(tǒng)，這里就不作過于深入的介紹，感興趣的同學們可以進一步查詢相關(guān)的知識點介紹。

寫在后面

在 App 審核日益增加的情況下，對于開發(fā)者群體肯定有不小的影響，特別是中小開發(fā)者和一些國外開發(fā)者來講會增加不小的阻隘。但是為了更好的適應(yīng)改變、擁抱變化，我們可以從技術(shù)角度出發(fā)去進行優(yōu)化，當然肯定還有其他大佬有更好的辦法也歡迎大家給出好的建議。