整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
读一开始我们的H5页面秒开率只有30%左右，现在我们的H5页面秒开率达到了 75%。这中间巨大的差异究竟有哪些黑科技在里面？我们为什么要做H5页面的秒开优化？我们的秒开指标是如何统计的？客户端和H5是怎么配合做到 1+1>2的？监控是如何发现H5页面可优化项的？我们又通过监控发现了哪些可优化的问题呢？
H5秒开优化是一个老生常谈的问题，本文将逐步介绍如何通过客户端 + H5 的优化手段（1+1>2）把秒开从 30% 提升到 75% ？后续接口预请求、客户端预渲染以及预加载2.0上线后还会再次助力指标提升。
为什么要做优化？
Global Web Performance Matters for ecommerce 的报告中指出：
整体系统架构图：
首先讲一下得物用来衡量秒开的指标 FMP，那为什么不选择 FCP 或者 LCP 呢？FCP 只有要渲染就会触发，LCP 兼容性不佳，得物希望站在用户的角度来衡量秒开这件事情，用户从点击打开一个WebView到首屏内容完整的呈现出来的时间点就是得物定义的FMP触发时机。
指标清楚了之后，再来看一下完整的 FMP 包含哪些耗时。
接下来将分为两大部分进行介绍，客户端优化部分和H5 优化部分。
通过 HTML 预加载、HTML 预请求、离线包、接口预请求、链接保活、预渲染等手段提升页面首屏打开速度，其中预加载、预请求、离线包分别可提升10%左右的秒开。
通过配置由客户端提前下载好HTML主文档，当用户访问时直接使用已经下载好的HTML文档，以此减少HTML网络请求时间，从而提升网页打开速度。
前人栽树后人乘凉，得物App有很多的资源位，banner、金刚位、中通位等，这些位置显示什么内容，早就已经是智能推荐算法产出的了，那么就可以直接指定这些资源位进行预加载。
页面被预加载之后，总不能一直不更新吧？那么什么时候更新页面的缓存呢？
被现实打脸：
但是在后面的灰度过程中被现实狠狠的教育了一顿，发现有些SSR的页面会涉及到状态的变更，比如说：领劵场景。这些状态都是经过SSR服务渲染好的，用户在进入页面时还没有领劵，这个时候去更新HTML文档，实属更新了个寂寞，在用户领劵之后关闭页面再次进入，发现页面中的状态仍是让用户领劵，点击领劵又告诉人家你已经领过了。
改进措施
至此问题也解决了，工程师的任务结束了吗？如果你认为功能做上去就算结束，那么此时此刻请你一定要转变思维，想一想我们的目标是什么？我们的目标是「提升秒开」，预加载只是一种提升秒开的手段，但是在功能做上去之后并不知道这个功能带来了多少秒开的收益，因此在把功能开发完成上线之后，就要开始关注上线之后的结果，来看看预加载的性能表现如何。从下图可以看到，预加载开启状态下可提升10%以上的秒开率。
（1）SSR服务扩容
要解决服务器压力问题，很自然就会想到增加机器，于是我们对SSR机器数量做了一次扩容，将机器数量提升了一倍，这个时候继续尝试扩大预加载的用户数量，但是仍然无法抗住这么大的QPS，而且此时还引发了第二个问题，算法部门的服务器发出了告警，于是放量计划又一次遇到了阻碍。
（2）破局者 CDN
利用CDN 服务器的缓存能力既可以减轻 SSR 服务器的压力又可以减少后端服务链路的压力，这么好的东西为什么不用呢？这里留个悬念，后面将H5优化部分会详细介绍。
（3）客户端配合改造
支持针对CDN域名进行全部开放预加载能力，针对非CDN域名保持原有放量比例。
在这个过程中还分析了页面的流量占比，发现开屏广告来源的页面流量占比也很高，那么是不是可以把开屏广告的HTML文档内容也给预加载下来呢？
开屏页面预加载策略
既然可以提前下载好HTML，那是不是可以更进一步，提前把页面内的资源加载好，这样在打开一个页面的时候可以减少大部分的网络请求从而更快速的把内容呈现给用户。这里还需要考虑如何跟下面讲到的离线包进行协作。
在WebView初始化同时，去请求HTML主文档，等待HTML文档下载完成 且 WebView初始成功后渲染，减少用户等待时间，客户端请求成功后，WebView加载本地 HTML，并保存以供下次使用。预请求HTML开启状态下可提升8%左右的秒开。
预请求 VS 预加载
本质上HTML预加载和HTML预请求的区别就是下载HTML文档的时机不同， 预加载是在App启动后用户无任何操作的情况下就会去下载，但是预请求只会在用户单击打开H5页面的时候才会去下载。如果用户是第二次打开某个H5页面，此时发现本地有已经下载好的HTML且尚未过期就会直接使用，这个时候的行为表现就跟预加载的功能是一致的了。
上线之后发现预请求只提升了2%左右的秒开，经过分析发现问题：
在本地用低端机对整个秒开耗时链路进行了分析，为什么要用低端机分析呢？低端机有个好处，天然的加上了慢放功能，可以最大程度发现问题。
从图中可以看出h5 页面加载之前 耗时 分布在 activityStart() 函数，该函数 包含了 onCreateView ，其中耗时最长是 布局填充 inflate()，因为 WebView 对象是提前创建好的，直接从对象池中取出的，所以耗时主要在 初始化过程，WebView 自身的初始化 WebViewChromiumFactoryProvider. startYourEngines （耗时 87 us，不到 1 ms），耗时还有 WebView 的一些其他初始化，jockey 的初始化 等等。
而秒开的计算是包含了 View 初始化到 WebVIew url 加载 的耗时，从而发现了优化点，可以将Webview loadUrl 前置，h5 页面加载 与 原生布局填充并行执行。在 onCreateView 时，创建 FrameLayout 进行返回，执行 WebView loadUrl 之后，主线程开始 对布局进行 inflate，布局加载成功后，将其 addView 到 FrameLayout 中，减少了 loadUrl 的阻塞时长。中高端机型有 15ms 左右优化，低端机型有 30 ~ 50 ms 优化 效果。
预请求HTML时机是在进入到 native 页面中，这个时间点距离用户单击事件已经过去100ms，那么是否可以将下载HTML的时机提前呢？经过一番探索，最终选择在路由阶段进行拦截，既可以统一收口而且距离用户点击的时间间隔可以忽略不计。通过这种方式将下载HTML时机提前了平均80ms+。
此时的流程变成了下面这样。
可能有的同学会问了，为什么不在用户点击的时候去下载呢？从用户点击到路由肯定还是有耗时的。
在上述问题解决后，将缓存时间修改为1天，发现预请求HTML开启状态下可提升8%左右的秒开，已经和预加载的效果相差不大了。
通过提前将H5页面内所需的css、js等资源聚合在一个压缩包内，由客户端在App启动后进行下载解压缩，在后续访问H5页面时，匹配是否有本地离线资源，从而加速页面访问速度。
资源拦截这块安卓这边实现比较简单，WebView支持 shouldInterceptRequest, 可以在该方法内检测是否需要进行资源拦截，需要的话返回 WebResourceResponse 对象，不需要直接返回 null。
但是在iOS 这边遇到了一些困难，调研了以下方案：
NSURLProtocol 拦截方式，使用WKBrowsingContextController和registerSchemeForCustomProtocol。通过反射的方式拿到了私有的 class/selector。通过把注册把 http 和 https 请求交给 NSURLProtocol 处理。通过这种方式确实可以拦截请求，但是发现post请求的body会出现丢失的问题。而且NSURLProtocol一经注册就是全局开启。我们希望他只会拦截接入了离线包的页面，但是没有办法控制他，他会拦截所有页面的请求，包括第三方合作页面，显然这是无法接受的。
在iOS 11及以上系统中, 拥有了加载自定义资源的API：WKURLSchemeHandler。
可以修改当前页面url为自定义 scheme 协议，比如：https://fast.dewu.com 修改为 duapp://fast.dewu.com 然后在客户端内注册该 scheme，前端配合修改页面内所有的资源请求未自适应协议，如：src="//fast.dewu.com/xxx" 就可以实现拦截。但是在测试过程中发现，接口为了安全起见只允许白名单内的域名发起跨域请求，且无法配置多个域名，导致该方案无法继续进行。
仍然是使用 WKURLSchemeHandler 然后通过 hook WKWebview 的 handlesURLScheme 方法来支持 http 和 https 请求的代理。通过这种方式虽然可以拦截请求了，但是遇到了以下问题：
（1）body丢失问题
不过在 iOS 11.3 之后对这种情况做了修复处理，只有 blob 类型的数据会丢失。需要由JS来代理 fetch 和 XMLHttpRequest 的行为，在请求发起时将 body 内容通过 JSBridge 告知 native，并将请求交给客户端进行发起，客户端在请求完成后 callback js 方法。
（2）Cookie 丢失、无法使用问题
通过代理 document.cookie 赋值和取值动作，交由客户端来进行管理，但是这里需要额外注意一点，需要做好跨域校验，防止恶意页面对cookie进行修改。
至此功能开发完成上线，先来一组线上收益数据，安卓开启离线情况有有10%左右的收益，但是iOS开启离线的反而秒开率更低。经过修复处理后iOS也可提升10%以上的秒开。
安卓和iOS实现差异
经过分析对比发现，安卓的拦截动作比较轻，可以判断是否需要拦截，不需要拦截可以交给WebView自己去请求。
但是iOS这边一旦页面开启拦截后，页面中所有的http和https请求都会被拦截掉，由客户端发起请求进行响应，无法将请求交还给WebView自己去发起。
iOS 缓存问题修复
页面中的资源经过客户端请求代理后原本第二次打开WebView本身会使用缓存的内存，现在缓存也失效了，于是只能在客户端内实现了一套缓存机制。
从下图可以看到离线包的下载错误率在 6% 左右浮动，这么高的下载错误率肯定是无法接受的， 经过一系列优化手段，把离线包下载错误率从6%左右浮动下降至 0.3%左右浮动。
先来看下优化前的流程图和问题点。
通过埋点发现大量 unknown host 、网络请求失败、网络连接断开的情况。分析代码发现下载未做队列控制，会同时并发下载多个离线包，从而导致多个下载任务争抢资源的情况。针对发现的问题点做出了以下优化：
下面是优化之后的流程图：
针对离线资源是直接存储在磁盘上的，每次访问都会有磁盘IO耗时，经过在低端机器上做测试发现这个耗时会在 0 - 10ms 之间进行波动，后面会把内存合理的利用起来，通过设置内存上限，文件数量上限，甚至是文件类型，并通过 LRU 策略进行内存文件的淘汰更新。
通过客户端发起H5页面首屏接口请求，远比等待客户端页面初始化、下载HTML、JS下载执行的时机更提前，从而节省用户的首屏等待时间。在本地测试过程中发现接口预请求可提前100+ms，用户也就可以更快的看到内容。
客户端会在App启动后获取配置，保存支持预请求的页面地址及对应的接口信息，在用户打开WebView时，会并行发起对应预请求的接口，并保存结果。当JS执行开始获取首屏数据时，会先询问客户端是否已经存有对应的响应数据，如果此时已经拿到数据则无需发起请求，否则 js 也会发起接口请求并开启竞速模式。以下是整体流程图：
那么客户端怎么知道这个页面需要请求什么接口呢？以及接口的参数是什么呢？那自然少不了配置平台，它支持以下功能：
首先即使是在 SSR 的情况下，首屏内容中仍然可能有部分组件是骨架直出的，需要等待页面渲染执行时才会去请求数据，另外还有一部分页面是SPA的。针对这两种情况都能做到很好的补充。
开启后DNS 90分位耗时从80ms降至0ms，TCP建连90分位耗时从65ms分位耗时降为0，DNS平均耗时从55ms降为4.3ms，TCP建连平均耗时从30ms降为2.5ms。
通过上图可以看到一个网络请求在经过DNS解析耗时、TCP建连耗时、SSL建连耗时阶段之后才能把请求发出去，那么是否可以节省这段时间的耗时呢？
客户端常用的网络请求框架如OkHttp等，都能完整支持http1.1与HTTP2的功能，也就支持连接复用。了解了这个连接复用机制优势，那就可以利用起来，比如在APP开屏等待的时候，就预先建立关键域名的连接，这样进入相应页面后可以更快的获取到网络请求结果，给予用户更好体验。在网络环境偏差的情况下，这种预连接理论上会有更好的效果。
可以通过对域名链接提前发起一个HEAD请求从而建立链接，网络框架会自动将连接放入连接池。并在默认无操作5分钟后进行释放，在五分钟内重复执行上述动作即可一直保持链接。
另外这里需要注意下连接池的数量问题，如果连接池的数据太小，但是域名比较多的话，通过预建连保持的链接很容易就会被释放掉，这就需要通过域名收敛或者调大连接池的数量来进行优化。
那预建连会不会增加服务器的压力呢？这个肯定是会的，首先会针对预建连功能本身就行灰度策略，在HTML页面通过CDN托管后，直接针对 cdn 域名进行全量开启，从而不用担心 cdn 域名扛不住压力。
来看一下线上效果，通过下图可以看到在开启后DNS 90分位耗时从80ms降至0ms，TCP建连90分位耗时从65ms分位耗时降为0，DNS平均耗时从55ms降为4.3ms，TCP建连平均耗时从30ms降为2.5ms。
客户端提前通过WebView将页面渲染好，等待用户访问时，可直接展示。从而达到瞬开效果。但是这种功能肯定不能对所有的页面进行开放，而且存在一定的弊端。
下图【开学季】是业务上已经进行预渲染的H5页面，可以看到在打开【开学季】页面时，页面已经渲染完毕，丝毫没有等待过程。
后面计划把这种能力放大到通用的webview上，针对大促以及PV量高的页面进行开放。
SSR服务端渲染（英语：server side render）一般情况下，一个H5页面的数据渲染完全由客户端来完成，先通过AJAX请求到页面数据并把相应的数据填充到模板，形成完整的页面来呈现给用户。而服务端渲染把数据的请求和模板的填充放在了服务端，并把渲染的完整的页面返回给客户端。
SSR对于秒开有平均15%的提升，既然是服务端渲染，就会对服务器造成压力，尤其是在预加载HTML功能开启后，那得物是如何解决的呢？
通过这么多优化手段仍然无法满足预加载的需求，并且通过分析发现网络阶段耗时较长，最终还是搬出了CDN这个大杀器，一直没上CDN的原因有很多，主要有以下几方面：
（1）得物的页面是千人千面的每个人看到的内容都不同
通过上述优化4即可解决，将原本SSR渲染的内容修改CSR，由于已经上了CDN了，后续计划将这部分内容再次修改回SSR，这样用户可以更快的看到商品而不是骨架，然后通过 CSR 的方式来更新内容。
（2）页面状态变更，无法及时更新缓存
这个问题在上述客户端预加载优化部分已经有解决方案了，可以通过在页面打开后针对有需要的组件再次请求接口刷新数据以确保数据的准确性，但是这部分工作量也是比较大的，梳理出来的需要刷新状态的组件就有30+，而且之后开发的组件都需要考虑状态更新的事情。
（3）HTML模板内容变更无法及时更新
引起模板内容变更的地方有两处，第一个场景就是在搭建器场景下，运营可以动态修改模板内容导致页面结构变更（低频次），第二个场景是项目发版后模板内容需要更新（高频）。
这个问题可以通过在感知到内容变更时自动调用CDN服务商的刷新缓存接口来更新CDN缓存内容。
通过puppeteer将SPA页面渲染出来并将HTML文档进行保存，配合上述页面刷新策略，并将HTML通过CDN进行托管，让你的 SPA 页面 像 SSR 一样丝滑。
主要实现方案是通过基于webpack的插件prerender-spa-plugin，并配置需要预渲染的路由，这样经过打包之后就会产出对应路由的页面。方案本身是通用的，但是每接入一个页面都需要人工check。
众所周知 css 加载会阻塞HTML渲染，最终将首屏公共css从118kb缩减至38kb，下图通过 chrome 模拟弱网环境下的SSR页面加载时序图。从图中可以看出 styles.fb201fce.chunk.css 下载耗时 18s，阻塞了页面的渲染，HTML 主文档耗时 2.38s 就已经下载完成了，但是实际渲染时间却是在 20s 之后。
优化思路也比较单间，将首屏所需要的css 文件通过内联方式内嵌到HTML中，由SSR服务一并返回，并对css文件进行拆分，按需加载。
思路有了，接下来就看怎么去实现了，最初尝试了MiniCssExtractPlugin 插件他可以把css分成单独的文件，并且每一个js会对应生成一个css文件，但是他需要建立在webpack5之上，然而项目中使用的next版本是9.5，于是就想着升级到最新版next12，升级后发现，在构建中其他包各种报错，发现有些包并不支持最新的next12，在尝试一天的修复之后，仍未解决，且升级到最新版不确定是否会引发其他稳定性问题，暂且搁置寻找其他方法。
经过不懈的努力，通过阅读 next 源码发现了端倪，发现在打包时将所有的公共css通过 splitChunks 进行分组，由于项目中组件都是动态引入的，这里直接在 next.config.js 中修改webpack打包参数，将 splitChunks.cacheGroups.styles 配置删除，使用默认的 chunks: async 配置，即可实现按需引入。
（1）避免图片src为空
虽然src属性为空字符串，但浏览器仍然会向服务器发起一个HTTP请求，尤其是在SSR服务器压力扛不住的情况下，因此这里需要特别注意一下。
（2）图片压缩以及格式选择
WebP 的优势体现在它具有更优的图像数据压缩算法，能带来更小的图片体积，而且拥有肉眼识别无差异的图像质量；同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性，在 JPEG 和 PNG 上的转化效果都相当优秀、稳定和统一。
通过向图片服务器传递参数选择合适的分辨率。
（1）打包优化
（2）非关键js、css延迟加载
（3）媒体资源加载优化
（4）其他资源优化
（5）页面渲染优化
（6）代码层面优化
为了帮助开发者更好地衡量和改进前端页面性能，W3C性能小组引入了 Performance API ，其中Navigation Timing API 实现了自动、精准的页面性能打点。得物前端性能监控指标也都是从 Performance API 中获取数据进行上报统计分析的。
SDK 数据采集完毕后，会上报到 阿里云 sls 日志平台，随后通过 flink 实时消费清洗数据后落库至 clickhouse 中，平台后端通过读取 clickhouse 数据并做各种聚合处理后使用。
做优化之前首先要建立监控指标，互联网称之为抓手，没有监控指标的情况下，任你怎么优化，都不知道优化的效果怎么样，更不知道下一步该做什么？以及还有哪些问题没解决。因此优化之前指标先行，当然一定要指标的准确性。
指标大盘主要包含以下功能：
在正常情况下，完成上述的优化措施后用户基本是可以秒开 H5 页面的了。但异常情况总是会有的，用户的网络环境和系统环境千差万别，甚至 WebView 也可能发生内部崩溃。当发生问题时，用户看到的可能就直接只是一个白屏页面了，所以进一步的优化手段就是需要去检测是否发生白屏以及相应的应对措施。
检测白屏最直观的方案就是对 WebView 进行截图，遍历截图的像素点的颜色值，如果非纯色的颜色点超过一定的阈值，就可以认为不是白屏。首先获取包含 WebView 视图的 Bitmap 对象，然后把截图缩小到指定的分辨率大小如:100*auto，遍历检测图片的像素点，当非纯色的像素点大于 5% 的时候就可以认为是非白屏的情况，但是还有很多列外的情况，我们通过图片识别技术对截图进行分析，可以很好的感知当前是否白屏、是不是在loading、是不是特殊页面等。
白屏是一个重要的指标，我们针对整体白屏率快速拉升、新增白屏页面发出告警通知，便于开发人员及时介入开始排查问题。
主要通过 CDN 未覆盖监控、http请求监控、网络监控（加载失败、耗时异常、传输大小异常）、图片监控（未压缩、分辨率异常）等监控手段发现页面中的潜在问题，同时还提供了问题分析能力，在问题分析页面输入页面url地址即可帮助您发现问题并给出修改建议。
CDN的重要性不言而喻，它可以加速资源访问速度，从而提升用户体验，我们通过对线上埋点数据分析，找出CDN未覆盖的资源列表，从而推动各业务同学优化。
为什么要监控HTTP请求呢？我们先来看一下HTTPS相对于HTTP新增的特点：
那么HTTP就容易被中间人查看到内容，甚至被篡改，既然如此为了我们服务的安全性就需要对现有的http协议统一进行升级改造，那就需要监控去发现。
某些页面秒开率低，那就要分析一下原因，是不是这个页面的接口响应比较慢呢，还是说页面本身有请求比较大的资源？如果发生网络请求失败的情况也要第一时间感知，不能被动等待用户反馈。
包含图片未压缩、图片分辨率异常、图片传输大小大于 300kb 异常、动图资源传输大小大于 1M 异常功能。
上面列出来一堆功能，对于业务的同学可能比较烦恼，我一个页面具体有哪些问题呢？你不能让我去上面的功能里面一个个看，哪个异常是我负责的页面的吧？这个功能本身就行将现有的功能利用起来，通过一个页面path进行聚合分析。
H5异常一直是使用 sentry 进行监控的，但是sentry系统因缺乏同PV、DAU数据的关联性，因此无法衡量产品异常发生后所带来的严重程度。在业务域关联上的缺失导致异常问题无法根据业务域进行划分。用户行为日志也尚未与Native 端侧打通，在问题分析时容易遇到上下文不全的瓶颈。还有一个问题是sentry会有限流措施，当qps较高时会丢弃一部分异常数据。
由于sentry已经可以帮助我们进行一定的问题排查分析能力，我们不打算做sentry同样的功能，而是做sentry不支持的部分，针对上述问题我们设计了以下功能：
虽然目前秒开率已经做到了75%以上，但是同时我们还有一个重要的指标，90分位耗时，致力于提升末尾用户H5页面使用体验，在90分位优化完成后，可能会考虑继续深入优化95分位耗时。
至此我们系统的讲解了背景以及从指标建立到秒开优化上线的全过程，全文分成了三个部分，客户端、H5、以及监控。如果阅读本文对您有所收获，麻烦您动一动发财的小手点个赞吧！如果阅读完还意犹未尽或者有什么问题和想法欢迎留言区评论交流。
最后奉上整体优化脑图：
*文/徐铭
欢迎关注「得物技术」微信公众号，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
于OZON的产品详情页来说，有两种形式来表达，分别是：纯文本和富文本形式。这两种形式可以共存，关于富文本Json的内容可以查看历史文章：https://kuajing365.cn/document/4516.html
那么这篇文章主要给大家介绍一下纯文本部分的内容应该写哪些？
如下图所示：纯文本填写的内容在特征页面填写。
审批通过的产品的详情页的描述会出现在产品页面如下图所示位置：
那么关于产品详情页这里，我们主要应该放哪些信息呢：
1、产品的核心关键词：这里也要出现产品的关键词，要将产品词以及核心修饰词、属性词放进去。通常会以句子的形式完成，比如说：这是一双非常轻便的女士跑步鞋。
2、产品的优点或者特点：在这里要将产品的优势罗列出来，起到打动买家的作用。
3、产品的尺寸、颜色、容量等特征：一般来说，在描述的下方会有特征模块。不过在这里可以适当将产品的重要属性列出来。
4、品牌故事或者产品故事：如果你的产品是有品牌的，那么完全可以在这里讲一个故事，或者围绕产品设计一段话。如上图所示的例子，就是专门针对这个拖鞋设计了一段文案，这个文案可以成为通用文案！那么对于俄罗斯用户来说，这种方式会起到情感共鸣的作用，有效提升转化率！
当然，描述信息这里与标题一样，同样有一些注意事项：不能描述脏话，不能包含以下非必要的推广营销信息，比如：“促销”、“销售”、“新奇”、“折扣”、“仅限今天”等词；产品价格；短语“最佳产品”、“独特产品”、“惊人产品”等；配送信息；不需要堆砌关键词！
综上所述，差不多从这四个方面来写描述即可，也不用写的太多，无论是哪个国家用户，对于大段文字其实都是缺乏耐心的！所有更多还是需要配合jason富内容来优化详情页，提升整体支付转化率！
文介绍了制定产品设计规范标准的重要性，也包括行业对于高级产品经理的要求，并以几点详细介绍，包括了制定标准的共同目标、基础要素、设计原则、规范制定的流程以及如何推动规范的执行等。适合产品岗位的你阅读。
每一款产品，都会有它的产品设计规范。例如支付宝小程序，微信小程序，有它的设计风格和交互的审核要求。
而适用于移动应用以及Web设计，可以参考Material Design（Google），强调直观性、一致性和有意义的动效设计。
如果你是ios产品，那首先就得去了解Human Interface Guidelines（Apple），再基于这个设计规范制定符合平台的标准，最通用，最基础的，就当属Microsoft Design Guidelines，适用于Windows平台的设计规范，强调平面化、简洁和直观的设计风格。
为什么要制定产品的规范标准？
制定产品的规范标准可以提高产品的一致性、可用性和用户体验，帮助建立品牌形象、提升用户满意度，并为团队提供明确的指导，提高工作效率和协作效果。
行业对于高级产品经理的要求:
在讲这篇内容之前，先容许我把之前的几篇文章给大家同步一下，感兴趣的小伙伴或者遇到瓶颈的小伙伴一定要看，我相信会对你们的提升带来很大的帮助，内容很长，建议先收藏。
我们先来简单的对规范标准有个概念，有很多小伙伴都总是会在这两个词进行拉扯，但其实这两个词加起来就代表了准则。而规范则是基于标准之下，如支付宝小程序，它的设计规范，对于我们来讲，就是平台的设计标准，我们基于这个标准下再去制定属于自己产品的设计规范。
那我们现在来看看，标准和规范在文学上的区别为：意思不同、出处不同。
① 意思不同
② 出处不同
规范要求和标准的区别：
③ 成因不同
接下来，我们开始今天的主要内容。小编会通过三个篇章，七个章节，给大家提供落地的方法。
倘若你目前刚好处在对于制定产品的规范标准无从下手的阶段，以下内容绝对能够让你按部就班的完成；假如你已经为多个平台制定过标准，也可以参考本篇内容，思考下有没有进步的空间；假如你从来没接触也没有机会制定，那么，这篇文章就是你的敲门砖。
小编总结了十点，先给大家介绍一下，我们为什么要去做这个事情，这个事情给我们带来什么价值。
作为产品，我们必须要清楚一个原则在于：我们做的任何事情，都得有它的价值，要清楚它的目的再去做，拒绝为了做而做的行为，切勿让自己变成了传声筒。
综上所述，制定产品的设计规范标准可以带来许多益处，包括提升用户体验、降低开发成本、增强品牌形象和改善团队协作。
规范的制定和执行有助于打造出一致、优质的产品，提高用户满意度和市场竞争力。
产品设计的常识（Common Sense），很多时候都会被忽略，特别一些小型项目。研发人员会在初期嫌麻烦不对一些常识的问题进行处理，最终导致的影响，往往是影响到产品的本身。
产品一定要把控好这个关卡，谁都可以不懂，产品一定要最清楚最基本的就是系统异常处理设计规范能够有效解决且避免以下七点：
产品设计是否保持一致很容易反映出一个产品经理做事情的严谨性。有不少产品经理设计产品很随意，抱着“能用就行”的态度做设计，结果就会出现整个产品的一致性非常差。
比如，列表的添加按钮一会在页面的右上角，一会在页面的左上角，搞得用户使用不同的页面像是在玩“躲猫猫”游戏一般，学习成本非常高。
再比如移动端，有些页面使用长按删除，有的使用向左滑动删除，还有的需要点击“…”在弹层中点击删除……同一个产品，多种交互形式也会让用户困惑。
至此，产品的规范标准入门篇已经跟大家介绍完了。大家在做任何一个项目的时候，都应该注意入门篇的两个章节，究竟有没有做到位，有没有制定规范标准同步到设计，研发。
入门篇基本满足大部门从0-1的项目，或者是初中级的产品经理所需要掌握的技能，建议大家收藏起来。如果遇到这类任务的时候，就可以以这篇文章，作为你们的任务List，一项一项对应的去检查是否有做到位。那么我相信你们吹来的作品，一定是具备一定的专业度，一致性以及可延展性的。
在入门篇开始之前，先给大家交个底。我们在制定产品入门篇的规范标准时，有一个部门必须拉他们参与进来，那就UI部。UI部门在入门篇的环节，起到了决定性的作用，由他们为主导，我们为辅助的方式，达成一致性的决定。
这一个环节，最重要的目的是让产品与UI保持同频，大家都在统一规范标准下进行设计，为产品添砖加瓦。而且通常我们都会把这个环节以一个功能模块级别的需求去做，也有这个需求的版本，持续优化迭代。
当然，需要优化迭代的时候，那就应该是由产品为主导，在原有的标准下，再去优化规范，最终形成新一版的规范标准。
这个环节也是能够让产品在与UI沟通上的成本减少，在同频基础下工作也有利于减少两个部门之间的摩擦。
相信大家应该也听说过交互设计师这个岗位，大多数在中小型企业很难有资源去匹配这个岗位，一般都是在成熟的互联网公司会有这个岗位的需求。
通过这么个规律我们也可以发现：需要注重交互设计，往往到了产品已经扎根土地，茁壮成长的阶段。
相对比较稳定的时候就会开始考虑这个问题，但并不代表说，交互设计不重要。交互设计对于产品来言，在做需求时，靠的是经验，靠的是竞品分析，靠的是借鉴。
看到这里的小伙伴们，自动自觉对号入座，往往一味的靠经验，靠竞品，靠借鉴，只会让产品的交互五花八门，没有一个体系。单个功能抽出来可能是合理的，方便的；但全部凑在一起的时候，倘若需要用户去适应，那么就适得其反。
因此，我们产品就需要UI同学帮忙一起制定出产品交互设计规范，而产品本身，也应该有一套自己的标准，把控好产品的交互，这样才有利于产品的发展。
接下来，我会通过收集一些常见的交互问题，给大家用实例去介绍产品交互设计规范如何制定。
1）做一个页面交互设计的时候要注意什么？
2）如何理解模态框？
何时应该使用模态框？模态框和阻断框有什么区别？
模态对话框(Modal DialogueBox) ，阻断(Blocking），可以用两个比喻给大家解释：
3）在具体设计一个产品的过程中，把握住哪些关键点才能让整个产品有着一致的交互体验，或者交互模式？比如iOS端和android端，比如web端和移动端？
一致性，在交互设计中非常重要！保持交互一致性，有两个武器：原则和规范。
规范又有两个层面：指南Guidelines和规格
原则
一些指导性的东西，在设计当中要遵从。在整个产品（无论多少端，多少子产品）都要遵守的。
举例：一个界面完成一个任务；表单超过10项必须分步骤；用户必须随时能回到主界面……这些原则可以由不同的形式来实现，但必须遵从这些原则。
规范
文章开头也有提及到，忘记了请翻上去复习一下。
指南：圈定具体的交互模式、色彩搭配和设计禁忌。
在这个层面，一个[构]可以有多个[形]，但某个形只能有一个[构]，达到相同位置、相同外观、相同操作。通过指南能够让各个端（IOS和安卓）看起来似曾相识，便于用户学习和养成习惯。
举例：在没有左侧导航的详情界面，必须包含面包屑；面包屑只能出现在PC浏览器端，不允许出现在响应式web界面中。
IOS和安卓的官方Guidelines就是这样的东西，但也可视情况制定私有的指南，也就是各个公司自己的设计指南。
规格：规格非常具体的描述了每一个模式的每一个形态的具体尺寸、色彩、响应，精确到数值。
举例：一级标题，字号为宋体 18pt；行高30pt；行上下外距为5pt；色值为#CC9300。
3）表单布局有什么规范要注意的？
这个问题是初级产品经理最容易犯的问题，设计太随意，看到别人的就想复制粘贴过来。这个问题正是可以解决很多初级产品常见错误的问题，以及给大家提供一个思路。
这里分享四个常见的表达布局对齐：
首先，我们要清楚，人的视觉是上下，左右的。所以我们会把要填写的标题，放在左边，输入的内容放在右边。这个原因也在于大部分都是右撇子，所以放在右面方便输入，而在左边提到的四点，各有千秋。
关键在于考虑的出发点是用户的视觉，还是表单的体验，抑或者是信息是否足够直观。再者就是是否够简洁，都是可供选择，关键在于选定一个就保持一致。
综上所述我们可以知道，交互设计可以通过交互的显性和交互的隐性去考虑。
交互显性
交互显性指的是用户在页面所有的点击，滑动，跳转的操作，比如刷新方式有下拉、上滑、按压点击等方式。
这就是所谓的交互显性的操作。要保持产品显性操作的统一性，同类别的交互不可有不同的操作感受。同时交互显性要符合大众的认知习惯，可创新但不可违背潜意识，比如说PC端的交互显性是以点击事件作为核心操作的，移动端的交互显性是以滑动作为核心操作的。
交互隐性
交互隐性指的是用户信息发生改变时的显示。比如说订单状态的显示，确认收货后，绿色的标签显示订单已完成，申请售后则有售后的标签，一些平台还会以订单的颜色区分去给用户隐喻。
再举个例子，消息有个小红点，用户就会知道去点，上文也有提到隐喻，很多时候，我们就是通过交互隐性的方式，来引导用户，提示用户，这样的方式有利于让用户自发性去体验，感受平台的功能，带来舒适感。
归根结底，产品的交互离不开创新，一致，符合规范。
本章节我们以Web端为例，我们在设计过程中，需要考虑我们基于什么样的尺寸进行基础设计。划分哪些区域需要固定尺寸、哪些需要做适配等。
据统计，使用中系统的用户的主流分辨率主要为 1920、1440 和 1366。
设计思考，有如下几点：
web页面是按照Html的设计规范标准进行布局设计的，由以下三部分构成:
1）Margin（边距）
为避免页面元素紧贴边沿的情况发生，WEB 页面和其中的表格，应设定边距，最小边距值为 “3px”。
一般粗细直角以1px，圆角为2px。
2）Button（按钮）
按钮一般有三种样式：小、中、大。
按钮是交互设计中必备的元素，它在用户和系统的交互中承担着非常重要的作用。
后台中常见的按钮类型分为线性按钮、文字按钮、图标按钮等。
按钮并列间距为：小间距8px，中间距16px，大间距24px
其中小中大的宽度分别为：58px，74px，96px
3）Table（表单）
常见表单是由多个列表项构成的。而每一个列表项都是由最基本的标签和输入框组成，常规的表单包括单选、多选、下拉选、输入框、时间选择、开关选择等控件。
顶部标签是标签在控件的上方，标签可以和控件左对齐，对于横向空间不足的情况是一种很好的方案。
竖列标签的使用场景思考：
表格的设计思考：
表格的设计规范的设计思考点如下：
表头的文案，可遵循信息降噪的原则思考：
4）Progress bar（进度条）
进度条的设计思考：
加载中进度条，存在加载中、成功、失败三种状态通过颜色去区分，进度条长度支持自定义。
5）Dialog（弹窗）
弹框主要分为两个大类模态弹框和非模态弹框，他们最大的区别就是是否强制用户交互。
常规状态通常出现在页面的上方，有普通信息、成功信息、失败信息、警示信息四种icon。
6）Default（缺省状态）：
缺省页面是当页面没有数据、用户没有建立资料或网络连接不通畅的情况下所展现的页面。
为了缓解用户面对这类情况产生焦虑情绪，设计师可以用一些插画和文字的结合来引导用户进行下一步的操作。
产品风格设计的形成一般通过以下几点：颜色，字体，图标，尺寸决定的。
1）Color（颜色）
色彩内容主要包含基础色（如品牌色、黑色、白色）和功能色（如链接色、提醒色等），图表配色为单独的配色体系。
在前期制定颜色规范的时候，精益求精的设定颜色，切忌颜色过多。
颜色的状态色尽量用原色进行转换，设置一个合理的变色公式，让所有颜色的状态色都根据这个公式进行转换。
例：
在设计规范中，尽量把颜色的色值和 rgba 值都写出来（这里是强迫症患者要标的，因为有时候色值完全一样，但 rgba 数值略有不同，虽然效果一样，但是对于强迫症的你来说，舒服吗？）。
状态色有 4 状态色：Normal、Hover、Click、Disable。
在设定图表颜色的时候，要考虑不同的使用样式（柱状图、环形图、饼图等…），同时也要考虑他的延展性。比如你设定 12 个 chart 色值，在使用的时候按着顺序来使用，当超过 12 个后可以为同一个颜色。
2）Font（文字）
设定统一的字体规范，使用非衬线字体在各个操作系统下都有最佳展示效果。
首先，要设置一个字体家族，保证产品界面的最优展示。
例如（仅作为展示，不是建议）：font-family: “Chinese Quote”, -apple-system, BlinkMacSystemFont, “Segoe UI”, “PingFang SC”, “Hiragino Sans GB”, “Microsoft YaHei”, “Helvetica Neue”, Helvetica, Arial, sans-serif, “Apple Color Emoji”, “Segoe UI Emoji”, “Segoe UI Symbol”;
字号
现在主流的产品中，主体字为 12px / 14px的居多，可根据自身的产品定位以及用户的习惯进行设定。
字号不要出现奇数，否则在一些显示器上会有对不齐像素的状况发生。
字体颜色
字体颜色数量建议在 3~4 个，不宜过多，但是每个层级之间区分要大一些。
文本应该保持至少 4.5:1 （基于亮度值计算）的对比度以保持文本清晰；最佳对比度为 7:1。
测试对比度的网站：https://contrast-ratio.com
WCAG 2.0 中将颜色对比等级分为 3 种，A级，AA级，AAA级，等级越高意味着颜色的对比度越高，呈现出来的视觉压力越大。
3）icon（图标）
设定统一的图标使用规范，让视觉效果更和谐。
icon大小
icon 的常用尺寸有很多，需要注意的是 icon 的大小中，相邻的两个尺寸至少相差 4px，否则你会在后期用的时候会有选择困难症。同时功能 icon 尽量贴边或尽量贴边绘制，保证展现的视觉统一性（操作 icon 除外）。
单独 icon 使用的时候，尽量不要太小，最小值建议为 12px。
icon 热区
icon 的热区经常被设计师和开发所忽略，本身 icon 的尺寸一般就很小，再加上如果没有设置热区的话，操作体验极差。
所以一定一定要设置 icon 的热区，设置的值我建议为 icon 大小的 2倍。例：icon 大小为 14 * 14px，则热区大小为 28 * 28px。
4）size（尺寸）
页面内布局间、模块间、模块内的各部件距离。
尺寸大部分规范中都用的是 8 的倍数，不用纠结，直接用就行。我这里有个公式：Sn=8px * n，n为正整数。特殊：最小支持4px。
进入进阶篇阶段，我们不只是按照行业标准制定规范，也不是按照一些平台标准以及常识问题，去为自己的产品制定规范标准。而是需要投入更多的精力，站在更高的角度去思考要为产品带来什么价值。而价值的体现就在于转化，管理，引导，复用，创新，切忌盲目动手。
在进阶篇没有唯一的标准，都需要各位结合自身产品的业务，产品定位，用户画像去制定。
接下来的内容，也只是小编分享一下比较通用的方法，希望能够帮助有缘人在迷茫的时候有个新思路。
在开始之前，再给大家补充三点，作为进阶篇学习之前，所需要结合着来学习的3个方面：
引导分为 5 种：Newbie guide（新手引导）、Steps guide（步骤引导）、Help / Operation guide（帮助/操作引导）、New function guide（新功能引导）、Blank guide（空白页引导）。
1）Newbie guide（新手引导）
新手引导是针对新用户的，首次进入产品的时候，我们要着重的把自己产品的亮点以及操作快速的介绍给新用户，让他用最短的时间上手我们的产品。
新手引导要言简意赅，并且如果非必要的话，尽量给用户一个可以直接关闭的按钮，让用户有选择权。我就非常讨厌有一些产品的新手引导，必须走完全部流程后才能关闭，恶心的不行。
2）Steps guide（步骤引导）
步骤引导一般用在有固定操作步骤的场景下，指引用户一步一步的完成想要的结果。常规的步骤引导建议在 3~5 步之间为合理。
3）Help/Operation guide（帮助/操作引导）
帮助/操作引导的展现方式是比较丰富多彩的，可以是提示语、辅助性文本、tooltips 等等，他的作用就是辅助用户去了解并且知道如何操作这个功能。
这个也是在产品中使用频率最高的，运用好他，可以让你的产品事半功倍。
4）New function guide（新功能引导）
他就是常用在新功能上线后，用户第一次登陆相关页面后做的一些引导，目的是为了告诉用户我们做了新东西，你快来试试吧。
5）Blank guide（空白页引导）
空白页引导一般用在在缺省页，对用户进行一些操作指引，让无信息的页面变得更有价值。比如百度在一些缺省页上就放了一些关于失踪儿童的信息，就因为做了这个引导，帮助了千万个家庭找到了失散的孩子。
这一章节在很多平台里面，都会给忽略掉它的一个重要性，一个产品的延展性，通用性，易用性和亲密性都离不开一个好的角色设计规范，角色设计的底层逻辑就是产品权限的制定。
目前的主流产品对于权限的制定都有一套规范标准，小编负责的产品也是通过借鉴主流产品权限的制定方式来设计，本章节主要是给大家分享下小编的方法。
我在做权限制定的对象是角色，而不是用户，所以也点一下题，我们在做的是对产品角色设计的规范，并不是对用户权限去做控制，接下来我们先来梳理下在做权限制定的时候常见的问题。
1）权限制定的过程中常遇到的问题有。
我们可管理的权限（系统资源）分为功能权限、数据权限：
这些问题主要都是基于用户作为权限主体的时候会出现的问题。传统的方式就是A -> B -> C 这类型的用户权限去对用户进行管理，对于业务的调整以及对功能模块的拓展是不友好的。
因此，我对于权限管理的理解为权限是主体对客体遵循特定机制做出的行为，而本章节主要是给各位分享RBAC模型。
2）对RBAC模型中的关系描述 – 基于角色的访问控制
RBAC（Role-Based Access Control）是一种访问控制模型，用于管理系统中的用户访问权限。RBAC模型基于角色来定义和分配权限，通过将权限与角色关联，然后将角色分配给用户，实现对系统资源的访问控制。
1. 角色与权限之间的关系：
2. 角色与用户之间的关系：
这些关系形成了RBAC模型的基本结构，通过这些关系的建立和管理，可以实现对用户访问权限的控制和管理。
3）对RBAC模型的分析
RBAC模型的优点包括：
然而，RBAC模型也存在一些挑战，如角色爆炸问题（角色数量过多）、权限维护复杂、权限继承问题等。在实施RBAC模型时，需要仔细设计角色和权限的结构，平衡权限的粒度和灵活性，以及确保合理的权限继承和分配策略。
4）分享一个使用RBAC模型的实例
假设有一个在线学习平台，涉及学生、教师和管理员三个角色，以及对应的权限：
1. 角色与权限之间的关系：
2. 角色与用户之间的关系：
3. 在该实例中，RBAC模型的使用如下：
通过RBAC模型，该在线学习平台实现了对不同角色的权限控制，确保每个用户只能执行其角色所允许的操作，从而提供了安全和可控的访问控制机制。
5）最后，对本章节进行一个总结
在权限模型里面有两个核心概念，第一个是静态指责分离，第二个是动态指责分离
静态职责分离
互斥角色限制：有些特殊的岗位，同一个用户在两个互斥的角色中只能选择一个。
比如财务和审计，不能既是运动员又做裁判。
基数限制：考虑容量、并发等的问题，一个用户拥有的角色是有限的，一个角色拥有的权限也是有限的，一个角色下的用户也是有限的。
比如微信公众平台做的限制：一个微信号可绑定并管理5个公众号。
先决条件限制：用户想要获得高级别的角色，必须先获得低级别的角色。
比如一个PMer需要先从专员做起，再升为产品经理，再到产品总监。
这种条件限制在人员规模比较大的团队就很常见了，人越多越需要严格且清晰的制度，避免个别的take a shortcut影响大局的稳定。
动态职责分离
动态的限制用户及其拥有的角色。
一个用户可以拥有多个角色，但是运行时只能激活一个角色。
常见就像招聘网站这种，用户既可以招人也可以找工作，角色不同看到的信息完全不一样，所以就只能激活其中一个角色。
最后给大家总结一下今天分享出来的内容，产品设计的规范标准，具体的规范还会根据产品的特点、行业要求和用户需求而有所不同。
在制定产品设计规范时，需要综合考虑用户体验、技术可行性、业务目标和品牌形象等因素，以确保产品能够提供优质的用户体验并达到预期的目标。
归纳为以下8点：
本文由@乐少有话说 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
*请认真填写需求信息，我们会在24小时内与您取得联系。
