前段时间客户端这边做了一个爆款活动，我这边支持了一下h5页面，也是我做了这么久的web页面之后第一次尝试做移动端和使用jsbridge，同时因为我们的服务有使用nodejs踩了一些坑，在这里记录一下。
端内开发代码规范
这里只记录了几个开发的时候没有注意到的坑
1. 无衬线字体
由于一开始UI给的prd里的字体不是浏览器自带的字体，因此我这边使用了默认字体，没有特意的添加font-family属性，后来在实际页面中发现文字都变成了带衬线的字体了，被UI提醒了一下才改成了Helvetica字体。
并且iOS的字体库和Android的字体库不同，在Android下可以正常访问的字体可能因为在iOS中不存在而命中黑体，因此要在全局设置font-family
font-family: "Helvetica Neue", Helvetica, STHeiTi, sans-serif;
复制代码2. 禁止用户长按链接与图片弹出菜单和选中文本
为了为了优化页面体验，我们在页面中应该禁止用户长按链接和图片弹出菜单的功能，以及禁用选中文本功能。
a, img {
-webkit-touch-callout: none; /* 禁止长按链接与图片弹出菜单 */
}
html, body {
-webkit-user-select: none;
user-select: none;-webkit-touch-callout: none;
}
复制代码3. rem与dpr
这里我们使用的hotcss这个库，一开始按照正常的rem开发去做，后来发现大小一直不对，最终从头排查了一遍，发现是hotcss计算出的dpr是3而不是1，导致meta标签最后是这个样子的：
<meta name="viewport" content="width=device-width, initial-scale=0.3333333333333333, minimum-scale=0.3333333333333333, maximum-scale=0.3333333333333333, user-scalable=no">
复制代码因此正常的计算出来的rem还要除3，如hotcss计算出的font-size为67.5px，dpr为1/3，则最终的单位应该为$px/22.5 + rem。
4. 性能优化
移动端的性能较web来说要差很多，因此要做很多的优化
- 图片压缩。压缩图片，尽可能将图片压缩2-3次，可以大幅减少图片体积，加快页面加载速度。图片压缩地址：tinypng.com/
- 尽可能将常用数据离线化，储存在
localStorage中。 - 首屏请求数目尽可能少，尽量限制在4个以内，小图片尽可能使用精灵图。即使不能使用精灵图也尽可能压缩图片大小。
- 首屏之外的资源使用按需加载和懒加载。
- iOS点击有300ms延迟，因此要禁止页面缩放从而取消点击延迟
- chrome浏览器有自动适配文字大小的机制，开发时如果遇到文字大小和设置的像素大小不一致时记得去掉文字自动适配大小功能。
-webkit-text-size-adjust: none; - 谷歌在线网站评测工具：developers.google.com/speed/pages…
压力测试
node层具体功能：
- 服务端渲染页面
- 转发前端请求，本次活动页面的代码存放在主站的仓库中，由于主站的域名不在客户端那边的白名单中（不是主站的客户端，另一个产品），因此需要node进行一次请求转发。
以前我们做压测都是对后端接口进行压测，这次由于使用了node进行SSR，并且node还有接口转发，因此还需要对node进行压力测试，这也是我们团队第一次对node进行压测。
指标：
- 测试接口的qps负载能力
- 测试返回结果500所占的比例
- 测试接口响应时间
- 测试页面502的比例
压测优化
本次活动对node层的要求是：SSR接口承载10000qps，转发请求接口承载100000qps。这两个数字其实都是峰值qps，也就是活动结束开奖那一刻的qps，平时qps很低，估计不到100。虽然感觉QA同学对峰值qps的估值也有点离谱，但是既然定了这个目标，我们就需要努力达成。
1. pm2开启cluster模式
由于我们申请的实例是双核的CPU，因此首先想到的是使用pm2的cluster模式充分利用多核机器的优势。
踩坑：pm2里面有一个参数是-i，表示要开启的进程数量，一般是开启和CPU数量相同的进程数量。-i max的意思是开启和当前核心数目相同的进程数目。天真的我就这么干了，后来发现我们的docker是运行在物理机上面的，物理机有60+的核心，使用max之后，pm2直接去读取物理机的核心数目并开启进程……一下就开了60多个进程，然后服务就崩溃了。
2. 请求缓存和打散
由于后端机器数量不足，无法承载10wqps，因此需要前端这边做一些打散和缓存的策略。
- 打散请求。开奖瞬间的请求并不是同时并发发送到后端的，前端这边使用随机数，将所有请求在10s内打散。
- 适当失败。并不是所有请求都需要成功，前端只需要将适当数量的请求发送给后端，其他请求直接返回访问失败请稍后重试的提示就可以了。通常秒杀活动中经常采用此策略，倒计时结束之后所有的用户请求，只有十分之一可以真正到达后端，大部分都在前端就被拒绝了。
- 缓存请求结果。一些开奖活动的结果并不是因人而异，而是大家看到的都一样的，比如锦鲤活动，数千万人参加，最后只有一人中奖，中奖信息所有人看到的都一样。这种情况下就适合使用node缓存策略。当node的接口拿到中奖信息之后，就将该请求的结果存到node的内存中，此后所有的用户请求，node直接读取内存中的数据来返回，不用真的发送给后端去等待响应。这样基本上后端就没有什么压力了，大部分工作node层就做完了，不过这样也就意味着后端的压力都转移到了node这边。
3. 缓存SSR
活动页面一开始要求尽可能快，因此我们这边直接采用了服务端渲染，后来压测的时候发现，由于开启了SSR，一台实例能够承载的qps从3000直接降低到200，但是又不能不使用ssr，因为国外一些地区网速可能会很慢，如果纯粹使用客户端渲染的话，可能页面的加载时间会很长。
因此只能在ssr部分进行优化。
我们第一时间想到的还是利用内存，因为qps很高的时候基本集中在开奖的瞬间，并且这个瞬间的页面是固定的，因此可以直接在node中缓存开奖页面的html字符串。
当第一个用户拿到中奖信息之后，node缓存该次请求生成的html字符串，此后所有的请求都直接从内存中拿这个字符串使用就可以了。
开奖之前的页面原本是不打算做优化的，因为每个用户的信息都不一样，如果放到内存那种的话可能会造成内存泄露，但是又怕有站内的大V宣传次活动导致qps突然增高，如果因为这种原因导致服务器宕机的话就有点丢人了，所以最后还是绝对对开奖之前的活动页面也做一下缓存。
由于页面关于用户信息的部分只有用户名和倒计时剩余时间的不同，因此我们在node中缓存一个没有用户名和倒计时时间的公共字符串，然后请求到数据之后使用正则，将模板字符串中的用户名和倒计时的占位符替换掉即可。
4. 加机器
性能不够，机器来凑。
上面说了那么多，都没有加机器管用。
我们为了支持活动，将4台实例扩容到了150台。用户尽管访问，能宕机算我输。