13518219792
这期内容当中小编将会给大家带来有关Android应用中出现内存泄漏的原因有哪些，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名注册、雅安服务器托管、营销软件、网站建设、南漳网站维护、网站推广。OutOfMemoryException是一个常见的令人沮丧的错误，也是导致应用程序意外关闭的主要原因之一。
“如果应用程序昨天运行良好，为什么现在会发生这种情况？这个问题让Android的开发者和新手都感到困惑。
导致OutOfMemory异常的潜在原因有很多种，但其中最常见的是内存泄漏—应用程序中的内存分配从未释放。本文将解释如何通过有效的生命周期管理（开发过程中一个重要但经常被忽视的部分）来最小化这种风险。
问题很简单。某些对象应该只有一个固定的寿命，当它们的使用寿命结束时，它们需要被删除。
理论上，当进程使用onStop或onDestroy终止时，应该处理该内存。但是，滥用对象引用可能会阻止垃圾收集器释放未使用的对象。例如：如果未使用的对象A引用了未使用的对象B，那么您将得到两个不必要的对象，垃圾回收器将永远不会释放它们，因为它们正在相互引用。
开发人员可以采取许多步骤来阻止死的活动被困在内存中。
在onResume（）/onPause（）或onStart（）/onStop（）中注册/注销广播接收器
不要对视图/活动/上下文使用静态变量
需要保存对上下文的引用的singleton应该使用applicationContext（）或将其包装到WeakReference中
注意匿名和非静态内部类，因为它们包含对其封闭类的隐式引用。
如果要比父类（如处理程序）更长寿，请使用静态内部类而不是匿名类。
如果内部或匿名类是可取消的（如AsyncTask、Thread、RxSubscriptions），则在销毁活动时取消它。
一旦你完成了上面的基本步骤，现在是时候做一些更重要的事情了：应用程序活动的生命周期。如果我们不能正确地管理生命周期，我们最终会在不再需要内存的时候挂掉它。
这涉及到许多不同的任务。对于每个活动，我们需要中断线程，去掉RxJava中的订阅，取消AsyncTask引用，并确保正确删除该活动的引用（以及与之相关的任何其他活动）。所有这些任务都会消耗开发人员的大量时间。
模型视图呈现器（MVP）使事情变得更加复杂，MVP是Android中构建用户界面的常用架构模式。然而，MVP对于从视图中分离业务逻辑非常有用。
在MVP模式中，View和Presenter都是它们之间行为契约的抽象实现。实现MVP最常见的方法是使用活动/片段作为视图的实现，并为习惯于引用视图的演示者使用简单的实现。
所以我们最终得到了一个带有Presenter引用的视图和一个带有视图引用的Presenter（提示：这里有一个潜在的漏洞）。
考虑到这些潜在的困难，我们有必要建立一个适当的管理结构来移除在生命周期中创建的多余内存。有几种行之有效的方法可以做到这一点：
生命周期感知组件是智能的。例如，它们可以通过除去内存来对另一个组件（如活动或片段）的生命周期状态的更改作出反应。这意味着代码更轻，内存效率更高。
archlifecycle是Android的一个新库，它提供了一组工具来构建支持生命周期的组件。库以抽象的方式工作，这意味着生命周期所有者不再需要担心管理特定任务和活动的生命周期。
Arch生命周期的关键工具和定义如下：
生命周期：一个排序系统，它定义了哪些对象具有Android生命周期，并允许对它们进行监视。
LifecycleObserver：一个常规接口，它监视每个被标识为具有Android生命周期的对象，使用一个简单的公式来处理每个密钥生命周期事件。
@OnLifecycleEvent：可以在实现LifecycleObserver接口的类中使用的注释。它允许我们设置关键生命周期事件，这些事件将在每次启动时触发带注释的方法。以下是可设置的所有事件的列表：ON_ANY、ON_CREATE、ON_DESTROY、ON_PAUSE、ON_RESUME、ON_START、ON_STOP
LifecycleOwner默认为每个可以管理其生命周期的Android组件实现，并让开发人员控制每个事件。
使用这些工具，我们可以将所有干净的任务发送给它们的所有者（在我们的例子中是演示者），这样我们就有了一个干净的、无泄漏的解耦代码（至少在演示者层是这样）。
下面是一个超级基本的实现，向您展示我们所说的：
interface View: MVPView, LifecycleOwner class RandomPresenter : Presenter, LifecycleObserver { private lateinit var view: View override fun attachView(view: View) { this.view = view view.lifecycle.addObserver(this) } @OnLifecycleEvent(Lifecycle.Event.On_DESTROY) fun onClear() { //TODO: clean }
另一种方法是通过使用新的生命周期组件来避免视图模型的内存泄漏。
ViewModel是一个抽象类，它实现一个称为onClear的函数，当必须删除某个特定对象时，该函数会自动调用。ViewModel是由框架生成的，它附加到创建者的生命周期中（作为一个额外的好处，使用Dagger注入非常容易）
除了使用ViewModel，LiveData还提供了一个重要的通信渠道。这意味着创造了一个容易观察到的反应性产物。
这里最重要的一点是，生命周期所有者可以观察到LiveData，因此数据传输总是由生命周期管理的，而且我们可以确保在使用它们时保留任何引用。
除了上述步骤之外，我们还想推荐两个重要的工具包：LeakCanary，一个用于监视泄漏的流行工具，以及我们自己的Bugfender。
LeakCanary是一个用于Android和Java的内存检测库。它是开源的，所以有一个庞大的社区支持它，它不仅仅告诉你一个漏洞，它还告诉你可能的原因。
我们的远程日志工具Bugfender允许您调试单个泄漏跟踪，并扩展一个名为DisplayLeakService的类，它让我们知道何时发生泄漏。然后我们就可以用Bugfender轻松登录了。
public class LeakUploadService extends DisplayLeakService {
override fun afterDefaultHandling(heapDump: HeapDump, result: AnalysisResult, leakInfo: String) {
if (result.leakFound) {
Bugfender.d(“LeakCanary”, result.toString())
}
}
}此外，用户还可以获得Bugfender的所有其他好处，包括全天候记录日志（即使设备离线）、内置故障报告和易于使用的web控制台。
上述就是小编为大家分享的Android应用中出现内存泄漏的原因有哪些了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
