跨浏览器和小程序的webGL开发方法、装置和计算机设备

摘要

本申请涉及一种跨浏览器与小程序的webGL开发方法、装置、计算机设备和存储介质。所述方法包括：通过声明canvas对象并补充window全局对象和document全局对象进行标记文档适配；设置canvas对象尺寸，通过canvas对象的getContext函数获取WebGL的上下文环境；通过将小程序中的request与webGL中的XMLHttpRequest对象对应实现网络资源加载适配。采用本方法能够实现webGL在完成浏览器的htlm5标准应用开发后，加入上述适配过程之后可以直接构建小程序版本，使得webGL的开发兼容浏览器应用和小程序应用。

说明书

技术领域

本申请涉及应用开发技术领域，特别是涉及一种跨浏览器和小程序的webGL开发方法、装置、计算机设备和存储介质。

背景技术

随着网页web技术迅猛发展，各类web开发技术栈层出不穷，从“静态网页”、“动态页面”到“单页Web应用(single page web application，SPA)”、“渐进式网页应用(Progressive Web App，PWA)”，web技术栈衍生出众多优秀思想和框架。此外，近年来小程序应用开发需求逐渐扩大，但是传统的基于H5标准的浏览器技术创新不断，也并不会被历史丢弃。对于web应用制作团队来说显然已无法避免同时开发htlm5标准应用和小程序应用，与此同时各家小程序技术存在较大差异、其接口定义与实现各成体系，Webview技术虽具备web页面能力，但对于依赖系统硬件参数的应用来说，不得不使用小程序原生技术重构一版，这使得开发成本几乎是双倍。

针对相关技术中，浏览器与小程序的应用开发不兼容的问题，目前尚未提出有效的解决方案。

发明内容

基于此，有必要针对上述技术问题，提供一种跨浏览器与小程序的webGL开发方法、装置、计算机设备和存储介质。

第一方面，本申请实施例提供了一种跨浏览器与小程序的webGL开发方法，其特征在于，所述方法包括：

通过声明canvas对象并补充window全局对象和document全局对象进行标记文档适配；

设置所述canvas对象尺寸，通过所述canvas对象的getContext函数获取WebGL的上下文环境；

通过将所述小程序中的request与webGL中的XMLHttpRequest对象对应实现网络资源加载适配。

在其中一个实施例中，补充window全局对象包括：设置bindCanvas函数绑定所述canvas对象，并使用全局变量存储所述canvas对象；定义requestAnimationFrame和cancelAnimationFrame作为window的驱动函数。

在其中一个实施例中，所述补充document全局对象包括：通过bindpage函数将小程序当前页面绑定至document对象；定义符合html5标准的getElementById函数；根据所述getElementById函数提供的id查找所述当前页面中的元素；根据所述元素返回所述canvas对象和image对象。

在其中一个实施例中，所述设置所述canvas对象尺寸包括：构建HTMLCanvasElement函数，所述HTMLCanvasElement函数包括style参数，所述style参数包括宽属性和高属性；传入所述canvas对象，获取所述canvas对象宽度设置为所述宽属性，获取所述canvas对象高度设置为所述高属性。

在其中一个实施例中，所述将所述小程序中的request与webGL中的XMLHttpRequest对象对应之后，所述方法还包括：将所述小程序的缓存API与html5标准的localstorage进行适配。

在其中一个实施例中，所述将所述小程序中的request与webGL中的XMLHttpRequest对象对应之后，所述方法还包括：通过构建事件机制实现交互过程，所述事件机制包括Event和EventTarget。

在其中一个实施例中，所述通过构建事件增加交互过程还包括：通过观察者模式构造非html5标准的事件输入与触发的机制。

第二方面，本申请实施例还提供一种跨浏览器与小程序的webGL开发装置，所述装置包括标记文档适配模块、canvas组件适配模块、上下文适配模块和网络资源加载适配模块：

所述标记文档适配模块用于声明canvas对象并补充window全局对象和document全局对象；

所述canvas组件适配模块用于设置所述canvas对象尺寸；

所述上下文适配模块用于通过所述canvas对象的getContext函数获取上下文；

所述网络资源加载适配模块用于将所述小程序中的request与webGL中的XMLHttpRequest对象对应。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现跨浏览器与小程序的webGL开发方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现跨浏览器与小程序的webGL开发方法。

上述跨浏览器与小程序的webGL开发方法、装置、计算机设备和存储介质，通过声明canvas对象并补充window全局对象和document全局对象进行标记文档适配；设置canvas对象尺寸，通过canvas对象的getContext函数获取WebGL的上下文环境；通过将小程序中的request与webGL中的XMLHttpRequest对象对应实现网络资源加载适配，从而实现webGL在完成浏览器的htlm5标准应用开发后，加入上述适配过程之后可以直接构建小程序版本，使得webGL的开发兼容浏览器应用和小程序应用。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本发明实施例的跨浏览器与小程序的webGL开发方法的终端的硬件结构框图；

图2是根据本发明实施例中跨浏览器与小程序的webGL开发方法的流程图；

图3是根据本发明实施例的跨浏览器与小程序的webGL开发方法中资源缓存适配方法流程图；

图4是根据本发明实施例的跨浏览器与小程序的webGL开发方法中内容开发适配方法流程图；

图5是根据本发明实施例的跨浏览器与小程序的webGL开发方法中观察者模式适配方法示意图；

图6是根据本发明实施中跨浏览器与小程序的webGL开发装置的示意图；

图7是根据本发明你实施例中跨浏览器与小程序的webGL开发计算机设备的示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本实施例提供的方法实施例可以在终端、计算机或者类似的运算装置中执行。以运行在终端上为例，图1是根据本发明实施例的跨浏览器与小程序的webGL开发方法的终端的硬件结构框图。如图1所示，终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，可选地，上述终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述终端的结构造成限定。例如，终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的跨浏览器与小程序的webGL开发方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

在一个实施例中，开发基于WebGL的浏览器页面应用和小程序应用的流程种均包括编写标记文档、获取canvas组件、获取WebGL上下文和网络资源加载的过程。由于HTML5标准api与小程序api在上述各个环节均不相同，造成了开发WebGL浏览器应用并将其适配至小程序时工作繁杂。小程序设计模式和运行原理决定了其文档对象模型(Document ObjectModel，简称DOM)的缺失，本实施例中则通过抽象和包装模拟小程序中的缺失api和歧义api，并将其对齐至HTML5标准，即在WebGL应用开发过程中常用接口的适配规范均以HTML5标准为参照。图2是根据本发明实施例中跨浏览器与小程序的webGL开发方法的流程图，如图2所示，提供了一种跨浏览器与小程序的webGL开发方法，以该方法应用于图1中的终端为例进行说明，包括以下步骤：

步骤S210，通过声明canvas对象并补充window全局对象和document全局对象进行标记文档适配。基于WebGL的浏览器页面应用和小程序应用的开发流程中，都包括编写标记文档这一步骤，WebGL应用在标记文档中只依赖组件，因此对于小程序的标记文档可通过统一声明canvas对象，并补充缺失的window和document全局对象以供模拟操作dom元素。

在一些实施例中，补充window全局对象的过程包括：设置bindCanvas函数绑定所述canvas对象，并使用全局变量存储所述canvas对象；设置全局对象requestAnimationFrame和cancelAnimationFrame作为window的驱动函数。WebGL应用常依赖全局对象window.requestAnimationFrame做循环驱动，该系列函数亦包含cancelAnimationFrame；小程序中的canvas对象规则相对凌乱，并且该对象中不仅包含驱动函数，所以使用全局变量存储该canvas对象供后续使用。为实现上述Window两个驱动函数，还增设bindCanvas函数以绑定小程序中当前页面声明的canvas对象，并且定义相应的requestAnimationFrame和cancelAnimationFrame函数。本实施中提供了一种Window对象的高效的实现方式。

在一些实施例中，由于通常情况下dom中的Window指一个文档窗口，在window是文档窗口的情况下，必然包含document对象，因此dom的实现应至少包含requestAnimationFrame、cancelAnimationFrame、document、bindCanvas四个函数。而其中WebGL应用总依赖document.createElementNS创建canvas和Image对象；对于标记文档中元素引用又依赖document.getElementById函数，因此一个最基本的适用于WebGL应用开发的document必须实现createElementNS、getElementById函数。小程序通常都包含.wxml页面,并在canvas组件中提供了等价的createImage函数，所以实现document对象时，可增加非标准接口bindPage函数以绑定页面用以模拟createElementNS。此外，定义符合html5标准的getElementById函数，根据getElementById函数提供的id查找当前页面中的元素；根据当前页面中的元素返回canvas对象和image对象。本实施例中提供了一种简单高效的document对象实现。

经过上述适配，已经可以使用dom方式获取页面中的canvas对象了

步骤S220，设置canvas对象尺寸，通过canvas对象的getContext函数获取WebGL的上下文环境。本步骤中涉及了canvas对象获取以及webGL上下文环境的获取过程的适配。Canvas组件获取中涉及canvas组件尺寸的设置，小程序中canvas组件大都不支持动态设置样式，因而既定canvas全屏范围展示即可，但其中两个属性width、height是必须包含的，所以需要在构建HTMLCanvasElement对象时为其增加style以确保可获取宽高属性。对于WebGL应用，获取canvas对象的目的是为了拿到WebGL的上下文环境以便操作显卡，因而即使是最基础的HTMLCanvasElement实现也应包含getContext函数。对于微信小程序来说，其canvas组件已提供相应的getContext方法，所以使用该方法并暴露相应接口即可。

在一个实施例中，设置canvas对象尺寸的过程包括：构建HTMLCanvasElement函数，HTMLCanvasElement函数包括style参数，style参数包括宽属性和高属性；传入canvas对象，获取canvas对象宽度设置为宽属性，获取canvas对象高度设置为高属性，这是一种高效的设置canvas对象尺寸的方式。

步骤S230，通过将小程序中的request与webGL中的XMLHttpRequest对象对应实现网络资源加载适配。WebGL应用通常使用XMLHttpRequest对象来做资源上传和加载。各小程序均提供不同的request对象，又区别于XMLHttpRequest提供的接口，所以应将凌乱的request统一对齐至XMLHttpRequest对象，根据不同小程序的request进行封装。

步骤S210至步骤S230中，通过声明canvas对象并补充window全局对象和document全局对象进行标记文档适配；设置canvas对象尺寸，通过canvas对象的getContext函数获取WebGL的上下文环境；通过将小程序中的request与webGL中的XMLHttpRequest对象对应实现网络资源加载适配，从而实现webGL在完成浏览器的htlm5标准应用开发后，加入上述适配过程之后可以直接构建小程序版本，使得webGL的开发兼容浏览器应用和小程序应用。

在一个实施例中，图3是根据本发明实施例的跨浏览器与小程序的webGL开发方法中资源缓存适配方法流程图，如图3所示，将小程序中的request与webGL中的XMLHttpRequest对象对应之后，该方法还包括：

步骤S310，将小程序的缓存API与html5标准的localstorage进行适配。对于web应用的每次启动都会是一个全新的页面和作用域，但对于用户来说，每次打开页面都重新下载新资源显然十分费时，WebGL应用也不例外。为达到缓存目的，可以将小程序缓存api对齐至H5标准的localstorage；上述小程序缓存api包含：clear、getItem、key、removeItem、setItem等。通过步骤S310，可以实现资源缓存的适配，使得跨浏览器与小程序的webGL开发方法更加高效。

在一个实施例中，图4是根据本发明实施例的跨浏览器与小程序的webGL开发方法中内容开发适配方法流程图，如图4所示，将小程序中的request与webGL中的XMLHttpRequest对象对应之后，该方法还包括：

步骤S410，通过构建事件机制实现交互过程，所述事件机制包括Event和EventTarget。基础的WebGL应用开发已可通过常规浏览器中Html5页面开发的方式进行，但并无交互(input、click)。因而需要构建一套事件系统，Html5标准事件机制核心为Event和EventTarget，可选地，将所有通过模拟适配方法实现类Window、Document、HTMLCnvasElement、XMLHttpRequest分别继承自EventTarget，对于基础事件在小程序环境下均可使用。本实施例提供了交互的适配实现方法。

在一个实施例中，由于各个小程序对于事件获取的方式各不相同，例如，有的小程序页面内获取事件的机制为声明式，即对应组件事件是开发阶段绑定好的，无法动态修改。因而需要构造一个非Html5标准的事件输入与触发的机制，可选地，使用观察者模式，图5是根据本发明实施例的跨浏览器与小程序的webGL开发方法中观察者模式适配方法示意图，如图5所示，当用户点击触发页面内元素既定的onStart、onMove、onEnd时，实际执行的是Touch对象的inputStart、inputMove、inputEnd函数，由Touch对象将事件汇总，并分发给事件观察者。Touch类应实现TouchSource接口。同时TouchSource应具备获取观察者事件信息的能力，因而有接口定义GetObserver，其返回值(EZXRTouchObserver)应该具备自动触发事件的对象。而对于观察者来说，只需要调取GetObserver即获取观察对象。常规观察事件包含点击、单指、双指操作等，实现方式根据小程序事件机制而定。本实施例中提供了观察者模式的内容开发适配方法，使得跨浏览器与小程序的webGL开发方法中的交互操作的适配方式兼容性更强。

下面通过优选实施例对本申请实施例进行描述和说明。同时开发基于WebGL的浏览器页面应用和小程序应用，全流程包括构建工程、编写标记文档、获取canvas组件、获取WebGL上下文、网络资源加载、资源缓存、内容开发和产出页面。小程序设计模式和运行原理决定了其dom对象的缺失，但可以通过抽象和包装再次模拟缺失api和歧义api，并将其对齐至html5标准，即在WebGL应用开发过程中常用接口的适配规范均以Html5标准为参照。

首先，是标记文档适配。由于小程序构建过程黑箱，无法注入代码或功能修改标准文档本身的解析规则，加之WebGL应用在标记文档中只依赖组件，因此该对于小程序的标记文档仅可做到统一声明canvas组件(标签)；并补充缺失的window和document全局对象以供模拟操作dom元素。

Window对象实现中，WebGL应用常依赖全局对象window.requestAnimationFrame以做循环驱动，该系列函数亦包含cancelAnimationFrame；而小程序中可提供替代同等功能的函数位于小程序canvas对象下。由于小程序canvas规则凌乱且不仅包含驱动函数，所以使用全局变量ElementNS存储该canvas对象供后续使用。为实现上述Window两个驱动函数，应增设bindCanvas函数以绑定小程序中当前页面声明的canvas对象，通常dom中的Window指一个文档窗口，其必然包含document对象，因而实现应至少包含requestAnimationFrame/cancelAnimationFrame、document、bindCanvas四个函数才能适用于WebGL应用。

Document对象实现中，WebGL应用总依赖document.createElementNS创建canvas和Image对象；对于标记文档中元素引用又依赖document.getElementById函数，因此一个最基本的适用于WebGL应用开发的document必须实现createElementNS、getElementById函数。然而小程序中并不存在可操作的文档对象；幸运的是小程序通常都包含.wxml页面,并在canvas组件中提供了等价的createImage函数，所以实现document对象时，需增加非标准接口bindPage函数以绑定页面模拟createElementNS。

经过上述适配，现已经可以使用dom方式获取页面中的canvas对象了，过程中需于小程序的标记文档中声明并顺序调取window.bindCanvas、document.bindPage、document.getElementById便可获取canvas对象了。

然后，获取canvas组件。小程序中canvas组件大都不支持动态设置样式，这也就造成了无法动态调整canvas组件尺寸的问题，现阶段国内各主流小程序中的canvas元素错误诸多，如何解决动态调整问题，已不属于本文阐述范畴。因而既定canvas全屏范围展示即可，但其中两个属性width、height是必须包含的，所以需要在构建HTMLCanvasElement对象时为其增加style以确保可获取宽高属性。

其次，获取WebGLContext。对于WebGL应用，获取canvas对象的目的是为了拿到WebGL的上下文环境以便操作显卡，因而即使是最基础的HTMLCanvasElement实现也应包含getContext函数。对于微信小程序来说，其canvas组件已提供相应的getContext方法，所以使用该方法并暴露相应接口即可。

接着，加载网络资源。WebGL应用通常使用XMLHttpRequest对象来做资源上传和加载。但各小程序均提供不同的request对象，又区别于XMLHttpRequest提供的接口，所以本步骤中将凌乱的request统一对齐至XMLHttpRequest对象。根据不同小程序的request进行封装，实现例如以下XMLHttpRequest接口：通过get readyState()返回一个无符号短整型(unsigned short)数字，代表请求的状态码；通过get response()返回一个ArrayBuffer、Blob、Document，或DOMString，具体是哪种类型取决于XMLHttpRequest.responseType的值；通过responseType返回响应数据的类型，类型允许我们手动的设置返回数据的类型，如果将它设置为一个空字符串，它将使用默认的"text"类型。在设置的类型中，例如，"arraybuffer"response是一个包含二进制数据的JavaScript ArrayBuffer；blob"response是一个包含二进制数据的Blob对象；document"response是一个HTML Document或XML XMLDocument，这取决于接收到的数据的MIME类型。通过get responseURL()返回响应的序列化(serialized)URL，如果该URL为空，则返回空字符串。通过get responseXML():Document|null{}返回一个Document，其中包含该请求的响应，如果请求未成功、尚未发送或时不能被解析为XML或HTML，则返回null。通过get status():number{}返回一个无符号短整型(unsigned short)数字，代表请求的响应状态；返回一个无符号长整型(unsignedlong)数字，表示该请求的最大请求时间(毫秒)，若超出该时间，则请求会自动结束。在一些实施例中，XMLHttpRequest类亦包含Header、Request、Respone、Url等小功能细分类，此处仅列出必要的XMLHttpRequest属性、函数名称，细分类未做说明。

之后，进行资源缓存。对于web应用的每次启动都会是一个全新的页面和作用域，但对于用户来说，每次打开页面都重新下载新资源显然无法忍受，WebGL应用也不例外。为达到缓存目的，需将小程序缓存api对齐至H5标准的localstorage；其中重要api包含：clear、getItem、key、removeItem、setItem，无论淘宝、微信还是支付宝的小程序均提供等价的函数，封装几乎是接口的名称更正，此处不罗列实现形式。

最后，内容开发。经过上述适配流程，基础的WebGL应用开发已可通过常规浏览器中H5页面开发的方式进行，但并无交互(input、click)。因而需要构建一套事件系统，H5标准事件机制核心为：Event、EventTarget，对于这两个类的实现方式各有优劣，可以根据应用场景进行选择。

将之前流程中的模拟实现类Window、Document、HTMLCnvasElement、XMLHttpRequest分别继承自EventTarget，对于基础事件已在小程序环境下可使用。但各家小程序对于事件获取的方式又各不相同，以微信小程序为例，页面内获取事件的机制为声明式，即对应组件事件是开发阶段绑定好的，无法动态修改。因而需要构造一个非Html5标准的事件输入与触发的机制，这里使用观察者模式，当用户点击触发页面内元素既定的onStart、onMove、onEnd时，实际执行的是Touch对象的inputStart、inputMove、inputEnd函数，由Touch对象将事件汇总，并分发给事件观察者。因此Touch类应实现TouchSource接口。同时TouchSource应具备获取观察者事件信息的能力，因而有接口定义GetObserver，其返回值(EZXRTouchObserver)应该具备自动触发事件的对象。而对于观察者来说，只需要调取GetObserver即获取观察对象。常规观察事件包含点击、单指、双指操作，这里仅给出观察者的接口定义，实现方式根据各家小程序事件机制而定。

至此，通过使用Window、Document、HTMLCanvasElement、XMLHttpRequest、Event、EventTarget的适配版本，结合EZXRTouchSource、EZXRTouchObserver，WebGL应用开发者仅需关注web浏览器调试效果，当需要构建小程序版本时，于构建脚本中动态注入以上是适配器即可。

上述跨浏览器与小程序的webGL开发方法，将各个小程序接口统一对齐至html5标准接口，降低了小程序和浏览器应用的适配工作量。

应该理解的是，虽然图2至图5中的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2至图5中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，图6是根据本发明实施中跨浏览器与小程序的webGL开发装置的示意图，如图6所示，提供了一种跨浏览器与小程序的webGL开发装置，该装置包括标记文档适配模块62、canvas组件适配模块64、上下文适配模块66和网络资源加载适配模块68：标记文档适配模块62用于声明canvas对象并补充window全局对象和document全局对象；canvas组件适配模块64用于设置canvas对象尺寸；上下文适配模块66用于通过canvas对象的getContext函数获取上下文；网络资源加载适配模块68用于将小程序中的request与webGL中的XMLHttpRequest对象对应。

关于跨浏览器与小程序的webGL开发装置的具体限定可以参见上文中对于跨浏览器与小程序的webGL开发方法的限定，在此不再赘述。上述跨浏览器与小程序的webGL开发装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，图7是根据本发明你实施例中跨浏览器与小程序的webGL开发计算机设备的示意图，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种跨浏览器与小程序的webGL开发方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述跨浏览器与小程序的webGL开发方法。

上述跨浏览器与小程序的webGL开发计算机设备，通过声明canvas对象并补充window全局对象和document全局对象进行标记文档适配；设置canvas对象尺寸，通过canvas对象的getContext函数获取WebGL的上下文环境；通过将小程序中的request与webGL中的XMLHttpRequest对象对应实现网络资源加载适配，从而实现webGL在完成浏览器的htlm5标准应用开发后，加入上述适配过程之后可以直接构建小程序版本，使得webGL的开发兼容浏览器应用和小程序应用。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述跨浏览器与小程序的webGL开发方法。

上述跨浏览器与小程序的webGL开发计算机可读存储介质，通过声明canvas对象并补充window全局对象和document全局对象进行标记文档适配；设置canvas对象尺寸，通过canvas对象的getContext函数获取WebGL的上下文环境；通过将小程序中的request与webGL中的XMLHttpRequest对象对应实现网络资源加载适配，从而实现webGL在完成浏览器的htlm5标准应用开发后，加入上述适配过程之后可以直接构建小程序版本，使得webGL的开发兼容浏览器应用和小程序应用。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。