Почему эмулятор Android такой медленный? Как мы можем ускорить эмулятор Android? [закрыто]
Чтобы преобразовать numpy.datetime64 в объект datetime, который представляет время в UTC на numpy-1.8:
>>> from datetime import datetime
>>> import numpy as np
>>> dt = datetime.utcnow()
>>> dt
datetime.datetime(2012, 12, 4, 19, 51, 25, 362455)
>>> dt64 = np.datetime64(dt)
>>> ts = (dt64 - np.datetime64('1970-01-01T00:00:00Z')) / np.timedelta64(1, 's')
>>> ts
1354650685.3624549
>>> datetime.utcfromtimestamp(ts)
datetime.datetime(2012, 12, 4, 19, 51, 25, 362455)
>>> np.__version__
'1.8.0.dev-7b75899'
В приведенном выше примере предполагается, что наивный объект datetime интерпретируется np.datetime64 как время в UTC .
Чтобы преобразовать datetime в np.datetime64 и назад (numpy-1.6):
>>> np.datetime64(datetime.utcnow()).astype(datetime)
datetime.datetime(2012, 12, 4, 13, 34, 52, 827542)
Он работает как на одном объекте np.datetime64, так и на массиве numpy из np.datetime64.
Подумайте о np.datetime64 так же, как и о np.int8, np.int16 и т. д. и примените те же методы для преобразования между объектами Python, такими как int, datetime и соответствующий numpy объекты.
Ваш «неприятный пример» работает правильно:
>>> from datetime import datetime
>>> import numpy
>>> numpy.datetime64('2002-06-28T01:00:00.000000000+0100').astype(datetime)
datetime.datetime(2002, 6, 28, 0, 0)
>>> numpy.__version__
'1.6.2' # current version available via pip install numpy
Я могу воспроизвести значение long на numpy-1.8.0, установленное как:
pip install git+https://github.com/numpy/numpy.git#egg=numpy-dev
Тот же пример:
>>> from datetime import datetime
>>> import numpy
>>> numpy.datetime64('2002-06-28T01:00:00.000000000+0100').astype(datetime)
1025222400000000000L
>>> numpy.__version__
'1.8.0.dev-7b75899'
Он возвращает long, потому что для numpy.datetime64 тип .astype(datetime) эквивалентен .astype(object), который возвращает целое число Python (long) на numpy-1.8.
Чтобы получить объект datetime, вы могли бы:
>>> dt64.dtype
dtype('>> ns = 1e-9 # number of seconds in a nanosecond
>>> datetime.utcfromtimestamp(dt64.astype(int) * ns)
datetime.datetime(2002, 6, 28, 0, 0)
Чтобы получить datetime64, который использует секунды напрямую:
>>> dt64 = numpy.datetime64('2002-06-28T01:00:00.000000000+0100', 's')
>>> dt64.dtype
dtype('>> datetime.utcfromtimestamp(dt64.astype(int))
datetime.datetime(2002, 6, 28, 0, 0)
Документы numpy говорят, что API-интерфейс datetime является экспериментальным и может меняться в будущих версиях numpy.
6 ответов
Эмулятор, включенный в вашу (старую) версию Eclipse, работает очень медленно.
Последние эмуляторы работают быстрее, чем в 2010 году. Обновите свой SDK / IDE.
Лично , Я использую настоящий телефон для тестирования. Это быстрее и тесты более реалистичны. Но если вы хотите протестировать свое приложение на большом количестве различных версий Android и не хотите покупать несколько телефонов, вам придется время от времени использовать эмулятор.
Опция -cpu-delay , описанная в Опции запуска эмулятора могут помочь.
Попробуй отключить свой антивирус. Возможно, это сделает эмулятор немного быстрее.
Я заметил, что эмулятор запускается намного быстрее, если не подключен сервер Dalvik Debug Monitor (DDMS). Поэтому, если вы запускаете эмулятор из диспетчера виртуальных устройств «SDK Setup.exe», а Eclipse не запускается, эмулятор работает быстрее.
Если вы запустите эмулятор из Eclipse: DDMS есть, поэтому иногда эмулятор работает очень медленно, но иногда быстрее.
Команда corelist из модуля Module:: CoreList определяет, является ли модуль основным.
> corelist Carp
Carp was first release with perl 5
> corelist XML::Twig
XML::Twig was not in CORE (or so I think)
Вот один из способов использовать его в сценарии. Модуль :: CoreList POD слишком тернистый - вы должны пройти поиск исходного кода, чтобы найти, какие методы назвать:
use strict;
use warnings;
use Module::CoreList;
my $mod = 'Carp';
#my $mod = 'XML::Twig';
my @ms = Module::CoreList->find_modules(qr/^$mod$/);
if (@ms) {
print "$mod in core\n";
}
else {
print "$mod not in core\n";
}
__END__
Carp in core
Я пытался с Restlet, RestEasy, Jersey, CXF, Spring. Вот мои отзывы:
Restlet: Kind of nasty с собственным набором аннотаций. И немного сбивает с толку. Тем не менее, нельзя винить, поскольку они смотрели на реализацию этого еще до того, как там был JAX-RS.
RestEasy/Jersey/CXF: Так же просто, как и его название. Просто и прямо вперед, чтобы начать работать над этим. Хорошая часть для этих 3 рамок заключается в том, что, поскольку они совместимы с JAX-RS, любое время в будущем может быстро вернуться к таким другим рамкам, совместимым с JAX-RS, если их делать лучше или еще лучше соответствует вашим потребностям
Весна: Весна 3 начали поддерживать API REST. Но сделайте не то, чтобы он НЕ совместим с JAX-RS, по той же причине, что и для Restlet.
Поэтому я бы выбрал только из RestEasy/Jersey/CXF.
Запуск эмулятора выполняется очень медленно. Хорошо то, что запустить эмулятор нужно только один раз. Если эмулятор уже запущен и приложение запущено снова, эмулятор относительно быстро переустановит приложение. Конечно, если вы хотите знать, как быстро он будет работать на телефоне, лучше всего протестировать его на реальном телефоне.
Чтобы добавить к этому дополнительную информацию.
Недавно я обновил свою установку Ubuntu до Ubuntu 10.04 LTS (Lucid Lynx), который, в свою очередь, обновил мою версию Java до:
Java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
И теперь эмулятор (хотя запускается некоторое время), похоже, бегать быстрее, чем раньше.
Возможно, стоит обновить JVM.