Избегайте внутренних добытчиков / сеттеров - PullRequest
7 голосов
/ 27 декабря 2010

В исходном коде Activity.java я вижу несколько методов ниже:

public View findViewById(int id) {
    return getWindow().findViewById(id);
}

и определение метода getWindow:

public Window getWindow() {
    return mWindow;
}

Но как следующие правила:

Избегайте внутренних геттеров / сеттеров

В родных языках, таких как C ++, обычная практика - использовать геттеры (например, i = getCount ()) вместо прямого доступа к полю(я = mCount).Это отличная привычка для C ++, потому что компилятор обычно может встроить доступ, и если вам нужно ограничить или отладить доступ к полю, вы можете добавить код в любое время.

В Android это плохая идея,Вызовы виртуальных методов стоят дорого, намного больше, чем поиск полей экземпляра.Разумно следовать общепринятым методам объектно-ориентированного программирования и иметь методы получения и установки в открытом интерфейсе, но внутри класса вы всегда должны обращаться к полям напрямую.

Без JIT прямой доступ к полям примерно в 3 раза быстрее, чем вызовтривиальный добытчик.С JIT (где прямой доступ к полю обходится дешевле, чем доступ к локальному), прямой доступ к полю примерно в 7 раз быстрее, чем вызов тривиального геттера.Это верно для Froyo, но улучшится в будущем, когда JIT встроит методы получения.

, поэтому я хочу знать, почему разработчики Android не имеют прямого доступа к этому объекту mWindow?Если JIT текущей версии Android не может встроить доступ, getWindow (). FindViewById (id) будет стоить больше времени, чем mWindow.findViewById (id), а findViewById - довольно часто используемый метод.

Ответы [ 3 ]

2 голосов
/ 27 декабря 2010

Во-первых: вы не можете получить к нему доступ, потому что это личное.

Почему это личное?

Как вы сказали, прямой доступ к участникам быстрее. С другой стороны, вы вызываете метод, который не очень быстрый, так как он будет искать некоторые представления в иерархии представлений. Поэтому использование метода вместо прямого доступа потребует небольших накладных расходов в процентах от общего времени, которое потребуется для выполнения этой задачи.

В любом случае, я считаю, что причиной этого является инкапсуляция.

Вы вызываете то, что вам не не принадлежит (то есть Android SDK). Таким образом, вы не должны делать какие-либо предположения о том, что происходит "на другой стороне". Просто используйте этот метод и ожидайте, что он вернет желаемое представление (или ноль, если он не существует).

Возможно, следующая версия Android будет использовать другой метод для поиска представления, не вызывая getWindow(). Если вы используете этот метод, они (Google / Android) могут просто пометить метод как устаревший и «перенаправить» ваш вызов в новейшую реализацию. Если бы вы звонили напрямую getWindow(), возможно, вы бы искали что-то, чего там больше нет.

1 голос
/ 27 декабря 2010

Вы не можете получить доступ к свойству mWindow напрямую - это личное .И мне было бы наплевать на скорость findViewById, поскольку вам нужно вызывать ее только один раз для каждого представления в макете в вашем методе onCreate() и сохранять представления в элементах вашей деятельности.Вы делаете вызовите findViewById только один раз за просмотр, не так ли?; -)

Однако, если вы действительно заботитесь об этих вещах, вы можете вызвать getWindow() для себя, сохранить его в локальной переменной и вызвать findViewById напрямую.Я не рекомендовал бы это, потому что все ваши улучшения производительности здесь не стоят времени и в любом случае будут устаревшими с будущими версиями JIT.

Если вы сделаете это, меня очень заинтересует количество микросекунд, которое высохранены.: -)

0 голосов
/ 26 апреля 2012

У нас есть причина улыбаться сейчас ...

Документация для Android, в которой говорится, что во избежание внутренних геттеров и сеттеров скоро изменится, предположительно, на платформу Gingerbread была добавлена ​​progruard, которая отлично справляется с встраиванием аксессоров. и эти два ТАК сообщения.

  1. https://stackoverflow.com/a/6716573/892055

  2. https://stackoverflow.com/a/4930538/892055

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...