在工作中，有时会遇到需要一些不能使用分页方式来加载列表数据的业务情况，对于此，我们称这种列表叫做 长列表。比如，在一些外汇交易系统中，前端会实时的展示用户的持仓情况(收益、亏损、收入等)，此时对于用户的持仓列表一般是不能分页的。
使用RequestAnimationFrame，核心部分就是利用transformX实现位移
之前我们在使用vue进行 h5 表单录入的过程中，遇到了Android软键盘弹出，覆盖 h5页面 输入框 问题，在此进行回顾并分享给大家:
在上一节中，我们在监听鼠标移动事件时，将其坐标范围处理为了[-1,1]的范围，使用如下代码
scrollIntoView对页面元素调用，会滚动元素的父容器，将该元素滚动到浏览器的可视区域
然后在你们页面中使用，这里需要将你们原来页面上img标签的src改为data-src，这样在元素处于可视区域,则将data-src中的值放入src，然后达到懒加载的效果
最近组内小程序项目从Taro1迁移到了Taro3，紧跟凹凸实验室的步伐，开发体验确实比版本1好了很多，完全支持React语法，没有了那么多鸡肋的限制，项目的可配置程度也大大放开，充分给予了开发者自由发挥的空间。
在ios手机中，当页面中包含有输入框时，点击输入框，键盘弹起，会让页面中被fixed的元素失效。所以造成了底部吸底和顶部吸顶的元素错位的问题。下面的视频中就出现了这个问题，吸顶元素被推到可视区之外去了，而吸底元素也被推到了键盘之上。
offsetWidth: width + padding + border （披着羊皮的狼）
在移动设备上进行网页的重构或开发，首先得搞明白的就是移动设备上的viewport了，只有明白了viewport的概念以及弄清楚了跟viewport有关的meta标签的使用，才能更好地让我们的网页适配或响应各种不同分辨率的移动设备。
当进行布局的时候，有时候需要div元素根据屏幕的宽度和高度进行自适应，而不是根据内容
rpx单位是微信小程序中css的尺寸单位，rpx可以根据屏幕宽度进行自适应。官方推荐微信小程序可以用iPhone6 作为视觉稿的标准。规定屏幕宽为750rpx。如在 iPhone6 上，屏幕宽度为750 px，则共有个750 物理像素，则750 rpx = 375px = 750 物理像素 例如 : 1rpx = 0.5px = 1物理像素
一、offset家族 1、offsetWidth offsetHeight offsetLeft offsetTop offsetParent共同组成了offset家族，用来获取元素尺寸。 offsetWidth = width + padding + border offsetHeight = height + padding + border 2、offsetLeft 和 offsetTop: 返回距离上级带有定位的盒子左边的位置，如果父级元素没有定位，则以body为准 offsetLeft从父亲的
随着移动端的流行，在移动端对网站进行重构和开发势在必行。但是你只有了解了移动设备的meta viewport参数之后，才能更好地让我们的网页适配或响应各种不同分辨率的移动设备。
最近公司在招人，对于移动端自适应的问题大部分回答的都不在我认为的答案。今天说一下自己对移动端自适应的理解，有错欢迎指正。
3.最终签核完，生成PDF版的销售合同，且上面自动加盖公司的电子印章，并打印该合同
mask遮罩蒙层使用通常的写法的bug 通常写法pug .mask 通常写法css .mask{ position: absolute; top: 0; right: 0; bottom: 0; left: 0; z-index: 100; /*移动端*/ background: rgba(0,0,0,.5); /*ie*/ background: #000; opacity: 0.5; filter: alpha(opacity = 0.5); } 但是这种适用于内容小于屏幕高度的，如果内容撑出屏幕，那
在一些电商的小程序项目中，长列表是一个很普遍的场景，在加载大量的列表数据的过程中，可能会遇到手机卡顿，白屏等问题。也许数据进行分页处理可以防止一次性加载数据带来的性能影响，但是随着数据量越来越大，还是会让小程序应用越来越卡顿，响应速度越来越慢。这种问题不仅仅在小程序上，在移动端 h5 项目中同样存在。
[获取元素具体的某个样式值] 1.[元素].style.xxx 操作获取 只能获取所有写在元素行内上的样式(不写在行内上,不管你写没写都获取不到,真实项目中我们很少会把样式写在行内上),outer.style.width =>'' (width是写在样式表中的) 2.获取当前元素所有经过浏览器计算的样式 经过计算的样式：只要当前元素可以在页面中呈现（或者浏览器渲染它了），那么它的样式都是被计算过的 不管当前样式写在哪,不管你是否写了(浏览器会给元素设置一些默认样式) 标准浏览器(IE9+) window.getComputedStyle([元素],[伪类,一般都写null]) 获取到当前元素所有被浏览器计算过的样式(对象) IE6~8 [元素].currentStyle 获取经过计算的样式
前端开发过程中，尺寸单位是我们必须用到的，下面我们对css中常见的几种尺寸单位px,em,rem,rpx进行逐一介绍 在这之前，需要先对几个概念进行普及介绍
对于移动端开发而言，为了做到页面高清的效果，视觉稿的规范往往会遵循以下两点： 1.首先，选取一款手机的屏幕宽高作为基准(现在一般选取iphone6的375×667)。之前项目中也用到过iphone5的320×568。 2.对于retina屏幕(如: dpr=2)，为了达到高清效果，视觉稿的画布大小会是基准的2倍，也就是说像素点个数是原来的4倍（对iphone6而言：原先的375×667，就会变成750×1334）。
在于你的布局，可以用定位position:fixed;来做处理，因为他相对于页面来说，定位于屏幕一定的位置。
在一个View中，系统提供了scrollTo、scrollBy两种方式来改变一个View的位置。这两个方法的区别非常好理解，与英文中To与By的区别类似，scrollTo(x, y)标识移动到一个具体的坐标点(x, y)，而scrollBy(dx, dy)表示移动的增量为dx、dy。
一、懒加载 1.什么是懒加载 目前，网络上各大论坛，尤其是一些图片类型的网站上，在图片加载时均采用了一种名为懒加载的方式，具体表现为，当页面被请求时，只加载可视区域的图片，其它部分的图片则不加载，只有这些图片出现在可视区域时才会动态加载这些图片，从而节约了网络带宽和提高了初次加载的速度。 2.懒加载的原理 页面中的img元素，如果没有src属性，浏览器就不会发出请求去下载图片，只有通过javascript设置了图片路径，浏览器才会发送请求。 懒加载的原理就是先在页面中把所有的图片统一使用一张占位图进行占位，
在平时开发的时候我们总会遇到长列表，因为本身web在长列表的性能并不是特别好；加之web本身受到网络波动影响特别大，在首屏同时加载过多的内容会导致卡顿不流畅响应速度慢等问题。对此我们常用懒加载机制来进行优化。
在日常的项目中经常需要获取屏幕的宽度或者高度，简单记录一下： Javascript方法获取： document.body.clientWidth //网页可见区域宽 document.body.clientHeight //网页可见区域高 document.body.offsetWidth //网页可见区域宽(包括边线的宽) document.body.offsetHeight //网页可见区域高(包括边线的高) document.body.scrollWidth //网页正文全文宽 document.b
最直接的方法就是直接渲染出来，但是这样的做法肯定是不可取的，因为直接渲染太耗性能了。
在移动设备上进行网页的重构或开发，首先得搞明白的就是移动设备上的viewport了，只有明白了viewport的概念以及弄清楚了跟viewport有关的meta标签的使用，才能更好地让我们的网页适配或响应各种不同分辨率的移动设备。 一、viewport的概念 通俗的讲，移动设备上的viewport就是设备的屏幕上能用来显示我们的网页的那一块区域，在具体一点，就是浏览器上(也可能是一个app中的webview)用来显示网页的那部分区域，但viewport又不局限于浏览器可视区域的大小，它可能比浏览器的可视区域
Dom结构 使用 clientHeight scrollTop offsetTop 判断 document.addEventListener('scroll', () => { // 屏幕可视区域的高度
为了理解插件背后的原理机制，我们实现一个自己简易版的虚拟列表，希望在实际业务项目中能带来一些思考和帮助。
实习期间主要在写微信端H5，遇到的最大问题就是适配各个不同尺寸的屏幕。公司就我自己一个前端，只能自己摸索着来。
在OpenGL中有两个重要的投影变换：正交投影(Orthographic Projection)和透视投影(Perspective Projection)，二者各有对应的变换矩阵。初学者比较难理解这两个矩阵是怎么来的。本文从数学角度来反向推导两个投影矩阵。 推导的思路 正交投影和透视投影的作用都是把用户坐标映射到OpenGL的可视区域。如果我们能根据二者的变换矩阵来推出最终经过映射的坐标范围恰好是OpenGL的可视区域，也就是反向推导出了这两个投影矩阵。 OpenGL的可视区域的坐标范围是一个边长为2
懒加载其实就是延迟加载，是一种对网页性能优化的方式，比如当访问一个页面的时候，优先显示可视区域的图片而不一次性加载所有图片，当需要显示的时候再发送图片请求，避免打开网页时加载过多资源。
Lazyload 可以加快网页访问速度，减少请求，实现思路就是判断图片元素是否可见来决定是否加载图片。当图片位于浏览器视口 (viewport) 中时，动态设置 标签的 src 属性，浏览器会根据 src 属性发送请求加载图片。
事件对象可以拿到 pageY、clientY、offsetY，分别代表到点击的位置到文档顶部，到可视区域顶部，到触发事件的元素顶部的距离。
如果您使用的是jQuery，则可以使用jQuery方法获取窗口或document的大小：
chrome和safari一条龙通杀!完全支持所有属性.其中(offsetX和layerX都是以border为参考点)
图片懒加载其实已经是一个近乎“烂大街”的词语了，在大大小小的面试中也会被频繁的问到，我在之前的面试中也被问到了图片懒加载的原因、实现方式及底层原理，但由于自己平时很少做“图片”相关的处理，对于“懒加载”也是知之甚少，所以在面试中问答的也不是很好。
公司这边要写一个温度的下拉框，35-42度，以0.1步进。算下来有好几十个，需求是做成下拉框可以拉动选择温度的形式。尝试了很多UI包括select，其中遇到不同的bug，作个记录。
前端性能优化，是每个前端必备的技能，优化自己的代码，使自己的网址可以更加快速的访问打开，减少用户等待，今天就会从几个方面说起前端性能优化的方案，
通俗来讲，移动设备上的viewport就是设备的屏幕上能用来显示我们的网页的那一块区域。
懒加载其实就是延迟加载，是一种对网页性能优化可方式，比如当访问一个页面的时候，优先显示可视区域的图片而不一次性加载所有图片，当需要显示的时候再发送图片请求，避免打开网页时加载过多资源。
使用requestAnimationFrame代替setTimeout和setInterval：
懒加载 即延迟加载，在电商或是页面很长的业务场景中，我们通常会使用懒加载的方式对图片进行请求，只有在图片进入可视区域之后才请求图片资源，而在之前都通过一张占位图进行占位，将真正的图片路径存储在元素的 data-url 中，这样做的好处在于减少无效资源的加载，并不是所有的用户都会浏览完网站的所有图片，而且浏览器是存在并发上限的，并发加载的资源过多会阻塞 JS 的加载，影响网站的正常使用
第一次变换 模型变换（Model Transforms）：就是指从模型空间转换到世界空间的过程
服务端渲染后的图片地址并不立即赋给img标签的src属性，而是赋给自定义属性如data-src 当img标签呈现在当前浏览器可视窗口时，动态设置img标签的src属性
组件、图片、路由对页面加载速度影响非常大。比如，当一个页面内容比较多的时候，加载速度就会大大的降低，极大的影响到用户体验 。更有甚者，一个页面可能会有几百个图片，但是页面上仅仅只显示前几张图片，那其他的图片是否可以晚点加载用于提高性能。
老马初始学习视口的概念的时候，看了很多的文章，看来很多的资料，鲜有人能把这个东西讲的非常透彻的。老马接下来就从初学者能看懂的角度去讲解视口和适配的方案。 1. 关于屏幕 1.1 屏幕尺寸 设备屏幕尺寸是指屏幕的对角线长度。比如：iphone6/7是4.7寸，iphone6/7p是5.5寸。 1英寸 = 2.54厘米 3.5in = 3.5*2.54cm = 8.89cm 4.0in = 4.0*2.54cm = 10.16cm 4.8in = 4.8*2.54cm = 12.192cm 5.0in = 5.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
