功能更新 | 地域分布图表功能上线!

这次的新功能可以说是真“新鲜出炉”了!首页的「概览」中新增了「独立访客」与「国家和地区」两个板块。

独立访客数量(UV)是网站流量分析中十分重要的指标,不仅对运营人员来说是每天都要关注的数据,对网站开发者或是PM而言同样重要。我们在听取了用户建议后,决定将「独立访客」数据单独展示在“概览”中,当日的访客数量一目了然。

同时,想关注当日或历史日活数据,只需在日报中点击对应日期查看即可。👇

另外,在「趋势」栏中,可以看到近两周的页面访问与日活的趋势,是不是很贴心?

接下来聊聊“版图”这件事儿。

FrontJS新增了超酷的地域分布图表功能,在「概览」「性能」以及「日报」中可以找到。增添了这个功能之后,一切都变得简单直观了起来。

值得一提的是,除了当日的独立访问量,同样可以看到当日访客的分布地图,颜色越深代表当日访客量越多。

对于网站开发者来说,看着自己的产品“版图”日益扩张,在这个世界的每个角落留下痕迹,内心想必是澎湃且激动的吧!

在性能栏的「网络请求」页中,可以观测到下载时长的地区分布图,通过颜色的深浅表示网络请求的时长,颜色越深,请求时间越长。

「资源加载」页新增资源加载时长地区分布图,同样的,颜色越深的地区表示资源加载用时越长。

「页面加载」页新增页面加载时长地区分布图,颜色越深的地区表示页面加载用时越长。

地域分布图标功能上线了之后,数据监控变得更加简明清晰,大大节省了用户小伙伴获得数据的时间。「为用户设计」一直是我们设计产品时追求的核心目标,提升产品的可用性也是我们一直在做的事。快来试试新功能吧 👉 https://www.frontjs.com/

轻松玩转数据,看 FrontJS 可视化工具带来的新惊喜

FrontJS 正式上线已经有一些时间了,这个伴随着 Tracup 成长起来的产品虽然年轻,功能却很全面。希望FrontJS 能成为大家维护网站,优化产品的一大利器。今天就来说说FrontJS里的可视化工具。

这个工具可以用来做什么呢?

它主要是对 frontJS 通过网站监控收集来的整体数据通过筛选和过滤后细分展示,让大家可以从庞杂的数据中,根据自己的业务逻辑所需对数据进行重新组合,来满足自己更精细化的工作需求

如何「玩转」可视化工具?

进入 FrontJS 后,在任意一个项目内,点击倒数第二个图标,即可进入可视化工具页面。

可视化工具详情

在左边,我们提供了 5 个展示分类,分别为「访客屏幕精细度分布」、「浏览器类型与页面完全加载时间」、「Windows 操作系统分布」、「最受欢迎页面」以及「页面访问量」。

以「访客屏幕精细度分布」为例,由右方的图表显示我们可以清晰看出,网站访问用户使用的设备屏幕分辨率的具体数据分布,由此可作为前端或设计在贴图、维护考虑分辨率等的参考。

其他 4 个展示分类依次类同。

自己如何定制数据报表?

前面说了,可视化工具,主要是在庞大的数据体系中挖掘并过滤、筛选出有用的数据,以图表形式来清晰展示,以便工作所需。

除过以上 5 类,用户也可自己添加想要的「可视化模板」,点击上部可视化模板右方「添加」,通过对过滤器、指标数据、水平数据等的设置,来对数据进行重新筛选、排列,定制化想要的数据报表。

可视化模板详情

如果你也想通过 FrontJS 更好维护网站?也想通过可视化工具定制数据报表便于工作?这就来 FrontJS 体验一把吧。

FrontJS上线Source Map功能,帮你更有针对性的解决问题

即日起,FrontJS 支持 Source Map 功能。

Source Map 即源码映射,如文件包含源码, 则FrontJS 会主动显示源码,可在项目设置中进行管理。

如何生成 Source Map?

  • 对于不同的前端打包工具, 打开 Source Map 支持的方式是不一样的。

如果在创建项目时使用前端脚手架工具, 那么生成 Source Map 是默认打开的, 生成的 Source Map 默认会与打包好的 JS 脚本文件存放在同一个目录下。
如果在项目在创建时没有使用脚手架工具, 那么则需要手动打开生成 Source Map 的选项, 具体操作需要参照构建工具的文档。

以下是一些常见的构建工具打开生成 Source Map 选项的配置方法:

如何生成包含完整信息的Source Map?

如果 FrontJS 堆栈信息中出现 您的 Source Map 文件不完整 的提示, 说明您上传的 Source Map 文件中没有嵌入源码, 您可以忽略这条提示, 直接按照 Source Map 解析结果去定位您的错误即可, 如果您确实需要堆栈信息中显示源文件而不是混缩的文件, 您需要在 Source Map 生成的过程中嵌入源代码, 则需要打开源码嵌入。
对于不同的前端打包工具, 嵌入源码的设置也不一样, 具体需要参照构建工具的文档。

以下是一些常见的构建工具打开生成 Source Map 选项的配置方法:

微信小程序错误监控经验谈

对于小程序开发者来说,如何进行错误监控一直是个头疼的问题。由于小程序开发迭代较快,会存在系统问题,机型问题和版本的兼容问题,有时候我们在自行测试中完美运行,可总是有用户抱怨使用异常。如果我们对小程序的错误进行有效的监控,可以帮助小程序开发者发现异常,优化代码,用户体验也会随着优化逐步的提升。

小程序的错误监控和 Web 端错误监控具有很多相似性,监控的数据规则基本是一致的,如果你是一名小程序开发者,同时对前端也很熟悉,那么在错误监控方面应该会更加得心应手,但由于小程序自身的特性,在错误监控方面会有以下几点需要注意:

  • 在 Web 端我们监测的是页面完整的url,而小程序端监测的是路由地址;
  • 小程序页面属于微信内部的页面,使用时已全部加载完毕,因此监控页面性能时不统计页面加载时长等信息,更多的是对页面内请求、资源请求和用户行为的监控;
  • 由于微信官方和小程序代码的要求,集成方式对比 Web 端会相对严格一些。

综上,我们可以整理出对于小程序而言哪些数据是需要监控的:

  • JavaScript异常监控:不论是 Web 端还是小程序端,对JavaScript异常的监控都是必要的;
  • 页面内请求监控:对于小程序来说,我们需要统计发送网络请求的wx.request()异常时的请求状态、请求时长、请求地址等;
  • 资源加载监控:当需要下载资源到本地的wx.downloadFile() 出现异常时,统计加载时间、异常类型、资源地址等;
  • 页面性能监控:访问监控、页面来源及流向监控等,方便我们更好的对小程序进行运营;
  • 用户数据统计:用户的分布、操作系统及版本、微信版本、IP 地址等,给错误的分析提供更多条件。

对于小程序出现的错误,我们目前只能在开发者工具上进行追踪和调试,有条件的开发者也可以选择在真机上进行调试,但是小程序大多还是小团队和个人开发者,拥有不同操作系统,不同型号,不同版本的真机进行调试还是不太现实,这里就可能会出现在本地调试中没有出现的问题,且很难定位的到。

在目前的微信小程序后台中,对于上面后两点的监控和统计已经可以实现,用户数据的分析也比较完善,但是对于错误的监控目前还无法实现,这里我们可以借助第三方工具来进行对错误的监控。

这里我们选择错误监控平台 FrontJS 的小程序错误监控:

FrontJS 的小程序错误监控相比于微信小程序后台的数据监控,增加了对于错误的统计和产生错误的相关用户分析,FrontJS可以收集精细到console.log级别的任何JavaScript异常信息并提供 stack trace 信息;对于任何一条错误信息或访问,它都会统计到该用户的IP、屏幕分辨率、DPR、操作系统类型和微信版本,方便我们更有针对性的去调试出现的错误。

使用时我们只需引入 FrontJS 插件,并添加配置代码,即可开启监控。

具体方法:

FrontJS-轻量级的网站错误监控平台​www.frontjs.com

 

  • 进入 FrontJS 后注册账号,登陆后选择创建项目,在创建项目页面的名称后选择“微信小程序”。

在这个页面也可以对不监听的资源和信任域进行设置。

创建完成后,我们只需要根据页面右侧的提示进行操作,就可以完成小程序错误监控的全部设置。

集成完毕后就可以开始错误的监控了,具体界面如下,在左侧菜单栏中我们可以选择不同的条件进行错误的筛选,具体内容各位可以亲自尝试。

FrontJS对微信小程序下已有的相关方法进行了监听,在出现异常或需要监控时,FrontJS会及时发现并统计数据,并且完全不影响小程序的正常运行。

在后续更新中,FrontJS 会继续挖掘可监控到的信息,如用户的位置信息,语言,基础库版本等,对这些信息做更优处理,配合可视化工具,开发者将可以构建出更符合自身需求的数据方案。

干货 | 一份我的前端技术进阶指南

近十年来,前端的发展势头迅猛,每年都会出现不少新的技术和标准。「If you are not growing,then you are dying.」这句名言对于前端工程师同样适用。维持现状就是落后的开始,不断地学习才是必修课。

话说回来,在时间和精力有限的情况下,那么多技术到底该怎么学?其实,技术的本质都是基础的设计模式和编程思想。只有把基础打好,学习新技术才不会吃力,达到「磨刀不误砍柴工」。

快速进阶的方法

首先,「开源项目」「造轮子」是我个人推荐的做法。

参与开源项目贡献的前提是你必须是项目的用户,并且在使用过程中遇到了问题。这样,你才有机会参与开源项目贡献。在遇到 bug 时不只提出 issue ,同时修改代码并且提交 pr,当 pr 被接受时,这个贡献才算完整。

为了达成这个目标,你不得不阅读这些项目的代码,作为此项目的用户,读清楚代码并且和业务相结合是最容易的,在这个过程中,吸收先进的写法和理念,提升会很快。在 pr 提交以后,会有项目成员 review 你的代码并给出修改意见,这是一个非常有意义的过程。那么问题来了,如何在现有的开源项目中找到一个 Bug ,又或者创建合理的特性呢?这还是需要一定功底的。所以说,参与开源项目贡献并不适合初学者提高技术能力。

下面说说造轮子。这也是不错的选择,但是,造出来的轮子很少会被使用在生产环境中,除非你的轮子真的独一无二 —— 因为对于一个项目来说,“稳”是排在第一位的。除了你的技术 Leader, 或许没有人会去关注项目中使用了哪些先进的技术和思想。

如果你的公司有基础建设部门,毫不犹豫的去那里吧,那就是造轮子的地方 —— 并且基本上都在使用原生技术,这里的每一个轮子都有可能变成开源项目。在这里,技术会得到大幅度提升。但是,如果本身技术一般,如何才能进入基础部门也是一个问题。那么就有了下面的内容。

初学者怎么办?

对于 Web 前端工程师来说,前端包含两点,即「呈现」「业务」

对于呈现,那主要是 HTML CSS 的事情,现在大家的浏览器在解析文档方面基本上已经没有太大区别了,所以现在的原生前端开发者很少去关注浏览器兼容的事情,在这里所要做的就是记忆,不要求记住所有,但起码要知道它们都有什么特性,在有需求的时候就不会太过于慌乱。

对于业务,这里主要使用的是 Javascript (ECMAScript) 。既然是编程,在掌握基本语法的基础上还需要了解数据结构、算法、设计模式以及常见的编程范式,这些都是「起高楼」的基本功。

我的建议是,能够简单使用原生语言实现业务后,再考虑使用框架和类库。因为我们知道了基础原理后,使用框架和类库的过程中你就会知道到底发生了什么,只有这样,在更换同类型框架或者类库时才能触类旁通。这一切的一切都源于基本功。所以,沉下心来修炼基础才是重中之重。

方法论

其实对于任何一门「技术」,不论是编程还是修理挖掘机,初学和进阶的模式都是一样的。

1. 先了解行业,掌握基础知识

了解编程是做什么的,数据结构,算法,设计模式,常见的编程范式,这些都是需要掌握的。虽然是老生常谈,但打好基础的确是进阶之路的重中之重

2. 小试牛刀

自己虚拟一个项目试一试,亲自玩一玩,从中必定会有所收获。

3. 上手实践

进入正式的项目,并且经历真正的项目磨练。

4. 总结经验

步骤3 和 步骤4 是循环的过程,当经验足够多时,就可以进行下一步骤了。

5. 传道、授业、解惑

当经验积攒到一定数量,别忘了进行「输出」,方式不设限,可以讲给别人听,也可以和同行进行交流。输出是巩固知识最有效的方式。写程序就是带徒弟做Leader,没事做做开源贡献,弄个开源项目玩玩。

6. 巨大的质疑和迷惑

了解了行业一切运转的规律,思考其原理和内核,提出问题。

「为什么要这样?」「怎么样才会更好?」

7. 创造者

到了这个阶段,所有的技术都要听你的了,当然,也是比较高的阶段。

对于编程者来说也许是制定新版本的语言标准?

与君共勉。

一个彩蛋

“道生一, 一生二, 二生三, 三生万物”

下面这个网站就是“一”

MDN Web Docs

可安装的 Web 应用: 用 JavaScript 与 Node.js 创建 PWAs 实践

翻译自 Peter Mbanugo 的文章,原文链接: nstallable Web Apps: A Practical Introduction To PWAs with JavaScript and Node.js

渐进式 Web 应用 (PWAs) 可以为用户在不稳定网络链接条件下提供更好的操控性,像离线 (offline-first) Web App 就可以在本地保存购物列表 (示例购物车)。这个示例 PWA 使用了 Hoodie 并添加 service worker 使 App 在离线状态下完成加载,当然我们也可以添加更多功能使其变得更好用。

在文本中,我们将会复制这个渐进式 Web 应用并且让这个应用可以被安装。可以被安装那就意味这这个应用需要添加到用户的开始屏幕并且像原生 App 一样的被启动。要让他可以被安装,我们在构建步骤中添加 manifest 文件和 Workbox 以便自动生成 service worker。

准备工作

为了能按照作者的思路来模仿,你需要以下环境和代码:

  1. NodeJS 版本 6.6.0 (或更高)
  2. npm 版本 6.6.0 (或更高)
  3. 示例购物车 PWA 的源代码 Github

如果你已经下载了源代码,那就在命令行中使用 npm install 命令去安装依赖。代码中已经包含了 service worker 并且使用 Cache API 来保存此 App 的资源。

Service worker 是一个可以编程的网络代理,它运行于独立的浏览器线程上,并允许你按照自己的要求来处理拦截的网络请求。

项目中的 service worker 文件位于 public/sw.js,并且已经有了以下内容:


//file -> public/sw.js

const CACHE_NAME = "cache-v1";
const assetToCache = [
  "/index.html",
  "/",
  "/history.html",
  "/manifest.json",
  "/resources/mdl/material.indigo-pink.min.css",
  "/resources/mdl/material.min.js",
  "/resources/mdl/MaterialIcons-Regular.woff2",
  "/resources/mdl/material-icons.css",
  "/css/style.css",
  "/resources/dialog-polyfill/dialog-polyfill.js",
  "/resources/dialog-polyfill/dialog-polyfill.css",
  "/resources/system.js",
  "/js/transpiled/index.js",
  "/js/transpiled/history.js",
  "/js/transpiled/shared.js",
  "/hoodie/client.js"
];
self.addEventListener("install", function(event) {
  event.waitUntil(
    caches
      .open(CACHE_NAME)
      .then(function(cache) {
        return cache.addAll(assetToCache);
      })
      .catch(console.error)
  );
});
self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      if (response) {
        return response;
      }
      return fetch(event.request);
    })
  );
});

由上段代码可知,当我们需要添加或修改资源列表时,我们需要更改 CACHE_NAME 的值来使旧的资源失效并且重新安装 service worker 脚本。这个过程很费事。相反,我们可以在资源发生变化时通过一些配置文件自动生成 service worker 脚本并且自动更新缓存。我们将使用 Workbox 来做这件事情。

使用 Workbox 生成 service worker 脚本

预缓存的资源是那些在被使用签就保存起来的资源。我们的 service worker 虽然预缓存着资源,但是当其中的一些资源发生变化时,service worker 就会删掉所有的旧的缓存资源并且重新下载所有的资源。而 Workbox 会自动产生一个 service worker 脚本,这个脚本只更新变更的缓存资源,不会刷新无关的缓存资源,这样刷新缓存资源会变得更容易。这也是一个更明知的刷新缓存资源的选择,这样做会使我们的 App 运行的更快并且节省网络带宽。

安装 Workbox

因为我们的构建过程简单,我们会让 Workbox 生成整个 service worker 脚本。

运行以下命令来安装 workbox-cli:


npm install -D workbox-cli@2.1.2

将 workbox-cli 添加到构建过程

在项目根目录创建一个名为 workbox-cli-config.js 的文件,这个文件将会自动被 Workbox 使用并生成最终的 service worker 脚本。

将以下内容添加到

workbox-cli-config.js 文件中:


module.exports = {
  globDirectory: "public/",
  globPatterns: ["**/*.{css,ico,html,png,js,json,woff2}"],
  swDest: "./public/sw.js",
  globIgnores: ["icons/*", "js/src/*", "sw.old.js"],
  skipWaiting: true,
  clientsClaim: true,
  templatedUrls: {
    "/hoodie/client.js": "../.hoodie/cleint.js"
  }
};

让我们了解以下配置参数:

  • globDirectory 表示监控变化并且获取资源文件的目录
  • globPatterns 表示那些文件将会为缓存。我们使用通配符来表示所有的具有指定扩展名的文件(包含子目录的文件)都会被缓存
  • swDest 表示输出 service work 脚本文件的位置
  • skipWaiting 表示 service worker 进入等待阶段时尽快的激活,如果我们没有选择 Workbox, 那么我们会等同的在安装实践处理函数中添加 self.skipWaiting();
  • clientsClaim 表示新的 service worker 是否在激活后立即控制所有客户端
  • templatedUrls 用于存放一些基于服务端逻辑的 URL。当请求 /hoodie/client.js 可以在项目中找到相应的文件。

如果这个文件发生变化,当启动构建过程或者刷新 App 时,service worker 会按照配置更新缓存。

好了,现在更新 package.json 通过在 “build” 这一行中添加 && workbox generate:sw 以在构建过程的最后一步调用 workbox 。


"build": "babel public/js/src --out-dir 
public/js/transpiled && workbox generate:sw"

运行以下命令来启动构建:


npm run build

已经存在的 sw.js 文件将会被刷新,内容和以下代码相似:


/**
 * DO NOT EDIT THE FILE MANIFEST ENTRY
 *
 * The method precache() does the following:
 * 1. Cache URLs in the manifest to a local cache.
 * 2. When a network request is made for any of these URLs the response
 *    will ALWAYS comes from the cache, NEVER the network.
 * 3. When the service worker changes ONLY assets with a revision change are
 *    updated, old cache entries are left as is.
 *
 * By changing the file manifest manually, your users may end up not receiving
 * new versions of files because the revision hasn't changed.
 *
 * Please use workbox-build or some other tool / approach to generate the file
 * manifest which accounts for changes to local files and update the revision
 * accordingly.
 */
const fileManifest = [
  {
    "url": "css/style.css",
    "revision": "99559afa2b600e50f33cebcb12bd35e6"
  },
  {
    "url": "favicon.ico",
    "revision": "2ec6120d215494c24e7c808d0d5abf56"
  },
  {
    "url": "history.html",
    "revision": "240e2a52b8580117383162e8ec15fc00"
  },
  {
    "url": "index.html",
    "revision": "4a215dad3782fb0715224df00149cee9"
  },
  {
    "url": "js/transpiled/history.js",
    "revision": "f5d6af7aff37147b0c82043fe3153828"
  },
  {
    "url": "js/transpiled/index.js",
    "revision": "3b5384eca25ad783829434ee190ecb58"
  },
  {
    "url": "js/transpiled/shared.js",
    "revision": "38039d6e28ad31c85c4adc0c4bab2dc9"
  },
  {
    "url": "manifest.json",
    "revision": "cfada03439f24ccdb59dae8d4f6370d1"
  },
  {
    "url": "resources/dialog-polyfill/dialog-polyfill.css",
    "revision": "24599b960cd01b8e5dd86eb5114a1bcb"
  },
  {
    "url": "resources/dialog-polyfill/dialog-polyfill.js",
    "revision": "a581e4aa2ea7ea0afd4b96833d2e527d"
  },
  {
    "url": "resources/mdl/material-icons.css",
    "revision": "35ac69ce3f79bae3eb506b0aad5d23dd"
  },
  {
    "url": "resources/mdl/material.indigo-pink.min.css",
    "revision": "6036fa3a8437615103937662723c1b67"
  },
  {
    "url": "resources/mdl/material.min.js",
    "revision": "713af0c6ce93dbbce2f00bf0a98d0541"
  },
  {
    "url": "resources/mdl/MaterialIcons-Regular.woff2",
    "revision": "570eb83859dc23dd0eec423a49e147fe"
  },
  {
    "url": "resources/system.js",
    "revision": "c6b00872dc6e21c1327c08b0ba55e275"
  },
  {
    "url": "sw1.js",
    "revision": "0a3eac47771ce8e62d28908ee47a657f"
  },
  {
    "url": "/hoodie/client.js",
    "revision": "1d95959fa58dcb01884b0039bd16cc6d"
  }
];
const workboxSW = new self.WorkboxSW({
  "skipWaiting": true,
  "clientsClaim": true
});
workboxSW.precache(fileManifest);

文件第一行 importScripts('workbox-sw.prod.v2.1.2.js') 会导入 Workbox 的 service worker 库。你会注意到项目目录中出现了同名的文件。如果你不小心删掉了它,请不要担心。当你在命令行中运行 generate:sw 时也会创建同样的文件。

有了这些新的设置,在命令行中运行 ‘npm start’ 并在浏览器中打开 localhost:8080 并打开控制台来查看 service worker 诗如歌更新的,允许在进入等待阶段是跳过等待阶段 (waiting phase) 。

添加 manifest 文件

manifest 是一个 JSON 文件,用于提供应用信息(比如, 应用的名字和图标等)和控开始屏幕下的外观 (比如智能手机开始屏幕,Windows 10 开始屏幕之类的). manifest 同样定义着当 App 启动时显示启动画面和启动后显示的页面或 URL。

我们需要添加一个 manifest.json 文件来为用户提供应用的元数据。在 public 目录下添加一个名为 manifest.json 的文件,并包含以下内容:


{
  "name": "Shopping List",
  "short_name": "ShoppingList",
  "theme_color": "#00aba9",
  "background_color": "#00aba9",
  "display": "standalone",
  "orientation": "landscape",
  "scope": "/",
  "start_url": "/",
  "icons": null
}
  • name 为 app 的名字,这个名字将会在安装弹窗中出现
  • short_name 会出现在安装后的 app 图标下面
  • theme_color 应用开打后 App bar 的颜色
  • background_color 启动状态和加载状态之间是显示的启动页面的背景颜色
  • display 定义应用的显示模式,Standalone 表示呈现为一个单独安装的应用
  • orientation 定义应用的显示的横竖屏设置
  • scope 用于定义应用的范围,当导航页面超过这个范围后,将会以正常的网页形式显示
  • start_url 表明启动页的位置
  • icons 用户定义不同尺寸下的图标以适配不同设备的屏幕尺寸

注意我们虽然将 icons 设置为 null。 但是我们需要 icon 用于图钉,推送通知,安装横幅和启动画面。从这里下载 一个 512×512 尺寸的 icon , 在浏览器中打开 https://app-manifest.firebaseapp.com 并上传刚下好的 icon,这个网页将会为你生成应用所需各种尺寸的 icon。

生成图标

点击 “Generate .ZIP” 按钮即可下载 manifest 文件以及所需的图标,既然我们已经有了 manifest 文件,我们只需要 zip 文件中的图标。解压 zip 文件,复制 icons 目录于项目 public 目录下,替换项目 manifest.json 文件 icons 属性的值为:


"icons": [
    {
      "src": "/icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
]

安装

我们把之前创建的 manifest.json 文件,链接到 public 目录中的 index.htmlhistory.html 文件中后,应用就可以安装了!你可以通过运行 npm run build && npm start 再次构建并且启动它。在浏览器中打开你的应用,浏览器将会安装最新的 service worker。然后尝试把应用添加到开始屏幕或者桌面上。

使用 Chrome 添加 App 到桌面上:

  1. 在开发者工具栏中打开 Applications 选项卡
  2. 在侧边栏中选择 “Manifest”
  3. 点击 “Add to homescreen”。你将会在地址栏上看到一个弹窗,点击 “Add” 并且安装到桌面 App 中

Chrome 安装

打包

我们提到了如何使用 Workbox 来生成 service worker 脚本、manifest 的概念及如何提供 App 安装过程中所需信息。我们还使用 https://app-manifest.firebaseapp.com 来生成不同尺寸的图标,当然你也可以添加其他信息一并生成一个的 manifest.json 文件。

现在,你的应用已经可以安装了,你可以部署到你偏爱的主机服务上并让所有人都可以安装。

你可以在 github 上找到本项目的代码。

以下优质资源可以作为参考:
Web App Manifest
Web App Manifest Generator
Workbox
Offline-First with Node.js and Hoodie: A Practical Introduction to Progressive Web Apps

关于作者

Peter Mbanugo 专注于离线应用,持续研究更好的方式来构建更快更轻量级更高效的 Web 应用服务。
任何时间可以通过 p.mbanugo@yahoo.com 和 Twitter (@p_mbanugo) 与作者取得联系。