Как работает Appcelerator Titanium Mobile?
Для последней версии MySQL
default-character-set = utf8
вызывает проблему.
Как говорится в , Джастин Бал говорит в « Обновление до MySQL 5.5.12, и теперь MySQL не запустится , вы должны:
- Удалите эту директиву, и вы должны быть хорошими.
- Тогда ваш файл конфигурации (например, /etc/my.cnf) должен выглядеть так:
[mysqld] collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8 - Перезагрузите MySQL.
- Для обеспечения того, что ваш MySQL является UTF-8, запустите в запросе MySQL следующие запросы: Первый запрос:
Результат должен выглядеть так:mysql> show variables like 'char%';
Второй запрос:+--------------------------+---------------------------------+ | Variable_name | Value | +--------------------------+---------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/charsets/| +--------------------------+---------------------------------+
И вывод запроса:mysql> show variables like 'collation%';+----------------------+-----------------+ | Variable_name | Value | +----------------------+-----------------+ | collation_connection | utf8_general_ci | | collation_database | utf8_unicode_ci | | collation_server | utf8_unicode_ci | +----------------------+-----------------+
2 ответа
Titanium принимает ваш Javascript код, анализирует и предварительно обрабатывает его, а затем предварительно компилирует в набор символов, которые определяются на основе ваших приложений, использующих API-интерфейсы Titanium. Из этой иерархии символов мы можем построить матрицу зависимостей символов, которая сопоставляется с символами базовой библиотеки Titanium, чтобы понять, какие API (и связанные зависимости, фреймворки и т. Д.) Конкретно нужны вашему приложению. Я использую слово «символ» в полуобщем виде, так как оно немного отличается в зависимости от языка. В iPhone символ отображается на настоящий символ C, который в конечном итоге отображается на скомпилированный файл .o, который был скомпилирован для архитектур ARM / i386. Что ж, для Java это более или менее файл .class и т. Д. Как только внешний интерфейс сможет понять вашу матрицу зависимостей, мы затем вызываем компилятор SDK (например, GCC для iPhone, Java для Android), чтобы затем скомпилировать ваше приложение в окончательный вариант. собственный двоичный файл.
Итак, простой способ думать об этом - это то, что ваш код JS скомпилирован почти один к одному в репрезентативные символы в родной стране.Интерпретатор все еще работает в интерпретируемом режиме, иначе такие вещи, как динамический код, не будут работать. Однако он намного быстрее, намного компактнее и максимально приближен к чистому нативному отображению.
Очевидно, что у нас еще много возможностей для улучшения и работы над этим. Пока что в нашем последнем тестировании 1.0 он почти неотличим от того же прямого кода objective-c (поскольку в большинстве случаев он точно соответствует этому). С точки зрения CompSci, теперь мы можем начать оптимизировать вещи, которые человеку действительно не под силу сделать - во многом так же, как компилятор GCC уже делает это сегодня.
Если я упакую свой простой объемный код, я получу gzip-архив размером ~ 80 МБ (исходный код ~ 1 КБ). В пакете - среди прочего - вы можете найти мои исходные файлы html и js. Также с пакетом поставляется множество библиотек (например, ssl) (потому что вы можете иметь низкоуровневый доступ к большому количеству вещей в этих рамках).
Думаю, они берут ваш код и оборачивают его вокруг какого-то программного обеспечения и библиотек для интерпретатора. В моем случае это было бы похоже на то, если бы я упаковал свой код html и js рядом с крошечным браузером, который отображает только мои сайт.
Однако пока код работает в каждой поддерживаемой системе одинаково, это хорошо.