Kotlin委托的常见使用场景

前言

在设计模式中，委托模式（Delegate Pattern）与代理模式都是我们常用的设计模式（Proxy Pattern），两者非常的相似，又有细小的区分。

委托模式中，委托对象和被委托对象都是同一类型的对象，委托对象将任务委托给被委托对象来完成。委托模式可以用于实现事件监听器、回调函数等功能。

代理模式中，代理对象与被代理对象是两种不同的对象，代理对象代表被代理对象的功能，代理对象可以控制客户对被代理对象的访问。代理模式可以用于实现远程代理、虚拟代理、安全代理等功能。

以类的委托与代理来举例，委托对象和被委托对象都实现了同一个接口或继承了同一个类，委托对象将任务委托给被委托对象来完成。代理模式中，代理对象与被代理对象实现了同一个接口或继承了同一个类，代理对象代表被代理对象，客户端通过代理对象来访问被代理对象。

两者的区别：

他们虽然都有同一个接口，主要区别在于委托模式中委托对象和被委托对象是同一类型的对象，而代理模式中代理对象与被代理对象是两种不同的对象。总的来说，委托模式是为了将方法的实现交给其他类去完成，而代理模式则是为了控制对象的访问，并在访问前后进行额外的操作。

而我们常用的委托模式怎么使用？在 Java 语言中需要我们手动的实现，而在 Kotlin 语言中直接通过关键字 by 就可以实现委托，其实现更加优雅、简洁了。

我们在开发一个 Android 应用中，常用到的委托分为：

1. 接口/类的委托


2. 属性的委托


3. 结合lazy的延迟委托


4. 观察者的委托


5. Map数据的委托

下面我们就一起看看不同种类的委托使用以及在 Android 常见的一些场景中的使用。

一、接口/类委托

我们可以选择使用接口来实现类似的效果，也可以直接传参，当然接口的方式更加的灵活，比如我们这里就以接口比如我定义一个攻击与防御的行为接口：

interface IUserAction {



    fun attack()



    fun defense()

}

定义了用户的行为，有攻击和防御两种操作！接下来我们就定义一个默认的实现类：

class UserActionImpl : IUserAction {



    override fun attack() {

        YYLogUtils.w("默认操作-开始执行攻击")

    }



    override fun defense() {

        YYLogUtils.w("默认操作-开始执行防御")

    }

}

都是很简单的代码，我们定义一些默认的操作，如果任意类想拥有攻击和防御的能力就直接实现这个接口，如果想自定义攻击和防御则重写对应的方法即可。

如果使用 Java 的方式实现委托，大致代码如下：

class UserDelegate1(private val action: IUserAction) : IUserAction {

    override fun attack() {

        YYLogUtils.w("UserDelegate1-需要自己实现攻击")

    }



    override fun defense() {

        YYLogUtils.w("UserDelegate1-需要自己实现防御")

    }

}

如果使用 Kotlin 的方式实现则是：

class UserDelegate2(private val action: IUserAction) : IUserAction by action

如果 Kotlin 的实现不想默认的实现也可以重写部分的操作：

class UserDelegate3(private val action: IUserAction) : IUserAction by action {



    override fun attack() {

        YYLogUtils.w("UserDelegate3 - 只重写了攻击")

    }

}

那么使用起来就是这样的：

    val actionImpl = UserActionImpl()



    UserDelegate1(actionImpl).run {

        attack()

        defense()

    }



    UserDelegate2(actionImpl).run {

        attack()

        defense()

    }



    UserDelegate3(actionImpl).run {

        attack()

        defense()

    }

打印日志如下：

其实在 Android 源码中也有不少委托的使用，例如生命周期的 Lifecycle 委托：

Lifecycle 通过委托机制实现其功能。具体来说，组件可以将自己的生命周期状态委托给 LifecycleOwner 对象，LifecycleOwner 对象则负责管理这些组件的生命周期。

例如，在一个 Activity 中，我们可以通过将 Activity 对象作为 LifecycleOwner 对象，并将该对象传递给需要注册生命周期的组件，从而实现组件的生命周期管理。 页面可以使用 getLifecycle() 方法来获取它所依赖的 LifecycleOwner 对象的 Lifecycle 实例，并在需要时将自身的生命周期状态委托给该 Lifecycle 实例。

通过这种委托机制，Lifecycle 实现了一种方便的方式来管理组件的生命周期，避免了手动管理生命周期带来的麻烦和错误。

class AnimUtil private constructor() : DefaultLifecycleObserver {

  

    ...



    private fun addLoopLifecycleObserver() {

        mOwner?.lifecycle?.addObserver(this)

    }



    // 退出页面的时候释放资源

    override fun onDestroy(owner: LifecycleOwner) {

        mAnim?.cancel()

        destory()

    }



}

除此之外委托还特别适用于一些可配置的功能，比如 Resutl-Api 的封装，如果当前页面需要开启 startActivityForResult 的功能，就实现这个接口，不需要这个功能就不实现接口，达到可配置的效果。

/**

 * 定义是否需要SAFLauncher

 */

interface ISAFLauncher {



    fun <T : ActivityResultCaller> T.initLauncher()



    fun getLauncher(): GetSAFLauncher?



}

由于代码是固定的实现，目标Activity也不需要重新实现，我们只需要实现默认的实现即可：

class SAFLauncher : ISAFLauncher {



    private var safLauncher: GetSAFLauncher? = null



    override fun <T : ActivityResultCaller> T.initLauncher() {

        safLauncher = GetSAFLauncher(this)

    }



    override fun getLauncher(): GetSAFLauncher? = safLauncher



}

使用起来我们直接用默认的实现即可：

class DemoActivity : BaseActivity, ISAFLauncher by SAFLauncher() {



    override fun init() {

        initLauncher()  // 实现了接口还需要初始化Launcher

    }



    fun gotoOtherPage() {

        //使用 Result Launcher 的方式启动，并获取到返回值

        getLauncher()?.launch<DemoCircleActivity> { result ->

            val result = result.data?.getStringExtra("text")

            toast("收到返回的数据：$result")

        }



    }



}

这样是不是就非常简单了呢？具体如何使用封装 Result Launcher 可以看看我去年的文章 【传送门】

二、属性委托

除了类与接口对象的委托，我们还常用于属性的委托。

我知道了！这么弄就行了。

    private val textStr by "123"

哎？怎么报错了？其实不是这么用的。

属性委托和类委托一样，属性的委托其实是对属性的 set/get 方法的委托。

需要我们把 set/get 方法委托给 setValue/getValue 方法,因此被委托类（真实类）需要提供 setValue/getValue 方法，val属性只需要提供 getValue 方法。

我们修改代码如下：

    private val textStr by TextDelegate()



    class TextDelegate {



        operator fun getValue(thisRef: Any?, property: KProperty<*>): String {

            return "我是赋值给与的文本"

        }



    }

打印的结果：

而我们定义一个可读写的属性则可以

  private var textStr by TextDelegate()



    class TextDelegate {



        operator fun getValue(thisRef: Any?, property: KProperty<*>): String {

            return "我是赋值给与的文本"

        }



        operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {

            YYLogUtils.w("设置的值为：$value")

        }



    }



    YYLogUtils.w("textStr:$textStr")

    textStr = "abc123"

打印则如下：

为了怕大家写错，我们其实可以用接口来限制，只读的和读写的属性，我们分别可以用 ReadOnlyProperty 与 ReadWriteProperty 来限制：

    class TextDelegate : ReadOnlyProperty<Any, String> {

        override fun getValue(thisRef: Any, property: KProperty<*>): String {

            return "我是赋值给与的文本"

        }

    }



    class TextDelegate : ReadWriteProperty<Any, String> {

        override fun getValue(thisRef: Any, property: KProperty<*>): String {

            return "我是赋值给与的文本"

        }



        override fun setValue(thisRef: Any, property: KProperty<*>, value: String) {

            YYLogUtils.w("设置的值为：$value")

        }

    }

那么实现的方式和上面自己实现的效果是一样的。如果要使用属性委托可以选用这种接口限制的方式实现。

我们的属性除了委托给类去实现，同时也能委托给其他属性（Kotlin 1.4+）来实现，例如：

    private var textStr by TextDelegate2()

    private var textStr2 by this::textStr

其实是内部委托了对象的 get 和 set 函数。相对委托对象而言性能更好一些。而委托对象去实现，不仅增加了一个委托类，而且还还在初始化时就创建了委托类的实例对象，算起来其实性能并不好。

所以属性的委托不要滥用，如果要用，可以选择委托现成的其他属性来完成，或者使用延迟委托Lazy实现，或者使用更简单的方式实现：

    private val industryName: String

        get() {

            return "abc123"

        }

对于只读的属性，这种方式也是我们常见的使用方式。

三、延迟委托

如果说使用类来实现委托不那么好的话，其实我们可以使用延迟委托。延迟关键字 lazy 接收一个 lambda 表达式，最后一行代表返回值给被推脱的属性。

默认的 Lazy 实现：

    val name: String by lazy {

        YYLogUtils.w("第一次调用初始化")

        "abc123"

    }



    YYLogUtils.w(name)

    YYLogUtils.w(name)

    YYLogUtils.w(name)

只有在第一次使用此属性的时候才会初始化，一旦初始化之后就可以直接获取到值。

日志打印：

它的内部其实也是使用的是类的委托实现。

public actual fun <T> lazy(initializer: () -> T): Lazy<T> = SynchronizedLazyImpl(initializer)

最终的实现是由 SynchronizedLazyImpl 类生成并实现的：

private class SynchronizedLazyImpl<out T>(initializer: () -> T, lock: Any? = null) : Lazy<T>, Serializable {

    private var initializer: (() -> T)? = initializer

    @Volatile private var _value: Any? = UNINITIALIZED_VALUE

    // final field is required to enable safe publication of constructed instance

    private val lock = lock ?: this



    override val value: T

        get() {

            val _v1 = _value

            if (_v1 !== UNINITIALIZED_VALUE) {

                @Suppress("UNCHECKED_CAST")

                return _v1 as T

            }



            return synchronized(lock) {

                val _v2 = _value

                if (_v2 !== UNINITIALIZED_VALUE) {

                    @Suppress("UNCHECKED_CAST") (_v2 as T)

                } else {

                    val typedValue = initializer!!()

                    _value = typedValue

                    initializer = null

                    typedValue

                }

            }

        }



    override fun isInitialized(): Boolean = _value !== UNINITIALIZED_VALUE



    override fun toString(): String = if (isInitialized()) value.toString() else "Lazy value not initialized yet."



    private fun writeReplace(): Any = InitializedLazyImpl(value)

}

我们可以直接看 value 的 get 方法,如果_v1 !== UNINITIALIZED_VALUE 则表明已经初始化过了，就直接返回 value ，否则表明没有初始化过，调用initializer方法，也就是 lazy 的 lambda 表达式返回属性的赋值。

跟我们自己实现类的委托类似，也是实现了getValue方法。只是多了判断是否初始化的一些相关逻辑。

lazy的参数分为三种类型：

1. SYNCHRONIZED:添加同步锁，使lazy延迟初始化线程安全


2. PUBLICATION：初始化的lambda表达式，可以在同一时间多次调用，但是只有第一次的返回值作为初始化值


3. NONE：没有同步锁，非线程安全

默认情况下，对于 lazy 属性的求值是同步锁的（synchronized)，是可以保证线程安全的，但是如果不需要线程安全和减少性能花销可以可以使用 lazy(LazyThreadSafetyMode.NONE){} 即可。

四、观察者委托

除了对属性的值进行委托，我们甚至还能对观察到这个变化过程：

使用 observable 委托监听值的变化：

    var values: String by Delegates.observable("默认值") { property, oldValue, newValue ->



        YYLogUtils.w("打印值: $oldValue -> $newValue ")

    }



    values = "第一次修改"

    values = "第二次修改"

    values = "第三次修改"

打印：

我们还能使用 vetoable 委托，和 observable 一样可以观察属性的变化，不同的是 vetoable 可以决定是否使用新值。

    var age: Int by Delegates.vetoable(18) { property, oldValue, newValue ->

        newValue > oldValue

    }



    YYLogUtils.w("age:$age")

    age = 14

    YYLogUtils.w("age:$age")

    age = 20

    YYLogUtils.w("age:$age")

    age = 22

    YYLogUtils.w("age:$age")

    age = 20

    YYLogUtils.w("age:$age")

我们需要返回 booble 值觉得是否使用新值，比如上述的例子就是当新值大于老值的时候才赋值。那么打印的日志就是如下：

虽然这种方式我们并不常用，一般我们都是使用类似 Flow 之类的工具在源头就处理了逻辑，使用这种方式我们就可以在属性的赋值过程中进行拦截了。在一些特定的场景下还是有用的。

五、Map委托

我们的属性不止可以使用类的委托，延迟的委托，观察的委托，还能委托Map来进行赋值。

当属性的值与 Map 中 key 相同的时候，我们可以把对应 key 的 value 取出来并赋值给属性：

class Member(private val map: Map<String, Any>) {



    val name: String by map

    val age: Int by map

    val dob: Long by map



    override fun toString(): String {

        return "Member(name='$name', age=$age, dob=$dob)"

    }



}

使用：

        val member = Member(mapOf("name" to "guanyu", "age" to 36, Pair("dob", 1234567890L)))

        YYLogUtils.w("member:$member")

打印的日志：

但是需要注意的是，map 中的 key 名字必须要和属性的名字一致才行，否则委托后运行解析时会抛出 NoSuchElementException 异常提示。

例如我们在 Member 对象中加入一个并不存在的 address 属性，再次运行就会报错。

而我们把 Int 的 age 属性赋值给为字符串也会报类型转换异常：

所以一定要一一对应才行哦，我怎么感觉有一点 TypeScript 结构赋值的那味道 - - ！

总结

委托虽好不要滥用。委托毕竟还是中间多了一个委托类，如果没必要可以直接赋值实现，而不需要多一个中间类占用内存。

我们可以通过接口委托来实现一些可选的配置。通过委托类实现属性的监听与赋值。可以减少一些模板代码，达到低耦合高内聚的效果，可以提高程序的可维护性、可扩展性和可重用性。

对于属性的类委托，我们可以将属性的读取和写入操作委托给另一个对象，或者另一个属性，或者使用延迟委托来推迟对象的创建直到第一次访问。

对于 map 的委托，我们需要仔细对应属性与 key 的一致性。以免出现错误，这是运行时的错误，有可能出现在生产环境上的。

那么大家都是怎么使用的呢？有没有更好的方式呢？或者你有遇到的坑也都可以在评论区交流一下，大家可以互相学习进步。如有本文有一些错漏的地方，希望同学们可以指出。

如果感觉本文对你有一点点的帮助，还望你能点赞支持一下，你的支持是我最大的动力。

本文的部分代码可以在我的 Kotlin 测试项目中看到，【传送门】。你也可以关注我的这个Kotlin项目，我有时间都会持续更新。

Ok,这一期就此完结。

startService可以很方便的启动一个service服务，也可以运行在单独的进程。

但是如果在后台调用了startService，则很可能会抛出一个崩溃。

Caused by: java.lang.IllegalStateException: Not allowed to start service Intent { cmp=com.test.broadservice/.MyService }: app is in background uid UidRecord{b67c471 u0a86 RCVR idle change:uncached procs:1 seq(0,0,0)}

        at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1577)

        at android.app.ContextImpl.startService(ContextImpl.java:1532)

        at android.content.ContextWrapper.startService(ContextWrapper.java:664)

        at android.content.ContextWrapper.startService(ContextWrapper.java:664)

        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1661) 

        at android.os.Handler.dispatchMessage(Handler.java:106) 

        at android.os.Looper.loop(Looper.java:193) 

        at android.app.ActivityThread.main(ActivityThread.java:6669) 

        at java.lang.reflect.Method.invoke(Native Method) 

        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) 

        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858) 

错误原因

Android8.0之后，系统增加了对后台Service的限制，如果应用处于后台，调用startService会抛出IllegalStateException。

意思是，在后台的应用，不允许调用startService启动一个后台服务，否则就会抛出异常。

解决方法

1. 使用startForegroundService

使用方法比较简单，这里就不列出代码了。

有几点需要注意：

• 用此方法启动前台服务，会在用户的通知栏上显示
• 必须在5s内调用服务的startForeground方法，否则会发生ANR

2. 使用JobScheduler

使用JobScheduler可以实现在后台运行任务。

定义一个JobService:

public class MyJobService extends JobService {

    @Override

    public boolean onStartJob(JobParameters params) {

        return false;

    }



    @Override

    public boolean onStopJob(JobParameters params) {

        return false;

    }

}

onStartJob：

• 运行在主进程，需要避免执行耗时的操作。
• 返回true：表示任务还在继续执行
• 返回false：表示任务已执行完
• 执行完之后，可以调jobFinished方法来通知系统任务已完成。

onStopJob:

• 当条件不满足的时候，会回调这个方法。
• 返回true：表示条件满足时，再次执行任务
• 返回false：表示任务完全结束

注册JobService：

        <service

            android:name=".MyJobService"

            android:permission="android.permission.BIND_JOB_SERVICE" />

定义一个JobInfo：

JobInfo.Builder builder = new JobInfo.Builder(111, new ComponentName(this, MyJobService.class));

// todo 设置任务的参数

将任务发布给系统：

JobScheduler jobScheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);

jobScheduler.schedule(builder.build());

3. 使用WorkManager

WorkManager是JobScheduler的升级版本，且支持多进程，可以将任务运行到单独的进程中。具体使用方法可以参考之前的文章：应用退出后继续运行后台任务，来试试WorkManager吧！

总结

Android 8.0版本以上，在后台调用startService会抛出IllegalStateException异常，需要改用其他的方式来使用。

常用的方法有如下三种：

• startForegroundService: 这种方式会在用户的通知栏显示UI。
• JobScheduler：可以实现后台无感知运行任务。
• WorkManager：Jetpack里的库，JobScheduler的升级版，支持多进程。

前言

startActivityForResult 可以说是我们常用的一种操作了，用于启动新页面并拿到这个页面返回的数据，是两个 Activity 交互的基本操作。

虽然可以通过接口，消息总线，单例池，ViewModel 等多种方法来间接的实现这样一个功能，但是 startActivityForResult 还是使用最方便的。

目前有哪些方式实现 startActivityForResult 的功能呢？

有新老两种方式，过时的方法是原生Activity/Fragment的 startActivityForResult 方法。另一种方法是 Activity Result API 通过 registerForActivityResult 来注册回调。

我们一起看看都是如何使用，使用起来方便吗？通常我们又都是如何封装的呢？

一、原生的使用

不管是Activity还是Fragment，我们都可以使用 startActivityForResult

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

        super.onActivityResult(requestCode, resultCode, data)

        if (requestCode == 120 && resultCode == -1) {

            toast("接收到返回的数据：" + data?.getStringExtra("text"))

        }

    }

可以看到虽然标记过时了，但是 startActivityForResult 这种方法是可以用的，我们一直这么用的，老项目中有很多页面都是这么定义的。也并没有什么问题。

不过既然谷歌推荐我们使用 Result Api 我们在以后使用 startActivityForResult 的时候还是推荐使用新的方式。

二、对原生的封装Ghost

在之前我们使用 startActivityForResult 这种方式的时候，为了更加方便的私有，有一种很流行的方式 Ghost 。

它使用一种 GhostFragment 的空视图当做一次中转，这种思路在现在看来已经不稀奇了，很多框架如Glide,权限申请等都是用的这种方案。

它的大致实现流程为：

Activty/Fragment -> add GhostFragment -> onAttach 中 startActivityForResult -> GhostFragment onActivityResult接收结果 -> callback回调给Activty/Fragment

总体需要两个类就可以完成这个逻辑，一个是中转Fragment，一个是管理类：

/**

 * 封装Activity Result的API

 * 使用空Fragemnt的形式调用startActivityForResult并返回回调

 *

 * Activty/Fragment——>add GhostFragment——>onAttach中startActivityForResult

 * ——>GhostFragment onActivityResult接收结果——>callback回调给Activty/Fragment

 */

class GhostFragment : Fragment() {



    private var requestCode = -1

    private var intent: Intent? = null

    private var callback: ((result: Intent?) -> Unit)? = null



    fun init(requestCode: Int, intent: Intent, callback: ((result: Intent?) -> Unit)) {

        this.requestCode = requestCode

        this.intent = intent

        this.callback = callback

    }



    private var activityStarted = false



    override fun onAttach(activity: Activity) {

        super.onAttach(activity)

        if (!activityStarted) {

            activityStarted = true

            intent?.let { startActivityForResult(it, requestCode) }

        }

    }



    override fun onAttach(context: Context) {

        super.onAttach(context)

        if (!activityStarted) {

            activityStarted = true

            intent?.let { startActivityForResult(it, requestCode) }

        }

    }



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

        super.onActivityResult(requestCode, resultCode, data)

        if (resultCode == Activity.RESULT_OK && requestCode == this.requestCode) {

            callback?.let { it1 -> it1(data) }

        }

    }



    override fun onDetach() {

        super.onDetach()

        intent = null

        callback = null

    }



}

/**

 * 管理GhostFragment用于StartActivityForResult

 * 启动的时候添加Fragment 返回的时移除Fragment

 */

object Ghost {

    var requestCode = 0

        set(value) {

            field = if (value >= Integer.MAX_VALUE) 1 else value

        }



    inline fun launchActivityForResult(

        starter: FragmentActivity?,

        intent: Intent,

        crossinline callback: ((result: Intent?) -> Unit)

    ) {

        starter ?: return

        val fm = starter.supportFragmentManager

        val fragment = GhostFragment()

        fragment.init(++requestCode, intent) { result ->

            callback(result)

            fm.beginTransaction().remove(fragment).commitAllowingStateLoss()

        }

        fm.beginTransaction().add(fragment, GhostFragment::class.java.simpleName)

            .commitAllowingStateLoss()

    }



}

如此我们就可以使用Kotlin的扩展方法来对它进行进一步的封装

//真正执行AcytivityForResult的方法，使用Ghost的方式执行

inline fun <reified T> FragmentActivity.gotoActivityForResult(

    flag: Int = -1,

    bundle: Array<out Pair<String, Any?>>? = null,

    crossinline callback: ((result: Intent?) -> Unit)

) {

    val intent = Intent(this, T::class.java).apply {

        if (flag != -1) {

            this.addFlags(flag)

        }

        if (bundle != null) {

            //调用自己的扩展方法-数组转Bundle

            putExtras(bundle.toBundle()!!)

        }

    }

    Ghost.launchActivityForResult(this, intent, callback)

}

使用起来就超级简单了：

    gotoActivityForResult<Demo10Activity> {

        val text = it?.getStringExtra("text")

        toast("拿到返回数据：$text")

    }



    gotoActivityForResult<Demo10Activity>(bundle = arrayOf("id" to "123", "name" to "zhangsan")) {

        val text = it?.getStringExtra("text")

        toast("拿到返回数据：$text")

    }

三、Result Api 的使用

其实看Ghost的原来就看得出，他本质上还是对 startActivityForResult 的调用与封装，还是过期的方法，那么如何使用新的方式，谷歌推荐我们怎么用？

Activity Result API ：

它是 Jetpack 的一个组件，这是官方用于替代 startActivityForResult() 和 onActivityResult() 的工具，我们以Activity 1.2.4版本为例：

implementation "androidx.activity:activity-ktx:1.2.4"

那么如何基础的使用它呢：

  

    private val safLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->

        if (result.resultCode == RESULT_OK) {

            val data = result.data?.getStringExtra("text")

            toast("拿到返回数据：$data")

        }

    }

    

    //在方法中使用

    safLauncher?.launch(Intent(mActivity, Demo10Activity::class.java))

看起来实现很简单，但是有几点要注意，Launcher 的创建需要在onStart生命周期之前，并且回调是在 Launcher 中处理的。并且 这些 Launcher 并不是只能返回Activity的Result的，还有其他的启动方式：

StartActivityForResult()

StartIntentSenderForResult()

RequestMultiplePermissions()

RequestPermission()

TakePicturePreview()

TakePicture()

TakeVideo()

PickContact()

GetContent()

GetMultipleContents()

OpenDocument()

OpenMultipleDocuments()

OpenDocumentTree()

CreateDocument()

可以看到这些方式其实对我们来说很多没必要，在真正的开发中只有 StartActivityForResult 这一种方式是我们的刚需。

为什么？毕竟现在谁还用这种方式申请权限，操作多媒体文件。相信大家也都是使用框架来处理了，所以我们这里只对 StartActivityForResult 这一种方式做处理。毕竟这才是我们使用场景最多的，也是我们比较需要的。

经过分析，对Result Api的封装，我们就剩下的两个重点问题：

1. 我们把 Launcher 的回调能在启动的方法中触发。


2. 实现 Launcher 在 Activity/Fragment 中的自动注册。

下面我们就来实现吧。

四、Result Api 的封装

我们需要做的是：

第一步我们把回调封装到launch方法中，并简化创建的对象方式

第二步我们尝试自动注册的功能

4.1 封装简化创建方式

首先第一步，我们对 Launcher 对象做一个封装， 把 ActivityResultCallback 回调方法在 launch 方法中调用。

/**

 * 对Result-Api的封装，支持各种输入与输出，使用泛型定义

 */

@SuppressWarnings("unused")

public class BaseResultLauncher<I, O> {



    private final androidx.activity.result.ActivityResultLauncher<I> launcher;

    private final ActivityResultCaller caller;

    private ActivityResultCallback<O> callback;

    private MutableLiveData<O> unprocessedResult;



    public BaseResultLauncher(@NonNull ActivityResultCaller caller, @NonNull ActivityResultContract<I, O> contract) {

        this.caller = caller;

        launcher = caller.registerForActivityResult(contract, (result) -> {

            if (callback != null) {

                callback.onActivityResult(result);

                callback = null;

            }

        });

    }



    public void launch(@SuppressLint("UnknownNullness") I input, @NonNull ActivityResultCallback<O> callback) {

        launch(input, null, callback);

    }



    public void launch(@SuppressLint("UnknownNullness") I input, @Nullable ActivityOptionsCompat options, @NonNull ActivityResultCallback<O> callback) {

        this.callback = callback;

        launcher.launch(input, options);

    }



}

上门是对Result的基本封装，由于我们只想要 StartActivityForResult 这一种方式，所以我们定义一个特定的 GetSAFLauncher

/**

 * 一般我们用这一个-StartActivityForResult 的 Launcher

 */

class GetSAFLauncher(caller: ActivityResultCaller) :

    BaseResultLauncher<Intent, ActivityResult>(caller, ActivityResultContracts.StartActivityForResult()) {



    //封装另一种Intent的启动方式

    inline fun <reified T> launch(

        bundle: Array<out Pair<String, Any?>>? = null,

        @NonNull callback: ActivityResultCallback<ActivityResult>

    ) {



        val intent = Intent(commContext(), T::class.java).apply {

            if (bundle != null) {

                //调用自己的扩展方法-数组转Bundle

                putExtras(bundle.toBundle()!!)

            }

        }



        launch(intent, null, callback)



    }



}

注意这里调用的是 ActivityResultContracts.StartActivityForResult() 并且泛型的两个参数是 Intent 和 ActivityResult。

如果大家想获取文件，可以使用 GetContent() 泛型的参数就要变成 String 和 Uri 。由于我们通常不使用这种方式，所以这里不做演示。

封装第一步之后我们就能这么使用了。

    var safLauncher: GetSAFLauncher? = null



    //其实就是 onCreate 方法

    override fun init() {

        safLauncher = GetSAFLauncher(this@Demo16RecordActivity)

    }



    //AFR

    fun resultTest() {



        safLauncher?.launch(Intent(mActivity, Demo10Activity::class.java)) { result ->

            val data = result.data?.getStringExtra("text")

            toast("拿到返回数据：$data")

        }

    }

//或者使用我们自定义的简洁方式

    fun resultTest() {



       safLauncher?.launch<Demo10Activity> { result ->

            val data = result.data?.getStringExtra("text")

            toast("拿到返回数据：$data")

        }



        safLauncher?.launch<Demo10Activity>(arrayOf("id" to "123", "name" to "zhangsan")) { result ->

            val data = result.data?.getStringExtra("text")

            toast("拿到返回数据：$data")

        }

    }

使用下来是不是简单了很多了，我们只需要创建一个对象就可以了，拿到这个对象调用launch即可实现 startActivityForResult 的功能呢！

4.2 自动注册/按需注册

可以看到相比原始的用法，虽然我们现在的用法就简单了很多，但是我们还是要在oncreate生命周期中创建 Launcher 对象，不然会报错：

LifecycleOwners must call register before they are STARTED.

那我们有哪些方法处理这个问题？

1）基类定义

我们都已经封装成对象使用了，我们把创建的逻辑定义到BaseActivity/BaseFragment不就行了吗？

abstract class AbsActivity() : AppCompatActivity(){



    protected var safLauncher: GetSAFLauncher? = null



    ...



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView()



        //Result-Api

        safLauncher = GetSAFLauncher(this)



        ...

    }



}

这样不就行了吗？可以正常使用的。那有人可能说，你这个对象可能用不到，又不是每一个Activity都会用到 Launcher 对象，你这么无脑创建出来消耗内存。

有办法，按需加载！

2).懒加载

懒加载可以吧，我需要的时候就创建。

abstract class AbsActivity() : AppCompatActivity(){



    val safLauncher by lazy { GetSAFLauncher(this) }



    ...

}

额，等等，这样的懒加载貌似是不行的，这在用的时候才初始化，一样会报错：

LifecycleOwners must call register before they are STARTED.

我们只能在页面创建的时候就要明确，这个页面是否需要这个 Launcher 对象，如果要就要在onCreate中创建对象，如果确定不要 Launcher 对象，那么就不必创建对象。

那我们就这么做：

abstract class AbsActivity() : AppCompatActivity(){



    protected var safLauncher: GetSAFLauncher? = null



    ...



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView()



        if (needLauncher()) {

            //Result-Api

            safLauncher = GetSAFLauncher(this)

        }



        ...

    }



    open protected fun needLauncher(): Boolean = false



}

我们使用一个flag判断不就行了吗？这个页面如果需要 Launcher 对象，重写方法返回true就行了。默认是不创建这个对象的。

3).Kotlin委托

我们可以使用Kotlin的委托方式，把初始化的代码和 Launcher 的对象获取用接口封装，然后提供对应的实现类，不就可以完成按需添加 Launcher 的效果了吗？

我们定义一个接口，由于逻辑都封装在了别处，这里就尽量不改动之前的代码，只是定义初始化和提供对象两种方法。

/**

 * 定义是否需要SAFLauncher

 */

interface ISAFLauncher {



    fun <T : ActivityResultCaller> T.initLauncher()



    fun getLauncher(): GetSAFLauncher?



}

接着定义这个实现类

class SAFLauncher : ISAFLauncher {



    private var safLauncher: GetSAFLauncher? = null



    override fun <T : ActivityResultCaller> T.initLauncher() {

        safLauncher = GetSAFLauncher(this)

    }



    override fun getLauncher(): GetSAFLauncher? = safLauncher



}

然后我们就可以使用了：

class Demo16RecordActivity : BaseActivity, ISAFLauncher by SAFLauncher() {



    //onCreate中直接初始化对象

    override fun init() {

        initLauncher()

    }



    

    //获取到对象直接用即可，还是之前的几个方法，没有变。

    fun resultTest() {



       getLauncher()?.launch<Demo10Activity> { result ->

            val data = result.data?.getStringExtra("text")

            toast("拿到返回数据：$data")

        }

    }



}

效果都是一样的：

这样通过委托的方式，我们就能自己管理初始化，自己随时获取到对象调用launch方法。

如果你当前的Activity不需要 startActivityForResult 这种功能，那么你不实现这个接口即可，如果想要 startActivityForResult 的功能，就实现接口委托实现，从而实现按需加载的逻辑。

我们再回顾一下 Result Api 需要封装的两个痛点与优化步骤：

1. 第一步我们把回调封装到launch方法中，并简化创建的对象方式


2. 第二步我们尝试自动注册的功能

同时我们还对一些步骤做了更多的可能性分析，对主动注册的方式我们有三种方式，（当然其实还有更多别的方式来实现，我只写了我认为比较简单方便的几种方式）。

到此对 Result Api的封装就此结束。

总结

总的来说 Result Api 的封装其实也不难，使用起来也是很简单了。如果大家是Kotlin项目我推荐使用委托的方式，如果是Java语言开发的也可以用flag的方式实现按需加载的逻辑。

而不想使用 Result Api 那么使用原始的 startActivityForResult 也能实现，那么我推荐你使用 Ghost 框架，可以更加方便快速的实现返回的功能。

本文对于 Result Api 的封装也只是限于 startActivityForResult 这一个场景，不过我们这种方式是很方便扩展的，如果大家想使用Result Api的方式来操作权限，文件等，都可以在 BaseResultLauncher 基础上进行扩展。

本文全部代码均以开源，源码在此。大家可以点个Star关注一波。

好了，本期内容如有错漏的地方，希望同学们可以指出交流。

如果感觉本文对你有一点点点的启发，还望你能点赞支持一下,你的支持是我最大的动力。

Ok,这一期就此完结。

额，为什么会有番外篇呢。。因为新版本上线后，别的同学用我的这个控件，描边显示出问题了-_-！

什么问题呢？

我把问题抽出来，同时把问题放大点，给大家看看(抹眼泪.png)

好嘛，问题不大。。就是描边歪了一点点，对吧。

可是怎么会这样！？，我自己测根本就没有问题，压根就没出现过这样的问题啊。。(抹眼泪.png)

我又去检查了一遍计算描边位置那块的代码，最初是以为其他同学一不小心该了那块的代码，导致描边位置计算出错了，结果发现，代码丝毫没有动过的痕迹。

那怎么会描边出错呢？而且他描边出问题的地方，在我这里这里显示也没什么问题，在他那里会什么会有这么大的偏差呢？

我不信邪，看看那位同学都对StrokeTextView做了哪些设置？结果发现，他多了下面这行代码：

mStrokeTextView.setTypeface(typeface);

我捉摸了一下，发现这行代码很有问题，因为我的StrokeTextView是继承自TextView的，调用setTypeface()，看看它的默认实现：

public void setTypeface(@Nullable Typeface tf) {

    if (mTextPaint.getTypeface() != tf) {

        mTextPaint.setTypeface(tf);



        if (mLayout != null) {

            nullLayouts();

            requestLayout();

            invalidate();

        }

    }

}

看了一眼我就明白了，它只是给TextPaint设置了不同的typeFace，而我们的描边是使用不同的TextPaint，也就是说setTypeface()只是给我们的文本设置了字体，却没有给我们的StrokeTextPaint设置相同的字体，导致了两种不同字体之间，没有办法对齐位置，导致了描边差异。

怎么解决？简单，照葫芦画瓢就行，我们在StrokeTextView重写setTypeface()方法。

setTypeface()的默认实现有两种，我们都要重写：

@Override

public void setTypeface(@androidx.annotation.Nullable Typeface tf) {

    // 模仿TextView的设置

    // 需在super.setTypeface()调用之前，不然没有效果

    if (mStrokePaint != null && mStrokePaint.getTypeface() != tf) {

        mStrokePaint.setTypeface(tf);

    }



    super.setTypeface(tf);

}

另一种比较复杂，不过我们会模仿就行了：

public void setTypeface(@Nullable Typeface tf, int style) {

        if (style > 0) {

            if (tf == null) {

                tf = Typeface.defaultFromStyle(style);

            } else {

                tf = Typeface.create(tf, style);

            }



            setTypeface(tf);

            // now compute what (if any) algorithmic styling is needed

            int typefaceStyle = tf != null ? tf.getStyle() : 0;

            int need = style & ~typefaceStyle;

            getPaint().setFakeBoldText((need & Typeface.BOLD) != 0);

            getPaint().setTextSkewX((need & Typeface.ITALIC) != 0 ? -0.25f : 0);



            // 同步设置mStrokeTextPaint

            if (mStrokePaint != null) {

                mStrokePaint.setFakeBoldText((need & Typeface.BOLD) != 0);

                mStrokePaint.setTextSkewX((need & Typeface.ITALIC) != 0 ? -0.25f : 0);

            }

        } else {

            getPaint().setFakeBoldText(false);

            getPaint().setTextSkewX(0);



            // 同步设置mStrokeTextPaint

            if (mStrokePaint != null) {

                mStrokePaint.setFakeBoldText(false);

                mStrokePaint.setTextSkewX(0);

            }



            setTypeface(tf);

        }

}

两步解决，但为什么我这显示没问题，别的同学那里显示就出问题了呢？

我突然想起来，相同字体在不同手机上显示是有差异的，而且有些手机不一定都支持那种字体。

我和那位同学用着不同厂商的真机进行测试，而我的真机是不支持他设置的字体的，所以看着没问题，但他的小米是支持的。难怪我这看着没问题，他那看着就很离谱。

修改完后，我们在运行一遍。

怎一个完美形容！ok，bug解决了，准备提交代码

就这样结束了吗？

时隔多日，我又重新审核了一遍代码，我留意到这样一行代码

float heightWeNeed

= getCompoundPaddingTop() + getCompoundPaddingBottom() + mStrokeWidth + mTextRect.height() + DensityUtil.dp2px(getContext(), 4);

我们需要的高度 = 内边距 + 描边高度 + 文本高度 + 一个额外设定的值 ?

怎么会需要一个额外的值呢？要实现wrap_content的效果，我们的宽度不是只需要加上边距、文本高度和一个描边的高度吗？

好奇怪的逻辑，这不是多余嘛，我当时怎么想的来着哈哈？不符合我wrap_content的预期，把它删了试试，再测一遍

把我之前的测试用例都测了一遍，都运行正常

除了。。除了下面这种情况。

果然，去掉额外的高度，就会有这种高度不够显示的情况。看来当时的我，就是遇到了这种情况，然后一个手快，就给heightWeNeed做了这种适配。

不过这种手快的适配方法貌似不太优雅，为了适配单一的这种情况，要牺牲剩下的所有情况都增加一个额外的高度。

而且因为我们适配的额外高度是一个固定值，如果我们给文本字体大小设置大一点，还是会有高度不够显示的可能，毕竟文本变大了，所需要的高度也就更多了。

好吧，这种适配方法看来是用不得了，要换一个吗？但是计算高度的公式 = 内边距 + 文本高度 + 描边高度，这个公式肯定是没错的。

回到我们最初的问题，我们为什么会需要增加一个额外的固定高度呢？明明公式都是对的，为什么还是会有偏差，难道是公式里的对应的值计算错误了？

我们看看再来看看这个式子：

heightWeNeed = getCompoundPaddingTop() + getCompoundPaddingBottom() +

        mStrokeWidth + mTextRect.height();

其中，getCompoundPaddingTop() 和 getCompoundPaddingBottom() 是Android提供的计算内边距的api，这个肯定不至于错吧。

mStrokeWidth是我们的描边宽度，是由用户使用时自定义的，这个没什么需要计算的，就是一个值而已

那么mTextRect.height() 这个呢，我们需要这里返回一个正确的文本高度。

看看这个mTextRect是在哪里赋值的

getPaint().getTextBounds(text, 0, text.length(), mTextRect);

从getTextBounds()里跟下去，发现最后调用测量的是native方法，看不到内部实现，不过我们可以看看getTextBounds()的注释

/**

 * Retrieve the text boundary box and store to bounds.

 *

 * Return in bounds (allocated by the caller) the smallest rectangle that

 * encloses all of the characters, with an implied origin at (0,0).

 *

 * @param text string to measure and return its bounds

 * @param start index of the first char in the string to measure

 * @param end 1 past the last char in the string to measure

 * @param bounds returns the unioned bounds of all the text. Must be allocated by the caller

 */

public void getTextBounds(String text, int start, int end, Rect bounds) {

    ...

    // native 方法

    nGetStringBounds(mNativePaint, text, start, end, mBidiFlags, bounds);

}

Return in bounds the smallest rectangle that encloses all of the characters

在bounds中返回包含所有字符的最小矩形

也就是说bounds返回的高度，只是能够包含文本的最小高度。

我们在三部曲概览里就讨论过，安卓里文本的描绘，是由几根线来确定的

文本的高度应该为(fontMetrics.bottom -fontMetrics. top)，但是，bounds中返回的height也够文本显示啊？怎么会显示成下面这个样子？

比如这样

但实际情况好像是这样的

我想到，安卓绘制文本是有起点坐标的，这个起点由gravity，textAlign，和baseline确定，和内容展示高度好像没有关系。

虽然我们展示高度设小了，但它的起点坐标还在原来的位置（比如y坐标baseline），这才导致了18数字显示不完整，底部好像缺了一块。

问题的根本找到了，看来好像有两种解决方法

1. 调整baseline的位置：把我们的baseline位置上移一些，让它和展示区域底部位置重合，这样就能以最小区域显示完整的文本内容。


2. 拓宽bounds.height的高度，以(fontMetrics.bottom - fontMetrics.top)作为文本的高度显示，这样就无需改变baseline的位置，但比第一种方案要多需要一些空间。

这里我选了第二种，顺着系统的绘制规则来，图个方便，而且我们的描边也可以利用文本顶部多出来的这些空间。

我们新设个变量 textHeight = fontMetrics.descent - fontMetrics.top

heightWeNeed = getCompoundPaddingTop() + getCompoundPaddingBottom() +

        textHeight + mStrokeWidth / 2;

为了最大化利用空间，文字顶部到top线的距离已经足够我们的描边显示了，而bottom线到descent线之间的距离很窄，就可能不够我们的描边显示。

所以只需要在文字底部加一半的描边宽度，同时去掉buttom线和descent线之间的距离，这样就能确保文字和描边都有足够的位置显示了。

好了，番外篇终于结束了，看了眼字数，居然比之前的三部曲系列都要多一些。实在没想到需要这么长的篇幅来讲这两个小优化，谢谢小伙伴们能够看到这里啦。

源码我都已经上传到github了，欢迎小伙伴自取，如果觉得写得不错的，还请给这份工程给个star ~_ <

兄dei，如果觉得我写的还不错，麻烦帮个忙呗 :-)

1. 给俺点个赞被，激励激励我，同时也能让这篇文章让更多人看见，(#^.^#)


2. 不用点收藏，诶别点啊，你怎么点了？这多不好意思！


3. 噢！还有，我维护了一个路由库。。没别的意思，就是提一下，我维护了一个路由库 =.= !！

拜托拜托，谢谢各位同学！

1.前言

好几年前写过一篇SharedPreference源码相关的文章，对apply跟commit方法讲解的不够透彻，作为颜值担当的天才少年来说，怎么能不一次深入到底呢？

2.正文

为了熟读源码，下班后我约了同事小雪一起探讨，毕竟三人行必有我师焉。哪里来的三个人，不管了，跟小雪研究学术更重要。

小安学长，看了你之前的文章：Android SharedPreference 源码分析（一）对apply()，commit()的底层原理还是不理解，尤其是线程和一些同步锁他里面怎么使用，什么情况下会出现anr？

既然说到apply()，commit()的底层原理，那肯定是老步骤了，上源码。 apply源码如下：

public void apply() {

            final long startTime = System.currentTimeMillis();



            final MemoryCommitResult mcr = commitToMemory();

            final Runnable awaitCommit = new Runnable() {

                    public void run() {

                        try {

                            mcr.writtenToDiskLatch.await();

                        } catch (InterruptedException ignored) {

                        }



                        if (DEBUG && mcr.wasWritten) {

                            Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration

                                    + " applied after " + (System.currentTimeMillis() - startTime)

                                    + " ms");

                        }

                    }

                };

			// 将 awaitCommit 添加到队列 QueuedWork 中

            QueuedWork.addFinisher(awaitCommit);



            Runnable postWriteRunnable = new Runnable() {

                    public void run() {

                        awaitCommit.run();

                        QueuedWork.removeFinisher(awaitCommit);// 将 awaitCommit 从队列 QueuedWork 中移除

                    }

                };



            SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);



            // Okay to notify the listeners before it's hit disk

            // because the listeners should always get the same

            // SharedPreferences instance back, which has the

            // changes reflected in memory.

            notifyListeners(mcr);

        }

你这丢了一大堆代码，我也看不懂啊。

别急啊，这漫漫长夜留给我们的事情很多啊，听我一点点给你讲，包你满意。 

apply()方法做过安卓的都知道（如果你没有做过安卓，那你点开我博客干什么呢，死走不送），频繁写文件建议用apply方法，因为他是异步存储到本地磁盘的。那么具体源码是如何操作的，让我们掀开他的底裤，不是，让我们透过表面看本质。

我们从下往上看，apply方法最后调用了SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);我长得帅我先告诉你，enqueueDiskWrite方法会把存储文件的动作放到子线程，具体怎么放的，我们等下看源码，这边你只要知道他的作用。这个方法的第二个参数 postWriteRunnable做了两件事：
1）让awaitCommit执行，及执行 mcr.writtenToDiskLatch.await();
2）执行QueuedWork.remove(awaitCommit);代码

writtenToDiskLatch是什么，QueuedWork又是什么？

writtenToDiskLatch是CountDownLatch的实例化对象，CountDownLatch是一个同步工具类，它通过一个计数器来实现的,初始值为线程的数量。每当一个线程完成了自己的任务调用countDown()，则计数器的值就相应得减1。当计数器到达0时,表示所有的线程都已执行完毕,然后在等待的线程await()就可以恢复执行任务。
1）countDown(): 对计数器进行递减1操作，当计数器递减至0时，当前线程会去唤醒阻塞队列里的所有线程。
2）await(): 阻塞当前线程，将当前线程加入阻塞队列。 可以看到如果postWriteRunnable方法被触发执行的话，由于 mcr.writtenToDiskLatch.await()的缘故，UI线程会被一直阻塞住，等待计数器减至0才能被唤醒。

QueuedWork其实就是一个基于handlerThread的，处理任务队列的类。handlerThread类为你创建好了Looper和Thread对象，创建Handler的时候使用该looper对象，则handleMessage方法在子线程中，可以做耗时操作。如果对于handlerThread的不熟悉的话，可以看我前面的文章：Android HandlerThread使用介绍以及源码解析

 觉得厉害，那咱就继续深入。
enqueueDiskWrite源码如下所示：

private void enqueueDiskWrite(final MemoryCommitResult mcr,

                                  final Runnable postWriteRunnable) {

        final boolean isFromSyncCommit = (postWriteRunnable == null);



        final Runnable writeToDiskRunnable = new Runnable() {

                public void run() {

                    synchronized (mWritingToDiskLock) {

                        writeToFile(mcr, isFromSyncCommit);

                    }

                    synchronized (mLock) {

                        mDiskWritesInFlight--;

                    }

                    if (postWriteRunnable != null) {

                        postWriteRunnable.run();

                    }

                }

            };



        // Typical #commit() path with fewer allocations, doing a write on

        // the current thread.

        if (isFromSyncCommit) {

            boolean wasEmpty = false;

            synchronized (mLock) {

                wasEmpty = mDiskWritesInFlight == 1;

            }

            if (wasEmpty) {

                writeToDiskRunnable.run();

                return;

            }

        }



        QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);

    }

很明显postWriteRunnable不为null，程序会执行QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);从writeToDiskRunnable我们可以看到，他里面做了两件事：
1）writeToFile():内容存储到文件；
2）postWriteRunnable.run()：postWriteRunnable做了什么，往上看，上面已经讲了该方法做的两件事。

QueuedWork.queue源码：

    public static void queue(Runnable work, boolean shouldDelay) {

        Handler handler = getHandler();



        synchronized (sLock) {

            sWork.add(work);



            if (shouldDelay && sCanDelay) {

                handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY);

            } else {

                handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN);

            }

        }

    }

private static class QueuedWorkHandler extends Handler {

        static final int MSG_RUN = 1;



        QueuedWorkHandler(Looper looper) {

            super(looper);

        }



        public void handleMessage(Message msg) {

            if (msg.what == MSG_RUN) {

                processPendingWork();

            }

        }

    }

这边我默认你已经知道HandlerThread如何使用啦，如果不知道，麻烦花五分钟去看下我之前的博客。
上面的代码很简单，其实就是把writeToDiskRunnable这个任务放到sWork这个list中，并且执行handler，根据HandlerThread的知识点，我们知道handlermessage里面就是子线程了。

接下来我们继续看handleMessage里面的processPendingWork()方法：

 private static void processPendingWork() {

        long startTime = 0;



        if (DEBUG) {

            startTime = System.currentTimeMillis();

        }



        synchronized (sProcessingWork) {

            LinkedList<Runnable> work;



            synchronized (sLock) {

                work = (LinkedList<Runnable>) sWork.clone();

                sWork.clear();



                // Remove all msg-s as all work will be processed now

                getHandler().removeMessages(QueuedWorkHandler.MSG_RUN);

            }



            if (work.size() > 0) {

                for (Runnable w : work) {

                    w.run();

                }



                if (DEBUG) {

                    Log.d(LOG_TAG, "processing " + work.size() + " items took " +

                            +(System.currentTimeMillis() - startTime) + " ms");

                }

            }

        }

    }

这代码同样很简单，先是把sWork克隆给work，然后开启循环，执行work对象的run方法，及调用writeToDiskRunnable的run方法。上面讲过了，他里面做了两件事：1）内容存储到文件 2）postWriteRunnable方法回调。 执行run方法的代码：

 final Runnable writeToDiskRunnable = new Runnable() {

                public void run() {

                    synchronized (mWritingToDiskLock) {

                        writeToFile(mcr, isFromSyncCommit);//由于handlermessage在子线程，则writeToFile也在子线程中

                    }

                    synchronized (mLock) {

                        mDiskWritesInFlight--;

                    }

                    if (postWriteRunnable != null) {

                        postWriteRunnable.run();

                    }

                }

            };

writeToFile方法我们不深入去看，但是要关注，里面有个setDiskWriteResult方法，在该方法里面做了如下的事情：

void setDiskWriteResult(boolean wasWritten, boolean result) {

            this.wasWritten = wasWritten;

            writeToDiskResult = result;

            writtenToDiskLatch.countDown();//计数器-1

        }

如何上面认真看了的同学，应该可以知道，当调用countDown()方法时，会对计数器进行递减1操作，当计数器递减至0时，当前线程会去唤醒阻塞队列里的所有线程。也就是说，当文件写完时，UI线程会被唤醒。

既然文件写完就会释放锁，那什么情况下会出现ANR呢？

Android系统为了保障在页面切换，也就是在多进程中sp文件能够存储成功，在ActivityThread的handlePauseActivity和handleStopActivity时会通过waitToFinish保证这些异步任务都已经被执行完成。如果这个时候过渡使用apply方法，则可能导致onpause，onStop执行时间较长，从而导致ANR。

private void handlePauseActivity(IBinder token, boolean finished,

            boolean userLeaving, int configChanges, boolean dontReport, int seq) {

       ......

            r.activity.mConfigChangeFlags |= configChanges;

            performPauseActivity(token, finished, r.isPreHoneycomb(), "handlePauseActivity");



            // Make sure any pending writes are now committed.

            if (r.isPreHoneycomb()) {

                QueuedWork.waitToFinish();

            }



           ......

    }

你肯定要问，为什么过渡使用apply方法，就有可能导致ANR？那我们只能看QueuedWork.waitToFinish();到底做了什么

 public static void waitToFinish() {

        long startTime = System.currentTimeMillis();

        boolean hadMessages = false;



        Handler handler = getHandler();



        synchronized (sLock) {

            if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) {

                // Delayed work will be processed at processPendingWork() below

                handler.removeMessages(QueuedWorkHandler.MSG_RUN);



                if (DEBUG) {

                    hadMessages = true;

                    Log.d(LOG_TAG, "waiting");

                }

            }



            // We should not delay any work as this might delay the finishers

            sCanDelay = false;

        }



        StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();

        try {

            processPendingWork();

        } finally {

            StrictMode.setThreadPolicy(oldPolicy);

        }



        try {

            while (true) {

                Runnable finisher;



                synchronized (sLock) {

                    finisher = sFinishers.poll();

                }



                if (finisher == null) {

                    break;

                }



                finisher.run();

            }

        } finally {

            sCanDelay = true;

        }



        synchronized (sLock) {

            long waitTime = System.currentTimeMillis() - startTime;



            if (waitTime > 0 || hadMessages) {

                mWaitTimes.add(Long.valueOf(waitTime).intValue());

                mNumWaits++;



                if (DEBUG || mNumWaits % 1024 == 0 || waitTime > MAX_WAIT_TIME_MILLIS) {

                    mWaitTimes.log(LOG_TAG, "waited: ");

                }

            }

        }

    }

看着一大坨代码，其实做了两件事：
1）主线程执行processPendingWork（）方法，把之前未执行完的内容存储到文件的操作执行完，这部分动作直接在主线程执行，如果有未执行的文件操作并且文件较大，则主线程会因为IO时间长造成ANR。
2）循环取出sFinishers数组，执行他的run方法。如果这时候有多个异步线程或者异步线程时间过长，同样会造成阻塞产生ANR。

第一个很好理解，第二个没有太看明白，sFinishers数组是在什么时候add数据的，而且根据writeToDiskRunnable方法可以知道，先写文件再加锁的，为啥会阻塞呢？

sFinishers的addFinisher方法是在apply（）方法里面调用的，代码如下：

        @Override

        public void apply() {

            ......

            // 将 awaitCommit 添加到队列 QueuedWork 中

            QueuedWork.addFinisher(awaitCommit);



            Runnable postWriteRunnable = new Runnable() {

                    @Override

                    public void run() {

                        awaitCommit.run();

                        QueuedWork.removeFinisher(awaitCommit);// 将 awaitCommit 从队列 QueuedWork 中移除

                    }

                };

            ......

        }

正常情况下其实是不会发生ANR的，因为writeToDiskRunnable方法中，是先进行文件存储再去阻塞等待的，此时CountDownLatch永远都为0，则不会阻塞主线程。

final Runnable writeToDiskRunnable = new Runnable() {

                @Override

                public void run() {

                    synchronized (mWritingToDiskLock) {

                        writeToFile(mcr, isFromSyncCommit);//写文件，写成功后会调用writtenToDiskLatch.countDown();计数器-1

                    }

                    synchronized (mLock) {

                        mDiskWritesInFlight--;

                    }

                    if (postWriteRunnable != null) {

                        postWriteRunnable.run();//回调到awaitCommit.run();进行阻塞

                    }

                }

            };

但是如果processPendingWork方法在异步线程在执行时，及通过enqueueDiskWrite方法触发的正常文件保存流程，这时候文件比较大或者文件比较多，子线程则一直在运行中；当用户点击页面跳转时，则触发该Activity的handlePauseActivity方法，根据上面的分析，handlePauseActivity方法里面会执行waitToFinish保证这些异步任务都已经被执行完成。
由于这边主要介绍循环取出sFinishers数组，执行他的run方法造成阻塞产生ANR，我们就重点看下sFinishers数组对象是什么，并且执行什么动作。

private static final LinkedList<Runnable> sFinishers = new LinkedList<>();

   @UnsupportedAppUsage

    public static void addFinisher(Runnable finisher) {

        synchronized (sLock) {

            sFinishers.add(finisher);

        }

    }

addFinisher刚刚上面提到是在apply方法中调用，则finisher就是入参awaitCommit，他的run方法如下：

final Runnable awaitCommit = new Runnable() {

                    @Override

                    public void run() {

                        try {

                            mcr.writtenToDiskLatch.await();//阻塞

                        } catch (InterruptedException ignored) {

                        }



                        if (DEBUG && mcr.wasWritten) {

                            Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration

                                    + " applied after " + (System.currentTimeMillis() - startTime)

                                    + " ms");

                        }

                    }

                };

不难看出，就是调用CountDownLatch对象的await方法，阻塞当前线程，将当前线程加入阻塞队列。也就是这个时候整个UI线程都阻塞在这边，等待processPendingWork这个异步线程执行完毕，虽然你是在子线程，但是我主线程在等你执行结束才会进行页面切换，所以如果过渡使用apply方法，则可能导致onpause，onStop执行时间较长，从而导致ANR。

小安学长不愧是我的偶像，我都明白了，那继续讲讲同步存储commit()方法吧。

commit方法其实就比较简单了，无非是内存和文件都在UI线程中，我们看下代码证实一下：

 @Override

        public boolean commit() {

            long startTime = 0;



            if (DEBUG) {

                startTime = System.currentTimeMillis();

            }



            MemoryCommitResult mcr = commitToMemory();//内存保存



            SharedPreferencesImpl.this.enqueueDiskWrite(

                mcr, null /* sync write on this thread okay */);//第二个参数为null

            try {

                mcr.writtenToDiskLatch.await();

            } catch (InterruptedException e) {

                return false;

            } finally {

                if (DEBUG) {

                    Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration

                            + " committed after " + (System.currentTimeMillis() - startTime)

                            + " ms");

                }

            }

            notifyListeners(mcr);

            return mcr.writeToDiskResult;

        }

可以看到enqueueDiskWrite的第二个参数为null，enqueueDiskWrite方法其实上面讲解apply的时候已经贴过了，为了不让你往上翻我们继续看enqueueDiskWrite方法：

   private void enqueueDiskWrite(final MemoryCommitResult mcr,

                                  final Runnable postWriteRunnable) {

        final boolean isFromSyncCommit = (postWriteRunnable == null);//此时postWriteRunnable为null，isFromSyncCommit 则为true



        final Runnable writeToDiskRunnable = new Runnable() {

                @Override

                public void run() {

                    synchronized (mWritingToDiskLock) {

                        writeToFile(mcr, isFromSyncCommit);

                    }

                    synchronized (mLock) {

                        mDiskWritesInFlight--;

                    }

                    if (postWriteRunnable != null) {

                        postWriteRunnable.run();

                    }

                }

            };



        // Typical #commit() path with fewer allocations, doing a write on

        // the current thread.

        if (isFromSyncCommit) {  //当调用commit方法时，isFromSyncCommit则为true

            boolean wasEmpty = false;

            synchronized (mLock) {

                wasEmpty = mDiskWritesInFlight == 1;

            }

            if (wasEmpty) {

                writeToDiskRunnable.run();//主线程回调writeToDiskRunnable的run方法，进行writeToFile文件的存储

                return;

            }

        }



        QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);

    }

关键代码已经注释过了，由于postWriteRunnable为null，则isFromSyncCommit为true，代码会在主线程回调writeToDiskRunnable的run方法，进行writeToFile文件的存储。这部分动作直接在主线程执行，如果文件较大，则主线程也会因为IO时间长造成ANR的。

所以SharedPreference 不管是commit()还是apply()方法，如果文件过大或者过多，都会有ANR的风险，那如何规避呢？

解决肯定有办法的，下一篇就介绍SharedPreference 的替代方案mmkv的原理，只是今晚有点晚了，咱们早上睡吧，不是，早点回家吧~~~

背景

曾几何时，我们只需要简简单单的一行 Thread.currentThread().getStackTrace() 代码就可以轻轻松松的获取到当前线程的堆栈信息，从而分析各种问题。随着需求的不断迭代，APP 遇到的问题越来越多，卡顿，ANR，异常等等问题接踵而来，那么简简单单某个时刻的堆栈信息已经不能满足我们的需求了，我们的目光逐渐转移到了每个时刻的堆栈上，如果能获取一个时间段内，每个时刻的堆栈信息，那么卡顿，以及 ANR 的问题也将被解决。

抓栈方案

目前对于一段时间内的抓栈方案有两种：

• 方法插桩抓栈


• Native 抓栈

代码插桩抓栈

基本思路

APP 编译阶段，对每个方法进行插桩，在插桩的同时，填入当前方法 ID，发生卡顿或者异常的时候，将之前收集到的方法 ID 进行聚合输出。

插桩流程图：

优点：简单高效，无兼容性问题

缺点：插桩导致所有类都非 preverify，同时 verify 与 optimize 操作会在加载类时被触发。增加类加载的压力照成一定的性能损耗。另外也会导致包体积变大，影响代码 Debug 以及代码崩溃异常后错误行数

Native 抓栈

使用 Native 抓栈之前，我们先了解一下 Java 抓栈的整个流程

JAVA堆栈获取流程图

抓栈当前线程

抓栈其他线程

Java堆栈获取原理分析

由于当前线程抓栈和其他线程抓栈流程类似，这里我们从其他线程抓栈的流程进行分析
首先从入口代码出发，Java 层通过 Thread.currentThread().getStackTrace() 开始获取当前堆栈数据

Thread.java



public StackTraceElement[] getStackTrace() {



    StackTraceElement ste[] = VMStack.getThreadStackTrace(this);

    return str!=null?ste:EmptyArray.STACK_TRACE_ELEMENT;

    

}

Thread 中的 getStackTrace 只是一个空壳，底层的实现是通过 native 来获取的，继续往下走，通过 VMStack 来获取我们需要的线程堆栈数据

dalvik_system_vmstack.cc



static jobjectArray VMStack_getThreadStackTrace(JNIEnv* env, jclass, jobject javaThread) {



    ScopedFastNativeObjectAccess soa(env);

    

    // fn 方法是线程挂起回调

    auto fn = [](Thread* thread, const ScopedFastNativeObjectAccess& soaa)

     REQUIRES_SHARED(Locks::mutator_lock_) -> jobject {

        return thread->CreateInternalStackTrace(soaa);

    };

    

    // 获取堆栈

    jobject trace = GetThreadStack(soa, javaThread, fn);

    if (trace == nullptr) {

        return nullptr;

    }

    

    // trace 是一个包含 method 的数组，有这个数据之后，我们进行数据反解，就能获取到方法堆栈明文

    return Thread::InternalStackTraceToStackTraceElementArray(soa, trace);

    

}

上述代码中，需要注意三个元素

• 
  

  fn={return thread->CreateInternalStackTrace(soaa);}。 // 这个是线程挂起后的回调函数

  
  


• 
  

  GetThreadStack(sao,javaThread,fn) // 用来获取实际的线程堆栈信息

  
  


• 
  

  Thread::InternalStackTraceToStackTraceElementArray(sao,trace)，这里 trace 就是我们拿到的目标产物，这里面就包含了当前线程此时此刻的堆栈信息，需要对堆栈进行进一步的解析，才能获取到可识别的堆栈文本

  
  

接下来我们从获取堆栈信息函数着手，看看 GetThreadStack 的具体行为。

dalvik_system_vmstack.cc



static ResultT GetThreadStack(const ScopedFastNativeObjectAccess& soa,jobject peer,T fn){



    ********

    ********

    ********

      

    ThreadList* thread_list = Runtime::Current()->GetThreadList();

    

    // 【Step1】: 挂起线程

    Thread* thread = thread_list->SuspendThreadByPeer(peer,SuspendReason::kInternal,&timed_out);

    if (thread != nullptr) {

      {

        ScopedObjectAccess soa2(soa.Self());

        

        // 【Step2】: FN 回调，这里面执行的就是抓栈操作，回到外层的回调函数逻辑中

        trace = fn(thread, soa);

      }

      

      // 【Step3】: 恢复线程

      bool resumed = thread_list->Resume(thread, SuspendReason::kInternal);

    }

  }

  return trace;

}

在该操作的三个步骤中，就包含了抓栈的整个流程，

• 
  

  【Step1】: 挂起线程，线程每时每刻都在执行方法，这样就导致当前线程的方法堆栈在不停的增加，如果想要抓到瞬时堆栈，就需要把当前线程暂停，保留瞬时的堆栈信息，这样抓出来的数据才是准确的。

  
  


• 
  

  【Step2】: 执行 FN 的回调，这里的 FN 回调，就是上文介绍的回调方法 fn={return thread->CreateInternalStackTrace(soaa)}

  
  


• 
  

  【Step3】: 恢复线程的正常运行。

  
  

上述流程中，我们需要重点关注一下 FN 回调里面做了什么，以及怎么做到的

thread.cc



jobject Thread::CreateInternalStackTrace(const ScopedObjectAccessAlreadyRunnable& soa) const {



    // 创建堆栈回溯观察者

    FetchStackTraceVisitor count_visitor(const_cast<Thread*>(this),&saved_frames[0],kMaxSavedFrames);

    count_visitor.WalkStack();    // 回溯核心方法

    

    // 创建堆栈回溯观察者 2 号，详细的堆栈数据就是 2 号处理返回的

    BuildInternalStackTraceVisitor build_trace_visitor(soa.Self(), const_cast<Thread*>(this), skip_depth);

    

    mirror::ObjectArray<mirror::Object>* trace = build_trace_visitor.GetInternalStackTrace();

    return soa.AddLocalReference<jobject>(trace);

    

}

• 
  

  创建堆回溯观察者 1 号 FetchStackTraceVisitor，最大深度 256 进行回溯，如果深度超过了 256，则使用 2 号继续进行回溯

  
  


• 
  

  创建堆回溯观察者 2 号 BuildInternalStackTraceVisitor，承接 1 号的回溯结果，1 号没回溯完，2 号接着回溯。

  
  

栈回溯的详细过程

回溯是通过 WalkStack 来实现的。StackVisitor::WalkStack 是一个用于在当前线程堆栈上单步遍历帧的函数。它可以用来收集当前线程堆栈上特定帧的信息，以便进行调试或其他分析操作。 例如，它可以用来找出当前线程堆栈上哪些函数调用了特定函数，或者收集特定函数的参数。 也可以用来找出线程调用的函数层次结构，以及每一层调用的函数参数。 使用这个函数，可以更好地理解代码的执行流程，并帮助进行异常处理和调试。

stack.cc



void StackVisitor::WalkStack(bool include_transitions) {



  for (const ManagedStack* current_fragment = thread_->GetManagedStack();current_fragment != nullptr; current_fragment = current_fragment->GetLink()) {

    

        cur_shadow_frame_ = current_fragment->GetTopShadowFrame();

        

        ****

        ****

        ****

        

        do {

            // 通知子类，进行栈帧的获取

            bool should_continue = VisitFrame();

            cur_depth_++;

            cur_shadow_frame_ = cur_shadow_frame_->GetLink();

          } while (cur_shadow_frame_ != nullptr);

  }

  

}

ManagedStack 是一个单链表，保存了当前 ShadowFrame 或者 QuickFrame 栈指针，先依次遍历 ManagedStack 链表，然后遍历其内部的 ShadowFrame 或者 QuickFrame 还原一个可读的调用栈，从而还原出当前的 Java 堆栈

还原操作是通过 VisitFrame 来实现的，它是一个抽象接口，实现类我们需要看 BuildInternalStackTraceVisitor 的实现

thread.cc



class BuildInternalStackTraceVisitor : public StackVisitor {



    mirror::ObjectArray<mirror::Object>* trace_ = nullptr;

    bool VisitFrame() override REQUIRES_SHARED(Locks::mutator_lock_) {

        

        ****

        ****

        ****

        

        // 每循环一帧，将其添加到 arrObj 中

        ArtMethod* m = GetMethod();

        AddFrame(m, m->IsProxyMethod() ? dex::kDexNoIndex : GetDexPc());

            return true;

    }

    

    void AddFrame(ArtMethod* method, uint32_t dex_pc) REQUIRES_SHARED(Locks::mutator_lock_) {

        ObjPtr<mirror::Object> keep_alive;

        if (UNLIKELY(method->IsCopied())) {

          ClassLinker* class_linker = Runtime::Current()->GetClassLinker();

          keep_alive = class_linker->GetHoldingClassLoaderOfCopiedMethod(self_, method);

        } else {

          keep_alive = method->GetDeclaringClass();

        }

        

        // 添加每一次遍历到的 artMethod 对象，在添加完成之后，进行 count++，进行 Arr 的偏移

        trace_->Set<false,false>(static_cast<int32_t>(count_) + 1, keep_alive);

        ++count_;

    }

    

}

在执行 VisitFrame 的过程中，会将每次的 method 拎出来，然后添加至 ObjectArray 的集合中。当所有方法查找完成之后，会进行 method 的反解。

堆栈信息反解关键操作

反解的流程在文章开头，通过 Thread::InternalStackTraceToStackTraceElementArray(soa,trace) 来进行反解。

thread.cc

  

jobjectArray Thread::InternalStackTraceToStackTraceElementArray(const ScopedObjectAccessAlreadyRunnable& soa,jobject internal,jobjectArray output_array,int* stack_depth) {

    

    int32_t depth = soa.Decode<mirror::Array>(internal)->GetLength() - 1;

    

    for (uint32_t i = 0; i < static_cast<uint32_t>(depth); ++i) {

        ObjPtr<mirror::ObjectArray<mirror::Object>> decoded_traces = soa.Decode<mirror::Object>(internal)->AsObjectArray<mirror::Object>();

        const ObjPtr<mirror::PointerArray> method_trace = ObjPtr<mirror::PointerArray>::DownCast(decoded_traces->Get(0));

            

        // 【Step1】: 提取数组中的 ArtMethod

        ArtMethod* method = method_trace->GetElementPtrSize<ArtMethod*>(i, kRuntimePointerSize);

        uint32_t dex_pc = method_trace->GetElementPtrSize<uint32_t>(i + static_cast<uint32_t>(method_trace->GetLength()) / 2, kRuntimePointerSize);

            

        // 【Step2】: 将 ArtMethod 转换成业务上层可识别的 StackTraceElement 对象

        const ObjPtr<mirror::StackTraceElement> obj = CreateStackTraceElement(soa, method, dex_pc);

        soa.Decode<mirror::ObjectArray<mirror::StackTraceElement>>(result)->Set<false>(static_cast<int32_t>(i), obj);

    }

    return result;

  

}



static ObjPtr<mirror::StackTraceElement> CreateStackTraceElement(



    const ScopedObjectAccessAlreadyRunnable& soa,

    ArtMethod* method,

    uint32_t dex_pc) REQUIRES_SHARED(Locks::mutator_lock_) {

    

    // 【Step3】: 获取行号

    line_number = method->GetLineNumFromDexPC(dex_pc);

    

    // 【Step4】: 获取类名

    const char* descriptor = method->GetDeclaringClassDescriptor();

    std::string class_name(PrettyDescriptor(descriptor));

    class_name_object.Assign(mirror::String::AllocFromModifiedUtf8(soa.Self(), class_name.c_str()));

    

    // 【Step5】: 获取类路径

    const char* source_file = method->GetDeclaringClassSourceFile();

    source_name_object.Assign(mirror::String::AllocFromModifiedUtf8(soa.Self(), source_file));

  

  

    // 【Step6】: 获取方法名

    const char* method_name = method->GetInterfaceMethodIfProxy(kRuntimePointerSize)->GetName();

    Handle<mirror::String> method_name_object(hs.NewHandle(mirror::String::AllocFromModifiedUtf8(soa.Self(), method_name)));

  

    // 【Step7】: 数据封装回抛

    return mirror::StackTraceElement::Alloc(soa.Self(),class_name_object,method_name_object,source_name_object,line_number);

}

到这里我们已经分析完一次由 Java 层触发的堆栈调用链路一直到底层的实现逻辑。

核心流程

我们的目标是抓栈，因此我们只需要关注 count_visitor.WalkStack 之后的栈回溯流程。

耗时阶段

这里最后阶段将 ArtMethod 转换成业务上层可识别的 StackTraceElement，由于涉及到大量的字符串操作，给 Java 堆栈的执行贡献了很大的耗时占比。

抓栈新思路

传统的抓栈产生的数据很完善，过程也比较耗时。我们是否可以简化这个流程，提高抓栈效率呢，理论上是可以的，我们只需要自己将这个流程复写一份，然后抛弃部分的数据，优化数据获取时间，同样可以做到更高效的抓栈体验。

Native抓栈逻辑实现

根据系统抓栈流程，我们可以梳理出要做的几个事情点

要做的事情：

• 
  

  挂起线程【获取挂起线程方法内存地址】

  
  


• 
  

  进行抓栈【获取抓栈方法内存地址】【优化抓栈耗时】

  
  


• 
  

  恢复线程的执行【获取恢复线程方法内存地址】

  
  

遇到的问题及解决方案：

• 如何获取系统 threadList 对象

threadList 是线程执行挂起和恢复的关键对象，系统未暴露该对象的直接访问操作，因此我们只能另辟蹊径来获取它，threadList 获取依赖流程图如下：

如果想要执行线程的挂起 thread_->SuspendThreadByPeer 或者恢复 thread_list->Resume ，首先需要获取到 thread_list 系统对象，该对象是通过 Runtime::Current()->getThreadList() 获取而来，，因此我们要先获取 Runtime ， Runtime 的获取可以通过 JavaVmExt 来获取，而 JavaVmExt 可以通过 JNI_OnLoad 时的 JavaVM 来获取，完整流程如下代码所示

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {



    JNIEnv *env = NULL;

    if (vm->GetEnv((void **) &env, JNI_VERSION_1_6) != JNI_OK) {

        return -1;

    }



    JavaVM *javaVM;

    env->GetJavaVM(&javaVM);

    auto *javaVMExt = (JavaVMExt *) javaVM;

    void *runtime = javaVMExt->runtime;



    // JavaVMExt 结构 

    // 10.0 https://android.googlesource.com/platform/art/+/refs/tags/android-10.0.0_r1/runtime/jni/java_vm_ext.h

    

    // 【Step1】. 找到 Runtime_instance_ 的位置

    if (api < 30) {

        runtime_instance_ = runtime;

    } else {

        int vm_offset = find_offset(runtime, MAX_SEARCH_LEN, javaVM);

        runtime_instance_ = reinterpret_cast<void *>(reinterpret_cast<char *>(runtime) + vm_offset - offsetof(PartialRuntimeR, java_vm_));

    }

    

    // 【Step2】. 以 runtime_instance_ 的地址为起点，开始找到 JavaVMExt 在 【https://android.googlesource.com/platform/art/+/refs/tags/android-10.0.0_r29/runtime/runtime.h】中的位置

    // 7.1 https://android.googlesource.com/platform/art/+/refs/tags/android-7.1.2_r39/runtime/runtime.h

    int offsetOfVmExt = findOffset(runtime_instance_, 0, MAX, (size_t) javaVMExt);

    if (offsetOfVmExt < 0) {

        ArtHelper::reduce_model = 1;

        return;

    }

  

    // 【Step3】. 根据 JavaVMExt 的位置，根据各个版本的结构，进行偏移，生成 PartialRuntimeSimpleTenR 的结构

    if (ArtHelper::api == ANDROID_P_API || ArtHelper::api == ANDROID_O_MR1_API) {

        PartialRuntimeSimpleNineR *simpleR = (PartialRuntimeSimpleNineR *) ((char *) runtime_instance_ + offsetOfVmExt - offsetof(PartialRuntimeSimpleNineR, java_vm_));

        thread_list = simpleR->thread_list_;

    }else if (ArtHelper::api <= ANDROID_O_API) {

        PartialRuntimeSimpleSevenR *simpleR = (PartialRuntimeSimpleSevenR *) ((char *) runtime_instance_ + offsetOfVmExt - offsetof(PartialRuntimeSimpleSevenR, java_vm_));

        thread_list = simpleR->thread_list_;

    }else{

        PartialRuntimeSimpleTenR *simpleR = (PartialRuntimeSimpleTenR *) ((char *) runtime_instance_ + offsetOfVmExt - offsetof(PartialRuntimeSimpleTenR, java_vm_));

        thread_list = simpleR->thread_list_;

    }

    

}    

经过三个步骤，我们就可以获取到底层的 Runtime 对象，以及最关键的 thread_list 对象，有了它，我们就可以对线程执行暂停和恢复操作。

• 线程的暂停和恢复

因为 SuspendThreadByPeer 和 Resume 方法我们访问不到，但如果我们能够找到这两个方法的内存地址，那么就可以直接执行了，怎么获取到内存地址呢？这里使用 Nougat_dlfunctions 的 fake_dlopen() 和 fake_dlsym() 来获取已被加载到内存的动态链接库 libart.so 中方法内存地址。

    WalkStack_ = reinterpret_cast<void (*)(StackVisitor *, bool)>(dlsym_ex(handle,"_ZN3art12StackVisitor9WalkStackILNS0_16CountTransitionsE0EEEvb"));

    SuspendThreadByThreadId_ = reinterpret_cast<void *(*)(void *, uint32_t, SuspendReason, bool *)>(dlsym_ex(handle,"_ZN3art10ThreadList23SuspendThreadByThreadIdEjNS_13SuspendReasonEPb"));

    Resume_ = reinterpret_cast<bool (*)(void *, void *, SuspendReason)>(dlsym_ex(handle, "_ZN3art10ThreadList6ResumeEPNS_6ThreadENS_13SuspendReasonE"));

    PrettyMethod_ = reinterpret_cast<std::string (*)(void *, bool)>(dlsym_ex(handle, "_ZN3art9ArtMethod12PrettyMethodEb"));

到这里，我们已经已经可以完成线程的挂起和恢复了，接下来就是抓栈的操作处理流程。

• 自定义抓栈

同样的，由于我们已经获取到用于栈回溯的 WalkStack 方法地址，我们只需要提供一个自定义的 TraceVisitor 类即可实现栈回溯

class CustomFetchStackTraceVisitor : public StackVisitor {



    bool VisitFrame() override {

    

        // 【Step1】: 系统堆栈调用时我们分析到的流程，每帧遍历时会走一次当前流程

        void *method = GetMethod();

        

		// 【Step2】: 获取到 Method 对象之后，使用 circular_buffer 存起来，没有多余的过滤逻辑，不反解字符串

        if (CustomFetchStackTraceVisitorCallback!= nullptr){

            return CustomFetchStackTraceVisitorCallback(method);

        }

        return true;

    }

    

}   

获取到 Method 之后，为了节省本次的抓栈耗时，我们使用固定大小的 circular_buffer 将数据存储起来，新数据自动覆盖老数据，根据需求，进行异步反解 Method 中的详细堆栈数据。到这里，自定义的 Native 抓栈逻辑就完成了。

总结

目前自定义 native 抓栈的多个阶段需要兼容不同系统版本的 thread_list 获取，以及不同版本的线程挂起，线程恢复的函数地址获取。这些都会导致出现或多或少的兼容性问题，这里可以通过两种方案来规避，第一种是过滤读取到的不合法地址，对于这类不合法地址，需要跳过抓栈流程。另外一种就是动态配置下发过滤这些不兼容版本机型。

参考资料

• Nougat_dlfunctions：github.com/avs333/Noug…


• 环形缓冲区：baike.baidu.com/item/%E7%8E…


• Android 平台下的 Method Trace 实现解析：zhuanlan.zhihu.com/p/526960193…

事情是这样的，我无聊刷到一个B站视频【旁门左道PPT】我发现了大厂发布会中，少文字PPT还贼高级的秘密！。看到视频中这个特殊的PPT文字效果，个人感觉非常高端。我就想，能不能用TextView来实现。于是就有了这篇文章，效果如下图：

简单填充	加入文字排版	加入动画

图片填充

在Android中，google提供了 BitmapShader 来实现图片填充的功能。代码如下

public BitmapShader(@NonNull Bitmap bitmap, 

                        @NonNull TileMode tileX, 

                        @NonNull TileMode tileY)

参数介绍：

● bitmap：用来做填充的 Bitmap 对象

● tileX：横向的 TileMode（平铺模式）

● tileY：纵向的 TileMode

TileMode有三种：分别是 Shader.TileMode.CLAMP、Shader.TileMode.MIRROR、Shader.TileMode.REPEAT

● Shader.TileMode.CLAMP：如果着色器超出原始边界范围，会复制边缘颜色。

● Shader.TileMode.MIRROR：横向和纵向的重复着色器的图像，交替镜像图像是相邻的图像总是接合。

● Shader.TileMode.REPEAT： 横向和纵向的重复着色器的图像。

接下来，我们自定义 TextView，让它使用我们定义的Shader，代码如下：

class MaskTextView: androidx.appcompat.widget.AppCompatTextView {



    constructor(context: Context) : super(context)

    constructor(context: Context, attrs: AttributeSet?) : super(context, attrs)

    constructor(context: Context, attrs: AttributeSet?, defStyleAttr: Int) : super(

        context,

        attrs,

        defStyleAttr

    )



    private var shader: BitmapShader? = null



    fun setMaskDrawable(source: Drawable): Unit {

        val maskW: Int = source.getIntrinsicWidth()

        val maskH: Int = source.getIntrinsicHeight()



        val b = Bitmap.createBitmap(maskW, maskH, Bitmap.Config.ARGB_8888)

        val c = Canvas(b)



        c.drawColor(currentTextColor)

        source.setBounds(0, 0, maskW, maskH)

        source.draw(c)

        

        shader = BitmapShader(b, Shader.TileMode.REPEAT, Shader.TileMode.CLAMP)

        paint.shader = shader

    }

}

在免费壁纸网站中找到一个你喜欢的图片，调用 setMaskDrawable 方法时，我们就可以看到填充后的效果了。效果如下：

但是光这个效果还不够，还需要设置文字排版。看【旁门左道PPT】我发现了大厂发布会中，少文字PPT还贼高级的秘密！我们知道，有三种文字排版，分别是 高低低高、高低高低、低高低高，它们都需要修改文字的 baseline 来实现。

如何修改单个字符的 baseline 呢？很简单，不需要重写 onDraw 方法。我们可以自定义 Span，然后通过 TextPaint 来实现。在上代码前，先介绍一下 TextPaint，TextPaint 继承 Paint，在绘制和测量文本时给Android一些额外的数据。它的属性介绍如下：

● baselineShift - 基线是文本底部的线。改变baselineShift会使基线向上或向下移动，所以它影响到文本在一条线上的绘制高度。

● bgColor - 这是文本后面的背景颜色。

● density - 暂不清楚它的作用

● drawableState - 暂不清楚它的作用

● linkColor - 一个链接的文本颜色。

可以看到我们只需要修改 baselineShift 就可以改变单个文字的 baseline 了，自定义的Span的代码如下：

class TextUpOrDownSpan(private val isUp:Boolean, private val offset: Int): CharacterStyle() {



    override fun updateDrawState(tp: TextPaint?) {

        tp?.baselineShift = if(isUp) - offset else offset

    }

}

效果如下：

添加一个波浪动画

我们也可以给我们的图片填充增加一个动画，其中最常见的就是波浪动画了。效果实现很简单：

第一步：在波浪效果网站上下载一张自己想要的波浪图片

第二步：创建自定义的TextView，加上对应的参数，方便做动画。代码如下：

class AnimatorMaskTextView: androidx.appcompat.widget.AppCompatTextView {



    private var shader: BitmapShader? = null

    private var shaderMatrix: Matrix = Matrix()

    private var offsetY = 0f

    var maskX = 0f

        set(value) {

            field = value

            invalidate()

        }

    var maskY = 0f

        set(value) {

            field = value

            invalidate()

        }



    fun setMaskDrawable(source: Drawable): Unit {

        val maskW: Int = source.getIntrinsicWidth()

        val maskH: Int = source.getIntrinsicHeight()



        val b = Bitmap.createBitmap(maskW, maskH, Bitmap.Config.ARGB_8888)

        val c = Canvas(b)



        c.drawColor(currentTextColor)

        source.setBounds(0, 0, maskW, maskH)

        source.draw(c)



        shader = BitmapShader(b, Shader.TileMode.REPEAT, Shader.TileMode.CLAMP)

        paint.shader = shader

        offsetY = ((height - maskH) / 2).toFloat()

    }



    override fun onDraw(canvas: Canvas?) {

        shaderMatrix.setTranslate(maskX, offsetY + maskY)

        shader?.setLocalMatrix(shaderMatrix)

        paint.shader = shader

        super.onDraw(canvas)

    }

}

第三步：使用Android的动画api，控制图片的位置。代码如下：

val maskXAnimator: ObjectAnimator = 

    ObjectAnimator.ofFloat(textView, "maskX", 0f, textView.width.toFloat())

val maskYAnimator: ObjectAnimator =

    ObjectAnimator.ofFloat(textView, "maskY", 0f, (-textView.getHeight()).toFloat())

val animatorSet = AnimatorSet()

animatorSet.playTogether(maskXAnimator, maskYAnimator)

animatorSet.start()

效果如下：

记一次JNI内存泄漏

前景

在视频项目播放界面来回退出时，会触发内存LeakCanary内存泄漏警告。

分析

查看leakCanary的日志没有看到明确的泄漏点，所以直接取出leakCanary保存的hprof文件，保存目录在日志中有提醒，需要注意的是如果是android11系统及以上的保存目录和android11以下不同，android11保存的目录在：

   /data/media/10/Download/leakcanary-包名/2023-03-14_17-19-45_115.hprof 

使用Memory Analyzer Tool（简称MAT） 工具进行分析，需要讲上面的hrof文件转换成mat需要的格式：

   hprof-conv -z 转换的文件 转换后的文件

    

   hprof-conv -z 2023-03-14_17-19-45_115.hprof mat115.hprof

打开MAT，导入mat115文件，等待一段时间。

在预览界面打开Histogram，搜索需要检测的类，如：VideoActivity

搜索结果查看默认第一栏，如果没有泄漏，关闭VideoActivity之后，Objects数量一般是零，如果不为零，则可能存在泄漏。

右键Merge Shortest Paths to GC Roots/exclude all phantom/weak/soft etc,references/ 筛选出强引用的对象。

筛选出结果后，出现com.voyah.cockpit.video.ui.VideoActivity$1 @0x3232332 JIN Global 信息，且无法继续跟踪下去。

筛选出结果之后显示有六个VideoActivity对象没有释放，点击该对象也无法看到GC对象路径。（正常的java层内存泄漏能够看到泄漏的对象具体是哪一个）

正常的内存泄漏能够看到具体对象，如图：

这个MegaDataStorageConfig就是存在内存泄漏。

而我们现在的泄漏确实只知道VideoActivity$1 对象泄漏了，没有具体的对象，这样就没有办法跟踪下去了。

解决办法：

虽然无法继续跟踪，但泄漏的位置说明就是这个VideoActivity$1 ，我们可以解压apk，在包内的class.dex中找到VideoActivity$1，我们可以解压apk，在包内的class.dex中找到VideoActivity1这个Class类（class.dex可能有很多，一个个找），打开这个class，查看字节码（可以android studio中快捷打开build中的apk）,根据【 .line 406 】等信息定位代码的位置，找到泄漏点。

根据方法名、代码行数、类名，直接定位到了存在泄漏的代码：

红框区内就是内存泄漏的代码，这个回调是一个三方sdk工具，我使用时进行了注册，在onDestory中反注册，但还是存在内存泄漏。（该对象未使用是我代码修改之后的）

修改方法

将这个回调移动到Application中去，然后进行事件或者回调的方式通知VideoActivity，在VideoActivity的onDestory中进行销毁回调。

修改完之后，多次进入VideoAcitivity然后在退出，导出hprof文件到mat中筛选查看，如图：

VideoActiviyty的对象已经变成了零，说明开始存在的内存泄漏已经修改好了，使用android proflier工具也能看到在退出videoactivity界面之后主动进行几次gc回收，内存使用量会回归到进入该界面之前。

总结：

1. LeakCanary工具为辅助，MAT工具进行具体分析。因为LeakCanary工具的监听并不准确，如触发leakcanary泄漏警告时代码已经泄漏了很多次。


2. 如果能够直接查看泄漏的对象，那是最好修改的，如果不能直接定位泄漏的对象，可以通过泄漏的Class对象在apk解压中找到改class，查看字节码定位具体的代码泄漏位置。


3. 使用第三方的sdk时，最好使用Application Context，统一分发统一管理，减少内存泄漏。

背景

用FLutterWeb开发的网站在使用过程中出现了一些问题，比如在Google浏览器中使用交互、动画流畅，在360浏览器中就卡顿；图标在代码中动态设置颜色的方式在Google浏览器中正常显示，在Safari浏览器中颜色缺失，变为黑色；在有的电脑中Google浏览器也有动画、交互卡顿的现象、页面报错等。很奇怪，一脑袋问号。

优化方案

这些问题的原因是，渲染模式为html导致的，将渲染模式由html改为canvaskit，之前遇到的问题基本就解决了，动画也不卡了，画面也流畅了，图标也正常了，兼容性也提高了，再也不用担心在老板的电脑上卡住了。

渲染模式

简单说说两种模式的区别。

html渲染模式：flutter会采用HTML的custom element，CSS，Canvas和SVG来渲染UI元素。

canvaskit渲染模式：flutter将 Skia 编译成 WebAssembly 格式，并使用 WebGL 渲染。

所以使用canvaskit会更加流畅，更符合FLutter的气质。但是！也出现了些新的问题。

由Canvaskit引起的问题

图片跨域

报错描述：
Access to XMLHttpRequest at 'https://.../icon/setting_228.webp' from origin 'https://...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

在html模式下是正常的，而在canvaskit出现了跨域问题，查看日志发现区别。

html的网络请求类型type就是图片本身，不会出现问题。

不会出现跨域的问题原因是在HTML中，有一些标签也可以发起HTTP请求，比如script标签，link标签，img标签，form标签，且被允许跨域。

1. link，img标签都是单纯的引入资源文件


2. form标签用于收集用户输入并发送，但是发送成功会跳转到新网页，并将服务器响应作为新网页的内容


3. script标签可以引入外部js文件，并执行引入的js文件的代码

其中，script标签由于其可以执行引入的js文件的代码，再加上其跨域特性，让script标签可以用来做一些超出其设计初衷的事。script标签会发起HTTP GET去请求服务器上的js文件，所以script标签可以用于实现HTTP GET跨域请求。

而canvaskit模式下，请求类型是xhr，不支持跨域。而我的图片地址和服务地址并不在一个域名，所以出现该问题。

原因是同源策略，它是浏览器特有的一种安全机制，主要用于限制不同的源之间的数据交互。

那如何解决呢？

询问前端大佬后，发现解决问题最快的方法就是放到自身服务的域名下。随后我把图片放在项目中的asset目录中，更改本地引用地址，打包上传部署，解决！

（PS：这个问题在本地debug模式下，并不会出现）

首次打开加载慢

在首次改成canvaskit模式部署后，打开网站，页面一度白屏很长时间，预计有10秒，查看后台日志发现是下载了很多文件，包括canvaskit绘制引擎、字体等。主要耗时是在引擎（约9M）、字体下载，而下载这些的域名都是官方的，所以下载速度也有所限制。

解决办法：
将引擎和字体传值自己的服务器，以加快下载速度。

1. 
   

   引擎本地化，查看网络请求详情，可以看到下载地址，单独下载后放到项目中。
   
   我的位置是web/assets/canvaskit/canvaskit.js&wasm。
   
   
   再设置替换引擎路径，在运行或打包的时候加上以下命令行。等号后面为本地的路径。

   
   

   --dart-define=FLUTTER_WEB_CANVASKIT_URL=assets/canvaskit/
   

   
   


2. 
   

   本地化加载KFOmCnqEu92Fr1Me5WZLCzYlKw.ttf字体文件，同样在请求详情中获取地址，下载至本地，放在本地，web/assets/canvaskit/。

   
   

   

   
   

   替换本地地址，在构建完成后的build目录下的main.dart.js中搜索该字体名，把前缀替换成本地路径。

   
   

   https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Me5WZLCzYlKw.ttf
   
   替换成
   
   assets/canvaskit/KFOmCnqEu92Fr1Me5WZLCzYlKw.ttf

   
   

字体需下载

在打开页面时，会出现字体乱码，原因是正在下载字体，而且引用的字体不一样下载的库也是不同的。同样也可以下载至本地，替换main.dart.js的地址，但下载完体验后，发现不管是第一次还是之后都会出现乱码，只是显示的时间长短，体验也是不很好。

所以我是在pubspec.yaml中设置了本地的字体包的方式解决的，这样在首次加载或后面的刷新，都未出现过乱码。

加载时提示

经过上面两步设置，首次加载时长会有大大缩减，但是也会有白屏，为了更好的体验在白屏时加个提示。

// 在 web/index.html 中的 body 标签下加提示

<div id="text">静态资源加载中...</div>

浏览器刷新后页面加载两次

在使用网站时刷新会出现页面加载两次的问题，查看日志发现是web/index.html中的一段代码引起的。

// If service worker doesn't succeed in a reasonable amount of time,

// fallback to plaint <script> tag.

setTimeout(() => {

  if (!scriptLoaded) {

    console.warn(

      'Failed to load app from service worker. Falling back to plain <script> tag.',

    );

    loadMainDartJs();

  }

}, 4000);

引起超时的原因是navigator.serviceWorker.register(serviceWorkerUrl)注册失败，而上面的代码是兜底的逻辑。serviceWorker是服务器与浏览器之间的代理，目前用不上，所以将注册逻辑注释掉，直接调用loadMainDartJs()即可。

路由包装url地址方式失效

在canvaskit模式下，刷新后不会停留在当前页面了。之前写过一篇文章《FlutterWeb浏览器刷新后无法回退的解决方案》中的方案看来只适应在html模式下。

解决办法：
在上面的的文章基础上稍微修改下。

 // 刷新时回调

    _beforeUnload = (event) {

      // 本地记录,标记成"已刷新"

      DB(DBKey.isRefresh).value = true;



      // 记录刷新时的页面,用于还原(本次新增的方法）

      List history = get();

      DB(DBKey.initRoute).value = history.last;

      history.removeLast();

      set(history);



      // 移除刷新前的实例的监听

      html.window.removeEventListener('beforeunload', _beforeUnload);

      html.window.removeEventListener('popstate', _popState);

    };

    

// 获取上次最后的页面，(本次新增的方法）

  static String initRoute(currentContext) {

    return DB(DBKey.initRoute).get(Uri(scheme: RoutePath.scheme, host: RoutePath.home).toString());

  }



// 初始化

  MaterialApp(

      .....

      initialRoute: RouterHistory.initRoute(context),//(本次新增的方法）

      .....

      ))

这样设置完后也会停留在当前页面了。

最后

如果有遇到其他问题或更好的解决办法欢迎提出讨论

可能是 Flutter 上最强的网络框架, 基于dio实现的非侵入式框架(不影响原有功能). 学习成本低、使用简单, 一行代码发起网络请求, 甚至无需初始化。

之前发过两篇关于封装网络库的文章：

• 强大的dio封装，可能满足你的一切需要


• 一步一步教你封装最新版的Dio

距离最早的文章发布时间，已经过去了三年。这期间 dio 也更新到5.x.x了，在使用中也积攒了许多定制需求和优化方案。在确定需求和方案后，修修改改，终于发布了最新最实用的网络请求版本。

欢迎贡献代码/问题

特点

• 个人使用下来感觉开发效率比目前网络请求库都高：最简单易用


• 专为 Flutter 而生，支持全平台


• 遵循设计模式最佳实践，build模式全局配置


• catch请求错误，不需要开发者处理


• 优秀的源码/注释/文档/示例


• 类似kotlin的语法糖：请求结果的when语句和密封类

主要功能

• RESTful API 设计
  GET/POST/PUT/HEAH/DELETE/PATCH/DOWNLOAD


• 可取消请求


• 异步解析，数据量大不再卡顿


• 全局错误处理(减少崩溃率)


• 自定义解析器，支持全局和单个请求


• 自定义解析方法


• 配置请求参数


• 漂亮的日志打印


• 证书快速配置


• 代理配置


• 拦截器配置


• 强制缓存模式/自定义缓存Key/缓存有效期/LRU缓存算法/缓存任何数据


• 监听上传/下载进度

简单使用

添加依赖：

dependencies:

  flutter_nb_net: ^0.0.1

像 dio 一样使用,无需配置,返回实体类实现BaseNetworkModel，复写fromJson函数即可,：

class BannerModel extends BaseNetworkModel<BannerModel> {



  @override

  BannerModel fromJson(Map<String, dynamic> json) {

    return BannerModel.fromJson(json);

  }

  //...

  }

温馨提示：dart实体类可用freezed、json_serializable生成或者JsonToDart插件一键生成。

  /// Get 请求

  void requestGet() async {

    var appResponse = await get<BannerModel, BannerModel>("banner/json",

        responseType: BannerModel());

    appResponse.when(success: (BannerModel model) {

      var size = model.data?.length;

      debugPrint("成功返回$size条");

    }, failure: (String msg, int code) {

      debugPrint("失败了：msg=$msg/code=$code");

    });

  }

get<BannerModel, BannerModel>这里有两个泛型，前者是接口返回的数据需要序列化的类型，后者是开发关注的需要返回的类型。如果数据类型一致，两个泛型就是一样的。否则，比如接口返回一个用户列表，前面泛型就是User类型，后面是List<User>；又或者接口返回的数据包了几层，我们只需要最里面的数据格式，那么前面就是需要序列化的整个数据类型，第二个泛型是最里面的数据类型。

配置使用

全局配置

在使用前进行全局配置：

 NetWrapper.instance

      // header

      .addHeaders({"aaa": '111'})

      // baseUrl

      .setBaseUrl("https://www.wanandroid.com/")

      // 代理/https

      .setHttpClientAdapter(IOHttpClientAdapter()

        ..onHttpClientCreate = (client) {

          client.findProxy = (uri) {

            return 'PROXY 192.168.20.43:8888';

          };

          client.badCertificateCallback =

              (X509Certificate cert, String host, int port) => true;

          return client;

        })

      // cookie

      .addInterceptor(CookieManager(CookieJar()))

      // dio_http_cache

      .addInterceptor(DioCacheManager(CacheConfig(

        baseUrl: "https://www.wanandroid.com/",

      )).interceptor)

      // dio_cache_interceptor

      .addInterceptor(DioCacheInterceptor(

          options: CacheOptions(

        store: MemCacheStore(),

        policy: CachePolicy.forceCache,

        hitCacheOnErrorExcept: [401, 403],

        maxStale: const Duration(days: 7),

        priority: CachePriority.normal,

        cipher: null,

        keyBuilder: CacheOptions.defaultCacheKeyBuilder,

        allowPostMethod: false,

      )))

       //  全局解析器

      .setHttpDecoder(MyHttpDecoder.getInstance())

       //  超时时间

      .setConnectTimeout(const Duration(milliseconds: 3000))

      // 允许打印log，默认未 true

      .enableLogger(true)

      .create();

如果接口返回的数据格式规范，配置自定义一个全局解析器 .setHttpDecoder(MyHttpDecoder.getInstance())：

/// 默认解码器

class MyHttpDecoder extends NetDecoder {

  /// 单例对象

  static final MyHttpDecoder _instance = MyHttpDecoder._internal();



  /// 内部构造方法，可避免外部暴露构造函数，进行实例化

  MyHttpDecoder._internal();



  /// 工厂构造方法，这里使用命名构造函数方式进行声明

  factory MyHttpDecoder.getInstance() => _instance;



  @override

  K decode<T extends BaseNetworkModel, K>(

      {required Response<dynamic> response, required T responseType}) {

    var errorCode = response.data['errorCode'];



    /// 请求成功

    if (errorCode == 0) {

      var data = response.data['data'];

      if (data is List) {

        var dataList = List<T>.from(

            data.map((item) => responseType.fromJson(item)).toList()) as K;

        return dataList;

      } else {

        var model = responseType.fromJson(data) as K;

        return model;

      }

    } else {

      var errorMsg = response.data['errorMsg'];

      throw NetException(errorMsg, errorCode);

    }

  }

}

如果添加缓存，可以使用dio_cache_interceptor、dio_http_cache等 dio 推荐的缓存库。

 // dio_http_cache

      .addInterceptor(DioCacheManager(CacheConfig(

        baseUrl: "https://www.wanandroid.com/",

      )).interceptor)

      // dio_cache_interceptor

      .addInterceptor(DioCacheInterceptor(

          options: CacheOptions(

        store: MemCacheStore(),

        policy: CachePolicy.forceCache,

        hitCacheOnErrorExcept: [401, 403],

        maxStale: const Duration(days: 7),

        priority: CachePriority.normal,

        cipher: null,

        keyBuilder: CacheOptions.defaultCacheKeyBuilder,

        allowPostMethod: false,

      )))

因为dio_http_cache依赖的dio和json_annotation是旧版本，所以如果使用dio_http_cache需要解决下依赖冲突：

dependency_overrides:

  dio: ^5.0.3

  json_annotation: ^4.8.0

配置代理和证书：

      .setHttpClientAdapter(IOHttpClientAdapter()

        ..onHttpClientCreate = (client) {

          client.findProxy = (uri) {

            return 'PROXY 192.168.20.43:8888';

          };

          client.badCertificateCallback =

              (X509Certificate cert, String host, int port) => true;

          return client;

        })

配置cookie：

addInterceptor(CookieManager(CookieJar()))

开启 log，默认开启：

.enableLogger(true)

特殊配置

有的接口比较特殊，比如返回的数据格式是特殊的，需要单独解析，此时有两种方法实现，第一种适合多个相同的特殊接口，在请求时传入自定义的解析器，第二种是在回调中解析。

解析器httpDecode：

    var appResponse = await get<BannerBean, List<BannerBean>>("banner/json",

        responseType: BannerBean(), httpDecode: MyHttpDecoder.getInstance());

    appResponse.when(success: (List<BannerBean> model) {

      var size = model.length;

      debugPrint("成功返回$size条");

    }, failure: (String msg, int code) {

      debugPrint("失败了：$msg");

    });

回调converter：

   var appResponse = await get<BannerModel, List<BannerBean>>("banner/json",

        options: buildCacheOptions(const Duration(days: 7)),

        responseType: BannerModel(), converter: (response) {

      var errorCode = response.data['errorCode'];

      /// 请求成功

      if (errorCode == 0) {

        var data = response.data['data'];

        var dataList = List<BannerBean>.from(

            data.map((item) => BannerBean.fromJson(item)).toList());

        return Result.success(dataList);

      } else {

        var errorMsg = response.data['errorMsg'];

        return Result.failure(msg: errorMsg, code: errorCode);

      }

    });

    appResponse.when(success: (List<BannerBean> model) {

      debugPrint("成功返回${model.length}条");

    }, failure: (String msg, int code) {

      debugPrint("失败了：msg=$msg/code=$code");

    });

名字的由来

一开始这个库的名字是net，这是我第一次在 pub 上发布，不知道库名称不能重合的规则，一直失败：

`xxx@gmail.com` has insufficient permissions to upload new versions to existing package `net`.

说明 pub 上已经有了这个名字的库，改名flutter_net，依然失败：

`xxx@gmail.com` has insufficient permissions to upload new versions to existing package `flutter_net`.

最后改名为flutter_nb_net，终于发布成功了。

国际惯例上源码

pub地址

Compose推出之初，就曾引发广泛的讨论，其中一个比较普遍的声音就是——“🤨这跟Flutter也长得太像了吧？！”

这里说的长得像，实际更多指的是UI编码的风格相似，而关于这种风格有一个专门的术语，叫做声明式UI。

对于那些已经习惯了命令式UI的Android或iOS开发人员来说，刚开始确实很难理解什么是声明式UI。就像当初刚踏入编程领域的我们，同样也很难理解面向过程编程和面向对象编程的区别一样。

为了帮助这部分原生开发人员完成从命令式UI到声明式UI的思维转变，本文将结合示例代码编写、动画演示以及生活例子类比等形式，详细介绍声明式UI的概念、优点及其应用。

照例，先奉上思维导图一张，方便复习：

命令式UI的特点

既然命令式UI与声明式UI是相对的，那就让我们先来回顾一下，在一个常规的视图更新流程中，如果采用的是命令式UI，会是怎样的一个操作方式。

以Android为例，首先我们都知道，Android所采用的界面布局，是基于View与ViewGroup对象、以树状结构来进行构建的视图层级。

当我们需要对某个节点的视图进行更新时，通常需要执行以下两个操作步骤：

1. 使用findViewById()等方法遍历树节点以找到对应的视图。


2. 通过调用视图对象公开的setter方法更新视图的UI状态

我们以一个最简单的计数器应用为例：

这个应用唯一的逻辑就是“当用户点击"+"号按钮时数字加1”。在传统的Android实现方式下，代码应该是这样子的：

class CounterActivity : AppCompatActivity() {



    var count: Int = 0



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_counter)



        val countTv = findViewById<TextView>(R.id.count_tv)

        countTv.text = count.toString()



        val plusBtn = findViewById<Button>(R.id.plus_btn)

        plusBtn.setOnClickListener {

            count += 1

            countTv.text = count.toString()

        }



    }

}

这段代码看起来没有任何难度，也没有明显的问题。但是，假设我们在下一个版本中添加了更多的需求：

• 当用户点击"+"号按钮，数字加1的同时在下方容器中添加一个方块。


• 当用户点击"-"号按钮，数字减1的同时在下方容器中移除一个方块。


• 当数字为0时，下方容器的背景色变为透明。

现在，我们的代码变成了这样：

class CounterActivity : AppCompatActivity() {



    var count: Int = 0



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_counter)



        // 数字

        val countTv = findViewById<TextView>(R.id.count_tv)

        countTv.text = count.toString()



        // 方块容器

        val blockContainer = findViewById<LinearLayout>(R.id.block_container)



        // "+"号按钮

        val plusBtn = findViewById<Button>(R.id.plus_btn)

        plusBtn.setOnClickListener {

            count += 1

            countTv.text = count.toString()

            // 方块

            val block = View(this).apply {

                setBackgroundColor(Color.WHITE)

                layoutParams = LinearLayout.LayoutParams(40.dp, 40.dp).apply {

                    bottomMargin = 20.dp

                }

            }

            blockContainer.addView(block)

            when {

                count > 0 -> {

                    blockContainer.setBackgroundColor(Color.parseColor("#FF6200EE"))

                }

                count == 0 -> {

                    blockContainer.setBackgroundColor(Color.TRANSPARENT)

                }

            }

        }



        // "-"号按钮

        val minusBtn = findViewById<Button>(R.id.minus_btn)

        minusBtn.setOnClickListener {

            if(count <= 0) return@setOnClickListener

            count -= 1

            countTv.text = count.toString()

            blockContainer.removeViewAt(0)

            when {

                count > 0 -> {

                    blockContainer.setBackgroundColor(Color.parseColor("#FF6200EE"))

                }

                count == 0 -> {

                    blockContainer.setBackgroundColor(Color.TRANSPARENT)

                }

            }

        }



    }



}

已经开始看得有点难受了吧？这正是命令式UI的特点，侧重于描述怎么做，我们需要像下达命令一样，手动处理每一项UI的更新，如果UI的复杂度足够高的话，就会引发一系列问题，诸如：

• 可维护性差：需要编写大量的代码逻辑来处理UI变化，这会使代码变得臃肿、复杂、难以维护。


• 可复用性差：UI的设计与更新逻辑耦合在一起，导致只能在当前程序使用，难以复用。


• 健壮性差：UI元素之间的关联度高，每个细微的改动都可能一系列未知的连锁反应。

声明式UI的特点

而同样的功能，假如采用的是声明式UI，则代码应该是这样子的：

class _CounterPageState extends State<CounterPage> {

  int _count = 0;



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: Text(widget.title),

      ),

      body: Column(

        children: [

          // 数字

          Text(

            _count.toString(),

            style: const TextStyle(fontSize: 48),

          ),

          Row(

            mainAxisSize: MainAxisSize.min,

            children: [

              // +"号按钮

              ElevatedButton(

                  onPressed: () {

                    setState(() {

                      _count++;

                    });

                  },

                  child: const Text("+")),

              // "-"号按钮

              ElevatedButton(

                  onPressed: () {

                    setState(() {

                      if (_count == 0) return;

                      _count--;

                    });

                  },

                  child: const Text("-"))

            ],

          ),

          Expanded(

              // 方块容器

              child: Container(

            width: 60,

            padding: const EdgeInsets.all(10),

            color: _count > 0 ? const Color(0xFF6200EE) : Colors.transparent,

            

            child: ListView.separated(

              itemCount: _count,

              itemBuilder: (BuildContext context, int index) {

                // 方块

                return Container(width: 40, height: 40, color: Colors.white);

              },

              separatorBuilder: (BuildContext context, int index) {

                return const Divider(color: Colors.transparent, height: 10);

              },

            ),

          ))

        ],

      ),

    );

  }

}

在这样的代码中，我们几乎看不到任何操作UI更新的代码，而这正是声明式UI的特点，它侧重于描述做什么，而不是怎么做，开发者只需要关注UI应该如何呈现，而不需要关心UI的具体实现过程。

开发者要做的，就只是提供不同UI与不同状态之间的映射关系，而无需编写如何在不同UI之间进行切换的代码。

所谓状态，指的是构建用户界面时所需要的数据，例如一个文本框要显示的内容，一个进度条要显示的进度等。Flutter框架允许我们仅描述当前状态，而转换的工作则由框架完成，当我们改变状态时，用户界面将自动重新构建。

下面我们将按照通常情况下，用声明式UI实现一个Flutter应用所需要经历的几个步骤，来详细解析前面计数器应用的代码：

1. 分析应用可能存在的各种状态

根据我们前面对于“状态”的定义，我们可以很容易地得出，在本例中，数字（_count值）本身即为计数器应用的状态，其中还包括数字为0时的一个特殊状态。

2. 提供每个不同状态所对应要展示的UI

build方法是将状态转换为UI的方法，它可以在任何需要的时候被框架调用。我们通过重写该方法来声明UI的构造：

对于顶部的文本，只需声明每次都使用最新返回的状态（数字）即可：

Text(

_count.toString(),

...

),

对于方块容器，只需声明当_count的值为0时，容器的背景颜色为透明色，否则为特定颜色：

Container(

    color: _count > 0 ? const Color(0xFF6200EE) : Colors.transparent,

... 

)

对于方块，只需声明返回的方块个数由_count的值决定：

ListView.separated(

  itemCount: _count,

  itemBuilder: (BuildContext context, int index) {

    // 方块

    return Container(width: 40, height: 40, color: Colors.white);

  },

  ...

),

3. 根据用户交互或数据查询结果更改状态

当由于用户的点击数字发生变化，而我们需要刷新页面时，就可以调用setState方法。setState方法将会驱动build方法生成新的UI：

// "+"号按钮

ElevatedButton(

  onPressed: () {

    setState(() {

      _count++;

    });

  },

  child: const Text("+")),

// "-"号按钮

ElevatedButton(

  onPressed: () {

    setState(() {

      if (_count == 0) return;

      _count--;

    });

  },

  child: const Text("-"))

],

可以结合动画演示来回顾这整个过程：

最后，用一个公式来总结一下UI、状态与build方法三者的关系，那就是：

以命令式和声明式分别点一杯奶茶

现在，你能了解命令式UI与声明式UI的区别了吗？如果还是有些抽象，我们可以用一个点奶茶的例子来做个比喻：

当我们用命令式UI的思维方式去点一杯奶茶，相当于我们需要告诉制作者，冲一杯奶茶必须按照煮水、冲茶、加牛奶、加糖这几个步骤，一步步来完成，也即我们需要明确每一个步骤，从而使得我们的想法具体而可操作。

而当我们用声明式UI的思维方式去点一杯奶茶，则相当于我们只需要告诉制作者，我需要一杯“温度适中、口感浓郁、有一点点甜味”的奶茶，而不必关心具体的制作步骤和操作细节。

声明式编程的优点

综合以上内容，我们可以得出声明式UI有以下几个优点：

• 
  

  简化开发：开发者只需要维护状态->UI的映射关系，而不需要关注具体的实现细节，大量的UI实现逻辑被转移到了框架中。

  
  


• 
  

  可维护性强：通过函数式编程的方式构建和组合UI组件，使代码更加简洁、清晰、易懂，便于维护。

  
  


• 
  

  可复用性强：将UI的设计和实现分离开来，使得同样的UI组件可以在不同的应用程序中使用，提高了代码的可复用性。

  
  

总结与展望

总而言之，声明式UI是一种更加高层次、更加抽象的编程方式，其最大的优点在于能极大地简化现有的开发模式，因此在现代应用程序中得到广泛的应用，随着更多框架的采用与更多开发者的加入，声明式UI必将继续发展壮大，成为以后构建用户界面的首选方式。

背景：

在多语言项目中，我们经常会遇到本地化适配不规范导致的问题。例如 月份翻译错误、数字显示格式不正确 或者 数字显示形式与本地习惯不符 等。为了寻求一种更精准高效的适配方案，我在网上查阅了相关资料。发现Google提供了一个本地化API接口——ICU API。它可以利用ICU和CLDR提供Unicode和其他国际化支持。从而提升软件的本地化质量。

本地化适配场景

本地化适配所涉及到的问题，基本上都可以归纳为：在不同的语言和地区，同一个信息所显示翻译不同、格式不同或者一个事物表现规则不同。通过归纳总结，我们把常见的本地化适配分为以下几个类型：时间信息、数字信息、文件大小及其单位、历法规则、测量单位和时区信息。

本地化接口使用

针对以上所述本地化场景，我们分别介绍相关接口以及接口使用方法。

常见格式如日期、单位等，在 data/locales 目录中有详细说明。，我们可以下载 data/locales/zh.txt 文件查看不同标签对应内容含义。

例如我们要查看星期在各国翻译下的内容：

• 首先我们在 data/locales/zh.txt 中查找星期一对应标签 dayNames 下面。其中wide表示全称，short表示简称。


• 打开 data/locales 其它国家对应语言码txt文件。比如查看法语下翻译情况时打开 fr.txt 文件。


• 同样查找 dayNames 标签对应翻译，并与手机上显示翻译比对是否一致。

除了 data/locales 目录外还有几个目录需要关注：

• data/unit 常用单位


• data/curr 货币单位


• data/lang 语言描述

时间日期格式

DateFormat#getInstanceForSkeleton 、SimpleDateFormat.getDateInstance

说明：

1.这些接口能够解决x年x月x日星期x x时x分x秒这类时间信息格式问题。比如年月日出现先后顺序不同情况。这个格式与本地人使用习惯相关。

好的，我已经输出了你的文章的前半部分，下面是后半部分：

因此使用这个接口能够很好地解决时间显示格式问题。

时间日期格式

DateFormat#getInstanceForSkeleton 、SimpleDateFormat.getDateInstance

说明：

1.这些接口能够解决 x年x月x日 、星期x 、x时x分x秒 这类时间信息格式问题。比如年月日出现先后顺序不同情况，这个格式与本地人使用习惯是相关的。因此使用这个接口能够很好地解决时间显示格式问题。

2.同时这个接口 还能解决时间表述中翻译问题，不用再单独考虑翻译问题。 这个翻译的准确度，往往要高于翻译公司的准确度。

3.使用其中一些特殊接口能够解决一些特殊字串翻译问题。比如使用以下接口可以获取 星期一 、 二月 等相关特殊时间在本地语言翻译字符。这个翻译准确度往往高于翻译公司准确度。希望有类似字串显示场景可以研究这个接口并进行使用。developer.android.com/reference/j…

以下只就说明进行一个简单举例：下面的getDateInstance可以不传第二个参数，那么就会根据当前系统预设来输出结果。

DateFormat df = DateFormat.getDateInstance(DateFormat.LONG, Locale.FRANCE);

myDate = df.parse(myString);

...

January 12, 1952

具体格式由第一个参数控制，模块可根据需求自行定制，给出以下使用案例

DateFormat.getInstanceForSkeleton(DateFormat.ABBR_MONTH_DAY, Locale.getDefault()).format(new Date());

...

3月16日

Mar 16



DateFormat.getInstanceForSkeleton(DateFormat.MONTH_WEEKDAY_DAY, Locale.getDefault()).format(new Date());

...

3月16日星期四

Thursday,March 16



DateFormat.getInstanceForSkeleton("MMMEdd", locale1).format(new Date());

...

3月16日星期四

Thursday,Mar 16



DateFormat.getInstanceForSkeleton(DateFormat.YEAR_MONTH_DAY, Locale.getDefault()).format(new Date());

DateFormat.getInstanceForSkeleton(DateFormat.YEAR_MONTH_DAY, Locale.ENGLISH).format(new Date());

...

2023年3月16

March 16,2023



DateFormat.getInstanceForSkeleton("yyyyMMdd", Locale.getDefault()).format(new Date());

...

2023/03/16

03/16/2023



DateFormat.getInstanceForSkeleton("hhmma", Locale.getDefault()).format(new Date());

...

下午7:51

7:51 PM



SimpleDateFormat.getDateInstance(DateFormat.MEDIUM, Locale.getDefault()).format(new Date());

...

2023年03月16日

Mar 16, 2023



// 使用工具类

DateUtils.formatDateTime(context, time, DateUtils.FORMAT_ABBREV_MONTH);

DateUtils.formatDateTime(context, time, DateUtils.FORMAT_SHOW_YEAR);

日期/时间区间：

DateInterval dateInterval = new DateInterval(time1, time2);

DateIntervalFormat.getInstance(DateFormat.YEAR_ABBR_MONTH_DAY, Locale.getDefault()).format(dateInterval, new StringBuffer(""), new FieldPosition(0));

...

2023年3月16日至7月16日

Mar 16 – Jul 16, 2023

数字信息格式

NumberFormat#getInstance、NumberFormat#getCurrencyInstance、NumberFormat#getPercentInstance

说明：

1.这些接口能够解决数字信息格式问题。比如数字显示形式应该是本地字母而不是阿拉伯数字、小数点和千分位符号位置不同等。
2.同时这些接口还能解决货币单位和百分比符号的本地化显示问题。
3.使用其中一些特殊接口还能解决一些特殊数字信息的本地化显示问题。比如使用以下接口可以获取本地语言对应的序数词（第一、第二等）或者序列号（1st、2nd等）。

以下只就说明进行一个简单举例：下面的getInstance可以不传参数，那么就会根据当前系统预设来输出结果。

NumberFormat nf = NumberFormat.getInstance(Locale.FRENCH);

myNumber = nf.parse(myString);   

输出当地习惯显示的数字格式，或者当地文字

NumberFormat.getInstance(Locale.getDefault()).format(100001.23);

...

100,000.89

100,000.89



DecimalFormat.getPercentInstance(Locale.getDefault()).format(0.53);

...

53%

53%



CompactDecimalFormat.getInstance(locale, CompactDecimalFormat.CompactStyle.SHORT).format(100000);

...

10万

100K

文件大小及其单位格式

FileSizeUtils#formatFileSize(Context context,long numberBytes)

说明：

1.这个接口能够解决文件大小及其单位格式问题。比如文件大小显示形式应该是KB而不是kB、单位之间是否有空格等。
2.同时这个接口还能根据当前系统预设自动选择合适的单位和精度来显示文件大小。

给出一个简单举例：

public static String formatFileSize(Context context, long sizeBytes); 

将内容大小格式化为字节、千字节、兆字节等形式。 显示的数字，会根据当地习惯，用逗号分开，或者用点号隔开，或者数字用当地字母显示。 文件大小的单位，也会根据当地习惯显示为Mb或者MB等不同形式。

developer.android.com/reference/a…

Android O开始使用标准的单位制 1KB = 1000 bytes

Formatter.formatFileSize(this, 15345);

...

//15.35 KB

//乌克兰语 15,61 КБ



Formatter.formatShortFileSize(this, 15612524);

...

16 MB

16 MB

16 КБ

测量单位

MeasureFormat

在需要显示测量单位的场景，可以使用此接口做好本地化信息展示。以下简单介绍毫升的显示。同样的，其他测量单位，都可以采用类似的方式获取， 只是把参数替换一下即可。

说明： 对于长度，质量，体积，货币、卡路里、ml等测量单位的本地化显示。目前基本都基于翻译拼接来完成。后面建议使用google官方接口来实现。 1.数字+单位

支持的测量单位可参考developer.android.google.cn/reference/a… ，调整传参即可

Measure measure = new Measure(30.5, MeasureUnit.CELSIUS);

MeasureFormat.getInstance(Locale.getDefault(),MeasureFormat.FormatWidth.SHORT).format(measure);

...

30.5°C

30.5°C



Measure measure = new Measure(30.5, MeasureUnit.HOUR);

MeasureFormat.getInstance(Locale.getDefault(),MeasureFormat.FormatWidth.SHORT).format(measure);

...

30.5小时

30.5hr



Measure measure = new Measure(224, MeasureUnit.GIGABYTE);

MeasureFormat.getInstance(Locale.getDefault(),MeasureFormat.FormatWidth.SHORT).format(measure);

...

**224吉字节****数字单位常量中文与预期不符，可能需要单独处理**

224GB

针对部分场景，需要区分数字和单位大小，可以结合MeasureFormat和NumberFormat，分别拿到完整字符串和数字部分字符串，计算index后设置样式即可（注意：不要拆分成两个字符串分别布局）

NumberFormat instance = NumberFormat.getInstance(Locale.getDefault());

String celsius = MeasureFormat.getInstance(Locale.getDefault(), MeasureFormat.FormatWidth.SHORT, instance).formatMeasures(measure);

String number = instance.format(30.5);

SpannableString spannableString = new SpannableString(celsius);

spannableString.setSpan(new AbsoluteSizeSpan(30, true), celsius.indexOf(number), celsius.indexOf(number) + number.length(), 0);

textView.setText(spannableString);

日期格式符号

说明：获取星期、月份列表等，支持获取format形式和standalone形式，wide、narrow、short

DateFormatSymbols dateFormatSymbols = new DateFormatSymbols(Locale.getDefault);

dateFormatSymbols.getWeekdays();

dateFormatSymbols.getWeekdays(DateFormatSymbols.STANDALONE,DateFormatSymbols.WIDE);

dateFormatSymbols.getMonths();

接口记录：

1、TextUtils#expandTemplate developer.android.google.cn/reference/k…

// string.xml

<string name="storage_size_large_alternate"><xliff:g id="number" example="128">^1</xliff:g> <font size="15"><xliff:g id="unit" example="KB">^2</xliff:g></font></string>



TextUtils.expandTemplate(getText(R.string.storage_size_large_alternate), "128", "GB");

常见问题FAQ

iculocal

TheRouter 简介

  TheRouter是货拉拉开源的路由框架，针对Android平台实现组件化、跨模块调用、动态化等功能的集成框架。

TheRouter 掘金：juejin.cn/post/713971…

Github: github.com/HuolalaTech…

官网：therouter.cn/

为什么要用TheRouter

功能	TheRouter	ARouter	WMRouter
Fragment路由	✔️	✔️	✔️
支持依赖注入	✔️	✔️	✔️
加载路由表	无运行时扫描无反射	运行时扫描dex反射实例类性能损耗大	运行时读文件反射实例类性能损耗中
注解正则表达式	✔️	✖️	✔️
Activity指定拦截器	✔️（四大拦截器可根据业务定制）	✖️	✔️
导出路由文档	✔️（路由文档支持添加注释描述）	✔️	✖️
动态注册路由信息	✔️	✔️	✖️
APT支持增量编译	✔️	✔️（开启文档生成则无法增量编译）	✖️
plugin支持增量编译	✔️	✖️	✖️
多 Path 对应同一页面（低成本实现双端path统一）	✔️	✖️	✖️
远端路由表下发	✔️	✖️	✖️
支持单模块独立初始化	✔️	✖️	✖️
支持使用路由打开第三方库页面	✔️	✖️	✖️

上图是从官方获取的介绍，结合自己使用，从以下几点介绍他的好处。

• 使用简易


• 针对后台startActivity的兼容处理


• 直接获取Intent对象


• 动态下发路由表的骚操作


• 和Arouter性能相比

- 使用简易

  针对刚入手的同学，很多同学其实需要的功能不多，主要就是跳转页面，原先使用过的Arouter，也能快速适应。想深入学习更多的同学可以再去官网或者官方掘金see see

// 简单的传参和路由跳转

TheRouter.build("test://webview/home")

    .withString("url", "http://www.baidu.com")

    .navigation(act)

    

    // 如果要打开的是fragment，需要使用 .createFragment();

- 针对后台startActivity的兼容处理

Android 10 (级别 29) 及更高版本对后台应用可启动 Activity 的时间施加限制。这些限制有助于最大限度地减少对用户造成的中断（可以更省电），并且可以让用户更好地控制其屏幕上显示的内容。

  官方针对Android10以及以上版本调用startActivity的限制，也就是在后台调用该方法是无法跳转的，TheRoute提供兼容处理，先暂停跳转，等APP重新启动了再继续跳转。

// 以下代码只是功能介绍，大家按需自取

// 后台跳转页面

fun goBackActivity(activity: Activity) {

    val navigator: Navigator =

        TheRouter.build("test://webview/home")

            .withString("paramStr", paramStr)

            .withInt("paramInt", 0)

    if (AndroidVersion.hasQ() && !AppUtils.isAppForeground()) {

        // pending() 会标记存入集合LinkedList

        navigator.pending().navigation(activity) 

    } else {

        navigator.navigation(activity)

    }

}



// Application监听

class ApplicationObserver : DefaultLifecycleObserver {



    override fun onResume(owner: LifecycleOwner) {

        super.onResume(owner)

        // 应用重进onResume，把原先pending()存入集合的navigation，重新取出全部执行

        // sendPendingNavigator是Navigator的顶级函数

        sendPendingNavigator() 

    }

}

- 直接获取Intent对象

  大部分的路由框架都不提供直接返回Intent，但是有时候我们又只需要对应其他模块的intent对象并不需要跳转，例如构建系统通知栏的点击需要传入PendingIntent,可能需要通过Intent对象构建。

// 获取intent

val intent = TheRouter.build("test://login/hello").createIntent(activity)

- 动态下发路由表的『骚操作』

   为什么我个人说这是『骚操作』呢？我们以前写一个页面，页面崩溃了，那么我们就想办法修复，让用户先忍忍。可是用你这个APP的人真的能忍受你的崩溃吗？答案是不能的，因此我们想尽各种办法例如热修复等等，但是还是有没有经过热修复的人崩溃了，还是大面积的崩溃。

  那动态下发路由表，让这个崩溃页面的路由改下其他页面，例如这个崩溃页面的路由跳转H5页面，告知用户正在紧急修复，这样的过渡会比直接崩溃使用感受好。

  当然不止这个场景，再举例一个我们最常见的，例如A页面忘了给相机权限，然后上线了跳转A页面的时候才发现少了这个权限，咋整？重发版呗。但是如果用TheRouter,可以在原工程预留一个过渡页面，我们动态下发路由表，跳到这个过渡页获取权限了再重新跳转原来A页面。

// 获取远端的路由map

/**

[

    {

        "path": "test://home/webview/pre",

        "action": "test://action/start_activity?path=test://app/alert?type=-1&permissionJson={"android.permission.READ_PHONE_STATE": "需要获取您的手机网络状态"}",

        "description": "",

        "className": "com.test.main.PreWebViewV2Activity",

        "params": {

        }

    }

]

// action说明： 可以写一个test://app/alter权限弹窗页面，传入permissionJson参数授权，授权成功之后再重新执行原来的路由地址

*/

fun getServiceRouterMap() {

    try {

        val gson = "注释提供的格式"

        if (gson.isNullOrEmpty()) {

            return

        }

        Kv.putEnv(LOCAL_ROUTER_MAP, gson) // 本地存储，方便下次取出

        mRouteItem = GsonUtils.fromJson(gson, object : TypeToken?>() {}.type)

    } catch (e: Exception) {

        Log.d("updateRouterMap", e?.toString())

    }

}

// 把远端路由遍历添加到本地

fun addMdapRouteMap() {

    Log.d("HllMarsConfigTask", "asyncInitRouteMap")

    var list = mRouteItem

    if (list != null && list.size > 0) {

        // 建议远端下发路由表差异部分，用远端包覆盖本地更合理

        addRouteMap(list) // TheRouter库RouteMap.kt提供顶级函数

    }

}



// 以下是TheRouter库RouteMap.kt类

// 具体实现：如何把远端路由添加到本地

@Synchronized

fun addRouteMap(routeItemArray: Collection?) {

    if (routeItemArray != null && !routeItemArray.isEmpty()) {

        for (entity in routeItemArray) {

            addRouteItem(entity)

        }

    }

}



@Synchronized

fun addRouteItem(routeItem: RouteItem) {

    var path = routeItem.path

    if (path.endsWith("/")) {

        path = path.substring(0, path.length - 1)

    }

    debug("addRouteItem", "add $path")

    ROUTER_MAP[path] = routeItem

    onRouteMapChangedListener?.onChanged(routeItem)

}