1.react源码解析（二）时间管理大师fiber
2.PyTorch 源码解读之 torch.optim：优化算法接口详解
3.Vue3源码解析（computed-计算属性）
4.深入理解 RxJava2：Scheduler（2）
5.技术人生阅读源码——Quartz源码分析之任务的调度和执行
6.JobScheduler的使用和原理

react源码解析（二）时间管理大师fiber

       React的渲染和对比流程在面对大规模节点时，会消耗大量资源，影响用户体验。为了改进这一情况，React引入了Fiber机制，成为时间管理大师，kdj变色主图指标源码平衡了浏览器任务和用户交互的响应速度。

       Fiber的中文翻译为纤程，是一种内部更新机制，支持不同优先级的任务管理，具备中断与恢复功能。每个任务对应于React Element的Fiber节点。Fiber允许在每一帧绘制时间（约.7ms）内，合理分配计算资源，优化性能。

       相比于React，React引入了Scheduler调度器。当浏览器空闲时，Scheduler会决定是否执行任务。Fiber数据结构具备时间分片和暂停特性，更新流程从递归转变为可中断的循环，通过shouldYield判断剩余时间，灵活调整更新节奏。

       Scheduler的关键实现是requestIdleCallback API，它用于高效地处理碎片化时间，提高用户体验。尽管部分浏览器已支持该API，React仍提供了requestIdleCallback polyfill，以确保跨浏览器兼容性。

       在Fiber结构中，每个节点包含返回指针（而非直接的气动网站源码父级指针），这个设计使得子节点完成工作后能返回给父级节点。这种机制促进了任务的高效执行。

       Fiber的遍历遵循深度优先原则，类似王朝继承制度，确保每一帧内合理分配资源。通过实现深度优先遍历算法，可以构建Fiber树结构，用于渲染和更新DOM元素。

       为了深入了解Fiber，可以使用本地环境调试源码。通过创建React项目并配置调试环境，可以观察Fiber节点的结构和行为。了解Fiber的遍历流程和结构后，可以继续实现一个简单的Fiber实例，这有助于理解React渲染机制的核心。

       Fiber架构是React的核心，通过时间管理机制优化了性能，使React能够在大规模渲染时保持流畅。了解Fiber的交互流程和遍历机制，有助于深入理解React渲染流程。未来，将详细分析优先级机制、断点续传和任务收集等关键功能，揭示React是如何高效地对比和更新DOM树的。

       更多深入学习资源和讨论可参考以下链接：

       《React技术揭秘》

       《完全理解React Fiber》

       《浅谈 React Fiber》

       《React Fiber 源码解析》

       《走进 React Fiber 的世界》

PyTorch 源码解读之 torch.optim：优化算法接口详解

       本文深入解读了 PyTorch 中的优化算法接口 torch.optim，主要包括优化器 Optimizer、学习率调整策略 LRScheduler 及 SWA 相关优化策略。以下为详细内容：

       Optimizer 是所有优化器的基类，提供了初始化、更新参数、源码逆向分析设置初始学习率等基本方法。在初始化优化器时，需要传入模型的可学习参数和超参数。Optimizer 的核心方法包括：

       1. 初始化函数：创建优化器时，需指定模型的可学习参数和超参数，如学习率、动量等。

       2. add_param_group：允许为模型的不同可学习参数组设置不同的超参数，以适应不同的学习需求。

       3. step：执行一次模型参数更新，需要闭包提供损失函数的梯度信息。

       4. zero_grad：在更新参数前，清空参数的梯度信息。

       5. state_dict 和 load_state_dict：用于序列化和反序列化优化器的状态，便于保存和加载模型的训练状态。

       Optimizer 包括常见的优化器如 SGD、Adagrad、RMSprop 和 Adam，各有特点，适用于不同的应用场景。例如，SGD 适用于简单场景，而 Adam 则在处理大数据集时表现更优。

       学习率调节器 lr_scheduler 则负责在训练过程中调整学习率，以适应模型的收敛过程。PyTorch 提供了多种学习率调整策略，如 StepLR、MultiStepLR、ExponentialLR 等，每种策略都有其特点和应用场景，python 源码分享如 StepLR 用于周期性调整学习率，以加速收敛。

       SWA（随机权重平均）是一种优化算法，通过在训练过程中计算模型参数的平均值，可以得到更稳定的模型，提高泛化性能。SWA 涉及 AveragedModel 类，用于更新模型的平均参数，以及 update_bn 函数，用于在训练过程中更新批量归一化参数。

       总结，torch.optim 提供了丰富的优化算法接口，可以根据模型训练的需求灵活选择和配置，以达到最佳的训练效果和泛化性能。通过深入理解这些优化器和学习率调整策略，开发者可以更有效地训练深度学习模型。

Vue3源码解析（computed-计算属性）

       作者：秦志英

       Vue3计算属性源码解析

       在理解了Vue3响应式系统后，我们继续深入剖析其核心组件——计算属性的实现机制。Vue3中的计算属性通过computed函数提供API，让我们通过源码来揭示其内部运作。

       在ComputedRefImpl类中，有两个关键私有属性：_value用于缓存计算结果，_dirty用于标记是否需要重新计算。当属性值改变时，会触发trigger函数，遍历并执行依赖的effect函数。如果effect配置了scheduler，那么计算属性的getter并不会立即执行，而是设置_dirty为false，并通知依赖的日本钓鱼源码副作用函数。

       构造函数中，我们会包装getter函数为effect，并将其添加到依赖集合中。同时，lazy和scheduler参数控制了计算属性在何时调度。让我们通过一个示例来看计算属性的完整流程：当点击按钮改变testData时，计算属性的更新流程如图所示。

       总结：计算属性特性

       计算属性的主要特性包括：其值依赖于其他属性的更新，但只有在必要时才会重新计算，且通过lazy和scheduler配置实现灵活调度。如果你对Electron感兴趣，不妨关注我们的开源项目Electron Playground，了解更多技术知识。

       我们是好未来·晓黑板前端技术团队，持续分享最新技术动态。关注我们：知乎、掘金、Segmentfault、CSDN、简书、开源中国、博客园。

深入理解 RxJava2：Scheduler（2）

       欢迎来到深入理解 RxJava2 系列第二篇，本文基于 RxJava 2.2.0 正式版源码，将探讨 Scheduler 与 Worker 的概念及其实现原理。

       Scheduler 与 Worker 在 RxJava2 中扮演着至关重要的角色，它们是线程调度的核心与基石。虽然 Scheduler 的作用较为熟悉，但 Worker 的概念了解的人可能较少。为何在已有 Scheduler 的情况下，还要引入 Worker 的概念呢？让我们继续探讨。

       首先，Scheduler 的核心定义是调度 Runnable，支持立即、延时和周期性调用。而 Worker 是任务的最小单元的载体。在 RxJava2 内部实现中，通常一个或多个 Worker 对应一个 ScheduledThreadPoolExecutor 对象，这里暂不深入探讨。

       在 RxJava 1.x 中，Scheduler 没有 scheduleDirect/schedulePeriodicallyDirect 方法，只能先创建 Worker，再通过 Worker 来调度任务。这些方法是对 Worker 调度的简化，可以理解为创建一个只能调度一次任务的 Worker 并立即调度该任务。在 Scheduler 基类的源码中，默认实现是直接创建 Worker 并创建对应的 Task（虽然在部分 Scheduler 的覆盖实现上并没有创建 Worker，但可以认为存在虚拟的 Worker）。

       一个 Scheduler 可以创建多个 Worker，这两者是一对多的关系，而 Worker 与 Task 也是一对多的关系。Worker 的存在旨在确保两件事：统一调度 Runnable 和统一取消任务。例如，在 observeOn 操作符中，可以通过 Worker 来统一调度和取消一系列的 Runnable。

       RxJava2 默认内置了多种 Scheduler 实现，适用于不同场景，这些 Scheduler 都可以在 Schedulers 类中直接获得。以下是两个常用 Scheduler 的源码分析：computation 和 io。

       NewThreadWorker 在 computation、io 和 newThread 中都有涉及，下面简单了解一下这个类。NewThreadWorker 与 ScheduledThreadPoolExecutor 之间是一对一的关系，在构造函数中通过工厂方法创建一个 corePoolSize 为 1 的 ScheduledThreadPoolExecutor 对象并持有。

       ScheduledThreadPoolExecutor 从 JDK1.5 开始存在，这个类继承于 ThreadPoolExecutor，支持立即、延时和周期性任务。但是注意，在 ScheduledThreadPoolExecutor 中，maximumPoolSize 参数是无效的，corePoolSize 表示最大线程数，且它的队列是无界的。这里不再深入探讨该类，否则会涉及太多内容。

       有了这个类，RxJava2 在实现 Worker 时就站在了巨人的肩膀上，线程调度可以直接使用该类解决，唯一的麻烦之处就是封装一层 Disposable 的逻辑。

       ComputationScheduler 是计算密集型的 Scheduler，其线程数与 CPU 核心数密切相关。当线程数远超过 CPU 核心数目时，CPU 的时间更多地损耗在了线程的上下文切换。因此，保持最大线程数与 CPU 核心数一致是比较通用的方式。

       FixedSchedulerPool 可以看作是固定数量的真正 Worker 的缓存池。确定了 MAX_THREADS 后，在 ComputationScheduler 的构造函数中会创建 FixedSchedulerPool 对象，FixedSchedulerPool 内部会直接创建一个长度为 MAX_THREADS 的 PoolWorker 数组。PoolWorker 继承自 NewThreadWorker，但没有任何额外的代码。

       PoolWorker 的使用方法是从池子里取一个 PoolWorker 并返回。但是需要注意，每个 Worker 是独立的，每个 Worker 内部的任务是绑定在这个 Worker 中的。如果按照上述方法暴露 PoolWorker，会出现两个问题：

       为了解决上述问题，需要在 PoolWorker 外再包一层 EventLoopWorker。EventLoopWorker 是一个代理对象，它会将 Runnable 代理给 FixedSchedulerPool 中取到的 PoolWorker 来调度，并负责管理通过它创建的任务。当自身被取消时，会将创建的任务全部取消。

       与 ComputationScheduler 恰恰相反，IoScheduler 的线程数是无上限的。这是因为 IO 设备的速度远低于 CPU 速度，在等待 IO 操作时，CPU 往往是闲置的。因此，应该创建更多的线程让 CPU 尽可能地利用。当然，并不是线程越多越好，线程数目膨胀到一定程度会影响 CPU 的效率，也会消耗大量的内存。在 IoScheduler 中，每个 Worker 在空置一段时间后就会被清除以控制线程的数目。

       CachedWorkerPool 是一个变长并定期清理的 ThreadWorker 的缓存池，内部通过一个 ConcurrentLinkedQueue 维护。和 PoolWorker 类似，ThreadWorker 也是继承自 NewThreadWorker。仅仅是增加了一个 expirationTime 字段，用来标识这个 ThreadWorker 的超时时间。

       在 CachedWorkerPool 初始化时，会传入 Worker 的超时时间，目前是写死的 秒。这个超时时间表示 ThreadWorker 闲置后最大存活时间（实际中不保证 秒时被回收）。

       IoScheduler 中也存在一个 EventLoopWorker 类，它和 ComputationScheduler 中的作用类似。因为 CachedWorkerPool 是每隔 秒清理一次队列的，所以 ThreadWorker 的存活时间取决于入队的时机。如果一直没有被再次取出，其被实际清理的延迟在 - 秒之间。

       熟悉线程的读者会发现，ComputationScheduler 与 IoScheduler 很像某些参数下的 ThreadPoolExecutor。它们对线程的控制外在表现很相似，但实际的线程执行对象不一样。这两者的对比有助于我们更深刻地理解 Scheduler 设计的内在逻辑。

       Scheduler 是 RxJava 线程的核心概念，RxJava 基于此屏蔽了 Thread 相关的概念，只与 Scheduler/Worker/Runnable 打交道。

       本来计划继续基于 Scheduler 和大家一起探讨 subscribeOn 与 observeOn，但考虑到篇幅问题，这些留待下篇分享。

       感谢大家的阅读，欢迎关注笔者的公众号，可以第一时间获取更新，同时欢迎留言沟通。

技术人生阅读源码——Quartz源码分析之任务的调度和执行

       Quartz源码分析：任务调度与执行剖析

       Quartz的调度器实例化时启动了调度线程QuartzSchedulerThread，它负责触发到达指定时间的任务。该线程通过`run`方法实现调度流程，包含三个主要阶段：获取到达触发时间的triggers、触发triggers、执行triggers对应的jobs。

       获取到达触发时间的triggers阶段，通过`JobStore`接口的`acquireNextTriggers`方法获取，由`RAMJobStore`实现具体逻辑。触发triggers阶段，调用`triggersFired`方法通知`JobStore`触发triggers，处理包括更新trigger状态与保存触发过程相关数据等操作。执行triggers对应jobs阶段，真正执行job任务，先构造job执行环境，然后在子线程中执行job。

       job执行环境通过`JobRunShell`提供，确保安全执行job，捕获异常，并在任务完成后根据`completion code`更新trigger。job执行环境包含job对象、trigger对象、触发时间、上一次触发时间与下一次触发时间等数据。Quartz通过线程池提供多线程服务，使用`SimpleThreadPool`实例化`WorkerThread`来执行job任务，最终调用`Job`的`execute`方法实现业务逻辑。

       综上所述，Quartz通过精心设计的线程调度与执行流程，确保了任务的高效与稳定执行，展示了其强大的任务管理能力。

JobScheduler的使用和原理

        JobScheduler主要用于在未来某个时间下满足一定条件时触发执行某项任务的情况，涉及的条件可以是网络、电量、时间等，例如执行特定的网络、是否只在充电时执行任务等。

        JobScheduler类负责将应用需要执行的任务发送给框架，以备对该应用Job的调度，是一个系统服务，可以通过如下方式获取：

        JobInfo是传递给JobScheduler类的数据容器，它封装了针对调用应用程序调度任务所需的各种约束，也可以认为一个JobInfo对象对应一个任务，JobInfo对象通过JobInfo.Builder创建。它将作为参数传递给JobScheduler：

        JobInfo.Builder是JobInfo的一个内部类，用来创建JobInfo的Builder类。

        JobService是JobScheduler最终回调的端点，JobScheduler将会回调该类中的onStartJob()开始执行异步任务。它是一个继承于JobService的抽象类，做为系统回调执行任务内容的终端，JobScheduler框架将通过bindService()方式来启动该服务。因此，用户必须在应用程序中创建一个JobService的子类，并实现其onStartJob()等回调方法，以及在AndroidManifest.xml中对它授予如下权限：

        注意在AndroidManifest.xml中添加权限

        当任务开始时会执行onStartJob(JobParameters params)方法，如果返回值是false，则系统认为这个方法返回时，任务已经执行完毕。如果返回值是true，那么系统认为这个任务正要被执行，执行任务的重担就落在了你的肩上。当任务执行完毕时你需要调用jobFinished(JobParameters params, boolean needsRescheduled)来通知系统。

        当系统接收到一个取消请求时，系统会调用onStopJob(JobParameters params)方法取消正在等待执行的任务。很重要的一点是如果onStartJob(JobParameters params)返回false，那么系统假定在接收到一个取消请求时已经没有正在运行的任务。换句话说，onStopJob(JobParameters params)在这种情况下不会被调用。

        需要注意的是这个Job Service运行在主线程，这意味着你需要使用子线程，handler，或者一个异步任务来运行耗时的操作以防止阻塞主线程。

        Google官方的Sample： /googlearchive/android-JobScheduler

        JobScheduler是一个抽象类，它在系统框架的实现类是android.app.JobSchedulerImpl

        执行的入口是JobScheduler.scheduler，其实是调了JobSchedulerImpl中的schedule方法；然后再调了mBinder.schedule(job)。这个mBinder就是JobSchedulerService，通过Binder跨进程调用JobSchedulerService。

        最后调用到JobSchedulerService中的schedule方法:

        接着发送MSG_CHECK_JOB消息，消息处理的地方是

        接着执行JobHandler中的 maybeRunPendingJobsH 方法，处理相应的任务

        availableContext是JobServiceContext，即ServiceConnection，这个是进程间通讯ServiceConnection，通过调用availableContext.executeRunnableJob(nextPending)方法，会触发调用onServiceConnected，看到这里应该明白了，onServiceConnected方法中的service就是Jobservice，里面还用了WakeLock锁，防止手机休眠。

        接着，通过Handler发消息，调用了handleServiceBoundH()方法。

        从上面源码可以看出，最终是触发调用了JobService中的startJob方法。

        从源码看，设置的内容应用于 JobStatus ，例如网络限制

        而在JobSchedulerService类，相关的状态控制在其构造函数里:

        例如网络控制类ConnectivityControllerç±»

        当网络发生改变时，会调用updateTrackedJobs(userid)方法，在updateTrackedJobs方法中，会判断网络是否有改变，有改变的会调mStateChangedListener.onControllerStateChanged()方法；然后调用了JobSchedulerService类中onControllerStateChanged方法：

        接着也是处理MSG_CHECK_JOB 消息，和上文一样，最终触发调用了JobService中的startJob方法。

        JobSchedulerService是一个系统服务，即应该在SystemServer启动的。阅读SystemServer的源码：

        run 方法如下：

        接着看 startOtherServices()

        因此，在这里就启动了JobSchedulerService服务。

        1. android 性能优化JobScheduler使用及源码分析

        2. Android 9.0 JobScheduler(一) JobScheduler的使用

        3. Android 9.0 JobScheduler(二) JobScheduler框架结构简述及JobSchedulerService的启动

        4. Android 9.0 JobScheduler(三) 从Job的创建到执行

        5. Android 9.0 JobScheduler(四) Job约束条件的控制

        6. 理解JobScheduler机制