概要：什么是端排序？怎样在不附加挤占服务器端资源的情况下，在应用程序化解排序市场需求？端排序和云排序相比，有什么样优势？责任编辑从结构设计两个化解埋点热修难题地小型化构架，及其演进以至化解其他端排序难题的事例，来说明设计两个端排序构架的形式化方式。

终端端发展至今，问世了很多构架用于化解各领域的私有难题。比如特别针对终端端梅利尼的Hybrid计划；兼具梅利尼和性能的RN、WEEX以至介面构筑计划；特别针对热复原的各式各样Patch计划；还有一些配置、选曲等特殊市场需求的计划。这些计划的核心都是用某种语言叙述业务的方法论方式，叙述能力越强大，能化解的难题越多。JavaScript似乎有着无穷的可能性，但当他们试著化解某一黑暗面的排序难题，对难题排序的可行性研究又缺乏自信心。此外，恰当评估结果各式各样构架的排序性无穷大对他们THF1、化解具体难题也是十分重要的。因而须要总结怎样结构设计、评估结果端排序构架的形式化方式。

一 从化解埋点热修难题理解何谓端排序

因众所周知的原因，苹果公司明令禁止类似JSPatch的热复原计划上架。对小蜜蜂iOS应用程序，大多数难题须要发版化解。透过发版化解统计数据难题，周期短且持续造成脏统计数据。对倚赖统计数据驱动力产品插值的Attichy会造成很大影响。同时，我也在思考与否有一种更灵巧的终端端取数计划，延长统计数据试验周期。基于以上目的，埋点热修计划的研发就推上了议程。

虽然他们能使用JSJAVA作为排序媒介，但须要证明埋点热修与否可透过排序复原。

示意图右图，埋点复原其实就是将两个严重错误的词典排序为两个恰当词典的过程。如果满足用户下面两个前提，则能修改任何严重错误的埋点统计数据：

要满足用户第两个前提，能根据词典本身的统计数据特点、可视化特点、当前网页等语句统计数据来辨识。埋点统计数据源于服务器端返回统计数据、后端位置及可视化和网页语句。要满足用户第三个前提，只须要补充上述统计数据即可。因而接入的统计数据源与否完整，是决定框架复原能力上限的两个重要的因素。

上面化解了埋点错埋和多埋的难题，但不能化解埋点漏埋的难题。化解埋点漏埋须要在可视化的合适时机，排序好埋点词典传输给SDK。排序的难题上面已经化解。那么只要满足用户在合适的时机排序，就能化解埋点漏埋的难题。

综上所诉，如果要复原埋点难题，则须要满足用户下面三个前提：

其实对错埋和多埋的复原场景，就是在上报SDK前这一时机进行排序。

至此，两个化解埋点热修难题的排序框架原理基本完成。框架主要围绕三件事情展开：

排序、统计数据、时机是两个排序框架能力最重要的三个因素。为了进一步说明，下面给出两个复原加购埋点漏埋难题的事例。

随着提供的API、统计数据以及时机能力增强，该框架能化解一些线上功能性难题复原。比如：

此外，还进行过一些统计数据实验。比如分析5秒内用户退出APP的原因，UT通道统计数据丢失指标建立等。

对排序、统计数据、时机三个维度的补充，框架已经从埋点复原，泛化为一般的端排序框架。透过控制统计数据，去影响APP的功能。从端排序的角度看JSPatch等热修框架，它的排序、统计数据层面限制较少，但复原时机是函数调用级别。相比代码行级别的复原，框架对复原计划有一定的限制。

二 从端排序角度改善DinamicX框架

DinamicX的构筑能力非常强，一般情况下，模板主要从单一统计数据源取数排序。统计数据源通常由网络请求下发。

如果期望做一些接口胶水层聚合，或者定制应用程序ViewModel的方法论，能接入FAAS层对DX的统计数据源进行重排序。

但FAAS只能利用服务器端侧统计数据进行排序，从端排序角度看，无法天然使用应用程序侧统计数据进行排序。这样并不适应须要服务器端侧和应用程序侧统计数据共同排序的市场需求。比如有些展示坑位有红点提示，须要点击后让红点消失，或者消失后隔一段时间再次展示。这个需求应用程序侧相对好实现一些，坑位点击后本地打标，也不须要消耗服务器端资源。服务器端也有一些计划，比如点击后发起请求由服务器端打标，然后FAAS层根据标记排序统计数据源展示。或者应用程序打标，在请求时回传标记给服务器端

不想消耗服务器端资源，又想从DX层面实现这个市场需求，如果看了之前埋点热修的框架计划，很自然的得出下面的解法。

这个计划是能化解上面的难题，但也有一些结构设计上的难题。比如纯梅利尼发版化解有些麻烦，方法论分散，应用程序会有附加的内存、IO操作。回到难题本身，其实他们是期望在DX引擎渲染排序时能利用服务器端侧和客户端侧统计数据。我透过对DX框架的学习，发现一种更优雅化解该难题的计划。

虽然DX渲染接口上只能使用单一统计数据源，但DX提供了DataParser自定义排序表达式机制。他们能定制两个DataParser，在模板渲染中使用应用程序侧统计数据。这样DX模板其实能支持多种统计数据源进行排序。同时DX提供了两个用户语句，用于参与DataParser和EventHandler的排序。他们能结构设计两个DataParser，以及持久化能力。从时机角度看，其实DX能在事件触发时，执行多个EventHandler。这样能透过组合执行EventHandler代替类似万能函数的EventHandler实现。使排序更具有灵活性。最终改造后的计划如下。

新计划透过排序和统计数据两个角度进行了优化。计划不附加挤占服务器端资源，在DX模板中实现了全部方法论，同时支持动态发布能力。比较优异地化解了该市场需求。

三 端排序优势以及未来发展

排序上云目前是趋势。极端的角度看，期望应用程序越做越轻，将主要的排序能力放到云上化解。我之前做过类似云游戏的计划，3D游戏这种极端倚赖应用程序硬件能力的应用也能上云。随着通讯技术的进一步发展，游戏上云、APP上云将来会有商业化产品出现。虽然趋势如此，但端上依然有两大优势，是云排序无法替代的：一是算力经济性，二是统计数据完整性。

从算力经济性角度看，端设备硬件的算力逐渐攀升。一般使用场景，算力其实是过剩的。同时频繁、大统计数据量的通讯，无论对用户还是运营组织，都是存在成本的。云排序与端排序未来会因经济性和体验，在适用场景上达到两个平衡。这是整体排序经济性最优导致的结果。

从统计数据完整性角度看，端上采集永远是第一手统计数据，无论维度还是统计数据量都较大。这些统计数据传输，以及在云上还原用户语句场景都须要巨大的算力。云端获得统计数据前，须要端上处理、清洗统计数据。云端统计数据始终存在人为的信息丢失、修改情况。可排序性倚赖统计数据完整性，另外出于对响应、算力的考虑，有些排序场景下放到端上排序更合适。特别是一些须要大量、复杂用户语句统计数据参与的场景。此外，未来隐私合规升级，统计数据传输到云上会更为谨慎。为了保证一些服务的可持续运行，须要提供端排序的适配计划。

服务器端和应用程序都满足用户统计数据完整性的情况下，如果应用程序再提供排序动态性支持，其实选用哪个计划没有本质性区别。例如FAAS服务能使用云排序实现，也能使用端排序实现。剩下的是性能、体验、成本以及稳定性等其他方面综合性考虑。