Cuando implementé un Canvas con Kotlin y Compose por primera vez, ¿qué gané?

Han pasado casi cuatro años desde que Google recomendó a Kotlin como el lenguaje preferido para el desarrollo de Android en 2019. La versión 1.0 de Compose también se lanzó hace casi dos años. Kotlin+Compose aún está muy atrasado en el proceso actual de desarrollo de Android. No es tan convencional. ¿Deberíamos empezar a experimentar con esta combinación?, ¿qué nos traerá esta combinación?

Para mí, soy una persona anticuada que ama lo nuevo.Desde principios de 2018, he intentado usar Kotlin para completar algunos trabajos de Android ( Android para Bezier ), pero no he usado Kotlin como mi desarrollo principal de Android personal. idioma. Sin embargo, con la mejora de la comunidad combinada de Kotlin+Compose, más y más personas comenzaron a probar esta combinación y agregaron su propia fuerza a la construcción comunitaria de esta combinación. Llamándose unos a otros, más y más personas (incluyéndome a mí) están comenzando a intentar agregar Kotlin o Kotlin+Compose a los proyectos de desarrollo existentes. Este artículo mostrará algunas de las ganancias y pensamientos que encontré en esta combinación.

Comience con un lienzo personalizado

Primero echemos un vistazo al efecto. El efecto de animación original no es original, y se ha llevado a cabo un diseño secundario en combinación con el efecto funcional real.

Canavs

El resultado final es bastante satisfactorio, y se han añadido muchos efectos de animación adicionales, es decir, cada parte de la pantalla tiene su propia animación.

Hablemos de la cosecha y el pensamiento primero.

En términos generales, explicaré el proceso de implementación desde el diseño hasta el código, pero esta vez hablaré sobre las razones de mi cosecha y pensamiento primero, principalmente porque todo el proceso desde el diseño hasta la implementación del código no tiene nada que ver con el desarrollo original. (Java) La diferencia Por supuesto, se proporcionará una descripción detallada de esta animación más adelante.

Kotlin y Java La comparación y la relación entre Kotlin y Java No entraré en detalles, pero a través del proceso de codificación de Canvas, tengo una comprensión más profunda del uso y la comprensión de Kotlin. Se comparan los dos lenguajes, aunque los dos la relación es muy estrecha, pero en el uso real, todavía es necesario evitar llevar los hábitos de un idioma a otro.
Compose El proyecto original mío era hacer una herramienta de escritorio esencial implementada por Compose, pero varios problemas y la falta de información en ese momento me impidieron completar este proyecto Solo cuando realmente uso Compose en el proyecto podemos entender cómo usar Compose aplicaciones , Es completamente imposible lograr el efecto de experiencia solo mediante la introducción de otros Esto es muy obvio para la mayoría de los desarrolladores que han estado profundamente involucrados en Android.

Lo primero que se lleva la peor parte es la idea del diseño receptivo, que es muy diferente de los hábitos generados por el diseño xml que usamos inicialmente.

Cuando implementamos nuestro diseño a través de xml (incluso cuando construimos directamente a través de View.add()

Y cuando usamos Compose para el diseño, necesitamos definir Compose (Compose es Compose, está al mismo nivel que View) y decirle qué hacer bajo qué circunstancias. Al igual que Yutu, en el suelo puede agregar varias herramientas ( pistas, cámaras...), pero cuando lo lanzas a la luna, ni siquiera puedes cambiar el patrón en la superficie.

最初的Coding过程中, 由于固有思路的原因, 想着先实现一部分的功能, 然后看下实现的效果在逐步添加相关的功能. 但是当我实现了某个效果再回来的时候, 在一小部分的情况下, 我不得不对现有的代码进行很大的修改. 同时我也确认过, 如果不使用Compose的话, 是不需要改动如此大的. 这里就是我在这个项目中对我观念转变最大的地方. "如果没有设计完成, 就不要去实现它", 平时的这个问题被我们拿住"把柄"的View所掩饰了.

换句话说, 使用Compose就像使用各种Builder一样, 当我们没有build()的时候, 我们可以做任何事情, 一旦我们完成build()了, 我们就不能这样随心所欲的控制它, 想想我们的AlertDialog.Builder().create().
Kotlin Compose和Java XML 在整个代码中, 我都尽量使用Kotlin+Compose来进行实现各种功能, 就像Kotlin和Java直接可以很方便的互相使用, Compose和View直接也可以很简单的互相融合, 在Coding过程中, 经验的不足和对Kotlin Compose的不熟悉使得很多看似简单的功能迟迟无法实现, 甚至一些效果对我来说, 不使用老方法我无法做到. (即便如此, 仍使用了一部分ValueAnimator而不是 rememberInfiniteTransition)
会让我更多的使用Kotlin和Compose么? 经过一段时间的使用后(不仅仅是这个demo, 还有在实际工作中的使用), 我认为我会尝试更多的Kotlin代码和用Compose来构建页面. 通常来说的Kotlin相对于Java来说代码量会更少, 不过现在的各种辅助开发工具(Copilot, ChatGpt)使其"写更少的代码"看起来并不是十分能吸引人, 俗话说的好"纸上得来终觉浅,绝知此事要躬行", 当你真正的使用一段时间之后, 你会发现写的少, 不仅仅是写的少, 也代表了看的少, 理解的少, 改的少, 维护的少.当然, 这些都是建立在一定基础上的, 在了解一定的特性和约定后才能达到, 不然最多的感受可能只有"这里的功能是什么? 这里为什么要这么设计?", (是吧协程).

如果说Java的学习难度是线性的, 那么Kotlin的学习难度我认为是抛物线的形状, 入门比Java更简单, 但是稍一深入, 由于有大量约定的特性, 使其中期难度比Java更难. 当然, 后期深入精通的部分都是需要不断的学习和使用的.

这导致了很多人初期使用的时候感觉很省心, 但是当尝试使用或者深入学习的时候, 会发现很多的地方都无从下手, 或者预期的功能无法实现. 一是固有思维的作祟, 二是你认为学习完成的基础知识还不足以让你进行下一步. 这可能就是"基础知识陷阱"吧. 最初的我, 认为Kotlin是Java的另一种实现形式, 认为直接的尝试是没有问题的. 但是就像是View和Compose直接的关系一样, 虽然两种之间都可以很轻易的互相使用, 但是, View就是View, Compose就是Compose, Kotlin就是Kotlin, Java就是Java. 两者之间的关系并不是替代和补充. 而是实现同一目的的不同思路. "条条大路通罗马"不是么? 所以当你使用Kotlin和Compose的时候, 放弃一下固有的思维和观念, Kotlin不是替代品, 它是另一条路.