toJson метод, вызывающий зависание пользовательского интерфейса

Question

У меня есть объект ArrayList, который я сохраняю в SharedPreferences в моем методе onPause. Когда я пытаюсь сериализации его JSON, я получаю следующее в журналах (эти 2 заявления повторить и перегружать LogCat):

06-20 20:33:31.620 26245-26252/com.example.app W/art﹕ Suspending all threads took: 21.556ms 
06-20 20:33:31.620 26245-26260/com.example.app W/art﹕ Suspending all threads took: 5.901ms 
06-20 20:33:31.650 26245-26260/com.example.app I/art﹕ Background partial concurrent mark sweep GC freed 210493(6MB) AllocSpace objects, 87(2MB) LOS objects, 25% free, 47MB/63MB, paused 16.970ms total 155.761ms 
06-20 20:33:32.480 26245-26260/com.example.app I/art﹕ Background sticky concurrent mark sweep GC freed 346396(10MB) AllocSpace objects, 140(4MB) LOS objects, 14% free, 48MB/56MB, paused 13ms total 88.199ms 

Я инициализации ArrayList в OnCreate, а затем дать ему объекты, когда я закончу выполнение Asynctask. Вот проблемный метод, который вызывает пользовательский интерфейс для замораживания:

@Override 
    protected void onPause() { 
    super.onPause(); 
    String json = mGson.toJson(mSelectedContactList); 
    mSharedPreferences.edit().putString("contact_list", json).apply(); 
    } 

Я также попытался следующие, и продолжать получать замораживание до:

JsonElement element = 
    mGson.toJsonTree(mSelectedContactList, new TypeToken<ArrayList<ContactObject>>() { 
    }.getType()); 
    String jsonString = element.getAsJsonArray().getAsString(); 

Я знаю, что это не то SharedPreferences, что является проблема. Я подозреваю, что метод toJson не может обрабатывать этот процесс, но я не могу понять, в чем проблема. Любая помощь будет высоко ценится.

* EDIT: Вот класс, который я использую:

public class ContactObject implements Parcelable { 

// Instance variables 
private String mID; 
private String mNumber; 
private String mName; 
private boolean mHasPhoto; 
private ArrayMap<Long, InboxSmsObject> mSentMessages; 
private ArrayMap<Long, OutboxSmsObject> mReceivedMessages; 
... 
} 

Answer 1

У меня была аналогичная проблема. Я мог почти гарантировать, что проблема связана с тем, что GSON с трудом сериализует ваш объект InboxSmsObject или OutboxSmsObject. Класс ContactObject выглядит просто, но вы должны иметь в виду, что GSON также придется сериализовать объекты в ArrayMap.

Первое, что вам нужно сделать, это попытаться изменить один или оба этих класса внутри класса ContactObject на некоторый простой класс, например String. Я был бы готов поспорить, что сериализация работает в этом сценарии.

Как только вы подтвердите, что это действительно так, вы можете работать над решением. Решением, которое я использовал, было создание простого класса с настройками, необходимыми для построения InboxSmsObject. Например, создайте класс с именем InboxSmsObjectSettings, который имеет только существенную информацию, необходимую для создания экземпляра класса InboxSmsObject (я бы предположил, что этому классу требуется всего несколько строк). Затем создать конструктор как

InboxSmsObject (настройки InboxSmsObjectSettings)

, так что вы можете легко создать экземпляр InboxSmsObject из настроек. Я знаю, что это не лучшее решение, так как вам придется перекодировать некоторые вещи, но это сработало для меня.

Answer 2

Это может быть рекурсивный вопрос.

Пожалуйста, проверьте, если у Вас есть рекурсивные модели, например:

public class ClassA { 

    ClassB b; 

} 

public class ClassB { 

    List<ClassA> aList; 

} 

Answer 3

Одна из возможных причин этого вопроса является ProGuard-ки над лексем типа, вероятно, когда запутывания не подавляется. Я тоже был очень похожая проблема, и общий сценарий был:

• Там было простой внешний пакет видимого класса, содержащий TypeToken экземпляров только, таким образом, является маркером реестра типа для того, чтобы не создать экземпляр типа жетонов каждый раз, когда я нужна десериализация. Стоит отметить (но на самом деле это не влияет на случай), маркеры типа были выставлены как статические конечные поля, видимые в виде пакетов.
• Существовал десериализатор, который ссылался на реестр.После выполнения самой первой десериализации (таким образом, , ссылаясь на класс реестра токенов типа), поток пользовательского интерфейса приложения зависает до тех пор, пока устройство не попросит, чтобы приложение было заморожено с просьбой остановить его.

Я не заметил сразу, что инициализаторы статического поля были причиной замораживания. После некоторой отладки я понял, что какой-то конструктор в абстрактном классе TypeToken вызывает зависание. Вот почему простой доступ к статическому полю заставил приложение замораживать. Я не могу вспомнить, какой конструктор вызывает его, но я бы сказал, что маркеры типа GSON могут работать в бесконечном цикле где-то в своих внутренних компонентах, если ваша параметризация токенов типа стирается во время ProGuard-ing. Так просто повторно настройка ProGuard исправляет проблему:

-keepattributes Signature 

Посмотреть больше для ProGuard Attributes.

Answer 4

Если у вас есть конструктор для ContactObject, просто удалите его. После этого он должен хорошо работать.