"Function Buffer" to avoid triggering an event handler too frequently If some big event handler is triggered too frequently, it will cause computer lagging.

In my example $(window).resize(), I want the function to be called after the user has completed his resize, instead of firing every time you resize by a single pixel.

So, I made this 'Function Buffer':

function FtnBuff(){
    var count=0;
    var delay = 50;     
    var ftnList=[];

    this.add = function(ftn){
        if(isFunction(ftn)){
            ftnList.push(ftn);
        }else{
            return false;
        }
    }
    this.start = function(){
        count ++;
        setTimeout(checkbuff, delay);
    }
    this.setDelay = function(num){
        if(!isNaN(num)){
            delay = num;
        }
    }
    function checkbuff(){
        if(count==1){
            runFtn();
        }
        count--;
    }
    function runFtn(){
        for(var key in ftnList){
            ftnList[key]();
        }
    }
    function isFunction(obj) {
        var getType = {};
        return obj &amp;&amp; getType.toString.call(obj) === '[object Function]';
    }
    return this;
}


Use case:

ftnbuff = new FtnBuff()
ftnbuff.add(aa)
ftnbuff.add(function(){
    bb('long time no C.')
})
$(window).resize(ftnbuff.start)

function aa(){
    console.log('This is aa.');
}
function bb(customText){
    console.log('This is bb.'+customText);
}
As mentioned in the comments, this is usually called "debouncing."

A simpler and easier-to-use approach would be something like this:

function debounce(fn, delay) {
    var timeout;

    return function () {
        var context = this,
            args = arguments;

        clearTimeout(timeout);
        timeout = setTimeout(function () {
            fn.apply(context, args);
        }, delay || 250);
    };
}


Use case:

$(window).resize(debounce(someFunction, 1000));




With that out of the way, let's review the code.

Broken features

The timeout is never cleared if the function is called multiple times within the delay period. Unless I'm missing something, all this is going to accomplish is delaying the function from running, but it will still run as many times as it is called. This doesn't seem to work "as advertised."

Missing features

Most functions take arguments. Many functions rely on a this binding. These buffered functions don't allow passing arguments or preserve the this binding. These are features you will probably need at some point. Incidentally, with this implementation it would be very difficult to make changes allowing arguments to your buffered functions, because FtnBuff does not have a...

Single responsibility

If you're going to debounce functions, there's no reason you can't debounce them one at a time. Your code incurs a lot of complexity from maintaining a list of functions to call (which also causes problems with passing arguments). 

Let's take a step back. If you wanted to have one function handle an event, you'd do this:

addEventListener('resize', someFunction);


If you needed to have two functions handle an event (and didn't want to register them as separate listeners), you might do something like this:

addEventListener('resize', function () {
    someFunction.apply(this, arguments);
    anotherFunction.apply(this, arguments);
});


There's no reason why a debounce function should handle calling a series of functions; that's not its job. Its job is just to debounce. Calling a series of functions is already a core feature of the language; just write a function that calls the other functions and debounce that. 

TLDR: Don't try to handle multiple functions, it's too limiting and not necessary.

Typechecking

You may be more familiar with strongly-typed languages; they have built-in type checking. So you think, "hmm, how can I ensure that things are the right type in this dynamically-typed language?" And you end up writing things like if (isFunction(fn)), or if (!isNaN(n)), or whatever.

This is not a road you want to go down. It's going to cause unnecessary code bloat, and it doesn't really solve anything. Imagine passing a non-function or a non-number to one of those functions. If you weren't doing these checks, things would likely fail in some way that would indicate what the problem was. Since you are doing these checks, things won't fail, but nothing useful will happen either. This is arguably worse -- I'd rather have something fail and be able to track down the problem then have nothing happen at all, and get stuck wondering why.

What you could do instead is throw errors when these checks fail. This would be better than what you have now, but again, not really necessary. It's up to you to document your API (think annotations) and it's up to the person using it to use it properly. If they're passing a string in for a delay parameter that's clearly documented as taking a number, that's user error.

TLDR: Don't write twice as much code to handle dumb user errors, document your API instead.