Лидеры

Ссылка: http://delphifmandroid.blogspot.ru/2016/09/delphi-android.html Автор: Андрей Ефимов Описание: Это маленькая заметка о том, какие события происходят, когда мы запускаем приложение на Android. В ней я покажу логи из LogCat (с описанием тестов, которые провёл) и мы выясним, какие же события происходят всегда, а какие нет.

И телепаты сразу угадали, что это за ошибка, и дали четкий и исчерпывающий ответ на все поставленные (и не поставленные) вопросы.

На Android штатный менеджер памяти не отслеживает утечки.

Windows, FMX Возможно не совсем в тему форума, вопрос по архитектуре серверных служб, хотелось бы услышать мнения. Ситуация: IdHTTTPServer на каждый запрос создает поток, в этом потоке не обойтись без обращения к пулу данных в памяти. Пул - несколько наборов актуальных данных. Наборы данных асинхронно получаются из БД, имеют связи многие ко многим, один ко многим и периодически кэшируются в память в основном потоке. Т.к. обращение к пулу из потока - соответственно пул должен быть потокозащищенным. После обработки запроса, данные также отправляются в основном потоке в очередь БД. 1. Если весь пул закрыть в TCriticalSection - то на время использования его одним потоком все остальные будут ожидать. Обращение к очереди БД из потока получается также должно быть потокозащищенным. Не изящно. 2. Можно задачу обработки положить в некую потокозащищенную очередь и остановить поток c помощью TSimpleEvent->WaitFor( INFINITE ). Далее в основном потоке работать с пулом данных и очередью БД без критических сессий и, после получения результата, запустить поток SetEvent(). Код будет проще и понятней, однако задачи будут выполняться синхронно, последовательно как и в первом случае. 3. Можно закрывать TCriticalSection отдельные наборы данных, это возможно несколько увеличит быстродействие (не факт!), усложнит код и увеличит вероятность deadlock, т.к. для обработки одного запроса используется несколько наборов данных. Deadlock не будет, если перед обращением к следующему набору ( critical_section->Enter() ) копировать что необходимо из предыдущего и отпускать его ( critical_section->Leave() ) - тут становится важна стоимость операторов копирования.При больших объемах, стоимость копирования может перекрыть весь профит от частного обращения к наборам. TThread полезно использовать при длительных операциях ввода вывода и ресурсоемких операциях, т.е. когда нужно подождать, не останавливая основной поток. Выигрыша в производительности полагаю нет, к тому же переключения критических секций также имеют стоимость. Вопросы: 1. Какой вариант предпочтительней? Есть стандартные схемы? 2. Как влияет количество ядер, процессоров, на быстродействие во втором и третьем случае?

ждать следующий релиз, там будет z-order вроде правильный для нативных и стилизованных

Актуальны :-)

cherezovmax, uses AndroidApi.Log, // LOGI Androidapi.Timer, ... private { Private declarations } FTimerHandle: integer; FTimerCounter: integer; TimerInterval: integer; procedure StartTimer; procedure WaitComplete(TimerId: Integer); ... procedure TDM.AndroidServiceCreate(Sender: TObject); begin FTimerHandle := AndroidTimerCreate; FTimerCounter := 0; TimerInterval:=5000; end; function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin StartTimer; LogI('TJService.JavaClass.START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; procedure TDM.StartTimer; begin LogI('... timer to be started'); AndroidTimerSetInterval(FTimerHandle, TimerInterval); AndroidTimerSetHandler(WaitComplete); LogI('+ Timer started'); end; procedure TDM.WaitComplete(TimerId: Integer); begin LogI('WaitComplete procedure') end;