工匠若水

背景前面文章我们分析了 flutter 在 android 端编译命令相关流程，也分析了 Flutter App dart 代码入口开始到三棵核心树诞生流程，按照源码顺序，我们接下来需要先分析一下 Flutter Android 端 framework 平台实现代码（非 native engine 引擎部分），下面以一个纯 Flutter App 为例展开分析。工程结构及 API 变更对于一个纯 flutter app 来说，当我们在 yaml 依赖中添加两个 flutter plugin 依赖，然后

背景从写 Flutter 第一行程序开始我们就知道在 Dart 的 main 方法中通过调用 runApp 方法把自己编写的 Widget 传递进去，只有这样编译运行后才能得到预期效果。你有没有好奇这背后都经历了什么？runApp 为什么这么神秘？或者说，在你入门 Flutter 后应该经常听到或看到过 Flutter 三棵树核心机制的东西，你有真正的想过他们都是什么吗？如果都没有，那么本文就是一场解密之旅。Flutter 程序入口我们编写的 Flutter App 一般入口都是在 main 方法，其

背景上一篇《Flutter Android 工程结构及应用层编译源码深入分析》我们分析了 Flutter Android 相关的应用层主要编译流程，其中分析到底层本质命令工具【Flutter SDK 下bin/flutter编译命令分析】小节时只提到，我们执行任何 flutter 命令的本质都是把参数传递到了FLUTTER_SDK_DIR/packages/flutter_tools/bin/flutter_tools.dart源码的 main 方法中，没有对这里面进行深入分析。本文要做的事就是层层递进揭

背景分析这里简单粗暴点，直接在自己项目根目录下 android\app\build.gradle 追加buildscript { repositories { maven { url "https://maven.aliyun.com/repository/public/" } maven { url "https://maven.aliyun.com/repository/google/" } }}allprojects { repos

什么是 Annotation Processor 构建问题写过自定义注解处理器的老司机们乍一看这个问题觉得挺简单，是的，因为网上基本通篇都在教你怎么打日志，但是你有没有想过如果连日志都打印不出来的时候你怎么定位呢？譬如如下代码：// 确认 META-INF/services/javax.annotation.processing.Processor 没问题// 确认构建脚本没问题，确认注解 Bridge 有被使用且有参与构建@AutoService(Processor.class)public c

背景Linux 的 tracepath 指令可以追踪数据到达目标主机的路由信息，同时还能够发现 MTU 值。它跟踪路径到目的地，沿着这条路径发现 MTU。它使用 UDP 端口或一些随机端口。它类似于 Traceroute，只是不需要超级用户权限，并且没有花哨的选项。Android 也是移植的它，其源码放置位置在platform/external/iputils/tracepath6.c。我们之所以直接移植tracepath6.c而不是tracepath.c的原因是 tracepath6 支持 IPV6

背景我们都知道，Application 初始化一直是安卓开发中被诟病最多的问题之一，尤其是 app 支持多进程且航母级应用场景下。随着业务迭代，初始化代码控制不到位的情况下是灾难性的，后人不敢随意挪动位置，或者说因为时机太早且为 app 启动必经之路，每次修改的影响面都很难评估，造成的启动性能影响也很严重。此时可能很多小伙伴觉得 Jetpack 的 App Startup 库就是解决上面这段话里的问题的，因为他们觉得官方库介绍里说：The App Startup library provides a s

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～特别说明，kotlin 系列文章均以 Java 差异为核心进行提炼，与 Java 相同部分不再列出。随着 kotlin 官方版本的迭代，文中有些语法可能会发生变化，请务必留意，语言领悟精髓即可，差异只是语法层面的事情，建议不要过多关注。类委托类委托原理：by 关键字后面的对象实际会被存储在类的内部，编译器则会将父接口的所有方法实现出来，并且将其转移给委托对象去执行。//定义一个接口interface InterfaceB

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景前面《Groovy 本质初探及闭包特性原理总结》文章中我们总结了 Groovy 的本质，可以发现 Groovy 不但增强了 java 的脚本能力，也提供了新的面向对象特性；就像前面看到的，Groovy 对 java 非对象基础类型直接变成了引用类型，引入了闭包，并为对象集合增加了许多简化符号和拓展能力；前面文章也说了，这些特性可以看作是 java 的一种语法糖，但如果 Groovy 的对象仅仅提供 java 的语法糖能力，

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～Groovy 语言的本质Groovy 是基于 JVM 的一种语言，也是 Java 的一种升级拓展语言。其具备脚本语言的特性，但又不算脚本，所以其运行有如下两种方式：基于源码直接运行，譬如 groovy Test.groovy。基于预编译模式运行，譬如先 groovyc Test.groovy 然后 java Test。无论上面的哪种运行方式，其本质都是 JVM 字节码，可以理解成和 java 编译运行没啥区别，只是

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～特别说明，kotlin 系列文章均以 Java 差异为核心进行提炼，与 Java 相同部分不再列出。随着 kotlin 官方版本的迭代，文中有些语法可能会发生变化，请务必留意，语言领悟精髓即可，差异只是语法层面的事情，建议不要过多关注。范型（generics）与协变逆变范型用来表示变量类型的参数化。一个简单的范型类定义使用样例：class Generics<T>(t: T) { var tmp: T =

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～特别说明，kotlin 系列文章均以 Java 差异为核心进行提炼，与 Java 相同部分不再列出。随着 kotlin 官方版本的迭代，文中有些语法可能会发生变化，请务必留意，语言领悟精髓即可，差异只是语法层面的事情，建议不要过多关注。kotlin 函数与 lambada 表达式在 kotlin 中调用 java 方法时不能使用具名参数语法，因为 java 字节码并不总是会保留方法参数信息。默认参数函数//重载一个 te

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～特别说明，kotlin 系列文章均以 Java 差异为核心进行提炼，与 Java 相同部分不再列出。随着 kotlin 官方版本的迭代，文中有些语法可能会发生变化，请务必留意，语言领悟精髓即可，差异只是语法层面的事情，建议不要过多关注。面向对象//kotlin 类默认修饰符是 public 的，不用再显式指定 publicclass MyClass {}//kotlin中一个类的类体没有任何内容则花括号可以省略，如下：

背景上一篇文章《记录一次 AGP 调研过程中的思考，我从一个事故搞出了一个故事！》发布后有很多小伙伴表示看不懂，本来不想写这篇的，但是恰巧最近大组有同事在做另一个技术需求时他的 R 也炸了，只是他炸的是 javac 阶段，我上篇分析的场景是 ASM 生成字节码阶段，所以我让他将他的R.java文件发我，我尝试编译并与我的字节码做对比发现了一点我以前没意识到的点，所以自己觉得上篇博文还是不够深入，AGP 升级的 R 问题还能继续挖坟考古，所以想来个续集。鉴于有人上篇没看懂，这篇就循序渐进的图文并茂下。所以接

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～特别说明，kotlin 系列文章均以 Java 差异为核心进行提炼，与 Java 相同部分不再列出。随着 kotlin 官方版本的迭代，文中有些语法可能会发生变化，请务必留意，语言领悟精髓即可，差异只是语法层面的事情，建议不要过多关注。letlet扩展函数的实际上是一个作用域函数，当你需要去定义一个变量在一个特定的作用域范围内，let函数的是一个不错的选择；let函数另一个作用就是可以避免写一些判断null的操作。obje

背景看过我博客的老铁应该知道，我在 18 年五月写过一个小 gradle 插件https://github.com/yanbober/app-tiny-R-gradle-plugin，其作用就是将 app 生成的 R 常量进行内联操作。对，就是前不久很火的滴滴 booster 和字节跳动 ByteX 提供的 R 资源 inline 原理。这两天因为项目要升级适配 AGP4.1.0 版本，顺手要调研 AGP 4.1.0 构建对子 module 及合成最终 app 的 intermediates 产物 R

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～特别说明，kotlin 系列文章均以 Java 差异为核心进行提炼，与 Java 相同部分不再列出。随着 kotlin 官方版本的迭代，文中有些语法可能会发生变化，请务必留意，语言领悟精髓即可，差异只是语法层面的事情，建议不要过多关注。kotlin 编译及反编译对于 kotlin 来说，如果你不用 IDE（其本质也是走的命令行行为），则其编译与反编译原理基本与 java 如出一辙，kotlin 的 kotlinc 命令对应

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景Java 9 版本中增强了Jar 包多版本字节码文件格式支持，也就是说在同一个 Jar 包中我们可以包含多个 Java 版本的 class 文件，这样就能做到 Jar 包升级到新的 Java 版本（新特性 API 使用）时不用强迫使用方为了使用新 Jar 包而升级自己的业务模块 Java 版本，也不用针对不同最低支持 Java 版本提供不同的 Jar，真正的做到了一个 Jar 包兼容所有的目的。这样的 Jar 称为 MRJ

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景代码各种维度的统计在有些时候是很重要的，这里总结一些常用的牛逼的代码统计工具，着重介绍了个人使用的 Statistic 插件。但是如果你是想统计团队维度的数据，推荐后面介绍的 git_stats 神器工具。Statistic IDEA 插件IDEA 的 Statistic 插件官方地址为 https://plugins.jetbrains.com/plugin/4509-statistic ，大家可以直接通过 IDEA

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景JavaScript 的模块系统主要是在解决大中型前端应用脚本管理与加载问题。在前端模块化进程中主要经历了下面几种 JavaScript 模块化解决方案：石器时代IIFECJS，CommonJS 模块规范AMD，CMD，异步模块定义UMDESM，ECMAScript 模块系统（ES6）石器时代HTML <script>元素用于嵌入或引用可执行脚本。互联网早期，页面比较简单，使用内嵌的方式或者

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景好的 commit message 是至关重要的，如果随意编写 log，带来的后果可小可大，但是无论大小都影响了开发的效率和回朔的难度，所以有必要进行 log 规范化检查。而检查的入口可以从 git hook 切入，而 git hook 却又有无限的遐想。关于 git commit 问题可以参考下面几个帖子：Augular git commit 提交规范如何写好 Git commit log?跑远了，我们下面先介绍

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景大家都知道静态代码检查工具有很多，譬如阿里的 p3c、sonar 挂钩的一堆插件等。但是这些东西对于一个已存在的项目不够友好，因为旧代码一扫描会出现一堆问题，修复带来的成本又很高，所以这些工具都比较适合新项目或者初期介入，对于老项目就显得很蛋疼了。因此有必要做到增量检查；一种就是针对版本控制的 changed 进行增量，这种情况会涉及到老文件修改一处全部问责的问题；另一种是针对新增文件进行增量，这种情况保证了从此刻开始新

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景好的 commit message 是至关重要的，如果随意编写 log，带来的后果可小可大，但是无论大小都影响了开发的效率和回朔的难度，所以有必要进行 log 规范化检查。而检查的入口可以从 git hook 切入，而 git hook 却又有无限的遐想。关于 git commit 问题可以参考下面几个帖子：Augular git commit 提交规范如何写好 Git commit log?跑远了，我们下面先介绍

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～缘由相信大家都用过 javadoc 命令或者 IDE 封装命令生成 java api doc 文档吧，但是你有没有反思过 javadoc 命令是怎么解析文件生成的呢？其实 javadoc 在 jdk 目录下只是一个可执行程序，但是这个可执行程序是基于 jdk 的 tools.jar 的一个封装，也就是说 javadoc 实现在 tools.jar 中。很多时候我们可能会有一些奇葩的需求，譬如获取 java 文档注释进行搞事情

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景经常在全球最大的男性社交平台 github 上看别人项目时，会发现好多顶级牛逼的项目目录下都会有个.editorconfig文件，出于好奇查了下才发现真特么香。恰巧最近在研究团队一致的 customer IDE format config file 场景，所以就深入品尝了下.editorconfig，发现他的这个真香只适合那些新立项项目或者强制全局执行的项目，因为深入研究后发现其不支持增量配置，略可惜，不过丝毫不影响我写篇

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景项目规模航母级庞大，年代久远，导致很多模块迟迟没有完全 gradle 化，所以浪费了一定的开发效率。由于构建采用了类似 c 语言的宏定义概念控制，加上自定义的拆 dex 构建，对部分大型模块不熟悉，所以整个构建无比复杂，从而对完全 gradle 化带来了一些坑。本文仅以总结记录自己的落地经验，以便后续回忆分析。落地过程中的坑与解决方案整体迁移的思路是先依据各种 ant 构建自定义的 build.xml 翻译成对应规则的

工匠若水可能会迟到，但是从来不会缺席，最终还是觉得将自己的云笔记分享出来吧 ～背景Android Native Crash 的捕获其实是有好几种方案的，譬如 coffeecatch、crash 后新进程过滤 logcat、google BreakPad 等，系统层面就另当别论了，系统有那么强大的墓碑机制，所以不讨论墓碑情况。应用层方案来说，其各自都存在一些利弊或者兼容问题，综合来看，Android 系还是推荐使用 google BreakPad 实现，本文就抛开其他方案来聊聊 BreakPad 在 An

【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】1 背景不知不觉关于 Python 3.X 爬虫系列已经介绍了如下系列：《正则表达式基础》 《Python3.X 爬虫实战（先爬起来嗨）》 《Python3.X 爬虫实战（静态下载器与解析器）》 《Python3.X 爬虫实战（并发爬取）》 《Python3.X 爬虫实战

缓存与持久化简单说就是 Cache 或者 Persistence 了，这玩意和爬虫有啥关系呢？想象一下如果我们需要对同一个页面进行多次解析，我们前面的代码都会重新发起真实网络请求，这是不合理的，因为短期之内这个页面是不可能有更新的，我们重复拉取是没有意义的；其次我们很多时候爬虫的输出器其实就是需要把爬取的数据依据需求多元化的持久化下来，所以我们有必要先掌握常见的爬虫相关缓存及持久化。

这一篇一下搞得有点不像在介绍并发爬虫，而成了 Python3 并发编程基础了，坑爹啊，无论怎样最后我们还是给出了两个基于 Python3 线程池、进程池的并发爬虫小案例，麻雀虽小，五脏俱全。虽然本篇对并发爬虫（Python3 并发）没有进行深入介绍，但是基本目的达到了，关于并发深入学习不是一两天的功夫，并发在大型项目中是个很有学问的东西，要走的路还有很长。

这一篇内容主要延续上一篇[《Python3.X 爬虫实战（先爬起来嗨）》](http://blog.csdn.net/yanbober/article/details/73162298)，重点偏向于爬虫爬取静态页面的下载器与解析器常用套路引导，主要适用于理解爬虫流程和自己编写小爬虫程序，对于大型爬虫这些介绍是十分不健壮的，我们一般会采用第三方爬虫框架，对于框架和动态页面爬取我们后面系列会进行介绍的。

爬虫的价值就不多说了，Python 的便捷与强大也就不 BB 了，在这个数据泛滥、追求效率的时代，使用 Python 可以为我们创造相当多的便捷，Web 开发、桌面小工具开发、粘性脚本编写、大数据处理、图像处理、机器学习等等，能做到的事情实在太多。

上一篇《Gradle 庖丁解牛（构建源头源码浅析）》我们分析了 Gradle 框架自身初始化（非构建生命周期初始化）的核心流程，这一篇我们续着前面的分析继续（如果没看过前一篇的建议先去看前一篇，因为这一系列存在非常高的关联性）。

总是有人问 Gradle 构建，总是发现很多人用 Gradle 是迷糊状态的，于是最近准备来一个“Gradle 庖丁解牛”系列，一方面作为自己的总结，一方面希望真的能达到标题所示效果，同时希望通过该系列达到珍惜彼此时间的目的，因为目前市面上关于 Gradle 的教程都是在教怎么配置和怎么编写插件，很少有说明 Gradle 自己到底是个啥玩意的，还有是如何工作的，本系列以官方 release 3.4 版本为基础。

Drawable 是一个抽象类，提供了一些 API 方法去处理各种资源的绘制，但是又不具备 View 的事件与交互处理能力。额，再简单粗暴一点认为就是一个辅助绘制工具类，把各种东西都封装搞好以后直接给Canvas去画。既然是工具类，说白了就是个模板，你就把它类比 View 或者 Paint 来看吧。

一眨眼又一年快要过去了，原计划今年的最后一个小目标（React Native）看样子要留尾巴到明年了，React Native 想说爱你不容易。怎么评价你呢？应用层 JSX 编写还是很友好的，尼玛框架接入的各种锅却让人痛哭不已，万事开头难，对于 React Native 的接入可以说大量工作可能都需要投入到框架接入中（各种灰度实验的兼容性、各种锅），一旦接入稳定以后真的就是尝到甜头了。

理解 RN 框架的一些东西，以便裁剪和对 RN 有个更深入的认识，所以本篇总结了我这段时间阅读源码的一些感触，主要总结了 React Native 启动流程、JS 调用 Java 流程、Java 调用 JS 流程。

了解 React Native 的编译流程是进行 React Native 裁剪阉割的首要任务，理解编译流程才能去看如何依赖、如何裁剪，这和 Android 源码一样，你想修改的前提是熟悉整个 Android 系统源码 build 目录下的 各种 shell、python 脚本的大致框架流程吧，否则搞毛线。

作为 Android 开发者来说，对待 RN 个人建议要保持一个端正的态度，什么原生 Android App 已死、RN 很牛逼之类的话听听就行了；至少到目前为止个人觉得原生开发才是王道，RN 也就只能胜任一些常规的 CS 模式应用，整体还是很弱的，不要告诉我它支持很方便的封装 Native UI 和 Module 到 js ，这就是扯蛋，除过一些通用 SDK 接口封装具备一定价值以外，个性化 UI 封装有毛用。

本文主要分两部分来进行简单粗略的浅析，首先会围绕Theme与Style的定义及在App开发中的使用来进行简单回顾，接着第二部分会介绍Android系统关于Theme与Style的规则及源码，然后简单总结下我们开发中如何处理自定义Theme与Style的一些方法。

时隔一年，多了些磨砺，懂了些故事，悟出些道理，但这一年技术却停留在了原地。有很多人私信想让NDK系列文章持续下去，自己现在想想是该捡起来了，在这种环境下不能再纵容自己了，以往的知识都该捡起来了。开始本篇前还是建议先按顺序看看前面这三篇吧，否则可能有些脱节。

关于Launcher是啥的问题我想这里就没必要再强调了。由于一些原因迫使最近开始需要研究一下Launcher3源码，为了不再像以前那么傻逼（研究Settings等代码没作笔记），故这里赶紧将阶段性的感悟整理成文章，方便日后回看。其实本文来源于我在项目组内部的一次分享活动的ppt。

最近有些乱，各种事情，各种交叉。好在还有一点上进心，于是继续将自定义这个系列的核心知识再梳理一下吧。关于自定义控件前面博文说过了，这里不会教你拿来主义，只授之以渔，如果你喜欢拿来主义，不好意思，请绕行，如果你喜欢得渔，那请继续。前面我们已经叙述过了几篇关于自定义View涉及的东西，大家可以自己回过头去看我之前的博客，譬如事件处理、坐标系、工具类等。下面我们还是继续补充一些常用的自定义控件工具类。

大家都知道Android View提供了scrollTo()与scrollBy()方法来供我们进行View的滚动，但是有个问题就是他的滚动很蛋疼，疼在是瞬时挪动到指定位置的，这种对于追求用户体验的今天来说简直是硬伤啊；为了解决这个问题Google给我们提供了一个牛叉的工具类Scroller，下面我们就深入浅出的来开战这一工具类，将其玩爆，以便日后自定义控件时如鱼得水。

很多人可能不屑一顾Android的坐标系，但是如果你想彻底学会自定义控件，我想说了解Android各种坐标系及一些API的坐标含义绝对算一个小而不可忽视的技能；所谓Android自定义View那几大主要onXXX()方法的重写实质其实大多数都是在处理坐标逻辑运算，所以我们就先来就题重谈一下Android坐标系。

自定义ViewGroup里通过ViewDragHelper静态工厂方法create()创建实例并实现ViewDragHelper.CallBack抽象类。在自定义ViewGroup的onInterceptTouchEvent()方法里调用并返回ViewDragHelper的shouldInterceptTouchEvent()方法，在onTouchEvent()方法里调用ViewDragHelper()即可完成使用。

其实这篇文章可能有些小题大作，但回过头想想还是很有必要的，有点阴沟里翻船的感觉。相信大家都知道Android API Level 8开始提供了为应用程序备份和恢复数据的功能，此功能的开关可以通过应用程序中AndroidManifest.xml文件的allowBackup属性值进行配置，默认是True，所以用户可以对我们应用程序进行数据备份。

在我们App开发中大家可能都会有过如下痛疾（程序员和设计妹妹注意喽）：好多小的图标好烦人，又占体积还要考虑分辨率，一拉伸就模糊等。同一个图标不同状态还有不同颜色的多张。总是幻想IOS、Android、Web等对于一个图标只切一次图多好。如果你有过类似的痛疾那么下面讨论的故事就是一个完美的解决方案，当然了，采用下面方案对于重型应用或者固件级的优化才会十分明显，对于普通小应用那就要看自己了。

1 背景建议阅读本文之前先阅读《Android Studio入门到精通》和《Groovy脚本基础全攻略》及《Gradle脚本基础全攻略》三篇博客作为背景知识，这样才能更好、更系统的串起来。本文的核心就是下图：关于Gradle的Android插件本文不会过多的说明，只给一个抛砖引玉的提示，详细使用参见文档API及Gradle配置，其实个性化的构建配置一般都是Gradle与Groovy的编写，与Andr

【工匠若水 http://blog.csdn.net/yanbober 转载请注明出处。点我开始Android技术交流】1 背景在开始Gradle之前请务必保证自己已经初步了解了Groovy脚本，特别是闭包规则，如果还不了解Groovy则可以先看《Groovy脚本基础全攻略》这一篇博客速成一下Groovy基础，然后再看此文即可。关于Gradle速成干货基础详情也请参考Geadle官方网站，不好意思我

【工匠若水 http://blog.csdn.net/yanbober 转载请注明出处。点我开始Android技术交流】1 背景Groovy脚本基于Java且拓展了Java，所以从某种程度来说掌握Java是学习Groovy的前提，故本文适用于不熟悉Groovy却想快速得到Groovy核心基础干货的Java开发者（注意是Java），因为我的目的不是深入学习Groovy语言，所以本文基本都是靠代码来解释

1 背景其实有点不想写这篇文章的，但是又想写，有些矛盾。不想写的原因是随便上网一搜一堆关于性能的建议，感觉大家你一总结、我一总结的都说到了很多优化注意事项，但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用，啥啥啥该咋用等，却很少有较为系统的进行真正性能案例分析的，大多数都是嘴上喊喊或者死记住规则而已（当然了，这话我自己听着都有些刺耳，实在不好意思，其实关于性能优化的优质博文网上也还是有很多

1 背景在Android中任何耗时的操作都不能放在UI主线程中，所以耗时的操作都需要使用异步实现。同样的，在ContentProvider中也可能存在耗时操作，这时也该使用异步操作，而3.0之后最推荐的异步操作就是Loader。它可以方便我们在Activity和Fragment中异步加载数据，而不是用线程或AsyncTask，他的优点如下：提供异步加载数据机制；对数据源变化进行监听，实时更新数据

准备开始重操那两年的旧业，后悔之前在上家公司做Amlogic和Realtak方案盒子时没有养成写博客的习惯，这算是开篇之作吧，顺带也算是给一个网友的答疑吧。不多说，该篇只是工具讲解而已。关于Android Studio对于应用层App开发的技巧和配置前面我写过文章分析的，这里不再解释说明，具体查看我的这一片博文《Android Studio入门到精通 》。

1 背景这个知识点是个low货，刚开始其实想在之前一篇文章《Android异步消息处理机制详解及源码分析》一文中作为一个知识点分析的，但是想了又想又觉得该放在后面进程间通信分析时再分析。然并卵，还是单独拿出来写一篇分析一下吧。提到Message和Handler其实大家都很熟悉，但是说到Messenger估计有些人还是不太常用的，更有甚者都能把Messenger拼写错误为Messager，以为是Mes

1 前言前一篇（点我阅读前一篇《Android应用Preference相关及源码浅析(SharePreferences篇)》）我们讨论分析使用了Android的SharePreferences，相信看过的朋友都有了自己的感悟与理解，这一篇我们继续乘热打铁来说说SharePreferences的衍生品—-Preference组件。其实Preference组件大家一定不陌生，因为Android系统的Se

1 前言在我们开发Android过程中数据的存储会有很多种解决方案，譬如常见的文件存储、数据库存储、网络云存储等，但是Android系统为咱们提供了更加方便的一种数据存储方式，那就是SharePreference数据存储。其实质也就是文件存储，只不过是符合XML标准的文件存储而已，而且其也是Android中比较常用的简易型数据存储解决方案。我们在这里不仅要探讨SharePreference如何使用，

题外话：有段时间没有更新博客了，这篇文章也是之前写了一半一直放在草稿箱，今天抽空把剩余的补上的。消失的这段时间真的好忙，节奏一下子有些适应不过来，早晨七点四十就得醒来，晚上九点四十才准备下班，好像最近都与世隔离了一样；然而自己每天还要熟悉一大套自己不熟悉、各种协议差异的代码。其实换个角度考虑还是蛮好的，忙，但很充实，有新的挑战与收获。【工匠若水 http://blog.csdn.net/yanbob

未经微博私信询问征得同意的情况下本博客所有原创类型文章一律禁止任何复制、转载、商用，对于复制段落的也请麻烦标明引用。为保证博客质量，任何事情都是花时间去做的，本着分享但不开放的态度总结自己的知识点，烦请尊重劳动成果。

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重劳动成果】1 背景之所以写这一篇博客的原因是因为之前有写过一篇《Android应用setContentView与LayoutInflater加载解析机制源码分析》，然后有人在文章下面评论和微博私信中问我关于Android应用Activity、Dialog、PopWindow加载显示机制是咋回事，所以我就写

前面分析那么多系统源码了，也该暂停下来休息一下，趁昨晚闲着看见一个有意思的需求就操练一下分析源码后的实例演练----自定义控件。

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】1 背景还记得前面《Android应用setContentView与LayoutInflater加载解析机制源码分析》这篇文章吗？我们有分析到Activity中界面加载显示的基本流程原理，记不记得最终分析结果就是下面的关系：看见没有，如上图中id为content的内容就是整个View树的结构，所

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】1 背景Android异步处理机制一直都是Android的一个核心，也是应用工程师面试的一个知识点。前面我们分析了Handler异步机制原理（不了解的可以阅读我的《Android异步消息处理机制详解及源码分析》文章），这里继续分析Android的另一个异步机制AsyncTask的原理。当使用线程

PS一句：最终还是选择CSDN来整理发表这几年的知识点，该文章平行迁移到CSDN。因为CSDN也支持MarkDown语法了，牛逼啊！【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】最近相对来说比较闲，加上养病，所以没事干就撸些自己之前的知识点为博客，方便自己也方便别人。1 背景之所以选择这个知识点来分析有以下几个原因：逛GitHub时发现关

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】1 背景今天突然想起之前在上家公司（做TV与BOX盒子）时有好几个人问过我关于Android的Context到底是啥的问题，所以就马上要诞生这篇文章。我们平时在开发App应用程序时一直都在使用Context（别说你没用过，访问当前应用的资源、启动一个activity等都用到了Context），但

【工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处，尊重分享成果】1 背景其实之所以要说这个话题有几个原因：理解xml等控件是咋被显示的原理，通常大家写代码都是直接在onCreate里setContentView就完事，没怎么关注其实现原理。前面分析《Android触摸屏事件派发机制详解与源码分析三(Activity篇)》时提到了一些关于布局嵌套的问题，当

PS一句：最终还是选择CSDN来整理发表这几年的知识点，该文章平行迁移到CSDN。因为CSDN也支持MarkDown语法了，牛逼啊！【工匠若水 http://blog.csdn.net/yanbober】该篇承接上一篇《Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇)》，阅读本篇之前建议先阅读。1 背景还记得前面两篇从Android的基础最小元素控件（View）到ViewGr

PS一句：最终还是选择CSDN来整理发表这几年的知识点，该文章平行迁移到CSDN。因为CSDN也支持MarkDown语法了，牛逼啊！【工匠若水 http://blog.csdn.net/yanbober】该篇承接上一篇《Android触摸屏事件派发机制详解与源码分析一(View篇)》，阅读本篇之前建议先阅读。当然，阅读完这一篇之后可以阅读继续进阶的下一篇《Android触摸屏事件派发机制详解与源码分

PS一句：最终还是选择CSDN来整理发表这几年的知识点，该文章平行迁移到CSDN。因为CSDN也支持MarkDown语法了，牛逼啊！【工匠若水 http://blog.csdn.net/yanbober】Notice：阅读完该篇之后如果想继续深入阅读Android触摸屏事件派发机制详解与源码分析下一篇请点击《Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇)》查看。1 背景最近

如果你学习过设计模式，那么当想通知其他组件某些事情发生时你一定会使用观察者模式。好了，既然能想到这个设计模式，那么就来看一个屌爆天的Android开源框架EventBus。主要功能是替代Intent、Handler、BroadCast在Fragment、Activity、Service、线程之间传递消息。他的最牛逼优点是开销小，代码简洁，解耦代码。

如果你学习过设计模式，那么当想通知其他组件某些事情发生时你一定会使用观察者模式。好了，既然能想到这个设计模式，那么就来看一个屌爆天的Android开源框架EventBus。主要功能是替代Intent、Handler、BroadCast在Fragment、Activity、Service、线程之间传递消息。他的最牛逼优点是开销小，代码简洁，解耦代码。

之所以要谈这个话题是因为你在开发App时可能会发现，Activity担负的责任非常之重，如果站在MVC框架角度看自己开发的App，一般xml布局文件科Activity的setContentView等充当了View角色，Activity其他代码充当了Controller角色，其他数据来源（数据库等）充当了Model角色。所以你会发现Activity违背单一职责原则，负担过重。同时如果要测试逻辑数据层会发现比较难编写测试

SQLite是一款轻型的数据库，是关系型数据库（RDBMS）管理系统，它包含在一个相对小的C库中。目前在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持Windows/Linux/Unix/Android/IOS等等主流的操作系统，同时能够跟很多程序语言相结合。

SQLite是一款轻型的数据库，是关系型数据库（RDBMS）管理系统，它包含在一个相对小的C库中。目前在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持Windows/Linux/Unix/Android/IOS等等主流的操作系统，同时能够跟很多程序语言相结合，比如 Tcl、C#、PHP、Java等，还有ODBC接口，同样比起Mysql、PostgreSQL这两款

SQLite是一款轻型的数据库，是关系型数据库（RDBMS）管理系统，它包含在一个相对小的C库中。目前在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持Windows/Linux/Unix/Android/IOS等等主流的操作系统，同时能够跟很多程序语言相结合，比如 Tcl、C#、PHP、Java等，还有ODBC接口，同样比起Mysql、PostgreSQL这两款

正则表达式使用单个字符串来描述、匹配一系列符合某个句法规则的字符串。在很多文本编辑器里，正则表达式通常被用来检索、替换那些符合某个模式的文本。由于正则表达式主要应用对象是文本，因此它在各种文本编辑器场合都有应用，小到著名编辑器EditPlus，大到Microsoft Word、Visual Studio等大型编辑器，都可以使用正则表达式来处理文本内容。

访问者模式是一种较为复杂的行为型设计模式，它包含访问者和被访问元素两个主要组成部分，这些被访问的元素通常具有不同的类型，且不同的访问者可以对它们进行不同的访问操作。访问者模式使得用户可以在不修改现有系统的情况下扩展系统的功能，为这些不同类型的元素增加新的操作。在使用访问者模式时，被访问元素通常不是单独存在的，它们存储在一个集合中，这个集合被称为“对象结构”，访问者通过遍历对象结构实现对其中存储的元素的逐个操作。

访问者模式是一种较为复杂的行为型设计模式，它包含访问者和被访问元素两个主要组成部分，这些被访问的元素通常具有不同的类型，且不同的访问者可以对它们进行不同的访问操作。访问者模式使得用户可以在不修改现有系统的情况下扩展系统的功能，为这些不同类型的元素增加新的操作。在使用访问者模式时，被访问元素通常不是单独存在的，它们存储在一个集合中，这个集合被称为“对象结构”，访问者通过遍历对象结构实现对其中存储的元素的逐个操作。

备忘录模式提供了一种状态恢复的实现机制，使得用户可以方便地回到一个特定的历史步骤，当新的状态无效或者存在问题时，可以使用暂时存储起来的备忘录将状态复原，当前很多软件都提供了撤销(Undo)操作，其中就使用了备忘录模式。

如果对象之间的联系呈现为网状结构，存在大量的多对多联系，在网状结构中，几乎每个对象都需要与其他对象发生相互作用，而这种相互作用表现为一个对象与另外一个对象的直接耦合，这将导致一个过度耦合的系统。如果在一个系统中对象之间存在多对多的相互关系，我们可以将对象之间的一些交互行为从各个对象中分离出来，并集中封装在一个中介者对象中，并由该中介者进行统一协调，这样对象之间多对多的复杂关系就转化为相对简单的一对多关系。通过引入中介

职责链可以是一条直线、一个环或者一个树形结构，最常见的职责链是直线型，即沿着一条单向的链来传递请求。链上的每一个对象都是请求处理者，职责链模式可以将请求的处理者组织成一条链，并让请求沿着链传递，由链上的处理者对请求进行相应的处理，客户端无须关心请求的处理细节以及请求的传递，只需将请求发送到链上即可，实现请求发送者和请求处理者解耦。

状态模式用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题。当系统中某个对象存在多个状态，这些状态之间可以进行转换，而且对象在不同状态下行为不相同时可以使用状态模式。状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化，对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致处理。

模板方法模式是一种基于继承的代码复用，它是一种类行为型模式；是结构最简单的行为型设计模式，在其结构中只存在父类与子类之间的继承关系。通过使用模板方法模式，可以将一些复杂流程的实现步骤封装在一系列基本方法中，在抽象父类中提供一个称之为模板方法的方法来定义这些基本方法的执行次序，而通过其子类来覆盖某些步骤，从而使得相同的算法框架可以有不同的执行结果。模板方法模式提供了一个模板方法来定义算法框架，而某些具体步骤的实现可以在

在软件开发中，我们经常需要向某些对象发送请求（调用其中的某个或某些方法），但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，此时，我们特别希望能够以一种松耦合的方式来设计软件，使得请求发送者与请求接收者能够消除彼此之间的耦合，让对象之间的调用关系更加灵活，可以灵活地指定请求接收者以及被请求的操作。命令模式为此类问题提供了一个较为完美的解决方案。命令模式可以将请求发送者和接收者完全解耦，发送者与接收者之间没有直

使用策略模式可以定义一些独立的类来封装不同的算法，每一个类封装一种具体的算法，在这里，每一个封装算法的类我们都可以称之为一种策略(Strategy)，为了保证这些策略在使用时具有一致性，一般会提供一个抽象的策略类来做规则的定义，而每种算法则对应于一个具体策略类。策略模式的主要目的是将算法的定义与使用分开，将算法的定义放在专门的策略类中，每一个策略类封装了一种实现算法，使用算法的环境类针对抽象策略类进行编程，符合“依赖

在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“ 同一种算法在多种集合对象上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方法。

观察者模式用于建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应作出反应。在观察者模式中，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间可以没有任何相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展。一个软件系统常常要求在某一个对象的状态发生变化的时候，某些其他的对象做出相应的改变。做到这一点的设计方案有很多，但是为

代理模式是常用的结构型设计模式之一，当无法直接访问某个对象或访问某个对象存在困难时可以通过一个代理对象来间接访问，为了保证客户端使用的透明性，所访问的真实对象与代理对象需要实现相同的接口。根据代理模式的使用目的不同，代理模式又可以分为多种类型，例如保护代理、远程代理、虚拟代理、缓冲代理等，它们应用于不同的场合，满足用户的不同需求。

当一个软件系统在运行时产生的对象数量太多，将导致运行代价过高，带来系统性能下降等问题。所以需要采用一个共享来避免大量拥有相同内容对象的开销。在Java中，String类型就是使用了享元模式。String对象是final类型，对象一旦创建就不可改变。在Java中字符串常量都是存在常量池中的，Java会确保一个字符串常量在常量池中只有一个拷贝。

一个客户类需要和多个业务类交互，而这些业务类经常会作为整体出现，由于涉及到的类比较多，导致使用时代码较为复杂。外观模式通过引入一个新的外观类(Facade)来实现该功能，外观类为多个业务类的调用提供统一入口，简化了类与类之间的交互。如果没有外观类，那么每个客户类需要和多个业务类之间进行复杂的交互，系统的耦合度将很大。外观模式是迪米特法则的一种具体实现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与

装饰模式可以在不改变一个对象本身功能的基础上给对象增加额外的新行为。装饰模式是一种用于替代继承的技术，它通过一种无须定义子类的方式来给对象动态增加职责，使用对象之间的关联关系取代类之间的继承关系。在装饰模式中引入了装饰类，在装饰类中既可以调用待装饰的原有类的方法，还可以增加新的方法，以扩充原有类的功能。

组合模式又叫做部分-整体模式，使我们在树型结构的问题中模糊简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂的元素，从而使得客户程序与复杂元素的内部结构解耦。组合模式可以优化处理递归或分级数据结构。有许多关于分级数据结构的例子，使得组合模式非常有用武之地。

桥接模式是一种很实用的结构型设计模式，如果软件系统中某个类存在多个独立变化的维度，通过该模式可以将这多个维度分离出来，使他们可以独立扩展，让系统更加符合“单一职责原则”。与多层继承方案不同，它将多个独立变化的维度设计为多个独立的继承等级结构，并且在抽象层建立一个抽象关联，该关联关系类似一条连接多个独立继承结构的桥，故名桥接模式。桥接模式用一种巧妙的方式处理多层继承存在的问题，用抽象关联取代了传统的多层继承，将类之间的

要理解原型原型模式必须先理解Java里的浅复制和深复制。有的地方，复制也叫做克隆。Java提供这两种克隆方式。 因为Java中的提供clone()方法来实现对象的克隆,所以Prototype模式实现一下子变得很简单。

将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。即Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。核心概念： 将一个接口转换成客户希望的另一个接口，使接口不兼容的。

建造者模式将客户端与包含多个组成部分的复杂对象的创建过程分离，客户端压根不用知道复杂对象的内部组成部分与装配方式，只需要知道所需建造者的类型即可。它关注如何一步一步创建一个的复杂对象，不同的具体建造者定义了不同的创建过程，且具体建造者相互独立，增加新的建造者非常方便。

单例模式可能是23种设计模式中最简单的。应用也非常广泛，譬如Android中的数据库访问等操作都可以运用单例模式。核心概念： 确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。