假设您已经使用了mediapipe一段时间，是否和我的想法一样。
为什么是mediapipe
1）对ML开发者来说，MP（mediapipe）可以大大简化工程架构方面的开发工作。
2）对于Google来说，MP可以帮助tensorflow的推广，形成矩阵产品。
极致的优雅
优雅的架构理念，优雅的OOP程序设计，优化的代码编写细节，能遇到你真棒！
数据结构--packet
packet是MP中传递数据的封装格式。MP已有算子中的packet均使用共享指针的方式传递内存对象。
数据结构--stream
stream是算子多线程运行的核心思想，算子的运行时依靠数据驱动的，当算子需要的所有数据到齐后算子开始process。stream巧妙的完成了算子的多线程调度。
数据结构--calculator
calculator的存在是为了复用。当积木足够多时，就可以搭建漂亮的大楼，算子就是积木。如果你想使用一大块木料直接制作大楼，将其直接作为一大块积木，这样也挺不错的，只是缺乏复用性。
MP的优雅很大程度上体现在算子的拆分上，一个通用的计算就值得封装成一个算子。
数据结构--graph
graph就是算子拼成的大厦，一个合法的graph不能存在数据流转的环装结构，graph描述的有向图使用类似json的文本配置，在初始化时就确定了，它是静态的。
有向图配置的合法性校验仅在初始化时做一次，后续可能出现数据断流引发的卡死问题，这和graph无关，每个算子都要保证在任意情况下都要将数据传递下去，即便是无意义的数据，因为数据驱动。
graph可以嵌套使用，这一切都是为了复用。子graph就如同一个大算子。
配套设施
MP提供了一些工具，包括graph可视化工具，这是一个web应用。
并且提供了profile和tracing的工具。
这些工具都不太好用。也许MP的用户量足够大，才值得拥有完善的工具链。
性能
MP是深度基于tensorflow和opencv的，性能一方面取决于算子逻辑，一方面取决于opencv和TF在此平台上的运行性能。
MP现有的ML demo如果用于学习交流，性能是足够的。
跨平台
MP的代码组织基于bazel，framework的设计编写尽量避免平台相关性。
是否跨平台很大取决于：
1）算子使用到的算方库是否跨平台。
2）目标平台的硬件性能是否足够。
代码复用
从架构上来说，算子的复用非常方便。
算子的编写应该考虑复用性问题，包括跨平台的复用性。设计之初即在注释中声明目标适配平台、输入输出，以便于复用。
MP的代码是bazel组织的，一般来说很难直接被VS、Android studio、Xcode直接使用。可以使用bazel编译成sdk的方式提供给app开发者，无法整体联编。IDE一般来说对cmake兼容性较好，bazel plugin在IntelliJ上（包括AS）并不易用，bazel plugin被设计成使用全部使用bazel来编译工程，而非bazel、gradle、cmake、ninja相互配合，对于Android开发者来说放弃gradle开发app是不太现实的。
同类型框架比较
DStream，线性数据流转，待补充。。
优缺点
方便算子开发，复用。这里包括：
- 方便的算子单测方案
- 方便的算子profile
- 方便的算子性能标准设定
方便控制算子并行串行运算关系
通过类似json的文本配置就可以做到，非常优雅
深度基于TF
对于希望更换inference库的ML开发者来说很不友好，将TF连根拔起至少需要删除70%的代码。
静态图
为什么不是动态图呢？有些时候某个算子是否运算是需要根据实际来数据决定的，如果检测不到人脸就不需要提取人脸关键点和位姿信息，但是对于静态图来说为了满足数据确定，我们必须要传递数据进入关键点算子和位姿算子，实际上些算子仅做了判断和跳过。我们希望没有人脸时就直接返回结果，这就需要动态图。
对于移动端来说过于笨重
MP framework将近10M，这还是将TF裁去之后。
