一段时间以来，我一直在使用 Android 的 GoogleApiClient 来访问地理围栏等其他 API。我很欣赏通过 GoogleApiClient 和 Google Play 服务，Google 一直在尝试解决 Google fragment 化问题，方法是允许较旧的 Android 设备将连续更新下载到其中包含的 API，而无需全新的操作系统更新。
在 Java 级别我一直不清楚的是为什么 GoogleApiClient 需要并支持连接/暂停/失败的回调？没有进一步的细节，看起来本质上是其他 API 的包装器的 GoogleApiClient 似乎是过度烘焙和过度设计的。连接/暂停/等不能对开发人员透明吗？最坏的情况是无法访问服务，难道它不能抛出异常吗？
因此，与其批评，我确实认为我的知识存在漏洞，这意味着我无法欣赏设计。为什么 Google 会这样设计 API 客户端？他们是否遵循某种设计模式？
最佳答案
它的结构方式有很多原因，但最重要的是:
- GoogleApiClient 代码旨在让您可以从 Android UI 主线程调用它(无需显式创建 AsyncTask 或后台线程)
- GoogleApiClient 代码可能需要很长时间才能运行(例如，如果用户尚未安装 Play 服务，它会提示用户下载/安装 Play 服务，并且只有在安装 Play 服务后才将控制权返回给应用程序)
- 如果主线程被长时间运行的操作(例如从 Play 商店下载应用程序)阻塞，Android 用户界面将变得无响应。因此，注册回调对于 Android 领域的此类代码来说是非常标准的。 [长时间阻塞Android UI主线程是系统强制退出应用的常见原因]
现在，最重要的是，增加 Play 服务复杂性的众多因素之一是对灵 active 的需求，需要支持许多不同的功能/库，而不需要编译每个使用 Play 服务的应用程序/包括它支持的每个库(并且，与此相关的是，通过在每个利用 Play 服务的应用程序中复制 Play 服务的所有功能来避免膨胀每个应用程序)。因此，Play Services 使用客户端-服务器架构；使用 Play 服务的应用不会导入所有 Play 服务(包括提供该系统底层功能的代码)。相反，每个使用 Play Services 的应用程序都会导入一组更小、更集中的接口(interface)，这些接口(interface)能够与 Play Services 应用程序中这些服务的实现进行通信(并且只有 Play Services 应用程序本身需要包含所有的实际实现这些接口(interface)的逻辑)。但是，由于这种架构，您需要在运行时执行相当于“导入”的操作……也就是说，您可能需要在使用其功能之前下载并初始化 Play Services 应用程序。
关于android - 什么是 GoogleApiClient 设计模式？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38889447/