一.自适应布局
自适应布局可通过百分比宽高和媒体查询配合的方式实现。 但是除了图片外， 自适应布局不是万能的
。空白空间、元素宽高可以压缩，文字的压缩无论如何都有一个极限。 正确的实现方式是预估屏幕水平
方向在哪个像素数区间时以特定方式显示内容。你不去针对性设计原型图,浏览器是不会自动帮你实现
排版的。一般不会使用自适应布局， 即使使用自适应布局，也只能适应指定范围内像素数的屏幕， 超
出范围的无能为力。
二.拖拽和动画
这个其实还好。用户的拖拽操作无非是那么的几种。不过在拖拽过程中如果被拖拽元素里面的子节点个
数发生变化、被拖拽元素宽高发生变化， 这个是一定会卡顿的， 现在不知道怎么去解决。动画的话,
绝大部分可以用css解决, animation、transform和transition能解决大部分, 少部分配合动画事件
监听函数和属性设置api可以实现。
三.svg和canvas
这个大部分是数学问题。
四.讲点其他的
浏览器是多进程的， 每个标签页是一个独立进程， 每个iframe也是一个独立进程。一般情况下， 进
程之间的内存是相互无法访问的, 但是一个进程内的多个线程会有共享的内存。浏览器ui线程和js执
行线程是互斥的,并且浏览器不会在这两个线程之间平均分配时间片。也就是如果ui线程一直工作(比如
一次渲染一亿个复杂节点), 那js执行线程就一直得不到时间片、一直不工作、页面没响应；如果js执行线程一直工作(比
如死循环), 那ui线程也会一直得不到时间片不会重绘页面, 发生的时间js执 行线程也不去处理(死循
环)， 页面也是卡死无响应。对于人眼来说, 如果一秒钟图像变化不少于60次
, 人眼会感觉图是连续流畅的动画, 所以要是浏览器页面看起来不卡顿, 那浏览器ui线程每秒不应重
绘少于60帧，并且在1秒内应该均匀的绘制, 也就是至多每16.67ms绘制一帧。所以我们写的任何一段
js代码, 它的执行时间必须要少于16.67ms,这样才会有剩余 、的时间去处理事件队列的任务、才有
剩余的时间留给ui线程去绘制界面。react采用三种策略提高性能，1是多个setState合并成一次更新
;2是如果一段js执行时间超过16.67ms, 那么react会把这段js分成多散到多帧里面去执行;3是采用虚
拟dom技术, 页面要么不更新， 要么尽可能一次更新到位。
总结: 前端的难点就是页面如何不卡顿
