安卓开发常用工具和第三方库汇总

我的名字叫 Ryan Cooke 我在 Pinterest 的核心体验团队工作。今天在这里我会谈论各种 Android 库：它们各自的优点，缺点和其他相关知识。目的是高效地概述尽可能多的库，这样，当你遇到一个问题的时候，你知道这是不是个已经解决的问题？什么样的方案更好？同时也能帮助你避免那些陷阱。

选择正确的库意味着你可以拥有一个已经成熟的更好的解决方案，而不是花费三个月来重新构建它。了解这些库是第一步。

我听到很多人想要实现第一个库， 我们难道不能用 Async 任务或原生的东西来做吗？ Google 觉得，如果市面上已经有一个解决方案了，他们就不想建立一个一模一样的竞品。他们在多个地方多次表达过这个想法。但是你应该知道，你还有一些别的选择。

一般提示

库最有价值的地方在于 可逆 ：你将库添加到你的应用程序中，之后也可以将其删除（没有任何开销）。随时都能拿出来。不是所有的东西都可以这样，但如果它可以的话，请把它做成一个库，而不是和你的应用终生绑在一起。

一个更好的方法是在把你的库封装起来。如果你自己的类调用了库的方法，那么这样做就有着许多的好处，可以让使用者调用你自己的 API。例如，在某些情况下如果库返回异常，你想在 API 里截获它。你只用修改一个文件。有一个封装器让你的库更易用些。

如果你正在做一个库，你的团队里面的某些人可能已经开始使用它了，他们知道该如何调用你的库，而不用你的封装。这个检查样式会在编译的时候抛出异常，或者在应用中当他们为连接类使用 import 语句时，提示他们“不要使用连接类，使用封装的 API”。你还会指出不要在这个特定文件上这样做。如果你不这样做，封装器用处就不大，因为人们最终会绕过它。

另外， 对第三方库做单元测试 也是一个好主意。你需要这些测试，如果你正在使用 Joda-Time 这样的库，你可以使用单元测试来了解它奇怪的边界情况。你甚至可以通过单元测试来了解它的工作原理。你可能会发现，如果你不用 add day 方法而是给今天加一的话，你可能会出现二月三十日的情况。

在 Android 的世界中，我们必须考虑 函数数量限制（64,000） 。（ 我在说第三方函数库的函数数量，它们会被精简掉 ）。有一个网站[函数数量]（http://methodscount.com），你可以上传你的库，Gradle 导入语句，然后它会告诉你这个库有多少个方法（这是件很棒的事情，特别是当你想使用该库的时候）。使用 ProGuard，许多库将会变得很小。这个方法使你只会包含库中被引用的部分，但是在使用库之前是很难预测你将要使用的内容的。有些时候你可以这样做，“我知道我只使用库的这个方法”，看看它有多小。

Dex函数计数 会在你的 gradle 里，你也可以在你自己的编译系统上这么做，跟踪你应用程序中函数的总个数。 Apk-method-count 是一个很棒的工具。你可以拖动你的 APK，看看它有多少个方法（63,905 个方法，我喜欢生活在 64,000 的边缘）。在 MultiDex 限制出现之前，你添加的每个方法仍将减慢那些旧设备的启动时间。虽然你的船已经航行，不受 MultiDexing 的限制，十万种方法和十二万种方法之间还是有差别的。更少的方法总是有好处的。 Instagram 就是以 从库 中提取所需的东西而不是使用完整的库而闻名的。这是一个很好的实践，如果你有精力这样做的话。

除此之外，我还建议关注 流行的成熟库 。每个月（特别是如果你订阅了 Reddit Android 开发者），你将会听到最新，最酷的库。库越成熟，就会越受欢迎。与现有的项目一起工作，兼容性问题就越少。无论何时遇到问题，stackoverflow 那里都会有答案。

另外，请注意特殊的方法。这是不符合 Java 标准的东西。如果你正在构建完全不同的布局，那么很可能会有兼容性问题。这时采用库就会变得更加犹豫。

社交登录

Facebook 是社交登录的黄金标准（ 如果你不喜欢 Facebook 的实现，情况只会变得更糟 ）。他们提供测试用户，你可以使用这些测试账户来测试。不再需要假帐户了，你应该使用他们的测试帐户 - 它们工作的更好。我看过有人犯过这样的错误，你不能假设每个 Facebook 用户都有电子邮件。大约 10 到 15％ 的 Facebook 用户没有电子邮件。如果你期待电子邮件，这可能是 10 到 15％ 的注册失败的神秘原因。他们需要密钥散列（ 这是一个随机序列，某段代码打印出的键值哈希 ），所以你不必处理它，不用理会它。如果你想申请些其他的疯狂权限，他们现在已经锁定了这些权限。他们需要先看看你打算如何使用这些权限，如果你有这个疯狂的想法而且应用还没有开发好，请提前告知他们。

登录和注册时，请记录你所得到的错误。这是我们如何发现由于没有电子邮件，10 到 15％ 的注册失败的方法。有时候记录错误可能是找到你不了解的东西的最有效的方法。

还有很多其他登录选项：Twitter，LinkedIn，Google。我的心态是（特别是 Twitter，LinkedIn），虽然他们很受欢迎，但往往不值得的尝试。你会看到不到 2％ 的注册率，除非是一个非常好的场景。 LinkedIn 提供了非常具有挑战性的 API（ 这不是我原来的单词，但是 PR 告诉我，我应该改变它 ）。 Twitter，他们不提供很多信息，但你可以 转到此链接 ， 并且说我需要电子邮件和基本信息，他们会给大家授予权限。但总体来说，除非你的架构非常好，这些都会增加你应用的复杂性，。

Google 情况比较复杂。在 Android 上，很多人都会拥有 Google 帐户。如果他们没有 Google 帐户，是非常奇怪的。但是你可以从 Google 登录中获得很多功能 - 你可以获取电子邮件提示和其他东西。此外，登录 UI 是十分丑陋的。还有点慢，所以你必须考虑加载模式的对话框。

联网

如果你使用本地库，那么有两个大名鼎鼎的库：Retrofit，Volley。还有 native HTML URL Connect（通常不推荐）。对于 Retrofit 和 Volley 来说，你经常会看到些比较，你会看到 Volley 比 Retrofit 做的更多（例如图像下载和 neat ）。这具有欺骗性。

Retrofit 是由 Square 建造的，他们有一个哲学，他们的库会尽可能少做事情。他们试图让库严格地解决具体的问题，解决这个问题时，强制执行良好的实践。Retrofit 可能是他们最好的例子。这段代码（ 见幻灯片 ）是我在一个应用程序中使用 Retrofit 的示例，我必须为我的 API 调用创建一个非常干净的接口。

Get more development news like this

Volley 给你足够的绳子吊死自己。你可以使用 Volley，很容易用错。Retrofit 更好地强化了最佳实践，我喜欢这样的做法。

很多时候你会听到 OkHttp：这是真正的幕后大举提升网络性能的功臣。它已经在 Android 4.4 的 native 里面了。

网络调试

考虑到网络调试，你有网络调用正在进行，你想了解发生了些什么。

Stetho

Stetho 是一个很好的选择。它是 Facebook 开发的。它为你的网络调用提供了 Chrome 开发者工具视图。它还提供了许多其他的好东西：可以查看你的数据库，看看那里发生了什么;可以看到你的布局，如果你不知道屏幕上发生了什么。其中需要注意的是，你必须在每次运行时启动它，否则它会自动关闭。虽然时间是准确的，但它会使你网络调用的时间更长。

HttpLoggingInterceptor

我个人倾向于另一个简单的 HttpLoggingInterceptor。你将拦截器添加到你的网络请求中，并将其打印在日志文件上。你也可以看到一些 JSON 文件。有一堆类似的东西都命名为 logging 拦截器。使用 Square 的标准 HTTP 日志记录可以让你更轻松地浏览，非常方便。

图片

作为在 Pinterest 工作的人，图片很重要。如果你正在做图片相关的应用，你可能希望使用第三方库来处理图片缓存，图片下载和图片大小调整。

Picasso,Glide

图片处理库里最有名的两个库是 Picasso 和 Glide。他们有着非常相似的接口；对于大多数标准用户来说接口基本相同。

Picasso 较小。最新版本从 2,879 行缩小到 849 行。但是，Glide 倾向于提供你想要的每个功能：它可以加载 GIF，也可以显示视频预览图像。

如果你正在加载图片，Picasso 比较合适。它更受欢迎：它有更多的文档，更多的支持。两个库都很好。如果你一直都有些奇怪的场景，你可以冒险使用 Glide。如果你的使用场景很标准，Picasso 是一个不错的选择。

提示

我已经提到我在 Pinterest 工作，而且图像对我的工作很重要。我必须扔出一堆关于图像的提示。

人们都没有做最简单的事情，因为这些库没有这样做，这件简单的事情就是在列表中预取。每当你滚动列表时，你都会看到图像在加载。如果你预取了下一个或两个图像，那么当你滚动时，将会减少帧丢失。这会给你带来更好的体验，不需要等待加载了。如果你预取的图像太多，资源就会竞争，也不好，但预取下一个或两个图像一定会带来更好的体验。

除此之外，这些库都不能解决你图像的内存问题。最简单的做法是禁用图像，然后计算出应用程序中的图像消耗了多少内存。不使用图像，计算出省下的内存消耗。另外，释放没有显示图像的图像，并将图像的大小调整为你显示的尺寸也可以帮助节省内存。 Cloudinary 是一个很酷的托管服务，你可以以特定的分辨率请求图像。他们努力做到这点。但是，当你调整请求的图像大小时，你必须确保你没有通过请求类似的图像来破坏缓存（所以这里有个平衡）。

我是 bigHeap 的粉丝。我们的一个的应用程序，使用了 bigHeap 后，内存崩溃降到原来的 1/4。 Google 不鼓励使用它，因为它关闭了在后台的其他应用程序，因此应用程序之间的切换并不是那么好。但在某些时候，这不是你的问题。垃圾回收也需要更长时间，你可以使用它来屏蔽内存问题（你不应该这么做）。一般来说，bigHeap 是好的。如果你去 Play Store，并且搜索 largeHeap，你可以下载一个很酷的应用程序，它会显示你手机上启用了 bigHeap 的应用程序。你会注意到现在几乎每个人都陷入了困境，并且正在使用 bigHeap。

当你想到内存和图像时，这里有一个简单的公式。有些人会问，“这是个两千字节的 JPEG，为什么我的实际使用的内存会这么大呢？” 使用的内存是像素宽度乘以像素高度的四倍。这就是你期望的大小。它们的标准格式是 ARGB_8888 - 它用四个字节存储颜色空间。如果你使用 RGB_565，你可以将其减少到两倍。但是颜色彼此会非常相似，你会看到更少的色彩空间，它也不能做 alpha，但它会减少一半的内存使用量。你可以考虑在低端设备或低版本 API 上进行此操作。这是节省内存不足问题的好方法。

Fresco

Facebook 发布了一个神奇的库，解决了 API 21 之前的所有版本的内存不足问题。在 API 21 之前，Android 系统中出现了一个错误，你可以在应用程序内存之外使用其他的内存。但是会带来些奇怪的情况：你的程序在旧设备上没有问题，但在新设备上会表现更糟。因为它加载的方式与其他库非常不同，所以它可以实现渐进式 JPEG 这样的图像，图像在图层中逐渐加载。但是，它们会更深入地耦合在你的应用程序中。借助 Glide 和 Picasso，你可以将其与你的应用隔离的很好。而不使用 imageViews，你必须使用它们的类型 Drawees，并且还会产生更多的孤岛代码。

如果你定位较低端的设备，你在旧设备上有更多的内存需求，我建议你使用 Fresco。除此之外，我会坚持 Picasso 和 Glide。

内存 - 泄漏

LeakCanary

LeakCanary 是当今内存泄露的神器，它可以帮助你找到内存泄露的地方。泄漏不是所有的内存问题，但是值得留意。当你将 LeakCanary 添加到应用程序中时，它会自动开始观察你的 activity 的内存泄漏。有一个我亲眼所见的误用是，他们将 LeakCanary 添加到应用程序中。修复一个或两个泄漏，然后就认为再没有更多的内存泄漏了。它只监视了 activity。如果你在这里使用这个代码（ 看幻灯片 ），你可以让它监视 fragment。这并不意味着你不会在别处泄漏内存。activity 和 fragment 是监测的好地方，但如果你没有将观察者设置为对象，你是不知道所有的泄露的。

简单来说，它的工作原理很酷。作为你引用的任何对象的弱引用：将其附加到你不再被引用的内容中。你把它放在 destroy 代码段。然后它做垃圾回收。如果对象仍然存在，这就是内存泄漏，所以它知道什么对象依旧存在。它给你那个 home fragment 现场的相关引用。我觉得这很难理解（*有些人认为这很简单，有人认为这很难。）

这里有个 view 的例子来做点简单说明（ 见幻灯片 ）。你从底部开始（这就是泄露的东西）。我有 home fragment。 它被 pin grid fragment 引用 - pin grid fragment 是这个对象的父亲。然后我们有这个奇怪的$ 0 - 它解释说，这是一个可运行的对象。对象内有一个处理程序包含一个 runnable。这段代码（这不是我的），它是 Android 操作系统的，是处理程序的代码。处理程序有个 runnalbe 正在运行。我需要确保处理程序不再保留 runnable。在这种情况下，我可以在视图的 destroy 中清除所有的 runnable 和处理程序，这将修复这个内存泄漏。

WeakHandler

你还可以使用这个随机工具 WeakHandler，这使得处理程序引用都是弱引用。如果你触发一个垃圾回收，就可以回收它们。它的缺点是可以被垃圾回收 - 如果你不希望它们被垃圾回收，那可能会出现意想不到的事情。值得注意的是，我遇到的大多数内存泄漏都是无效的，它通常是一个正在运行的 non-missed 的类持有外部类 （这是最常见的地方） 。对于你的内存泄漏，还需要一个 bug 分类的方法。没有什么比你手机上有 70 个内存泄漏， 而你不知道下一步该做什么更糟糕了。作为一个团队，弄清楚当我们发现内存泄漏时要做什么，总是一个好主意。

UI

我们都知道我们一直深陷泥潭。Activity 是旧标准。因为你想重用，所以有了 fragment。但是最后我们用 fragment 把 UI 显示做的异常复杂。试试另一种方法，基于视图的架构，它更流行。在基于视图的架构里，你有一个框架布局，而不用处理任何原生的 Android navigation 的东西，你可以用你想要的视图替换内部的框架布局里的任何东西。希望这能够解决 fragment 的复杂性。

fragment 已经被简化了，而且更新了版本，它们现在更加稳定，但是人们依旧争论着需要有基于视图的架构。如果我们遵循这个论点，我们应该看看一些库（图形的底部， 看幻灯片 ）。

基于视图的架构

这个架构是由 Mortar 和 Flow 引入的。我相信他们是第一批普及基于视图的架构的库。 Flow 真正地遵循了基于视图的架构，但是它们往往是一起的，而 Mortar 主要是 MVP 模式。当你开始实现基于视图的架构时，请注意这个奇怪的地方。

你还可以找到些更奇怪的地方，那就是如果你的应用是基于 View 的话，你会遇到些随机的问题，因为这个库不是基于 View 的。它是基于 activity 的， 如果你的应用是基于 view 的话，你得自己去解决那些问题。比如基于 View 的标准问题，例如 on-activity 的行为，许可等等。即使是后退按钮和导航，你都不得不自己去解决，只要你是基于 View 的。

Mortar 和 Flow完成基本的导航功能，但它们并不解决所有常见问题（例如屏幕上保存的状态）。

Conductor正是为这些基于 View 的视图而生的，它创建了一个解决方案：比如保存状态，转换等等。但是你仍然会遇到兼容性问题。总的来说，他们是非常好的，他们是架构不可知的，所以你可以采用你自己的 MV。

Scoop 来自 Lyft。他们在产品中使用它。它是经过产品测试的基于视图架构的解决方案。它们不保存状态，所以 Lyft 无法保存状态。在你将要使用基于视图的架构的主要常见问题中，这是最大的问题。切换很容易使用，但也很有限，这对于基于视图的体系结构来说有点令人失望，因为在这种架构下，你往往可以实现很好的切换。

总的来说，如果你不需要保存状态，Scoop 是可用的，最安全的产品。Conductor 也很好。我会推荐这两个库。

模型 视图 表示（MVP）

有几个很好的 MVP 的库。MVP 的基本思想是把逻辑代码分离出来，这样视图部分，Core Android 的东西，会放在一起，然后 presenter 也是分开的，我们可以单元测试这个 presenter。理论上，我们可以改变视图，而不必完全重写业务逻辑。

有很多方法来做 MVP。我推荐的第一个库是 Mosby 。即使你不使用 Mosby，他们也有很棒的教程和 Android 相关的文章（ 比如 MVP 应该是什么样的，它如何工作 ）。它主要能提供的功能是给你的 presenter 提供视图状态。

Nucleus也很类似。 Mortar ，作为 Mortar 和 Flow 的一部分，是它们早期的版本，它们越升级问题越多。我看到公司常常自己 构建 MVP ：在创建时，你将启动你的 presenter; 销毁时，你会停止你的 presenter 。每个 activity 或任何你的视图持有的任何东西都会有一个 presenter。

所有的这些权衡，虽然听起来很简单，当你实际操作一个用例时，有很多边缘案例要考虑。你有你的适配器，你的视图项目。确保每个人理解的都一样，并且找到能够运用 MVP 的地方是最难的部分。但是这样做的最终结果是你可以获得更多的可单元测试代码。你可以获得更稳定的代码。

测试 - 性能

NimbleDroid

我有一堆关于测试的内容，但我不想让你们听三个小时测试的东西，所以我们跳过使用 JUnit 4 进行单元测试。你有一个 Gradle 构建系统，有 Espresso。这些都是标配。性能测试是个非标的工具。

执行性能测试有两种主要的方法。 Google 倾向于主张使用 Systrace 类似的方法来查看丢帧率，他们有一个代码库，可以为你提供几乎能直接工作的代码（但不是很有效）。这允许你进行自动化性能测试，以查看丢帧率是否变化。

NimbleDroid 有一个免费的试用选项，你可以在其中上传 APK，它将自动测试冷启动，你也可以增加些应用程序中的关键流程。他们提供一个函数发生的时间序列图和详细信息。它可以免费进行试用（例如上传你的 APK 并获得冷启动时间，看是否有明显问题）。如果你想使用它来进行回归测试，那么它是很贵的，但它会帮助你意识到，有人做了一个改动，我们的启动时间变慢了，或者我们的关键流程慢了。如果性能是一个高优先级的目标，那么使用它是很有效的。

JSON

人们在考虑性能时往往都会想到 JSON。有很多的 JSON 库。我的第一个警告是：人们喜欢纯粹通过性能来看待 JSON 库。这是一个错误。我收到了我最大的请求（150千字节，30,000行，巨大的 JSON 文件）。我分别用 GSON 和 Jackson 解析了它们。它们相差大约 20 毫秒，对于那个巨大的文件来说，这并不疯狂。

我的第一个建议是：更多地关注易于使用的东西，有很好的文档的库。你希望得到支持。你不用花几个星期让开发人员尝试找出原因，就因为 stackoverflow 没有答案。除非你对性能有超高的要求，GSON 和 Jackson 是使用最多的，最受欢迎的，特别是在 Android 上，GSON 更受欢迎。

Moshi 是 Square 采用的库。它跟 GSON 非常相似。我试图就如何使用好 GSON 给出了一些意见。你可以同意或不同意这些观点，但都不会错。

如果你关心 JSON 解析性能，并希望它更快，LoganSquare 是一个很好的选择。它们在编译的时候完成了其他库需要在运行时完成的工作。与其他的库相比，这将使你节约大约 1/4 的时间，或四倍的性能提升。如果你真的关心 JSON 性能，你不应该使用 JSON。

相反，你可以使用 Flatbuffer。 JSON 人类可读，Flatbuffer 不是，但是因为这样，它丢掉了其他的不需要的负担。但是 Flatbuffer 与 JSON 相比，Falbuffer 解析几乎不花时间。Facebook 做了这个转换。他们发现启动时间增加了 10％ 到 15％，启动时间有所改善。他们也观察到内存使用效率更高。但是使用起来比 JSON 更难，所以谨慎使用。

数据库 - SQL

对于数据库，我们知道常见的是 SQLite - 标准 Android 库。

SQLBrite 是 SQLite 上一个常见的简单库;它为你提供了数据库的 reactive 接口。你可以监听你的用户。如果你的用户有任何更改，你会收到通知，你可以随即更新用户界面。这是一个非常小的库。和 SQL 兼容的很干净。

SQLDelight 也来自 Square。他们写了很多库。它试图避免成为一个完整的 ORM，因为 ORM 会泄漏太多你的代码，并且往往迫使你做太多的事情，当然它仍然试图使数据库的工作更容易些。它使得 API 类型安全，使得 SQL 语句组织的很好（它尝试使其更容易些，同时不会太重）。

如果你愿意去做一个完整的 ORM，那么有很多很好的库：GreenDAO，OrmLite，DBFlow 是一些比较受欢迎的（ 还有许多其他选择 ）。他们都会说，它们在性能方便表现最好。每个库都有些图表，这些图表显示它们比其他的方案快 100 倍。我的建议是易用性是第一优先事项，然后再考虑是他们在性能上是不是会更好。

数据库 - NoSQL

Realm 是 NoSQL 的方法。它超级快。与其他可比较的数据库不同，Realm 支持的文档非常多。这可以最终节省你大量的开发时间，而且无所谓数据库类型。

Google 推荐的另一种 NoSQL 方法是 LevelDB。键值对，但是它可以说是 “你能够弄清楚该怎么做，但你必须自己弄清楚每一步”。 Realm db 可以帮助你避免这种情况。

Realm 数据库需要特别注意的地方是它的大小（ 我认为我们最初添加它时，我们的应用程序大小增加了一倍 ）。原因是它是一个本地库。对于每个芯片架构，它们在你的应用程序中都包含了 Realm 数据库的完整副本。为了避免这种情况，你可以将此代码放入 Gradle（ 参见幻灯片中的代码 ），并为每个架构生成一个单独的 APK。你把它分解成多少个版本，大小就会减少多少。这也会使你的内存节省很多。对于任何本地运行的 C++ 代码，这是正确的做法，所以在 Crashlytics 和其他一些受欢迎的库中，你能看到同样的收益。

还有另外一款很酷的 Google Play 商店的应用程序 Native Lib。 - 它在 Play 商店中，它会显示些本机库，以便你可以看到你是否为你的 APK 下载了不适用于你手机的代码库。这样做会减少内存使用。如果你就是在寻找手机上保存数据的方案，你可能希望在手机上存储数据。如果你正在构建一次性的应用程序，请不要保持数据。如果你正在使用 Realm 在存储量很小的手机上构建应用（为什么在这种情况下你的应用需要占用大量的存储）？但总的来说，这是一个非常好的数据库解决方案。

数据库 - 移动平台

另一个方面是移动平台：移动开发人员的梦想，我们不再需要这些服务器指南。我们也可以自己构建应用程序。以前的 Parse 是最好的例子（可能会安息）。

现在移动平台中最有名的就是 Firebase 和 Realm。它们都是 NoSQL 模型，它们有一些查询方面的挑战，但是构建速度非常非常快。非常适合进行同步更新。聊天是最常见的解决方案，你发送聊天消息，突然所有的手机都能获取更新。不必构建数据库，不必拥有服务器，你可以使用其中一个解决方案。它使得构建过程非常迅速，马上完成应用并推向市场。而且性能也特别好。

Realm 与 Firebase 的区别是它有离线优先的优点。它们都可以脱机，但是 Firebase 是事后补救，而 Realm 是事先就设计好了，Realm 在许多方面都支持离线。许多应用程序几乎不需要在线行为。如果你正在考虑运行应用跟踪程序，我们希望同步我们的运行状态，而且我们希望所有功能都能完全脱机运行，之后在线工作也正常。Realm 就会脱颖而出。

Analytics

我喜欢分析。精益创业的说法是。如果你可以测量它，你就可以优化它。如果你没有数字的东西，一切都是随机的，你只能猜想如何使它更好。我喜欢有详细的分析，来了解这个改变是否使事情变得更好？人们是否使用此功能？如何改善它？

Analytics 是封装第三方库的理想选择。如果你封装好了 Analytics，那么你应该能够在不修改任何功能代码的前提下，完全替代你的分析服务。你应该能够很容易地添加一个新的 Analytics 服务，以便它们能同时工作。封装 Analytics 代码是一个很好的实践。

如果你正在添加分析数据，最简单的方法是记录你的屏幕，记录人们浏览过的屏幕，将其放在抽象的 activity 中。这样会很快地获得很多的价值。

我看到人们使用 Analytics 技术的常见错误是增加了太多的 Analytics 。他们会在任何地方添加一千个事件，然后没有人知道这个分析意味着什么。他们没有进行充分的测试，所以你真实的注册只有注册的 2/3。在添加分析时需要非常小心。尝试使用简单的命名和标准。不要使用分析来延迟轻松的决定。如果有一个容易的决定，那么请开始。如果你的分析结果告诉你“人们不喜欢释放内存”，那先假设你的分析是错误的。得出一个错误的结论是很容易的。如果你有一个很重要的结论，首先要做的是确认你的分析代码方面没有什么疯狂的事情。

Firebase

Firebase 曾经是一个实时数据库，然后 Google（混淆我们）开始使用一大堆叫做 Firebase 的工具。Firebase Analytics 是所有 Firebase 工具的基础。Google 意识到 iOS 和 Android 开发人员正在解决同样的问题。他们正在使用第三方服务并且通过付费来解决所有这些问题。他们认为，我们可以使构建应用程序更加容易，而且构建应用程序更容易，赚的钱就更多。他们做了这些工具的竞品。迫使它们更好用，谷歌试图使分析工具成为所有的工具的基础。这样做的愿景是，如果你收到崩溃报告，看到你的分析数据，你可以按照崩溃的投资回报率给它们排序。你的通知系统也参与其中，你可以发送通知给那些碰到最昂贵的崩溃的客户，并告诉他们一些免费的折扣。我们知道你即将购买，因为你是一个高价值的崩溃。

这是个很酷的愿景。还没有实现，实话实说。有些工作正常，有些还在开发中，这不是谷歌最高的优先级的任务。但是很多工具还是很好的（不如竞争对手的工具）。 Analytics 虽然是免费的。但是事件不受限制。没有太多的理由不使用它。

另一个流行的是 Google Analytics（分析）。它很容易地获得许多关于用户的基本信息。这是我看到的唯一一个提供很酷的行为流程图的工具，在那里你可以看到人们在你的事件之间切换。它还是有点过时了，其记录事件的风格比所有其他分析工具更旧。它也是免费的，Firebase 意在替换它。

A / B 测试

我个人认为 A / B 测试被过度宣传。通常它被用于慢速学习，以便你了解的更清楚，如果是简单的命名规则就不适用了，当然你可以将其投放到用户手里，你会发现，100 个用户的样本中，55％ 偏好了这一选择。这就是你通常看到的 A / B 测试。

它很容易产生 Bug。基本上，A / B 测试中应用程序版本数是你应用程序中的 A / B 测试数加 2。如果你的应用程序中有 3 个 A / B 测试，那么就有 8 个不同版本应用程序一起工作。你可能没有测试各种不同版本的应用程序。有时候你可能会发现因为这些问题，往往会导致重要的决定不太容易做了。

我的解决方案是用户分析服务。 Mixpanel 具有非常好的 A / B 测试工具，而且和你的分析工具兼容。有许多工具用于 A / B 测试。我想说最有名的是 Optimizely 和 Apptomize。Optimizely 更适合网页（ 他们的价格 都有点神秘）。他们帮助你提供不同的版本，告诉你这是一个比另一个有显著的更好的统计学差异的版本。

声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除