Flow.shareIn 与 Flow.stateIn 操作符可以将冷流转换为热流: 它们可以将来自上游冷数据流的信息广播给多个收集者。这两个操作符通常用于提升性能: 在没有收集者时加入缓冲；或者干脆作为一种缓存机制使用。

注意 : 冷流 是按需创建的，并且会在它们被观察时发送数据；热流 则总是活跃，无论是否被观察，它们都能发送数据。

本文将会通过示例帮您熟悉 shareIn 与 stateIn 操作符。您将学到如何针对特定用例配置它们，并避免可能遇到的常见陷阱。

底层数据流生产者

继续使用我 之前文章 中使用过的例子——使用底层数据流生产者发出位置更新。它是一个使用 callbackFlow 实现的 冷流。每个新的收集者都会触发数据流的生产者代码块，同时也会将新的回调加入到 FusedLocationProviderClient。

class LocationDataSource(

    private val locationClient: FusedLocationProviderClient

) {

    val locationsSource: Flow<Location> = callbackFlow<Location> {

        val callback = object : LocationCallback() {

            override fun onLocationResult(result: LocationResult?) {

                result ?: return

                try { offer(result.lastLocation) } catch(e: Exception) {}

            }

        }

        requestLocationUpdates(createLocationRequest(), callback, Looper.getMainLooper())

            .addOnFailureListener { e ->

                close(e) // in case of exception, close the Flow

            }

        // 在 Flow 结束收集时进行清理

        awaitClose {

            removeLocationUpdates(callback)

        }

    }

}

让我们看看在不同的用例下如何使用 shareIn 与 stateIn 优化 locationsSource 数据流。

shareIn 还是 stateIn?

我们要讨论的第一个话题是 shareIn 与 stateIn 之间的区别。shareIn 操作符返回的是 SharedFlow 而 stateIn 返回的是 StateFlow。

注意 : 要了解有关 StateFlow 与 SharedFlow 的更多信息，可以查看 我们的文档 。

StateFlow 是 SharedFlow 的一种特殊配置，旨在优化分享状态: 最后被发送的项目会重新发送给新的收集者，并且这些项目会使用 Any.equals 进行合并。您可以在 StateFlow 文档 中查看更多相关信息。

两者之间的最主要区别，在于 StateFlow 接口允许您通过读取 value 属性同步访问其最后发出的值。而这不是 SharedFlow 的使用方式。

提升性能

通过共享所有收集者要观察的同一数据流实例 (而不是按需创建同一个数据流的新实例)，这些 API 可以为我们提升性能。

在下面的例子中，LocationRepository 消费了 LocationDataSource 暴露的 locationsSource 数据流，同时使用了 shareIn 操作符，从而让每个对用户位置信息感兴趣的收集者都从同一数据流实例中收集数据。这里只创建了一个 locationsSource 数据流实例并由所有收集者共享:

class LocationRepository(

    private val locationDataSource: LocationDataSource,

    private val externalScope: CoroutineScope

) {

    val locations: Flow<Location> = 

        locationDataSource.locationsSource.shareIn(externalScope, WhileSubscribed())

}

WhileSubscribed 共享策略用于在没有收集者时取消上游数据流。这样一来，我们便能在没有程序对位置更新感兴趣时避免资源的浪费。

Android 应用小提醒！ 在大部分情况下，您可以使用 WhileSubscribed(5000)，当最后一个收集者消失后再保持上游数据流活跃状态 5 秒钟。这样在某些特定情况 (如配置改变) 下可以避免重启上游数据流。当上游数据流的创建成本很高，或者在 ViewModel 中使用这些操作符时，这一技巧尤其有用。

缓冲事件

在下面的例子中，我们的需求有所改变。现在要求我们保持监听位置更新，同时要在应用从后台返回前台时在屏幕上显示最后的 10 个位置:

class LocationRepository(

    private val locationDataSource: LocationDataSource,

    private val externalScope: CoroutineScope

) {

    val locations: Flow<Location> = 

        locationDataSource.locationsSource

            .shareIn(externalScope, SharingStarted.Eagerly, replay = 10)

}

我们将参数 replay 的值设置为 10，来让最后发出的 10 个项目保持在内存中，同时在每次有收集者观察数据流时重新发送这些项目。为了保持内部数据流始终处于活跃状态并发送位置更新，我们使用了共享策略 SharingStarted.Eagerly，这样就算没有收集者，也能一直监听更新。

缓存数据

我们的需求再次发生变化，这次我们不再需要应用处于后台时 持续 监听位置更新。不过，我们需要缓存最后发送的项目，让用户在获取当前位置时能在屏幕上看到一些数据 (即使数据是旧的)。针对这种情况，我们可以使用 stateIn 操作符。

class LocationRepository(

    private val locationDataSource: LocationDataSource,

    private val externalScope: CoroutineScope

) {

    val locations: Flow<Location> = 

        locationDataSource.locationsSource.stateIn(externalScope, WhileSubscribed(), EmptyLocation)

}

Flow.stateIn 可以缓存最后发送的项目，并重放给新的收集者。

注意！不要在每个函数调用时创建新的实例

切勿 在调用某个函数调用返回时，使用 shareIn 或 stateIn 创建新的数据流。这样会在每次函数调用时创建一个新的 SharedFlow 或 StateFlow，而它们将会一直保持在内存中，直到作用域被取消或者在没有任何引用时被垃圾回收。

class UserRepository(

    private val userLocalDataSource: UserLocalDataSource,

    private val externalScope: CoroutineScope

) {

    // 不要像这样在函数中使用 shareIn 或 stateIn 

    // 这将在每次调用时创建新的 SharedFlow 或 StateFlow，而它们将不会被复用。

    fun getUser(): Flow<User> =

        userLocalDataSource.getUser()

            .shareIn(externalScope, WhileSubscribed())    



    // 可以在属性中使用 shareIn 或 stateIn 

    val user: Flow<User> = 

        userLocalDataSource.getUser().shareIn(externalScope, WhileSubscribed())

}

需要入参的数据流

需要入参 (如 userId) 的数据流无法简单地使用 shareIn 或 stateIn 共享。以开源项目——Google I/O 的 Android 应用 iosched 为例，您可以在 源码中 看到，从 Firestore 获取用户事件的数据流是通过 callbackFlow 实现的。由于其接收 userId 作为参数，因此无法简单使用 shareIn 或 stateIn 操作符对其进行复用。

class UserRepository(

    private val userEventsDataSource: FirestoreUserEventDataSource

) {

    // 新的收集者会在 Firestore 中注册为新的回调。

    // 由于这一函数依赖一个 `userId`，所以在这个函数中

    // 数据流无法通过调用 shareIn 或 stateIn 进行复用.

    // 这样会导致每次调用函数时，都会创建新的  SharedFlow 或 StateFlow

    fun getUserEvents(userId: String): Flow<UserEventsResult> =

        userLocalDataSource.getObservableUserEvents(userId)

}

如何优化这一用例取决于您应用的需求:

• 您是否允许同时从多个用户接收事件？如果答案是肯定的，您可能需要为 SharedFlow 或 StateFlow 实例创建一个 map，并在 subscriptionCount 为 0 时移除引用并退出上游数据流。
• 如果您只允许一个用户，并且收集者需要更新为观察新的用户，您可以向一个所有收集者共用的 SharedFlow 或 StateFlow 发送事件更新，并将公共数据流作为类中的变量。

shareIn 与 stateIn 操作符可以与冷流一同使用来提升性能，您可以使用它们在没有收集者时添加缓冲，或者直接将其作为缓存机制使用。小心使用它们，不要在每次函数调用时都创建新的数据流实例——这样会导致资源的浪费及预料之外的问题！

如题，这种效果类似微信小程序显示的效果，就是打开微信跳一跳后，切换安卓多任务窗口(就是清理内存窗口),会看到如下页面 

微信小程序会在其中显示两个单独的页面，点击跳一跳会进入跳一跳小程序，点击后面的微信，即会进入微信聊天主页面。

在安卓中如何实现呢？

这里有两种方法实现：

第一种：代码动态实现

Intent intent = new Intent(this, SecondActivity.class);

intent.addFlags(Intent.FLAG_ACTIVITY_NEW_DOCUMENT);

intent.addFlags(Intent.FLAG_ACTIVITY_MULTIPLE_TASK);

startActivity(intent);

添加上面的两个Flag即可，有些文章说关闭的时候要使用

finishAndRemoveTask()；

方法，我这边没使用该方法也没发现问题，如果存在潜在问题，知道的人麻烦告知下，谢谢！！！

第二种：在AndroidManifest.xml中配置属性

参考链接:在近期任务列表显示单个APP的多个Activity

第二种方法由于需要写死配置，可能对于我来说作用不大，所以也没有测试，需要了解的人可以查看上面地址。

注意:这里来说下处理第一种方法的问题

使用上面的方法确实是实现了微信小程序多任务窗口的效果，但你会发现两个窗口在文章开头的图中的地方显示的是相同的名字，即你APP的名字，这里就跟小程序有区别了，下面来说下如何实现这种效果：

首先：经过测试，在manifest.xml中给要显示的activity设置android:lable，这种方法是可行的，但会相当于是固定了，不可变了。

然后：在manifest.xml中给该activity设置android:icon也是可以的，这样就实现了显示"跳一跳"文字和logo了。

最后：当然还是同样需要在代码中动态设置，不然固定死对于程序员来说有瑕疵。

在需要显示的activity中调用下面的代码即可显示不同文字

setTaskDescription(new ActivityManager.TaskDescription("跳一跳"));

聪明的程序员都会看下该方法的源码以及需要参数的构造方法，所以同时显示图片和文字以及需要适配就需要用下面的代码了

if( Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP){

    setTaskDescription(new ActivityManager.TaskDescription("跳一跳", mBitmap));

}

没错，需要5.0以上才能实现，参数的构造就需要传入bitmap才能显示图片了。

最终效果图:

存在的问题：当添加flag打开activity之后，如果切换了任务窗口，这时返回是不能返回到之前调用startActivity的方法的页面了，如果没有切换就不会存在这个问题，微信也是一样，像微信大佬都没有解决(也可能没这个需求)，反正我是没有办法滴。

最近准备开始新的项目，在编写base类复写onActivityResult方法时，发现已经提示deprecation了。于是去官网查找了一下，发现现在官方推荐做法是使用 Activity Result API。

本篇文章用来记录一下 Activity Result API 如何使用。

以往的实现方式

以往，A Activity获取B Activity的返回值的实现方法是，A通过startActivityForResult()来启动B，然后B在finish()之前通过setResult()方法来设置结果值，A就可以在onActivityResult()方法中获取到B在setResult()方法中设置的参数。简单示例如下：

class A : Activity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        startActivityForResult(Intent(this,B::class.java))

    }



    override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {

        super.onActivityResult(requestCode, resultCode, data)

        //从B返回后这里就可以获取到resultCode为Activity.RESULT_OK

    }

}



class B: Activity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setResult(Activity.RESULT_OK)

        finish()

    }

}

Activity Result API

现在，在Activity和Fragment中，Activity Result API提供了registerForActivityResult()方法，该方法用于注册获取结果的回调。

registerForActivityResult可以传入ActivityResultContract、ActivityResultRegistry、ActivityResultCallback等3个参数，并返回ActivityResultLauncher。

• ActivityResultContract：ActivityResult合约，约定输入的参数和输出的参数。包含默认合约和自定义合约。
• ActivityResultRegistry：存储已注册的ActivityResultCallback的记录表，可以在非Activity和Fragment的类中借用此类获取ActivityResult。
• ActivityResultCallback：ActivityResult回调，用于获取返回结果。
• ActivityResultLauncher：启动器，根据合约规定的输入参数来启动页面。

Activity Result API的简单使用示例：

class A : Activity() {



    //默认合约

    var forActivityResultLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { activityResult ->

        launcher?.text="lanuncher callback value : resultCode:$resultCode data$data"

    }

    

    //自定义合约（输入输出类型均为String）

    var forActivityResultLauncher1 = registerForActivityResult(object : ActivityResultContract<String, String>() {

        override fun createIntent(context: Context, input: String?): Intent {

            return Intent(this@AActivity, B::class.java).apply {

                putExtra("inputParams", input)

            }

        }



        override fun parseResult(resultCode: Int, intent: Intent?): String {

            return if (resultCode == Activity.RESULT_OK) {

                intent?.getStringExtra("result") ?: "empty result"

            } else {

                ""

            }

        }

    }) { resultString ->

        launcher1?.text = "lanuncher1 callback value : reslutString:$reslutString"

    }



    var launcher: TextView? = null

    var launcher1: TextView? = null



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.layout_a_activity)

        launcher = findViewById(R.id.tv_launcher_callback)

        launcher1 = findViewById(R.id.tv_launcher_callback1)

        val btnLauncher = findViewById<Button>(R.id.launcher)

        val btnLauncher1 = findViewById<Button>(R.id.launcher1)

        btnLauncher.setOnClickListener {

            //默认合约

            forActivityResultLauncher.launch(Intent(this@AActivity, B::class.java))

        }

        

        btnLauncher1.setOnClickListener {

            //自定义合约

            forActivityResultLauncher1.launch("inputParams from A")

        }

    }

}



class B: Activity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.layout_b_activity)

        val btnBack = findViewById<Button>(R.id.back)

        val inputParams = intent.getStringExtra("inputParams")

        btnBack.setOnClickListener {

            if (TextUtils.isEmpty(inputParams)) {

                setResult(Activity.RESULT_OK, Intent())

            } else {

                setResult(Activity.RESULT_OK, Intent().apply {

                    putExtra("result", "result from A")

                })

            }

            finish()

        }

    }

}

示例效果图： 

在非Activity和Fragment的类中接收ActivityResult

示例代码如下:

class A : Activity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        val myActivityResultObserver = MyActivityResultObserver(activityResultRegistry)

        lifecycle.addObserver(myActivityResultObserver)

    }

}



class MyActivityResultObserver(private val registry: ActivityResultRegistry) : DefaultLifecycleObserver {



    override fun onCreate(owner: LifecycleOwner) {

        super.onCreate(owner)

        registry.register("MyActivityResultReceiver", owner, ActivityResultContracts.StartActivityForResult()) {

            

        }

    }

}

前言

官方介绍：LiveData 是一种可观察的数据存储器类。与常规的可观察类不同，LiveData 具有生命周期感知能力，意指它遵循其他应用组件（如 Activity、Fragment 或 Service）的生命周期。这种感知能力可确保 LiveData 仅更新处于活跃生命周期状态的应用组件观察者。 它有以下的优势：

• 确保界面符合数据状态
• 不会发生内存泄露
• 不会因Activity停止而导致崩溃
• 不再需要手动处理生命周期
• 数据始终保持最新状态
• 适当的配置修改
• 共享资源

接下来我们通过基本使用，一步一步的探究LiveData是如何实现这些优势的。

使用

创建 LiveData 对象

public class CoursePreviewModel extends ViewModel {



    /**

     * view状态

     */

    private MutableLiveData<List<CoursePreviewBean.DataBean>> mStateLiveData;



    public MutableLiveData<List<CoursePreviewBean.DataBean>> viewStateLive() {

        if (mStateLiveData == null) {

            mStateLiveData = new MutableLiveData<>();

        }

        return mStateLiveData;

    }

}

观察 LiveData 对象

class CoursePreviewActivity : AppCompatActivity() {



    // Use the 'by viewModels()' Kotlin property delegate

    // from the activity-ktx artifact

    private val mViewModel: CoursePreviewModel by viewModels()



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        // 监听

        mViewModel.viewStateLive().observe(this, target -> {

        });

    }

}

原理分析

这里我们先提出几个问题：

1. LiveData怎么绑定到应用组件的生命周期呢
2. 为什么不需要我们手动处理生命周期，为什么不会因Activity停止而导致崩溃
3. 数据变化又是怎么触发的呢

带着这些问题，我们逐步往里看

一、应用组件生命周期的绑定

当我们需要观察数据变化时，需要调用LiveData的observe接口，这也是LiveData与Activity或Fragment产生关联的地方：

    @MainThread

    public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {

        assertMainThread("observe");

        if (owner.getLifecycle().getCurrentState() == DESTROYED) {

            // ignore

            return;

        }

        LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);

        ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);

        if (existing != null && !existing.isAttachedTo(owner)) {

            throw new IllegalArgumentException("Cannot add the same observer"

                    + " with different lifecycles");

        }

        if (existing != null) {

            return;

        }

        owner.getLifecycle().addObserver(wrapper);

    }

这个方法需要接收两个参数：

• LifecycleOwner：生命周期所有者
• Observer：观察者，用于观察获取变化后的数据

通常我们在Activity或Fragment中使用LiveData，看下androidx包提供的AppCompatActivity和Fragment都是实现了LifecycleOwner接口。所以直接将this作为第一个参数即可。

继续分析上边的observe方法

• 这里会首先判断是否在主线程执行，假如不是即会抛出异常

assertMainThread("observe");

static void assertMainThread(String methodName) {

    if (!ArchTaskExecutor.getInstance().isMainThread()) {

        throw new IllegalStateException("Cannot invoke " + methodName + " on a background"

                + " thread");

    }

}

• 假如是应用组件的生命周期已经是destory的状态，即不会继续往下执行

if (owner.getLifecycle().getCurrentState() == DESTROYED) {

    // ignore

    return;

}

• 通过LifecycleBoundObserver进行真正的逻辑处理，这里我们继续往下走，待会再回头分析这块
• 判断相同的observer不能被不同的LifecycleOwner处理

ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);

if (existing != null && !existing.isAttachedTo(owner)) {

    throw new IllegalArgumentException("Cannot add the same observer"

            + " with different lifecycles");

}

if (existing != null) {

    return;

}

这里主要用到SafeIterableMap这个结构保存owner和observer的关系：

// put之前先判断是否已经包含了该key，假如是则直接返回相应的value

public V putIfAbsent(@NonNull K key, @NonNull V v) {

    Entry<K, V> entry = get(key);

    if (entry != null) {

        return entry.mValue;

    }

    put(key, v);

    return null;

}

• 最后，将生命周期所有者与observer绑定起来，这样子observer即可接收到相应的生命周期

owner.getLifecycle().addObserver(wrapper);

可以看到，这里不是直接add传递进来的Observer，而是上边提到的包装了owner和Observer的LifecycleBoundObserver。所以接下来我们好好分析下它：

class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {

    @NonNull

    final LifecycleOwner mOwner;



    LifecycleBoundObserver(@NonNull LifecycleOwner owner, Observer<? super T> observer) {

        super(observer);

        mOwner = owner;

    }



    @Override

    boolean shouldBeActive() {

        return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);

    }



    @Override

    public void onStateChanged(@NonNull LifecycleOwner source,

            @NonNull Lifecycle.Event event) {

        if (mOwner.getLifecycle().getCurrentState() == DESTROYED) {

            removeObserver(mObserver);

            return;

        }

        activeStateChanged(shouldBeActive());

    }



    @Override

    boolean isAttachedTo(LifecycleOwner owner) {

        return mOwner == owner;

    }



    @Override

    void detachObserver() {

        mOwner.getLifecycle().removeObserver(this);

    }

}

可以看到，LifecycleBoundObserver是实现了LifecycleEventObserver接口，而LifecycleEventObserver接口是继承于LifecycleObserver接口的，因此可以看出主要是在LifecycleBoundObserver这里完成生命周期的处理。

二、为什么不需要手动处理生命周期

经过上边的分析，我们发现其实主要的生命周期处理工作是在LifecycleBoundObserver里边完成的。我们继续看它的源码，有这么两个方法：

    @Override

    public void onStateChanged(@NonNull LifecycleOwner source,

            @NonNull Lifecycle.Event event) {

        if (mOwner.getLifecycle().getCurrentState() == DESTROYED) {

            removeObserver(mObserver);

            return;

        }

        activeStateChanged(shouldBeActive());

    }

    

    @Override

    void detachObserver() {

        mOwner.getLifecycle().removeObserver(this);

    }

我们先看detachObserver，这里明显就是用于解除绑定的。我们找下哪里调用了这个方法：

@MainThread

public void removeObserver(@NonNull final Observer<? super T> observer) {

    assertMainThread("removeObserver");

    ObserverWrapper removed = mObservers.remove(observer);

    if (removed == null) {

        return;

    }

    removed.detachObserver();

    removed.activeStateChanged(false);

}

主要是在LiveData的removeObserver，那继续找下该方法的调用。发现又回到了LifecycleBoundObserver本身，不错就是在onStateChanged里边，它会接收生命周期的变化通知，当发现mOwner.getLifecycle().getCurrentState() == DESTROYED即组件处于destory状态时，自动移除相应的观察者，这样子当activity或fragment销毁时，不会再收到相应的事件通知

三、数据变化怎么触发的

我们继续将核心放在LifecycleBoundObserver的onStateChanged方法上。当组件还没销毁，即会继续往下跑activeStateChanged(shouldBeActive());，该方法定义在ObserverWrapper类里边（LifecycleBoundObserver继承于它）

void activeStateChanged(boolean newActive) {

    if (newActive == mActive) {

        return;

    }

    // immediately set active state, so we'd never dispatch anything to inactive

    // owner

    mActive = newActive;

    boolean wasInactive = LiveData.this.mActiveCount == 0;

    LiveData.this.mActiveCount += mActive ? 1 : -1;

    if (wasInactive && mActive) {

        onActive();

    }

    if (LiveData.this.mActiveCount == 0 && !mActive) {

        onInactive();

    }

    if (mActive) {

        dispatchingValue(this);

    }

}

当处于活跃状态，即mActive为true时，会走到dispatchingValue(this);。我们继续看

void dispatchingValue(@Nullable ObserverWrapper initiator) {

    if (mDispatchingValue) {

        mDispatchInvalidated = true;

        return;

    }

    mDispatchingValue = true;

    do {

        mDispatchInvalidated = false;

        if (initiator != null) {

            considerNotify(initiator);

            initiator = null;

        } else {

            for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =

                    mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {

                considerNotify(iterator.next().getValue());

                if (mDispatchInvalidated) {

                    break;

                }

            }

        }

    } while (mDispatchInvalidated);

    mDispatchingValue = false;

}

核心在于considerNotify方法

private void considerNotify(ObserverWrapper observer) {

    if (!observer.mActive) {

        return;

    }

    // Check latest state b4 dispatch. Maybe it changed state but we didn't get the event yet.

    //

    // we still first check observer.active to keep it as the entrance for events. So even if

    // the observer moved to an active state, if we've not received that event, we better not

    // notify for a more predictable notification order.

    if (!observer.shouldBeActive()) {

        observer.activeStateChanged(false);

        return;

    }

    if (observer.mLastVersion >= mVersion) {

        return;

    }

    observer.mLastVersion = mVersion;

    observer.mObserver.onChanged((T) mData);

}

直接看到最后一句，这里直接调用了observer.mObserver.onChanged((T) mData);，这里就会触发数据变化回调。而这里的mObserver即是我们在刚开始传递进来的。

其他

一、observeForever

其实，LiveData除了提供observe用于方法，还提供了一个observeForever方法

@MainThread

public void observeForever(@NonNull Observer<? super T> observer) {

    assertMainThread("observeForever");

    AlwaysActiveObserver wrapper = new AlwaysActiveObserver(observer);

    ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);

    if (existing instanceof LiveData.LifecycleBoundObserver) {

        throw new IllegalArgumentException("Cannot add the same observer"

                + " with different lifecycles");

    }

    if (existing != null) {

        return;

    }

    wrapper.activeStateChanged(true);

}

这里可以看到，没有跟生命周期绑定，也不再使用LifecycleBoundObserver进行包装，而是使用AlwaysActiveObserver：

private class AlwaysActiveObserver extends ObserverWrapper {



    AlwaysActiveObserver(Observer<? super T> observer) {

        super(observer);

    }



    @Override

    boolean shouldBeActive() {

        return true;

    }

}

AlwaysActiveObserver和LifecycleBoundObserver都继承于ObserverWrapper，但是前者没有重写它的detachObserver方法，因此它不会被自动移除监听。只能通过手动调用removeObserver进行移除。

二、postValue和setValue

两个方法都可以用于更新值，分析下区别：

protected void postValue(T value) {

    boolean postTask;

    synchronized (mDataLock) {

        postTask = mPendingData == NOT_SET;

        mPendingData = value;

    }

    if (!postTask) {

        return;

    }

    ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);

}



@MainThread

protected void setValue(T value) {

    assertMainThread("setValue");

    mVersion++;

    mData = value;

    dispatchingValue(null);

}

1. setValue必须在主线程调用，否则会抛出异常
2. postValue用于在其他线程更新值，核心在：ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);，这会切回到主线程执行。
3. 由于postValue是通过handler的消息派发进行处理，而setValue直接设值，因此这种情况需要注意：

// 源码提示

Posts a task to a main thread to set the given value. So if you have a following code executed in the main thread:

       liveData.postValue("a");

       liveData.setValue("b");

       

The value "b" would be set at first and later the main thread would override it with the value "a".

4. 如果在主线程执行已发布任务之前多次调用此方法，则只会调度最后一个值。这个是怎么实现的呢？我们看下postValue里边的处理

protected void postValue(T value) {

    boolean postTask;

    synchronized (mDataLock) {

        postTask = mPendingData == NOT_SET;

        mPendingData = value;

    }

    if (!postTask) {

        return;

    }

    ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);

}



private final Runnable mPostValueRunnable = new Runnable() {

    @SuppressWarnings("unchecked")

    @Override

    public void run() {

        Object newValue;

        synchronized (mDataLock) {

            newValue = mPendingData;

            mPendingData = NOT_SET;

        }

        setValue((T) newValue);

    }

};

第一次，mPendingData的值为NOT_SET，因此postTask为true，而mPendingData为设置的value。直到mPostValueRunnable被执行时，mPendingData才被重新赋值为NOT_SET。假如在主线程执行前，不断的调用postValue，postTask一直为false，mPendingData会被更新到最新设置的值，但是mPostValueRunnable不会被重复执行。

我们在开发中肯定会经常用Kotlin提供的一些通用拓展函数，当我们进去看源码的时候会发现许多函数里面有contract {}包裹的代码块，那么这些代码块到底有什么作用呢？？

测试

接下来用以下两个我们常用的拓展函数作为例子

public inline fun <T, R> T.run(block: T.() -> R): R {

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return block()

}



public inline fun CharSequence?.isNullOrEmpty(): Boolean {

    contract {

        returns(false) implies (this@isNullOrEmpty != null)

    }



    return this == null || this.length == 0

}

run和isNullOrEmpty我相信大家在开发中是经常见到的。

不知道那些代码有什么作用，那么我们就把那几行代码去掉，然后看看函数使用起来有什么区别。

public inline fun <T, R> T.runWithoutContract(block: T.() -> R): R {

    return block()

}



public inline fun CharSequence?.isNullOrEmptyWithoutContract(): Boolean {

    return this == null || this.length == 0

}

上面是去掉了contract{}代码块后的两个函数 调用看看

fun test() {

    var str1: String = ""

    var str2: String = ""



    runWithoutContract {

        str1 = "jayce"

    }

    run {

        str2 = "jayce"

    }



    println(str1) //jayce

    println(str2) //jayce

}

经过测试发现，看起来好像没什么问题，run代码块都能都正常执行，做了赋值的操作。

那么如果是这样呢

将str的初始值去掉，在run代码块里面进行初始化操作

@Test

fun test() {

    var str1: String

    var str2: String 



    runWithoutContract {

        str1 = "jayce"

    }

    run {

        str2 = "jayce"

    }



    println(str1) //编译不通过 （Variable 'str1' must be initialized）

    println(str2) //编译通过

}

？？？？？？

我们不是在runWithoutContract做了初始化赋值的操作了吗？怎么IDE还报错，难道是IDE出了什么问题？好 有问题就重启，我去，重启还没解决。。。。好重装。不不不！！别急 会不会Contract代码块就是干这个用的？是不是它悄悄的跟IDE说了什么话 以至于它能正常编译通过？

好 这个问题先放一放 我们再看看没contract版本的isNullOrEmpty对比有contract的有什么区别

fun test() {

    val str: String? = "jayce"



    if (!str.isNullOrEmpty()) {

        println(str) //jayce

    }

    if (!str.isNullOrEmptyWithoutContract()) {

        println(str) //jayce

    }

}

发现好像还是没什么问题。相信大家根据上面遇到的问题可以猜测，这其中肯定也有坑。

比如这种情况

fun test() {

    val str: String? = "jayce"



    if (!str.isNullOrEmpty()) {

        println(str.length) // 编译通过

    }



    if (!str.isNullOrEmptyWithoutContract()) {

        println(str.length) // 编译不通过（Only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type String?）

    }

}

根据错误提示可以看出，在isNullOrEmptyWithoutContract判断为flase之后的代码块，str这个字段还是被IDE认为是一个可空类型，必须要进行空检查才能通过。然而在isNullOrEmpty返回flase之后的代码块，IDE认为str其实已经是非空了，所以使用前就不需要进行空检查。

查看 contract 函数

public inline fun contract(builder: ContractBuilder.() -> Unit) { }

点进去源码，我们可以看到contract是一个内联函数，接收一个函数类型的参数，该函数是ContractBuilder的一个拓展函数（也就是说在这个函数体里面拥有ContractBuilder的上下文）

看看ContractBuilder给我们提供了哪些函数（主要就是依靠这些函数来约定我们自己写的lambda函数）

public interface ContractBuilder {

  	//描述函数正常返回，没有抛出任何异常的情况。

    @ContractsDsl public fun returns(): Returns



  	//描述函数以value返回的情况，value可以取值为 true|false|null。

    @ContractsDsl public fun returns(value: Any?): Returns

  

  	//描述函数以非null值返回的情况。

    @ContractsDsl public fun returnsNotNull(): ReturnsNotNull



   	//描述lambda会在该函数调用的次数，次数用kind指定

    @ContractsDsl public fun <R> callsInPlace(lambda: Function<R>, kind: InvocationKind = InvocationKind.UNKNOWN): CallsInPlace

}

returns

其中 returns() returns(value) returnsNotNull() 都会返回一个继承于SimpleEffect的Returns 接下来看看SimpleEffect

public interface SimpleEffect : Effect {

  	//接收一个Boolean值的表达式 改函数用来表示当SimpleEffect成立之后 保证Boolean值的表达式返回值为true

  	//表达式可以传判空代码块（`== null`, `!= null`）判断实例语句 (`is`, `!is`)。

    public infix fun implies(booleanExpression: Boolean): ConditionalEffect

}

可以看到SimpleEffect里面有一个中缀函数implies 。可以使用ContractBuilder的函数指定某种返回的情况 然后用implies来声明传入的表达式为true。

看到这里 那么我们应该就知道 isNullOrEmpty() 加的contract是什么意思了

public inline fun CharSequence?.isNullOrEmpty(): Boolean {

    contract {

      	//返回值为false的情况 returns(false）

				//意味着 implies

				//调用该函数的对象不为空 (this@isNullOrEmpty != null)

        returns(false) implies (this@isNullOrEmpty != null)

    }

  

    return this == null || this.length == 0

}

因为isNullOrEmpty里面加了contract代码块，告诉IDE说：返回值为false的情况意味着调用该函数的对象不为空。所以我们就可以直接在判断语句后直接使用非空的对象了。

有些同学可能还是不理解，这里再举一个没什么用的例子（运行肯定会crash哈。。。）

@ExperimentalContracts //因为该特性还在试验当中 所以需要加上这个注解

fun CharSequence?.isNotNull(): Boolean {

    contract {

      	//返回值为true returns(true)

      	//意味着implies

      	//调用该函数的对象是StringBuilder (this@isNotNull is StringBuilder)

        returns(true) implies (this@isNotNull is StringBuilder)

    }



    return this != null

}



fun test() {                                                                                               

    val str: String? = "jayce"                                                                             

                                                                                                           

    if (str.isNotNull()) {                                                                                 

        str.append("")//String可是没有这个函数的，因为我们用contract让他强制转换成StringBuilder了 所以才有了这个函数                       

    }                                                                                                      

}

是的 这样IDE居然没有报错，因为经过我们contract的声明，只要这个函数返回true，调用函数的对象就是一个StringBuilder。

callsInPlace

//描述lambda会在该函数调用的次数，次数用kind指定

@ContractsDsl public fun <R> callsInPlace(lambda: Function<R>, kind: InvocationKind = InvocationKind.UNKNOWN): CallsInPlace

可以知道callsInPlace是用来指定lambda函数调用次数的

kind有四种取值

• InvocationKind.AT_MOST_ONCE：最多调用一次
• InvocationKind.AT_LEAST_ONCE：最少调用一次
• InvocationKind.EXACTLY_ONCE：调用一次
• InvocationKind.UNKNOWN：未知，不指定的默认值

我们再看回去之前run函数里面的contract声明了什么

public inline fun <T, R> T.run(block: T.() -> R): R {

    contract {

      	//block这个函数，刚好调用一次

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return block()

}

看到这里 应该就知道为什么我们自己写的runWithoutContract会报错（Variable 'str1' must be initialized），而系统的run却不会报错了，因为run声明了lambda会调用一次，所以就一定会对str2做初始化操作，然而runWithoutContract却没有声明，所以IDE就会报错（因为有可能不会调用，所以就不会做初始化操作了）。

总结

1. Kotlin提供了一些自动转换的功能，例如平时判空和判断是否为某个实例的时候，Kotlin都会为我们自动转换。但是如果这个判断被提取到其他函数的时候，这个转换会失效。所以提供了contract给我们在函数体添加声明，编译器会遵守我们的约定。
2. 当使用一个高阶函数的时候，可以使用callsInPlace指定该函数会被调用的次。例如在函数体里面做初始化，如果申明为EXACTLY_ONCE的时候，IDE就不会报错，因为编译器会遵守我们的约定。

前言

跟我学flutter系列：
跟我学flutter：我们来举个例子通俗易懂讲解dart 中的 mixin
跟我学flutter：我们来举个例子通俗易懂讲解异步（一）ioslate
跟我学flutter：我们来举个例子通俗易懂讲解异步（二）ioslate循环机制
企业级篇目：
跟我学企业级flutter项目：用bloc手把手教你搭建用户认证系统
跟我学企业级flutter项目：dio网络框架增加公共请求参数&header
跟我学企业级flutter项目：如何用dio封装一套企业级可扩展高效的网络层
跟我学企业级flutter项目：如何封装一套易用，可扩展的Hybrid混合开发webview
跟我学企业级flutter项目：手把手教你制作一款低耦合空页面widget

在开发过程中，我们经常会用到网络请求，在flutter框架中，dio框架非常不错，所以今天的文章在dio的基础上搭建一套网络持久化框架，那么在flutter项目中如何搭建一套，高可用性，维护性较高的dio公共请求参数框架呢？

搭建前夕准备

一、基本认知

1. 要持久化那么必然要有存储设备
2. 持久化的数据在app启动后要即使填充到项目中
3. 由于项目中网络请求地址繁多，类型不同，需要持久化的位置不同

二、基于基本认知来找合适的工具&必要点

2.1 持久化的工具：

我的推荐

1. mmkv
2. share_prefresence

今天主要用讲解mmkv版本

2.2必要点：

dio拦截器

拦截器是搭建这套持久化的关键

三、准备好如上技能，我们来搭建这套持久化网络框架吧

1、首先要知道有几种类型的公共

  //请求中url后追加公共请求

  static const int urlPresistent = 1;

  //请求头中追加公共请求

  static const int headerPresistent = 2;

  //全部都追加公共请求

  static const int allPresistent = 3;

2、构建缓存参数（为了快速获取）

  static Map> headerPersistent = Map();

  static Map> urlPersistent = Map();

3、构建mmkv存储结构（加密存储）

static MMKV _store(String baseUrl, int type) => MMKVStore.sysSafeMMKV(name: '${SysConfig.sysPersistent}${baseUrl}_${type.toString()}');

4、构建基本函数

单健值对存储

static void setPersistent(String baseUrl,String key,String? value,{int type = allPresistent}){

    if (type == allPresistent || type == headerPresistent) {

      if (!headerPersistent.containsKey(baseUrl)) {

        headerPersistent[baseUrl] = Map();

      }

      var keyMap = headerPersistent[baseUrl]!;

      keyMap[key] = value;

      _store(baseUrl, headerPresistent).encodeString(key, value??"");

    }

    if (type == allPresistent || type == urlPresistent) {

      if (!urlPersistent.containsKey(baseUrl)) {

        urlPersistent[baseUrl] = Map();

      }

      var keyMap = urlPersistent[baseUrl]!;

      keyMap[key] = value;

      _store(baseUrl, urlPresistent).encodeString(key, value??"");

    }

  }

多健值对存储

static void setPersistentMap(String baseUrl,Map map,{int type = allPresistent}){

    if (type == allPresistent || type == headerPresistent) {

      if (!headerPersistent.containsKey(baseUrl)) {

        headerPersistent[baseUrl] = Map();

      }

      var keyMap = headerPersistent[baseUrl]!;

      keyMap.addAll(map);

      keyMap.forEach((key, value) {

        _store(baseUrl, headerPresistent).encodeString(key, value??"");

      });

    }

    if (type == allPresistent || type == urlPresistent) {

      if (!urlPersistent.containsKey(baseUrl)) {

        urlPersistent[baseUrl] = Map();

      }

      var keyMap = urlPersistent[baseUrl]!;

      keyMap.addAll(map);

      keyMap.forEach((key, value) {

        _store(baseUrl, urlPresistent).encodeString(key, value??"");

      });

    }

  }

参数获取：

  static Map? getPersistent(String baseUrl, {int type = allPresistent}) {

    Map? map;

    if (type == allPresistent || type == headerPresistent) {

      Map? headerMap;

      if (headerPersistent.containsKey(baseUrl)) {

        headerMap = headerPersistent[baseUrl];

      } else {

        headerMap = null;

      }

      if (headerMap != null) {

        if (map == null) {

          map = Map();

        }

        map.addAll(headerMap);

      }

    }

    if (type == allPresistent || type == urlPresistent) {

      Map? urlMap;

      if (urlPersistent.containsKey(baseUrl)) {

        urlMap = urlPersistent[baseUrl];

      } else {

        urlMap = null;

      }



      if (urlMap != null) {

        if (map == null) {

          map = Map();

        }

        map.addAll(urlMap);

      }

    }

    return map;

  }

刷新当前缓存（应用启动刷新）

  static Map _all(String baseurl, int type) {

    var mmkv= _store(baseurl, type);

    var keys = mmkv.allKeys;

    var map = Map();

    keys.forEach((element) {

      var value = mmkv.decodeString(element);

      map[element] = value;

    });

    return map;

  }



  static void flushPersistent(String baseurl, {int type = allPresistent}) {

    if (type == allPresistent || type == headerPresistent) {

      var map = _all(baseurl, headerPresistent);

      headerPersistent[baseurl]?.clear();



      if (!headerPersistent.containsKey(baseurl)) {

        headerPersistent[baseurl] = Map();

      }

      var keyMap = headerPersistent[baseurl]!;

      keyMap.addAll(map);

    }

    if (type == allPresistent || type == urlPresistent) {

      var map = _all(baseurl, urlPresistent);

      urlPersistent[baseurl]?.clear();

      if (!urlPersistent.containsKey(baseurl)) {

        urlPersistent[baseurl] = Map();

      }

      var keyMap = urlPersistent[baseurl]!;

      keyMap.addAll(map);

    }



  }

退出登陆移除持久化

static void removeAllPersistent(String baseurl, {int type = allPresistent}) {

    if (type == allPresistent || type == headerPresistent) {

      headerPersistent[baseurl]?.clear();

      _store(baseurl, headerPresistent).clearAll();

    }

    if (type == allPresistent || type == urlPresistent) {

      urlPersistent[baseurl]?.clear();

      _store(baseurl, urlPresistent).clearAll();

    }

  }

拦截器实现（dio请求拦截管理）

class PresistentInterceptor extends Interceptor {



  @override

  void onRequest(RequestOptions options, RequestInterceptorHandler handler) {

    var urlPersitents = HttpPersistent.getPersistent(options.baseUrl,type: HttpPersistent.urlPresistent);

    var headerPersitents = HttpPersistent.getPersistent(options.baseUrl,

        type: HttpPersistent.headerPresistent);

    headerPersitents?.forEach((key, value) {

      options.headers[key] = value;

    });



    urlPersitents?.forEach((key, value) {

      options.queryParameters[key] = value;

    });

    super.onRequest(options, handler);

  }



}

四、整体代码&事件调用逻辑

整体代码

class HttpPersistent{



  static const int urlPresistent = 1;

  static const int headerPresistent = 2;

  static const int allPresistent = 3;



  static MMKV _store(String baseUrl, int type) => MMKVStore.sysSafeMMKV(name: '${SysConfig.sysPersistent}${baseUrl}_${type.toString()}');

  static Map> headerPersistent = Map();

  static Map> urlPersistent = Map();



  static void setPersistent(String baseUrl,String key,String? value,{int type = allPresistent}){

    if (type == allPresistent || type == headerPresistent) {

      if (!headerPersistent.containsKey(baseUrl)) {

        headerPersistent[baseUrl] = Map();

      }

      var keyMap = headerPersistent[baseUrl]!;

      keyMap[key] = value;

      _store(baseUrl, headerPresistent).encodeString(key, value??"");

    }

    if (type == allPresistent || type == urlPresistent) {

      if (!urlPersistent.containsKey(baseUrl)) {

        urlPersistent[baseUrl] = Map();

      }

      var keyMap = urlPersistent[baseUrl]!;

      keyMap[key] = value;

      _store(baseUrl, urlPresistent).encodeString(key, value??"");

    }

  }



  static void setPersistentMap(String baseUrl,Map map,{int type = allPresistent}){

    if (type == allPresistent || type == headerPresistent) {

      if (!headerPersistent.containsKey(baseUrl)) {

        headerPersistent[baseUrl] = Map();

      }

      var keyMap = headerPersistent[baseUrl]!;

      keyMap.addAll(map);

      keyMap.forEach((key, value) {

        _store(baseUrl, headerPresistent).encodeString(key, value??"");

      });

    }

    if (type == allPresistent || type == urlPresistent) {

      if (!urlPersistent.containsKey(baseUrl)) {

        urlPersistent[baseUrl] = Map();

      }

      var keyMap = urlPersistent[baseUrl]!;

      keyMap.addAll(map);

      keyMap.forEach((key, value) {

        _store(baseUrl, urlPresistent).encodeString(key, value??"");

      });

    }

  }



  static Map? getPersistent(String baseUrl, {int type = allPresistent}) {

    Map? map;

    if (type == allPresistent || type == headerPresistent) {

      Map? headerMap;

      if (headerPersistent.containsKey(baseUrl)) {

        headerMap = headerPersistent[baseUrl];

      } else {

        headerMap = null;

      }

      if (headerMap != null) {

        if (map == null) {

          map = Map();

        }

        map.addAll(headerMap);

      }

    }

    if (type == allPresistent || type == urlPresistent) {

      Map? urlMap;

      if (urlPersistent.containsKey(baseUrl)) {

        urlMap = urlPersistent[baseUrl];

      } else {

        urlMap = null;

      }



      if (urlMap != null) {

        if (map == null) {

          map = Map();

        }

        map.addAll(urlMap);

      }

    }

    return map;

  }



  static Map _all(String baseurl, int type) {

    var mmkv= _store(baseurl, type);

    var keys = mmkv.allKeys;

    var map = Map();

    keys.forEach((element) {

      var value = mmkv.decodeString(element);

      map[element] = value;

    });

    return map;

  }



  static void flushPersistent(String baseurl, {int type = allPresistent}) {

    if (type == allPresistent || type == headerPresistent) {

      var map = _all(baseurl, headerPresistent);

      headerPersistent[baseurl]?.clear();



      if (!headerPersistent.containsKey(baseurl)) {

        headerPersistent[baseurl] = Map();

      }

      var keyMap = headerPersistent[baseurl]!;

      keyMap.addAll(map);

    }

    if (type == allPresistent || type == urlPresistent) {

      var map = _all(baseurl, urlPresistent);

      urlPersistent[baseurl]?.clear();

      if (!urlPersistent.containsKey(baseurl)) {

        urlPersistent[baseurl] = Map();

      }

      var keyMap = urlPersistent[baseurl]!;

      keyMap.addAll(map);

    }



  }



  static void removeAllPersistent(String baseurl, {int type = allPresistent}) {

    if (type == allPresistent || type == headerPresistent) {

      headerPersistent[baseurl]?.clear();

      _store(baseurl, headerPresistent).clearAll();

    }

    if (type == allPresistent || type == urlPresistent) {

      urlPersistent[baseurl]?.clear();

      _store(baseurl, urlPresistent).clearAll();

    }

  }

}







class PresistentInterceptor extends Interceptor {



  @override

  void onRequest(RequestOptions options, RequestInterceptorHandler handler) {

    var urlPersitents = HttpPersistent.getPersistent(options.baseUrl,type: HttpPersistent.urlPresistent);

    var headerPersitents = HttpPersistent.getPersistent(options.baseUrl,

        type: HttpPersistent.headerPresistent);

    headerPersitents?.forEach((key, value) {

      options.headers[key] = value;

    });



    urlPersitents?.forEach((key, value) {

      options.queryParameters[key] = value;

    });

    super.onRequest(options, handler);

  }



}

1、登陆后，调用存储 HttpPersistent.setPersistent("http://www.baidu.com","token","123",HttpPersistent.headerPresistent)

 2、退出登陆后，调用移除 HttpPersistent.removeAllPersistent("http://www.baidu.com",,type: HttpPersistent.headerPresistent); 

3、应用启动后刷新缓存
HttpPersistent.flushPersistent("http://www.baidu.com", type: HttpPersistent.headerPresistent);

五、大功告成

如上就构建出一套可靠性高，维护性高的网络持久化框架

更多flutter教程请关注我的IMGeek：http://www.imgeek.org/people/3369…

👉关于作者

众所周知，人生是一个漫长的流程，不断克服困难，不断反思前进的过程。在这个过程中会产生很多对于人生的质疑和思考，于是我决定将自己的思考，经验和故事全部分享出来，以此寻找共鸣！！！

专注于Android/Unity和各种游戏开发技巧，以及各种资源分享（网站、工具、素材、源码、游戏等）

欢迎关注公众号【空名先生】获取更多资源和交流！

👉前提

前面我们学了Kotlin语言，趁热打铁我们试试Kotlin在Android中的应用。

如果是新手，请先学完Android基础。

推荐先看小空之前写的熬夜Android系列，再来尝试。

👉实践过程

😜方式一

Java中有static关键字，而且我们常用，在Kotlin中是伴生对象，使用方式如下：

class LoginFragment : Fragment() {

    companion object {

        //默认无权限修饰符的话，就public类型

        const val APP_Name = "空名先生"

        var APP_Name_Change = "空名先生"

        private const val APP_Author = "芝麻粒儿"

    }

}

class MainActivity : AppCompatActivity(), View.OnClickListener {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

        Log.e("TAG", "onCreate: " + LoginFragment.APP_Name)

        // Log.e("TAG", "onCreate: "+LoginFragment.APP_Author ) //无法调用，因为是私有类型private

        LoginFragment.APP_Name_Change="我修改了你的名字"

        Log.e("TAG", "onCreate: " + LoginFragment.APP_Name_Change)

}

}

输出结果：
2021-10-19 16:04:26.574 22369-22369/cn.appstudy E/TAG: onCreate: 空名先生
2021-10-19 16:04:26.577 22369-22369/cn.appstudy E/TAG: onCreate: 我修改了你的名字

上面是关于变量的使用，那方法呢？Java中方法加上【static】关键字就是静态再加上public就是公开的了，哪都能用。Kotlin呢？

companion object {

    fun myWork() {

        Log.e("TAG", "方法：我的工作是研发")

    }

    //默认无权限修饰符的话，就public类型

    const val APP_Name = "空名先生"

    var APP_Name_Change = "空名先生"

    private const val APP_Author = "芝麻粒儿"

}

如上在里面正常些函数，其他的kt文件中就能调用。

难道就这么简单？

注意，重点来了。如果在Java中调用Kotlin呢？

我们创建个【TextActivity】，调用下：

public class TextActivity extends AppCompatActivity {

    public static String myName = "";



    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_text);

        //LoginFragment.myWork();  //无法调用

        //LoginFragment.setAPP_Name_Change("修改名字"); //无法调用

        LoginFragment.Companion.myWork();

        LoginFragment.Companion.setAPP_Name_Change("修改名字");

    }

}

从实践中我们得知，在KT的companion object中做的任何声明，在Java中不能直接调用，而是利用【Companion】实体调用出来的，这就相当于new个类，调用实例方法了，而非静态方法。

所以需要这样：

companion object {



        @JvmStatic

        fun myWork() {

            Log.e("TAG", "方法：我的工作是研发")

        }



        //默认无权限修饰符的话，就public类型

        const val APP_Name = "空名先生"

 

        @JvmStatic

        var APP_Name_Change = "空名先生"

        private const val APP_Author = "芝麻粒儿"

        //非const类型的常量 val修饰的，要想Java中作为静态引用需要@JvmField

        @JvmField

        val MY_APP = "我的作品"

}

public class TextActivity extends AppCompatActivity {



    public static String myName = "";



    @Override

    protected void onCreate(Bundle savedInstanceState) {



        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_text);

        //LoginFragment.myWork();  //无法调用

        //LoginFragment.setAPP_Name_Change("修改名字"); //无法调用

        Log.e("TAG", "onCreate: " + LoginFragment.APP_Name);

        //这些使用均正常，即使添加了@JvmStatic,仍然可以用Companion实例形式调用

        LoginFragment.Companion.myWork();

        LoginFragment.Companion.setAPP_Name_Change("修改名字");

        LoginFragment.myWork();

        LoginFragment.getAPP_Name_Change();

        Log.e("TAG", "onCreate: " + LoginFragment.MY_APP);

        Log.e("TAG", "onCreate: " + LoginFragment.APP_Name);

    }

}

运行后你再试试，会发现，哎？真的，没有那么多吐司了，真的好啊。

要想实现Java中直接点出来的静态形式

• var类型的要添加@JvmStatic
• const修饰的不用管
• 方法使用@JvmStatic
• 非const修饰却为val类型的使用@JvmField

在之前的篇幅介绍中，我们在构造函数中都没有使用key，只要继承于Widget的都默认有这个key属性，这是一个可选属性。下面我们通过案例来研究一个key的作用。

const MyApp({Key? key}) : super(key: key);

StatefulWidget中的key

先搭建一个页面，在页面的中间位置随机创建不同颜色的正方形

class _MyHomePageState extends State<MyHomePage> {

  List<SquareItem1> list = [

    const SquareItem1('上上上', key: ValueKey(111),),

    const SquareItem1('中中中', key: ValueKey(222),),

    const SquareItem1('下下下', key: ValueKey(333),)

  ];



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: Text(widget.title),

      ),

      body: Center(

        child: Column(

          mainAxisAlignment: MainAxisAlignment.center,

          children: list,

        ),

      ),

      floatingActionButton: FloatingActionButton(

        onPressed: () {

          setState(() {

            list.removeAt(0);

          });

        },

        child: const Icon(Icons.add),

      ), // This trailing comma makes auto-formatting nicer for build methods.

    );

  }

}

其中SquareItem1的构造方法如下：const SquareItem1(this.title, {Key? key}) : super(key: key);

import 'dart:math';

import 'package:flutter/material.dart';

class SquareItem1 extends StatefulWidget {

  final String title;

  const SquareItem1(this.title, {Key? key}) : super(key: key);



  @override

  _SquareItem1State createState() => _SquareItem1State();

}



class _SquareItem1State extends State<SquareItem1> {

  final color = Color.fromRGBO(

      Random().nextInt(256), Random().nextInt(256), Random().nextInt(256), 1.0);

  @override

  Widget build(BuildContext context) {

    return Container(

      width: 100,

      height: 100,

      color: color,

      child: Text(widget.title),

    );

  }

}

在点击按钮的时候，一次删除数组中的第一个元素 仔细看，通过实验对比可以明显的发现，此时顺序似乎是有点问题，那么问题出在哪里？

• 先看文字：文字的话似乎顺序没有问题，每一次都删除最上面的
• 再看颜色：颜色话倒像从是后面开始删除的，每次把最后一个删掉

带着这个疑问，我们再来看看StatelessWidget中的key

StatelessWidget中的key

这次继承的是StatelessWidget,其中SquareItem1的构造方法如下：SquareItem(this.title, {Key? key}) : super(key: key);

import 'dart:math';

import 'package:flutter/material.dart';



class SquareItem extends StatelessWidget {

  final String title;

  SquareItem(this.title, {Key? key}) : super(key: key);



  final color = Color.fromRGBO(

      Random().nextInt(256), Random().nextInt(256), Random().nextInt(256), 1.0);

  @override

  Widget build(BuildContext context) {

    return Container(

      width: 100,

      height: 100,

      color: color,

      child: Text(title),

    );

  }

}

经过观察发现，此次的remove的顺序没有问题，颜色和文字都能一一对应上。通过两边的代码对比发现唯一的差别可能就是color初始化的位置区别，一个是在State中初始化，一个是在Widget中初始化，那是不是就是这个原因呢，我们接着研究。

key的使用

在StatefulWidget中我们可以通过给key赋值来区分不同的Widget，示例

  List<SquareItem1> list = [

    const SquareItem1(

      '上上上',

      key: ValueKey(111),

    ),

    const SquareItem1(

      '中中中',

      key: ValueKey(222),

    ),

    const SquareItem1(

      '下下下',

      key: ValueKey(333),

    )

  ];

此时再运行发现颜色+文字删除的顺序正确了。所以我们有理由合理大胆的猜测，之所以在Stateful中数据紊乱是因为对应关系出了问题，那么到底是不是呢，我们看下API。StatelessWidget -> Widget 这里有一个方法canUpdate

  static bool canUpdate(Widget oldWidget, Widget newWidget) {

    return oldWidget.runtimeType == newWidget.runtimeType

        && oldWidget.key == newWidget.key;

  }

Flutter是增量渲染，哪些需要更新的通过上面的那个方法来判断。所以当两个Widget都StatefulWidget的时候，如果不指定key的话，如果结构一样那么此时这个方法就会返回True

• 在Widget中保存的是Text
• 在Element中保存的是Color
• 在删除的时候，虽然我们删除了文字，但是由于没有指定key，所以canUpdate = true所以此时第一个Element的颜色指向了Widget的第二个，这也就是示例一中出现的问题。

当然如果再新增一个跟上面一模一样的小部件，此时没有用到了Element下有了新的指向就不会删除了。也就是说新增的color= Element下的颜色

Key的原理

Key本身是一个抽象类，有一个工厂构造方法，创建ValueKey,其直接子类主要有：LocalKey和GlobalKey

1. GlobalKey:帮助访问某一个Widget的信息
2. LocalKey: 用来区别哪个Element需要保留
   • const ValueKey(this.value);// 以值作为参数，数字、字符串
   • const ObjectKey(this.value);// 以对象作为参数
   • UniqueKey();// 创建唯一标识

GlobalKey的使用

import 'package:flutter/material.dart';



class GlobalDemo extends StatelessWidget {

  const GlobalDemo({Key? key}) : super(key: key);



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: const Text('Home Page'),

      ),

      body: const BodyCenter(),

      floatingActionButton: FloatingActionButton(

        onPressed: () {

          //外层需要调用内层的count++

        },

        child: const Icon(Icons.add),

      ),

    );

  }

}



class BodyCenter extends StatefulWidget {

  const BodyCenter({Key? key}) : super(key: key);



  @override

  _BodyCenterState createState() => _BodyCenterState();

}



class _BodyCenterState extends State<BodyCenter> {

  int count = 0;

  String title = 'hello';



  @override

  Widget build(BuildContext context) {

    return Center(

      child: Column(

        children: [Text(count.toString()), Text(title)],

        mainAxisAlignment: MainAxisAlignment.center,

      ),

    );

  }

}

在下面的设计中，外层是一个StatelessWidget中间的body是一个StatefulWidget,我们在外层onPress的时候，正常情况是无法更新内存的count的，此时用GlobalKey可以解决

1. 在外层初始化一个GlobalKey同时指定需要跟哪个State绑定final GlobalKey<_BodyCenterState> _globalKey = GlobalKey();
2. 内存小部件初始化的时候同步绑定body: BodyCenter(key: _globalKey),
3. 使用方式：

onPressed: () {

  _globalKey.currentState!.setState(() {

  _globalKey.currentState!.title =

     '上一次count=' + _globalKey.currentState!.count.toString();

      _globalKey.currentState!.count++;

    });

},

只要是属于当前子部件的树状结构中，这种方式都管用，都可以拿到子部件的数据。

Gradle 是每个 Android 同学都逃不开的一个话题。

你是否看到别人的 Gradle 文件干净又卫生？而自己的又是一团乱麻🏷

不用怕,本篇将结合我的开发日常，将一些常用的操作分享出来，希望可以帮到像我一样不怎么会[玩]Gradle 的同学，相信会对大家有所帮助。

模板代码提取

这是最基础的操作了，对于一个普通 model.gradle ,默认的配置如下：

如果我们每个 model 都这样写，那岂不是很麻烦，那么让我们提取通用代码：

优化步骤

新建一个 gradle 文件，命名为 xxx.gradle ,复制上述 model 里的配置，放到你的项目中,可以自定义修改一些通用内容，在其他model 中依赖即可,如下所示：

这是一个播放器model

// 这就是刚才新建的默认gradle文件,

// 注意：如果你的default.gradle是在项目目录下，请使用../,如果仅在app下，请使用./

apply from: "../default.gradle"

import xxx.*



android {

  	// 用于隔离不同model的资源文件

    resourcePrefix "lc_play_"

}





dependencies {

    compileOnly project(path: ':common')

    api xxx

}

上述的 android{} , dependencies{}

其内部的内容都会在 default.gradle 的基础上叠加，对于唯一的键值对，会进行替换。

定义统一的config配置

在项目中，你是如何去写你的版本号等其他默认配置呢？

对于一个新项目，其默认的配置如下所示，每次新创建 model ,也需要定义其默认参数，如果每次都直接在这里去改动，那么如果版本变化，意味着我们需要修改多次，这并不是我们想看到的效果。

优化步骤

新建 config.gradle ，内容如下：

// 一些配置文件的保存



// 使用git的commit记录当做versionCode

static def gitVersionCode() {

    def cmd = 'git rev-list HEAD --count'

    return cmd.execute().text.trim().toInteger()

}



static def releaseBuildTime() {

    return new Date().format("yyyy.MM.dd", TimeZone.getTimeZone("UTC"))

}



ext {

    android = [compileSdkVersion: 30,

               applicationId    : "com.xxx.xxx",

               minSdkVersion    : 21,

               targetSdkVersion : 30,

               buildToolsVersion: "30.0.2",

               buildTime        : releaseBuildTime(),

               versionCode      : gitVersionCode(),

               versionName      : "1.x.x"]

}

使用时：

android {

    def android = rootProject.ext.android

    defaultConfig {

        multiDexEnabled true

        minSdk android.minSdkVersion

        compileSdk android.compileSdkVersion

        targetSdk android.targetSdkVersion

        versionCode android.versionCode

        versionName android.versionName

    }

 }

配置你的build

配置不同build类型

在开发中，我们一般会有多个环境，比如 开发环境 ，测试环境，线上环境：

buildTypes {

    release {

        minifyEnabled false

        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

    }



    dev{

        // initWith代表的是允许从其他build类型进行复制操作，然后配置我们想更改的设置

      	// 这里代表的是从release复制build配置

        initWith release

        // 清单占位符

        manifestPlaceholders = [hostName:"com.petterp.testgradle.dev"]

        // 会在你原包名后面新增.test

        applicationIdSuffix ".dev"

    }

}

如上所述，dev 是我们新增的 build类型 ,当新增之后，我们就可以在命令行使用如下匹配的指令，或者点击As 最右侧，gradle图标，选择app(根据自己build的配置位置而定，一般默认是app-model)，选择other,即可看到多了如下几个指令：

当然你也可以选择如下命令行执行,以便在 Jenkins 或者 CI 下 build 时执行：

gradlew buildDev

gradlew assembleDev

注意，mac下是gradlew开头，windows下可能是./gradlew

配置变体

对于开发中，我们一般都有多渠道的需求，一般而言，如果仅仅是多渠道我们可以选择使用第三方 walle 去做，如果我们可能还有更精细的设置，比如针对这个 build类型，我们很可能对应了不同的默认配置等，比如配置不同的 applicationId ,资源。

如下所示：

// 变体风味名，如果只设置一个，则所有变体会自动使用，如果存在两个及以上，需要在变体中指定,并且变体需要与分组匹配。

// 风味名，类似于风格，分组的意思。

flavorDimensions "channel"

// flavorDimensions ("channel","api")

productFlavors {

    demo1 {

    		// 每一个变体都必须存在一个风味，默认使用flavorDimensions(仅限其为单个时)的值，否则如果没提供，则会报错。

        dimension "channel"

        // appid后缀,会覆盖了我们build类型中的applicationIdSuffix

        applicationIdSuffix ".demo"

        // 版本后缀

        versionNameSuffix "-demo"

    }

    demo2 {

        dimension "channel"

        applicationIdSuffix ".demo2"

        versionNameSuffix "-demo2"

    }

}

然后查看我们的 build Variants:

Gradle 会根据我们的 变体 和 build类型 自动创建多个build变种，按照 变体名-build类型名 方式命名。

在配置变体时，我们也可以替换在 build类型 中设置的所有默认值，具体原因是，在添加 build类型时，默认的 defaultConfig 配置其实是属于 ProductFlavors 类，所以我们也可以在任意变体中替换所有默认值。

组合多个变体

在某些场景下，我们可能想将多个产品的变体组合在一起，比如我们想增加一个 api30 的变体，并且针对这个变体，我们想让demo1和demo2与分别也能与其组合在一起 ，即也就是当channel是demo1时api30下对应的包。

理解起来有些拗口，示例如下所示，我们更改上面的配置:

  flavorDimensions("channel", "api")

    productFlavors {

        demo1 {

            dimension "channel"

            applicationIdSuffix ".demo"

            versionNameSuffix "-demo"

        }

        demo2 {

            dimension "channel"

            applicationIdSuffix ".demo2"

            versionNameSuffix "-demo2"

        }

        minApi23 {

            dimension "api"

            minSdk 23

            applicationIdSuffix ".minapi23"

            versionNameSuffix "-minapi23"

        }

    }

最终如下所示,左侧是 gralde 生成的 build变种 ，右侧对应其中 demo1MinApi23Debug 打包后的产物具体信息：

所以我们可以总结为：

最终我们在打包时，我们的包名和版本名会根据多个变体混合生成，具体如上图所示，然后分别使用了两者都具有的配置，当配置出现重复时，优先以开头的变体配置作为基准。

比如如果我们给demo1变体也配置了最低sdk版本是21,那么最终打出来的包minSdk也会是21，而不是minApi23中的minSdk配置，这点需要注意。

解疑

那么 变体 和 build类型 两者到底应该怎么选？似乎两者好像很是相似？

其实不难理解，如下所示：

比如你新增了一个变体 firDev ,那么默认情况下就会有如下的 build命令 生成

firDevDebug

firDevRelase

firDevXXX(xxx是你自定义的build类型)

需要注意的是 debug 和 relase 是默认就会存在的，我们可以选择覆盖，否则就算移除，其也会选择默认设置存在

即也就是最终 gradle 会帮我们每个变体都生成相应的 build类型 对应的命令，变体就相当于不同的渠道，而 build类型 就相当于针对这个渠道，存在着多种环境，比如 debug,relase,你自定义的更多build类型。

• 所以如果你的场景仅仅是想对应几个不同环境，那么直接配置 build类型 即可；
• 如果你可能希望区分不同的包下的依赖项或者资源配置，那么配置变体即可。

过滤变体

Gradle 会为我们配置的 所有变体 和 build类型 每一种可能组合都创建一个 build变种 。当然有些变种，我们并不需要，所以我们可以在相应模块的 build.gradle 中创建 变体过滤器 ，以便移除某些不需要的变体配置。

android{

	...

	variantFilter { variant ->

        def names = variant.flavors*.name

        if (names.contains("demo2")) {

            setIgnore(true)

        }

    }

	...

}

效果如下：

针对变体配置依赖项

我们也可以针对上面这些变体，进行不同的依赖。比如：

 demo1Implementation  xxx

 minApi23Implementation xxxx

常见技巧

关于依赖管理

对于一些环境下，我们并不想在线上依赖某些库或者 model ，如果是三方库，一般都会有 relase 下依赖的版本。

如果是本地model,目前已经引用到了，所以就需要对于线上环境做null包处理，只留有相应的包名与入口，具体的实现都为null.

限制依赖条件为build类型

debugImplementation project(":dev")

releaseImplementation project(":dev_noop")

有一点需要注意，当我们使用默认的 debugImplementation 和 releaseImplementation 进行依赖时,最终打包时是否会依赖其中，取决于我们 使用的build命令中build类型是不是debug或者relase ,如果使用的是自定义的 dev ,那么上述的两个 model 也都不会依赖，很好理解。

限制依赖条件为变体

相应的，如果我们希望当前的依赖的库或者model 不受 build类型 限制，仅受 变体 限制，我们也可以使用我们的 变体-Implementation 进行依赖，如下所示：

demo1Implementation project(":dev")

这个意思是，如果我们打包时使用demo1相应的gradle命令，比如assembleDemo1Debug,那么无论当前build类型是debug还是release或者其他，其都会参与依赖。

排除传递的依赖项

开发中，我们经常会遇见依赖冲突，对于第三方库导致的依赖冲突，比较好解决，我们只需要使用 exclude 解决即可，如下所示：

dependencies {

    implementation("androidx.lifecycle:lifecycle-extensions:2.2.0") {

        exclude group: 'androidx.lifecycle', module: 'lifecycle-process'

    }

}

统一全局的依赖版本

有时候，某些库会存在好多个版本，虽然 Gradle 会默认选用最高的版本，但是依然不免有时候还是会提示报错，此时我们就可以通过配置全局统一的版本限制：

android{

	defaultConfig {

        configurations.all {

            resolutionStrategy {

                force AndroidX.Core

                force AndroidX.Ktx.Core

                force AndroidX.Work_Runtime

            }

        }

     }

}

简化你的BuildConfig配置

开发中，我们常见的都会将一些配置信息，写入到 BuildConfig 中，以便我们在开发中使用，这也是最常用的手段之一了。

配置方式1

最简单的方式就是，我们可以在执行 applicationVariants task任务时，将我们的 config 写入配置中，示例如下：

app/ build.gradle

android.applicationVariants.all { variant ->

    if ("release" == variant.buildType.getName()) {

        variant.buildConfigField "String", "baseUrl", "\"xxx\""

    } else if ("preReleaseDebug" == variant.buildType.getName()) {

        variant.buildConfigField "String", "baseUrl", "\"xxx\""

    } else {

        variant.buildConfigField "String", "baseUrl", "\"xxx\""

    }

    variant.buildConfigField "String", "buglyAppId", "\"xx\""

    variant.buildConfigField "String", "xiaomiAppId", "\"xx\""

  	...

}

在写入时，我们也可以通过判断当前的 build类型 从而决定到底写入哪些。

优化配置

如果配置很少的话，上述方式写还可以接收，那如果配置参数很多，成百呢？此时就需要我们将其抽离出来了。

所以我们可以新建一个 build_config.gradle ,将上述代码复制到其中。

然后在需要的 模块 里，依赖一下即可。

apply from: "build_config.gradle"

这样做的好处就是，可以减少我们 app-build.gradle 里的逻辑，通过增加统一的入口，来提高效率和可读性。

配置方式2

当然也有另一种方式，相当于我们自己定义两个方法，在 buildType 里自行调用，相应的我们将 config配置 按照规则写入一个文件中去管理。

示例代码：

app/ build.gradle

buildTypes {

    // 读取 ./build_extras 下的所有配置

    def configBuildExtras = { com.android.build.gradle.internal.dsl.BuildType type ->

        // This closure reads lines from "build_extras" file and feeds its content to BuildConfig

        // Nothing but a better way of storing magic numbers

        def buildExtras = new FileInputStream(file("./build_extras"))

        buildExtras.eachLine {

            def keyValue = it == null ? null : it.split(" -> ")

            if (keyValue != null && keyValue.length == 2) {

                type.buildConfigField("String", keyValue[0].toUpperCase(), "\"${keyValue[1]}\"")

            }

        }

    }

   release {

    ...

    configBuildExtras(delegate)

    ...

   }

   debug{

    ...

    configBuildExtras(delegate)

    ...

   }

 }

build_extras

...

baseUrl -> xxx

buglyId -> xxx

...

上述两种配置方式，我们可以根据需要自行决定，我个人是比较喜欢方式1,毕竟看着更简单，但其实两者的实现方式也是大差不大，具体看个人习惯吧。

管理全局插件的依赖

某些时候，我们所有的model,可能都需要集成一个插件，此时我们就可以通过在 项目build.gradle 里全局统一管理，而避免到每一个Gradle 下去集成：

// 管理全局插件的依赖

subprojects { subproject ->

    // 默认应用所有子项目中

    apply plugin: xxx

    // 如果想应用到某个子项目中，可以通过 subproject.name 来判断应用在哪个子项目中

    // subproject.name 是你子项目的名字，示例如下

    // 官方文档地址：https://guides.gradle.org/creating-multi-project-builds/#add_documentation

//    if (subproject.name == "app") {

//        apply plugin: 'com.android.application'

//        apply plugin: 'kotlin-android'

//        apply plugin: 'kotlin-android-extensions'

//    }

}

动态调整你的组件开关

对于一些组件，在 debug 开发时如果依赖，对我们的编译时间可能会有影响，那么此时，如果我们增加相应的开关控制，就会比较好：

buildscript {

	ext.enableBooster = flase

	ext.enableBugly = flase



	if (enableBooster)

   	classpath "com.didiglobal.booster:booster-gradle-plugin:$booster_version"

 }

如果每次都是静态控制，那么当我们使用 CI 来打包时，就会没法操作。所以相应的，我们可以更改一下逻辑：

我们创建一个文件夹，里面放的是相应的忽略文件，如下所示：

然后我们更改一下相应的 buildscript 逻辑：

buildscript {

	ext.enableBooster = !file("ignore/.boosterignore").exists()

	ext.enableBugly = !file("ignore/.buglyignore").exists()



	if (enableBooster)

   	classpath "com.didiglobal.booster:booster-gradle-plugin:$booster_version"

 }

通过判断相应的插件对应的文件是否存在，来决定插件在CI打包时的启用状态。在CI打包时，我们只需要通过shell删除相应的配置ignore文件或者通过gradle执行相应命令即可。因为本篇是讲gradle的一些操作，所以我们就主要演示一下gradle的命令示例。

定义自己的gradle插件

我们先简单写一个最入门的插件，用来移除相应的文件，来达到开关插件的目的。

task checkIgnore {

    println "-------checkIgnore--------开始->"

    removeIgnore("enableBugly", ".buglyignore")

    removeIgnore("enableGms", ".gmsignore")

    removeIgnore("enableByteTrack", ".bytedancetrackerignore")

    removeIgnore("enableSatrack", ".satrackerignore")

    removeIgnore("enableBooster", ".boosterignore")

    removeIgnore("enableHms", ".hmsignore")

    removeIgnore("enablePrivacy", ".privacyignore")

    println "-------checkIgnore--------结束->"

}



def removeIgnore(String name, ignoreName) {

    if (project.hasProperty(name)) {

        delete "../ignore/$ignoreName"

        def sdkName = name.replaceAll("enable", "")

        println "--------已打开$sdkName" + "组件"

    }

}

这个插件的作用很简单，就是通过我们 Gradle 命令 携带的参数 来移除相应的插件文件。

gradlew app:assembleRoyalFinalDebug  -PenableBugly=true

具体如图所示：在 CI-build 时，我们就可以通过传递相应的值，来动态决定是否启用某插件。

优化版

上述方式虽然方便，但是看着依然很麻烦，那么有没有更简单，单纯利用 Gradle 即可。其实如果稍微懂一点 Gradle 生命周期，这个问题就能轻松解决。

我们可以在 settings.gradle 里监听一下 Gradle 的 生命周期 ，然后在项目结构加载完成时，也就是 projectsLoaded 执行时，去判断一下，如果存在某个参数，那么就打开相应的组件，否则关闭。

示例：

settings.gradle

gradle.projectsLoaded { proj ->

    println 'projectsLoaded()->项目结构加载完成（初始化阶段结束）'

    def rootProject = proj.gradle.rootProject

    rootProject.ext.enableBugly = rootProject.findProperty("enableBugly") ?: false

    rootProject.ext.enableBooster = rootProject.findProperty("enableBooster") ?: false

    rootProject.ext.enableGms = rootProject.findProperty("enableGms") ?: false

    rootProject.ext.enableBytedance = rootProject.findProperty("enableBytedance") ?: false

    rootProject.ext.enableSadance = rootProject.findProperty("enableSadance") ?: false

    rootProject.ext.enableHms = rootProject.findProperty("enableHms") ?: false

    rootProject.ext.enablePrivacy = rootProject.findProperty("enablePrivacy") ?: false

}

执行build命令时携带相应参数即可:

gradlew assembleDebug -PenablePrivacy=true 

参考

Android开发者-配置你的build

我是Petterp,一个三流开发，如果本文对你有所帮助，欢迎点赞支持。

这篇文章我们主要来分析 Kotlin 中的操作符 == 和 === 的区别，以及它们分别在什么场景下使用。这些操作符在实际项目和开源项目中，使用的频率非常的高。主要包含以下内容：

• Java 中的 == 和 equals 的区别？
• Kotlin 提供的操作符 == 和 === 分别做什么用？
  • 比较对象的结构是否相等 ( == 或者 equals )
  • 比较对象的引用是否相等 ( === )
• Kotlin 中的操作符在以下场景中的使用
  • 基本数据类型
  • 包装类
  • 普通类
  • 数据类

在开始分析之前，我们先来简单回顾一下 Java 中的操作符 == 和 equals 的区别。

Java 中的操作符 == 和 equals 的区别

操作符 ==

• 如果是基本数据类型比较的是值
• 如果是引用数据类型比较的是地址

操作符 equals

• 默认情况下在不重写 equals 方法时，等价于 ==，比较的是地址

public boolean equals(Object obj) {

    return (this == obj);

}

• 重写 equals 方法时，一般用于比较结构是否相等，例如 String

public boolean equals(Object anObject) {

    if (this == anObject) {

        return true;

    }

    if (anObject instanceof String) {

        String anotherString = (String)anObject;

        int n = value.length;

        if (n == anotherString.value.length) {

            char v1[] = value;

            char v2[] = anotherString.value;

            int i = 0;

            while (n-- != 0) {

                if (v1[i] != v2[i])

                    return false;

                i++;

            }

            return true;

        }

    }

    return false;

}

但是需要注意的是重写 equals 方法时，需要重写 hashCode() 方法，否则无法和 hash 集合类一起正常工作，可以通过快捷键自动生成 equals() 、hashCode() 、 toString() 等等方法。

• Mac: Cmd + N
• Win/Linux: Alt+Insert

更多 AndroidStudio 快捷键使用技巧查看下列文章：

• 图解多平台 AndroidStudio 技巧(一)
• 图解多平台 AndroidStudio 技巧(二)
• 图解多平台 AndroidStudio 技巧(三)

关于 Java 的操作符介绍就到这里了，接下来重点来分析 Kotlin 中的操作符。

Kotlin 中的操作符 == 和 === 及 equals

Kotlin 提供了两种方式用于对象的比较。

• 比较对象的结构是否相等（ == 或者 equals ）

  Kotlin 中的操作符 == 等价于 equals 用于比较对象的结构是否相等, 很多情况下使用的是 ==，因为对于浮点类型 Float 和 Double，其实现方法 equals 不遵循 IEEE 754 浮点运算标准。

• 比较对象的引用是否相等 ( === )

  Kotlin 中的操作符 === 用于比较对象的引用是否指向同一个对象，运行时如果是基本数据类型 === 等价于 ==。

我们知道了基本概念之后，接下来一起来看一下这些操作符（ == 和 === 及 equals ），在以下场景中的使用。

• 基本数据类型
• 包装类
• 普通类
• 数据类

基本数据类型

我们先来看一个例子：

val a1 = -0

val a2 = 0

println(a1 == a2)       // true

println(a1.equals(a2))  // true

println(a1 === a2)      // true



a1 = 100

a2 = 100

println(a1 == a2)       // true

println(a1.equals(a2))  // true

println(a1 === a2)      // true

运行时，对于基本数据类型 === 等价于 == 比较的是值（即对象的结构是否相等），如果比较基本数据类型时使用 ===，编译器就会给出一个警告，不建议使用。

但是 equals 比较特殊, 对于浮点类型 Float 和 Double 却有不同的表现，代码如下所示。

val a3 = -0f

val a4 = 0f

println(a3 == a4)       // true

println(a3.equals(a4))  // false

println(a3 === a4)      // true

正如你所看到的 a3.equals(a4) 结果为 false，那么为什么会这样呢，一起来查看反编译后的 Java 代码都做了什么。Tools → Kotlin → Show Kotlin Bytecode 。

float a3 = -0.0F;

float a4 = 0.0F;

boolean var2 = Float.valueOf(a3).equals(a4);

boolean var3 = false;

System.out.println(var2);

将 float 转换为包装类型 Float，调用其 equals 方法来进行比较，来看一下 equals 方法。

运行结果正如源码注释高亮部分一样，使用 equals 方法比较 +0.0f 和 -0.0f 其结果为 false, 如果使用操作符 ==结果为 true。

在 equals 方法中调用了 floatToIntBits 方法，在这个方法中是根据 IEEE 754 浮点算法标准，返回指定浮点值的表示形式，结果是一个整数，如下所示：

System.out.println(Float.floatToIntBits(-0f));  // -2147483648

System.out.println(Float.floatToIntBits(0f));   // 0

正如你所见，Float.floatToIntBits(-0f) 计算出来的结果，是整数的最小值 -2147483648，从结果来看它不遵循 IEEE 754 浮点运算标准，一起来看一下官方是如何解释的，更多信息点击查看 IEEE 754 浮点运算标准

对于浮点类型 Float 和 Double，其实现方法 equals 不遵循 IEEE 754 浮点运算标准：

• NaN 被认为和它自身相等
• NaN 被认为比包括正无穷在内的任何其他元素都大
• -0.0 小于 +0.0

因此在 Kotlin 中如果使用 equals 方法进行比较的时候，需要注意这个情况。

包装类

无论是 Java 还是 Kotlin 每一种基本类型都会对应一个唯一的包装类，只不过它们的区分方式不一样。

val a5 = Integer(10)    

val a6 = Integer(10)

println(a5 == a6)       // true

println(a5.equals(a6))  // true

println(a5 === a6)      // false

因为包装类重写了 equals 方法，所以使用操作符 == 和 equals 比较的是对象的结构是否相等，所以结果为 true。而操作符 === 比较的是对象的引用，是否指向同一个对象，因为是不同的对象，所以结果为 false。

普通的类

普通的类其实就是我们自己新建的类，并没有重写 equals 方法，一起来看一下这三种操作符的运行结果。

class Person1(val name: String, val age: Int)



val p1 = Person1(name = "hi-dhl", age = 10)

val p2 = Person1(name = "hi-dhl", age = 10)

println(p1 == p2)       // false

println(p1.equals(p2))  // false

println(p1 === p2)      // false



println(p1.name == p2.name)         // true

println(p1.name.equals(p2.name))    // true

println(p1.name === p2.name)        // true

因为普通的类 Person1 并没有实现 equals 方法，所以使用操作符 == 和 equals 比较的结果为 false，而 p1 和 p2 是不同的对象所以操作符 === 的结果为 false。

参数 name 是 String 类型，在上文分析过了 String 重写了 equals 方法，操作符 == 和 equals 比较的结果为 true。而 p1.name === p2.name 结果为 true , 是因为会先去常量池中查找是否存在 "hi-dhl"，如果存在直接返回常量池中的引用。

数据类

最后我们在来看一下这三种操作符在数据类中的表现。

data class Person2(val name: String, val age: Int)



val p3 = Person2(name = "ByteCode", age = 10)

val p4 = Person2(name = "ByteCode", age = 10)

println(p3 == p4)       // true

println(p3.equals(p4))  // true

println(p3 === p4)      // false



println(p3.name == p4.name)     // true

println(p3.name.equals(p4.name))// true

println(p3.name === p4.name)    // true

因为编译器会根据数据类中的参数，自动生成 equals 、 hashCode 、 toString 等等方法，编译后的代码如下所示。

public int hashCode() {

  String var10000 = this.name;

  return (var10000 != null ? var10000.hashCode() : 0) * 31 + Integer.hashCode(this.age);

}



public boolean equals(@Nullable Object var1) {

  if (this != var1) {

     if (var1 instanceof Person2) {

        Person2 var2 = (Person2)var1;

        if (Intrinsics.areEqual(this.name, var2.name) && this.age == var2.age) {

           return true;

        }

     }



     return false;

  } else {

     return true;

  }

}

所以使用操作符 == 和 equals，输出结果为 true，但是 p3 和 p4 是不同的对象所以操作符 === 的结果为 false。

总结

Java 中的操作符

操作符 ==

• 如果是基本数据类型比较的是值
• 如果是引用数据类型比较的是地址

操作符 equals

• 默认情况下在不重写 equals 方法时，等价于 ==，比较的是地址
• 重写 equals 方法时，常用于比较结构是否相等，可以通过快捷键自动生成 equals() 、hashCode() 、 toString() 等等方法。
  • Mac: Cmd + N
  • Win/Linux: Alt+Insert

Kotlin 中的操作符

Kotlin 提供了两种方式用于对象的比较。

• 比较对象的结构是否相等（ == 或者 equals ）

  Kotlin 中的操作符 == 等价于 equals 用于比较对象的结构是否相等, 很多情况下使用的是 ==，因为对于浮点类型 Float 和 Double，其实现方法 equals 不遵循 IEEE 754 浮点运算标准。

• 比较对象的引用是否相等 ( === )

  Kotlin 中的操作符 === 用于比较对象的引用是否指向同一个对象，运行时如果是基本数据类型 === 等价于 ==。

全文到这里就结束了，最后附上文章的精简示例，你能够在不运行程序的情况下，说出下面代码的运行结果吗？

class Person1(val name: String, val age: Int)

data class Person2(val name: String, val age: Int)



fun main() {

    val a1 = -0

    val a2 = 0

    println(a1 == a2)

    println(a1.equals(a2)



    val a3 = -0f

    val a4 = 0f

    println(a3 == a4)

    println(a3.equals(a4))



    //-------------



    val p1 = Person1(name = "hi-dhl", age = 10)

    val p2 = Person1(name = "hi-dhl", age = 10)

    println(p1 == p2)

    println(p1.equals(p2))

    println(p1 === p2)

    println(p1.name === p2.name)



    //-------------



    val p3 = Person2(name = "ByteCode", age = 10)

    val p4 = Person2(name = "ByteCode", age = 10)

    println(p3 == p4)

    println(p3.equals(p4))

    println(p3 === p4)

    println(p3.name === p4.name)



}

运行结果如下所示：

a1 == a2        true

a1.equals(a2)   true

a3 == a4        true

a3.equals(a4)   false

--------------------------

p1 == p2        false

p1.equals(p2)   false

p1 === p2       false

p1.name === p2.name true

--------------------------

p3 == p4        true

p3.equals(p4)   true

p3 === p4)      false

p3.name === p4.name true