objective-c - 安排生成敌人的方法或使用敌人缓存的更新方法是否更有效？

Question

我在 iPhone 上使用 Cocos2d，我想知道使用这种方法构建我的代码逻辑以生成敌人是否更有效:

-(void) schedule:(SEL)selector interval:(ccTime)interval

或在 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

您的应用是否存在性能问题？如果不是，答案是:没关系。如果这样做，您是否对其进行了测量并且问题是否来自所讨论的方法？如果不是，答案是:您找错地方了。

换句话说:premature optimization is the root of all evil .

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

没有人可以(或将)看到这么多代码并得出结论“是的，A 肯定快 30-40%，使用 A”。如果您担心该方法的速度，请不要让任何人告诉您哪个更快。测量它。这是您可以确定的唯一方法。

原因是:程序员因对代码性能做出假设而臭名昭著。很多时候他们错了，因为语言或硬件或对主题的理解在他们上次测量时有了很大的飞跃。但更有可能的是，他们会记住他们学到的东西，因为一旦他们提出了与您的问题相同的问题，并且其他人给了他们一个他们从那时起就接受为事实的答案。

但是回到您的具体示例:这真的无关紧要。由于渲染太多敌人而不是确定何时生成敌人的代码，您更有可能遇到性能问题。然后，如果该代码是在预定的选择器中运行，还是在每帧增加计数器的预定更新方法中运行，那么真的、真的、真的、真的真的无关紧要。这归结为一个主观的编码风格偏好问题，而不是关于性能的决定。