[發明專利]信息處理裝置、信息處理方法以及存儲介質

在審

• 申請號: 201910375861.0
• 申請日: 2019-05-07
• 公開（公告）號: CN110109728A
• 公開（公告）日: 2019-08-09
• 發明（設計）人: 徐錦添;李海軍;劉博;呂洪震
• 申請（專利權）人: 安徽省渠道網絡股份有限公司
• 主分類號: G06F9/451
• 分類號: G06F9/451;G06F9/445;G06F8/41;G06F8/38
• 代理公司: 北京怡豐知識產權代理有限公司 11293
• 代理人: 遲軍

本發明提供信息處理裝置、信息處理方法以及存儲介質。該信息處理裝置能夠與外部裝置進行通信，所述信息處理裝置具有用于顯示信息的顯示單元，所述信息處理裝置包括：接收單元，其被構造為從外部裝置接收配置文件；解析單元，其被構造為對接收單元接收到的配置文件進行解析，以獲得用于顯示的UI信息；以及渲染單元，其被構造為基于解析單元獲得的UI信息，更新所述顯示單元的顯示配置。

技術領域

本發明涉及信息處理裝置、信息處理方法以及存儲介質。具體地，涉及一種能夠實現動態改變頁面布局及功能的動態渲染方法。

背景技術

傳統上，存在如下一種動態渲染庫(UIBuilder)，圖2示出了該動態渲染庫的框架圖。其中，RN(react-native)框架讓JS開發者可以大部分使用JS代碼就可以構建一個跨平臺APP。Facebook官方說法是learn once,run everywhere，即在Android、IOS、Browser各個平臺，程序畫UI和寫邏輯的方式都大致相同。因為JS可以動態加載，從而理論上可以做到write once,run everywhere，當然要做額外的適配處理。RN需要一個JS的運行環境，在IOS上直接使用內置的javascriptcore，在Android則使用webkit.org官方開源的jsc.so。此外還集成了其他開源組件，如fresco圖片組件、okhttp網絡組件等。RN會把應用的JS代碼(包括依賴的framework)編譯成一個js文件(一般命名為index.android.bundle)，RN的整體框架目標就是為了解釋運行這個js腳本文件，如果是js擴展的API，則直接通過bridge調用native方法；如果是UI界面，則映射到virtual DOM這個虛擬的JS數據結構中，通過bridge傳遞到native，然后根據數據屬性設置各個對應的真實native的View。bridge是一種JS和JAVA代碼通信的機制，用bridge函數傳入對方module和method即可得到異步回調的結果。

對于JS開發者來說，畫UI只需要畫到virtual DOM中，不需要特別關心具體的平臺,還是原來的單線程開發，還是原來HTML組裝UI(JSX)，還是原來的樣式模型(部分兼容)。RN的界面處理除了實現View增、刪、改、查的接口之外，還自定義一套樣式表達CSSLayout，這套CSSLayout也是跨平臺實現。RN擁有畫UI的跨平臺能力，主要是加入Virtual DOM編程模型，該方法一方面可以照顧到JS開發者在html DOM的部分傳承，讓JS開發者可以用類似DOM編程模型就可以開發原生APP，另一方面則可以讓Virtual DOM適配實現到各個平臺，實現跨平臺的能力，并且為未來增加更多的想象空間，比如react-cavas、react-openGL。而實際上react-native也是從react-js演變而來。

對于Android開發者來說，RN是一個普通的安卓程序加上一堆事件響應，事件來源主要是JS的命令。主要有兩個線程，UI main thread和JS thread。UI thread創建一個APP的事件循環后，掛在looper等待事件，事件驅動各自的對象執行命令。JS thread運行的腳本相當于底層數據采集器，不斷上傳數據，轉化成UI事件，通過bridge轉發到UI thread，從而改變真實的View。后面再深一層發現，UI main thread跟JS thread更像是CS模型，JSthread更像服務端，UI main thread是客戶端，UI main thread不斷詢問JS thread并且請求數據，如果數據有變，則更新UI界面。

然而，現有的動態渲染庫存在如下缺陷：開發體驗一般，文檔很粗略，兩個平臺還沒有完全統一，控件不完善，升級RN版本需要大動干戈，而且要做出優質app需要花費大量人力和時間去打磨。

發明內容