什么是端计算？如何在不占用额外服务器资源的情况下解决客户端的计算需求？端计算与云计算相比有哪些优势？以通用架构及其演进乃至解决其他端计算问题的案例来说明设计端计算架构的一般方法。移动端发展以来，诞生了很多架构，解决各个领域的专有问题。例如，移动端动态的Hybrid解决方案；兼顾动态性和性能的RN、WEEX甚至接口构建方案；用于热修复的各种补丁解决方案；以及一些特殊需求的解决方案，例如配置和安排。这些解决方案的核心是使用某种语言来描述业务的逻辑方法。描述能力越强，能解决的问题就越多。脚本语言看似拥有无限可能，但当我们试图解决一个未知领域的计算问题时，我们对问题计算的可行性缺乏信心。此外，正确评估各种架构的计算极限对于我们选择模型和解决具体问题也非常重要。因此，有必要总结一下如何设计和评估端计算架构的通用方法。1、从解决热修复问题的角度理解什么是端到端计算？由于众所周知的原因，Apple禁止推出JSPatch等热修复程序。对于KoalaiOS客户端，大部分问题需要发布才能解决。通过发布解决数据问题，周期长，脏数据不断产生。它将对依赖数据驱动产品迭代的开发方式产生重大影响。同时我也在思考是否有更敏捷的移动数据接入方案来缩短数据实验周期。基于以上目的，埋地式热修方案的研发已提上日程。虽然我们可以使用JS脚本作为计算载体，但是我们需要证明埋点热修复是否可以通过计算来修复。如上图所示，埋点修复其实就是将错误的字典计算成正确的字典的过程。如果满足以下两个条件，则可以纠正任何错误的埋点数据：错误数据可以被无歧义地识别。数据齐全，可以计算出正确的数据。满足第一个条件，可以根据字典本身的数据特征、交互特征、当前页面等上下文数据来识别。埋点数据来自服务器返回的数据、前端位置、交互和页面上下文。满足第二个条件，只需补充上述数据即可。因此，连接的数据源是否完整是决定框架修复能力上限的重要因素。以上解决了错埋和过埋的问题，但不能解决漏埋的问题。解决遗漏埋点问题，需要计算埋点字典，并在交互的合适时机传给SDK。上面的计算问题已经解决了。那么只要在合适的时候满足计算，就可以解决埋点和漏埋点的问题。综上所述，要想修复埋点问题，需要满足以下三个条件：能够无歧义地识别错误数据。数据齐全，可以计算出正确的数据。需要在正确的时间进行计算。其实对于错埋和过埋的修复场景，都是在这个时候进行计算，然后再上报给SDK的。至此基本完成了一个解决埋点热修复问题的计算框架原理。该框架主要围绕三件事：1.为JSContext补充API提供基本的计算能力。二是补充数据源，为计算提供素材。三、增加触发计算的时机。计算、数据和时序是计算框架能力中最重要的三个因素。为了进一步说明，下面以修复追加购买丢失埋点问题为例。通过提供增强的API、数据和时序能力，该框架可以解决一些在线功能问题修复。例如：修复视频多段拍摄问题：修改进入剪辑编辑器前传入的音轨信息，禁用多段拍摄功能，调整页面相关控件的显示状态。修复搜索特定关键字导致富文本渲染崩溃：修改发送数据字段避免崩溃问题。修复品牌方非自营商品搜索请求因参数不足导致失败：修改接口请求体，补充必要数据。修复切换SKU时，某区域数据不刷新的问题：切换SKU后，重置该区域View的显示状态。此外，还进行了一些数据实验。例如，分析用户5秒内退出APP的原因，建立UT通道数据丢失指标等。将计算、数据、时序三个维度进行互补，框架从埋点修复，泛化为一个通用端计算框架。通过控制数据，影响APP的功能。从端计算的角度来看，JSPatch等热修复框架对计算和数据层面的限制较少，但修复的时机是在函数调用层面。与代码行修复相比，框架对修复方案有一定的限制。2、从终端计算的角度改进DinamicX框架DinamicX具有很强的构建能力。一般来说，模板主要是从单一数据源计算而来。数据源通常由网络请求传递。如果想做一些接口胶层聚合，或者自定义客户端ViewModel的逻辑，可以接入FAAS层重新计算DX数据源。但是，FAAS只能使用服务器端的数据进行计算。从端侧计算的角度来说，自然不能使用客户端的数据进行计算。这不符合服务器端和客户端数据联合计算的需要。比如有些显示坑有红点提示，需要点击使红点消失，或者消失后过一段时间再显示。这个需求在客户端实现起来还是比较容易的。点坑后，本地标记不需要消耗服务器资源。服务端也有一些解决方案，比如点击后发起请求由服务端做标记，然后FAAS层根据标记计算出数据源展示。或者客户端进行标记，请求时将标记返回给服务端，然后FAAS层计算并显示数据源。两种服务端的解决方案本质上是相似的，都是尝试从服务端获取标记数据。不想消耗服务端资源，又想从DX层面实现这个需求。如果之前看过hotfix的框架方案，自然会想出下面的方案。该方案可以解决上述问题，但也存在一些设计问题。比如纯动态发布的方案就有点麻烦，逻辑分散，客户端会有额外的内存和IO操作。回到问题本身，其实我们期望在DX引擎渲染计算的时候，能够使用到服务端和客户端的数据。通过研究DX框架，我找到了更优雅的解决这个问题的方法。虽然在DX渲染界面上只能使用单一数据源，但DX提供了DataParser自定义计算表达式机制。我们可以自定义一个DataParser以在模板渲染中使用客户端数据。这样一来，DX模板其实是可以支持多种数据源进行计算的。同时DX提供了用户上下文参与DataParser和EventHandler的计算。我们可以设计一个DataParser来获取用户上下文中的键值对数据；另外，我们可以设计一个EventHandler，将键值对数据设置到用户上下文中。用户上下文提供多种生命周期存储方式，实现页面内DX组件间的数据互通，页面间DX组件间的数据互通，以及持久化能力。从时序上看，其实DX可以在一个事件触发的时候执行多个EventHandlers。这样就可以通过组合执行EventHandler来实现，而不是类似universalfunction的EventHandler。让计算更灵活。最终修改方案如下。新方案从计算和数据两个角度进行了优化。该方案不占用额外的服务端资源，所有逻辑都在DX模板中实现，支持动态发布能力。比较优秀的解决了这个需求。三端计算的优势和未来计算向云端的发展是目前的趋势。从一个极端的角度来看，预计客户端会越来越轻，主要的算力会在云端解决。之前做过类似云游戏的解决方案，像3D游戏这类非常依赖客户端硬件能力的应用也可以上云。随着通信技术的进一步发展，未来会有云上的游戏和应用程序的商业产品。虽然趋势如此，但端上还有两个优势是云计算无法替代的：一是算力的经济性，二是数据的完整性。从算力经济的角度来看，终端设备硬件的算力正在逐步上升。在一般的使用场景下，算力其实是过剩的。同时，频繁和大规模的通信对用户和运营机构都有成本。未来，云计算和终端计算会因为经济和体验，在适用场景上达到平衡。这是优化整体计算经济性的结果。从数据完整性的角度来看，设备上收集的永远是第一手数据，无论是维度还是数据量。这些数据在云端的传输和用户上下文场景的恢复需要巨大的计算能力。云在获取数据之前，需要在端对数据进行处理和清洗。云数据中总是存在人为的信息丢失和修改。可计算性取决于数据的完整性。另外，出于对响应和计算能力的考虑，将一些计算场景委托给端部比较合适。尤其是一些需要大量复杂用户上下文数据参与的场景。此外，未来隐私合规性将升级，数据上云将更加谨慎。为了保证部分业务的持续运行，需要提供端计算的适配方案。当服务端和客户端都满足数据完整性要求时，如果客户端提供动态计算支持，选择哪种方案没有本质区别。例如，FAAS服务可以使用云计算或端计算来实现。剩下的就是性能、体验、成本、稳定性等其他方面的综合考虑。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
