Сохранение контекста, активности или представлений как члена класса – это плохая производительность?

У меня есть красный где-то, что сохранение представлений в качестве элементов активности – это плохая производительность, потому что в каждом представлении содержится ссылка на его родительский контекст, и он заполняет кучу. Это правда?

Представьте себе эту деятельность:

public class MyActivity extends FragmentActivity{ private RelativeLayout mainLayout; private LineraLayout menuLayout; private FrameLayout tableLayout; private Button buttonOk; private Button buttonCancel; @Override protected void onCreate(Bundle bundle){ super.onCreate(bundle); mainLayout = (RelativeLayout) findViewById(R.id.mainlayout); // And inflating other views } } 

А как насчет адаптеров ?

 public class MyAdapter extends BaseAdapter{ private MyActivity activity; private ArrayList<MyObjects> myObjects; public MyAdapter (MyActivity activity, ArrayList<MyObjects> myObjects){ this.activity = activity; this.myObjects = myObjects; } } 

Это плохая работа? Неправильно ли передавать активность в качестве параметра вместо контекста? Что делать, если я хочу получить доступ к общедоступным методам из родительского класса MyActivity из адаптера?

Класс Non-Activity

 public MyDatabase{ private Context context; private SQLiteDatabase db; public MyDatabase(Context context){ this.context = context; this.db = new DatabaseHelper(context).getWritableDatabase(); } public Object getData(int id){ return db.query(params...); } public static class DatabseHelper extends SQLiteOpenHelper{ public DatabaseHelper(Context context){ super(context, "my_db", null, 1); } } } 

Почему люди говорят, что, когда конструктор класса ожидает Context как параметра, вы должны передать getApplicationContext() вместо Activity и Activity?

    Чтобы передать экземпляр Activity на какой-либо метод или сохранить ссылку на него где-то, это плохая практика, потому что во время изменения конфигурации Android создает новый экземпляр действия, а старый должен быть удален сборщиком мусора. Но если кто-то ссылается на старый объект Activity он не будет собран GC, пока ссылка на него не будет существовать. Так происходит утечка памяти.

    Но в случае конструктора адаптера вполне нормально передавать экземпляр активности, поскольку жизненный цикл адаптера связан с жизненным циклом деятельности. Обычно это будет мусор, собранный после активности.

    getApplicationContext возвращает контекст единого глобального объекта приложения текущего процесса, поэтому его можно безопасно использовать во всем коде приложения.

    Речь идет не о плохой производительности, а о возможной утечке памяти. Передача getApplicationContext () вместо Activity – это просто избежать потенциальной утечки памяти.

    Нет ничего плохого в том, что деятельность должна содержать мнение как членов, поскольку контекст представления – это активность. Если активность не содержит ссылок, вам нужно вызывать findViewById каждый раз, когда вы хотите получить доступ к представлению, что будет действительно влиять на производительность. Что касается адаптера, все равно хорошо, чтобы вы проходили не контекст активности.

    Контекст «Передача активности» – это то, что вам нужно в конце для доступа к общедоступным методам вашей деятельности, потому что любым способом, если вы используете getApplicationContext (), вам придется отдать его в свою активность во время вызовов метода.

     ((MainActivity)context).getMyPublicMehtods() inside the non Activity class. 

    И для более подробной информации @makovkastar определил его очень хорошо. 🙂