#iphone #cocoa-touch #ios
#iPhone #cocoa-touch #iOS
Вопрос:
Я портировал библиотеку (ice, обход NAT) для iPhone и столкнулся с проблемой при фактическом тестировании ее на устройстве iphone (версия 4.3). Разработал оболочку cocoa touch, которая связана с моей библиотекой. Библиотечные процедуры вызываются с помощью кнопки «test», размещенной в моем приложении.
Приложение является .mm, а библиотека основана на C .
Ниже приведены случаи, в которых мое приложение завершается с ошибкой / проходит
Пример I: я «создаю и отлаживаю» / «создаю и запускаю» приложение из Xcode для iphone. Приложение отлично работает на iphone, и я могу видеть журналы для того же самого на консоли на моем компьютере Mac.
Случай II: я пытаюсь запустить приложение со своего iphone, но оно просто вылетает при открытии.
Пример III: я собираю и отлаживаю приложение из Xcode, приложение get запущено. Но как только я отсоединяю отладочный кабель (подключенный к iphone с моего Mac), приложение получает сбой.
Размер приложения составляет 16 МБ, а размер библиотеки — 288 МБ.
Я попытался смоделировать ту же проблему, создав простое тестовое приложение и тестовую библиотеку. она работает нормально во всех случаях без проблем. В чем может быть проблема?
-
Похоже, что приложение отображает код библиотеки с компьютера Mac во время работы на iphone. и как только физическая ссылка прерывается, приложение вылетает.
-
размер библиотеки огромен?
Заранее спасибо
Комментарии:
1. Просто чтобы добавить, я запустил otools -L для подтверждения зависимости, все двоичные файлы предназначены для архитектуры arm6 и arm7.
2. Вы получаете трассировку стека? 288 МБ скомпилированного кода — это много. Бьюсь об заклад, это связано с памятью. Вы пробовали разбивать библиотеку на более мелкие части и загружать только те части, которые вы фактически используете?
3. 1. Приложение отлично работает на iphone, когда отладочный кабель подключен к iphone через mac os x. Приложение не работает, когда я отсоединяю кабель. поэтому я не могу видеть трассировку стека в то время.
4. 2. Также код библиотеки будет выполняться только при нажатии кнопки. Поэтому я не думаю, что в то время должны быть проблемы с памятью. Чтобы протестировать это, я добавил фиктивную функцию, возвращающую целое число. я вызвал эту функцию только из своего приложения. все та же проблема.
5. может ли это быть связано с проблемой синхронизации? когда мы запускаем приложение через Mac os, мы на самом деле даем ему много времени для загрузки.. но это не тот случай, когда мы запускаем ее непосредственно из iOS..
Ответ №1:
iOS убивает приложения, которые слишком долго блокируют основной поток. Так что это может быть проблемой, а также объясняет, почему приложение не завершает работу в режиме отладки.
Попробуйте запустить свою функцию в фоновом режиме и посмотрите, поможет ли это!
Комментарии:
1. При просмотре кода библиотеки, у нее есть некоторые глобальные переменные, которые на самом деле требуются. На самом деле это может занять некоторое время, что, в свою очередь, блокирует основной поток. Поэтому я думаю, что мы не можем поместить этот код в фоновый режим. есть ли какой-либо другой способ заставить основной поток ждать, а не прерываться? я читал о grand central dispatch, можно ли это использовать?
2. Запуск ее в фоновом режиме с
performSelectorInBackground:должен работать просто отлично. Вы должны использовать это все время, когда вам нужно делать тяжелые вещи. GCD делает то же самое, так что это не должно иметь значения.3. У меня в библиотеке есть несколько заголовочных файлов, которые, в свою очередь, содержат некоторые глобальные переменные. они должны быть включены. на самом деле это создает задержку для основного потока. функциональность для вызова находится под кнопкой. поэтому, даже если я переведу эту функцию в фоновый режим (используя performselectorinbackground), это не поможет. я пытался, как вы сказали, но это не помогло (причина: как я уже сказал выше)
4. Если это действительно так, то следует разделить инициализацию на несколько шагов, которые вы помещаете в фоновую очередь и надеетесь, что основной поток получит шанс запуститься (или явно добавить небольшую задержку между каждым шагом инициализации). Для этого GCD может быть хорошим вариантом.
5. есть идеи, как реализовать GCD?
Ответ №2:
Наконец-то я получил ответ на свой вопрос! Большое спасибо Мартину за указание «iOS убивает приложения, которые слишком долго блокируют основной поток»
Ниже приведена процедура, которой я следовал, чтобы найти решение проблемы:
Xcode «orgainzer» -> раздел «Журналы устройств» показывает отчет о сбое iphone. Мой отчет о сбое приложения также был сгенерирован в том же.
В отчете о сбое было четко написано «mytestapp не удалось запустить вовремя», и далее он показал API, который слишком долго возвращал результат. (в моем случае это был getlocalhostname API).
Я просто исправил API в соответствии со своими требованиями, скомпилировал и запустил приложение на устройстве iphone, и оно сработало!! Кроме того, время запуска приложения теперь значительно меньше.
Еще раз спасибо!