开源实验室

张涛 - 【HarmonyOS】TheRouter 鸿蒙版新手入门

2025-03-23

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/code/2025/03/23/01

TheRouter 鸿蒙版是货拉拉基于HMRouter深度定制的开源路由框架，提供了 Android、iOS、Harmony 三端高一致性使用，在支持平台化应用实现组件化、跨模块调用、动态化等功能的集成等功能基础上，支持动态路由下发、编译时安全检查、路由Path一对多等高度动态能力。

Github: https://github.com/HuolalaTech/hll-wp-therouter-harmony/
官网：http://therouter.cn/

0、开始之前

如果你的是新项目，请先记住一点：plugin、router 两个依赖的版本号必须保持一致，请继续往下看接入步骤。

0.1、查看最新版本

TheRouter 的版本分为两种，稳定版和 rc版，一般不追求新功能我们就用稳定版就行，可以在官网看到最新的版本号和各种版本的说明：https://therouter.cn/docs/2022/09/06/01

一、接入

在工程根目录命令行引入依赖库和插件库（必须全部依赖，不能只使用其中一个）。

// 引入代码库依赖
ohpm i @therouter/library   

// 引入插件依赖
npm i @therouter/plugin

第一步：接入编译插件

打开项目根目录的 hvigor/hvigor-config.json5，检查 dependencies 中是否已经加入了依赖，一般为 "@therouter/plugin": "x.x.x"。
打开工程所有模块（hsp、hap、har）的 hvigorfile.ts 文件。
在 plugins 中加入如下对应的依赖

// 如果是 hap，则类似如下依赖
import { hapPlugin } from "@therouter/plugin";
export default {
  plugins: [hapPlugin()]
}

// 如果是 har，则类似如下依赖
import { harPlugin } from "@therouter/plugin";
export default {
  plugins: [harPlugin()]
}

// 如果是 hsp，则类似如下依赖
import { hspPlugin } from "@therouter/plugin";
export default {
  plugins: [hspPlugin()]
}

第二步：检查依赖是否引入

打开 工程根目录 的 oh-package.json5 文件。
检查 dependencies 中，是否已经加入了依赖，一般为："@therouter/library": "x.x.x"

二、使用

2.1、初始化

在项目入口的 UIAbility 的 onCreate() 中加入如下代码：

onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    TheRouter.init(this.context);
}

2.2、定义页面容器

TheRouter 按照华为推荐方案，基于系统 Navigation 实现，所以必须在页面中定义一个容器项 TheRouterPage，建议创建一个完全新的类作为入口并在 /resources/base/profile/main_pages.json 中配置这个类，复制如下代码：

import { TheRouterPage } from '@therouter/library';

@Entry
@Component
struct Index {
  build() {
    RelativeContainer() {
      TheRouterPage({
        stackId: 'XXXX',  //【必传】可以自定义当前stack的名字，每个stack必须唯一
        root: 'path'  // 【必传】当前应用的首页 path，推荐按照一定格式定义页面path
		// 还有很多可选参数，详情请见文档
      });
    }
    .height('100%')
    .width('100%')
  }
}

2.3、声明路由

给需要跳转的页面加上路由表声明

@Route({path : "http://therouter.com/home"})
export struct HomePage {
	xxx
}

2.4、发起跳转

在需要跳转页面的位置调用如下代码：

TheRouter
	.build("http://therouter.com/home")  
	.withString('k', 'v') // 向落地页传参数（如果没参数，可不调用）
	.with({ hello: 'world' }) // 另一种方式传参
	.navigation()

2.5、获取页面传参

接收有两种形式：

通过注解自动接收，默认支持 String 和8种基本数据类型，也支持自定义对象的解析
通过代码从路由中获取

使用注解接收对象时，必须调用 TheRouter.inject(this) 。

// 第一种：使用注解自动填充
  // 允许解析成8种基本数据类型或对应封装类
  @Autowired()
  key1 : string = ''

  // 允许自定义传参key，如果不传默认是变量名作为key
  @Autowired('hello')
  key1 : string = ''

  // 使用注解接收对象时，必须调用，建议放在 aboutToApper() 中调用。
  TheRouter.inject(this)
  
  
  
// 第二种：通过代码从路由中获取
  // 可以在任何方法中调用，getCurrentParam() 返回值是个ESObject
  const v = TheRouter.getCurrentParam()['k'];   
  

三、问题排查万能公式

在使用过程中，如果发现服务无法调用，或返回为空的时候。通常的排查方式都是以下三步：

首先观察接入环境。插件是否和依赖库版本一致，插件是否生效了。在我们内部使用的过程中，经常发现，oh-package.json5 中引入的明明是新版本，但是实际编译时使用的还是老版本，猜测应该是构建工具的问题。在TheRouter编译时，日志的第一行就会有当前编译实际使用的版本号，如果和你预期不一致时，需要再执行一下命令行：
```
 // 引入代码库依赖
 ohpm i @therouter/library   

 // 引入插件依赖
 npm i @therouter/plugin
```
上一步排查完依然无法调用时，就要考虑一下是不是代码使用姿势问题了。比如添加@ServiceProvider的服务提供者必须实现IServiceProvider接口。服务提供者注解参数里面的serviceName是不是和使用方传入的一致。注：如果多次添加重复serviceName，框架会保证安全，在编译时报错。
如果上两步都不能解决你的问题，那就需要进源码通过断点调试进一步明确问题出在哪里了。首先从TheRouter.init()开始找，看看路由表读取是否正确，再看服务Map里面是否有记录成功，再看调用的时候传入的是否正确，一步一步排查。

四、鸿蒙路由源码调试步骤

4.1、clone 仓库

使用命令行：

git clone git@github.com:HuolalaTech/hll-wp-therouter-harmony.git

4.2、创建 build-profile

在项目根目录中，新建一个名为 build-profile.json5 的文件，文件内加入如下内容。

{
  "app": {
    "signingConfigs": [ 
    // 签名部分需要手动从官网获取自己的开发者信息
     ],
    "products": [
      {
        "name": "default",
        "signingConfig": "xxxxx填上面的签名信息",
        "compatibleSdkVersion": "可根据自己SDK情况填写",
        "runtimeOS": "HarmonyOS",
        "buildOption": {
          "strictMode": {
            "caseSensitiveCheck": true,
            "useNormalizedOHMUrl": true
          }
        }
      }
    ],
    "buildModeSet": [
      {
        "name": "debug",
      },
      {
        "name": "release"
      }
    ]
  },
  "modules": [
    {
      "name": "entry",
      "srcPath": "./entry",
      "targets": [
        {
          "name": "default",
          "applyToProducts": [
            "default"
          ]
        }
      ]
    },
    {
      "name": "therouter",
      "srcPath": "./therouter"
    },
    {
      "name": "business_a",
      "srcPath": "./business_a"
    },
    {
      "name": "business_b",
      "srcPath": "./business_b"
    },
    {
      "name": "base",
      "srcPath": "./base"
    }
  ]
}

4.3、创建 hvigor 构建环境

在工程根目录新建一个名为 hvigor 的文件夹
文件夹内新建一个名为 hvigor-config.json5 的文件，文件内加入如下内容：

{
  "modelVersion": "根据实际情况填写版本号",
  "dependencies": {
    "@therouter/plugin": "根据实际情况填写版本号"  
  },
  "execution": {
    // "analyze": "normal",                     /* Define the build analyze mode. Value: [ "normal" | "advanced" | false ]. Default: "normal" */
    // "daemon": true,                          /* Enable daemon compilation. Value: [ true | false ]. Default: true */
    // "incremental": true,                     /* Enable incremental compilation. Value: [ true | false ]. Default: true */
    // "parallel": true,                        /* Enable parallel compilation. Value: [ true | false ]. Default: true */
    // "typeCheck": false,                      /* Enable typeCheck. Value: [ true | false ]. Default: false */
  },
  "logging": {
    // "level": "info"                          /* Define the log level. Value: [ "debug" | "info" | "warn" | "error" ]. Default: "info" */
  },
  "debugging": {
    // "stacktrace": false                      /* Disable stacktrace compilation. Value: [ true | false ]. Default: false */
  },
  "nodeOptions": {
    // "maxOldSpaceSize": 8192                  /* Enable nodeOptions maxOldSpaceSize compilation. Unit M. Used for the daemon process. Default: 8192*/
    // "exposeGC": true                         /* Enable to trigger garbage collection explicitly. Default: true*/
  }
}

张涛 - 为 TheRouter 的 AGP8 编译加个速

2024-10-31

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/code/2024/10/31/01

背景

AGP8 的变更应该很多人都知道了，移除了Transform API，所以很多 class 操作类的插件代码都需要改了。

TheRouter在开发的时候就支持了AGP8，使用的也是Gradle提供的标准 API。

详细可见官方示例仓库：https://github.com/android/gradle-recipes/blob/agp-8.7/transformAllClasses/build-logic/plugins/src/main/kotlin/CustomPlugin.kt

project.plugins.withType(AppPlugin::class.java) {
    // Queries for the extension set by the Android Application plugin.
    // This is the second of two entry points into the Android Gradle plugin
    val androidComponents =
        project.extensions.getByType(ApplicationAndroidComponentsExtension::class.java)
    // Registers a callback to be called, when a new variant is configured
    androidComponents.onVariants { variant ->
        val taskProvider = project.tasks.register<ModifyClassesTask>("${variant.name}ModifyClasses")

        // Register modify classes task
        variant.artifacts.forScope(ScopedArtifacts.Scope.PROJECT)
            .use(taskProvider)
            .toTransform(
                ScopedArtifact.CLASSES,
                ModifyClassesTask::allJars,
                ModifyClassesTask::allDirectories,
                ModifyClassesTask::output
            )
    }
}

问题

这里使用的是toTransform()这个方法替代老版本的 API，这么做以后有个问题，就是编译速度会非常非常慢，尤其是工程里代码量越大，编译速度越慢，原因我们先看看这个方法的定义。

/**
 * Transform the current version of the [type] artifact into a new version. The order in which
 * the transforms are applied is directly set by the order of this method call. First come,
 * first served, last one provides the final version of the artifacts.
 *
 * @param type the [ScopedArtifact] to transform.
 * @param inputJars lambda that returns a [ListProperty] or [RegularFile] that will be used to
 * set all incoming files for this artifact type.
 * @param inputDirectories lambda that returns a [ListProperty] or [Directory] that will be used
 * to set all incoming directories for this artifact type.
 * @param into lambda that returns the [Property] used by the [Task] to save the transformed
 * element. The [Property] value will be automatically set by the Android Gradle Plugin and its
 * location should not be considered part of the API and can change in the future.
 */
fun toTransform(
    type: ScopedArtifact,
    inputJars: (T) -> ListProperty<RegularFile>,
    inputDirectories: (T) -> ListProperty<Directory>,
    into: (T) -> RegularFileProperty)

重点在这一句：last one provides the final version of the artifacts。这个方法是整个构建最后一步执行，会提供一个最终的输出，并且输出类型是一个 RegularFileProperty 他只能输出一个单独的 File。

这也就意味着你需要把前期构建的所有产物，包括全部的 jar 依赖、源码编译后的 class 依赖，都在这个Task中聚合到一个产物内返回，这就是耗时的原因。

并且由于需要将所有的 jar 和 class 聚合到一个 jar 内，所以也没办法使用增量编译，这就又进一步拖慢了编译速度。

而对应的老版本操作是，拿到所有的 jar 和 class，需要字节码操作的就做操作，不需要的直接复制一遍到输出路径就可以。很显然，新版本使用的方案还不如旧版本，把所有的class聚合成一个新的jar是很耗时的，而且没办法做增量操作。

解决思路1

既然耗时间的原因是将全部的 class 聚合成一个 jar，这一步太慢。那么我们的想法肯定是怎么避免这样做，同时又能在编译期改变 class 内容。

在老版本Transform API的替代类还提供了一个 AsmClassVisitorFactory，是对一个指定class做字节码操作，而我们的TheRouter路由恰好是只需要改TheRouterServiceProvideInjecter这一个类就足够了，那这样就可以大幅降低编译时间了。

但是问题是在于， AsmClassVisitorFactory 是对所有类遍历的过程中执行的，而路由的代码需要所有类遍历一遍以后才知道应该要把哪些类放到 TheRouterServiceProvideInjecter中。如果使用AsmClassVisitorFactory，就有可能要记录的类还没有遍历完，就已经轮到要ASM插桩处理的TheRouterServiceProvideInjecter类了。

比如这个图中的流程，假设红色箭头是当前构建处理类的顺序，整体的逻辑就是处理A类的时候，记录是否需要插桩，再B，再C。但是到TheRouterServiceProvideInjecter的时候，就要开始读取记录，开始插桩了，实际上如果E、F也是需要插桩的话，此时就会被漏掉。

所以现在的问题又变成了如何让 ASM 处理的时候就知道要处理哪些类。

解决思路2

之前在TheRouter的反馈群里，有人给出了这篇文章，里面提到了一个很好的方案：https://juejin.cn/post/7374677514536812571

在编译的时候，由于KSP/KAPT这种编译期工具是优先于Transform过程的，并且我们所有需要插入的代码类都是由 KSP/KAPT 生成的，可以在这个时候将所有需要记住的类写入的一个构建文件中，直到Transform的时候直接去读这个文件。
但是他有个很大的弊端，公司大了以后项目会变成各个业务线开发一个独立模块，最终打包的时候只依赖各个业务线的aar打包。而 KSP 如果是在独立模块中，那么在 aar 生成的时候就已经执行完了，这时候如果是给到主工程aar再去打包，就会丢失这个aar内需要写入到文件中的产物。

大概的逻辑如下图：

AAR A、AAR B、AAR C，里面的ksp_cache.txt就会丢失了，因为app在构建的时候，也会有自己的产物文件，这部分并没有包含aar中的内容。
然后还有一种折中的办法，就是让所有aar提供给app接入方的时候，也同时将这个产物文件一起提供，由接入方手动把产物同步到app的产物文档内，这样在最终打包的时候插件asm就能直接插入了。

TheRouter 目前的方案

还是回到最原始的那个思考。

AsmClassVisitorFactory 可以做到增量编译，并且按需插桩，问题是插桩时还没有遍历完全部类。
toTransform() 可以做到完整遍历所有类，并且按需插桩，问题是无法增量编译，类多的时候执行很耗时。

那么能不能把这两个结合一下？

用AsmClassVisitorFactory去做插桩，用toTransform()去生成待插桩的记录文件。

但这样依然有2个问题。

前面也讲过了toTransform()执行时间是在整个构建的最后。所以这就变成了先插桩，再生成记录文件。
toTransform()如果要想遍历所有类，依然要经历那个聚合所有class的动作，也就意味着依然没办法增量编译，所以并没有解决耗时问题。

第一个问题好解决，第一次遍历没法用，那就先记录，下次编译的时候再用这次的类记录缓存就行了。
第二个问题再想一下，toTransform()耗时的原因是需要把所有类聚合，而我们用到他的目的是为了在构建的最后执行我们自己的一个方法，那有没有可以在最后执行，又不需要聚合所有类的方法呢？还真有！ toTransform()方法所在类里面，还有一个方法，toGet()它只有两个输入，但是没有输出，并且也是在构建结尾执行。

/**
 * Set the final version of the [type] artifact to the input fields of the [Task] [T].
 * Those input fields should be annotated with [org.gradle.api.tasks.InputFiles] for Gradle to
 * property set the task dependency.
 *
 * @param type the [ScopedArtifact] to obtain the final value of.
 * @param inputJars lambda that returns a [ListProperty] or [RegularFile] that will be used to
 * set all incoming files for this artifact type.
 * @param inputDirectories lambda that returns a [ListProperty] or [Directory] that will be used
 * to set all incoming directories for this artifact type.
 */
fun toGet(
    type: ScopedArtifact,
    inputJars: (T) -> ListProperty<RegularFile>,
    inputDirectories: (T) -> ListProperty<Directory>)

从注释来看，toGet() 完全就是 toTransform() 的平替，而且非常适合我们现在的场景。再看一下官方的demo使用方法都一模一样，只是参数少了个输出路径。

https://github.com/android/gradle-recipes/blob/agp-8.7/getScopedArtifacts/build-logic/plugins/src/main/kotlin/CustomPlugin.kt

variant.artifacts
    .forScope(ScopedArtifacts.Scope.PROJECT)
    .use(taskProvider)
    .toGet(
        ScopedArtifact.CLASSES,
        CheckClassesTask::projectJars,
        CheckClassesTask::projectDirectories,
    )

再优化一下

现在还剩的一个问题就是：编译的记录文件是下次才生效的，但作为 SDK 这样的表现肯定是不合适的，因为会产生不确定性，你不知道实际使用 SDK 的用户会怎么用，万一他用了旧产物打的包直接发布了，那就会造成问题。

所以在TheRouter中，做了一个额外的内存缓存，会把本次编译使用的类记录，与本次构建新生成的类记录缓存，在编译结束时做一次对比，如果两次结果不一致，直接抛异常，表示本次构建的产物是有问题的，不可用，再次编译以后就正常了。
这样就能既享受了增量编译，快速构建，同时对产物结果有了保障。

比如微信群里面一个使用者的截图：

再优化首次的中断

目前还有一个问题，Gradle 构建此时的 AsmClassVisitorFactory 并不会每次都执行（如果输入没有变会直接跳过），单纯从构建来看这是合理的，但是上面的方案就出问题了。因此需要解决增量编译时缓存的正确性，否则会有两个结果，要么每次编译经常性的提醒有模块增删请重新编译，要么就是编译后的插桩类丢失。

因此我们再次将前面的模式整合一下，每次全新构建时，使用toTransform，同时将此时需要插桩的类记录下来。再次编译时，只走AsmClassVisitorFactory，对增量变化的类做记录，这样就彻底解决了类记录缺失、增量编译、缓存一致性的全部问题。

详细实现可以直接去看TheRouter的源码，能查看更多细节实现以及TheRouter对构建内存占用的优化，以及文件读写的优化。

说实话，其实这样的方案也是一个折中后的取舍。按理说如果 toTransform 加一个重载，第三个参数同时支持既能定义成File又能定义成Dir，如何在File的重载里面调用Dir的产物做一次聚合，达到的效果是一样的，并且也能更简单的解决问题。

2024.11.26 更新：
在 @5peak2me 的提醒下发现，原来从 AGP8 开始，就提供了上面的疑惑的方法，只不过 API 还是 internal 的，应该还是没确定具体的实现方案，可能要到 9 才能对外公开出来了，留个记录，后续观察吧。
详情见 TheRouter issue #216： https://github.com/HuolalaTech/hll-wp-therouter-android/issues/216.

张涛 - NAS - 玩点有意思的

2024-08-05

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/stickies/2024/08/05/01

NAS是什么

其实就是一个私有的云存储，你也可以理解为你自己独享的功耗很低的小型linux服务器，这个服务器通常用来做存储相关的事情，里面可以放很多很大的硬盘。
比如我就放了两块10T的硬盘，组了个冗余存储阵列，感觉10T已经够用了，等快装满的时候可以再买两块。

冗余存储

群晖系统对存储有多个支持类型（其实所有的NAS，都有类似的能力）。
最常用的存储就是RAID了，RAID（独立磁盘冗余阵列）是将多个独立的硬盘整合成一个存储单元的数据存储技术。
因为我们的物理机上是有多块硬盘的，但实际系统使用的时候，不可能每次都我们自己指定要存在哪块硬盘上(我一直不能理解Windows为什么要反过来，把完整的磁盘分不同的盘符)。RAID就是用来把多个硬盘的感受对使用者屏蔽，让使用者觉得用到的就是一块硬盘。

RAID 又分很多类型，Basic、RAID 0、RAID 1、RAID 5、RAID 6 …

Basic其实就是最普通的方式，众所周知，玩NAS，最贵的就是买硬盘了。假如你买不起，只有一块硬盘，那你只能组 Basic，它就是单个硬盘构成独立的单位。也不具备数据安全，如果硬盘坏了，那数据就丢了。

再进一步，还是那个原因，由于硬盘贵，并且相比其他电子元器件更容易坏，你只买了两块，这时候你有两种选择。牺牲存储来保障数据的安全性，同一份数据存两遍；或者不在乎数据的安全性，直接把两块拼起来，有多大的硬盘就存多少东西。这就对应了RAID 0和RAID 1 。

RAID 0 组合了两个或更多硬盘以提高性能和容量，但没有容错保护功能。单个硬盘出现故障将导致阵列中的的所有数据丢失。RAID 0 对于需要高性能比的非关键系统非常有用。

RAID 1 通常为两个硬盘来执行。硬盘中的数据被映射，在硬盘出现故障时提供容错保护功能。读取性能得到提高，而写入性能将与单个硬盘类似。单个硬盘出现故障时可得以维持而不会丢失数据。在容错保护非常关键而空间和性能不那么重要时，往往使用 RAID 1。

如果又过了一段时间，你觉得硬盘不够又买了几块硬盘，这时候你就又多一些选择。依然是牺牲存储来保障数据的安全性，或者更在乎能存的数据量，我要存更多东西但数据还得相对安全一点。这就对应了RAID 5和RAID 6。

RAID 5 提供容错保护功能并提高了读取性能。至少需要三个硬盘。RAID 5 可在单个硬盘丢失时得以维持运行。在硬盘出现故障的情况下，故障硬盘上的数据将从其余硬盘上延展的奇偶校验进行重建。因此，在 RAID 5 阵列处于降级状态时，读写性能受到严重影响。当存储空间和成本的重要性高于性能时，RAID 5 最为理想。

RAID 6 与 RAID 5 相似，但其提供了另一层区块延展功能，并在 2 个硬盘出现故障时得以维持。至少需要四个硬盘。RAID 6 的性能因其额外的容错保护功能而低于 RAID 5。在存储空间和成本较为重要且需要在多个硬盘出现故障得以维持的情况下，RAID 6 最为理想。

联通的公网IP

既然都是个服务器了，没有公网岂不是很没意思，只能在自己局域网玩有什么用。
先看一下我家的网络结构。

拨号靠联通光猫，然后路由器再分一个子网。这样子普通用户使用肯定没有问题，但是作为服务器肯定是不行的。
第一联通光猫性能极差，靠他去调度大流量指不定能把你卡成狗，所以一定得干掉那个性能极差的联通光猫，让自己的高性能路由器直接拨号上网，如果你的路由器更烂那你还是花几十块钱买个好点的吧。
第二个问题就是这种网络得做两次内网穿透，两次端口转发，光猫一次、路由器一次，太麻烦了。

接下来就是详细配置步骤：

首先本地通过wifi连上联通光猫的网段，然后访问管理页：http://192.168.1.1/cu.html
账号密码都是 CUAdmin，CU的意思是 China Unicom。
进去以后把IPV4和V6都打开，然后把模式选成桥接模式。
再进自己路由器设置，把路由器改成拨号上网。
拨号的账号可以在联通APP->首页右上角切宽带账号->我的->宽带专区->查宽带账号
密码不知道给10010打电话重置就行了。
能正常拨号上网以后，再给10010打电话，让他开公网IP，这一步不一定能成功，根据所在地联通的公网IP数量决定的，上海还挺多，二话没说就给我打开了。
至此已经有一个可变公网IP了，再配合腾讯云的DDNS，就得到一个公网可以访问的域名了。
记住，公网还是比较危险的，全世界各种端口扫描暴力破解的都在搞，路由器最好设置一下，把默认端口改了，把ssh密码校验关掉。

腾讯云免费 DDNS 服务看这个链接：腾讯云DDNS链接

以下是改进后的拓扑结构，NAS直连路由器，路由器直连公网：

配个nexus

作为一个移动端开发，最先想到的在服务端占用硬盘的服务，也就是nexus了。
有一个属于自己的Nexus代理，以后拉依赖可就快多了。

群晖是自带docker的，写一个compose.yml，直接拉镜像了，这种事当然不能我来写：

反正一路让GPT教我，分分钟就搞好了。

以下是我的 nexus，想用你也可以直接用，反正也就只是占我一点公网IP，没啥大影响。

repositories {
    maven { url 'https://maven.therouter.cn:8443/repository/maven-public/' }
    google()
    mavenCentral()
}

nginx 端口转发

你可能已经看到了，上面配nexus的时候，GPT 是帮我配置的8081端口，而且只支持 http 协议。但是新版本的Gradle默认是不允许 http 访问的，所以要么改Gradle 添加仓库时的代码，要么就从服务端直接支持 https。
你可以这样子添加一个 maven 仓库地址，手动声明允许 http 协议拉依赖，但最标准的做法当然还是让服务端支持。

maven {
    allowInsecureProtocol = true
    url "http://maven.therouter.cn/xxxx"
}

Nexus 要启用 https 还挺麻烦，搜了网上的各种教程照着配，也让GPT帮我改了很多次，依然没办法解决。最后是直接在 nginx 上做了一次端口转发，直接把外部的 https 请求，都打到 nginx 上，然后 nginx 再全转到内部的 8081 端口，也能达到目的。

server {
    listen 8443 ssl;
    server_name nas.therouter.cn;

    ssl_certificate /xxxxx/ssl/nas.therouter.cn.pem;
    ssl_certificate_key /xxxxx/nas.therouter.cn.key;

    location / {
        proxy_pass http://localhost:8081;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

网盘当然是用来存数据的

把 Mac 备份到 NAS 上

把 Mac 的时间机器备份到 NAS 上。
照着官网教程一步一步来，很简单
群晖官网链接

注：教程里面的这一句很重要，【进入高级选项卡，然后选择启用通过SMB进行 Bonjour Time Machine 播送】如果没有勾选，不会报任何错，但是在 mac 的时间机器里面，NAS 始终挂载不上，最后不停在连接 smb。

把 iPhone 备份到 NAS 上

垃圾 iOS 系统真的是封闭，我试了网上能搜到的几乎全部的方案，始终没有一个能够无感把iPhone数据直接备份到 NAS 上的办法。
后来我换了个思路，既然 iOS 封闭，那就在 Apple 的体系理解解决这个事。
通过我的 Mac，把 iPhone 的数据备份到 Nas 上。可能唯一麻烦的就是手机得连着电脑。

备份还是用 Apple 默认的备份方式，连上手机就能看到了。

Mac 默认是把手机的数据备份到电脑上，并且这个备份的路径是完全不告诉你的，费了点时间查到了，备份目录是在~/Library/Application\ Support/MobileSync/Backup
既然找到了备份目录就简单了。

最简单也最傻的办法，备份好了以后，直接手动把数据再转到NAS上。

很显然程序员是不会这么干的，直接一步到位，把手机数据直接丢到 NAS 上。

先通过smb在本地挂一个网络存储卷。
命令行进到存储目录，直接把原本的Backup目录删了。这一步会报Operation not permitted。
进 System setting -> Privacy -> Full Disk Access -> 把终端勾上

重新再进命令行，ln -s建一个软链，把 NAS 的存储目录链接到 Backup目录就行了。
这样再备份就自动备份到 NAS 上了。

把 Android 备份到 NAS 上

是的，一个移动端开发，手上只有一个手机是不是有点丢人。
Android 也没有什么好的同步软件，但是 Android 有个好处，遇事不求人，自己动手上。
无非就是读文件、读通话记录、读联系人、读短信，读完通过 smb 往NAS上写数据。自己写的自己也放心一点，省的第三方指不定读完顺手同步到哪去了。

对象存储

既然都公网IP了，NAS又本来就是做存储的，那拿来做对象存储太合适了。
还是老方法，docker 部一个 apache，把独立的文件夹映射出来做存储。nginx 再把跨域header限制一下，只能我自己的kymjs.com调用，顺带就又解决了盗链问题，剩下的被恶意刷流量更是无所谓了，反正联通公网IP，我交的是宽带费又不是服务器一样按流量计费。

再下一步就是把我的博客都给部署到 NAS 上了，这样每年的服务器费用也可以省下来买硬盘和交电费了，只不过好像运营商都是把80和443端口封了，所以可能访问起来会有些影响。

张涛 - 动态路由 TheRouter 的设计与实践

2022-11-23

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/session/2022/11/23/01

这篇文章是我在 2022【GIAC 全球互联网架构大会】分享时所讲内容的文字版本，修改删减了演讲时的冗余言语，现开放给大家阅读，希望能给买不到票参加分享的开源实验室读者带来帮助。

大家好，今天跟大家分享的是一个开源路由TheRouter的设计。
代码地址： https://github.com/HuolalaTech/hll-wp-therouter-android

先来看一下目录我们从三点，来讲述今天的主题：

分别是模块化的开始，如何通过路由去实现一个模块化。
然后再根据目标，去设计一个动态化的路由解决我们的问题，以及在我们的项目中，是如何实践的。
最后，今年的大环境大家应该都知道，考虑一下如何在资源有些的情况下，推动工程的重构。

这里有三张我手机上APP的截图，分别是：货拉拉、今日头条、美团

他们基本上可以代表了如今市面上大部分APP的一个形态，在这四五年里，互联网公司大幅增加，而APP的业务功能也不断增多。

从技术角度再看一下：

这是我列出来的一个APP的通用架构，这张图基本可以覆盖现如今百分之八九十的 APP 架构。

首先最上层是各个业务层比方说是像货拉拉的搬家、拉货、运大件这种。
接下来是各个业务模块比如常见的像用户账户体系、然后可能有一些直播、音视频、支付这样的场景模块。
再往下就是一些功能性的组件：他们可能跟具体的业务功能相关，比如推送、IM、广告控件、这样的一系列功能组件。
最底层就是基础设施了：就像数据上报异常统计等等一系列的必要基础能力。

然后在侧面还有一些贯穿整个APP的能力像CICD 国际化端智能热修复等等。

从这张图我们也能看出现如今的APP是越来越复杂功能也越来越多

对于功能越来越多，越来越复杂的APP架构，我们最直接能想到的就是通过模块化，将不同的功能、不同的业务做独立拆分，分而治之，降低整个系统的复杂度。毕竟越简单，逻辑越少的代码块，BUG就越少。

所以大型 APP 的开发，基本都会选用模块化开发，同时对于模块间解耦要求更高。
而说到模块化，我们一定需要一个路由去承载不同模块之间的通信。路由是现如今 Android 开发中必不可少的功能，尤其是企业级APP，可以用于将原生页面跳转的强依赖解耦，同时减少跨团队开发的互相依赖问题。

比如UI层级的跳转、功能模块的联动调用，这是做模块化绕不开的两点。

实现这两点最常用的办法也就是：分别将我们当前的一个UI页面与一个uri关联，用Uri替代我们的页面，

这个样子在跳转的时候就不需要强依赖UI页面去做匹配，而只需要通过一段字符串去匹配就行

那另一种就是通过接口下沉，将模块依赖改为协议依赖，这样我们在不同的模块之间调度的时候只需要依赖一个最基础的协议或者说是接口去实现就可以了

做完模块化以后，一个APP的复杂度已经被降低很多了。
但是有一个最大的问题，我们通过模块化是没办法解决的。

也就是APP依赖用户去主动的更新升级，用户不更新，那就是永远在用旧版本，当年，也是为了解决这个问题，催生出了很多黑科技，比如Android的插件化、热修复这种黑科技，最终这些科技最终也被验证是点歪了的技能树。

今天我跟大家讲讲另一种解决办法：

回到我们今天的主题：动态化路由

前些天我们开源了一套，在安卓上面的动态化路由叫 TheRouter 他是一整套我们实现APP动态化的设计方案。包括模块化、包括远端路由下发、包括前面刚才我列出来的几个依赖用户升级而造成的一些问题，我们都是通过他来解决的。

之所以叫TheRouter 因为 The 代表了一种唯一性，我们在设计的时候就参考了全部现有的开源方案，吸取了大量优秀实现，同时补齐了各个方案的缺点。我们认为做移动端的模块化，只需要看这一个就够了。

首先我们来看一下行业内路由的设计方案，不管是页面跳转，还是跨模块调用，基本上都是

开发阶段，对要使用路由的落地页或被调用方法添加注解标识。
在编译期解析注解，生成一系列中间代码，等待调用。
应用启动后调用中间代码完成路由的准备动作。大部分路由会额外通过 Gradle Transform，在编译期做一次聚合，以提升运行时准备路由表的效率。
发起路由跳转时，本质上就是一次路由表遍历，通过uri获取到对应的落地页或方法对象，进行调用。

跨模块调用也是类似，在开发时做标记，编译时生成中间代码，运行时通过中间代码调用跨模块方法。

TheRouter 的整体实现逻辑也是按照这个思路去做的，不过我们对于各个细节的处理，有更好的解决办法。

这是另一个角度，跟行业路由的一些对比数据。

大家可以主要关注这几个点：

第一个点： TheRouter是完全无运行时扫描，没有任何反射代码的框架。
当然因为引用了Gson做json解析，他里面应该是用了反射的，但这不在我们讨论的范围内，如果你愿意我们允许自定义json解析框架，你可以换成其他的解析。
第二点是TheRouter对增量编译支持非常好，APT、plugin都能做到增量编译。
同时我们内部也有一套基于最新KSP的注解处理代码，KSP是kotlin专门用于处理注解做的一套实现，我们之前用的都是kapt，但是kapt只能处理Kotlin类的注解，如果是Kotlin跟Java混合的工程，他还没办法处理，所以在他内部还包了一层Java的apt，碰到他解析不了的文件，就调用apt去解析，所以他的处理速度是非常慢的。
而KSP是基于语法树分析去做的，我们知道，所有的代码在编译之前，都会先经过语法树分析，他就是在这一步顺带把分析出来的词法返回，让我们做一些自己的定制逻辑。所以KSP其实不仅仅可以做注解处理，还可以做一些定制的语法分析规则，类似lint那种。
第三点：TheRouter应该是现如今所有路由里，唯一一个支持AGP8的。Gradle从7.X开始，内置了编译过程处理的相关方法，所以AGP直接在8.0删除了相同功能的方法，这就造成大量基于TransformAPI的库，在AGP8都没办法使用了。
最后一点也是我们之前碰到的坑，在用tinker这类热修复框架的时候，由于路由编译的产物代码是无序的，所以每次编译都有可能发生改变，就造成我们的补丁包非常大。TheRouter对这一点也做了特殊支持，只要你没有新增或改动路由相关的代码，编译产物代码就不会有任何变动。

接下来需要大家一起思考一下，一个路由他真正需要具备的核心能力是哪些。我前面PPT列了一下，参考现在业内的一些通用的路由解决方案它真正核心需要解决的问题就两个点：

一个是解耦UI跳转
一个是降低系统依赖

我们把这两个目标分别拆开。
在跳转方面，除了业界常用的通过路由字符串映射页面UI之外，我们还加入了动态参数注入。
也就是一个UI页面需要的默认参数可以通过路由表提前声明好，而路由表可以是远端下发的，那这些默认参数也可以是远端下发的，这就做到了线上默认字段的及时更新。

另一部分，降低依赖，除了常用的SPI接口下沉，将模块功能依赖改为接口协议依赖之外，我们还提供了业务节点的hook，所有模块可以反向订阅所需的业务节点，并在业务发生时做自己的逻辑处理。

这一个能力最常用的地方，比如我们在做隐私合规的时候，要求用户同意隐私协议以后，才能做一些敏感API的调用。在以前的开发，这些调用都得要放到隐私弹窗所在的模块内，当用户点同意按钮以后，再调用其他模块初始化方法。这种逻辑对模块化是非常难受的，因为增大了跨模块的沟通，如果团队特别大，不同团队负责不同模块的时候，这种沟通就很累了，假设初始化方法需要增加一个参数，还得额外处理。哪些能力是要一启动就调用的，哪些API是必须用户同意以后才能调用的，都得沟通清楚。

而我们做了业务节点订阅以后，就把这种依赖某个业务节点的功能，做成了订阅发布模式，你只需要声明初始化方法依赖用户同意隐私协议就行了，在用户同意以后就会自动调用初始化方法。

另外，我们还允许客户端创建一套基于规则引擎的触发与响应，可以全局动态智能处理用户操作。假设客户端此刻碰到什么意外情况，比如一个女性用户，在夜里十一二点打车，路上又在某些偏僻点发生异常停留，客户端可以主动做一些我们预置的事件，比如自动报警、语音或者视频自动联系我们的客服。比如像今年iPhone14的新功能，有个车祸检测，如果车翻了或者撞车了，自动帮你打救援电话。而我们这一系列规则，都可以是动态响应的。

接下来看一下路由的设计细节

TheRouter 会在编译期根据注解生成 RouteMap__开头的类，这些类中记录了当前模块的所有路由信息，也就是当前模块的路由表。

在最顶层的app模块中，通过Gradle插件，将所有aar、源码中的RouteMap__开头的类统一集中到TheRouterServiceProvideInjecter类中。

后续应用启动后，初始化路由时只需要执行TheRouterServiceProvideInjecter类的方法，就能没有任何反射的加载到全部的路由表了。

加载以后的路由表会被保存到一个支持正则匹配的 Map 中，这也是TheRouter允许多个path对应同一个落地页的原因。每当发生页面跳转时，通过跳转时的path，去Map中获取到对应的落地页信息，再正常调用startActivity()即可。

对于模块化开发中跨模块的调用，我们推荐采用 SOA(面向服务架构) 的设计方式，服务调用方与使用方完全隔离，调用模块外的能力不需要关注能力的提供者是谁。 ServiceProvider 的核心设计思想也是这样的，目前服务间的调用协议采用接口的方式。当然，也可以兼容不通过接口下沉而是直接调用的情况。

具体到 Android 侧就是 AIDL 类似的设计，只是要比AIDL开发简单很多：

服务提供方负责提供服务，不需要关心调用方是谁会在何时调用自己。
服务的使用方只关注服务本身，不需要关心这个服务是谁提供的，只需要只能服务能提供哪些能力即可。

例如上面的图片：服务使用方需要使用录音的服务，服务提供方则向外提供一个录音的服务，由TheRouter的ServiceProvider负责撮合。

服务使用方：

无需关心，IRecordService这个接口服务是谁提供的，他只需要知道自己需要使用这样的一个服务就行了。注：如果没有提供服务的提供方，TheRouter.get()可能返回null

TheRouter.get(IRecordService::class.java)?.doRecord()

服务提供方：

服务提供方需要声明一个提供服务的方法，用@ServiceProvider注解标记。

如果是 java，必须是 public static 修饰

如果是 kotlin，建议写成 top level 的函数

方法名不限

/**
 * 方法名不限定，任意名字都行
 * 返回值必须是服务接口名，如果是实现了服务的子类，需要加上returnType限定（例如下面代码）
 * 方法必须加上 public static 修饰，否则编译期就会报错
 */
@ServiceProvider
public static IRecordService test() {
    return new IRecordService() {
        @Override
        public void doRecord() {
            String str = "执行录制逻辑";
        }
    };
}

// 也可以直接返回对象，然后标注这个方法的服名是什么
@ServiceProvider(returnType = IRecordService.class)
public static RecordServiceImpl test() {
    // xxx 
}

前面讲过，TheRouter是完全面向模块化开发提供的一套解决方案。

在模块化开发时，可能每个模块都有自己需要初始化的一些代码。以前的做法是把这些代码都在Application里声明，但是这样可能随着业务变动每次都需要修改Application所在模块。TheRouter 的单模块自动初始化能力就是为了解决这样的情况，可以只在当前模块声明初始化方法后，将会在业务场景时自动被调用。

每个希望被自动初始化的方法，必须使用public static修饰，主要原因是这样子就能通过类名直接调用了。另外很多初始化代码都需要获取Context对象，所以我们将Context作为初始化方法的默认参数，会自动传入Application。其他的所在类名、方法名都没有限制，反正只要加上了 @FlowTask 注解，在编译期都能通过 APT 获取到。

或者隐私合规的时候，有一些功能需要同意隐私协议才能调用。

跨模块依赖的时候，需要另一个模块初始化以后，才能调用当前模块的初始化，等等业务都可以用业务节点自主订阅的方式去解耦。

每个加了 @FlowTask 注解的方法，都会在编译期被解析，生成一个对应的 Task 对象，这个对象包含了初始化方法的相关信息，比如：是否异步执行、任务名、是否依赖其他任务先执行。

当所有aar都编译完成，生成好全部的 Task 以后，会在主 app 中通过Gradle插件进行聚合，在这时会将所有的 Task 做一次检查，通过构建有向无环图来防止 Task 发生循环引用的情况。

每次应用启动后，会在路由初始化时，将有向图中的全部Task，按照依赖关系按顺序加载。

可以在当前模块中，任意类中声明一个任意方法名的方法，给方法添加上@FlowTask 的注解即可。

@FlowTask 注解参数说明：

taskName：当前初始化任务的任务名，必须全局唯一，建议格式为：moduleName_taskName
dependsOn：参考Gradle Task，任务与任务之间可能会有依赖关系。如果当前任务需要依赖其他任务先初始化，则在这里声明依赖的任务名。可以同时依赖多个任务，用英文逗号分隔，空格可选，会被过滤：dependsOn = “mmkv, config, login”，默认为空，应用启动就被调用
async：是否要在异步执行此任务，默认false。

最后一个，APP动态响应的实现。

还是回到之前的例子：假设一个女性、夜里12点、KTV上车、偏僻地点停车，那么我们就可以根据这样的一系列先决条件，交由后端的智慧大脑分析，然后下发给客户端一个动作：比如打开视频或语音，让客服介入。

而把这个例子抽象一下，所有用户的操作，比如点击、曝光、页面跳转等等埋点数据，都可以作为分析数据交给服务端分析，然后让客户端执行：跳转页面、弹窗、优惠券、或者其他本地方法。

这样的一个流程做完了以后，只要我们有一个可靠的行为分析模型，我们是大概率可以预测用户接下来的行为是要做什么的。

当然，即便我们没有这样一个用户行为分析的大脑，纯客户端的方案，也是能够支持的，这就是离线端智能方案了。

最后我们再来看一下前面提到的几个 APP 的弊端，在 TheRouter 中是怎么解决的呢？

第一个：页面Crash，我们可以通过去修改路由表，然后我们把某一些页面的 Crash 给它降级，降级成 H5 或者说是小程序。当假设我们这个页面没办法访问的时候，我们可以让用户先暂时地去访问 H5 页面或者说小程序页面。同样的，如果某个页面白屏很久，我们也可以通过降级，直接通过H5或小程序的方式兼容打开。
第二个：对于一些接口字段，老版本的兼容问题，我们也是能够去下发默认参数的方式。如果老版本它强制要求有某一个参数，那其实我们可以把这个参数给下发成一个默认参数。如果我们做了千人千面的话，那每一个用户都可以达到不同参数不同展示的效果。
第三个：新功能透传及时性。假设我们当前有某一个直播的页面，新版本已经有一个可以让用户打赏或者说是让用户发礼物这样的功能了。那老版本它还没有这样的一个功能的话，我们可以通过点击礼物图标后，修改落地页把它给他提示升级弹窗。这样的升级弹窗对用户是影响最小的，它只在使用到这个功能的时候才需要做某一些升级。
第四个意外事件处理：就是我前面讲到的云端大脑或端智能这样的应用场景了。

最后我们来看今天的第三部分，今年的情况大家都能感受，各种人员优化，大家都很忙，那如何将这种大的技术重构成本降到最低呢，我们为TheRouter开发了很多周边能力：

TheRouter提供了图形化界面的一键迁移工具，可以一键从其他路由迁移到TheRouter，整个迁移过程都是基于字符串匹配完成的，不涉及任何黑科技，所有的替换点也都会展示出来，非常安全。在替换完成后，自动输出改动页面与测试点，大幅减少了开发与测试的工作量。

还有一个用于自动跳转的高效IDE辅助插件，可以直接从路由的声明处查看到哪些地方跳转到本路由，再也不用怕路由字符串满天飞了。

只需要点一下左边的图标，就能自动跳转到落地页了。假设我们有多个跳转，跳转到同一个落地页的，点击落地页左侧的图标，也会展示出对应的代码，选择以后也可以自动跳转过去。

另外还有一个很好的特性，就是如果你写了没有落地页的跳转，会在IDE左侧有个黄色的警告，提示你是不是因为手抖或其他原因，写错了path。

另外TheRouter还提供了官网和微信群，官网有大量的技术文档和指导教程，有不懂的问题还可以加入微信群寻求帮助。

官网：https://therouter.cn

微信群：https://therouter.cn/wx/

总的来说，TheRouter 并不仅仅是一个小巧灵活的路由库，而是一整套完整的 Android 模块化解决方案，能够解决几乎全部的模块化过程中会遇到的问题。对于现有的路由框架，我们也在最大限度支持平滑迁移。你也可以在Github issue中提出需求，我们评估后会尽快支持，也欢迎任何人提供 Pull Requests。

张涛 - 没错，TheRouter 是我写的

2022-09-05

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/code/2022/09/05/01

没错，货拉拉开源的路由库 —— TheRouter 是我写的

大约在17年底到18年初的时候，我经常会讲一些当时做模块化开发的心得和踩坑历程。比如这几篇都是那时候写的：《Android 模块化平台设计》、《优雅移除模块间耦合》、《企业级 Android 模块化平台设计建议》。

但后来我慢慢不讲这些了，因为我发现做模块化，虽然我们能总结出来一套较为通用的解决方案，但很难通过几次短短的技术分享就跟别人讲清楚。并且很容易让人产生误解：我们是小公司，不需要做模块化。再加上因为当时是基于公司已有的基础建设，和制度的一些限制，并不能对外开源一套较为完善的模块化方案，开源一套完整的模块化方案这个种子就一直埋下了。

说回 TheRouter

这个名字，其实熟悉我的都知道，之前写过一个开源类 MVP 框架，叫TheMVP，基本上成为了一种将Activity看做 P 层架构的行业规范。后来被支付宝使用了，也在设置-关于-版权信息里面能查到，直到前几天我去反编译的时候，都还看到BaseActivity用的是我的代码。

The 代表了一种唯一性，表示有这个就够了。

TheRouter也是一样，我相信用过TheRouter以后你才会真正意识到，现在的企业级Android模块化应该怎么玩。

为什么要使用 TheRouter

路由是现如今 Android 开发中必不可少的功能，尤其是企业级APP，可以用于将Intent页面跳转的强依赖关系解耦，同时减少跨团队开发的互相依赖问题。

对于大型 APP 开发，基本都会选用模块化(或组件化)方式开发，对于模块间解耦要求更高。 TheRouter 是一整套完全面向模块化开发的解决方案，不仅能支持常规的模块依赖解耦、页面跳转，同时提供了模块化过程中常见问题的解决办法。例如：完美解决了模块化开发后组件内无法获取 Application 生命周期与业务流程，造成每次初始化与关联依赖调用都需要跨模块修改代码的问题。

不过为什么要用，说到底，还是用ARouter用的太头疼了。

一个是死板，所有路由都是写死的，但凡想灵活一点，把线上Crash的页面降级成H5临时解决，都得改一大堆代码还很多限制性。
另一个就是效率，不管是编译时长还是启动耗时，这俩问题都一直不解决。某个厂的开源项目都这样，作者们该晋升的晋升，该转岗的转岗，剩下的躺平不管，毕竟修修补补这事不占KPI，没法述职啊。没办法，自己来吧，谁让我们还有启动耗时指标的。
再就是遇到的一个坑，在用tinker下发补丁的时候，发现同一个分支打出来的包，ARouter和Butterknife的产物包代码都不一样，直接增大了补丁体积。
当然，还有很多差异，看这个表格吧。

功能	TheRouter	ARouter	WMRouter
Fragment路由	✔️	✔️	✔️
支持依赖注入	✔️	✔️	✔️
加载路由表	无运行时扫描无反射	运行时扫描dex 反射实例类性能损耗大	运行时读文件反射实例类性能损耗中
注解正则表达式	✔️	✖️	✔️
Activity指定拦截器	✔️（四大拦截器可根据业务定制）	✖️	✔️
导出路由文档	✔️（路由文档支持添加注释描述）	✔️	✖️
动态注册路由信息	✔️	✔️	✖️
APT支持增量编译	✔️	✔️（开启文档生成则无法增量编译）	✖️
plugin支持增量编译	✔️	✖️	✖️
多 Path 对应同一页面（低成本实现双端path统一）	✔️	✖️	✖️
远端路由表下发	✔️	✖️	✖️
支持单模块独立初始化	✔️	✖️	✖️
支持使用路由打开第三方库页面	✔️	✖️	✖️
对热修复支持（例如tinker）	✔️(未改变的代码多次构建无变动)	✖️(多次构建apt产物会发生变化，生成无意义补丁)	✖️(多次构建apt产物会发生变化，生成无意义补丁)

动态页面路由能力

其实单纯的页面路由，没什么好说的，基本上所有人都是这么做的。APT编译期生成一个描述类，gradle插件聚合所有的描述类，应用启动的时候再加载描述类，就这么一个流程。TheRouter 文档里面写的非常详细了，这里主要讲讲路由在现代APP中要怎么用。

TheRouter 从设计阶段，考虑的就是APP动态化能力。所以既能支持第三方SDK的路由跳转，也能支持插件化的开发形态，又能处理H5Hybrid、Flutter混合的这种项目，反正路由表都是可以随便添加。

那，真正用处最多的是通过动态下发，提升客户端容灾能力。
比如在线上，某些页面或者核心下单交易流程因为客户端开发疏忽，造成无法使用的情况，可以通过路由将对应页面降级为H5或者小程序，保证线上APP依然是可用的状态。

有两种推荐的远程下发方式可供使用方选择：

将打包系统与配置系统打通，每次新版本APP打包后自动将assets/目录中的配置文件上传到配置系统，下发给对应版本APP 。优点在于全自动不会出错。
配置系统无法打通，线上手动下发需要修改的路由项，因为 TheRouter 会自动用最新下发的路由项覆盖包内的路由项。优点在于精确，且流量资源占用小。

注：一旦你设置了自定义的InitTask，原框架内路由表初始化任务将不再执行，你需要自己处理找不到路由表时的兜底逻辑，一种建议的处理方式见如下代码。

// 此代码 必须 在 Application.super.onCreate() 之前调用
RouteMap.setInitTask(new RouterMapInitTask() {
    /** 
     * 此方法执行在异步
     */
    @Override
    public void asyncInitRouteMap() {
        // 此处为纯业务逻辑，每家公司远端配置方案可能都不一样
        // 不建议每次都请求网络，否则请求网络的过程中，路由表是空的，可能造成APP无法跳转页面
        // 最好是优先加载本地，然后开异步线程加载远端配置
        String json = Connfig.doHttp("routeMap");
        // 建议加一个判断，如果远端配置拉取失败，使用包内配置做兜底方案，否则可能造成路由表异常
        if (!TextUtils.isEmpty(json)) {
            List<RouteItem> list = new Gson().fromJson(json, new TypeToken<List<RouteItem>>() {
            }.getType());
            // 建议远端下发路由表差异部分，用远端包覆盖本地更合理
            RouteMap.addRouteMap(list);
        } else {
            // 在异步执行TheRouter内部兜底路由表
            initRouteMap()
        }
    }
});

另一种情况，如果某些页面传参过程中，漏传了一些固定参数，也可以通过动态下发路由表的方式，对不同的页面，做动态的默认参数注入，这样就能达到不发版也能直接修复某些参数引起的小问题。

TheRouter中下发路由表的格式：

[
  {
    "path": "https://kymjs.com/therouter/test",
    "className": "com.therouter.app.autoinit.TestActivity",
    "action": "",
    "description": "",
    "params": {
    	"key":"value"
    }
  },
  ......
]

单模块自动初始化能力

其实，做模块化最麻烦的两个点，第一个是依赖解耦，第二个应该就是独立模块的初始化问题了。再加上现在对于隐私合规问题越查越严，各种权限都必须在隐私弹窗授权以后才能使用，使得模块独立更难，动不动就得改到Application壳工程。

TheRouter 的单模块自动初始化能力就是为了解决这样的情况，可以只在当前模块声明初始化方法后，将会在业务场景时自动被调用。

类似于 Gradle 的 Task，你也可以声明自己的初始化 Task，然后声明的时候提供好需要依赖的其他 Task，这样只要依赖的那个 Task 没有初始化，你的任务就不会被初始化。直到依赖的那个 Task 初始化完成，你的任务才会被自动调用。

/**
 * 将会在异步执行
 */
@FlowTask(taskName = "mmkv_init", dependsOn = TheRouterFlowTask.APP_ONCREATE, async = true)
public static void test2(Context context) {
    System.out.println("异步=========Application onCreate后执行");
}

@FlowTask 注解参数说明：

taskName：当前初始化任务的任务名，必须全局唯一，建议格式为：moduleName_taskName
dependsOn：参考Gradle Task，任务与任务之间可能会有依赖关系。如果当前任务需要依赖其他任务先初始化，则在这里声明依赖的任务名。可以同时依赖多个任务，用英文逗号分隔，空格可选，会被过滤：dependsOn = “mmkv, config, login”，默认为空，应用启动就被调用
async：是否要在异步执行此任务，默认false。

内置初始化节点

使用这个能力，在路由内部默认支持了两个生命周期类任务，可在使用时直接引用

TheRouterFlowTask.APP_ONCREATE：当Application的onCreate()执行后初始化
TheRouterFlowTask.APP_ONSPLASH：当应用的首个Activity.onCreate()执行后初始化

同时，使用TheRouter的自动初始化依赖，也无需担心循环依赖造成的问题，框架会在编译期构建有向无环图，监测循环依赖情况，如果发现会在编译期直接报错，并且还会将发生循环引用的任务显示出来，用于排错。

动态化能力

还有一个，动态化能力。这个能力其实是需要整个项目公司的配合，比如有一套类似智慧大脑的方案，可以基于客户端过去的一些埋点数据，智能推断出用户下一步要做的事情，然后通过长连接直接向客户端下发指令做某些事情。

不过抛开后端的能力，单独靠客户端也是可以使用的。

Action 本质是一个全局的系统回调，主要用于预埋的一系列操作，例如：弹窗、上传日志、清理缓存。
与 Android 系统自带的广播通知类似，你可以在任何地方声明动作与处理方式。并且所有Action都是可以被跟踪的，只要你愿意，可以在日志中将所有的动作调用栈输出，以方便调试使用。

当用户执行某些操作（打开某个页面、H5点击某个按钮、动态页面配置的点击事件）时，将会自动触发，执行预埋的 Action 逻辑。

但还是强烈推荐，将端上数据与服务端链路打通，根据客户端不同的用户行为，交由后端分析，进而推测出用户下一步动作，提前执行下发逻辑交给客户端执行，则是一套完整的动态化方案。

模块化支持，Gradle脚本一键切换源码引用

在模块化开发过程中，如果没有采用分仓，或采用了分仓但依然使用 git-submodule 的方式开发，应该都会遇到一个问题。如果集成包采用源码编译，构建时间实在太久，大大降低开发调试效率；如果采用aar依赖编译，对于底层模块修改了代码，每次都要重新构建aar，在上层模块修改版本号以后，才能继续整包构建编译，也极大影响开发效率。
TheRouter 中提供了一个 Gradle 脚本，只需要在开发本地的local.properties文件中声明要参与编译的module，其他未声明的默认使用aar编译，这样就能灵活切换源码与aar，并且不会影响其他人，如下节选代码可供参考使用：

/**
 * 如果工程中有源码，则依赖源码，否则依赖aar
 */
def moduleApi(String compileStr, Closure configureClosure) {
    String[] temp = compileStr.split(":")
    String group = temp[0]
    String artifactid = temp[1]
    String version = temp[2]

    Set<String> includeModule = new HashSet<>()
    rootProject.getAllprojects().each {
        if (it != rootProject) includeModule.add(it.name)
    }

    if (includeModule.contains(artifactid)) {
        println(project.name + "源码依赖：===project(\":$artifactid\")")
        projects.project.dependencies.add("api", project(':' + artifactid), configureClosure)
//        projects.project.configurations { compile.exclude group: group, module: artifactid }
    } else {
        println(project.name + "依赖：=======$group:$artifactid:$version")
        projects.project.dependencies.add("api", "$group:$artifactid:$version", configureClosure)
    }
}

在实际使用时，可以完全使用moduleApi 替换掉原有的api。当然， implementation也可以有一个对应的moduleImplementation，这样只需要注释或解注释setting.gradle文件内的include语句就可以达到切换源码、aar的目的了。
具体的使用方法，可以看我这篇文章里面讲的【源码与aar互斥】的实现：https://xiaozhuanlan.com/topic/2735849061

什么年代了，还在用 ARouter?

支持从 ARouter 一键迁移！
没错，什么年代了，还在用ARouter？
对于这种已有的存量路由框架，当然也是提供了一键迁移的图形化工具。
为了写这个工具我也是废了好大的劲，特意学了一遍JavaFX怎么用，然后打了一个Mac产物、一个Windows产物。
不禁感叹：Java的跨平台才是真正的跨平台啊。

注：传到了GitHub，可能有点慢，耐心等待

Mac OS 迁移工具下载：https://github.com/HuolalaTech/hll-wp-therouter-android/wiki/uploads/file/TheRouterTransfer-Mac.zip
Windows 迁移工具下载：https://github.com/HuolalaTech/hll-wp-therouter-android/wiki/uploads/file/TheRouterTransfer-Windows.zip

张涛 - 货拉拉 Android 模块化路由框架：TheRouter

2022-09-04

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/code/2022/09/04/01

TheRouter 是一个 Kotlin 编写，用于 Android 模块化开发的一整套解决方案框架。
Github 项目地址与使用文档详见 https://github.com/HuolalaTech/hll-wp-therouter-android。

TheRouter 核心功能具备如下能力：

页面导航跳转能力(Navigator)
跨模块依赖注入能力(ServiceProvider)
单模块自动初始化能力(FlowTaskExecutor)
动态化能力(ActionManager)
模块AAR/源码依赖一键切换脚本

一、为什么要使用 TheRouter

路由是现如今移动端开发中必不可少的功能，尤其是企业级APP，可以用于将Intent页面跳转的强依赖关系解耦，同时减少跨团队开发的互相依赖问题。

对于大型 APP 开发，基本都会选用模块化(或组件化)方式开发，对于模块间解耦要求更高。 TheRouter 是一整套完全面向模块化开发的解决方案，不仅能支持常规的模块依赖解耦、页面跳转，同时提供了模块化过程中常见问题的解决办法。例如：完美解决了模块化开发后由于组件内无法获取 Application 生命周期与业务流程，造成每次初始化与关联依赖调用都需要跨模块修改代码的问题。

1.1 TheRouter 四大能力

Navigator：

支持 Activity 和 Fragment
支持Path与页面多对一关系或一对一关系，可用于解决多端path统一问题
页面Path支持正则表达式声明
支持 json 格式路由表导出
支持动态下发 json 路由表，降级任意页面为H5
支持任意object跨模块传递（无需序列化，且能保证对象类型）
支持页面跳转拦截处理
支持自定义页面参数解析方式（例如将json解析为对象）
支持使用路由跳转到第三方 SDK 中的Activity(Fragment)

ServiceProvider：

支持跨模块依赖注入
支持自定义注入项的创建规则，依赖注入可自定义参数
支持自定义服务拦截，单模块mock调试
支持注入对象缓存，多次注入只会new一次对象

FlowTaskExecutor：

支持单模块独立初始化
支持懒加载初始化
独立初始化允许多任务依赖(参考Gradle Task)
支持编译期循环引用检测
支持自定义业务初始化时机，可以用于解决隐私合规问题

ActionManager：

支持全局回调配置
支持优先级响应与中断响应
支持记录调用路径，解决调试期观察者模式无法追踪Observable的问题

注： FlowTaskExecutor、ActionManager 后续会作为可选能力，提供可插拔或单独使用的选项（预计10月份提供）。

二、路由方案

目前现有的路由基本上集中于两种能力的实现：页面跳转、跨模块调用，核心技术方案大体上如图：

开发阶段，对要使用路由的落地页或被调用方法添加注解标识。
编译期解析注解，生成一系列中间代码，待调用。
应用启动后调用中间代码完成路由的准备动作。大部分路由会额外通过 Gradle Transform，在编译期做一次聚合，以提升运行时准备路由表的效率。
发起路由跳转时，本质上就是一次路由表遍历，通过uri获取到对应的落地页或方法对象，进行调用。

TheRouter 的页面跳转、跨模块调用也是如此，但是在设计上会有一些细节处理。

TheRouter 会在编译期根据注解生成 RouteMap__开头的类，这些类中记录了当前模块的所有路由信息，也就是当前模块的路由表。

在最顶层的app模块中，通过Gradle插件，将所有aar、源码中的RouteMap__开头的类统一集中到TheRouterServiceProvideInjecter类中。

后续应用启动后，初始化路由时只需要执行TheRouterServiceProvideInjecter类的方法，就能没有任何反射的加载到全部的路由表了。

三、使用 TheRouter 页面跳转

3.1 声明路由项

如果一个页面（支持 Activity、Fragment）允许被路由打开，则需要使用注解 @Route 声明路由项，每个页面允许声明多个路由项，也就是一对多的能力，极大降低多端路由统一时的业务影响面。

参数释义

path: 路由path 【必传】。
建议是一个url。path内支持使用正则表达式（为了匹配效率，正则必须包含反双斜杠\），允许多个path对应同一个Activity(Fragment)。
action: 自定义事件【可选】。
一般用来打开目标页面后做一个执行动作，例如自定义页面弹出广告弹窗。
description: 页面描述【可选】。
会被记录到路由表中，方便后期排查的时候知道每个path或Activity是什么业务。
params: 页面参数【可选】。
自动写入intent中，允许写在路由表中动态下发修改默认值，或通过路由跳转时代码传入。

 @Route(path = "http://therouter.com/home", action = "action://scheme.com",
        description = "第二个页面", params = {"hello", "world"})
public class HomeActivity extends AppCompatActivity {
}

3.2 发起页面跳转

传入的参数可以是 String 和8种基本数据类型、也可以是Bundle、Serializable、 Parcelable对象，跟 Intent 传值规则一致。
同时也支持为本次跳转的 Intent 添加Flag/Uri/ClipData/identifier等业务特殊参数。

// 传入参数可以通过注解 @Autowired 解析成任意类型，如果是对象建议传json
// context 参数如果不传或传 null，会自动使用 application 替换
TheRouter.build("http://therouter.com/home")
        .withInt("key1", 12345678)
        .withString("key2", "参数")
        .withBoolean("key3", false)
        .withSerializable("key4", object)
        .withObject("object", any) // 这个方法可以传递任意对象，但是接收的地方对象类型需自行保证一致，否则会强转异常
        .navigation(context);

        // 如果传入 requestCode，默认使用startActivityForResult启动Activity
        .navigation(context, 123);

        // 如果要打开的是fragment，需要使用
        .createFragment();

3.3 路由表生成规则

如果两条路由的path、目标className完全相同，则认为是同一条路由，不会考虑参数是否相同。
路由表生成规则：编译期按照如下顺序取并集。

覆盖规则：
根据如下顺序，如果相同，后者可以覆盖前者的路由表规则。

编译期解析注解生成路由表
首先取 业务模块 aar 中的路由表
再取主app module 代码中的路由表
最后取 assets/RouteMap.json 文件中声明的路由表。
- 如果编译期没有这个文件，会生成一份默认路由表放在这个目录内；如果有，会将路由表合并。
- 路由表生成时可配置是否启用检查路由合法性，判断目标页面是否存在，(warning/error)级别。
运行时线上动态下发的路由表
- 路由表允许线上动态下发，将覆盖本地路由表，详见【3.4 动态路由表的设计与使用】

如果编译期没有这个文件，会生成一份默认路由表放在这个目录内；如果有，会将路由表合并，因此，对于没办法修改代码的第三方SDK内部，如果希望通过路由打开，只需要手动在RouteMap.json文件中声明，就能通过路由打开了。

3.4 动态路由表的设计与使用

TheRouter 的路由表是动态添加的，项目每次编译后，会在 apk 内生成一份当前 APP 的全量路由表，默认路径为：/assets/therouter/routeMap.json。这个路由表也可以后续通过远程下发的方式使用，例如远端可以针对不同的APP版本，下发不同的路由表达到配置目的。这样如果将来线上某些页面发生Crash，可以通过将这个页面的落地页替换为H5的方式，临时解决这类问题。

有两种推荐的远程下发方式可供使用方选择：

将打包系统与配置系统打通，每次新版本APP打包后自动将assets/目录中的配置文件上传到配置系统，下发给对应版本APP 。优点在于全自动不会出错。
配置系统无法打通，线上手动下发需要修改的路由项，因为 TheRouter 会自动用最新下发的路由项覆盖包内的路由项。优点在于精确，且流量资源占用小。

// 此代码 必须 在 Application.super.onCreate() 之前调用
RouteMap.setInitTask(new RouterMapInitTask() {
    /** 
     * 此方法执行在异步
     */
    @Override
    public void asyncInitRouteMap() {
        // 此处为纯业务逻辑，每家公司远端配置方案可能都不一样
        // 不建议每次都请求网络，否则请求网络的过程中，路由表是空的，可能造成APP无法跳转页面
        // 最好是优先加载本地，然后开异步线程加载远端配置
        String json = Connfig.doHttp("routeMap");
        // 建议加一个判断，如果远端配置拉取失败，使用包内配置做兜底方案，否则可能造成路由表异常
        if (!TextUtils.isEmpty(json)) {
            List<RouteItem> list = new Gson().fromJson(json, new TypeToken<List<RouteItem>>() {
            }.getType());
            // 建议远端下发路由表差异部分，用远端包覆盖本地更合理
            RouteMap.addRouteMap(list);
        } else {
            // 在异步执行TheRouter内部兜底路由表
            initRouteMap()
        }
    }
});

3.5 高级用法

TheRouter同时支持更多页面跳转能力，详情可参考项目文档【https://github.com/HuolalaTech/hll-wp-therouter-android/wiki/Navigator】：

为第三方库里面的页面添加路由表，达到对某些页面降级替换的目的；
延迟路由跳转（从Android 8开始，不能在后台启动页面）；
跳转过程拦截器（总共四层，可根据实际需求使用）；
跳转结果回调；

四、跨模块依赖注入 ServiceProvider 的设计

对于模块化开发中跨模块的调用，我们推荐采用 SOA(面向服务架构) 的设计方式，服务调用方与使用方完全隔离，调用模块外的能力不需要关注能力的提供者是谁。
ServiceProvider 的核心设计思想也是这样的，目前服务间的调用协议采用接口的方式。当然，也可以兼容不通过接口下沉而是直接调用的情况。

具体到 Android 侧就是 AIDL 类似的设计，只是要比AIDL开发简单很多：

服务提供方负责提供服务，不需要关心调用方是谁会在何时调用自己。
服务的使用方只关注服务本身，不需要关心这个服务是谁提供的，只需要只能服务能提供哪些能力即可。

例如上面的图片：拉拉需要使用录音的服务，小货则向外提供一个录音的服务，由TheRouter的ServiceProvider负责撮合。

4.1 服务使用方：拉拉

她无需关心，IRecordService这个接口服务是谁提供的，他只需要知道自己需要使用这样的一个服务就行了。
注：如果没有提供服务的提供方，TheRouter.get()可能返回null

TheRouter.get(IRecordService::class.java)?.doRecord()

4.2 服务提供方：小货

服务提供方需要声明一个提供服务的方法，用@ServiceProvider注解标记。

如果是 java，必须是 public static 修饰
如果是 kotlin，建议写成 top level 的函数
方法名不限

/**
 * 方法名不限定，任意名字都行
 * 返回值必须是服务接口名，如果是实现了服务的子类，需要加上returnType限定（例如下面代码）
 * 方法必须加上 public static 修饰，否则编译期就会报错
 */
@ServiceProvider
public static IRecordService test() {
    return new IRecordService() {
        @Override
        public void doRecord() {
            String str = "执行录制逻辑";
        }
    };
}

// 也可以直接返回对象，然后标注这个方法的服名是什么
@ServiceProvider(returnType = IRecordService.class)
public static RecordServiceImpl test() {
    // xxx 
}

五、单模块自动初始化能力 FlowTaskExecutor 的设计

前面讲过，TheRouter是完全面向模块化开发提供的一套解决方案。在模块化开发时，可能每个模块都有自己需要初始化的一些代码。以前的做法是把这些代码都在Application里声明，但是这样可能随着业务变动每次都需要修改Application所在模块。TheRouter 的单模块自动初始化能力就是为了解决这样的情况，可以只在当前模块声明初始化方法后，将会在业务场景时自动被调用。

5.1 FlowTaskExecutor 使用介绍

可以在当前模块中，任意类中声明一个任意方法名的方法，给方法添加上@FlowTask 的注解即可。

@FlowTask 注解参数说明：

taskName：当前初始化任务的任务名，必须全局唯一，建议格式为：moduleName_taskName
dependsOn：参考Gradle Task，任务与任务之间可能会有依赖关系。如果当前任务需要依赖其他任务先初始化，则在这里声明依赖的任务名。可以同时依赖多个任务，用英文逗号分隔，空格可选，会被过滤：dependsOn = “mmkv, config, login”，默认为空，应用启动就被调用
async：是否要在异步执行此任务，默认false。

/**
 * 将会在异步执行
 */
@FlowTask(taskName = "mmkv_init", dependsOn = TheRouterFlowTask.APP_ONCREATE, async = true)
public static void test2(Context context) {
    System.out.println("异步=========Application onCreate后执行");
}

@FlowTask(taskName = "app1")
public static void test3(Context context) {
    System.out.println("main线程=========应用启动就会执行");
}

/**
 * 将会在主线程初始化
 */
@FlowTask(taskName = "test", dependsOn = "mmkv,app1")
public static void test3(Context context) {
    System.out.println("main线程=========在app1和mmkv两个任务都执行以后才会被执行");
}

5.2内置初始化节点

使用这个能力，在路由内部默认支持了两个生命周期类任务，可在使用时直接引用

TheRouterFlowTask.APP_ONCREATE：当Application的onCreate()执行后初始化
TheRouterFlowTask.APP_ONSPLASH：当应用的首个Activity.onCreate()执行后初始化

5.3 实现原理

每次应用启动后，会在路由初始化时，将有向图中的全部Task，按照依赖关系按顺序加载。

六、动态化能力 ActionManager 的设计

Action 本质是一个全局的系统回调，主要用于预埋的一系列操作，例如：弹窗、上传日志、清理缓存。
与 Android 系统自带的广播通知类似，你可以在任何地方声明动作与处理方式。并且所有Action都是可以被跟踪的，只要你愿意，可以在日志中将所有的动作调用栈输出，以方便调试使用，这样在一定程度上可以解决观察者模式带来的通病：无法追踪Observable的问题。

6.1 Action 使用

声明一个 Action：

// action建议遵循一定的格式
const val ACTION = "therouter://action/xxx"

@FlowTask(taskName="action_demo")
fun init(context: Context) =
    TheRouter.addActionInterceptor(ACTION, object: ActionInterceptor() {
        override fun handle(context: Context, args: Bundle): Boolean {
            // do something
            return false
        }
    })

执行一个 Action：

// action建议遵循一定的格式
const val ACTION = "therouter://action/xxx"

// 如果执行了一个没有被声明的Action，则不会有任何动作
TheRouter.build(ACTION).action()

6.2 高级用法

每个Action 允许关联多个 ActionInterceptor进行处理，多个ActionInterceptor之间可以自定义拦截器优先级，同时允许终止接下来的低优先级拦截器的执行。

最典型应用场景：首页可能会有多个弹窗，不同业务之间的弹窗是有优先级之分的，为了体验优化我们肯定不会在首页一次把所有弹窗全部弹出，可以通过ActionInterceptor为每个弹窗声明好优先级关系，假设需求是首页只能弹出3个弹窗，那么第三个弹窗处理完毕即可关闭当前事件，接下来的拦截器将不会被响应。

abstract class ActionInterceptor {

    abstract fun handle(context: Context, args: Bundle): Boolean

    fun onFinish() {}

    /**
     * 数字越大，优先级越高
     */
    open val priority: Int
        get() = 5
}

6.3 客户端动态响应使用场景

如果仅客户端使用，常用的场景可能是：当用户执行某些操作（打开某个页面、H5点击某个按钮、动态页面配置的点击事件）时，将会自动触发，执行预埋的 Action 逻辑。

如果与服务端链路打通，这个能力其实是需要整个公司的配合，比如有一套类似智慧大脑的方案，可以基于客户端过去的一些埋点数据，智能推断出用户下一步要做的事情，然后通过长连接直接向客户端下发指令做某些事情。那么通过客户端预埋的页面跳转、弹窗、清缓存、退出登录等等操作，就可以通过服务端指令进行操作，则就是一套完整的动态化方案。

七、一键切换源码与 AAR

7.1 模块化支持的 Gradle 脚本

在模块化开发过程中，如果没有采用分仓，或采用了分仓但依然使用 git-submodule 的方式开发，应该都会遇到一个问题。如果集成包采用源码编译，构建时间实在太久，大大降低开发调试效率；如果采用aar依赖编译，对于底层模块修改了代码，每次都要重新构建aar，在上层模块修改版本号以后，才能继续整包构建编译，也极大影响开发效率。
TheRouter 中提供了一个 Gradle 脚本，只需要在开发本地的local.properties文件中声明要参与编译的module，其他未声明的默认使用aar编译，这样就能灵活切换源码与aar，并且不会影响其他人，如下节选代码可供参考使用：

/**
 * 如果工程中有源码，则依赖源码，否则依赖aar
 */
def moduleApi(String compileStr, Closure configureClosure) {
    String[] temp = compileStr.split(":")
    String group = temp[0]
    String artifactid = temp[1]
    String version = temp[2]

    Set<String> includeModule = new HashSet<>()
    rootProject.getAllprojects().each {
        if (it != rootProject) includeModule.add(it.name)
    }

    if (includeModule.contains(artifactid)) {
        println(project.name + "源码依赖：===project(\":$artifactid\")")
        projects.project.dependencies.add("api", project(':' + artifactid), configureClosure)
//        projects.project.configurations { compile.exclude group: group, module: artifactid }
    } else {
        println(project.name + "依赖：=======$group:$artifactid:$version")
        projects.project.dependencies.add("api", "$group:$artifactid:$version", configureClosure)
    }
}

在实际使用时，可以完全使用moduleApi 替换掉原有的api。当然， implementation也可以有一个对应的moduleImplementation，这样只需要注释或解注释setting.gradle文件内的include语句就可以达到切换源码、aar的目的了。

八、从其他路由迁移至 TheRouter

8.1 迁移工具一键迁移

TheRouter提供了图形化界面的迁移工具，可以一键从其他路由迁移到TheRouter，目前仅支持ARouter，其他路由框架迁移也在开发中：

Mac OS 迁移工具下载：https://github.com/HuolalaTech/hll-wp-therouter-android/wiki/uploads/file/TheRouterTransfer-Mac.zip
Windows 迁移工具下载：https://github.com/HuolalaTech/hll-wp-therouter-android/wiki/uploads/file/TheRouterTransfer-Windows.zip

如果项目中使用了ARouter的IProvider.init()方法，可能需要手动处理初始化逻辑。
如下图：

8.2 与其他路由对比

功能	TheRouter	ARouter	WMRouter
Fragment路由	✔️	✔️	✔️
支持依赖注入	✔️	✔️	✔️
加载路由表	无运行时扫描无反射	运行时扫描dex 反射实例类性能损耗大	运行时读文件反射实例类性能损耗中
注解正则表达式	✔️	✖️	✔️
Activity指定拦截器	✔️（四大拦截器可根据业务定制）	✖️	✔️
导出路由文档	✔️（路由文档支持添加注释描述）	✔️	✖️
动态注册路由信息	✔️	✔️	✖️
APT支持增量编译	✔️	✔️（开启文档生成则无法增量编译）	✖️
plugin支持增量编译	✔️	✖️	✖️
多 Path 对应同一页面（低成本实现双端path统一）	✔️	✖️	✖️
远端路由表下发	✔️	✖️	✖️
支持单模块独立初始化	✔️	✖️	✖️
支持使用路由打开第三方库页面	✔️	✖️	✖️
支持使用路由打开第三方库页面	✔️	✖️	✖️
对热修复支持（例如tinker）	✔️(未改变的代码多次构建无变动)	✖️(多次构建apt产物会发生变化，生成无意义补丁)	✖️(多次构建apt产物会发生变化，生成无意义补丁)

九、总结

TheRouter 并不仅仅是一个小巧灵活的路由库，而是一整套完整的 Android 模块化解决方案，能够解决几乎全部的模块化过程中会遇到的问题。
对于现有的路由框架，我们也在最大限度支持平滑迁移，目前已完成ARouter的一键迁移工具，其他框架的迁移仍在开发中。你也可以在Github issue中提出需求，我们评估后会尽快支持，也欢迎任何人提供 Pull Requests。

加入微信群沟通交流：

张涛 - 菲律宾这国家到底怎么回事

2022-05-11

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/history/2022/05/11/01

另一件事意义也挺大的：菲律宾总统大选。
根据选举委员会提供给媒体的服务器的初步统计数据，截至5月10日凌晨2时47分，总统候选人小费迪南德·马科斯以 29446813票大幅领先，在投票中胜出。
不过菲律宾人不靠谱，公告没出咱都别信。它曾经有过1天就出选举初步结果的，也曾有过3周之后才出结果的，3周出的那次，就是现任总统杜特尔特当年参选时。

投票前一天，马科斯阵营显示团结

菲律宾到底是个什么国家

这件事的意义也是挺大的。
甚至可以这么说，一点都不亚于普京宣称要挑战美国为主导的世界秩序。
为什么这么说呢？要从菲律宾这个国家说起。

菲律宾本身不是个特别大的国家：国土面积不到30万平方公里，但它老百姓挺能生的，人口倒是有1.2亿了。经济也很一般般：2021年GDP为3900多亿美元，人均3570美元。比前段时间很多自媒体猛吹的越南，人均其实还要稍强一些。但和中国，就不好比了。

这个国家的军力，也不强，简单这么说：它的全部海军，战力可能不如一艘052D导弹驱逐舰；它的全部陆军，可能打不过我们一个师；空军也没啥好飞机。
那么为什么说它这次总统大选意义重大呢？
这和它的历史有关。

菲律宾这个国家的过往和现在，简单来说，就是这三句话：

两次殖民；
两个大岛；
一场动荡。

两次殖民

菲律宾这个国家，离我们虽然近，我们也一直知道它，却没对它做什么。这主要是与亚洲盛行季风有关。
菲律宾的历史，主要和西班牙有关。

1521年，麦哲伦搞人类首次环球航海时，发现了它，当时麦哲伦比较粗暴，想直接在当地搞征服，结果被打死了，是的麦哲伦环球旅行的终点就是菲律宾。麦哲伦死了以后，他的同伙逃跑了，一路航行，跑回欧洲老家，完成整个航行。
所以我们看不少地图，会发现标有麦哲伦环球航行线路的，分成了两段：一段是麦哲伦自己航行的；从菲律宾到欧洲那一段，是他的同伙航行的。

这样，有菲律宾这么个地方，就被西班牙人知道了。
1565年，西班牙人吸取教训后，传播宗教加武力征服，软硬两手一起来，在几十年间，就基本搞定了吕宋岛和上千个大大小小的岛屿。
当时西班牙国王名字叫菲利普，“菲律宾”这国名就这么来的。
这是菲律宾第一次被殖民。

然后到了1898年。美国那时候强大起来了，当时中国虽然屡遭侵略，但要论GDP，还是世界第一大国。
美国人很想在附近找个地盘，和中国做贸易。
当时西班牙已经很弱了，所以美国人就黑吃黑，对西班牙人下手。
当时有艘美国军舰，名字叫“缅因号”，停在现在古巴首都哈瓦那的港口，当时古巴还是西班牙的殖民地，这艘军舰突然爆炸，然后沉了。

它为啥爆炸，现在还说不清楚。
很多人觉得是美国人自己干的。
因为它后来有太多这样自导自演，然后栽赃给他国的例子。
但美国说：这是西班牙人干的。
然后两家开战。

战争一开，基本就是一边倒，西班牙人根本没还手之力。
当时主要有两个战场，一个是古巴，当时全世界最大的蔗糖产地；一个是菲律宾。
两家打仗的时候，美国对菲律宾人许诺，让他们赶紧起义，赶走西班牙人，还说战后让菲律宾独立。等美国人打败古巴人，它就说话不算数了，说菲律宾还得乖乖做殖民地。菲律宾人觉得受骗了，为了独立，就和美国人打仗。

这场仗打了3年。
战争非常残酷：美国人差不多把所有城市夷为平地，还到处袭击村庄，见到村民就杀掉，大家结下了血仇。
美国人自己统计说，有25万到27万菲律宾老百姓被杀，2万菲律宾士兵被杀。当时菲律宾总人口也就400多万，差不多13个人中，就有1个被杀。

所以，菲律宾就这么两次被殖民了。一次被西班牙，一次被美国。

这两次殖民产生了什么后果呢？
先说第一次。

西班牙离菲律宾非常远，所以能到这地方的白人就少。但西班牙人有办法。他们疯狂和当地部落首领通婚，建立亲属关系，在菲律宾社会中搞出一大群有西班牙血统的人；西班牙还大力推广天主教，信教和帮着他们传教的当地人，也获得了不低的社会地位。

西班牙人再给这些人授土地和老百姓。顿时就在菲律宾制造出一个大地主阶层出来。
西班牙统治菲律宾300多年，这些当初跟着它混的人，就这么繁衍了十几代，这么一代代地繁衍下来，加上之间通婚，就形成一个个大家族。
这些家族的利益，是和西班牙捆绑在一起的。

这也是现代职场空降以后最有效的管理手段，打压一批人，再拉拢一批人，让这批人跟自己有共同利益，同时分给他们一些甜头，接下来他们为了维护自己的甜头，自然就会拼死跟你站在同一阵营了。

后来美国人来了。
这些家族当然就拼命反抗，美国人非常不客气，到处杀人，把那些最激烈抵抗它的家族要么杀光，要么搞得跌落到社会最底层。
当然，不少西班牙人时期的老牌家族一看：美国人太猛了，和它对干没好果子吃！就和美国人合作了，这些家族就这么保留下来了。
但光靠这些倒戈的家族，美国人还不能统治菲律宾。
所以它也得扶植一批。

正好，菲律宾还确实有这么一批人。
这事要从明朝说起，哥伦布不是发现了美洲大陆了吗？
西班牙就去殖民，搞到了很多白银，尤其是秘鲁，那白银产量非常不得了。西班牙人就从南美洲，穿过太平洋，用大帆船把白银拉到菲律宾的马尼拉。

中国沿海的商人，看到银子，积极性非常高，纷纷驾船，装着各种货物，像丝绸、瓷器、茶叶什么的，赶到马尼拉，去和西班牙人交易。
那些货品，是当时的古驰、LV，非常抢手。这些船的目的地是马尼拉，所以有个专用名词，叫“马尼拉大帆船”。

“马尼拉大帆船”航行路线

后来有个统计，说西班牙人从南美洲搞到的银子，大约二分之一到三分之二，就这么流入了中国。

我们在古装电视剧里，老是看到某某人进了酒店，扔出一块银子，对店小二喊道：打五斤酒，整一桌好菜，剩下的就不要找了。

其实这是在西班牙发现新大陆，搞来大批银子之后才有的事。之前中国没那么多银子。

大家哪怕上馆子吃饭或者做一些交易，一般用铜钱，或者用纸钞。阔气得到处扔银子，其实只是近四、五百年的事。

但这么一贸易，事情就来了：慢慢地，菲律宾有了很多华人后裔。
这是怎么一回事呢？怪老天爷！！！

古代船要在大海航行，主要靠风，亚洲季风。
从我们这里坐船去菲律宾，方向是从西北往东南，得靠西北风。
但老天爷和古人作对。广东、福建、台湾以北，二月吹的是西北风，但过了台湾后，季风突然转成往东南方向吹的，对中国古代的船来说，沿越南海岸线走，顺风顺水，往菲律宾方向走，既不顺风也不顺水。

这就是为啥菲律宾明明离我们不远，古代中国人不大去的原因。

两个大岛

但后来有银子赚，情况就不一样了嘛！
幸好每年冬季，总是有那么一段时间，哪怕过了台湾，风也是朝东南方向吹的。于是人们就纷纷驾船出海。
赶到马尼拉后，东西虽然卖掉了，但风向不对。大家就只能在那里呆着，找个地方住下，每天喝酒吃饭，等到六七月，夏季季风来了，再乘着顺风船回国。

古代航海的，都是男人。远离家乡那么长时间，既空虚又寂寞还无聊，加上身边没家眷，还赚了这么多钱，时间慢慢长了，菲律宾就冒出了一大堆华人后裔。
再后来呢，就有人不回去了，慢慢定居下来。

1901年，美国人做了个统计，发现至少三分之一的菲律宾人有中国血统，比有西班牙人血统的要多很多。所以东南亚有些国家排华，但菲律宾从来就没排华这种事。
因为整个国家的老百姓，几乎都沾点华人血统，怎么排？

中国人勤劳能干，善于经商，很多人就成了当地的大富翁，在西班牙人统治时，就有一些和那些老牌家族联姻，加入了大家族的行列。但毕竟不多。
美国人从西班牙手里抢到菲律宾后，就大力扶植当地的华人富豪，于是又形成了一波大家族。
那么，这些家族都在哪里呢？看到菲律宾的地图。

菲律宾是个群岛国家，这个国家简单来说，就是南边有个大岛，北边也有个大岛，中间好像被谁狠狠地踹了一脚，全碎了，所以是一大堆零零星星的小岛。

南边那个大岛，叫棉兰老岛，是菲律宾第一大岛。
北边那个大岛，叫吕宋岛，是第二大岛。
中间那一大堆被踹碎了的岛屿群，叫作米沙鄢群岛。

虽然吕宋岛是第二大岛，但在很长一段时间，它是菲律宾整个国家的核心。
为什么呢？原因很简单：它离中国近。
我在上面说过，西班牙殖民菲律宾后，主要在做什么事？和我们做生意。
美国人为什么要从西班牙人手里抢菲律宾？也是为和我们做生意，有个立足点。

既然菲律宾这个国家之所以被殖民，之所以存在的目的，绝大部分时候，都是为了和我们做生意。俗话说：近水楼台先得月。有钱有势的大家族，都聚集在离我们最近的吕宋岛，也就顺理成章了。

说到这里，有小伙伴应该能看出来了：美国这个国家，虽然天天民主、自由喊得震天响，其实和其他西方国家一样，也是很善于控制被它殖民的国家的。
既然菲律宾当过它的殖民地，当然会和它产生千丝万缕的联系，一般不可能轻易逃脱。按照一般逻辑，本来应该是这样。
但在美国统治菲律宾时，偏偏发生了一件事。

1941年12月，日本偷袭珍珠港，太平洋战争爆发。
在日本偷袭珍珠港时，日军也大举南下，分兵多路，占领东南亚。
菲律宾是美国殖民地，日本人当然不会放过，其中一路就直指菲律宾。当时麦克阿瑟正在菲律宾担任美国远东军司令部司令，他抵抗了一段时间后，就丢下7.5万名部下，逃之夭夭。

菲律宾这些家族，早就成墙头草了。
谁有奶谁就是娘，它们立即和日本人合作。
但有个小家族，坚决地不和日本人合作，还打起了游击战，在那种“疾风知劲草”的战争年代，着实让美国人刮目相看了一把。
这个家族，就是5月这次大选的主角：马科斯家族。

马科斯家族的来源，非常神秘。
很早时，泰国曾经拍过一个片子，叫《晚娘》（这片子国内不能正常看，别想了，给你们一个链接）。
大致意思是：有个权贵家族的女儿，因为被人掳走，被坏人强暴之后，怀孕了，为了遮羞，招了个普通人做丈夫。而她丈夫，因为贪图权贵家族的钱财，“喜当爹”，也就认了。

马科斯家族

Marcos：马科斯家族(不是马尔科，也不是马克思Marx，我刚看的时候一直想着海贼的马尔科)，据说就源于这样的一次“喜当爹”。

1917年，有个已经怀孕的女孩子，和一个男孩子结婚了。
菲律宾比较开放，这种情况比较正常。男方叫马里亚诺·马科斯，爷爷是个西班牙法官的私生子，但家庭没啥社会地位；女方叫何塞法，祖先是中国人和西班牙人混血，父母亲开杂货铺的。
没多久，孩子生下了，名字叫费迪南德·马科斯。但奇怪的事发生了：

这孩子刚生下没多久，就被当地一个纯华人血统的富豪家族蔡家，认作教子。
自从这次结婚之后，马里亚诺·马科斯就开始从政，此后基本上是青云直上，当过北依罗戈省省长，还去参选过参议员。

在菲律宾，这两件事能干成，都是不简单。

当地社会等级森严，普通人家的孩子根本没机会和豪门套上什么交情。
同样的原因，普通人想从政，根本难如上青天。

后来大家才知道真相：原来孩子真正父亲，名字叫名叫费迪南德·蔡，是这个蔡家的大少爷，蔡少爷和何塞法混了一场后，怀孕了。

但当时纯华人血统的家族，都会要自家孩子去福建故乡娶老婆，否则就没法当地华人大家族圈里混，所以他父母坚决反对。
所以只能找马里亚诺·马科斯。正好，马里亚诺·马科斯是个要求上进的好青年，就提出了自己的条件，蔡家也同意帮忙。各取所需。这张图就是这个私生子费迪南德·马科斯 ，是不是长得一点都不像菲律宾人，反倒像中国人？

对这孩子，喜当爹的老马科斯显然一点都不喜欢，也不怎么照看他，就任他自生自灭。
所以费迪南德·马科斯从小就在他外公的杂货铺里，和当地小孩厮混。
但这个假爸爸，费迪南德·马科斯却很有感情。
马里亚诺有次竞选众议员败了，他很生气。
他的对手叫纳沦达桑，马里亚诺就说他贿选；纳沦达桑也不客气，直接叫人抬了口棺材上街，上面写一行大字：这是马里亚诺的棺材。

3天之后，纳沦达桑吃完晚饭，在洗脸池漱口刷牙时，突然“砰”的一声枪响，纳沦达桑中枪身亡。3年以后，警察逮捕了小马科斯，承认就是他杀了纳沦达桑。
之后神奇的事发生了：对费迪南德·马科斯为父报仇这件事，菲律宾各大媒体纷纷报道，对他大加赞扬，说他是个了不起的孩子。

还有更神奇的事：
案子还没判，最高法院就准许他交保出狱；
他自己都没申请，菲律宾总统就宣布赦免他；
更牛逼的是，他在监狱里通过律师资格考试，都成了大新闻。
背后的原因，大家都能猜到的：蔡家在后面使了很大的劲。

这件事还带来另一个意想不到的结果：马里亚诺对这儿子也产生了感情。
虽然不是亲生的，却干了亲生儿子不见得能干到的事。
其实马里亚诺自己也挺努力的，在政坛也闯荡出了一点名头出来，所以等这件事平息后，他的政治衣钵就传给了马科斯。
但才到第二代，离成为一个家族，还远远不够。
关键时刻，日本人来了。不得不说，亚洲近现代史里面，每次大变动都跟小日子过的不错的日本人有关。

日本轰炸珍珠港

马科斯对美国人挺忠诚的，当时他参加了美军，结果美军战败，他被俘虏。但他虽说名义上的爸爸是参议员什么的，却不像那些大家族的公子哥们，因为马里亚诺根本就不管他，所以从来没娇生惯养过，因此眼快脚快，乘着日本人一个不注意，就逃走了。
逃走之后，他也不闲着，找人拉了一支队伍，和日本人打起了游击战。
这就不得了。
对美国人来说，能拉队伍，能和日本人打游击战，这就是块试金石啊。

后来美军打回菲律宾。
对在关键时刻，菲律宾能出这么一号人物，麦克阿瑟极其地欣赏，1945年任命马科斯为吕宋岛北部八省的行政官。
马科斯一下子变得有钱有粮有地盘。
枪杆子里出政权，这是颠扑不破的真理。
后来菲律宾独立，但经历过这么一次成功地站队后，马科斯虽说是第二代，但作为一个家族，他是完全够格了，所以之后一帆风顺：1959 年任参议员，1962年任参议院议长，1965年当选为总统。
马科斯家族就此崛起。

但美国人不乐意了。
我之前说过：美国人向来讨厌这种自己手头有枪杆子，又有地盘的人。
美国人喜欢搞民主，把一个国家分成好几派，让大家斗得你死我活，谁想占优势，就得跑去美国人那里磕头，是多么爽的一件事？
自己手头有枪杆子，又有地盘的人，基本上会自家一个人说了算。
美国当时在搞冷战啊，这种能自己说了算的国家，美国得花钱去拉拢啊，要不然就会被苏联或者什么别的国家拉去了。
自家养的鹰，翅膀硬了，也会飞的。

马科斯夫人伊梅尔达带着儿子小马科斯（就是身穿白衣那位少年，这次菲律宾总统大选胜选者）访华

从表面上看，马科斯每次去美国，总能搞到大笔大笔的钱。
当众演讲时，马科斯的夫人伊梅尔达也公开说：菲律宾是美国的小儿子。
但美国人心里还是极其不爽。和美国人一样不爽的，还有吕宋岛的大家族们。
家族政治嘛，就要讲平衡，但马科斯家族实在太强大了。
所以，1955年，菲律宾举行一场世纪婚礼：阿基诺家族的公子和许寰哥家族的大小姐结婚。
菲律宾最顶级的三个家族就此结盟：许寰哥、阿基诺、苏木隆。

三大家族

阿基诺家族，本来是当地部落首领，后来投靠西班牙人，得到了打拉省的大片土地，这个省几乎全是平原，是菲律宾最重要的农业省。
美国人到时，阿基诺家族又跟了美国人，再上一层楼。
许寰哥家族，最早的祖先名叫许尚志，福建人，年轻时因生活所迫到菲律宾闯天下，到菲律宾后，他改名为许玉寰。
因为他人勤劳，由精明能干，善于经营，在打拉省买下大批田产，成了这个省的首富。大家都叫他许寰哥，他的后人登记时，就把“许寰哥”当姓。
苏木隆家族和阿基诺家族经历类似：也是西班牙人时期就有的，美国人来时又投靠了美国人，从而跃升为顶级家族。

这三个家族，出过好几位菲律宾参议院议长，至于议员，那更是无数。
许寰哥家族的这位大小姐，她的舅家是苏木隆家族。
很多人都说：阿基诺家这位大公子，将来迟早是菲律宾总统。
但历史和他开了个很大的玩笑，他没当成。因为有马科斯在。

1972年，马科斯宣布戒严，阿基诺二世和众多老政治家族的人、新闻记者被关进牢里。5年之后，检察官说阿基诺家的大公子从事颠覆活动，法院判他死刑。
世界各国的家族政治，向来有条不成文的规矩：搞政治斗争，可以把政敌关进牢里，可以逼人流亡国外，但做事要留一线，不能动手杀人。一动手杀人，那就麻烦了，因为这意味着各大家族从此之后只能以命相搏了。

马科斯竟然想杀人，此例一开，今后他岂不是想杀谁就杀谁了？
各个家族纷纷组织力量，上街游行。
连支持马科斯的那些家族，都劝他说千万不能杀人。
美国人呢？他们早就看马科斯不顺眼了，早就说他是“独裁者”了，也疯狂施压力。马科斯就没敢杀人。

1980年5月，在美国压力下，阿基诺二世被假释出狱，去美国就医。之后，马科斯在撑了3年后，实在受不了美国和国内的压力，被迫同意阿基诺二世回国。
1983年8月，阿基诺二世坐飞机回国，但刚走出机舱时，突然头部中了一枪，当场身亡。

菲律宾顿时掀起轩然大波。马科斯说：他绝对没想杀阿基诺二世。
后来有消息说：可能是美国干的，为的是嫁祸马科斯。真相至今没人知道。
接下来的路数，有点像颜色革命。
先是全国游行，搞了两年。菲律宾人嘛，干事情从来都是这么慢吞吞的。
之后，马科斯同意举行大选，阿基诺夫人被推作他的对手。1986年2月，议会宣布马科斯胜选，但阿基诺夫人说马科斯作弊，实际上是她胜选了，并宣布接管国家权力。

菲律宾国内差不多所有的大家族都站了出来，宣布不承认马科斯胜选；美国和西方国家，也说不承认。然后马科斯带着妻子、儿子，被迫流亡海外。他死在了海外。

1955年那场婚礼，确实产生一位菲律宾未来的总统。但命运竟然如此弄人，大家都以为是丈夫，结果竟然是妻子！
阿基诺夫人成为总统，背后有很深的美国背景。
顺便说一下，她的儿子阿基诺三世后来也当过菲律宾总统，在任内搞出了非常严重的“南海仲裁案”。

菲律宾以中国在南海（菲律宾称西菲律宾海）中菲争议“九段线”的海洋权益主张及近年的海洋执法和岛礁开发违反《联合国海洋法公约》为由，向裁法院提出对中国的仲裁案。

在当上总统之前，阿基诺三世还曾好几次到中国寻根问祖过。可见，有华人血统的外国元首，不见得一定对华友好。

一场动荡

1986年那次事件，在菲律宾历史上，是非常严重的一场动荡。
作为政治核心的吕宋岛，居然发生了大家族之间的内讧！
于是，按照惯例，他们就得找外援。菲律宾的第一大岛棉兰老岛的政治势力，机会就来了。
一个新家族出头了。杜特尔特家族。
杜特尔特来自一个小家族，他的父亲曾任过南达沃省省长，不过时间不长，他妈妈是是个教师。但杜特尔特有个优势，他外公是华人，姓吕，所以他也有华人血统，长这个样子：

棉兰老岛毕竟在最南边，离北面太远了，有华人血统的人要少一点。
在吕宋岛大家族们内讧时，杜特尔特正好任达沃市的检察官。
杜特尔特是个好勇斗狠的人，他说自己16岁就用刀捅死一个人，“仅仅是因为我们互相看了对方一眼”，还频繁入狱。“这里打一架，那里打一架”。

当时的达沃市算边陲地带，市长是马科斯的人。
为了稳住当地，阿基诺夫人任命杜特尔特当达沃市的行政长官。马科斯任命的这个市长平时就知道杜特尔特心狠手辣，听说阿基诺夫人已经任命了，吓得连夜逃走，把达沃市拱手相让。
从此之后，达沃市就成了杜特尔特家的地盘。至今已经36年。一个新家族从此崛起。

发生在1986年，吕宋岛这次家族之间的大内讧，导致了一个很严重的后果：从此之后，菲律宾的政坛就陷入了混乱。
可能是政治平衡被打破的原因，从此之后，吕宋岛的大家族再也推不出什么像样的人选来。

既然吕宋岛无英雄，那么就只能别的地方人来执政。
杜特尔特有点像董卓，他从边陲之地崛起，成功当选为菲律宾总统。
和之前所有的菲律宾总统不同，他没有美国背景。
所以这些年，我们看到：很多场合，他和美国对着干，对中国的态度呢，也相对友好。

所以美国人恨透了他。
就想着在今年这次选举，把局面再扳回来。
所以这次选举，其实是一次决定菲律宾命运的大博弈：主要是菲律宾本土力量和美国之间的博弈。
所谓的菲律宾本土力量，主要指的是马科斯家族和杜特尔特家族之间的联盟。
小马科斯是总统候选人。杜特尔特的女儿莎拉是副总统候选人。

杜特尔特和他女儿莎拉

这两个家族，都和美国关系不好。小马科斯的爸爸马科斯，和美国有宿怨，整个家族还因此遭到了清算。
马科斯家族逃亡出去几年后，风声慢慢松了，小马科斯又回到家乡，然后蛰伏了将近30年，最近这几年，因为很多事情已经过去，他才再次出现在政坛。
至于杜特尔特，因为他强力扫毒，又不像美国靠拢，早就惹怒了美国。
美国人早就扬言，等他总统任期结束后，要把他送进国际刑事法院。

这两个家族在菲律宾，有着不同寻常的影响力：在吕宋岛北部，马科斯家族有着无可匹敌的影响力，至于杜特尔特家族，在明达瑙岛尤其是达沃大区的号召力，则是独占鳌头的。
可以说是南北呼应。而且它们和美国的关系，至少目前看来，都很不好。
这对组合的对手，则是明白无误的美国代理人：现任菲律宾副总统罗布雷多。

对罗布雷多，美国给了最全力的支持。简直是不遗余力。首先，她选举的资金从哪里来？我们可以看到一个大家都很熟悉的名字：美国民主基金会。

菲律宾媒体说：这是她最大的金主。还有大批的菲律宾媒体，在美国民主基金会的操纵下，成了她的吹鼓手：拉普勒、媒体自由与责任中心、菲律宾调查性新闻中心。美国民主基金会还收买了菲律宾年轻政治精英。花了很多钱。各种渠道，光现在透露出来的，就有450万美元。

其中最大一个渠道就是“青年领袖善治奖学金”。名义上打着是为纪念罗布雷多老公林炳智而设立的。你没看错，这是个华人名字，罗布雷多的老公是华人。
在菲律宾，有华人血统的人太多了，这不意味着什么，因为有华人名字的，不一定亲华；而没有华人名字的，很可能也是华人，说不定对华更友好。

我们都知道，美国民主基金会背后，就是索罗斯。索罗斯背后，则是更黑暗深沉的力量。
美国势力介入的，还不止索罗斯一个。还有一个美国富豪，名字叫皮埃尔·奥米迪亚。这人非常神秘，谁也说不清楚他到底是个什么人，甚至世界上存在不存在这么一个人，都很难说，或者干脆他就是某个团体的神秘符号。但在这次菲律宾总统大选中，就至少出现了这么一个名字。

菲律宾的媒体，像CNN菲律宾、菲律宾星报、菲律宾每日询问者报，都在皮埃尔·奥米迪亚指挥下，每天都在攻击小马科斯。
在美国的指挥下，当年死硬反对马科斯家族的力量也都集结了。美国人不喜欢小马科斯上台，吕宋岛的大家族们也不喜欢。照道理说，罗布雷多应该要赢的。但结果是：她没赢。

这是为什么呢？因为三点：

1. 对美国人支持的候选人，菲律宾人已经产生戒备心理了。
  马科斯在位时，菲律宾人骂他独裁专权，贪污腐败。结果后来换上来的政权，竟然一个都不如他在位时，腐败依旧，社会停滞，治安还更差。
  菲律宾人已经受够了，尤其是前几年和美国没关系的杜特尔特在台上，菲律宾不管是经济发展，还是社会治安，比之前好多了。
  所以这次小马科斯宣布参选，菲律宾人因为知道他父亲当年倒台是美国人逼的，虽说他父亲也不那么干净，但至少菲律宾在他治下，社会治安还是好的，生活还是安定的，怀念当年的菲律宾人很多，因此他的支持率一直一马当先，保持在50%以上。
1. 杜特尔特家族这次很有策略。
  之前讲过，其实在总统大选刚开始时，因为杜特尔特不能连任总统，所以他的女儿莎拉的支持率一直是比小马科斯高的。
  但杜特尔特显然明白，如果他当过总统之后，再让女儿当总统，必然会引起吕宋岛大家族和美国人内外夹击，所以虽然民望很高，但他女儿作为副总统候选人，和遭受过大难的马科斯家族，可以有效抗击这双重压力。
1. 美国看走眼，选错了人。
  罗布雷多太过自信，以为有了美国支持，一定能当选。今年4月，美国曾经插手进去，让很多候选人退选，并要求他们退选时宣布支持罗布雷多。
  本来罗布雷多应该很客气地跟他们说，并且和他们谈一下价钱。但她什么也没干，而是用命令式的方式，要他们如何如何，结果这帮人虽然确实退选了，却都破口大骂罗布雷多，白白替小马科斯增加了选票。

今年4月，菲律宾选举史上发生了惊人的一幕：五位候选人宣布退选，但没有按照一般国家的选举规则，宣布支持第二名，而是痛骂排名第二的罗布雷多。

这就是美国人看人不准，用人不当了。

第一，如果说上次杜特尔特胜选，还有美国没怎么用心的原因。这次的菲律宾大选，美国人可以说是其实使尽浑身解数，但还是没能成功。在美国前殖民地中，这种情况很可能是第一次发生。
这说明，美国对前殖民地的控制，也开始松动了。有了第一个，就有第二个、第三个。这个世界真的在改变。
第二，对中国来说，小马科斯胜选是件好事。他的对华政策，一般来说，可能甚至会比杜特尔特更友好。
比如说，他在竞选时，就说过：南海仲裁案根本就是张废纸，因为仲裁要双方参与啊，一方搞的，怎么能说是仲裁呢？
南海今后会更平静了。
第三，小马科斯和美国的关系，不会那么好。
因为按照美国法院的判决，小马科斯和他妈妈伊梅尔达等，至今仍然是被执行人。就算他当了总统，如果没能和美国政府达成谅解，不光是他，甚至他的整个家族成员踏上美国土地时，都可能被关进监狱。
美国期待菲律宾政权发生变动，然后它可以在南海搞事，已经等了很长时间了。

当年被美国打翻的家族，再次复兴了。
当年那个青涩的少年，蛰伏30多年后，东山再起了。
这么一个人胜选，对美国来说，真不是个好消息，今后在南海更会没筹码。

张涛 - 印度的穆斯林王朝——德里苏丹

2022-05-08

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/history/2022/05/08/01

前段时间在研究阿富汗的时候，特意了解了一下中东地区几个国家的历史，看着看着反倒觉得印度是个神奇的存在，因为整个印度的历史基本上就是印度的屈辱史，被各种民族各种国家入侵，然后关键他到现在还能活着。所以特意写一系列文章讲一讲。

库特布沙希王朝——翻身农奴做国王

1206年，古尔王朝的苏丹吉亚斯·乌德丁·穆罕默德遇刺身亡，统治印度地区的总督库特布丁·艾伊拜克(也有翻译为艾伊伯克)趁机独立1206年，古尔王朝的印度总督艾伊拜克自立为苏丹，建立德里苏丹国。

这是印度历史上第一个信奉伊斯兰教的王朝。就在艾伊拜克登上帝位的庆典前不久，穆罕默德的侄子给他送来了释放证书和一副华盖。原来艾伊拜克竟然是个古尔王族的奴隶。他是如何从这般卑贱的地位一步步成为一个王国的缔造者的呢？让我们把目光投向这之前的中亚。

当时古尔王朝地理位置：位于阿富汗一带，南接印度。

在突厥人的一个奴隶市场，小小年纪的艾伊拜克被卖身成为奴隶。奴隶贩子将他卖给了尼夏普尔的首席法官卡济，卡济让艾伊拜克跟自己的儿子一起接受宗教教育，进行军事训练。艾伊拜克就是从这里得到了一些行军打仗的知识。在中亚地区，奴隶多从事生产、打仗，主人也乐得他们带来财富和军功，最后奴隶靠这些自己赎身。所以突厥人吹牛聊天的时候就喜欢说：想出人头地，就去做奴隶。艾伊拜克还真是靠做奴隶出人头地的。卡济去世后，他又被卖给奴隶贩子，这一次艾伊拜克的买主来头更大了，他就是古尔王朝的苏丹吉亚斯·乌德丁·穆罕默德。凭借出色的表现和忠心耿耿，艾伊拜克荣升“弼马温”。齐天大圣觉得这个职位小，大闹天宫，而艾伊拜克给苏丹穆罕默德管理马厩，那前景是非常光明的，突厥人作战主要依赖骑兵，此时为了获得南部的土地，苏丹远征印度。

随着艾伊拜克的新征程，我们也可以把目光转向印度了。艾伊拜克追随左右，军事才能发挥作用，立下了赫赫战功。于是，苏丹派艾伊拜克前去掌管印度地区的事务，并继续开疆拓土，扩大征服区。艾伊拜克果然不负所望，先后为苏丹征服了德里、曲女城、孟加拉等重要地区，北印度大部分地区都在他的控制之下。艾伊拜克艾伊拜克还十分懂得笼络当地王公，通过与当地首领的联姻，巩固自己在印度的统治。他本人就娶了当地首领塔杰·伊勒迪兹的女儿，又将自己的妹妹和女儿也都嫁给势力较小的首领，结成势力集团。当艾伊拜克在印度的势力不断膨胀的同时，古尔王朝却在外敌入侵的打击下逐渐衰落。艾伊拜克开始为自己的未来做打算，产生了自立之心。1206年，苏丹穆罕默德遇刺身亡，他的哥哥夺取王位。许多被征服的地区趁机开始反抗，国家陷入四分五裂的境地。见此情形，艾伊拜克当机立断，自立为苏丹。由于艾伊拜克信奉伊斯兰教，按照当时中亚国家穆斯林对国王的叫法，被称为“苏丹”。新建立的国家又是以德里为首都，因此，这个国家就被称为“德里苏丹国”。德里苏丹国是印度历史上第一个信仰伊斯兰教的王朝。

当年艾伊拜克的奴隶王朝大概区域

由于艾伊拜克已经提前做好准备，巩固势力，因此在宣布独立后，立刻得到了印度的其他穆斯林官员和地方首领的承认。基尔曼的总督伊勒迪兹，也在加兹尼自立为王。伊勒迪兹见艾伊拜克得到了印度的统治权，于是心生嫉妒，就想要夺取富庶的旁遮普地区。艾伊拜克也不甘示弱，他起兵迎战，击败伊勒迪兹，占领了加兹尼。随后，艾伊拜克将这个所谓的“国王”赶了出去。可惜，艾伊拜克在加兹尼并没有赢得民心，他的暴虐引起了人民的反抗，人们暗中帮助伊勒迪兹重返加兹尼，赶走了艾伊拜克。于是，艾伊拜克失去了对阿富汗地区的影响力，统治范围仅限于印度。艾伊拜克是一个虔诚的伊斯兰教徒，他大力推动伊斯兰教的传播，并修建了许多清真寺和学校。而印度本土宗教损失惨重，佛教更是在印度彻底灭亡，艾伊拜克大量捣毁佛寺，玄奘的母校那烂陀寺就被夷为平地。由于艾伊拜克曾经是奴隶，因此他开创的德里苏丹国的第一个王朝就被称为“奴隶王朝”。

此后，德里苏丹国还经历了四个王朝的统治，分别是卡尔吉王朝、图格鲁克王朝、赛义德王朝、洛迪王朝，直到1526年灭亡。后来德里苏丹国逐渐扩张后果：莫卧儿王朝建立1526年，帖木儿的后裔巴布尔征服印度，建立起莫卧儿王朝，德里苏丹国最终灭亡。

卡尔吉王朝

卡尔吉王朝（1290年－1320年）是德里苏丹国第二个王朝。这个朝代王族是阿富汗突厥的一支。人种上与文化上已经是伊朗化的。

卡尔吉王朝的创建者为菲鲁兹·卡尔吉。菲鲁兹本为库特布沙希王朝的一名将领，并在1290年取代了当时的库特布沙希苏丹。菲鲁兹死后，他儿子阿拉乌丁·卡尔吉大力继位，加强中央集权，整顿了财政和行政，并向南面的德干苏丹国发动进攻，并派遣马利克·卡富尔四次南征德干高原，大大扩张扩张了王国的领土。但这王朝捣毁了孟加拉国超戒寺与那烂陀寺。
1320年，卡尔吉王朝的最后一任苏丹被刺杀，王朝也就灭亡了。

德里苏丹国的扩张在卡尔吉王朝达到鼎盛，剩下的王朝基本可以忽略了，反正就是开始走下坡路的那种，有点像南北朝时期南朝这边的状态，宋齐梁陈一个比一个废。
在1300年的卡尔吉王朝时人口达到 3500 万，到 1380 年的图格鲁克王朝时人口达到5500万。但是到了1450年的赛义德王朝人口只有3200万。

德里之战

1398年，帖木儿率军入侵印度的德里苏丹国，双方在在首都德里附近爆发的决战。图格鲁克王朝一败涂地，德里德里苏丹国各地总督纷纷独立，为后来亡国埋下伏笔。帖木儿等待这一战已经很久了。
自十年前苏丹菲鲁兹·图格鲁克去世，德里苏丹国就陷入四分五裂的境地，国力渐渐衰落。而帖木儿帝国却如日中天，称霸于整个中亚地区。作为帖木儿帝国的缔造者，帖木儿继承了祖先蒙古人的优良传统，能征善战。经过短短十几年的战争，就征服了整个中亚和两河流域地区。

帖木儿帝国大致版图

苏丹国的丧钟

1398年，帖木儿决定率军南下，征服印度。初秋，帖木儿的军队在撒马尔罕集结起来，10万大军向南进发。一路上，军队对行军途中的部族和居民进行屠杀，扫荡他们的物资用作军队补给。9月份，军队已经开进开伯尔山口，沿着曾经波斯人、希腊人和阿拉伯人走过的路线进军。此时，统治德里苏丹国的是倒霉的纳西尔丁·马赫穆德·沙。苏丹虽然已经得知帖木儿率军入侵的消息，但他早已被地方上的总督和封建主们架空了权力，根本无力调动各地总督来阻挡入侵。既然苏丹都无所作为，各地的总督更是先求自保，哪里顾得上老百姓的安危。
于是，帖木儿的军队一路上几乎没有遭到任何抵抗，顺利的朝着印度的心脏德里开进。面对日渐逼近的侵略者，苏丹勉强拼凑起一支数量相当的军队，准备背水一战。只是，苏丹的军队都是临时招募的，人员混杂，作战经验参差不齐，无法与久经沙场、训练有素的帖木儿大军相提并论。但是没有办法，战争不会等你做好准备了才爆发。帖木儿是成吉思汗后裔。

开战

12月17日，双方在德里附近展开了决战。虽然军队战斗力不高，但苏丹自持拥有一个秘密武器，梦想以此实现反击。这个秘密武器就是印度的战象。印度人专门为战象准备了坚固的护甲，将他们安排在战线的最前方。苏丹的计划是，让战象首先进攻，将敌人的阵线冲出一个缺口，然后军队在发起进攻，将敌人一举击败。起初，这些庞然大物确实让帖木儿的士兵大卫惊惧。他们大都来自中亚，大部分人从来都没有见过大象，一时不知如何是好。帖木儿迅速想出了应对策略。他先是命令士兵挖掘了一道壕沟，组建起一道临时工事，让步兵躲在后面见机行事。然后，他又将运输补给用的骆驼全部拉出来，在它们身上布置了秘密武器。战斗开始后，大批战象横冲直撞而来。帖木儿不慌不忙，令躲在壕沟里的步兵先发射带有火药的箭头，并放炮惊吓大象。随后，他又将许多身上驮着干草的骆驼放出来，在它们身上点者熊熊烈火。大象怕火，面对此情此景都被吓得不行，竟调头向印度人冲去。印度军队的阵线就这样被自家的大象活活冲散了。帖木儿看到时机已到，立刻下令让军队发起总攻。中亚铁骑冲向混乱的印度军队，如入无人之境，肆意杀戮。苏丹看到战况不妙，只好撤退到要塞里躲了起来。帖木儿的军队又对要塞围攻不断，纳西尔丁只好抛下自己的国家，暗中出逃。帖木儿攻占德里后，军队照例在城中烧杀抢掠。反抗的市民遭到了惨烈的屠杀，大量建筑被焚毁殆尽，整个城市都失去了生机。帖木儿帝国骑兵次年，整个德里已经被帖木儿洗劫一空，城市的防卫体系也被完全破坏，帖木儿心满意足地回国了，留下一片狼藉的印度。苏丹已经完全丧失了自己的军队，无力在对国家进行统治。德里苏丹国的分裂更加严重，国势日渐衰微。后果：赛义德王朝1414年，黑兹尔汗占领德里，建立赛义德王朝。

德里之战是帖木儿帝国入侵印度德里苏丹国的一次战役。苏丹纳西尔丁的失败，导致图格鲁克王朝覆灭，也使德里苏丹国深受打击，一蹶不振。
1526年，帖木儿的后裔巴布尔彻底推翻德里苏丹国的统治，建立莫卧儿王朝。

张涛 - 学历史有什么用

2022-05-04

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/history/2022/05/04/01

学历史有什么用

之前在朋友圈发我学中亚地区历史的时候，碰到朋友问的最多的问题就是这个了：学历史有什么用。
凡是在朋友圈问我这个问题的，我基本上都是一句话：互联网没有增量了，多学点历史没坏处的。因为手机上解释的多了，我打字累，再加上别人也不一定愿意听，可能纯粹就是随便问一句。
其实说到底，任何开放性问题要想解答都要引入特定环境作为背景。通常来说，作为一个程序员，学历史可能真的没什么用。但是如果是经济下行，互联网公司大量裁员的今天，了解一下历史上经济危机前期或两国开战前期，做什么事情最容易保命甚至发达，可能就是一件收益颇丰的事情了。

学历史有什么用基本上也就两点：

了解历史史实
史实其实没什么好说的，哪怕是理科生，初中也学过基础的历史课程，甚至很多内容还被强迫必须背下来。一是从全局了解历史面貌，至少看电视剧的时候也不会问出刘邦不是秦始皇时期的人怎么又变成汉朝的人这种问题。第二就是一种成就感吧，比如你可以自信的跟别人说出：清朝时期就已经能去纽交所买股票，喝可口可乐了。
锻炼出探究事物背后逻辑的能力。
也可能是我作为一个程序员的职业病，遇到什么事都想搞清楚是什么原因造成的这件事发生。我觉得很多课堂上的老师都会忽略这种逻辑的推理，经常是照着书读，当时只知道老师是这么教的，但是不知道为什么，而现在却已经锻炼出把问题带入到特定环境去分析的能力。

成年人应该怎么学历史

参考系法

参考系法是最容易的，而且后期跟人吹逼的时候，讲出来也是最顺畅的，我自己用的就是这种方式来学历史的。
首先你要有一个自己熟悉的参考坐标系，比如我们都学过的中国史是最好的坐标轴，在这个参考系里面有一个关键的事件点的先后顺序要知道。
比如说最简单的

以电视剧中封神榜作为历史起点，周朝开国天子姬昌姬发灭了商朝纣王，建立周朝。
然后是周朝分封诸侯，开始了春秋战国，诸子百家。
电视剧《神话》，秦始皇统一中国，顺带刘邦跟项羽打仗，最后有了汉朝，顺带也知道了刘邦他老婆叫吕雉，儿子叫刘盈。
然后有首歌”东汉末年分三国”，顺带也就知道最早是西汉，然后才变成东汉，汉朝以后是三国。
三国最后有个老六司马懿，熬死了曹魏的所有人，然后有了晋朝。
有个词叫『魏晋南北朝』，这是历史老师最烦的，因为这是一大堆朝代。
魏晋南北朝以后就是《隋唐英雄传》
再然后有了唐，就是那个词『唐宋元明清』

一下子就把中国古代史记住了。
记住了中国古代史以后，就以这几个朝代作为坐标点，去横向延伸，看其他国家在这个时期的事情，就慢慢把全部的历史都记住了。

公元纪年法

还有一种记忆方式，就是公元纪年法。这种方式相当于你把时间作为坐标轴，然后在这个坐标轴上去看历史上的几个大事件，他们发生的时间段都是什么时候。
然后慢慢，事件与事件之间又发生了哪些事，慢慢把事情的前因后果联系起来，就能把全部历史记住了。
这一套记忆的方式，可以看看下面这个视频，如果你能把其中大部分王国的发家史和这个王国的事情有一个概述，那么你就很厉害了。

手机端也可以抖音搜索：【开源实验室】打开浏览。

张涛 - 印度的列国时代大一统——孔雀王朝

2022-05-03

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/history/2022/05/03/01

东边的摩揭陀王国

有一个前提大家要知道，印度历史上，各种各样的王朝。别太当真以为跟中国的李唐王朝，大清王朝一样动不动就是上百年。印度的王朝可能一代人就是一个王朝，老爹还叫牛逼王朝，儿子就马上改名叫喂牛王朝了。

诃黎王朝建立约公元前544年，由于摩揭陀国国王频毗沙罗是诃黎人，由他建立的王朝就被称为诃黎王朝。最早的摩揭陀国因为地理优势具备易守难攻的条件，再加上两代强势国王的经营，崛起也就成了必然。当时印度正处于列国时代，本土有16个国家并存，摩揭陀是其中一个。除了这些国外，还有数不清的城市和部落，也在彼此征伐战争不断。

列国时代末期的摩羯陀国

摩揭陀第一个国王就是公元前544年继位的频毗(pi)沙罗只有15岁。当时的他就已经懂得采取远交近攻的策略，通过联姻与强国居萨罗结盟，随后，慢慢吞并了旁边的大国鸳伽。没想到此时的儿子阿阇(shé)世为夺取王位，直接囚禁饿死了他。阿阇世继位后，进一步对外征服吞并了许多国家，摩揭陀国的势力一直扩张到恒河流域，成为十六雄国时代最强盛的国家。
除了对外扩张，频毗沙罗和阿阇世二人对佛教的发展也作出了巨大的贡献。

阿阇世早期迫害过佛教，佛陀(也就是现在我们说的佛祖)释迦牟尼有个一直想要谋害他的堂兄弟叫提婆达多，跟阿阇世是好友，就是这个提婆达多劝阿阇世篡位的。提婆达多曾经加入过释迦牟尼的僧团，但是后来因为意见不合与权力斗争，另外成立教派，也是之前讲佛教的18教派之一。
但是阿阇世篡位当上国王后，随着佛教的影响力，还有维护统治的需要，他也转而开始支持佛教。佛教历史上的第一次结集就是在阿阇世赞助下举办的。
另外上面我们也提到，最早支持耆那教的国家，就是摩揭陀国了。
整个摩羯陀国可能是跟基因有关，几乎每一任的国王，都是靠杀父篡位的。但偏偏开了这个先河的阿阇世，是自然老死的。
后面继任的统治者残暴昏庸，无所作为，摩揭陀国渐渐衰落。约公元前430年，诃黎王朝的最后一任国王被大臣悉输那伽推翻，建立起幼龙王朝，继续执掌摩揭陀国。
不过这个幼龙王朝跟他名字一样幼小，总共就三代，儿子辈有个响亮的名字”黑阿育王”。黑主要是为了跟接下来有个孔雀王朝的阿育王做个区分，可能是他比较心黑。
就是在他统治时期，爆发了佛教第二次结集。黑阿育王可能对结集进行了干预，他本来支持在本国的毗舍离比丘一方的大众部，后来他在妹妹的劝告下转而支持了西边“正统”的上座部一方。

黑阿育王死了以后，就是历史重现，他的年幼的儿子们被推翻，建立了难陀王朝。难陀王朝是摩揭陀又一次大扩张时代，其扩张所及远远超出了摩揭陀的核心范围，公元前400年左右已经基本统一印度北部。最后是因为末代国王统治非常残暴，导致民众暴乱，一个叫旃(zhān)陀罗笈多的冒险家乘机推翻难陀王朝，建立了孔雀王朝。

西北的犍陀罗国

公元前600-400年，印度次大陆正处于列国时期，共有16个国和不计其数的部落、城邦并存，政治混乱，国力衰弱。前面我们讲了东边摩揭陀国一统的事情，接下来讲讲西边印度河流域的事，一讲西边，那自然是开伯尔山口又进来人了。
之前的文章我讲过，印度这地形，两面环山，两面环海，虽然南边是高原，但是北部还有块大平原，其实是个很好的地形。但是要命的地方是西北部他山脉没包上，留了个面朝中亚的开伯尔山口，中亚这地方，从古至今就没安稳过，所以，时不时就进来一波游牧民族。而离这个山口最近的国家，就是犍陀罗国了。

公元前550年左右，波斯帝国蒸蒸日上，国王居鲁士远征小亚细亚，东出伊朗高原，一路来到印度。面对久经沙场的波斯大军，犍陀罗本地的统治者很快就宣告投降了。
波斯帝国的边境扩展到印度河西岸，还留下了雕刻功绩的石碑，只是当时波斯帝国内有叛乱，所以在印度只留下一部分士兵驻扎，让印度上贡金粉。
后来，波斯国王去世后，整个波斯帝国分崩离析，犍陀罗国这边也早就心怀不满，但是他们的反抗还没有成气候，波斯这边又诞生了一个厉害的君主，波斯贵族大流士。大流士希望凭借印度的海上航线，为打希腊运送士兵和物资。公元516年左右，整个帝国的波斯军人沿着印度河长驱直入印度境内，几乎没遭遇到任何抵抗，仅用了一年时间，大流士就整合了印度河流域兴起的城邦。

波斯帝国入侵应该算印度历史上第一次被外国入侵，之前的雅利安人更多是算融入了印度，而波斯帝国入侵，则是真正意义上将印度划入了波斯帝国的领土。

当年波斯帝国的领土

孔雀王朝，印度的首次统一

当波斯实力逐渐衰败后，印度开始了各个小国之间的混战。亚历山大征服波斯后，公元前327年，他一路向东朝印度进军，此时的印度各邦国非但不齐心御敌还想着从中获利。
从翻越兴都库什山脉进入印度后，亚历山大帝就一路势如破竹，将印度北边的多个国家收入囊中。他们少有对手，比较像样的印度土邦就是保拉瓦王国，当时王公波鲁斯同马其顿军艰难的战争持续了几个月，最终亚历山大俘获了投降的波鲁斯和他的儿子，宣告胜利。紧接着因为军中开始传播疫病，再加上长年的征战让士兵们看不到尽头，马其顿军开始了集体的罢工。也因为下一目标摩揭陀国当时正好是全盛时期的难陀王朝，难陀王朝是当时控制着恒河流域的广大地区，并有继续向外扩张，统一北印度之势。没有了士兵支持的亚历山大也只好放弃向恒河前进的计划，在公元前326年他停止了东征，在被征服的旁遮普地区设立总督进行统治，就撤军返回罗马了。

这时，有个叫旃(zhān)陀罗笈多的人，率领当地人民揭竿而起，组织了一支军队，他是摩揭陀国人，出身是吠舍种姓，加上年轻，所以其实部队并不大，但是却赶走了马其顿军留守的人，趁机占领了一座城。因为他有一个自己的贵人——出身婆罗门种姓的考底利耶。考底利耶擅长权谋、军事和政治，是个了不起的智者。
当时他们都正值青年，一边抗击马其顿侵略者，一边逐步蚕食难陀王朝的领地，扩大自己的势力。旃陀罗笈多不断的袭扰难陀王朝的外围领土，然后慢慢的向王朝的核心腹地渗透。最终难陀王朝无力支撑，被旃陀罗笈多在公元前324年彻底击败。

王朝的领土不断扩大。但是公元前305年，亚历山大留下的另一个大将给孔雀王朝泼了盆冷水。旃陀罗笈多遇到了人生中的一大劲敌：亚历山大的部将塞琉古。亚历山大去世后，塞琉古继承了对中亚地区的统治。为了夺回被孔雀王朝占领的旁遮普，塞琉古挑起战争。期间断断续续打了一年多，最终双方议和结束。此后7年间，旃陀罗笈多都没有再发动大规模的对外征服战争。后来皈依了耆那教，将王位传给了自己的儿子宾头娑罗。他本人则前往南印度，到耆那教圣地进行修行，他按照正统耆那教的苦行，绝食而死。
随着宾头娑罗治理，孔雀王朝已控制了印度河平原，恒河平原，孟加拉湾，德干高原以及远达阿拉伯海的广大领域，形成了史学界传统意义上的大帝国。直到公元前273年宾头娑罗逝世，他儿子阿育王在大臣成护的帮助下，与兄弟苏深摩争夺王位取胜，并把王族政敌全部杀死。上位后的阿育王最初也是四处征战，最后统一了印度全境，成为古代印度历史上空前强盛的时代。

阿育王在统治初期被认为是一个暴君，后来也可能是统治需要，也可能是受人影响，开始接触佛教，即位后第七年皈依佛教，并且将佛教定为国教。不过虽然佛教为国教，其他宗教也还是能正常存在和发展，他还向周边国家派遣传教师至各地宣传佛教。从那以后开始佛教遂成为世界重要宗教之一。不过阿育王早期信奉是西边的上座部，在各国宣传的也是上座部佛法，但到了晚年又改信大众部，这也就是为什么印度周边，斯里兰卡、缅甸、泰国、柬埔寨、老挝及中国云南傣族都是南传佛教，结果后来玄奘去取经取回来的却是北传佛教的原因。

张涛 - 印度列国时代的百家争鸣——沙门思潮

2022-05-02

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/history/2022/05/02/01

沙门思潮

大概公元前1500年，遍布亚洲中心的雅利安人就侵入了印度河古印度文明，他们把自己的多神教改成了婆罗门教，雅利安的祭司们也就成了最高贵的婆罗门，雅利安得武士们成为了国王官员刹帝利，雅利安的普通平民就成了商人农民吠舍，然后原本的古印度人就成了苦力劳工叫首陀罗。
这几个词都是来自当时雅利安传说：普鲁沙是众神为了献祭创造出的巨人，他死了以后，身体各部分就幻化成了众生。嘴巴变成婆罗门，双臂变成刹帝利，双腿变成吠舍，双脚变成首陀罗。这也就是印度种姓制的由来，虽然现如今被废弃了但依然影响着印度人的思想。当时的雅利安人随着入侵很快扩散到整个北印度，原住民就只能被挤到了南部的德干高原，然后雅利安人搞出了一套以婆罗门为精神领袖，以刹帝利为世俗领导的这些农业邦国。

但是问题没多久，刹帝利又不乐意了，凭什么我每天打仗，你天天吆喝训斥我。
于是大约在公元前800-600年，刹帝利内兴起了一种提倡众生平等、绝对精神的运动叫沙门思潮。
沙门这个词也被翻译成：娑门、沙门那。大致上可以理解为出家人，修行者，跟我们汉传佛教中的和尚类似。
沙门思潮是当时一系列宗教起源运动的统称，沙门诸教不承认后期婆罗门所提出祭祀升天的说法，而是相信原来的轮回。这一时期的印度不仅时间上跟中国的春秋时期很接近，形态上也非常相像，当时印度有16个国家和多不胜数的小城邦，它们各自独立，征战不休。
在这样动荡的环境下，思想空前活跃，形成了百家争鸣的局面。筏驮摩那(Vardhamāna)创立的耆(qi)那教就是其中重要的一派，另一个重要的派别就是我们熟知的佛教。

列国时代的16个大国

耆那教

公元前599年，筏驮摩那出生，他父亲属刹帝利种姓，统治着贝拿勒斯的一个小王国。筏驮摩那自幼就过着安定富足的生活，后来娶妻生女，但30岁那年，筏驮摩那的父亲去世，兄弟争斗不休，厌倦宫廷生活的他便决定出家修行，寻找人生意义。
后来，筏驮摩那前往各处游历，开始了颠沛流离的旅途。因为没有行李，又经常绝食来磨练心志，时间长了衣服也磨损地破烂不堪，后来甚至裸体行乞，这样的生活，筏驮摩那一共坚持了整整12年。
后来慢慢集结起一批信徒和追随者，因为他反对婆罗门教的种姓制度，受到了当时掌握军政大权的刹帝利种姓、经商致富的吠舍大商人的欢迎。

当时的印度据说有十六国，正处于列国时代，学术流派百家争鸣。耆那教并不是当时唯一反对婆罗门教的宗教。除了耆那教外，还有佛教、顺世派、不可知论派等等许多思想流派，它们被统称为“沙门思潮”。
这一时期也成为奠定古印度文明基本价值的轴心时代。佛教因为与耆那教的主张相似，两派产生了尖锐的矛盾。
最初，筏驮摩那带领众弟子在恒河流域一带传教，得到了摩揭陀王国、阿般提王国等国王的支持（上面那张图靠近南部的两个国家），之前的文章也提过，此时北方都还受雅利安人的婆罗门教统治，能有两个大国支持已经很不容易了。
除了国王，还有王公贵族、朝中许多大臣都成为耆那教的信徒，筏驮摩那也完全不会为供养问题发愁。然而后来佛教兴起，王子等人也皈依佛门，甚至剃度出家，耆那教的势力受到了排挤，因为它有一个常人难以接受的问题。比起佛教，耆那教信徒的修行要更加严格，长期苦行甚至裸休让他们痩骨嶙峋、身上也总是污秽不堪。
筏驮摩那是以智者的形象来到王廷的，当时贵族们热衷追捧智者，但是苦行僧的方式非常不利于耆那教的形象，与人们想象中的智慧、威严的智者完全不是一回事。筏驮摩那还算有名声，而他的弟子们没有智者的光环，在人们眼中形象就很糟糕了。此外，严格的耆那教徒都不会做屠夫、当兵，甚至不肯耕田。对他们而言，就连走路踩死一只蚂蚁、打死一只苍蝇，所犯下的罪过都与杀人别无二致。这样的宗教规范实在太过沉重。直到今天的耆那教教徒，依然长期佩戴口罩，以免呼吸杀死微生物。
后来，越来越强势的佛教，让耆那教渐渐暗淡。筏驮摩那虽然一生从来没有跟佛陀见面，但他们的弟子却经常争斗，挑起论战，但是用一句话形容就是又菜又爱玩。类似的论战很多，也不光是佛教跟耆那教吵，那时候各种沙门教都在互相吵。佛陀就会经常亲自出马，还教授佛教弟子辩论术，耆那教往往占不到什么便宜。筏驮摩那本人原本无意争斗，但是后来他亲信弟子优婆离长者也改信佛教，筏驮摩那听到这个消息后，悲愤交加，吐血身亡。筏驮摩那死后，信徒已经有5万余人之多，他的弟子继续传播耆那教的主张，后来耆那教发展成为印度重要的传统宗教之一。

佛教

在公元前600年左右，释迦牟尼创立了佛教，与婆罗门教、耆那教共同成为影响印度的重要宗教。释迦牟尼的本名是乔达摩·悉达多，释迦牟尼是后人对他的尊称，意思是释迦族的圣人。释迦牟尼的父亲净饭王是释迦族的首领，妈妈是摩耶夫人，生活富足，因为看到人们的苦难才决心出家。
释迦牟尼最早用了六年的时间深入极端苦行，而苦行就是当时兴起的沙门思潮中的一种修行方式。后来他来到一棵菩提树下静坐冥想，找寻到了答案立身成佛，尊称释迦牟尼。并把自己证悟的佛法讲给最早跟随他的五个人，而这五人也成为了释迦牟尼最初的弟子，被称为五比丘。
而这一次释迦牟尼的首次讲法，也被称为“初转法轮”。从此要构成佛教的基本要素，佛陀：释迦牟尼、法：佛法、僧：五比丘，三宝都具备了，佛教就正式创立起来。
早期佛教认为佛陀只是一位导师，而不是神，信徒是向他学习的。同时，信徒要想超脱生死轮回必须离开家，在外苦行（早期的沙门思潮下的各个教派都是以苦行僧为主）。由于这种修行太过严苛，后来佛教逐渐产生了以功德为主，简化修行，同时神话佛陀的新学派，这种学派称为：大乘佛教。相对的，早期的佛教便被称为：小乘佛教。
早期佛教都是以思想教义讲述修行方法为主，但是，却没有将各类思想编著成册流传下来，随着释迦牟尼去世后，这种修行方式让佛教的发展停滞不前。而此时受其他教派打压，佛教逐渐危机四伏。
后来五比丘之一的伽叶担起了这个重任，开始将分散在各地的有名望的佛学大师召集起来，汇编佛教经典，佛经也是从这时出现的，这一次集结也被称为佛教第一次集结。
后来，到了公元前330年左右，虽然有了佛经，但是一些僧人自行修改，印度东部僧人提出十条新戒律，其中有几条是允许比丘收取钱财、可以存储食言随时食用、如果饭没吃饱可以继续进食，而最早五比丘之一的耶舍则认定这十条新戒律非法。

之所以有这样的新戒律主要是因为印度东部的状况跟西部差距太大，当时以耶舍为首的西部佛教大概在摩偷罗这里，而东部十条新戒律的比丘在毗舍离。后来耶舍召集了大概700名西部比丘，与东部比丘辩论。从而导致两方爆发论战，这也就是佛教第二次集结，而到最后两方谁也说服不了谁，干脆各自推行自己的做法，原始佛教也分裂出两大传统，遵守西边的称为上座部，而遵守东边毗舍离比丘戒律的僧团则称大众部。再到后来出现了18个部派，佛教也从此进入部派佛教时期。
后来印度大一统的孔雀王朝将佛教定为国教，还向周边国家派遣传教师至各地宣传佛教。当时的国王早期信奉是西边的上座部，在各国宣传的也是上座部佛法，但到了晚年国王又改信大众部，这也就是为什么印度周边的斯里兰卡、缅甸、泰国、柬埔寨、老挝，及中国云南傣族都是上座部，也叫南传佛教；结果后来玄奘去取经取回来的却是大众部(也叫北传佛教)的原因。
佛教受到婆罗门教很大影响，一些用语概念来自婆罗门，而部派佛教中的一派密宗与婆罗门教结合更紧密，藏传佛教就是这一支，吸收婆罗门神体系，图为婆罗门神毗那夜迦，被佛教吸收为护法。

摩揭陀国诃黎王朝

摩揭陀国必须得讲，主要是佛教、耆那教都是从跟他有很大的关系。而且到最后列国末期，也是他领土最大，可以把他类比成我们这边没能一统的秦国。

诃黎王朝建立约公元前544年，由于摩揭陀国国王频毗沙罗是诃黎人，由他建立的王朝就被称为诃黎王朝。当时正处于列国时代，印度本土有16个小国家并存，摩揭陀就是其中一个。除了这些小国外，还有数不清的城市和部落，也在彼此征伐战争不断。
摩揭陀国的崛起依靠的是频毗沙罗和阿阇世两代国王的经营。

除了对外扩张，二人对佛教的发展也作出了巨大的贡献。阿阇世早期迫害过佛教，佛陀(也就是现在我们说的佛祖)释迦牟尼有个一直想要谋害他的堂兄弟叫提婆达多，跟阿阇世是好友，就是这个提婆达多劝阿阇世篡位的。提婆达多曾经加入过释迦牟尼的僧团，但是后来因为意见不合与权力斗争，另外成立教派，也是之前讲佛教的18教派之一。
但是随着佛教的影响力，还有维护统治的需要，他也转而开始支持佛教。佛教历史上的第一次结集就是在阿阇世赞助下举办的。
另外上面我们也提到，最早支持耆那教的国家，就是摩揭陀国了。

阿阇世死后，继任的统治者残暴昏庸，无所作为，摩揭陀国渐渐衰落。
约公元前430年，诃黎王朝的最后一任国王被大臣推翻，建立起幼龙王朝，继续执掌摩揭陀国，随着扩张，公元前400年左右已经基本统一印度北部。

张涛 - 印度真是个神奇的国度——总章

2022-05-01

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/history/2022/05/01/01

四大文明古国

四大文明古国，古中国、古印度、古巴比伦、古埃及。当然之所以有这四个古文明，是因为他们都有一条或多条河流：咱们中国的长江黄河，印度河，底格里斯河幼发拉底河，尼罗河。在这个纬度上，刚好是处于北纬30度副高气压带形成的一种亚热带沙漠气候下被南北山地发源的大河滋润的平原，使得阳光水源双滋润形成的最早的农业文明。

这几个大河里面尼罗河在埃及，底格里斯河幼发拉底河在伊拉克，长江黄河在我们中国，印度河就比较好玩，他竟然全境几乎都在巴基斯坦。

印度和巴基斯坦到底是个什么关系呢，很早的时候，印度有可能还是个独立的岛，在印度洋上往欧亚大陆上飘，结果撞在一起变成个大陆，顺带还撞出来个世界屋脊青藏高原还加个横断山脉，包括到现在都还有研究表明说青藏高原还在升高，也就是说印度这块还在往欧亚大陆上挤。然后现在的印度次大陆就形成了两面环海两边是山，随着高山流下的雪水，和海吹向山的季风就出现了山脉脚下的高度肥沃的印度河和恒河平原。尤其是在印度河流域，也就产生了古印度人的哈拉帕文化，也就是俗称的古印度文明。

外族入侵

但问题是印度毁就毁在印度河这一边了，因为这个闭塞的印度次大陆，他还留了个口子，西北这边有个面向亚洲的口子，就是兴都库什山脉、苏莱曼山脉、昆仑山脉那个位置。这个口子叫开伯尔山口，口子对着的，还是个要命的中亚戈壁沙漠区，这个区域生活的是一帮游牧民族叫『雅利安人』，也就是现在的伊朗、阿富汗等主体民族，就算放在今天看，他也是个要命的地形。所以现在你看印度又有黑人又有黄种人，又有白人，就是因为这个口子，谁都能进来。伊朗的波斯语是叫”ayran”，其实就是现在的『雅利安』这个词。

大概公元前1500年，遍布亚洲中心的雅利安人就侵入了印度河印度文明。
当时印度的土著黑人叫达罗毗(pi)荼(tu)人就逃到了南边。
后来雅利安人把自己的多神教改成了婆罗门教，雅利安的祭司们也就成了最高贵的婆罗门，雅利安得武士们成为了国王官员刹帝利，雅利安的普通平民就成了商人农民吠舍，然后原本的古印度人就成了苦力劳工叫首陀罗。这几个词都是来自当时雅利安传说：普鲁沙是众神为了献祭创造出的巨人，他死了以后，身体各部分就幻化成了众生。嘴巴变成婆罗门，双臂变成刹帝利，双腿变成吠舍，双脚变成首陀罗。这也就是印度种姓制的由来，虽然现如今被废弃了但依然影响着印度人的思想。当时的雅利安人随着入侵很快扩散到整个北印度，原住民就只能被挤到了南部的德干高原，然后雅利安人搞出了一套以婆罗门为精神领袖，以刹帝利为世俗领导的这些农业邦国。

但是问题没多久，刹帝利又不乐意了，凭什么我每天打仗，你天天吆喝训斥我。于是大约在公元前800-600年，相当于中国的春秋时期，刹帝利内兴起了一种提倡众生平等、绝对精神的运动叫沙门思潮。

沙门思潮他里面最重要的一个教派，就是如今的佛教了。早期的佛教并没有翻起什么浪花，毕竟还有婆罗门这一层统治着。直到不久之后，隔壁雅利安同胞的波斯，又一次大规模入侵印度河流域，后来欧洲的希腊亚历山大东征来到了印度河。这个时候差不多相当于我们的战国时期。按照历史的先例，印度人民本来应该继续躺平的，没想到恒河地区的当时一个刹帝利邦国摩揭陀国揭竿而起，不仅统一印度大半，而且为了弥和阶级组群之间的矛盾，还皈依了平等的佛教，这就是著名的孔雀王朝。

上面这一段历史，大约公元前800年-公元100年，相当于我们从西周到西汉，我后面单独花时间，写到我的知识星球里。这时期印度内部各种各样的种族斗争，被称为列国时代，加上后面的希腊入侵，孔雀王朝崛起，精彩程度丝毫不亚于我们的战国时期。

已填坑：印度列国时代的百家争鸣——沙门思潮
第二部分：印度列国时代的大一统——孔雀王朝

贵霜帝国

公元200年左右，进入到了我们的西汉时期，甘肃河西走廊的少数民族月氏(zhi)，被北方的匈奴给击败，逃到了中亚阿富汗这一代，这群人又和当地的雅利安融合，然后又南下看到了印度河恒河流域，建立了贵霜帝国，定都在现在巴基斯坦的白沙瓦。
当年汉武帝刘彻派张蹇出使西域，就是找月氏族结盟的，结果月氏人没理他，后来大汉就自己把匈奴干翻了，结果匈奴又把月氏人赶跑了，月氏人跑到雅利安大本营待了一段时间，又跑到印度，把印度本土的孔雀王朝推了。

这个贵霜帝国在汉朝还曾想要东进新疆，最后被班超给击败打了回来，但依然不影响这个帝国的强大。
当时之所以从中亚南下到白沙瓦，也是因为当时的贵霜帝国在整个中亚加印度次大陆地区，都已经没有可以与贵霜称霸的强权。大约公元130年，当时的统治者是个刚上位的国王，叫迦腻色迦，急需一场征服战争来树立自己的威望，于是他将目光转向了富庶的北印度地区。这里离印度河流域更近，也方便入侵印度打仗。
贵霜帝国和伊朗的安息帝国、地中海的罗马帝国和咱们东亚的汉朝，并称为四大帝国时代。

但是，从公元400年左右开始，地球迎来了一个大寒潮时期，现在也有推测汉朝罗马衰败都跟这次寒潮有关，当时汉朝被鲜卑人入侵，罗马被日耳曼人入侵，而这个贵霜帝国，也遇到了号称白匈奴的嚈哒(yàn dā)人。到现在认为这批嚈哒人可能就是中亚的雅利安人、月氏人、匈奴人混在一起的游牧民族。
后来又到公元500年左右，就相当于我们南北朝晚期时候，游牧民族里边出现了一个真正的强者，就是来自于我们北方的突厥人，他向东吞灭了鲜卑的柔然国，向西灭了白匈奴，更是把大量的雅利安人同化成白突厥，后来一直是打到了乌克兰才结束。成为了巨大的突厥汗国，只可惜突厥人生不逢时，没多久之后，在西南的沙漠地带，阿拉伯人就靠着伊斯兰教迅速的整合兴起，先占据了当时罗马的叙利亚，又灭掉了伊朗的波斯，最后建立了非常强大的阿拉伯帝国。而我们这边大家应该很清楚了，就是大唐天朝一统天下。然后突厥汗国因为突然两边面临强敌，没多久就被肢解了。后来唐朝和阿拉伯就成为了世界上仅有的两大帝国，地理位置上也是直接在中亚接壤，此时南边的印度倒是也经历了几个大国度，先后为超日王的笈多帝国、戒日王的戒日帝国。你听听这名字应该也就知道有多酱油了，也没坚持几年。
西游记就是戒日王时期的事情，当时玄奘跟戒日王关系还特别好。之后有次大唐又派了个使者叫王玄策来印度，结果没想到戒日王已经死了，印度还发生了政变，把王玄策关了起来。再后来被他逃了出去，跑到隔壁吐蕃国借了点人，差点把印度给灭了。这就是王玄策“一人灭一国”的真实故事，到现在西藏还有石碑记录这个事。

伊斯兰王朝时代

再往后，了解历史的应该都知道了，突厥人又一次崛起了，而且这次还是吸取了阿拉伯跟大唐优势的新突厥人。这一群突厥人，建立了东起中国西到欧洲的一系列伊斯兰苏丹王朝，苏丹是一个阿拉伯语的音译词，后衍生为伊斯兰国家的统治者头衔，现在我们把苏丹统治的国家被称为“苏丹国”。然后在中亚地区出来的迦色尼王朝、古尔王朝也先后占据了阿富汗，并且以阿富汗为核心彻底控制了印度河流域。
这个时候是公元1200年左右，中国的宋朝。在这种环境之下，印度是又又又一次躺平，一方面西北地区开始逐渐伊斯兰化，另一方面本土的佛教也开始走向虚幻的神秘化，而曾经婆罗门教被牛逼的商羯罗融合佛教改成了印度教，再次从各个基层复苏起来。
再往后呢就是世界史的大事件了，蒙古成吉思汗这个大BUG，说大半个世界被他一锅端都不过分，当时突厥的古尔王朝还有一点残余势力，他们以印度河恒河流域的枢纽，从德里这个城邦为中心建立了一个伊斯兰化的邦国叫德里苏丹国。

但问题是这个国家它其实不算是个国家，因为他本身的就是四十几个阿富汗突厥贵族为了利益组成的一种诸侯联邦状态。这个状态就有点像我们的战国时期，各个诸侯表面上都说自己是周天子的子民，但实际上都自立为王。当时的德里苏丹国也是这样，内部矛盾很多，要不是印度土著擅长躺平，估计早就像陈胜吴广一样揭竿而起，干翻这个王国了。

这一段伊斯兰苏丹王朝时期，也是段很有意思的历史。期间有个比较大的战局叫德里之战；还有印度宗教的改革，直接宗教信仰都变了；达伽马开辟了欧洲绕道非洲前往印度的新航线；东印度公司成立也都是在这期间发生的。我后面有时间单独在我的知识星球里写一篇文章讲。

莫卧儿王朝

第一次帕尼帕特战役

到头来改变这一切的反而又是一群外来者。当时蒙古到处肆虐欧亚大陆的时候，也是有反抗者的，一个是中国的朱元璋，另一个是中亚的帖木儿。帖木儿反抗蒙古的时候建立了一个帖木儿帝国，这个帖木儿其实也是蒙古血统，不过从小在中亚长大，是个中亚突厥化的蒙古人。他儿子叫巴布尔，当时利用德里苏丹国的内乱，部分民意代表向他求援的时候，南下直接进攻德里苏丹国，前前后后大概花了一年时间，期间有一场很著名的战役叫第一次帕尼帕特战役，当时打了大约一个月就结束了。最终建立了统一的莫卧儿王朝，定都在现在巴基斯坦的拉合尔，后来印度著名的泰姬陵也是这个王朝第五代王修建的。莫卧儿这个名字也就是mughul，就是蒙古的意思。

最初刚成立的莫卧儿王朝大概有这么大。

莫卧儿王朝在1526年建立，大约是我们明末清初的时候，在莫卧儿王朝伊斯兰跟印度教的矛盾达到了一定的缓和，因为当时伊斯兰教大多数都是上层贵族去加入，然后还有一些和伊朗接壤的印度河那里的旁遮普跟信得地区，还有商业贸易发达的恒河下游的孟加拉地区，这些地方信的多（看上图，记住这几个地区，对比现在的世界地图你会发现很有意思的现象）。
而信仰印度教的更多是北方腹地从事农业的领主，这两股势力在当时基本上井水不犯河水。王朝的官方语言也是当时印度北部的通用语言，叫印地语。但是，蒙古王公一般称叫乌尔都(urdu)语的多，这个词也就是蒙古语蒙古包的意思，也叫鄂尔多，比如鄂尔多斯(ordos)就是一堆蒙古包的意思。
现如今巴基斯坦的官方语言就叫乌尔都语，而印度的官方语言就叫印地语(注意不是印度语)，这俩本质上就是一门语言，完全能互通的，差异甚至还没我们河南陕西的方言差异大。
1530年，莫卧儿帝国的开国国王巴布尔去世，22岁的儿子胡马雍继位。历史总是相似的，年轻的子孙守不住祖业，丢了国家的案例比比皆是。1539年，当时阿富汗的叛乱者跟着北印度地区的统治者舍尔沙将胡马雍赶出了国家，他也只能流亡到同样信仰伊斯兰教的波斯，而叛乱者在原本的莫卧儿国土上建立起苏尔王朝。
当时胡马雍逃到波斯后取了一个学者的女儿，生了个儿子叫阿克巴，这儿子将来很牛逼，大家要记住他。
胡马雍自从逃到波斯后，卧薪尝胆猥琐发育，一直到1554年等来了个机会。舍尔沙父子都先后去世，不满10岁的孙子继承王位。又是相似的历史，年轻的子孙守不住祖业，小国王的舅舅夺取了王位，但遭到了各地反叛，国家又陷入了分裂。
此时的胡马雍立即率军前往，趁着速尔王朝内乱，借着波斯人的火药再次统一了北方。
此时距离他当时流亡，已经过了16年，结果没想到刚过了一年好日子，第二年于1556年，去祷告的时候从楼梯上摔下身亡，小阿克巴也在这时继承了王位。

第二次帕尼帕特战役

1556年，胡马雍意外身亡，13岁的阿克巴继承王位。之前我们就说过这儿子很牛逼，但是刚继位的时候，基本和亡国之君差不多。他只能在一些大臣的支持下，在兰诺尔城的一个花园内登基。阿富汗人喜穆趁机联合其他印度贵族，一举夺取了首都德里，建立起自己的统治，自称“超日王”，就是前面我们说的那个酱油王。
这时候的阿克巴不仅没有国土，还差点失去朝廷官员。当时，许多大臣都被喜穆吓坏了，对这个小皇帝根本不抱任何希望，纷纷劝说阿克巴撤退甚至是投降。
只有一名忠心耿耿的老臣白拉姆汗坚决要求作战。他年过六旬，身经百战，曾为巴布尔和胡马雍的征服立下汗马功劳。胡马雍死时，他正在阿富汗招募新兵，得知消息后立刻率军前来辅佐新主。白拉姆汗建议阿克巴，趁着敌人还没有集结完毕，做好战争准备，主动出击。这种故事在中国史里经常看到，小皇帝阿克巴采取了白拉姆汗的建议，并御驾亲征，阿克巴和白拉姆汗率领1.5万大军向德里进发，巧合的是正好又是在帕尼帕特地区，30年前的巴布尔也是在这里大败阿富汗人，建立起莫卧儿帝国的。
叠上了祖辈buff的阿克巴自然也是大获全胜，喜穆也被斩杀，此战之后，他重新夺回德里。此后，阿克巴经过南征北战，逐渐统一北印度地区。
这就是第二次帕尼帕特战争，本质上是印度本土贵族反抗外来的莫卧儿王朝统治的起义，战争失败后，莫卧儿王朝的统治反倒更加巩固。
阿克巴还有个孙子，叫沙贾汗，泰姬陵就是他为了纪念老婆修的。

英国殖民时期

英国殖民这时候已经算近代史了，当时英国从一开始只想赚钱变成统治再到跑路留下一堆烂摊子，资料比较多也比较全，后面有时间我也单独总结一篇文章。

到1700-1800年左右，乾隆年间，莫卧儿王朝也是堕落到连阿富汗人都能持续暴打的状态。法国人英国人开始从孟加拉登陆，先是接手大量的印度教邦，然后迅速向西向南蚕食整个印度。后来莫卧儿的时控区仅仅剩下了德里、旁遮普、信德这些西北地区。最终莫卧儿王朝就在火烧圆明园之前的1857年被英国女王冠名为印度女皇之下，然后彻底灭亡。所以结合来看鸦片战争时候，那一句：”英国在中国之何方”，并不是说清朝连英国在哪都不知道，实际上他们真正迷惑的，可能只是不知道那个遥远的欧洲岛国什么时候把近在咫尺的印度都彻底划成自己的了。
不过英国统治了，也必然影响了一大部分当地土邦皇帝的利益，虽然印度擅长躺平，但是恶心英国的行为也从来没有停止过。至于印度的穆斯林，更是在一战期间发动基拉法特运动，谋求在国内的地位。最终在二战期间英国陷入了漩涡不能自拔，印度河畔的穆斯林贵族，也提出以这个旁遮普、阿富汗、克什米尔、信德、伊朗的俾路支斯坦建立巴基斯坦。
事实上巴基斯坦(Pakistan)的名字也是从这几个地区来的：

旁遮普（P）
阿富汗 (A)
克什米尔 (Ki)
信德 (S)
俾路支斯坦 (stan)

这是印度这边的，而另一边，1932年，英国更是爆发了皇家海军哗变，导致英国的殖民统治在全世界都乱套了，所以二战之后，英国就打算赶紧解决掉印度问题。当然大家都知道，英国就擅长挑事，当时英国让印度的新总督蒙巴顿照着地图硬画了一个有印度教的印度国、伊斯兰教的巴基斯坦国让这两国分制。更诡异的是在东北角孟加拉地区也有大量的伊斯兰教民，当时还搞成一个叫东巴基斯坦的飞地，后来也是独立成孟加拉国了，还记得上面莫卧儿王朝那张图吧，看看这里的印度、巴基斯坦、东巴基斯坦。
还一个问题是两国的北方边境，就是印度河的源头克什米尔地区，因为信仰更复杂，还特地画成了一个待解决的地区，让民众自愿加入两方，这也就导致同文同种的两个国家，因为信仰、领土争端就维持着不断的矛盾，1947年的印巴战争也就是因为这个原因。
顺带说一句，这问题到现在都还没解决。

百度地图标注的红色虚线

再后来，独立后的印度反倒就飘了，觉得自己是亚洲霸主，搞了一个包括的青藏在内的大印度文化圈，结果被我们一顿暴打，这也结了一个梁子，那边巴基斯坦一看那当然敌人的敌人就是朋友，也就很难不和中国走得越来越近了。而除了这个外忧，巴基斯坦内部还有着属于伊朗系统的俾路支人和阿富汗人，俾路支地处印度河西的沙漠，是很贫穷的一块地，一直有一群土邦组织反对武装不满政府，所以当年苏联入侵阿富汗就是因为巴基斯坦给阿富汗提供了补给线，苏联就支援了这个俾路支武装，骚扰巴基斯坦。阿富汗不愧帝国坟场，苏联解体之后，美国又为了获得塔利班的情报，又开始支援这个俾路支武装。这个俾路支武装很多次把中巴关系当做是巴基斯坦政府的软肋，对当地中方企业工程展开了多次袭击，当然也包括这次事件。包括前段时间阿富汗内战时候，为了在巴基斯坦跟阿富汗关系上搞事，还在中国一带一路的工程上搞自杀式袭击。

有个很搞笑的事，俾路支一直把民族挂在嘴上，说要独立。但是这片土地上真正互相开打的，基本上都是同种族的人。所以比起我们的血脉，或许还真是我们选择的大地才真正主宰了我们未来的命运吧。

张涛 - 某一天，中国真会超过美国吗？

2022-03-30

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/stickies/2022/03/30/01

最近一直在苦苦思考这个问题：会不会我们所说的某一天，永远都不会到来？
哪一天呢？
很长一段时间，很多国内国外的媒体，一直在说一件事：再给中国一点时间，再给中国一个战略机遇期，中国就会超越美国，成为世界第一经济大国，就会登顶了。

这些年，这方面炒作很多。
记得不知道是2018，还是2019年时，国际货币基金组织给出的报告是：2030年左右，中国的GDP将实现对美国的赶超，上升为全球第一名。
后来，疫情来了。
又有种说法，说中国会在2024年，就超越美国，成为世界第一经济大国。
我们国内专家要谦虚一点，前段时间，有人说：中国在2028年到2030年，将可能超越美国，成为世界第一大经济体。
但不管哪种说法，都是建立一个基础上的：总有一天，中国的GDP会超越美国，成为世界第一大经济强国。
对绝大多数人来说，这可能已经成为一种信仰。
未来就在招手。

但我们不妨思考另一个问题：万一这一天永远不会到来呢？
我之所以会这么想，是因为看到这条新闻：中国决定向斯里兰卡提供2000吨大米作为紧急粮食援助。
据中国驻科伦坡大使馆介绍，此次捐赠价值约250万美元（含运费），是应斯里兰卡政府要求，鉴于该岛国目前面临粮食短缺的困境而提出的。
看上去，这件事好像没什么，中国又多了一个朋友啊。
但如果你细想一下，就会发现不对劲：这个世界的老大，是美国啊。现在这个世界体系是美国人创建的，也是美国人在维护的，当然美国人也是最大的受益者。一个国家发生粮食短缺，是对美国所创建的国际体系的一种冲击，作为这个体系最大的受益者，应该是美国人最着急才对啊。

还可以再思考另一件事：
疫情刚爆发时，中国人在干嘛，在拼命防疫。
拼命防疫为了什么？为了早日复工复产。
为什么要复工复产，是因为如果我们不复工复产，那会有很多工人失业，他们都是要养家糊口的嘛。所以为了他们，各级政府都非常努力。结果疫情控制住了，复工复产也搞得很不错。
但同时美国人在干嘛？
他们主要干两件事：

第一件事：很多美国人在家里蹲，拿政府补贴拿到手软。美国全面开动了核动力印钞机，这大家都知道的嘛！
第二件事：进口中国，当然还有全世界的商品。

所以，我们这么努力，为的是什么？
过去，美国人还给我们一张绿纸，现在连绿纸都不用给了，直接在我们的账户上加一点数字就行了。
这种数字，归根结底，就是一张欠条。
只有把它花掉时，才有价值，如果没花掉，连废纸都不如，因为它只是银行账户上的一串数字。
所以，中国有钱没钱，是中国说了算吗？
不是。
其实是美国说了算。

所以看数字，有很多让人疑惑不解之处。
比如说钢铁这种东西，总是重要的工业品吧？
2020年，中国产量10.65亿吨，占全球56.71%；美国钢铁产量7268万吨，在全球产量中占比3.87%。
再来比粮食，我之前说过，光论农业，美国的地理条件比中国好太多。 2020年，全球粮食产量中国也是第一，6.57亿吨，美国呢，则是第二，5.98亿吨。
粮食还算差距最小的。
美国强过中国的，可能也就是石油、天然气了。
更别说，你要是走遍全世界，只怕货架上最多看到的，还是中国商品，全世界不到200个国家，但中国已经是120个国家及地区的第一大贸易伙伴，而且几乎世界上数得着的国家，中国都和它们是第一大贸易伙伴。

这说明什么？
说明中国早就是世界第一大经济体了呀。
但在去年，美国的 GDP 是23.02万亿美元，增长了5.6%；中国呢，则是17.73万亿美元，增长了8.1%。
8.1%，这个数字不低；但美国的5.6%，涨得可也不低啊。
这不是偶然现象。

上一张图：中美经济历年增长对比图。

有没有发现这么一个现象：大约从2010年起，中国和美国的经济增长，就出现了一个非常奇怪的现象：中国涨得快，美国也涨得快；中国涨得慢，美国也涨得慢。
渐渐地，差不多玩成了两条平行线。所以这是个非常不对劲的情况。
伴随着这种情况，还有一个更奇怪的现象。
如果把全世界比作一家企业，老板是美国，中国、日本和欧洲就很像中层管理者，底层则是众多的发展中国家。
照道理说，美国是企业的老板，也是最大的受益者，它应该最关心这个世界。

美国不是这样。老板三天两头搞七搞八，一副不务正业，要把公司搞散架的模样。
这时候，企业中层就慌了：公司垮了，该怎么办呢?我可是从底层干起，一直到现在，都是在这家公司的啊。公司倒了，我吃什么呢?这时候中层就会非常努力，比老板还在意公司的生存和死活。因为他们手头已经有了一点东西，很害怕损失掉。
底层员工，反而无所谓，反正到哪里都是打工。
中国的困境就在于：其实整家公司，技术开发不少是靠你，产品线大部分也是你在做，销售也大部分靠你。中国本来早就可以跳出来去干，自己当老板，从此天大地大。

但中国整体非常犹豫。就像很多现实中的企业中层一样，走到这一步不容易啊，如果自己干，还得冒着很大的风险，很多人会犹豫来犹豫去，有时候差点话要说出口了，辞职信要递出去啊，但一想到房贷，一想到车贷，一想到老婆孩子，就又把头缩回去了。
因为不愿意冒这种风险，所以很多时候，现实中很多企业中层本来明明有自立的能力和本钱，却还是本着“老板虐我一千遍，我待老板如初恋”的心态，老是想着“公司是我家，发展靠大家”的心态，整天勤勤恳恳，像老黄牛一样，竭力顶住老板的破坏，坚决维持着公司的正常运转。这和我们在2020年疫情发生时，全民严防死守，抓紧防疫。
等疫情一消退，立即投入生产，然后排出一队队的医疗队，带着物资，带着设备，跑到全世界各国去帮助当地人，是不是很有点像？
甚至连美国的医疗设备、防护用品，也基本都是中国提供的。
是不是很像不少公司里那个最赚钱、最能干，基本公司就靠它顶起大半个天的那种部门？

很多人都觉得：这种部门，老板一定很重视，会巴结着它。
但只要你在公司里呆过，就应该知道——其实不会。
真实情况是：老板对这种部门的头头，是充满了猜疑和嫉妒，恨不得找出一切机会，把他做掉。
所以直到现在，美国是一边拿着中国的东西，一边有事没事就制裁中国一下。
其他的中层，会怎么反应呢？
他们的部门不重要，很多人甚至只是因为公司在，他们才能过上中层的生活。
对他们来说，公司就显得特别重要，因为公司没了，他们就啥也不是了。
所以在这种时候，不管那个主要的部门有多么重要，不管他们心里有多明白，但为了自己的利益，他们肯定会站在老板那一边，有时候甚至老板一施眼色，他们就会跟着，甚至为了让老板更看得起自己，会像疯狗一样，去骂那个支撑起公司的顶梁柱中层。

2020中国远赴意大利抗疫

想想看，这些年欧洲人对中国的态度，是不是就像这些没啥用的中层？所以，2020年疫情后，我们看到：其实欧洲人也在疯狂印欧元，然后用这些废纸，来买中国的产品和医护用品。
他们一边拿着中国生产的东西，一边跟着老大，疯狂臭骂中国。
最典型的，就是西域问题。
换句话说，是因为有某个特别能干的部门，老板才可以啥事不管，一边捣蛋还能一边拿到最大利益，其他部门中层也能因此分沾雨露，虽然它们对公司的贡献，其实非常小。
最苦的人，就是这个部门的中层，还有整个部门的人。
因为他们要扛着整个公司。
他们还得忍受着老板的羞辱，以及其他部门的人因为老板指使，而进行的羞辱。
压力巨大。而且自从疫情以来，明明世界更依赖中国，但中国人却觉得压力更加巨大，甚至还创造出一个名词：卷。

确实非常卷。这就奇怪了：中国生产了这么多东西，中国人比以前更勤劳了，世界也更依赖中国了，中国人不是应该享受到更美好的生活吗？为什么在这种一片前途光明时，很多人却感到卷了呢？
原因很简单。
因为疫情之后，要中国这个中层来扛的东西更多了呀。
比如说这次斯里兰卡粮食短缺。
比如说将来还会遇到的其他东西，比如说阿富汗，美国人拍拍屁股走路了，还把阿富汗的外汇储备给吞了，是谁在给阿富汗援助？
很多时候，也是中国啊。
我们会发现：这个能干的中层，在做的很多事情，都是为了维持这个公司，或者世界体系，为了养那个肆无忌惮的老板，为了养那群同为中层的同事。
而且越来越沉重。

其实在这个体系中，我们已经越来越处在盈亏线上，有时在线上，有时在线下，但我们却始终狠不下这个心来。
因为我们的公司，已经习惯了做外贸，换美元或欧元，然后后面再一整套，这种体系和习惯已经形成，如果改变，就会意味着利益的巨大调整。
没有人喜欢风险。

所以，我们就看到了那条中美经济增长率的线。
美国如附骨之蛆，和我们玩起了”齐步走“。
这就是说：它其实在吸我们的血。
只要这条线存在，就意味着其实中国能拿多少，最终是美国说了算的。就像你只要在公司，哪怕公司100%的业务都是你做的，老板说给你多少钱，你还是只能拿多少钱。
这恐怕就是中层管理者的困境。
我们能突破吗？
如果不能突破，前车之鉴已经一大堆。

日本、英国、德国、法国这些中层，早年时也有意气风发时，但它们再意气风发，也只是暂时的，到了一定阶段，就纷纷坠落了。
看他们的人均GDP线，刚开始还挺好看的，越到后来越曲折！
只有美国这个老板，才是日子过得顺风顺水，一直是条平滑斜线。
我们如果不摆脱这个体系，将来也极可能会和他们一样。
俄罗斯和乌克兰之间的这场战火，如果仔细观察的话，会发现很多东西，说不定能给我们更多启发，同样也不断地在拷问我们：这个中层，还值得继续做下去吗？

张涛 - 基于 C++ 的 Android 协程设计

2022-02-26

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/session/2022/02/26/01

这篇文章是我在 2022【T沙龙】技术分享时所讲内容的文字版本，修改删减了演讲时的冗余言语，现免费开放给大家阅读，希望能给买不到票参加分享的开源实验室读者带来帮助。

然后首先有几个问题，第一个：协程是怎么来的？

这个问题其实要追溯到很久以前的一个事情上。long long ago。。。。

当那个时候我们计算机就是个铁块，就一个电脑可能只能去运行一个程序。比方说举个例子，像我们炒菜，一个厨师他去炒菜，那么他在同一时间的时候只能去炒一个菜。
一开始大家想要同一时间执行多个代码任务，于是就有了并发。从程序员的角度可以看成是多个独立的逻辑流，内部可以是多 CPU 并行，也可以是单 CPU 时间分片。

进程就是这样抽象出来个一个概念，搭配虚拟内存、进程表之类，用来管理独立的程序运行、切换。
但是一并发就有上下文切换的问题，干了一半跑去处理另一件事，我这做了一半的东西怎么保存。
就好像我们刚刚那个厨师炒菜的例子，那这个时候就像相当于是同一个厨师，他可以一次炒两个菜。那么这个菜他可能刚刚炒了一半，我放了油，放了盐这些调味品了以后，突然跟我说要我再继续去炒下一个菜，当前这个菜先放到一边。

后来硬件提升了，一电脑上有了好几个 CPU 就可以一人跑一进程，就是所谓的并行。
但是一并行，进程数一高，大部分系统资源就得用于进程切换的状态保存。后来搞出线程的概念，大致意思就是这个地方阻塞了，但我还有其他地方的逻辑流可以计算，不用特别麻烦的切换页表、刷新 TLB，只要把寄存器刷新一遍就行。

但是线程是一个非常麻烦的东西，因为他是操作系统调度的，你可能正在run，不知道什么情况，突然你的CPU就被交给另一个线程了，你就得靠边站，等着下一次翻牌子了。
你没办法决定线程在何时运行，你甚至不能正常停止一个线程。做 Java 的同学应该都知道，线程的停止只能是 run 的内容执行完或者出异常时，当然还有一种会造成死锁的方法就是直接调用stop()。
我们看图，箭头最右侧竖线表示线程已经结束了。由于你在主线程无法知道子线程什么时候开始，什么时候结束，甚至有可能主线程都结束了，子线程还在跑。

就是因为这种情况，后来引入了一个概念，叫用户态线程。
如果你嫌操作系统调度线程有不确定性，不知道什么时候开始什么时候切走，其实是可以自己在进程里面手写代码去管理逻辑调度，这就是用户态线程。
而用户态线程是不可剥夺的，也就是说不会像内核态线程那样，run 着 run 着 CPU 就没了。通常控制权是程序员交给用户的，而用户最了解何时需要放弃执行权，这么做减少了系统切换次数，实现了最高的 CPU 利用率。但是有一个问题，毕竟是模拟的操作系统调度线程，操作系统内核不知道多线程的存在，如果一个用户态线程发生了阻塞，就会造成整个进程阻塞，所以进程需要自己拥有调度线程的能力。

而如果用户态线程将控制权交给进程，让进程调度自己，这就是协程。

接下来是第二个问题：协程真的能提升我们的程序的性能吗？
这也就说到了一个经常会提到的点，就是协程能够提升我们代码的性能。但事实上协程提升的这个性能并不是我们开发的过程中的那种代码的效率，而是协程真正能够提升我们程序的性能的原因，是因为：

大家看到这张图红色的这个位置，它在有一个任务正在被阻塞着，然后它去执行另一个任务。其实这个时候就是一个协程的状态了，它阻塞了一个协程，同时阻塞状态的时候它却调用了另一个协程。那么这个时候实际上阻塞的只是一个协程而已。然后我们的线程依旧是一个顺序执行的状态，也就是它减少了一次线程的切换。

这也就是为什么我们说协程能够提升性能，其实它真正提升性能的原因是让我们的线程不停地跑，让线程一直去跑，减少了线程切换给我们程序带来的一个线程切换的开销，从而达到提升了我们整个程序的性能的原因。

那么除了这一点，协程还有一些其他的优点。

比方说协程的可控制：我们前面讲，线程的结束都没办法由我们程序员通过代码去直接控制它。但是协程是可以的，因为协程其实在我们代码中它的本质就是一个函数，然后函数挂起了以后，我们继续去调用下一个函数，做了一次函数的切换，所以它本质是可以被控制的。
协程的轻量级：网上有很多文章都会讲到这一点，就是协程的轻量级，它占用的资源非常小。回到我们刚刚讲的协程，其实它的本质就是一个函数，如果说只是一个函数的运行的话，那么他当然占用的资源是很小的。
是协程的安全性。我们大家应该都做过多线程开发。多线程开发的时候有一个非常大的问题，就是我们得要考虑数据的线程安全性。而协程其实它的本身是没有并发概念的，就像我们前面介绍的那张图，如果说一个协程发生了阻塞的话，它其实只仍然是在当前线程里面切换到了下一个协程去继续执行它，协程与协程之间的任务都是一个线性的，所以它其实是不具备并发能力的。而如果说真正我们在写代码的时候依然是需要考虑并发现程安全问题，是因为我们现代的编程语言都是有多线程概念的，就算我们没有再发起线程，我们还有一个主线程在继续执行的，所以我们的协程都是运行在线程里面的，那么一定程度上它也具备了多线程的一个并发执行的能力，造成我们不得不应对多线程的数据安全问题。
第四点就是语法糖的优势。对于不同的语言来讲，都有不同的语法糖。几乎所有的具备协程能力的编程语言。比方说像 Python、go、C# 这样的语言。他们对于协程专门做了一层语法糖的封装，可以帮助我们更方便地去书写一个线性的代码。

那么再回到我们今天的一个主题，就是，如果我们自己去设计一个安卓协程库的话我们要怎么去设计呢？

首先一个完整协程库，它所具备的功能应该是启动挂起这两个能力。然后还有线性的能力，比方说我们当前有一个协程，它需要被优先的执行。我们需要能够对这个协程做一个校验，然后同时把前一个协程挂起，最后当前的协程执行完了以后，再继续恢复之前先挂起的那个协程，再继续执行。
这样的这样的一些基本能力我们肯定是得要实现的。而如果要实现这样一些基本的能力的话，我们完整的一个思路肯定是分三步。

第一步协程肯定是运行在线程里面的，所以我们基于 C 语言去构建一个 C 的线程， C 里面有一个 < pthread.h > 的库，它是可以直接帮我们构建在 C 层的线程的， C++ 也可以直接去调用这个库完成一个线程的创建。

构建完线程了以后，就开始构建我们的协程，然后将构建出来的协程交给 C 线程去调度。按顺序去一个一个的执行协程。

第三步就是保证我们协程的一个线性状态。就是当一个协程我们调用它 delay 方法了以后，应该是可以把当前的协程挂起，然后继续去执行接下来的协程的。
另外，对于另一个协程调了他的 join() 方法的话，它应该是可以优先地插入到当前正在执行的这个协程里面，同时打断也就是挂起当前正在执行的协程，然后优先去执行我们插入的这个协程。
当插入的这个协程执行完了以后，然后再恢复之前被挂起的协程，让他继续去执行。

Talking is chip, show me the code。
接下来我们来看代码，这个库其实我之前已经写了一个 demo 是放在了 github 上面，大家可以通过下面的这个链接或者直接扫就能看到这样的一个库。看完记得点个star：
https://github.com/kymjs/AndroidCoroutine

首先第一步是我们要通过在 Java 层定义一个线程的实现，也就是一个线程它所要具备的一些能力。因为我们最终的目标是需要给安卓去使用它，所以我们肯定也是需要通过 JNI 调到 C 层方法的。

首先我们左上角的这个 JNI 入口，这里我们主要看到最下面的一行就是调了 OSThread 的 start() 方法。然后 OSThread 其实对应了我们刚刚在 Java 层声明的那个线程，然后调了他的 start 方法，我们就在 C 层模拟了一个 C++ 的线程，然后去调度 Java 层的线程。
而中间的这一块也就是我们现在看到第二张代码图，这里其实就是一个完整的在 C 层启动一个线程的模板，大家知道一下就行了。

其实前面的线程不是重点，重要的是我们协程的实现。
首先协程在 Java 层，它的定义有两个比较重要的点：第一个是协程需要有一个 async() 方法，我们这段代码的第29行表示我们要执行的这一个协程的协程体就是我们这个协程它的起始状态相有点类似于线程的 start() 方法，大家可以把它理解为线程的 star 方法。
不过 async() 方法执行完了以后，它允许你有一个回调在 await() 里面。
大家都知道 kotlin 里 async() 方法会返回来一个对象，然后这个对象又有一个 await() 方法可以继续执行，这是 kotlin 通过它的一个语言特性，给我们做了一个语法糖封装的。当然在这里我基于 C++ 示例，暂时先不管语法糖的能力。
所以我把 await() 方法定义成了一个回调，也就是这里第 20 行列出来的 onAwait() 方法，也是当 async() 执行完了以后，它是允许响应一个回调结果的，也就是这里的一个结果参数 result。

那么在协程的定义的时候，还有一个比较重要的就是我们要把协程跟一个线程做关联，也就是第 8 行。这里第 8 行有一个线程 threadid 就是它会最终在构造方法里面默认初始化。
构造方案我没有截出来，在第 8-20 行之间，每一次我们协程创建的时候，我默认会关联到当前的线程。如果你不希望用当前的线程去调度它，或者你想自己定义一个或复用已有的线程的话，你只需要把那个线程的 ID 传过来就可以了，然后他就会在这个线程里面去调度当前的协程。

然后协程的实现跟刚刚线程类似，我们主要看 init() 方法和 async() 方法里面。其实在我们所有协程最早的构造方法里面的时候，它会调用这个 init() 方法。然后 init() 方法其实就是把当前的协程跟要调度它的线程做一个关联。
我们看到这里，也就第 51 行。 threads 就是个 map, 我构建了一个全局的 map 去用来存放我们的线程，把这个 map 作为一个线程池，然后通过线程 ID 作为 Key 来取到对应要调度它的线程去执行。然后 53 行就对应的是把我们当前的这个协程交给这个线程去调度了。

在我们整个方法里面，协程是被定义了一个生命周期状态的。
也就是看到我们左下角这里有总共 5 个状态，从 0-4。
0 就是一个协程被最初构建好的时候，它就是默认状态。然后有 suspend 当前这个协程要被挂起了。
然后还有 need resume 表示它已经挂起了。
然后 3 就表示这个协程已经被恢复了，他这个协程可以继续的被执行了。
所以 123 其实是可以循环转换的，是从 1 到 2 再到3，然后再到 1 也是可以的，就这样循环转换。
4 finished 比较好理解，我们当前这个协程已经被执行完了，执行完了以后这个协程应该是要被回收，要被结束了的，就是 finished 状态。

后面我们从这张图上面来看一下我们自己协程的运行原理。首先有两个入口，一个是 init() 第二个是 async()。
我从左边开始讲从 init 开始，最早的时候也就是我们 new 了一个 Java 层的那个 coroutine 对象的时候，它会在构造方法里面调用它的 init 方法。
然后通过 JNI 调到 C 层里面，然后在 JNI 里面会去调用 C 的 start 方法，然后这个 start() 方法会去通过调协程的调度器，然后去在当前的线程里面做一个阻塞态的循环，去不停地通过协程的队列去不停地取协程，取出来了以后，然后开始调度这个协程，让这个协程开始执行。
如果说这个协程是一个待恢复的状态的话，那么就恢复它，然后继续执行。

然后另一边是我们协程的加入assync() 方法,也是一样，从 Java 层调到 C 层，然后它有一个关键点，就 attach() 方法， attach() 会把当前的这个协程和需要调度它的线程做一个关联，把我们当前的这个协程加入到那个调度的线程的队列里面去，然后那个线程就开始调度。这样的一个协程其实就是一个非常经典的生产者和消费者的模型。

然后我们接下来引入下一个概念，就是挂起点。因为我们前面讲了协程是可以随时把一个协程给挂起，挂起完了以后我们继续去执行下一个协程。我们刚才讲的时候，其实是为了让大家理解比较清楚，没有跟大家讲挂起点的这样一个概念。其实协程并不能随便地被挂起，它有一个概念就是挂起点的概念，协程只能在挂起点被挂起和恢复。

这张图是从 kotin 的官网截的一张图，就是他用来讲协程的，大家有兴趣可以去看一下 kotlin 协程的实现。其实他把整个协程的原理讲得非常的清晰，就是在 kotlin 官方的那个文档上面。
我们这里看一下，从 start 到 end 是一整个协程完整的生命周期。然后中间有三个 suspension point。这三个点表示了协程的三个挂起点，协程只能在这三个点里面被挂起，以及被恢复。
然后在第一个挂起点到第二个挂起点之间这样的一个段落，是协程的一个执行体，执行体是不能被中断的。
那回到我们这个例子里面，协程的挂起点是在哪里呢？

我们先还是回到刚才的运行原理图上，看到黄色这一部分，假设我们要对当前的这个协程，我给它调用了一个 delay() 方法，就是要把自己挂起一段时间。那么我们在协程的调度器里，它在执行到这个协程的时候，发现这个协程如果是要被挂起。

我们重点看到左半部分，右半部分现在不需要考虑。然后我们把这个图给拉长，假设当前的这个协程是一个需要被挂起的协程的话，那么我们会先把这个协程从队列里面给取出来。
严格来说这个其实不是一个队列，但你可以把它理解为是一个双向队列，就是我们从协程头里面去取出来一个协程，然后把把它暂存起来。

因为它已经被挂起了，所以我们先把这个挂起的协程给暂存起来，然后同时继续从队列里面去取下一个协程。取到下一个协程了以后，我们再去调度这个。然后把这个协程调度完了以后，我们再把刚刚挂起的那个协程继续给放回当前的队列头，让它放在那里了以后，等到我们当前这个协程执行完了以后，然后再去继续调度下一个那个已经被挂起的协程，然后再去恢复它，让他继续地执行。

然后我们看到刚刚讲的在我们这个库里面的协程的挂起点。其实在我们这个库里面，协程的挂起点只有一个，是因为实现的原因，后面我会给大家讲。
我先讲一下为什么只有一个挂起点，因为我们是基于 C 层去做的。我们先看一下协程的整个逻辑。
在我们这个库里面，协程整个完整的生命周期，是从你调用了协程的 async() 开始，然后通过 Java 的 run() 方法，也就是 Java 层的 coroutine 对象里面的 run() 方法。
然后在 suspend await 这一步是在 C 层里面。
只能有这一个挂起点最主要的原因就是我们在调用在 C 层调用 Java 的时候，我们只能按方法去调用，没办法按语句去调用。如果我们要想在像 kotlin 那个样子，按照语句级别的增加挂起点的话，我们可能需要有两种方式。
第一种是给我们的所有的 Java 代码加入 hook, 也相当于是给每一个语句执行的执行前和执行后去调用一下我们 C 层的代码。
还有一种方式就是我们直接去改 JVM 的代码，因为我们都知道 Java 的 class 它最终在执行的时候都是靠 JVM 一行一行的去解释执行的。所以如果我们从 JVM 层面去改掉它的解释执行的方式，把每条语句结束作为一个挂起点其实也是能实现的。

然后在 C 层我们使用的协程库其实有很多可以选择。比方说像 C++ 20 官方已经内置了协程的能力，但是它内置的那一份协程能力，只提供了一系列协程的基础实现，没有去做成封装成可用的 API 你让你能够调用。所以我猜测可能 C++ 会在马上的 C++ 23 版本里面会对它做一个封装，然后真正给到程序员，让开发者可以去用它的完善的一个调度函数体去直接调度一个协程。

然后第二个其实是 C 库里面提供的一个协程的库，就是它很小，只有两个方法你就可以实现一个协程的能力，就是 setjmp() 和 longjmp() 然后我们这个库也是直接用的，因为这是成本最低的方法。
然后下还有剩下两个是在 github 上面比较出名的。第一个是风云写的一个库叫 Ucontext 这个库它实际上是通过 C 去嵌入了汇编，然后通过汇编去调度，把当前的调用栈给存入寄存器里面，然后再切到下一个调用栈去执行的。但是他有一个问题，他只帮你实现了 x86 和 x64 的 CPU 架构，所以它不能用在移动端上。
然后第四个 libco 它是微信的一个开源库，也是可以用来实现协程能力的库，但是它也是只是用在服务端的，也只提供了 PC 的能力，它的整个实现方案也是参考了那个 Ucontext，后面包括还有一些 libcoevent 也是基于 Ucontext 跟 libco 做的一系列的封装去实现的。

看一下在我们库里面，setjmp库的使用，最主要的就是 39 行和 68 行。
setjmp() 有一个参数是一个指针，就是用来保存协程当前的运行上下文信息，恢复这个协程的时候也是通过这个指针恢复。
longjmp() 就是恢复时调用的，第一个参数就是指针位置，第二个是设置setjmp的返回值，在 C 里面，int 是可以做条件判断的非零即真，代码里传个 1 相当于 setjmp 会返回 true。

最后还有坑需要填的，其实说是坑，其实也就是todo项：

第一个，我们目前是没有类似于 kotlin 那样的一个回调语法的，所以我们现在 await 是用的典型的就是回调语法去做的， onAwait() 方法去实现的。后面其实我们是可以基于 kotlin 的 suspend 关键字，就是如果大家了解的话应该知道，suspend 其实也是 kotlinc 在编译期的时候做的一次语法翻译，他帮你在每一个方法编译以后，给这个方法在最后一个参数上面多插入了一个参数，这个参数其实就是一个用作回调的 callback。
第二个就是刚刚跟大家讲到了为什么只有一个挂起点的原因。因为 JVM 层的语法级别去实现，挂起点的这样能力开发起来太难了。就正常来说，对于一个普通的开发者是没办法去做到的。而如果用 hook，又会造成频繁 JNI 调用，影响性能。
然后第三个点是一个 IO 中断，前面跟大家讲在某一个协程发生阻塞的时候，我们应该是能够调度另一个协程去，然后把当前这个正在 IO 的协程给挂起的。这一点其实在 C 层是可以通过信号量去完成的。
如果大家对于以上几个 todo 项感兴趣，也可以扫右上角的二维码，加入微信群，我们一起把遗留的几个点完善掉。

张涛 - Gradle 6.X 上传 aar 到 Nexus 私服

2021-02-02

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/pay/2021/02/02/01

昨天把 gradle 升级到 6.0 以后，发现这傻逼的 google 又直接干 API，以前上报的全部脚本都没法用了。我们原先上报一个 aar，是直接引入

apply plugin: 'maven'

结果新版本直接这个插件都被干掉了，看了官网文档以后才知道，换成了

apply plugin: 'maven-publish'

然后里面的API也全换掉了。

解决 sourcesJar Task 过时

然后 sourcesJar 的 task 也报了个警告，说classifier已经过时了，以前代码是这样写的：

task sourcesJar(type: Jar) {
    classifier = 'sources'
}

这个好解决，看一眼源码,要用 archiveClassifier 去替代：

/**
 * Sets the classifier.
 *
 * @deprecated Use {@link #getArchiveClassifier()}
 */
@Deprecated
public void setClassifier(@Nullable String classifier) {
    // This is used by the Kotlin plugin, we should upstream a fix to avoid this API first.
    // DeprecationLogger.deprecateProperty(AbstractArchiveTask.class, "classifier").replaceWith("archiveClassifier").withDslReference().nagUser();
    archiveClassifier.convention(classifier);
    archiveClassifier.set(classifier);
}

内部就是做了个代理，改成了新API，就解决了。

task sourcesJar(type: Jar) {
    archiveClassifier.convention('sources')
    archiveClassifier.set('sources')
}

本文为付费文章，订阅用户请访问小专栏查阅 https://xiaozhuanlan.com/topic/1892435067

张涛 - 自定义C/C++日志输出函数

2020-08-07

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/code/2020/08/07/01

在繁杂的项目中，日志打印必不可少。但是编写打印的工作，有时候是无趣的、繁琐的、浪费精力的。
如何能够快速、方便的编写打印；如何清晰、准确的定位；如何简单并优雅的实现；最后才能让我们摆脱这样枯燥的、重复的工作？
网上有很多强大的日志类工具，我也都使用过一些，有时候也并没有理想中的方便。今天我想分享给大家的一套我自己的解决方案。

C++ 中标准输出方式

对于单个变量输出，可以如下方式：

int delay = 5;
std::cout << "delay:" << delay << std::endl;

对于多变量信息输出则需要如下方式：

#include <iostream>
using namespace std;

int main(int argc, char **argv)
{
    char *Name = "Bill";
    int Age = 10;
    float Score = 86.5;
    float Height = 121.3;
    float Body_Weight = 36;

    std::cout << "Name:" << Name << ", "
              << "Age:" << Age << ", "
              << "Score:" << Score << ", "
              << "Height:" << Height << ", "
              << "Body_Weight:" << Body_Weight << std::endl;
}

问题的提出

大家可以看见，需要添加很多对应变量名的字符串，导致写一次打印，非常耗时间。
我一直在想有没有更好的解决方案，形如 logOut(a, b, c, d); 这样简单方便的输出方式?
最后经过不断探索终于找到了一份这样的解决方案，而且只需要加入一个头文件即可，代码如下：

#include "logger.h"

int main(int argc, char **argv)
{
    char *Name = "Bill";
    int Age = 10;
    float Score = 86.5;
    float Height = 121.3;
    float Body_Weight = 36;

    logDebug(Name, Age, Score, Height, Body_Weight);
}

输出结果：

DEBUG [..\cppdemo\main.cpp@main#11]Name:Bill, Age:10, Score:86.5, Height:121.3, Body_Weight:36

大家可能注意到了，背景图的内容就是这个，还有Info、Warn、Error并对应不同颜色输出。

如何实现

那么对于以上效果，如何才能实现呢？
下面我将带领大家一步一步讲解我的心路历程与解决方案。这样也容易让大家了理解其中原理。

单个变量的实现

究其根本，就是减少对变量名称字符串的输入，但是打印的时候能够对应显示，便于我们分析。
对于单个变量，我很早就想到，用过宏“#”就可以轻松实现。

宏 “#” 的妙用

如果熟悉c++宏的小伙伴，可能知道里面有个“#”的用法，可以将对应的参数变成字符串，效果如下：

#define  toStr(x)  #x

char *str = toStr(hello);  
//  等价于 
char *str = "hello";

那么对于单个变量最简单的宏实现方式就是：

#define logs(x)  std::cout << #x":" << x << std::endl;

...

int delay = 5;
int other = 3;

logs(delay);
logs(other);

输出结果：

delay:5
other:3

显示文件名、函数、行号

对于想要显示文件位置信息，c++中也有对应的宏，分别是 __FILE__、 __FUNCTION__、 __LINE__ ；
只需要做如下改动即可。

#define FILE_INFO   "[" << __FILE__ << '@' << __FUNCTION__ << '#' << __LINE__  << "]"
#define logs(x)     std::cout << FILE_INFO << #x":" << x << std::endl

...

int delay = 5;
int other = 3;

logs(delay);
logs(other);

输出结果：

[..\cppdemo\main.cpp@main#21]delay:5
[..\cppdemo\main.cpp@main#22]other:3

设置打印颜色

大家都知道在Linux使用 ls 命令列出文件列表时，不同的文件类型会用不同的颜色显示。那么如何实现这样带颜色的文本输出呢？
在bash中，通常我们可以使用echo命令加-e选项输出各种颜色的文本，例如：

echo -e "\033[31mRed Text\033[0m"
echo -e "\033[32mGreen Text\033[0m"
echo -e "\033[33mYellow Text\033[0m"
echo -e "\033[34mBlue Text\033[0m"
echo -e "\033[35mMagenta Text\033[0m"
echo -e "\033[36mCyan Text\033[0m"

其中：”\033[31m”、”\033[31m”、”\033[0m”等是ANSI转义序列（ANSI escape code/sequence），它控制文本输出的格式、颜色等。

格式 : 
 \033[显示方式;字体颜色;背景颜色m 中间是变颜色的内容 \033[0m

其中各个参数意义如下：

字体色            背景色           颜色
---------------------------------------------
              40              黑色
              41              红色
              42              绿色
              43              黃色
              44              蓝色
              45              紫红色
              46              青蓝色
              47              白色

显示方式           意义
-----------------------------------
              终端默认设置
              高亮显示
              使用下划线
              闪烁
              反白显示
              不可见

那么添加颜色就可以如下处理：

#define OUT_RED     "\033[0;31;1m"
#define OUT_GREEN   "\033[0;32;1m"
#define OUT_END     "\033[0m"

#define FILE_INFO       "[" << __FILE__ << '@' << __FUNCTION__ << '#' << __LINE__  << "]"
#define logRed(x)       std::cout << OUT_RED << FILE_INFO << #x":" << x << OUT_END << std::endl
#define logGreen(x)     std::cout << OUT_GREEN << FILE_INFO << #x":" << x << OUT_END << std::endl

...

int delay = 5;
int other = 3;

logRed(delay);
logGreen(other);

多个变量的实现

最后一个问题，在多变量的时候，如何输出呢？
对于多变量的输出，就是要弄清楚究竟有多少个变要输出，这样就可以扩展宏，进行足个输出即可。

最简单的方案

非常傻瓜的方式可以直接如下：

#define logs1(a)       std::cout << OUT_GREEN << FILE_INFO << #a":" << a << OUT_END << std::endl
#define logs2(a,b)     std::cout << OUT_GREEN << FILE_INFO << #a":" << a << ", "#b":" << b << OUT_END << std::endl
#define logs3(a,b,c)   std::cout << OUT_GREEN << FILE_INFO << #a":" << a << ", "#b":" << b << ", "#c":" << c << OUT_END << std::endl
#define logs4...
#define logs5...
...

int one = 5;
int two = 3;
int three = 2;

logs1(one);
logs2(one, two);
logs3(one, two, three);

即多少个变量，对应用哪一个函数输出；由于宏不能够重载，所以不能用相同的名字！
但是这种方式有如下几个问题：

输出函数名称会很多。
还要数参数个数，与函数名对应。
如果想要不同颜色输出，则又要添加新的函数名。

计算参数个数

因为C/C++多参数输入，可以直接用 “…”代替，比如常见的 printf 函数就是如此！原型如下：

int __cdecl printf(const char * _Format,...);

只要我们能够动态计算出参数个数，就可以通过映射的方式，绑定到对应参数数目的输出函数上面。
那么如何计算呢？
经过苦苦查找，让我找到如下的方式：

#define ARG_COUNT_PRIVATE(_0,  _1,  _2,  _3,  _4,  _5,  _6,  _7,  _8, N, ...) N
#define ARG_COUNT(...)      ARG_COUNT_PRIVATE(0, __VA_ARGS__, 8,  7,  6,  5,  4,  3,  2,  1,  0)

#define FILE_INFO   "[" << __FILE__ << '@' << __FUNCTION__ << '#' << __LINE__  << "]"
#define logs(a)       std::cout << OUT_GREEN << FILE_INFO << #a":" << a << OUT_END << std::endl

...

int one = 5;
int two = 3;
int three = 2;

logs(ARG_COUNT(one));
logs(ARG_COUNT(one, two));
logs(ARG_COUNT(one, two, three));

输出结果：

[..\cppdemo\main.cpp@main#30]ARG_COUNT(one):1
[..\cppdemo\main.cpp@main#31]ARG_COUNT(one, two):2
[..\cppdemo\main.cpp@main#32]ARG_COUNT(one, two, three):3

然后只要我们在用C++宏里面的 “##”进行连接，就可以将 logs ## Num 变成对应的函数。

最后的源码

所有的问题都已经解决了，那么最后的代码就如下了。

#ifndef LOGGER_H
#define LOGGER_H

///================= package define =====================
#define ARG_COUNT_PRIVATE(\
     _0,  _1,  _2,  _3,  _4,  _5,  _6,  _7,  _8,  _9, \
    _10, _11, _12, _13, _14, _15, _16, _17, _18, _19, \
    _20, _21, _22, _23, _24, _25, _26, _27, _28, _29, \
    _30, _31, _32, _33, _34, _35, _36, _37, _38, _39, \
    _40, _41, _42, _43, _44, _45, _46, _47, _48, _49, \
    _50, _51, _52, _53, _54, _55, _56, _57, _58, _59, \
    _60, _61, _62, _63, _64, N, ...) N

#define ARG_COUNT(...)      ARG_COUNT_PRIVATE(0, __VA_ARGS__,\
    64, 63, 62, 61, 60, \
    59, 58, 57, 56, 55, 54, 53, 52, 51, 50, \
    49, 48, 47, 46, 45, 44, 43, 42, 41, 40, \
    39, 38, 37, 36, 35, 34, 33, 32, 31, 30, \
    29, 28, 27, 26, 25, 24, 23, 22, 21, 20, \
    19, 18, 17, 16, 15, 14, 13, 12, 11, 10, \
     9,  8,  7,  6,  5,  4,  3,  2,  1,  0)

#define FUN_COUNT_GLUE(M,count)     M##count
#define FUN_JOIN_COUNT(M,count)     FUN_COUNT_GLUE(M,count)
#define FUN_JOIN_ARGS(x, y)     x y

#define CallSomeOne(fn, ...)    FUN_JOIN_ARGS(FUN_JOIN_COUNT(fn, ARG_COUNT(__VA_ARGS__)), (__VA_ARGS__))

///================= logger =====================
///  日志输出
///
#if defined QS_LOG
#include "QsLog.h"
#define PR QLOG_INFO() // QsLog 输出（一个用Qt封装的日志类，挺好用的，在此推荐一下）
#define ENDL ""
#elif defined QT_CORE_LIB  // Qt 标准输出
#include <QDebug>
#define PR qDebug()
#define ENDL ""
#elif defined __cplusplus
#include <iostream>
using namespace std;
#define PR std::cout
#define ENDL std::endl
#endif

#define OUT_RED     "\033[0;31;1m"
#define OUT_GREEN   "\033[0;32;1m"
#define OUT_YELLOW  "\033[0;33;1m"
#define OUT_BLUE    "\033[0;34;1m"
#define OUT_END     "\033[0m"

#define FILE_INFO   "[" << __FILE__ << '@' << __FUNCTION__ << '#' << __LINE__  << "]"

#define param1(a)               #a":" << a
#define param2(a,b)             #a":" << a << ", "#b":" << b
#define param3(a,b,c)           #a":" << a << ", "#b":" << b << ", "#c":" << c
#define param4(a,b,c,d)         #a":" << a << ", "#b":" << b << ", "#c":" << c << ", "#d":" << d

#define pr0()           "null param out"
#define pr1(...)        param1(__VA_ARGS__)
#define pr2(...)        param2(__VA_ARGS__)
#define pr3(...)        param3(__VA_ARGS__)
#define pr4(...)        param4(__VA_ARGS__)

#define pr5(a,b,c,d,e)              pr3(a,b,c) << ", " << param2(d,e)
#define pr6(a,b,c,d,e,f)            pr3(a,b,c) << ", " << param3(d,e,f)
#define pr7(a,b,c,d,e,f,g)          pr4(a,b,c,d) << ", " << param3(e,f,g)
#define pr8(a,b,c,d,e,f,g,h)        pr4(a,b,c,d) << ", " << param4(e,f,g,h)
#define pr9(a,b,c,d,e,f,g,h,i)      pr8(a,b,c,d,e,f,g,h) << ", " << param1(i)
#define pr10(a,b,c,d,e,f,g,h,i,j)   pr9(a,b,c,d,e,f,g,h,i) << ", " << param1(j)
//....  有兴趣大家可以继续扩充

#define logStr(x)       PR << FILE_INFO << x << ENDL  // 原样输出，无需格式化

#define logDebug(...)   PR << ""         << "DEBUG " << FILE_INFO << CallSomeOne(pr, __VA_ARGS__) << ENDL
#define logInfo(...)    PR << OUT_GREEN  << "INFO  " << FILE_INFO << CallSomeOne(pr, __VA_ARGS__) << OUT_END << ENDL
#define logWarn(...)    PR << OUT_YELLOW << "WARN  " << FILE_INFO << CallSomeOne(pr, __VA_ARGS__) << OUT_END << ENDL
#define logError(...)   PR << OUT_RED    << "ERROR " << FILE_INFO << CallSomeOne(pr, __VA_ARGS__) << OUT_END << ENDL
#endif // LOGGER_H

总结

由于受到工作方向的影响，有很多用法被局限在我们日常的工作方向中，不能很好的做出符合大家各自场景的东西。然而我觉得学习，除了学到东西，更应该获取的是思维方式。我的砖就抛到这里，希望对你们有用。接下来的路就请各位小伙伴们自己走了！

张涛 - 扁平化管理，就是管理者的失职

2020-06-29

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/pay/2020/06/29/01

奉劝大家一句：千万不要想不开跑去小公司，尤其是在大厂已经做到高P的，即便小公司给你的许诺更好。因为在小公司呆久了你会发现只可能有两种变化，要么脾气会变的越来越暴躁，要么整个人变得越来越佛系。

本文为付费文章，订阅用户请访问小专栏查阅 https://xiaozhuanlan.com/topic/9078324651

张涛 - 再聊 Git Flow

2020-05-29

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/manager/2020/05/29/01

最近定了一些团队标准的东西，刚好聊到了 Git Flow 这个事，可以拿出来分享一下。

分支应用情境

根据 Git Flow 的建议，主要的分支有 master、develop、hotfix、release 以及 feature 这五种分支，各种分支负责不同的功能。其中 Master 以及 Develop 这两个分支又被称作长期分支，因为他们会一直存活在整个 Git Flow 里，而其它的分支大多会因任务结束而被刪除。

Master 分支

主要是用来放稳定、随时可上线的版本。这个分支的来源只能从别的分支合并过来，开发者不会直接 Commit 到这个分支。因为是稳定版本，所以通常也会在这个分支上的 Commit 上打上版本号 tag。

每个版本发布完，develop 会合并到 master，并打tag。

Develop 分支

这个分支主要是所有开发的基础分支，当要新增功能的时候，所有的 Feature 分支都是从这个分支切出去的。而 Feature 分支的功能完成后，也都会合并回来这个分支。

开发过程中的稳定分支，develop分支应该保证每次最新的commit都是可以被run的。

Hotfix 分支

当线上产品发生紧急问题的时候，会从 Master 分支开一个 Hotfix 分支出来进行修复，Hotfix 分支修复完成之后，会合并回 Master 分支，也同时会合并一份到 Develop 分支。

为什么要合并回 Develop 分支？如果不这么做，等到时候 Develop 分支完成并且合并回 Master 分支的时候，那个问题就又再次出现了。

那为什么一开始不从 Develop 分支切出来修？因为 Develop 分支的功能可能尚在开发中，这时候硬是要从这里切出去修再合并回 Master 分支，只会造成更大的灾难。

其实在我们公司，hotfix 分支基本用不着，一方面是很少有紧急bug要修复，另一方面是Google Play，禁止动态下发。

Release 分支

当认为 Develop 分支够成熟了，就可以把 Develop 分支合并到 Release 分支，在这边进行算是上线前的最后测试。测试完成后，Release 分支将会同时合并到 Master 以及 Develop 这两个分支上。 Master 分支是上线版本，而合并回 Develop 分支的目的，是因为可能在 Release 分支上还会测到并修正一些问题，所以需要跟 Develop 分支同步，免得之后的版本又再度出现同样的问题。

其实正常的做法应该是提测，或测试到某个阶段以后使用。但是目前我们一般用在多版本并行开发的时候，充当特定版本的develop 分支使用

Feature 分支

当要开始新增功能的时候，就是使用 Feature 分支的时候了。 Feature 分支都是从 Develop 分支来的，完成之后会再并回 Develop 分支。

目前feature分支起名规则以 dev_ 开头，后面跟当前开发功能

分支提交与合并

如果 feature 需要 develop 的功能，不要将 develop 分支 merge 到 feature 分支，应该使用 feature rebase develop

分支提交使用 rebase 或 merge 方式都可以，一般来说commit 少的场景我会比较喜欢 rebase，但如果commit攒的多了，rebase 解决冲突会很累。

rebase 操作：

例如，开始开发时，分支是这样的

* -- * -- A (develop)
           \
            * (dev_xxx)

开发完成，准备提交时：

* -- * -- A -- B -- C -- D -- E (develop)
           \
            * -- X -- Y -- Z (dev_xxx)

命令行步骤如下（GUI参考命令行执行对应操作）

git add .

git commit -m "xxx"

git pull  //用于更新远端分支(git fetch 也可以)

git rebase origin/develop //将当前分支base变为develop 的最新 commit

这一步的实际原理是，git会从develop新开一个分支，将你当前的dev_xxx 分支的 commit 按照提交顺序挨个 cherry-pick 到新开分支上

这一步执行过程中如果 develop 的 B C D E等commit 与 X Y Z 冲突，则需要依次解决冲突

解决冲突以后，执行 git rebase --continue 或者 git rebase --skip 继续执行接下来的 rebase

rebase 结束后，分支结构将变为：

* -- * -- A -- B -- C -- D -- E (develop)
                               \
                                 -- * -- X -- Y -- Z (dev_xxx)

然后需要执行

git push -f // 必须加 -f 强制推送，否则由于本地分支的base与远端不一致，会报需要 git pull 无法提交

提交完成后去 gitlab 创建 merge request，走正常 review 流程，合并代码。

张涛 - Flutter 设置控件是否可见

2020-03-19

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/note/2020/03/19/01

共有两种实现比较简单的方式

第一种比较好理解，将一个控件的透明度设置成0，达到隐藏的目的。

class _HideAndShowPageState extends State<HideAndShowPage> {
bool visible = true;

@override
Widget build(BuildContext context) {
  return new Scaffold(
    appBar: new AppBar(
      title: new Text('widget显示与隐藏'),
      centerTitle: true,
    ),
    body: new ListView(
      children: <Widget>[
        new Padding(
          padding: const EdgeInsets.only(left: 10.0, top: 10.0, right: 10.0),
          child: new RaisedButton(
              textColor: Colors.black,
              child: new Text(visible ? '隐藏B    显示A' : '隐藏A   显示B'),
              onPressed: () {
                visible = !visible;
                setState(() {});
              }),
        ),
        new Padding(
          padding: const EdgeInsets.only(left: 10.0, top: 10.0, right: 10.0),
          child: new Stack(
            children: <Widget>[
              new TestAWidget(
                visible: visible,
              ),
              new TestBWidget(
                visible: !visible,
              ),
            ],
          ),
        ),
      ],
    ),
  );
}
}

class TestAWidget extends StatelessWidget {
final bool visible;

const TestAWidget({Key key, this.visible}) : super(key: key);

@override
Widget build(BuildContext context) {
  return AnimatedOpacity(
    duration: Duration(milliseconds: 300),
    opacity: visible ? 1.0 : 0.0,
    child: new Container(
      color: Colors.blue,
      height: 100.0,
      child: new Center(
        child: new Text('TestAWidget'),
      ),
    ),
  );
}
}

class TestBWidget extends StatelessWidget {
final bool visible;

const TestBWidget({Key key, this.visible}) : super(key: key);

@override
Widget build(BuildContext context) {
  return AnimatedOpacity(
    duration: Duration(milliseconds: 300),
    opacity: visible ? 1.0 : 0.0,
    child: new Container(
      color: Colors.green,
      height: 100.0,
      child: new Center(
        child: new Text('TestBWidget'),
      ),
    ),
  );
}
}

第二种办法是使用 SDK 自带的 Offstage 控件包裹。

offstage的布局行为完全取决于 offstate 参数,offstage 默认为 true ,不显示;

当 offstage 为 true,child 不会绘制到屏幕上,不会响应点击事件,也不会占用空间; 当 offstage 为 false,child 绘制到屏幕上; 注意,当 offstage 不可见,如果 child 有动画,应该手动停止动画, offstage 不会停止动画;

class TestCWidget extends StatelessWidget {
 final bool visible;

 const TestCWidget({Key key, this.visible}) : super(key: key);

 @override
 Widget build(BuildContext context) {
   return new Offstage(
     offstage: visible,
     child:new Container(
       color: Colors.orange,
       height: 100.0,
       child: new Center(
         child: new Text('TestCWidget'),
       ),
     ),
   );
 }
}

张涛 - Flutter 线性布局：Column 和 Row

2020-03-18

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/note/2020/03/18/01

mainAxisSize：　　控制自己的布局方式
　　MainAxisSize.min　　默认值，Column和Row自适应children；
　　MainAxisSize.max　　Column填充父控件竖屏，Row填充父控件横屏；需要搭配MainAxisAlignment使用才有效果；

mainAxisAlignment：　　控制子集的对齐方式，Column上下对齐，Row左右对齐
　　MainAxisAlignment.start　　默认值，Column靠上，Row靠左；
　　MainAxisAlignment.center　　Column,Row居中；
　　MainAxisAlignment.end　　Column靠下，Row靠右；
　　MainAxisAlignment.spaceAround　　自己填充，等份分配空间给子集，子集各自居中对齐；
　　MainAxisAlignment.spaceBetween　　自己填充，等份分配空间给子集，子集两侧对齐；
　　MainAxisAlignment.spaceEvenly　　自己填充，等份分配空间给子集，子集同一中线居中对齐；
　　注：当设置MainAxisSize.max时才该值有效果。

crossAxisAlignment：　　　控制子集各自的对齐方式，Column左右对齐，Row上下对齐
　　CrossAxisAlignment.strech 　Column中会使子控件宽度调到最大，Row则使子控件高度调到最大
　　CrossAxisAlignment.start　　　 Column中会使子控件向左对齐，Row中会使子控件向上对齐
　　CrossAxisAlignment.center　　　默认值，子控件居中
　　CrossAxisAlignment.end　　　　Column中会使子控件向右对齐，Row中会使子控件向下对齐
　　CrossAxisAlignment.baseline　　按文本水平线对齐。与TextBaseline搭配使用

textBaseline：
　　TextBaseline.alphabetic　　用于对齐字母字符底部的水平线。
　　TextBaseline.ideographic　　用于对齐表意字符的水平线。

verticalDirection：　　控制子控件对齐方式是否相反方式
　　VerticalDirection.down　　默认值，按照默认方式
　　VerticalDirection.up　　　CrossAxisAlignment.start跟CrossAxisAlignment.end对反

张涛 - 开源一段 Mac 批量压缩图片的脚本

2020-03-17

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/note/2020/03/17/01

近日处理了一批照片，现在分享一下如何在mac平台进行图片批量处理。

0、安装 xCode 命令行工具，需要确定电脑上已经安装了 xCode，如果没有，自己去 AppStore 里面搜索就看到了。

打开终端，输入命令：

xcode-select --install

如果看到如下提示，表示已经安装了

xcode-select: error: command line tools are already installed, use "Software Update" to install updates  

1、安装brew：

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2、使用 brew 安装 imagemagick

brew install imagemagick

3、去桌面新建一个 zip.sh 的文件，里面写入

#!/bin/bash
# 查找目录及子目录的图片文件(jpg,gif,png)，将大于某值的图片进行压缩处理
# Config
folderPath=$1   # 图片目录路径

maxSize='200'    # 图片尺寸允许值
maxWidth=600   # 图片最大宽度
maxHeight=500  # 图片最大高度
quality=60      # 图片质量


# 压缩处理
# Param $folderPath 图片目录
function compress(){

    folderPath=$1

    if [ -d "$folderPath" ]; then

        for file in $(find "$folderPath" \( -name "*.jpg" -or -name "*.jpeg" -or -name "*.gif" -or -name "*.png" \) -type f -size +"$maxSize" ); do

            echo $file

            # 调用imagemagick resize图片
            $(convert -resize "$maxWidth"x"$maxHeight" "$file" -quality "$quality" -colorspace sRGB "$file")

        done

    else
        echo "$folderPath 不存在"
    fi
}

# 执行compress
compress "$folderPath"

exit 0

4、给脚本执行权限

cd ~/Desktop

chmod a+x  zip.sh

5、可以压缩图片了，下面命令的path替换成你要压缩的图片文件夹路径

cd ~/Desktop
./zip.sh  path

张涛 - Leader 的自我修养——学会预测

2020-03-15

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/manager/2020/03/15/01

大概两个多月前的一次，跟朋友聊天，谈到了一些当 leader 的心路和历程，他说正好我很久没更新博客的，让我写下来，分享一波，我当时没放在心上，心想这种管理上的事情，各有各的方法，本身没有对和错，只有合适不合适，何况都是一些不成片的经历而已，适合互动交流，但很难提炼成文章。

无独有偶，今年过年因为疫情在家，跟一个年前离职的同事聊天，他之前在我团队是个很不错的研发，现在也是在一个一线公司带小团队。他当时问了我同样的事情，让我讲了讲带团队的成长经验。

我突然意识到，这些过往的经验如果稍微做一下抽象和总结，多少能给人一些启发。虽然我从很早开始做 Android 开发，真正带自己的团队也只是从两年前加入一条开始的。得益于职业生涯前几年的努力，自己技术累积了良好的口碑，恰好也是公司快速发展的需要，其实我相信，几乎全部的初当 leader 的同学一样，我们应该都算是 “码而优则仕”，又恰巧碰到一个机会，就这样走上了这条路。这两年，我们团队从5个人到20个人，学到的感受到的很大程度上可以总结为一些做事方法，其中主要的就是三点预判。

预测业务

从技术研发初做 Leader，最大的变化就是工作内容的改变。以前需要重心放在代码上，思考怎样解决问题、了解实现原理，而现在变成了解业务，思考业务，预测业务。
这个过程是个非常痛苦的过程，甚至有点算一种悖论。不知道大家有没有发现，在最初我们做研发的时候，要去了解各种各样的框架，学习内部实现原理，再尝试自己去写一个类似的框架，再从这个过程中了解这项技术的本质。这其中最神奇的就是，大家都觉得做业务写需求是一件很傻的事，而做架构，搞技术预研则是一件很高大上的事，所以很多人觉得公司的架构组、基础组的人都很厉害，相对的垂直业务组的人则技术比较差。
但是作为 Leader 往往是需要对公司的业务和组织架构有着深入的理解，并且能够通过产品经理提出的需求，对应的猜到这项需求上线后会对将来的业务干系方产生怎样的影响。
所以这两类人在很多公司都是被分割开的，比如阿里的P职级跟M职级，虽然有对应的转换，但大部分都是P职级做技术，M职级做管理。

举个我之前经历过的例子，我们是电商公司，APP 的首页对布局的灵活性要求非常高，上面这张图就是我们 APP 的首页。
公司有一套 CMS 系统，就是专门应对这样的场景的。核心技术就是后端返回一个 JSON，前端根据 JSON 展示对应的布局和内容，这其实是行业很通用的做法了，天猫之前开源过一个叫 Tangram 的解决方案，就是应对这种动态化首页的场景的。但是这种界面，如果是纯展示后端返回的数据还好，只要稍微插入一些特殊逻辑，代码马上会变得混乱不堪。最好的办法是客户端在请求接口的时候就将用户信息都传过去，然后服务端根据业务对应返回。但现实中往往是做不到的，要么是后端需要的参数非常非常多，要么是数据由不同的系统传出，可能同时涉及到VIP信息、订单、位置、推荐、广告等等。所以就变成了服务端返回一个占位符、客户端再根据占位符请求对应的子接口。
这种问题的解决就有两大思路，第一种技术层面的：就是通过良好的客户端架构设计，去充分考虑各种组件的情况，预留好应对方法。
第二种则是业务层面的：既然接口涉及到很多信息，那么能不能这些信息由一个专门去负责数据整合的中间层完成。
相比较而言，第一种改动点更小，只需要在自己工程代码中完成就可以了，第二种办法则需要充分了解公司的业务划分以及产品已定义的组件和将来可能的组件，找到相关的后端，再拉一个人或一个团队专门负责做接口整合的中间层，这时候第二种方案就对 Leader 的做事能力有着极大的挑战了。

预测行业

移动端开发没人要了。这种话作为段子我们不知道听到多少次了，事实上，每个公司都需要移动端的开发，只不过要求在不断变化而已。比如五年前，那时候创业的黄金时间，我们要的是能把业务快速做好上线的人；三年前，行业头部基本稳定，我们要的是能够把快速迭代那几年所欠下技术债还上的人；近几年，裁员不断，我们要的是能把公司成本降到最低，收益提到最高的人。理解了这一点，如何提高自己的价值，很简单，你能做公司需要而别人做不到的事，再帮助你的团队理解这一点，你就是公司最有价值的人。
比方说做 Android 的，近几年没有什么新技术，Kotlin、Flutter，没了。你要学吗？不一定！思考一下学完了以后对自己对公司有没有帮助，这才是重点。
想起来这样一个段子，说公司各种员工对老板的看法

员工	看法
普通员工	老板傻逼，什么都不懂
基层管理	老板有时候还是懂点的
高管	老板说的太对了，我怎么没想到
老板	我他妈太傻逼了，怎么没想到他这样

又是一年春天，招聘跳槽的黄金季节。没事多看看，了解一下现在其他公司的招聘要求，工作内容，细心一点你就能看出当前行业缺少的技术是什么；多跟你的上级聊一聊，打听一下公司的下一步大的战略方向是什么，你就又能提前准备一些事情。
很多时候，之所以能够做到预测未来，无非是你掌握的信息比别人要多而已。

预测团队和项目

如何找到自己团队或者项目的不足？
其中一个方法是直接问你的用户。就像我在文章开头时候提到的那个 CMS 系统的例子，如果你不是切实去做 CMS 系统的人，你根本不可能知道完成一个 CMS 组件有多复杂。
预测团队是个很有意思的事情。他的有意思在于你很容易先入为主，去猜测某些可能会发生的事情，然后某个机缘巧合，这件事情发生了，会让你觉得，其实你早就知道这件事会发生了。比如你想知道自己团队的不足，你去找团队的人聊天，大概率会得到的答案是那个你心中已经有的答案。而这背后，并不仅仅是大家的想法都一样，事实上更多的是因为你很容易只听到那些你想听到的事。所以得出的结论经常是前端说的后端技术太差，返回的东西乱七八糟，有用的数据没有，没用的数据一堆；后端说前端水平太差，几个字段自己拼一下就能知道数据了，什么都让我返回，这个逻辑我没法写。
之前在沪江的时候，我们 team 里有一句话叫：当一个事情发生第一次的时候，他就有可能发生第二次，当他发生了第二次的时候，就一定会发生第三次。
像这种推脱，很难直接去解决，因为前端没发理解后端的难点，后端也不知道前端的复杂。但一个常常被忽略的重点是，他们至少能表达出自己觉得差的地方。当多个人都觉得某个东西很差的时候，那可能真的是他有问题了，需要考虑如何解决掉这个问题或者避免下次继续发生。

team 的成长，才是 Leader 的绩效

之前看过一部电视剧，叫《大江大河》。讲的是文化大革命刚结束的时候，男主是个大学生被分配到国企化工厂上班，因为能力出众，当上了小组长，带两个厂子弟一起做事。
当时他就跟上级说了一句话：他们两个做事效率实在太低，与其让他们两个人去做，还不如我一个人直接做完了。
我相信这是很多人刚当上 leader 的第一感受，我当时也是这样，很多事情还不如自己加个班去解决掉，也比交给别人拖两三天才完成要好。
但事实上这样的后果就是：现在你只带两个人，有些事可以帮他们完成，将来将一个厂的人都交给你的时候，你要如何去帮他们完成呢？

我们 CTO 每次都说 Leader 要懂得将自己的能力复制给组员。让 Leader 的能力变得可复制，这才是公司最大的财富。
而懂得将预测未来的能力交给组员，这才是提升的最快办法，比很多傻逼公司强制996要好太多倍了。
当然，懂得跟上级形成定期的汇报机制，小事用钉钉微信，重要决策或进展当面或者日报。掌握足够的信息才是预测未来的重要依据，同时也是向上管理的必要条件，这也是我们CTO教我的。

你看，我们CTO自己也需要向上管理。

张涛 - 玩玩区块链——概念

2019-11-21

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/code/2019/11/21/01

讲个故事

这个故事是 2016 年 MDCC 大会结束一起聊天的时候，听冯森林冯老师讲的。背景是：前几天有个人问他，说冯老师我很迷茫，前端技术天天变，而真正重要的东西都在后端，我该不该去学后端。
在很早很早之前，程序员就是程序员，不分什么前端后端客户端，后来是我们人为的在中间画了一条线，规定线的左边叫后端，线的右边叫前端。在左边与右边的信息交互，我们用一种协议去完成。
而事实上，在当今世界跟用户打交道的都是前端，离开了用户，后端终究只是一堆冷冰冰的数字，而随着人工智能与物联网的发展，我们是有可能讲这些冷冰冰的数字计算，放在端上完成的。

具体的原话我已经忘了，但大概意思就是这些。虽然哪怕 5G 已经到来，我也不太相信人工智能跟物联网能解决这种问题，但我隐隐觉得区块链跟智能合约能做到类似的实现。

反正信不信由你，连潘木匠都开始跨界玩 Python 了，我玩会区块链不行吗？ 😂😂😂

比特币

分布式数据库

用我们平时最常用的数据库 MySQL 举例，你在自己服务器上装一个 MySQL 就是一个中央存储器。他面临的问题就是扩展麻烦，一不小心哪里崩了，整个数据都不能用了。于是就有人做出了分布式数据库，就是多个服务器，每个服务器存储一部分。中央存储与分布式就类似数组与链表(或者树)的关系，但是面临的问题就是，链表的每个节点是有可能被篡改的，比如有人破解了你服务器，获取了 root 权限，那还不上去随便改你数据库。

区块链

区块链也是一个分布式数据库，他的每个区块，也就对应了上面讲的链表的一个节点，而多个区块组合起来，才是一个区块链。拿比特币举例子，他每个区块实际上存储了多笔交易的信息，每个正在挖矿的矿工(其实就是一个存储机器)手里都会有一份完整的全量数据。这时候如果有一个人的数据与其他人不一样，那肯定他的数据是有问题的。这也就是为什么我们总说区块链是不可篡改也不会丢失的了（随着技术迭代，现在有更多的链选择节点搭配的形式，不再所有人都记录全部数据了）。

区块内防篡改

前面讲了区块间防篡改其实就是少数服从多数的方式，接下来再看看区块内如何防篡改的，还是用比特币的防篡改来举例。比特币每个区块的结构如下：

核心结构是由一种称之为默克尔树的二叉树实现的。当前区块的全部交易信息位于叶子节点，然后每两个相邻的叶子节点聚合进行Hash运算，运算结果作为中间节点，中间节点再次两两聚合进行 Hash，最终生成唯一的根节点 Merkle Root。默克尔树的特性在于，任意叶子节点发生改变，改变都会影响到上层的 Hash 运算结果，最终经过层层传递，根节点的 Hash 值也将发生改变，基于此特性，比特币系统牢牢的将区块内的所有交易聚合成为一个整体，任何的篡改行为都会影响到整个区块。
而比特币每次有区块新增的时候，其实都会计算一下默克尔树，但这段计算其实是很快的而真正耗时的，其实是一段没有任何意义的计算。（这也就是有人说比特币浪费能源的原因）比特币会每隔一段时间，生成一个区块，但是为了保证生成区块的时间稳定，就强制要求所有挖矿的矿工(存储机器)不停的去运算一个很复杂的运算，而这个运算的复杂度是动态变化的，整个系统能保证每次运算出结果的时间都差不多10分钟。第一个运算出结果的人，要把这个结果告诉所有正在计算的矿工(其他存储机器)，这样，他就算是成功记录了新的区块，而别的矿工就会同步他记录的这个区块，作为最先运算出结果的矿工，也会获得奖励(也就是比特币)。
所以，看出来了吧，本来是用来存储的机器，结果最大的代价居然不是存储，而是不停的计算一个毫无意义的运算，这就是个笑话。
(扩展知识：双花问题、51%攻击，自行搜索)

各种空气币

比特币被称为区块链1.0，很多人希望把区块链的技术应用到数字货币之外的场景，然而，比特币本身的功能单一，对用户来讲，无非是挖矿、转账交易，于是就有了区块链2.0，以太坊。
前面已经说了，比特币计算一个区块是十分钟左右，而以太坊计算一个区块是十几秒，这就大大提高了数据同步的速度，也就是说交易确认将会更快（垃圾，再快能比微信支付宝快吗😂）。
然而，以太坊的成功并不是他的交易速度。比特币有一个很大的问题，就是其中协议的扩展性是一项不足，例如比特币网络里只有一种”token”——比特币，用户无法自定义另外的属性 token，这些 token 可以是代表公司的股票，或者是债务凭证等，这就损失了一些功能。另外，比特币协议里使用了一套基于堆栈的脚本语言，这语言虽然具有一定灵活性，使得像多重签名这样的功能得以实现，然而却不足以构建更高级的应用，例如去中心化交易所等。以太坊从设计上就是为了解决比特币扩展性不足的问题。

安全可信

如果仅仅是用来发币，国家可能早就把区块链给封了。以太坊真正解决的，是共识问题，这也是为什么国家重视区块链的原因。前面我们讲，比特币给每个矿工存储数据的回报是比特币，而以太坊也有自己对应的报酬叫以太币。以太坊英文叫 Ethereum，对应的币叫 ETH。但是以太坊统一了所有基于以太坊定制的各种定制链的 token，即(Token 标准协议)。而这里说的各种定制链，其实就是合约，这是以太坊的核心。合约是一个活在以太坊系统里的自动代理人，他有一个自己对应的 eth 地址，当用户向合约的地址里发送一笔交易后(其实就是调用一个函数)，该合约的对应回调函数就被调用，而交易是可以附带额外信息的，然后合约再根据交易中的额外信息处理自己的逻辑，最后返回一个响应，这个响应可能是从合约的地址发出另外一笔交易(触发另一个调用)。这样任何一个基于以太坊定制的 token，都是可以被互相兑换的。看到没有，交易所也出来了。

共识机制

POW

虽然以太坊相比比特币的内部实现已经好了很多了，但依然没有从根本改变比特币那个笑话——本来是用来存储的机器，结果最大的代价居然不是存储，而是不停的计算一个毫无意义的运算。
而这个笑话有一个专业的名词叫做 POW(Proof Of Work)。
这是机制的问题，因为如果一个存储数据的机器，想要证明自己记录的数据是准确的，还要让别人相信自己的数据是准确的，他不得不想办法证明自己是准确的(类似于证明自己是自己)。而证明自己的过程，就是他把自己的数据求一遍 hash，然后吧 hash 结果告诉别的同样在记录数据(挖矿)的机器，然后别的机器去用你的 hash 结果验证他们的数据，如果发现一致的话，那他就相信你的数据是对的(因为跟自己的结果是一致的)，然后当系统里面相信这个数据是对的机器越来越多，这个结果自然而然就成了正确的结果。
这个验证的过程是一个很特殊的算法，求 hash 的时候是非常复杂耗时的操作，而验证 hash 正确性的时候，是一个非常简单的操作。举个例子：比如我给出一个 md5 值，让你去算哪一段文本的 md5 值跟他是一样的。你可能唯一的办法就是自己不停的穷举所有文本的 md5，去找出一段文本的 md5 是不是跟我给出的一样，而如果此时有人给出一段文本，说这段文本跟给定的 md5 是一样的，你很容易就能验证他说的对不对。
因为这种机制问题，POW 不得不花大量的资源用于计算 hash 上，而不是原本存储的目的，从而造成了很大的资源浪费(毕竟计算机算hash费电啊)。

POS

POW 的本质目的是为了保证数据是可靠的。优点是公平而且不容易出错，缺点自然就是浪费资源。所以有人提出了一种新的方案，也可以用来保证数据的可靠性，同时还节约资源，就是 POS(Proof of Stake)
POS 机制实际上是模拟了人类社会的信任过程。就好像中国古代动不动就找一个德高望重的老人家来主持公道一样，POS 就是找出一个德高望重的人，让他来负责记录数据，那我们就都相信他的数据是准确的。而德高望重，实际上就是一个根据你持有货币的量和时间来决定的。持有的时间越长，币越多，你你产出的新区块被认可的概率也就越大。
而怎么算你持有币呢，用上面讲的以太坊举例(注:以太坊对外宣称将来会改为POS机制，但截止目前，他依然是POW)，你的每一个币其实都是放在一个数字钱包里面的，你说你持有币，其实你持有的只是数字而已，而数字钱包实际上就是一个记录数据的机器，这台机器是拥有记录数据能力的，机器拥有(钱包中)的币越多，新记录的数据越能得到认可。
但是，不知道你发现了没有，这又是一个套路。他已经从原本依赖机器去计算改为依赖币的量了，换句话说就是骗你去持有更多的币。你持有的币越多，你就越有可能让别人相信你的数据是正确的，而如果你让别人相信了一个新区块是正确的，系统会额外分你一些奖励(类似挖矿所得)。
于是就有人去吸引你把币放我这里，我去记录数据，因为币越多，放的时间越长，我发现新区块的概率也就越高，获得系统奖励的概率也越高，到时候再分你一部分奖励，这就是银行啊。

DPOS

POS 已经从很大程度上解决了资源浪费的问题，毕竟他基本上还原了分布式存储的本质，每台机器的主要作用是存储数据，而不是计算。
但 POS 实际上依然在每台机器上都还是有可能会有计算的，也就是那个根据持有币的时间和数量的概率算法。
而 DPOS(Delegated Proof of Stake) 是 POS 的进一步优化，他从全部的机器中选出几台机器来指定，只有这些机器可以轮流记录新区块，别的机器都只负责同步区块。这就真正还原了分布式数据库的作用——只用于记录数据。
但又引入了新的问题，这些有记录新数据权力的机器，如何指定。于是又引入了一个人类社会的信任方式——投票。
而这里的票，也就是你手里的币，你把你的币给别人，这就是给别人投票。但是没有人会傻到把币免费给别人，想要我的币，拿东西来换啊(类似于拉票)。
但是你发现没，号称去中心化的区块链，居然又变得中心化了，傻逼区块链。

张涛 - 一条电商 Android 工程化实践

2019-11-02

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/session/2019/11/02/01

大家好，今天跟大家分享的主题是：从小作坊到大工厂，一条电商的 Android 工程化开发实践。

我是张涛，就职于一条生活馆，我们公司是一家电商新零售公司，目前移动端的一些开发管理工作都是由我在负责。对今天的分享有哪些值得探讨的也都欢迎与我交流

Android 作为一个诞生近十一年的移动操作系统，占据了近 80% 的市场份额。
我相信在座的很多朋友，都是从2013-2015年开始从事 Android 开发的，可能晚一点的有2016年的。这也正是 Android 生态发展最快速的3年，如今我们再回过头来看一下这几年。

这是我们曾经的 APP，携程、美团、京东、淘宝，这是我在网上找的四张图片，时间都是在2014年2015年的，主要是再久一点的也找不到了。
从前我们的应用，这四个应该是很典型了的，因为他们栏目多，业务也多。可以看到，携程四行三列，其他的：美团、京东、淘宝，都是两行四列。

你们都知道，接下来我要放现在的了：这是我最近才从我手机上截的四张图，依然是携程、美团、京东、淘宝。
在这四五年里，互联网公司大幅增加，而这样的老牌互联网公司，新业务也不断增多，我们看到，携程的：WiFi 电话卡、保险签证、以及上面主业务细分更加精细。
美团那就更是如此了，骑单车、叫外卖、美团打车、美团买菜，相信大家都是有所感受的。
再往后京东淘宝我就不用说了，大家也都看得到。
前面从业务角度回顾了我们这几年APP的发展，接下来我们从技术架构角度看一下现代的APP

这张图，是我们一条生活馆的移动架构图，这张图应该可以覆盖如今百分之九十 APP 的架构模型。最上层是业务层，常见的 APP 各个业务模块，比如我们一条生活馆的最重要的几个业务，CMS首页、内容相关模块、电商的商品购物、还有拍卖等等。
第二层，是服务于业务的通用业务层，最常见的浏览器web容器、路由功能。UI 统一、我们的 APP 越做越大，可能一个 APP 由多个设计团队去负责，那设计就需要有一个统一的控件风格。广告，各种闪屏页、内插页弹窗、小红点等等。还有 RN、Weex、Flutter这种多端共用业务。
最下层，是一些基础服务。这里我列出来了8种，大家可以发现一个特点就是这8种都是与用户无关的服务，比如数据上报、异常统计，我作为一个普通的用户完全不在乎我用的应用是否有异常统计，他不会影响我的使用。
侧边是一个贯穿我们整个应用的综合性技术，像 Kotlin 的 Coroutine(协程)、Google 新推出的类似 SwiftUI 的 Jetpack Compose、模块化、国际化、插件化等等，都是改动一块，整个应用可能都会发生变动的技术点。
我们如今的应用已经到了如此惊人的一个庞大体量，但是……

回到我们今天的主题：如何完成作坊到工厂的转变？把上面那些技术全都用一遍吗？哪怕你说插件化 Kotlin 都不适合我们，我找出适合我们的技术都用上，就是大工厂了吗？
不是的，至少我认为不是的。
自从我投身到创业公司以后，经常有人问我大公司和小公司的差别是什么。在我看来程序员能力的差距都不是最大的问题，当然这是前端，后端可能会因为性能问题造成比较多的损失噢。
在我看来最大的差距就是在基础设施建设上。小公司往往会因为老板的眼界、公司资源等各种各样的原因，缺失

一套成体系的工程化平台
那么何谓工程化平台，就是通过标准化流程的方式，去做的能够批量生产的能力。

比如说我们前面介绍的一个应用有多个功能模块，包含基础模块和业务模块，这也是近几年被喊的很火的移动端模块化技术。
第二点，数据驱动模块重组，我们为什么要让这些模块独立是如何选择的。
第三点，我们的研发做好了各个需求，这些需求要如何测试如何上线。
当然，一个前端工程化平台不止这三点能力，比如线上的APM、日志监控等等，只是这三点是我认为作为一个作坊到工厂转变必不可少的三点。
接下来我们从应用架构的角度去一个一个的详细聊聊，首先是业务模块独立。

无论任何一个应用，想要做到模块化拆分，都必不可少要面临这三个问题：跨模块函数调用、跨模块界面跳转、跨模块消息传递。当然，如果这是一个业界常见问题，一定会有开源的解决方案，比如前面两个，我们可以通过阿里开源的ARouter解决，后一个我相信做Android的没有人不知道EventBus。但是这两个框架在我们真正用起来的时候，都会碰上一些问题。比如ARouter，他从一开始设计就是为了淘宝这样大型的APP去做的，他在应用首次启动的时候要把所有类遍历一遍而这个时间是非常长的，即便是通过分组懒加载也依然很慢。
当然还要一个更重要的原因，是因为我们在ARouter开源之前，就已经有了一套完整的路由框架，所以就没有再使用ARouter了。另一个EventBus也是订阅者模式都会遇到的问题，就是消息泛滥的情况。当应用内消息过多的时候，会造成消息难以追踪，调试问题的复杂度也随之增大了。

YitBridge 使用了与后端 SOA 设计思路类似的方式：将模块之间的主动依赖倒置，变为功能的提供与使用。那什么是 SOA 的设计思路呢，我们看到一张我画的漫画图：SOA 它是一种面向服务的架构模型。
例如图上左边有一个对外提供媒体功能的服务提供者，他告知YitBridge我提供媒体服务：“嘿，老铁，我这有个媒体服务，你那边有谁要用的时候可以用我的。”
到了另一边，如果此刻有模块说是，我需要媒体服务：“老铁，你那有没有媒体服务，我这边需要播一个铃声啊！”。
“有的，给你。”
YitBridge 就会将之前服务提供者与服务使用者做一个桥接完成服务的调用。

接下来我们来看具体到代码上是如何使用的：首先是作为服务使用方，也就是上一张图右半部分的Client。我们看到上面是传统的做法，首先声明一个借口类型，然后new出接口的实现类给他赋值。而使用了YitBridge的时候，你是不需要关心接口的实现类到底是谁的。这就是YitBridge唯一的用处，隐藏实现类，做到彻底的面相接口编程。

之前说过，YitBridge将模块之间依赖倒置，由之前的服务提供方被动的接受调用方调用变为，服务方主动提供服务给调用方。那作为服务提供方需要做些什么事呢，非常简单，你只需要给你的对象提供方法加上一个@Creator注解，告诉YitBridge这是一个创建器方法就可以了。

前面讲YitBridge实现完美实现了模块间的解耦，而YitBridge的内部实现就是通过这个APT来完成的。Annotation Processing Tool，相信大家都有听说过这个APT，即便是你没听说过，你也肯定早就用过了，只是你不知道。 Android 上有一个注明的注解绑定框架叫 Butterknife，他的内部实现就是通过APT来做的，还有 Google 出品的 Dtabinding、Dagger2，这些也都是APT来做的。那这个注解处理器在 YitBridge 中做了些什么呢，我们来看这段代码。

这是 YitBridge 在编译以后生成的一段类：还是继续我们前面讲的那段示例来继续，在运行时，他会根据你传入的 get() 方法的参数，来判断你所需要的是哪个接口的实现，然后去调用对应的创建器方法。

那么除了这个问题，还有就是多版本协作开发时候的模块依赖问题。 Android 使用的是 Gradle 构建，如果出现基础接口更新，上层所有依赖都跟着重新更改一下，再做一次兼容。这种事本来是无可避免的，但是如果我们有多个版本同时开发，这个问题就大大提升了版本管理的复杂度问题。所以我们引入了一个 baseVersion 的概念，也就是你当前模块构建的目标版本号。只要依赖的模块的目标版本号一致，就可以不用考虑兼容性问题直接更新，如果baseVersion 不一致，那说明这是一次不兼容升级，需要上层模块处理完兼容性问题后再发布。

这就是前面 moduleApi的实现，其实就是判断了一下baseVersion是否一致，如果一致，那么就直接引用最新版本，如果不一致，则抛异常退出编译。从而将运行时的错误在编译期就直接发现。

第二部分，数据驱动模块重组

数据这里，我能跟大家聊的不多。
第一个，RMF模型。
RFM 模型是电商衡量用户价值和用户创利能力的一个重要数据，分别指三个纬度：最近一次消费 (Recency)、消费频率 (Frequency)、消费金额 (Monetary)。从这三个维度综合评分最终就可以量化出一个用户的价值，那么这个价值就可以辅助我们在线下建立线下店、用户社群等等数据化运营了。

第二个，商品曝光与转化统计。
也是电商公司会经常使用的统计商品转化率的方式，比如一个商品他在用户手机上被展示了多少次，展示了以后用户点击了多少次，这些点击又有多少是收藏或加入购物车了的，以及最终下单购买等等一系列流程，最终就可以分析出每个商品的转化率，慢慢的我们肯定会优先选择跟转化率高的供应商合作。

第三部分，标准化持续集成与交付

这里是我们目前使用的模块依赖构建工具，大家可以从这张图中感受一下。构建工具，主要的功能是很明显的，就是用于构建模块，在这之上，还有隐含的功能，就是集中了构建模块的权限，可以更便于统一管理；当然还有最重要的优势就在于模块版本的管理，你可以很清晰的知道当前主应用所接入的模块的版本是哪个，当前最新构建的SNAPSHOT是哪个，以及每个版本的更新日志；这样做了以后，在跨团队协作上的沟通就大大降低了，如果你已经接入或者即将接入的模块是另一个团队开发的模块组件，那你可以直接关注它，它的所有版本变动日志，最新版本全都一目了然；并且可以通过平台简化模块的测试与模块发布的流程，比如提测的时候，如果是一次兼容版本的发布，你只需要告诉测试提测分支，测试可以自己根据现在线上应用的tag，同时引入当前提测的模块替换老版本的模块重新编译，很容易就能控制变量。

第二个就是，通过平台化的构建工具，可以很方便的动态选择模块依赖，比如我们在测试某个模块的时候，可以排除部分已经保证没有问题的模块，那么在测试的时候就可以更聚焦，让测试只看我们发生改动了的模块，最终集成测试只需要简单看一下就行了。

接下来我们再看看发布效率。最早我们的代码，是非常严格的 N 周一个迭代的发布。但是随着业务越来越多，团队也越来越大。很多时候不得不 delay 一两天来照顾到所有的业务团队。
之后，就有了我们模块化解耦，每个业务按照自己的迭代排期计划好，如果 delay 了那么这个版本你们的新需求就得放到下个版本再发布了，这样主 APP 的发版不再依赖哪个业务线，同时业务组件可以提前打包，这也加快了打包时所用的时间。
再到最后，通过用户画像精准推送。我们可以做到代码随时发版，只要你认为你的需求做完了，测试通过了，就可以发布 APP。但是这个版本并不一定是每个用户都会接收到，而是我们提前已经分析过用户行为，那些愿意主动使用最新应用的用户才会收到应用更新。大家打开手机里面的微信、QQ 等等，点一下检查更新看看，基本上都是提示已经是最新版本了，但你用的却不一定是最新的版本，你可以去官网再自己下载一个 apk 装上看看版本号。

在之后就是我前面提过的，工厂化发布一个APP。我们可以根据业务需要任意组装业务模块，最后拼成一个APP，快速发布到线上，查看这个应用的数据反馈，如果这个应用从数据层面看运行的非常好，那么就可以考虑引导流量到这个应用。如果数据不好，那么尽早放弃降低研发成本，准备其他的业务也更灵活。

张涛 - 最新版提升 Android 应用编译速度的方法

2019-08-15

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/note/2019/08/15/01

应用的构建速度会直接影响开发效率，本文将带您通过改造一个 Android 应用: “Google 追踪圣诞老人 (Google Santa Tracker)” 来为大家提供十个小技巧，帮助提升应用的 Gradle 构建速度，当我们应用了所有的小技巧之后，该演示应用的构建速度快了三倍以上。

首先来了解一下 “Google 追踪圣诞老人” 应用的工程背景: 这个应用有约 60M 大小，它包含 9 个模块，有 500 多个 Java 文件，1,700 多个 XML 文件、3,500 多张 PNG 图片资源，用到了 Mutil-dex，没有注解处理器。

其次，在我们开启速度提升调优之前，来了解本次三个性能指标的说明:

全量构建，也就是重新开始编译整个工程的 debug 版；

代码增量构建，指的是我们修改了工程的 Java / Kotlin 代码；

资源增量构建，指的是我们对资源文件的修改，增加减少了图片和字符串资源等。

每个小技巧实施以后，我们会对比如上三个场景的构建时间以作为我们的量化标准。请注意，由于工程规模大小不一、开发环境各异，开发者们在实际的操作中的结果可能会与本文的结果有所不同。

使用最新版本的 Android Gradle 插件

每次 Android Gradle 插件的更新都会修复大量的 bug 及提升性能等新特性，因此保持最新的 Android Gradle 插件版本有非常大的必要。

从 3.0 版本开始，我们将通过 google() 的 Maven 仓库分发新的 Android Gradle 插件，所以需要在 repositories 处加入 google() 以获得最新的插件更新 (现在的 Android Studio 新建工程的时候会默认加入 google() 的 Maven 仓库指向)。

这是将 Android Gradle 插件版本从 2.x 更新到 3.0.0-alpha1 之后得到的结果 (这里的演示是基于 3.0.0-alpha1 版本，随着插件版本的更新，性能的提升会更加明显)，我们可以看出，全量构建一次应用的时间直接减少了 25%，代码改动的增量构建减少了将近 40%，资源改动的增量构建也减少了 16%。

避免激活旧版的 Multidex

这个小技巧大家应该比较熟悉——避免激活旧版的 multidex。当您的应用配置方法数超过 64K 的时候，您需要启用 multidex。当您启用了 multidex，且工程的最低 API 级别在 21 之前时，旧版的 multidex 就会被激活，这将严重拖慢您的构建速度，原因是 21 之前的 API 级别并没有原生的支持 multidex。关于启用 multidex请查看官方文档。

如果您是通过 Android Studio 的运行/调试按钮来执行构建，那么无需考虑这个问题，新版本的 Android Studio 会自动检测连接的设备和模拟器，如果系统的 API 级别大于 21 则进行原生的 multidex 支持，同时会忽略工程里对最低 API 级别 (minSdkVersion) 的设置。

习惯通过命令行窗口构建工程的开发者们则需要试着避免这个问题: 配置一个新的 productFlavor，设定工程的最低 API 级别为 21 或者以上，在命令行里调用 assembleDevelopmentDebug 即可避免这个问题。

这一次的性能改进结果效果也非常明显 (灰色的线条是最初的结果)，在全量构建的时候我们又降低了 5.5 秒的时间，而在代码改动的增量构建里时间减少了 50% 以上，资源改动的增量构建与之前的时间相同。

最小化使用资源文件

当您的应用包含大量本地化资源或者为不同像素密度加入了特别的资源时，您可能需要应用这个小技巧来提高构建速度——最小化开发阶段打包进应用的资源数量。

构建系统默认会将声明过或者使用过的资源全部打包进 APK，但在开发阶段我们可能只用到了其中一套而已，针对这种情况，我们需要使用 resConfigs() 来指定构建开发版本时所需要用到的资源，如语言版本和屏幕像素密度。

这里我们看到了较大程度上的改观，全量构建的时间又降低了 6 秒，增量构建的时间也分别降低了 20% 以上。

禁用 PNG 压缩

与小技巧 4 一样，这个特性本身在打包发布阶段是相当有帮助的—— PNG 压缩，但在开发阶段禁用这个功能可以提高构建效率。默认情况下，AAPT 会压缩工程的 PNG 资源以减小 APK 体积，根据图片的数量和大小，这个过程所消耗的时间有长有短。

如果要避免使用 PNG 压缩，我们可以在小技巧 3 里提到的，在 devBuild 属性里加入 aaptOptions.cruncherEnabled = false 来实现，在构建的过程中把这个值传给 gradle，它就可以避免执行 PNG 压缩命令了。

另外一个避免压缩 PNG 的方法是使用把 PNG 转换成 WebP 格式的图片，对比 PNG 格式，WebP 可以减少最多 25% 的大小，同时 2.3 以上版本的 Android Studio 直接支持 PNG 到 WebP 格式的转换。

需要注意的是，API 级别 15 及更高可以支持不透明的 WebP 格式图片，如果是透明格式的 WebP，需要 API 级别 18 以及更高。

这可以看到全量构建又减少了 9 秒的时间，这也是因为 Google 追踪圣诞老人应用里有 3,500 多张 PNG 图片，这要花费大量的时间进行压缩计算，所以这方面的效率提升显得很明显，而其他增量构建只是维持了之前的情况。

特别提出一下关于 APK 体积的问题——对比了启用和禁用 PNG 压缩之后的 APK 体积之后，我们发现前后的体积并没有太大改变，这说明该工程里使用的 PNG 图片在导入之前已经经过了充分优化，PNG 压缩在这里实属多此一举。

使用 Apply Changes

从 Android Studio 3.5 版开始 (3.5 版目前在 Beta 构建渠道发布)，开发者们可以使用 Apply Changes 功能来提高构建性能，它可以让代码和资源的改动直接生效而无需重启应用，有时候甚至无需重启当前的 Activity。与 Instant Run 的实现方式不一样，Apply Changes 充分利用了 Android 8.0 以上版本操作系统的特性进行运行时检测，从而动态的对类进行重新定义。因此，如果您希望使用 Apply Changes，则需要让您的工程运行在 Android 8.0 (API级别26) 以上的真机或者模拟器上。

不使用动态版本标识

Gradle 提供了一个非常方便的依赖库版本号管理功能，方便开发者们通过使用一个加号 “+” 标识希望使用这个依赖库的最新版本。但是使用动态版本有几个风险，从性能角度来说，Gradle 会每隔 24 小时去检查一次依赖库的更新，如果您的依赖库很多，而且都使用了动态获取最新版本的这个设定，那会对构建时候的性能产生一定的影响。

即使您不是特别在意这些性能损耗，但他还有一个你必须在意的风险点——具体见我这篇文章《如何在 Android 代码中下毒》。

Gradle 内存分配调优

默认的构建环境里，我们会给 Gradle 分配 1.5G 的内存，但这个并非适用于所有的项目，您需要通过对这个数字对调优来得到适合您工程的最佳 Gradle 内存分配。

与此同时，从 Android Gradle 插件 2.1 版本之后，dex 已经默认在进程里了，所以如果您之前设定过 javaMaxHeapSize 值，可以选择删掉它了。

开启 Gradle 构建缓存

Gradle 新推出的缓存机制效果非常出色，我们建议大家尝试开启，最新的 Gradle 支持了 Kotlin 项目使用构建缓存，构建速度可以提高很多。Gradle 的构建缓存默认是不开启的，您可以通过在命令行里加入 –build-cache 参数或者在工程根目录的 gradle.properties 里加入 org.gradle.caching=true 为所有人启用构建缓存。您可以在这个文档里了解更多关于 Gradle 构建缓存的内容。

点击访问关于 Gradle 构建缓存

张涛 - Beta 6 现已发布，Android Q 正式版即将面世！

2019-08-12

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/news/2019/08/12/01

再过几周，Android Q 正式版就要与大家见面啦！目前，Android 团队正在对平台进行最后的优化与调试。同时今天向各位开发者发布最后一个 Beta 测试版: Android Q Beta 6。

在我们向消费者正式推出稳定版之前，请确保您的应用已准备就绪。现在，请您抓紧时间进行测试并尽早发布应用更新，让用户平滑过渡至 Android Q。

此刻参加 Beta 测试计划，在 Pixel 设备上获取 Beta 6。如果您之前已经加入计划并成功安装了 Beta 5，设备将很快收到 Beta 6 更新。另外，参加 Android Q Beta 计划的合作伙伴也会在接下来的几周内，陆续更新设备系统——您可前往设备官网，获取更多信息。请搜索开源实验室，立即开启您的 Android Q 之旅。

Beta 6 有哪些更新？

Beta 6 更新中包含供 Pixel 及 Android 模拟器使用的最新 Android Q 系统映像、官方 API 29 SDK 以及升级版的 Android Studio 工具。最终版系统平台涵盖的所有特性、系统行为以及面向开发者的 API，全部都可以在 Beta 6 中找到。请您利用这些更新，进一步打磨您的应用，确保它们做好万全准备。此外，为了给用户创造更好的体验，我们还在 Beta 6 中添加了许多修复和优化，请阅读发布说明，获取更多内容。

我们基于用户反馈改进了 Beta 6 中的手势导航功能，重要更新包括 (1) 对于应用设置的排除返回手势导航区域，添加了 200dp 的范围限制，从而确保操作的可靠性和一致性; (2) 新增返回手势灵敏度偏好设置。我们会在《Android Q 手势导航优化技巧系列专栏》中公布更多技术细节，敬请期待。

面向开发者的 API https://android-developers.googleblog.com/2019/06/android-q-beta-4-and-final-apis.html
发布说明 https://developer.android.google.cn/preview/release-notes
《Android Q 手势导航优化技巧系列专栏》 https://medium.com/androiddevelopers/gesture-navigation-going-edge-to-edge-812f62e4e83e

将您的应用适配至 Android Q

Android Q 消费者版本即将发布，我们强烈建议所有 Android 开发者尽快进行更新，确保现有应用在 Android Q 上的兼容性。

具体操作如下:

在 Android Q 上安装您的应用: 请从应用商店下载您的应用，并安装至运行 Android Q Beta 的设备或模拟器，然后进行测试。应用须运行流畅，实现完整功能，并妥善处理 Android Q 的各项行为变更。请注意隐私变更、手势导航、生物验证库的动态链接路径变化等各项特性带来的影响。
针对 Android Q 的隐私保护特性进行测试，例如: 新的位置权限、限制从后台启动 activity、关于数据和设备识别符方面的变更等。请查看隐私特性清单并阅读行为变更文档，了解更多需要测试的范围。
测试应用正在使用的受限制的非 SDK 接口，并尽快转用公开 SDK 或 NDK 替代接口。请阅读《非 SDK 接口限制在 Android Q 中的更新》获取更多信息。
测试应用中的开发库和 SDK: 如果您发现任何问题，请尝试更新到最新版本的 SDK, 或联系 SDK 开发者以获取帮助。您也可以使用下面的链接向我们报告 SDK 兼容性问题。
更新并发布兼容 Q 的应用: 在测试完毕并进行必要更新后，我们建议您立即发布适配后的应用。这样一来，Android Beta 用户便能在第一时间测试您的应用，并且平滑过渡至 Android Q。

运行 Android Q Beta 的设备 https://developer.android.google.cn/preview/devices
模拟器 https://developer.android.google.cn/studio/run/managing-avds.html
行为变更 https://developer.android.google.cn/preview/behavior-changes-all
隐私变更 https://developer.android.google.cn/preview/privacy
手势导航 https://developer.android.google.cn/preview/features/gesturalnav
生物验证库的动态链接路径变化 https://developer.android.google.cn/preview/behavior-changes-all#bionic
新的位置权限 https://developer.android.google.cn/preview/privacy/device-location
限制从后台启动 activity https://developer.android.google.cn/preview/privacy/background-activity-starts
关于数据和设备识别符方面的变更 https://developer.android.google.cn/preview/privacy/data-identifiers
隐私特性清单 https://developer.android.google.cn/preview/privacy/checklist
行为变更文档 https://developer.android.google.cn/preview/behavior-changes-all
《非 SDK 接口限制在 Android Q 中的更新》 https://developer.android.google.cn/preview/non-sdk-q
报告 SDK 兼容性问题 https://issuetracker.google.com/issues/new?component=190602&template=1227583
测试您的应用 https://developer.android.google.cn/distribute/best-practices/launch/test-tracks

我们深知变更支持对开发者的重要性，因此，非常感谢大家优先安排 Android Q 的应用适配工作，与我们一同在 Android Q 上构筑精彩！

利用 Android Q 特性和 API 提升您的应用

一切准备就绪后，请您尽情探索 Android Q，并了解可供应用使用的新特性与 API。我们从中挑选了一些最重要的特性，您可以从这些特性着手，逐步提升应用的性能和体验。

我们建议所有应用支持以下特性:

夜间模式: 为了确保用户在启用全局夜间模式后能够享受到一致的体验，请您在应用中添加夜间主题，或开启 “强制暗黑” (Force Dark) 功能。支持手势导航: 为用户提供边到边的视觉体验，同时确保应用的自定义手势与系统手势互相配合。
适配折叠屏: 针对折叠屏为应用进行优化，以便在现代创新设备上实现边到边的无缝体验。

如果下列特性与您的应用相关，我们建议您添加相应支持:

互动性更高的消息通知: 如果您的通知中包含消息，请启用通知内的智能回复及建议操作，以吸引用户并让他们可以立即采取行动。
更强的生物验证支持: 如果应用需要处理生物验证用例，推荐您使用 BiometricPromt，它是在现代设备上支持指纹身份验证的首选方式。
更丰富的录音体验: 如需支持字幕生成或游戏录制，请启用音频回放获取功能。这能让您的应用惠及更多用户，并更好地支持无障碍体验。
更优秀的 codec 编解码器: 媒体应用请利用 AV1 进行视频传输，并通过 HDR 10+ 播放高动态范围视频；语音和音乐应用请使用 Opus 进行音频编码。另外，我们还为音乐工作者提供了原生 MIDI API。
更好的网络连接 API: 如果您的应用通过 Wi-Fi 管理 IoT 设备，不妨试一下新的网络连接 API (network connection API) 来执行配置、下载或打印等功能。

以上仅为 Android Q 新特性和新 API 的一部分，请前往 Android Q Beta 官网查看完整列表。

新特性与 API https://developer.android.google.cn/preview/api-overview.html
夜间主题 https://developer.android.google.cn/preview/features/darktheme
强制变暗 https://developer.android.google.cn/preview/features/darktheme#force_dark
手势导航 https://developer.android.google.cn/preview/features/gesturalnav
针对折叠屏为应用进行优化 https://developer.android.google.cn/preview/features/foldables
通知内的智能回复及建议操作 https://developer.android.google.cn/preview/features#smart-suggestions
BiometricPromt https://developer.android.google.cn/reference/androidx/biometric/BiometricPrompt
音频回放获取功能 https://developer.android.google.cn/preview/features/playback-capture
AV1 https://en.wikipedia.org/wiki/AV1
HDR 10+ https://en.wikipedia.org/wiki/High-dynamic-range_video#HDR10+
Opus http://opus-codec.org/
原生 MIDI API https://developer.android.google.cn/preview/features/midi
网络连接 API https://developer.android.google.cn/preview/features#peer2peer

在应用商店发布应用更新

在您准备好后，请将编译版本为 (或选择目标版本为) API 29 的 APK 更新发布至应用商店。请确保更新后的应用在 Android Q 及更早版本平台上运行流畅。建议您使用 Google Play 测试发布渠道先获取一小部分用户的使用反馈，然后再逐渐进行全量发布。

Google Play 测试发布渠道

https://developer.android.google.cn/distribute/engage/beta.html

如何获取 Beta 6？

获取步骤十分简单！Pixel 用户请加入 Beta 测试计划并获取更新。如果您已加入，无需任何行动，设备将很快收到更新推送。此外，系统映像文件也已开放下载。Android Q Beta 测试计划中合作伙伴也会在接下来的数周内更新他们的设备。请访问 android.com/beta 查看全部支持机型。

如果您想为 Android Q 开发应用，只需将官方 API 29 SDK 和工具下载至 Android Studio 3.4 稳定版即可；如果您想获取最新的 Android Q 支持，我们建议您更新至 Android Studio 3.5 Beta 版本。接着，请您按照步骤配置开发环境，并阅读《发布说明》中的已知问题部分。更多内容，请访问： https://developer.android.google.cn/preview

张涛 - GitHub 开始阻止被制裁国的开发者使用

2019-07-29

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/news/2019/07/29/01

上周五，国外新闻网站 ZDNet 发表了一篇报道GitHub与跟世界贸易摩擦国（例如中国、俄罗斯）的程序员关系的文章 —— GitHub starts blocking developers in countries facing US trade sanctions（GitHub 开始阻止被制裁国的开发者使用），具体内容如下：

如果你是在一个面临美国制裁的国家使用 GitHub 的在线服务，你的账号可能会因此被限制只能使用最基本的产品。

GitHub 本周告诉居住在克里米亚的21岁俄罗斯公民 Anatoliy Kashkin，由于美国的贸易管制，它“限制”了他的 GitHub 账户。Anatoliy Kashkin 在 YC 上发了帖子开源实验室-传送门-自备梯子说明此事，据说与该开发者同一地区的其他开发者也同样被限制。

GitHub 确实为开发者提供了一个争议限制的申诉表格，但 Kashkin 声称通过上诉限制没有任何好处：“这是毫无意义的。我的帐户被标记为限制，为了取消标记，我必须提供一份证据证明我不住在克里米亚。我实际上是一名克里米亚人注册的俄罗斯公民，我身处其中克里米亚，我一生都住在克里米亚。”

正如 GitHub 在其关于美国贸易管制的网页上所述，美国的制裁适用于其在线托管服务 GitHub.com，但其针对企业用户的付费内部部署软件可能是这些情况下用户的选择，它还声称正在与美国监管机构讨论如何纠正这种情况。

GitHub 说：“用户有责任确保他们在GitHub.com上开发和分享的内容符合美国出口管制法律，包括EAR（出口管理条例）和美国国际武器贸易条例（ITAR）。Github.com 上提供的云托管服务产品并非设计用于托管受ITAR约束的数据，目前不提供按国家/地区限制存储库访问的功能。如果您希望在ITAR或其他出口方面进行协作，受控数据，我们建议您考虑 GitHub 企业服务器，GitHub的内部部署产品。“

Kashkin 并不是美国认可的国家中唯一一位最近在GitHub上遇到麻烦的开发商。他告诉ZDNet，克里米亚的朋友最近面临类似的制裁相关限制。

GitHub 也在伊朗实施限制。总部设在伊朗的开发商 Hamed Saeedi 发布了对Medium的投诉，声称：“GitHub封锁了我的帐户，他们认为我正在开发核武器”。

该开发商声称自2012年以来一直在使用GitHub，并表示他最近收到了GitHub发送的关于贸易控制的电子邮件，就像Kashkin一样。他还说，GitHub阻止了所有伊朗账户。

Github 在给 Hamed Saeedi 发的邮件里这样写道：“由于美国的贸易管制法律限制，你的GitHub账户受到限制，如果是是个人帐户，您可能只能访问免费的GitHub 公共存储库服务，仅用于个人用户” 。同时邮件里还指导他访问 GitHub 关于交易控制页面和指向上诉页面的链接。

ZDNet 新闻的原文地址：开源实验室-传送门
对此你有什么想法？欢迎留言交流。

张涛 - 中国的开源项目正在破坏 GitHub 榜单页

2019-07-17

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/news/2019/07/17/01

近日一名国外开发者（Balazs Saros，下简称 Balazs）在个人博客发表了一篇看似是在“声讨”中国开发者的文章，标题起得有点唬人 —— “Chinese repos are ruining the Github trending page”（中国开发者创建的 repo 正在破坏 GitHub Trending 页面）。

上图乍一看还以为中国开发者开源的项目搞了个什么大新闻

文章开头处，作者写了一个旨在避免引起误会的声明，他表示自己不反对 GitHub Trending 上语言为非英语的 repo，因为这毕竟是一件好事，能保证英语水平欠佳的开发者也能在这个热门页面拥有一席之地。他主要是想指出 GitHub Trending 页面的用户体验设计存在缺陷，并希望 GitHub 能对此进行修复。

Balazs 说到，自己在任意时间打开 GitHub Trending 页面，很大概率会看到许多由中国开发者创建的 repo，甚至遇到过前 10 项目中有 9 个使用中文的情况，如下：

GitHub Trending 原本是一个十分意义的功能，于开发者而言，这是一个发现有趣和优秀开源项目的好地方，对开源项目来说，这也是曝光和获取关注的一个有效渠道。但 Balazs 表示自己越来越不愿意打开这个页面了，原因在于 GitHub Trending 基本是长期被中国开发者创建的 repo “霸榜”。

Balazs 表示虽然可以借助翻译工具对这些 repo 的 readme 文件进行翻译以了解项目，但项目的演示页面、截图中出现的文字都不是英文，甚至代码的注释也没有使用英语。此外，这些项目大多是面向部分特定群体而创建，例如为准备求职的开发者而整理的“面经”材料，或者是一些教程类的内容。

对于这个现象的出现，Balazs 给出了自己的分析，原因有三：

中国在软件开发/技术方面的实力正在追赶美国，并开始大力扩充人才库
投身软件开发行业是让“那里的人”摆脱贫困并拥有更多机会的一个最好的途径（有时甚至是唯一途径）
GitHub 正在迅速扩张市场并且在开发者群体中拥有非常大的影响力，所以这些人将 GitHub 视为一个获取资料和解决方案的地方就不难理解了（中国人可无阻碍访问 GitHub 也是重要的影响因素）

最后，Balazs 再次强调自己并非是在抱怨这些 repo 以及创建这些 repo 的用户，他认为总体来看这是一件好事，但却破坏了 GitHub Trending 的使用体验。为此，他提出了自己的想法：

GitHub 现在可通过 repo 包含的代码来判断项目使用的编程语言，然后在 GitHub Trending 提供依据语言来浏览项目的筛选项。因此，GitHub 可考虑根据 repo 的 readme/docs/etc 文件使用的自然语言来对这些项目做出区分。同样的，然后据此在 GitHub Trending 中提供一个与地区相关的筛选项，默认值当然是 “worldwide” —— 避免对排行榜造成影响。
参考 repo 的 LICENSE 文件，GitHub 可以考虑给 repo 创建者提供添加 LANGUAGE 文件的选择，这样无疑比自动判断自然语言更准确。
将上述两点结合起来是最佳的做法，也就是说在 GitHub 判断项目使用的自然语言后，repo 的创建者还能进行修改。

Balazs 博客的原文地址：开源实验室-传送门
对此你有什么想法？欢迎留言交流。

张涛 - Leader 的自我修养 —— Tech 与 Team

2019-07-13

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/manager/2019/07/13/01

招人那些事

最近一直在招人，一直在面试，见了很多人，遇过很多事。
总的来说，在我面试别人的时候，能方便他人都会尽量去方便，面试过程中，尽量营造一个轻松的气氛，比如聊一些别人的强项，总是抓住别人薄弱点不放，把气氛搞得很尴尬，我觉得真的没意义。
可即便是这样，我发现最多的情况是，几乎所有人都不知道自己的强项在哪里——没有自我认知。

开放性问题

问开放性问题可以很容易了解一个人，对于技术好的人可以很容易表现自己，对于技术不好的，一定会支支吾吾，因为根本就没有答案可背。比如通常有两个开放性的问题，是我一定会问的：

你在这家公司做的，你觉得最牛逼的事情是什么？
你做了几年 Android 开发，你觉得哪个开源项目让你学习到的最多。

其实这两个问题通常我都是希望从宏观和细节的角度，去尝试了解你对自己项目的认知和理解。
第一个问题，我得到的答案通常是一个很小的技术点。有两三个人，都是之前做互联网金融的(可见前两年互金的泡沫多可怕)说自己做的最牛逼的是是做了一套 hybrid 框架，可以高性能浏览前端页面。一问怎么做的，jsbridge 用了自定义方案，通过某个 webview 回调解析 js 传来的字符串命令，再调对应的原生方法；怎么高性能了，用了 X5 内核。再有就是实时聊天相关的，一问怎么做的，用了云信、环信、极光，卧槽，能不能有你自己的东西，拿着别人的东西封装一下，就是自己最牛逼的工作了吗，你是得多lowB。
第二个问题，最多的回答是Retrofit+RxJava+MVP，再一问细节：从interface通过动态代理创建OKHttp的Request再通过OKHttp拦截器按定制逻辑判断，之后从连接池中取出链接发送请求。基本上 Retrofit 能大体上把这个流程答上来的我都默认你是看过代码了，至少看过网上的原理介绍了。Rxjava就更是搞笑，几乎所有人都把Rxjava当成一个切线程工具来用了，最多再提一个流操作。结果就是连自定义操作符都不会，subscribe()方法不调用会怎样都不知道，却说自己对 rxjava 多么了解。

对于队友的培养和提高

我们CTO总强调，说Leader要懂得将自己的能力复制给组员。还一副我高兴就好的把这条加入了绩效考核里，真拿他没办法。不过想想也是，让 Leader 的能力变得可复制，这才是公司最大的财富。

对于菜鸟队友的建议

其实新手在很多大公司是根本看不到的，比如之前呆过的饿了么、沪江，随便一个实习生都要比普通公司的开发强很多。但是没有办法，不是所有公司都能找到这样的宝贝新人，更多的还是要自己培养。
而培养最重要的是有计划，并且压力给到，做出鼓励，持续跟进。
同时，这个菜鸟希望成为什么样的人，适合成为什么样的人，Leader一定要比他自己更清楚，这样才能真正让他成长，并且能够留住这个人。

对于牛逼的核心主力

这类人一定是公司的财富，任何一个流失对公司来说都是一种损失。其实留住人也很简单，如果你不能像头条那样单纯用钱砸死，那就想办法解决他关注的。根据马斯洛需求层次理论，一层一层的去看能解决他的哪一个需求，如果你能持续的给他目标，同时又是让他努力一点能够达到的目标，那么他一定是会愿意与你合作。

而对于那种明显的能力强的人，公司的成长都已经跟不上这类人的成长时，Leader也不得不考虑一下，当这个人离开时，事情应当如何处理。

90后管理的反转

经常会听到说90后不好管，完全不鸟管理者，却乐意被大神虐。我自己也是一个90后，可以明显觉得 80 70 后和 90 后的表现气质有明显的差别。就是“装”到“不装”的气质差异。

装与不装

因为 90 后不装，又看不惯别人装。今天很多做管理时间很长的人，身上的气质不仅仅是装，做管理者时间长了，气质叫“端装”，又端又装。

但事实上跟 90 后又不是不装，大神也都是喜欢装的，你得搞清楚什么是装的资本。比如你能让他意识到，有东西确实是你比他了解的，而且这种了解是你当着面让他看到帮助到了他，这时候你可以再装一下，告诉他，这就叫经验。而这种装其实是一种玩笑式的装，叫“装逼”。

为什么跟年轻人沟通的时候有很多冲突？不是管理经验不足，也不是学的管理工具不够，唯一的差别是，如果他观察到你身上有端和装的气质，所有沟通大门都会瞬间关死。
今天中国所有满足人们“装”这样核心诉求的产品、品牌、服务、企业、组织都在发生断崖式下降，房地产、奢侈品、餐饮包括我们现在这样的行业趋势都是非常明显的。保健品行业以前是送礼的，满足人什么需求？“装”的需求。不需要太多的品质，只要打广告，让所有人都知道这个品牌，知道你送了一个很贵的东西就可以。

90 后已经进入讨论中年危机的问题，他们养生保健比之前任何一代意识都强，一定愿意买这个东西，但是他们不是为了装给别人看，而是为了让自己身体更好。

合理规划时间，提高生产力

每一个初做管理的人，一定都会有很大的感慨就是——时间不够用。
我也尝试过不少提升生产力的方法，目前我用的是四象限工作事项管理法和番茄时间管理法组合的方式。

1.番茄时间管理法

第一次使用番茄工作法的时候，我并没有严格做到它规定的要求。我只是每天用它来设置若干个“25分钟”的番茄钟。我并没有留意自己每天完成了几个番茄钟，也没有估算某项任务要用掉几个番茄钟；因此我并没有从中受益。只是简单认为整个方法就是让你在一个时间段内保持专注。

直到后来我决定严格地使用番茄时间管理法，发现自己潜移默化地逐渐有能力、可量化去真正评估自己每天可以完成的工作量。通过跟踪自己一天内完成了多少个番茄钟，并为每天要完成的番茄钟的数量设定目标。今后每次项目中，需要评估工作量、估算工时，便发挥了番茄时间管理法真正的威力。

2.四象限工作法

那四象限工作法如何与番茄时间管理结合使用呢？

使用番茄工作法，你可以把每周看作是由有限个番茄钟组成的。想在每周完成一定数量的任务?你要搞清楚自己一周能完成多少个番茄钟，并相应地设置任务的优先级。通过计算自己完成的番茄钟的数量，可以确切知道自己一周完成了多少任务。

某些情况下，我们总是幻想着自己可以在一周内完成超出自己实际能力许多的工作，过高地估计了自己的能力而低估了完成任务所需的时间。这个时候，我们就非常有必要给各个任务项设置的优先级了，将你每周需要完成的任务按照重要、紧急划分成四类：重要紧急、重要不紧急、紧急不重要、不重要不紧急。

这两个软件分别是Focus Matrix和Be Focused。数据是可以打通的，同时提供了手机版，喜欢的同学可以去试试。

当然也可以不使用软件的方式，这只是一个时间和任务管理的方法论，你也可以买一个沙漏⏳管理时间和便签管理任务，使用得当的话，也是可以达到一样效果的。

张涛 - Facebook Libra，数字货币离我们很近吗？

2019-06-23

本文开源实验室原创，转载请以链接形式注明：https://www.kymjs.com/pay/2019/06/23/01

Libra的使命是建立一个简单的全球货币和金融基础设施，为数十亿人提供支持。

互联网和移动宽带的出现使全球数十亿人能够获得世界的知识和信息，高保真通信以及各种低成本，更便捷的服务。这些服务现在可以使用来自世界上几乎任何地方的40美元智能手机进行访问.1这种连接通过让更多人能够访问金融生态系统来推动经济赋权。通过合作，技术公司和金融机构也找到了有助于提高全球经济能力的解决方案。尽管取得了这一进展，但仍有大量世界人口落后 - 全球仍有17亿成年人不在金融体系之内，无法使用传统银行，即使10亿人拥有移动电话，近5亿人拥有互联网接入。

对于大多数人，金融系统的部分看起来像互联网之前的电信网络。二十年前，在欧洲发送短信的平均价格为每封邮件16美分.3现在，拥有智能机的每个人都可以通过基本数据计划免费与世界各地进行通信。当时，电信价格高但均匀;而今天，对于那些最需要金融服务的人来说，获得金融服务的机会是有限的或受限制的 - 那些受成本，可靠性和无缝汇款能力影响的人可以获得金融服务。

开源实验室

张涛 - 【HarmonyOS】TheRouter 鸿蒙版新手入门

0、开始之前

0.1、查看最新版本

一、接入

第一步：接入编译插件

第二步：检查依赖是否引入

二、使用

2.1、 初始化

2.2、 定义页面容器

2.3、声明路由

2.4、发起跳转

2.5、获取页面传参

三、问题排查万能公式

四、鸿蒙路由源码调试步骤

4.1、clone 仓库

4.2、创建 build-profile

4.3、创建 hvigor 构建环境

张涛 - 为 TheRouter 的 AGP8 编译加个速

背景

问题

解决思路1

解决思路2

TheRouter 目前的方案

再优化一下

再优化首次的中断

张涛 - NAS - 玩点有意思的

NAS是什么

冗余存储

联通的公网IP

配个nexus

nginx 端口转发

网盘当然是用来存数据的

把 Mac 备份到 NAS 上

把 iPhone 备份到 NAS 上

把 Android 备份到 NAS 上

对象存储

张涛 - 动态路由 TheRouter 的设计与实践

服务使用方：

服务提供方：

张涛 - 没错，TheRouter 是我写的

说回 TheRouter

为什么要使用 TheRouter

动态页面路由能力

单模块自动初始化能力

内置初始化节点

动态化能力

模块化支持，Gradle脚本一键切换源码引用

什么年代了，还在用 ARouter?

张涛 - 货拉拉 Android 模块化路由框架：TheRouter

一、为什么要使用 TheRouter

1.1 TheRouter 四大能力

二、路由方案

三、使用 TheRouter 页面跳转

3.1 声明路由项

3.2 发起页面跳转

3.3 路由表生成规则

3.4 动态路由表的设计与使用

3.5 高级用法

四、跨模块依赖注入 ServiceProvider 的设计

4.1 服务使用方：拉拉

4.2 服务提供方：小货

五、单模块自动初始化能力 FlowTaskExecutor 的设计

5.1 FlowTaskExecutor 使用介绍

5.2内置初始化节点

5.3 实现原理

六、动态化能力 ActionManager 的设计

6.1 Action 使用

6.2 高级用法

6.3 客户端动态响应使用场景

七、一键切换源码与 AAR

7.1 模块化支持的 Gradle 脚本

八、从其他路由迁移至 TheRouter

8.1 迁移工具一键迁移

8.2 与其他路由对比

九、总结

张涛 - 菲律宾这国家到底怎么回事

菲律宾到底是个什么国家

两次殖民

两个大岛

2.1、初始化

2.2、定义页面容器