Handler.postDelayed()简化lambda传入

不知道大家在使用Handler下的postDelayed()方法是不是感觉很不简洁，我们看下这个函数源码：

public final boolean postDelayed(@NonNull Runnable r, long delayMillis) {

    return sendMessageDelayed(getPostMessage(r), delayMillis);

}

可以看到Runnable类型的参数r放在第一位，在Kotlin中我们就无法利用其提供的简洁的语法糖，只能这样使用：

private fun test11(handler: Handler) {

    handler.postDelayed({

        //编写代码逻辑

    }, 100)

}

有没有感觉很别扭，估计官方也发现了这个问题，就提供了这样一个扩展方法：

public inline fun Handler.postDelayed(

    delayInMillis: Long,

    token: Any? = null,

    crossinline action: () -> Unit

): Runnable {

    val runnable = Runnable { action() }

    if (token == null) {

        postDelayed(runnable, delayInMillis)

    } else {

        HandlerCompat.postDelayed(this, runnable, token, delayInMillis)

    }

    return runnable

}

可以看到将函数类型（相当于上面的Runnable中的代码执行逻辑）放到了方法参数的最后一位，这样利用kotlin的语法糖就可以这样使用：

private fun test11(handler: Handler) {

    handler.postDelayed(200) {

        

    }

}

可以看到这个函数类型使用了crossinline修饰，这个是用来加强内联的，因为其另一个Runnable的函数类型中进行了调用，这样我们就无法在这个函数类型action中使用return关键字了（return@标签除外），避免使用return关键字带来返回上的歧义不稳定性。

除此之外，官方core-ktx还提供了类似的扩展方法postAtTime()方法，使用和上面一样！！

Context.getSystemService()泛型实化获取系统服务

看下以往我们怎么获取ClipboardManager:

private fun test11() {

    val cm: ClipboardManager = getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager

}

看下官方提供的方法：

public inline fun <reified T : Any> Context.getSystemService(): T? =

    ContextCompat.getSystemService(this, T::class.java)

借助于内联和泛型实化简化了获取系统服务的代码逻辑：

private fun test11() {

    val cm: ClipboardManager? = getSystemService()

}

泛型实化的用处有很多应用场景，大家感兴趣可以参考我另一篇文章：Gson序列化的TypeToken写起来太麻烦？优化它

Context.withStyledAttributes简化操作自定义属性

这个扩展一般只有在自定义View中较常使用，比如读取xml中设置的属性值，先看下我们平常是如何使用的：

private fun test11(

    @NonNull context: Context,

    @Nullable attrs: AttributeSet,

    defStyleAttr: Int

) {

    val ta = context.obtainStyledAttributes(

        attrs, androidx.cardview.R.styleable.CardView, defStyleAttr,

        androidx.cardview.R.style.CardView

    )

    //获取属性执行对应的操作逻辑

    val tmp = ta.getColorStateList(androidx.cardview.R.styleable.CardView_cardBackgroundColor)



    ta.recycle()

}

在获取完属性值后，还需要调用recycle()方法回收TypeArray，这个一旦忘记写就不好了，能让程序保证的写法那就尽量避免人为处理，所以官方提供了下面的扩展方法：

public inline fun Context.withStyledAttributes(

    @StyleRes resourceId: Int,

    attrs: IntArray,

    block: TypedArray.() -> Unit

) {

    obtainStyledAttributes(resourceId, attrs).apply(block).recycle()

}

使用如下：

private fun test11(

    @NonNull context: Context,

    @Nullable attrs: AttributeSet,

    defStyleAttr: Int

) {

    context.withStyledAttributes(

        attrs, androidx.cardview.R.styleable.CardView, defStyleAttr,

        androidx.cardview.R.style.CardView

    ) {

        val tmp = getColorStateList(androidx.cardview.R.styleable.CardView_cardBackgroundColor)

    }

}

上面的写法就保证了recycle()不会漏写，并且带接收者的函数类型block: TypedArray.() -> Unit也能让我们省略this直接调用TypeArray中的公共方法。

SQLiteDatabase.transaction()自动开启事务读写数据库

平常对SQLite进行写操作时为了效率及安全保证需要开启事务，一般我们都会手动进行开启和关闭，还是那句老话，能程序自动保证的事情就尽量避免手动实现，所以一般我们都会封装一个事务开启和关闭的方法，如下：

private fun writeSQL(sql: String) {

    SQLiteDatabase.beginTransaction()

    //执行sql写入语句

    SQLiteDatabase.endTransaction()

}

官方core-ktx也提供了相似的扩展方法：

public inline fun <T> SQLiteDatabase.transaction(

    exclusive: Boolean = true,

    body: SQLiteDatabase.() -> T

): T {

    if (exclusive) {

        beginTransaction()

    } else {

        beginTransactionNonExclusive()

    }

    try {

        val result = body()

        setTransactionSuccessful()

        return result

    } finally {

        endTransaction()

    }

}

大家可以自行选择使用！

<K : Any, V : Any> lruCache()简化创建LruCache

LruCache一般用作数据缓存，里面使用了LRU算法来优先淘汰那些近期最少使用的数据。在Android开发中，我们可以使用其设计一个Bitmap缓存池，感兴趣的可以参考Glide内存缓存这块的源码，就利用了LruCache实现。

相比较于原有创建LruCache的方式，官方库提供了下面的扩展方法简化其创建流程：

inline fun <K : Any, V : Any> lruCache(

    maxSize: Int,

    crossinline sizeOf: (key: K, value: V) -> Int = { _, _ -> 1 },

    @Suppress("USELESS_CAST")

    crossinline create: (key: K) -> V? = { null as V? },

    crossinline onEntryRemoved: (evicted: Boolean, key: K, oldValue: V, newValue: V?) -> Unit =

        { _, _, _, _ -> }

): LruCache<K, V> {

    return object : LruCache<K, V>(maxSize) {

        override fun sizeOf(key: K, value: V) = sizeOf(key, value)

        override fun create(key: K) = create(key)

        override fun entryRemoved(evicted: Boolean, key: K, oldValue: V, newValue: V?) {

            onEntryRemoved(evicted, key, oldValue, newValue)

        }

    }

}

看下使用：

private fun createLRU() {

    lruCache<String, Bitmap>(3072, sizeOf = { _, value ->

        value.byteCount

    }, onEntryRemoved = { evicted: Boolean, key: String, oldValue: Bitmap, newValue: Bitmap? ->

        //缓存对象被移除的回调方法

    })

}

可以看到，比之手动创建LruCache要稍微简单些，能稍微节省下使用成本。

bundleOf()快捷写入并创建Bundle对象

bundleOf()方法的参数被vararg声明，代表一个可变的参数类型，参数具体的类型为Pair，这个对象我们之前的文章有讲过，可以借助中缀表达式函数to完成Pair的创建：

private fun test12() {

    val bundle = bundleOf("a" to "a", "b" to 10)

}

这种通过传入可变参数实现的Bundle如果大家不太喜欢，还可以考虑自行封装通用扩展函数，在函数类型即lambda中实现更加灵活的Bundle创建及写入：

1.自定义运算符重载方法set实现Bundle写入：

operator fun Bundle.set(key: String, value: Any?) {

    when (value) {

        null -> putString(key, null)



        is Boolean -> putBoolean(key, value)

        is Byte -> putByte(key, value)

        is Char -> putChar(key, value)

        is Double -> putDouble(key, value)

        is Float -> putFloat(key, value)

        is Int -> putInt(key, value)

        is Long -> putLong(key, value)

        is Short -> putShort(key, value)



        is Serializable -> putSerializable(key, value)

        //其实数据类型自定参考bundleOf源码实现

    }

}

2.自定义BundleBuild支持向Bundle写入多个值

class BundleBuild(private val bundle: Bundle) {



    infix fun String.to(that: Any?) {

        bundle[this] = that

    }

}

其中to()方法使用了中缀表达式的写法

3.暴漏扩展方法实现在lambda中完成Bundle的写入和创建

private fun bundleOf(block: BundleBuild.() -> Unit): Bundle {

    return Bundle().apply {

        BundleBuild(this).apply(block)

    }

}

然后就可以这样使用：

private fun test12() {

    val bundle = bundleOf {

        "a" to "haha"

        //经过一些逻辑操作获取结果后在写入Bundle

        val t1 = 10 * 5

        val t2 = ""

        t2 to t1

    }

}

相比较于官方库提供的bundleOf()提供的创建方式，通过函数类型也就是lambda创建并写入Bundle的方式更加灵活，并内部支持执行操作逻辑获取结果后再进行写入。

总结

关于官方core-ktx的研究基本上已经七七八八了，总共输出了五篇相关文章，对该库了解能够节省我们编写模板代码的时间，提高开发效率，大家如果感觉写的不错，可以点个赞支持下哈，感谢！！

类到对象是实例化。对象到类是抽象。

抽象类：
1.什么是抽象类？
类和类之间具有共同特征，将这些共同特征提取出来，形成的就是抽象类。
类本身是不存在的，所以抽象类无法创建对象（无法实例化）

2.抽象类属于什么类型？抽象类也属于引用数据类型。

3.抽象类怎么定义？@#^%&^^&^%
语法：
（修饰符列表）abstract class类名{类体}

4.抽象类是无法实例化的，无法创建对象的，所以抽象类是用来被子类继承的。

5.final和abstract不能联合使用，这两个关键字是对立的。

6.抽象类的子类可以是抽象类。

7.抽象类虽然无法实例化，但是抽象类有构造方法，这个构造方法提供子类使用的。

8.抽象类关联到一个概念，抽象方法，什么是抽象方法呢？
抽象方法标识没有实现的方法，没有方法体的方法。例如：
public abstract void dosome();

9.抽象方法的类必须是抽象类，抽象类的方法不一定要是抽象方法。
抽象方法的特点是：特点1：没有方法体，以分号结尾。特点2：前面修饰符列表中有abstract关键字

10.抽象类中不一定有抽象方法，但抽象方法必须出现在抽象类中

11.非抽象方法集成抽象类，必须重写抽象类里的方法，如果是抽象类继承抽象类，那么就不一定要重写父类的方法

public abstract class AbstractTest extends AbstractChildTest{

    /**

     * 类到对象是实例化。对象到类是抽象

     *

     */

    public static void main(String[] args) {



    }



    @Override

    void Bird() {

        

    }

}

abstract class AbstractChildTest{

    //子类继承抽象类

    abstract void Bird();

}

朋友聊天讨论到一个问题，怎么检测zip的完整性。zip是我们常用的压缩格式，不管是Win/Mac/Linux下都很常用，我们做文件的下载也会经常用到，网络充满不确定性，对于多个小文件（比如配置文件）的下载，我们希望只发起一次连接，因为建立连接是很耗费资源的，即使现在http2.0可以对一条TCP连接进行复用，我们还是希望网络请求的次数越少越好，不管是对于稳定性还是成功失败的逻辑判断，都会有益处。

这个时候我们常用的其实就是把他们压缩成一个zip文件，下载下来之后解压就好了。

但很多时候zip会解压失败，如果我们的zip已经下载下来了，其实不存在没有访问权限的问题了，那原因除了空间不够之外，就是zip格式有问题了，zip文件为空或者只下载了一半。

这个时候就需要检测一下我们下载下来的zip是不是合法有效的zip了。

有这么几种思路：

1. 直接解压，抛异常表明zip有问题


2. 下载前得到zip文件的length，下载后检测文件大小


3. 使用md5或sha1等摘要算法，下载下来后做md5，然后比对合法性


4. 检测zip文件结尾的特殊编码格式，检测是否zip合法

这几种做法有利有弊，这里我们只看第4种。

我们讨论之前，可以大致了解一下zip的格式ZIP文件格式分析，我们关注的是End of central directory record，核心目录结束标记，每个zip只会出现一次。

我们可以看到，0x06054b50所在的位置其实是在zip.length减去22个字节，所以我们只需要seek到需要的位置，然后读4个字节看是否是0x06054b50，就可以确定zip是否完整。

下面是一个判断的代码

        //没有zip文件注释时候的目录结束符的偏移量

        private static final int RawEndOffset = 22;

        //0x06054b50占4个字节

        private static final int endOfDirLength = 4;

        //目录结束标识0x06054b50 的小端读取方式。

        private static final byte[] endOfDir = new byte[]{0x50, 0x4B, 0x05, 0x06};



        private boolean isZipFile(File file) throws IOException {

            if (file.exists() && file.isFile()) {

                if (file.length() <= RawEndOffset + endOfDirLength) {

                    return false;

                }

                long fileLength = file.length();

                RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");

                //seek到结束标记所在的位置

                randomAccessFile.seek(fileLength - RawEndOffset);

                byte[] end = new byte[endOfDirLength];

                //读取4个字节

                randomAccessFile.read(end);

                //关掉文件

                randomAccessFile.close();

                return isEndOfDir(end);

            } else {

                return false;

            }

        }



        /**

         * 是否符合文件夹结束标记

         */

        private boolean isEndOfDir(byte[] src) {

            if (src.length != endOfDirLength) {

                return false;

            }

            for (int i = 0; i < src.length; i++) {

                if (src[i] != endOfDir[i]) {

                    return false;

                }

            }

            return true;

        }

有人可能注意到了，你上面写的结束标识明明是0x06054b50，为什么检测的时候是反着写的。这里就涉及到一个大端小端的问题，录音的时候也能会遇到大小端顺序的问题，反过来读就好了。

涉及到二进制的查看和编辑，我们可以使用010editor这个软件来查看文件的十六进制或者二进制，并且可以手动修改某个位置的二进制。

他的界面大致长这样子，小端显示的，我们可以看到我们要得到的06 05 4b 50，

我们看上面的表格里面最后一个表格里的 .ZIP file comment length(n) 和 .ZIP Comment ，意思是描述长度是两个字节，描述长度是n，表示这个长度是可变的。这个有啥作用呢？

其实就是给了一个可以写额外的描述数据的地方（.ZIP Comment），他的长度由前面的.ZIP file comment length(n)来控制。也就是zip允许你在它的文件结尾后面额外的追加内容，而不会影响前面的数据。描述文件的长度是两个字节，也就是一个short的长度，所以理论上可以寻址2^16^个位置。

举个例子：

修改之前：

修改之后



看上面两个文件，修改之前长度为0，我们把它改成2(注意大小端)，我们改成2，然后随便在后面追加两个byte，保存，打开修改之后的zip，发现是可以正常运行的，甚至我们可以在长度是2的基础上追加多个byte，其实还是可以打开的。

所以回到标题内容，其实apk就是zip，我们同样可以在apk的Comment后面追加内容，比如可以当做渠道来源，或者完成这样的需求：h5网页A上下载的需要打开某个ActivityA，h5网页B上下载的需要打开某个ActivityB。

原理还是上面的原理，写入渠道或者配置，读取apk渠道或者配置，做相应统计或者操作。

        //magic -> yocn

        private static final byte[] MAGIC = new byte[]{0x79, 0x6F, 0x63, 0x6E};

        //没有zip文件注释时候的目录结束符的偏移量

        private static final int RawEndOffset = 22;

        //0x06054b50占4个字节

        private static final int endOfDirLength = 4;

        //目录结束标识0x06054b50 的小端读取方式。

        private static final byte[] endOfDir = new byte[]{0x50, 0x4B, 0x05, 0x06};

        //注释长度占两个字节，所以理论上可以支持 2^16 个字节。

        private static final int commentLengthBytes = 2;

        //注释长度

        private static final int commentLength = 8;



        private boolean isZipFile(File file) throws IOException {

            if (file.exists() && file.isFile()) {

                if (file.length() <= RawEndOffset + endOfDirLength) {

                    return false;

                }

                long fileLength = file.length();

                RandomAccessFile randomAccessFile = new RandomAccessFile(file, "r");

                //seek到结束标记所在的位置

                randomAccessFile.seek(fileLength - RawEndOffset);

                byte[] end = new byte[endOfDirLength];

                //读取4个字节

                randomAccessFile.read(end);

                //关掉文件

                randomAccessFile.close();

                return isEndOfDir(end);

            } else {

                return false;

            }

        }



        /**

         * 是否符合文件夹结束标记

         */

        private boolean isEndOfDir(byte[] src) {

            if (src.length != endOfDirLength) {

                return false;

            }

            for (int i = 0; i < src.length; i++) {

                if (src[i] != endOfDir[i]) {

                    return false;

                }

            }

            return true;

        }



        /**

         * zip(apk)尾追加渠道信息

         */

        private void write2Zip(File file, String channelInfo) throws IOException {

            if (isZipFile(file)) {

                long fileLength = file.length();

                RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");

                //seek到结束标记所在的位置

                randomAccessFile.seek(fileLength - commentLengthBytes);

                byte[] lengthBytes = new byte[2];

                lengthBytes[0] = commentLength;

                lengthBytes[1] = 0;

                randomAccessFile.write(lengthBytes);

                randomAccessFile.write(getChannel(channelInfo));

                randomAccessFile.close();

            }

        }



        /**

         * 获取zip(apk)文件结尾

         *

         * @param file 目标哦文件

         */

        private String getZipTail(File file) throws IOException {

            long fileLength = file.length();

            RandomAccessFile randomAccessFile = new RandomAccessFile(file, "r");

            //seek到magic的位置

            randomAccessFile.seek(fileLength - MAGIC.length);

            byte[] magicBytes = new byte[MAGIC.length];

            //读取magic

            randomAccessFile.read(magicBytes);

            //如果不是magic结尾，返回空

            if (!isMagicEnd(magicBytes)) return "";

            //seek到读到信息的offest

            randomAccessFile.seek(fileLength - commentLength);

            byte[] lengthBytes = new byte[commentLength];

            //读取渠道

            randomAccessFile.read(lengthBytes);

            randomAccessFile.close();

            char[] lengthChars = new char[commentLength];

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

                lengthChars[i] = (char) lengthBytes[i];

            }

            return String.valueOf(lengthChars);

        }



        /**

         * 是否以魔数结尾

         *

         * @param end 检测的byte数组

         * @return 是否结尾

         */

        private boolean isMagicEnd(byte[] end) {

            for (int i = 0; i < end.length; i++) {

                if (MAGIC[i] != end[i]) {

                    return false;

                }

            }

            return true;

        }



        /**

         * 生成渠道byte数组

         */

        private byte[] getChannel(String s) {

            byte[] src = s.getBytes();

            byte[] channelBytes = new byte[commentLength];

            System.arraycopy(src, 0, channelBytes, 0, commentLength);

            return channelBytes;

        }



      //读取源apk的路径

      public static String getSourceApkPath(Context context, String packageName) {

        if (TextUtils.isEmpty(packageName))

            return null;

        try {

            ApplicationInfo appInfo = context.getPackageManager().getApplicationInfo(packageName, 0);

                return appInfo.sourceDir;

            } catch (PackageManager.NameNotFoundException e) {

                e.printStackTrace();

            }

        return null;

    }

这里使用了一个魔数的概念，表明是否是写入了我们特定的渠道，只有写了我们特定渠道的基础上才会去读取，防止读到了没有写过的文件。

读取渠道的时候首先获取安装包的绝对路径。Android系统在用户安装app时，会把用户安装的apk拷贝一份到/data/apk/路径下，通过getSourceApkPath 可以获取该apk的绝对路径。如果使用rw可能会有权限问题，所以读取的时候只使用r就可以了。

参考：
ZIP文件格式分析
全民K歌增量升级方案

Hi , 你好 :)

引言

在2022的今天，AndroidX 普遍的情况下，JetPack Lifecycle 也早已经成为了开发中的基础设施，小到 View(扩展库) ,大到 Activity，都隐藏着它的身影，而了解 Lifecycle 也正是理解 JetPack 组件系列库生命感知设计的基础。

本篇定位中级，将从背景到源码实现，从而理解其背后的设计思想。

导航

看完本篇，你将会搞清以下问题：

• Lifecycle 的前世今生；


• Lifecycle 可以干什么；


• Lifecycle 源码解析；

背景

在开始前，我们先聊聊关于 Lifecycle 的前世今生，从而便于我们更好的理解 Lifecycle 存在的意义。

洪荒之时

在 Lifecycle 之前(不排除现在😂)，如果我们要在某个生命周期去执行一些操作时，经常会在Act或者Fragment写很多模版代码，如下两个示例：

0. 比如，有一个定时器，我们需要在 Activity 关闭时将其关闭，从而避免因此导致的内存问题，所以我们自然会在 onDestory() 中去stop一下。这些事看起来似乎不麻烦，但如果是一个重复多处使用的代码，细心的开发者会将其单独抽离成为一个 case ,从而通过组合的方式降低我们主类中的逻辑，但不可避免我们依然还要存在好多模版代码，因为每次都需要 onStop() 清理或者其他操作(除非写到base,但不可接受☹️)。

📌 如果能不需要开发者自己手动，该有多好？

2. 在老版本的友盟中，我们经常甚至需要在基类的 Activity 中复写 onResume() 、onPause() 等方法，这些事情说麻烦也不麻烦，但总是感觉很不舒服。不过，有经验的开发者肯定会想喷，为什么一个三方库，你就自己不会通过application.registerActivityLifecycleCallbacks 监听吗🤌🏼。

📌 注意，Application有监听全局Act生命周期的方法，Act也有这个方法。🤖

盘古开天

在 JetPack 之前，Android 一直秉承着传统的 MVC 架构，即 xml 作为 View, Activity 作为 Control ，Model 层由数据模型或者仓库而定。虽然说官方曾经有一个MVP的示例,但真正用的人并不多。再加上官方一直也没推荐过 Android 的架构指南，这就导致传统的Android开发方式和系统的碎片化一样☹️，五花八门。随着时间的推移，眼看前端的MVVM已愈加成熟，后有Flutter，再加上开发者的需求等背景下，Google于2017年发布了新的开发架构: AAC,全名 Architecture，并且伴随着一系列相关组件，从而帮助开发者提高开发体验，降低错误概率，减少模版代码。

而本篇的主题 Lifecycle 正是其中作为基础设施的存在，在 sdk26 之后，更是被写入了基础库中。

那Lifecycle到底是干什么的呢？

Lifecycle 做的事情很简单，其就是用于检测组件(Fragment、Act) 的生命周期，从而不必强依赖于 Activity 与 Fragment ,帮助开发者降低模版代码。

常见用法

在官网中，对于 Lifecycle 的生命周期感知的整个流程如下所示：

Api介绍

相关字段

• 
  

  Event

  
  

  生命周期事件，对应具体的生命周期:

  
  

  ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTROY, ON_ANY

  
  


• 
  

  State

  
  

  生命周期状态节点，与 Event 紧密关联，Event 是这些结点的具体边界,换句话说，State 代表了这一时刻的具体状态,其相当于一个范围集，在这个范围里，都是这个状态。而Event代表这一状态集里面触发的具体事件是什么。

  
  

  INITIALIZED

  构造函数初始化时，且未收到 `onCreate()` 事件时的状态;
  
  

  
  

  CREATED

  在 `onCreate()` 调用之后，`onStop()` 调用之前的状态;
  
  

  
  

  STARTED

  在 `onStart()` 调用之后，`onPause()` 调用之前的状态;
  
  

  
  

RESUMED

    在 `onResume()` 调用时的状态;



   `DESTROYED`



   `onDestory()` 调用时的状态;

相关接口

• 
  

  LifecycleObserver

  
  

  基础 Lifecycler 实现接口,一般调用不到,可用于自定义的组件，从而避免在 Act 或者 Fragment 中的模版代码,例如ViewTreeLifecyleOwner ；

  
  


• 
  

  LifecycleEventObserver

  
  

  可以接受所有生命周期变化的接口；

  
  


• 
  

  FullLifecycleObserver

  
  

  用于监听生命周期变化的接口，提供了 onCreate()、onStart()、onPause()、onStop()、onDestory()、onAny();

  
  


• 
  

  DefaultLifecycleObserver

  
  

  FullLifecycleObserver 的默认实现版本,相比前者，增加了默认 null 实现；

  
  

举个栗子

如下所示，通过实现 DefaultLifecycleObserver 接口，我们可以在中重写我们想要监听的生命周期方法，从而将业务代码从主类中拆离出来，且更便于复用。最后在相关类中直接使用 lifecycle.addObserver() 方法添加实例即可，这也是google推荐的用法。

上述示例中，我们使用了 viewLifecycle ,而不是 lifecycle ,这里顺便提一下。

见名之意，前者是视图(view)生命周期，后者则是非视图的生命周期，具体区别如下：

viewLifecycle 只会在 onCreateView-onDestroyView 之间有效。

lifecycle 则是代表 Fragment 的生命周期,在视图未创建时，onCreate(),onDestory() 时也会被调用到。

或者你有某个自定义View,想感知Fragment或者Act的生命周期，从而做一些事情，比如Banner组件等，与上面示例类似：

当然你也可以选择依赖：androidx.lifecycle:lifecycle-runtime 扩展库。

从而使用 view.findViewTreeLifecycleOwner() 的扩展函数获得一个 LifecycleOwner,从而在View内部自行监听生命周期,免除在Activity手动添加观察者的模版代码。

lifecycle.addObserver(view)

源码解析

Lifecycle

在官方的解释里，Lifecycle 是一个类，用于存储有关组件(Act或Fragment)声明周期状态新的类，并允许其他对象观察此类。

直接去看 Lifecycle 的源码，其实现方式如下：

总体设计如上所示,比较简单,就是观察者模式的接口模版：

使用者实现 LifecycleObserver 接口(),然后调用 addObserver() 添加到观察者列表，取消观察者时调用 rmeoveObserver() 移除掉即可。在相应的生命周期变动时，遍历观察者列表，然后通知实现了 LifecycleObserver 的实例，从而调用相应的方法。

因为其是一个抽象类，所以我们调用的一般都是它的具体实现类，也就是 LifecycleRegistry ,目前也是其的唯一实现类。

LifecycleRegistry

Lifecycle 的具体实现者,正如其名所示，主要用于管理当前订阅的 观察者对象 ,所以也承担了 Lifecycle 具体的实现逻辑。因为源码较长,所以我们做了一些删减，只需关注主流程即可，伪代码如下：

public class LifecycleRegistry extends Lifecycle {

  

    // 生命周期观察者map,LifecycleObserver是观察者接口,ObserverWithState具体的状态分发的包装类

    private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap;

    // 当前生命周期状态

    private State mState = INITIALIZED;

    // 持有生命周期的提供商,Activity或者Fragment的弱引用

    private final WeakReference<LifecycleOwner> mLifecycleOwner;

    // 当前正在添加的观察者数量,默认为0,超过0则认为多线程调用

    private int mAddingObserverCounter = 0;

    // 是否正在分发事件

    private boolean mHandlingEvent = false;

    // 是否有新的事件产生

    private boolean mNewEventOccurred = false;

    // 存储主类的事件state

    private ArrayList<State> mParentStates = new ArrayList<>();



    @Override

    public void addObserver(@NonNull LifecycleObserver observer) {

        // 初始化状态,destory or init

        State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;

        // 📌 初始化实际分发状态的包装类

        ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);

        // 将观察者添加到具体的map中,如果已经存在了则返回之前的,否则创建新的添加到map中

        ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

        // 如果上一步添加成功了,putIfAbsent会返回null

        if (previous != null) {

            return;

        }

        // 如果act或者ff被回收了,直接return

        LifecycleOwner lifecycleOwner = mLifecycleOwner.get();

        if (lifecycleOwner == null) {

            return;

        }

        // 当前添加的观察者数量!=0||正在处理事件

        boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;

        // 📌 取得观察者当前的状态

        State targetState = calculateTargetState(observer);

        mAddingObserverCounter++;

        // 📌 如果当前观察者状态小于当前生命周期所在状态&&这个观察者已经被存到了观察者列表中

        while ((statefulObserver.mState.compareTo(targetState) < 0

                && mObserverMap.contains(observer))) {

            // 保存当前的生命周期状态

            pushParentState(statefulObserver.mState);

            // 返回当前生命周期状态对应的接下来的事件序列

            final Event event = Event.upFrom(statefulObserver.mState);

            ...

            // 分发事件

            statefulObserver.dispatchEvent(lifecycleOwner, event);

            // 移除当前的生命周期状态

            popParentState();

            // 再次获得当前的状态,以便继续执行

            targetState = calculateTargetState(observer);

        }

        

        // 处理一遍事件,保证事件同步

        if (!isReentrance) {

            sync();

        }

        // 回归默认值

        mAddingObserverCounter--;

    }

    ...

    static class ObserverWithState {

        State mState;

        LifecycleEventObserver mLifecycleObserver;



        ObserverWithState(LifecycleObserver observer, State initialState) {

            // 初始化事件观察者

            mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);

            mState = initialState;

        }



        void dispatchEvent(LifecycleOwner owner, Event event) {

            State newState = event.getTargetState();

            mState = min(mState, newState);

            mLifecycleObserver.onStateChanged(owner, event);

            mState = newState;

        }

    }

    ...

}

我们重点关注的是 addObserver() 即订阅生命周期变更时的逻辑,具体如下：

0. 先初始化当前观察者的状态，默认两种，即 DESTROYED(销毁) 或者 INITIALIZED(无效)，分别对应 onDestory() 和 onCreate() 之前；


1. 初始化 状态观察者(ObserverWithState) ，内部使用 Lifecycling.lifecycleEventObserver() 将我们传递进来的 生命周期观察者(LifecycleObser) 包装为一个 生命周期[事件]观察者LifecycleEventObserver，从而在状态变更时触发事件通知；


2. 将第二步生成的状态观察者添加到缓存map中,如果之前已经存在，则停止接下来的操作,否则继续初始化；


3. 调用 calculateTargetState() 获得当前真正的状态。


4. 开始事件轮训，如果 当前观察者的状态小于此时真正的状态 && 观察者已经被添加到了缓存列表 中，则获得当前观察者下一个状态，并触发相应的事件通知 dispatchEvent(),然后继续轮训。直到不满足判断条件；

需要注意的是, 关于状态的判断,这里使用了compareTo() ,从而判断当前状态枚举是否小于指定状态。

Activity中的实现

Tips:

写过权限检测库的小伙伴，应该很熟悉，为了避免在 Activity 中手动实现 onActivityRequest() ,从而实现以回调的方式获得权限结果，我们往往会使用一个透明的 Fragment ,从而将模版方法拆离到单独类中，而这种实现方式正是组合的思想。

而 Lifecycle 在 Activity 中的实现正是上述的方式。

如下所示，当我们在 Activity 中调用 lifecycle 对象时,内部实际上是调用了 ComponentActivity.mLifecycleRegistry,具体逻辑如下：

不难发现，在我们的 Activity 初始化时,相应的 LifecycleRegistry 已经被初始化。

在上面我们说过，为了避免对基类的入侵，我们一般会用组合的方式，所以这里的 ReportFragment 正是 Lifecycle 在 Activity 中具体的逻辑承载方,具体逻辑如下：

ReportFragment.injectIfNeededIn

内部会对sdk进行判断，对应着两套流程，对于 sdk>=29 的,通过注册 Activity.registerActivityLifecycleCallbacks() 事件实现监听，对于 sdk<29 的,重写 Fragment 相应的生命周期方法完成。

ReportFragment 具体逻辑如下：

Fragment中的实现

直接去 Fragment.lifecycle 中看一下即可,伪代码如下:

总结如下：lifecycle 实例会在 Fragment 构造函数 中进行初始化,而 mViewLifecycleOwner 会在 performCreateView() 执行时初始化,然后在相应的 performXxx 生命周期执行时,调用相应的 lifecycle.handleLifecycleEvent() 从而完成事件的通知。

总结

Lifecycle 作为 JetPack 的基石，而理解其是我们贯穿相应生命周期的关键所在。

关于生命周期的通知，Lifecycle 并没有采用直接通知的方式,而是采用了 Event(事件) + State(状态) 的设计方式。

• 对于外部生命周期订阅者而言，只需要关注事件 Event 的调用；


• 而对于Lifecycle而言,其内部只关注 State ，并将生命周期划分为了多个阶段,每个状态又代表了一个事件集，从而对于外部调用者而言，无需拘泥于当前具体的状态是什么。

在具体的实现底层上面:

• 在 Activity 中，采用组合的方式而非继承，在 Activity.onCreate() 触发时，初始化了一个透明Fragment,从而将逻辑存于其中。对于sdk>=29的版本，因为 Activity 本身有监听生命周期的方法,从而直接注册监听器，并在相应的会调用触发生命周期事件更新;对于sdk<29的版本，因为需要兼容旧版本,所以重写了 Fragment 相应的生命周期方法，从而实现手动触发更新我们的生命周期观察者。


• 在 Fragment 中,会在 Fragment 构造函数中初始化相应的 Lifecycle ,并重写相应的生命周期方法，从而触发事件通知,实现生命周期观察者的更新。

每当我们调用 addObserver() 添加新的观察者时：

内部都会对我们的观察者进行包装，并将其包装为一个具体的事件观察者 LifecycleEventObserver,以及生成当前的观察者对应的状态实例(内部持有LifecycleEventObserver)，并将其保存到 缓存map 中。接着会去对比当前的 观察者的状态 和 lifecycle此时实际状态 ,如果 当前观察者状态<lifecycle对应的状态 ，则触发相应 Event 的通知,并 更新此观察者对应的状态 ，不断轮训，直到当前观察者状态 >= lifecycle 对应状态。

参阅

• Android-使用生命周期感知型组件处理生命周期

关于我

我是 Petterp ,一个 Android工程师 ，如果本文对你有所帮助，欢迎点赞支持，你的支持是我持续创作的最大鼓励！

LiveData 是否已经被弃用?

没有被弃用。在可以预见的未来也没有废弃的计划。

LiveData 可以使用简单的方式获取一个易于观察、状态安全的对象。虽然其缺少一些丰富的操作符，但是对于一些简单的 UI 业务场景已经足够。

Flow 有 LiveData 相同的功能，其包含大量丰富的操作符，可以简单的完成复杂的业务逻辑处理。相应的会增加一定的使用门槛，如果不需要 Flow 的 全部功能，继续使用 LiveData 即可。

更多内容：Migrating from LiveData to Kotlin’s Flow

什么是业务逻辑？为什么将业务逻辑移动到 Data Layer ？

业务逻辑是给 App 带来价值的东西，是一系列决定 App 如何运行的规则集。比如，如果你有一个显示新闻文章的 App，你点击书签按钮，从书签文章到持久的交互，这就是业务逻辑。

将业务逻辑移动到 Data Layer 的主要原因是提供单一信源，App 的不同页面和不同逻辑使用到这部分数据将从同一个地方进行获取，方便统一管理；其次是分离职责，将不同的处理逻辑（控制UI的与操作数据）分散在不同的层级中，可以减少各自交互的复杂度。

如何在 ViewModel 中获取系统资源（字符串、颜色等）？

访问资源只应该放在 UI 层，如 View 或者是 Compose。 可以在 ViewModel 中提供资源 ID，但是不应该直接在 ViewModel 中直接访问资源。除了单一职责之外，就是可以响应手机配置的变化：

• 切换语言的时候，会变成对应的语种字符串；
• 切换亮暗模式的时候，对应的颜色会随之变化；

另外就是 Context 的上下文与 ViewModel 的生命周期不一致，可能会导致内存泄漏。

如何让 Service 与 Compose/ViewModel 进行交互？

他们不应该直接进行交互或者说是互相引用。

应该采用单一信源的方式定义一个 Repository，在 Service/ViewModel 中调用 Repository 中的方法来更改状态，UI（Views/Compose） 层通过数据流的方式监听数据变化。

可以确定的是，在 ViewModel 中应尽可能少的依赖 Android 系统组件，如 Service、Activity 等。

未来平稳过度到 KMM/KMP 的最佳实践有哪些？

通常最佳实践会随着时间的推移而建立起来的。对于未来如果 KMM/KMP ，并不需要做过多的事情，遵循架构指南即可。比如：将数据的操作放在 Data Layer，在此层尽量少的调用系统 API。但是目前并需要定义跨端的接口定义，因为 KMM/KMP 还是比较新的技术，在他被大规模使用之前还有不少变数。

ViewModel 被建议当做 State Holders 之后，其在 MVVM 中的职责？

ViewModel 在 MVVM 中就是一个状态持有者。在不同的语义场景下可能有不同的含义。如果是整个页面中的 View（不论是 Activity 还是 Compose 中的目的地），其对应的是 AAC 中的 ViewModel 类。如果是普通的自定义 View 或是 Compose 中的一个可组合函数，那么 View 的状态持有者定义成一个普通的类就可以。这里可以类比下 RecycleView 中的 ViewHolder 设计。

所以这是根据 UI 的范围所决定的，整个页面对应的就是 ViewModel，局部页面对应的就是普通的类。

ViewModel 可以当做是一种特殊的状态管理器，他可以持有普通的 State Holders。

架构指南中的层级对模块化开发有什么建议么？

官方正在研究模块化的架构指南，希望今年能够完成。

应该在 DataSource/Repostory/UseCase 中使用 Flow 么？

可以，但是应该在合适的地方使用 Flow。如果是提供一个一次性的数据（比如从云端接口返回的一个数据），使用 suspend 函数是比较合适的。如果是从 Room 或者是其他类似的数据源中提供可以变化的数据流时，应该使用 Flow。

在 Repository 中会合并多个数据源的数据，这些数据可能会会随时间的变化而变化，因此需要使用 Flow。

什么时候应该使用 UseCase ？

UseCase 主要是为了解决以下两个问题：

• 封装复杂的业务逻辑，避免出现大型的 ViewModel 类；
• 封装多 ViewModel 通用的业务逻辑，避免代码重复；

满足上述两个条件的任何一个都可以使用 UseCase。除此之外，使用 UseCase 之后可以 ViewModel 就不必依赖 Repository，而是在构造函数中直接使用 UseCase，这样在构造函数中就可以知道 ViewModel 中做了哪些事情。

在 Repository 中传递多个 Suspend 函数是反模式的么？

并不是，如果只是进行一次性的操作应该使用 suspend 函数。否则的话应该使用 Flow。

ViewModel 中如何处理页面跳转？

这部分内容在 UI Layer 中有提到，我们把他称之为 UI Event 之类的东西。不管是 UI 事件还是构建 UI 的数据都应该放在 UiState 中，一旦 UI 层监听到对应的事件，进行响应的跳转即可。

具体取决于采用何种方式建模，比如你可以把他定义为一个 Boolean 值，在 ViewModel 中更新对应的 UiState，UI 层就可以根据对应的事件跳转到对应的页面中了。

以用户登录为例，用户登录成功之后需要进入到主页面。这其实是一种状态的变化，从未登录变成了已登录，所以只要改变 UiState UI 层就可以处理他。你可能会说这是不是太复杂了？

对一些人来说这可能是一个顿悟时刻，不会把命令视为事件。ViewModel 中的事件整体上来看就是 App 的状态数据，这样 ViewModel 并不是告诉 UI 层应该做什么，而是 UI 层根据 App 的状态去做一些事情，这是思维方式上的转变。

如果根据用户配置定义导航视图？

和上一个问题基本类似，通过设置不同的 UiState 来控制导航到不同的视图。

WorkManager/Service 在架构中的什么位置？

WorkManager/Service 应该作为入口类来调用 Repository 中的 API。这样可以使我们的业务逻辑与 Android 系统的 API 中解放出来，因为 Android 系统 API 的行为逻辑一般是我们不可控的。当然还有另外的好处，比如更容易测试、以及后续有可能迁移到 KMM 。

当然，WorkManager 有其 API 自身的优势，其内部逻辑与节省电量 、WIFI 链接等 Android 平台的优势，可以根据设备自身的状态进行一次性或者周期性的任务。当然，如果是正常的耗时操作（如网络请求）使用简单的协程即可。

为什么有时在 Repository 中使用 IoDispatcher 访问数据库，有时不用？

Room 数据库目前已支持 suspend 函数，其默认会将任务放到后台线程中执行，当然也可以对其进行自定义的配置。当你调用 Room 的一个 suspend 函数的时候，你并不需要关心线程的问题，把这个问题交给 Room 处理即可。这样 Room 的所有操作都会放到 Room 控制的线程中执行，以尽可能的减少因访问同一个文件而导致的互相争夺资源的问题。

不管由于什么原因你无法使用/提供 suspend 函数，Room 不支持将其移动到另一个线程中。这种情况下可以使用 IO 线程或者 IoDispatcher 。通常情况下还是建议使用 suspend 函数或是 Flow。

另外，每个 DataSource 中都建议处理自己的线程问题，所以在 Repository 中并不需要关心 IO 线程的问题。

当我们处理内存敏感数据时，将复杂数据从一个屏幕传输到另一个屏幕的建议方法是什么？

最原始的处理方式可能是使用 Activity 当做两个 Fragment 的中介，在 Activity 中实现 Fragment 中定义接口，当 Fragment 被关联到 Activity 之后就可以调用 Fragment 中相关的逻辑了。当然这种方式已经一去不复返了。

现在可以使用 ViewModel 调用 UseCase 或者是 Repository 来更新数据，另外的 ViewModel 会使用 Flow 的方式接收到数据的变化，然后根据变化做出相应的处理即可。

在 Compose 中应该使用 MVVM 还是 MVI ?

两者没有本质的区别，都是采用单向数据流的方式。MVI 的特点是将 UI 事件封装成枚举方式，统一在一个函数中处理事件。

随着项目的扩展，我应该将 Domain Layer 或者 Data Layer移动到单独的模块吗？

这取决于你是否想进行模块化，但是两者的差异并不大，这里并没有一个明确的答案。 随着项目的扩展建议把 Data Layer 放到单独的 module 中，如果有 Domain Layer 的话，也是建议把他放在单独的模块中。

[!info] 注： 如果是在多仓库的模块架构以及同一数据层可能有不同 UI 实现的场景下建议采用上述方式，如果没有类似需求的话，个人建议通过 Feature （特性）划分模块，这样可以减少不必要的编译耗时，同样的功能也想多内聚。 当然，如果有对外提供 SDK 需求的，也应将 Data Layer 定义在单独的模块中。

将错误从其他层返回到表示层的最佳方法是什么？

指导文档 中的建议的方式是使用协程的异常处理机制将错误传递到展示层（UI Layer）。

对于使用协程或者是 Flow 的方式，建议使用协程的异常处理机制，当然 Folw 中也可以使用 catch 操作符；对于使用 suspend 函数的地方可以使用 try/catch 块。

另外一种 Data Layer 和上层交互的方式就是使用 Kotlin 自带的 Result<T> 类，此类中除了包含正常的数据 T 之外，还包含错误信息。除此之外提供很多好用的 API ，建议使用。

更多内容：Exceptions in coroutines

新的架构方式是否适用与非移动端的领域？如平板、Auto 等

在上述的领域上，仍然建议使用 UI Layer、Domain Layer、Data Layer 这种架构方式。这种架构方式主要是用到了关注点分离以及数据驱动的方式，而这两种设计原则对非移动端的应用也是适用的。

多 Activity 还是单 Activity + 多 Fragment ？

Activity 有其自身的一些特定及职责，在以下场景中应该使用 Activity：

• 当前页面需要支持 PIP（画中画）功能时；
• 当 App 有多个入口可以启动时，如在其他 App 中拉起当前 App 中的一个二级页面，这个页面就需要使用 Activity；

简而言之，就是需要在 manifest 文件中 exported 需要被设置为 true 的逻辑都需要使用 Activity 来实现。

除此之外的一些逻辑，通常是 App 内部的一些页面导航，这个时候应该使用 Fragment 来实现。当然，现在我们还有另外一个新的选择，那就是使用 Compose 。

总结

这篇文章中的内容根据 Arch - MAD Skills 中的问答部分，结合自己的理解整理而得，会包含个人观点，更多详细内容可以观看原文。

协程（coroutines）的封装

在默认的Kotlin协程环境中,我们需要自定义协程的作用域CoroutineScope，还有负责维护协程的调度等等，有没有方法可以让协程的使用者屏蔽对底层协程的认识，简单就能使用呢？这里带来了一个封装思路。（这里没有考虑生命周期相关的封装，如果需要实际落地可以在deferred里面封装），这里有个背景，比如在java kotlin混合开发的时候，如果java同学不会kotlin，就需要更上一层的抽象了

封装前例子

假如我们有个一个suspend函数

suspend fun getTest():String{

    delay(5000)

    return "11"

}

我们要实现的封装是：

1.执行suspend函数，并且使用者对底层无感知，无需了解协程就可以使用，这就要求我们屏蔽CoroutineScope细节

2.自动类型转换，比如返回String我们就应该可以在成功的回调中自动转型为String

3.成功的回调，失败的回调等

4.要不，来个DSL风格

//

async{

    // 请求

    getTest()



}.await(onSuccess = {

    //成功时回调,并且具有返回的类型

   Log.i("print",it)

},onError = {



},onComplete = {



})

可以看到，编译时就已经将it变为我们想要的类型了！
我们最终想要实现上面这种方式

封装开始

思路：我们自动对请求进行线程切换，使用Dispatchers即可，还有就是我们需要有监听的回调和DSL写法，所以就可以考虑用协程的async方式发起一个请求，返回值是Deferred类型，我们就可以使用扩展函数实现.await的形式！如果熟悉flutter的同学看的话，是不是很像我们的dio请求方式呢！下面是代码，可以根据更细节的需求进行补充噢：

fun <T> async(loader:suspend () ->T): Deferred<T> {

    val deferred = CoroutineScope(Dispatchers.IO).async {

        loader.invoke()

    }

    return deferred

}



fun <T> Deferred<T>.await(onSuccess:(T)->Unit,onError:(e:Exception)->Unit,onComplete:(()->Unit)?=null){

    CoroutineScope(Dispatchers.Main).launch {



        try{          

            val result = this@await.await()     

            onSuccess(result)

            

        }catch (e:Exception){

            onError(e)

        }

        finally {

            onComplete?.invoke()

        }

    }

}

总结

是不是非常好玩呢！我们实现了一个dio风格的请求，对于开发者来说，只需定义suspend修饰的函数，就可以无缝使用我们的请求框架！

前言

我们都知道 Activity 与 Fragment 都是有生命周期的，例如：onCreate()、onStop() 这些回调方法就代表着其生命周期状态。我们开发者所做的一些操作都应该合理的控制在生命周期内，比如：当我们在某个 Activity 中注册了广播接收器，那么在其 onDestory() 前要记得注销掉，避免出现内存泄漏。

生命周期的存在，帮助我们更加方便地管理这些任务。但是，在日常开发中光凭 Activity 与 Fragment 可不够，我们通常还会使用一些组件来帮助我们实现需求，而这些组件就不像 Activity 与 Fragment 一样可以很方便地感知到生命周期了。

假设当前有这么一个需求：

开发一个简易的视频播放器组件以供项目使用，要求在进入页面后注册播放器并加载资源，一旦播放器所处的页面不可见或者不位于前台时就暂停播放，等到页面可见或者又恢复到前台时再继续播放，最后在页面销毁时则注销掉播放器。

试想一下：如果现在让你来实现该需求？你会怎么去实现呢？

实现这样的需求，我们的播放器组件就需要获取到所处页面的生命周期状态，在 onCreate() 中进行注册，onResume() 开始播放，onStop() 暂停播放，onDestroy() 注销播放器。

最简单的方法：提供方法，暴露给使用方，供其自己调用控制。

class VideoPlayerComponent(private val context: Context) {



    /**

     * 注册，加载资源

     */

    fun register() {

        loadResource(context)

    }



    /**

     * 注销，释放资源

     */

    fun unRegister() {

        releaseResource()

    }



    /**

     * 开始播放当前视频资源

     */

    fun startPlay() {

        startPlayVideo()

    }



    /**

     * 暂停播放

     */

    fun stopPlay() {

        stopPlayVideo()

    }

}

然后，我们的使用方MainActivity自己，主动在其相对应的生命周期状态进行控制调用相对应的方法。

class MainActivity : AppCompatActivity() {

    private lateinit var videoPlayerComponent: VideoPlayerComponent



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

	videoPlayerComponent = VideoPlayerComponent(this)

        videoPlayerComponent.register(this)

    }



    override fun onResume() {

        super.onResume()

        videoPlayerComponent.startPlay()

    }



    override fun onPause() {

        super.onPause()

        videoPlayerComponent.stopPlay()

    }



    override fun onDestroy() {

        videoPlayerComponent.unRegister()

        super.onDestroy()

    }



}

虽然实现了需求，但显然这不是最优雅的实现方式。一旦使用方忘记在 onDestroy() 进行注销播放器，就容易造成内存泄漏，而忘记注销显然是一件很容易发生的事情😂 。

回想初衷，之所以将方法暴露给使用方来调用，就是因为我们的组件自身无法感知到使用者的生命周期。所以，一旦我们的组件自身可以感知到使用者的生命周期状态的话，我们就不需要将这些方法暴露出去了。

那么问题来了，组件如何才能感知到生命周期呢？

答：Lifecycle !

直接上案例，借助 Lifecycle 我们改进一下我们的播放器组件👇

class VideoPlayerComponent(private val context: Context) : DefaultLifecycleObserver {



    override fun onCreate(owner: LifecycleOwner) {

        super.onCreate(owner)

        register(context)

    }



    override fun onResume(owner: LifecycleOwner) {

        super.onResume(owner)

        startPlay()

    }



    override fun onPause(owner: LifecycleOwner) {

        super.onPause(owner)

        stopPlay()

    }



    override fun onDestroy(owner: LifecycleOwner) {

        super.onDestroy(owner)

        unRegister()

    }



    /**

     * 注册，加载资源

     */

    private fun register(context: Context) {

        loadResource(context)

    }



    /**

     * 注销，释放资源

     */

    private fun unRegister() {

        releaseResource()

    }



    /**

     * 开始播放当前视频资源

     */

    private fun startPlay() {

        startPlayVideo()

    }



    /**

     * 暂停播放

     */

    private fun stopPlay() {

        stopPlayVideo()

    }

}

改进完成后，我们的调用方MainActivity只需要一行代码即可。

class MainActivity : AppCompatActivity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

        

        lifecycle.addObserver(VideoPlayerComponent(this))

    }

}

这样是不是就优雅多了。

那这 Lifecycle 又是怎么感知到生命周期的呢？让我们这就带着问题，出发探一探它的实现方式与源码！

如果让你来做，你会怎么做

在查看源码前，让我们试着思考一下，如果让你来实现 Jetpack Lifecycle 这样的功能，你会怎么做呢？该从何入手呢？

我们的目的是不通过回调方法即可获取到生命周期，这其实就是解耦，实现解耦的一种很好方法就是利用观察者模式。

利用观察者模式，我们就可以这么设计👇

被观察者对象就是生命周期，而观察者对象则是需要知晓生命周期的对象，例如：我们的三方组件。

接着我们就具体探探源码，看一看Google是如何实现的吧。

Google 实现方式

Lifecycle

一个代表着Android生命周期的抽象类，也就是我们的抽象被观察者对象。

public abstract class Lifecycle {



    public abstract void addObserver(@NonNull LifecycleObserver observer);



    public abstract void removeObserver(@NonNull LifecycleObserver observer);



    public enum Event {

        ON_CREATE,

        ON_START,

        ON_RESUME,

        ON_PAUSE,

        ON_STOP,

        ON_DESTROY,

        ON_ANY;

    }



    public enum State {

        DESTROYED,

        INITIALIZED,

        CREATED,

        STARTED,

        RESUMED;

    }



}

内包含 State 与 Event 分别者代表生命周期的状态与事件，同时定义了抽象方法 addObserver(LifecycleObserver) 与removeObserver(LifecycleObserver) 方法用于添加与删除生命周期观察者。

Event 很好理解，就像是 Activity | Fragment 的 onCreate()、onDestroy()等回调方法，它代表着生命周期的事件。

那这 State 又是什么呢？何为状态？他们之间又是什么关系呢？

Event 与 State 之间的关系

关于 Event 与 State 之间的关系，Google官方给出了这么一张两者关系图👇

乍一看，可能第一感觉不是那么直观，我整理了一下👇

• INITIALIZED：在 ON_CREATE 事件触发前。


• CREATED：在 ON_CREATE 事件触发后以及 ON_START 事件触发前；或者在 ON_STOP 事件触发后以及 ON_DESTROY 事件触发前。


• STARTED：在 ON_START 事件触发后以及 ON_RESUME 事件触发前；或者在 ON_PAUSE 事件触发后以及 ON_STOP 事件触发前。


• RESUMED：在 ON_RESUME 事件触发后以及 ON_PAUSE 事件触发前。


• DESTROYED：在 ON_DESTROY 事件触发之后。

Event 代表生命周期发生变化那个瞬间点，而 State 则表示生命周期的一个阶段。这两者结合的好处就是让我们可以更加直观的感受生命周期，从而可以根据当前所处的生命周期状态来做出更加合理操作行为。

例如，在LiveData的生命周期绑定观察者源码中，就会判断当前观察者对象的生命周期状态，如果当前是DESTROYED状态，则直接移除当前观察者对象。同时，根据观察者对象当前的生命周期状态是否 >= STARTED来判断当前观察者对象是否是活跃的。

class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {

   ......



   @Override

   boolean shouldBeActive() {

      //根据观察者对象当前的生命周期状态是否 >= STARTED 来判断当前观察者对象是否是活跃的。

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

   }



  @Override

  public void onStateChanged(@NonNull LifecycleOwner source,

          @NonNull Lifecycle.Event event) {

      //根据当前观察者对象的生命周期状态，如果是DESTROYED，直接移除当前观察者

      Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();

      if (currentState == DESTROYED) {

          removeObserver(mObserver);

          return;

      }

      ......

  }

  ......



}

其实 Event 与 State 这两者之间的联系，在我们生活中也是处处可见，例如：自动洗车。

想必现在你对 Event 与 State 之间的关系有了更好的理解了吧。

LifecycleObserver

生命周期观察者，也就是我们的抽象观察者对象。

public interface LifecycleObserver {



}

所以，我们想成为观察生命周期的观察者的话，就需要具体实现该接口，也就是成为具体观察者对象。

换句话说，就是如果你想成为观察者对象来观察生命周期的话，那就必须实现 LifecycleObserver 接口。

例如Google官方提供的 DefaultLifecycleObserver、 LifecycleEventObserver 。

LifecycleOwner

正如其名字一样，生命周期的持有者，所以像我们的 Activity | Fragment 都是生命周期的持有者。

大白话很好理解，但代码应该如何实现呢？

抽象概念 + 具体实现

抽象概念：定义 LifecycleOwner 接口。

public interface LifecycleOwner {

    @NonNull

    Lifecycle getLifecycle();

}

具体实现：Fragment 实现 LifecycleOwner 接口。

public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,

        ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner,

        ActivityResultCaller {



    public Lifecycle getLifecycle() {

        return mLifecycleRegistry;

    }

......



}

具体实现：Activity 实现 LifecycleOwner 接口。

public class ComponentActivity extends androidx.core.app.ComponentActivity implements

        ContextAware,

        LifecycleOwner,

        ViewModelStoreOwner,

        HasDefaultViewModelProviderFactory,

        SavedStateRegistryOwner,

        OnBackPressedDispatcherOwner,

        ActivityResultRegistryOwner,

        ActivityResultCaller {



@NonNull

    @Override

    public Lifecycle getLifecycle() {

        return mLifecycleRegistry;

    }



......



}

这样，Activity | Fragment 就都是生命周期持有者了。

疑问？在上方 Activity | Fragment 的类中，getLifecycle() 方法中都是返回 mLifecycleRegistry，那这个 mLifecycleRegistry 又是什么玩意呢？

LifecycleRegistry

是 Lifecycle 的一个具体实现类。

LifecycleRegistry 负责管理生命周期观察者对象，并将最新的生命周期事件与状态及时通知给对应的生命周期观察者对象。

添加与删除观察者对象的具体实现方法。

//用户保存生命周期观察者对象

private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();



@Override

public void addObserver(@NonNull LifecycleObserver observer) {

    enforceMainThreadIfNeeded("addObserver");

    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;

    //将生命周期观察者对象包装成带生命周期状态的观察者对象

    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);

    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

    ... 省略代码 ...

}



@Override

public void removeObserver(@NonNull LifecycleObserver observer) {

    mObserverMap.remove(observer);

}

可以从上述代码中发现，LifecycleRegistry 还对生命周期观察者对象进行了包装，使其带有生命周期状态。

static class ObserverWithState {

    //生命周期状态

    State mState;

    //生命周期观察者对象

    LifecycleEventObserver mLifecycleObserver;



    ObserverWithState(LifecycleObserver observer, State initialState) {

        //这里确保observer为LifecycleEventObserver类型

        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);

        //并初始化了状态

        mState = initialState;

    }



    //分发事件

    void dispatchEvent(LifecycleOwner owner, Event event) {

        //根据 Event 得出当前最新的 State 状态

        State newState = event.getTargetState();

        mState = min(mState, newState);

        //触发观察者对象的 onStateChanged() 方法

        mLifecycleObserver.onStateChanged(owner, event);

        //更新状态

        mState = newState;

    }

}

将最新的生命周期事件通知给对应的观察者对象。

public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {

    ... 省略代码 ...

    ObserverWithState observer = mObserverMap.entrySet().getValue();

    observer.dispatchEvent(lifecycleOwner, event);

		

    ... 省略代码 ...

    mLifecycleObserver.onStateChanged(owner, event);

}

那 handleLifecycleEvent() 方法在什么时候被调用呢？

相信看到下方这个代码，你就明白了。

public class FragmentActivity extends ComponentActivity {

   ......



   final LifecycleRegistry mFragmentLifecycleRegistry = new LifecycleRegistry(this);



   @Override

   protected void onCreate(@Nullable Bundle savedInstanceState) {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);

   }



   @Override

   protected void onDestroy() {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);

   }



   @Override

   protected void onPause() {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);

   }



   @Override

   protected void onStop() {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);

   }



   ......



}

在 Activity | Fragment 的 onCreate()、onStart()、onPause()等生命周期方法中，调用LifecycleRegistry 的 handleLifecycleEvent() 方法，从而将生命周期事件通知给观察者对象。

总结

Lifecycle 通过观察者设计模式，将生命周期感知对象与生命周期提供者充分解耦，不再需要通过回调方法来感知生命周期的状态，使代码变得更加的精简。

虽然不通过 Lifecycle，我们的组件也是可以获取到生命周期的，但是 Lifecycle 的意义就是提供了统一的调用接口，让我们的组件可以更加方便的感知到生命周期，方便广达开发者。而且，Google以此推出了更多的生命周期感知型组件，例如：ViewModel、LiveData。正是这些组件，让我们的开发变得越来越简单。

前言

OK，这是Android系统启动的第二篇文章。第二篇我们讲解一个我们一直都在用，但是却很少提起的进程---Zygote。
提到Zygote可能了解一些的小伙伴会说，它是分裂进程用的。没错它最大的作用的确是分裂进程，但是它除了分裂进程外还做了什么呢。
还是老规矩，让我们抱着几个问题来看文章。最后在结尾，再对问题进行思考回复。

1. 你能大概描述一遍Zygote的启动流程吗


2. 我们为什么可以执行java代码，和zygote有什么关系


3. Zygote到底都做了哪些事情

另外，我最近也看了一些写底层的文章。要么就是言简意赅到只知道Zygote的作用，但是完全不知道如何实现的，就像是背作文一样。要么是全篇都是代码，又臭又长，让人完全没有看下去的动力。

不过作为一个读者，太长的我可能完全不想看，太短的又真的完全就是被课文一点都不明白原理。

因此，本篇文章，仍旧会引入一些代码，方便大家通过代码方便记忆。但是又会将代码进行精简，以免给大家造成过度疲劳。我们的目的都是希望用最少的时间，能掌握更多的知识。

读源码时：不要过于纠结细节，不要过于纠结细节，不要过于纠结细节！重要的事情说三遍！！！

OK,让我们进入正题瞅瞅Zygote到底是个什么东西。

1.C++还是Java

选这个当标题当然是有原因的。我们知道的是Android系统启动的时候，运行的是Linux内核，执行的是C++代码。这是一个很有趣的事情。

因为我们在写App的时候，AndroidStudio默认给我们创建的都是Activity.java，而选择的语言，要么是Java要么就是Kotlin。

启动时候运行的是C++代码，应用层却可以使用Java代码，这到底是为什么呢？其实这就是Zygote的功劳之一。

2.Native层

Init进程创建Zygote时，会调用app_main.cpp的main() 方法。此时它依旧运行的是C++代码。我们通过下面的代码，来看下它到底做了什么。

这里它做的最关键的一件事就是启动AndroidRuntime（Android运行时）。另外这里需要注意的是 start方法 中的 "com.android.internal.os.ZygoteInit" 这个类似于全类名。他到底是做什么的？别着急，大概2分钟后，你可能就会得到答案。

Zygote的新手村：app_main.cpp

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

{

    //  创建Android运行时对象

    AppRuntime runtime(argv[0], computeArgBlockSize(argc, argv));

    // 代码省略...

    

    // 调用AppRuntime.start方法，

    // 而AppRuntime是AndroidRuntime的子类，并且没有重写start方法

    // 因此调用的是AndroidRuntime的start方法

    runtime.start("com.android.internal.os.ZygoteInit", args, zygote);

}

精简后的代码告诉我们，这里一共就做了两件事，第一件创建AppRuntime，第二件调用start方法。

不过，AppRuntime是AndroidRuntime的子类，他没有重写start方法，因此这里调用的是 AndroidRuntime的start() 方法。

奇迹的诞生地：AndroidRuntime：

这里我依旧只保留关键代码，源码关键注释也进行了保留。由下方代码看出这里做了三件改变命运的事情。

1. startVM -- 启动Java虚拟机


2. startReg -- 注册JNI


3. 通过JNI调用Java方法，执行com.android.internal.os.ZygoteInit 的 main 方法

/*

 * Start the Android runtime. 

 */

void AndroidRuntime::start(const char* className, const Vector<String8>& options, bool zygote)

{

    /* start the virtual machine */

    JNIEnv* env;

    if (startVm(&mJavaVM, &env, zygote, primary_zygote) != 0) {

        return;

    }



    /*

     * Register android functions.

     */

    if (startReg(env) < 0) {

        ALOGE("Unable to register all android natives\n");

        return;

    }

    /*

     * Start VM.  This thread becomes the main thread of the VM, and will

     * not return until the VM exits.

     */

    jmethodID startMeth = env->GetStaticMethodID(startClass, "main","([Ljava/lang/String;)V");

    env->CallStaticVoidMethod(startClass, startMeth, strArray);

}

有了JVM，注册了JNI，我们就可以执行Java代码了。

这里我个人建议不要过于纠结细节，比如JVM是如何创建的，JNI是如何注册的。如果感兴趣的童鞋，可以下载源码，到app_main.cpp里进行查看。这里就不进行赘述了。否则代码量太大，适得其反。

3.Java层

命运的十字路口：ZygoteInit.java：

之所以说是命运的十字路口，因为Zygote会在这里创建SystemServer，但是二者却走向了截然不同的道路。

从这里就开始执行Java代码了，当然这些Java代码是运行在JVM中的。

让我们通过代码来看一下，到底都做了些什么。

class ZygoteInit{



    /**

     * This is the entry point for a Zygote process.  It creates the Zygote server, loads resources,

     * and handles other tasks related to preparing the process for forking into applications.

     * This process is started with a nice value of -20 (highest priority).  

     */

     // 上面是源码中的注释，小伙伴们可以自行翻译一下。

     // 创建了ZygoteServer，加载资源，并且介绍了这个进程的优先级是最高的-20.

    public static void main(String argv[]) {

        ZygoteServer zygoteServer = null;



        // 1. 预加载资源，常用的：resource，class，library等在此处进行加载

        preload(bootTimingsTraceLog);

            

        // 2. 创建ZygoteServer，实际是一个Socket用来进行跨进程间通信用的。

        zygoteServer = new ZygoteServer(isPrimaryZygote);



        // 3. fork出SystemServer进程，这个进程会创建AMS,ATMS,WMS，电池服务等一切只有你想不到没有它做不到的服务

        forkSystemServer(abiList, zygoteSocketName, zygoteServer);



        // 4.里面是一个while(true)循环，等待接收AMS创建进程的消息，类似于handler中的Looper.loop()

        zygoteServer.runSelectLoop(abiList);

    }

}

上面代码里的注释基本说明了ZygoteInit都干了啥。下面会再稍微总结下：

1. 创建了ZygoteServer：这是一个Socket相关的服务，目的是进行跨进程通信。


2. 预加载preload：预加载相关的资源。


3. 创建SystemServer进程：通过forkSystemServer分裂出了两个进程，一个Zygote进程，一个SystemServer进程。而且由于是分裂的，所以新分裂出来的进程也拥有虚拟机，也能调用JNI，也拥有预加载的资源，也会执行后续的代码。


4. 执行runSelectLoop()：内部是一个while(true)循环，等待AMS创建新的进程的消息。（想想Looper.loop()）

4. 戛然而止

没错就是这么突然，Zygote的故事到这就结束了。至于它是如何创建SystemServer，如何去创建App那就是后面的故事了。所以你还记得我的问题嘛？我替你总结一下Zygote到底做了什么：

1. 创建虚拟机


2. 注册JNI


3. 回调Java方法ZygoteInit.java 的main方法，从这儿开始运行Java代码


4. 创建ZygoteServer，内部包含Socket用于跨进程通信


5. 预加载class，resource，library等相关资源


6. fork 出了 SystemServer进程。他俩除了返回的pid不同，剩下一模一样。通过返回值不同来决定剩下的代码如何运行。这个留待后续进行讲解。


7. 进入while(true)循环等待，等待AMS创建进程的消息（类似于Looper.loop()）

5. 多说一句

这个系列才刚刚进行到第二章，我尽量让文章不是特别长的情况下，既有代码整理思路，又有总结方便记忆。代码是源码中摘抄的，省略了很大一部分，只能保证执行顺序。有兴趣的小伙伴可以下载源码进行查看。

其实最近我看了很多文章和视频，最后却选择写文章来对知识进行总结。归根结底就是因为一句话，好记性不如烂笔头。要是真的想快速记住，真的需要亲自查看一下源码。翻源码的同时，也是在不知不觉中锻炼你阅读源码的能力。 万一以后让你学习一个新的库，你也知道大概该怎么看。

都已经到这儿了，就稍微厚个脸皮，希望各位看官，能够点个赞，加个关注。毕竟一篇文章可能就要耗费几个小时的时间，上一篇文章就几个赞，感谢这几个小伙伴，让我有继续写下去的动力。 真心感谢你们。

另外，文章中有哪里出错，请及时指出。毕竟各位才是真正的大佬。希望各位Androider，可以一起取暖，度过这个互联网寒冬！加油各位！！！

6. Zygote功能图