flying meng的菜鸟居

canvas ，作为HTML5的「画布」，canvas强大的功能将一直伴随H5走下去。前端使用canvas一般有两种方式：<canvas class="canvas" width="" height=""></canvas>然后通过JavaScript去操控一些属性比如文字：ctx.fillText("一段文字",左上角X坐标值,左上角Y坐标值); //填充//或ctx.strokeText("一段文字",左上角X坐标值,左上角Y坐标值); //镂空.

在 leetCode 上看到了这样一道算法题：给定一个整数数组和一个整数目标，返回两个数字的索引，使它们加起来等于目标。你可能会假设每个输入都只有一个解决方案，并且，你可能不会两次使用相同的元素。你可以按任何顺序返回答案。这很容易想到双for循环O(n^2)那么，什么结构既能满足“快速查找”的目的，又能避免循环呢？Map！这里说Map只是为了引出业务场景中的使用。事实上，当数据量够小时我们通常使用的是Object，而当涉及到大量数据或对顺序有要求或需要遍历时选择Map。是不是非常简单明了？

当cache里面没有缓存，则使用fetch发起请求，这个Fetch发起请求的是用来代替XMLHttpRequest来发请求的方案；当请求响应了错误直接返回错误信息，当请求响应成功的情况，更新cache缓存，将新的响应存入cache缓存中，下次在访问就直接从缓存中读取。注意：上面说的是“静态资源缓存”，也就是缓存列表是固定的。事件，这里我们可以进行一些静态资源的 cache，以防止在后面的请求时依然对这些资源发送请求！阶段，而老的那个还处于工作状态，新的那个就会进入。后，新的才能正常替换老的那个的工作。

在视觉和前端眼中，需要着重考虑的只有一点：当可视区域变化时，是在一行中展示更多/更少的内容？如果针对一个个单独的点做处理，过多的 media 反而会使效率大打折扣，所以我更建议选取“某些阶段”的临界点做处理。很显然，之前的开发中并没有考虑到极小屏下的场景 —— 在字体允许的、不影响体验的大小下宽度并不足以支持和大屏一样的内容。而在H5中，由于各种情况影响，很多时候会选择后者。，我们把设备可视区域也就是我们的各种移动端设备的这个画布也分成10份，并赋值给根元素的。可以明确的是，上面的问题并不针对“字体”。

对这个“引导页”，我第一时间也是迷茫的，有些按钮询问了产品才知道是干啥用的。几乎所有的相关文章都在说 relative 会如何影响到 absolute 和 fixed，但似乎笔者没有见到有反过来研究的，也可能是我阅读的少，如有见谅。第一种方式，保证了元素的“独立性”，但是缺失了元素的“可交互性”。但这不是最重要的，每次的clone会带来繁琐的操作，我们应该避免它！当然，这种方法也是有遗憾的：由于这时候“高亮”也是“画”出来的，所以这时候切记不可让页面滚动 —— 页面操作是有延迟的！

当然，对后半部分来说，本文举的例子其实并不那么恰当。在笔者的实践和实际一些项目使用的效果来看，我认为它的使用场景应该更多的在买家端。而且本文只说了pc端的情况，要知道，H5是没有“鼠标事件”的，这又会带来一个问题：如何更精准的知道“哪些资源需要提前获取？”关于这个问题以及后续的问题我都会及时回到本文中进行更新～相比之下，在本文这种场景下，笔者更认同“在新建-保存时缓存一份表单项数据，在进入时判断”这种做法 —— 虽然一刷新就无了。最后，我再一次认为，用户体验是没有尽头的。

在图片与前端体验优化中，最重要的莫过于「骨架屏」了，因为它和“首屏体验”息息相关。

最近在研究微前端。我觉得从理论上来说，iframe是微前端最理想的组合技术。使用iframe能够将一个页面内嵌到另一个页面中，并且和链接集成一样具有松散的耦合和高鲁棒性。iframe具有极强的隔离性，其中发生的一切只会影响到自身 —— 实际上目前大多数在线编辑平台都是iframe技术实现的。...

基于iOS对web页面的规则，input的type为不同值时软键盘的弹出规则尤其是右下角按键名就非常值得注意。以为例，在安卓段展示正常，右下角是一个蓝白“搜索图标”。但iOS仍然遵循默认“换行”效果。以至于不少人会这么做......

我所理解的是，虚拟滚动需要一次性获取所有数据，但是只渲染显示屏幕可见范围内的那些。要做到这些我需要知道：假设一次只需要展示 10 条数据，需要加载的数据是一个数组，只需要裁剪数据范围随着滚动条向下，将可以计算出当前行数。而要模拟滚动条高度就要在页面挂载时就手动设置页面的高度为。最后也是最关键的是保持列表一直保持在当前位置上，手动设置列表容器等于当前滚动条高度。如何使用？CSS虚拟滚动这个概念忘了在哪听到的了。其实我认为它更像是一种内容的懒加载。他需要用到一个css属性：：控制一个元素是否渲染其内

标题显而易见，要说两种情况：重新打开页面或者返回某个页面时滚动到上次离开时的位置，以及不滚动保持在顶部。这也有两种情况：页面重新打开，与返回某个页面。如果是前者，必定用或者。或者麻烦一点的、在webview中用其他手段。总之这个必须有存储。然后在组件的或是时取出存储内容改变。非常牛逼。若是第二种情况，则只需要临时缓存即可，这里拿vue演示一下：有两个方案。其一，利用路由中的，在离开页面时缓存 top 信息然后在回到当前页面时拿到临时缓存，并赋值组件内其二，利用缓存整个页面。但是仅限于没有实时数据变

flex已经越来越成为前端不可避免的话题。曾经为了搞清flex的原理偶然画了一张图。但后来发现只是冰山一角。通过我的实践，发现使用flex布局时稍不注意便会遇到三个问题：子元素不平分父元素空间、对文字设置了溢出省略却失效、flex下列表溢出但是滚动失效。常常会让人摸不着头脑。这里记录探究。元素不均分“均分列”，也就是子元素等宽应该是项目中最常见的效果。我常常在项目中见到这样的代码：flex: 1;似乎有很多人认为在 Flex 布局中这样显式设置即可“一劳永逸”。但事实是什么？事实是我们都知道

最近总是回想起大三时为了体(装)验(逼)提出要在学校新版系统中加入无感刷新token的功能。当时只是听到这个玩意甚至还没搞明白是咋回事，于是直到几个月后出来实习也没真正加上这个功能。先说一个场景：我们都知道 JWT。假如说某系统将其token存留时间设置为5分钟。那么，如果说用户在这一时间内恰好有其他事，快结束时回来以后再点“提交”，发现弹出“用户凭证已失效，请重新登录”。怎一个惨字了得！当然，类似的场景还有许多，毫无疑问的是，如果过期时间设置的很短，用户就必须每隔一段时间重新登录，以获取新的凭证，这会

上一篇文章结尾提到了一个对图片至关重要的点：采样、量化和编解码。图像的显示需要GPU和CPU两者配合，CPU主要负责视图的创建，布局的计算和视图的绘制，然后进行图片的解码，将生成的位图交给GPU，GPU进行渲染，并将渲染的结果交到帧缓冲区，待下一个VSync 信号到来的时候视频控制器从帧缓冲区取出数据，经过转换，显示到屏幕上。如果在规定的16.7ms内，CPU和GPU的合作未完成，没有生成新的渲染数据到帧缓冲区中，那么就会出现卡顿或者掉帧的情况。一般我们常说的“精灵图”Sprite 其实不止优化了“网

这个想法是来源于「性能优化」中的骨架屏：在图片居多的站点中，这将是非常nice的体验 —— 图片加载通常是比较让人难受的，好的骨架中一般占位图就是低像素的图片，即大体配色和变化是和实际内容一致的。有时候比如图片不固定的，那可以使用算法获取图片的主体颜色（至少得是同色系的吧），使用纯色块占位。再进一步想到，在一些“轻松”的场景下，我们可以让背景色/页面主题色跟随轮播图改变。至于效果嘛…你们可以想一下网易云音乐滑动切歌时的背景效果。因为是不固定图片，所以我想到了四种方法：tensorflow.js

HTML5提出的<picture>标签非常实用，在新时期用户体验大方向上可以结合css以及其它HTML元素达到意想不到的效果。picture往往和<source>元素（可以多个）、<img>元素（最多一个）一同使用。渲染的时候，浏览器优先使用<source>元素，<img>元素兜底。结合近两年W3C年度报告来看，前端（尤其是css）开始往用户体验方向突破。一方面目前已经很难有大方向的创新，另一方面有Google这个“急先锋”存在，已经势不可

点这里直接到下面看解决方案自古以来，滚动条都是用户体验大难关，也在不断进化。一者滚动条样式在浏览器间表现不一致，从而有人提出“顶部阅读进度”方案；二者在window下，滚动条本身是占位的！这就导致了天生考虑响应式的现代页面中元素会受到影响从而“跳动”。经常有下面的场景的发生：“加载更多”页面懒加载模板页面跳转/路由跳转共同点都是：从不足一屏到超出一屏。淘宝网首页使用CSS把页面尺寸布局骨架搭好，再在里面吐数据。但即使是这样，他们还是做了overflow-x:hidden;。一方面是为.

最近在设计笔者所在组自己的组件库。从设计上看，一个组件库是否“成功”取决于前期的设计 —— 我决定用上ITCSS模型。为这个组件的团队维护、扩展打下坚实的基础。但这还不够，组件库最重要的组件往往是非大型库开发中最容易被忽视的。为此，我将组件从使用场景上分为两种类型：大组件：也叫“场景组件”。功能完善，自成一片天地。取之即用，通过传参在内部做不同处理 —— 或渲染不同UI、或返回不同值。最重要的是：不会侵入页面逻辑。也就是说，无论谁在什么场景下调用，都是相同的方式。拿到值以后这个组件在当前操作流中就算完

笔者之前有过对此功能的两次探究：https://blog.youkuaiyun.com/qq_43624878/article/details/110124299 这篇文章主要描述了文本溢出省略功能的实现，以及用js大致模拟了其原理和如何用js动态实现“溢出省略”；后来的 https://blog.youkuaiyun.com/qq_43624878/article/details/120993013 这篇文章又进一步从实际场景研究了不同情况下的溢出对用户体验的影响；本文将结合之前的文章用css代替js实现动态“多行溢出.

目前Chrome浏览器依然没有放开12px的限制，但Chrome仍然是使用人数最多的浏览器。在笔者开发某个项目时遇到一个问题：实际需要11px的字体大小但是在Chrome中是实现不了的。关于字体，一开始想到的就是rem等非px单位。但是rem只是为了响应式适配，并不能突破这一限制。em、rem等单位只是为了不同分辨率下展示效果提出的换算单位，常见的库px2rem也只是利用了js将px转为rem。包括微信小程序提出的rpx单位也是一样！这条路走不通，就只剩下一个方法：改变视觉大小而非实际大小。

依然先说结论：目前为止所有的点击问题都是移动端事件触发顺序混乱导致的！关于捕获和冒泡→我们首先要知道的是：当我们鼠标按下一个按钮时，并不是“点击了一个按钮”，而是在这个区域内，鼠标（上的按键）被按下，操作系统和浏览器把这个信息对应到了“按钮”所在区域并触发其逻辑。事实上鼠标点击并没有位置信息，是操作系统一直在监听鼠标移动，根据累积的位移计算出来的坐标，将其传给浏览器。那么，把这个坐标转换为具体的元素上的事件的过程，就可称作“捕获”。那“冒泡”呢？这个不好直观解释，但有一点想必你是明白的：当你按下电视

最近为我开源的小项目：微信小程序扩展自定义组件库（点击去GitHub） 增加了一个新组件 —— 日历组件。在编写过程中，因为大家都知道，日历组件是有固定行数和每一行的固定列数的（即使当前方块内没有值），所以结合小程序“数据优先”的特点，最合适的布局方式一定是flex了！说一下大致思路（布局上），笔者将整个组件分为两部分：分别是头部的当前日期（年月）显示，以及左右两侧的切换按钮当前切换月份的日期显示头部的布局自不多说：一个 display:flex; 加上 align-items:center;

canvas动画，又叫“粒子系统”，是HTML5新增的为页面添加多样化效果的绝佳实践。正巧最近做的一个天气类微信小程序紧接尾声，寻思着首页展示温度等信息的地方似乎少了点什么。到Android自带的天气预报上看了下，恍然大悟。于是结合前一段时间钻研的canvas为其添加雨雪粒子效果。小程序中的“绘图”API小程序的绘图 API 虽然也叫canvas，但跟 HTML5 的 Canvas 本质上有很大区别的，其原因是小程序的绘图（Canvas）是客户端实现的 Native UI 组件，而不是普通的 H5

最近看过我文章的都知道：我最近在写一个微信小程序的项目，在其中遇到了很多有趣的事和一些“奇思妙想”。本文的背景就是今天早上我看着wxml文件中一堆wx:if/else和hidden突然很烦躁，先不说wx:if的性能问题，就是标签上也是冗杂的。接着上一篇文章【微信小程序自定义组件库yPicker组件分析及省市区三级联动实现】，在其中我分析了这么一个例子 —— 省市区三级联动的自定义实现，在其中有详细代码这里就不多说，说说如何调用：我当时是这么想的：一方面出于“不在JavaScript里写太多东西”的考虑

自从上一篇文章：微信小程序自定义日历组件及flex布局最后一行对齐问题分析 出来以后，有人私聊我说能不能从头分析一下我开源的自定义组件？一直没时间。这不，最近项目中有个需求是 省市区三级联动 ，我就顺便从组件库中的第一个 「扩展日期-时间（点此直接至GitHub）」picker组件开始说一下这两个功能的实现。简单说一下“自定义日期-时间组件”它的背景是项目的第一版当时发现微信小程序内置的日期组件：picker只能精确到某一天（年月日），但是我们很多时候需要年月日时分甚至是年月日时分秒（如结束时间/发布

今天面试官问的我这个问题，说实话，我当时懵逼了。我第一个想法竟然是：嘶~这问题挺简单的啊，不就是用 Date 对象判断是否大于某个时间差么？于是写出了下面这段代码：let rest=function(){ // 开始是放在外面的，但是面试官说要尽可能不单独暴露值，于是鬼迷心窍（紧张）杀都没想就直接扔进来了... let date=Date.now(); return new Promise((resolve,reject)=>{ let _date=Date.now(); if(_d

最近玩三国志战略版时发现它上面占领土地候一段时间内的动画效果不错，进而引发了一些探究：原动画可以简化为一个方块上有一个类似遮罩的白色的光晕，而且不断膨胀收缩，我开始一想，这不是css的scale么？然后一定时间后将其remove掉。然后发现其每隔一段时间颜色还会变淡一些，这里“理所当然”地用了“多次setTimeout”。但写完后我就立刻想到了“由于浏览器eventLoop和消息队列机制的原因，setTimeout通常不能准时，而且嵌套的setTimeout越多延时越大”。怎么解决呢？既然和时间相关

为什么说“通常情况下1em=16px”？用户的浏览器默认渲染的文字大小是“16px”，换句话说，Web页面中“body”及其子元素的文字大小在用户浏览器下默认渲染是“16px”。我们都知道：em（和 rem ）是一个相对单位！“相对”的意思是：相对的计算必然会一个参考物，那么这里相对所指的是相对于元素父元素的font-size。比如说：如果在一个 div 设置字体大小为“16px”，此时这个 div 的后代元素教程了是将继承他的字体大小，除非重新在其后代元素中进行过显示的设置。如果用户通过浏览器的

笔者曾在大量的关于页面加载分析的文章中提到过图片加载对页面展示（速度）的影响 —— 这是毋庸置疑的。事实上，不管是通过实际感知还是各类API在遇到图片时提供的 onload 处理我们都能知道这样一件事：图片在网页中总是靠后被加载并渲染的，其速度受图片本身大小的影响，并且直接阻塞了页面的展现！通过 network ，我们又知道了另一件事：图片的加载是一个 client 向 server 发送请求的过程！既然如此，它一定还受到当前网速的限制！过去很长时间内，我们针对网页优化提供了众多方法 —— 图片懒加

在实现业务的过程中，我们难免会发现之前由于各种原因存在的代码中正在产生大量的冗余。这时候就需要优化代码，如果有功能的迭代，就是进行重构的好时机了！我曾看过很多关于架构的书籍、文章。恕我肤浅，至今都没能确切搞懂架构的真正含义，只是觉得：这是一个通过某些手段将项目变成一个层级划分、面向功能、结构清晰的关系。最近在搞某一块业务的重构，恰好时间不紧。组内大佬说“放手去干吧”。于是我将目光投向了自认为比较了解的CSS方面。ITCSS这是由csswizardry提倡的一个 CSS 设计方法论，他可以让你更好的

适配问题说起适配，其实就不得不提到“ 响应式 ”。而说起响应式，可能很多人下意识就会脱口而出：css @media媒体查询。可能还有些人会进一步说出：“利用css的em、rem单位”。是的，但是你有没有想过一个问题：em、rem是根据px计算得来的；而media又“足够复杂” —— 放在一般的项目中还好，如果将css自适应放到淘宝、京东这种极度复杂的场景下，就显得有些束缚了：因为我们知道，元素大小、位置甚至颜色等的改变都会引起回流和重绘！导致页面重新渲染…这对性能是不友好的。css单位上面说到e

alternate？你没搞错吧？这不就是“交替、替换”吗？这有什么好说的？但是如果我问出来：alternate在HTML中的用法，具体作用，可能你只能说：“诶这不是那啥么”。说实话我一开始也压根不知道有这个东西，但是就在前两天这玩意解决了我的一大“难题”，顿时这兴趣不就来了么！alternate在网站换肤方面的应用好吧想来你也遇到过这种情况：网页换肤！其实我们的选择还是挺多的，比如：设置不同颜色，用JavaScript去一个一个的操控、替换（或者设置“全局的”class名）用JavaScr

图片渲染优化以前谈过许多次图片问题。也给出了几种方案。在实际使用中这几种无疑是可行而且方便的：loadingconnection API + promise.all()异步加载图片骨架屏懒加载 + 占位图但是在电商场景下，第一种方案是不可以的：我们不能为了一张图片而放弃整个内容对用户的正常展现。（尤其是这个图片还只是个背景图）第二种方案在首页是有奇效的，但是笔者觉得限制太多 —— 如果对于“通用型”的方案来说，骨架屏似乎更适合中大型项目。这个方案当时提出的场景是：在我校的实验系统首页会有

以前来说，单复选框与后跟文字的对其问题其实大多出现在 `font-size` 为 `12px` 的场景下。在现在默认和常用的 `14px`下其实应该是不会出现的。随着浏览器的不断发展，对css的支持程度以及不同的实现方式，我们大概要时刻注意相关问题的产生...

你一定知道 JS 动画的优先级 < css 动画。即使必要，用 JS 操作class的优先级也一定 > 用 JS 直接修改具体样式。但是如果问到：“你了解css动画的性能么？如何优化？”你该怎么解决？CSS中有两个至关重要的概念 —— 重排和重绘。由此，通常会有一个问题：“为什么重排比重绘更耗性能？”要解释这个，还要回到浏览器的渲染原理上：自上而下解析 DOM，生成 DOM 树；解析 CSS，生成 CSSOM 树；（加载js代码）DOM 树和 CSSOM 树节点一一对应，结合生成

有时候你在vue项目中做路由跳转时，可能是比如elementUI的memn同级跳转，也可能是比如root.vue中做身份校验跳转，总之，可能会遇到这样的报错：Uncaught (in promise) NavigationDuplicated:...你说他难看吧，也确实难看。但要说是个错误吧，也不影响正常逻辑。但是有错误还是要解决的。这个问题其实是vue-router3版本更新后和老的写法之间的兼容问题。其实有三种解决方法。网上的解决方案几乎都是第一种，但这样是会出问题的！先说导致问题的原因：

这是我又一次探究文字溢出相关问题，也是我在用户体验道路上踏出的又一小步。之前提到“文字溢出”瞬间就能想到 ellipsis。再接触的多了一点会同时想到 display: -webkit-box;（多行溢出）。你一定欣喜若狂，认为掌握了“宇宙之玄妙”，拥有了“制胜之法宝”。但是如果你就此而去，你仍会时不时的发出疑问：“为什么我的溢出省略没有生效？”先说，目前已知的所有相关问题最终都可以归结为一个点上：行内样式与块级样式。包括一个很可惜的、似乎还没有文章给出具体说明的一个问题 —— flex！fl.