flash卸载器（flash卸载软件）

2021年就要来了，win10将通过更新永久删除Flash，很多“苦Flash久矣”的用户都非常开心，因为能够加速H5的普及。Flash的体验非常糟糕，但是国内依然有很多“不得不用的网站”是用的Flash，本来以为这样能够迫使他们升级成H5，但是FlashPlay在国内却依然被一家公司代理并维护更新。前两天还公开表示将发布更新，底下十几条评论，全都在骂[捂脸]谷歌今日开始推送Chrome88，“永久删除”Flash：Adobe在去年12月31日正式停止支持Flash，但是根据网络技术调查网站W3Techs的数据显示，目前仍然有2.2％的网站使用Flash代码，但是这一数字已经比2011年初的28.5％下降很多了。谷歌工程总监大布里士（Tabriz）在2018年2月的一次会议上说，当时每天至少加载了一个包含Flash内容的网页的Chrome浏览器用户所占的百分比，从2014年的80％下降到了8％以下，而且自2018年初以来，这一数字持续下降。Chrome88优化深色模式，覆盖设置、书签、历史、新标签页等更多内部页面的滚动条，正式支持Manifestv3扩展，可阻止标签捕捉攻击，在后台脚本中大量限制JavaScript计时器操作，以提高性能，减少CPU和RAM的使用。另外，这个的版本的Chrome浏览器，放弃了对于苹果OSX10.10(OSXYosemite)的支持，未来，要想在Mac平台上使用Chrome浏览器，需要将需要OSX10.11或更高版本。此外，Chrome88的一项重要变化是，取消了对内部访问FTP链接（ftp：//）的支持，该过程始于Chrome86。Chrome86在默认情况下，大多数用户仍启用FTP，但对于预发布渠道（Canary和Beta）则关闭了FTP，并且将对稳定用户的1%进行实验性关闭。在此版本中，用户仍然可以cefp使用--enable-ftp 命令行或 --enable-features=FtpProtocol 命令重新启用。今天评审同事开发的项目，其中有涉及到spiflash的操作。我想起了几年前的一桩往事。当时，有一款产品使用了旺宏电子(MXIC)的flashMX25L3206，用于存储程序代码、设置参数以及操作记录等。MX25L3206是一款spi接口的norflash。在测试过程中，我们发现有一些样机的程序代码被误改写，导致程序无法运行。从规格书上查到，在上电或掉电过程中可能会产生错误的电平，被误认为是写操作，导致数据被误擦写。我们根据规格书上的说明，加了一些额外的保护措施，即通过置位状态寄存器中的BP3-BP0等位进行软件保护，同时通过控制WP引脚上的电平进行硬件保护。在开启了软、硬件保护之后，当需要向flash写入数据时，就需要改变状态寄存器的设置值禁止保护功能，写入数据之后，再改变状态寄存器的设置值使能保护功能。所以，在每一次数据写入时都会改写状态寄存器的数值。状态寄存器也是非易失存储器，即断电不丢失，根据规格书的说明，flash的数据区的擦写寿命为10万次。当超过擦写次数后，flash的读写时间大大增加，甚至会不能正常读写。产品的通话记录大概每天会产生几十条，每一条记录的长度大概在100个字节左右。考虑到flash的擦写次数的限制，我们做了一些擦写平衡的机制。即先擦一块4096个字节的区域。每次当有新的记录产生时，先查找事先擦写的区域内是否有没有被占用的空间，找到后写入到该空间。当所有4096个字节的区域都被占满之后，再搬移并清理被删除的记录。通过这种方式，可以避免反复操作同一块区域。使得整个flash存储空间都可以被均匀使用。改完之后，我们开始了自动测试，编写自动测试代码控制设置，使得设备每天产生约5000条记录。没过几天，出现了始料不及的问题，存储记录的代码运行越来越慢，甚至影响到了其它的功能。通过调试，发现是操作状态寄存器使能/禁止写保护的操作耗费的大量时间。细查之后，原来状态寄存器的擦写也一样有10万次次数的限制。虽然，对数据本身的读写进行了擦写平衡的设计，但是因为每次写数据都操作了状态寄存器，对状态寄存器的操作没有任何降低擦写频次的机制。于是，再次进行代码优化，写完记录数据之后，并不立即开启写保护，而且设置1天左右的定时器，定时时间到了之后，再开启写保护。#单片机#