离上次聊跨端已经过去一年多了，想再聊一下跨端架构这件事，因为在实际工作中落地遇到了很多问题，以总结。
先回顾一下上次聊的内容，上次主要聊了跨端架构的重要性、核心概念以及实际应用的几种策略。我们将跨端架构分解为三个层面：硬件形态、相同硬件形态下的不同平台和相同平台下不同的应用或应用中的衍生应用。
还详述了几种常见的跨端架构方案，包括 H5 hybrid 方案、框架 + 原生渲染、框架 + 自渲染引擎和 DSL 编译 + 混合渲染。并深入探讨了如 Qunar 的 React Native 优先的多端统一化方案、Flutter 全平台方案和 Hybrid 方案等实际落地的策略。这些方案各有优缺点，需要根据特定的业务需求和场景来选择最适合的跨端架构方案。更多细节可以见：
而今，在此基础上，我想再聊聊关于跨端架构落地过程中因为遇到一些问题而产生的思考。
1 平衡
在实现「一次编写，多端运行」的愿景下，我们的核心关注点是成本和体验。这其中，复用代表了我们在成本方面的考量，我们希望通过复用代码来降低开发和维护的成本。而提升用户体验则代表了我们在体验方面的追求，我们希望无论在哪个平台上，用户都能得到最好的原生体验。
然而，这两个目标之间存在着一种天然的张力。在实践中，我们常常需要在代码复用（降低成本）和优化用户体验（提升体验）之间寻找一个平衡。这就需要我们不断地试错、调整，找到适合自己的最佳策略。
当我们从跨端的角度出发，面对的主要挑战是解决界面渲染和能力复用的问题。使用跨端开发框架，如React Native、Flutter 等，帮助我们实现代码的复用，以及在不同平台上进行统一的界面渲染。
再看到具体的界面，我们需要高效地解决屏幕适配的问题，这意味着我们的应用需要能够在不同大小、分辨率的屏幕上都能提供良好的用户体验。这可能需要我们使用响应式设计，或者针对不同平台进行特定的界面设计。
在这些个过程中，虽然我们是想「一次编写，多端运行」，这只是一个结果，这个结果的背后是复用和提升用户体验，更深一个层次是成本和体验，成本和体验是我们的核心关注点。在过程中，找到一个平衡。
2 区分大小屏
理想状态下，我们希望能够实现「一次编写，多端运行」，即不管在哪个平台，都只有一份代码。这样可以极大地提高开发效率，降低维护成本，并保证应用在各个平台上的一致性。
然而在实际的开发过程中，我们往往会发现，由于大屏和小屏设备的使用场景、用户行为习惯以及界面布局等方面存在着显著的差异，简单地复用一份代码并不能提供最佳的用户体验。因此，一个比较实际且合理的做法是，对大屏和小屏设备使用不同的代码。
对于大屏设备（如桌面应用和 WEB 版本），我们可以利用更大的屏幕空间来展示更多的信息，提供更丰富的交互方式。而对于小屏设备（如手机），我们则需要更注重信息的精简和易用性，以适应用户在移动环境下的使用需求。
虽然区分了大小屏，但并不意味着不能实现代码的复用。我们可以通过抽象和封装共享的逻辑和组件，来实现在不同代码库之间的复用。这样，我们既能保证在各个平台上提供最佳的用户体验，又能充分利用代码复用来降低开发和维护的成本。
这个区分的逻辑往往由实际的业务、产品逻辑以及组织分工来决定的，各家不同。比如要考虑小屏上的定位，如果手机浏览器访问只是一个移动流量入口，并不作为业务功能的，那么基于运营逻辑的复用和代码的复用，可以把大屏 WEB 做移动端适配。
3 选择合适的技术栈
评估和选择技术栈对于跨端架构落地来说一件非常重要的事情，我们不仅仅要考虑性能、开发效率、可维护性、扩展性以及成本（包括熟悉成本、部署成本等），还要考虑这个技术栈所在的社区，成熟度，以及现有团队对技术栈的承受力。
没有一种技术栈是适用于所有情况的。每种技术栈都有其优点和缺点，选择哪种最合适，取决于我们的项目需求、团队能力和期望的结果。如果选择新的、未经验证的技术，可能会导致技术债务，甚至会在项目的后期阶段导致大量的时间和资源消耗，最后让事情尾大不掉。
在实际的评估和选择过程中，跨端项目的负责人对此负主要责任。从团队的技能和经验是选择技术栈的关键因素。选择一种团队成员已经熟悉的技术栈，可能会比选择一种可能更适合项目但需要学习的技术栈更为实际。但是我们此时又需要考虑到是否当下的技术栈已经过时，或者引入新的技术栈能触发团队成员的学习热情，从而变成另一种激励呢？
进一步思考，我们必须认识到技术的选择并非一成不变。随着项目的演进和业务需求的变化，我们可能需要对技术栈进行迭代和调整。当我们在选择技术栈时，应该考虑到这种可能性，并选择那些具有一定的灵活性和可适应性的技术。
从技术栈的社区和生态系统，一个健康的社区和丰富的生态系统可以为我们的项目提供强大的支持，包括开源库、教程、工具和问题解答等等。选择一个有活跃社区和丰富生态系统的技术栈，可以大大提高我们的开发效率和项目的成功概率。
我们必须清醒的认识到：「人」是项目成功的关键。技术栈的选择应基于团队的能力和需求，而不仅仅是技术本身的优点。我们需要基于团队已有的人员配置，与团队成员进行深入的沟通，理解他们的需求和期望，然后做出最佳的选择。如果必要，我们还可以为团队成员提供培训和学习资源，帮助他们掌握新的技术。
在实际选择技术栈的时候，其考量点主要是三个：复用性、性能和多端一致性。
-
复用性：成本角度，研发效率（包括开发效率和发版效率） -
性能：用户体验角度 -
多端一致性：用户体验的统一
在复用性方面主要是渲染层的事情，关注点是业务差异性，及是否有复用的必要，复用对于原有架构是否会产生更多的影响。
在性能方面主要考虑响应速度、流畅度、稳定性等方面，主打一个顺滑和愉悦的用户体验。
多端一致性主要是用户体验的统一和体感一致。
以性能为例，可能需要考虑页面的复杂度，或者对性能的要求，比如长页面，多级嵌套页面，如iOS 上可能因为触发内存上限，系统优先清理 WebView，导致 WebView 白屏，或者页面的整体表现稳定性，不存在卡顿等等
那么，基于以上的考量点，大概要回答如下的判断基准问题：
-
复用度有多少？复用和不复用的人力差有多少？ -
复用对现有架构有哪些影响？ -
是否存在多层嵌套、长页面的场景，对于性能的要求指标是什么？需要测试一下现有 web 方案是否会触发白屏、卡顿等情况 -
当前页面是否关键页面，如果出现页面级的不可用，如何处理？ -
是否存在多端一致性的要求，一致性要求有多少？
在技术方案选择时，需要考虑当前产品所处的阶段，比如创始阶段，可能纯 WEB 方案就行，当发展到一定程度，可能在入口级页面需要有更好的用户体验，则可以把入口页面改为原生或者 Flutter 页面。
4 渐进式开发
渐进式开发是一种实施新技术或变革的策略，它的主要目的是降低风险、提高效率和保证稳定性。不会一下子太猛，导致项目挂了，或者风险不可控。
通过逐步引入新技术或变革，我们可以控制每个阶段的风险，避免一次性全面改变带来的巨大风险。如果在某个阶段发现问题，我们可以及时调整或回滚，而不会影响到整个项目。
渐进式开发也是一个持续学习的过程。团队成员可以通过实际操作和反馈，逐步深入理解新技术，提升自己的技能和知识，这通常比纯理论学习更有效。同时，每个阶段的成功实施都会增强团队的信心和动力，提高开发效率。
市场和技术环境总是在快速变化，渐进式开发使得我们能更好地适应这些变化。我们可以根据新的需求和情况，逐步引入新技术或进行优化，使项目始终保持在最佳状态。
渐进式开发在实施过程中有以下几种方式：
低风险模块试点：选择非核心的，风险较低的模块进行新技术架构的试点实施。在低风险的环境中尝试和学习新技术，为后续的全面实施打下基础。在过程中需要注意选择的模块应具有一定的代表性，以便能够有效地验证新技术栈。同时，要做好版本控制和回滚计划，以防新技术栈出现问题。
技术底层实施：从与业务逻辑关联较小，更侧重于技术实现的底层模块开始实施新技术。这种落地方式可以避免新技术栈对业务逻辑造成影响。同进，通过底层模块的实施，可以更深入地理解和掌握新技术栈。但是在具体实施过程中要特别注意到其广泛的影响，以及需要进行充分的测试，确保底层模块的稳定性和性能。
并行式开发：在维持旧技术栈的同时，建立新的团队在新的技术栈上开发新的功能或模块。这可以避免影响现有的业务，并且可以并行推进新技术栈的实施。但是要注意要做好新旧技术栈的集成和切换计划，以及要确保有足够的资源来支持并行开发。
在跨端架构的落地过程中，全方位的考虑和准备是关键，这包括团队的认知，项目的方向，以及有效的沟通。每个参与者，无论是发起人、负责人还是核心成员，都需要明确自己在过程中的角色并发挥其特有的责任和职能。
发起人提供方向和资源，负责人为项目负总责，制定详细的实施计划并监视进程，而核心成员则负责掌握新架构，实现功能需求并密切合作以解决问题。这是一个团队协作的过程，每个角色都扮演着关键的部分，以确保新架构的成功落地和最大化的效果。
5 规范的系统化
跨端是一个系统化的过程，规范在落地过程中逐步建立起来，整个规范系统化的过程包括协议管理，SDK 的生成和管理，文档统一，以及防劣化等等。
协议是我们交互和通信的基础，我们设立了统一的接口定义标准，每个接口都需经过严格的审核流程，确保数据的一致性和接口的稳定性。同时，我们引入了版本控制机制，确保 API 的演进不会破坏现有系统的稳定性，同时也方便了新功能的迭代。
SDK 的生成和管理是跨端架构中的关键环节。我们开发了一套自动化工具链，用于生成和管理 SDK，这不仅提高了开发效率，还确保了 SDK 的一致性和安全性。通过对 SDK 的严格版本控制和定期更新，我们能够及时修复已知问题，同时引入新的特性，以支持不断变化的业务需求。
在文档的统一方面，良好的文档是跨端协作的桥梁。我们建立了一套文档规范，确保所有开发者都能够轻松理解系统架构、API 使用和 SDK 集成。我们采用了 Markdown 格式来编写文档，并通过内部 Wiki 进行管理，这样不仅便于团队成员访问，也方便了新成员的快速上手。
防劣化是跨端架构中容易被忽视的一个方面。我们通过组织、系统、知识库三个层面来做到防劣化，组织层面，有一个跨端架构小组，系统层面实施代码审查、自动化测试、全局代码检测和性能监控等措施来确保系统的质量和性能，知识库层面通过前面的文档统一、SDK 管理及脚手架构等。这些措施帮助我们及时发现并修复潜在的问题，避免了系统劣化对用户体验的影响。
跨端不仅仅是技术层面的整合，更是对业务流程、用户体验和团队协作方式的一次革新。
在跨端落地过程中，我们会遇到多种问题，团队的问题，人员的问题，技术栈选择的问题等等，这些问题都是在过程中不断思考、决策和调整，以确保我们的架构能够适应快速变化的环境，同时也能够支持团队的高效工作。
希望通过这些努力，我们的跨端架构能够为公司带来长期的竞争优势。