BaseUrlManager

BaseUrlManager for Android 的设计初衷主要用于开发时，有多个环境需要打包APK的场景，通过BaseUrlManager提供的BaseUrl动态设置入口，只需打一 次包，即可轻松随意的切换不同的开发环境或测试环境。在打生产环境包时，关闭BaseUrl动态设置入口即可。

妈妈再也不用担心因环境不同需要打多个包的问题，从此告别环境不同要写一堆配置的烦恼，真香。

配合 RetrofitHelper 动态改变BaseUrl一起使用更香。

Gif 展示

引入

Maven：

<dependency>

  <groupId>com.king.base</groupId>

  <artifactId>base-url-manager</artifactId>

  <version>1.1.1</version>

  <type>pom</type>

</dependency>

Gradle:

//AndroidX 版本

implementation 'com.king.base:base-url-manager:1.1.1'



//-----------------------v1.0.x以前的版本

//AndroidX 版本

implementation 'com.king.base:base-url-manager:1.0.1-androidx'



//Android Support 版本

implementation 'com.king.base:base-url-manager:1.0.1'

Lvy:

<dependency org='com.king.base' name='base-url-manager' rev='1.1.1'>

  <artifact name='$AID' ext='pom'></artifact>

</dependency>

如果Gradle出现implementation失败的情况，可以在Project的build.gradle里面添加如下：（也可以使用上面的GitPack来implementation）

allprojects {

    repositories {

        maven { url 'https://dl.bintray.com/jenly/maven' }

    }

}

示例

集成步骤代码示例 （示例出自于app中）

Step.1 在您项目中的AndroidManifest.xml中通过配置meta-data来自定义全局配置

    <!-- 在你项目中添加注册如下配置 -->

    <activity android:name="com.king.base.baseurlmanager.BaseUrlManagerActivity"

        android:screenOrientation="portrait"

        android:theme="@style/BaseUrlManagerTheme"/>

Step.2 在您项目Application的onCreate方法中初始化BaseUrlManager

    //获取BaseUrlManager实例（适用于v1.1.x版本）

    mBaseUrlManager = BaseUrlManager.getInstance();



    //获取BaseUrlManager实例（适用于v1.0.x旧版本）

    mBaseUrlManager = new BaseUrlManager(this);



    //获取baseUrl

    String baseUrl = mBaseUrlManager.getBaseUrl();

Step.3 提供动态配置BaseUrl的入口（通过Intent跳转到BaseUrlManagerActivity界面）

v.1.1.x 新版本写法

   BaseUrlManager.getInstance().startBaseUrlManager(this,SET_BASE_URL_REQUEST_CODE);

v1.0.x 以前版本写法

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

    //BaseUrlManager界面的标题

    //intent.putExtra(BaseUrlManagerActivity.KEY_TITLE,"BaseUrl配置");

    //跳转到BaseUrlManagerActivity界面

    startActivityForResult(intent,SET_BASE_URL_REQUEST_CODE);

Step.4 当配置改变了baseUrl时，在Activity或Fragment的onActivityResult方法中重新获取baseUrl即可

    //方式1：通过BaseUrlManager获取baseUrl

    String baseUrl = BaseUrlManager.getInstance().getBaseUrl();

    //方式2：通过data直接获取baseUrl

    UrlInfo urlInfo = BaseUrlManager.parseActivityResult(data);

    String baseUrl = urlInfo.getBaseUrl();

更多使用详情，请查看app中的源码使用示例或直接查看API帮助文档

BaseUrlManager.zip

一，背景

这是个沙雕操作，原因是：在小米手机的部分机型上，弹Toast时会在吐司内容前面带上app名称，如下：

此时产品经理发话了：为了统一风格，在小米手机上去掉Toast前的应用名。

网上有以下解决方案，比如：先给toast的message设置为空，然后再设置需要提示的message，如下：

Toast toast = Toast.makeText(context, “”, Toast.LENGTH_LONG);

toast.setText(message);

toast.show();

但这些都不能从根本上解决问题，于是Hook Toast的方案诞生了。

二，分析

首先分析一下Toast的创建过程.

Toast的简单使用如下：

Toast.makeText(this,"abc",Toast.LENGTH_LONG).show();

1，构造toast

通过makeText()构造一个Toast，具体代码如下：

public static Toast makeText(@NonNull Context context, @Nullable Looper looper,

		@NonNull CharSequence text, @Duration int duration) {

	if (Compatibility.isChangeEnabled(CHANGE_TEXT_TOASTS_IN_THE_SYSTEM)) {

		Toast result = new Toast(context, looper);

		result.mText = text;

		result.mDuration = duration;

		return result;

	} else {

		Toast result = new Toast(context, looper);

		View v = ToastPresenter.getTextToastView(context, text);

		result.mNextView = v;

		result.mDuration = duration;



		return result;

	}

}

makeText()中也就是设置了时长以及要显示的文本或自定义布局，对Hook什么帮助。

2，展示toast

接着看下Toast的show():

public void show() {

	...



	INotificationManager service = getService();

	String pkg = mContext.getOpPackageName();

	TN tn = mTN;

	tn.mNextView = mNextView;

	final int displayId = mContext.getDisplayId();



	try {

		if (Compatibility.isChangeEnabled(CHANGE_TEXT_TOASTS_IN_THE_SYSTEM)) {

			if (mNextView != null) {

				// It's a custom toast

				service.enqueueToast(pkg, mToken, tn, mDuration, displayId);

			} else {

				// It's a text toast

				ITransientNotificationCallback callback =

						new CallbackBinder(mCallbacks, mHandler);

				service.enqueueTextToast(pkg, mToken, mText, mDuration, displayId, callback);

			}

		} else {

            // 展示toast

			service.enqueueToast(pkg, mToken, tn, mDuration, displayId);

		}

	} catch (RemoteException e) {

		// Empty

	}

}

代码很简单，主要是通过service的enqueueToast()和enqueueTextToast()两种方式显示toast。

service是一个INotificationManager类型的对象，INotificationManager是一个接口，这就为动态代理提供了可能。

service是在每次show()时通过getService()获取，那就来看看getService():

@UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.P)

private static INotificationManager sService;



@UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.P)

static private INotificationManager getService() {

	if (sService != null) {

		return sService;

	}

	sService = INotificationManager.Stub.asInterface(

			ServiceManager.getService(Context.NOTIFICATION_SERVICE));

	return sService;

}

getService()最终返回的是sService，是一个懒汉式单例，因此可以通过反射获取到其实例。

3，小结

sService是一个单例，尅反射获取到其实例。

sService实现了INotificationManager接口，因此可以动态代理。

因此可以通过Hook来干预Toast的展示。

三，撸码

理清了上面的过程，实现就很简单了，直接撸码：

1，获取sService的Field

Class<Toast> toastClass = Toast.class;



Field sServiceField = toastClass.getDeclaredField("sService");

sServiceField.setAccessible(true);

2，动态代理替换

Object proxy = Proxy.newProxyInstance(Thread.class.getClassLoader(), new Class[]{INotificationManager.class}, new InvocationHandler() {

	@Override

	public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

		

		return null;

	}

});

// 用代理对象给sService赋值

sServiceField.set(null, proxy);

3，获取sService原始对象

因为动态代理不能影响被代理对象的原有流程，因此需要在第二步的InvocationHandler()的invoke()中需要执行原有的逻辑，这就需要获取sService的原始对象。

前面已经获取到了sService的Field，它是静态的，那直接通过sServiceField.get(null)获取不就可以了？然而并不能获取到，这是因为整个Hook操作是在应用初始化时，整个应用还没有执行过Toast.show()的操作，因此sService还没有初始化（因为它是一个懒汉单例）。

既然不能直接获取，那就通过反射调用一下：

Method getServiceMethod = toastClass.getDeclaredMethod("getService", null);

getServiceMethod.setAccessible(true);

Object service = getServiceMethod.invoke(null);

接着完善一下第二步代码：

Object proxy = Proxy.newProxyInstance(Thread.class.getClassLoader(), new Class[]{INotificationManager.class}, new InvocationHandler() {

	@Override

	public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

		

		return method.invoke(service, args);

	}

});

到此，已经实现了对Toast的代理，Toast可以按照原始逻辑正常执行，但还没有加入额外逻辑。

4，添加Hook逻辑

在InvocationHandler的invoke()方法中添加额外逻辑：

Object proxy = Proxy.newProxyInstance(Thread.class.getClassLoader(), new Class[]{INotificationManager.class}, new InvocationHandler() {

    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        // 判断enqueueToast()方法时执行操作

        if (method.getName().equals("enqueueToast")) {

            Log.e("hook", method.getName());

            getContent(args[1]);

        }

        return method.invoke(service, args);

    }

});

args数组的第二个是TN类型的对象，其中有一个LinearLayout类型的mNextView对象，mNextView中有一个TextView类型的childView，这个childView就是展示toast文本的那个TextView，可以直接获取其文本内容，也可以对其赋值，因此代码如下：

private static void getContent(Object arg) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {

	// 获取TN的class

    Class<?> tnClass = Class.forName(Toast.class.getName() + "$TN");

    // 获取mNextView的Field

    Field mNextViewField = tnClass.getDeclaredField("mNextView");

    mNextViewField.setAccessible(true);

    // 获取mNextView实例

    LinearLayout mNextView = (LinearLayout) mNextViewField.get(arg);

    // 获取textview

    TextView childView = (TextView) mNextView.getChildAt(0);

    // 获取文本内容

    CharSequence text = childView.getText();

    // 替换文本并赋值

    childView.setText(text.toString().replace("HookToast：", ""));

    Log.e("hook", "content: " + childView.getText());

}

最后看一下效果：

四，总结

这个一个沙雕操作，实际应用中这种需求也比较少见。通过Hook的方式可以统一控制，而且没有侵入性。大佬勿喷！！！

这是我参与新手入门的第2篇文章

产品看到别家的app,未勾选协议的时候，会给用户一个抖动效果的提示，感觉不错，然后看了看自家的app，不行，没有抖动，不能很明显表示，于是需求出来了，用户未勾选的时候，给个抖动效果。（ 呵，都不能有点创新，当然不能说出来了，只能内心暗说，哈哈，给自己加了点戏，）正事来了，开始。。。干，就完了。

如果需要实现用户协议、隐私政策的代码，请看这篇文章：juejin.cn/post/698126…

实现功能大概需要三个步骤：

一、 用什么实现；二、实现的步骤；三、运行效果

一、用什么实现

其实实现起来很简单，用补间动画就行了。

二、实现的步骤

这里说下实现补间动画的步骤：总共需要以下几个步骤

1.如果res目录下没有anim文件，就新建一个文件夹； 2.在anim文件夹下创建一个名字叫translate_checkbox_shake.xml的文件，抖动动画

<?xml version="1.0" encoding="utf-8"?>

<translate xmlns:android="http://schemas.android.com/apk/res/android"

 android:duration="300"

 android:fromXDelta="0"

 android:interpolator="@anim/cyc"

 android:toXDelta="30">

</translate>

再在anim下创建一个插值器，名字叫cyc，这样会有抖动效果

<?xml version="1.0" encoding="utf-8"?>

<cycleInterpolator xmlns:android="http://schemas.android.com/apk/res/android"

    android:cycles="2">

</cycleInterpolator>

3.在translate_checkbox_shake.xml里写上需要的动画属性；

android:duration="300"与android:cycles="2"联合表示在300毫秒内将动画执行2次，根据需求来设置就行了；

属性toXDelta和fromXDelta是横向效果，toYDela和fromYDelta是竖向，感兴趣的可以尝试下。、

4.在代码中使用 AnimationUtils.loadAnimation加载新创建的动画文件；

 val animation = AnimationUtils.loadAnimation(this, R.anim.translate_checkbox_shake)

5.在代码中使用View的startAnimation启动动画，完事

 binding.llShake.startAnimation(animation)

三、效果如下：

作者：JasonYin

大四那年我被骗到了电子厂，无法忍受流水线的工作，愤而撩了挑子。前途一片渺茫的时候，我连夜爬起自学起了Android，开启了我的Android开发之路。至今已毕业多年，一直在这条热爱的道路上坚持着，快乐、知足、感恩。

分享我的故事之前，先简单回顾一下我这半年都干了啥。

这半年

年初看到了一篇文章《我的 2020 年终总结》，深受感染。作者杰哥在2020一整年，始终坚持日更输出，拿到了多个平台的证书和奖杯。同时还学做了多道菜品，期间还坚持健身和旅游放松。一年同样是365天，别人竟过得如此充实、如此精彩！

钦佩之余我不禁陷入了思考，联想到了自己。忽然意识到自高考以后，总是间歇性踌躇满志无疾而终，太久没有为一个目标而坚持了。 我想好好做成一件事情，我要给自己定个目标。我擅长Android开发，那就坚持写作，保证一两个礼拜输出一篇高质量文章。

一则将自己用心打磨的东西分享出来，帮助别的开发者；二来利用持续的输出倒逼自己不断地摄入新知识，迫使我持续学习，养成终生学习、定期总结的好习惯。但分享给大家看的东西不比私人笔记，需要注意很多细节，诸如深入的理解、通俗的讲解、友好的排版等等。

为此我做了很多准备，潜心学习了很多优质文章的行文风格、目录次序、MarkDown语言以及一堆作图工具。接着删除了手机、平板里的游戏和视频软件等一切时间杀手。另外收集了大量Android相关的优质话题。并买了个专业的待办事项App，用来随时记录新的灵感，高效地安排每篇文章的写作计划。万事俱备，一月底的时候就开始了半学习、半摸索的写作之路。

写了一些文章

半年不到的时间内我输出了十四篇技术文章和三篇随笔。技术文章主要聚焦在Android领域比较流行的话题，比如持续火爆的Jetpack框架，重大UI变革的Compose 工具包，即将发布的Android 12系统以及国人热捧的鸿蒙系统。

• 一直好奇AppCompat包的构成和作用，却发现没有一篇完整讲述它的文章。便从原理入手，结合DEMO进行了详细地总结： 深度解读Jetpack框架的基石-AppCompat


• 总听说CameraX很好用，但不少文章使用的API已不兼容。我基于最新的版本循序渐进地演示了CameraX的各种用法：为什么推荐使用Jetpack CameraX？


• 定制Backup功能，查阅全网却发现相关资料极少的时候，决定自己填补这块空白。遂从功能由来、发展历史、实现原理、破解和定制等完整维度，对它进行了充分地解读，汇成了三万字： 全面复盘Android开发者容易忽视的Backup功能


• Android 12 preview版发布的SplashScreen API可以丰富App启动效果但实现十分简单，引起了我的兴趣。我反复打磨各种动画效果，详细展示启动画面的各种酷炫玩法：Android 12上全新的应用启动画面，还不适配一下？


• Compose beta版发布，带来了全新的UI构建方式。我结合一众Jetpack框架和MVVM架构，重新打造了电影App：Jetpack Compose助我快速打造电影App


• Google IO 2021上发布的Android 12宣传片里AppWidget发生了重大变化。我精心制作了Todo-list、步数、时间倒数等小组件对其多个变化进行了全方位的解读：Android 12上焕然一新的小组件：美观、便捷和实用


• AndroidX和Jetpack一直在用，但其关系总分不清楚，困扰着很多开发者。我就以变化最大的Preference组件为例，自Android诞生之初开始回溯Jetpack出现的由来、构成和未来：从Preference组件的更迭看Jetpack的前世今生

被多个官方转载

自High的文章没有价值，好在我不是自我感动，写的文章被多个官方平台转载。【深度解读Jetpack框架的基石-AppCompat】是第一篇被Google转载的文章，我很激动、也很意外。因为那是今年输出的第一篇文章，排版和措辞都略显粗糙。很感谢他们提供的平台，这些认同让我坚定了写作方向。

2篇文章被Android官方公众号转载：

3篇文章被CSDN官方公众号转载：

1篇文章被搜狐技术公众号分享：

1篇文章被掘金官方公众号转载：

额外赞扬一波掘金平台，上面的高质量文章很多，技术氛围很好。我在这里读到了很多优质文章，也结识了很多优秀作者。而且相较其他平台，掘金对于新人更加友好，只要你的文章认真、质量过关，掘金不会吝啬曝光量。我入驻掘金的时间不长，但前两个月都闯进了移动端前二十的作者榜单，比心。

特别感谢鸿神

从事Android工作以来，拜读过鸿神的很多文章，但并不认识。写文章这段时间与鸿神有了多次交流，在钦佩他技术厉害的同时，更感受到他为人的Nice。很感激他的个人公众号转载过我多篇文章，给予的帮助。

接受认可以及批评

当然，输出文章的初衷还是希望对大家有所帮助。欣慰的是文章受到了很多积极的评价：有留下“全网最佳”评价的朋友，也有专门加我好友跟我道谢的朋友。你们的认可是我持续输出的最大动力。

有赞扬自然也有批评，有些朋友说我某个知识点没提到、评价Demo难以理解、吐槽技术点过时。。。真的，我诚恳接受每个批评，将努力发掘和改正这些不足。

我沉迷于将一个技术点一次性讲清楚，又常常选取一个大的话题，最终导致文章的篇幅都很大。这又需要准备很长时间，而这些时间都来源于工作、生活之余的零碎片段。思路非常很容易被打断，一不小心就错过某个细节，或者代码写得仓促，请大家多多包涵。

那年高考

回到文章的标题上来，回顾下我与Android结缘的心路历程，这还得从那年高考讲起。

高考已过十年有余，那会儿的江苏高考已经很卷，一年一度的新政策搞得我们无所适从。还好我高二那年一鼓作气，势如破竹拿下小四门全A。可惜高考的时候还是大意了，即便我侥幸冲破了葛军神卷的围堵，还是栽在了语文作文上。不会出问题的化学还是出了问题，痛失了6A。在双重失利的情况下，艰难地挺过了一本线。

与理想的211大学失之交臂后，只能在一众双非大学里碰碰运气了。路过江苏大学招生座位的时候，他们的老师对我兴趣十足，想跟我签订个志愿协议：保证能上他们学校的四个好专业之一，最终录取则要按照我定的顺序来。他提供了车辆工程、机械工程、电气工程、电子信息工程这几个专业，事实上这个顺序已经按照分数线进行了由高到低的排名。

爸爸和我在前一分钟还不知道江苏有个不在南京的江苏大学（散装江苏还真不是说笑的）。我们对于这个大学和这些专业完全不了解，彻底犯了难。不知道怎么选，更不知道怎么排序。在这重要的抉择时刻，爸爸把选择权交给了我，让我按照自己的想法来（内心OS：呐，你自己选哦，选错了别怨我）。

面对这一众陌生又熟悉的名词，稚嫩的高三学生开始了他的内心戏：

• 车辆工程？机械工程？是要学修车吗，还是做拖拉机，摩托车啥的，还是不要了吧


• 电气工程？是学做电工吗，上电线杆修变压器的那种？但跟我喜欢的物理貌似有点关系，还不错


• 电子信息工程？电子？电路？芯片？手机？手机能打电话、发短信、玩游戏，高端、有意思，就它了

所以我在协议上郑重写下了：电子信息工程 > 电气工程 > 机械工程> 车辆工程。是的，我把顺序完美调了个头，哈哈。爸爸看到这个完全颠倒的顺序后，一脸疑惑，隐约不安。但确认了我坚定无比的眼神后，欲言又止，不想耽误我的远大前程。

结果可想而知，毫无悬念地被江苏大学电子信息工程专业成功录取。进入学校后我才了解到这几个专业的真实情况后，心里直呼草率了，捂脸。

我的大学

电子信息工程专业确如我猜想的那样，跟芯片有关系。除此之外，还跟通信、操作系统密不可分。要学的知识点超级多：有令人头皮发麻的数电模电、单片机，需要记忆一堆公式的通信原理，C语言、Java语言和数据库。一句话，很多很散，复杂且枯燥。完全不是我想象中手机的有趣样子，自然是提不起一点兴趣。

加上高中老师“认真学，到大学就解放了” 的反复洗脑深深地影响了我，便开始混日子。翘课是常有的事，连高等数学挂科了，都没激起我内心的一点涟漪。现在想来也不赖高中老师，这就是给自己的懒惰找的借口，哈哈。

玩命地打工

考研是不可能考研的，进大学的时候我就笃定了毕业后直接参加工作，去挣钱。工作需要什么？当时的我浅薄地以为，表达能力、处事能力这些社交素质才是最重要的。可这些本事，学校里不教啊。那就到社会中去，去打工，玩命地打工，还能挣到零花钱。

在这样的“指导思想”下，大学的寒暑假，几乎都在打工中度过。前前后后在台湾仁宝代工厂做过工人，在日本妮飘面纸厂做过保安，在苏宁电器卖过步步高手机（那一整个暑假，耳朵都被宋慧乔的广告插曲统治着）。。。

多份打工的体验，让我待人接物变得更加自信、接触新的环境也更加的从容，好像确实提升了所谓的社交素质。但让我感受最深的是，很多工作真的不容易，大学里不愁吃穿、只要顾好学习一件事情的生活真的太珍贵了，可那时候就是没有毅力去珍惜。

肆意的青春

大学里特别迷恋某位明星，就跟着一起痴迷Hipop文化。喜欢的歌以说唱为主，看的书都是日韩、港台潮流杂志，外在就更“嘻哈”了：染一头金色头发、打个“钻石”耳钉、戴个夸张的耳环、穿一套炸街的嘻哈服装。从里到外都很Real，简直就是学院里最靓的仔。那个时候Hipop没现在火，知道和接受的人很少，我在他们眼中特别另类，但我不Care。打工得来的大部分钱也都花在了置办这些行头上，在淘宝还不流行的年代买成了淘宝的五星买家。

看似充实的大学生活，难掩空洞和无聊。除了帝国时代和文明的陪伴，就通过画画、练字来排遣这无病呻吟的时光。

大四了还去电子厂装电路板？

浑浑噩噩地熬到了大四，终于到检验我社交才能的时候了。信心满满地参加了多个宣讲会，最后竟没有一家企业欣赏我“名企”的兼职经历，连笔试机会都不给啊。接连遭受企业的无情毒打，我才认识到专业成绩和基础仍然是企业最看重的东西。 可这就被动了，书本这一块早就被我放弃了。当年可是村里的高考状元啊，要是连工作都没找到就太丢人了！这种焦虑的状况持续了一个多月。

工作还得继续找啊！痛定思痛，开始仔细地分析。恶补成绩和基础已经不可能了，那就去整点硬核的实习经验，在专业经验这块弯道超车。 恰好一个电子公司到学校招实习生，说是画PCB电路板子，还发正规的实习证书。这简直是雪中送炭，不拿工资我也得去啊。

到了之后就傻眼了，压根不是想像中的电子公司，而是一家装配电瓶车充电器的电子厂。算嘞，既来之则安之，给我画电路图就行。可他们让我们一帮学生到流水线上组装电路板，就是左手拿电阻右手拿二极管，在快速转动的传送带上放元件！过分！

才练习了半小时就得全部上流水线，我手忙脚乱地忙到几乎崩溃。联想到之前在代工厂的打工经历，心里直犯嘟哝：这哪是实习，分明就是打零工嘛，干上一年我还是找不到工作啊，简直就是在浪费时间！ 我越想越气，越气装得越乱，越乱越被骂。情绪被逼到了极点，我甩开了电路板子，气呼呼地跟领班说：我，不干了！

管不了工人们鄙视的眼神，我像逃兵一样跑了出来，钻上了回学校的公交。一路上都在跟自己较劲：你就这么跑了对吗？这点苦都受不了以后能干好什么？跟爸妈吹嘘的实习证书又该怎么办？

复杂的情绪笼罩了一整天，直到晚上睡觉，还在为这事犯愁。

Android给了我曙光

躺在床上，思绪不禁回到了三年前。那时的我对手机兴趣满满，选择了这个专业。如今专业四年即将划上终点，而当初的梦想却未曾踏出半步。 惆怅之余看了眼身旁的HTC G14手机，突然想起店员曾说过它搭载了时下最火的Android智能系统。又回想起学校里曾经有过Android开发的培训广告，我不禁两眼放光：手机我有了，正好是这个最火的Android系统，那干嘛不开发个软件试试呢？如果能开发个完整的App，简历里、面试时不就有东西可说了嘛！

想罢，立马从床上爬起来搜索关于Android开发的一切。那个年代Android Studio还没发布，开发资料更少得可怜。庆幸我学习能力还不错，顺利地装好了驱动、打开了开发者模式、搭好了Eclipse和SDK环境，这时候已经到了深夜。当G14成功运行了Hello world的时候，我情不自禁地炸了一句“Yeah”，气得舍友直骂娘。那一刻我兴奋不已，因为我感觉找对了方向。

网上的资料少且零碎，第二天一早就去图书馆找相关书籍。谢天谢地，还真有一本Android相关的书。我抱着手里的“圣经”，虔诚地学习了各种控件的使用，小心翼翼地倒腾了两天，终于搞出了一个播放本地mp3的播放界面。看到这有模有样的成果，成就感爆棚。于是乘胜追击，加了很多小功能：音乐封面、上下首、播放模式、文件列表、主题切换、启动画面等等。

大概又搞了一个礼拜，一个完整的音乐App成型了。我把杰作安装到G14上，随身携带。面试的时候时不时拿出来演示一番，顺带着复述着那些似懂非懂的API。 那个年代懂Android的人很少，我如愿以偿地找到了Android开发工作。我清晰地记得拿到Offer后，爸爸在电话那头的兴奋。在他们不看好的方向上获得成功、受到认可的感觉真得很棒！

打那以后，我对Android的兴趣一发不可收拾。在学校的最后一点时光里，总忍不住开发个小Demo把玩把玩，时不时地刷个新Rom体验体验。G14很快就被折腾不行了，对我而言这是一部意义非凡的手机，多次搬家都不忍丢弃。 如今那个启蒙App早已找不着了，很想找来跑一跑，康康当时写的代码有多烂、界面有多丑，哈哈。

社会人

说不清是音乐App助我找到了工作，还是自学Android的热情打动了公司，给了我机会。

我有幸一直从事品牌手机的ROM开发工作，从开发第三方App、到修改系统App、再到定制Framework；从面向Bug编程、到面向对象编程、再到面向产品编程，一晃已过了七年！

临笔前特地到官网瞅了一眼这些年开发过的Android设备，有20多部。当这么多部造型各异的手机和平板，平铺在电脑面前时，回忆历历在目、感慨不已。

成长为安卓老兵的同时，外在也不可抗拒地发生变化。发际线渐渐失守，眼镜戴上就摘不下来了，身形也渐渐走样。好像也不全是坏事，它们提醒着我在工作、生活、学习的同时，时刻关注身体健康。

半山腰回望

如果大四那年没有在电子厂里撂挑子，我大概率不会自学Android。可能最终也能找着工作，但极有可能不会从事我如今热爱的Android行业。

我很荣幸参与和见证了这个行业的发展，这些年它变化太快，像是一场狂欢。从颠覆移动领域的变革时代，到移动互联的红利时代，再到如今内卷严重的存量时代，各方都在努力地维持或改变：

• 巨头们在不断调整战略：Google通过GMS想方设法地控制Android系统，厂商们在同质化严重的Android设备里寻求亮点和突破，在传统设备以外持续探索和开发新的赛道。。。


• 开发者们亦疲于奔命：应对各种快速迭代的新技术，应付各种碎片化ROM的适配，苦于前端、跨平台技术的蚕食。。。

移动互联的落寞必然引发Android市场的紧缩，企业对于Android群体的要求将持续拉高，Android开发的内卷加剧则是不争的事实。 如果热爱Android、对Android仍有信心，时刻保持技术人的好奇心和探索欲吧，对新技术以及新领域：

• AAB、Jetpack、Kotlin、Compose、Flutter。。。


• 革新的智能座舱、划时代的自动驾驶、万物互联的鸿蒙、一统Android和Chrome OS的Fuchsia。。。

最后一点碎碎念

I always knew what the right path was. Without exception, l knew, but l never took it. You know why ? lt was too damn hard.

这是我最喜欢的电影《闻香识女人》里迈克中校的感人自白：“无一例外，我永远知道哪条路是对的。但我从来不走，因为太XX难了”。知易行难，这无疑是古今中外、亘古不变的难题。它关乎的东西太多：改变、自律、坚持和成长，哪一个都不好对付。

如今的我早已被生活磨平了棱角，渐渐丢掉了当年的那份冲劲和激情。但每每想起当年那个敢于说不、熬夜自学的我，感慨之余多了一份坚持。

也许你也曾踌躇满志、无疾而终，记得想想最初的自己，你会找到那个答案。

正值毕业季，祝福即将踏入社会的新朋友，以及社会中浮沉的老朋友，都有个淋漓尽致的人生！

1. 前言

Activity生命周期真是一个非常古老的话题，无论是10年前，还是当下。不管是面试还是工作，经常会遇到与Activity生命周期相关的问题。比如“按下返回键和Home键，生命周期方法调用顺序”、“A启动B，它们的生命周期方法调用顺序”。工作中，Jetpack Lifecycle、LiveData、ViewModel等组件都是建立在生命周期之上。

在我研究Jetpack Lifecycle、LiveData、ViewModel源码时，我发现它们与组件的生命周期有很大的关系。它们能够自动感知组件的生命周期变化。LiveData能够在onDestroy方法调用时自动将监听注销掉，ViewModel能够在Configuration发生改变时(比如旋转屏幕)自动保存数据，并且在Activity重建时恢复到Configuration发生改变之前。

本文我将从几个场景详细介绍Activity的生命周期变化。

2. 单Activity按返回按钮

触发步骤:

• 按返回按钮


• 或者调用finish方法


• 重新进入Activity

该场景演示了用户启动，销毁，重新进入Activity的生命周期变化。调用顺序如图：

状态管理：

• onSaveInstanceState没有被调用，因为Activity被销毁，没有必要保存状态


• 当Activity被重新进入时，onCreate方法bundle参数为null

3. 单Activity按Home键

触发步骤:

• 用户按Home键


• 或者切换至其它APP


• 重新进入Activity

该场景Activity会调用onStop方法，但是不会立即调用onDestroy方法。调用顺序如图：

状态管理：

当Activity进入Stopped状态，系统使用onSaveInstanceState保存app状态，以防系统将app进程杀死，重启后恢复状态。

4. 单Activity旋转屏幕

触发步骤:

• Configuration发生改变, 比如旋转屏幕


• 用户在多窗口模式下调整窗口大小

当用户旋转屏幕，系统会保留旋转之前的状态，能很好的恢复到之前的状态。调用顺序如图：

状态管理：

• Activity被完全销毁掉，但是状态会被保存，而且会在新的Activity中恢复该状态


• onCreate和onRestoreInstanceState方法中的bundle是一样的

5. 单Activity弹出Dialog

触发步骤:

• 在API 24+上开启多窗口模式失去焦点时


• 其它应用部分遮盖当前APP，比如弹出权限授权dialog


• 弹出intent选择器时，比如弹出系统的分享dialog

该场景不适用于以下情况：

• 相同APP中弹dialog，比如弹出AlertDialog或者DialogFragment不会导致Activity onPause发生调用


• 系统通知。当用户下拉系统通知栏时，不会导致下面的Activity onPause发生调用。

6. 多个Activity跳转

触发步骤:

• activity1 跳转到activity2


• 按返回按钮

注意:activity1 跳转到activity2 正确的调用顺序是

->activity1.onPause

->activity2.onCreate

->activity2.onStart

->activity2.onResume

->activity1.onStop

->activity1.onSaveInstanceState

在该场景下，当新的activity启动时，activity1处于STOPPED状态下(但是没有被销毁)，这与用户按Home键有点类似。当用户按返回按钮时，activity2被销毁掉。

状态管理：

• onSaveInstanceState会被调用，但是onRestoreInstanceState不会。当activity2展示在前台时，如果发生了旋转屏幕，当activity1再次获得焦点时，它将会被销毁并且重建，这就是为什么activity1在失去焦点时为什么需要保存状态。


• 如果系统杀死了app进程，该场景后面会介绍到

7. 多个Activity跳转，并且旋转屏幕

• activity1 跳转到activity2


• 在activity2上旋转屏幕


• 按返回按钮

注意: 当返回activity1时，必须保证屏幕是保持旋转后的状态，否则并不会调用onDestroy方法。而且是在activity1回到前台时才会主动掉onDestroy

状态管理：

保存状态对所有的activity都非常重要，不仅仅是对前台activity。所有在后台栈中的activity在configuration发生改变时重建UI时都需要将保存的状态恢复回来。

8. 多个Activity跳转，被系统kill掉app

• activity1 跳转到activity2


• 在activity2上按Home键


• 系统资源不足kill app

9. 总结

本文主要是从Google大佬Jose Alcérreca的文章翻译过来。他假设的这7个关于activity的生命周期场景，对了解Lifecycle有非常大的帮助。甚至对于面试都是有非常大的帮助。

后续我会写一系列关于Jetpack的文章。文风将会延续我的一贯风格，深入浅出，坚持走高质量创作路线。本文是我讲解Lifecycle的开篇之作。生命周期是Lifecycle、LiveDa、ViewModel等组件的基础。在对生命周期知识掌握不牢靠的情况，去研究那些组件，无异于空中楼阁。

KingPlayer

KingPlayer 一个专注于 Android 视频播放器（IjkPlayer、ExoPlayer、VlcPlayer、SysPlayer）的基础库，无缝切换内核。

功能说明

•  主要播放相关核心功能
•  播放器无缝切换
  •  MediaPlayer封装实现（SysPlayer）
  •  IjkPlayer封装实现
  •  ExoPlayer封装实现
  •  vlc-android封装实现
•  控制图层相关
  •  待补充...

Gif 展示

录制的gif效果有点不清晰，可以下载App查看详情。

引入

gradle:

使用 SysPlayer (Android自带的MediaPlayer)

//KingPlayer基础库，内置SysPlayer

implementation 'com.king.player:king-player:1.0.0-beta1'

使用 IjkPlayer

//KingPlayer基础库（必须）

implementation 'com.king.player:king-player:1.0.0-beta1'

//IjkPlayer

implementation 'com.king.player:ijk-player:1.0.0-beta1'



// 根据您的需求选择ijk模式的so

implementation 'tv.danmaku.ijk.media:ijkplayer-armv7a:0.8.8'

// Other ABIs: optional

implementation 'tv.danmaku.ijk.media:ijkplayer-armv5:0.8.8'

implementation 'tv.danmaku.ijk.media:ijkplayer-arm64:0.8.8'

implementation 'tv.danmaku.ijk.media:ijkplayer-x86:0.8.8'

implementation 'tv.danmaku.ijk.media:ijkplayer-x86_64:0.8.8'

使用 ExoPlayer

//KingPlayer基础库（必须）

implementation 'com.king.player:king-player:1.0.0-beta1'

//ExoPlayer

implementation 'com.king.player:exo-player:1.0.0-beta1'

使用 VlcPlayer

//KingPlayer基础库（必须）

implementation 'com.king.player:king-player:1.0.0-beta1'

//VlcPlayer

implementation 'com.king.player:vlc-player:1.0.0-beta1'

示例

布局示例

    <com.king.player.kingplayer.view.VideoView

        android:id="@+id/videoView"

        android:layout_width="match_parent"

        android:layout_height="match_parent" />

代码示例

        //初始化一个视频播放器（IjkPlayer、ExoPlayer、VlcPlayer、SysPlayer）

        videoView.player = IjkPlayer(context)

        //初始化数据源

        val dataSource = DataSource(url)

        videoView.setDataSource(dataSource)



        videoView.setOnSurfaceListener(object : VideoView.OnSurfaceListener {

            override fun onSurfaceCreated(surface: Surface, width: Int, height: Int) {

                LogUtils.d("onSurfaceCreated: $width * $height")

                videoView.start()

            }



            override fun onSurfaceSizeChanged(surface: Surface, width: Int, height: Int) {

                LogUtils.d("onSurfaceSizeChanged: $width * $height")

            }



            override fun onSurfaceDestroyed(surface: Surface) {

                LogUtils.d("onSurfaceDestroyed")

            }



        })



        //缓冲更新监听

        videoView.setOnBufferingUpdateListener {

            LogUtils.d("buffering: $it")

        }

        //播放事件监听

        videoView.setOnPlayerEventListener { event, bundle ->



        }

        //错误事件监听

        videoView.setOnErrorListener { event, bundle ->



        }

        

        

        //------------ 控制相关

        //开始

        videoView.start()

        //暂停

        videoView.pause()

        //进度调整到指定位置

        videoView.seekTo(pos)

        //停止

        videoView.stop()

        //释放

        videoView.release()

        //重置

        videoView.reset()

更多使用详情，请查看app中的源码使用示例或直接查看API帮助文档

其他

需使用JDK8+编译，在你项目中的build.gradle的android{}中添加配置：

compileOptions {

    targetCompatibility JavaVersion.VERSION_1_8

    sourceCompatibility JavaVersion.VERSION_1_8

}

代码下载:KingPlayer.zip

KingKeyboard

KingKeyboard for Android 是一个自定义键盘。内置了满足各种场景的键盘需求：包括但不限于混合、字母、数字、电话、车牌号等可输入场景。还支持自定义。集成简单，键盘可定制化。

引入

Maven：

<dependency>

  <groupId>com.king.keyboard</groupId>

  <artifactId>kingkeyboard</artifactId>

  <version>1.0.0</version>

  <type>pom</type>

</dependency>

Gradle:

//AndroidX

implementation 'com.king.keyboard:kingkeyboard:1.0.0'

Lvy:

<dependency org='com.king.keyboard' name='kingkeyboard' rev='1.0.0'>

  <artifact name='$AID' ext='pom'></artifact>

</dependency>

如果Gradle出现compile失败的情况，可以在Project的build.gradle里面添加如下：（也可以使用上面的GitPack来complie）

allprojects {

    repositories {

        //...

        maven { url 'https://dl.bintray.com/jenly/maven' }

    }

}

自定义按键值

 /*

  * 在KingKeyboard的伴生对象中定义了一些核心的按键值，当您需要自定义键盘时，可能需要用到

  */



 //------------------------------ 下面是定义的一些公用功能按键值

        /**

         * Shift键 -> 一般用来切换键盘大小写字母

         */

        const val KEYCODE_SHIFT = -1

        /**

         * 模式改变 -> 切换键盘输入法

         */

        const val KEYCODE_MODE_CHANGE = -2

        /**

         * 取消键 -> 关闭输入法

         */

        const val KEYCODE_CANCEL = -3

        /**

         * 完成键 -> 长出现在右下角蓝色的完成按钮

         */

        const val KEYCODE_DONE = -4

        /**

         * 删除键 -> 删除输入框内容

         */

        const val KEYCODE_DELETE = -5

        /**

         * Alt键 -> 预留，暂时未使用

         */

        const val KEYCODE_ALT = -6

        /**

         * 空格键

         */

        const val KEYCODE_SPACE = 32



        /**

         * 无作用键 -> 一般用来占位或者禁用按键

         */

        const val KEYCODE_NONE = 0



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



        /**

         * 键盘按键 -> 返回（返回，适用于切换键盘后界面使用，如：NORMAL_MODE_CHANGE或CUSTOM_MODE_CHANGE键盘）

         */

        const val KEYCODE_MODE_BACK = -101



        /**

         * 键盘按键 ->返回（直接返回到最初,直接返回到NORMAL或CUSTOM键盘）

         */

        const val KEYCODE_BACK = -102



        /**

         * 键盘按键 ->更多

         */

        const val KEYCODE_MORE = -103



        //------------------------------ 下面是自定义的一些预留按键值，与共用按键功能一致,但会使用默认的背景按键



        const val KEYCODE_KING_SHIFT = -201

        const val KEYCODE_KING_MODE_CHANGE = -202

        const val KEYCODE_KING_CANCEL = -203

        const val KEYCODE_KING_DONE = -204

        const val KEYCODE_KING_DELETE = -205

        const val KEYCODE_KING_ALT = -206



        //------------------------------ 下面是自定义的一些功能按键值，与共用按键功能一致,但会使用默认背景颜色



        /**

         * 键盘按键 -> 返回（返回，适用于切换键盘后界面使用，如：NORMAL_MODE_CHANGE或CUSTOM_MODE_CHANGE键盘）

         */

        const val KEYCODE_KING_MODE_BACK = -251



        /**

         * 键盘按键 ->返回（直接返回到最初,直接返回到NORMAL或CUSTOM键盘）

         */

        const val KEYCODE_KING_BACK = -252



        /**

         * 键盘按键 ->更多

         */

        const val KEYCODE_KING_MORE = -253



        /*

            用户也可自定义按键值，primaryCode范围区间为-999 ~ -300时，表示预留可扩展按键值。

            其中-399~-300区间为功能型按键，使用Special背景色，-999~-400自定义按键为默认背景色

        */

示例

代码示例

    //初始化KingKeyboard

    kingKeyboard = KingKeyboard(this,keyboardParent)

    //然后将EditText注册到KingKeyboard即可

    kingKeyboard.register(editText,KingKeyboard.KeyboardType.NUMBER)



    /*

     * 如果目前所支持的键盘满足不了您的需求，您也可以自定义键盘，KingKeyboard对外提供自定义键盘类型。

     * 自定义步骤也非常简单，只需自定义键盘的xml布局，然后将EditText注册到对应的自定义键盘类型即可

     *

     * 1. 自定义键盘Custom，自定义方法setKeyboardCustom，键盘类型为{@link KeyboardType#CUSTOM}

     * 2. 自定义键盘CustomModeChange，自定义方法setKeyboardCustomModeChange，键盘类型为{@link KeyboardType#CUSTOM_MODE_CHANGE}

     * 3. 自定义键盘CustomMore，自定义方法setKeyboardCustomMore，键盘类型为{@link KeyboardType#CUSTOM_MORE}

     *

     * xmlLayoutResId 键盘布局的资源文件，其中包含键盘布局和键值码等相关信息

     */

    kingKeyboard.setKeyboardCustom(R.xml.keyboard_custom)

//        kingKeyboard.setKeyboardCustomModeChange(xmlLayoutResId)

//        kingKeyboard.setKeyboardCustomMore(xmlLayoutResId)

    kingKeyboard.register(et12,KingKeyboard.KeyboardType.CUSTOM)

 //获取键盘相关的配置信息

 var config = kingKeyboard.getKeyboardViewConfig()



 //... 修改一些键盘的配置信息



 //重新设置键盘配置信息

 kingKeyboard.setKeyboardViewConfig(config)



 //按键是否启用震动

 kingKeyboard.setVibrationEffectEnabled(isVibrationEffectEnabled)



 //... 等等，还有各种监听方法。更多详情，请直接使用。

    //在Activity或Fragment相应的生命周期中调用，如下所示



    override fun onResume() {

        super.onResume()

        kingKeyboard.onResume()

    }



    override fun onDestroy() {

        super.onDestroy()

        kingKeyboard.onDestroy()

    }

相关说明

• KingKeyboard主要采用Kotlin编写实现，如果您的项目使用的是Java编写，集成时语法上可能稍微有点不同，除了结尾没有分号以外，对应类伴生对象中的常量，需要通过点伴生对象才能获取。

  //Kotlin 写法

  var keyCode = KingKeyboard.KEYCODE_SHIFT

  //Java 写法

  int keyCode = KingKeyboard.Companion.KEYCODE_SHIFT;

更多使用详情，请查看app中的源码使用示例

代码下载:KeyboardVisibilityEvent.zip

WordPOI

WordPOI是一个将Word接口文档转换成JavaBean的工具库，主要目的是减少部分无脑的开发工作。

核心功能：将文档中表格定义的实体转换成Java实体对象

WordPOI特性说明

1. 支持解析doc格式和docx格式的Word文档
2. 支持批量解析Word文档并转换成实体
3. 解析配置支持自定义，详情请查看{@link ParseConfig}相关配置
4. 虽然解析可配置，但因文档内容的不可控，解析转换也具有一定的局限性

只要在文档上定义实体对象时，尽量满足示例文档的规则，就可以规避解析转换时的局限性。

ParseConfig属性说明

引入

Maven：

<dependency>

  <groupId>com.king.poi</groupId>

  <artifactId>word-poi</artifactId>

  <version>1.0.1</version>

  <type>pom</type>

</dependency>

Gradle:

compile 'com.king.poi:word-poi:1.0.1'

Lvy:

<dependency org='com.king.poi' name='word-poi' rev='1.0.1'>

  <artifact name='$AID' ext='pom'></artifact>

</dependency>

如果Gradle出现compile失败的情况，可以在Project的build.gradle里面添加如下：（也可以使用上面的GitPack来complie）

allprojects {

    repositories {

        maven { url 'https://dl.bintray.com/jenly/maven' }

    }

}

引入的库：

compile 'org.apache.poi:poi:4.1.0'

compile 'org.apache.poi:poi-ooxml:4.1.0'

compile 'org.apache.poi:poi-scratchpad:4.1.0'

如想直接引入jar包可直接点击左上角的Download下载最新的jar，然后引入到你的工程即可。

示例

代码示例 (直接在main方法中调用即可)

        try {



            /**

             * 解析文档中的表格实体，表格包含了实体名称，只需配置 {@link ParseConfig#parseEntityName} 为 true 和相关对应行，即可开启自动解析实体名称，自动解析实体名称

             * {@link ParseConfig}中包含解析时需要的各种配置，方便灵活的支持文档中更多的表格样式

             */

            ParseConfig config  = new ParseConfig.Builder().startRow(2).parseEntityName(true).build();

            WordPOI.wordToEntity(Test.class.getResourceAsStream("Api3.docx"),false,"C:/bean/","com.king.poi.bean",config);

            //解析文档docx格式  需要传生成的对象实体名称

//            WordPOI.wordToEntity(Test.class.getResourceAsStream("Api1.docx"),false,"C:/bean/","com.king.poi.bean","Result","PageInfo");

            //解析文档docx格式  需要传生成的对象实体名称

//            WordPOI.wordToEntity(Test.class.getResourceAsStream("Api2.doc"),true,"C:/bean/","com.king.poi.bean","TestBean");

        } catch (Exception e) {

            e.printStackTrace();

        }

• 文档实体示例一（默认格式，见文档 Api1.docx）

1.1. Result （响应结果实体）

1.2. PageInfo （页码信息实体）

• 文档实体示例二（自动解析实体名称格式，见文档 Api3.docx）

1.1. 响应结果实体

1.2. 页码信息实体

更多使用详情，请查看Test中的源码使用示例或直接查看API帮助文档

代码下载:WordPOI.zip

注：根据史上最详细的iOS之事件的传递和响应机制-原理篇重新整理（适当删减及补充）。

在 iOS 中，只有继承了 UIReponder（响应者）类的对象才能接收并处理事件。其公共子类包括 UIView 、UIViewController 和 UIApplication 。

UIReponder 类中提供了以下 4 个对象方法来处理触摸事件：

/// 触摸开始
override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {}
/// 触摸移动
override func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?) {}
/// 触摸取消（在触摸结束之前）
/// 某个系统事件（例如电话呼入）会打断触摸过程
override func touchesCancelled(_ touches: Set<UITouch>, with event: UIEvent?) {}
/// 触摸结束
override func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent?) {}

注意：

如果手指同时触摸屏幕，touches(_:with:) 方法只会调用一次，Set<UITouch> 包含两个对象；

如果手指前后触摸屏幕，touches(_:with:) 会依次调用，且每次调用时 Set<UITouch> 只有一个对象

iOS 中的事件传递

事件传递和响应的整个流程

触发事件后，系统会将该事件加入到一个由 UIApplication 管理的事件队列中；
UIApplication 会从事件队列中取出最前面的事件，将之分发出去以便处理，通常，先发送事件给应用程序的主窗口（ keyWindow ）；
主窗口会在视图层次结构中<u>找到一个最适合的视图</u>来处理触摸事件；
找到适合的视图控件后，就会调用该视图控件的 touches(_:with:) 方法；
touches(_:with:) 的默认实现是将事件顺着响应者链（后面会说）一直传递下去，直到连 UIApplication 对象也不能响应事件，则将其丢弃。

如何寻找最适合的控件来处理事件

当事件触发后，系统会调用控件的 hitTest(_:with:) 方法来遍历视图的层次结构，以确定哪个子视图应该接收触摸事件，过程如下：

调用自己的 hitTest(_:with:) 方法；
判断自己能否触发事件、是否隐藏、alpha <= 0.01；
调用 point(inside:with:) 来判断触摸点是否在自己身上；
倒序遍历 subviews ，并重复前面三个步骤。直到找到包含触摸点的最上层视图，并返回这个视图，那么该视图就是那个最适合的处理事件的 view；
如果没有符合条件的子控件，就认为自己最适合处理事件，也就是自己是最适合的 view；
通俗一点来解释就是，其实系统也无法决定应该让哪个视图处理事件，那么就用遍历的方式，依次找到包含触摸点所在的最上层视图，则认为该视图最适合处理事件。

注意：

触摸事件传递的过程是从父控件传递到子控件的，如果父控件也不能接收事件，那么子控件就不可能接收事件。

寻找最适合的的 view 的底层剖析

hitTest(_:with:) 的调用时机

事件开始产生时会调用；
只要事件传递给一个控件，就会调用这个控件的 hitTest(_:with:) 方法（不管这个控件能否处理事件或触摸点是否自己身上）。
hitTest(_:with:) 的作用

返回一个最适合的 view 来处理触摸事件。

注意：

如果 hitTest(_:with:) 方法中返回 nil ，那么该控件本身和其 subview 都不是最适合的 view，而是该控件的父控件。

在默认的实现中，如果确定最终父控件是最适合的 view，那么仍然会调用其子控件的 hitTest(_:with:) 方法（不然怎么知道有没有更适合的 view？参考 如何寻找最适合的控件来处理事件。）

hitTest(_:with:) 的默认实现

override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
    // 1. 判断自己能否触发事件
    if !self.isUserInteractionEnabled || self.isHidden || self.alpha <= 0.01 {
        return nil
    }
    // 2.判断触摸点是否在自己身上
    if !self.point(inside: point, with: event) {
        return nil
    }
    // 3. 倒序遍历 `subviews` ，并重复前面两个步骤；
    // 直到找到包含触摸点的最前面的视图，并返回这个视图，那么该视图就是那个最合适的接收事件的 view；
    for view in  subviews.reversed() {
        // 把坐标转换成控件上的坐标
        let p = self.convert(point, to: view)
        if let hitView = view.hitTest(p, with: event) {
            return hitView
        }
    }
    
    return self
}

iOS 中的事件响应

找到最适合的 view 接收事件后，如果不重写实现该 view 的 touches(_:with:) 方法，那么这些方法的默认实现是将事件顺着响应者链向下传递， 将事件交给下一个响应者去处理。

可以说，响应者链是由多个响应者对象链接起来的链条。UIReponder 的一个对象属性 next 能够很好的解释这一规则。

UIReponder().next

返回响应者链中的下一个响应者，如果没有下一个响应者，则返回 nil 。

例如，UIView 调用此属性会返回管理它的 UIViewController 对象（如果有），没有则返回它的 superview；UIViewController 调用此属性会返回其视图的 superview；UIWindow 返回应用程序对象；共享的 UIApplication 对象则通常返回 nil 。

例如，我们可以通过 UIView 的 next 属性找到它所在的控制器：

extension UIView {
    var next = self.next
    while next != nil { // 符合条件就一直循环
        if let viewController = next as? UIViewController {
            return viewController
        }
        // UIView 的下一个响应控件，直到找到控制器。
        next = next?.next   
    }
    return nil
}

转自：https://www.jianshu.com/p/024f0c719715

前言

本文分享iOS开发中遇到的问题，和相关的一些思考。

正文

一、Xcode10.1 import头文件无法索引
【问题表现】如图，当import头文件的时候，索引无效，无法联想出正确的文件；

【问题分析】通过多个文件尝试，发现并非完全不能索引头文件，而是只能索引和当前文件在同级目录的头文件；
有点猜测是Xcode10.1的原因，但是在升级完的半年多时间里，都没有出现过索引。
从已有的知识来分析，很可能是Xcode的头文件搜索路径有问题，于是尝试把工程文件下的路径设置递归搜索，结果又出现以下问题：

【问题解决】在多次尝试无效之后，最终还是靠Google解决该问题。
如下路径，修改设置
Xcode --> File --> Workspace Settings --> Build System --> Legacy Build System

二、NSAssert的断点和symbolic 断点

【问题表现】NSAssert是常见的断言，可以在debug阶段快速暴露问题，但是在触发的时候无法保持上下文；
【问题分析】NSAssert的本质就是抛出一个异常，可以通过Xcode添加一个Exception Breakpoint：

如下，便可以NSAssert触发时捕获现场。

同理，在Exception Breakpoint，还有Smybolic Breakpoint较为常用。
以cookie设置接口为例，以下为一段设置cookies的代码
[[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookies];
但是有时候设置cookies的地方可能较多，此时可以添加一个Smybolic Breakpoint并设置符号为cookies。
如下，可以看到所有设置cookies的接口：

三、.m文件改成.mm文件后编译失败

【问题表现】Pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)
出错代码行： typedef void(^SSDataCallback)(NSError *error, id obj);
手动给参数添加 nullable的声明并无法解决。

【问题分析】
首先确定的是，这个编译失败实际上是一个warning，只是因为工程设置了把warning识别为error；
其次.m文件可以正常编译，并且.m文件也是开启了warning as error的设置；而从改成.mm就报错的表现和提示log来看，仍然是因为参数为空的原因导致。

【问题解决】
经过对比正常编译的.mm文件，找到一个解决方案：
1，添加NS_ASSUME_NONNULL_BEGIN在代码最前面，NS_ASSUME_NONNULL_END在代码最后面；
2、手动添加_Nullable到函数的参数；
typedef void(^SSDataCallback)(NSError * _Nullable error, id _Nullable obj);

四、UITabbar疑难杂症

问题1、batItem的染色异常问题

【问题表现】添加UITabBarItem到tabbar上，但是图片会被染成蓝色；
【问题分析】tabbar默认会帮我们染色，所以我们创建的UITabBarItem默认会被tinkColor染色的影响。
解决办法就是添加参数imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal，这样UITabBarItem的图片变不会受到tinkColor影响。

UITabBarItem *item1 = [[UITabBarItem alloc] initWithTitle:@"商城" image:[UIImage imageNamed:@"tabbar_item_store"] selectedImage:[[UIImage imageNamed:@"tabbar_item_store_selected"] imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal]];

问题2、tabbar的背景色问题

【问题表现】设置tabbar的背景色是0xFFFFFF的白色，但是实际的效果确是灰白色，并不是全白色；
【问题分析】tabbar默认是透明的（属性translucent），会对tabbar下面的视图进行高斯模糊，然后再与背景色混合。
【问题解决】
1、自由做法，addSubview:一个view到tabbar上，接下来自己绘制4个按钮；（可操作性强，缺点是tabbar的逻辑需要自己再实现一遍）
2、改变tabbar透明度做法，设置translucent=YES，再修改背景色；（引入一个巨大的坑，导致UITabbarViewController上面的子VC的self.view属性高度会变化！）
3、空白图做法，把背景图都用一张空白的图片替代，如下：（最终采纳的做法）

self.tabBar.backgroundImage = [[UIImage alloc] init];
    self.tabBar.backgroundColor = [UIColor whiteColor];

问题3、tabbar顶部的线条问题

【问题表现】UITabbar默认在tabbar的顶部会有一条灰色的线，但是并没有一个属性可以修改其颜色。
【问题分析】从Xcode的工具来看，这条线是一个UIImageView：

再从UITabbar的头文件来看，这条线的图片可能是shadowImage。
【问题解决】将shadowImage用一张空白的图片替代，然后自己再添加想要的线条大小和颜色。

self.tabBar.shadowImage = [[UIImage alloc] init];
    UIView *lineView = [[UIView alloc] initWithFrame:CGRectMake(0, 0, self.tabBar.width, 0.5)];
    lineView.backgroundColor = [UIColor colorWithHexString:@"e8e8e8"];
    [self.tabBar addSubview:lineView];

五、特殊机型出现的异常现象

1、iOS 11.4 充电时无法正常获取电量

【问题表现】在某个场景需要获取电池，于是通过以下addObserverForName:UIDeviceBatteryLevelDidChangeNotification的方式监听电量的变化，在iOS 12的机型表现正常，但是在iOS 11.4的机型上会出现无法获取电量的原因。

void (^block)(NSNotification *notification) = ^(NSNotification *notification) {
        SS_STRONG_SELF(self);
        NSLog(@"%@", self);
        self.batteryView.width = (self.batteryImageView.width - Padding_battery_width) * [UIDevice currentDevice].batteryLevel;
    };
    //监视电池剩余电量
    [[NSNotificationCenter defaultCenter] addObserverForName:UIDeviceBatteryLevelDidChangeNotification
                                                      object:nil
                                                       queue:[NSOperationQueue mainQueue]
                                                  usingBlock:block];

【问题分析】从电量获取的api开始入手分析，在获取电量之前，需要显式调用接口
[UIDevice currentDevice].batteryMonitoringEnabled = YES;
于是点击batteryMonitoringEnabled属性进入UIDevice.h，发现有个batteryState属性，里面有一个状态是充电UIDeviceBatteryStateCharging，但是对问题并无帮助；
点击UIDeviceBatteryLevelDidChangeNotification发现还有一个通知是UIDeviceBatteryStateDidChangeNotification，猜测可能是充电状态下的回调有所不同；
【问题解决】最终通过添加新通知的监听解决。该问题并不太难，但是养成多看.h文件相关属性的习惯，还是会有好处。

[[NSNotificationCenter defaultCenter] addObserverForName:UIDeviceBatteryStateDidChangeNotification
                                                      object:nil
                                                       queue:[NSOperationQueue mainQueue]
                                                  usingBlock:block];

2、iOS 10.3的UILabel富文本排版异常

【问题表现】有一段文本的显示需要设置首行缩进，所以用的富文本添加段落属性的方式；但是在iOS 10.3的6p机型上出现异常现象，如下：
测试文本：contentStr=@"一年佛山电脑放山东难道是防空洞念佛"
如下，最后的字符没有显示完全。
实现方式是计算得到富文本，然后赋值给UILabel，再调用-sizeToFit的接口。

以上的问题仅在一行的时候出现异常，两行又恢复正常。

【问题分析】
从表现来看，是sizeToFit的时候宽度结算出错；通过多次尝试，发现是少计算了大概两个空格的距离，也即是首行缩进的距离。
【问题解决】
方法1、去除首行缩进，每行增加两个空格；
方法2、一行的时候，把宽度设置到最大；
如何判断1行的情况，可以用以下的代码简短判断

if (self.contentLabel.height < self.contentLabel.font.lineHeight * 2) { // 一行的情况
        self.contentLabel.width = self.width - 40;
    }

总结

日常开发遇到的问题，如果解决过程超过10分钟，我都会记录下来。
这些问题有的很简单，仅仅是改个配置（如第一个Xcode索引问题），但是在解决过程中还是走了一些弯路，因为完全没想过可能会去改Workspace setting，都是在Build setting修改进行尝试。
还有些问题纯粹是特定现象，比如说特殊机型问题，只是做一个备忘和提醒

链接：https://www.jianshu.com/p/6c964411fc03

GitHub 地址：YBTaskScheduler
支持 cocopods，使用简便，效率不错，一个性能优化的基础组件。

前言

前些时间有好几个技术朋友问过笔者类似的问题：主线程需要执行大量的任务导致卡顿如何处理？异步任务量级过大导致 CPU 和内存压力过高如何优化？

解决类似的问题可以用几个思路：降频、淘汰、优先级调度。

本来解决这些问题并不需要很复杂的代码，但是涉及到一些 C 代码并且要注意线程安全的问题，所以笔者就做了这样一个轮子，以解决任务调度引发的性能问题。

本文讲述 YBTaskScheduler 的原理，读者朋友需要有一定的 iOS 基础，了解一些性能优化的知识，基本用法可以先看看 GitHub README，DEMO 中也有一个相册列表的应用案例。

一、需求分析

就拿 DEMO 中的案例来说明，一个显示相册图片的列表：

实现图中业务，必然考虑到几个耗时操作：

1、从相册读取图片
2、解压图片
3、圆角处理
4、绘制图片

理所当然的想到处理方案（DEMO中有实现）：

1、异步读取图片
2、异步裁剪图片为正方形（这个过程中就解压了）
3、异步裁剪圆角
4、回到主线程绘制图片

一整套流程下来，貌似需求很好的解决了，但是当快速滑动列表时，会发现 CPU 和内存的占用会比较高（这取决于从相册中读取并显示多大的图片）。当然 DEMO 中按照屏幕的物理像素处理，就算不使用任务调度器组件快速滑动列表也基本不会有掉帧的现象。考虑到老旧设备或者技术人员的水平，很多时候这种需求会导致严重的 CPU 和内存负担，甚至导致闪退。

以上处理方案可能存在的性能瓶颈：

从相册读取图片、裁剪图片，处理圆角、主线程绘制等操作会导致 CPU 计算压力过大。
同时解压的图片、同时绘制的图片过多导致内存峰值飙升（更不要说做了图片的缓存）。
任何一种情况都可能导致客户端卡死或者闪退，结合业务来分析问题，会发现优化的思路还是不难找到：

· 滑出屏幕的图片不会存在绘制压力，而当前屏幕中的图片会在一个 RunLoop 循环周期绘制，可能造成掉帧。所以可以减少一个 RunLoop 循环周期所绘制的图片数量。
· 快速滑动列表，大量的异步任务直接交由 CPU 执行，然而滑出屏幕的图片已经没有处理它的意义了。所以可以提前删除掉已经滑出屏幕的异步任务，以此来降低 CPU 和内存压力。

没错， YBTaskScheduler 组件就是替你做了这些事情 ，而且还不止于此。

二、命令模式与 RunLoop

想要管理这些复杂的任务，并且在合适的时机调用它们，自然而然的就想到了命令模式。意味着任务不能直接执行，而是把任务作为一个命令装入容器。

在 Objective-C 中，显然 Block 代码块能解决延迟执行这个问题：

[_scheduler addTask:^{
     /* 
     具体任务代码
     解压图片、裁剪图片、访问磁盘等 
     */
}];

然后组件将这些代码块“装起来”，组件由此“掌握”了所有的任务，可以自由的决定何时调用这些代码块，何时对某些代码块进行淘汰，还可以实现优先级调度。

既然是命令模式，还差一个 Invoker (调用程序)，即何时去触发这些任务。结合 iOS 的技术特点，可以监听 RunLoop 循环周期来实现：

static void addRunLoopObserver() {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        taskSchedulers = [NSHashTable weakObjectsHashTable];
        CFRunLoopObserverRef observer = CFRunLoopObserverCreate(CFAllocatorGetDefault(), kCFRunLoopBeforeWaiting | kCFRunLoopExit, true, 0xFFFFFF, runLoopObserverCallBack, NULL);
        CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
        CFRelease(observer);
    });
}

然后在回调函数中进行任务的调度。

三、策略模式

考虑到任务的淘汰策略和优先级调度，必然需要一些高效数据结构来支撑，为了提高处理效率，笔者直接使用了 C++ 的数据结构：deque和priority_queue。

因为要实现任务淘汰，所以使用deque双端队列来模拟栈和队列，而不是直接使用stack和queue。使用priority_queue优先队列来处理自定义的优先级调度，它的缺点是不能删除低优先级节点，为了节约时间成本姑且够用。

具体的策略：

栈：后加入的任务先执行（可以理解为后加入的任务优先级高），优先淘汰先加入的任务。
队列：先加入的任务先执行（可以理解为先加入的任务优先级高），优先淘汰后加入的任务。
优先队列：自定义任务优先级，不支持任务淘汰。
实际上组件是推荐使用栈和队列这两种策略，因为插入和取出的时间复杂度是常数级的，需要定制任务的优先级时才考虑使用优先队列，因为其插入复杂度是 O(logN) 的。

至此，整个组件的业务是比较清晰了，组件需要让这三种处理方式可以自由的变动，所以采用策略模式来处理，下面是 UML 类图：

嗯，这是个挺标准的策略模式。

四、线程安全

由于任务的调度可能在任意线程，所以必须要做好容器（栈、队列、优先队列）访问的线程安全问题，组件是使用pthread_mutex_t和dispatch_once来保证线程安全，同时笔者尽量减少临界区来提高性能。值得注意的是，如果不会存在线程安全的代码就不要去加锁了。

后语

部分技术细节就不多说了，组件代码量比较少，如果感兴趣可以直接看源码。实际上这个组件的应用场景并不是很多，在项目稳定需要做深度的性能优化时可能会比较需要它，并且希望使用它的人也能了解一些原理，做到胸有成竹，才能灵活的运用。

转自：https://www.jianshu.com/p/f2a610c77d26

LiveData 的历史要追溯到 2017 年。彼时，观察者模式有效简化了开发，但诸如 RxJava 一类的库对新手而言有些太过复杂。为此，架构组件团队打造了 LiveData: 一个专用于 Android 的具备自主生命周期感知能力的可观察的数据存储器类。LiveData 被有意简化设计，这使得开发者很容易上手；而对于较为复杂的交互数据流场景，建议您使用 RxJava，这样两者结合的优势就发挥出来了。

DeadData?

LiveData 对于 Java 开发者、初学者或是一些简单场景而言仍是可行的解决方案。而对于一些其他的场景，更好的选择是使用 Kotlin 数据流 (Kotlin Flow)。虽说数据流 (相较 LiveData) 有更陡峭的学习曲线，但由于它是 JetBrains 力挺的 Kotlin 语言的一部分，且 Jetpack Compose 正式版即将发布，故两者配合更能发挥出 Kotlin 数据流中响应式模型的潜力。

此前一段时间，我们探讨了 如何使用 Kotlin 数据流 来连接您的应用当中除了视图和 View Model 以外的其他部分。而现在我们有了 一种更安全的方式来从 Android 的界面中获得数据流，已经可以创作一份完整的迁移指南了。

在这篇文章中，您将学到如何把数据流暴露给视图、如何收集数据流，以及如何通过调优来适应不同的需求。

数据流: 把简单复杂化，又把复杂变简单

LiveData 就做了一件事并且做得不错: 它在 缓存最新的数据 和感知 Android 中的生命周期的同时将数据暴露了出来。稍后我们会了解到 LiveData 还可以 启动协程 和 创建复杂的数据转换，这可能会需要花点时间。

接下来我们一起比较 LiveData 和 Kotlin 数据流中相对应的写法吧:

#1: 使用可变数据存储器暴露一次性操作的结果

这是一个经典的操作模式，其中您会使用协程的结果来改变状态容器:

△ 将一次性操作的结果暴露给可变的数据容器 (LiveData)

<!-- Copyright 2020 Google LLC.  

   SPDX-License-Identifier: Apache-2.0 -->



class MyViewModel {

    private val _myUiState = MutableLiveData<Result<UiState>>(Result.Loading)

    val myUiState: LiveData<Result<UiState>> = _myUiState



// 从挂起函数和可变状态中加载数据

    init {

        viewModelScope.launch { 

            val result = ...

            _myUiState.value = result

        }

    }

}

如果要在 Kotlin 数据流中执行相同的操作，我们需要使用 (可变的) StateFlow (状态容器式可观察数据流):

△ 使用可变数据存储器 (StateFlow) 暴露一次性操作的结果

class MyViewModel {

    private val _myUiState = MutableStateFlow<Result<UiState>>(Result.Loading)

    val myUiState: StateFlow<Result<UiState>> = _myUiState



    // 从挂起函数和可变状态中加载数据

    init {

        viewModelScope.launch { 

            val result = ...

            _myUiState.value = result

        }

    }

}

StateFlow 是 SharedFlow 的一个比较特殊的变种，而 SharedFlow 又是 Kotlin 数据流当中比较特殊的一种类型。StateFlow 与 LiveData 是最接近的，因为:

• 它始终是有值的。


• 它的值是唯一的。


• 它允许被多个观察者共用 (因此是共享的数据流)。


• 它永远只会把最新的值重现给订阅者，这与活跃观察者的数量是无关的。

当暴露 UI 的状态给视图时，应该使用 StateFlow。这是一种安全和高效的观察者，专门用于容纳 UI 状态。

#2: 把一次性操作的结果暴露出来

这个例子与上面代码片段的效果一致，只是这里暴露协程调用的结果而无需使用可变属性。

如果使用 LiveData，我们需要使用 LiveData 协程构建器:

△ 把一次性操作的结果暴露出来 (LiveData)

class MyViewModel(...) : ViewModel() {

    val result: LiveData<Result<UiState>> = liveData {

        emit(Result.Loading)

        emit(repository.fetchItem())

    }

}

由于状态容器总是有值的，那么我们就可以通过某种 Result 类来把 UI 状态封装起来，比如加载中、成功、错误等状态。

与之对应的数据流方式则需要您多做一点配置:

△ 把一次性操作的结果暴露出来 (StateFlow)

class MyViewModel(...) : ViewModel() {

    val result: StateFlow<Result<UiState>> = flow {

        emit(repository.fetchItem())

    }.stateIn(

        scope = viewModelScope, 

        started = WhileSubscribed(5000), //由于是一次性操作，也可以使用 Lazily 

        initialValue = Result.Loading

    )

}

stateIn 是专门将数据流转换为 StateFlow 的运算符。由于需要通过更复杂的示例才能更好地解释它，所以这里暂且把这些参数放在一边。

#3: 带参数的一次性数据加载

比方说您想要加载一些依赖用户 ID 的数据，而信息来自一个提供数据流的 AuthManager:

△ 带参数的一次性数据加载 (LiveData)

使用 LiveData 时，您可以用类似这样的代码:

class MyViewModel(authManager..., repository...) : ViewModel() {

    private val userId: LiveData<String?> = 

        authManager.observeUser().map { user -> user.id }.asLiveData()



    val result: LiveData<Result<Item>> = userId.switchMap { newUserId ->

        liveData { emit(repository.fetchItem(newUserId)) }

    }

}

switchMap 是数据变换中的一种，它订阅了 userId 的变化，并且其代码体会在感知到 userId 变化时执行。

如非必须要将 userId 作为 LiveData 使用，那么更好的方案是将流式数据和 Flow 结合，并将最终的结果 (result) 转化为 LiveData。

class MyViewModel(authManager..., repository...) : ViewModel() {

    private val userId: Flow<UserId> = authManager.observeUser().map { user -> user.id }



    val result: LiveData<Result<Item>> = userId.mapLatest { newUserId ->

       repository.fetchItem(newUserId)

    }.asLiveData()

}

如果改用 Kotlin Flow 来编写，代码其实似曾相识:

△ 带参数的一次性数据加载 (StateFlow)

class MyViewModel(authManager..., repository...) : ViewModel() {

    private val userId: Flow<UserId> = authManager.observeUser().map { user -> user.id }



    val result: StateFlow<Result<Item>> = userId.mapLatest { newUserId ->

        repository.fetchItem(newUserId)

    }.stateIn(

        scope = viewModelScope, 

        started = WhileSubscribed(5000), 

        initialValue = Result.Loading

    )

}

假如说您想要更高的灵活性，可以考虑显式调用 transformLatest 和 emit 方法:

val result = userId.transformLatest { newUserId ->

        emit(Result.LoadingData)

        emit(repository.fetchItem(newUserId))

    }.stateIn(

        scope = viewModelScope, 

        started = WhileSubscribed(5000), 

        initialValue = Result.LoadingUser //注意此处不同的加载状态

    )

#4: 观察带参数的数据流

接下来我们让刚才的案例变得更具交互性。数据不再被读取，而是被观察，因此我们对数据源的改动会直接被传递到 UI 界面中。

继续刚才的例子: 我们不再对源数据调用 fetchItem 方法，而是通过假定的 observeItem 方法获取一个 Kotlin 数据流。

若使用 LiveData，可以将数据流转换为 LiveData 实例，然后通过 emitSource 传递数据的变化。

△ 观察带参数的数据流 (LiveData)

class MyViewModel(authManager..., repository...) : ViewModel() {

    private val userId: LiveData<String?> = 

        authManager.observeUser().map { user -> user.id }.asLiveData()



    val result = userId.switchMap { newUserId ->

        repository.observeItem(newUserId).asLiveData()

    }

}

或者采用更推荐的方式，把两个流通过 flatMapLatest 结合起来，并且仅将最后的输出转换为 LiveData:

class MyViewModel(authManager..., repository...) : ViewModel() {

    private val userId: Flow<String?> = 

        authManager.observeUser().map { user -> user?.id }



    val result: LiveData<Result<Item>> = userId.flatMapLatest { newUserId ->

        repository.observeItem(newUserId)

    }.asLiveData()

}

使用 Kotlin 数据流的实现方式非常相似，但是省下了 LiveData 的转换过程:

△ 观察带参数的数据流 (StateFlow)

class MyViewModel(authManager..., repository...) : ViewModel() {

    private val userId: Flow<String?> = 

        authManager.observeUser().map { user -> user?.id }



    val result: StateFlow<Result<Item>> = userId.flatMapLatest { newUserId ->

        repository.observeItem(newUserId)

    }.stateIn(

        scope = viewModelScope, 

        started = WhileSubscribed(5000), 

        initialValue = Result.LoadingUser

    )

}

每当用户实例变化，或者是存储区 (repository) 中用户的数据发生变化时，上面代码中暴露出来的 StateFlow 都会收到相应的更新信息。

#5: 结合多种源: MediatorLiveData -> Flow.combine

MediatorLiveData 允许您观察一个或多个数据源的变化情况，并根据得到的新数据进行相应的操作。通常可以按照下面的方式更新 MediatorLiveData 的值:

val liveData1: LiveData<Int> = ...

val liveData2: LiveData<Int> = ...



val result = MediatorLiveData<Int>()



result.addSource(liveData1) { value ->

    result.setValue(liveData1.value ?: 0 + (liveData2.value ?: 0))

}

result.addSource(liveData2) { value ->

    result.setValue(liveData1.value ?: 0 + (liveData2.value ?: 0))

}

同样的功能使用 Kotlin 数据流来操作会更加直接:

val flow1: Flow<Int> = ...

val flow2: Flow<Int> = ...



val result = combine(flow1, flow2) { a, b -> a + b }

此处也可以使用 combineTransform 或者 zip 函数。

通过 stateIn 配置对外暴露的 StateFlow

早前我们使用 stateIn 中间运算符来把普通的流转换成 StateFlow，但转换之后还需要一些配置工作。如果现在不想了解太多细节，只是想知道怎么用，那么可以使用下面的推荐配置:

val result: StateFlow<Result<UiState>> = someFlow

    .stateIn(

        scope = viewModelScope, 

        started = WhileSubscribed(5000), 

        initialValue = Result.Loading

    )

不过，如果您想知道为什么会使用这个看似随机的 5 秒的 started 参数，请继续往下读。

根据文档，stateIn 有三个参数:?

@param scope 共享开始时所在的协程作用域范围



@param started 控制共享的开始和结束的策略



@param initialValue 状态流的初始值



当使用 [SharingStarted.WhileSubscribed] 并带有 `replayExpirationMillis` 参数重置状态流时，也会用到 initialValue。

started 接受以下的三个值:

• Lazily: 当首个订阅者出现时开始，在 scope 指定的作用域被结束时终止。


• Eagerly: 立即开始，而在 scope 指定的作用域被结束时终止。


• WhileSubscribed: 这种情况有些复杂 (后文详聊)。

对于那些只执行一次的操作，您可以使用 Lazily 或者 Eagerly。然而，如果您需要观察其他的流，就应该使用 WhileSubscribed 来实现细微但又重要的优化工作，参见后文的解答。

WhileSubscribed 策略

WhileSubscribed 策略会在没有收集器的情况下取消上游数据流。通过 stateIn 运算符创建的 StateFlow 会把数据暴露给视图 (View)，同时也会观察来自其他层级或者是上游应用的数据流。让这些流持续活跃可能会引起不必要的资源浪费，例如一直通过从数据库连接、硬件传感器中读取数据等等。当您的应用转而在后台运行时，您应当保持克制并中止这些协程。

WhileSubscribed 接受两个参数:

public fun WhileSubscribed(

   stopTimeoutMillis: Long = 0,

   replayExpirationMillis: Long = Long.MAX_VALUE

)

超时停止

根据其文档:

stopTimeoutMillis 控制一个以毫秒为单位的延迟值，指的是最后一个订阅者结束订阅与停止上游流的时间差。默认值是 0 (立即停止)。

这个值非常有用，因为您可能并不想因为视图有几秒钟不再监听就结束上游流。这种情况非常常见——比如当用户旋转设备时，原来的视图会先被销毁，然后数秒钟内重建。

liveData 协程构建器所使用的方法是 添加一个 5 秒钟的延迟，即如果等待 5 秒后仍然没有订阅者存在就终止协程。前文代码中的 WhileSubscribed (5000) 正是实现这样的功能:

class MyViewModel(...) : ViewModel() {

    val result = userId.mapLatest { newUserId ->

        repository.observeItem(newUserId)

    }.stateIn(

        scope = viewModelScope, 

        started = WhileSubscribed(5000), 

        initialValue = Result.Loading

    )

}

这种方法会在以下场景得到体现:

• 用户将您的应用转至后台运行，5 秒钟后所有来自其他层的数据更新会停止，这样可以节省电量。


• 最新的数据仍然会被缓存，所以当用户切换回应用时，视图立即就可以得到数据进行渲染。


• 订阅将被重启，新数据会填充进来，当数据可用时更新视图。

数据重现的过期时间

如果用户离开应用太久，此时您不想让用户看到陈旧的数据，并且希望显示数据正在加载中，那么就应该在 WhileSubscribed 策略中使用 replayExpirationMillis 参数。在这种情况下此参数非常适合，由于缓存的数据都恢复成了 stateIn 中定义的初始值，因此可以有效节省内存。虽然用户切回应用时可能没那么快显示有效数据，但至少不会把过期的信息显示出来。

replayExpirationMillis 配置了以毫秒为单位的延迟时间，定义了从停止共享协程到重置缓存 (恢复到 stateIn 运算符中定义的初始值 initialValue) 所需要等待的时间。它的默认值是长整型的最大值 Long.MAX_VALUE (表示永远不将其重置)。如果设置为 0，可以在符合条件时立即重置缓存的数据。

从视图中观察 StateFlow

我们此前已经谈到，ViewModel 中的 StateFlow 需要知道它们已经不再需要监听。然而，当所有的这些内容都与生命周期 (lifecycle) 结合起来，事情就没那么简单了。

要收集一个数据流，就需要用到协程。Activity 和 Fragment 提供了若干协程构建器:

• Activity.lifecycleScope.launch : 立即启动协程，并且在本 Activity 销毁时结束协程。


• Fragment.lifecycleScope.launch : 立即启动协程，并且在本 Fragment 销毁时结束协程。


• Fragment.viewLifecycleOwner.lifecycleScope.launch : 立即启动协程，并且在本 Fragment 中的视图生命周期结束时取消协程。

LaunchWhenStarted 和 LaunchWhenResumed

对于一个状态 X，有专门的 launch 方法称为 launchWhenX。它会在 lifecycleOwner 进入 X 状态之前一直等待，又在离开 X 状态时挂起协程。对此，需要注意对应的协程只有在它们的生命周期所有者被销毁时才会被取消。

△ 使用 launch/launchWhenX 来收集数据流是不安全的

当应用在后台运行时接收数据更新可能会引起应用崩溃，但这种情况可以通过将视图的数据流收集操作挂起来解决。然而，上游数据流会在应用后台运行期间保持活跃，因此可能浪费一定的资源。

这么说来，目前我们对 StateFlow 所进行的配置都是无用功；不过，现在有了一个新的 API。

lifecycle.repeatOnLifecycle 前来救场

这个新的协程构建器 (自 lifecycle-runtime-ktx 2.4.0-alpha01 后可用) 恰好能满足我们的需要: 在某个特定的状态满足时启动协程，并且在生命周期所有者退出该状态时停止协程。

△ 不同数据流收集方法的比较

比如在某个 Fragment 的代码中:

onCreateView(...) {

    viewLifecycleOwner.lifecycleScope.launch {

        viewLifecycleOwner.lifecycle.repeatOnLifecycle(STARTED) {

            myViewModel.myUiState.collect { ... }

        }

    }

}

当这个 Fragment 处于 STARTED 状态时会开始收集流，并且在 RESUMED 状态时保持收集，最终在 Fragment 进入 STOPPED 状态时结束收集过程。如需获取更多信息，请参阅: 使用更为安全的方式收集 Android UI 数据流。

结合使用 repeatOnLifecycle API 和上面的 StateFlow 示例可以帮助您的应用妥善利用设备资源的同时，发挥最佳性能。

△ 该 StateFlow 通过 WhileSubscribed(5000) 暴露并通过 repeatOnLifecycle(STARTED) 收集

注意: 近期在 Data Binding 中加入的 StateFlow 支持 使用了 launchWhenCreated 来描述收集数据更新，并且它会在进入稳定版后转而使用 repeatOnLifecyle。

对于数据绑定，您应该在各处都使用 Kotlin 数据流并简单地加上 asLiveData() 来把数据暴露给视图。数据绑定会在 lifecycle-runtime-ktx 2.4.0 进入稳定版后更新。

总结

通过 ViewModel 暴露数据，并在视图中获取的最佳方式是:

• ?? 使用带超时参数的 WhileSubscribed 策略暴露 StateFlow。[示例 1]


• ?? 使用 repeatOnLifecycle 来收集数据更新。[示例 2]

如果采用其他方式，上游数据流会被一直保持活跃，导致资源浪费:

• ? 通过 WhileSubscribed 暴露 StateFlow，然后在 lifecycleScope.launch/launchWhenX 中收集数据更新。


• ? 通过 Lazily/Eagerly 策略暴露 StateFlow，并在 repeatOnLifecycle 中收集数据更新。

当然，如果您并不需要使用到 Kotlin 数据流的强大功能，就用 LiveData 好了 :)

向 Manuel、Wojtek、Yigit、Alex Cook、Florina 和 Chris 致谢！

1、前言

本案例是我本人遇到的真实案例，因查找原因的过程一度让我崩溃，我相信不少人也遇到过相同的问题，故将其记录下来，希望对大家有帮助，本案例使用RxHttp 2.6.4 + OkHttp 4.9.1版本，当然，如果你使用Retrofit等其它基于OkHttp封装的框架，且用到监听上传进度功能，那么很大概率你也会遇到这个问题，请耐心看完，如果你想直接看到结果，划到文章末尾即可。

2、问题描述

事情是这样的，有一段文件上传的代码，如下：

fun uploadFiles(fileList: List<File>) {

    RxHttp.postForm("/server/...")     

        .add("key", "value")           

        .addFiles("files", fileList)   

        .upload {                       

            //上传进度回调                   

        }                              

        .asString()                    

        .subscribe({                    

            //成功回调                     

        }, {                            

            //失败回调                     

        })                             

}                                                                                  

这段代码在写完后很长一段时间内都是ok的，突然有一天，执行这段代码居然报错了，日志如下：

这个异常是100%出现的，很熟悉的异常，具体原因就是，数据流被关闭了，但依然往里面写数据，来看看最后抛异常的地方，如下：

可以看到，方法里面第一行代码就判断数据流是否已关闭，是的话，抛出异常。

注：如果你是RxHttp使用者，正在尝试这段代码，发现没问题，也不要惊讶，因为这需要在Android Studio特定场景下执行才会出现，而且是相对高频使用的场景，请待我一步步揭晓答案

3、一探究竟

本着出现问题，先定位到自己代码的原则，打开ProgressRequestBody类76行看看，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    private BufferedSink bufferedSink;

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

        if (bufferedSink == null) {

            bufferedSink = Okio.buffer(sink(sink));

        }

        requestBody.writeTo(bufferedSink);   //这里是76行

        bufferedSink.flush();

    }

}

ProgressRequestBody继承了okhttp3.RequestBody类，作用是监听上传进度；显然最后执行到这里时，数据流已经被关闭了，从日志里可以看到，最后一次调用ProgressRequestBody#writeTo(BufferedSink)方法的地方在CallServerInterceptor拦截器的59行，打开看看

class CallServerInterceptor(private val forWebSocket: Boolean) : Interceptor {



    //省略相关代码 

    @Throws(IOException::class)

    override fun intercept(chain: Interceptor.Chain): Response {

        //省略相关代码

        if (responseBuilder == null) {

            if (requestBody.isDuplex()) {

              exchange.flushRequest()

              val bufferedRequestBody = exchange.createRequestBody(request, true).buffer()

              requestBody.writeTo(bufferedRequestBody)

            } else {

              val bufferedRequestBody = exchange.createRequestBody(request, false).buffer()

              requestBody.writeTo(bufferedRequestBody)  //这里是59行

              bufferedRequestBody.close()         //数据写完，将数据流关闭

            }

        }

    }

}

熟悉OkHttp原理的同学应该知道，CallServerInterceptor拦截器是okhttp拦截器链的最后一个拦截器，将客户端数据写出到服务端，就是在这里实现的，也就是59行，那问题就来了，数据都还没写出去，数据流怎么就关闭了呢？这令我百思不得其解，毫无头绪。

于是乎，我做了很多无用功，如：重新检查代码，看看是否有手动关闭数据流的地方，显然没有找到；接着，实在没有办法，代码回滚，回滚到最初写这段代码的版本，我满怀期待的以为，这下应该没问题了，可尝试过后，依旧报java.lang.IllegalStateException: closed，成年人的崩溃就在这一瞬间，我陷入了绝境，已经消耗5个小时在这个问题上，此时已晚上23：30，看来又是一个不眠夜。

习惯告诉我，一个问题很久没查出来，可以先放弃，好吧，拔手机关电脑，洗澡睡觉。

半小时后，我躺在床上，很难受，于是我拿出手机，打开app，再试了试上传功能，惊奇的发现，可以了，上传成功了，这。。。。一脸懵逼，我找谁说理去，虽然没问题了，但问题没找到，作为一名初级程序员，这我无法接受。

精神的力量把我从床上扶了起来，再次打开电脑，连上手机，这次，果然有了新的收获，也一下子刷新了我的世界观；当我再次打开app，尝试上传文件时，一样的错误出现在我眼前，What??? 刚才还好好的，连上电脑就不行了？

ok，我彻底没脾气了，拔掉手机，重启app，再试，没问题了，再次连上电脑，再试，问题又出来了。。

此时，我的心态有了些许的好转，毕竟有了新的调查方向，我再次查看错误日志，发现了一个很奇怪的地方，如下：

com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor是从哪冒出来的？在我的认知里，OkHttp3是没有这个拦截器的，为了验证我的认知，再次查看okhttp3源码，如下：

确定是没有添加这个拦截器的，仔细看日志发现，OkHttp3Interceptor在CallServerInterceptor、ConnectInterceptor之间执行的，那就只有一个解释，OkHttp3Interceptor是通过addNetworkInterceptor方法添加，现在就好办了，全局搜索addNetworkInterceptor就知道是谁添加的，哪里添加的，很可惜，未找到调用此方法的源码，似乎又陷入了绝境。

那就只能开启调试，看看OkHttp3Interceptor是否在OkHttpClient对象的networkInterceptors网络拦截器列表里，一调试，果然有发现，如下：

调试点击下一步，神奇的事情就发生了，如下：

这怎么解释？networkInterceptors.size始终是0，interceptors.size是如何加1变为5的？再来看看，加的1是什么，如下：

很熟悉，就是我们之前提到的OkHttp3Interceptor，这是如何做到的？只有一个解释，OkHttpClient#networkInterceptors()方法被字节码插桩技术插入了新的代码，为了验证我的想法，我做了以下实验：

可以看到，我直接new了一个OkHttpClient对象，啥也没配置，调用networkInterceptors()方法，就获取了OkHttp3Interceptor拦截器，但OkHttpClient对象里的networkInterceptors列表中是没有这个拦截器的，这就证实了我的想法。

那现在的问题就是，OkHttp3Interceptor是谁注入的？跟文件上传失败是否有直接的关系？

OkHttp3Interceptor是谁注入的？

先来探索第一个问题，通过OkHttp3Interceptor类的包名class com.android.tools.profiler.agent.okhttp，我有以下3点猜测

• 包名有com.android.tools,应该跟 Android 官方有关系




• 包名有agent,又是拦截器，应该跟网络代理，也就是网络监控有关




• 最后一点，也是最重要的，包名有profiler，这让我联想到了Android Studio(以下简称AS)里Profiler网络分析器

果然，在Google的源码中，真找到了OkHttp3Interceptor类，看看相关代码：

public final class OkHttp3Interceptor implements Interceptor {



    //省略相关代码

    @Override

    public Response intercept(Interceptor.Chain chain) throws IOException {

        Request request = chain.request();

        HttpConnectionTracker tracker = null;

        try {

            tracker = trackRequest(request);  //1、追踪请求体

        } catch (Exception ex) {

            StudioLog.e("Could not track an OkHttp3 request", ex);

        }

        Response response;

        try {

            response = chain.proceed(request);

        } catch (IOException ex) {

            

        }

        try {

            if (tracker != null) {

                response = trackResponse(tracker, response);  //2、追踪响应体

            }

        } catch (Exception ex) {

            StudioLog.e("Could not track an OkHttp3 response", ex);

        } 

        return response;

    }

可以确定它就是一个网络监控器，但它是不是AS的网络监听器，我却还持怀疑态度，因为我这个项目没开启Profiler分析器，但我最近在开发room数据库相关功能，开启了数据分析器Database Inspector，难道跟这个有关？我尝试关掉Database Inspector，并且重启app，再次尝试文件上传，居然成功了，是真的成功了，你能信？我也不信，于是，再次开启Database Inspector，再次尝试文件上传，失败了，异常跟之前的一模一样；接着，我关闭Database Inspector，并且打开Profiler分析器，再次尝试文件上传，一样失败了。

我想到这里，基本可以认定OkHttp3Interceptor就是Profiler里面的网络监控器，但也好像缺乏直接证据，于是，我尝试改了下ProgressRequestBody类，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    private BufferedSink bufferedSink;

    

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

        //如果调用方是OkHttp3Interceptor，不写请求体，直接返回

        if (sink.toString().contains(

            "com.android.tools.profiler.support.network.HttpTracker$OutputStreamTracker"))

            return;

        if (bufferedSink == null) {

            bufferedSink = Okio.buffer(sink(sink));

        }

        requestBody.writeTo(bufferedSink);  

        bufferedSink.flush();

    }

}

以上代码，仅仅加了一句if语句，这条语句可以判断当前调用方是不是OkHttp3Interceptor，是的话，不写请求体，直接返回；如果OkHttp3Interceptor就是Profiler里的网络监控器，那么此时Profiler里应该是看不到请求体的，也就是看不到请求参数，如下：

可以看到，Profiler里的网络监控器，没有监控到请求参数。

这就证实了OkHttp3Interceptor的确是Profiler里的网络监控器，也就是AS动态注入的。

OkHttp3Interceptor 与文件上传是否有直接的关系？

通过上面的案例分析，显然是有直接关系的，当你未打开Database Inspector、Profiler时，文件上传一切正常。

OkHttp3Interceptor是如何影响文件上传的？

回到正题，OkHttp3Interceptor是如何影响文件上传的？这个就需要继续分析OkHttp3Interceptor的源码，来看看追踪请求体的代码：

public final class OkHttp3Interceptor implements Interceptor {



    private HttpConnectionTracker trackRequest(Request request) throws IOException {

        StackTraceElement[] callstack =

                OkHttpUtils.getCallstack(request.getClass().getPackage().getName());

        HttpConnectionTracker tracker =

                HttpTracker.trackConnection(request.url().toString(), callstack);

        tracker.trackRequest(request.method(), toMultimap(request.headers()));

        if (request.body() != null) {

            OutputStream outputStream =

                    tracker.trackRequestBody(OkHttpUtils.createNullOutputStream());

            BufferedSink bufferedSink = Okio.buffer(Okio.sink(outputStream));

            request.body().writeTo(bufferedSink);  // 1、将请求体写入到BufferedSink中

            bufferedSink.close();                  // 2、关闭BufferedSink

        }

        return tracker;

    }



}

想到这里问题就很清楚了，上面备注的第一代码中request.body()，拿到的就是ProgressRequestBody对象，随后调用其writeTo(BufferedSink)方法，传入BufferedSink对象，方法执行完，就将BufferedSink对象关闭了，然而，ProgressRequestBody里却将BufferedSink声明为成员变量，并且为空时才会赋值，这就导致后续CallServerInterceptor调用其writeTo(BufferedSink)方法时，使用的还是上一个已关闭的BufferedSink对象，此时再往里面写数据，自然就java.lang.IllegalStateException: closed异常了。

4、如何解决

知道了具体的原因，就好解决，将ProgressRequestBody里面的BufferedSink对象改为局部变量即可，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

        BufferedSink bufferedSink = Okio.buffer(sink(sink));

        requestBody.writeTo(bufferedSink);  

        bufferedSink.colse();

    }

}

改完后，开启Profiler里的网络监控器，再次尝试文件上传，ok成功了，但又有一个新的问题，ProgressRequestBody是用于监听上传进度的，OkHttp3Interceptor、CallServerInterceptor先后调用了其writeTo(BufferedSink)方法，这就会导致请求体写两次，也就是进度监听会收到两遍，而我们真正需要的是CallServerInterceptor调用的那次，咋整？好办，我们前面就判断过调用方是否OkHttp3Interceptor

于是，做出如下更改：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

         //如果调用方是OkHttp3Interceptor，直接写请求体，不再通过包装类来处理请求进度

        if (sink.toString().contains(

        "com.android.tools.profiler.support.network.HttpTracker$OutputStreamTracker")) {

            requestBody.writeTo(bufferedSink);  

        } else {

            BufferedSink bufferedSink = Okio.buffer(sink(sink));

            requestBody.writeTo(bufferedSink);  

            bufferedSink.colse();

        }

    }

}

你以为这样就完了？相信很多人都会用到com.squareup.okhttp3:logging-interceptor日志拦截器，当你添加该日志拦截器后，再次上传文件，会发现，进度回调又执行了两遍，为啥？因为该日志拦截器，也会调用ProgressRequestBody#writeTo(BufferedSink)方法，看看代码：

//省略部分代码

class HttpLoggingInterceptor @JvmOverloads constructor(

  private val logger: Logger = Logger.DEFAULT

) : Interceptor {



  @Throws(IOException::class)

  override fun intercept(chain: Interceptor.Chain): Response {

    val request = chain.request()

    val requestBody = request.body



    if (logHeaders) {

      if (!logBody || requestBody == null) {

        logger.log("--> END ${request.method}")

      } else if (bodyHasUnknownEncoding(request.headers)) {

        logger.log("--> END ${request.method} (encoded body omitted)")

      } else if (requestBody.isDuplex()) {

        logger.log("--> END ${request.method} (duplex request body omitted)")

      } else if (requestBody.isOneShot()) {

        logger.log("--> END ${request.method} (one-shot body omitted)")

      } else {

        val buffer = Buffer()

        //1、这里调用了RequestBody的writeTo方法，并传入了Buffer对象

        requestBody.writeTo(buffer)  

      }

    }



    val response: Response

    try {

      response = chain.proceed(request)

    } catch (e: Exception) {

      throw e

    }

    return response

  }



}

可以看到，HttpLoggingInterceptor内部也会调用RequestBody#writeTo方法，并传入Buffer对象，到这，我们就好办了，在ProgressRequestBody类增加一个Buffer的判断逻辑即可，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

         //如果调用方是OkHttp3Interceptor，或者传入的是Buffer对象，直接写请求体，不再通过包装类来处理请求进度

        if (sink instanceof Buffer

            || sink.toString().contains(

            "com.android.tools.profiler.support.network.HttpTracker$OutputStreamTracker")) {

            requestBody.writeTo(bufferedSink);  

        } else {

            BufferedSink bufferedSink = Okio.buffer(sink(sink));

            requestBody.writeTo(bufferedSink);  

            bufferedSink.colse();

        }

    }

}

这样就完了？也不见得，如果后续又遇到什么拦截器调用其writeTo方法，还是会出现进度回调执行两遍的情况，只能在遇到这种情况时，加入对应的判断逻辑

到这，也许有人会问，为啥不直接判断调用方是不是CallServerInterceptor，是的话监听进度回调，否则，直接写入请求体。想法很好，也是可行的，如下：

public class ProgressRequestBody extends RequestBody {



    //省略相关代码

    @Override

    public void writeTo(BufferedSink sink) throws IOException {

         //如果调用方是CallServerInterceptor，监听上传进度

        if (sink.toString().contains("RequestBodySink(okhttp3.internal")) {

            BufferedSink bufferedSink = Okio.buffer(sink(sink));

            requestBody.writeTo(bufferedSink);  

            bufferedSink.colse();

        } else {

            requestBody.writeTo(bufferedSink);  

        }

    }

}

但是该方案有个致命的缺陷，如果okhttp未来版本更改了目录结构，ProgressRequestBody类就完全失效。

两个方案就由大家自己去选择，这里给出ProgressRequestBody完整源码，需要自取

5、小结

本案例上传失败的直接原因就是在AS开启了Database Inspector数据库分析器或Profiler网络监控器时，AS就会通过字节码插桩技术，对OkHttpClient#networkInterceptors()方法注入新的字节码，使其多返回一个com.android.tools.profiler.agent.okhttp.OkHttp3Interceptor拦截器(用于监听网络)，该拦截器会调用ProgressRequestBody#writeTo(BufferedSink)方法，并传入BufferedSink对象，writeTo方法执行完毕后，立即将BufferedSink对象关闭，在随后的CallServerInterceptor拦截又调用ProgressRequestBody#writeTo(BufferedSink)方法往已关闭的BufferedSink对象写数据，最终导致java.lang.IllegalStateException: closed异常。

但有个有疑惑，我却未找到答案，那就是为啥开启Database Inspector也会导致AS去监听网络？有知道的小伙伴可以评论区留言。

面试的时候经常会被问及多线程同步的问题，例如：

“ 现有 Task1、Task2 等多个并行任务，如何等待全部执行完成后，执行 Task3。”

在 Kotlin 中我们有多种实现方式，本文将所有这些方式做了整理，建议收藏。

1. Thread.join
2. Synchronized
3. ReentrantLock
4. BlockingQueue
5. CountDownLatch
6. CyclicBarrier
7. CAS
8. Future
9. CompletableFuture
10. Rxjava
11. Coroutine
12. Flow

我们先定义三个Task，模拟上述场景， Task3 基于 Task1、Task2 返回的结果拼接字符串，每个 Task 通过 sleep 模拟耗时：

val task1: () -> String = {

    sleep(2000)

    "Hello".also { println("task1 finished: $it") }

}



val task2: () -> String = {

    sleep(2000)

    "World".also { println("task2 finished: $it") }

}



val task3: (String, String) -> String = { p1, p2 ->

    sleep(2000)

    "$p1 $p2".also { println("task3 finished: $it") }

}

1. Thread.join()

Kotlin 兼容 Java，Java 的所有线程工具默认都可以使用。其中最简单的线程同步方式就是使用 Thread 的 join() ：

@Test

fun test_join() {

    lateinit var s1: String

    lateinit var s2: String



    val t1 = Thread { s1 = task1() }

    val t2 = Thread { s2 = task2() }

    t1.start()

    t2.start()



    t1.join()

    t2.join()

    

    task3(s1, s2)



}

2. Synchronized

使用 synchronized 锁进行同步

	@Test

    fun test_synchrnoized() {

        lateinit var s1: String

        lateinit var s2: String



        Thread {

            synchronized(Unit) {

                s1 = task1()

            }

        }.start()

        s2 = task2()



        synchronized(Unit) {

            task3(s1, s2)

        }



    }

但是如果超过三个任务，使用 synchrnoized 这种写法就比较别扭了，为了同步多个并行任务的结果需要声明n个锁，并嵌套n个 synchronized。

3. ReentrantLock

ReentrantLock 是 JUC 提供的线程锁，可以替换 synchronized 的使用

	@Test

    fun test_ReentrantLock() {



        lateinit var s1: String

        lateinit var s2: String



        val lock = ReentrantLock()

        Thread {

            lock.lock()

            s1 = task1()

            lock.unlock()

        }.start()

        s2 = task2()



        lock.lock()

        task3(s1, s2)

        lock.unlock()



    }

ReentrantLock 的好处是，当有多个并行任务时是不会出现嵌套 synchrnoized 的问题，但仍然需要创建多个 lock 管理不同的任务，

4. BlockingQueue

阻塞队列内部也是通过 Lock 实现的，所以也可以达到同步锁的效果

	@Test

    fun test_blockingQueue() {



        lateinit var s1: String

        lateinit var s2: String



        val queue = SynchronousQueue<Unit>()



        Thread {

            s1 = task1()

            queue.put(Unit)

        }.start()



        s2 = task2()



        queue.take()

        task3(s1, s2)

    }

当然，阻塞队列更多是使用在生产/消费场景中的同步。

5. CountDownLatch

JUC 中的锁大都基于 AQS 实现的，可以分为独享锁和共享锁。ReentrantLock 就是一种独享锁。相比之下，共享锁更适合本场景。 例如 CountDownLatch，它可以让一个线程一直处于阻塞状态，直到其他线程的执行全部完成：

	@Test

    fun test_countdownlatch() {



        lateinit var s1: String

        lateinit var s2: String

        val cd = CountDownLatch(2)

        Thread() {

            s1 = task1()

            cd.countDown()

        }.start()



        Thread() {

            s2 = task2()

            cd.countDown()

        }.start()



        cd.await()

        task3(s1, s2)

    }

共享锁的好处是不必为了每个任务都创建单独的锁，即使再多并行任务写起来也很轻松

6. CyclicBarrier

CyclicBarrier 是 JUC 提供的另一种共享锁机制，它可以让一组线程到达一个同步点后再一起继续运行，其中任意一个线程未达到同步点，其他已到达的线程均会被阻塞。

与 CountDownLatch 的区别在于 CountDownLatch 是一次性的，而 CyclicBarrier 可以被重置后重复使用，这也正是 Cyclic 的命名由来，可以循环使用

	@Test

    fun test_CyclicBarrier() {



        lateinit var s1: String

        lateinit var s2: String

        val cb = CyclicBarrier(3)



        Thread {

            s1 = task1()

            cb.await()

        }.start()



        Thread() {

            s2 = task1()

            cb.await()

        }.start()



        cb.await()

        task3(s1, s2)



    }

7. CAS

AQS 内部通过自旋锁实现同步，自旋锁的本质是利用 CompareAndSwap 避免线程阻塞的开销。 因此，我们可以使用基于 CAS 的原子类计数，达到实现无锁操作的目的。

 	@Test

    fun test_cas() {



        lateinit var s1: String

        lateinit var s2: String



        val cas = AtomicInteger(2)



        Thread {

            s1 = task1()

            cas.getAndDecrement()

        }.start()



        Thread {

            s2 = task2()

            cas.getAndDecrement()

        }.start()



        while (cas.get() != 0) {}



        task3(s1, s2)



    }

while 循环空转看起来有些浪费资源，但是自旋锁的本质就是这样，所以 CAS 仅仅适用于一些cpu密集型的短任务同步。

volatile

看到 CAS 的无锁实现，也许很多人会想到 volatile， 是否也能实现无锁的线程安全？

 	@Test

    fun test_Volatile() {

        lateinit var s1: String

        lateinit var s2: String



        Thread {

            s1 = task1()

            cnt--

        }.start()



        Thread {

            s2 = task2()

            cnt--

        }.start()



        while (cnt != 0) {

        }



        task3(s1, s2)



    }

注意，这种写法是错误的 volatile 能保证可见性，但是不能保证原子性，cnt-- 并非线程安全，需要加锁操作

8. Future

上面无论有锁操作还是无锁操作，都需要定义两个变量s1、s2记录结果非常不方便。 Java 1.5 开始，提供了 Callable 和 Future ，可以在任务执行结束时返回结果。

@Test

fun test_future() {



    val future1 = FutureTask(Callable(task1))

    val future2 = FutureTask(Callable(task2))



    Executors.newCachedThreadPool().execute(future1)

    Executors.newCachedThreadPool().execute(future2)



    task3(future1.get(), future2.get())



}

通过 future.get()，可以同步等待结果返回，写起来非常方便

9. CompletableFuture

future.get() 虽然方便，但是会阻塞线程。 Java 8 中引入了 CompletableFuture ，他实现了 Future 接口的同时实现了 CompletionStage 接口。 CompletableFuture 可以针对多个 CompletionStage 进行逻辑组合、实现复杂的异步编程。 这些逻辑组合的方法以回调的形式避免了线程阻塞：

@Test

fun test_CompletableFuture() {

    CompletableFuture.supplyAsync(task1)

        .thenCombine(CompletableFuture.supplyAsync(task2)) { p1, p2 ->

             task3(p1, p2)

        }.join()

}

10. RxJava

RxJava 提供的各种操作符以及线程切换能力同样可以帮助我们实现需求： zip 操作符可以组合两个 Observable 的结果；subscribeOn 用来启动异步任务

@Test

fun test_Rxjava() {



    Observable.zip(

        Observable.fromCallable(Callable(task1))

            .subscribeOn(Schedulers.newThread()),

        Observable.fromCallable(Callable(task2))

            .subscribeOn(Schedulers.newThread()),

        BiFunction(task3)

    ).test().awaitTerminalEvent()



}

11. Coroutine

前面讲了那么多，其实都是 Java 的工具。 Coroutine 终于算得上是 Kotlin 特有的工具了：

@Test

fun test_coroutine() {



    runBlocking {

        val c1 = async(Dispatchers.IO) {

            task1()

        }



        val c2 = async(Dispatchers.IO) {

            task2()

        }



        task3(c1.await(), c2.await())

    }

}

写起来特别舒服，可以说是集前面各类工具的优点于一身。

12. Flow

Flow 就是 Coroutine 版的 RxJava，具备很多 RxJava 的操作符，例如 zip:

@Test

fun test_flow() {



    val flow1 = flow<String> { emit(task1()) }

    val flow2 = flow<String> { emit(task2()) }

        

    runBlocking {

         flow1.zip(flow2) { t1, t2 ->

             task3(t1, t2)

        }.flowOn(Dispatchers.IO)

        .collect()



    }



}

flowOn 使得 Task 在异步计算并发射结果。

总结

上面这么多方式，就像茴香豆的“茴”字的四种写法，没必要都掌握。作为结论，在 Kotlin 上最好用的线程同步方案首推协程！

编译器优化

局部变量&全局变量

int global = 10;



int main(int argc, char * argv[]) {

    int a = 20;

    int b = global + 1;

    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

}

在不进行优化的情况下:

改成Fastest、Smallest模式，a和b都被优化掉了。

局部变量和全局变量会被优化掉。

函数

int func(int a,int b) {

    return a + b;

}



int main(int argc, char * argv[]) {

    int value = func(10, 20);

    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

}

func函数也会被优化掉，因为对程序的执行结果没有影响。
修改下:

int func(int a,int b) {

    return a + b;

}



int main(int argc, char * argv[]) {

    int value = func(10, 20);

    NSLog(@"%d",value);

    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

}

可以看到直接将0x1e结果入栈。一样也会被优化。

编译配置（Optimization Level）

编译器（从c到汇编的编译过程）的优化配置（指定被编译代码的执行速度和二进制文件大小的优化程度）。优化后的代码效率比较高，但是可读性比较差，且编译时间更长。
优化等级配置在Build Settings -> Apple Clang - Code Generation -> Optimization Level 中：

None [-O0]:不优化。
编译器的目标是降低编译消耗，保证调试时输出期望的结果。程序的语句之间是独立的：如果在程序的停在某一行的断点出，我们可以给任何变量赋新值抑或是将程序计数器指向方法中的任何一个语句，并且能得到一个和源码完全一致的运行结果。

Fast [-O, O1]: 大函数所需的编译时间和内存消耗都会稍微增加。
在这种设置下，编译器会尝试减小代码文件的大小，减少执行时间，但并不执行需要大量编译时间的优化。在苹果的编译器中，在优化过程中，严格别名，块重排和块间的调度都会被默认禁止掉。此优化级别提供了良好的调试体验，堆栈使用率也提高，并且代码质量优于None[-O0]。

Faster [-O2]:编译器执行所有不涉及时间空间交换的所有的支持的优化选项。
更高的性能优化Fast[-O1]。在这种设置下，编译器不会进行循环展开、函数内联或寄存器重命名。和‘Fast[-O1]’项相比，此设置会增加编译时间和生成代码的性能。

Fastest [-O3]:在开启Fast[-O1]项支持的所有优化项的同时，开启函数内联和寄存器重命名选项
是更高的性能优化Faster[-O2]，指示编译器优化所生成代码的性能，而忽略所生成代码的大小，有可能会导致二进制文件变大。还会降低调试体验。

Fastest, Smallest [-Os]:在不显着增加代码大小的情况下尽量提供高性能
这个设置开启了Fast[-O1]项中的所有不增加代码大小的优化选项，并会进一步的执行可以减小代码大小的优化。增加的代码大小小于Fastest[-O3]。与Fast[-O1]相比，它还会降低调试体验。

Fastest, Aggressive Optimizations [-Ofast]:与Fastest, Smallest[-Os]相比该级别还执行其他更激进的优化
这个设置开启了Fastest[-O3]中的所有优化选项，同时也开启了可能会打破严格编译标准的积极优化，但并不会影响运行良好的代码。该级别会降低调试体验，并可能导致代码大小增加。

Smallest, Aggressive Size Optimizations [-Oz]:不使用LTO的情况下减小代码大小
与-Os相似，指示编译器仅针对代码大小进行优化，而忽略性能优化，这可能会导致代码变慢。

Xcode中Debug模式默认为None[-O0]，Release默认为Fastest, Smallest[-Os]。

指针

指针在汇编中只是地址， 在底层来说就是数据。

指针基本常识

指针的宽度为8字节。

void func() {

    //指针的宽度8字节

    int *a;

    printf("%lu",sizeof(a));

}



int main(int argc, char * argv[]) {

    func();

    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

}

• sizeof：是个符号，操作符。这里验证了是常量8。

指针的运算

指针++

int型指针++：

int *a;

a = (int *)100;

a++;

运算结果：104，int占4字节。

char型指针++：

char *a;

a = (char *)100;

a++;

运算结果：101，char占1字节。

指向指针的指针++：

int **a;

a = (int **)100;

a++;

int **a;

a = (int **)100;

a = a + 1;

int *a;

a = (int *)100;

int *b;

b = (int *)200;

int x = a - b; // a/4 - b/4 = -25

运算结果：-25。（a/4 - b/4 = -25）

• 指针的运算与指向的数据类型宽度（步长）有关。
• 指针的运算单位是执行的数据类型的宽度。
• 结构体和基本类型不能强制转换，普通类型可以通过&。

指针的反汇编

void func() {

    int* a;

    int b = 10;

    a = &b;

}

对应的汇编:

TestDemo`func:

    0x10098a1c4 <+0>:  sub    sp, sp, #0x10             ; =0x10 

    //sp+0x4  给 x8

    0x10098a1c8 <+4>:  add    x8, sp, #0x4              ; =0x4 

    //1O给w9

    0x10098a1cc <+8>:  mov    w9, #0xa

    //w9 入栈

->  0x10098a1d0 <+12>: str    w9, [sp, #0x4]

    //x8 指向 sp+0x8。相当于x8指向sp，也就是指向10的地址

    0x10098a1d4 <+16>: str    x8, [sp, #0x8]



    0x10098a1d8 <+20>: add    sp, sp, #0x10             ; =0x10 

    0x10098a1dc <+24>: ret    

[sp, #0x8]是个指针变量。从0x8~0x10保存的就是指针。

数组和指针

void func() {

    int arr[5] = {1,2,3,4,5};

    //int *a == &arr[0] == arr

    int *a = arr;

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

        printf("%d\n",arr[i]);

        printf("%d\n",*(arr + i));

//        printf("%d\n",*(arr++));

        printf("%d\n",*(a++));

    }

}

*(arr++) 会报错。int *a = arr; 之后 a++就没问题了、

• 数组名和指针变量是一样的，唯一的区别是一个是常量，一个是变量。
  int *a == &arr[0] == arr

指针的基本用法

void func() {

    char *p1;

    char c = *p1;

    printf("%c",c);

}

p1由于是个指针，没有初始化编译不会报错，运行会报错。在iOS中默认是0，运行会直接野指针。

指向char的指针+0

void func() {

    char *p1;

    char c = *p1;

    char d = *(p1 + 0);

}

对应汇编

TestDemo`func:

    0x104b661bc <+0>:  sub    sp, sp, #0x10             ; =0x10 

    //p1 -> 0x0  x8指向p1

    0x104b661c0 <+4>:  ldr    x8, [sp, #0x8]

    //c = [x8]  给到 w9

->  0x104b661c4 <+8>:  ldrb   w9, [x8]

    0x104b661c8 <+12>: strb   w9, [sp, #0x7]

    0x104b661cc <+16>: ldr    x8, [sp, #0x8]

    //d = [x8]  给到 w9

    0x104b661d0 <+20>: ldrb   w9, [x8]

    0x104b661d4 <+24>: strb   w9, [sp, #0x6]



    0x104b661d8 <+28>: add    sp, sp, #0x10             ; =0x10 

    0x104b661dc <+32>: ret   

指向char的指针+1

void func() {

    char *p1;//指针 -> x8 0x0

    char c = *p1;// [x8]

    char d = *(p1 + 1);//[x8, #0x1]

}

对应汇编：

TestDemo`func:

    0x1041f21bc <+0>:  sub    sp, sp, #0x10             ; =0x10 

    //p1

    0x1041f21c0 <+4>:  ldr    x8, [sp, #0x8]

    //c

->  0x1041f21c4 <+8>:  ldrb   w9, [x8]

    0x1041f21c8 <+12>: strb   w9, [sp, #0x7]

    0x1041f21cc <+16>: ldr    x8, [sp, #0x8]

    //d

    0x1041f21d0 <+20>: ldrb   w9, [x8, #0x1]

    0x1041f21d4 <+24>: strb   w9, [sp, #0x6]

    0x1041f21d8 <+28>: add    sp, sp, #0x10             ; =0x10 

    0x1041f21dc <+32>: ret  

指向int的指针+1

void func() {

    int *p1;//指针 -> x8 0x0

    int c = *p1;// [x8]

    int d = *(p1 + 1);//[x8, #0x4]

}

TestDemo`func:

    0x1040e61bc <+0>:  sub    sp, sp, #0x10             ; =0x10 

    //p1 [x8]

    0x1040e61c0 <+4>:  ldr    x8, [sp, #0x8]

    //c

->  0x1040e61c4 <+8>:  ldr    w9, [x8]

    0x1040e61c8 <+12>: str    w9, [sp, #0x4]

    0x1040e61cc <+16>: ldr    x8, [sp, #0x8]

    //d

    0x1040e61d0 <+20>: ldr    w9, [x8, #0x4]

    0x1040e61d4 <+24>: str    w9, [sp]

    0x1040e61d8 <+28>: add    sp, sp, #0x10             ; =0x10 

    0x1040e61dc <+32>: ret