1.Navigation源码解析及自定义FragmentNavigator详解
2.源码编译——Xposed源码编译详解
3.TiDB 源码阅读系列文章（五）TiDB SQL Parser 的文章文章实现

Navigation源码解析及自定义FragmentNavigator详解

       谷歌推出的Navigation主要目标是统一应用内页面跳转行为。使用方法简单，系统系统新项目选择Bottom Navigation Activity，源码源码系统自动生成页面逻辑。文章文章

       Navigation源码设计简洁，系统系统包含多个关键类。源码源码家长监控系统源码其中，文章文章NavHostFragment是系统系统直接在XML文件中定义的，其生命周期方法onCreate中直接创建了NavHostController，源码源码并通过findNavController暴露给外部调用者。文章文章NavHostController继承自NavController。系统系统在此过程中，源码源码通过navController获取NavigatorProvider并添加了两个Navigator：DialogFragmentNavigator和FragmentNavigator。文章文章NavController构造方法中还额外添加了两个Navigator，系统系统分别对应DialogFragment、源码源码Fragment和Activity的页面跳转。NavGraphNavigator用于在XML配置的navGraph与根节点文件中的startDestination之间实现跳转，功能单一。

       各个Navigator通过重写navigate方法实现各自的跳转逻辑。FragmentNavigator的关键实现在于注释1处，使用replace加载Fragment，这不符合实际开发需求。文章后续将解释如何自定义FragmentNavigator以避免Fragment在切换时执行生命周期。

       NavigatorProvider内部维护了一个HashMap存储相关Navigator信息，通过获取Navigator的注解Name作为键和getClass作为值进行存储。在onCreate方法中，mNavController调用了setGraph，解析XML配置的mobile_navigation节点信息文件，根据不同的CobaltStrike源码节点各自解析。通过获取NavInflater进行解析，返回NavGraph，NavGraph继承自NavDestination，保存了所有解析出的节点信息。

       总结，通过NavHostFragment获取到NavContorl并存储了相关Navigator信息。通过各自navigate方法进行页面跳转，通过setGraph解析配置的页面节点信息并封装为NavGraph对象。其中，通过SparseArray存储Destination信息。

       自定义Navigator实现思路主要在于继承现有FragmentNavigator并重写其navigate方法，将replace方法替换为show和hide方法，完成Fragment切换。通过@Navigator.Name(value)注解标记自定义类为Navigator，加入NavigatorProvider中即可识别。自定义Navigator核心代码实现后，需调整mobile_navigation节点中的fragment为fixFragment，并删除布局文件中NavHostFragment节点信息，手动关联FixFragmentNavigator与NavControl，完成Fragment切换时生命周期不会重新执行。

源码编译——Xposed源码编译详解

       本文深入解析了基于Android 6.0源码环境，实现Xposed框架的源码编译至定制化全过程，提供一套清晰、系统的操作指南。实验环境选取了Android 6.0系统，旨在探索并解决源码编译过程中遇到的难点，同时也借助于社区中其他大神的宝贵资源，让编译过程更加高效且精准。pulseln源码

       致谢部分，首先对定制Xposed框架的世界美景大佬致以诚挚的感谢，其提供框架的特征修改思路和代码实例给予了深度学习的基础，虽然个人能力有限，未能完整复现所有的细节，但通过对比和实践，逐步解决了遇到的问题。特别提及的是肉丝大佬的两篇文章，《来自高纬的对抗：魔改XPOSED过框架检测(上)》和《来自高纬的对抗：魔改XPOSED过框架检测(下)》，这两篇文章是本文深入定制Xposed框架的基础指引，通过它们的学习，许多技术细节和解决方案得以明确。

       关于Xposed框架编译和配置的技术细节，参考文章《xposed源码编译与集成》提供了清晰的理论框架，而在《学习篇-xposed框架及高版本替代方案》中，能够找到关于Xposed安装、功能验证以及遇到问题时的解决策略，这两篇文档对理解Xposed框架运行机制、安装流程以及后续的调试工作大有裨益。

       在编译流程中，我们首先对Xposed框架中的各个核心组件进行详细的解析和功能定位，包括XposedInstaller、XposedBridge、Xposed、android_art、以及XposedTools。每一步都精心设计，确保实现模块与Android系统环境的dnguard源码无缝对接。接下来，我们进行具体的编译步骤。

       首先是XposedBridge源码的下载，直接从GitHub上获取最新且与Android 6.0版本相适配的代码，这里选择下载Xposed_art。其次，通过Android.mk文件，我们可以配置编译环境，明确哪些源文件需要编译、生成的目标文件类型以及依赖的其他库文件。在Android.mk文件中，要确保针对特定的XposedBridge版本进行参数的调整，避免不必要的错误。

       后续的编译过程可通过mmm或Android Studio完成。mmm编译更倾向于手动操作，适合熟悉CMakebuild系统的开发者，而Android Studio提供了一站式的IDE解决方案，操作流程更为便捷且直观。无论是采用哪种编译方式，最终的目标是生成XposedBridge.jar文件，这个文件将成为Xposed框架的核心组件，用于在Android系统上运行模块化的功能。

TiDB 源码阅读系列文章（五）TiDB SQL Parser 的实现

       本文是 TiDB 源码阅读系列文章的第五篇，主要内容围绕 SQL Parser 功能实现进行讲解。内容源自社区伙伴马震（GitHub ID：mz）的投稿。系列文章的目的是与数据库研究者及爱好者深入交流，收到了社区的积极反馈。后续，netexam源码期待更多伙伴加入 TiDB 的探讨与分享。

       TiDB 的源码阅读系列文章，帮助读者系统性地学习 TiDB 内部实现。最近的《SQL 的一生》一文，全面阐述了 SQL 语句处理流程，从接收网络数据、MySQL 协议解析、SQL 语法解析、查询计划制定与优化、执行直至返回结果。

       其中，SQL Parser 的功能是将 SQL 语句按照 SQL 语法规则进行解析，将文本转换为抽象语法树（AST）。此功能需要一定背景知识，下文将尝试介绍相关知识，以帮助理解这部分代码。

       TiDB 使用 goyacc 根据预定义的 SQL 语法规则文件 parser.y 生成 SQL 语法解析器。这一过程可在 TiDB 的 Makefile 文件中看到，通过构建 goyacc 工具，使用 goyacc 依据 parser.y 生成解析器 parser.go。

       goyacc 是 yacc 的 Golang 版本，因此理解语法规则定义文件 parser.y 及解析器工作原理之前，需要对 Lex & Yacc 有所了解。Lex & Yacc 是用于生成词法分析器和语法分析器的工具，它们简化了编译器的编写。

       下文将详细介绍 Lex & Yacc 的工作流程，以及生成解析器的过程。我们将从 Lex 根据用户定义的 patterns 生成词法分析器，词法分析器读取源代码并转换为 tokens 输出，以及 Yacc 根据用户定义的语法规则生成语法分析器等角度进行阐述。

       生成词法分析器和语法分析器的过程，用户需为 Lex 提供 patterns 的定义，为 Yacc 提供语法规则文件。这两种配置都是文本文件，结构相同，分为三个部分。我们将关注中间规则定义部分，并通过一个简单的例子来解释。

       Lex 的输入文件中，规则定义部分使用正则表达式定义了变量、整数和操作符等 token 类型。例如整数 token 的定义，当输入字符串匹配正则表达式时，大括号内的动作会被执行，将整数值存储在变量yylval 中，并返回 token 类型 INTEGER 给 Yacc。

       而 Yacc 的语法规则定义文件中，第一部分定义了 token 类型和运算符的结合性。四种运算符都是左结合，同一行的运算符优先级相同，不同行的运算符，后定义的行具有更高的优先级。语法规则使用 BNF 表达，大部分现代编程语言都可以使用 BNF 表示。

       表达式解析是生成表达式的逆向操作，需要将语法树归约到一个非终结符。Yacc 生成的语法分析器使用自底向上的归约方式进行语法解析，同时使用堆栈保存中间状态。通过一个表达式 x + y * z 的解析过程，我们可以理解这一过程。

       在这一过程中，读取的 token 压入堆栈，当发现堆栈中的内容匹配了某个产生式的右侧，则将匹配的项从堆栈中弹出，将该产生式左侧的非终结符压入堆栈。这个过程持续进行，直到读取完所有的 tokens，并且只有启始非终结符保留在堆栈中。

       产生式右侧的大括号中定义了该规则关联的动作，例如将三项从堆栈中弹出，两个表达式相加，结果再压回堆栈顶。这里可以使用 $position 的形式访问堆栈中的项，$1 引用第一项，$2 引用第二项，以此类推。$$ 代表归约操作执行后的堆栈顶。本例的动作是将三项从堆栈中弹出，两个表达式相加，结果再压回堆栈顶。

       在上述例子中，动作不仅完成了语法解析，还完成了表达式求值。一般希望语法解析的结果是一颗抽象语法树（AST），可以定义语法规则关联的动作。这样，解析完成时，我们就能得到由 nodeType 构成的抽象语法树，对这个语法树进行遍历访问，可以生成机器代码或解释执行。

       至此，我们对 Lex & Yacc 的原理有了大致了解，虽然还有许多细节，如如何消除语法的歧义，但这些概念对于理解 TiDB 的代码已经足够。

       下一部分，我们介绍 TiDB SQL Parser 的实现。有了前面的背景知识，对 TiDB 的 SQL Parser 模块的理解会更易上手。TiDB 使用手写的词法解析器（出于性能考虑），语法解析采用 goyacc。我们先来看 SQL 语法规则文件 parser.y，这是生成 SQL 语法解析器的基础。

       parser.y 文件包含 多行代码，初看可能令人感到复杂，但该文件仍然遵循我们之前介绍的结构。我们只需要关注第一部分 definitions 和第二部分 rules。

       第一部分定义了 token 类型、优先级、结合性等。注意 union 结构体，它定义了在语法解析过程中被压入堆栈的项的属性和类型。压入堆栈的项可能是终结符，也就是 token，它的类型可以是 item 或 ident；也可能是非终结符，即产生式的左侧，它的类型可以是 expr、statement、item 或 ident。

       goyacc 根据这个 union 在解析器中生成对应的 struct。在语法解析过程中，非终结符会被构造成抽象语法树（AST）的节点 ast.ExprNode 或 ast.StmtNode。抽象语法树相关的数据结构定义在 ast 包中，它们大都实现了 ast.Node 接口。

       ast.Node 接口有一个 Accept 方法，接受 Visitor 参数，后续对 AST 的处理主要依赖这个 Accept 方法，以 Visitor 模式遍历所有的节点以及对 AST 做结构转换。例如 plan.preprocess 是对 AST 做预处理，包括合法性检查以及名字绑定。

       union 后面是对 token 和非终结符按照类型分别定义。第一部分的最后是对优先级和结合性的定义。文件的第二部分是 SQL 语法的产生式和每个规则对应的 aciton。SQL 语法非常复杂，大部分内容都是产生式的定义。例如 SELECT 语法的定义，我们可以在 parser.y 中找到 SELECT 语句的产生式。

       完成语法规则文件 parser.y 的定义后，使用 goyacc 生成语法解析器。TiDB 对 lexer 和 parser.go 进行封装，对外提供 parser.yy_parser 进行 SQL 语句的解析。

       最后，我们通过一个简单的例子，使用 TiDB 的 SQL Parser 进行 SQL 语法解析，构建出抽象语法树，并通过 visitor 遍历 AST。我实现的 visitor 只输出节点的类型，运行结果依次输出遍历过程中遇到的节点类型。

       了解 TiDB SQL Parser 的实现后，我们有可能实现当前不支持的语法，如添加内置函数。这为我们学习查询计划以及优化打下了基础。希望这篇文章对读者有所帮助。

       作者介绍：马震，金蝶天燕架构师，负责中间件、大数据平台的研发，今年转向 NewSQL 领域，关注 OLTP/AP 融合，目前在推动金蝶下一代 ERP 引入 TiDB 作为数据库存储服务。