安排一个方法来繁殖敌人还是使用敌人缓存的更新方法更有效

Question

我正在为iPhone使用Cocos2d，我想知道使用以下方法构建代码的逻辑以滋生敌人是否更有效：

-（无效）时间表：（SEL）选择器间隔：（ccTime）间隔

或者使用EnemyCache类中的更新，并每次验证是否满足时间间隔。以下是EnemyCache类的更新方法中调用的代码片段（相对时间是GameScene在GameScene类中每次更新时更新的整数值-GameScene更新方法调用以1秒为间隔进行调度）：

-(void) checkForPlayerCollisionsAndSpwanTime
{

    int count = [elements count];
    //CCLOG(@"count %i", count);
    Element* element;
    for(int i=0; i<count;i++){
        element = [elements objectAtIndex:i];
        NSAssert(element!=nil, @"Nil enemy");
        if (element.visible)
        {
            [element justComeDown];
            ShipEntity * ship = [[GameScene sharedGameScene]defaultShip];
            CGRect rect = [ship boundingBox];
            if (CGRectIntersectsRect([element boundingBox], rect)){
                [element doWhatever]; 
                element.visible=FALSE;
                [element stopAllActions];
            }       
        }
        else{
            if(element.spawnTime == relativeTime) {
                [self addChild:element]; 
                element.visible=TRUE;
            }
        }
    }
}

不同的是，在每次更新时，checkForPlayerCollisionsAndSpwanTime方法都会遍历敌人阵列。第一种方法是，通过安排选择器调用类似的方法，我可以减少CPU查看数组和条件所花费的时间。

我不确定这个电话的成本有多高：

[self schedule:selector interval:interval repeat:kCCRepeatForever delay:0];

仔细查看，我发现它调用了这个方法（见下文），但我想问一下，你解决这个问题的方法是什么，我应该继续使用EnemyCache更新方法还是使用scheduleSelector方法。

-(void) scheduleSelector:(SEL)selector forTarget:(id)target interval:(ccTime)interval paused:(BOOL)paused repeat:(uint) repeat delay:(ccTime) delay
{
    NSAssert( selector != nil, @"Argument selector must be non-nil");
    NSAssert( target != nil, @"Argument target must be non-nil");
    tHashSelectorEntry *element = NULL;
    HASH_FIND_INT(hashForSelectors, &target, element);
    if( ! element ) {
        element = calloc( sizeof( *element ), 1 );
        element->target = [target retain];
        HASH_ADD_INT( hashForSelectors, target, element );
        // Is this the 1st element ? Then set the pause level to all the selectors of this target
        element->paused = paused;
    } else
        NSAssert( element->paused == paused, @"CCScheduler. Trying to schedule a selector with a pause value different than the target");

    if( element->timers == nil )
        element->timers = ccArrayNew(10);
    else
    {
        for( unsigned int i=0; i< element->timers->num; i++ ) {
            CCTimer *timer = element->timers->arr[i];
            if( selector == timer->selector ) {
                CCLOG(@"CCScheduler#scheduleSelector. Selector already scheduled. Updating interval from: %.4f to %.4f", timer->interval, interval);
                timer->interval = interval;
                return;
            }
        }
        ccArrayEnsureExtraCapacity(element->timers, 1);
    }
    CCTimer *timer = [[CCTimer alloc] initWithTarget:target selector:selector interval:interval repeat:repeat delay:delay];
    ccArrayAppendObject(element->timers, timer);
    [timer release];
}

Answer 1

您的应用程序是否存在性能问题？如果没有，答案是：没关系。如果你这样做了，你测量过了吗？问题是否来自所讨论的方法？如果没有，答案是：你找错地方了。

换句话说：过早的优化是万恶之源。

如果你仍然想知道，只有一种方法可以找到：测量代码的两个变体，然后选择一个更快的变体。如果速度差异很小（我怀疑会是这样），请选择更容易使用的版本。你应该考虑一种不同的表现：你作为一个人，阅读、理解、更改代码。在几乎所有情况下，代码的可读性和可维护性都比性能重要得多。

没有人能够（或将要）看到这么多代码并得出结论："是的，A肯定快30-40%，使用A"。如果你担心这个方法的速度，不要让任何人告诉你哪个更快。测量一下。这是你唯一能确定的方法。

原因是：程序员对代码性能的假设是臭名昭著的。很多时候，他们错了，因为他们上次测量时，语言、硬件或对主题的理解已经有了很大的飞跃。但他们更有可能记住自己学到的东西，因为一旦他们问了一个和你一样的问题，别人就给了他们一个答案，从此他们就接受了这个答案。

但回到你的具体例子：这真的无关紧要。与决定何时生成敌人的代码相比，由于渲染了太多敌人，您更容易遇到性能问题。然后，无论该代码是在调度选择器中运行，还是在每帧增加一个计数器的调度更新方法中运行，这都无关紧要。这归根结底是一个主观的编码风格偏好问题，而不是关于性能的决定。