Камышев Александр

Раньше тоже пользовался продуктами devart, хоть и недорогие, удобные, надежные, но все же они платные, плюс вообще не люблю подключать сторонние компоненты. 
На oldschool теплом ламповом CBuilder приходилось много всего подключать: скины, компоненты доступа к бд, инди последних версий, компоненты для отчетов, png и т.п. С тех пор стараюсь избегать всего не родного.
FireDAC понравился, хорош CmdExecMode amAsync - The calling thread and GUI are not blocked. The called method will return immediately.
Позволяет работать с базой из основного потока без завешивания, отправил запрос и занимайся другими задачами пока callback не придет.

Раньше тоже пользовался продуктами devart, хоть и недорогие, удобные, надежные, но все же они платные, плюс вообще не люблю подключать сторонние компоненты. 
На oldschool теплом ламповом CBuilder приходилось много всего подключать: скины, компоненты доступа к бд, инди последних версий, компоненты для отчетов, png и т.п. С тех пор стараюсь избегать всего не родного.
FireDAC понравился, хорош CmdExecMode amAsync - The calling thread and GUI are not blocked. The called method will return immediately.
Позволяет работать с базой из основного потока без завешивания, отправил запрос и занимайся другими задачами пока callback не придет.

Раньше тоже пользовался продуктами devart, хоть и недорогие, удобные, надежные, но все же они платные, плюс вообще не люблю подключать сторонние компоненты. 
На oldschool теплом ламповом CBuilder приходилось много всего подключать: скины, компоненты доступа к бд, инди последних версий, компоненты для отчетов, png и т.п. С тех пор стараюсь избегать всего не родного.
FireDAC понравился, хорош CmdExecMode amAsync - The calling thread and GUI are not blocked. The called method will return immediately.
Позволяет работать с базой из основного потока без завешивания, отправил запрос и занимайся другими задачами пока callback не придет.

Может быть так? (правда код на Delphi)

печалька 
ошибка та же? если сборке не указать APP_ABI := x86 собирается четыре папки: arm64-v8a, mips64, x86 и x86-64
arm и x86-64 вот libs.zip
попробовать библиотеки 86-64 и для чистоты эксперимента arm из этой сборки, mips думаю не нужен

Так рассуждая, можно вообще до низов дойти
Просто если у вас http - то я на текущий момент ничего лучше чем mORMot-ы не нашел. Да и не искал, если честно. Стабильность работы - 101%, в отличие от Indy и Synapse (до этого работал только с ними).
А вот если TCP (своя надстройка над ним), то тут уже есть варианты. Но индейцы все равно в пролете, как и ScktComp.pas в режиме stBlocking.
Всё вышесказанное - imho.

MS - это Microsoft.
http.sys и великолепная надстройка над ним в виде THttpApiServer из состава mORMot. Естественно - заточено только под Windows.

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

чем плох стандартный TLang? свойство
AutoSelect=True - автоматическое определение языка и StoreInForm=True - хранить в ресурсах
использую TLang для статичных строк и вот такой код для статусов и сообщений:
String LangString( unsigned int code, AnsiString lang ) { if ( lang == "RU" ) switch( code ) { case 0: return (AnsiString)"Ожидание"; case 60: return (AnsiString)" не выполнено"; case 61: return (AnsiString)" выполнено успешно"; } else if ( lang == "EN" ) switch( code ) { case 0: return "Waiting"; case 60: return " not completed"; case 61: return " completed successfully"; } return "";  

чем плох стандартный TLang? свойство
AutoSelect=True - автоматическое определение языка и StoreInForm=True - хранить в ресурсах
использую TLang для статичных строк и вот такой код для статусов и сообщений:
String LangString( unsigned int code, AnsiString lang ) { if ( lang == "RU" ) switch( code ) { case 0: return (AnsiString)"Ожидание"; case 60: return (AnsiString)" не выполнено"; case 61: return (AnsiString)" выполнено успешно"; } else if ( lang == "EN" ) switch( code ) { case 0: return "Waiting"; case 60: return " not completed"; case 61: return " completed successfully"; } return "";  

компиляция шла около часа, вот если кому нннада файлы библиотек
x86.zip

что ж теперь не пользоваться indy? ssl и в других проектах пригодится, вот тут про сборку https://habrahabr.ru/company/intel/blog/271013/
Библиотеки OpenSSL

Рассмотрим сборку библиотек OpenSSL для Android-устройств, построенных на базе архитектуры x86.
 
Предварительная подготовка

Для дальнейшей работы нам понадобится следующее.
 
Главный компьютер, работающий под управлением ОС Windows 7 или более поздней.
  Так как библиотеки OpenSSL написаны на чистом C, для сборки будет достаточно Android NDK, в который встроена поддержка для кросс-компиляции библиотек для заданных платформ (ARM, x86 и других).
Исходный код библиотек OpenSSL для Android можно загрузить из репозиториев eighthave или guardianproject.
 
Сборка для платформы x86

Выбрать целевую платформу сборки можно так же, как и для любого другого Android-приложения, используя установки Application Binary Interface (ABI). В нашем случае в файле jni/Application.mk должно присутствовать следующее:
 
APP_ABI := x86
Итак, после того, как NDK загружен и установлен, исходный код Android OpenSSL так же загружен и размещён в локальной папке (например, в C:\openssl-android-master), для сборки библиотек нужно будет сделать следующее.
 
Откройте окно командной строки (cmd.exe). Перейдите в папку, где расположены файлы OpenSSL для Android. Например, такой командой:
Не забудьте указать для сборки целевую платформу x86:
 
APP_ABI := x86
Выполните команду NDK для запуска сборки:
 
C:\openssl-android-master > ndk-build
После её успешного завершения будут созданы OpenSSL-библиотеки libssl и libcrypto, расположенные, в нашем случае, здесь:
 
C:\openssl-android-master\libs\x86\libcrypto.so C:\openssl-android-master\libs\x86\libssl.so

program Project1; uses System.StartUpCopy, FMX.Forms, FMX.Types, Unit1 in 'Unit1.pas' {Form1}; {$R *.res} begin GlobalUseDXInDX9Mode := True; Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end.  

program Project1; uses System.StartUpCopy, FMX.Forms, FMX.Types, Unit1 in 'Unit1.pas' {Form1}; {$R *.res} begin GlobalUseDXInDX9Mode := True; Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end.  

extern "C" int FMXmain() { try { GlobalUseDXInDX9Mode = true; Application->Initialize(); Application->CreateForm(__classid(TdmSUHttpClient), &dmSUHttpClient); Application->CreateForm(__classid(TForm1), &Form1); Application->Run(); } не заметил тормозов и проблем, работает вроде,
это конечно не графический движок современной видеоигры...
по теме должно помочь

Можно и перевести в режим GDI+

Берлин не виноват, ошибку возвращает WinAPI, кроме драйверов видео и DirectX ничего и не сделать, разве что DLL попробовать подсунуть.
В oldschool VCL не было обращений к directx, там были GDI и GDIplus,
а FMX видимо графику сразу по-взрослому рисует в 3d.

procedure TForm2.SpinBox1ChangeTracking(Sender: TObject); begin   SpinBox1.Value := SpinBox1.Text.ToExtended; end;  

Дебаггер не используете что ли? Тупо брикпоинт на OnShow и по шагам идти до ошибки - F7,F8,F9 в помощь

крайние ситуации требуют крайних мер

у ZuBy есть DeviceInfo, может он подскажет. http://fire-monkey.ru/topic/1762-deviceinfo-modul-dlya-polucheniya-informacii-o-devayse/?do=findComment&comment=14057 - очень полезная разработка
есть System.SysUtils.TOSVersion.TArchitecture, в винде показывает х64, в андроид с arm у меня пустые поля, на x86 наверно покажет. http://docwiki.embarcadero.com/Libraries/XE5/en/System.SysUtils.TOSVersion.TArchitecture
в реализации можно так: 
String docs_path = System::Ioutils::TPath::GetDocumentsPath(); if ( atom ) IdOpenSSLSetLibPath( docs_path + "/lib_atom/" ); else if ( arm ) IdOpenSSLSetLibPath( docs_path + "/lib_arm/" ); else {} отдельный APK для x86 - неизящно
 
 
 
 

компиляция шла около часа, вот если кому нннада файлы библиотек
x86.zip

компиляция шла около часа, вот если кому нннада файлы библиотек
x86.zip

скачал в c:/openssl-android-master исходники,
скачал AndroidNDK в d:\ndk\
исправил jni/Application.mk:
APP_PROJECT_PATH := $(shell pwd)
APP_BUILD_SCRIPT := c:/openssl-android-master/Android.mk
APP_ABI := x86
далее в cmd:
C:\Windows\system32>cd c:\openssl-android-master
c:\openssl-android-master>d:\ndk\ndk-build
process_begin: CreateProcess(NULL, pwd, ...) failed.
Android NDK: WARNING:c:/openssl-android-master/crypto/Android.mk:crypto_
LOCAL_LDLIBS is always ignored for static libraries
[x86] Compile        : crypto <= cryptlib.c
c:/openssl-android-master/crypto/cryptlib.c: In function 'CRYPTO_THREADI
t':
c:/openssl-android-master/crypto/cryptlib.c:503:34: warning: passing arg
of 'CRYPTO_THREADID_set_pointer' discards 'volatile' qualifier from poin
et type
  CRYPTO_THREADID_set_pointer(id, &errno);
                                  ^
c:/openssl-android-master/crypto/cryptlib.c:431:6: note: expected 'void
rgument is of type 'volatile int *'
 void CRYPTO_THREADID_set_pointer(CRYPTO_THREADID *id, void *ptr)
      ^
[x86] Compile        : crypto <= mem.c
[x86] Compile        : crypto <= mem_clr.c
[x86] Compile        : crypto <= mem_dbg.c
минут 10 уже компилит, жду результата

что ж теперь не пользоваться indy? ssl и в других проектах пригодится, вот тут про сборку https://habrahabr.ru/company/intel/blog/271013/
Библиотеки OpenSSL

Рассмотрим сборку библиотек OpenSSL для Android-устройств, построенных на базе архитектуры x86.
 
Предварительная подготовка

Для дальнейшей работы нам понадобится следующее.
 
Главный компьютер, работающий под управлением ОС Windows 7 или более поздней.
  Так как библиотеки OpenSSL написаны на чистом C, для сборки будет достаточно Android NDK, в который встроена поддержка для кросс-компиляции библиотек для заданных платформ (ARM, x86 и других).
Исходный код библиотек OpenSSL для Android можно загрузить из репозиториев eighthave или guardianproject.
 
Сборка для платформы x86

Выбрать целевую платформу сборки можно так же, как и для любого другого Android-приложения, используя установки Application Binary Interface (ABI). В нашем случае в файле jni/Application.mk должно присутствовать следующее:
 
APP_ABI := x86
Итак, после того, как NDK загружен и установлен, исходный код Android OpenSSL так же загружен и размещён в локальной папке (например, в C:\openssl-android-master), для сборки библиотек нужно будет сделать следующее.
 
Откройте окно командной строки (cmd.exe). Перейдите в папку, где расположены файлы OpenSSL для Android. Например, такой командой:
Не забудьте указать для сборки целевую платформу x86:
 
APP_ABI := x86
Выполните команду NDK для запуска сборки:
 
C:\openssl-android-master > ndk-build
После её успешного завершения будут созданы OpenSSL-библиотеки libssl и libcrypto, расположенные, в нашем случае, здесь:
 
C:\openssl-android-master\libs\x86\libcrypto.so C:\openssl-android-master\libs\x86\libssl.so