实战Hybird app：内存溢出与优化_.NET

您所在的位置：程序员俱乐部 > 编程开发 > .NET > 实战Hybird app：内存溢出与优化

实战Hybird app：内存溢出与优化

2013/11/4 12:35:44 Aaron. 博客园我要评论(0)

摘要：pheongap项目：http://www.nduoa.com/apk/detail/646816主要的问题：heap过大，内存低性能差的机子上引起奔溃，直接退出关于webapp的优化，不仅仅只是js方面，包括HTML布局嵌套，CSS的属性使用，数据的读取，还有浏览器的重排与回流之类的这里就不讨论了，本章涉及的是脚本代码引发的性能问题，更进一步说就是闭包带来的内存泄露关于性能：首先我不得不承认一个事实，移动端的性能跟PC端，那完全不是一回事比如用innerHTML绘制大段的HTML结构
标签：优化 APP 内存

pheongap项目：http://www.nduoa.com/apk/detail/646816

主要的问题：

heap过大，内存低性能差的机子上引起奔溃，直接退出

关于web app的优化，不仅仅只是js方面，包括HTML布局嵌套，CSS的属性使用，数据的读取，还有浏览器的重排与回流之类的这里就不讨论了，

本章涉及的是脚本代码引发的性能问题，更进一步说就是闭包带来的内存泄露

关于性能：

首先我不得不承认一个事实，移动端的性能跟PC端，那完全不是一回事

比如用innerHTML绘制大段的HTML结构，之后同步获取生成HTML中的ID节点，结果不存在

这种问题在单页面模拟多页面，动态创建DOM的时候，尤为明显

var element   = $('<div id = "aaron">...填充大量结构...</div>');

$(root).html(element)

$('#aaron')  //为空

这个是很简单的一段代码，按照常规的认识，JS主线程与GUI的渲染线程是互斥的，所以在执行JS的时候，GUI应该就是挂起的，同理执行GUI的时候亦然，因为JS可以动态操作节点，所以如果我们在GUI绘制的时候做操作明显就会打乱了，所以互斥的解释也合理
但是实际上这样并不能直接获取到$('#aaron')，PC上基本不会出现，常规的办法都是加setTimeout
实际上由于setTimeout的机制，所以也是不准确的，当然我已经有一个比较完美的方式解决

关于JavaScript内存管理：

原文：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management

JavaScript会给开发者一个错觉：可以不用考虑内存管理

现代浏览器已经够聪明了，从2012年起，所有现代浏览器都使用了标记-清除垃圾回收算法。所有对JavaScript垃圾回收算法的改进都是基于标记-清除算法的改进，并没有改进标记-清除算法本身和它对“对象是否不再需要”的简化定义。

所以引用计数收集与循环引用之类的都不再是问题了,过去导致内存泄漏的许多经典模式在现代浏览器中以不再导致泄漏内存。

但是，如今有一种不同的趋势影响着内存泄漏。许多人正设计用于在没有硬页面刷新的单页中运行的 Web 应用程序。在那样的单页中，从应用程序的一个状态到另一个状态时，很容易保留不再需要或不相关的内存。

典型的就是： 单页面模拟多页面的行为

简单的内存管理测试

视图：

HTML结构:

<button id="start_button">Start</button>
<button id="destroy_button">Destroy</button>

脚本代码：

var Leaker = function() {
    this.name = 'aaron'
};

$("#start_button").click(function(){
 leak = new Leaker();
});

$("#destroy_button").click(function(){
  leak = null;
});

点击Start 产生一个对象leak = new Leaker();

点击Destroy 销毁这个对象观察下内存中变化（工具后面会提到）

点击Start ,产生一个对象

点击Destroy,对象销毁

那么这个图很形象的说明了，#Delata释放了一个实例,就是内存被回收了

如果不做任何处理,那么这个对象leak始终最存在整个生命周期内(全局上下文的情况)

如果leak = null,内存确实是由浏览器GC 自动给回收了

闭包引起的内存泄漏：

代码：内部增加了一个定时器，递归调用

var count = 0;

var Leaker = function(){};

Leaker.prototype = {
    init:function(){
        this._interval = null;
        this.start();
    },

    start: function(){
        var self = this; //递归调用自身
        this._interval = setInterval(function(){
            self.onInterval();
        }, 100);
    },

    destroy: function(){
        if(this._interval !== null){
            clearInterval(this._interval);
        }
    },

    onInterval: function(){
        count++;
        console.log("Interval",count);
    }
};

从样的观察

我在按了销毁，leak = null了

可见代码依然还在走，可见此时内存绝对的溢出了，也就是失控了

但是监视器显示该对象回收了

那么这个问题就很明显了，通过leak = null 销毁的只是引用，内部如果还存在引用的话，这个heap是不会被回收的

此时这个内存我们已经管理不到了，会一直递归下去

要解决只能在销毁的时候先停止定时器了

由此可见，引用不仅仅只是外部的，内部同样存在这样的问题，当然引用类型的机制本来就是这样的

所以在日常的代码编写方面，JS的坑确实不少，接下来看看我项目中的大坑吧！！！

应用截图：

$9_T`B{QZZKGCVJHU@0E[]S2$

内存使用检测：

Eclipse

Eclipse不熟悉的路过，我们还是回到前端的角度去处理

使用Chrome DevTools的Timeline和Profiles提高Web应用程序的性能

具体的使用就不介绍了，大家接着看

抓怕的heap快照，实时反馈的信息

系统的闭包数

加上JQuery

项目中的

视图解释

列字段解释：

Constructor -- 构造器

Distance -- 估计是对象到根的引用层级距离

Objects Count -- 给出了当前有多少个该类的对象

Shallow Size -- 对象所占内存（不包含内部引用的其它对象所占的内存）(单位：字节)

Retained Size -- 对象所占总内存（包含内部引用的其它对象所占的内存）(单位：字节)

小伙伴都吓呆了

项目中除去系统与一些插件的，至少有上千个闭包

分析堆快照

Object's retaining tree视图显示出了该对象被哪些对象引用了，以及这个引用的名称

关于XUTUTIL.Event类

XUTUTIL.Event是一个构函数函数,主要就是一个订阅/发布模式

那么这个图我的理解就是通过XUTUTIL构造生成的的对象都应该是放到这个里面，所以

根据分析图显示，这个类有208个对象，被实例了208次,也就是说存在这么多订阅者了

XUTUTIL部分源码（观察者模式）

class="cnblogs_code_Collapse">XUTUTIL.Event//=================自定义事件===================
//  
//  所有组件的最顶层类
//  
//  一个抽象基类
//  为事件机制的管理提供一个公共接口
//  子类应有一个"events"属性来定义所有的事件。
//
//==============================================
(function () {

    var XUTUTIL = Xut.util,
        EACH  = Xut.each,
        TRUE  = true,
        FALSE = false;

    XUTUTIL.Observable = function () {
        var me = this, e = me.events;
        if (me.listeners) {
            me.on(me.listeners);
            delete me.listeners;
        }
        me.events = e || {};
    };

    /**
     *  1 数据保护
     *  2 事件冒泡
     *  3 事件挂起
     * @type {Object}
     */
    XUTUTIL.Observable.prototype = {
        /**
         * 加入一个事件处理函数
         * @param {String}   事件处理函数的名称
         * @param {Function} 事件处理函数
         * @param {Object}  （可选的） 事件处理函数执行时所在的作用域。处理函数“this”的上下文
         *
         *  eventName 是对象形式，递归分解
         *  events    保存所有事件对象
         */
        addListener:function (eventName, fn, scope, o) {
            var me = this,
                e,
                oe,
                localEvent;

            //分解元素
            if (typeof eventName == 'object') {
                o = eventName;
                for (e in o) {
                    oe = o[e];
                    if (!me.filterOptRe.test(e)) {
                        me.addListener(e, oe.fn || oe, oe.scope || o.scope, oe.fn ? oe : o);
                    }
                }
            } else {
                //创建
                eventName = eventName.toLowerCase();
                localEvent = me.events[eventName] || TRUE;
                //第一次添加,创建Event对象
                if (typeof localEvent == 'boolean') {
                    me.events[eventName] = localEvent = new XUTUTIL.Event(me, eventName);
                }
                localEvent.addListener(fn, scope, typeof o == 'object' ? o : {});
            }
        },
     ……………………………………………………………
     };