WEBVTT

00:00:00.000 --> 00:00:01.680
Настройтесь на эту неделю
Xamarin Показать, где

00:00:01.680 --> 00:00:03.360
мой хороший друг Алекси на разговоры

00:00:03.360 --> 00:00:06.810
об управлении памятью для
ваших приложений. Так что настройтесь.

00:00:06.810 --> 00:00:13.200
(МУЗЫКА)

00:00:13.200 --> 00:00:14.280
С возвращением, все,

00:00:14.280 --> 00:00:15.405
на шоу Ксамарин.

00:00:15.405 --> 00:00:16.650
Я ваш хозяин Джеймс Монтемагно.

00:00:16.650 --> 00:00:17.820
Сегодня, мой лучший друг в

00:00:17.820 --> 00:00:21.270
весь мир Алекси с
Меня. Как дела, приятель?

00:00:21.270 --> 00:00:22.905
Я в порядке. А ты?

00:00:22.905 --> 00:00:24.960
Я делаю фантастические.
Прекрасный день

00:00:24.960 --> 00:00:26.640
здесь, в Редмонде, штат Вашингтон каждый день.

00:00:26.640 --> 00:00:27.325
В-это.

00:00:27.325 --> 00:00:29.085
Теперь вы с нашего мобильного

00:00:29.085 --> 00:00:31.065
консультирование клиентов
команда, это правильно?

00:00:31.065 --> 00:00:31.920
Это правильно.

00:00:31.920 --> 00:00:33.450
Так что же это значит?

00:00:33.450 --> 00:00:35.370
Это означает, что мы работаем с

00:00:35.370 --> 00:00:38.250
наших клиентов и мы
советовать им, очевидно.

00:00:38.250 --> 00:00:41.645
Но в основном, мы работаем с разработчиками
и посмотреть, как они используют инструменты,

00:00:41.645 --> 00:00:44.300
как они работают с нашим инструментом Xamarin,

00:00:44.300 --> 00:00:47.560
и каковы общие
ловушки они сталкиваются с.

00:00:47.560 --> 00:00:48.420
Идеально.

00:00:48.420 --> 00:00:50.205
Сегодня я хочу поговорить о

00:00:50.205 --> 00:00:52.355
одним из них является управление памятью.

00:00:52.355 --> 00:00:53.780
Я поймала тебя. Да. Это очень важно

00:00:53.780 --> 00:00:55.730
потому что мы часто говорим
обо всем прохладном,

00:00:55.730 --> 00:00:57.155
причудливые функции, которые вы можете сделать,

00:00:57.155 --> 00:01:00.440
но мы хотели, чтобы это
лучшие практики серии

00:01:00.440 --> 00:01:02.340
потому что у тебя неприятности.

00:01:02.340 --> 00:01:03.820
Такое бывает. Это так легко сделать.

00:01:03.820 --> 00:01:06.345
Управление памятью,
честно говоря, я нуб.

00:01:06.345 --> 00:01:07.770
Я действительно не знаю. Я просто говорю:

00:01:07.770 --> 00:01:09.560
"Они собираются убить
мое приложение в пять секунд.

00:01:09.560 --> 00:01:11.705
Это не имеет значения, не так ли? Но
Я не должен так думать.

00:01:11.705 --> 00:01:14.210
Это правда. Это то, что мы видим

00:01:14.210 --> 00:01:16.850
потому что никто не заботится о
управления памятью.

00:01:16.850 --> 00:01:21.300
У нас так много памяти
и вы никогда не проверить их.

00:01:21.300 --> 00:01:24.750
Я имею в виду, когда ты в последний раз
проверили использование памяти приложения?

00:01:24.750 --> 00:01:26.250
В последний раз, когда я попала в аварию.

00:01:26.250 --> 00:01:29.510
На самом деле, у меня был очень
хороший пример этого.

00:01:29.510 --> 00:01:31.910
Вот что я тебе скажу. Это
является реальным примером.

00:01:31.910 --> 00:01:35.120
Я получил ошибку в Xamarin Essentials

00:01:35.120 --> 00:01:38.375
что говорит, когда я звоню
этот метод 20000 раз,

00:01:38.375 --> 00:01:41.570
мое приложение сбои, и это
было, потому что я не был

00:01:41.570 --> 00:01:45.155
правильное утилизация
родной объект Android,

00:01:45.155 --> 00:01:46.775
окно, дисплей.

00:01:46.775 --> 00:01:48.170
Итак, что происходит,

00:01:48.170 --> 00:01:50.480
Я хотел бы продолжать создавать его
и он никогда не получит

00:01:50.480 --> 00:01:53.135
мусор, собранный когда-либо, потому что
Я никогда не издавал его.

00:01:53.135 --> 00:01:54.890
Это то, что мы собираемся
говорить о сегодняшнем дне.

00:01:54.890 --> 00:01:56.925
Да, да. Замечательно. Давайте сделаем
это. Что у тебя есть для нас?

00:01:56.925 --> 00:02:00.435
Так что у нас есть этот небольшой
простое приложение с двумя окнами,

00:02:00.435 --> 00:02:02.745
главный экран и экран детализации.

00:02:02.745 --> 00:02:06.375
Это очень распространенная закономерность
Контроллер навигации uI.

00:02:06.375 --> 00:02:09.600
Это простой Xamarin
Приложение для iOS, не так ли?

00:02:09.600 --> 00:02:10.305
Хорошо, хорошо.

00:02:10.305 --> 00:02:12.440
- Что мы собираемся
сделать, это ввести

00:02:12.440 --> 00:02:14.930
утечки памяти во многих,
много разных способов.

00:02:14.930 --> 00:02:19.025
Но сначала я хочу поговорить о
отличия от родного мира

00:02:19.025 --> 00:02:23.960
и управляемый мир
производительности и памяти.

00:02:23.960 --> 00:02:25.340
Поэтому всякий раз, когда у вас есть процесс,

00:02:25.340 --> 00:02:27.995
операционная система дает
вы кусок памяти.

00:02:27.995 --> 00:02:31.370
Вы должны знать о том, что
потому что как только у вас кончись памяти,

00:02:31.370 --> 00:02:33.670
ваше приложение выходит из строя или
операционная система убивает его.

00:02:33.670 --> 00:02:35.355
В управляемой памяти

00:02:35.355 --> 00:02:40.260
наши Xamarin Моно получать эти
маленький кусочек этой памяти.

00:02:40.260 --> 00:02:41.630
Вот когда мы должны быть

00:02:41.630 --> 00:02:43.670
осторожны о том, как мы
использовать эту часть, а также.

00:02:43.670 --> 00:02:44.030
Хорошо, хорошо.

00:02:44.030 --> 00:02:46.640
Так что вы все равно должны быть
осведомлены о родной памяти,

00:02:46.640 --> 00:02:48.905
и теперь, как только вы работаете с Xamarin,

00:02:48.905 --> 00:02:50.320
также известно об управленческой части.

00:02:50.320 --> 00:02:52.740
Получил его. Таким образом, у вас есть
наиродная память, iOS,

00:02:52.740 --> 00:02:55.980
Android биты и куски,
Управляет памятью .NET?

00:02:55.980 --> 00:02:56.640
Вот именно.

00:02:56.640 --> 00:02:57.090
Идеально.

00:02:57.090 --> 00:03:00.530
Всякий раз, когда вы создаете объект
и вы создаете, скажем так,

00:03:00.530 --> 00:03:02.330
кнопка uI, вы фактически создаете

00:03:02.330 --> 00:03:04.950
родная кнопка uI и
управляемый класс кнопки uI.

00:03:04.950 --> 00:03:06.680
Они имеют различное влияние памяти.

00:03:06.680 --> 00:03:10.310
Они могут вызвать различные
проблемы с памятью, потому что есть

00:03:10.310 --> 00:03:14.135
также родной способ сбора
мусор а также управляемый путь.

00:03:14.135 --> 00:03:20.385
В Mono мы используем одиночный моно
поколения сборщик мусора.

00:03:20.385 --> 00:03:23.460
В родном мире iOS использует ARC,

00:03:23.460 --> 00:03:26.680
Android использовать свои собственные
сборщик мусора,

00:03:26.680 --> 00:03:29.420
но они должны работать вместе
бок о бок, и мы должны

00:03:29.420 --> 00:03:32.300
иметь их, потому что вы можете
ввести проблемы, используя это.

00:03:32.300 --> 00:03:32.690
Получил его.

00:03:32.690 --> 00:03:34.640
Так что первый и

00:03:34.640 --> 00:03:36.950
самый простой подход к внедрению

00:03:36.950 --> 00:03:40.830
проблемы с памятью — это подписка
без подписки.

00:03:42.040 --> 00:03:45.680
Сборщик мусора должен знать
когда есть мусор.

00:03:45.680 --> 00:03:47.180
Но как он мог знать?

00:03:47.180 --> 00:03:49.565
Он должен быть в состоянии построить

00:03:49.565 --> 00:03:53.915
график дерева досягаемости
и начинается с маршрутов.

00:03:53.915 --> 00:03:57.320
Наши статические события, статические переменные,

00:03:57.320 --> 00:03:59.350
статические события или переклички потоков,

00:03:59.350 --> 00:04:01.910
все они достижимые маршруты и

00:04:01.910 --> 00:04:05.005
сборщик мусора лечит
их, как не мусор.

00:04:05.005 --> 00:04:06.810
Поэтому всякий раз, когда вы подписываетесь, как это,

00:04:06.810 --> 00:04:09.560
Давайте возьмем плагин подключения.

00:04:09.560 --> 00:04:11.960
Я знаю, Джеймс, ты
знакомы с этим плагином.

00:04:11.960 --> 00:04:13.400
Я- В. Да. Очень сильно.

00:04:13.400 --> 00:04:14.960
Мне это нравится. В
Здесь, мы просто что?

00:04:14.960 --> 00:04:16.220
Подписка на мероприятие,

00:04:16.220 --> 00:04:18.610
и это может быть любой
такие события, как событие щелчка,

00:04:18.610 --> 00:04:20.360
у вас есть событие изменения датчика.

00:04:20.360 --> 00:04:22.715
В принципе, что-нибудь когда-либо в .NET.

00:04:22.715 --> 00:04:25.970
Да, да. Это специфично
не только Ксамарину.

00:04:25.970 --> 00:04:27.830
Это любое статическое событие

00:04:27.830 --> 00:04:31.745
в .NET и подключение
вот только пример.

00:04:31.745 --> 00:04:35.390
То, что я пытаюсь сказать, это
может быть любое статическое событие или

00:04:35.390 --> 00:04:38.960
любое событие, при условии, что это однособытие.

00:04:38.960 --> 00:04:40.880
Поэтому всякий раз, когда мы подписываемся так,

00:04:40.880 --> 00:04:42.520
и предположим, что у нас есть

00:04:42.520 --> 00:04:47.100
этот маленький кусочек
Обработчик ConnectivityChanged.

00:04:47.100 --> 00:04:49.655
Мы вводим небольшую утечку памяти.

00:04:49.655 --> 00:04:54.290
Он мал, потому что наш взгляд
довольно простой и легкий,

00:04:54.290 --> 00:04:55.400
но это утечка памяти.

00:04:55.400 --> 00:04:57.685
Так что это утечка памяти, почему, хотя?

00:04:57.685 --> 00:05:00.860
Потому что это подключение и

00:05:00.860 --> 00:05:03.830
Событие ConnectivityChanged
является статической ссылкой

00:05:03.830 --> 00:05:05.270
для нашего сборщика мусора.

00:05:05.270 --> 00:05:06.980
Однажды наш мусор
коллекционер пытается

00:05:06.980 --> 00:05:08.810
определить, если это мусор или нет,

00:05:08.810 --> 00:05:11.015
это не потому, что

00:05:11.015 --> 00:05:14.540
Событие ConnectivityChanged имеет
ссылка на этого обработчика,

00:05:14.540 --> 00:05:17.375
и этот обработчик на самом деле ручки

00:05:17.375 --> 00:05:21.080
ссылка на наши
ПодробностиПросмотрконтроллер.

00:05:21.080 --> 00:05:24.680
Я вижу. Есть. Таким образом, мы
создал это событие внутри

00:05:24.680 --> 00:05:29.600
этот ViewController и я
подписка, но никогда не отписались.

00:05:29.600 --> 00:05:31.970
Так что это всегда имеет это
ссылка немедленно.

00:05:31.970 --> 00:05:34.940
Так сборщики мусора говорят:
"Эй, что доступно?"

00:05:34.940 --> 00:05:37.030
Он говорит: "Вы не можете иметь это."

00:05:37.030 --> 00:05:38.205
Это правильно.

00:05:38.205 --> 00:05:40.580
Я хочу убедиться, что
это правильно, потому что я

00:05:40.580 --> 00:05:42.185
считаю, что это, как
это работает в моей голове.

00:05:42.185 --> 00:05:43.150
Я хочу убедиться, что я прав.

00:05:43.150 --> 00:05:47.225
Одиночный сборщик мусора задачи
делает это, чтобы разослать память,

00:05:47.225 --> 00:05:48.605
и сделать это правильно,

00:05:48.605 --> 00:05:50.540
сборщик мусора должен знать, как

00:05:50.540 --> 00:05:52.730
правильно определить, если
это мусор или нет.

00:05:52.730 --> 00:05:53.180
Получил его.

00:05:53.180 --> 00:05:55.790
Таким образом, чтобы построить дерево досягаемости,

00:05:55.790 --> 00:05:59.270
сборщик мусора
использует статические маршруты или

00:05:59.270 --> 00:06:01.430
просто маршруты и статические события

00:06:01.430 --> 00:06:03.500
или любое статическое свойство
как один из маршрутов.

00:06:03.500 --> 00:06:06.460
Также локальные переменные,
много других вещей.

00:06:06.460 --> 00:06:07.020
Получил его.

00:06:07.020 --> 00:06:11.820
Так что позвольте мне просто запустить его
и показать, как это работает.

00:06:11.820 --> 00:06:14.745
Как вы думаете, мы будем
видите какую-то разницу?

00:06:14.745 --> 00:06:17.540
Я не знаю. Я имею в виду
надеюсь, не потому, что

00:06:17.540 --> 00:06:20.090
это так просто то, что я думаю.

00:06:20.090 --> 00:06:22.160
Теперь, мой страх, хотя в том, что

00:06:22.160 --> 00:06:24.200
так как мы регистрации более
и снова и снова,

00:06:24.200 --> 00:06:26.750
если мы изменим события,

00:06:26.750 --> 00:06:28.850
мы, вероятно, получить
во многих мероприятиях.

00:06:28.850 --> 00:06:30.635
Да, да. Давайте проверим это.

00:06:30.635 --> 00:06:33.560
Так что я переехала на страницу Подробности.

00:06:33.560 --> 00:06:36.185
Я собираюсь отключить мой Wi-Fi сейчас.

00:06:36.185 --> 00:06:38.510
Здесь мы используем
ioOS Simulator.

00:06:38.510 --> 00:06:41.975
Так что это на самом деле с помощью
машина В Интернете.

00:06:41.975 --> 00:06:46.460
Да, да. Мы только что получили событие здесь
которые являются ConnectivityChanged.

00:06:46.460 --> 00:06:51.910
Давайте вернемся несколько раз
и еще несколько раз,

00:06:51.910 --> 00:06:54.630
и я вернулся на главную страницу.

00:06:54.630 --> 00:06:58.215
Я не деликатный в
ничего прямо сейчас,

00:06:58.215 --> 00:07:01.280
и я предполагаю, что мои детали
страницы больше не существует, не так ли?

00:07:01.280 --> 00:07:01.430
Да, да.

00:07:01.430 --> 00:07:02.810
Мой обработчик подписки

00:07:02.810 --> 00:07:04.805
не должно работать, потому что
Я ничего не сделал.

00:07:04.805 --> 00:07:07.015
Давайте включим Wi-Fi.

00:07:07.015 --> 00:07:09.510
Хорошо, хорошо. Таким образом, мы на самом деле создали

00:07:09.510 --> 00:07:11.910
это ConnectivityChanged
на второй странице.

00:07:11.910 --> 00:07:12.420
Вторая страница.

00:07:12.420 --> 00:07:13.665
Ну, я на первой странице.

00:07:13.665 --> 00:07:17.440
Да, да. Поэтому мы не ожидаем, что
наш обработчик на работу,

00:07:17.440 --> 00:07:18.645
но посмотрите, что мы получили.

00:07:18.645 --> 00:07:21.090
Мы только что получили четыре обработчика
работает наш код,

00:07:21.090 --> 00:07:23.600
и это может быть любой
база данных обновления кода,

00:07:23.600 --> 00:07:25.505
сохранение настройки, независимо.

00:07:25.505 --> 00:07:28.070
Проблема здесь не только
с управлением памятью

00:07:28.070 --> 00:07:30.635
потому что это занимает некоторое воспоминание.

00:07:30.635 --> 00:07:34.970
Это также проблема, потому что у нас есть
некоторые коды, которые будут выполнены, а также.

00:07:34.970 --> 00:07:37.445
Тогда это означает,
что страница Детали,

00:07:37.445 --> 00:07:39.350
Теперь он никогда не может быть
мусор собран?

00:07:39.350 --> 00:07:42.455
Так что теперь я просто это
Подробная страница всегда в памяти.

00:07:42.455 --> 00:07:43.400
К сожалению, да.

00:07:43.400 --> 00:07:44.660
О боже мой, это плохо.

00:07:44.660 --> 00:07:47.385
Это плохо. Как разработчик,

00:07:47.385 --> 00:07:49.560
мы не всегда это видим.

00:07:49.560 --> 00:07:54.280
Как пользователь, я вижу, что мое приложение выходит из строя
как раз в неделю, независимо.

00:07:54.280 --> 00:07:56.675
Я просто перезакажу его
и продолжать использовать его.

00:07:56.675 --> 00:07:58.220
Вот почему об этом не сообщается,

00:07:58.220 --> 00:08:00.350
это не воспринимается очень серьезно,

00:08:00.350 --> 00:08:03.950
но это вопрос, особенно если вы

00:08:03.950 --> 00:08:08.330
получить огромное изображение там
что влияет на вашу память.

00:08:08.330 --> 00:08:10.910
Так что я собираюсь без комментариев
эта строка кода,

00:08:10.910 --> 00:08:14.680
который на самом деле добавляет некоторую нагрузку памяти

00:08:14.680 --> 00:08:19.740
здесь, и это загрузка
изображение из Интернета.

00:08:19.740 --> 00:08:22.265
Мы просто делаем случайное изображение.

00:08:22.265 --> 00:08:24.815
Позвольте мне показать, что это действительно случайно.

00:08:24.815 --> 00:08:27.035
Давайте посмотрим, что мы получим здесь.

00:08:27.035 --> 00:08:29.510
Я всегда беспокоюсь об этом.

00:08:29.510 --> 00:08:32.210
Хорошо. Итак, у нас есть это случайное изображение,

00:08:32.210 --> 00:08:34.370
и это то, что мы
собирается загрузить в

00:08:34.370 --> 00:08:37.190
наше приложение каждый раз, когда мы
перейдите на страницу Подробности.

00:08:37.190 --> 00:08:37.610
Хорошо, хорошо.

00:08:37.610 --> 00:08:40.395
Позвольте мне показать его здесь.

00:08:40.395 --> 00:08:42.970
Это совершенно что-то
что то, что всегда происходит, не так ли?

00:08:42.970 --> 00:08:45.220
Потому что перейдите на страницу Подробности,

00:08:45.220 --> 00:08:46.740
вероятно, загрузить некоторую информацию,

00:08:46.740 --> 00:08:48.080
может быть потянув некоторые
информации от

00:08:48.080 --> 00:08:51.095
база данных на этом экране,
и это может быть плохо.

00:08:51.095 --> 00:08:53.930
Представьте себя, что вы
с помощью приложения Instagram.

00:08:53.930 --> 00:08:55.330
У вас есть подробная страница там.

00:08:55.330 --> 00:08:56.710
Вы нажмете и следовать,

00:08:56.710 --> 00:08:58.435
внисять детали, вернулся.

00:08:58.435 --> 00:09:00.720
Перейти проверить другую папку,
внисяли детали,

00:09:00.720 --> 00:09:03.920
вернулся, и через неделю ваше приложение
падает, и никто не знает, почему.

00:09:03.920 --> 00:09:06.680
Вот когда проблемы с памятью
может вступить в игру.

00:09:06.680 --> 00:09:09.180
Я поймала тебя.

00:09:09.180 --> 00:09:11.855
Я не буду показывать вам, что
утечка памяти все еще там

00:09:11.855 --> 00:09:14.650
потому что я хочу показать
вы профайлер,

00:09:14.650 --> 00:09:16.375
как вы можете определить эти проблемы.

00:09:16.375 --> 00:09:17.800
Чтобы определить эти проблемы,

00:09:17.800 --> 00:09:19.990
у вас есть несколько инструментов.

00:09:19.990 --> 00:09:23.350
Прежде всего, это родные инструменты,
iOs предоставляет инструменты,

00:09:23.350 --> 00:09:25.520
и второй - это управляемый инструмент,

00:09:25.520 --> 00:09:27.005
который Xamarin Profiler.

00:09:27.005 --> 00:09:27.990
Я поймала тебя.

00:09:27.990 --> 00:09:29.520
Как вы думаете, зачем нам нужно и то, и другое?

00:09:29.520 --> 00:09:32.985
Ну, они делают разные вещи.

00:09:32.985 --> 00:09:36.090
Да, да. Фактически
из-за этого изображения.

00:09:36.090 --> 00:09:38.025
Помните. Я говорила об этом.

00:09:38.025 --> 00:09:41.565
Они на самом деле могут знать,
о своей собственной части.

00:09:41.565 --> 00:09:44.190
Так Xamarin Profiler ничего не знает

00:09:44.190 --> 00:09:47.100
о родной памяти
объекты, созданные там,

00:09:47.100 --> 00:09:50.010
и отечественные инструменты не
знать об управляемой памяти.

00:09:50.010 --> 00:09:52.685
Он просто говорит, что есть некоторые
кусок созданного объекта.

00:09:52.685 --> 00:09:54.710
Когда Mono создает объект,

00:09:54.710 --> 00:09:57.275
он по-прежнему связывают его как-то
на родные объекты.

00:09:57.275 --> 00:09:59.210
Таким образом, те, которые вы сможете увидеть,

00:09:59.210 --> 00:10:00.500
но все остальное не будет.

00:10:00.500 --> 00:10:01.220
Хорошо, хорошо. Классно.

00:10:01.220 --> 00:10:02.945
Итак, давайте посмотрим, Xamarin Profiler.

00:10:02.945 --> 00:10:06.550
Легче понять,
в начале,

00:10:06.550 --> 00:10:10.955
и это также показывает вам приятно
пространство имен и как именования.

00:10:10.955 --> 00:10:12.815
Таким образом, вы можете идентифицировать свой объект.

00:10:12.815 --> 00:10:16.715
Есть небольшая кнопка "Бег"
и "Стартовый профиль" здесь.

00:10:16.715 --> 00:10:20.050
Вам нужно предприятие
лицензии для этого.

00:10:20.050 --> 00:10:23.870
Но это очень удобно и
Я призываю вас сделать это.

00:10:23.870 --> 00:10:25.190
Итак, как только вы это сделаете,

00:10:25.190 --> 00:10:26.825
он на самом деле строит приложение с

00:10:26.825 --> 00:10:31.130
некоторые дополнительные метаданные и
код, встроенный в ваше приложение.

00:10:31.130 --> 00:10:33.580
Таким образом, мы могли видеть и
отслеживать объекты.

00:10:33.580 --> 00:10:36.140
Теперь одна вещь, в то время как это
строит и развертывает это,

00:10:36.140 --> 00:10:38.030
мы бежим на
симулятор, что означает, что он

00:10:38.030 --> 00:10:40.520
имеет полную лошадиную силу этого.

00:10:40.520 --> 00:10:45.320
Это нормально, что я делаю это
и профилирование его на моем устройстве,

00:10:45.320 --> 00:10:49.150
или это лучше сделать это на
физический iPhone, например?

00:10:49.150 --> 00:10:50.570
Хороший вопрос, потому что вы

00:10:50.570 --> 00:10:52.340
может делать различные виды профилирования.

00:10:52.340 --> 00:10:52.940
Интересно.

00:10:52.940 --> 00:10:54.230
Если вы профилируете процессор,

00:10:54.230 --> 00:10:56.480
это не очень хорошая идея
сделать это на симуляторе

00:10:56.480 --> 00:10:58.820
потому что у вас нет
полная мощность устройства.

00:10:58.820 --> 00:11:01.340
Но если вы делаете память
профайлер и распределение,

00:11:01.340 --> 00:11:04.355
Вы получите те же вопросы
на симуляторе и на устройстве.

00:11:04.355 --> 00:11:04.730
Идеально.

00:11:04.730 --> 00:11:10.300
Мне нравится делать это на ноутбуке
потому что он просто начинается быстрее.

00:11:10.300 --> 00:11:13.010
Он не переводит код

00:11:13.010 --> 00:11:16.085
в родной инструкции и просто
имитирует и работает мгновенно.

00:11:16.085 --> 00:11:18.470
Поэтому всякий раз, когда вы делаете профилирование памяти,

00:11:18.470 --> 00:11:20.180
если вы запустите приложения так много раз,

00:11:20.180 --> 00:11:23.045
так что вам понравится.

00:11:23.045 --> 00:11:25.085
Позволь мне сделать тот же тест.

00:11:25.085 --> 00:11:27.980
Так что я открыл страницу Подробности один раз,

00:11:27.980 --> 00:11:29.840
и вы видите этот небольшой пик здесь.

00:11:29.840 --> 00:11:33.590
Это означает, что мы увеличили наши
использование памяти значительно.

00:11:33.590 --> 00:11:35.915
Но вы не видите этого
память увеличивается здесь.

00:11:35.915 --> 00:11:38.510
Он по-прежнему, как самый большой объект

00:11:38.510 --> 00:11:40.730
систем ы дерева и где-то здесь.

00:11:40.730 --> 00:11:43.155
Позвольте мне сделать это еще несколько раз.

00:11:43.155 --> 00:11:45.815
Я увеличу его снова.

00:11:45.815 --> 00:11:47.610
Вы увидите всплеск здесь,

00:11:47.610 --> 00:11:49.735
но вы не видите никаких шипов здесь.

00:11:49.735 --> 00:11:53.330
Это означает, что, когда мы выделяем
в чем-то в родной памяти,

00:11:53.330 --> 00:11:56.220
он не отражает
это в управляемом мире,

00:11:56.220 --> 00:11:59.419
но мы видим, общая память
растет, а не дело,

00:11:59.419 --> 00:12:00.720
что самое главное.

00:12:00.720 --> 00:12:01.455
Я вижу.

00:12:01.455 --> 00:12:04.015
Мы возвращаемся с этим моментальным снимком.

00:12:04.015 --> 00:12:05.710
Моментальный снимок памяти фактически выполняется

00:12:05.710 --> 00:12:07.875
сбор мусора
на управляемом сайте.

00:12:07.875 --> 00:12:10.195
Итак, мы делаем этот снимок.
Я сделаю еще один.

00:12:10.195 --> 00:12:11.755
Я объясню это позже,

00:12:11.755 --> 00:12:14.500
иметь дело с доработкой кий.

00:12:14.500 --> 00:12:17.475
Но в основном, теперь это чистая память.

00:12:17.475 --> 00:12:19.605
Мы позаботимся о том, чтобы
наш сборщик мусора

00:12:19.605 --> 00:12:22.270
уже побежал и deallocated
весь приобретенный объект.

00:12:22.270 --> 00:12:23.920
Мы все еще видим воспоминания там.

00:12:23.920 --> 00:12:25.845
Так что он все еще пошел вниз.

00:12:25.845 --> 00:12:28.755
Чтобы знать, что здесь происходит,

00:12:28.755 --> 00:12:32.005
мы просто идем сюда и
использовать кнопку фильтра.

00:12:32.005 --> 00:12:35.265
Мы пытаемся определить
только R объектов,

00:12:35.265 --> 00:12:38.110
и я также хочу видеть на
живые объекты здесь.

00:12:38.110 --> 00:12:40.980
Так что я ударил этот "Применить"
кнопку, и вуаля,

00:12:40.980 --> 00:12:43.575
мы видим две детали контроллера
висит в памяти,

00:12:43.575 --> 00:12:47.160
хотя я не
иметь подробную информацию на месте.

00:12:47.160 --> 00:12:48.570
Супер образец, так что вы сказали:

00:12:48.570 --> 00:12:50.289
найти все в моем имени-пространства,

00:12:50.289 --> 00:12:51.610
фильтр на этом.

00:12:51.610 --> 00:12:54.820
Буквально то, что мы видим здесь
— контроллер представления детали 2.

00:12:54.820 --> 00:12:55.225
Да, да.

00:12:55.225 --> 00:12:56.650
Но она должна исчезнуть.

00:12:56.650 --> 00:13:00.015
Я начну с самого большого
объекты, которые у вас есть на этих страницах.

00:13:00.015 --> 00:13:00.280
Да, да.

00:13:00.280 --> 00:13:02.865
Это верно и для Android.

00:13:02.865 --> 00:13:04.030
Вы просто ищете действия,

00:13:04.030 --> 00:13:05.395
просматривать модели, или любой другой,

00:13:05.395 --> 00:13:07.875
потому что как только у вас есть вид
модель висит там,

00:13:07.875 --> 00:13:11.320
он начинает связывать все
другие объекты.

00:13:11.320 --> 00:13:13.380
Все услуги, все привязки,

00:13:13.380 --> 00:13:16.605
все UIs, и вы будете
получить много памяти.

00:13:16.605 --> 00:13:17.500
Получил его.

00:13:17.500 --> 00:13:19.465
Позвольте мне показать, что это правда.

00:13:19.465 --> 00:13:23.260
Я открою его еще один
время, нажмите на "Snapshot".

00:13:23.260 --> 00:13:25.455
Мы видим три примера здесь.

00:13:25.455 --> 00:13:28.569
Я возвращаюсь, ударяю "Snapshot",

00:13:28.569 --> 00:13:30.030
и он остается в памяти.

00:13:30.030 --> 00:13:30.660
Я поймала тебя.

00:13:30.660 --> 00:13:32.500
Так что давайте исправим эту проблему памяти.

00:13:32.500 --> 00:13:33.700
Я готов.

00:13:33.700 --> 00:13:36.470
Как бы вы это исправили?

00:13:41.220 --> 00:13:43.525
Это страница деталей,

00:13:43.525 --> 00:13:45.460
так что мы должны отписаться
на каком-то мероприятии.

00:13:45.460 --> 00:13:49.325
Я поймала тебя. Таким образом, реальная проблема здесь
я подписался на событие.

00:13:49.325 --> 00:13:49.970
Да, да.

00:13:49.970 --> 00:13:52.135
Тогда мы должны отписаться, не так ли?

00:13:52.135 --> 00:13:54.550
Это правильно. Это
является хорошей практикой.

00:13:54.550 --> 00:13:56.370
Всякий раз, когда вы видите это плюс равные,

00:13:56.370 --> 00:13:59.490
Вы просто искать, если
есть минус равный,

00:13:59.490 --> 00:14:01.980
если это не так, вы
должны ввести это.

00:14:01.980 --> 00:14:02.595
Получил его.

00:14:02.595 --> 00:14:05.020
Это первое указание
что у вас есть утечка памяти.

00:14:05.020 --> 00:14:05.340
Получил его.

00:14:05.340 --> 00:14:10.460
Единственное исключение– когда
Вы подписываетесь на главной странице,

00:14:10.460 --> 00:14:12.285
как наша главная страница здесь,

00:14:12.285 --> 00:14:14.725
и вы уверены, что эта страница

00:14:14.725 --> 00:14:18.010
не сможет пойти
в ближайшее время.

00:14:18.010 --> 00:14:20.115
Может быть, у вас есть это на
уровни делегата приложения.

00:14:20.115 --> 00:14:21.530
Ты как, я вообще-то
хочу, чтобы это было

00:14:21.530 --> 00:14:23.290
глобальное событие на все времена.

00:14:23.290 --> 00:14:25.845
Но также, возможно, когда ваше приложение
уходит на задний план,

00:14:25.845 --> 00:14:27.295
Вы также должны отписаться.

00:14:27.295 --> 00:14:28.345
Это правда.

00:14:28.345 --> 00:14:28.675
Да, да.

00:14:28.675 --> 00:14:29.700
Не выполнять.

00:14:29.700 --> 00:14:31.750
Так что теперь вы говорите,
когда он появляется,

00:14:31.750 --> 00:14:33.855
он будет подписаться, и исчезнут,

00:14:33.855 --> 00:14:35.935
отписаться, а затем вы
удалите один сверху.

00:14:35.935 --> 00:14:37.990
Да, я удалился из облака,

00:14:37.990 --> 00:14:39.710
потому что мы хотим
запустить его каждый раз, когда мы

00:14:39.710 --> 00:14:42.040
появляются и каждый раз, когда мы исчезаем.

00:14:42.040 --> 00:14:43.850
Плюс равный подписке,

00:14:43.850 --> 00:14:45.640
минус равен отпиской.

00:14:45.640 --> 00:14:48.735
Ничего сложного, просто хочу

00:14:48.735 --> 00:14:52.045
убедитесь, что нам не нужно каких-либо
инструменты, как только вы идете через него.

00:14:52.045 --> 00:14:52.720
Прохладный.

00:14:52.720 --> 00:14:55.110
Так что я делаю то же самое,

00:14:55.110 --> 00:14:59.490
идти к деталям,
показывая, что это правда.

00:14:59.490 --> 00:15:02.980
Снимок,
фильтр в мои события.

00:15:02.980 --> 00:15:05.300
Извините. Он просто нажал.

00:15:08.700 --> 00:15:12.170
Давайте посмотрим на живых объектах.

00:15:12.420 --> 00:15:15.345
Мы должны увидеть детали
потому что мы в настоящее время на

00:15:15.345 --> 00:15:17.475
подробности страницы. Мы возвращаемся.

00:15:17.475 --> 00:15:18.990
Мы попали в "Snapshot"

00:15:18.990 --> 00:15:20.880
и что мы ожидаем здесь?

00:15:20.880 --> 00:15:23.715
Во-первых, сбор мусора на самом деле

00:15:23.715 --> 00:15:26.065
положить эти объекты в
доработка кий,

00:15:26.065 --> 00:15:27.625
но второй должен кий 1,

00:15:27.625 --> 00:15:30.340
или, возможно, все тот же самый.

00:15:30.340 --> 00:15:31.570
Теперь он ушел.

00:15:31.570 --> 00:15:33.910
Да, да. Итак, позвольте мне поговорить о

00:15:33.910 --> 00:15:36.940
доработка кий в
во-вторых, но на данный момент,

00:15:36.940 --> 00:15:40.395
Идея заключается в том, что мы
потеряли наши детали зрения,

00:15:40.395 --> 00:15:43.135
и наше использование памяти спускается.

00:15:43.135 --> 00:15:43.770
Красивая.

00:15:43.770 --> 00:15:46.150
Вот как мы фиксируем утечки памяти.

00:15:46.150 --> 00:15:49.420
Да, да. Вы подписались на
События. Отписаться от событий.

00:15:49.420 --> 00:15:51.630
Основное правило.

00:15:51.630 --> 00:15:54.915
Это тоже очень смешно
потому что, во-впротив, это вызывает две проблемы.

00:15:54.915 --> 00:15:56.800
Мы видели, что ты держишь его в живых

00:15:56.800 --> 00:15:58.750
потому что эти события продолжают идти.

00:15:58.750 --> 00:16:00.715
Так что теперь вы стреляете
их несколько раз,

00:16:00.715 --> 00:16:04.290
но также, что-нибыдь на той странице
останется в памяти.

00:16:04.290 --> 00:16:06.685
Вот именно. Вот почему
мы добавили тяжелый образ,

00:16:06.685 --> 00:16:08.205
и это все еще в памяти.

00:16:08.205 --> 00:16:08.830
Получил его.

00:16:08.830 --> 00:16:10.570
Позвольте мне показать вам инструменты.

00:16:10.570 --> 00:16:13.390
Так что я собираюсь представить
обратно утечки памяти.

00:16:13.390 --> 00:16:13.800
Конечно же.

00:16:13.800 --> 00:16:15.985
Просто удалив неподписывающее событие.

00:16:15.985 --> 00:16:18.435
Я собираюсь развернуть на мой тренажер,

00:16:18.435 --> 00:16:21.330
и инструменты работают довольно легко.

00:16:21.330 --> 00:16:23.355
Вы просто выбрать цель из

00:16:23.355 --> 00:16:25.930
симулятор и
приложение, и это все.

00:16:25.930 --> 00:16:28.435
Это все, что вам нужно, чтобы начать
профайлер инструментов.

00:16:28.435 --> 00:16:30.175
Даже если это Xamarin App,

00:16:30.175 --> 00:16:32.150
Вы можете начать это право
из инструментов,

00:16:32.150 --> 00:16:33.615
который ничего не знает о Xamarin.

00:16:33.615 --> 00:16:35.310
Откуда берутся инструменты?

00:16:35.310 --> 00:16:38.709
Яблоко. Это Яблоко
инструмент, поставляется с Xcode,

00:16:38.709 --> 00:16:41.950
и он имеет много
инструментвнутренний внутри него.

00:16:41.950 --> 00:16:43.450
Так что это просто построено в
потому что у вас уже есть

00:16:43.450 --> 00:16:45.415
Xcode установлен? Сооо
у всех есть это?

00:16:45.415 --> 00:16:46.015
Это бесплатно.

00:16:46.015 --> 00:16:48.925
Это бесплатно. Классно. Так что любой
может использовать это прямо сейчас?

00:16:48.925 --> 00:16:53.880
Да, да. Вы можете на самом деле
видеть эти виды деятельности,

00:16:53.880 --> 00:16:57.920
даже несмотря на то, что те, созданные управляемыми
мир, как детали деятельности,

00:16:57.920 --> 00:17:00.525
она по-прежнему представлена
родным объектом.

00:17:00.525 --> 00:17:00.930
Получил его.

00:17:00.930 --> 00:17:02.855
Итак, давайте посмотрим на этот объект.

00:17:02.855 --> 00:17:07.240
Мы называем это Подробная информация Просмотр контроллера.

00:17:07.240 --> 00:17:09.595
Позвольте мне создать несколько из них.

00:17:09.595 --> 00:17:11.030
Это на самом деле
действительно здорово, потому что

00:17:11.030 --> 00:17:12.240
Я никогда не использовал инструменты,

00:17:12.240 --> 00:17:15.295
никому не говори, через несколько лет.

00:17:15.295 --> 00:17:18.440
Я не думаю, что все дают
мне деталь. Так она существует?

00:17:18.440 --> 00:17:20.070
Да, она существует.

00:17:20.070 --> 00:17:22.335
Это имеет смысл
потому что Xamarin является родным,

00:17:22.335 --> 00:17:23.770
таким образом, он создает родной объект.

00:17:23.770 --> 00:17:26.380
Да, да. Вам не нужно делать

00:17:26.380 --> 00:17:27.885
моментальный снимок памяти здесь

00:17:27.885 --> 00:17:29.975
потому что у нас нет
сбор мусора здесь.

00:17:29.975 --> 00:17:33.780
IOS использует иерархию, которая
автоматический счетчик ссылки.

00:17:33.780 --> 00:17:35.605
В основном, всякий раз, когда
вы создаете объект,

00:17:35.605 --> 00:17:37.065
это приращения счетчика,

00:17:37.065 --> 00:17:39.550
всякий раз, когда вы не используете или это

00:17:39.550 --> 00:17:42.505
уходит из сферы
использование, это decrements счетчика.

00:17:42.505 --> 00:17:43.845
Как только счетчик равен нулю,

00:17:43.845 --> 00:17:46.495
объект мусора, и
он может быть собран.

00:17:46.495 --> 00:17:48.075
Так что это довольно легко начать

00:17:48.075 --> 00:17:51.735
Инструменты с приложением
просто нажав на эту кнопку.

00:17:51.735 --> 00:17:53.505
Он запускает приложение,

00:17:53.505 --> 00:17:55.860
он показывает вам использование памяти здесь.

00:17:55.860 --> 00:17:57.690
Давайте откроем страницу Подробности.

00:17:57.690 --> 00:18:00.425
Я поймала тебя. Инструменты
исходит от Apple?

00:18:00.425 --> 00:18:02.040
Инструменты приходят от Apple.

00:18:02.040 --> 00:18:03.350
Это бесплатный инструмент от Apple.

00:18:03.350 --> 00:18:04.490
Вы можете использовать это прямо сейчас.

00:18:04.490 --> 00:18:05.390
Прохладный.

00:18:05.390 --> 00:18:06.970
Вы видите, что у нас также есть

00:18:06.970 --> 00:18:10.140
это память след право
здесь, как только мы открываем Подробная страница.

00:18:10.140 --> 00:18:12.120
Давайте откроем его еще раз.

00:18:12.120 --> 00:18:15.140
Так что это очень похоже
к профилировщику Xamarin,

00:18:15.140 --> 00:18:16.870
но это будет показывать нам

00:18:16.870 --> 00:18:19.240
родной стек для всех
намерений и целей.

00:18:19.240 --> 00:18:21.500
Вот именно. К сожалению,

00:18:21.500 --> 00:18:24.090
ничего не знает о
Xamarin и управляемый мир,

00:18:24.090 --> 00:18:27.025
так что вы не сможете увидеть
созданный им объект.

00:18:27.025 --> 00:18:28.990
Итак, вы видите всплеск,

00:18:28.990 --> 00:18:30.850
и вы видите, что это не проходит.

00:18:30.850 --> 00:18:33.350
Итак, позвольте мне сделать это в третий раз,

00:18:33.350 --> 00:18:35.145
и просто показать объекты.

00:18:35.145 --> 00:18:38.455
Так что давайте посмотрим. Существует
небольшая кнопка фильтра.

00:18:38.455 --> 00:18:43.170
Мы идем на все ассигнования здесь,

00:18:43.170 --> 00:18:45.165
и попал в "Подробности".

00:18:45.165 --> 00:18:45.820
Хорошо, хорошо.

00:18:45.820 --> 00:18:47.555
Это три страницы прямо здесь,

00:18:47.555 --> 00:18:48.660
они все в памяти,

00:18:48.660 --> 00:18:50.650
и они распределяют в памяти.

00:18:50.650 --> 00:18:54.070
Я не буду показывать, как мы deallocate
это потому, что это то же самое исправить,

00:18:54.070 --> 00:18:57.020
мы просто отписаться,
управляемый мир отписывается

00:18:57.020 --> 00:19:00.120
от объекта. Объекта
считается мусором.

00:19:00.120 --> 00:19:04.660
Тогда наш сборщик мусора
собирает эту информацию,

00:19:04.660 --> 00:19:06.460
затем родной может собирать
потому что ничего

00:19:06.460 --> 00:19:08.490
от управления миром
уже держась за это.

00:19:08.490 --> 00:19:10.780
Имеет смысл. Так что очень
так же исправить,

00:19:10.780 --> 00:19:12.255
но еще один способ обнаружить его.

00:19:12.255 --> 00:19:15.045
Вот именно. Так что это

00:19:15.045 --> 00:19:19.345
о различиях между
управляемый и родной мир.

00:19:19.345 --> 00:19:22.120
Мои следующие примеры будут
быть в основном о управляемых

00:19:22.120 --> 00:19:25.320
мир, потому что вы можете
ввести вопрос в любом,

00:19:25.320 --> 00:19:26.905
и это не связано с Xamarin.

00:19:26.905 --> 00:19:29.570
Как вы сказали, это может быть
подписка на статическое событие,

00:19:29.570 --> 00:19:32.745
он может ввести
вопрос даже в любом месте.

00:19:32.745 --> 00:19:35.410
Так что следующая вещь

00:19:35.410 --> 00:19:38.210
о подписке, и
без подписки.

00:19:38.210 --> 00:19:39.315
Но в этом случае,

00:19:39.315 --> 00:19:42.820
мы на самом деле
подписка неявно,

00:19:42.820 --> 00:19:44.480
мы не используем плюс равные.

00:19:44.480 --> 00:19:46.015
Так что это труднее найти.

00:19:46.015 --> 00:19:48.710
В этом случае мы запускаем этот
центр уведомлений пытается

00:19:48.710 --> 00:19:51.795
определить, когда наше приложение вращается.

00:19:51.795 --> 00:19:53.695
Добавим в этого наблюдателя.

00:19:53.695 --> 00:19:57.525
Это центр по умолчанию singleton.

00:19:57.525 --> 00:19:59.700
Мы говорим, что я хочу получить

00:19:59.700 --> 00:20:02.595
любая информация всякий раз, когда
ориентация изменилась,

00:20:02.595 --> 00:20:04.140
и вот мой обработчик для этого.

00:20:04.140 --> 00:20:04.650
Получил его.

00:20:04.650 --> 00:20:06.690
Сам обработчик,
это довольно легко.

00:20:06.690 --> 00:20:08.125
Мы там ничего не будем делать,

00:20:08.125 --> 00:20:11.665
Мы просто распечатаем его, чтобы отладить.

00:20:11.665 --> 00:20:12.465
Получил его.

00:20:12.465 --> 00:20:15.525
Позвольте мне удалить
подключение вещи, потому что

00:20:15.525 --> 00:20:18.630
мы хотим ввести различные
виды проблемы с памятью.

00:20:18.630 --> 00:20:21.525
Я также комментирую наши
изображение, потому что нам не нужно

00:20:21.525 --> 00:20:24.430
чтобы показать память
след, он есть.

00:20:24.430 --> 00:20:28.390
Мы будем экспериментировать только с
Контроллеры и представления пультов.

00:20:28.390 --> 00:20:30.650
Очень круто. Так что это
очень похож,

00:20:30.650 --> 00:20:32.870
но эта модель, вы
может быть подписка,

00:20:32.870 --> 00:20:34.605
может быть, даже прохождения в действии.

00:20:34.605 --> 00:20:38.340
Или в этом случае, что он делает
он говорит, вот ваш обратный вызов.

00:20:38.340 --> 00:20:40.010
Делегаты очень похожи,

00:20:40.010 --> 00:20:41.115
Я думаю, что эти модели.

00:20:41.115 --> 00:20:42.480
Так что это просто что-то
Я тоже привык.

00:20:42.480 --> 00:20:45.590
Вот именно. Это было

00:20:45.590 --> 00:20:47.864
их основная идея, потому что
когда вы подписываетесь,

00:20:47.864 --> 00:20:51.405
Вы проходите ссылку на
контроллер представления пули также.

00:20:51.405 --> 00:20:53.425
Это просто другой
способ передать ссылку.

00:20:53.425 --> 00:20:55.260
Иногда это не так очевидно.

00:20:55.260 --> 00:20:57.955
Итак, у нас есть подписка,
он работает здесь.

00:20:57.955 --> 00:20:59.305
Он работает только один раз.

00:20:59.305 --> 00:21:01.780
Давайте закроем и откроем его снова.

00:21:01.780 --> 00:21:03.525
Теперь у нас есть двойной щелчок.

00:21:03.525 --> 00:21:05.230
Позвольте мне ясно, чтобы показать вам это.

00:21:05.230 --> 00:21:07.240
Вращаясь один раз, получая два,

00:21:07.240 --> 00:21:11.655
что означает, что у нас есть uI View
Контроллер висит в памяти,

00:21:11.655 --> 00:21:13.535
в то же время обработка первого.

00:21:13.535 --> 00:21:13.980
Получил его.

00:21:13.980 --> 00:21:15.430
Это может быть проблемой, если у вас есть

00:21:15.430 --> 00:21:19.660
некоторые логики обновления базы данных
или запрос HTTP сверхурочно.

00:21:19.660 --> 00:21:21.340
Как и в день использования,

00:21:21.340 --> 00:21:24.810
ваше приложение не убит, вы
деактивировать, реактивировать.

00:21:24.810 --> 00:21:26.740
Он будет иметь все это
Просмотр неподвижно в памяти,

00:21:26.740 --> 00:21:28.265
и через неделю он может рухнет.

00:21:28.265 --> 00:21:28.785
Да, да.

00:21:28.785 --> 00:21:30.105
Так как же это исправить?

00:21:30.105 --> 00:21:31.550
Это очень просто.

00:21:31.550 --> 00:21:34.145
Я предполагаю, что вы отписаться?

00:21:34.145 --> 00:21:35.835
Вот именно. Это труднее

00:21:35.835 --> 00:21:38.685
отписаться, потому что вы
не имеют плюс равных.

00:21:38.685 --> 00:21:42.010
Позвольте мне показать также, что вы
на самом деле отправить сюда.

00:21:42.010 --> 00:21:43.365
Поэтому, когда вы подписываетесь,

00:21:43.365 --> 00:21:46.395
Вы проходите вверх по имени метода.

00:21:46.395 --> 00:21:48.215
Вы на самом деле проходите действие,

00:21:48.215 --> 00:21:51.745
и компилятор делает
большая работа, скрывая, что,

00:21:51.745 --> 00:21:54.150
и сделать нашу жизнь проще.

00:21:54.150 --> 00:21:55.945
Компилятор очень хороший.

00:21:55.945 --> 00:21:57.255
Очень хорошо к нам.

00:21:57.255 --> 00:22:00.415
Вот почему мы любим быть разработчиками.

00:22:00.415 --> 00:22:04.360
Так что на самом деле просит
действия с NSNotification.

00:22:04.360 --> 00:22:07.840
Так что я подписываю NSNotification здесь,

00:22:07.840 --> 00:22:13.365
а затем, используя эту нотацию,
вставки этого объекта.

00:22:13.365 --> 00:22:16.560
Таким образом, вместо названия метода,

00:22:16.560 --> 00:22:19.225
мы на самом деле прохождения
действие и объект,

00:22:19.225 --> 00:22:20.960
который содержит ссылку на

00:22:20.960 --> 00:22:23.610
эти метаданные о том, как
для вызова метода.

00:22:23.610 --> 00:22:26.555
Таким образом, мы не проходим метод,
это всего лишь ссылка.

00:22:26.555 --> 00:22:30.060
В нашем случае наиболее важные
часть при передаче этой ссылки,

00:22:30.060 --> 00:22:32.155
который является контроллером UIV,

00:22:32.155 --> 00:22:34.170
и именно поэтому он держится в памяти.

00:22:34.170 --> 00:22:35.260
Получил его.

00:22:35.260 --> 00:22:35.865
Хорошо, хорошо.

00:22:35.865 --> 00:22:36.670
Имеет смысл. Да.

00:22:36.670 --> 00:22:38.595
Я не буду показывать детали

00:22:38.595 --> 00:22:40.390
потому что память
утечка все еще там

00:22:40.390 --> 00:22:43.975
потому что мы видели эти
вещь, чтобы сэкономить некоторое время.

00:22:43.975 --> 00:22:45.500
Я хочу сосредоточиться на

00:22:45.500 --> 00:22:48.830
наихудший сценарий, который
Вы должны быть в курсе.

00:22:48.830 --> 00:22:54.250
Когда родной мир не место
красиво с управляемым миром.

00:22:54.250 --> 00:22:56.280
Я поймала тебя. Когда
сталкиваются два мира.

00:22:56.280 --> 00:23:00.265
Это правильно, потому что всякий раз, когда
мы управляли созданным объектом,

00:23:00.265 --> 00:23:02.155
и есть родной объект создан,

00:23:02.155 --> 00:23:05.690
и он / она пытается
дераспределение родных объектов,

00:23:05.690 --> 00:23:07.495
наш управляемый мир думает,

00:23:07.495 --> 00:23:09.330
Я до сих пор не закончил с этим объектом.

00:23:09.330 --> 00:23:11.270
Пожалуйста, держись, не надо

00:23:11.270 --> 00:23:13.765
собирать объект, потому что
Я все еще работаю с этим.

00:23:13.765 --> 00:23:14.525
Я поймала тебя.

00:23:14.525 --> 00:23:15.805
Это может быть напротив,

00:23:15.805 --> 00:23:19.130
когда родной мир
может создать объект,

00:23:19.130 --> 00:23:20.265
и теперь управляемый мир думает,

00:23:20.265 --> 00:23:22.450
это не сделано, по-прежнему
там, так что давайте держать.

00:23:22.450 --> 00:23:25.015
Даже если у вас нет других
ссылки на этот объект,

00:23:25.015 --> 00:23:29.015
он может держать его, он может
держать его не как мусор.

00:23:29.015 --> 00:23:29.820
Я поймала тебя.

00:23:29.820 --> 00:23:31.460
Я мог бы объяснить это с

00:23:31.460 --> 00:23:34.640
эти маленькие маленькие изображения
бессмертных объектов.

00:23:34.640 --> 00:23:37.230
Так что не создавайте бессмертных
Объектов. Это плохо.

00:23:37.230 --> 00:23:38.435
Это звучит круто.

00:23:38.435 --> 00:23:39.963
Да, да.

00:23:39.963 --> 00:23:43.355
Это происходит, когда вы
есть эти два мира.

00:23:43.355 --> 00:23:46.925
Родной, вы видите справа
родной контроллер представления и представления,

00:23:46.925 --> 00:23:49.640
и слева у вас есть

00:23:49.640 --> 00:23:52.580
управляемый мир C Sharp, который
Просмотр контроллеров и представлений.

00:23:52.580 --> 00:23:55.640
Всякий раз, когда вы не знаете, что
происходит на родном мире,

00:23:55.640 --> 00:23:58.070
Вы не можете собрать
это из этого мира.

00:23:58.070 --> 00:24:00.905
Я покажу вам один пример
как вы можете это сделать.

00:24:00.905 --> 00:24:03.275
Так что в моем примере,

00:24:03.275 --> 00:24:07.235
Я хочу добавить здесь небольшой
маленькая кнопка "Сохранить",

00:24:07.235 --> 00:24:11.375
и просто хочу, чтобы закрыть
Просмотр, как только пользователь попадает в это.

00:24:11.375 --> 00:24:13.925
Допустим, что
Кнопка "Сохранить" также будет делать

00:24:13.925 --> 00:24:17.330
некоторые сохранения логики базы данных
или HTTP вызывает все,

00:24:17.330 --> 00:24:19.055
он просто не возвращаясь

00:24:19.055 --> 00:24:22.145
и это на самом деле выполняет
некоторые дополнительные действия.

00:24:22.145 --> 00:24:22.775
Хорошо, хорошо.

00:24:22.775 --> 00:24:24.980
Как детали этой кнопки,

00:24:24.980 --> 00:24:26.300
мы посылаем в обработчик.

00:24:26.300 --> 00:24:31.205
Этот обработчик говорит, что
пожалуйста, закройте эти контроллер.

00:24:31.205 --> 00:24:33.395
- Выглядит совершенно законно для меня.

00:24:33.395 --> 00:24:35.255
Да, да. Мы представим
утечка памяти.

00:24:35.255 --> 00:24:36.230
Хорошо, хорошо.

00:24:36.230 --> 00:24:42.515
Ты плохой. К сожалению, это
и это общая картина.

00:24:42.515 --> 00:24:45.005
У нас нет
статическое событие, как здесь.

00:24:45.005 --> 00:24:47.195
У нас нет
один тон, как здесь.

00:24:47.195 --> 00:24:49.025
Мы просто держим эту кнопку здесь,

00:24:49.025 --> 00:24:51.650
это просто локальный элемент.

00:24:51.650 --> 00:24:54.260
Хорошо Джеймс, теперь мы
создал кнопку и

00:24:54.260 --> 00:24:56.735
мы хотим добавить его к
наш вид навигации.

00:24:56.735 --> 00:25:00.440
Таким образом, мы сказали в нем через
навигационный элемент также не используется

00:25:00.440 --> 00:25:05.225
любые статические ссылки ничего
как, что и только он.

00:25:05.225 --> 00:25:08.015
Теперь у нас есть кнопка подконье
и давайте начнем профайлер.

00:25:08.015 --> 00:25:09.890
Да и снова,
супер похожий шаблон.

00:25:09.890 --> 00:25:11.285
Я создаю кнопку,

00:25:11.285 --> 00:25:15.800
добавить кнопку, а затем я поп
Контроллер представления кажется нормальным.

00:25:15.800 --> 00:25:18.185
У вас есть делегат, который не использует

00:25:18.185 --> 00:25:20.540
любые внешние или статические ссылки

00:25:20.540 --> 00:25:23.225
и не проходит никакой ссылки
от нашего контроллера.

00:25:23.225 --> 00:25:23.750
Я поймала тебя.

00:25:23.750 --> 00:25:27.090
- Должен нормально работать,
Правильно? Давайте посмотрим.

00:25:27.280 --> 00:25:32.780
Так профайлер покажет объекты

00:25:32.780 --> 00:25:34.760
создан в самом начале, и я

00:25:34.760 --> 00:25:37.790
собирается начать отслеживать
их в самом начале.

00:25:37.790 --> 00:25:39.530
Так что я спрятал снимки право

00:25:39.530 --> 00:25:42.455
теперь и фильтрации только для моих объектов.

00:25:42.455 --> 00:25:45.380
Опять же очень часто
шаблон для устранения неполадок

00:25:45.380 --> 00:25:48.800
проблемы с памятью просто
видеть только мои объекты.

00:25:48.800 --> 00:25:52.235
Тогда я пошла один раз там.
Это моя кнопка.

00:25:52.235 --> 00:25:55.565
Видите ли, это новый контроль
красиво наше приложение.

00:25:55.565 --> 00:25:56.870
У нас есть это в памяти,

00:25:56.870 --> 00:25:58.745
что верно, мы ожидаем, что.

00:25:58.745 --> 00:26:03.410
Возвращаясь назад, давайте нажмем на одного
больше времени и еще раз.

00:26:03.410 --> 00:26:04.430
Еще раз, потому что я знаю.

00:26:04.430 --> 00:26:05.195
Еще раз.

00:26:05.195 --> 00:26:06.380
Хорошо, и до сих пор там.

00:26:06.380 --> 00:26:08.270
Еще раз, он все еще там.

00:26:08.270 --> 00:26:11.030
Так что давайте откроем его и намного больше раз.

00:26:11.030 --> 00:26:14.090
Давайте также закроем его
по-другому, возвращаясь назад,

00:26:14.090 --> 00:26:17.390
собирается сохранить, это на самом деле
в основном делают то же самое.

00:26:17.390 --> 00:26:20.090
Давайте хит "Память
снимок" еще один

00:26:20.090 --> 00:26:22.610
время и о вау мы
имеют пять экземпляров

00:26:22.610 --> 00:26:24.920
страниц висит там в
памяти, и если у вас есть

00:26:24.920 --> 00:26:28.130
огромное изображение там он
будет иметь много памяти

00:26:28.130 --> 00:26:28.550
Получил его.

00:26:28.550 --> 00:26:32.615
Так что это очень распространенная закономерность

00:26:32.615 --> 00:26:36.800
потому что не очевидно, что
у вас есть утечка памяти здесь.

00:26:36.800 --> 00:26:39.830
Вопрос здесь в том,
что UIBarButtonItem

00:26:39.830 --> 00:26:43.910
на самом деле держится
какой-то родной ресурс,

00:26:43.910 --> 00:26:45.485
он связан с родным ресурсом.

00:26:45.485 --> 00:26:49.100
Если мы не будем ясно говорить, что
Мне больше не нужна эта кнопка,

00:26:49.100 --> 00:26:51.020
Вы представите
этот бессмертный объект.

00:26:51.020 --> 00:26:53.135
Я поймала тебя. Так как же
Я решаю эту проблему?

00:26:53.135 --> 00:26:56.240
Для решения этой проблемы давайте

00:26:56.240 --> 00:26:59.900
наше событие ViewDisappear и
сделать что-то с нашей кнопкой.

00:26:59.900 --> 00:27:00.150
Хорошо, хорошо.

00:27:00.150 --> 00:27:01.220
Итак, у нас есть два варианта,

00:27:01.220 --> 00:27:02.735
мы могли бы использовать либо

00:27:02.735 --> 00:27:05.299
Нажмите событие и
подписаться и отписаться,

00:27:05.299 --> 00:27:07.160
но мы вернемся к

00:27:07.160 --> 00:27:10.400
наш первый пункт, когда мы подписываемся
без подписки.

00:27:10.400 --> 00:27:12.560
Давайте сделаем что-нибудь более интересное.

00:27:12.560 --> 00:27:14.030
Мы просто утилизуем кнопку.

00:27:14.030 --> 00:27:15.680
Мне это нравится. Я
сделали с ним, не так ли?

00:27:15.680 --> 00:27:18.320
Да, мы как бы говорим
управляемый мир, который,

00:27:18.320 --> 00:27:20.495
"Я сделал с кнопкой
пожалуйста, распоряжаться его ".

00:27:20.495 --> 00:27:24.365
Это не очевидно, потому что
много просмотров и оберток

00:27:24.365 --> 00:27:26.540
в Xamarin IOS есть
этот метод распоряжаться и

00:27:26.540 --> 00:27:29.015
Вы действительно не знаете, когда
Вы должны назвать это.

00:27:29.015 --> 00:27:30.815
Так что это интересный случай.

00:27:30.815 --> 00:27:32.975
Но давайте сделаем это и убежим.

00:27:32.975 --> 00:27:34.700
Это единственное действие, которое я добавил

00:27:34.700 --> 00:27:37.500
так как предыдущий запуск приложения.

00:27:38.290 --> 00:27:42.530
Я начинаю профайлер
и делать тот же случай использования.

00:27:42.530 --> 00:27:44.000
Мы собираемся отслеживать объекты от

00:27:44.000 --> 00:27:46.310
самого начала и сделать
уверен, что они расположены.

00:27:46.310 --> 00:27:48.050
Очень круто. Это мило.

00:27:48.050 --> 00:27:49.670
Чтобы ты мог, как ты и сказал,

00:27:49.670 --> 00:27:53.270
вместо прохождения
что все действия в,

00:27:53.270 --> 00:27:55.130
Вы можете просто похоже на то, как мы

00:27:55.130 --> 00:27:57.605
делать Связь,
подписаться, отписаться,

00:27:57.605 --> 00:28:00.590
Я бы понял это
из, но в этом случае,

00:28:00.590 --> 00:28:03.125
Вы уже сделали это так
Вы просто избавиться от него.

00:28:03.125 --> 00:28:04.010
Вот именно.

00:28:04.010 --> 00:28:04.875
Прохладный.

00:28:04.875 --> 00:28:08.455
Да, потому что мы не
ожидать, что он будет отпиской.

00:28:08.455 --> 00:28:10.840
Это не подписка,

00:28:10.840 --> 00:28:14.230
мы просто пройти и делегировать
внутри локального объекта.

00:28:14.230 --> 00:28:16.045
В случае NotificationCenter,

00:28:16.045 --> 00:28:18.790
это своего рода подписка, потому что
мы проходим в местный объект

00:28:18.790 --> 00:28:21.760
в некоторых статических
экземпляр или синглтон.

00:28:21.760 --> 00:28:24.760
В этом случае мы просто использовали
в наших местных ресурсах,

00:28:24.760 --> 00:28:26.395
мы не ожидаем утечки памяти.

00:28:26.395 --> 00:28:26.680
Я поймала тебя.

00:28:26.680 --> 00:28:28.630
Но, к сожалению, я вижу,

00:28:28.630 --> 00:28:32.660
этот барьер много, и люди
попасть в такие ситуации.

00:28:32.680 --> 00:28:37.530
Так что давайте делать тот же трюк.

00:28:37.750 --> 00:28:41.760
Я желаю что оно смогло сохранить эти данные.

00:28:41.950 --> 00:28:46.310
Таким образом, у нас есть только один вид
Контроллер и делегат.

00:28:46.310 --> 00:28:48.290
Давайте ударить "Сохранить".

00:28:48.290 --> 00:28:51.215
Давай вернемся.

00:28:51.215 --> 00:28:54.005
Давайте на самом деле остаться на странице деталей.

00:28:54.005 --> 00:28:56.975
Хит "Память снимок", и мы видим один.

00:28:56.975 --> 00:28:59.315
Позвольте мне нажать на него еще несколько раз.

00:28:59.315 --> 00:29:02.735
Мы поговорим об этом. Таким образом, мы
есть только один экземпляр здесь.

00:29:02.735 --> 00:29:10.805
Я нажимаю кнопку "Сохранить", нажмите "Снимок"
и он исчезает сканирование.

00:29:10.805 --> 00:29:12.380
Хорошо? Утечка памяти исправлена.

00:29:12.380 --> 00:29:13.250
Очень круто. Хороший.

00:29:13.250 --> 00:29:14.900
Бессмертный объект был убит.

00:29:14.900 --> 00:29:16.445
Убит. Очень круто.

00:29:16.445 --> 00:29:17.810
В противном случае, это огромная.

00:29:17.810 --> 00:29:20.600
Так просто, посмотрите на ваши события,

00:29:20.600 --> 00:29:22.850
но и посмотрите на то, как вы проходите

00:29:22.850 --> 00:29:24.890
эти действия вокруг, и даже я

00:29:24.890 --> 00:29:26.870
не будет даже думать о том, что
кнопка, чтобы быть честным с вами

00:29:26.870 --> 00:29:29.315
потому что конструктор
проходит эту вещь.

00:29:29.315 --> 00:29:29.600
Да, да.

00:29:29.600 --> 00:29:30.725
Очень круто.

00:29:30.725 --> 00:29:33.350
Я также рекомендовал бы

00:29:33.350 --> 00:29:36.425
наши разработчики, чтобы использовать его более
часто, как раз в неделю,

00:29:36.425 --> 00:29:39.545
каждый спринт, а затем
увидеть использование памяти,

00:29:39.545 --> 00:29:41.585
вы можете увидеть его как тестовый запуск uI.

00:29:41.585 --> 00:29:45.590
Он показывает этот маленький
памяти рабочий набор.

00:29:45.590 --> 00:29:48.050
Таким образом, вы просто видите более
месяцев, если он растет или

00:29:48.050 --> 00:29:51.530
нет, и если он растет вы
вероятно, есть утечка памяти.

00:29:51.530 --> 00:29:53.360
Вы показали iOS.

00:29:53.360 --> 00:29:54.560
Теперь как насчет для Android?

00:29:54.560 --> 00:29:57.500
Есть ли какие-либо конкретные другие
инструменты там, которые вы можете использовать?

00:29:57.500 --> 00:29:59.465
Это большой вопрос
потому что, Android,

00:29:59.465 --> 00:30:02.000
все, о чем мы говорили
iOS применяется для Android.

00:30:02.000 --> 00:30:02.150
Я поймала тебя.

00:30:02.150 --> 00:30:03.440
Просто иметь другой инструмент для

00:30:03.440 --> 00:30:07.145
Android родной профилировщик
называется Android Profiler.

00:30:07.145 --> 00:30:08.390
Это действительно здорово.

00:30:08.390 --> 00:30:09.740
Это показывает вам много

00:30:09.740 --> 00:30:12.380
информации, но у вас есть еще
придется использовать его, кто

00:30:12.380 --> 00:30:14.330
Профайлер Xamarin в сочетании

00:30:14.330 --> 00:30:16.790
из-за управляемых
мира и родного мира.

00:30:16.790 --> 00:30:17.930
Я поймала тебя. Это просто

00:30:17.930 --> 00:30:19.340
звуки было здорово, что
есть отличные инструменты

00:30:19.340 --> 00:30:22.400
доступны независимо от того, где
Вы находитесь в, iOS, Android.

00:30:22.400 --> 00:30:23.240
Это верно.

00:30:23.240 --> 00:30:24.005
Я могу пойти дальше и сделать это.

00:30:24.005 --> 00:30:25.820
Честно говоря, просто глядя
в некоторых из них,

00:30:25.820 --> 00:30:28.160
Я уверен, что мой код,
есть много плохих вещей.

00:30:28.160 --> 00:30:29.480
Поэтому, когда я поток следующий,

00:30:29.480 --> 00:30:31.790
это будет все
фиксации моей памяти утечки.

00:30:31.790 --> 00:30:32.180
Хорошо, хорошо.

00:30:32.180 --> 00:30:34.280
Очень круто. Все остальное Алекси
что вы хотите поговорить о?

00:30:34.280 --> 00:30:35.315
Все это на сегодня.

00:30:35.315 --> 00:30:37.865
Awesome. Ну, спасибо
все для настройки дюйма

00:30:37.865 --> 00:30:40.010
Алекси, большое спасибо за
появляется все эти вещи.

00:30:40.010 --> 00:30:42.305
Спасибо, ребята. Благодарю
Вы Джеймс за то, что позволили мне.

00:30:42.305 --> 00:30:43.970
Абсолютно, и убедитесь, что

00:30:43.970 --> 00:30:45.920
что вы проверить все
шоу отмечает ниже,

00:30:45.920 --> 00:30:47.420
открыть все источники
код, все ссылки

00:30:47.420 --> 00:30:48.980
для всей документации там.

00:30:48.980 --> 00:30:51.740
Вы также можете пойти в aka.ms/Xamarin

00:30:51.740 --> 00:30:54.485
лучшие практики для всей серии.

00:30:54.485 --> 00:30:55.790
Поэтому убедитесь, что вы подписаться

00:30:55.790 --> 00:30:57.695
сегодня, где бы вы ни находились
смотреть прямо сейчас.

00:30:57.695 --> 00:30:59.090
Я Джеймс Монтемагно.

00:30:59.090 --> 00:31:01.790
Это был Xamarin
Показать и спасибо за просмотр.

00:31:01.790 --> 00:31:02.480
Спасибо, ребята.

00:31:02.480 --> 00:31:09.230
(МУЗЫКА)

00:31:09.230 --> 00:31:11.120
Эй, Джеймс здесь.
Просто хотел зарегистрироваться

00:31:11.120 --> 00:31:13.175
и благодарю вас за
смотреть это видео.

00:31:13.175 --> 00:31:16.265
Теперь делайте все, что вы
знаю, что вы хотите сделать такие, как, как,

00:31:16.265 --> 00:31:18.710
подписаться, и динь
что уведомление колокола,

00:31:18.710 --> 00:31:20.825
стать частью
уведомительный отряд.

00:31:20.825 --> 00:31:22.190
Пока вы здесь, проверить

00:31:22.190 --> 00:31:25.400
все эти удивительные видео
что я уже закодирован.

00:31:25.400 --> 00:31:29.040
Нажмите на эту штуку. Нажмите
это, смотреть его, сделать это.