itbird的专栏

LiveData使用观察者设计模式，视图作为观察者，数据作为被观察者，视图对于进行数据的观察，当数据发生变化时，可以主动通知视图，这本身是一个很简单类似OnClickListener的简单原理，但是难点在于，如何解决LiveData中由于需要实现通知，拥有了视图的引用，从而导致可能存在的内存泄露问题。

LiveData 从实践到原理，源码阅读

首先是LiveData数据结构定义，经过猜想，我们知道这块两个东西最重要，一个是数据容器的设定，一个是内部存储数据结构，我们这里通过泛型就可以实现/*** 自定义LiveData实现/*** 内部存储的数据结构*/ T data;/*** 构造函数} /*** set方法} /*** 直接在当前线程调用//todo 子线程执行的逻辑 } public T getValue() {} /*** 检测是否为主线程if(!} } }

五一假期，第二节课，Jetpack组件LiveData从实践、源码阅读、原理解读几方面，我们一起来学习、探索、总结一下。

ViewModel使用以及源码分析ViewModel 、 onSaveInstanceState、持久化数据的使用场景总结ViewModel 与 onSaveInstanceState的异同对比

onSaveInstanceState与onRetainNonConfigurationInstance 的对比分析SaveStateHandle使用DemoSaveStateHandle源码原理分析

ViewModel的实现机制是，在内存中存储了相关的ViewModel的数据，借助 activity的相关周期方法onRetainNonConfigurationInstance 与 getLastNonConfigurationInstance的自动调用，实现了 ViewModel数据的存储和恢复。

五一期间，我们来一起学习总结一下Jetpack的ViewModel组件，从使用、源码、经验来总结分析。老办法，在研究一个框架之前，先提出一些自己可以想到的问题，带着问题，有目标的去阅读源码，收货相信更多、更明确一些。ViewModel 是做什么的？ViewModel 如何使用？ViewModel 生命周期是怎么样的？ViewModel 数据是如何保存的？是通过文件吗？类似于SP的做法？

在源码探索的过程中，大家是否发现了这样一个类。/**/**} }有小伙伴，是否看着很有趣又亲切呢？有趣在于这里即对一个对象的行为进行了接口抽象定义，同时也对这个对象的创建工厂，进行了工厂定义亲切在于，不管是去年我们在设计模式精讲系列课程里，还是在okhttp的源码探索，以及rxjava的源码探索中，发现这些第三方框架，几乎都使用了这样的封装方式，即：先将行为抽象，使外界面向接口编程，其次再将对象创建也抽象，使用工厂模式，进行对象创建。

Room是对SQLite数据库的抽象，它提供了很多便利的API和注解等，简化了使用者使用数据库的方式。同时，Room提供了 LiveData、Rxjava的结合使用的组件，更加方便了开发使用。使用Room减少了很多sql模板代码的编写，整体使用上简单、明了了很多，尤其是结合Rxjava，可以直接实现主子线程的切换、流式业务代码操作的编写。

本文，我们通过一个简单的sqlite应用实例，引入了Room，知道了Room使用的便捷和好处。然后用Room的方式，重新实现了应用实例中的场景，在这个过程中，我们结合自己已有的知识体系，从使用代码入手，对Room的实现原理，进行了猜想和简单的验证。Room是否是这样做的？下一章节，我们一边阅读源码，一边去看一下。

上面的调用，从worker的提交，到job的具体执行，绕了一圈，我们画个图梳理一下。SerialExecutor的知识应用，当我们想要控制一个任务队列中的任务，串行执行时，可以使用这样的实现方案，但是，我们需要知道，这样有一个坏处就是，达不到并发的目的了。Provider可以用于初始化init函数的调用，当我们在设计一些框架时，为了简化使用者的调用步骤，可以使用Provider的方案。

本文，我们对于WorkManager的初始化、任务入队的源码进行了深入的解读，学到了WorkManager的初始化，和MMKV、VirtualAPK、LeakCanary这些第三方框架源码一样，都使用了Provider初始化的设计方案，发现这真是一个好处，就是使用了manifest注册时，PackageParse会解析其中的四大组件，然后在AMS中进行信息初始化，那么此时Provider就会进行初始化，所以使用了这个特性。

本文，我们对Jetpack的调度任务组件WorkManager ，由使用入手，对其源码进行深入学习、总结一下。

按照标准观察者模式设计思想，首先要定义通知接口看到这里，lifecycle源码，基本都已讲完。我们来总结一下1）lifecycle大体是，通过观察者设计模式，实现activity、fragment等生命周期的具体感知、通知的2）lifecycle实现方案上，对于API>=29采用的最新的API ActivityLifecycleCallbacks 来感知所有的生命周期。

本文，我们首先一个简单的实际代码例子入手，开始说明lifecycle被引入的背景，进而我们使用lifecycle实现了简单的需求，篇幅所限，lifecycle的自我实现以及源码探索，我们下篇文章继续探索。

1）JobIntentService在android8.0以上，是通过JSS+JSC实现的后台任务执行管理，任务会交由AsyncTask后台执行；在android8.0以上，是通过PowerManager来获取了wakeup锁，实现了后台任务的执行管理，任务同样也会交由AsyncTask后台执行；2）JobIntentService的任务后台执行，是放置于线程池的，所以是多线程并发执行；

本文，我们主要对IntentService的替代API接口JobScheduler，从简单的使用入手，然后逐步对内部的实现源码细节进行分析。JobSchedulerService是一个关键的系统服务，在android系统启动时，作为核心服务已经启动。我们通过JobScheduler提交的JobInfo，在JobSchedulerService中，会转换为JobStatus，然后交由各个状态监控器StateController去监控。

本文，从Job任务的创建，到如何与JSC（JobServiceCotext）关联，到具体任务的绑定、执行进行了源码探索，相信大家到现在为止，对于JobScheduler的庐山真面目，脑海中已经有了些许自己的轮廓。但是，我们也知道，目前为止，仅仅是任务的创建、任务的执行原理我们了解、学习到了，但是任务何时执行的？约束条件如何监控job的？这些还未讲到。别着急，下一节，我们一起继续探索源码，解析其中的奥秘。

Android源码面试宝典之JobScheduler从使用到原理分析（二）【JSS的启动】我们从使用代码入手，通过阅读JobScheduler源码，来开始对于其原理，进行深入解读。

我们先看一下google官方，对于这个API框架有哪些接口和类？可以看到主要有JobInfo、JobScheduler，其中 JobInfo有内部类Builder，那么看这个设计，应该是可以通过建造者模式，去外部构建一个 JobInfo实体对象，然后我们看到JobScheduler有schedule方法，那么应该就是把这个JobInfo交由JobScheduler去执行即可。

MMAP原理MMKV原理mmkv源码

去年，我们写过一篇文章，对于android原生提供的key-value存储API SharePreference，进行了，进行了深入的探索、总结。但是之前的文章，我们仅仅指出了问题，没有给大家提供解决方案，也就是说，SharePreference既然不建议使用，那么我应该使用啥？mmkv原理mmkv使用

Retrofit+Rxjava大家知道如何使用吗？添加CallAdapterFactory支持

Retrofit实践系列课程到现在，大家是否发现还有两个关键问题，或者准确一点，应该描述为两个功能并未实现一个是Gson数据的解析，我们是直接在返回里面使用了Gson解析的，并未使用到最初框架设计的时候，加入的ConvertFactoryRetrofitCall中数据的解析，其实包含两方面，一方面是gson的转换，一方面是code的处理，这部分，明显不应该写死在这里，因为服务端可能返回xml数据、gson数据，另外code的不同，你封装一个框架是给其他人去用的，code怎么能写死在解析里面呢？

a) Start：用于启动tomcat服务器，如果已启动，则显示 ReStart，作用是重启服务器b) Stop：用于停止服务器c) Add and Remove：将Web应用部署到tomcat服务器中，或者移除服务器中部署的Web应用d) Clean：作用是将发布到Eclipse自己的webapps目录中的项目删除再重新部署e) Clean Tomcat Work Directory：作用是将在tomcat运行过程中存入work目录的文件删除。

经过上面Demo实践，相信大家已经对服务端web编程有了一点点的了解，当然这是特别简单的一个demo而已，并非服务端web编程就是如此的简单，要想学好、用好web编程，里面的东西很多、很多。不过我们仅仅是为了配合okhttp编程实践，去自己会实现简单的服务端demo 测试即可，如有兴趣的小伙伴，可以看一下其他书籍，深入学习一下这块知识。

前面几章，我们学习了http的基础知识，服务端的基础知识、服务端测试Demo的实践编写，本章开始，我们正式开始Okhttp的框架源码学习和实践，大家要紧跟脚步哦，建议大家，可以跟随小编，一点一点的敲一下文章中的代码，相信通过这个系列学习，您不单单会获得okhttp的源码实践知识，更多的可能，会总结得到一份自我学习、实践的方式方法。1.从使用入手，初探源码我们先从okhttp的经典使用入手，试着了解、猜测一下okhttp的整体实现逻辑。 OkHttpClient okHttpClient =

好了，本章到了现在，基本的网络请求已经实现，尽管和okhttp的实现方案相比，有所不同，但是大家清楚，我们此行（实践学习）的初心并不是为了重新实现一个okhttp，而是想要用自己所学所思，看是否实现一个okhttp的框架，然后再结合okhttp的真正源码，去学习、深化。知道哪些地方我们无法实现的时候，okhttp是如何实现的？知道我们的实现方案与okhttp的某个功能点的实现方案的优缺对比？收获点还有很多，小编这里不再一一例举。

这里责任链，就是一个从上到下，按顺序处理同一个请求的过程，每一层都有它固定的职责。那么okhttp做的比较好的地方，是支持我们插入自定义的拦截器，例如我们可以在请求发起前，进行请求数据的特定加密，也可以对返回的数据，做统一的解密操作拦截。

本章从下载的功能需求，到下载框架的设计、开发、运行调试，花费了不少精力。也许一切看上去那么简单，但是从需求、设计、编码、调试，小编中间犯了很多低级的错误，所以每件事情，我们还是要动手去做，可能一些东西并非看上去那么简单，只有自己遇到了，并且利用所学所思，解决了问题或者需求，也许这些知识才真正属于我们自己。

近期在看okhttp的源码，这块也正好与http知识相关联，那么就索性将这块知识挖到底，学习、回顾、总结一下，所以有了这个系列的文章。本系列文章，我们就几点来进行深入学习总结，基本按照一条线来学习，先学习基础理论知识，然后摸清基本门路之后，我们自己通过实践编码来一一实现Okhttp的核心代码。PS：可能这里会有人提出疑问，小编上面的分解目录，为啥突然插入了一个服务端的基础知识和搭建呢？

本节到这里就基本结束了，我们回顾一下。解决retrofit 多baseUrl的动态解决方案就是RetrofitManager作为单例类，使用map保存baseurl-retrofit的一一对应保存为了解决需要记忆baseurl-retrofit一一对应关系的问题，我们引入自定义注解BaseUrl，给需要的接口类，直接添加这个注解。

篇幅所限，本文我们先就其中四个问题进行了解决，过程中，也对之前实现的诸多代码进行了优化。Create接口，使用泛型，面向所有请求接口注解的处理封装到ServiceMerthod方法中Call对象的封装和转换返回数据不规范的解决方案。

由上一节，我们基于retrofit使用代码入手，搭建了整体的框架，但是为了简化，一步一步来，我们首先使用自己搭建的retrofit实现基本的请求和返回，那么我们暂时忽略convertfactory和callback的转换，本节我们先直接使用okhttp的call，直接返回okhttp的response，实现基本的retrofit核心功能代码，具体功能点有接口动态代理创建对象注解的处理，拼接url和请求参数基于okhttp实现基本的请求本章，我们一起来基于上节搭建的Retrofit框架，实现核

我们运行一下，不出所料，肯定会崩溃的。因为在上面的代码编写中，我们只是搭建框架，并未填充任何实现，有几件重要的事情，都没有去做retrofit的builder模式创建中，okhttp并未使用convertFactroy接口并未填充实现retrofit.create方法我们只是创建一个空壳，并未去真正实现注解并未处理，因为我们最简单的，要处理注解，从而生成请求的完整url返回的数据封装处理，也就是从okhttp的call，到自己封装的call对象的转换，并未做处理。

工欲善其事必先利其器，我们开始具体的retrofit源码探索与实践之前，需要找一个免费的测试api接口，因为我们知道，不管使用okhttp，还是retrofit，你都需要一个api测试服务器。

从使用入手，到每个关键步骤的源码实现原理猜测、结合实际retrofit源码验证，大家是否已经基本了解的retrofit的整体框架和源码。接下来几节课，我们开始自我实现一个retrofit框架，还是那句老话，这里小编明确，去使用自己已知的知识，结合我们之前讲过的设计模式相关知识，实现并不是关键，毕竟已有的框架、已有的知识总结一大堆，我们并非是要花费时间重复造轮子，但是借助这个自我实践过程，去进行自我的知识沉淀、累加，进而吃透相应框架，这才是最关键的。

在android 6.0中也同时添加了权限组的概念，若用户同意组内的某一个权限，那么系统默认app可以使用组内的所有权限，无需再次申请。我们一般申请权限，是怎么做的呢？先建一个权限判断处理的类在相应的activity中（Note：为什么我这里没有包含fragment呢？大家先想一下，后续我们揭晓），做如下权限申请这个使用上有两处不方便有了这个前提，我们看一下RxPermissions使用的代码是否特别简单呢？是否解决了上面我们所说的两个问题呢？第二个问题肯定是解决了，第一个问题，是否已经解决了呢？我

总体来说， Rxjava的常见操作符分为创建操作符、转换操作符、过滤操作符、合并操作符、 条件操作符、功能操作符.我们常见的创建型操作符有 create、 just 、fromArray、interval、range 、timer。1.2 源码我们看一下create函数源码看到包装为了ObservableCreate对象，继续看一下source是上游的observable，也就是我们刚开始调用函数的crreate中创建的对象所以这里绕回到开头，也就是走到订阅流的 ObservableOnSubsc