本文分为以下几个部分：
- 阐述打通Flutter和小程序跨端技术的商业意义。
- 阐述选择Taro作为小程序跨端方案的原因。
- 阐述目前已知的可以打通Flutter和Taro的思路。
本文的主要写作目的是：
- 和团队沟通此方向上的设想。
- 和Taro团队沟通我提出这个想法的动机和目前我已经有的信息。
- 和潜在的感兴趣的小伙伴交流思路，拉同伴一起研究。
小程序 as APP Clip
把小程序作为APP Clip，用以提高APP增长效率，是一种非常具有性价比的方式。
首先回答为什么增长效率重要。VC们在和我们创业者打交道时，最常问的、最可能影响他们决策的，就是增长速度是不是足够快到他们可以获得十倍百倍的效率。尽管我认为这种只盯着片面的财务数据的投资策略十分粗糙，但我们自己和我们服务的企业都需要面对这样的投资市场，所以我们必须要想办法提高企业的增长能力。然而，揠苗助长的行为往往只有利于投资者而不利于创业者，创业者得到的经常是一大堆隐忧。过快的增长如果没有足够的技术能力支持，往往会带来灾难性的成本攀升，或者迭代成本过高阻碍产品升级。坚实的技术基础，最起码可以让创业团队能够更好的解决问题，这是我们的能力范围内可以推动的事情。
接着简要概括增长渠道和常见问题。线上的角度，各大流量平台是最主要的渠道，包括但不限于微信、知乎、微博、抖音、快手、B站、百度、头条等等。通过自己企业的自媒体，或者通过平台购买广告，或者通过和平台上的Up主/小程序合作推广，或者APP插入广告等等，是最常见的方式。大部分平台都通过各种政策明里暗里限制往其他平台导流，因此自媒体行业常用的“所有流量导入微信维护”的策略已经越来越不安全了。随着各大平台的开放平台（比如微信开放平台、抖音开放平台等）建设起来，我们拥有了打通各个平台的能力，通过一站式打通全渠道的能力代替导入一个平台维护也成了可行的策略。（PS：B站和知乎什么时候能跟上。）
我经常研究抖音推荐给我的广告，分析他们做的效果怎么样。我总结最大的问题是，即使我比较感兴趣某个产品，但由于我只能看到一个填个人信息的表单，或者让我跳转到APP Store下载，大部分时候我是不会做下一步的。从用户增长的AARRR模型（获客-激活-留存-收入-推荐）的角度，我在“激活”这一步被卡住了。如果是一个抖音小程序，那么我是很有动力打开试试的。因此，如果我可以在这个平台的小程序上体验APP的一部分功能，感兴趣再去下载APP或者去找网站，那么“激活”甚至“留存”就可以更顺畅地完成了。这个思路恰好是Apple添加APP Clip特性的设计初。
这样我们自然而然可以得到一个结论：假设我有一个Flutter应用，如果Flutter可以复用这套适配方案到编译的小程序上，我们就可以获得一个承担APP Clip角色的小程序应用。
Taro是小程序跨端的最优解
要解决上述问题，我们首先需要选择一个小程序跨端框架和Flutter打通。
早在两三年前我就开始关注小程序跨端技术。Taro在1.x的时候我就有试用过，当时还不是太理想，没跑起来，于是放弃。然后我又看了微信小程序自己的kbone，看起来不太靠谱，遂放弃。美团的mpvue当时已经不维护了，因此也不考虑。滴滴的Chameleon一度是一个质量不错且很活跃的项目，并且团队有在认真考虑和Flutter的打通，因此我重点试用了一段时间，又是没跑通，遂放弃；它到去年也基本停止更新了，因此也不建议其他开发者再考虑。闭源的UniApp不考虑，项目质量一般，且谁知道会有什么幺蛾子卡住。
到这两年，几乎所有的小程序跨端都停在了原地，只有Taro勇敢地进行了重构，各个方面都有了明显的改变，社区治理也日益完善。因此站在今天的时间点，Taro几乎是小程序跨端唯一可靠的选择。
实现Flutter的Taro引擎
Flutter提供了很完善的文档教用户开发自己的引擎，因此我们遵循文档做一个Taro引擎即可实现我们的目标。
问题是怎么做。目前社区的尝试不是太多。唯一在Flutter适配小程序的方向上努力过的社区的试验项目flutter_mp在Web端stable之前做的，因此很大概率没有用上Web端的积累，估计可能参考价值也不大。Taro、Chameleon有一些零星的Flutter适配Taro或者Taro适配Flutter的讨论。总结来说Taro适配Flutter比较困难，我估计会得到类似于社区项目MPFlutter的结果。Flutter写Taro引擎相对容易。Flutter的Native引擎大多使用C++写底层；而浏览器使用的是Dart自带的dart2js，把Dart代码转成JS在浏览器运行，因此上线的时候我们会看到Web段有个1M多的main.dart.js文件。Dart这门语言本身就是为了代替JS、起到类似TS的作用发明的，因此原生支持了dart2js引擎。而小程序大多运行在V8引擎上，运行环境和Chrom浏览器十分类似，因此使用Flutter的Web引擎的思路（甚至很大一部分部分代码）适配一遍小程序即可。
如果想做出来这么一个引擎，我们需要：
- 熟悉Flutter应用开发的开发者，主要负责设计面向开发者的顶层效果。我自己比较熟悉Flutter开发，可以承担这个角色。
- 熟悉Flutter引擎开发的开发者，主要负责实现引擎的主体。同类项目，目前我只看到美团做过一个鸿蒙的引擎（结果是和Android差不多）。这个只能组织一批感兴趣的开发者研究Dart和Flutter自定义引擎相关的资料，有感兴趣的朋友可以和我讨论。
- 熟悉Taro引擎的开发者，主要负责适配引擎到Taro。我已经通过我在京东的同学联系Taro的核心团队讨论相关问题，首先想看下他们有没有相关积累，如果已有一些思路进展是最理想，如果没有就只好从头搭框架。
Plan B
如果这样的引擎很难做出来，我们依然有一些替代策略可以使用。一个基本思路是，维护Flutter和Taro两套代码依然是可以接受的，如果有足够的商业利益。
从设计的角度，维护多套客户端代码，往往需要独立设计稿项目出来，通过设计稿规范各个平台按照一致的要求实现。如果只维护Flutter，我们可以不要设计师、直接用Flutter优秀的组件库搭，也可以让有编程基础的设计师直接对着改，或者让设计师和前端工程师坐在一起现场改。这些都是Flutter团队在自己周围发现的实践，通过减少沟通流程和使用优秀组件，可以大大提高设计效率。
从数据分析的角度，维护多套代码需要严格地定义组件对应关系。比如，当我们需要前端埋点时，Flutter和Taro的某个组件是对应的，这里的埋点在统计时应当被视为同一个。一套代码同样可以显著地减少埋点成本。AB测试也是同理，不再赘述。
从Plan B的成本收益来说，有一个Flutter的Taro引擎是非常有价值的，这也是我希望可以推动社区一起研究这个可能性的原因。
