开发一流的 Android SDK：Fabric SDK 的创建经验

第一个例子让你马上开始，其次是一个拥有更多定制的版本，在这里你可以选择需要的特定组件，然后它们才生效。

让我们的 SDK 尽可能小，我们着眼于模块化来设计我们的架构。就像我们讨论过的，在 Android 上二进制文件的大小和方法计数是非常重要的，所以这使我们能够尽可能高效。因为如果我们利用 AAR（标准的通过 Maven 提供标准的库），我们可以使用分解依赖来满足我们的需求。

在架构 推ter SDK 堆栈，所有的一切都建立在 Fabric 上，它提供共享的 common 代码给所有我们的 SDKs. 我们建立了 推terCore 层，它提供了登录和 API 客户端和其他一些核心功能。

然后，我们才有基于特征的 SDKs，像我们的 Tweets，我们的 composer，我们的短信登录基础设施；这些特点都可能是你使用我们 SDK 的理由。最后，我们提供了一个接口，通过传递依赖关系将其包装起来。这允许应用程序开发人员根据他们需要的层次结构选择组件。

压缩数据(19:04)

除了注意 SDK 本身的大小之外，我们建议你在“压线”之前进行压缩。我们可以明显看到，不同格式之间有压缩大小差异，如 XML 和 JSON，一起使用jzip压缩格式，或二进制格式 Protobuf 。有些人可能不熟悉 Protobuf，它是一个二进制的压缩格式，在服务器和客户端接口使用一致的预期协议，使得不需要将所有字段都进行传输。它可以非常高效地进行序列化和反序列化。

批量处理请求(19:36)

有效地发射是避免消耗过多电源功率的关键。Android 有三种典型的能量状态：全功率、低功耗、空闲状态或称待机状态。

在高功耗的时候进行统一的网络传输，比在空闲的时候断断续续进行多次传输来得节约时间和节约电源。

对于在典型的3G设备上每一个数据连接，网络接收模块会产生约20秒的活跃时间。这意味着如果你每分钟有三个网络连接，我们将会保持这个网络接收模块不断地处于激活。通过批处理这三个连接，我们可以在这里减少20秒的启用速率，以及至少40秒的待机或空闲时间。

不过对于这个方面，有一个例子，说的是天真统计分析 SDK，它们有时会不停地 ping 你的服务器，大约20秒一次，仅仅是为了告知服务器你的应用当前处于前台。这么做的后果就是会造成网络接收模块一直处于激活状态，并且把电源耗尽又没有传输什么实质上的数据内容。

异步任务(20:54)

保持 Fabric 的轻量部分方式是，我们应该清楚地知道何时在主线程做的工作何时在后台线程工作，我们建议在你的应用程序启动时候初始 Fabric，因此它的初始化将在主线程，我们从我们周围很多顾客那里听到大家都是比较关注启动时间的。

为了缓解这一点，我们做了非常有限的一些同步工作，然后立马返回到开发者的 application，同时在后台继续做一些毕竟耗时的运行工作，以保持您的应用程序下次能够快速启动。

有些事情需要用同步做的一个例子：如果你使用在使用我们的 Crashlytics ，你得立即使用它的 crash handler，因为一旦崩溃异常发生在异步初始化 crash handler 完成之前，就会捕捉不到这个异常。

灵活性(22:36)

一个 SDK 的开发者没有像应用开发者那么多的选择权。你不能选择你的设备，API level，或客户。你需要支持更大范围的设备，应用程序开发者并不局限在选择你的SDK，所以提供最大程度的灵活性是很重要的。

建立工具支持(22:53)

灵活性的一个体现是，可以让开发者选择不同的依赖管理器或者构件工具来引入或集成你的库。

我们提供一些主要的开发工具插件支持，包括 Gradle, Maven, 和 Ant. 我们还为通常的 IDE 提供 GUI 插件，以及一个帮助开发 Mac 和 iOS app 的应用。尽管我们这是主要在讲 Android 方面开发 SDK 的内容，但我还是忍不住想告诉大家一个好消息就是我们最近完成了令人兴奋的 CocoaPods 支持，这将非常方便于 iOS 开发者使用我们的 SDK.

尽量选择兼容最低的系统版本(23:26)

灵活性的关键是了解您的 SDK 用户的需求。然后做出需要支持的最低系统版本的决定。我们很希望我们的 SDK 能够尽可能支持更多的系统设备。对于这一点，降低支持最低操作系统版本是很有必要尽力去做的。

但另一方面，兼容低版本也是要付出代价的。并没有什么直接的法则能够告诉我们如何才能在繁琐度和更好的兼容性上确定平衡。支持旧的操作系统版本，通常意味着不利用更加好用的新接口，同时还要面对一些旧版本存在的问题。初次之后，你还要花费更多精力去测试你的代码之正确性。

一般来说，SDK 会比应用软件在支持的最低系统版本的选择上，更近保守。例如，Crashlytics 提供了 Android 2.2 的支持，因为这是一个还基本实用的 Android 应用程序。而不是像一些应用程序，它们仅支持某一操作系统的版本，它们关注用户数量而去选择最佳系统版本。

另一个重要的部分是能够检测出你正在运行的 Android 版本，所以你才能知道，哪些是可以调用的方法。通常，SDK 支持更老版本的 Android SDK。这对我们来说是非常重要的，因为我们想提供最大限度的设备支持。

Android Manifests(24:57)

在 Android 系统上，运行时兼容性是灵活性的重要组成部分。Android 开发者都知道，一个应用程序的元数据(metadata)在 manifest 文件中声明，一个 apk 一个 manifest 文件。

此外，每一个你包含进来的 aar 都会带一个 Manifest 文件，只是在 build 的过程中，Android 工具会自动帮它们合并到一个 Manifest 里面。这意味着，如果一个 AAR 的 Manifest 会影响最终 Manifest 的生成，比如新增一个权限声明，这对于开发者来说是很难注意到的。

权限(25:37)

权限是任何 Android 应用程序的关键。在 Crashlytics 我们利用 wifi state permission 可以更好地管理上传崩溃日志。在 Android 的棉花糖系统上，这是属于正常水平的权限，这意味着它还需要在 manifest 文件中声明并同意。然而，我们没有在我们的清单中声明这个权限，所以，如果使用了我们 SDK 的开发者想要上传崩溃日志，就必须得在他的清单文件中声明上这条权限。如果开发者声明了那条权限，我们在下面的代码中就能够知道拥有这个权限了。

protected boolean canCheckNetworkState(Context context) {    String permission = Manifest.permission.ACCESS_NETWORK_STATE;    int result = context.checkCallingOrSelfPermission(permission);      return (result == PackageManager.PERMISSION_GRANTED);  }

private boolean hasOkHttpOnClasspath() {    try {      Class.forName("com.squareup.okhttp.OkHttpClient");      return true;    } catch (ClassNotFoundException e) { }    return false;  }