卡片代码生成器 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数据库的使用接口。典型的数据库初始化操作如下: