Сообщение об ошибке что-то говорит. Вот исправленная версия, сэр:
public static void funcA(object obj)
{
}
public static void funcB(int num)
{
}
public static void performSelectorAfterDelay<T>(Action<T> method, T parameter, double delay)
{
Thread thread = new Thread(delegate()
{
Thread.Sleep(TimeSpan.FromSeconds(delay));
uc.BeginInvoke((Action)(() => method(parameter)));
});
thread.Start();
}
public static void SomeCall()
{
performSelectorAfterDelay(new Action<object>(funcA), null, kSecondsWaitAfterTransferToFollowersPage);
performSelectorAfterDelay(new Action<int>(funcB), 5, kSecondsWaitAfterTransferToFollowersPage);
}
equalsIgnoreCase
может быть намного быстрее. Например, рассмотрим две строки, которые начинаются с одних и тех же 10000 символов, но одна из них имеет дополнительный символ в конце. equalsIgnoreCase
может немедленно вернуться; compareToIgnoreCase
должен выполнить итерацию до конца строки, чтобы увидеть разницу.
Но, как правило, я выбираю то, что выражает ваше намерение лучше. Это также хорошо работает для производительности: если я правильно скажу, что equalsIgnoreCase
по крайней мере так же быстро, как compareToIgnoreCase
, это означает, что вы должны использовать это, где можете - если вам нужно фактический порядок, вы все равно должны использовать compareToIgnoreCase
.
если вы беспокоитесь о производительности ... измерьте его
Просмотр источника для java.lang.String
public boolean equalsIgnoreCase(String anotherString) {
return (this == anotherString) ? true :
(anotherString != null) && (anotherString.count == count) &&
regionMatches(true, 0, anotherString, 0, count);
}
Итак, прежде чем смотреть на фактическую строку символ за символом (что также происходит аналогичным образом для compareToIgnoreCase
), equalsIgnoreCase
также проверяет эталонную идентичность и длину символа, что может быть намного быстрее.