API 3/6 #3644
API 3/6 #3644
Conversation
| <title>详情</title> | ||
| <p id="getUserInfo_desc">远端用户加入频道后，SDK 会获取到该远端用户的 UID 和 User Account，然后缓存一个包含了远端用户 UID 和 User Account 的 Mapping 表，并在本地触发 <xref keyref="onUserInfoUpdated" /> 回调。收到这个回调后，你可以调用该方法，通过传入 UID 获取包含了指定用户 User Account 的 <xref keyref="UserInfo" /> 对象。</p> | ||
| <section id="detailed_desc" deliveryTarget="details" otherprops="no-title"> | ||
| <p id="getUserInfo_desc">远端用户加入频道后，SDK 会获取到该远端用户的 UID 和 User Account，然后缓存一个包含了远端用户 UID 和 User Account 的 Mapping 表，并在本地触发 <xref keyref="onUserInfoUpdated"/> 回调。</p> |
There was a problem hiding this comment.
原文的 “Mapping 表” 显得有点不土不洋，可改成映射表。
There was a problem hiding this comment.
可以找研发补充一点信息，获取了 userinfo 后可以干点啥
There was a problem hiding this comment.
userinfo 里面包含了 uid 和 useraccount 呀..现在的情况是用户可能只拿到了其中一个
| </section> | ||
| <section id="related" deliveryTarget="details"> | ||
| <title>相关回调</title> | ||
| <p><xref keyref="onUserInfoUpdated"/></p> |
There was a problem hiding this comment.
这个方法跟这个回调是无限套娃的关系么？好奇怪啊……有一个猜测：
原文中 userInfo 参数在 C++ 是个输入/输出参数；输出时包含 User Account 和 UID 的 UserInfo ，所以这个方法在 C++ 就不会有回调了；
userInfo 在其他平台是个普通的输入参数，根据 onUserInfoUpdated 回调获取完整的 UserInfo 对象（这里也很迷，那用户还传 userInfo 干啥）
There was a problem hiding this comment.
这个方法在 C++ 有回调，这里 userinfo 对象作为输入参数，你不需要把用户 id 和 user account 都传入，比如这个对象我只需要传用户 ID，获取到了 user account之后，又会作为 UserInfo 对象返回，其中既包含用户ID，又包含 user account，这个在 c++ 里面还挺常见的
There was a problem hiding this comment.
onUserInfoUpdated 回调是在远端用户加入频道后，sdk 获取了他的 uid 和 useraccount 后触发的
| </section> | ||
| <section id="timing" deliveryTarget="details"> | ||
| <title>调用时机</title> | ||
| <p props="cpp unreal flutter rn electron">请确保在调用其他 API 前先调用 <xref keyref="createAgoraRtcEngine"/> 和 <apiname keyref="initialize"/> 创建并初始化 <apiname keyref="IRtcEngine"/>。</p> |
There was a problem hiding this comment.
这里不用提 initialize，专注于这个方法本身就行：
在所有 API 中，该方法需要第一个被调用。
There was a problem hiding this comment.
这里不用提 initialize，专注于这个方法本身就行 -> 这个方法就是 initialize，为啥不能提？create 方法是创建引擎，initialize 是初始化，要先创建才能初始化，我觉得原文没啥问题。“在所有 API 中，该方法需要第一个被调用。”这个反而会引起误解，让人以为只要先调用 initialize 就可以
| <title>详情</title> | ||
| <p>SDK 初始化后默认的频道场景为直播场景。你可以调用该方法设置频道的使用场景。SDK 会针对不同的使用场景采用不同的优化策略，如通信场景偏好流畅，直播场景偏好画质。</p> | ||
| <section id="detailed_desc" deliveryTarget="details" otherprops="no-title"> | ||
| <p>你可以调用该方法设置频道的使用场景。SDK 会针对不同的使用场景采用不同的优化策略，如直播场景优先保证画质。SDK 初始化后默认的频道场景为直播场景。</p> |
There was a problem hiding this comment.
应该先写 SDK 的默认行为是什么，然后再说这个方法起到什么作用。
因为对于一些有默认行为的 API ，我们并不希望用户去主动调用，而是要看具体的场景。比如这个，默认就是直播场景。
”如直播场景优先保证画质“这个例子其实只说了一半，要么就把直播和通信两个场景下的具体区别写出来。
There was a problem hiding this comment.
4.x 里面不是不区分通信和直播场景了么？如果我们在文档里面突出这两个概念的区别，别人看了文档还是会想要去设置，所以我才把通信的例子删掉了，想要弱化这个概念。
There was a problem hiding this comment.
我写这个逻辑正好跟你是反的，我觉得应该先写这个api本身是做什么事情的，然后再说SDK的默认行为哈哈。一上来直接介绍默认行为有点怪
There was a problem hiding this comment.
4.x 里面不是不区分通信和直播场景了么？如果我们在文档里面突出这两个概念的区别，别人看了文档还是会想要去设置，所以我才把通信的例子删掉了，想要弱化这个概念。
比较纠结的一点是，我们内部是知道不区分，但是在用户界面（API）上，通信场景仍然存在，所以要写就要清楚体现出区别，只写一半就可能会引起疑问
| <section id="parameters"> | ||
| <ul> | ||
| <li>为保证实时音视频质量，相同频道内的用户必须使用同一种频道场景。</li> | ||
| <li props="android ios cpp unreal bp rn">不同的频道场景下，SDK 的默认音频路由和默认视频编码码率是不同的，详见 <xref keyref="setDefaultAudioRouteToSpeakerphone" /> 和 <xref keyref="setVideoEncoderConfiguration" /> 中的说明。</li> |
There was a problem hiding this comment.
默认的编码码率现在是个黑盒了，用户也无法得知，而且不确定文档中是否要体现不同 profile 下的码率区别，具体还是要看用户是否可感知，可以再确认下。
There was a problem hiding this comment.
编码码率感觉可以删掉了，因为视频编码属性里面也把通信模式的码率删掉了
No description provided.