H5缓存机制浅析-移动端Web加载性能优化【干货】

fox
作者:贺辉超,腾讯游戏平台与社区产品部 高级工程师

目录
1 H5缓存机制介绍
2 H5缓存机制原理分析
2.1 浏览器缓存机制
2.2 Dom Storgage(Web Storage)存储机制
2.3 Web SQL Database存储机制
2.4 Application Cache(AppCache)机制
2.5 Indexed Database (IndexedDB)
2.6 File System API
3 移动端Web加载性能(缓存)优化

1 H5缓存机制介绍

H5,即HTML5,是新一代的HTML标准,加入很多新的特性。离线存储(也可称为缓存机制)是其中一个非常重要的特性。H5引入的离线存储,这意味着 web 应用可进行缓存,并可在没有因特网连接时进行访问。

H5应用程序缓存为应用带来三个优势:

离线浏览 – 用户可在应用离线时使用它们
速度 – 已缓存资源加载得更快
减少服务器负载 – 浏览器将只从服务器下载更新过或更改过的资源。

根据标准,到目前为止,H5一共有6种缓存机制,有些是之前已有,有些是H5才新加入的。

浏览器缓存机制
Dom Storgage(Web Storage)存储机制
Web SQL Database存储机制
Application Cache(AppCache)机制
Indexed Database (IndexedDB)
File System API

下面我们首先分析各种缓存机制的原理、用法及特点;然后针对Anroid移动端Web性能加载优化的需求,看如果利用适当缓存机制来提高Web的加载性能。

2 H5缓存机制原理分析
2.1 浏览器缓存机制

浏览器缓存机制是指通过HTTP协议头里的Cache-Control(或Expires)和Last-Modified(或Etag)等字段来控制文件缓存的机制。这应该是WEB中最早的缓存机制了,是在HTTP协议中实现的,有点不同于Dom Storage、AppCache等缓存机制,但本质上是一样的。可以理解为,一个是协议层实现的,一个是应用层实现的。

Cache-Control用于控制文件在本地缓存有效时长。最常见的,比如服务器回包:Cache-Control:max-age=600表示文件在本地应该缓存,且有效时长是600秒(从发出请求算起)。在接下来600秒内,如果有请求这个资源,浏览器不会发出HTTP请求,而是直接使用本地缓存的文件。

Last-Modified是标识文件在服务器上的最新更新时间。下次请求时,如果文件缓存过期,浏览器通过If-Modified-Since字段带上这个时间,发送给服务器,由服务器比较时间戳来判断文件是否有修改。如果没有修改,服务器返回304告诉浏览器继续使用缓存;如果有修改,则返回200,同时返回最新的文件。

Cache-Control通常与Last-Modified一起使用。一个用于控制缓存有效时间,一个在缓存失效后,向服务查询是否有更新。

Cache-Control还有一个同功能的字段:Expires。Expires的值一个绝对的时间点,如:Expires: Thu, 10 Nov 2015 08:45:11 GMT,表示在这个时间点之前,缓存都是有效的。

Expires是HTTP1.0标准中的字段,Cache-Control是HTTP1.1标准中新加的字段,功能一样,都是控制缓存的有效时间。当这两个字段同时出现时,Cache-Control是高优化级的。

Etag也是和Last-Modified一样,对文件进行标识的字段。不同的是,Etag的取值是一个对文件进行标识的特征字串。在向服务器查询文件是否有更新时,浏览器通过If-None-Match字段把特征字串发送给服务器,由服务器和文件最新特征字串进行匹配,来判断文件是否有更新。没有更新回包304,有更新回包200。Etag和Last-Modified可根据需求使用一个或两个同时使用。两个同时使用时,只要满足基中一个条件,就认为文件没有更新。

另外有两种特殊的情况:

手动刷新页面(F5),浏览器会直接认为缓存已经过期(可能缓存还没有过期),在请求中加上字段:Cache-Control:max-age=0,发包向服务器查询是否有文件是否有更新。

强制刷新页面(Ctrl+F5),浏览器会直接忽略本地的缓存(有缓存也会认为本地没有缓存),在请求中加上字段:Cache-Control:no-cache(或Pragma:no-cache),发包向服务重新拉取文件。

下面是通过Google Chrome浏览器(用其他浏览器+抓包工具也可以)自带的开发者工具,对一个资源文件不同情况请求与回包的截图。

首次请求:200
headers
缓存有效期内请求:200(from cache)
headers
缓存过期后请求:304(Not Modified)
headers
一般浏览器会将缓存记录及缓存文件存在本地Cache文件夹中。Android下App如果使用Webview,缓存的文件记录及文件内容会存在当前app的data目录中。

分析:Cache-Control和Last-Modified一般用在Web的静态资源文件上,如JS、CSS和一些图像文件。通过设置资源文件缓存属性,对提高资源文件加载速度,节省流量很有意义,特别是移动网络环境。但问题是:缓存有效时长该如何设置?如果设置太短,就起不到缓存的使用;如果设置的太长,在资源文件有更新时,浏览器如果有缓存,则不能及时取到最新的文件。

Last-Modified需要向服务器发起查询请求,才能知道资源文件有没有更新。虽然服务器可能返回304告诉没有更新,但也还有一个请求的过程。对于移动网络,这个请求可能是比较耗时的。有一种说法叫“消灭304”,指的就是优化掉304的请求。

抓包发现,带if-Modified-Since字段的请求,如果服务器回包304,回包带有Cache-Control:max-age或Expires字段,文件的缓存有效时间会更新,就是文件的缓存会重新有效。304回包后如果再请求,则又直接使用缓存文件了,不再向服务器查询文件是否更新了,除非新的缓存时间再次过期。

另外,Cache-Control 与 Last-Modified 是浏览器内核的机制,一般都是标准的实现,不能更改或设置。以QQ浏览器的X5为例,Cache-Control 与 Last-Modified 缓存不能禁用。缓存容量是12MB,不分HOST,过期的缓存会最先被清除。如果都没过期,应该优先清最早的缓存或最快到期的或文件大小最大的;过期缓存也有可能还是有效的,清除缓存会导致资源文件的重新拉取。

还有,浏览器,如X5,在使用缓存文件时,是没有对缓存文件内容进行校验的,这样缓存文件内容被修改的可能。

分析发现,浏览器的缓存机制还不是非常完美的缓存机制。完美的缓存机制应该是这样的:

缓存文件没更新,尽可能使用缓存,不用和服务器交互;
缓存文件有更新时,第一时间能使用到新的文件;
缓存的文件要保持完整性,不使用被修改过的缓存文件;
缓存的容量大小要能设置或控制,缓存文件不能因为存储空间限制或过期被清除。
以X5为例,第1、2条不能同时满足,第3、4条都不能满足。
在实际应用中,为了解决Cache-Control缓存时长不好设置的问题,以及为了”消灭304“,Web前端采用的方式是:

在要缓存的资源文件名中加上版本号或文件MD5值字串,如common.d5d02a02.js,common.v1.js,同时设置Cache-Control:max-age=31536000,也就是一年。在一年时间内,资源文件如果本地有缓存,就会使用缓存;也就不会有304的回包。

如果资源文件有修改,则更新文件内容,同时修改资源文件名,如common.v2.js,html页面也会引用新的资源文件名。

通过这种方式,实现了:缓存文件没有更新,则使用缓存;缓存文件有更新,则第一时间使用最新文件的目的。即上面说的第1、2条。第3、4条由于浏览器内部机制,目前还无法满足。

2.2 Dom Storage存储机制

DOM存储是一套在Web Applications 1.0 规范中首次引入的与存储相关的特性的总称,现在已经分离出来,单独发展成为独立的W3C Web存储规范。 DOM存储被设计为用来提供一个更大存储量、更安全、更便捷的存储方法,从而可以代替掉将一些不需要让服务器知道的信息存储到cookies里的这种传统方法。

上面一段是对Dom Storage存储机制的官方表述。看起来,Dom Storage机制类似Cookies,但有一些优势。

Dom Storage是通过存储字符串的Key/Value对来提供的,并提供5MB(不同浏览器可能不同,分HOST)的存储空间(Cookies才4KB)。另外Dom Storage存储的数据在本地,不像Cookies,每次请求一次页面,Cookies都会发送给服务器。

DOM Storage 分为 sessionStorage 和 localStorage。localStorage 对象和 sessionStorage 对象使用方法基本相同,它们的区别在于作用的范围不同。sessionStorage 用来存储与页面相关的数据,它在页面关闭后无法使用。而 localStorage 则持久存在,在页面关闭后也可以使用。

Dom Storage提供了以下的存储接口:
存储接口
sessionStorage 是个全局对象,它维护着在页面会话(page session)期间有效的存储空间。只要浏览器开着,页面会话周期就会一直持续。当页面重新载入(reload)或者被恢复(restores)时,页面会话也是一直存在的。每在新标签或者新窗口中打开一个新页面,都会初始化一个新的会话。
sessionStorage
当浏览器被意外刷新的时候,一些临时数据应当被保存和恢复。sessionStorage 对象在处理这种情况的时候是最有用的。比如恢复我们在表单中已经填写的数据。

把上面的代码复制到session_storage.html(也可以从附件中直接下载)页面中,用Google Chrome浏览器(点击查看支持Dom Storage的浏览器)的不同PAGE或WINDOW打开,在输入框中分别输入不同的文字,再点击“Save”,然后分别刷新。每个PAGE或WINDOW显示都是当前PAGE输入的内容,互不影响。关闭PAGE,再重新打开,上一次输入保存的内容已经没有了。
page
Local Storage的接口、用法与Session Storage一样,唯一不同的是:Local Storage保存的数据是持久性的。当前PAGE 关闭(Page Session结束后),保存的数据依然存在。重新打开PAGE,上次保存的数据可以获取到。另外,Local Storage是全局性的,同时打开两个PAGE会共享一份存数据,在一个PAGE中修改数据,另一个PAGE中是可以感知到的。
script
将上面代码复制到local_storage.html的页面中,用浏览器打开,pageLoadCount的值是1;关闭PAGE重新打开,pageLoadCount的值是2。这是因为第一次的值已经保存了。
page
用两个PAGE同时打开local_storage.html,并分别交替刷新,发现两个PAGE是共享一个pageLoadCount的。
page
分析:Dom Storage 给Web提供了一种更录活的数据存储方式,存储空间更大(相对Cookies),用法也比较简单,方便存储服务器或本地的一些临时数据。

从DomStorage提供的接口来看,DomStorage适合存储比较简单的数据,如果要存储结构化的数据,可能要借助JASON了,将要存储的对象转为JASON字串。不太适合存储比较复杂或存储空间要求比较大的数据,也不适合存储静态的文件等。

在Android内嵌Webview中,需要通过Webview设置接口启用Dom Storage。
Dom Storage
拿 Android类比的话,Web 的Dom Storage机制类似于Android的SharedPreference机制。

2.3 Web SQL Database存储机制

H5也提供基于SQL的数据库存储机制,用于存储适合数据库的结构化数据。根据官方的标准文档,Web SQL Database存储机制不再推荐使用,将来也不再维护,而是推荐使用AppCache和IndexedDB。

现在主流的浏览器(点击查看浏览器支持情况)都还是支持Web SQL Database存储机制的。Web SQL Database存储机制提供了一组API供Web App创建、存储、查询数据库。

下面通过简单的例子,演示下Web SQL Database的使用。
Web SQL Database
将上面代码复制到sql_database.html中,用浏览器打开,可看到下面的内容。
page
官方建议浏览器在实现时,对每个HOST的数据库存储空间作一定限制,建议默认是5MB(分HOST)的配额;达到上限后,可以申请更多存储空间。另外,现在主流浏览器SQL Database的实现都是基于SQLite。

分析:SQL Database的主要优势在于能够存储结构复杂的数据,能充分利用数据库的优势,可方便对数据进行增加、删除、修改、查询。由于SQL语法的复杂性,使用起来麻烦一些。SQL Database也不太适合做静态文件的缓存。

在Android内嵌Webview中,需要通过Webview设置接口启用SQL Database,同时还要设置数据库文件的存储路径。
Webview
Android系统也使用了大量的数据库用来存储数据,比如联系人、短消息等;数据库的格式也SQLite。Android也提供了API来操作SQLite。Web SQL Database存储机制就是通过提供一组API,借助浏览器的实现,将这种Native的功能提供给了Web App。

2.4 Application Cache机制

Application Cache(简称AppCache)似乎是为支持Web App离线使用而开发的缓存机制。它的缓存机制类似于浏览器的缓存(Cache-Control 和 Last-Modified)机制,都是以文件为单位进行缓存,且文件有一定更新机制。但AppCache是对浏览器缓存机制的补充,不是替代。

先拿W3C官方的一个例子,说下AppCache机制的用法与功能。
AppCache机制
上面HTML文档,引用外部一个JS文件和一个GIF图片文件,在其HTML头中通过manifest属性引用了一个appcache结尾的文件。

我们在Google Chrome浏览器(点击查看浏览器支持详情)中打开这个HTML链接,JS功能正常,图片也显示正常。禁用网络,关闭浏览器重新打开这个链接,发现JS工作正常,图片也显示正常。当然也有可能是浏览缓存起的作用,我们可以在文件的浏览器缓存过期后,禁用网络再试,发现HTML页面也是正常的。

通过Google Chrome浏览器自带的工具,我们可以查看已经缓存的AppCache(分HOST)
AppCache
上面截图中的缓存,就是我们刚才打开HTML的页面AppCache。从截图中看,HTML页面及HTML引用的JS、GIF图像文件都被缓存了;另外HTML头中manifest属性引用的appcache文件也缓存了。

AppCache的原理有两个关键点:manifest属性和manifest文件。

HTML在头中通过manifest属性引用manifest文件。manifest文件,就是上面以appcache结尾的文件,是一个普通文件文件,列出了需要缓存的文件。
html
上面截图中的manifest文件,就HTML代码引用的manifest文件。文件比较简单,第一行是关键字,第二、三行就是要缓存的文件路径(相对路径)。这只是最简单的manifest文件,完整的还包括其他关键字与内容。引用manifest文件的HTML和manifest文件中列出的要缓存的文件最终都会被浏览器缓存。

完整的manifest文件,包括三个Section,类型Windows中ini配置文件的Section,不过不要中括号。

CACHE MANIFEST – Files listed under this header will be cached after they are downloaded for the first time
NETWORK – Files listed under this header require a connection to the server, and will never be cached
FALLBACK – Files listed under this header specifies fallback pages if a page is inaccessible

完整的manifest文件,如:
manifest文件
总的来说,浏览器在首次加载HTML文件时,会解析manifest属性,并读取manifest文件,获取Section:CACHE MANIFEST下要缓存的文件列表,再对文件缓存。

AppCache的缓存文件,与浏览器的缓存文件分开存储的,还是一份?应该是分开的。因为AppCache在本地也有5MB(分HOST)的空间限制。

AppCache在首次加载生成后,也有更新机制。被缓存的文件如果要更新,需要更新manifest文件。因为浏览器在下次加载时,除了会默认使用缓存外,还会在后台检查manifest文件有没有修改(byte by byte)。发现有修改,就会重新获取manifest文件,对Section:CACHE MANIFEST下文件列表检查更新。manifest文件与缓存文件的检查更新也遵守浏览器缓存机制。

如用用户手动清了AppCache缓存,下次加载时,浏览器会重新生成缓存,也可算是一种缓存的更新。另外, Web App也可用代码实现缓存更新。

分析:AppCache看起来是一种比较好的缓存方法,除了缓存静态资源文件外,也适合构建Web离线App。在实际使用中有些需要注意的地方,有一些可以说是”坑“。

要更新缓存的文件,需要更新包含它的manifest文件,那怕只加一个空格。常用的方法,是修改manifest文件注释中的版本号。如:# 2012-02-21 v1.0.0
被缓存的文件,浏览器是先使用,再通过检查manifest文件是否有更新来更新缓存文件。这样缓存文件可能用的不是最新的版本。
在更新缓存过程中,如果有一个文件更新失败,则整个更新会失败。
manifest和引用它的HTML要在相同HOST。
manifest文件中的文件列表,如果是相对路径,则是相对manifest文件的相对路径。
manifest也有可能更新出错,导致缓存文件更新失败。
没有缓存的资源在已经缓存的HTML中不能加载,即使有网络。例如:https://appcache-demo.s3-website-us-east-1.amazonaws.com/without-network/
manifest文件本身不能被缓存,且manifest文件的更新使用的是浏览器缓存机制。所以manifest文件的Cache-Control缓存时间不能设置太长。

另外,根据官方文档,AppCache已经不推荐使用了,标准也不会再支持。现在主流的浏览器都是还支持AppCache的,以后就不太确定了。

在Android内嵌Webview中,需要通过Webview设置接口启用AppCache,同时还要设置缓存文件的存储路径,另外还可以设置缓存的空间大小。
设置缓存的空间大小
2.5 Indexed Database

IndexedDB也是一种数据库的存储机制,但不同于已经不再支持的Web SQL Database。IndexedDB不是传统的关系数据库,可归为NoSQL数据库。IndexedDB又类似于Dom Storage的key-value的存储方式,但功能更强大,且存储空间更大。

IndexedDB存储数据是key-value的形式。Key是必需,且要唯一;Key可以自己定义,也可由系统自动生成。Value也是必需的,但Value非常灵活,可以是任何类型的对象。一般Value都是通过Key来存取的。

IndexedDB提供了一组API,可以进行数据存、取以及遍历。这些API都是异步的,操作的结果都是在回调中返回。

下面代码演示了IndexedDB中DB的打开(创建)、存储对象(可理解成有关系数据的”表“)的创建及数据存取、遍历基本功能。
IndexedDB
IndexedDB
IndexedDB
IndexedDB
IndexedDB
IndexedDB
IndexedDB
IndexedDB
IndexedDB
将上面的代码复制到indexed_db.html中,用Google Chrome浏览器(点击查看游戏器支持详情)打开,就可以添加、查询数据。在Chrome的开发者工具中,能查看创建的DB、存储对象(可理解成表)以及表中添加的数据。
开发者工具
IndexedDB有个非常强大的功能,就是index(索引)。它可对Value对象中任何属性生成索引,然后可以基于索引进行Value对象的快速查询。

要生成索引或支持索引查询数据,需求在首次生成存储对象时,调用接口生成属性的索引。可以同时对对象的多个不同属性创建索引。如下面代码就对name和email两个属性都生成了索引。
对name和email生成索引
生成索引后,就可以基于索引进行数据的查询。
数据查询
分析:IndexedDB是一种灵活且功能强大的数据存储机制,它集合了Dom Storage和Web SQL Database的优点,用于存储大块或复杂结构的数据,提供更大的存储空间,使用起来也比较简单。可以作为Web SQL Database的替代。不太适合静态文件的缓存。

以key-value的方式存取对象,可以是任何类型值或对象,包括二进制。
可以对对象任何属性生成索引,方便查询。
较大的存储空间,默认推荐250MB(分HOST),比Dom Storage的5MB要大的多。
通过数据库的事务(tranction)机制进行数据操作,保证数据一致性。
异步的API调用,避免造成等待而影响体验。

Android 在4.4开始加入对IndexedDB的支持,只需打开允许JS执行的开关就好了。
JS执行
2.6 File System API

File System API是H5新加入的存储机制。它为Web App提供了一个虚拟的文件系统,就像Native App访问本地文件系统一样。由于安全性的考虑,这个虚拟文件系统有一定的限制。Web App在虚拟的文件系统中,可以进行文件(夹)的创建、读、写、删除、遍历等操作。

File System API也是一种可选的缓存机制,和前面的SQLDatabase、IndexedDB和AppCache等一样。File System API有自己的一些特定的优势:

可以满足大块的二进制数据( large binary blobs)存储需求。
可以通过预加载资源文件来提高性能。
可以直接编辑文件。

浏览器给虚拟文件系统提供了两种类型的存储空间:临时的和持久性的。临时的存储空间是由浏览器自动分配的,但可能被浏览器回收;持久性的存储空间需要显示的申请,申请时浏览器会给用户一提示,需要用户进行确认。持久性的存储空间是WebApp自己管理,浏览器不会回收,也不会清除内容。持久性的存储空间大小是通过配额来管理的,首次申请时会一个初始的配额,配额用完需要再次申请。

虚拟的文件系统是运行在沙盒中。不同WebApp的虚拟文件系统是互相隔离的,虚拟文件系统与本地文件系统也是互相隔离的。

File System API提供了一组文件与文件夹的操作接口,有同步和异步两个版本,可满足不同的使用场景。下面通过一个文件创建、读、写的例子,演示下简单的功能与用法。
File System API
File System API
File System API
File System API
将上面代码复制到file_system_api.html文件中,用Google Chrome浏览器打开(现在File System API只有Chrome 43+、Opera 32+以及Chrome for Android 46+ 这三个浏览器支持,点击查看详细支持情况)。由于Google Chrome禁用了本地HTML文件中的File System API功能,在启动Chrome时,要加上”—allow-file-access-from-files“命令行参数。
Chrome
上面截图,左边是HTML运行的结果,右边是Chrome 开发者工具中看到的Web的文件系统。基本上H5的几种缓存机制的数据都能在这个开发者工具看到,非常方便。

分析:File System API给Web App带来了文件系统的功能,Native文件系统的功能在Web App中都有相应的实现。任何需要通过文件来管理数据,或通过文件系统进行数据管理的场景都比较适合。

到目前,Android系统的Webview还不支持File System API。

3 移动端Web加载性能(缓存)优化

分析完H5提供的各种缓存机制,回到移动端(针对Android,可能也适用于iOS)的场景。现在Android App(包括手Q和WX)大多嵌入了Webview的组件(系统Webview或QQ游览器的X5组件),通过内嵌Webview来加载一些H5的运营活动页面或资讯页。这样可充分发挥Web前端的优势:快速开发、发布,灵活上下线。但Webview也有一些不可忽视的问题,比较突出的就是加载相对较慢,会相对消耗较多流量。

通过对一些H5页面进行调试及抓包发现,每次加载一个H5页面,都会有较多的请求。除了HTML主URL自身的请求外,HTML外部引用的JS、CSS、字体文件、图片都是一个独立的HTTP请求,每一个请求都串行的(可能有连接复用)。这么多请求串起来,再加上浏览器解析、渲染的时间,Web整体的加载时间变得较长;请求文件越多,消耗的流量也会越多。我们可综合使用上面说到几种缓存机制,来帮助我们优化Web的加载性能。
缓存机制
结论:综合各种缓存机制比较,对于静态文件,如JS、CSS、字体、图片等,适合通过浏览器缓存机制来进行缓存,通过缓存文件可大幅提升Web的加载速度,且节省流量。但也有一些不足:缓存文件需要首次加载后才会产生;浏览器缓存的存储空间有限,缓存有被清除的可能;缓存的文件没有校验。要解决这些不足,可以参考手Q的离线包,它有效的解决了这些不足。

对于Web在本地或服务器获取的数据,可以通过Dom Storage和IndexedDB进行缓存。也在一定程度上减少和Server的交互,提高加载速度,同时节省流量。

当然Web的性能优化,还包括选择合适的图片大小,避免JS和CSS造成的阻塞等。这就需要Web前端的同事根据一些规范和一些调试工具进行优化了。

参考资料:

浏览器缓存机制:
http cache笔记
https://imweb.io/topic/5623b34e34764b2c16769746
Web缓存机制系列
https://www.alloyteam.com/2012/03/web-cache-1-web-cache-overview/

Web SQL Database:
A simple TODO List Using Web SQL Database
https://www.html5rocks.com/en/tutorials/webdatabase/todo/?redirect_from_locale=zh
W3C:Web SQL Database
https://dev.w3.org/html5/webdatabase/
HTML5:Web SQL Database
https://www.tutorialspoint.com/html5/html5_web_sql.htm

Dom Storage:
浅谈Html5的Dom Storage
https://www.ibm.com/developerworks/cn/web/1107_gaoly_html5storage/
Dom Storage
https://developer.mozilla.org/zh-CN/docs/Web/Guide/API/DOM/Storage

Application Cache:
Html5 Application Cache
https://www.w3schools.com/html/html5_app_cache.asp
Using the application cache
https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache
Common Pitfalls to Avoid when Using HTML5 Application Cache
https://www.sitepoint.com/common-pitfalls-avoid-using-html5-application-cache/
Application Cache is a Douchebag
https://alistapart.com/article/application-cache-is-a-douchebag

IndexedDB:
Working with IndexedDB
https://code.tutsplus.com/tutorials/working-with-indexeddb–net-34673
Working with IndexedDB -Part2
https://code.tutsplus.com/tutorials/working-with-indexeddb-part-2–net-35355
IndexedDB:浏览器端数据库
https://javascript.ruanyifeng.com/bom/indexeddb.html
W3C:Indexed Database API
https://www.w3.org/TR/IndexedDB/

File System API:
Debugging the FileSystem API
https://developers.google.com/web/updates/2011/08/Debugging-the-Filesystem-API
Building an HTML5 Text Editor with the FileSystem APIs
https://blog.teamtreehouse.com/building-an-html5-text-editor-with-the-filesystem-apis
Toying with the FileSystem API
https://code.tutsplus.com/tutorials/toying-with-the-html5-file-system-api–net-24719
Exploring the FileSystem APIs
https://www.html5rocks.com/en/tutorials/file/filesystem/
文章来源微信公众号:腾讯大讲堂 本文链接https://mp.weixin.qq.com/s?__biz=MTEwNTM0ODI0MQ==&mid=404724239&idx=1&sn=e0a2887f9ff6293f0f550fa4e44057a0&scene=23&srcid=0406keLWfG0TG9vBgcILerRN#rd

Leave a Comment