Tag: 完美应用

Swift中的内存泄漏

在本文中，我们将讨论内存泄漏，并将学习如何使用单元测试来检测它们。 偷看一下： 这是用SpecLeaks编写的测试。 重要：我将解释什么是内存泄漏，讨论保留周期以及您可能已经知道的其他事情。 如果您只想阅读有关单元测试泄漏的信息，请跳至最后一部分。 内存泄漏 确实，这是我们作为开发人员面临的最常见的问题之一。 我们会逐个功能地编写代码，并且随着应用的增长，我们会引入漏洞。 内存泄漏是内存中永远被占用且永远不会再使用的一部分。 这是占用空间并导致问题的垃圾。 在某个时刻已分配但从未释放过并且不再被您的应用程序引用的内存。 由于没有对其的引用，因此现在无法释放它，并且该内存无法再次使用。 苹果文件 从初级到高级开发人员，我们都会在某个时候造成漏洞。 我们有多经验都没关系。 拥有一个干净，无崩溃的应用程序，消除它们是至关重要的。 为什么？ 因为它们很危险。 泄漏很危险 它们不仅增加了应用程序的内存占用 ，而且还引入了有害的副作用和崩溃。 为什么内存占用量会增加？ 这是对象未释放的直接结果。 这些对象实际上是垃圾。 随着创建这些对象的动作的重复，占用的内存将增加。 垃圾太多了！ 这可能会导致出现内存警告情况，最终，该应用程序将崩溃。 解释不必要的副作用需要更多细节。 想象一下在init内创建通知时开始监听的对象。 它对此做出反应，将内容保存到数据库，播放视频或将事件发布到分析引擎。 由于需要平衡对象，因此我们在释放对象时在deinit内停止监听通知。 如果此类物体泄漏，会发生什么？ 它永远不会死，也永远不会停止收听通知。 每次发布通知时，对象都会对此做出反应。 如果用户重复创建有问题的对象的操作，则将存在多个实例。 所有这些实例都响应该通知并相互介入。 在这种情况下， 崩溃可能是最好的事情。 多个泄漏的对象对应用程序通知做出反应，更改了数据库，UI，破坏了应用程序的整个状态。 您可以在The Pragmatic Programmer中的“死程序不说谎”中了解有关此类问题的重要性。 泄漏无疑会导致不良的用户体验和不良的App Store评分。 泄漏来自哪里？ 例如，泄漏可能来自第三方SDK或框架。 甚至来自Apple创建的类，例如CALayer或UILabel 。 在这些情况下，除了等待更新或放弃SDK之外，我们无能为力。 但是我们很有可能在 我们的代码。 泄漏的 首要 原因是 保持周期 […]

为什么我使用Texture构建我的应用程序（以及为什么也应该如此）

我已经在我的应用程序中使用了很长一段时间（Facebook，Pinterest和Buffer等巨头也使用过Texture）。 这是一个基于UIKit构建的iOS框架，即使最复杂的用户界面也可以保持平滑和响应。 在本教程中，我想分享我在Texture方面的经验以及所有有关如何充分利用此工具的有用技巧。 我们将一起在Texture中实现几个接口，并查看其实际工作方式。 起源 当他们构建Facebook Paper应用程序时，纹理起源于Facebook内部。 作为该项目的首席工程师之一，斯科特·古德森（Scott Goodson）最初从事第一批iPhone构建应用，例如计算器，股票，时钟等。 在理想的世界中，我们希望药丸可以增加数量而无需求助于近似值（例如在指标中显示999+）。 同时，我们希望支持诸如动态类型之类的辅助功能。 解决此问题的最明显方法是使用水平UIStackView并将标签和药丸保留在堆栈中。 不过有一个问题！ 在这种情况下， UIStackView 。此外，您还必须设置contentHuggingPriority和contentCompressionResistance并使用其他属性（在读完这句话之后，我需要喝杯咖啡）。 摆弄所有这些属性并弄清楚它们将很容易使我花费一个下午的时间。 相比之下，让我们看一下Texture的实现： 另外，Texture在`ASTableNode`上有一个很好的`inverted`属性，对于聊天/消息应用程序来说真的很方便。 基本上可以确保单元格是反向的，因此它们从底部开始！