<p>我的名字叫 Ryan Cooke 我在 Pinterest 的核心体验团队工作。今天在这里我会谈论各种 Android 库：它们各自的优点，缺点和其他相关知识。目的是高效地概述尽可能多的库，这样，当你遇到一个问题的时候，你知道这是不是个已经解决的问题？什么样的方案更好？同时也能帮助你避免那些陷阱。</p>    <p>选择正确的库意味着你可以拥有一个已经成熟的更好的解决方案，而不是花费三个月来重新构建它。了解这些库是第一步。</p>    <p>我听到很多人想要实现第一个库， <em>我们难道不能用 Async 任务或原生的东西来做吗？</em> Google 觉得，如果市面上已经有一个解决方案了，他们就不想建立一个一模一样的竞品。他们在多个地方多次表达过这个想法。但是你应该知道，你还有一些别的选择。</p>    <h3>一般提示</h3>    <p>库最有价值的地方在于 <strong>可逆</strong> ：你将库添加到你的应用程序中，之后也可以将其删除（没有任何开销）。随时都能拿出来。不是所有的东西都可以这样，但如果它可以的话，请把它做成一个库，而不是和你的应用终生绑在一起。</p>    <p>一个更好的方法是在把你的库封装起来。如果你自己的类调用了库的方法，那么这样做就有着许多的好处，可以让使用者调用你自己的 API。例如，在某些情况下如果库返回异常，你想在 API 里截获它。你只用修改一个文件。有一个封装器让你的库更易用些。</p>    <p>如果你正在做一个库，你的团队里面的某些人可能已经开始使用它了，他们知道该如何调用你的库，而不用你的封装。这个检查样式会在编译的时候抛出异常，或者在应用中当他们为连接类使用 import 语句时，提示他们“不要使用连接类，使用封装的 API”。你还会指出不要在这个特定文件上这样做。如果你不这样做，封装器用处就不大，因为人们最终会绕过它。</p>    <p>另外， <strong>对第三方库做单元测试</strong> 也是一个好主意。你需要这些测试，如果你正在使用 Joda-Time 这样的库，你可以使用单元测试来了解它奇怪的边界情况。你甚至可以通过单元测试来了解它的工作原理。你可能会发现，如果你不用 add day 方法而是给今天加一的话，你可能会出现二月三十日的情况。</p>    <p>在 Android 的世界中，我们必须考虑 <strong>函数数量限制（64,000）</strong> 。（ <em>我在说第三方函数库的函数数量，它们会被精简掉</em> ）。有一个网站[函数数量]（http://methodscount.com），你可以上传你的库，Gradle 导入语句，然后它会告诉你这个库有多少个方法（这是件很棒的事情，特别是当你想使用该库的时候）。使用 ProGuard，许多库将会变得很小。这个方法使你只会包含库中被引用的部分，但是在使用库之前是很难预测你将要使用的内容的。有些时候你可以这样做，“我知道我只使用库的这个方法”，看看它有多小。</p>    <p><em>Dex函数计数</em> 会在你的 gradle 里，你也可以在你自己的编译系统上这么做，跟踪你应用程序中函数的总个数。 <em>Apk-method-count</em> 是一个很棒的工具。你可以拖动你的 APK，看看它有多少个方法（63,905 个方法，我喜欢生活在 64,000 的边缘）。在 MultiDex 限制出现之前，你添加的每个方法仍将减慢那些旧设备的启动时间。虽然你的船已经航行，不受 MultiDexing 的限制，十万种方法和十二万种方法之间还是有差别的。更少的方法总是有好处的。 Instagram 就是以 <em>从库</em> 中提取所需的东西而不是使用完整的库而闻名的。这是一个很好的实践，如果你有精力这样做的话。</p>    <p>除此之外，我还建议关注 <strong>流行的成熟库</strong> 。每个月（特别是如果你订阅了 Reddit Android 开发者），你将会听到最新，最酷的库。库越成熟，就会越受欢迎。与现有的项目一起工作，兼容性问题就越少。无论何时遇到问题，stackoverflow 那里都会有答案。</p>    <p>另外，请注意特殊的方法。这是不符合 Java 标准的东西。如果你正在构建完全不同的布局，那么很可能会有兼容性问题。这时采用库就会变得更加犹豫。</p>    <h3>社交登录</h3>    <p>非死book 是社交登录的黄金标准（ <em>如果你不喜欢 非死book 的实现，情况只会变得更糟</em> ）。他们提供测试用户，你可以使用这些测试账户来测试。不再需要假帐户了，你应该使用他们的测试帐户 - 它们工作的更好。我看过有人犯过这样的错误，你不能假设每个 非死book 用户都有电子邮件。大约 10 到 15％ 的 非死book 用户没有电子邮件。如果你期待电子邮件，这可能是 10 到 15％ 的注册失败的神秘原因。他们需要密钥散列（ <em>这是一个随机序列，某段代码打印出的键值哈希</em> ），所以你不必处理它，不用理会它。如果你想申请些其他的疯狂权限，他们现在已经锁定了这些权限。他们需要先看看你打算如何使用这些权限，如果你有这个疯狂的想法而且应用还没有开发好，请提前告知他们。</p>    <p>登录和注册时，请记录你所得到的错误。这是我们如何发现由于没有电子邮件，10 到 15％ 的注册失败的方法。有时候记录错误可能是找到你不了解的东西的最有效的方法。</p>    <p>还有很多其他登录选项：推ter，LinkedIn，Google。我的心态是（特别是 推ter，LinkedIn），虽然他们很受欢迎，但往往不值得的尝试。你会看到不到 2％ 的注册率，除非是一个非常好的场景。 LinkedIn 提供了非常具有挑战性的 API（ <em>这不是我原来的单词，但是 PR 告诉我，我应该改变它</em> ）。 推ter，他们不提供很多信息，但你可以 <a href="/misc/goto?guid=4959754713679384562" rel="nofollow,noindex">转到此链接</a> ， 并且说我需要电子邮件和基本信息，他们会给大家授予权限。但总体来说，除非你的架构非常好，这些都会增加你应用的复杂性，。</p>    <p>Google 情况比较复杂。在 Android 上，很多人都会拥有 Google 帐户。如果他们没有 Google 帐户，是非常奇怪的。但是你可以从 Google 登录中获得很多功能 - 你可以获取电子邮件提示和其他东西。此外，登录 UI 是十分丑陋的。还有点慢，所以你必须考虑加载模式的对话框。</p>    <h3>联网</h3>    <p>如果你使用本地库，那么有两个大名鼎鼎的库：Retrofit，Volley。还有 native HTML URL Connect（通常不推荐）。对于 Retrofit 和 Volley 来说，你经常会看到些比较，你会看到 Volley 比 Retrofit 做的更多（例如图像下载和 neat ）。这具有欺骗性。</p>    <p>Retrofit 是由 Square 建造的，他们有一个哲学，他们的库会尽可能少做事情。他们试图让库严格地解决具体的问题，解决这个问题时，强制执行良好的实践。Retrofit 可能是他们最好的例子。这段代码（ <em>见幻灯片</em> ）是我在一个应用程序中使用 Retrofit 的示例，我必须为我的 API 调用创建一个非常干净的接口。</p>    <p>Get more development news like this</p>    <p>Volley 给你足够的绳子吊死自己。你可以使用 Volley，很容易用错。Retrofit 更好地强化了最佳实践，我喜欢这样的做法。</p>    <p>很多时候你会听到 OkHttp：这是真正的幕后大举提升网络性能的功臣。它已经在 Android 4.4 的 native 里面了。</p>    <h3>网络调试</h3>    <p>考虑到网络调试，你有网络调用正在进行，你想了解发生了些什么。</p>    <p>Stetho</p>    <p>Stetho 是一个很好的选择。它是 非死book 开发的。它为你的网络调用提供了 Chrome 开发者工具视图。它还提供了许多其他的好东西：可以查看你的数据库，看看那里发生了什么;可以看到你的布局，如果你不知道屏幕上发生了什么。其中需要注意的是，你必须在每次运行时启动它，否则它会自动关闭。虽然时间是准确的，但它会使你网络调用的时间更长。</p>    <p>HttpLoggingInterceptor</p>    <p>我个人倾向于另一个简单的 HttpLoggingInterceptor。你将拦截器添加到你的网络请求中，并将其打印在日志文件上。你也可以看到一些 JSON 文件。有一堆类似的东西都命名为 logging 拦截器。使用 Square 的标准 HTTP 日志记录可以让你更轻松地浏览，非常方便。</p>    <h3>图片</h3>    <p>作为在 Pinterest 工作的人，图片很重要。如果你正在做图片相关的应用，你可能希望使用第三方库来处理图片缓存，图片下载和图片大小调整。</p>    <p>Picasso,Glide</p>    <p>图片处理库里最有名的两个库是 Picasso 和 Glide。他们有着非常相似的接口；对于大多数标准用户来说接口基本相同。</p>    <p>Picasso 较小。最新版本从 2,879 行缩小到 849 行。但是，Glide 倾向于提供你想要的每个功能：它可以加载 GIF，也可以显示视频预览图像。</p>    <p>如果你正在加载图片，Picasso 比较合适。它更受欢迎：它有更多的文档，更多的支持。两个库都很好。如果你一直都有些奇怪的场景，你可以冒险使用 Glide。如果你的使用场景很标准，Picasso 是一个不错的选择。</p>    <h3>提示</h3>    <p>我已经提到我在 Pinterest 工作，而且图像对我的工作很重要。我必须扔出一堆关于图像的提示。</p>    <p>人们都没有做最简单的事情，因为这些库没有这样做，这件简单的事情就是在列表中预取。每当你滚动列表时，你都会看到图像在加载。如果你预取了下一个或两个图像，那么当你滚动时，将会减少帧丢失。这会给你带来更好的体验，不需要等待加载了。如果你预取的图像太多，资源就会竞争，也不好，但预取下一个或两个图像一定会带来更好的体验。</p>    <p>除此之外，这些库都不能解决你图像的内存问题。最简单的做法是禁用图像，然后计算出应用程序中的图像消耗了多少内存。不使用图像，计算出省下的内存消耗。另外，释放没有显示图像的图像，并将图像的大小调整为你显示的尺寸也可以帮助节省内存。 Cloudinary 是一个很酷的托管服务，你可以以特定的分辨率请求图像。他们努力做到这点。但是，当你调整请求的图像大小时，你必须确保你没有通过请求类似的图像来破坏缓存（所以这里有个平衡）。</p>    <p>我是 bigHeap 的粉丝。我们的一个的应用程序，使用了 bigHeap 后，内存崩溃降到原来的 1/4。 Google 不鼓励使用它，因为它关闭了在后台的其他应用程序，因此应用程序之间的切换并不是那么好。但在某些时候，这不是你的问题。垃圾回收也需要更长时间，你可以使用它来屏蔽内存问题（你不应该这么做）。一般来说，bigHeap 是好的。如果你去 Play Store，并且搜索 largeHeap，你可以下载一个很酷的应用程序，它会显示你手机上启用了 bigHeap 的应用程序。你会注意到现在几乎每个人都陷入了困境，并且正在使用 bigHeap。</p>    <p>当你想到内存和图像时，这里有一个简单的公式。有些人会问，“这是个两千字节的 JPEG，为什么我的实际使用的内存会这么大呢？” 使用的内存是像素宽度乘以像素高度的四倍。这就是你期望的大小。它们的标准格式是 ARGB_8888 - 它用四个字节存储颜色空间。如果你使用 RGB_565，你可以将其减少到两倍。但是颜色彼此会非常相似，你会看到更少的色彩空间，它也不能做 alpha，但它会减少一半的内存使用量。你可以考虑在低端设备或低版本 API 上进行此操作。这是节省内存不足问题的好方法。</p>    <p>Fresco</p>    <p>非死book 发布了一个神奇的库，解决了 API 21 之前的所有版本的内存不足问题。在 API 21 之前，Android 系统中出现了一个错误，你可以在应用程序内存之外使用其他的内存。但是会带来些奇怪的情况：你的程序在旧设备上没有问题，但在新设备上会表现更糟。因为它加载的方式与其他库非常不同，所以它可以实现渐进式 JPEG 这样的图像，图像在图层中逐渐加载。但是，它们会更深入地耦合在你的应用程序中。借助 Glide 和 Picasso，你可以将其与你的应用隔离的很好。而不使用 imageViews，你必须使用它们的类型 Drawees，并且还会产生更多的孤岛代码。</p>    <p>如果你定位较低端的设备，你在旧设备上有更多的内存需求，我建议你使用 Fresco。除此之外，我会坚持 Picasso 和 Glide。</p>    <h3>内存 - 泄漏</h3>    <p>LeakCanary</p>    <p>LeakCanary 是当今内存泄露的神器，它可以帮助你找到内存泄露的地方。泄漏不是所有的内存问题，但是值得留意。当你将 LeakCanary 添加到应用程序中时，它会自动开始观察你的 activity 的内存泄漏。有一个我亲眼所见的误用是，他们将 LeakCanary 添加到应用程序中。修复一个或两个泄漏，然后就认为再没有更多的内存泄漏了。它只监视了 activity。如果你在这里使用这个代码（ <em>看幻灯片</em> ），你可以让它监视 fragment。这并不意味着你不会在别处泄漏内存。activity 和 fragment 是监测的好地方，但如果你没有将观察者设置为对象，你是不知道所有的泄露的。</p>    <p>简单来说，它的工作原理很酷。作为你引用的任何对象的弱引用：将其附加到你不再被引用的内容中。你把它放在 destroy 代码段。然后它做垃圾回收。如果对象仍然存在，这就是内存泄漏，所以它知道什么对象依旧存在。它给你那个 home fragment 现场的相关引用。我觉得这很难理解（*有些人认为这很简单，有人认为这很难。）</p>    <p>这里有个 view 的例子来做点简单说明（ <em>见幻灯片</em> ）。你从底部开始（这就是泄露的东西）。我有 home fragment。 它被 pin grid fragment 引用 - pin grid fragment 是这个对象的父亲。然后我们有这个奇怪的$ 0 - 它解释说，这是一个可运行的对象。对象内有一个处理程序包含一个 runnable。这段代码（这不是我的），它是 Android 操作系统的，是处理程序的代码。处理程序有个 runnalbe 正在运行。我需要确保处理程序不再保留 runnable。在这种情况下，我可以在视图的 destroy 中清除所有的 runnable 和处理程序，这将修复这个内存泄漏。</p>    <p>WeakHandler</p>    <p>你还可以使用这个随机工具 WeakHandler，这使得处理程序引用都是弱引用。如果你触发一个垃圾回收，就可以回收它们。它的缺点是可以被垃圾回收 - 如果你不希望它们被垃圾回收，那可能会出现意想不到的事情。值得注意的是，我遇到的大多数内存泄漏都是无效的，它通常是一个正在运行的 non-missed 的类持有外部类 <em>（这是最常见的地方）</em> 。对于你的内存泄漏，还需要一个 bug 分类的方法。没有什么比你手机上有 70 个内存泄漏， 而你不知道下一步该做什么更糟糕了。作为一个团队，弄清楚当我们发现内存泄漏时要做什么，总是一个好主意。</p>    <h3>UI</h3>    <p>我们都知道我们一直深陷泥潭。Activity 是旧标准。因为你想重用，所以有了 fragment。但是最后我们用 fragment 把 UI 显示做的异常复杂。试试另一种方法，基于视图的架构，它更流行。在基于视图的架构里，你有一个框架布局，而不用处理任何原生的 Android navigation 的东西，你可以用你想要的视图替换内部的框架布局里的任何东西。希望这能够解决 fragment 的复杂性。</p>    <p>fragment 已经被简化了，而且更新了版本，它们现在更加稳定，但是人们依旧争论着需要有基于视图的架构。如果我们遵循这个论点，我们应该看看一些库（图形的底部， <em>看幻灯片</em> ）。</p>    <h3>基于视图的架构</h3>    <p>这个架构是由 Mortar 和 Flow 引入的。我相信他们是第一批普及基于视图的架构的库。 Flow 真正地遵循了基于视图的架构，但是它们往往是一起的，而 Mortar 主要是 MVP 模式。当你开始实现基于视图的架构时，请注意这个奇怪的地方。</p>    <p>你还可以找到些更奇怪的地方，那就是如果你的应用是基于 View 的话，你会遇到些随机的问题，因为这个库不是基于 View 的。它是基于 activity 的， 如果你的应用是基于 view 的话，你得自己去解决那些问题。比如基于 View 的标准问题，例如 on-activity 的行为，许可等等。即使是后退按钮和导航，你都不得不自己去解决，只要你是基于 View 的。</p>    <p>Mortar 和 Flow完成基本的导航功能，但它们并不解决所有常见问题（例如屏幕上保存的状态）。</p>    <p>Conductor正是为这些基于 View 的视图而生的，它创建了一个解决方案：比如保存状态，转换等等。但是你仍然会遇到兼容性问题。总的来说，他们是非常好的，他们是架构不可知的，所以你可以采用你自己的 MV。</p>    <p>Scoop 来自 Lyft。他们在产品中使用它。它是经过产品测试的基于视图架构的解决方案。它们不保存状态，所以 Lyft 无法保存状态。在你将要使用基于视图的架构的主要常见问题中，这是最大的问题。切换很容易使用，但也很有限，这对于基于视图的体系结构来说有点令人失望，因为在这种架构下，你往往可以实现很好的切换。</p>    <p>总的来说，如果你不需要保存状态，Scoop 是可用的，最安全的产品。Conductor 也很好。我会推荐这两个库。</p>    <h3>模型 视图 表示（MVP）</h3>    <p>有几个很好的 MVP 的库。MVP 的基本思想是把逻辑代码分离出来，这样视图部分，Core Android 的东西，会放在一起，然后 presenter 也是分开的，我们可以单元测试这个 presenter。理论上，我们可以改变视图，而不必完全重写业务逻辑。</p>    <p>有很多方法来做 MVP。我推荐的第一个库是 <strong>Mosby</strong> 。即使你不使用 Mosby，他们也有很棒的教程和 Android 相关的文章（ <em>比如 MVP 应该是什么样的，它如何工作</em> ）。它主要能提供的功能是给你的 presenter 提供视图状态。</p>    <p>Nucleus也很类似。 <strong>Mortar</strong> ，作为 Mortar 和 Flow 的一部分，是它们早期的版本，它们越升级问题越多。我看到公司常常自己 <strong>构建 MVP</strong> ：在创建时，你将启动你的 presenter; 销毁时，你会停止你的 presenter 。每个 activity 或任何你的视图持有的任何东西都会有一个 presenter。</p>    <p>所有的这些权衡，虽然听起来很简单，当你实际操作一个用例时，有很多边缘案例要考虑。你有你的适配器，你的视图项目。确保每个人理解的都一样，并且找到能够运用 MVP 的地方是最难的部分。但是这样做的最终结果是你可以获得更多的可单元测试代码。你可以获得更稳定的代码。</p>    <h3>测试 - 性能</h3>    <p>NimbleDroid</p>    <p>我有一堆关于测试的内容，但我不想让你们听三个小时测试的东西，所以我们跳过使用 JUnit 4 进行单元测试。你有一个 Gradle 构建系统，有 Espresso。这些都是标配。性能测试是个非标的工具。</p>    <p>执行性能测试有两种主要的方法。 Google 倾向于主张使用 Systrace 类似的方法来查看丢帧率，他们有一个代码库，可以为你提供几乎能直接工作的代码（但不是很有效）。这允许你进行自动化性能测试，以查看丢帧率是否变化。</p>    <p>NimbleDroid 有一个免费的试用选项，你可以在其中上传 APK，它将自动测试冷启动，你也可以增加些应用程序中的关键流程。他们提供一个函数发生的时间序列图和详细信息。它可以免费进行试用（例如上传你的 APK 并获得冷启动时间，看是否有明显问题）。如果你想使用它来进行回归测试，那么它是很贵的，但它会帮助你意识到，有人做了一个改动，我们的启动时间变慢了，或者我们的关键流程慢了。如果性能是一个高优先级的目标，那么使用它是很有效的。</p>    <p>JSON</p>    <p>人们在考虑性能时往往都会想到 JSON。有很多的 JSON 库。我的第一个警告是：人们喜欢纯粹通过性能来看待 JSON 库。这是一个错误。我收到了我最大的请求（150千字节，30,000行，巨大的 JSON 文件）。我分别用 GSON 和 Jackson 解析了它们。它们相差大约 20 毫秒，对于那个巨大的文件来说，这并不疯狂。</p>    <p>我的第一个建议是：更多地关注易于使用的东西，有很好的文档的库。你希望得到支持。你不用花几个星期让开发人员尝试找出原因，就因为 stackoverflow 没有答案。除非你对性能有超高的要求，GSON 和 Jackson 是使用最多的，最受欢迎的，特别是在 Android 上，GSON 更受欢迎。</p>    <p>Moshi 是 Square 采用的库。它跟 GSON 非常相似。我试图就如何使用好 GSON 给出了一些意见。你可以同意或不同意这些观点，但都不会错。</p>    <p>如果你关心 JSON 解析性能，并希望它更快，LoganSquare 是一个很好的选择。它们在编译的时候完成了其他库需要在运行时完成的工作。与其他的库相比，这将使你节约大约 1/4 的时间，或四倍的性能提升。如果你真的关心 JSON 性能，你不应该使用 JSON。</p>    <p>相反，你可以使用 Flatbuffer。 JSON 人类可读，Flatbuffer 不是，但是因为这样，它丢掉了其他的不需要的负担。但是 Flatbuffer 与 JSON 相比，Falbuffer 解析几乎不花时间。非死book 做了这个转换。他们发现启动时间增加了 10％ 到 15％，启动时间有所改善。他们也观察到内存使用效率更高。但是使用起来比 JSON 更难，所以谨慎使用。</p>    <h3>数据库 - SQL</h3>    <p>对于数据库，我们知道常见的是 SQLite - 标准 Android 库。</p>    <p>SQLBrite 是 SQLite 上一个常见的简单库;它为你提供了数据库的 reactive 接口。你可以监听你的用户。如果你的用户有任何更改，你会收到通知，你可以随即更新用户界面。这是一个非常小的库。和 SQL 兼容的很干净。</p>    <p>SQLDelight 也来自 Square。他们写了很多库。它试图避免成为一个完整的 ORM，因为 ORM 会泄漏太多你的代码，并且往往迫使你做太多的事情，当然它仍然试图使数据库的工作更容易些。它使得 API 类型安全，使得 SQL 语句组织的很好（它尝试使其更容易些，同时不会太重）。</p>    <p>如果你愿意去做一个完整的 ORM，那么有很多很好的库：GreenDAO，OrmLite，DBFlow 是一些比较受欢迎的（ <em>还有许多其他选择</em> ）。他们都会说，它们在性能方便表现最好。每个库都有些图表，这些图表显示它们比其他的方案快 100 倍。我的建议是易用性是第一优先事项，然后再考虑是他们在性能上是不是会更好。</p>    <h3>数据库 - NoSQL</h3>    <p>Realm 是 NoSQL 的方法。它超级快。与其他可比较的数据库不同，Realm 支持的文档非常多。这可以最终节省你大量的开发时间，而且无所谓数据库类型。</p>    <p>Google 推荐的另一种 NoSQL 方法是 LevelDB。键值对，但是它可以说是 “你能够弄清楚该怎么做，但你必须自己弄清楚每一步”。 Realm db 可以帮助你避免这种情况。</p>    <p>Realm 数据库需要特别注意的地方是它的大小（ <em>我认为我们最初添加它时，我们的应用程序大小增加了一倍</em> ）。原因是它是一个本地库。对于每个芯片架构，它们在你的应用程序中都包含了 Realm 数据库的完整副本。为了避免这种情况，你可以将此代码放入 Gradle（ <em>参见幻灯片中的代码</em> ），并为每个架构生成一个单独的 APK。你把它分解成多少个版本，大小就会减少多少。这也会使你的内存节省很多。对于任何本地运行的 C++ 代码，这是正确的做法，所以在 Crashlytics 和其他一些受欢迎的库中，你能看到同样的收益。</p>    <p>还有另外一款很酷的 Google Play 商店的应用程序 Native Lib。 - 它在 Play 商店中，它会显示些本机库，以便你可以看到你是否为你的 APK 下载了不适用于你手机的代码库。这样做会减少内存使用。如果你就是在寻找手机上保存数据的方案，你可能希望在手机上存储数据。如果你正在构建一次性的应用程序，请不要保持数据。如果你正在使用 Realm 在存储量很小的手机上构建应用（为什么在这种情况下你的应用需要占用大量的存储）？但总的来说，这是一个非常好的数据库解决方案。</p>    <h3>数据库 - 移动平台</h3>    <p>另一个方面是移动平台：移动开发人员的梦想，我们不再需要这些服务器指南。我们也可以自己构建应用程序。以前的 Parse 是最好的例子（可能会安息）。</p>    <p>现在移动平台中最有名的就是 Firebase 和 Realm。它们都是 NoSQL 模型，它们有一些查询方面的挑战，但是构建速度非常非常快。非常适合进行同步更新。聊天是最常见的解决方案，你发送聊天消息，突然所有的手机都能获取更新。不必构建数据库，不必拥有服务器，你可以使用其中一个解决方案。它使得构建过程非常迅速，马上完成应用并推向市场。而且性能也特别好。</p>    <p>Realm 与 Firebase 的区别是它有离线优先的优点。它们都可以脱机，但是 Firebase 是事后补救，而 Realm 是事先就设计好了，Realm 在许多方面都支持离线。许多应用程序几乎不需要在线行为。如果你正在考虑运行应用跟踪程序，我们希望同步我们的运行状态，而且我们希望所有功能都能完全脱机运行，之后在线工作也正常。Realm 就会脱颖而出。</p>    <h3>Analytics</h3>    <p>我喜欢分析。精益创业的说法是。如果你可以测量它，你就可以优化它。如果你没有数字的东西，一切都是随机的，你只能猜想如何使它更好。我喜欢有详细的分析，来了解这个改变是否使事情变得更好？人们是否使用此功能？如何改善它？</p>    <p>Analytics 是封装第三方库的理想选择。如果你封装好了 Analytics，那么你应该能够在不修改任何功能代码的前提下，完全替代你的分析服务。你应该能够很容易地添加一个新的 Analytics 服务，以便它们能同时工作。封装 Analytics 代码是一个很好的实践。</p>    <p>如果你正在添加分析数据，最简单的方法是记录你的屏幕，记录人们浏览过的屏幕，将其放在抽象的 activity 中。这样会很快地获得很多的价值。</p>    <p>我看到人们使用 Analytics 技术的常见错误是增加了太多的 Analytics 。他们会在任何地方添加一千个事件，然后没有人知道这个分析意味着什么。他们没有进行充分的测试，所以你真实的注册只有注册的 2/3。在添加分析时需要非常小心。尝试使用简单的命名和标准。不要使用分析来延迟轻松的决定。如果有一个容易的决定，那么请开始。如果你的分析结果告诉你“人们不喜欢释放内存”，那先假设你的分析是错误的。得出一个错误的结论是很容易的。如果你有一个很重要的结论，首先要做的是确认你的分析代码方面没有什么疯狂的事情。</p>    <h3>Firebase</h3>    <p>Firebase 曾经是一个实时数据库，然后 Google（混淆我们）开始使用一大堆叫做 Firebase 的工具。Firebase Analytics 是所有 Firebase 工具的基础。Google 意识到 iOS 和 Android 开发人员正在解决同样的问题。他们正在使用第三方服务并且通过付费来解决所有这些问题。他们认为，我们可以使构建应用程序更加容易，而且构建应用程序更容易，赚的钱就更多。他们做了这些工具的竞品。迫使它们更好用，谷歌试图使分析工具成为所有的工具的基础。这样做的愿景是，如果你收到崩溃报告，看到你的分析数据，你可以按照崩溃的投资回报率给它们排序。你的通知系统也参与其中，你可以发送通知给那些碰到最昂贵的崩溃的客户，并告诉他们一些免费的折扣。我们知道你即将购买，因为你是一个高价值的崩溃。</p>    <p>这是个很酷的愿景。还没有实现，实话实说。有些工作正常，有些还在开发中，这不是谷歌最高的优先级的任务。但是很多工具还是很好的（不如竞争对手的工具）。 Analytics 虽然是免费的。但是事件不受限制。没有太多的理由不使用它。</p>    <p>另一个流行的是 Google Analytics（分析）。它很容易地获得许多关于用户的基本信息。这是我看到的唯一一个提供很酷的行为流程图的工具，在那里你可以看到人们在你的事件之间切换。它还是有点过时了，其记录事件的风格比所有其他分析工具更旧。它也是免费的，Firebase 意在替换它。</p>    <h3>A / B 测试</h3>    <p>我个人认为 A / B 测试被过度宣传。通常它被用于慢速学习，以便你了解的更清楚，如果是简单的命名规则就不适用了，当然你可以将其投放到用户手里，你会发现，100 个用户的样本中，55％ 偏好了这一选择。这就是你通常看到的 A / B 测试。</p>    <p>它很容易产生 Bug。基本上，A / B 测试中应用程序版本数是你应用程序中的 A / B 测试数加 2。如果你的应用程序中有 3 个 A / B 测试，那么就有 8 个不同版本应用程序一起工作。你可能没有测试各种不同版本的应用程序。有时候你可能会发现因为这些问题，往往会导致重要的决定不太容易做了。</p>    <p>我的解决方案是用户分析服务。 Mixpanel 具有非常好的 A / B 测试工具，而且和你的分析工具兼容。有许多工具用于 A / B 测试。我想说最有名的是 Optimizely 和 Apptomize。Optimizely 更适合网页（ <em>他们的价格</em> 都有点神秘）。他们帮助你提供不同的版本，告诉你这是一个比另一个有显著的更好的统计学差异的版本。</p>    <p>Firebase Remote Config 在技术上可以用来进行 A / B 测试。它不是用于 A / B 测试的。它是用来在不需要开发人员的更新的情况下，从服务器发送键值对的，但是这能让我们做 A / B 测试。你可以发送两个不同版本的键值对，然后你可以使用代码来决定要做什么。之后，你可以将其传递到你自己的分析界面，并找出解析它的方法。从某个角度说，如果你使用 Firebase 远程配置，你是在创造轮子。</p>    <p>你也可以使用 A / B 测试商店列表。这是值得尝试的，特别是你在不同的国家里测试。这是比较容易的，你可以在那里获得一些收获。</p>    <h3>崩溃报告</h3>    <p>像分析一样，有一千个解决方案。 <em>我只打算介绍少数几个</em></p>    <p>人们首先看到，特别是 Android 新手，那就是 Play 商店。每当你遇到崩溃时，你可以选择发送报告。大家都会直接忽略，大约 1％ 的崩溃出现在 Play 商店中。有时候，如果你的用户数非常大，而且有些非常神秘的崩溃，那可能值得去看看，因为人们会对发生的事情发表评论。也就是说，你有 1％ 的崩溃; “99％ 的人说应用很烂，崩溃”。但是每隔一段时间，就会有这样的评论 “我在手机上旋转了屏幕，它崩溃了”（ <em>你好像是，啊，一个开发者，我很感激</em> ）</p>    <p>Crashlytics 趋势是最受欢迎的。这是 推ter 的 Fabric Suite 或者说是现在的 Google Fabric Suite 的一部分。它是免费的，并为你提供一个非常好的，高级的，有组织的崩溃视图。你仍然需要自行排序和确定优先级。它有一些问题，很难搜索和查询。我看到人们联合使用 Bugsnag，这样查询和搜索会更好一点。 Bugsnag 是相当不错的，但它不是免费的。</p>    <p>Instabug 和 Telescope。Telescope 是个库。你把它放到 bug 里，作为第三方服务。这些库的优点不是监控 crash，而是让你在问题出现时，摇晃手机来报告问题。这样，当你的团队中的设计师看到错误时，他们不用在 JIRA 里提交 Bug，或者和别人说明所有的步骤然后让别人来报 bug，但是你仍然希望这些不是 crash 的 bug 也能被修复。有这么一个工具，所有的测试用户，alpha 用户，你公司的人，看到错误都能告诉你，这些问题需要修复。</p>    <h3>推送通知</h3>    <p>作为开发人员，第一反应是使用 GCM 或现在的 Firebase Cloud Messaging，这些库正在重组。但是这些工具对营销人员不友好。最简单的情况是，如果你已经有了很好的分析服务，Firebase 和 Mixpanel（以及其他许多库）都可以用来发送通知。你可以根据你的 activity 发送消息。可以这样设计，一个从来没有发生过购买的人，做了三次搜索，这时你可以给他们发送一个通知，建议他们买些东西。这是最简单的情况。</p>    <p>有时你会想要一些更深入的东西。Urban Airship 的推送通知特别专业，这是他们的主要方向。他们发现，“人们只会看到通知的前 60 个字符”，我们都会收到这样的通知，你只能看到前面几个字。就像，“你不会相信这个…”，它被截断了。然后你点击它，你被带到一个随机的屏幕里，你甚至不知道推送通知的内容是什么。Urban Airship 很好，他们帮助你思考这样的事情，给你更多的细微差别提示，思考如何能更好地推出通知服务。</p>    <p>Kahuna 很受欢迎，有很多人都在使用它，但我会强烈反对。他们的想法很棒。通过借助 AI 来帮你确定哪种推送方式更合适，是发送电子邮件，还是发送短信或者是推送通知。AI 计算出最好的推送时间，并建议通知上需不需要添加花朵。这部分他们还没有实现。但他们现在会做些文字上的变化。他们试图让通知受人喜爱，尽可能地推送最合适的通知，想法很酷，希望它能很快实现。但是现在，现实实现中，他们遇到了很多问题，用户的通知被发送给错误的用户。用户被合并在一起，视为一组。所以使用时请小心。有些人用的很好。但我被坑了。</p>    <h3>更轻松</h3>    <p>有很多伟大的工具能使你的开发更容易些。</p>    <p>一个工具是 Butter Knife（@indVView）。它使你的代码更漂亮。你可以使用 @BindView 通过 ID 查找视图，而不必遍历所有的视图。Zelezny，是一个Android Studio 插件。把它放进 Layout 中，它会自动生成 BindViews 和 OnClicks。如果你以前一直是手敲代码，它会节省点时间。最大的限制是 annotation 的处理会破坏增量编译。如果你有 Butter Knife，那么你可能会比没有 Butter Knife 时的增量编译慢些。对我个人而言，我喜欢所有的 annotation 处理工具，船已航行。我已经接受了 annotation 处理器打破我的增量编译的现实。我听说有人建议将它们全部放在同一个模块中可以解决这个问题。这是唯一的缺点，许多 annotation 处理都会有这个问题。也许有一天这个问题会被修复。 JRebel 声称一些特定版本的增量编译已经修复了。除此之外，Butter Knife 是最好的选择。</p>    <p>Hugo 是个 Jake Wharton 的库（* 当我说 Jake Wharton，一半的时候是指 Square，它们是同一个意思*）。它是一个轻量级的库，你可以在方法之上执行 @Debug.Log，然后打印出该方法花费的时间，以及参数。它特别适用于现场性能记录。 “我需要缓存这个变量吗？它被调用太多了以至于变慢了吗？”你可以看到，“不，这只花了 10 毫秒，我应该把它放在一个后台线程上，或者花了不到一毫秒，我们不用担心这个”。它很容易纳入你的代码，并迅速获得相关数字。</p>    <p>Dart ＆ Henson，你有 intents ;不需要使用键值映射，它给你应该有的值。它做了点 annotation 的映射来展示 intents 的值是什么。我更喜欢的另外一种理解方法是你正在调用的 activity 的静态 intents 。这样，你可以传入你想要的参数，这样就解决了神秘的键值对的问题。它使得代码更加紧密，这样可以防止错误。</p>    <p>如果你喜欢 lambdas，你应该使用 Retrolambda。需要注意是它产生四种方法，而不是正常的匿名类。我认为使用 Retrolambda 会使得代码不易读，这是你必须做出明智决定的地方。</p>    <h3>更困难（初期）</h3>    <p>我们来谈一谈哪些库会让开发变得更加困难，或者说开始的时候更困难。但总的来说，这些都是好工具。</p>    <p>RxJava</p>    <p>RxJava，对于那些没有听说过的人来说，这个库的想法是，过去的代码从 A 点开始，到 B 点结束。但在 Android 世界中，移动开发世界中，这一切就都不一样了。 *你从 A 点开始。然后人们点击某些东西，所以你必须做些别的事情来响应。然后一个通知进来，你必须又做些事情。然后数据库请求出现了。Reactive 努力使你的代码能够对你的应用程序中的发生的事情做出反应，帮助你更好的组织它们，而且方便移动。</p>    <p>起初很难，因为它有一个学习曲线。如果你正在看代码，特别是对于没有接触过 RxJava 的人来说，会有许多不清楚的地方。最简单的就是网络。但是，如果你有几个标准的例子，你使用这些案例，并确保是最佳的做法，情况就会不一样了。当你开始拥有这些功能时，它们非常强大，你可以将其运用于应用程序中的任何地方，但是当你这样做的时候，每当雇用新的开发人员，你将不得不教会他们每个 activity 是怎么工作的，这需要很小心。</p>    <p>此外，它很容易用错。即使是关于 RxJava 的许多会议都会漏掉一些最佳做法。例如，如果你不取消订阅网络呼叫，那么你会被回调，这时可能会发生崩溃，因为屏幕已经不存在了。谨慎地使用它，总体上来说它还是很好的。</p>    <p>Kotlin</p>    <p>当我说小心使用非内建语言或者说新语言不寻常的地方时，我想说的就是那些你能看到的不寻常的地方。 Kotlin 生成了更整洁的代码。这有好处。使你的代码更容易阅读，也会使没有意义的东西少一些，这是你需要的核心东西。它也隐藏了指针的概念。</p>    <p>最大的缺点是它会随机地破坏事情，如果有什么事情发生，你都会怀疑 Kotlin。这可能是 Kotlin 的错，可能不是，但是都会花掉开发人员的许多时间，来弄清楚到底是不是 Kotlin 的错。你需要更新 Gradle 的构建，然而这依旧不奏效。这可能是 Kotlin 的错，也可能不是 Kotlin 的错，但是你都不得不重新检查 Kotlin。</p>    <p>同样的情况是，你的 Android Studio 也会随机崩溃，或者 ProGuard 不工作了，因为它去掉了一些 Kotlin 的类。这些事情经常发生，很难扭转。Kotlin 有很多权衡点。我们在代码中使用它。确实有一些问题，与此同时，了解 Kotlin 的人们的代码审查更快。对于不知道 Kotlin 的人来说，有一个学习的曲线。这是一个权衡。你必须自己决定。</p>    <h3>相机</h3>    <p>如果你曾经在 Android 中使用过 Camera，而且你采用的是原生的方案，这并不疯狂，你会发现有摄像头 one API 和摄像头 two API，而且摄像头 two API 没有比摄像头 one API 更好，如果你同时支持新旧设备，你必须使用摄像头 one API，除非你只打算在非常新的设备上正常运行。我的第一个建议是，如果你有使用相机的场景，构建一个 intent。让其他人的相机应用来解决你的问题，如果这不是你的核心场景的话。</p>    <p>如果不是这种情况，有一个名为 Material Camera 的库，我以前 fork 过。你可以添加自己的外观。它帮助你创建相机。解决问题。但是当你按照本教程进行首次设置后，横向显示时，图片会颠倒，你不得不在每个手机上都进行测试，因为他们会以不同的方式安装相机。还有很多边界案例要考虑。Material Camera 是伟大的，它已经把这些情况都解决了。它也支持视频。这是视频模式。你可以改变它上面的 UI，效果很好。再说一次，如果 Camera 是你非常核心的用例，那么你应该重新构建它，这只是个折衷的方案。</p>    <p>我使用的每个相机应用都有裁剪功能，这个功能很可怕。我不知道是什么原因。你试图剪裁，突然间你的视频被剪掉了中间部分。有一个很好的库叫做 “Android Crop”。它提供了一个非常简单的新的 activity 来完成剪裁。</p>    <h3>全球思考</h3>    <p>作为 Android 的开发人员，我们需要考虑到世界各地的所有开发者。如果你正在为世界各地的开发人员做些开发工作，有些事情你必须考虑，比如网络仿真：你希望能够在低质量网络上进行测试。Android 上做到这点比 iOS 难。仿真器技术可以提供本地仿真器 AVD，但通常情况下，我的经验是，如果你在模拟器上进行任何 3G 操作，没有应用工作正常。我的一些应用程序有时候能在 3G 上正常工作。</p>    <p>我知道的最成功的工具是 Charles 代理。你可以配置经过某个代理。这很容易设置。你可以告诉代理，下载速度应该是多快。但仍然有一个挑战，你需要知道网络可能有多快。比如说像巴西的 3G 网络，几乎是一个无意义的声明 - 3G 在巴西各处都不一样，在各地都是非常不同的。某些时候，你必须尝试找一些数字，选择一些数字。</p>    <p>外面有些资源，但是选择参数是挑选网络仿真最困难的部分之一。有一个名为 Augmented Traffic Control 工具，它来自 非死book。它允许你连接到服务器或设置路由器，你可以设置配置文件 - 当你连接到路由器时，你的互联网应该有多快。如果你有非开发人员为你测试，他们仍然可以连接到这个 WiFi 网络并设置他们拥有的连接级别。产品经理和测试人员一般也应该考虑质量较差的网络。 ATC 服务器很好用。</p>    <p>我相信新的 Android O 暗示他们会有类似于 AutoFitTextView 的东西，但现在这只是一个库，只要文本对于文本框来说太大，文本就会缩小。如果你正在翻译德语，它的很多字母比英文还是要大一些，那么它会把它缩小到框中。这不是你的第一个翻译解决方案，但最好让它们缩小到文本框的大小，而不是填满整个屏幕并覆盖所有内容。它将调整你的文本大小（更改你的文本大小来适应），这是一个很好的安全的翻译。</p>    <p>YearClass 是 非死book 的另一个库。它会告诉你，运行你产品的最新的手机生产年份是多少。如果我们说 2015 年是最高的年份，那你就不用关心 2016 年制作的手机上的一些特别的事情。从分析角度来说，这是最好的 - 比如这个崩溃是，发生在 Android OS Marshmallow 上，所有的手机都是低功耗的手机，有时候会发生这种情况。知道一下 crash 在不同年份的手机上的发生概率可以帮你对这个 crash 有更深的了解。</p>    <p>Connection 类是理解用户连接质量的一个非常好的工具（* 这是我在开始时推荐的封装样本类）。它对网络进行分类。不是分成 4G 3G，因为它们变化很大，它依据的是带宽，分为优秀，好，中度或差，或未知。它通过采样下载速度来分类。然后它会移动平均值。这样做的价值是，例如，你是一个显示许多图像的图像网站，你可能希望在较差的网络上降低图像质量，或着执行其他操作。预先知道带宽可以做许多事情。</p>    <p>最大的警告是它的抽样可能是不合时宜的。你能做的事情是让它们开始采样和停止采样。比如，当我打开应用程序时，开始采样，当我关闭应用程序时停止。它们做的事情是查看你下载的数据量，每秒刷新一次。如果用户将你的应用程序打开，并且没有进行任何操作，他们会认为你的网络慢的可怕。我们所做的是，你可以在网络调用或者图像调用的中间启动它，这样做的效果很好。除此之外，这个库对你的网络带宽了解的很准确。</p>    <p>About the content</p>    <p>This content has been published here with the express permission of the author.</p>    <p> </p>    <p> </p>    <p>来自：https://academy.realm.io/cn/posts/tools-and-libraries-for-common-android-problems/</p>    <p> </p>