직렬화 - Parcelize, Parcelable, Serializable

Intent로 값을 전달할 때 primitive type은 그냥 전달하면 되지만, data class로 선언된 객체들은 직렬화 과정이 필요하다.

# 직렬화가 왜 필요할까?

JVM에 올라가 있는 primitive type 데이터는 연속된 메모리 주소값을 가지면서 바이트 형태로 변환된다. 그래서 통신할 때도 형태가 유지되는데, class로 이루어진 객체는 객체 참조 주소가 스택에 올라가고 heap에 객체 안에 있는 멤버가 올라간다. 직렬화를 사용하면 이런 멤버 데이터 까지 직렬화된 바이트 형태의 데이터로 변환해서 JVM에 상주시킨다. 직렬화 과정을 거치고 나서야 외부로 이 객체를 내보낼 수 있게 되는 것이다.(파일 쓰기, 읽기, 네트워크 통신)

 

kotlin은 java를 계승한 언어이고, 당연히 마커인터페이스인 Serializable을 쓸 수 있다. 자바에서 Serializable을 implements만 하면 됐던걸 그대로 코틀린 문법에 적용했다.

data class Person(
    val firstName: String,
    val lastName: String
) : Serializable

이대로 써도 되지않나?? 라는 생각이 들 때 쯤 Parcelable의 존재를 알게 되었다.

# Parcelable

Parcelable은 Android SDK의 인터페이스로 Serializable을 개선한 버전이다. Serializable은 내부에서 자바 리플렉션을 사용해서 직렬화를 처리(직렬화 방식을 리플렉션으로 탐색한다)하는데, 이 과정에서 오브젝트 생성이 많이 일어나고 생성된 오브젝트는 GC 대상이 되며, 그로 인해 자원을 잡아먹어 전체적인 성능 저하를 일으킨다. 리플렉션은 프로그램 내부 속성을 조작할 수 있는 방법으로 비용이 매우 큰 작업이다. 리플렉션에 대한 자세한 설명은 여기서 더 볼 수 있다.

 

Parcelable은 Serializable이 하는 일은 그대로 하면서, 직렬화 처리 방법을 명시하여 리플렉션이 일어나지 않도록 설계되었다. => 보일러 플레이트가 생긴다는 의미다.

 

위에서 Serializable로 선언했던 코드를 그대로 Parcelable로 바꿔보면 아래와 같아진다. 모든 프로퍼티가 nullable인 이유는 유연성을 높이기 위해서다.

parcelable의 readString만 보면,

@Nullable
public final String readString() {
    return readString16();
}

@Nullable로 선언되어있어서 생성자가 만들어질 때 생길 오류를 막기위해서라도 프로퍼티를 nullable하게 선언한다.

data class Person(
    var firstName: String?,
    var lastName: String?,
    var age: Int?
) : Parcelable {
    constructor(parcel: Parcel) : this(
        parcel.readString(),
        parcel.readString(),
        parcel.readInt()
    )

    override fun writeToParcel(parcel: Parcel, flags: Int) {
        parcel.writeString(firstName)
        parcel.writeString(lastName)
        age?.let { parcel.writeInt(it) }
    }

    override fun describeContents(): Int {
        return 0
    }

    companion object CREATOR : Parcelable.Creator<Person> {
        override fun createFromParcel(parcel: Parcel): Person {
            return Person(parcel)
        }

        override fun newArray(size: Int): Array<Person?> {
            return arrayOfNulls(size)
        }
    }
}

 

Parcelable 인터페이스를 상속받으면 무조건 구현해야하는 몇몇 메서드가 있다.

• constructor(parcel: Parcel)
  parcel에서 데이터를 읽어 this로 Person 객체를 생성한다.
• writeToParcel(parcel: Parcel, flags: Int)
  Person 객체의 데이터를 Parcel에 쓰기 위한 메서드다.
• describeContents()
  Parcel content에 대한 flag값을 반환하는데, 일반적으로 0을 반환한다. 객체에 대한 버전관리가 필요한 경우에 여기에 버전을 담아 보낼 수 있다.
• companion object CREATOR: Parcelable.Creator<Person>
  
  • createFromParcel 메서드는 주어진 Parcel로 Person 객체를 만들고 
  • newArray 메서드는 지정된 크기의 Person 배열을 만든다.

Interface for classes whose instances can be written to and restored from a Parcel. Classes implementing the Parcelable interface must also have a non-null public static field called CREATOR of a type that implements the Parcelable.Creator interface.

 

Parcelable인터페이스에 CREATOR가 non-null인 static field로 정의되어있어서 companion object로 구현해야한다.

직렬화를 위한 코드들로 수많은 DTO를 만들면서 매번 이 코드들을 작성하는 건 번거롭다고 느낄 수 있다.

# Parcelize

이걸 자동화 해둔 게 Parcelize 플러그인이다. 몇 년 전에는 beta였지만 지금은 정식 배포가 되었고 꾸준히 구글에서 업데이트 해주고 있다.

사용할 모듈의 gradle에 plugin을 추가해주고

plugins {
    id("kotlin-parcelize")
}

@Parcelize 어노테이션을 붙여주면 끝난다.

@Parcelize
data class Person(
    var firstName: String?,
    var lastName: String?,
    var age: Int?
) : Parcelable

결과적으로 Serializable처럼 간단하지만 리플렉션이 일어나지않는 코드가 되었다. 어노테이션을 사용해서 보일러플레이트를 날렸지만, 직렬화 과정에서 필요한 조치가 있으면 여전히 Parcelable 인터페이스를 받아서 구현할 수 있다. 형태는 조금 달라진다.

transient와 같이 직렬화 대상에서 제외하고 싶은 프로퍼티가 있으면, 해당 멤버에 @IgnoredOnParcel을 붙여주면 된다.

@Parcelize
data class Person(
    var firstName: String?,
    var lastName: String?,
    var age: Int?
) : Parcelable{
	private companion object : Parceler<Person> {
        override fun User.write(parcel: Parcel, flags: Int) {
            // Custom write implementation
        }

        override fun create(parcel: Parcel): Person {
            // Custom read implementation
        }
    }
}

아래 링크에 Parcelize가 지원하는 Type을 남겨두었다.

https://developer.android.com/kotlin/parcelize?hl=ko#types

Parcelable 구현 생성기  |  Kotlin  |  Android Developers

# Serializable도 인터페이스를 구현해준다면?

Parcelable이 속도를 빠르게 만든 방식은 리플렉션을 타지 않도록 직접 지정해준 것이다. 그렇다면 Seralizable에도 똑같이 할 수 있지 않을까?

Serializable도 어노테이션에서 끝나지않고 커스텀으로 writeObject, readObject, readObjectNoData를 구현해주면 리플렉션을 막을 수 있다...! 심지어 Parcelable보다 속도가 더 빠르다고 나온 테스트 결과도 있다.

 

https://medium.com/@limgyumin/parcelable-vs-serializable-%EC%A0%95%EB%A7%90-serializable%EC%9D%80-%EB%8A%90%EB%A6%B4%EA%B9%8C-bc2b9a7ba810

Parcelable vs Serializable , 정말 Serializable은 느릴까?

---

Serializable을 custom해서 사용하는 것도 좋겠지만, 고급 직렬화를 수행할때나 그렇게 하면 될 것 같고, 단순히 data class를 intent로 넘기고 싶을 때는 Parcelize 플러그인을 사용하는 게 비용 상 이점을 더 가져갈 수 있다고 생각한다.

 

:: 참고 자료 ::

https://medium.com/@limgyumin/parcelable-vs-serializable-%EC%A0%95%EB%A7%90-serializable%EC%9D%80-%EB%8A%90%EB%A6%B4%EA%B9%8C-bc2b9a7ba810

https://bladecoder.medium.com/a-study-of-the-parcelize-feature-from-kotlin-android-extensions-59a5adcd5909

https://www.charlezz.com/?p=44613

https://www.charlezz.com/?p=823

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^