阅读代码时，在不同的文件中跳转，不同的函数又在文件中的不同行，要记忆调用的流程，不仅要记忆函数名、函数所在代码行、文件名，甚至对于结构复杂的项目，还要记忆不同的文件夹路径，如此多的记忆点，如此繁复的心智负担，对于只想梳理逻辑学习的我们，不得不说太难了。

        常规的操作，就是准备好本地开发环境，然后切换到早期代码量较小的版本，然后根据自己的兴趣点，通过打断点或者命令行打印的方式来梳理逻辑。但是，对于较复杂的项目，逻辑结构一复杂，调用层次过深，在多个文件中不停跳转、调用，往往让人苦不堪言。

        简单来说就是，复杂的嵌套关系，繁琐依赖结构，来回跳转几次后，就让人迷失在代码的汪洋之中，可我们的目的是想要尽快的理解核心机制啊！而可视化读代码就就能解决这个问题，如用Codemap1来阅读代码，会倍感轻松。

        我们拿个例子对比看看，以Animated Drawings 2为例👇

普通阅读代码

        安装正常后，按照文档说明，在本地运行，便能启动基础范例。

空格：暂停，esc：退出，←↑→↓：逐帧播放，awds控制摄像机左右前后移动
 

        通常，我们会通过入口文件，在IDE中逐个文件或函数查看代码的具体实现机制。

        比如 render.start('./examples/config/mvc/interactive_window_example.yaml') 这段代码，首先调用了配置文件interactive_window_example.yaml，然后通过 render 的 start 方法启动。

        接着，我们会发现 interactive_window_example.yaml 又调用了 char_cfg.yaml、dab.yaml、fair1_ppf.yaml 文件，但各个文件的具体功能对于初学者的我们却无从得知。render.start 方法首先初始化了 cfg 实例，然后通过 cfg 中的具体配置，分别创建了 view、scene、controller 等实例，最后通过 controller.run() 启动。

        在 controller.run 中首先执行了 self._prep_for_run_loop()，然后通过检测是否 self._is_run_over() 执行死循环，包括 self._start_run_loop_iteration()、self._update()、self._render()、self._tick()、self._handle_user_input()、self._finish_run_loop_iteration() 等更新算法，最后执行 self._cleanup_after_run_loop()。

        而针对更具体的 self._prep_for_run_loop()、self._prep_for_run_loop() 等更新算法的实现机制，我们发现他们在 Controller 类中都是通过抽象方法 @abstractmethod 定义的，也就是说对于具体的执行流程，要查看具体执行的函数需要看在函数的运行流程中，具体是哪个 Controller 的子类被实例化了，那个子类实现的 self._prep_for_run_loop()、self._prep_for_run_loop() 等方法才是真实被执行的代码，因此，我们需要跳转到 render.py 文件中，查看 controller 的实例过程。

        通过代码，我们发现controller的具体实现类是由 cfg.mode 决定，即当 config 中 mode 为 video_render 时，controller 为 VideoRenderController 的实例，当 mode 为 interactive 时，controller 为 InteractiveController 的实例。也就是说，具体执行的 self._prep_for_run_loop()、self._prep_for_run_loop() 等更新算法由 config 中的 mode 决定，当 mode 为 video_render 时，程序流中执行的就是 VideoRenderController 中的 self._prep_for_run_loop()、self._prep_for_run_loop()，否则就是 InteractiveController 中的 self._prep_for_run_loop()、self._prep_for_run_loop()。而具体的 mode 值，在 interactive_window_example.yaml 中，interactive_window_example.yaml 又依赖 char_cfg.yaml、dab.yaml、fair1_ppf.yaml，我们需要不停地在不同的文件夹中打开不同的文件，不停地查找、切换，才能验证这个最简单的范例究竟是怎么执行的。

        为了这么简单的需求，我们不停地打开文件，不停地切换，对于初学者，大脑早就一团乱麻，不必要的思维负担已经消耗了绝大多数的脑力，而对于更重要的具体更新机制，却还一筹莫展。

可视化读代码

        所谓可视化读代码，简单来说以图形或图形格式表示代码的过程，而不是传统的文本行，较为常见的就是依赖关系图，架构图和流程图等，但它们都需要另外生成，并不能直接展现。

        而Codemap 摒弃了tab页的打开方式，通过平铺布局，以及连线、高亮、标注等一系列手段，辅助用户阅读源代码，告别了为了研究代码的执行机制，而不停切换文件，不断展开、折叠源代码的历史，为用户提供了一种可以清晰展示代码逻辑结构、添加高亮备注的方式。如下视频演示（Animated Drawings 在Codemap中的可视化分析过程）👇

 


        单行的代码大家都认识，但是复杂的项目为什么就看不懂了呢？其中的关键在于阅读源代码的过程中，我们的大脑做了太多的无用功，在现有的IDE中需要记忆大量无关紧要的中间函数、路径，甚至所在代码的行数，而通过Codemap，我们能很好地解决这个问题。

Codemap界面

1、回到上述问题，cfg.mode的具体取值影响了程序流，但在用户显式加载的配置文件interactive_window_example.yaml等中并没有mode配置项，着眼于程序示例1（蓝色标记），发现Config类会加载默认配置 mvc_base_cfg.yaml，在该文件中有配置项MODE: 'interactive'，因此可以证实controller是InteractiveController的实例。

2、在程序示例2（蓝色标记）处，展示了controller.run()的执行步骤，但是具体的执行函数在Controller父类中都是抽象方法，具体的实现在子类InteractiveController中。

3、如图示例3（蓝色标记），InteractiveController会依次执行：

  1. _prep_for_run_loop：更新self.prev_time为当前时间
  2. _is_run_over：通过glfw.window_should_close(self.view.win)来判断是否需要执行以下循环
  3. _start_run_loop_iteration：调用self.view.clear_window()，实际是通过OpenGL清理窗口
  4. _update：通过平移、旋转、缩放矩阵相乘，求最新的矩阵
  5. _render：首先通过view._update_shaders_view_transform()等更新camera信息，然后调用scene.draw()渲染
  6. _tick：更新时间
  7. _handle_user_input：处理用户输入
  8. _finish_run_loop_iteration：交换缓存
  9. _cleanup_after_run_loop：执行清理程序

        

通过Codemap进行分析，我们已经大致地了解了Animated Drawings的启动流程，而且期间不会再因为不停地打开、切换文件，不停折叠代码、不停跳转而烦恼了，这次进行了分析，下次还能在今天的基础上继续研究。

        通常，对于越复杂的项目，Codemap的效果越好，想象一下，你要打开几十个文件，每个文件里面都是你不熟悉的类和函数，对于他们之间的调用、依赖关系，如果纯用脑力，我相信你会爆炸的。