1. 首頁 > 云知道 > >

卡片代碼生成器 json卡片代碼( 三 )

云知道json

  • 當用戶已安裝優酷主客時，中轉頁自動打開優酷主客的播放頁，并退出 。
    • 數據請求在優酷主客中，網絡數據的請求都是通過統一的網絡庫訪問的 。由于優酷鴻蒙卡片并未集成網絡庫，優酷鴻蒙卡片必須使用其他方式請求網絡接口 。
    要實現在鴻蒙上發起數據請求，有兩個方案：
    • 一是針對每個數據請求接口，封裝一個新的HTTP Open API接口，客戶端可以通過HTTP(S)直接訪問；
    • 二是客戶端通過H5頁面里的JS版Network庫發起數據請求 。
    考慮到將來在鴻蒙系統上有可能實現更多其他的需求，且第一種方案有安全性的風險，所以最終我們采用了第二種方案 。
    前端業務使用的JS版本的網絡庫，其使用方式是通過JS中的Promise機制來實現異步回調，但是這種方式在Java中并不好實現對應的調用結構 。所以這里需要有一層封裝，將網絡請求結果通過簡單回調來通知請求方 。相應的在Java側需要對WebView注冊全局的JS對象，實現JS對象的回調方法，打通JS -> Java的調用通路 。
    這個方案在紙面上看著還不錯，但是在實際使用中會發現有嚴重的性能瓶頸 。WebView本身是一個很重的控件，在進程中首次創建的時候會比較耗時，有很多的so加載、初始化等工作 。加載HTML是一個網絡請求，耗時在百毫秒級，而加載并解析完HTML以后，還要再加載JS版本的網絡庫，又是一次網絡訪問 。等JS網絡庫加載并解釋執行后，才可以正常服務調用方 。
    要在這個過程中進行優化，這里有主動權的地方就是加載HTML和JS網絡庫這兩個文件 。在鴻蒙系統中，WebView可以通過設置WebAgent來實現特定URL的劫持，將其轉化為讀取本地資源中的HTML和JS文件 。
    public class LoadAgent extends WebAgent {// ...@Overridepublic ResourceResponse processResourceRequest(WebView webView, ResourceRequest request) {// mInterceptor用于識別HTML和JS網絡庫的URL，并返回本地資源中的HTML和JS 。ResourceResponse response = mInterceptor.intercept(request);if (response != null) {return response;}return super.processResourceRequest(webView, request);}}這可以將兩個百毫秒級的串行操作縮減為毫秒級，大大減少JS版本的網絡庫的初始化時間 。
    數據緩存從網絡請求返回的卡片數據，除了用于即時渲染卡片之外，還會被保存一份到本地存儲中 。如果下一次發起網絡請求的時候，無法正常訪問網絡（例如手機重啟后一時連不上網絡），則可以使用緩存中的卡片數據先渲染一下，使用戶不至于完全看不到內容 。這就需要有一套卡片數據的緩存管理能力 。
    針對卡片數據的特點，我們使用了兩個數據庫表來存儲卡片的緩存數據 。根據卡片大小不同，請求中會提供不同的參數給服務端 。反過來說，同樣大小的卡片發出請求的參數是相同的，也就是說同樣大小的卡片請求得到的數據是相同的 。所以有一個表用來存儲不同大小的卡片數據，每個卡片大小對應一條記錄，包括唯一標識、卡片大小、請求返回的數據、時間戳等 。
    系統不限制用戶向桌面添加卡片的數量，同時在服務中心也可以有已經添加到桌面的卡片 。所以同樣的卡片數據是可以被顯示在多個卡片上的 。數據庫需要有一個表來記錄每一個卡片的信息，包括卡片的唯一標識、卡片大小、數據表中對應的記錄等 。
    如果在Android中實現過ContentProvider，一般都會比較熟悉SQLite數據庫 。通常ContentProvider需要管理大量、不同類型且互相有關聯的數據，這種需求用SQLite來實現最合適了 。這里管理卡片數據的緩存也具有同樣的特征，并且鴻蒙系統也提供了SQLite數據庫的使用接口 。典型的數據庫初始化操作如下:

    推薦閱讀