作者：吉丰
一、 KUN的背景/动机
即使已经到了2022年，在面向复杂多变的用户端开发领域，我们依然绕不开一个问题？我们选择什么技术更适应我们的业务场景，不管是通用还是独特。这回到一个问题的原点，每一种技术都有它的局限性（短板）。
1. 单一技术的缺陷
1) Native技术的局限性
尽管Native技术在用户体验上有绝对的天然优势，但在工程化，部署效率，敏捷上又有天然的短板。
工程化效率低
• 工程复杂度高，由于天然的把所有的业务集成在一个工程里，依赖复杂性，工程复杂度高。
• 编译效率低，切环境，编译打包，效率低。这显著影响实际的开发效率。
部署效率低
• 由必须依赖用户的安装更新，生效周期长，导致实际迭代效率慢。
2) Web技术的局限性
• 尽管Web技术是当今最流行的GUI技术，但受限于浏览器架构/渲染模型，使其在体验上有天然的劣势。特别是在强调“图片/动画/视频控制、长列表容器、多Tab容器”等场景显得力不从心。
• 涉及底层基础能力，必须依赖Native技术的增强。
更广义而言，这是C/S架构和B/S架构技术对比的缩影，历史上从以C/S架构为开始，到以B/S架构的大流行。而PC互联网时代后，Native技术和Web技术在移动互联网上的继续相爱相杀。
2. 烟囱式多种技术并存的挑战
技术上的乌托邦，理想的情况，我们期望日常的业务软件开发关注于业务本身的复杂度（比如前台而言关注与，核心关注于业务模型复杂度/展示复杂度/交互复杂度），而不是更多的关注于技术工具本身的复杂性。
但实际的情况却相反，我们往往考虑技术工具的问题，比如什么场景下适合使用什么技术？什么时候使用native技术，什么时候使用web技术，什么时候使用非web的跨端技术，什么时候使用某些特定领域的技术，随着业务场景越来越多，越来越复杂，我们的技术工具的数量也在不断的上升。
每多增加一种技术工具，背后需要额外的投入，
• 如何学习熟练掌握一种技术工具。
• 如果不断优化提升技术工具，使之在质量和效率上不断提升。
• 技术工具之间的耦合关系使得复杂度进一步上升，为了解决这部分复杂度所需要的额外的成本。
• 组织效率的降低，容易形成更多的开发瓶颈。
技术的割裂，对中小规模的技术团队的影响更加明显，因为技术的割裂，更加容易产生因为技术本身导致的人力瓶颈。
有没有一种技术，在效率、体验、通用性取得最大化的平衡。甚至打破传统按技术栈粒度进行划分的职能边界，统一到普遍意义上的终端开发工程师职能上。
3. KUN是什么
KUN是一个让开发者使用Javascript，HTML，CSS进行开发，使用Flutter进行增强的跨端开发框架。
它最早的雏形是来自Kraken，正如鲲这个名字所内涵的：北冥（Kraken）有鱼，其名为鲲（Kun）。Kraken将Flutter技术引入并应用于Web技术栈，而在和Kraken团队的交流中吸取了大量的优秀知识。
但我们并不希望去做一个仅仅基于Flutter渲染带裁剪的Web浏览器。相反，我们试图去完美融合Web生态和Flutter生态。我们希望在面向中小规模的大前端/大终端的组织中，找到一种真正适合的，长期性的，通用型解决方案。来解决包括我们闲鱼技术团队在内的，大前端/大终端所面临的前端用户体验低、客户端效能低、团队技术割裂、技术协作成本高等一系列问题。
KUN项目组是一个技术栈高度互补的团队，包含flutter、前端、native多技术栈的关键专家开发者，在这个过程中，缺少任何一方都将大幅度的降低所能达到的上限。
就像KUN Logo所隐喻的，它既像一条大鱼又像一个猫身，它是对立和统一的结合体。
二、 KUN的独特价值
既然已经有了React Native，WEEX2.0，Kraken等跨平台开发框架，我们为什么还需要KUN？
React Native试图去混合和连接JS生态和OEM的GUI生态（Android生态&iOS生态）。但最大的问题在于其不同OEM生态之间天然的差异，去抹平它们之间的差异，是一件极具挑战的目标。而舍弃操作系统GUI生态，试图去重新构建一套独立完整的GUI系统去对接JS生态，是一件非常有抱负的目标。它可能意味着在对齐W3C标准上的更高的上限，但同样这个方向上，挑战重重。
1. KUN站在巨人的肩膀上，做出独特的价值-开放性
1) KUN从一开始就不试图去达到完备的W3C的标准。
接受达到W3C标准（包括html标签标识，CSS样式标准，WebAPI标准）的必要的子集对我们而言充分的。我们在一开始就对我们的目标做取舍和精确的定义。
2) KUN基于Flutter GUI系统和其生态，以极低的扩展成本，向上层JS运行时提供大量丰富的扩展标签/组件。
KUN不试图去构建全新独立的GUI系统，也不去试图抹平多个操作系统GUI之间的差异。最大程度结合JS技术/生态和Flutter技术/生态，取长补短，优势互补。
KUN的开放性是KUN最显著的特征。通过更加开放和轻量化的容器设计和实现。KUN试图通过更加开放性的架构设计，去混合兼顾JS&Flutter。开放性，技术上意味着：
• 有更广泛的通用性
• 更大的生态/社区的支持
• 有更敏捷的响应性
• 有更长期的成长性
结合闲鱼技术在flutter技术领域的天然优势，去混合连接JS生态&Flutter生态，通过更加开放&更加轻量化的设计，在效率，体验，通用性上去取的最佳平衡。
基于将Flutter生态融入到Web生态中，同时高度的开发性，有着更加广泛的通用性，使得从技术和组织的各种为政，从烟囱式的多技术栈，有机会向分层的技术融合转变，走向技术统一，最后进一步到组织融合成为可能。不再按细粒度的技术栈划分职能岗位，而是统一为职能更大类的终端开发工程师或者开发工程师转变。
这尤其在中小规模的技术团队组织中，产生更加显著的价值。
当然就这一融合目标的达成，需要考虑至少三个因素：
• 技术方案能不能行
• 组织内同学愿不愿意
• 外部环境趋势是否符合
接下篇：https://developer.aliyun.com/article/1225898?groupCode=idlefish
