kotlin-parcelize is a great tool. Its simple to use and it helps in avoiding writing a lot of boilerplate code. There are times though that we need to take control of writing and reading to/from the parcel. One of these times is to cut down a few bytes from it (TransactionTooLargeException I am looking at you).

Meet me in the middle

@Parcelize takes full control and creates everything. Without the annotation, the developer has to do this on her own. Parceler lives in the middle of this spectrum. The plugin will create all necessary methods and classes but the actual write and read to/from the parcel will be the developer’s responsibility.

Without a Parceler the write/read looks like this:

	public void writeToParcel(@NotNull Parcel parcel, int flags) {
	Intrinsics.checkNotNullParameter(parcel, "parcel");
	parcel.writeInt(this.id);
	parcel.writeString(this.description);
	parcel.writeString(this.priority.name());
	parcel.writeParcelable(this.status, flags);
	Attachment var10001 = this.attachment;
	if (var10001 != null) {
	parcel.writeInt(1);
	var10001.writeToParcel(parcel, 0);
	} else {
	parcel.writeInt(0);
	}
	}
	@NotNull
	public final Task createFromParcel(@NotNull Parcel in) {
	Intrinsics.checkNotNullParameter(in, "in");
	return new Task(
	in.readInt(),
	in.readString(),
	(Priority)Enum.valueOf(Priority.class, in.readString()),
	(Status)in.readParcelable(Task.class.getClassLoader()),
	in.readInt() != 0 ? (Attachment)Attachment.CREATOR.createFromParcel(in) : null
	);
	}

view raw parcelable_on_diet__generated_write_read.java hosted with ❤ by GitHub

with a Parceler like this (where the Companion object is acting as a Parceler):

	public void writeToParcel(@NotNull Parcel parcel, int flags) {
	Intrinsics.checkNotNullParameter(parcel, "parcel");
	Companion.write(this, parcel, flags);
	}
	@NotNull
	public final Task createFromParcel(@NotNull Parcel in) {
	Intrinsics.checkNotNullParameter(in, "in");
	return Task.Companion.create(in);
	}

view raw parcelable_on_diet__generated_write_read_after.java hosted with ❤ by GitHub

Cutting down parcel’s size

The above-generated code is based on Task

	@Parcelize
	class Task(
	val id: Int,
	val description: Description,
	val priority: Priority = Normal,
	val status: Status = NotStarted,
	val attachment: Attachment? = null
	) : Parcelable
	@Parcelize
	class Attachment(val path: String) : Parcelable
	@Parcelize
	@JvmInline
	value class Description(val value: String) : Parcelable
	enum class Priority {
	Low,
	Normal,
	High
	}
	sealed class Status : Parcelable {
	@Parcelize
	object NotStarted : Status()
	@Parcelize
	object InProgress : Status()
	@Parcelize
	class Completed(val completedAt: LocalDate) : Status()
	}

view raw parcelable_on_diet__example.kt hosted with ❤ by GitHub

which, creates a parcel of 248 bytes. The code does not do anything weird. All primitives, which include the value classes too, are well handled. So nothing to do here. This leaves parcelables and enums.

But first, let’s use a Parceler. This means that writing and reading to/from the parcel has to be implemented by us. For starters, we will do exactly what the generated code does except for the attachment property. For that, the generated code uses parcelable’s methods and CREATOR. In the Parceler we don’t have access to the CREATOR.

	companion object : Parceler<Task> {
	override fun create(parcel: Parcel): Task {
	return Task(
	parcel.readInt(),
	Description(parcel.readString()!!),
	Priority.valueOf(parcel.readString()!!),
	parcel.readParcelable(Status::class.java.classLoader)!!,
	parcel.readParcelable(Attachment::class.java.classLoader)
	)
	}
	override fun Task.write(parcel: Parcel, flags: Int) {
	with(parcel) {
	writeInt(id)
	writeString(description.value)
	writeString(priority.name)
	writeParcelable(status, flags)
	writeParcelable(attachment, flags)
	}
	}
	}

view raw parcelable_on_diet__writeparcelable.kt hosted with ❤ by GitHub

That leaves us with writeParcelable and readParcelable but now the parcel’s size is bigger, it is 328 bytes! Turns out that writeParcelable first writes the parcelable’s name and then the parcelable itself!

We need to use the CREATOR. After searching around I found parcelableCreator. A function that solved a well-known problem and will be added to Kotlin 1.6.20.

	inline fun <reified T : Parcelable> Parcel.readParcelable(): T? {
	val exists = readInt() == 1
	if (!exists) return null
	return parcelableCreator<T>().createFromParcel(this)
	}
	@Suppress("UNCHECKED_CAST")
	inline fun <reified T : Parcelable> parcelableCreator(): Parcelable.Creator<T> =
	T::class.java.getDeclaredField("CREATOR").get(null) as? Parcelable.Creator<T>
	?: throw IllegalArgumentException("Could not access CREATOR field in class ${T::class.simpleName}")
	fun <T : Parcelable> Parcel.writeParcelable(t: T?) {
	if (t == null) {
	writeInt(0)
	} else {
	writeInt(1)
	t.writeToParcel(this, 0)
	}
	}

view raw parcelable_on_diet__creator.kt hosted with ❤ by GitHub

This allows us to revert the size increment back to 248 bytes

	companion object : Parceler<Task> {
	override fun create(parcel: Parcel): Task {
	return Task(
	//…
	parcel.readParcelable()
	)
	}
	override fun Task.write(parcel: Parcel, flags: Int) {
	with(parcel) {
	//…
	writeParcelable(attachment)
	}
	}
	}

view raw parcelable_on_diet__creator_usage.kt hosted with ❤ by GitHub

Use enum’s ordinal than its name. The generated code writes enum’s name so that it can use Enum.valueOf when reading. We can write an int instead by using enum’s ordinal

	companion object : Parceler<Task> {
	override fun create(parcel: Parcel): Task {
	return Task(
	//…
	parcel.readEnum()
	)
	}
	override fun Task.write(parcel: Parcel, flags: Int) {
	with(parcel) {
	//…
	writeEnum(priority)
	}
	}
	}
	inline fun <reified T : Enum<T>> Parcel.readEnum(): T {
	return enumValues<T>()[readInt()]
	}
	inline fun <reified T : Enum<T>> Parcel.writeEnum(t: T) {
	writeInt(t.ordinal)
	}

view raw parcelable_on_diet__enum.kt hosted with ❤ by GitHub

and use Enum.values() when reading. This drops the parcel’s size to 232 bytes.

Skip a class’s parcelable implementation. This of course depends on each implementation.
For instance, Status is a sealed class that only one of its children has a construction parameter. We can leverage this by writing only that value

	companion object : Parceler<Task> {
	override fun create(parcel: Parcel): Task {
	return Task(
	//…
	parcel.readStatus()
	)
	}
	override fun Task.write(parcel: Parcel, flags: Int) {
	with(parcel) {
	//…
	writeStatus(status)
	}
	}
	}
	fun Parcel.readStatus(): Status {
	return readLong().let { value ->
	when (value) {
	0L -> NotStarted
	1L -> InProgress
	else -> Completed(LocalDate.ofEpochDay(value))
	}
	}
	}
	fun Parcel.writeStatus(status: Status) {
	when (status) {
	is Completed -> writeLong(status.completedAt.toEpochDay())
	InProgress -> writeLong(1)
	NotStarted -> writeLong(0)
	}
	}

view raw parcelable_on_diet__status.kt hosted with ❤ by GitHub

this drops the parcel’s size to 136 bytes!

Conclusion

Fortunately, the generated code does a pretty good job and making any optimizations is not that common. But when needed Parceler and parcelableCreator are great tools.

PS: for measuring the parcel’s size I was using this method

	fun Parcelable.sizeInBytes(): Int {
	val parcel = Parcel.obtain()
	try {
	parcel.writeParcelable(this, 0)
	return parcel.dataSize()
	} finally {
	parcel.recycle()
	}
	}

view raw parcelable_on_diet__size_in_bytes.kt hosted with ❤ by GitHub

which was shamelessly stolen from Guardian’s TooLargeTool.