专栏首页前端架构与工程Typescript+WebGL+Webpack开发环境搭建

Typescript+WebGL+Webpack开发环境搭建

目前Web实现矢量渲染的主流技术包括SVG、VML和WebGL。相对而言,VML是一种较古老的技术,虽然未成为W3C标准,但被早期的IE浏览器(IE9以下)和微软Office广泛使用,目前已经远离了浏览器战场。所以可供选择的仅剩SVG和WebGL。SVG是XML的一个子集,秉承了一个标签对应一条数据的原则,目前经常被使用于数据量较小的web项目,比如图表和地铁图。Web矢量地图的数据量非常庞大,举个例子,如下图所示的一个512px*512px的瓦片,其数据量是一个接近5位数的二维数组。而这个瓦片仅仅是最简单的大陆和海洋轮廓,同尺寸街道图的数据量更加庞大。

处理庞大的数据量必然对性能的要求非常苛刻,况且由于中间隔着一层浏览器,Web地图并不能完全发挥CPU的计算能力。在有限的CPU资源下如果能够借助其他计算资源则必事半功倍,能够调用GPU资源的WebGL便成为了唯一的选择。

SVG不适合开发Web矢量地图的原因主要有两点:

  • 无法借助GPU提高性能;
  • Web地图交互非常频繁,比如移动、缩放、旋转等等,如果使用SVG则需要借助频繁操作DOM实现,而DOM操作是浏览器最消耗性能的行为。

技术选型

确定了底层技术-WebGL之后,接下来需要选择合适的辅助技术,针对目标有两点:

  • JavaScript
  • 构建工具

WebGL渲染与CSS无关,所以CSS开发框架的选型对整体的影响微乎其微,在此略过。

WebGL可以理解为OpenGL在浏览器环境下的变种,保留了OpenGL ES的语义和规范,提供相对简洁的JavaScript API。绝大部分的shader可以实现WebGL和OpenGL的共用。开发WebGL shader的语言GLSL是一种语法接近C的强类型编程语言。这一点对于习惯了JavaScript的前端开发者们需要一定的调整。既然是调整,那么不妨调整的彻底一些:将整体开发都引入强类型的概念。目前支持在JavaScript中引入强类型的主流框架有两种:TypeScript和Flow.js。TypeScript是JavaScript的强类型超集,Flow则更接近于一种类型注解或者注释工具。相对而言,引入Flow的成本更低,你可以自由决定哪些文件开启或者关闭类型检查,仅仅需要在文件顶部添加一行注释:

// @flow

所以Flow非常适合现有的项目进行迁移,而如果使用TypeScript则更需要将全部源代码进行改写。好在目前要做的项目并没有历史包袱,所以Flow的这点优势并不能作为技术选型的决定性因素。

最终选择TypeScript的原因有以下几点:

  • 语法更严谨甚至有些繁琐,但习惯之后非常顺手;
  • 生态更丰富,目前大部分主流第三方库均提供TypeScript支持。

ES6正式推出了Typed Array标准,但其实早在ES6之前,支持WebGL的浏览器就已经提供了强类型数组的API,目的是为了提高计算性能。

构建工具的选择相对比较多,Webpack、Rollup、gulp都是非常优秀的工具。最终选择Webpack的原因非常简单:比较熟。

构建配置

Webpack的配置与常规的web项目大体相同,需要注意的两点是:

  • TypeScript与Babel的配合
  • shader的构建

TypeScript&Babel

TypeScript本身支持编译为ES5或ES3,即将tsconfig.json的编译选型target修改为"es5"/"es3":

{
  "compilerOptions": {
    "target": "es5"
  }
}

TypeScript编译器对于语法规范的转译功能可以满足绝大多数ES6新功能,但是其功能的全面性相比较Babel仍然有些不足,所以为了对编译进行更精准的控制,项目中采用的方案是将TypeScript首先转译为ES6语法,再借助Babel将其转译为ES5,即将tsconfig.json中的compilerOptions.target设置为"es6",webpack配置如下:

module: {
    rules: [{
      test: /\.ts$/,
      exclude: /node_modules/,
      use: ['babel-loader','awesome-typescript-loader']
    }
}

Webpack编译TypeScript的loader有两个:ts-loaderawesome-typescript-loader。最终选择后者的原因当然不是因为它的名字中有个awesome,而是相对于前者,awesome-typescript-loader能够提供一些更加便利的功能,比如alias-别名。

如果源码的目录结构比较复杂,引用一个模块时可能需要写很长的路径名称,比如:

import Utils from '../../../utils';

为了令代码具有更好的易读性,我们通常借助一些工具将模块的引用设置较短的别名。Webpack也有此功能,通过resolve配置模块的别名:

resolve: {
  alias: {
    'utils': path.resolve(__dirname,'src/utils')
  }
}

但遗憾的是ts-loaderawesome-typescript-loader并不能直接使用Webpack的alias配置,源码中直接使用模块别名将会抛出not found错误,请注意这个错误是TypeScript编译器抛出而非Webpack。解决方案很简单:在tsconfig.json中配置模块别名。如下:

{
  "paths": {
    "utils/*": ["src/utils/*"]
  }
}

但这并不是最终的解决方案,因为如果使用ts-loader作为Webpack集成的话,Webpack并不能获取tsconfig.json的别名配置,也就是说,Webpack将会抛出not found错误。awesome-typescript-loader很好地解决了这个问题,它可以将tsconfig.json的别名配置映射至Webpack的resolve.alias。当然,如果你仍然坚持使用ts-loader也可以解决,如果你不怕麻烦的话:在Webpack中手动配置同样的resolve.alias

另外需要注意的是,使用awesome-typescript-loader需要在Webpack的resolve中创建对应的插件:

const TsConfigPathsPlugin = require('awesome-typescript-loader').TsConfigPathsPlugin;

module.exports = {
  module: {
    rules: [{
      test: /\.ts$/,
      exclude: /node_modules/,
      use: ['babel-loader','awesome-typescript-loader']
    },
    // other rules
    ]
  },
  resolve: {
    plugins: [
      new TsConfigPathsPlugin({
        configFileName: Path.resolve(__dirname,'../tsconfig.json')
      })
    ]
  }
}

shader

WebGL创建shader的流程为:

  1. 首先创建指定类型的shader实例;
  2. 将shader源码与实例绑定;
  3. 编译shader。

示例代码如下:

const source = `
precision mediump float;

attribute vec2 a_pos;

uniform vec4 u_color;
uniform vec2 u_resolution;
uniform vec2 u_translate;

varying vec4 v_color;

void main() {
    vec2 real_poistion = (a_pos+u_translate) / u_resolution * 2.0 - 1.0;
    gl_Position = vec4(real_poistion * vec2(1, 1), 0, 1);
    v_color = u_color;
}`;
// 创建shader实例
const Shader = gl.createShader(gl.VERTEX_SHADER);
// 绑定shader源码
gl.shaderSource(Shader,source);
// 编译
gl.compileShader(Shader);

shader的源码以字符串的形式绑定至shader实例,也就是说,不论shader的源码是用什么编程语言编写(比如可以按照上述代码中用JavaScript字符串编写,也可以直接用glsl语言编写),一定要保证以字符串的形式引入shader源码模块。秉承这项原则,最简单的shader构建方案便是上述代码中的字符串形式。比如将上述示例代码中的shader源码单独抽离为vertex.js如下:

export default `
precision mediump float;

attribute vec2 a_pos;

uniform vec4 u_color;
uniform vec2 u_resolution;
uniform vec2 u_translate;

varying vec4 v_color;

void main() {
    vec2 real_poistion = (a_pos+u_translate) / u_resolution * 2.0 - 1.0;
    gl_Position = vec4(real_poistion * vec2(1, 1), 0, 1);
    v_color = u_color;
}`;

然后在主文件中引入:

import VertexShaderSource from './vertex.js';
// 创建shader实例
const Shader = gl.createShader(gl.VERTEX_SHADER);
// 绑定shader源码
gl.shaderSource(Shader,VertexShaderSource);
// 编译
gl.compileShader(Shader);

这种书写方式优点是不需要对Webpack进行任何配置,但是却等于放弃了IDE对glsl语法的高亮、纠错等辅助功能。如果shader源码只有几行倒也没什么大问题,但是对于几十上百行的代码如果没有高亮辅助的话可能会严重影响开发效率。

解决这个问题的办法要从两方面入手:

  • 令Webpack能够正确编译glsl代码;
  • 令TypeScript能够将glsl模块与ts模块融合。

第一个问题很好解决,因为我们的目的是把glsl模块引入到js模块中并且作为字符串使用,所以Webpack要做的就是将glsl源码构建为字符串即可:

{
  test: /\.glsl$/,
  loader: 'raw-loader'
}

raw-loader的功能是将被引入的文件内容转换为字符串。

除了强类型带来的开发模式转变以外,TypeScript最大的问题是不能自动识别ts以外的任何其他类型模块,即使最普遍的JSON也不行。比如下述代码在TypeScript环境下会报not found错误:

import Data from '../data.json';

这时候需要用到TypeScript的声明文件。声明文件的作用简单来说就是告知TypeScript编译器一些必要的信息以便被正确识别。比如声明一些全局的类型(type)、接口(interface)、模块(module)等。

默认情况下,TypeScript编译器会自动识别源码和node_modules目录中@types文件夹内的声明文件,你也可以通过配置tsconfig.jsoncompilerOptions.typeRoots指定声明文件目录。针对上文提到的TypeScript不识别glsl和json模块问题,我们在源码目录的@types文件夹中创建声明文件global.d.ts,内容如下:

declare module '*.glsl';
declare module '*.json';
declare type WidthAndHeight = {
  width: number;
  height: number;
};

上述代码中声明了三个信息:

  • 声明glsl后缀类型的文件为可识别模块;
  • 声明json后缀类型的文件为可识别模块;
  • 声明全局类型WidthAndHeight,此类型将在任何源码文件中直接使用。

在以上配置的基础上还有一个注意事项:与ES6 modules不同的是,TypeScript引入declare声明的非ts模块并不能将其内容自动转化为默认导出,即export default。比如在ES6环境下引入一个json文件:

import JsonData from './data.json';

而在TypeScript环境下需要使用以下语法:

import * as JsonData from './data.json';

示例代码

具体代码可以参考demo:https://github.com/ihardcoder/demo_ts-webgl-webpack

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 《微信小程序七日谈》- 第六天:小程序devtool隐藏的秘密

    《微信小程序七日谈》系列文章: 本系列的文章并非初学教程,而是笔者在具体开发过程中遇到的问题以及部分解决方案。 笔者参与的小程序项目开发也进入尾声了,坑也踩得...

    寒月十八
  • 前端工程师的基本素养

    阅读原文 闲来无事,今天随便聊聊前端工程师应该具备哪些素质,权当博大家一笑。 前端工程师到底是工作很简单的“切图仔”,还是包揽客户端和中间层的“大前端”?招聘市...

    寒月十八
  • 利用Decorator和SourceMap优化JavaScript错误堆栈

    最近收到用户吐槽 @cloudbase/js-sdk(云开发Cloudbase的JavaScript SDK)的报错信息不够清晰,比如下面这条报错:

    寒月十八
  • 嵌入式(触摸板库tslib的编译和配置)

    作为基本输入设备,触摸板几乎是交互式嵌入式系统的标配。当我们知道了可以通过设备节点读取触摸板数据后,我们需要进一步优化这些直接获取的原生数据,比如去抖、消噪、校...

    用户2617681
  • Android多线程:手把手教你使用IntentService(含实例讲解)

    步骤1:定义 IntentService的子类,需复写onHandleIntent()方法 步骤2:在Manifest.xml中注册服务 步骤3:在Acti...

    Carson.Ho
  • DelayQueue 源码分析

    我们先来看一下它的实现类图,它实现了 Delayed、BlockingQueue 接口和 AbstractQueue 基础类,从实现的功能上看,它首先是一个阻塞...

    itliusir
  • 一次诡异的线上数据库的死锁问题排查过程

    前几天,线上发生了一次数据库死锁问题,这一问题前前后后排查了比较久的时间,这个过程中自己也对数据库的锁机制有了更深的理解。本文总结了这次死锁排查的全过程,并分析...

    Java3y
  • 图解 VueLoader : .vue 文件是如何被打包的?

    导语 | 在 Vue 开发中,单文件组件(SFC,.vue 文件)的组件形态很常见,本文意在梳理和分享 SFC 的打包流程,便于大家对 SFC 的解析细节有所了...

    腾小云
  • 论跨PC和移动平台socket库yasio的设计和实现原理

    之前分享的文章是对yasio特性和用法的描述:https://blog.csdn.net/xseekerj/article/details/51891362 本...

    simdsoft
  • Spring boot结合Zuul Ribbon Eureka Admin的小demo

    小程故事多

扫码关注云+社区

领取腾讯云代金券