日本免费高清视频-国产福利视频导航-黄色在线播放国产-天天操天天操天天操天天操|www.shdianci.com

學(xué)無先后，達(dá)者為師

網(wǎng)站首頁 編程語言 正文

Android開發(fā)Compose框架使用開篇_Android

作者：Pika ? 更新時間： 2022-10-31 編程語言

Compose的誕生

在2019年的谷歌IO大會上，Compose作為Android新一代UI開發(fā)亮相，因為聲明式開發(fā)越來越流行了，對標(biāo)IOS開發(fā)SwiftUi，Compose的立項也為Android開發(fā)新加了聲明式ui的開發(fā)選項，在2021年7月1.0正式版本的誕生，也意味著Compose即將進(jìn)入生產(chǎn)環(huán)節(jié)，國際app巨頭Twitter就首當(dāng)其沖，在新頁面上用上了Compose

Compose好處

與傳統(tǒng)的xml相比，Compose不僅吸收了其優(yōu)點，摒棄了糟粕，還具有以下幾個優(yōu)點

聲明式 兼容性 跨平臺 布局效率
不同于傳統(tǒng)的命令式，ui的刷新需要調(diào)用者主動調(diào)用刷新方法，比如TextView需要特定的setText進(jìn)行文本變化，而compose在定義好聲明狀態(tài)后，由框架自主調(diào)用刷新，減少狀態(tài)不一致 compose最低兼容到android api 21，不但可以在原來View體系中嫁接使用，也可以在compose中使用原來View體系的xml 跨平臺，目前支持macos等多個平臺，跨平臺由Jetbrain團(tuán)隊在做，compose未來會實現(xiàn)ui多跨平臺，同時也搭配邏輯跨平臺KMM項目（有關(guān)kmm的以后有機(jī)會可以再說說，比起說跨平臺，更不如說是多平臺，因為編譯出來的代碼是直接符合原平臺開發(fā)規(guī)范的，比如ios編譯出來的就是framework），未來實現(xiàn)ui跟邏輯都跨平臺也不在遙遠(yuǎn) compose 是嚴(yán)格遵循LayoutNode的單次測量，不會出現(xiàn)View的多次測量導(dǎo)致的問題，在ui卡頓或者ui規(guī)范上，是非常重要的改進(jìn)

因為Compose是Android團(tuán)隊與JetBrain在推，國內(nèi)外的學(xué)習(xí)熱情都挺好，目前國內(nèi)也有不少大廠進(jìn)行了嘗試階段，比如字節(jié)。

Compose 架構(gòu)

說了這么多，那么Compose是怎么做到在原有View體系做到兼容并改善的呢？

我們從一個例子出發(fā)：

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
             xxx組件
        }
    }
}

我們可以看到，Compose在Activity中，用了setContent方法代替了原有的setContentView方法，那么setContent做了什么呢？

public fun ComponentActivity.setContent(
    parent: CompositionContext? = null,
    content: @Composable () -> Unit
) {
    val existingComposeView = window.decorView
        .findViewById<ViewGroup>(android.R.id.content)
        .getChildAt(0) as? ComposeView
    if (existingComposeView != null) with(existingComposeView) {
        setParentCompositionContext(parent)
        setContent(content)
    } else ComposeView(this).apply {
        // Set content and parent **before** setContentView
        // to have ComposeView create the composition on attach
        setParentCompositionContext(parent)
        setContent(content)
        // Set the view tree owners before setting the content view so that the inflation process
        // and attach listeners will see them already present
        setOwners()
        setContentView(this, DefaultActivityContentLayoutParams)
    }
}

可以看到，android.R.id.content的第一個孩子被替換成了ComposeView，而這個ComposeView，就是Compose環(huán)境的提供者，在這里面，Compose將剔除原本View體系的測量邏輯，從而采用自己的測量架構(gòu)。如下圖包餃子架構(gòu)所示：

值得注意的是ComposeView是繼承于AbstractComposeView（他定義了compose環(huán)境的規(guī)范），還有就是android中是多window架構(gòu)的，所以針對Dialog這種，也有特別的環(huán)境實現(xiàn)類。針對PopupWindow這種共用window的組件，也同樣提供了compose環(huán)境實現(xiàn)類

可以看到架構(gòu)圖中，AbstractComposeView其實也是繼承于ViewGroup的。所以準(zhǔn)確來說，Compose并沒有完全脫離AndroidView體系，而是在這之上建立起了中間層，這就印證了一句老話，沒有什么架構(gòu)是不能解決的，如果有，那就加個中間層！而這個中間層，提供了全新的設(shè)計，從而讓android得以脫胎換骨到一個新架構(gòu)！

@Composable的背后

說到Compose，那么肯定離不開Compsoable的介紹，我們肯定會有一個疑問，為什么一個函數(shù)加上了Composable注解，就變成了一個可見的視圖了呢？比如

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}

我們進(jìn)行反編譯后

    public static final void Greeting(String name, Composer $composer, int $changed) {
        Intrinsics.checkNotNullParameter(name, "name");
        Composer $composer2 = $composer.startRestartGroup(-154424256);
        ComposerKt.sourceInformation($composer2, "C(Greeting)46@1589L27:MainActivity.kt#8m9ksz");
        int $dirty = $changed;
        if (($changed & 14) == 0) {
            $dirty |= $composer2.changed(name) ? 4 : 2;
        }
        if ((($dirty & 11) ^ 2) != 0 || !$composer2.getSkipping()) {
            TextKt.m1219TextfLXpl1I(LiveLiterals$MainActivityKt.INSTANCE.m4567String$0$str$arg0$callText$funGreeting() + name + LiveLiterals$MainActivityKt.INSTANCE.m4584String$2$str$arg0$callText$funGreeting(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
        } else {
            $composer2.skipToGroupEnd();
        }
        ScopeUpdateScope endRestartGroup = $composer2.endRestartGroup();
        if (endRestartGroup == null) {
            return;
        }
        endRestartGroup.updateScope(new MainActivityKt$Greeting$1(name, $changed));
    }

可以看到，實際上，編譯器為我們的帶有@Composable的Greeting方法添加了兩個參數(shù)，

Composer $composer, int $changed

Composer就是我們真的compose執(zhí)行時的操作者，changed就是一個參與是否重組的標(biāo)識之一，這種通過注解在編譯時生成對應(yīng)參數(shù)的方案，在Coroutine里面也用到，當(dāng)然我們也可以通過ASM等方法去編譯時判斷注解并更改相應(yīng)的函數(shù)方法，只不過這部分由compose編譯器幫我們做了。

我們重點關(guān)注一下composer.startRestartGroup這個方法

override fun startRestartGroup(key: Int): Composer {
    start(key, null, false, null)
    addRecomposeScope()
    return this
}

可以看到傳入了一個key為Int類型的標(biāo)識，所有Composable函數(shù)區(qū)域會通過特定key去判斷重組的范圍以及當(dāng)前范圍是否進(jìn)行更新（范圍就是startRestartGroup - endRestartGroup 之間的狀態(tài)），當(dāng)然一個Composable函數(shù)里面可能存在多個重組范圍，我們還是拿上面的Greeting函數(shù)做個例子，不過這次有點變化

@Composable
fun Greeting(name: String) {
    val  state by remember {
        mutableStateOf(true)
    }
    if (state){
        Text(text = "true")
    }else{
        Text(text = "false")
    }
}

此時反編譯后就會多一些代碼

    public static final void Greeting(String name, Composer $composer, int $changed) {
        Object value$iv$iv;
        Intrinsics.checkNotNullParameter(name, "name");
        Composer $composer2 = $composer.startRestartGroup(-154424404);
        ComposerKt.sourceInformation($composer2, "C(Greeting)43@1455L45:MainActivity.kt#8m9ksz");
        if (($changed & 1) == 0 && $composer2.getSkipping()) {
            $composer2.skipToGroupEnd();
        } else {
            $composer2.startReplaceableGroup(-492369756);
            ComposerKt.sourceInformation($composer2, "C(remember):Composables.kt#9igjgp");
            Object it$iv$iv = $composer2.rememberedValue();
            if (it$iv$iv == Composer.Companion.getEmpty()) {
                value$iv$iv = SnapshotStateKt__SnapshotStateKt.mutableStateOf$default(Boolean.valueOf(LiveLiterals$MainActivityKt.INSTANCE.m4554x2b38c863()), null, 2, null);
                $composer2.updateRememberedValue(value$iv$iv);
            } else {
                value$iv$iv = it$iv$iv;
            }
            $composer2.endReplaceableGroup();
            MutableState state$delegate = (MutableState) value$iv$iv;
            // 關(guān)注這里
            if (m4607Greeting$lambda1(state$delegate)) {
                $composer2.startReplaceableGroup(-154424297);
                ComposerKt.sourceInformation($composer2, "47@1525L19");
                TextKt.m1219TextfLXpl1I(LiveLiterals$MainActivityKt.INSTANCE.m4597String$arg0$callText$branch$if$funGreeting(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
                $composer2.endReplaceableGroup();
            } else {
                $composer2.startReplaceableGroup(-154424258);
                ComposerKt.sourceInformation($composer2, "49@1564L20");
                TextKt.m1219TextfLXpl1I(LiveLiterals$MainActivityKt.INSTANCE.m4598String$arg0$callText$else$if$funGreeting(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
                $composer2.endReplaceableGroup();
            }
        }
        ScopeUpdateScope endRestartGroup = $composer2.endRestartGroup();
        if (endRestartGroup == null) {
            return;
        }
        endRestartGroup.updateScope(new MainActivityKt$Greeting$1(name, $changed));
    }

可以看到，我們狀態(tài)state變量改變的時候，compose會在if里面生成先startReplaceableGroup，代表著這個范圍是可以被替換的，也就是說當(dāng)if成立的時候會生成一個composition節(jié)點，此時如果state變成了false，那么這個if里面的范圍group就會被移除，此時父group（即在之前調(diào)用startgroup的范圍）以替換的方式載入新的else，子group，這就是startReplaceableGroup的含義。

總之，我們可以注意到，key就是一個非常關(guān)鍵的點，就是讓我們compose識別到哪些范圍能夠進(jìn)行重組，哪些不能！在if else語句中，如果我們依賴一個state，就會在相應(yīng)的if語句里面插入一個新的子范圍group，這就是compose架構(gòu)中的的智能重組！

智能重組真的那么智能嗎

上面我們提到了智能重組的這個概念，那么智能重組真的如字面所說，那么“智能”嗎？我們很容易想到，既然compose能在if else這種有作用域的關(guān)鍵字上加上子group，如果是list這種呢？存在著循環(huán)語句的條件呢？就算在循環(huán)語句里面加上子group，并不能滿足我們想要的需求呀！舉個??

@Composable
fun CustomList(list: List<CustromData>) {
   Column {
       for (item in list){
           CustromView(item)
       }
   }
}

我們想要for循環(huán)里面的list，如果list改變了數(shù)據(jù)，我們希望compose只重組改變部分的數(shù)據(jù)，而不是全部list里面的CustromView，那么compose能做到嗎？compose：老子不干了！ 是的！做不到！因為已經(jīng)生成的CustromView的key只能依靠著當(dāng)前的數(shù)據(jù)決定了，比如list的index，如果下次index更改，那么key就會因為index的不一致，導(dǎo)致了list中每一個生成的CustromView再次重組

CustomList部分反編譯代碼

  ColumnScopeInstance columnScopeInstance = ColumnScopeInstance.INSTANCE;
            int $changed2 = ((0 >> 6) & 112) | 6;
            // 只加了一個startReplaceableGroup
            $composer2.startReplaceableGroup(-1487261693);
            ComposerKt.sourceInformation($composer2, "C*52@1739L17:MainActivity.kt#8m9ksz");
            if ((($changed2 & 81) ^ 16) != 0 || !$composer2.getSkipping()) {
                Iterator<CustromData> it = list.iterator();
                // 循環(huán)沒辦法加入子group
                while (it.hasNext()) {
                    Iterator<CustromData> it2 = it;
                    CustromData item = it.next();
                    CustromView(item, $composer2, 0);
                    $changed$iv = $changed$iv;
                    it = it2;
                }
            } else {
                $composer2.skipToGroupEnd();
            }
            $composer2.endReplaceableGroup();

    public static final void CustromView(CustromData data, Composer $composer, int $changed) {
        Intrinsics.checkNotNullParameter(data, "data");
        Composer $composer2 = $composer.startRestartGroup(-201540877);
        ComposerKt.sourceInformation($composer2, "C(CustromView)59@1825L23:MainActivity.kt#8m9ksz");
        int $dirty = $changed;
        if (($changed &amp; 14) == 0) {
            $dirty |= $composer2.changed(data) ? 4 : 2;
        }
        if ((($dirty &amp; 11) ^ 2) != 0 || !$composer2.getSkipping()) {
            TextKt.m1219TextfLXpl1I(data.getTest2(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
        } else {
            $composer2.skipToGroupEnd();
        }
        ScopeUpdateScope endRestartGroup = $composer2.endRestartGroup();
        if (endRestartGroup == null) {
            return;
        }
        endRestartGroup.updateScope(new MainActivityKt$CustromView$1(data, $changed));
    }

所以一旦出現(xiàn)增刪改查list的情況，那么不好意思，compose也就只能把group里面的list再重組一次，如圖：

這也是為什么list系列的compose函數(shù)，比如LazyRow等會被詬病為有性能問題。那么compose就沒有相關(guān)解決方法嗎？嗯！官方肯定準(zhǔn)備了，就是我們可以主動設(shè)置當(dāng)前composable函數(shù)的key！從而避免額外的重組！

@Composable
inline fun <T> key(
    @Suppress("UNUSED_PARAMETER")
    vararg keys: Any?,
    block: @Composable () -> T
) = block()

回到我們自定義的list，就可以這樣使用

for (item in list){
    key(keys = arrayOf(item.test) ) {
        CustromView(item)
    }
}

當(dāng)然，我們的LazyList系列也可以直接指定，在item函數(shù)及其他items函數(shù)中直接使用

interface LazyListScope {
fun item(key: Any? = null, content: @Composable LazyItemScope.() -> Unit)
...

最后

原文鏈接：https://juejin.cn/post/7136444742610452493

欄目分類
最近更新