#11WeeksOfAndroid 期间，全新的 Play 应用内评价 API 正式登场。通过 Play Core 开发库，Play 团队推出了这项众人期盼已久的功能。
#11WeeksOfAndroid
https://developer.android.google.cn/11weeksofandroid
Play 应用内评价 API 正式登场
https://developer.android.google.cn/guide/playcore/in-app-review
尽管我们收到的大多为正面反馈，但一些开发者也表达了他们的担忧，称需要调整自己的 UI 流程适应新 API 的要求。为打消这些疑虑，我们将向各位解释说明团队做出的一些决策，并提供进一步指导，帮助大家充分利用该 API。
"为什么该 API 不提供任何信息？"
鉴于 API 的重要性与潜在滥用风险，或会暴露用户的评论，甚至获悉评分面板是否显示，团队设计了这款 API 将用户隐私和体验放在首位。
虽然看上去这增加了开发者的工作难度，但我认为实际情况并非如此。该 API 操作简单 (只需调用两个方法！)，在设计上符合开发者的利益，同时平衡了用户隐私问题，并避免诱发不必要行为。要点在于明确 "何时使用该 API"。
"突然显示的评分面板"
该 API 并非 "随机" 显示评分面板，而是由开发者确定启动评分流程的最佳位置和时机。
诚然，该 API 的设计 (如上所述) 目的在于保护用户。为此，该 API 不会提供有关评论显示与否的信息，并且不会频繁启动/弹出评分流程 (详情请参阅 "配额")。
配额
https://developer.android.google.cn/guide/playcore/in-app-review#quotas
这样能够有效避免可能出现的滥用问题，例如，应用强迫用户对其打分，或者误导用户，仅在界面中显示 "5 星" 评论 (详情请参阅 "何时请求应用内评论")。
何时请求应用内评论
https://developer.android.google.cn/guide/playcore/in-app-review#when-to-request
"能否将该 API 用于 '打分' 按钮"
如上所述，该 API 不应由 call-to-action (即 "打分" 按钮) 触发，而应作为用户流程的一部分触发。
若不满足显示评分对话框的条件 (如下面链接中列举的状况)，用户在点击按钮后可能不会触发任何操作。
无法显示出评分对话框的常见情况
https://developer.android.google.cn/guide/playcore/in-app-review/test#troubleshooting
"我的应用没有任何 '成功' 页面，因此我没有触发评分的时机"
实际上还有其他很多适合启动评分流程的情景。例如，如果用户已经使用应用一定次数或时间，您可以在他下一次打开应用时启动评分流程，只要确保不过度触发用户评价，且在用户评价完成后继续执行原有流程即可。
"此行为将导致用户给我的应用打差评"
一些早期使用者表示，有些用户可能永远不会给应用评分，而如果将该 API 放置在正确的位置，就能够帮助他们，使其在收到请求时愿意撰写评论。
当然，如果滥用该 API，那效果必然适得其反。
"我可以使用一些变通的方法来确定评分面板显示与否"
恭喜！尽管一些变通的方法看似可行，但我们并不推荐大家去做这样的尝试，如果一款正式发布的应用是基于系统内部实现细节而实现的，那它本身也存在一定风险。此外，这种做法也违反了设计初衷，反而可能产生负面影响。
"该 API 不可靠且无法正常工作"
如 "测试应用内评价" 部分所述，该 API 有严苛的使用要求。最常见的错误包括:
未使用已发布到 Google Play 的应用；
使用从未通过 Google Play 安装这款应用的帐号或已评价过应用的帐号；
当设备中有多个账户时，未选择主账户 (以及安装了应用的账户)。
测试应用内评价
https://developer.android.google.cn/guide/playcore/in-app-review/test
如需获取详情，请参阅问题排查部分。
问题排查
https://developer.android.google.cn/guide/playcore/in-app-review/test#troubleshooting
"我需要了解具体的配额！我该怎样知道多久请求一次用户评价？"
根据我们的设计，该 API 并不会提供完成度/结果反馈，因此配额机制旨在帮助开发者避免滥用 API 和过度触发评论请求。确切的配额属于实现细节问题，并且未来可能会发生变化。
应用不应试图确定配额的具体情况，而应尝试添加自己的逻辑 (何时/何处是请求评论的最佳时间)，并在合适的条件通过该 API 启动评论。
所以，该 API 的最佳使用方式是什么？
没有唯一或 "最佳" 的使用方式，而且每款应用的用例和用户群也各不相同。不过，以下建议可能会对您有所帮助:
确保用户在启动评分流程之前已经体验过该应用。
在界面过渡后启动评分流程。例如，执行完某些操作并引导用户返回 "主" 界面后。
避免在用户点击任何功能运行 (call-to-action) 按钮之后调用该 API，防止此处显示用户不希望看到的对话框/面板。
启动评论时，请通过提前预加载评分流程 (requestReviewFlow) 来防止阻塞用户，如果请求未按时加载，则跳过启动流程 (参阅 ReviewViewModel 示例)。
不要过度触发评价 (避免每次启动应用都触发)。即使已预先加载，启动用户评价也可能导致 UI 轻微延迟。
requestReviewFlow
https://developer.android.google.cn/reference/com/google/android/play/core/review/ReviewManager.html#requestReviewFlow()
ReviewViewModel
https://github.com/android/app-bundle-samples/blob/master/PlayCoreKtx/app/src/main/java/com/google/android/samples/dynamicfeatures/state/ReviewViewModel.kt
PlayCoreKtx 示例应用为一个手电筒应用，您可选择其背景颜色。该应用以简化方式说明了上文给出的一些建议。
ReviewViewModel 负责 "预热" 评分流程，确保 ReviewInfo 对象准备就绪，并在满足评论条件的情况下提供。
PaletteFragment 请求 ReviewViewModel 在评分流程启动后立即对其进行 "预热"。
当用户从 PaletteFragment 中选择背景、返回主界面并关闭手电筒后，MainFragment 会请求 ReviewViewModel 获取 ReviewInfo。
PlayCoreKtx
https://github.com/android/app-bundle-samples/tree/master/PlayCoreKtx
ReviewViewModel
https://github.com/android/app-bundle-samples/blob/master/PlayCoreKtx/app/src/main/java/com/google/android/samples/dynamicfeatures/state/ReviewViewModel.kt
PaletteFragment
https://github.com/android/app-bundle-samples/blob/c32d75fc267440b8da8387429c6315528254c379/PlayCoreKtx/features/picture/src/main/java/com/google/android/samples/dynamicfeatures/ondemand/PaletteFragment.kt#L114
获取 ReviewInfo
https://github.com/android/app-bundle-samples/blob/c32d75fc267440b8da8387429c6315528254c379/PlayCoreKtx/app/src/main/java/com/google/android/samples/dynamicfeatures/ui/MainFragment.kt#L126
注: 为了简化示例，应用没有保存最近一次触发评分流程的时间，并且使用了简单逻辑而可能多次触发评分逻辑。正式的应用应使用更为复杂的逻辑。
希望这篇文章能帮助您理清一些概念，并让您顺利实现新的应用内评价 API。如有任何疑问，欢迎您在留言区提问交流。
推荐阅读
点击屏末 | 阅读原文 | 进一步了解 Play 应用内评价 API