全文 8000 字，预计浏览工夫 18 分钟

一、前言

百度 ToB 垂类账号权限平台（以下简称平台），是专一于为百度 ToB 垂类各产品线提供通用账号权限服务的根底平台，所提供的服务涵盖了租户治理、账号治理、单点登录、权限管控、账号平安、企业资质。业务方将账号、权限相干服务托管给平台后能够专一于本身的业务研发。目前曾经接入了爱番番、爱洽购、寻客宝、出海易一期产品线总计超过 1000 万的企业账号，为各 ToB 垂类业务提供一站式账号与权限解决方案，以下是简化版的业务架构图：

△平台业务架构

以下列出了必要的名词解释，便于更好地了解本文内容：

二、账号登录服务

2.1 企业组织与账号模型

=================

平台反对一个客户在多个产品线注册多个租户，租户间的数据彼此隔离，每个租户默认创立一个主账号领有最大的超级管理员权限，并生成具备管辖关系的租户组织构造树。主账号能够创立多个子账号，每个账号能够绑定多个第三方账号或者客户公司本人的账号体系（比方微信、手机号、苹果账号、UC、passport 等），超级管理员能够给每个账号调配不同的角色从而具备不同的性能权限，比方给客服人员调配客服一线角色具备 IM 沟通权限。

△企业组织与账号模型

2.2 稳固高效可配置的对立登录服务

ToB 垂类的业务场景岂但须要反对 Saas 类业务，也要反对大客户私有化部署的业务，在设计的指标上，平台的账户登录服务须要给各类业务提供一个平安、稳固、高效、可配置的对立登录服务。

△登录服务架构图

作为企业应用的登录服务，为了保障企业用户的安全性，在流程上的设计上减少了很多平安的策略，所以总体的登录流程会较简单：

首先以账号密码登录为例，当用户进入爱番番的页面的时候，零碎页面进行初始化，此时给以后的页面生成一套独有的加密信息和时长。这里加密信息会用于后续用户填写账号、明码等信息的传输过程当中的加密；时长是以后页面的时长，如果用户在以后页面静止的工夫超过零碎规定的工夫，那么页面信息将会生效，零碎会从新加载页面。当用户填写账号、明码、验证码等信息的时候，传输给零碎一串加密信息，零碎会在页面最开始加密生成的加密信息当中找到密钥，并进行解密，等实现根本的账号密码信息的校验后，会通过一系列的安全策略，比方十分用地登录、罕用设施查看、手机验证查看等等。安全策略通过后会生成长期验证信息返回给前端，前端在进行校验的时候，零碎会将长期的登录信息替换成实在的登录信息，从而零碎实现了一次登录行为。

△账号密码具体流程图

那么作为 saas 服务的对立业务根底，咱们须要在登录服务上解决几个问题：

• 如何反对登录服务可配置化？可配置化能力能够反对不同的企业在私有化部署的场景能够依照企业本身的业务来定制登录流程，也能够反对爱番番 saas 服务接入不同的产品线的定制化需要。
• 如何反对多产品线利用接入并反对单点登录？
• 如何保障账号登录平安？登录服务的外围就是保障登录性能的安全性，作为爱番番、爱洽购等零碎的一级服务，避免零碎被歹意入侵，登录流程的安全性就变得十分的重要。

2.2.1 配置扩大能力

一个简单的问题通常是有多个小问题组合起来，而解决一个简单问题也会波及到多个不同的解决步骤，只须要采纳分而治之的形式，将简单的解决逻辑拆分出不同的小的步骤，这样能够将问题简单化。所以外围的解决思路也是将登录流程不同的解决步骤拆分进去，将步骤对应行为和操作。这样就能够失去多个不同的原子行为，而每一种行为对应不同的原子操作。

2.2.1.1 模型形象

基于该思维能够形象出一套模型，如下图，爱番番账号体系是能够反对多产品线的接入的，一个产品线归属多个账号。P 代表产品线，U 示意账号，E 代表登录服务的一些原子事件，C 代表登录相干的配置，S 代表登录相干的安全策略。一个产品线下能够组装不同的登录流程须要的原子事件，所以 P 和 E 的关系是一对多的状况。产品线 P 也能够有不同的配置，比方登录态时长、是否反对多端同时登录、登录端的个数等等配置。无论是产品线或者账号都会有一系列的安全策略的配置，当然这些安全策略能够是账号粒度也能够产品线粒度，比方对于一些黑产账号、异样登录行为账号的封禁策略，判断账号是否在罕用地登录的提醒策略等等。

△配置扩大能力图 1

通过将登录过程的步骤进行拆分，由不同产品线进行组织步骤能够实现企业的一些自定义的需要，然而如何反对不同的登录形式进行可配置操作？登录服务须要反对不同的登录形式，如密保手机登录、扫码登录、第三方登录等等支流通用的登录形式，在设计可配置流程的时候须要确保设计的通用性，将不同的登录形式的登录流程也能套用一套模型当中。形象模型 M，示意登录形式，M 也是由不同的事件组成，而产品线 P 是能够自定义本人的产品须要哪些登录形式的，通过前端登录组件进行展现。当然为了思考到安全性等方面的可配置，也设置了黑名单、白名单。黑名单能够基于账号级别的一些封禁，也能够基于异样 ip、手机号等进行封禁，而白名单往往和安全策略相干，比方一些跨域申请、跳转申请等等。下图就是基于上述一些思考丰盛后的登录服务配置扩大能力形象模型。

△配置扩大能力图 2

2.2.1.2 对立登录流程

基于设计的配置扩大的能力，能够将最开始的账号密码登录流程形象成如下的登录可配置流程图，首先采纳通用的加解密服务对申请的参数进行加密解决，而后各类的原子事件和对应的原子事件处理器都注册到中央处理器当中，通过中央处理器来进行组装流程，中央处理器会通过产品线和登录形式来查询数据库配置的事件编号程序，而后逐渐触发执行触发。

△对立登录流程图

2.2.2 单点登录

2.2.2.1 流程介绍

单点登录，个别利用于多个利用零碎中，用户只须要登录一次就能够拜访相互信赖的利用零碎。比方拜访 http://a.baidu.com , 当登录之后，再次拜访 http://b.baidu.com、http://a.aifanfan.com 都是能够免登录进行零碎当中，用户只需一次登录，各个系统即可感知该用户曾经登录。

△单点登录比照图

基于上述对于单点登录的阐明，能够想到只须要不同端认可一份登录认证凭据就能够实现，因为 http 是无状态的，天然能够想到 cookie 用于传递不同端的用户信息，然而因为 cookie 和域是强相关性，且基于浏览器有失落的问题，所有在不同的端互通登录态应用 cookie 存在两个问题：一是跨域问题；二是 cookie 失落问题。平台基于 CAS 协定设计实现一整套基于多端的单点登录流程，岂但能够基于浏览器解决 cookie 问题，并且反对 native 各利用之间登录互通。

如下图是平台账号单点登录的次要流程图，在零碎 A 应用 ToB 账号登录的时候，登录胜利后，认证核心会生成一个长期认证信息 Stoken，并且会写入认证核心的域名 www.b.com 下 cookie 当中 Ptoken，当零碎胜利跳转零碎当中，业务 A 服务端网关集成登录校验 SDK，由登录校验 SDK 将长期认证信息 Stoken 换取零碎 A 的实在稳固的登录态，生成只属于零碎 A 的登录校验 Atoken；当零碎 A 跳转到零碎 B 的时候，零碎 B 服务端登录态校验发现以后域名下并没有登录信息，会执行 302 跳转到认证核心，由认证核心查找域名 www.b.com 下 cookie 当中 Ptoken，通过认证后，会给零碎 B 的申请接口返回长期 Stoken，由登录校验 SDK 将长期认证信息 Stoken 换取零碎 B 的实在稳固的登录态 Btoken。所以不同零碎去认证信息的时候只须要关怀零碎自身域名寄存的信息即可，如果登录校验失败或者 cookie 失落的场景，会跳转到认证核心再次进行校验。

△单点登录流程

2.2.2.2 认证逻辑

在流程介绍当中能够理解到单点登录当中设计了三种票据 Stoken、Ptoken、Rtoken：

• Stoken : 服务长期 token，由认证核心去颁布；
• Ptoken : 寄存在认证核心服务端，会申请通过 Cookie 或者 Header 的 Key 值找到绝对于的 Ptoken，从而拿到用户信息；
• Rtoken : 业务方专属的 token，用于以后零碎的登录态校验。

生成 Stoken

长期 Stoken 生成的机会有两种，一种是不同零碎相互跳转的时候生成，一种就是登录的时候生成。不论哪种场景都是由认证核心去颁布，长期 Stoken 对应服务端存储的数据结构须要蕴含以后登录的账户信息、校验信息、客户端信息、加密信息。在设计上是一种 Hash 的构造形式，长期 Stoken 存储各类的信息放弃 key-value 的形式，这样读取、存储都清晰不便。当业务零碎设置登录实现跳转后的地址是 http://a.baidu.con/index，那么生成长期 Stoken 后，登录服务 SDK 会将 Stoken 追加到跳转地址上，变成  http://a.baidu.con/index?st=x… , 因为长期 Stoken 裸露在 url 上，为了保障安全性，长期 Stoken 的有效期设置 30s 以内，如果 30s 当中，长期 token 没有被业务申请进行认证，则间接进行销毁。

Stoken 换取 Rtoken

当业务 A 登录后，业务申请通过登录 SDK 校验的时候，会拿到申请参数上的 Stoken，通过解密到实在存储的 Key，拿到以后登录的账户信息、校验信息、客户端信息、加密信息，生成稳固 Rtoken，将 Stoken 的信息复制到 Rtoken，并通过产品线的配置设置登录态工夫。这一步就是长期 Stoken 换取实在登录态 Rtoken。

校验登录态过程

△登录态校验示意图

2.2.3 登录安全性保障

2.2.3.1 分阶段 session 管制

通过之前的登录流程可配置、单点登录流程的介绍，在理论处理过程当中，将服务器的 session 划分成三个局部，别离是登录期间的 session、长期 session、登录态 session。登录期间的 session 管制总体登录流程的工夫，避免歹意狂刷，这种的 session 时长要设置分钟级别，如果 session 过期，须要前端登录 SDK 从新加载初始化页面信息，从新开始登录流程；长期 session 就是为了单点登录设计，这种 session 时长设置秒级别；实在登录态 session 为用户最终的登录 session，存在实在的登录 Token 信息，通过一直的交互 session 来保障登录流程的安全性。如下是账号密码登录划分图。

△分阶段 session 划分

2.2.3.2 敏感信息加解密

加解密过程在登录流程比拟重要，也是为了安全性，将具体的加密算法进行替换。这外面应用对称加密算法 A、非对称算法 B，账号密码加密算法 C、D 等。

△加解密流程图

加解密过程如下：

1. 首先通过加密算法 A 生成一对秘钥对，将公钥给端上应用，端上随机数 Random 联合公钥算法 A 加密以后随机数 Random 传给登录服务。
2. 首先 Random 将解密进去，而后生成新的密钥对，而后将私钥，公钥寄存 session 外面，并返回算法 B 加密后的公钥，这个公钥的 salt 是解进去的原始的 Random 参数。
3. 端上算法 B 解密后出实在的公钥后。将明码算法 A 加密。
4. 明码校验的时候，会在 session 外面取之前存的私钥，解出原始明码，再通过算法 C、D 加密后和数据库比对。

2.2.3.3 其余平安动作

• cookie 属性

Secure：安全性，指定 Cookie 是否只能通过 https 协定拜访，个别的 Cookie 应用 HTTP 协定即可拜访，如果设置了 Secure（没有值），则只有当应用 https 协定连贯时 cookie 才能够被页面拜访。

HttpOnly：如果在 Cookie 中设置了 ” HttpOnly ” 属性，那么通过程序 (JS 脚本、Apple t 等) 将无奈读取到 Cookie 信息，避免 xss 攻打。

时长：设置有效期，倡议设置时长不宜过大。

• 申请校验

域申请限度：登录相干的接口反对跨域的场景，然而须要校验申请头 origin 属性，设置白名单，只有在登录认证核心配置的起源 origin 才能够放行；对一些执行 302 跳转的申请，同样设置白名单的管制跳转申请。

频次：登录相干的申请会依据以后的 IP、浏览器惟一 ID、客户端设施 ID 等信息设置工夫范畴内频率的限度，如果超过阈值，会进行频次报警，也会对指定的 IP、设施、账号进行及时的封禁。

• 验证码

验证码是十分有必要的，而验证码的目标就是辨别正常人和机器的操作。验证码的作用在于辨别人和机器，避免被暴力破解，进步破解明码的难度。只是不同阶段表现形式不同，将来的趋势是更加智能无感知，用户体验更好。登录服务反对图片验证码、人机交互滑动验证码、手机验证码。业务方能够依据平安要求不同接入不同的验证码的形式。

2.3 OAuth 能力

2.3.1 OAuth 介绍

ToB 多租户账号服务反对客户相干需要，有时候会和内部企业进行单干，须要保障客户体验的一致性，买通内部平台和账号零碎的账号受权关系，保障登录爱番番零碎的客户能够免登录到内部零碎。因而须要造成一套欠缺的受权体系。OAuth 2.0 是目前最风行的受权机制，用来受权第三方利用, 获取用户数据。数据的所有者通知零碎，批准受权第三方利用进入零碎，获取这些数据。零碎从而产生一个短期的进入令牌（token），用来代替明码，供第三方利用应用。

2.3.2 受权流程

在用户受权登录已接入 OAuth2.0 的第三方利用后，第三方能够获取到用户的接口调用凭证（access\_token），通过 access\_token 能够进行对外提供的 OpenApi 接口进行调用，从而可实现获取爱番番账号用户根本凋谢信息和帮忙用户实现根底凋谢性能等。目前平台 Oauth 能力反对 authorization\_code 模式，该模式整体流程为：

1. 第三方发动受权登录申请，当查问相干利用注册到受权核心的时候，如果用户没有在账号零碎进行登录，会默认链接到提供的对立受权登录页，登录实现后会拉起利用或重定向到第三方网站，并且带上受权长期票据 code 参数；
2. 通过 code 参数加上 AppID 和 AppSecret 等，通过 API 换取 access\_token；
3. 通过 access\_token 进行接口调用，获取用户根本数据资源或帮忙用户实现基本操作。

△OAuth 时序图

三、权限服务

作为 ToB SAAS 产品的根底权限服务，服务于多个产品线，须要为来自各行各业的客户解决复杂多变的权限管控需要，提供蕴含性能权限和数据权限管控的能力。

3.1 问题与思路

问题 1 ：各产品线在代码中实现简单权限管制逻辑，业务权限了解老本高、保护老本高；

解决思路 ：提供易于接入的可扩大的性能鉴权、数据鉴权能力；

问题 2 ：权限逻辑简单、性能要求高，随着业务倒退和客户量的减少，零碎不稳固危险高；

解决思路 ：建设高性能高牢靠的鉴权服务；

3.2 简单的性能鉴权

3.2.1 权限接入形式

如下图所示，权限服务蕴含登录态校验、权限校验能力，并提供三种鉴权接入形式，别离为：

①、通过网关对立集成鉴权 sdk 实现鉴权，蕴含登录态的校验、权限校验；

②、不通过网关，独自引入鉴权 sdk 实现鉴权；

③、间接通过 RPC 接口与权限平台交互，实现鉴权；

_△___性能鉴权交互图

性能鉴权蕴含两局部，别离为升级版 RBAC 模型即 TD-RBAC、权利包模型，上面别离进行介绍。

3.2.2 GD-RBAC 模型（引入用户组的基于维度和角色的权限访问控制模型）

3.2.2.1 RBAC

在介绍 GD-RBAC 之前，先介绍下根底的 RBAC 模型，Role Based Access Control，基于角色的权限管制模型的外围是在用户和权限之间引入了角色的概念。防止用户和权限的间接关联，通过用户关联角色、角色关联权限的办法来间接地赋予用户权限，从而达到用户和权限解耦的目标。

RBAC 模型模型是 20 世纪 90 年代钻研进去的一种新模型，RBAC 认为权限受权的过程能够抽象地概括为：Who 是否能够对 What 进行 How 的拜访操作，并对这个逻辑表达式进行判断是否为 True 的求解过程，也即是将权限问题转换为 What、How 的问题，Who、What、How 形成了拜访权限三元组。即在 RBAC 模型外面，有 3 个根底组成部分，别离是：用户、角色和权限。RBAC 通过定义角色的权限，并对用户授予某个角色从而来管制用户的权限，实现了用户和权限的逻辑拆散，极大中央便了权限的治理。

• 用户（User）：每个用户都有惟一的 UID 辨认，并被授予不同的角色；
• 角色（Role）：是一种虚构身份，关联一组权限，必须关联到某个用户身份能力应用；
• 资源（Resource）：资源是用户与零碎交互的对象实体的一种形象；
• 性能（Function）：某个业务性能，通常是多个接口地址组成，比方关上某个菜单页面、按钮是否可见等操作；
• 权限（Auth）：角色和性能之间的关联映射；

_△___RBAC 模型

RBAC 反对三个驰名的平安准则：最小权限准则、责任拆散准则和数据抽象准则

• 最小权限准则：RBAC 能够将角色配置成其实现工作所需的最小权限汇合；
• 责任拆散准则：能够通过调用互相独立互斥的角色来共同完成敏感的工作；
• 数据抽象准则：能够通过权限的形象来体现；

3.2.2.2 GD-RBAC

下面介绍了根底的 RBAC 模型，但随着业务倒退，无奈满足不同产品线的简单鉴权需要，比方爱番番转化晋升域须要实现同一个账号在不同线索池下领有不同的操作权限，基于此咱们提供 GD-RBAC 模型：

GD-RBAC 模型是在 RBAC 根底上进行晋升，具体降级点为：

1、减少用户组，多个用户（能够为 1 个）能够聚合为一个用户组，同一用户组内的用户角色雷同，进而具备雷同的权限，能够简化用户配置流程；

2、在用户组与角色之间减少维度，同一个用户组能够关联 ≥ 1 个维度，在每个维度下能够独自关联惟一的角色，进而实现同一用户在不同业务场景下的不同权限；

_△___GD-RBAC 模型

GD-RBAC 示例

有了 GD-RBAC 模型，咱们就能够很简略的实现用户在不同线索池下的权限配置，如下图所示：

同一个账号能够关联到不同的维度即线索池，而后每个线索池能够关联不同的角色，从而能够帮忙业务实现简单的业务定制鉴权。

_△___GD-RBAC 模型在线索池业务的利用

3.2.3 权利包模型

有了 GD-RBAC 是不是就能实现所有性能权限管控了呢？依然存在以下问题：

①、版本差别：爱番番存在多个售卖版本，比方线索管家根底版、拓客标准版、拓客专业版、公有部署版，版本之间的权限范畴是不统一的，那么 GD-RBAC 下的不同租户的同一个超级管理员角色对应的权限必然是不雷同的，举例来说根底版的管理员角色是不具备标准版管理员的潜客定投权限的；

②、性能增购：同一个用户同一个版本，用户能够独自购买产品实现性能增购，此时即便没有降级版本但权限也失去了裁减；

为了解决上述问题，咱们设计了权利包模型来定义权限汇合，如下所示：

_△___权利包模型

权利包是可定制的业务属性，租户能够关联多个权利包，比方爱番番产品线存在租户版本权利包、400 电话性能权利包、用户坐席 license 权利包等分类。通过租户关联权利包来实现租户权限的最大汇合。通过权利包模型能够很灵便、简略的解决上述提到的三个问题：

①、租户版本权利包解决版本差别：比方租户版本权利包能够别离定义不同版本的最大性能汇合，用户购买不同版本即具备了权利包的所有权限；

②、性能权利包解决性能增购问题：将不同产品性能打包成独自的性能权利，用户通过购买性能实现权限的降级。

3.2.4 性能鉴权：GD-RBAC 模型 + 权利包模型

以上咱们介绍了 GD-RBAC 实现通过角色来关联不同的权限，通过权利包来关联最大权限汇合，那么用户的最终权限等于两者权限交加，即如下所示：

_△___残缺的性能鉴权

3.2.5 疾速利用：客服代操作

基于 GD-RBAC 和权利包模型，平台能够疾速反对业务各种权限应用场景，这里举例客服代操作场景：

先说下代操作的概念：一组用户能够拜访、操作另一组用户领有的资源。典型例子：具备管辖权限的客服应用客服账号进入客户的爱番番零碎，帮忙客户实现系统配置。

客服 A 如果须要应用客服本人的账号进入张三的零碎，通过设置组织构造树具备管辖权限并退出张三所在用户组，而后就能够实现客服的登录态且具备客户张三的操作权限。

_△___通过模型疾速反对客服代操作业务

3.3 灵便扩大的数据鉴权

除了以上咱们介绍了性能鉴权之外，不同产品线有比拟灵便的数据鉴权需要，比方不同部门、职位的账号如何实现数据权限的隔离或管辖？如何构建可定制的数据鉴权能力？咱们定义了用户特色，分为通用特色和自定义特色：

通用的维度特色诸如维度、产品线、行业等每个 ToB 产品都具备的，咱们通过维度来实现通用特色，比方每个部门、岗位都是不同的维度。业务方能够通过维度模型标准用户数据，反对特色级联，构建用户的特色网络，从而反对不同业务自定义不同的用户特色模型；

自定义特色是通过 k - v 模式存储的要害值对，用于灵便定义业务数据，比方客户起源、地址等非通用数据。

_△___数据权限形象

_△___数据维度模型

咱们把维度通过左右值树结构进行存储，使得维度具备肯定档次关系，如果把数据绑定在维度节点上，资源间也有了层级关系，很适宜解决一些具备层级关系的权限问题。比方业务方管理员能够定义组织构造、职位两个不同的维度，来别离建设组织构造树、职位树，如下图所示：

_△___左右值树在组织构造与职位的利用示例

那么为什么要采纳左右值树存储维度呢？先介绍下左右值树基本原理：

应用左右序号对每一个节点进行标记，根节点的左值是树的最小序号，根节点的右值是树的最大序号，且高度是 0。

1. 查问某节点的所有后辈节点：任意节点，其后辈的左值肯定比以后节点左值大，后辈的右值肯定比以后节点右值小
2. 查问某个节点的先人：任意节点，其先人的左值肯定比以后节点左值小，其先人的右值肯定比以后节点右值大
3. 计算节点下有多少子节点：蕴含本身：（右值 – 左值 + 1）/ 2；不含本身：（右值 – 左值 – 1）/  2
4. 节点排序：依据叶子结点排序。

下图是将维度 1 - 组织构造通过左右值树进行标记的图，其中 lv 示意树的层高，lleft 示意右边序号，lright 示意左边序号，通过左右值树进行存储标记，查找用户挂在哪个维度节点上，查问效率高。

_△___左右值树节点排序

最终咱们能够通过两个维度节点的交加查问失去账号张三所在部门、职位的管辖后果集：

_△___维度管辖交加计算

所以通过左右值树的特点，对于查多写少的数据场景来说，能够疾速的获取节点的所有子节点，进而高效的获取管辖关系判断数据权限。

3.4 高性能高可用的鉴权服务

如下图所示，平台将账号和权限数据缓存到 BDRP，优先通过缓存进行权限的判断。同时平台部署在苏州、北京、广州多个地区异地容灾，网关服务通过负载平衡策略和健康检查剔除不可用实例；网关和平台通过多级兜底缓存、降级 DB 以及流控熔断能够确保间断 2 年放弃 99.999% 的服务稳定性。

_△___多级缓存与熔断

四、总结

本文次要介绍了百度 ToB 垂类账号权限平台的账号登录服务以及权限服务的设计：

• 通过配置化的事件编排灵便反对各产品线丰盛的登录形式和登录策略，具体开展介绍了单点登录的设计与实际，并通过分阶段 session 管制与多种手段保障登录服务的安全可靠；
• 联合一个示例残缺的介绍了通过 GD—RBAC 和权利包模型解决简单业务的性能鉴权，并通过多维度鉴权灵便实现数据权限治理，助力业务和客户简略便捷的实现权限管控。

将来，平台将继续丰盛账号和权限的能力，继续晋升服务稳定性，秉持“技术为产品服务”的理念提供一站式账号与权限解决方案帮忙 ToB 垂类各业务线更好的施展业务产品价值。

五、作者介绍

本篇系百度 MEG ToB 垂类爱番番鲁班团队多位同学独特编写：

• Corwin：资深研发工程师，先后负责多个业务方向，善于平台和业务零碎架构设计，用技术解决业务痛点；
• Tao：高级研发工程师，负责业务根底、经营撑持等相干业务，善于分布式与零碎设计。

举荐浏览 ：

视觉 Transformer 中的输出可视化办法

深刻了解 WKWebView (渲染篇) —— DOM 树的构建

深刻了解 WKWebView（入门篇）—— WebKit 源码调试与剖析

GDP Streaming RPC 设计

百度 APP 视频播放中的解码优