大终端领域的新物种-KUN

KUN的 背景/动机

即使已经到了2022年， 在面向复杂多变的用户端开发领域，我们依然绕不开一个问题 ？我们选择什么技术更适应我们的业务场景，不管是通用还是独特。这回到一个问题的原点，每一种技术都有它的局限性（短板）。

单一技术的缺陷

• • Native技术的局限性

  • • 尽管Native技术在用户体验上有绝对的天然优势，但在工程化，部署效率，敏捷上又有天然的短板。

      （1）工程化效率低

  • • • 工程复杂度高，由于天然的把所有的业务集成在一个工程里，依赖复杂性，工程复杂度高

      • 编译效率低，切环境，编译打包，效率低。这显著影响实际的开发效率。

    （2）部署效率低

• • • 由必须依赖用户的安装更新，生效周期长，导致实际迭代效率慢。

• Web技术的局限性

• • 尽管Web技术是当今最流行的GUI技术，但受限于浏览器架构/渲染模型， 使其在体验上有天然的劣势。特别是在强调 “图片/动画/视频控制、长列表容器、多Tab容器”等场景显得力不从心。

  • 涉及底层基础能力，必须依赖Native技术的增强。

更广义而言，这是C/S架构和B/S架构技术对比的缩影，历史上从以C/S架构为开始，到以B/S架构的大流行。而PC互联网时代后，Native技术和Web技术在移动互联网上的继续相爱相杀。

烟囱式多种技术并存的挑战

技术上的乌托邦，理想的情况， 我们期望日常的业务软件开发关注于业务本身的复杂度（比如前台而言关注与，核心关注于业务模型复杂度/展示复杂度/交互复杂度），而不是更多的关注于技术工具本身的复杂性。

但实际的情况却相反， 我们往往考虑技术工具的问题，比如 什么场景下适合使用什么技术？什么时候使用 native技术， 什么时候使用web技术， 什么时候使用非web的跨端技术， 什么时候使用某些特定领域的技术，随着业务场景越来越多，越来越复杂，我们的技术工具的数量也在不断的上升 。

每多增加一种技术工具，背后需要额外的投入， 

• 如何学习熟练掌握一种技术工具。

• 如果不断优化提升技术工具，使之在质量和效率上不断提升。

• 技术工具之间的耦合关系 使得复杂度进一步上升， 为了解决这部分复杂度所需要的额外的成本。

• 组织效率的降低， 容易形成更多的开发瓶颈。

技术的割裂，对中小规模的技术团队的影响更加明显，因为技术的割裂，更加容易产生因为技术本身导致的人力瓶颈。

有没有一种技术，在效率、体验、通用性取得最大化的平衡。甚至打破传统按技术栈粒度进行划分的职能边界， 统一到普遍意义上的终端开发工程师职能上。

KUN是什么

KUN 是一个让开发者使用 Javascript，HTML，CSS进行开发，使用Flutter进行增强的跨端开发框架。

它最早的雏形是来自Kraken， 正如 鲲 这个名字所内涵的：北冥（Kraken）有鱼，其名为鲲（Kun）。Kraken将Flutter技术引入并应用于Web技术栈，而在和Kraken团队的交流中吸取了大量的优秀知识。

但我们并不希望去做一个仅仅基于Flutter渲染带裁剪的Web浏览器。相反，我们试图去完美融合Web生态和Flutter生态。我们希望在面向中小规模的大前端/大终端的组织中，找到一种 真正适合的，长期性的，通用型解决方案。来解决包括我们闲鱼技术团队在内的，大前端/大终端所面临的前端用户体验低、客户端效能低、团队技术割裂、技术协作成本高等一系列问题。

KUN 项目组是一个技术栈高度互补的团队，包含flutter、前端、native 多技术栈的关键专家开发者， 在这个过程中，缺少任何一方都将大幅度的降低所能达到的上限。

就像KUN Logo 所隐喻的，它既像一条大鱼又像一个猫身，它是对立和统一的结合体。

<