Jetpack Compose What and Why, 6个难题

Jetpack Compose What and Why, 6个难题

1.这一技术性发生的情况, 初心, 要做到哪些的总体目标或者要处理哪些的难题.

Jetpack Compose是什么?
它是一个申明式的UI工具箱(declarative UI toolkit for Android).

它的关键目地便是更改以前命令句地(imperatively)写UI的方式 , 改为申明式(declarative)的.

命令句

Android以前的书写就叫命令句: view hierarchy是一个UI widgets组成的tree, 当app的情况更改时, UI必须升级. 一般的作法是根据findViewById()等方式寻找要升级的连接点, 根据setText(), addChild(), setImageBitmap()等方式 升级控制的內部情况. 每一个控制都是有自身的內部情况, 而且曝露getter/setter, 容许程序结构和控制互动.

命令句为何不太好呢:

• 那样手动式地升级view会提升犯错误的概率. 假如某一数据信息在好几个地区被3D渲染, 那麼很可能就忘记了升级在其中的某一view.
• 非常容易建立不法情况, 例如2个升级以不期待的方法矛盾了. (例如: 一个要升级值, 另一个要清除连接点.)
• 维护保养的复杂性伴随着必须升级的view数量而提升.

申明式

因此, 过去的两年里, 业内一直在探寻而且逐渐转为一种申明式的UI实体模型. 目地便是简单化搭建和升级UI.

Jetpack Compose是一个申明式的UI framework. 该技术性的基本原理是重新开始再次转化成全部显示屏, 随后仅运用必需的变更. 这类方式 防止了手动式升级stateful view的复杂性.

在Compose的申明式解决方法里, widgets相对而言是stateless的, 不曝露getter/setter.
事实上, widgets压根并不是以目标的方式来曝露的.
当升级UI的情况下, 事实上是传不一样的主要参数启用了composable方式 . 当数据信息更改时, composable承担把当今的运用情况转换为UI.

2.这一技术性的优点和缺点各自是啥, 换句话说, 这一技术性的trade-off是啥.

Compose的优点:

• 现阶段Google资金投入了很多的資源(教学资源, 小区争霸赛, IDE和c语言编译器适用, 发布desktop版本号等)来营销推广Compose, 大家有原因坚信Google官方网会再次使力, Compose会变成Android将来的UI规范开发设计方式.
• Compose的申明式书写和Flutter, SwiftUI, React切合, 在适用好几个服务平台的精英团队里, 有益于构架观念的统一.
• 申明式UI, 写起來更快, 不易打错.
• 由于全部的编码全是Kotlin写的(真100%kotlin), 运用了Kotlin的强种类安全性, c语言编译器会提醒许多不正确.
• 修补和升级了一些旧的API: (Buggy Android Views: Picker, Spinner, EditText, 有一些edge cases. 由于要变更旧的一直难以, 比不上建立一个新的. )
• 根据组成的Composable, 比根据承继的View管理体系, 更为灵便, 便于重复使用. 例如能够根据组成来做到重复使用好几个源, 不会再受单承继限定.
  以Button为例子, 在传统式的UI里, 它是单承继管理体系下的一个类: Button -> TextView -> View.
  而在Compose的全球里, 它仅仅一个@Composable的方式 , 里边包括了别的composable, surface, row等.
  举例说明: list->detail2个页面, 能够根据获取方式 主要参数来做到2个页面的composable重复使用.
• 适用和View-based UI系统软件的相互之间启用. 那样有两个优势: 有益于现有新项目app的互用和逐渐转移; 当Compose达到不上要求的情况下可以用传统式View做为第二挑选.
• 和Jetpack系列的别的库都能极致融合. (ViewModel, Kotlin Flow, Coroutines, Paging, Hilt, Navigation...)

缺点:

• 必须用Canary版本号的Android Studio, 现阶段(2021.5)IDE或是存有一些难题的.
• Gradle还要升級到最新版本(7.0.0-alpha15), 并不是很平稳, 也有一些难题.
• 版本升级经常. Compose alpha版本号的一些API早已发生变化. -> 可是现阶段早已beta, 全新的Google I/0说7月便会有稳定版公布.
• 对比Android View, 小区适用不足多. -> 可是Google早已资金投入了很多的資源来营销推广, 小区适用已经飞快提高.
• 尽管Google封裝了material的compose库, 但或是有一部分View控制没有办法给予, 例如WebView, MapView等.

3.这一技术性应用的情景.

Jetpack Compose的应用情景是替代原先的Android View书写(xml, 在编码里创建对象View目标再加上到View hierarchy里等),
Jetpack Compose用全新升级的方法来写UI, 将要变成Google Android规范书写.

留意这儿的更改除开UI书写的更改, 或是一种情况管理方法观念的变化.
申明式, 单边数据流分析, 单独数据库.
Android內部的方式近些年一直追求完美的不外乎便是数据信息和View的分离出来, View的愚昧与自动升级, 清楚的逻辑性管理方法和分离出来, 可检测性这些.

除开与View强有关的这一层(ViewModel)外, 别的的领域模型, 数据信息互动等被危害并不大, 因此就算app决策慢慢转移到Compose, 也仅用管View制作及其和View邻近的这一层.

4.技术性的构成部分和关键环节.

Jetpack compose的整体特性:

• 申明式UI. f(state)=UI.
• Built on Kotlin.
• Unbundled: 并不是和系统软件关联的, 只是和Jetpack中的库一样, 版本号单独, 能够自身升级维护保养版本号, 也确保了好几个系统软件上的个人行为一致.
• Built for interop. 能够和现有View相互之间启用, 适用目前新项目的慢慢转移.
• 内嵌控制和theming, 适用material design.

Composable functions

Compose的操作方法:
界定一系列的composable functions: 读取数据, 发送UI原素.

@Composable
fun Greeting(names: String) {
    Text("Hello $name")
}

Composable方式 的特性:

• 全部的方式 都务必有@Composable注释.
• 方式 主要参数是数据信息.
• 根据启用别的composable方式 来发送UI原素.
• 方式 不传参, 由于他们在叙述显示屏情况, 而不是搭建UI widgets.
• 方法要快, 具备幂等性(启用几回結果都一样), 沒有不良反应. (fast, idempotent, and side-effect free.) 这就规定方式 不容易改动外界特性或是全局变量, 都没有Random的启用等.

还有一个小差别便是有别于一般的kotlin方式 命名规范, composable方式 名的首写要英文大写, 因为它这时意味着的是一种widget.

Recomposition

Compose framework会很机敏地挑选出有转变, 必须再次制作的一部分.

在Compose中, 假如启用composable function, 传到了新数据, 会促使方式 被recomposed: 这一方式 发送的widgets会依据必须开展再次制作.

由于再次制作全部UI tree会开销较为大, 因此事实上composable function仅有input更改的才会被再次制作, 针对这些主要参数沒有转变的方式 和lambda, 实际上是skip掉的, 那样才可以提升recompose的高效率.

因此, 始终不必取决于实行composable function的side-effects, 由于recomposition有可能会被skip掉.

side-effects包含:

• 升级共享资源目标.
• 升级ViewModel中的observable.
• 升级shared preferences.

因为composable functions有可能会被逐帧实行(例如动漫期内), 因此它应当充足的快, 假如必须用时的实际操作, 能够考虑到后台管理的coroutine.

5.技术性的最底层基本原理和重要完成.

Compose的好多个特性:

• Composable functions能够以一切次序实行.
• Composable functions能够并行执行.
• Recomposition会尽量地skip多的composable functions. 假如确实必须side-effects, 考虑到用callback.
• Recomposition是开朗的, 它觉得在此次重绘期内不容易有新的情况更改, 如果有新的情况更改, 它很有可能会撤销当今制作, 以新的主要参数从头开始制作.
• Composable function有可能会强制执行得很经常(例如动漫), 因此防止用时实际操作.

有关Compose的最底层基本原理, 现阶段还没找到一个官方网的文本文档或是框架图.
由于很有可能大家都仍在学习培训如何使用, 此项技术性的最底层完成关键点都还没被热情探讨起來.
这儿有一个难题: https://stackoverflow.com/questions/58558163/how-does-jetpack-compose-work-under-the-hood

从使用人的视角揣摩一下Compose的基本原理:
尽管Composable应用了注释@Composable, 可是却沒有加上注释CPU(kapt), 因此并并不是借助注释在编译程序期转化成编码.

在加上依靠的情况下必须在build.gradle里加上:

    composeOptions {
        kotlinCompilerExtensionVersion compose_version
    }

因此它和kotlin的c语言编译器有关系.

这个视频: Understanding Compose (Android Dev Summit '19)在17:18逐渐讲完成基本原理.

@Composable更好像一个语言表达的关键词. 能够对比suspend, 有下列好多个相同点:

• 更改了方式 的种类.
• 强制性了方式 的启用前后文.

一部分升级

用了订制化的Kotlinc语言编译器软件, 数据信息更改时, 受数据信息危害的composable的方式 会被再次启用.

6.现有的完成和它中间的比照.

Android View和Jetpack Compose的比照.

Android View和Jetpack Compose的类似点:

• 全是Android UI的书写.

Jetpack Compose改善了View系统软件的什么地方:

• 不会再必须担忧深层次嵌入. Compose UI不允许很多遍的精确测量(multi-pass measurement), 改进了高效率.

Flutter和Jetpack Compose的比照.

Jetpack Compose和Flutter的类似点:

• 申明式UI, UI = f(state).
• 都是有web和desktop版本号.
• 官方网都给予了一些material的控制和資源, 例如都是有个Scaffold, 给予钢管脚手架.
• 都能够和原生态互用, 尽管水平不一样, Compose的互用粒度分布更准一点.
• 都能够一边改UI一边浏览.

Jetpack Compose比Flutter好的地区:

• 根据Kotlin, 对比于Flutter的dart而言, 对Android开发人员更友善一些.
• 然后上一点, 由于Compose只改了UI, 因此别的一部分的代码库依然是Android原生态编码的逻辑性, 称手的第三方库比较多. 而Flutter, 就得运用其他package来做json分析, 数据库查询这些.
• Flutter的stateful widget改情况务必要在setState里, 应用上并不是很便捷, 非常容易打错.
• Jetpack Compose的Recomposition看起来更智能化一些, 彻底全自动, 并不像Flutter一样必须开发人员自身设定一些flag来说明哪一个一部分不用重绘.
• 安装文件容积应当有优点? 由于Flutter SDK包括了自身的图象模块, 而Compose是沒有native方面的物品的.

Flutter比Jetpack Compose好的地区:

• Flutter还适用iOS.
• Flutter对比Jetpack Compose略微完善一些(Flutter出去的早一些), 是历经一些app的事实上线认证的.
• Flutter是有自身的图型模块Skia的, 制作会更高效率? (沒有认证, 纯猜想)

Reference

• Thinking in Compose
• Using Jetpack libraries in Compose | Session -> 这一讲情况管理方法和别的Jetpack库融合的视頻非常好.