在开始前，还是给大家简单介绍一下，以前出现过的一些黑科技：

大概在6年前Github中出现过一个叫MarsDaemon，这个库通过双进程守护的方式实现保活，一时间风头无两。好景不长，进入 Android 8.0时代之后，这个库就废掉了。

最近2年Github上面出来一个Leoric 感兴趣的可以去看一下源码，谁敢用在生产环境呢，也就自己玩玩的才会用吧(不能因为保活而导致手机卡巴斯基)，我没有试过这个，我想说的是：黑科技能黑的了一时，能黑的了一世吗？

没有规矩，不成方圆，要提升产品的存活率，最终还是要落到产品本身上面来，尊重用户，提升用户体验才是正道。

以前我也是深受保活需求的压迫，最近发现QQ群里有人又提到了如何保活，那么我们就来说一说，如何来正确保活App?

Android 8.0之后: 加强了应用后台限制，当时测试过一组数据：

应用处于前台，启动一个前台Service，里面使用JobScheduler启动定时任务(30秒触发一次)，
此时手机锁屏，前10分钟内，定时任务都是正常执行；

大概在12分钟左右，发现应用进程就被kill掉了，解锁屏幕，app也不在前台了；

各大国产手机厂商底层都经过自己魔改，自家都有自己的一套自启动管理，小米手机更乱(当时有个神隐模式的概念，那也是杀后台高手)，只能说当时Android手机各种性能方面都不足，各家都会有自己的一套省电模式，以此来达到省电和提高手机性能，Android 系统变得越来越完善，但是厂商定制的自启动、省电模式还在，所以我们要做保活。

1.Android 8.0之前-常用的保活方案

1.开启一个前台Service

2.Android 6.0+ 忽略电池优化开关(稍后会有代码)

3.无障碍服务(只针对有用这个功能的app，如支付宝语音增强提醒用了它)

2.Android 8.0之后-常用的保活方案

1.开启一个前台Service(可以加上,单独启用的话无法满足保活需求)

2.Android 6.0+ 忽略电池优化开关(稍后会有代码)

3.无障碍服务(只针对有用这个功能的app，如支付宝语音增强提醒用了它)

4.应用自启动权限(最简单的方案是针对不同系统提供教程图片-让用户自己去打开)

5.多任务列表窗口加锁(提供GIF教程图片-让用户自己去打开)

6.多任务列表窗口隐藏App(仅针对有这方面需求的App)

7.应用后台高耗电(仅针对Vivo手机)

3.保活方案实现步骤

(1). 前台Service

//前台服务

class ForegroundCoreService : Service() {

    override fun onBind(intent: Intent?): IBinder? = null

    private var mForegroundNF:ForegroundNF by lazy {

        ForegroundNF(this)

    }

     override fun onCreate() {

        super.onCreate()

        mForegroundNF.startForegroundNotification()

    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {

        if(null == intent){

            //服务被系统kill掉之后重启进来的

            return START_NOT_STICKY

        }

        mForegroundNF.startForegroundNotification()

        return super.onStartCommand(intent, flags, startId)

    }

    override fun onDestroy() {

        mForegroundNF.stopForegroundNotification()

        super.onDestroy()

    }

}

//初始化前台通知，停止前台通知

class ForegroundNF(private val service: ForegroundCoreService) : ContextWrapper(service) {

    companion object {

        private const val START_ID = 101

        private const val CHANNEL_ID = "app_foreground_service"

        private const val CHANNEL_NAME = "前台保活服务"

    }

    private var mNotificationManager: NotificationManager? = null

    

    private var mCompatBuilder:NotificationCompat.Builder?=null

    

    private val compatBuilder: NotificationCompat.Builder?

            get() {

                if (mCompatBuilder == null) {

                    val notificationIntent = Intent(this, MainActivity::class.java)

                    notificationIntent.action = Intent.ACTION_MAIN

                    notificationIntent.addCategory(Intent.CATEGORY_LAUNCHER)

                    notificationIntent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED

                    //动作意图

                    val pendingIntent = PendingIntent.getActivity(

                        this, (Math.random() * 10 + 10).toInt(),

                        notificationIntent, PendingIntent.FLAG_UPDATE_CURRENT

                    )

                    val notificationBuilder: NotificationCompat.Builder = NotificationCompat.Builder(this,CHANNEL_ID)

                    //标题

                    notificationBuilder.setContentTitle(getString(R.string.notification_content))

                    //通知内容

                    notificationBuilder.setContentText(getString(R.string.notification_sub_content))

                    //状态栏显示的小图标

                    notificationBuilder.setSmallIcon(R.mipmap.ic_coolback_launcher)

                    //通知内容打开的意图

                    notificationBuilder.setContentIntent(pendingIntent)

                    mCompatBuilder = notificationBuilder

                }

                return mCompatBuilder

            }

   

    init {

        createNotificationChannel()

    }

    

    //创建通知渠道

    private fun createNotificationChannel() {

        mNotificationManager =

            getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

        //针对8.0+系统

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

            val channel = NotificationChannel(

                CHANNEL_ID,

                CHANNEL_NAME,

                NotificationManager.IMPORTANCE_LOW

            )

            channel.lockscreenVisibility = Notification.VISIBILITY_PUBLIC

            channel.setShowBadge(false)

            mNotificationManager?.createNotificationChannel(channel)

        }

    }

    

    //开启前台通知

    fun startForegroundNotification() {

        service.startForeground(START_ID, compatBuilder?.build())

    }

    

    //停止前台服务并清除通知

    fun stopForegroundNotification() {

        mNotificationManager?.cancelAll()

        service.stopForeground(true)

    }

}

(2).忽略电池优化(Android 6.0+)

1.我们需要在AndroidManifest.xml中声明一下权限

<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />

2.通过Intent来请求忽略电池优化的权限(需要引导用户点击)

//在Activity的onCreate中注册ActivityResult，一定要在onCreate中注册

//监听onActivityForResult回调

mIgnoreBatteryResultContract = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { activityResult ->

            //查询是否开启成功

            if(queryBatteryOptimizeStatus()){

               //忽略电池优化开启成功

            }else{

               //开启失败

            }

        }

通过Intent打开忽略电池优化弹框：

val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS)

intent.data = Uri.parse("package:$packageName")

//启动忽略电池优化，会弹出一个系统的弹框，我们在上面的

launchActivityResult(intent)

查询是否成功开启忽略电池优化开关：

fun Context.queryBatteryOptimizeStatus():Boolean{

    val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager?

    return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {

        powerManager?.isIgnoringBatteryOptimizations(packageName)?:false

    } else {

        true

    }

}

(3).无障碍服务

看官方文档：创建自己的无障碍服务

它也是一个Service，它的优先级比较高，提供界面增强功能，初衷是帮助视觉障碍的用户或者是可能暂时无法与设备进行全面互动的用户完成操作。

可以做很多事情，使用了此Service，在6.0+不需要申请悬浮窗权限，直接使用WindowManager.LayoutParams.TYPE_ACCESSIBILITY_OVERLAY 挺方便的

(仅针对有需要此服务的app，可以开启增强后台保活)

(4).自启动权限(即：白名单管理列表页面)

是系统给用户自己去打开“自启动权限”开关的入口，我们需要针对不同的手机厂商和系统版本，弹出提示引导用户是否前去打开“自启动权限”

有的手机厂商叫：白名单管理，有的叫：自启动权限，两个是一个概念；

点击查看跳转到『手机自启动设置页面』完整代码

(需要注意：如果是代码控制跳转，无法保证永远可以调整，系统升级可能就给你屏蔽了，
最简单的方法是：显示一个如何找到自启动页面的引导图，下面以华为手机为例:)

华为手机-自启动管理

(5).多任务列表窗口加锁

可以针对不同手机厂商，显示引导用户，开启App窗口加锁之后，点击清理加速不会导致应用被kill

华为手机窗口加锁-教程图

(6).多任务列表窗口隐藏App窗口

刚刚上面多任务窗口加锁完，再提示用户去App里面把隐藏App窗口开关打开，这样用户就不会在多任务列表里面把App窗口给手抖划掉

多任务窗口中『隐藏App窗口』，可以用如下代码控制：

(这个也只是针对有这方面需求App提供的一种增强方案罢了：因为隐藏了窗口，用户就不会去想他，不会去手痒去划掉它)

//在多任务列表页面隐藏App窗口

fun hideAppWindow(context: Context,isHide:Boolean){

        try {

            val activityManager: ActivityManager = context.getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager

            //控制App的窗口是否在多任务列表显示

            activityManager.appTasks[0].setExcludeFromRecents(isHide)

        }catch (e:Exception){

            .....

        }

    }

(7).应用后台高耗电(Vivo手机独有)

开启的入口:“设置”>“电池”>“后台高耗电”>“找到xxxApp打开开关”

vivo允许后台高耗电

最后还是奉劝那些，仍然执着于找寻黑科技的开发者，醒醒吧，太阳晒屁股了。

如果说你的App用户群体不是普通用户，是专门给一些玩机大神们用的，都可以root手机的话，那么直接 move 到系统目录 priv/system/app 即可， 即使被用户强杀也会自动重新拉起。

一般手机上的 Android App，主要的交互方式是点击。用户在点击后，App 可能做出在页面内更新 UI、新开一个页面或者发起网络请求等操作。Android 系统本身没有对重复点击做处理，如果用户在短时间内多次点击，则可能出现新开多个页面或者重复发起网络请求等问题。因此，需要对重复点击有影响的地方，增加处理重复点击的代码。

之前的处理方式

之前在项目中使用的是 RxJava 的方案，利用第三方库 RxBinding 实现了防止重复点击：

fun View.onSingleClick(interval: Long = 1000L, listener: (View) -> Unit) {

    RxView.clicks(this)

        .throttleFirst(interval, TimeUnit.MILLISECONDS)

        .subscribe({

            listener.invoke(this)

        }, {

            LogUtil.printStackTrace(it)

        })

}

但是这样有一个问题，比如使用两个手指同时点击两个不同的按钮，按钮的功能都是新开页面，那么有可能会新开两个页面。因为 Rxjava 这种方式是针对单个控件实现防止重复点击，不是多个控件。

现在的处理方式

现在使用的是时间判断，在时间范围内只响应一次点击，通过将上次单击时间保存到 Activity Window 中的 decorView 里，实现一个 Activity 中所有的 View 共用一个上次单击时间。

fun View.onSingleClick(

    interval: Int = SingleClickUtil.singleClickInterval,

    isShareSingleClick: Boolean = true,

    listener: (View) -> Unit

) {

    setOnClickListener {

        val target = if (isShareSingleClick) getActivity(this)?.window?.decorView ?: this else this

        val millis = target.getTag(R.id.single_click_tag_last_single_click_millis) as? Long ?: 0

        if (SystemClock.uptimeMillis() - millis >= interval) {

            target.setTag(

                R.id.single_click_tag_last_single_click_millis, SystemClock.uptimeMillis()

            )

            listener.invoke(this)

        }

    }

}



private fun getActivity(view: View): Activity? {

    var context = view.context

    while (context is ContextWrapper) {

        if (context is Activity) {

            return context

        }

        context = context.baseContext

    }

    return null

}

参数 isShareSingleClick 的默认值为 true，表示该控件和同一个 Activity 中其他控件共用一个上次单击时间，也可以手动改成 false，表示该控件自己独享一个上次单击时间。

mBinding.btn1.onSingleClick {

    // 处理单次点击

}



mBinding.btn2.onSingleClick(interval = 2000, isShareSingleClick = false) {

    // 处理单次点击

}

其他场景处理重复点击

间接设置点击

除了直接在 View 上设置的点击监听外，其他间接设置点击的地方也存在需要处理重复点击的场景，比如说富文本和列表。

为此将判断是否触发单次点击的代码抽离出来，单独作为一个方法：

fun View.onSingleClick(

    interval: Int = SingleClickUtil.singleClickInterval,

    isShareSingleClick: Boolean = true,

    listener: (View) -> Unit

) {

    setOnClickListener { determineTriggerSingleClick(interval, isShareSingleClick, listener) }

}



fun View.determineTriggerSingleClick(

    interval: Int = SingleClickUtil.singleClickInterval,

    isShareSingleClick: Boolean = true,

    listener: (View) -> Unit

) {

    ...

}

直接在点击监听回调中调用 determineTriggerSingleClick 判断是否触发单次点击。下面拿富文本和列表举例。

富文本

继承 ClickableSpan，在 onClick 回调中判断是否触发单次点击：

inline fun SpannableStringBuilder.onSingleClick(

    listener: (View) -> Unit,

    isShareSingleClick: Boolean = true,

    ...

): SpannableStringBuilder = inSpans(

    object : ClickableSpan() {

        override fun onClick(widget: View) {

            widget.determineTriggerSingleClick(interval, isShareSingleClick, listener)

        }

        ...

    },

    builderAction = builderAction

)

这样会有一个问题， onClick 回调中的 widget，就是设置富文本的控件，也就是说如果富文本存在多个单次点击的地方， 就算 isShareSingleClick 值为 false，这些单次点击还是会共用设置富文本控件的上次单击时间。

因此，这里需要特殊处理，在 isShareSingleClick 为 false 的时候，创建一个假的 View 来触发单击事件，这样富文本中多个单次点击 isShareSingleClick 为 false 的地方都有一个自己的假的 View 来独享上次单击时间。

class SingleClickableSpan(

    ...

) : ClickableSpan() {



    private var mFakeView: View? = null



    override fun onClick(widget: View) {

        if (isShareSingleClick) {

            widget

        } else {

            if (mFakeView == null) {

                mFakeView = View(widget.context)

            }

            mFakeView!!

        }.determineTriggerSingleClick(interval, isShareSingleClick, listener)

    }

    ...

}

在设置富文本的地方，使用设置 onSingleClick 实现单次点击：

mBinding.tvText.movementMethod = LinkMovementMethod.getInstance()

mBinding.tvText.highlightColor = Color.TRANSPARENT

mBinding.tvText.text = buildSpannedString {

    append("normalText")

    onSingleClick({

        // 处理单次点击

    }) {

        color(Color.GREEN) { append("clickText") }

    }

}

列表

列表使用 RecyclerView 控件，适配器使用第三方库 BaseRecyclerViewAdapterHelper。

Item 点击：

adapter.setOnItemClickListener { _, view, _ ->

    view.determineTriggerSingleClick {

        // 处理单次点击

    }

}

Item Child 点击：

adapter.addChildClickViewIds(R.id.btn1, R.id.btn2)

adapter.setOnItemChildClickListener { _, view, _ ->

    when (view.id) {

        R.id.btn1 -> {

            // 处理普通点击

        }

        R.id.btn2 -> view.determineTriggerSingleClick {

            // 处理单次点击

        }

    }

}

数据绑定

使用 DataBinding 的时候，有时会在布局文件中直接设置点击事件，于是在 View.onSingleClick 上增加 @BindingAdapte 注解，实现在布局文件中设置单次点击事件，并对代码做出调整，这个时候需要将项目中 listener: (View) -> Unit 替换成 listener: View.OnClickListener。

@BindingAdapter(

    *["singleClickInterval", "isShareSingleClick", "onSingleClick"],

    requireAll = false

)

fun View.onSingleClick(

    interval: Int? = SingleClickUtil.singleClickInterval,

    isShareSingleClick: Boolean? = true,

    listener: View.OnClickListener? = null

) {

    if (listener == null) {

        return

    }



    setOnClickListener {

        determineTriggerSingleClick(

            interval ?: SingleClickUtil.singleClickInterval, isShareSingleClick ?: true, listener

        )

    }

}

在布局文件中设置单次点击：

<androidx.appcompat.widget.AppCompatButton

    android:layout_width="match_parent"

    android:layout_height="wrap_content"

    android:text="@string/btn"

    app:isShareSingleClick="@{false}"

    app:onSingleClick="@{()->viewModel.handleClick()}"

    app:singleClickInterval="@{2000}" />

在代码中处理单次点击：

class YourViewModel : ViewModel() {



    fun handleClick() {

        // 处理单次点击

    }

}

总结

对于直接在 View 上设置点击的地方，如果需要处理重复点击使用 onSingleClick，不需要处理重复点击则使用原来的 setOnClickListener。

对于间接设置点击的地方，如果需要处理重复点击，则使用 determineTriggerSingleClick 判断是否触发单次点击。

项目地址

https://github.com/TaylorKunZhang/single-click，

正在做的这款App是一个打卡软件，旨在让用户能够更好地坚持自己所设置的目标，坚持自己的初心。

由于项目还只是在前期阶段，目前根据需要建立了以下结构： 

参考了部分官方插件以及结合官方getX文档中建议的目录：

暂时没有对state分离出来一层的想法。 以下是各层详细内容：

在使用GetX的时候，往往每次都是用需要手动实例化一个控制器final controller = Get.put(CounterController());，如果每个界面都要实例化一次，有些许麻烦。使用Binding 能解决上述问题，可以在项目初始化时把所有需要进行状态管理的控制器进行统一初始化，直接使用Get.find()找到对应的GetxController使用。

• 可以将路由、状态管理器和依赖管理器完全集成
• 这里介绍三种使用方式，推荐第一种使用getx的命名路由的方式
• 不使用binding，不会对功能有任何的影响。

• 第一种：使用命名路由进行Binding绑定

/// 入口类

class MyApp extends StatelessWidget {

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

  @override

  Widget build(BuildContext context) {

    /// 这里使用 GetMaterialApp

    /// 初始化路由

    return GetMaterialApp(

      initialRoute: RouteConfig.onePage,

      getPages: RouteConfig.getPages,

    );

  }

}



/// 路由配置

class RouteConfig {

  static const String onePage = "/onePage";

  static const String twoPage = "/twoPage";



  static final List<GetPage> getPages = [

    GetPage(

      name: onePage,

      page: () => const OnePage(),

      binding: OnePageBinding(),

    ),

    // GetPage(

    //   name: twoPage,

    //   page: () => TwoPage(),

    //   binding: TwoPageBinding(),

    // ),

  ];

}



/// binding层

class OnePageBinding extends Bindings {

  @override

  void dependencies() {

    Get.lazyPut(() => CounterController());

  }

}



/// 逻辑层

class CounterController extends GetxController{

  var count = 0;

  /// 自增方法

  void increase(){

    count++;

    update();

  }

}

• 第二种：使用initialBinding初始化所有的Binding

/// 入口类

class MyApp extends StatelessWidget {

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

  @override

  Widget build(BuildContext context) {

    return GetMaterialApp(

      /// 初始化所有的Binding

      initialBinding: AllControllerBinding(),

      home: const OnePage(),

    );

  }

}



/// 所有的Binding层

class AllControllerBinding extends Bindings {

  @override

  void dependencies() {

    Get.lazyPut(() => CounterController());

    ///Get.lazyPut(() => OneController());

    ///Get.lazyPut(() => TwoController());

  }

}

自从Jquery被mvvm平替了之后，$.ajax 也被 axios 平替了，在使用这个方式之前，我想大部分的人也想到了去封装一个请求，然后每一次调用去做Get 、Post的请求服务，也有一些人习惯在vue里直接编写 this.$axios.get() ，萝卜青菜各有所爱，没有优劣之分。

灵感来源

写d4axios的灵感来源于open-figen，现在功能还没有那么丰富，但是足以应付多大多数的场景，比如上传、下载、get、post等等请求，配合上ts，可以解决数据类型前后台一致性，数据类型的转换，保证了请求的便利性。让代码专注于数据处理，而非复制粘贴模版代码

别忘了 在 [ts | js]config.json 文件里开启对装饰器的支持。"experimentalDecorators":true

在项目中使用 d4axios

d4axios (Decorators for Axios) 是一款基于axios请求方式的装饰器方法组，可以快速地对服务进行管理和控制，增强前端下服务请求方式，有效降低服务的认知难度，并且在基于ts的情况下可以保证服务的前后台的数据接口一致性

npm i d4axios



yarn add d4axios

一、 引入配置信息

在这里提供了几种配置方式，可以采用原始的axios的配置方法，也可以采用 d4axios 提供的方法

// 在 vue3下我们建议使用 `createService` 

// 其他情况下使用 `serviceConfig`

import { createApp } from 'vue'

import {createService,serviceConfig} from 'd4axios'





createApp(App).use(createService({ ... /* 一些配置信息 */}))

1.1 提供的axios配置项

createService 和 serviceConfig 使用的配置项是一样的，并且完全兼容axios的配置。在现有的项目中改造的话，可以使用：

// 可以直接使用由d4axios提供的服务

createService()



// 可直接传入axios的相关配置，由d4axios自动基于配置相关构建

createService({axios:{ baseURL:"domain.origin" }})



// 可直接传入已经配置好的 `axios` 实例对象

const axios = Axios.create({ /* 你的配置*/ });





createService({axios})

1.2 提供基于请求和相应数据的配置

createService({

    beforeRequest(requestData){

        // form对象会被转为JSON对象的浅拷贝，但是会在该方法执行完后重新转为form对象

        // 你可在请求前追加一些补充的请求参数

        // 比如对请求体进行签名等等

        return requestData

    },

    beforeResponse(responseData){

        // 默认情况下会返回 axios的response.data值，而不会返回response的完整对象

        // 可以修改返回的响应结果

        return responseData

    }

})

1.3 提供快速的axios interceptors 配置

createService({

    interceptors:{

        request：{

            use(AxiosRequestConfig){},

            reject(){}

        },

        response{

            use(AxiosResponse){},

            reject(){}

        }

    }

})

配置完成后，会返回一个axios实例对象，可以继续对axios对象做更多的操作，可以绑定到vue.prototype.$axios下使用

Vue.prototype.$axios = serviceConfig({... /*一些配置*/})

二、创建请求服务

为了更好的组织业务逻辑，d4axios提供了一系列的组织方法，供挑选使用

import {Service,Prefix,Get,Post,Download,Upload,Param,After,Header} from 'd4axios'



@Service("UserService") // 需要提供一个服务名称，该名称将在使用服务的时候被用到

@Prefix("/user") // 可以给当前的服务添加一个请求前缀

export class UserService {



    @Get("/:id") // 等同于 /user/:id

    @After((respData)=>{

            //在输出给最终结果前，可以对结果做一些简单处理

            return respData 

    })

    async getUserById(id:string){

        // 异步请求需要增加 `async` 属性以便语法识别

        // 支持restful的方式

    }





    @Post("/regist")

    @Header({'plantform':'android'}) // 请求前追加一些header参数

    async registUser(form:UserForm){

        // 可以在请求的时候做一些参数修改

        form.nickName = createNickName(form.nickName);



        // return的值是最终请求的参数

        return {

            ...form,

            plant:"IOS"

        };

    }



    @Download("/user/card") // 支持文件下载

    async downloadCard(@Param("id") id:stirng){

        // 当我们的参数较少并且不是一个key-value形式的值时

        // 可以使用@Param辅助，确定传参名称

    }

    

    @Upload("/user/card") // 支持文件上传

    async uploadCard(file:File){

        return {file}

    }



    // 可以定义同步函数，直接做服务计算

    someSyncFunc(){

        return 1+1

    }



    // 我们还可以直接定义非请求函数

    async someFunc(){

        // 所有的当前函数都是可以直接调用的

        return await this.getUserById(this.someSyncFunc());

    }

   

}

三、使用服务

使用服务分为几种方式，第一种是在一个服务中调用另一个服务。第二种是在react或者vue中调用服务，对于这两种有不同的方法，也可以用相同的方法。

3.1 在 vue或者react中使用useService 导入服务

// 在 vue 或者 react中，可以直接使用 useService 导入一个服务对象

import {useService} from 'd4axios'

import SomeService from './some.service'



const someService  = useService(SomeService)



复制代码

3.2 在一个服务中Use调用另一个服务

import {Use} from 'd4axios'

import SomeService from './some.service'

// 也可以直接像上面一样的导入进来是用

const someService  = useService(SomeService)



@Service("MyService")

export class MyService {

    @Use(SomeService)  // use 导入服务

    // 默认的属性名为小写驼峰

    // 用 S<T> 包裹服务名称，这样可以得到相应的async方法的响应类型

    someService !: S<SomeService> 

    

    async someMethod(){

     // 就可以使用了，

      await this.someService.something();

    }

}

四、响应重写

默认情况下，d4axios支持async响应类型值，该值为

 export interface ResponseDataType<T> { }

在项目根路径下定义 d4axios.d.ts文件
然后文件内定义，通过重写该类型，可以得到响应的 response type类型，比如

export interface ResponseDataType<T> { 

    data : T;

    msg:string ;

    code:string ;

}

后即可以得到相关内容的提示信息

五、其他一些基于 Decorators 的操作

5.1 在使用装饰器的class上都可以使用 Use 导入服务 比如：

import {Component,Vue,} from 'vue-class-decorator'

import SomeService from './some.service'



@VueServiceBind(MyService,OtherService) // 只能在vue的这种形式下使用，可以绑定多个值

@Component

export default class MyVueComp extends Vue {



    @Use(SomeService)  // use 导入服务

    // 默认的属性名为小写驼峰

    // 用 S<T> 包裹服务名称，这样可以得到相应的async方法的响应类型

    someService !: S<SomeService> 



    myService !: S<MyService>



    otherService !: S<OtherService>

}

5.2 在一般的vue的服务下可以使用这种 mapService 形式

// 传统的模式下



import { mapService } from 'd4axios';

import MyService from './MyService.service'



export default {

    computed:{

        ...mapService(MyService,OtherService)

    },

    created(){

        this.myService.getName(10086);

    }

如何在浏览器 console 控制台中播放视频？

要实现这个目标，主要涉及到这几个点：

1. 如何获取和解析视频流？


2. 如何在 console 里播放动态内容？


3. 如何在 console 里播放彩色内容？


4. 如何连接视频流和 console？

事实上最后的代码极其简单，我们就一步一步简单讲一下

效果

测试地址：yu-tou.github.io/colors-web/…

如何获取和解析视频流？

这里我们用电脑摄像头捕获视频流，然后获取视频流每一帧的图像数据，作为下一步的输入。

// 捕捉电脑摄像头的视频流

const mediaStream = await navigator.mediaDevices.getUserMedia({

  video: true,

  audio: true,

});

// 创建一个 video 标签

const video = document.createElement("video");

document.body.appendChild(video);



video.onloadedmetadata = function (e) {

  video.play(); // 等摄像头数据加载完成后，开始播放

};

// video 标签播放视频流

video.srcObject = mediaStream;

如何获取每一帧图像的数据？创建一个 canvas 画布，可以将 video 当前的内容绘制到画布上，然后通过 canvas 的方法即可拿到图像的像素数据。

const ctx = canvas.getContext("2d");

canvas.width = width;

canvas.height = height;



ctx.drawImage(video, 0, 0, width, height);

const imageData = ctx.getImageData(0, 0, width, height);

const data = imageData.data;

// imageData 的结构是平铺的，需要自己去学习下

如何在 console 里播放动态内容？

视频每帧的图像内容我们已经可以拿到了，继续下一步，如果需要在 console 中完成播放视频，首先需要能够一帧一帧绘制内容，但是这个好像是不太现实的，console.log 只能输出文本。

回想远古时代，在终端里大家怎么播放视频的？没错，用字符画一帧一帧绘制，连起来不就是动态的视频了。

当然 chrome dev tool 里如果每一帧绘制后都调用 console.clear() 清空重绘，体验不是很好，闪烁会很严重，所以我们采用持续输出的方式绘制，当你停留在 console 的最后的时候，看起来也算是动态内容了。

如何在 console 里播放彩色内容？

console.log 支持部分 css 特性，可以为输出的字符串指定简单的样式，最基本的支持背景色、字体颜色、下划线等，甚至支持 background-image、padding 等特性，利用这些特性，甚至可以插入图片，但是这些特性在不同浏览器的 console 中或多或少有些兼容问题，不过要实现字体着色，或者输出色块（用背景色），问题不大。

我们在此使用 colors-web 来更方便地输出彩色内容到控制台。

这是一个非常方便的库，可以使用链式调用在控制台快速输出彩色内容，并且支持诸多特性，无需自己去了解，直接使用对应的方法即可。

如：

import { logger, colors } from "colors-web";

logger(

  colors().red().fontsize(48).fontfamily("SignPainter").log("hello"),

  colors().white.redBg("hello").linethrough(),

  "world",

  colors().white.padding(2, 5).underline().lightgrey("芋头")

);

相信我不解释，大家也基本理解这些用法，非常简单和自由，而且支持 typescript。

我们这里，用 colors-web 输出色块：

for (let i = 0; i < height; i++) {

  for (let j = 0; j < width; j++) {

    if (i * width + j < data.length) {

      const color = `rgb(${data[(i * width + j) * 4 + 0]},${data[(i * width + j) * 4 + 1]},${

        data[(i * width + j) * 4 + 2]

      })`;

      colors()

        .bg(color)

        .color(color)

        .fontfamily(/Chrome/.test(navigator.userAgent) ? "Courier" : "")

        .log("╳");

    }

  }

}

最终逻辑

最终我将每一帧所有的像素值都转换成一个 colors 的实例，记录到数组之后，最终统一调用 logger 即可完成一帧的渲染。

const frameColors = [];

for (let i = 0; i < height; i++) {

  for (let j = 0; j < width; j++) {

    if (i * width + j < data.length) {

      const color = `rgb(${data[(i * width + j) * 4 + 0]},${data[(i * width + j) * 4 + 1]},${

        data[(i * width + j) * 4 + 2]

      })`;

      frameColors.push(

        colors()

          .bg(color)

          .color(color)

          .fontfamily(/Chrome/.test(navigator.userAgent) ? "Courier" : "")

          .log("╳")

      );

    }

  }

}

// 绘制，colors() 只是在准备数据结构，logger 才是真正的输出

logger(...frameColors);

大公告成啦！

okay, it's me again.

哈哈哈我怎么也没想到，我又会经历多一次三面，这次可以说是被狠狠的按在地上摩擦了，没办法，只能奉行一贯的“技术不够，吹牛来凑”原则

btw 应该看多点别人的面经，而不是自己写面经，当然自己写也可以当作一个很好的复盘

这次是某家准备上市的公司，公司的技术部门也是挺强大的，所以也才会有三面吧可能

其实复盘过程中记的也不太清楚，只能说想起来一点写一点，这里建议将整个面试过程录音，以便做一次彻底的复盘，当然最好还是取得面试官同意才这么做

面试流程：boss直聘聊 -> 发邮件邀约面试 -> 一面技术面 -> 二面技术面 -> 三面HR面 -> 电话沟通薪资和入职事宜 -> offer

一面技术面

1. 
   

   自我介绍

   
   


2. 
   

   一个业务场景，PC端用vue做后台管理系统的时候，一般路由是动态生成的，前端的文件与路由是一一对应的，假如不小心删了一个文件，这个时候就会跳404页面，会有不好的用户体验，怎么做才能比较好的防止跳去404页面？

   
   


3. 
   

   有一个页面，一个绝对够长的背景图，我们知道不给盒子设定高度的情况下默认是100%的高度，盒子高度会被内容所撑开。那么怎么做到第一屏完全显示背景图，第二屏也能继续显示呢？

   
   

   好，来看我的第一个错误回答🤣

   
   

   <style>
   
       * {
   
           margin: 0;
   
           padding: 0;
   
       }
   
       .container {
   
           width: 100%;
   
           height: 100vh;
   
           background-image: url('./assets/images/long.jpeg');
   
       }
   
   </style>
   
   
   
   <body>
   
       <div class="container">
   
         <p>1</p>
   
         这里复制出足够多的<p>1</p>就好，我就不贴出来重复代码占据太大篇幅了
   
       </div>
   
   </body>
   
   
   

   
   

   这是第一屏的效果，嗯很好完全没有问题! 但是当我们鼠标来到第二屏就哦豁了🙈

   
   

然后我的第二个回答是：将图片绝对定位，这样图片就能适应不管多少屏了，但是图片绝对定位的话，没有内容撑开，那么第一屏根本都不会出现背景，所以这样也是不行的😅

答案：将 height: 100vh; 换成 min-height: 100vh;就可以了😂

4. 
   

   我们都知道在谷歌浏览器里面字体的最低像素是 12px ，就算设置font-size: 8px;也会变成 12px ，我现在有一个需求需要 8px 的字体，怎么才能突破 12px 的限制？

   
   

   基本原理是使用css3的 transform: scale(); 属性

   
   

   需求是 8px 的字体，那我们就 font-size: 16px; transform: scale(0.5); 即可

   
   


5. 
   

   讲一下 ES6 的新特性

   
   


6. 
   

   说一些你经常用到的数组的方法

   
   


7. 
   

   前端性能优化

   
   

   传送门：聊一聊前端性能优化

   
   


8. 
   

   原型链

   
   

   传送门：继承与原型链

   
   

   传送门：JavaScript原型系列（三）Function、Object、null等等的关系和鸡蛋问题

   
   


9. 
   

   假设在一个盒子里，里面所有小盒子的宽高都是相等的(PS技术不好，画的不相等)，大盒子刚好放得下7个小盒子，使用css实现下面的布局

   
   

10. 
    

    讲一下微信登录流程

    
    


11. 
    

    怎么给每个请求加上 Authorization token ? (考察封装请求，axios 拦截器)

    
    


12. 
    

    讲一下 vue 的双向数据绑定原理

    
    


13. 
    

    移动端防止重复点击，防抖节流

    
    


14. 
    

    怎么触发BFC，有什么应用场景？

    
    


15. 
    

    Promise有哪几种状态？

    
    


16. 
    

    如果现在有一个任务，让你来做主力开发，架构已经搭好了，UI设计图也已经出完了，那你第一步会做什么？

    
    


17. 
    

    后台管理系统怎么做权限分配？

    
    


18. 
    

    怎么判断一个对象是否为空对象？

    
    


19. 
    

    数字1-50的累加，不用 for 循环，用递归写

    
    

    因为我很抗拒当场写代码，然后满脑子都是1-50的累加为什么不用 for 循环，用 for 循环不是更快吗？为什么要用递归？但是面试官都把纸笔递过来了，没办法也是只能硬着头皮上了，但是这也是很简单的一道题，下面贴出当时手写的代码(是错的)

    
    

        // 这是错的这是错的这是错的
    
        function add(n) {
    
            let sum = 0;
    
            
    
            if (n > 0) {
    
                sum += add(n - 1);
    
            } else {
    
                return sum;
    
            }
    
        }
    
        
    
        // 这是根据上面改进之后的写法
    
        function add(n, sum) {
    
          if (n > 0) {
    
            return add(n - 1, (sum += n));
    
          } else {
    
            return sum;
    
          }
    
        }
    
        
    
        // 当然还有一种更为优雅与简便的写法
    
        function add(n) {
    
          return n === 0 ? 0 : n + add(n - 1);
    
        }
    
        
    
        // 想一行代码搞定的话就是
    
        const add = (n) => (n === 0 ? 0 : n + add(n - 1));
    

    
    


20. 
    

    怎么解决 vuex 里的数据在页面刷新后丢失的问题？

    
    


21. 
    

    说一下 vue 组件通信有几种方式(老生常谈的问题)

    
    


22. 
    

    说一下 vue 和微信小程序各自的生命周期

    
    


23. 
    

    看一下这个 ts 问题

    
    

        let num: string = '1';
    
        转一下数据类型转成 number
    

    
    


24. 
    

    说一下 ts 总共有多少种数据类型

    
    

二面技术面

1. 
   

   封装一个级联组件，讲一下思路

   
   


2. 
   

   封装 v-model

   
   


3. 
   

   POST请求的 Content-Type 有多少种？

   
   


4. 
   

   css flex: 1; 是哪几个属性的组合写法

   
   


5. 
   

   vue provide/inject 的数据不会及时回流到父组件的问题(我记得没错的话好像是这么问的)

   
   


6. 
   

   不用Promise的情况下，怎么实现一个Promise.all()方法

   
   


7. 
   

   [1, 2, 3].map((item, index) => parseInt(item, index))的结果

   
   

   这里考察了两点，1是parseInt()方法的第二个参数有什么作用，2是进制转换的相关知识

   
   


8. 
   

   cookie，sessionStorage，localStorage 3者之间有什么区别？

   
   


9. 
   

   有 http://www.xxx.com (a网站) 和 http://www.api.xxx.com (b网站) 两个网站，在b网站里登录授权拿到了 cookie ，怎么在a网站里拿到这个 cookie ？

   
   


10. 
    

    说一下 forEach, map, for...in, for...of 的区别

    
    


11. 
    

    git fetch和git pull的区别(最后一道题)

    
    

    git pull：相当于是从远程获取最新版本并 merge 到本地

    
    

    git fetch：相当于是从远程获取最新版本到本地，不会自动 merge

    
    

    区别就是会不会自动 merge

    
    

三面HR面

这里就不展开了，HR面差不多都是那些东西

以上

其实一面二面还有很多问题都没有写出来，但是碍于当时也没有录音，只记得这么多

严格来讲，这并不太算是一篇面经，在上面很多都只是抛出了问题，因为技术的原因并没有做出相应的解答，还是有些遗憾的

背景

临近年底，公司还在招人，可筛选的人才真是越来越少，这可能是因为大家都在等年终奖吧。于是在简历筛选时，将学历和年龄都适当的放松了。正因为如此，面试了不少大龄的程序员。

网络上一直有讨论大龄程序员找工作困境的话题，对于我个人来说，是将信将疑的，但作为程序员对自己职业生涯和未来的危机感还是有的。同时，作为技术部门领导，我是不介意年龄比我大，能力比我强的人加入的，只要能把事做好，这都不是事。

随着互联网的发展，大量程序员必然增多，都找不到工作是不可能的。而且中国的未来必然也会像发达国家一样，几十岁甚至一辈子都在写代码，也不是有可能的。

那么，我们担忧的是什么呢？又是什么影响了找工作呢？本文就通过自己亲身面试的几个典型案例来说说，可能样本有些小，仅供参考，不喜勿喷。

大厂与小厂招人的区别

前两天在朋友圈发了一条招人的感慨，关于大厂招人和小公司招人的区别。

大厂：有影响力，有钱，能够吸引了大量的应聘者。因此，也就有了筛选的资格，比如必须985名校毕业，必须35岁以下，不能5年3跳，必须这个……不能那个……当员工不合适时，绩效分给的低点或直接赔钱让其出局。

小公司：没有品牌，资金有限，每一分钱都要精打细算。招聘的人选有限，在这有限的选择范围内，还要考虑成本、能不能用、能不能留住等问题。能力太强，给不起钱，留不住；能力太弱，只会让项目越来越糟糕；所以，最好的选择只能是稍微高于现有团队能力，又不至于轻易跳槽的人。

有了上面的基本前提，再来看看大厂与小厂对待大龄程序员的差别。

对于35岁以后的程序员，有的大厂已经直接卡死，也就别死磕了。另外一些大厂还是开放的，但肯定是有一定的要求的，比如职位必须达到什么等级，能力必须达到什么要求。换句话说，如果你是牛人，其实35岁并不是什么问题，如果不是，那么这个选项几乎不存在。

所以，大厂的选择基本上等于没什么选择。再来看看小公司，小公司追求的核心是性价比，或者直白点说就是能干事且节省成本。另外就是能不能一职多能，能不能带新人，能不能加班……

个人看来，相对于大厂的要求，小公司的要求稍微努力一下还是可以满足的。对于加班这一项，不是所有的公司都有加班文化，也不是所有的公司常年需要加班。

招聘案例

挑选面试中几个比较典型的案例来聊聊，看看对你有什么启发。

案例一

84年的应聘者，自己在简历上填写的是应聘“中高级Java开发”。面试中，各项技能都平平，属于有功能开发经验，但没有深钻技术，没有考虑更好解决方案的状态。明确加班不能超过9点。也有写博客和公众号。9月份离职，目前暂未未找到工作。

就这位应聘者而言：第一，能接受员工比自己年龄大的领导不多，因为担心管不住；第二，技能没有亮点，就像他自己定位的那样，十多年工作经验，只是中高级开发；第三，加班这一项卡的太死，哪家公司上个线不到10点以后了，有突发需求不加个班？

案例二

86年的应聘者，别家公司裁员，推荐过来的简历。十来年工作经验，一直负责一个简单彩会不会是敏感词票业务的开发，中间有几年还没有项目履历。简历上写的功能还是：用户管理、权限管理、XX接口对接。推荐他的老板，给他的定位是中级开发。

这位应聘者，真的是将一年的代码写了十年。上家老板裁员选择了他，定位也只是中级，然后帮忙推荐了他到其他公司。这背后的故事，你仔细品，再仔细品。

案例三

87年的应聘者，学历一般，这两年的工作履历有点糟糕，跳槽的时机选择的也不好。长期从事支付行业，十来年的工作履历中，有七八年在做支付及相关的行业，其中在一家支付公司工作了四年。面试中，特意问了行业中的一些解决方案、技术实现，都没问题。基础知识稍微有点弱，但影响不大。面试过后，发了Offer，其中我还在老板面前帮忙争取了一把。

这位应聘者，虽然在学历，近两年的经历，基础知识上都略有不足。但他的行业经验丰富，给人一种踏实做事的感觉。整体能力恰好符合上面提到的小公司选择标准：比现有团队人能力强，有行业经验，薪资适中，稳定性较好。他的长板完全弥补了短板。

案例四

91年的应聘者，一家小有名气二线互联网公司出来。最近半年未工作，给出的原因是：家中有事，处理了半年，现在决定找工作了。聊半年前做过的项目，基本上记不起逻辑了；聊技术知识，也只能说个大概，但能感觉还是做过一些功能的，但没有深入思考过或没有做过复杂逻辑。

这位应聘者，不确定已经面试多久了，但应该不那么容易找工作。第一，半年未工作，即使有原因，也让人多少有些顾虑；第二，面试前完全没做功课，这不是能力问题，而是态度的问题了。

上面的案例，有成功的也有失败的。总结一下失败的原因，基本上有几点：能力与年龄不匹配、不能加班、家庭影响、没有特长……当然，你如果能看到其他的失败原因，那就更好了。

小结

上面只是最近一段时间面试的几个典型案例，至于你能从中获得什么，能不能提前行动，做好准备。那就是大家自己的事了。当然，还是那句话，样本有些小，但也能说明一些问题。仅个人观点，不抬杠，不喜勿喷。

我也曾为职场的未来担忧，也曾为年龄担忧，但始终未放弃的就是持续学习和思考。多位朋友都曾说过：无论你是否当上领导，是否还在写代码，技术能力都不能丢，你必须是团队中技术最牛的那一个。我一直在努力做到，你呢

早在去年的时候我就提到过使用工厂的方式获取 Adapter 而不是为每个 Adapter 定义一个类文件。这样的好处是，对于不是那么复杂的 Adapter 可以节省大量的代码，提升开发效率和解放双手，同时更好的支持多类型布局效果。

1、Kotlin DSL 和 Adapter 工厂方法

可以把 Kotlin DSL 当作构建者使用。这里有一篇不错的文章，想了解的可以阅读下，

http://www.ximedes.com/2020-04-21/…

Kotlin DSL 是拓展函数的延申，比如我们常用的 with 等函数就是函数的拓展，

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

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return receiver.block()

}

这里是泛型 T 的拓展。这里的 T 可以类比到 Java 构建者模式中的 Builder，通过方法接收外部参数之后调用 build() 方法创建一个最终的对象即可。

对于 Adapter 工厂方法，之前我是通过如下方式使用的，

fun <T> getAdapter(

    @LayoutRes itemLayout:Int,

    converter: (helper: BaseViewHolder, item: T) -> Unit,

    data: List<T>

): Adapter<T> = Adapter(itemLayout, converter, data)



class Adapter<T>(

    @LayoutRes private val layout: Int,

    private val converter: (helper: BaseViewHolder, item: T) -> Unit,

    val list: List<T>

): BaseQuickAdapter<T, BaseViewHolder>(layout, list) {

    override fun convert(helper: BaseViewHolder, item: T) {

        converter(helper, item)

    }

}

也就是每次想要得到 Adapter 的时候只要调用 getAdapter() 方法即可。这种封装方式比较简陋，支持的功能有限。后来慢慢采用了 Kotlin DSL 之后，我封装了 Kotlin DSL 风格的工厂方法。采用 Kotlin DSL 风格之后更加优雅和方便快捷，同时更好的支持多类型布局效果。

2、使用

2.1 引入依赖

首先，该项目依赖于 BRVAH，所以，你需要引入该库之后才可以使用。BRVAH 可以说是目前开源的最好用的 Adapter，我们没必要再另起炉灶自己再造轮子。这个框架设计最好地方在于通过 SpareArray 收集了 ViewHolder 控件，从而避免了自定义 ViewHolder，这是我们框架设计的基础思想。

该项目已经上传到了 MavenCentral，你需要先在项目中引入该仓库，

allprojects {

    repositories {

        mavenCentral()

    }

}

然后在项目中添加如下依赖，

implementation "com.github.Shouheng88:xadapter:${latest_version}"

2.2 使用 Adapter 工厂方法

使用 xAdapter 之后，当你需要定义一个 Adapter 的时候，你无需单独创建一个类文件，只需要通过 createAdapter() 方法获取一个 Adapter，

adapter = createAdapter {

    withType(Item::class.java, R.layout.item_eyepetizer_home) {

        // Bind data with viewholder.

        onBind { helper, item ->

            helper.setText(R.id.tv_title, item.data.title)

            helper.setText(R.id.tv_sub_title, item.data.author?.name + " | " + item.data.category)

            helper.loadCover(requireContext(), R.id.iv_cover, item.data.cover?.homepage, R.drawable.recommend_summary_card_bg_unlike)

            helper.loadRoundImage(requireContext(), R.id.iv_author, item.data.author?.icon, R.mipmap.eyepetizer, 20f.dp2px())

        }

        // Item level click and long click events.

        onItemClick { _, _, position ->

            adapter?.getItem(position)?.let {

                toast("Clicked item: " + it.data.title)

            }

        }

    }

}

在这种新的调用方式中，你需要通过 withType() 方法指定数据类型及其对应的布局文件，然后在 onBind() 方法中即可实现数据到 ViewHolder 的绑定操作。这里的 onBind() 方法的使用与 BRVAH 中的 convert() 方法使用一致，可以通过阅读该库了解如何使用。总之，xAapter 在 BRVAH 的基础上做了二次封装，可以说，比简单更简单。

xAdapter 支持为每个 ViewHolder 绑定点击和长按事件，同时也支持为 ViewHolder 上的某个单独的 View 添加点击和长按事件。使用方式如上所示，只需要添加 onItemClick() 方法并实现自己的逻辑即可。其他的点击事件可以参考项目的示例代码。

效果，

2.3 使用多类型 Adapter

多类型 Adapter 的使用方式非常简单，类似于上面的调用方式，只需要在 createAdapter() 内再添加一个 withType() 方法即可。下面是一个写起来可能相当复杂的 Adapter，但是采用了 xAdpater 的调用方式之后，一切变得非常简单，

private fun createAdapter() {

    adapter = createAdapter {

        withType(MultiTypeDataGridStyle::class.java, R.layout.item_list) {

            onBind { helper, item ->

                val rv = helper.getView<RecyclerView>(R.id.rv)

                rv.layoutManager = GridLayoutManager(context, 3)

                val adapter = createSubAdapter(R.layout.item_home_page_data_module_1, 1)

                rv.adapter = adapter

                adapter.setNewData(item.items)

            }

        }

        withType(MultiTypeDataListStyle1::class.java, R.layout.item_home_page_data_module_2) {

            onBind { helper, item ->

                converter.invoke(helper, item)

            }

            onItemClick { _, _, position ->

                (adapter?.getItem(position) as? MultiTypeDataListStyle1)?.let {

                    toast("Clicked style[2] item: " + it.item.data.title)

                }

            }

        }

        withType(MultiTypeDataListStyle2::class.java, R.layout.item_list) {

            onBind { helper, item ->

                val rv = helper.getView<RecyclerView>(R.id.rv)

                rv.layoutManager = LinearLayoutManager(context, RecyclerView.HORIZONTAL, false)

                val adapter = createSubAdapter(R.layout.item_home_page_data_module_4, 3)

                rv.adapter = adapter

                adapter.setNewData(item.items)

            }

        }

        withType(MultiTypeDataListStyle3::class.java, R.layout.item_home_page_data_module_3) {

            onBind { helper, item ->

                converter.invoke(helper, item)

            }

            onItemClick { _, _, position ->

                (adapter?.getItem(position) as? MultiTypeDataListStyle3)?.let {

                    toast("Clicked style[4] item: " + it.item.data.title)

                }

            }

        }

    }

}

xAdapter 对多类型布局方式的支持是在 BRVAH 之上进行的改造，在这种封装方式中，数据类无需实现任何类和接口。Adpater 内部通过 Class 区分各个 ViewHolder.

效果，

总结

相对于为各种类型的数据定义 Adapter 的使用方式，以上封装方式的优势是：

1. 借助 BRVAH 的优势，封装了大量的方法，进一步简化了 Adapter 的使用；


2. 通过工厂和 DSL 封装，简化了调用 Adapter 的方式，你无需为数据类型定义 Adapter 文件，减少了项目中需要维护的代码和类文件数量；


3. 通过以上封装，使用 Adapter 更加简洁，节省了大量的代码，提升开发效率和解放双手；


4. 自由地在单一类型布局和多类型布局之间进行切换，但是少了没必要的工厂方法。

当有更加简洁的使用方式的时候，继续采用复杂的调用方式无异于抱残守缺，对于程序员而言，做这种重复而没有太大价值的工作，付出再多的汗水都不值得同情。以上是部分功能和代码的展示，可以通过阅读源码了解更多。后续我参考其他优秀的库的设计思想，支持更多 Adapter 特性的封装来实现快速调用。

项目已开源，感兴趣的可以直接阅读项目源码，源码地址：github.com/Shouheng88/…

网上最近看到了个摸鱼应用，还挺好玩的。

我打算自己用flutter写了一个

之前我有用flutter制作过mobile应用，但是没有在desktop尝试过；毕竟2.0大更新，我这里就在这试手一下，并说说flutter的体验.

当前flutter环境 2.8

增加flutter desktop支持 (默认项目之存在ios，android项目包)

flutter config --enable-<platform>-desktop

我这里是mac，因此platform=macos，详细看flutter官网

代码十分简单，UI部分就不讲了

在摸鱼界面，我是用了 Bloc 做倒计时计算逻辑，默认摸鱼时长15分钟

 MoYuBloc() : super(MoyuInit()) {

    on(_handleMoyuStart);

    on(_handleUpdateProgress);

    on(_handleMoyuEnd);

  }

摸鱼开始事件处理

// handle moyu start action

  FutureOr<void> _handleMoyuStart(

      MoyuStarted event, Emitter<MoyuState> emit) async {

    if (_timer != null && _timer!.isActive) {

      _timer?.cancel();

    }

 

    final totalTime = event.time;

    int progressTime = state is MoyuIng ? (state as MoyuIng).progressTime : 0;

 

    _timer = Timer.periodic(const Duration(seconds: 1), (timer) {

      add(MoyuProgressUpdated(totalTime, ++progressTime));

 

      if (progressTime >= totalTime) {

        timer.cancel();

        add(MoyuEnded());

      }

    });

    emit(MoyuIng(progress: 0, progressTime: 0));

  }

摸鱼进度更新

// handle clock update

  FutureOr<void> _handleUpdateProgress(

      MoyuProgressUpdated event, Emitter<MoyuState> emit) async {

    final totalTime = event.totalTime;

    final progressTime = event.progressTime;

    emit(

      MoyuIng(progress: progressTime / totalTime, progressTime: progressTime),

    );

  }

摸鱼结束，释放结束事件

// handle clock end

  FutureOr<void> _handleMoyuEnd(

      MoyuEnded event, Emitter<MoyuState> emit) async {

    emit(MoyuFinish());

  }

总结3个event (摸鱼开始，进程更新，摸鱼结束）



abstract class MoyuEvent {}

 

class MoyuStarted extends MoyuEvent {

  final int time;

  final System os;

 

  MoyuStarted({required this.time, required this.os});

}

 

class MoyuProgressUpdated extends MoyuEvent {

  final int totalTime;

  final int progressTime;

 

  MoyuProgressUpdated(this.totalTime, this.progressTime);

}

 

class MoyuEnded extends MoyuEvent {

  MoyuEnded();

}

其中3个state （摸鱼初始，正在摸鱼，摸鱼结束）

abstract class MoyuState {}

 

class MoyuInit extends MoyuState {}

 

class MoyuIng extends MoyuState {

  final double progress;

  final int progressTime;

 

  MoyuIng({required this.progress, required this.progressTime});

}

 

class MoyuFinish extends MoyuState {}

启动摸鱼使用, 记录总时长和消耗时间，计算进度百分比，更新UI进度条

下面是界面更新逻辑

BlocConsumer<MoYuBloc, MoyuState>(

          builder: (context, state) {

            if (state is MoyuIng) {

              final progress = state.progress;

 

              return _moyuIngView(progress);

            } else if (state is MoyuFinish) {

              return _replayView();

            }

            return const SizedBox();

          },

          listener: (context, state) {},

          listenWhen: (pre, cur) => pre != cur,

        ),

很简单 最重要的是进度状态，其次结束后是否重新摸鱼按钮

构建运行flutter应用

flutter run -d macos 

最后结果展示

总结下flutter desktop使用

1. 简单上手，按着官网走基本没问题，基本上没踩上什么雷，可能项目比较简单
2. 构建流程简单，hot reload强大
3. 性能强大，启动速度很快，并且界面无顿挫感

比较遗憾的事desktop电脑构建系统独立，mac环境下无法构建windows应用，有点小遗憾.

项目完全开源 可以前往GitHub查看 不要忘点个star😊

github.com/lau1944/moy…

前言

我们通常会用 toast（也叫吐司）来显示提示信息，例如网络请求错误，校验错误等等。大多数 App的 toast 都很简单，简单的半透明黑底加上白色文字草草了事，比如下面这种.

说实话，这种toast 的体验很糟糕。假设是新手用户，他们并不知道 toast 从哪里出来，等出现错误的时候，闪现出来的时候，可能还没抓住内容的重点就消失了（尤其是想截屏抓错误的时候，更抓狂）。这是因为一个是这种 toast 一般比较小，而是动效非常简单，用来提醒其实并不是特别好。怎么破？本篇来给大家介绍一个非常有趣的 toast 组件 —— motion_toast。

motion_toast 介绍

从名字就知道，motion_toast 是支持动效的，除此之外，它的颜值还很高，下面是它的一个示例动图，仔细看那个小闹钟图标，是在跳动的哦。这种提醒效果比起常用的 toast 来说醒目多了，也更有趣味性。

下面我们看看 motion_toast 的特性：

• 可以通过动画图标实现动效；


• 内置了成功、警告、错误、提醒和删除类型；


• 支持自定义；


• 支持不同的主题色；


• 支持 null safety；


• 心跳动画效果；


• 完全自定义的文本内容；


• 内置动画效果；


• 支持自定义布局（LTR 和 RTL）；


• 自定义持续时长；


• 自定义展现位置（居中，底部或顶部）；


• 支持长文本显示；


• 自定义背景样式；


• 自定义消失形式。

可以看到，除了能够开箱即用之外，我们还可以通过自定义来丰富 toast 的样式，使之更有趣。

示例

介绍完了，我们来一些典型的示例吧，首先在 pubspec.yaml 中添加依赖motion_toast: ^2.0.0（最低Dart版本需要2.12）。

最简单用法

只需要一行代码搞定！其他参数在 success 的命名构造方法中默认了，因此使用非常简单。

MotionToast.success(description: '操作成功！').show(context);

其他内置的提醒

内置的提醒也支持我们修改默认参数进行样式调整，如标题、位置、宽度、显示位置、动画曲线等等。

// 错误提示

MotionToast.error(

  description: '发生错误！',

  width: 300,

  position: MOTION_TOAST_POSITION.center,

).show(context);



//删除提示

MotionToast.delete(

  description: '已成功删除',

  position: MOTION_TOAST_POSITION.bottom,

  animationType: ANIMATION.fromLeft,

  animationCurve: Curves.bounceIn,

).show(context);



// 信息提醒（带标题）

 MotionToast.info(

  description: '这是一条提醒，可能会有很多行。toast 会自动调整高度显示',

  title: '提醒',

  titleStyle: TextStyle(fontWeight: FontWeight.bold),

  position: MOTION_TOAST_POSITION.bottom,

  animationType: ANIMATION.fromBottom,

  animationCurve: Curves.linear,

  dismissable: true,

).show(context);

不过需要注意的是，一个是 dismissable 参数只对显示位置在底部的有用，当在底部且dismissable为 true 时，点击空白处可以让 toast 提前消失。另外就是显示位置 position 和 animationType 是存在某些互斥关系的。从源码可以看到底部显示的时候，animationType不能是 fromTop，顶部显示的时候 animationType 不能是 fromBottom。

void _assertValidValues() {

  assert(

    (position == MOTION_TOAST_POSITION.bottom &&

            animationType != ANIMATION.fromTop) ||

        (position == MOTION_TOAST_POSITION.top &&

            animationType != ANIMATION.fromBottom) ||

        (position == MOTION_TOAST_POSITION.center),

  );

}

自定义 toast

自定义其实就是使用 MotionToast 构建一个实例，其中，description，icon 和 primaryColor参数是必传的。自定义的参数很多，使用的时候建议看一下源码注释。

MotionToast(

  description: '这是自定义 toast',

  icon: Icons.flag,

  primaryColor: Colors.blue,

  secondaryColor: Colors.green[300],

  descriptionStyle: TextStyle(

    color: Colors.white,

  ),

  position: MOTION_TOAST_POSITION.center,

  animationType: ANIMATION.fromRight,

  animationCurve: Curves.easeIn,

).show(context);

下面对自定义的一些参数做一下解释：

• icon：图标，IconData 类，可以使用系统字体图标；


• primaryColor：主颜色，也就是大的背景底色；


• secondaryColor：辅助色，也就是图标和旁边的竖条的颜色；


• descriptionStyle：toast 文字的字体样式；


• title：标题文字；


• titleStyle：标题文字样式；


• toastDuration：显示时长；


• backgroundType：背景类型，枚举值，共三个可选值，transparent，solid和 lighter，默认是 lighter。lighter其实就是加了一层白色底色，然后再将原先的背景色（主色调）加上一定的透明度叠加到上面，所以看起来会泛白。


• onClose：关闭时回调，可以用于出现多个错误时依次展示，或者是关闭后触发某些动作，如返回上一页。

总结

看完之后，是不是觉得以前的 toast 太丑了？用 motion_toast来一个更有趣的吧。另外，整个 motion_toast 的源码并不多，有兴趣的可以读读源码，了解一下toast 的实现也是不错的。

前言

鸿蒙系统 （HarmonyOS）是华为推出的一款面向未来、面向全场景的分布式操作系统。在传统单设备系统能力的基础上，鸿蒙提出了基于同一套系统能力、适配多种终端形态的分布式理念。自 2020 年 9 月 HarmonyOS 2.0 发布以来，华为加快了鸿蒙系统大规模落地的步伐，预计 2021 年底，鸿蒙系统会覆盖包括手机、平板、智能穿戴、智慧屏、车机在内数亿台终端设备。对移动应用而言，新的系统理念、新的交互形式，也意味着新的机遇。如果能够利用好鸿蒙的开发生态及其特性能力，可以让应用覆盖更多的交互场景和设备类型，从而带来新的增长点。

与面临的机遇相比，适配鸿蒙系统带来的挑战同样巨大。当前手机端，尽管鸿蒙系统仍然支持安卓 APK 安装及运行，但长期来看，华为势必会抛弃 AOSP，逐步发展出自己的生态，这意味着现有安卓应用在鸿蒙设备上将会逐渐变成“二等公民”。然而，如果在 iOS 及 Android 之外再重新开发和维护一套鸿蒙应用，在如今业界越来越注重开发迭代效率的环境下，所带来的开发成本也是难以估量的。因此，通过打造一套合适的跨端框架，以相对低的成本移植应用到鸿蒙平台，并利用好该系统的特性能力，就成为了一个非常重要的选项。

在现有的众多跨端框架当中，Flutter 以其自渲染能力带来的多端高度一致性，在新系统的适配上有着突出的优势。虽然Flutter 官方并没有适配鸿蒙的计划，但经过一段时间的探索和实践，美团外卖 MTFlutter 团队成功实现了 Flutter 对于鸿蒙系统的原生支持。

这里也要提前说明一下，因为鸿蒙系统目前还处于Beta版本，所以这套适配方案还没有在实际业务中上线，属于技术层面比较前期的探索。接下来本文会通过原理和部分实现细节的介绍，分享我们在移植和开发过程中的一些经验。希望能对大家有所启发或者帮助。

背景知识和基础概念介绍

在适配开始之前，我们要明确好先做哪些事情。先来回顾一下 Flutter 的三层结构：

在 Flutter 的架构设计中，最上层为框架层，使用 Dart 语言开发，面向 Flutter 业务的开发者；中间层为引擎层，使用 C/C++ 开发，实现了 Flutter 的渲染管线和 Dart 运行时等基础能力；最下层为嵌入层，负责与平台相关的能力实现。显然我们要做的是将嵌入层移植到鸿蒙上，确切地说，我们要通过鸿蒙原生提供的平台能力，重新实现一遍 Flutter 嵌入层。

对于 Flutter 嵌入层的适配，Flutter 官方有一份不算详细的指南，实际操作起来成本很高。由于鸿蒙的业务开发语言仍然可用 Java，在很多基础概念上与 Android 也有相似之处（如下表所示），我们可以从 Android 的实现入手，完成对鸿蒙的移植。

Flutter 在鸿蒙上的适配

如前文所述，要完成 Flutter 在新系统上的移植，我们需要完整实现 Flutter 嵌入层要求的所有子模块，而从能力支持角度，渲染、交互以及其他必要的原生平台能力是保证 Flutter 应用能够运行起来的最基本的要素，需要优先支持。接下来会依次进行介绍。

1. 渲染流程打通

我们再来回顾一下 Flutter 的图像渲染流程。如图所示，设备发起垂直同步（VSync）信号之后，先经过 UI 线程的渲染管线（Animate/Build/Layout/Paint），再经过 Raster 线程的组合和栅格化，最终通过 OpenGL 或 Vulkan 将图像上屏。这个流程的大部分工作都由框架层和引擎层完成，对于鸿蒙的适配，我们主要关注的是与设备自身能力相关的问题，即：

(1) 如何监听设备的 VSync 信号并通知 Flutter 引擎？
(2) OpenGL/Vulkan 用于上屏的窗口对象从何而来？

VSync 信号的监听及传递

在 Flutter 引擎的 Android 实现中，设备的 VSync 信号通过 Choreographer 触发，它产生及消费流程如下图所示：

Flutter 框架注册 VSync 回调之后，通过 C++ 侧的 VsyncWaiter 类等待 VSync 信号，后者通过 JNI 等一系列调用，最终 Java 侧的 VsyncWaiter 类调用 Android SDK 的 Choreographer.postFrameCallback 方法，再通过 JNI 一层层传回 Flutter 引擎消费掉此回调。Java 侧的 VsyncWaiter 核心代码如下：

@Override

public void asyncWaitForVsync(long cookie) {

  Choreographer.getInstance()

      .postFrameCallback(

        new Choreographer.FrameCallback() {

          @Override

          public void doFrame(long frameTimeNanos) {

            float fps = windowManager.getDefaultDisplay().getRefreshRate();

            long refreshPeriodNanos = (long) (1000000000.0 / fps);

            FlutterJNI.nativeOnVsync(

              frameTimeNanos, frameTimeNanos + refreshPeriodNanos, cookie);

          }

        });

}

在整个流程中，除了来自 Android SDK 的 Choreographer 以外，大多数逻辑几乎都由 C++ 和 Java 的基础 SDK 实现，可以直接在鸿蒙上复用，问题是鸿蒙目前的 API 文档中尚没有开放类似 Choreographer 的能力。所以现阶段我们可以借用鸿蒙提供的类似 iOS Grand Central Dispatch 的线程 API，模拟出 VSync 的信号触发与回调：

@Override

public void asyncWaitForVsync(long cookie) {

  // 模拟每秒 60 帧的屏幕刷新间隔：向主线程发送一个异步任务, 16ms 后调用

  applicationContext.getUITaskDispatcher().delayDispatch(() -> {

    float fps = 60; // 设备刷新帧率，HarmonyOS 未暴露获取帧率 API，先写死 60 帧

    long refreshPeriodNanos = (long) (1000000000.0 / fps);

    long frameTimeNanos = System.nanoTime();

    FlutterJNI.nativeOnVsync(frameTimeNanos, frameTimeNanos + refreshPeriodNanos, cookie);

  }, 16);

};

渲染窗口的构建及传递

在这一部分，我们需要在鸿蒙系统上构建平台容器，为 Flutter 引擎的图形渲染提供用于上屏的窗口对象。同样，我们参考 Flutter for Android 的实现，看一下 Android 系统是怎么做的：

Flutter 在 Android 上支持 Vulkan 和 OpenGL 两种渲染引擎，篇幅原因我们只关注 OpenGL。抛开复杂的注册及调用细节，本质上整个流程主要做了三件事：

1. 创建了一个视图对象，提供可用于直接绘制的 Surface，将它通过 JNI 传递给原生侧；


2. 在原生侧获取 Surface 关联的本地窗口对象，并交给 Flutter 的平台容器；


3. 将本地窗口对象转换为 OpenGL ES 可识别的绘图表面（EGLSurface），用于 Flutter 引擎的渲染上屏。

接下来我们用鸿蒙提供的平台能力实现这三点。

a. 可用于直接绘制的视图对象

鸿蒙系统的 UI 框架提供了很多常用视图组件（Component），比如按钮、文字、图片、列表等，但我们需要抛开这些上层组件，获得直接绘制的能力。借助官方 媒体播放器开发指导 文档，可以发现鸿蒙提供了 SurfaceProvider 类，它管理的 Surface 对象可以用于视频解码后的展示。而 Flutter 渲染与视频上屏从原理上是类似的，因此我们可以借用 SurfaceProvider 实现 Surface 的管理和创建：

// 创建一个用于管理 Surface 的容器组件

SurfaceProvider surfaceProvider = new SurfaceProvider(context);

// 注册视图创建回调

surfaceProvider.getSurfaceOps().get().addCallback(surfaceCallback);



// ... 在 surfaceCallback 中

@Override

public void surfaceCreated(SurfaceOps surfaceOps) {

  Surface surface = surfaceOps.getSurface();

  // ...将 surface 通过 JNI 交给 Native 侧

  FlutterJNI.onSurfaceCreated(surface);

}

b. 与 Surface 关联的本地窗口对象

鸿蒙目前开放的 Native API 并不多，在官方文档中我们可以比较容易地找到 Native_layer API。根据文档的说明，Native API 中的 NativeLayer 对象刚好对应了 Java 侧的 Surface 类，借助 GetNativeLayer 方法，我们实现了两者之间的转化：

// platform_view_android_jni_impl.cc

static void SurfaceCreated(JNIEnv* env, jobject jcaller, jlong shell_holder, jobject jsurface) {

  fml::jni::ScopedJavaLocalFrame scoped_local_reference_frame(env);

  // 通过鸿蒙 Native API 获取本地窗口对象 NativeLayer

  auto window = fml::MakeRefCounted(

      GetNativeLayer(env, jsurface));

  ANDROID_SHELL_HOLDER->GetPlatformView()->NotifyCreated(std::move(window));

}

c. 与本地窗口对象关联的 EGLSurface

在 Android 的 AOSP 实现中，EGLSurface 可通过 EGL 库的 eglCreateWindowSurface 方法从本地窗口对象 ANativeWindow 创建而来。对于鸿蒙而言，虽然我们没有从公开文档找到类似的说明，但是 鸿蒙标准库 默认支持了 OpenGL ES，而且鸿蒙 SDK 中也附带了 EGL 相关的库及头文件，我们有理由相信在鸿蒙系统上，EGLSurface 也可以通过此方法从前一步生成的 NativeLayer 转化而来，在之后的验证中我们也确认了这一点：

// window->handle() 即为之前得到的 NativeLayer

EGLSurface surface = eglCreateWindowSurface(

      display, config_, reinterpret_cast(window->handle()),

      attribs);

//...交给 Flutter 渲染管线

2. 交互能力实现

交互能力是支撑 Flutter 应用能够正常运行的另一个基本要求。在 Flutter 中，交互包含了各种触摸事件、鼠标事件、键盘录入事件的传递及消费。以触摸事件为例，Flutter 事件传递的整个流程如下图所示：

iOS/Android 的原生容器通过触摸事件的回调 API 接收到事件之后，会将其打包传递至引擎层，后者将事件传发给 Flutter 框架层，并完成事件的消费、分发和逻辑处理。同样，整个流程的大部分工作已经由 Flutter 统一，我们要做的仅仅是在原生容器上监听用户的输入，并封装成指定格式交给引擎层而已。

在鸿蒙系统上，我们可以借助平台提供的 多模输入 API，实现多种类型事件的监听：

flutterComponent.setTouchEventListener(touchEventListener); // 触摸及鼠标事件

flutterComponent.setKeyEventListener(keyEventListener); // 键盘录入事件

flutterComponent.setSpeechEventListener(speechEventListener); // 语音录入事件

对于事件的封装处理，可以复用 Android 已有逻辑，只需要关注鸿蒙与 Android 在事件处理上的对应关系即可，比如触摸事件的部分对应关系：

3. 其他必要的平台能力

为了保证 Flutter 应用能够正常运行，除了最基本的渲染和交互外，我们的嵌入层还要提供资源管理、事件循环、生命周期同步等平台能力。对于这些能力 Flutter 大多都在嵌入层的公共部分有抽象类声明，只需要使用鸿蒙 API 重新实现一遍即可。

比如资源管理，引擎提供了 AssetResolver 声明，我们可以使用鸿蒙 Rawfile API 来实现：

class HAPAssetMapping : public fml::Mapping {

 public:

  HAPAssetMapping(RawFile* asset) : asset_(asset) {}

  ~HAPAssetMapping() override { CloseRawFile(asset_); }



  size_t GetSize() const override { return GetRawFileSize(asset_); }



  const uint8_t* GetMapping() const override {

    return reinterpret_cast(GetRawFileBuffer(asset_));

  }



 private:

  RawFile* const asset_;



  FML_DISALLOW_COPY_AND_ASSIGN(HAPAssetMapping);

};

对于事件循环，引擎提供了 MessageLoopImpl 抽象类，我们可以使用鸿蒙 Native_EventHandler API 实现：

// runner_ 为鸿蒙 EventRunnerNativeImplement 的实例

void MessageLoopHarmony::Run() {

  FML_DCHECK(runner_ == GetEventRunnerNativeObjForThread());

  int result = ::EventRunnerRun(runner_);

  FML_DCHECK(result == 0);

}



void MessageLoopHarmony::Terminate() {

  int result = ::EventRunnerStop(runner_);

  FML_DCHECK(result == 0);

}

对于生命周期的同步，鸿蒙的 Page Ability 提供了完整的生命周期回调（如下图所示），我们只需要在对应的时机将状态上报给引擎即可。

当以上这些能力都准备好之后，我们就可以成功把 Flutter 应用跑起来了。以下是通过 DevEco Studio 运行官方 flutter gallery 应用的截图，截图中 Flutter 引擎已经使用鸿蒙系统的平台能力进行了重写：

借由鸿蒙的多设备支持能力，此应用甚至可在 TV、车机、手表、平板等设备上运行：

总结和展望

通过上述的构建和适配工作，我们以极小的开发成本实现了 Flutter 在鸿蒙系统上的移植，基于 Flutter 开发的上层业务几乎不做任何修改就可以在鸿蒙系统上原生运行，为迎接鸿蒙系统后续的大规模推广也提前做好了技术储备。

当然，故事到这里并没有结束。在最基本的运行和交互能力之上，我们更需要关注 Flutter 与鸿蒙自身生态的结合：如何优雅地适配鸿蒙的分布式技术？如何用 Flutter 实现设备之间的快速连接、资源共享？现有的众多 Flutter 插件如何应用到鸿蒙系统上？未来 MTFlutter 团队将在这些方面做更深入的探索，因为解决好这些问题，才是真正能让应用覆盖用户生活的全场景的关键。

1. 示例

问题抛出，当引入线上ANR抓取工具后，发现了不少IdleHandler带来的问题。堆栈具体见下图

思考为什么idleHandler会带来这样的问题呢，或许你会觉得是单个消息执行时间过长导致的。那么请看示例，项目本身代码较为复杂，简化代码如下：

• 工具类

    /**

     * 添加任务到IdleHandler

     *

     * @param runnable runnable

     */

    public static void run(Runnable runnable) {

        IUiRunnable uiRunnable = new IUiRunnable(runnable);

        Looper.getMainLooper().getQueue().addIdleHandler(uiRunnable);

    }

• 使用工具类

public class MainActivity extends AppCompatActivity {



    public static final String TAG = "idleHandler";



    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

    }

    

    @Override

    protected void onResume() {

        super.onResume();

        Log.e(TAG, "onResume: start");

        //1 //关键代码处 延迟 3s执行的delay msg

        new Handler().postDelayed(new Runnable() {

            @Override

            public void run() {

                Log.e(TAG, "delay: msg");

                startService(new Intent(MainActivity.this, MyService.class));

            }

        }, 3000);

        //关键代码处 添加到IdleHandler里的三个任务

        UIManager.run(() -> test(1));

        UIManager.run(() -> test(2));

        UIManager.run(() -> test(3));

    }

        //延迟任务

        private void test(final int i) {



            try {

                Log.e(TAG, "queueIdle:test start " + i);

                Thread.sleep(3000);

                Log.e(TAG, "queueIdle:test end " + i);



            } catch (InterruptedException e) {

                e.printStackTrace();

            }

        }

    }

让我们来猜猜下面代码的输出顺序。再回看一下代码，肯定以为是下面这样对吧？

如果你觉得上面的输出没问题，那就更需要继续读下去了

这里把真实log截出来：

what?？delay3000ms为什么失效了。而是Idle消息先执行了。

为什么呢？不慌遇到这种问题我们肯定要通过IdleHandler机制的源码，来找答案了。

2. 源码分析

//MessageQueue.java

Message next() {

    // Return here if the message loop has already quit and been disposed.

    // This can happen if the application tries to restart a looper after quit

    // which is not supported.

    final long ptr = mPtr;

    if (ptr == 0) {

        return null;

    }



    int pendingIdleHandlerCount = -1; // -1 only during first iteration

    int nextPollTimeoutMillis = 0;

    for (;;) {

        if (nextPollTimeoutMillis != 0) {

            Binder.flushPendingCommands();

        }



        nativePollOnce(ptr, nextPollTimeoutMillis);



        ...

            // If first time idle, then get the number of idlers to run.

            // Idle handles only run if the queue is empty or if the first message

            // in the queue (possibly a barrier) is due to be handled in the future.

            //1 执行时机

            if (pendingIdleHandlerCount < 0

                    && (mMessages == null || now < mMessages.when)) {

                pendingIdleHandlerCount = mIdleHandlers.size();

            }

            if (pendingIdleHandlerCount <= 0) {

                // No idle handlers to run.  Loop and wait some more.

                mBlocked = true;

                continue;

            }



            if (mPendingIdleHandlers == null) {

                mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];

            }

            //2 copy副本

            mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);

        }



        // Run the idle handlers.

        // We only ever reach this code block during the first iteration.

        //3  逐个执行

        for (int i = 0; i < pendingIdleHandlerCount; i++) {

            final IdleHandler idler = mPendingIdleHandlers[i];

            mPendingIdleHandlers[i] = null; // release the reference to the handler



            boolean keep = false;

            try {

                keep = idler.queueIdle();

            } catch (Throwable t) {

                Log.wtf(TAG, "IdleHandler threw exception", t);

            }

            //4 是否移除当前idleHandler

            if (!keep) {

                synchronized (this) {

                    mIdleHandlers.remove(idler);

                }

            }

        }



        // Reset the idle handler count to 0 so we do not run them again.

        pendingIdleHandlerCount = 0;



        // While calling an idle handler, a new message could have been delivered

        // so go back and look again for a pending message without waiting.

        nextPollTimeoutMillis = 0;

    }

}



//5 外部调用添加idleHandler

public void addIdleHandler(@NonNull IdleHandler handler) {

    if (handler == null) {

        throw new NullPointerException("Can't add a null IdleHandler");

    }

    synchronized (this) {

        mIdleHandlers.add(handler);

    }

}

鉴于next()方法比较长且相关介绍也比较多，这里不细说。

• 
  

  注释1处，这里是IdleHandler执行时机，即主线程无消息或者未到执行时机（空闲时间）。

  
  


• 
  

  注释2处，可以看到mPendingIdleHandlers相当于copy了mIdleHandlers中的内容，由注释5处可以看到我们调用addIdleHandler()添加的任务都存进了mIdleHandlers。

  
  


• 
  

  注释3处，这里循环意味着要一次性处理之前添加的全部IdleHandler任务，如果我们短时内调用了多次addIdleHandler()，意味着这些idle msg将被拿出来逐个执行；而且要全部处理掉，才可以继续执行原消息队列的消息，如果idle msg很耗时，便会出现前面的主线程的postDelay任务执行时间就非常不可靠了；同理如果期间有触摸事件发生，那极有可能会因为得不到及时处理而导致ANR发生。赶紧检查下自己的项目中是否有此类问题。

  
  


• 
  

  注释4处，控制本次的IdleHandler是会被再次调用还是单次调用呢，是由queueIdle()方法的返回值决定，这点是我们该利用起来的。

  
  

上面的工具方法初衷是好的，提供接口暴露给各业务侧在某个需要的时刻将非紧急任务延迟加载，进而减少卡顿，但用起来却没有那么丝滑，甚至导致ANR，希望大家理解后能够避开这个坑。

3.安全用法

IdleHandler再介绍

• 这里再赘述下IdleHandler作用，我们都知道在做启动性能优化的时候，要尽可能多地减少启动阶段主线程任务。对一些启动阶段非必须且一定要在主线程里完成的任务，我们可以在应用启动完成之后再去加载。正是考虑到这些google官方提供了IdleHandler机制来告诉我们线程空闲时机。

利用IdleHandler设计的工具类

直接使用IdleHandler，肯定不太符合博主这种“大项目”的编码风格，简单封装是必要，方便我们做些功能定制，下面给大家说下项目中的工具类。

• 正确的方法 将启动过程中非紧急的主线程任务全部放进uiTasks里，然后逐个执行,切记单个消息耗时不要太长。

private static List<Runnable> uiTasks = new ArrayList<>();



public static UIPoolManager addTask(Runnable runnable) {

    tasks.add(runnable);

    return this;

}



public static UIManager runUiTasks() {

    NullHelper.requireNonNull(uiTasks);

    IUiTask iUiTask = new IUiTask() {

        @Override

        public boolean queueIdle() {

            if (!uiTasks.isEmpty()) {

                Runnable task = uiTasks.get(0);

                task.run();

                uiTasks.remove(task);

            }

            //逐次取一个任务执行 避免占用主线程过久

            return !uiTasks.isEmpty();

        }

    };



    Looper.myQueue().addIdleHandler(iUiTask);

    return this;

}

替换成上面的方法再试一遍。

@Override

    protected void onResume() {

        super.onResume();

        Log.e(TAG, "onResume: start");

        //1

        new Handler().postDelayed(new Runnable() {

            @Override

            public void run() {

                Log.e(TAG, "delay: msg");

                startService(new Intent(MainActivity.this, MyService.class));

            }

        }, 3000);

        UIManager.addTask(() -> test(1));

        UIManager.addTask(() -> test(2));

        UIManager.addTask(() -> test(3));

        UIManager.runUiTasks();

    }

得到最初希望的时序结果：