导读：本文会先带领大家一起简单回顾下跨端技术背景与演进历程与在这一波儿接着一波儿的跨端浪潮中的饿了么跨端现状，以及在这个背景下，相较于业界基于 React/Vue 研发习惯出发的各种跨端方案，饿了么为什么会选择走另外一条路，这个过程中我们的一些思考、遇到及解决的问题和取得的一些成果，希望能给大家带来一些跨端方面的新思路。

跨端技术背景与演进历程

跨端，究竟跨的是哪些端？

自 90 年的万维网出现，而后的三十多年，我们依次经历了 PC 时代、移动时代，以及现在的万物互联（的 IoT ）时代，繁荣的背后，是越来越多的设备、越来越多的系统以及各种各样的解决方案。

总的来说，按照跨端的场景来划分，主要包含以下 4 类：

• 跨设备平台，如 PC（电脑）/ Mobile（手机）/ OTT（机顶盒）/ IoT（物联网设备）。不同的设备平台往往意味着不同的硬件能力、传感器、屏幕尺寸与交互方式


• 跨操作系统，如 Android/iOS/HarmonyOS。不同的操作系统为应用开发通常提供了不同的编程语言、应用框架和 API


• 跨移动应用，如 微信/支付宝/手淘/抖音/快手等。由于移动平台 CS 架构 及 App 间天然的壁垒，不同 App 间相互隔离，并各自在其封闭体系内遵循一套自有标准进行各类资源的索引、定位及渲染。而同一业务投放至不同 App 端时，就需要分别适配这些不同的规则。


• 跨渲染容器，如 Webview/React Native/Flutter。前面三类场景催生了针对不同设备平台、不同操作系统、不同 App 间解决方案，因而移动领域的各种 Native 化渲染、自绘渲染与魔改 Webview 的方案也由此被设计出来，在尝试解决跨端问题的同时，也一定程度上提高了跨端的迁移门槛和方案选择难度。

而在当下，移动领域依然是绝对的主角，我们来看一下移动端的跨端技术都经历了哪些阶段。

移动跨端技术演进

随着移动互联网的蓬勃发展，端形态变的多样，除了传统的 Native、H5 之外，以动态化与小程序为代表的新兴模式百花齐放大行其道，世面上的框架/容器/工具也层出不穷，整个业态朝着碎片化方向发展。

对开发者来说，碎片化的直接影响，是带来了包括但不限于，刚才提到的设备平台、操作系统、渲染容器、语法标准等方面的各种不确定性，增加了大量的学习、开发与维护成本。

于是，应运而生的各类跨端技术，核心在于从不确定性中找寻确定性，以保障研发体验与产物一致性为前提，为各端适配到最优解，用最少成本达到最好效果，真正做到 "一次编写，到处运行"。

移动跨端大致经历了如下几个阶段：

• 
  

  H5 Wap 阶段：Web 天然跨平台，响应式布局是当时的一个主要手段，但由于早期网络环境原因，页面加载速度无法满足业务预期，加之设备传感器标准缺失、内存占用大、GPU 利用率低等问题，在移动设备量爆发伊始，难堪大任的论调一下子被推上风口浪尖，并在 12 年达到顶峰。

  
  


• 
  

  Hybrid 阶段：典型代表是 Cordova/ionic。功能上看，Hybrid 解决了历史两大痛点：

  
  
  
  
  • 1）性能，依靠容器能力，各类离线化、预装包、Prefetch 方案大幅减少加载耗时，配合编码优化在 3/4G 时代使 H5 的体验上了一个台阶；
  
  
  • 2）功能，通过 JSBridge 方式规避了与 Native 原生割裂带来的底层能力缺失。
  
  
  
  


• 
  

  框架+原生阶段：典型代表是 ReactNative/Weex。基于 JSC 或类似的引擎，在语法层与 React/Vue 结合，渲染层使用原生组件绘制，尝试在研发效率与性能体验间寻找更佳的平衡点，各类领域解决方案（受限 DSL + 魔改 web 标准 + Native 渲染能力）开始涌现，拉开了大前端融合渲染方案的序幕。

  
  


• 
  

  自绘渲染阶段：典型代表是 Flutter/Qt。这里的 “自绘” 更强调不使用系统原生控件或 Webview 的渲染管线，而是依赖 Skia、Cairo 等跨平台图形库，自底向上自建渲染引擎、研发框架及基础配套的方式，其跨 Android/iOS 的特性迅速点燃了客户端研发领域。

  
  


• 
  

  小程序阶段：典型代表是 微信/支付宝小程序。小程序是被创造出来的，其本质是各 APP 厂商出于商业考量构造了相对封闭的生态，在标准与能力上无论与 Web 还是厂商之间均存在差异，能力上是自定义 DSL & API + Hybrid + 同层渲染 + 商业管控的综合体。市面跨端方案策略均是锚定一种研发规约进行各形态编译时与运行时的差异抹平与适配。

  
  

回顾了以上跨端技术背景与演进历程，在这股浪潮里面，饿了么的跨端投放情况是什么样的？投了那些端？遇到了哪些问题？又是如何解决的？

饿了么跨端投放诉求、现状与策略

众所周知，饿了么是围绕 O2O 为用户提供线上到线下服务的公司，通过对时、空、人、货 的有机结合，来链接商家与消费者，相比于传统电商，时空人货本身具有区域属性，这意味着我们做的不是一个大卖场生意，更多的是需要围绕区域特性提供精细化的服务，这里面有一系列时空、体验、规模、成本的约束需要考虑与应对

而在这一系列约束背后，其实有一个各方共通的经营诉求：

• 对于商家来说：为了有更好的经营需要有更多曝光，与客户有更多的触达，以便带来成交


• 对于平台来说：为了能够让更多消费者享受我们的服务，除了深耕自己的超级APP（饿了么APP）外，还需要在人流量大的地方加大曝光、声量与服务能力来扩大我们的规模

这都导向一个目的：哪里流量多，我们就需要在哪里提供与消费者的连接能力。

那么问题来了，流量在哪里？现在的互联网，更多都是在做用户的时间与精力生意，背后拆解下来，其实有几个关键因素可以衡量：用户密度、用户活跃度、市场占有率与用户时间分配，细化来看，其中任意几个条件满足，都可以作为我们流量阵地的候选集。

饿了么经过多年耕耘，对外部关键渠道做了大量布局，业务阵地众多，从效果上看，渠道业务无论是用户流量规模还是订单规模均对大盘贡献度较高，且随着业务的持续精进与外部合作环境的持续改善，增量渠道也在不断的涌现中。

在这么多的业务阵地中，投放在各个端的应用的形态基于：

• 渠道的运行环境


• 渠道的流量特性


• 渠道的业务定位


• 渠道的管控规则

等的差异和限制，目前形成了 以小程序为主，H5为辅 的承接方式，而这些差异带来了大量的不确定性，主要体现在：

• 渠道环境的高度不确定性：对接了这么多渠道，每个端的运行环境存在巨大差异，拿小程序能力举例，即使是个别 APP 的小程序方案借鉴了微信的思路，由于其内部商业能力、产品设计思路、能力成熟度与完整度、研发配套（语法、框架、工具等）的不一致也会使研发体感有明显的不同，这对技术同学来说，带来的是渠道环境的高度不确定性；


• 业务诉求的高度不确定性：同时，我们所投放的 APP 都可划分到某些细分领域，用户特性与用户在该平台上的诉求不一，渠道定位也不一致，随着每个业务域的功能演进越来越多，多个渠道功能是否对齐、要不要对齐、有没有对齐、什么时候对齐成了一个非常现实和麻烦的事情，同时业务域之间可能还存在功能上的关联，这进一步提高了其复杂度，在没有一个好的机制与能力保障下，业务、产品、研发对每个渠道的同步策略、能力范围的感知会有较大偏差，甚至于一个需求的迭代，每个端什么时候能同步都变成了一个无法预期的事情，这对于业、产、研来说，带来的是业务诉求上的高度不确定性。

而我们要做的，就是在这两种不确定性中，找到技术能带来的确定性的事情。如何系统性的解决这些问题，则成为我们在保障渠道业务灵活性的基础上持续提升研发效率和体验的关键。

在差异应对上，业务研发最理想的方式是对底层的变化与不一致无感，安心应对业务诉求，基于这个点出发，我们的主要策略是：围绕 “研发体验一致性提升与复杂应用协作机制改进”来保障业务高效迭代。这需要一套强有力的、贴合业务特性的基础设施来支撑。首先想到的便是如何通过“推动框架统一”和“实现一码多端”，来为业务研发降本增效，然而理想很丰满，现实很骨感：

框架的升级通常情况下，大概率会带来业务重构，综合评估之后，作为外部渠道流量大头的小程序业务，则成为了我们优先要保障的业务，也基于此，为了尽可能降低对业务的影响和接入成本，我们明确了以小程序为第一视角来实现多端。

基于小程序跨端的行业现状和思考

在明确了方向之后，那么问题来了：业界有没有适合我们的开源的框架或解决方案呢？

业界有哪些面向于小程序的研发框架？

市面上，从小程序视角出发，具备类似能力的优秀多端框架有很多，有代表性的如 Taro、uni-app、Rax 等，大多以 React 或者 Vue 作为 DSL

那么这些框架能否解决我们所面临的问题？答案是：并不能。

为什么饿了么选择以小程序 DSL 为基础实现跨端？

综合 饿了么 的渠道业务背景需要考虑以下几点：

• 改造成本：以支付宝、微信、淘宝为代表的饿了么小程序运营多年，大部分存量业务是以支付宝或微信小程序 DSL 来编写，需关注已有业务逻辑（或组件库）的改造成本，而采纳业界框架基本上会直接引发业务的大量重构，这个改造成本是难以接受的。


• 性能体验：渠道业务是饿了么非常重要的流量阵地，重视程度与APP无差，在体验和性能上有极致的要求，所以我们期望在推动跨端的同时，尽可能减少运行时引入带来的性能损耗。


• 业务协同：由于每个渠道都基本相当于一个小型的饿了么APP，复杂度高，涉及到多业务域的协同，包括主线步调一致性考量、多业务线/应用类型集成、全链路功能无缝衔接等，在此之外还需给各业务线最大限度的自控与闭环能力，背后需要的是大型小程序业务的一体化研发支撑。

在做了较多的横向对比与权衡之后，上面的这些框架对于我们而言采纳成本过高，所以我们选择了另外一条相对艰辛但更为契合饿了么多端演进方向的路：以小程序原生 DSL 为基础建设跨端解决方案，最大限度保障各端产物代码贴合小程序原生语法，以此尽可能降低因同构带来的体验损耗和业务多端接入成本。

基于小程序 DSL 的跨端解决方案

确定以小程序 DSL 作为方向建设跨端解决方案之后，首先要解决的就是如果将已有的小程序快速适配到多端。这就需要对各个端的差异做细致的分析并给出解决方案。

如何解决小程序多端编译？

为了能够兼顾性能和研发体验，我们选择了 编译时（重）+运行时（轻） 的解决方案。

静态编译解决了那些问题？

静态编译转换主要用于处理 JS、WXS/SJS、WXML/AXML、WXSS/ACSS、JSON 等源码中约束强且不能动态修改的部分，如：

• 模块引用：JS/WXS/SJS/WXML/AXML/WXSS/ACSS/JSON 等源码中的模块引用替换和后缀名修改；


• 模版属性映射或语法兼容： AXML/WXML 中如 a:if → wx:if、 onTap → bind:tap、{{`${name}Props`}} →  {{name + 'Props'}} 等；


• 配置映射：如页面 { "titleBarColor": "#000000" } → { "navigationBarBackgroundColor: "#000000", "navigationBarTextStyle": "white" }

等，原理是通过将源码文件转换为 AST（抽象语法树），并通过操作 AST 的方式来实现将源码转换为目标平台的代码。

但静态编译只能解决一部分的差异，还有一些差异需要通过运行时来抹平。

运行时补偿解决了那些问题？

运行时补偿主要用于处理静态编译无法处理或者处理成本较高的一些运行时动态内容，如：

• JSAPI：实际业务使用上，不管是 JSAPI 的名字还是 JSAPI 的入参都会存在动态赋值的情况，导致了在 JSAPI 的真实调用上，很难通过 AST 去解析出实际传参；


• 自定义组件 - Props 属性：比如，支付宝属性使用 props 声明，而微信属性使用 properties 声明，配置方式不同且使用时分别使用 this.props.x 及 this.properties.x 的方式获取，同时可能存在动态取值的情况；


• 自定义组件 - 生命周期：支付宝小程序中的 didUpdate 生命周期，在触发了 props 和 data 更新后都会进入 didUpdate 这个生命周期，且能够在 didUpdate 中访问到prevProps / prevData，而在微信小程序中静态转义出这个生命周期就意味着你需要去动态分析出didUpdate里面要用到的所有属性，然后去动态生成出这些属性的监听函数。这显然可靠程度是极其低的；

等等，类似的场景有很多，这里不再一一列举。

通过静态编译 + 运行时补偿的方式，我们便可以让现有的微信或支付宝小程序快速的迁移到其他小程序平台。

如何解决小程序转 Web？

伴随外卖小程序上线多年之后，各个大的渠道（支付宝、手淘、微信等）已切流为小程序承载，但是还有很多细分渠道或非小程序环境渠道，比如：各个银行金融渠道，客户端的极小包等，还需要依赖 H5 的形态快速投放，但当前饿了么的业务越来越复杂，相关渠道的投入资源有限，历史包袱重、迭代成本大等原因，产品功能和服务能力远远落后于小程序和饿了么App。而业务急需一个可以将小程序的功能快速复制到 h5 端的技术方案，以较低的研发和维护成本，满足业务多渠道能力对齐上线的诉求。

基于这个背景，我们自然而然的可以想到，即然小程序可以转其他小程序，那么是否也可以直接将小程序直接转换为 Web，从而最大程度上提升人效和功能对齐效率。

具体是怎么实现的？主要手段还是通过编译时 + 运行时的有机结合：

Web 转端编译原理

编译部分和小程序转小程序的主要区别和难点是：需要将 JS、WXS/SJS、WXML/AXML 等文件统一转换并合并为 JS 文件并将 WXML/AXML 文件转换为 JSX 语法，将样式文件统一转换为 CSS 文件，并将小程序的页面和组件都转换为 React 组件。

运行时原理

转 Web 的运行时相较于转换为其他小程序会重很多，为了兼顾性能和体验，运行时的核心在于提供与小程序对等的高效运行环境，这里面包含四个主要模块：

• 框架：提供了小程序在 Web 中的基础运行时功能，比如：Page 、Component 、App 等全局函数，并且提供完整的生命周期实现，事件的注册、分发等


• 组件：提供小程序公共组件的支持，比如 view、button、scroll-view 等小程序原生提供的组件


• API：​提供了类似小程序中 wx 或者 my 的 一系列 api 的实现


• 路由：提供了页面路由支持和 getCurrentPages 等方法支持

基于这四个模块，配合编译时的自动注入和代码转换，以及路由映射等，我们就可以把一个小程序转换为一个 Web 的 SPA（单页） 或者 MPA（多页） 应用，也成功的解决了业务的研发效率问题，目前 饿了么的新 M 站就是基于这套方案在运行。

如何解决多端多形态问题？

解决了各端的编译转换问题，是不是就万事大吉，业务接下来只要按部就班的基于这套能力实现一码多端就可以了？

然而并不是，随着饿了么的业务场景和范围快速拓展，诞生了一些新的诉求，比如：

• 支付宝的独立小程序作为分包接入微信小程序


• 淘宝 / 支付宝的小程序插件作为分包接入某个现有的微信小程序


• 支付宝的独立小程序作为插件接入淘宝小程序插件


• 支付宝小程序插件作为分包接入微信或抖音小程序

等等，大家如果仔细观察这些诉求，就会发现一个共同的点：就是小程序的形态不一样。

虽然我们已经具备了多端的能力，但是形态的差异没有解决掉，而之前相关业务的做法是，尽可能将通用功能沉淀到组件库，并按照多端的方式分端输出产物，然而由于相同业务在不同小程序端形态差异性的问题，业务上难以自行规避，而重构的成本又比较高，所以有一部分业务选择了直接按照不同的端不同的形态（如微信、支付宝、淘宝、抖音）各自维护一套代码，但这样做不仅功能同步迭代周期被拉长，而且 BUG 较多，维护困难，研发过程也是异常痛苦。

小程序形态差异有哪些？

形态差异是指 小程序、小程序分包、小程序插件 三种不同形态的运行方式差异以及转换为其他形态之后产生的差异，具体如下：

• 
  

  getApp 差异

  
  
  
  
  • 小程序： 可通过 getApp() 来获取全局 App 实例及实例上挂载的属性或方法
  
  
  • 小程序插件： 无法调用 getApp()
  
  
  • 小程序分包： 可通过 getApp() 来获取全局 App 实例及实例上挂载的属性或方法；但当通过小程序转换为分包后，分包自身原本调用的 getApp 将失效，并被替换为宿主小程序的 getApp
  
  
  
  


• 
  

  App 应用生命周期 差异

  
  
  
  
  • 小程序： 应用会执行 onLaunch、onShow、onHide 等生命周期
  
  
  • 小程序插件： 无应用生命周期
  
  
  • 小程序分包： 无应用生命周期
  
  
  
  


• 
  

  全局样式（如：app.wxss 或 app.acss）差异

  
  
  
  
  • 小程序： 可通过全局样式来声明全局样式
  
  
  • 小程序插件： 无全局样式
  
  
  • 小程序分包： 无全局样式
  
  
  
  


• 
  

  NPM 使用限制

  
  
  
  
  • 小程序： 各个小程序平台支持和限制情况不一
  
  
  • 小程序插件： 各个小程序平台支持和限制情况不一
  
  
  • 小程序分包： 各个小程序平台支持和限制情况不一
  
  
  
  


• 
  

  接口调用限制

  
  
  
  
  • 小程序： 无限制
  
  
  • 小程序插件： 存在大量的接口调用限制，如 开发支付宝小程序插件 或 开发微信小程序插件
  
  
  • 小程序分包： 无限制
  
  
  
  


• 
  

  路由差异

  
  
  
  
  • 小程序： 转换到其他形态后自身路由会发生变化
  
  
  • 小程序插件： 转换到其他形态后自身路由会发生变化，跳转插件页面需要包含 plugin:// 或 dynamic-plugin:// 等前缀，小程序或分包则不需要
  
  
  • 小程序分包： 转换到其他形态后自身路由会发生变化
  
  
  
  


• 
  

  getCurrentPages 差异

  
  
  
  
  • 小程序： 无限制
  
  
  • 小程序插件： 无法通过 getCurrentPages 获取到小程序的页面堆栈
  
  
  • 小程序分包： 无限制
  
  
  
  


• 
  

  页面或组件样式差异

  
  
  
  
  • 小程序： 无限制
  
  
  • 小程序插件： 基本选择器只支持 ID 与 class 选择器，不支持标签、属性、通配符选择器
  
  
  • 小程序分包： 无限制
  
  
  
  

等等，相关形态差异可结合各个小程序平台查看，这里仅罗列常见的部分。

如何解决这些差异？

这里举几个例子：

通过在编译过程中，自动向产物中注入对 App 和 getApp 的运行时模拟实现，这样就可以解决分包和插件下方法缺失或者是冲突引起的报错问题。

方法也是类似，可以在编译的过程中检测全局样式是否存在，如果存在，则将对应的全局样式引用自动注入到每一个页面和组件中来解决全局样式失效的问题。

而针对各个小程序平台的 NPM 使用规则不同的问题，可以通过依赖解析、动态分组、组件提取打包、引用替换等方式，将 NPM 抽取到特定的地方，并将对应的组件和页面中的引用进行替换，来解决 NPM 的支持问题，这样业务就可以基本无脑使用各类 NPM 而不用关心平台差异。

以此类推，将业务难以自行适配的差异，逐一解决之后，剩余的一些功能差异，则由业务基于条件编译的方式来自行适配，这样便可以大大的降低业务形态转换成本，同时也形成了我们面向多端场景下的形态转换方案。

那么到这里，多端转换的问题才算是基本解决了。

如何治理 “复杂小程序”？

如果说上面讲的内容都是聚焦在如何通过编译的方式来解决多端同构以及形态问题的话，那么接下来要解决的就是针对“复杂小程序”的应用架构与研发协作的问题了。

首先介绍下我们所定义的 “复杂小程序”，即具备跨业务领域的、长周期的、多团队协同的、呈现主链路+多分支业务模式的应用，其之所以“复杂”，主要体现在应用形态多样、诉求多样、关联业务面广等特性上。

对于饿了么来说，每个渠道阵地均相当于一个小型饿了么APP，除了在研发上提供便利外，还需一套可靠的应用架构来保证其有序演进。

同时，由于渠道之间定位不同，各域的业务、产品及研发对各渠道重视程度与投入比重均有差异，间接导致渠道间相同业务能力的参差不齐，且不同渠道功能缺失的情况持续出现。

我们以饿了么微信小程序为例：

面临的问题有哪些？

• 工程复杂导致研发效率低：大量的团队在一个单体小程序应用上研发，带来的直接问题就是小程序巨大化带来的研发体验差和编译效率低，且业务相互依赖，单一模块构建失败会引发整个项目的失败，比如饿了么微信小程序单次编译的时间超过了半个小时，且体积逼近 20m 上限


• 研发流程不规范导致稳定性差：同时由于不同的业务团队迭代周期不一致，而每次发版都需要所有业务的代码一起发，哪怕是某个业务分包或者插件没有更新，但是对应的底层依赖库发生了变更，也极有可能引入线上 BUG，导致测试回归的成本居高不下，发版质量难以保障

解决方案：线下线上结合的集成研发模式

针对上面两个“复杂小程序”所面临的核心问题，我们针对性的通过 「线下集成研发」和「线上研发协作」来解决。

线下集成研发

重点考虑的是提供什么样的集成研发能力，允许以业务单元维度将多个独立的构建（宿主、小程序、插件、分包等）组成一个可用的小程序，消除业务之间强依赖关系，从而达成业务可独立开发、调试和部署的目的，方面统一业务协作流程、降低多端同构成本，关键策略：

• 提供统一的集成研发方式和流程


• 提供标准、可复用的集成产物规范


• 为复杂小程序提供解耦工具和集成方法


• 标准化小程序宿主、小程序插件、小程序分包、小程序模块之间的通信及能力注入方式

将小程序宿主和各个业务模块（分包、小程序、插件）通过形态转换、拉包、编译、构建、合并等一系列处理后，合并为一个完整小程序，且根据不同的场景可以支持：

• 主子分包研发模式：基于不同业务对小程序中的分包进行拆分，以达到各个业务相互解耦，独立迭代的目的；


• SDK 研发模式：将通用的页面或组件封装置某个 NPM 包中作为提供特定功能的 SDK 交由业务使用；


• 小程序插件研发模式：集成研发也可以用支持标准的小程序插件研发。

这样我们就可以解决线下研发的问题。

线上研发协作

前面介绍的“线下集成研发”为业务单元提供了无阻塞的开发与调试能力，但对于饿了么业务整体演进来说，重视的是每个版本功能的可用与可控，这里面除了将集成的范围扩展到所有业务域的之外，还需要标准化的流程约束：

具体方式上，在机制层面提供了业务类型定义的能力，开发者可将工程做对应标记（主包、分包、插件、独立小程序），在流程层面定义了开发、集成与发布三个阶段，这和 APP 的研发流程有些类似：

• 开发：各业务应用自行研发并结合平台部署测试，开发测试通过，等待窗口期开启进入集成测试；


• 集成：管理员设置集成窗口期，在窗口期，允许业务多次集成研发，确认最终要进集成的稳定版本，期间主包管理员可多次部署体验版用于集成测试。窗口期结束后，不允许随意变更；


• 发布：集成测试通过，各业务进行代码 CR 并进入发布阶段，等候主包提审通过发布上线，最终由管理员完成本次迭代发布，发布完成后，符合标准的主分包产物会被保存下来，后续的迭代中，如果某个分包未发生变更，则会直接复用产物，极大的降低了业务的发布风险，并提升了整体的构建效率。

再进一步，多端业务的最佳实践

通过线下集成+线上协作的双重能力加持，结合已有的多端编译能力，在成功的支撑了饿了么多端渠道业务的稳定高效研发的同时，我们也在思考，面向于未来的多端研发模式应该是个什么样子？

下图是我们期望同时也是饿了么目前多端应用架构正在演进中的样子：

从图上可以看出，我们将应用架构划分为三层（从下往上看）：

• 
  

  基础服务与研发规范：最底部的是基础服务与研发规范，由 多端研发框架、多端研发平台和多端研发规范，来提供统一的研发支撑，保障业务研发的基础能力、体验和效率，并负责将相关的业务统一打包、封装、集成，并部署和投放到不同的渠道；

  
  


• 
  

  宿主应用框架：第二层是宿主应用框架（Framework），也可以认为是多端统一解决方案，承接了面向于业务研发并适配了多端差异的基础 API（如 登录、定位、请求、路由、实验、风控、埋点、容器等）、基础组件和最佳实践，通过分渠道的配置化运行、标准化的接入手段和中心化的能力管理，来保障整体框架的轻量化、标准化与持续迭代和升级；

  
  


• 
  

  渠道应用主体：最上层是各个业务的应用实体，有一个壳工程 + N个业务工程组成，壳工程承接各个渠道定制化的一些能力，而并将下层应用框架的能力暴露给上层的各个业务，各个业务只需要关心两件事即可：

  
  
  
  
  • 多端形态：以什么样的形态接入到对应的渠道（即壳工程中）？
  
  
  • 业务功能：不同的渠道需要展示那些功能？
  
  
  
  

基于这种分层协作模式，可以最大程度上消除业务对多端差异的感知，可以将重心放在如何更好的为用户提供服务上。

以上内容为饿了么基于小程序 DSL 的跨端实践和解决方案，下面我们来看一下具体取得的成果。

跨端成果

饿了么各渠道业务效果展示

业务一码多端研发提效数据

• 研发提效：采用一码多端和集成研发模式的业务平均提效 70%，同构的端越多提效越多


• 多端占比：饿了么内部 85%+ 的多端业务在基于这套方案实现多渠道业务研发和投放


• 业务覆盖：涵盖了饿了么全域的各个业务板块

能力沉淀 — 饿了么自研 MorJS 多端研发框架

MorJS 开源

我们将饿了么在跨端多渠道上的多年沉淀和解决方案，融合为 MorJS 多端研发框架，并通过 Github 开源的方式向社区开放。

GitHub 仓库地址：github.com/eleme/morjs

下图为 MorJS 的完整架构图：

MorJS 框架目前支持 ：

• 2 种 DSL：微信小程序 DSL 或 支付宝小程序 DSL


• 4 种编译形态：小程序、小程序插件、小程序分包、小程序多端组件


• 9 个目标平台：微信、支付宝、百度、字节、快手、钉钉、手淘、QQ、Web

并支撑了饿了么 C 端大多数业务在各个渠道上的研发和投放。

MorJS 为饿了么解决了大量业务在多端研发上的差异问题，让小程序开发的重心回到产品业务本身，减少使用者对多端差异兼容的投入。通过 MorJS 的开源，我们期望能把其中的实现细节、架构设计和技术思考呈现给大家，为更多有类似多端同构需求的企业和开发者服务。同时，我们也希望能够借此吸引到更多志趣相投的小伙伴参与共建，一起加速小程序一码多端能力的发展。欢迎广大小程序开发者们与我们交流。

MorJS 特性介绍

为了能够帮助社区的用户可以快速上手，我们在易用性、标准化和灵活性方面做了大量的准备：

• ⭐️ 易用性：
  
  
  
  • 💎 DSL 支持：可使用微信小程序 DSL 或 支付宝小程序 DSL 编写小程序，无额外使用成本；
  
  
  • 🌴 多端支持：支持将一套小程序转换为各类小程序平台及 Web 应用, 节省双倍人力；
  
  
  • 🚀 快速接入：仅需引入两个包，增加一个配置文件，即可简单快速接入到现有小程序项目；
  
  
  
  


• 🌟 标准化：
  
  
  
  • 📦 开箱即用：内置了脚手架、构建、分析、多端编译等完整研发能力，仅需一个依赖即可上手开发；
  
  
  • 🌈 表现一致：通过编译时+运行时抹平多端差异性，让不同平台的小程序获得一致的用户体验；
  
  
  • 🖇 形态转换：支持同一个项目的不同的形态，允许小程序、分包、插件不同形态之间的相互转换；
  
  
  
  


• ✨ 灵活性：
  
  
  
  • 🎉 方便扩展：MorJS 将完备的生命周期和内部功能插件化，使用插件(集)以满足功能和垂直域的分层需求；
  
  
  • 📚 类型支持：除小程序标准文件类型外，还支持 ts、less/scss、jsonc/json5 等多种文件类型；
  
  
  • 🧰 按需适配：可根据需求选择性接入适配能力，小项目仅需编译功能，中等项目可结合编译和页面注入能力，大型项目推荐使用复杂小程序集成能力；
  
  
  
  

同时也提供了丰富的文档：mor.eleme.io/ 共大家查阅。

部分使用案例及社区服务

以下为部分基于 MorJS 的案例：

用户原声

MorJS 上线的这几个月里面，我们收到了一些社区用户的正向反馈，也收到了一些诉求和问题，其中用户最担心的问题是：MorJS 是不是 KPI 项目，是否会长期维护？

这里借用一下我在 Github 项目的讨论区（Discussions）的回复：

如果大家对 MorJS 感兴趣，期望有更多了解或者在使用 MorJS 中有遇到任何问题，欢迎加入 MorJS 社区服务钉钉群（群号：29445021084）反馈、交流和学习，也可以🔗 点击链接加入钉钉群。

展望未来

未来，在现有的 MorJS 的能力基础上，我们会进一步完善已有的多端能力，提升多端转换可用度，完善对各类社区组件库的兼容，并持续扩展编译目标平台的支持（如 鸿蒙、快应用等），在持续为饿了么自身业务和社区用户提供高质量服务的同时，期望有朝一日 MorJS 可以成为业界小程序多端

背景

一天，本该快乐编码flutter的我，突然被集团法务钉了，说在合规扫描排查中发现某xxxApp存在在App静默状态下调用某敏感权限获取用户信息，不合规。通过调用栈排查发现是某第三方推送sdk在静默状态下心跳调用的，本着能动口不动脑的准则，我联系了上了第三方的技术，询问是否有静默方面的api，结果一番舌战后，对方告诉我他们隐私政策里有添加说明，之后也没有想要改动的打算，但是集团那边说在隐私里说明也不行。

综上，那只能自己动手。

解决的方法：是通过hook系统权限，添加某个业务逻辑点拦截并处理。

涉及到的知识点：java反射、动态代理、一点点耐心。

本文涉及到的敏感权限：

//wifi

android.net.wifi.WifiManager.getScanResults()

android.net.wifi.WifiManager.getConnectionInfo()

//蓝牙

android.bluetooth.le.BluetoothLeScanner.startScan()

//定位

android.location.LocationManager.getLastKnownLocation()

开始

wifi篇

1.首先寻找切入点，以方法WifiManager.getScanResults()为例查看源码

public List<ScanResult> getScanResults() {

    try {

        return mService.getScanResults(mContext.getOpPackageName(),

                mContext.getAttributionTag());

    } catch (RemoteException e) {

        throw e.rethrowFromSystemServer();

    }

}

发现目标方法是由mService对象调用，它的定义

@UnsupportedAppUsage

IWifiManager mService;

查看IWifiManager

interface IWifiManager{

 ...



List<ScanResult> getScanResults(String callingPackage, String callingFeatureId);



WifiInfo getConnectionInfo(String callingPackage, String callingFeatureId);



 ...

}

可以看到IWifiManager是一个接口类，包含所需方法，可以当成一个切入点。

若以IWifiManager为切入点，进行hook

方法一

private static void hookWifi(Context context) {

    try {

        //反射获取相关类、字段对象

        Class<?> iWifiManagerClass = HookUtil.getClass("android.net.wifi.IWifiManager");

        Field serviceField = HookUtil.getField("android.net.wifi.WifiManager", "mService");

        

        WifiManager wifiManager = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);

        //获取原始mService对象

        Object realIwm = serviceField.get(wifiManager);



        //创建IWifiManager代理

        Object proxy = Proxy.newProxyInstance(iWifiManagerClass.getClassLoader(),

                new Class[]{iWifiManagerClass}, new WifiManagerProxy(realIwm));



        //设置新代理

        serviceField.set(wifiManager, proxy);

    } catch (Exception e) {

        e.printStackTrace();

    }

}

其中新代理类实现InvocationHandler

public class WifiManagerProxy implements InvocationHandler {



    private final Object mOriginalTarget;



    public WifiManagerProxy(Object mOriginalTarget) {

        this.mOriginalTarget = mOriginalTarget;

    }



    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        String methodName = method.getName();

        if (("getScanResults".equals(methodName) || "getConnectionInfo".equals(methodName))){

            //todo something

            return null;

        }

        return method.invoke(mOriginalTarget,args);

    }

}

2.考虑context问题：

获取原始wifiManager需要用到context上下文，不同context获取到的wifiManager不同。若统一使用application上下文可以基本覆盖所需，但是可能会出现遗漏（比如某处使用的是activity#context）。为了保证hook开关唯一，尝试再往上查找新的切入点。

查看获取wifiManager方法，由context调用.getSystemService(）

WifiManager wifiManager = (WifiManager) context.getSystemService(Context.WIFI_SERVICE);

继续查看context的实现contextImpl中

@Override

public Object getSystemService(String name) {

    ...

    return SystemServiceRegistry.getSystemService(this, name);

}

查看SystemServiceRegistry.getSystemService静态方法

public static Object getSystemService(ContextImpl ctx, String name) {

    if (name == null) {

        return null;

    }

    final ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);

    if (fetcher == null) {

        ...

        return null;

    }



    final Object ret = fetcher.getService(ctx);

    if (sEnableServiceNotFoundWtf && ret == null) {

        ...

        return null;

    }

    return ret;

}

服务由SYSTEM_SERVICE_FETCHERS获取，它是一个静态的HashMap，它的put方法在registerService中

private static <T> void registerService(@NonNull String serviceName,

        @NonNull Class<T> serviceClass, @NonNull ServiceFetcher<T> serviceFetcher) {

   ...

   SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);

   ...

}



static{

...

//Android 11及以上

WifiFrameworkInitializer.registerServiceWrappers()

...

}



...



@SystemApi

public static <TServiceClass> void registerContextAwareService(

        @NonNull String serviceName, @NonNull Class<TServiceClass> serviceWrapperClass,

        @NonNull ContextAwareServiceProducerWithoutBinder<TServiceClass> serviceProducer) {

    ...

    registerService(serviceName, serviceWrapperClass,

        new CachedServiceFetcher<TServiceClass>() {

            @Override

            public TServiceClass createService(ContextImpl ctx)

                    throws ServiceNotFoundException {

                return serviceProducer.createService(

                        ctx.getOuterContext(),

                        ServiceManager.getServiceOrThrow(serviceName));

            }});



}

public static void registerServiceWrappers() {

...

SystemServiceRegistry.registerContextAwareService(

                  Context.WIFI_SERVICE,

                  WifiManager.class,

                  (context, serviceBinder) -> {

                      IWifiManager service = IWifiManager.Stub.asInterface(serviceBinder);

                      return new WifiManager(context, service, getInstanceLooper());

                  }

          );

}

SYSTEM_SERVICE_FETCHERS静态代码块中通过.registerServiceWrappers()注册WIFI_SERVICE服务。

在registerService中new了一个CachedServiceFetcher，它返回一个serviceProducer.createService(...)

TServiceClass createService(@NonNull Context context, @NonNull IBinder serviceBinder);

其中第二个参数是一个IBinder对象，它的创建

ServiceManager.getServiceOrThrow(serviceName)

继续

public static IBinder getServiceOrThrow(String name) throws ServiceNotFoundException {

          final IBinder binder = getService(name);

          if (binder != null) {

              return binder;

          } else {

              throw new ServiceNotFoundException(name);

          }

      }

...

@UnsupportedAppUsage

public static IBinder getService(String name) {

          try {

              IBinder service = sCache.get(name);

              if (service != null) {

                  return service;

              } else {

                  return Binder.allowBlocking(rawGetService(name));

              }

          } catch (RemoteException e) {

              Log.e(TAG, "error in getService", e);

          }

          return null;

      }

最终在getService中IBinder缓存在sCache中，它是一个静态变量

@UnsupportedAppUsage

private static Map<String, IBinder> sCache = new ArrayMap<String, IBinder>();

综上，如果可以创建新的IBinder，再替换掉sCache中的原始值就可以实现所需。

若以sCache为一个切入点

方法二

private static void hookWifi2() {

    try {

        Method getServiceMethod = HookUtil.getMethod("android.os.ServiceManager", "getService", String.class);

        Object iBinderObject = getServiceMethod.invoke(null, Context.WIFI_SERVICE);



        Field sCacheFiled = HookUtil.getField("android.os.ServiceManager", "sCache");

        Object sCacheValue = sCacheFiled.get(null);

        

        //生成代理IBinder，并替换原始值

        if (iBinderObject != null && sCacheValue != null) {

            IBinder iBinder = (IBinder) iBinderObject;

            Map<String, IBinder> sCacheMap = (Map<String, IBinder>) sCacheValue;

            Object proxy = Proxy.newProxyInstance(iBinder.getClass().getClassLoader(), new Class[]{IBinder.class}, new WifiBinderProxy(iBinder));

            sCacheMap.put(Context.WIFI_SERVICE, (IBinder) proxy);

        }

    } catch (Exception e) {

        e.printStackTrace();

    }

}

public class WifiBinderProxy implements InvocationHandler {



    private final IBinder originalTarget;



    public WifiBinderProxy(IBinder originalTarget) {

        this.originalTarget = originalTarget;

    }



    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        if ("queryLocalInterface".equals(method.getName())) {

            Object hook = hookQueryLocalInterface();

            if (hook != null){

                return hook;

            }

        }

        return method.invoke(originalTarget, args);

    }



    private Object hookQueryLocalInterface(){

        try {

            //获取原始IWifiManager对象

            Method asInterfaceMethod = HookUtil.getMethod("android.net.wifi.IWifiManager$Stub", "asInterface", IBinder.class);

            Object iwifiManagerObject = asInterfaceMethod.invoke(null, originalTarget);



            //生成新IWifiManager代理

            Class<?> iwifiManagerClass = HookUtil.getClass("android.net.wifi.IWifiManager");

            return Proxy.newProxyInstance(originalTarget.getClass().getClassLoader(),

                    new Class[]{IBinder.class, IInterface.class, iwifiManagerClass},

                    new WifiManagerProxy(iLocationManagerObject));

        }catch (Exception e){

            e.printStackTrace();

        }

        return null;

    }

}

至此完成无需上下文的全局拦截。

蓝牙篇

以BluetoothLeScanner.startScan()为例查找切入点，以下省略非必需源码粘贴

private int startScan(List<ScanFilter> filters, ScanSettings settings,

        final WorkSource workSource, final ScanCallback callback,

        final PendingIntent callbackIntent,

        List<List<ResultStorageDescriptor>> resultStorages) {

        ...

        IBluetoothGatt gatt;

        try {

            gatt = mBluetoothManager.getBluetoothGatt();

        } catch (RemoteException e) {

            gatt = null;

        }

...

        

private final IBluetoothManager mBluetoothManager;



...

public BluetoothLeScanner(BluetoothAdapter bluetoothAdapter) {

    mBluetoothAdapter = Objects.requireNonNull(bluetoothAdapter);

    mBluetoothManager = mBluetoothAdapter.getBluetoothManager();

    ...

}

向上查找IBluetoothManager,它在BluetoothAdapter中；向下代理getBluetoothGatt方法处理IBluetoothGatt

查看BluetoothAdapter的创建

public static BluetoothAdapter createAdapter(AttributionSource attributionSource) {

    IBinder binder = ServiceManager.getService(BLUETOOTH_MANAGER_SERVICE);

    if (binder != null) {

        return new BluetoothAdapter(IBluetoothManager.Stub.asInterface(binder),

                attributionSource);

    } else {

        Log.e(TAG, "Bluetooth binder is null");

        return null;

    }

}

ok，他也包含由ServiceManager中获取得到IBinder，然后进行后续操作。

若以IBluetoothManager为切入点

private static void hookBluetooth() {

    try {

        //反射ServiceManager中的getService(BLUETOOTH_MANAGER_SERVICE = 'bluetooth_manager')方法，获取原始IBinder

        Method getServiceMethod = HookUtil.getMethod("android.os.ServiceManager", "getService", String.class);

        Object iBinderObject = getServiceMethod.invoke(null, "bluetooth_manager");



        //获取ServiceManager对象sCache

        Field sCacheFiled = HookUtil.getField("android.os.ServiceManager", "sCache");

        Object sCacheValue = sCacheFiled.get(null);



        //动态代理生成代理iBinder插入sCache

        if (iBinderObject != null && sCacheValue != null) {

            IBinder iBinder = (IBinder) iBinderObject;

            Map<String, IBinder> sCacheMap = (Map<String, IBinder>) sCacheValue;

            Object proxy = Proxy.newProxyInstance(iBinder.getClass().getClassLoader(), new Class[]{IBinder.class}, new BluetoothBinderProxy(iBinder));

            sCacheMap.put("bluetooth_manager", (IBinder) proxy);

        }

    } catch (Exception e) {

        e.printStackTrace();

    }

}

代理IBluetoothManager

public class BluetoothBinderProxy implements InvocationHandler {



    private final IBinder mOriginalTarget;



    public BluetoothBinderProxy(IBinder originalTarget) {

        this.mOriginalTarget = originalTarget;

    }



    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        if ("queryLocalInterface".equals(method.getName())) {

            //拦截

            Object hook = hookQueryLocalInterface();

            if (hook != null){

                return hook;

            }

        }

        //不拦截

        return method.invoke(mOriginalTarget, args);

    }



    private Object hookQueryLocalInterface(){

        try {

            //获取原始IBluetoothManager对象

            Method asInterfaceMethod = HookUtil.getMethod("android.bluetooth.IBluetoothManager$Stub", "asInterface", IBinder.class);

            Object iBluetoothManagerObject = asInterfaceMethod.invoke(null, mOriginalTarget);



            //生成代理IBluetoothManager

            Class<?> iBluetoothManagerClass = HookUtil.getClass("android.bluetooth.IBluetoothManager");

            return Proxy.newProxyInstance(mOriginalTarget.getClass().getClassLoader(),

                    new Class[]{IBinder.class, IInterface.class, iBluetoothManagerClass},

                    new BluetoothManagerProxy(iBluetoothManagerObject));

        }catch (Exception e){

            e.printStackTrace();

        }

        return null;

    }

}

代理IBluetoothGatt

public class BluetoothManagerProxy implements InvocationHandler {



    private final Object mOriginalTarget;



    public BluetoothManagerProxy(Object mOriginalTarget) {

        this.mOriginalTarget = mOriginalTarget;

    }



    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        if ("getBluetoothGatt".equals(method.getName())) {

            Object object = method.invoke(mOriginalTarget,args);

            Object hook = hookGetBluetoothGatt(object);

            if (hook != null){

                return hook;

            }

        }

        return method.invoke(mOriginalTarget, args);

    }



    private Object hookGetBluetoothGatt(Object object) {

        try {

            Class<?> iBluetoothGattClass = HookUtil.getClass("android.bluetooth.IBluetoothGatt");

            return Proxy.newProxyInstance(mOriginalTarget.getClass().getClassLoader(),

                    new Class[]{IBinder.class, IInterface.class, iBluetoothGattClass},

                    new BluetoothGattProxy(object));

        } catch (Exception e) {

            e.printStackTrace();

        }

        return null;

    }

}

处理业务逻辑

public class BluetoothGattProxy implements InvocationHandler {



    private final Object mOriginalTarget;



    public BluetoothGattProxy(Object mOriginalTarget) {

        this.mOriginalTarget = mOriginalTarget;

    }





    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        if ("startScan".equals(method.getName())){

            //todo something

            return null;

        }

        return method.invoke(mOriginalTarget,args);

    }

}

定位篇

以LocationManager.getLastKnownLocation()为例查找切入点，此处不粘贴源码，直接展示

private static void hookLocation() {

    try {

        Method getServiceMethod = HookUtil.getMethod("android.os.ServiceManager", "getService", String.class);

        Object iBinderObject = getServiceMethod.invoke(null, Context.LOCATION_SERVICE);



        Field sCacheFiled = HookUtil.getField("android.os.ServiceManager", "sCache");

        Object sCacheValue = sCacheFiled.get(null);



        //动态代理生成代理iBinder插入sCache

        if (iBinderObject != null && sCacheValue != null) {

            IBinder iBinder = (IBinder) iBinderObject;

            Map<String, IBinder> sCacheMap = (Map<String, IBinder>) sCacheValue;

            Object proxy = Proxy.newProxyInstance(iBinder.getClass().getClassLoader(), new Class[]{IBinder.class}, new LocationBinderProxy(iBinder));

            sCacheMap.put(Context.LOCATION_SERVICE, (IBinder) proxy);

        }

    } catch (Exception e) {

        e.printStackTrace();

    }

}

public class LocationBinderProxy implements InvocationHandler {



    private final IBinder originalTarget;



    public LocationBinderProxy(IBinder originalTarget) {

        this.originalTarget = originalTarget;

    }



    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        if ("queryLocalInterface".equals(method.getName())) {

            Object hook = hookQueryLocalInterface();

            if (hook != null){

                return hook;

            }

        }

        return method.invoke(originalTarget, args);

    }



    private Object hookQueryLocalInterface(){

        try {

            //获取原始ILocationManager对象

            Method asInterfaceMethod = HookUtil.getMethod("android.location.ILocationManager$Stub", "asInterface", IBinder.class);

            Object iLocationManagerObject = asInterfaceMethod.invoke(null, originalTarget);



            //生成代理ILocationManager

            Class<?> iLocationManagerClass = HookUtil.getClass("android.location.ILocationManager");

            return Proxy.newProxyInstance(originalTarget.getClass().getClassLoader(),

                    new Class[]{IBinder.class, IInterface.class, iLocationManagerClass},

                    new LocationManagerProxy(iLocationManagerObject));

        }catch (Exception e){

            e.printStackTrace();

        }

        return null;

    }

}

总结

作为Android进程间通信机制Binder的守护进程，本次所hook的权限都可追溯到ServiceManager，ServiceManager中的sCache缓存了权限相关的IBinder，以此为切入点可以进行统一处理，不需要引入context。

在此记录一下因隐私合规引发的hook处理流程，同时也想吐槽一下国内应用市场App上架审核是真滴难，每个市场的合规扫描标准都不一样。

附录

源码查看网站 aospxref.com/

路径：/frameworks/base/core/java/android/os/ServiceManager.j


前言

大家好，我是未央歌，一个默默无闻的移动开发搬砖者~

本文针对 Android 各种标识符做了统一收集，方便大家比对，以供选择适合大家的唯一标识符。

标识符

IMEI

• 从 Android 6.0 开始获取 IMEI 需要权限，并且从 Android 10+ 开始官方取消了获取 IMEI 的 API，无法获取到 IMEI 了

fun getIMEI(context: Context): String {

    val telephonyManager = context

        .getSystemService(TELEPHONY_SERVICE) as TelephonyManager

    return telephonyManager.deviceId

}

Android ID（SSAID）

• 无需任何权限


• 卸载安装不会改变，除非刷机或重置系统


• Android 8.0 之后签名不同的 APP 获取的 Android ID 是不一样的


• 部分设备由于制造商错误实现，导致多台设备会返回相同的 Android ID


• 可能为空

fun getAndroidID(context: Context): String {

    return Settings.System.getString(context.contentResolver,Settings.Secure.ANDROID_ID)

}

MAC 地址

• 需要申请权限，Android 12 之后 BluetoothAdapter.getDefaultAdapter().getAddress()需要动态申请 android.permission.BLUETOOTH_CONNECT 权限


• MAC 地址具有全局唯一性，无法由用户重置，在恢复出厂设置后也不会变化


• 搭载 Android 10+ 的设备会报告不是设备所有者应用的所有应用的随机化 MAC 地址


• 在 Android 6.0 到 Android 9 中，本地设备 MAC 地址（如 WLAN 和蓝牙）无法通过第三方 API 使用 ， 会返回 02:00:00:00:00:00，且需要 ACCESS_FINE_LOCATION 或 ACCESS_COARSE_LOCATION 权限

Widevine ID

• DRM 数字版权管理 ID ，访问此 ID 无需任何权限


• 对于搭载 Android 8.0 的设备，Widevine 客户端 ID 将为每个应用软件包名称和网络源（对于网络浏览器）返回一个不同的值


• 可能为空

fun getWidevineID(): String {

    try {

        val WIDEVINE_UUID = UUID(-0x121074568629b532L, -0x5c37d8232ae2de13L)

        val mediaDrm = MediaDrm(WIDEVINE_UUID)

        val widevineId = mediaDrm.getPropertyByteArray(MediaDrm.PROPERTY_DEVICE_UNIQUE_ID);

        val sb = StringBuilder();

        for (byte in widevineId) {

            sb.append(String.format("x", byte))

        }

        return sb.toString();

    } catch (e: Exception) {

    } catch (e: Error) {

    }

    return ""

}

AAID

• 无需任何权限


• Google 推出的广告 ID ，可由用户重置的标识符，适用于广告用例


• 系统需要自带 Google Play Services 才支持，且用户可以在系统设置中重置

重置后，在未获得用户明确许可的情况下，新的广告标识符不得与先前的广告标识符或由先前的广告标识符所衍生的数据相关联。

还要注意，Google Play 开发者内容政策要求广告 ID“不得与个人身份信息或任何永久性设备标识符（例如：SSAID、MAC 地址、IMEI 等）相关联。”

在支持多个用户（包括访客用户在内）的 Android 设备上，您的应用可能会在同一设备上获得不同的广告 ID。这些不同的 ID 对应于登录该设备的不同用户。

OAID

• 无需任何权限


• 国内移动安全联盟出台的“拯救”国内移动广告的广告跟踪标识符


• 基本上是国内知名厂商 Android 10+ 才支持，且用户可以在系统设置中重置

UUID

• 生成之后本地持久化保存


• 卸载后重新安装、清除应用缓存 会改变

如何选择

同个开发商需要追踪对比旗下应用各用户的行为

• 可以采用 Android ID（SSAID），并且不同应用需使用同一签名


• 如果获得的 Android ID（SSAID）为空，可以用 UUID 代替【 OAID / AAID 代替也可，但需要引入第三方库】


• 在 Android 8.0+ 中， Android ID（SSAID）提供了一个在由同一开发者签名密钥签名的应用之间通用的标识符

希望限制应用内的免费内容（如文章）

• 可以采用 UUID ，作用域是应用范围，用户要想规避内容限制就必须重新安装应用

用户群体主要是大陆

• 可以采用 OAID ，低版本配合采用 Android ID（SSAID）/ UUID


• 可以采用 Android ID（SSAID），空的时候配合采用 UUID 等

用户群体在海外

• 可以采用 AAID


• 可以采用 Android ID（SSAID），空的时候配合采用 UUID 等

业务背景

在前后端数据交互场景下，使用最多的一种方式是客户端发起 HTTP 请求，等待服务端处理完成后响应给客户端结果。

但在一些场景下，服务端对数据的处理需要较长的时间，比如提交一批数据，对这批数据进行数据分析，将最终分析结果返回给前端。

如果采用一次 HTTP 请求，用户会一直处于等待状态，再加上界面不会有进度交互，导致用户不知何时会处理完成；此外，一旦刷新页面或者其他意外情况，用户就无从感知处理结果。

面对这类场景，可以借助 「HTTP 轮询方式」 对交互体验进行优化，具体过程如下：

首先发起一次 HTTP 请求用于提交数据，之后启动轮询在一定间隔时间内查询分析结果，在这期间后台可将分析进度同步到前端来告知用户处理进度；此外即使刷新再次进入页面还可以通过「轮询」实时查询进度结果。

下面，我们来看看代码层面看如何实现这类场景。

JS 实现轮询的方式

在实现代码之前，我们需要先明确 JS 实现轮询的方式有哪些，哪种方式最适合使用。

1. setInterval

作为前端开发人员，提起轮询第一时间能想到的是计时器 setInterval，它会按照指定的时间间隔不间断的轮询执行处理函数。

let index = 1;



setInterval(() => {

  console.log('轮询执行: ', index ++);

}, 1000);

回过头来看我们的场景：要轮询的是 异步请求（HTTP），请求响应结果会受限制网络或者服务器处理速度，显然 setInterval 这种固定间隔轮询并不适合这个场景。

2. Promise + setTimeout sleep

setInterval 的不足之处在于 轮询间隔时间 在异步请求场景下无法保证两个请求之间的间隔固定。要解决这个问题，可以使用 sleep 睡眠函数来控制间隔时间。

JS 中没有提供 sleep 相关方法，但可以结合 Promise + setTimeout 来实现。

const sleep = () => {

  return new Promise(resolve => {

    setTimeout(resolve, 1000);

  });

}

sleep 仅控制了轮询间隔，而轮询的执行机制需要我们手动根据异步请求结果来实现，比如下面通过控制 while 循环的条件：

const start = async () => {

  let i = 0;

  while (i < 5) {

    await sleep();

    console.log(`第 ${++ i} 次执行`);

  }

}



start();

使用轮询的时候可以借助 async/await 同步的方式编写，提高代码阅读质量。

实现异步请求轮询

下面我们通过一个完整示例理解 轮询异步请求 的实现及使用注意事项。

首先我们定义两个变量：index 用于控制何时停止轮询，timer 则用于实现中断轮询。

let index = 1;

let timer = 0;

这里，我们定义 syncPromise 来模拟异步请求，可以看作是一次 HTTP 请求，当进行 5 次异步请求后，会返回 false 表示拿到数据分析结果，停止数据查询轮询：

const syncPromise = () => {

  return new Promise(resolve => {

    setTimeout(() => {

      console.log(`第 ${index} 次请求`);

      resolve(index < 5 ? true : false);

      index ++;

    }, 50);

  })

}

现在，我们实现 pollingPromise 作为 sleep 睡眠函数使用，去控制轮询的间隔时间，并在指定时间执行异步请求：

const pollingPromise = () => {

  return new Promise(resolve => {

    timer = setTimeout(async () => {

      const result = await syncPromise();

      resolve(result);

    }, 1000);

  });

}

最后，startPolling 作为开始轮询的入口，包含以下逻辑：

• 1）在轮询前会清除正在进行的轮询任务，避免出现多次轮询；


• 2）如果需要，在开始轮询时会立刻调用异步请求查询一次数据结果；


• 3）最后，通过 while 循环根据异步请求的结果，决定是否继续轮询；

const startPolling = async () => {

  // 清除进行中的轮询，重新开启计时轮询

  clearTimeout(timer); // !!! 注意：清除计时器后，会导致整个 async/await 链路中断，若计时器的位置下方还存在代码，将不会执行。

  index = 1;

  // 立刻执行一次异步请求

  let needPolling = await syncPromise();

  // 根据异步请求结果，判断是否需要开启计时轮询

  while (needPolling) {

    needPolling = await pollingPromise();

  }

  console.log('轮询请求处理完成！'); // 若异步请求被 clearTimeout(timer)，这里不会被执行打印输出。

}



const start = async () => {

  await startPolling();

  console.log('若异步请求被 clearTimeout(timer)，这里将不会被执行');

}

start();

不过，需要注意的是：一旦清除计时器后，会导致整个 async/await 链路中断，若计时器的位置下方还存在代码，将不会执行。。

假设当前执行了两次轮询被 clearTimeout(timer) 后，从 startPolling 到 start 整个 async/await 链路都会中断，且后面未执行的代码也不会被执行。

基于以上规则，异步轮询的处理逻辑尽量放在 syncPromise 异步请求核心函数中完成，避免在开启轮询

前言

1、人情世故

如果做得好就会说是情商高，做不好会说是世故，这是冯仑老师一段话，然后怎么做不世故呢，也很难评判。

借着这个聊聊人情世故，在我看来它也是做事规则的一部分，我们发展很长一段历史，从不同的立场、不同的利益分出了派别，又从血缘关系分出了宗族，这些都是为了利益最大化的一个产物。

反观博主本人，典型理工男，执着技术研究，所以这块一直是弱项，不太会讲话，但是我人缘一直比较好的。当然有利也有弊，弊端的话比较明显的，当一个人说话很厉害的时候，会给人自信，给人觉得靠谱，当一个人说话不咋样的时候，其实也有好处，就是藏锋，你不说出来个人想法大家是不知道你心里的小九九的，所以保全了你自身。（当一个人份量足的时候，说话会引发很大的影响，所以你可以发现如果一个人在公开场合大发演讲，要么是初出茅庐要么就是有靠山）

2、人生的发展需要平台

王立群老师：人生发展往往需要平台，秦国李斯这么一个故事，他发现仓鼠跟厕鼠待遇很不一样，同样是一个物种，但是一个光明正大的吃着粮食，一个过街老鼠人人喊打，所以他悟到了一个道理，人生好的发展需要借助平台的。

我们今天讲的人物：曹操，我们还是从几个学习角度去看，一个是做事的方法，另一个我们从他的事迹里面看出成事的借力的这么一回事。

曹操

出身

他祖父是一个大太监，伺候皇后还有皇上，古代有三股力量，两股都是因为比较亲近产生的，一个是外戚，另一个太监，还有一股力量是文官，这个是人数最多的。那么他祖父权利很大的，然后收了一个义子也就是曹操的父亲，然后他本身属于夏侯家族，所以他带的资源是曹家还有夏侯家非常有实力。

他并没有说直接躺平，而是想着有所作为，接下来我们再看看他的做事方面

做事手段

1、许劭风评

古代有个一个规则，靠着这些有能力、有品德的人来进行推荐人才，曹操想出来做事，他找到许劭，一开始是不肯的，因为前面讲过三股力量，文官是很鄙视太监的，后面曹操使了点手段最终让许劭给他做了风评，然后他听完大笑而去。

idea：从这件事看做什么事都是有个窍门，这个方式是别人建议曹操这么干，所以做事要恰到好处。另外里面提到曹操使了点手段，哈哈透出了一个狠，有点东西。

2、傍大腿

曹操曾经在袁绍下面干活，然后好几次都把自己的精锐干没了，袁绍作为盟主，慷慨的给予兵马才得以恢复元气。

idea：我们看曹操的出身，这么牛逼的背景，他也需要大腿的支持，更何况普普通通的我们。

3、挟天子以令诸侯

这个是非常著名的历史典故，也是因为这个跟袁绍闹掰了，当汉献帝去了洛阳的时候，他马上去迎接，然后用这个发号施令讨伐别人。

idea：曹操的眼光十分毒辣，他看出潜在的价值，不愧是曹老板。

4、善用人才

像官渡之战，像迎接汉献帝，都是底下这批谋士给的主意，曹操手下文官是人才济济的，另外这个老板是善于听从这些好的计谋，这是非常重要的。

官渡之战，袁绍没有听从谋士的重兵把守粮草，导致给了曹操抓住了机会，乌巢一把火烧光了粮草。

个人看法

a、平台是重要的，借力也是需要的

从曹操的发迹来看，他站在一个大平台上面，不像刘备四处投奔。人并不是说能力很强就能表现出来，需要有平台，有这么伯乐去发现你，然后有这么一股力量在你困难的时候拉你一把，这是重要的。

b、曹操做事狠

这里的狠，不是残暴，而是毒辣，眼光毒辣、做事方式到位，我们从善用人才，许劭风评，挟天子以令诸侯，这些做的都很到位。举个例子，比如说我们要煮开一壶水，需要火柴、木头、可能需要鼓风工具，这都是关键那些点。

这个我们前面也提到了，做事一定要有所研究，事情的关键点是什么，当然有这么一群得力助手也很重要，发现关键突破点。所以古代对英雄标准是：腹有良策，有大气概。

c、驾驭人

司马家起来是在曹操去世后几代的事情，可以说在曹操在的时候，这些有心机的人没有动作的，侧面看出曹操的厉害之处，懂人心。在资治通鉴里面也有一个例子，就是桓温，他也是古代一个权臣，后面几代就不行了压不住这批人。

学历史，学读懂人心

历史里面基本都是那个朝代的精英，他们的事迹，做事方法，当然我们看到很多东西，包括抱负、无奈、遗憾；我们学的不仅仅是做事方法，避开权谋的陷阱，还有就是学习读懂人心、人性。当我们谈到这个，大家第一印象就是坏的人性，其实它是一种自然的表现，就像饿了就要吃饭。

《百家讲坛》里面讲了这么一个故事，曹操的下邳之战生擒了吕布，原本曹操很爱惜人才的，后面刘备的一句话：吕布对以往老板不好，而曹操生性多疑，最终嘎了吕布。王立群老师：人们往往看重结果，以结果说话，而不是问你这么做的原因。

是啊，我们在故事背后，看到整件事情人心的博弈，刘备被人称为仁义之君，但是他在那会落进下石了，因为他之前跟吕布有些矛盾的，吕布把他从原来的根据地赶走了，当然他说的也是事实。所以我们除了学习历史，还需要去洞察人心，往往这

Koa是一个非常轻量化的Node.js web应用框架,其洋葱圈模型是它独特的设计理念和核心实现机制之一。本文将详细介绍Koa的洋葱圈模型背后的设计思想，以及它是如何实现的。

洋葱圈模型设计思想

Koa的洋葱圈模型主要是受函数式编程中的compose思想启发而来的。Compose函数可以将需要顺序执行的多个函数复合起来，后一个函数将前一个函数的执行结果作为参数。这种函数嵌套是一种函数式编程模式。

Koa借鉴了这个思想，其中的中间件(middleware)就相当于compose中的函数。请求到来时会经过一个中间件栈，每个中间件会顺序执行，并把执行结果传给下一个中间件。这就像洋葱一样，一层层剥开。

这样的洋葱圈模型设计有以下几点好处:

• 更好地封装和复用代码逻辑，每个中间件只需要关注自己的功能；


• 更清晰的程序逻辑，通过中间件的嵌套可以表明代码的执行顺序；


• 更好的错误处理，每个中间件可以选择捕获错误或将错误传递给外层；


• 更高的扩展性，可以很容易地在中间件栈中添加或删除中间件。

洋葱圈模型实现机制

Koa的洋葱圈模型主要是通过Generator函数和Koa Context对象来实现的。

Generator函数

Generator是ES6中新增的一种异步编程解决方案。简单来说，Generator函数可以像正常函数那样被调用，但其执行体可以暂停在某个位置，待到外部重新唤起它的时候再继续往后执行。这使其非常适合表示异步操作。

// koa中使用generator函数表示中间件执行链

function *logger(next){

  console.log('outer');

  yield next;

  console.log('inner');

}



function *main(){

  yield logger();

}



var gen = main();

gen.next(); // outer

gen.next(); // inner

Koa使用Generator函数来表示洋葱圈模型中的中间件执行链。外层不断调用next重新执行Generator函数体，Generator函数再按顺序yield内层中间件异步操作。这样就可以很优雅地表示中间件的异步串行执行过程。

Koa Context对象

Koa Context封装了请求上下文，作为所有中间件共享的对象，它保证了中间件之间可以通过Context对象传递信息。具体而言，Context对象在所有中间件间共享以下功能:

• ctx.request：请求对象


• ctx.response：响应对象


• ctx.state：推荐的命名空间，用于中间件间共享数据


• ctx.throw：手动触发错误


• ctx.app：应用实例引用

// Context对象示例

ctx = {

  request: {...}, 

  response: {...},

  state: {},

  throw: function(){...},

  app: {...}

}



// 中间件通过ctx对象传递信息

async function middleware1(ctx){

  ctx.response.body = 'hello';

}



async function middleware2(ctx){

  let body = ctx.response.body; 

  //...

}

每次请求上下文创建后，这个Context实例会在所有中间件间传递，中间件可以通过它写入响应，传递数据等。

中间件执行流程

当请求到达Koa应用时，会创建一个Context实例，然后按顺序执行中间件栈:

1. 最内层中间件首先执行，可以操作Context进行一些初始化工作；


2. 用yield将执行权转交给下一个中间件；


3. 下一个中间件执行，并再次yield交还执行权；


4. 当最后一个中间件执行完毕后，倒序执行中间件的剩余逻辑；


5. 每个中间件都可以读取之前中间件写入Context的状态；


6. 最外层获得Context并响应请求。

// 示意中间件执行流程

app.use(async function(ctx, next){

  // 最内层执行

  ctx.message = 'hello';



  await next();

  

  // 最内层剩余逻辑  

});



app.use(async function(ctx, next){

  // 第二层执行

  

  await next();



  // 第二层剩余逻辑

  console.log(ctx.message); 

});



// 最外层获得ctx并响应

这就是洋葱圈模型核心流程，通过Generator函数和Context对象实现了优雅的异步中间件机制。

完整解析

Koa中间件是一个Generator函数，可以通过yield关键字来调用下一个中间件。例如:

const Koa = require('koa');

const app = new Koa();



app.use(async (ctx, next) => {

  console.log('中间件1开始');

  

  await next();

  

  console.log('中间件1结束');

});



app.use(async (ctx, next) => {

  console.log('中间件2');



  await next();



  console.log('中间件2结束');  

});



app.use(async ctx => {

  console.log('中间件3')

});



app.listen(3000);

在代码中，可以看到Koa注册中间件是通过app.use实现的。所有中间件的回调函数中，await next()前面的逻辑是按照中间件注册的顺序从上往下执行的，而await next()后面的逻辑是按照中间件注册的顺序从下往上执行的。

执行流程如下:

1. 收到请求,进入第一个中间件


2. 第一个中间件打印日志,调用next进入第二个中间件


3. 第二个中间件打印日志,调用next进入第三个中间件


4. 第三个中间件打印日志,并结束请求


5. control返回第二个中间件,打印结束日志


6. control返回第一个中间件,打印结束日志


7. 请求结束

这样每个中间件都可以控制请求前和请求后，形成洋葱圈模型。

中间件的实现原理

Koa通过compose函数来组合中间件，实现洋葱圈模型。compose接收一个中间件数组作为参数，执行数组中的中间件，返回一个可以执行所有中间件的函数。

compose函数的实现源码如下:

function compose (middleware) {



  return function (context, next) {

    // last called middleware #

    let index = -1

    return dispatch(0)

    function dispatch (i) {

      if (i <= index) return Promise.reject(new Error('next() called multiple times'))

      index = i

      let fn = middleware[i]

      if (i === middleware.length) fn = next

      if (!fn) return Promise.resolve()

      try {

        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));

      } catch (err) {

        return Promise.reject(err)

      }

    }

  }

}

这里利用了函数递归的机制。dispatch函数接收当前中间件的索引i，如果i大于中间件数组长度，则执行next函数。如果i小于中间件数组长度，则取出对应索引的中间件函数执行。

中间件的执行过程

执行中间件函数的时候，递归调用dispatch，同时将索引+1，表示执行下一个中间件。

这样通过递归不断调用dispatch函数，就可以依次执行每个中间件，实现洋葱圈模型。

所以Koa的洋葱圈模型实现得非常简洁优雅，这也是Koa作为新一代Node框架，相比Express更优秀的设计。

洋葱圈模型的优势

提高中间件的复用性

洋葱模型让每个中间件都可以控制请求前和请求后,这样中间件可以根据需要完成各种额外的功能,不会相互干扰,提高了中间件的复用性。

使代码结构更清晰

洋葱模型层层嵌套，执行流程一目了然，代码阅读性好，结构清晰。不会像其他模型那样回调多层嵌套，代码难以维护。

异步编程更简单

洋葱模型通过async/await，使异步代码可以以同步的方式编写，没有回调函数，代码逻辑更清晰。

错误处理更友好

每个中间件都可以捕获自己的错误，并且不会影响其他中间件的执行，这样对错误处理更加友好。

方便Debug

通过洋葱模型可以清楚看到每个中间件的进入和离开，方便Debug。

便于扩展

可以随意在洋葱圈的任意层增加或删除中间件，结构灵活，便于扩展。

总结

总体来说，洋葱模型使中间件更容易编写、维护和扩展，这也是Koa等新框架选择它的主要原因。它的嵌套结构和异步编程支持，使Koa的中间件机制更优雅和高效。

贪心算法

贪心算法是一种寻找最优解的算法思想，它通过局部最优选择来达到全局最优解。在贪心算法中，每一步都会做出当前状态下的最优选择，并且假设做出这样的选择后，剩余的问题可以被简化为一个更小的子问题。

与动态规划不同，贪心算法不需要保存子问题的解，因此通常需要更少的空间和时间。

贪心算法通常采用一种贪心的策略，即在每一步选择当前看起来最优的选择，希望最终得到全局最优解。但是，在某些情况下，局部最优解并不能保证一定能够导致全局最优解。由于贪心算法一旦做出选择就不能更改。贪心算法只是一种近似算法。

贪心算法通常需要满足贪心选择性质和最优子结构性质，否则它可能会导致错误的结果。

在使用贪心算法时，我们需要仔细考虑问题的特点和贪心选择的合理性，并尽可能地证明贪心算法的正确性。如果无法证明贪心算法的正确性，我们需要考虑使用其他算法来解决问题。

贪心算法常见的应用场景包括：

• 贪心选择性质：在求解最优解的过程中，每一步的选择只与当前状态有关，不受之前选择的影响。


• 最优子结构性质：问题的最优解可以被分解为若干个子问题的最优解，即子问题的最优解可以推导出原问题的最优解。


• 无后效性：某个状态以前的过程不会影响以后的状态，只与当前状态有关。

举个反例🌰：279. 完全平方数

给你一个整数 n ，返回 和为 n 的完全平方数的最少数量 。

完全平方数 是一个整数，其值等于另一个整数的平方；换句话说，其值等于一个整数自乘的积。例如，1、4、9 和 16 都是完全平方数，而 3 和 11 不是。

示例 1：

输入： n = 12

输出： 3 

解释： 12 = 4 + 4 + 4

示例 2：

输入： n = 13

输出： 2

解释： 13 = 4 + 9

提示：

• $1 <= n <= 10^4$

错误做法：

class Solution:

    def numSquares(self, n: int) -> int:

        count = 0

        while n != 0:

            c = int(n**(1/2))

            n -= c**2

            count += 1

        return count

输入12的时候答案是4，也就是12 = 9 + 1 + 1 + 1，

实际上应该是答案为3，12 = 4 + 4 + 4。

这个函数使用的是贪心算法的思想，每次都选择当前能用的最大完全平方数来减去 n，直到 n 减为 0。

在每一步中，选择最大的完全平方数来减去 n，可以确保所需的完全平方数的数量最小，因为如果我们选择了小的完全平方数，那么我们需要更多的完全平方数才能表示 n。

但是它并没有证明贪心策略的正确性，也没有提供正确性的证明。我们已经提供反例，证明这玩意儿是错的了。贪心算法的正确性得不到保证，所以本题不能用贪心算法。

正确答案：

class Solution:

    def numSquares(self, n: int) -> int:

        dp = [float('inf')]*(n+1)

        dp[0] = 0

        for i in range(1,n+1):

            j = 1

            while j*j <= i:

                dp[i] = min(dp[i],dp[i-j*j]+1)

                j+=1

        return dp[-1]

这个代码使用了动态规划来解决完全平方数问题，它的时间复杂度为 $O(n\sqrt{n})$，空间复杂度为 $O(n)$。

• 
  

  当 i=0 时，不需要任何完全平方数。

  
  


• 
  

  对于 i>0 的情况，我们枚举从 1 到 i 中的每个完全平方数 j*j，然后计算 dp[i-j*j]+1 的值，这个值表示在将 i-j*j 分解成完全平方数之和的基础上再加上一个完全平方数 j*j。我们需要使 dp[i-j*j]+1 的值最小，因此我们可以得出状态转移方程：

  
  

最后，dp[n] 的值就是将 n 分解成完全平方数之和所需的最小个数。

该代码正确地解决了完全平方数问题，可以得到全局最优解。

55. 跳跃游戏

给定一个非负整数数组 nums ，你最初位于数组的 第一个下标 。

数组中的每个元素代表你在该位置可以跳跃的最大长度。

判断你是否能够到达最后一个下标。

示例 1：

输入： nums = [2,3,1,1,4]

输出： true

解释： 可以先跳 1 步，从下标 0 到达下标 1, 然后再从下标 1 跳 3 步到达最后一个下标。

示例 2：

输入： nums = [3,2,1,0,4]

输出： false

解释： 无论怎样，总会到达下标为 3 的位置。但该下标的最大跳跃长度是 0 ， 所以永远不可能到达最后一个下标。

提示：

• 1 <= nums.length <= 3 * 104


• 0 <= nums[i] <= 105

class Solution:

    def canJump(self, nums: List[int]) -> bool:

        maxlen = 0

        for i,n in enumerate(nums):

            if maxlen < i:

                return False

            maxlen = max(maxlen,i+n)

        return maxlen >= len(nums) -1 

这段代码实现了一个非常经典的贪心算法，用于判断能否从数组的起点跳到终点。

具体思路是，用 maxlen 记录当前能到达的最远位置，遍历数组中的每个位置，如果当前位置大于 maxlen，说明无法到达该位置，直接返回 False。否则，更新 maxlen 为当前位置能够到达的最远位置。

这个算法的贪心策略是，在每个位置上都选择能够到达的最远位置。由于跳跃的步数只能是整数，所以如果当前位置能到达的最远位置小于当前位置，那么就无法到达该位置。

这个算法的时间复杂度是 $O(n)$，空间复杂度是 $O(1)$。

45. 跳跃游戏 II

给定一个长度为 n 的 0 索引整数数组 nums。初始位置为 nums[0]。

每个元素 nums[i] 表示从索引 i 向前跳转的最大长度。换句话说，如果你在 nums[i] 处，你可以跳转到任意 nums[i + j] 处:

• 0 <= j <= nums[i] 


• i + j < n

返回到达 nums[n - 1] 的最小跳跃次数。生成的测试用例可以到达 nums[n - 1]。

示例 1:

输入: nums = [2,3,1,1,4]

输出: 2

解释: 跳到最后一个位置的最小跳跃数是 2。

     从下标为 0 跳到下标为 1 的位置，跳 1 步，然后跳 3 步到达数组的最后一个位置。

示例 2:

输入: nums = [2,3,0,1,4]

输出: 2

提示:

• 1 <= nums.length <= 104


• 0 <= nums[i] <= 1000


• 题目保证可以到达 nums[n-1]

class Solution:

    def jump(self, nums) -> int:

        minstep = 0

        i = len(nums) - 1

        while i > 0:

            for j,n in enumerate(nums):

                if j+n >= i:

                    minstep += 1

                    i = j

                    break

        return minstep

该算法的时间复杂度为 $O(n^2)$，其中 $n$ 为数组的长度。

在最坏情况下，每个元素都需要遍历一遍，以找到它们能够到达的最远距离，这需要 $O(n)$ 的时间复杂度。同时，每次找到能够到达 $i$ 的最远距离时，都需要遍历从 $0$ 到 $i-1$ 的所有元素，以找到能够到达 $i$ 的最小步数，这也需要 $O(n)$ 的时间复杂度。因此，总时间复杂度为 $O(n^2)$。

该算法的空间复杂度为 $O(1)$，因为它只使用了常数级别的额外空间。

优化——从前往后跳：

这个算法是一个基于贪心策略的解法，跟之前的从前往后跳的贪心算法类似，不过稍微做了一些改进，可以将时间复杂度降低到 $O(n)$。

算法的核心思想是维护一个区间 [0, end]，在这个区间内每个位置所能跳到的最远距离都是 i + nums[i]，其中 i 是当前位置，nums[i] 是当前位置所能跳的最远距离。维护的时候，我们不断更新能够到达的最远距离 maxlen，当 i 到达区间的末尾 end 时，说明需要跳一步，并将 end 更新为 maxlen。

这个算法的时间复杂度为 $O(n)$，空间复杂度为 $O(1)$。

class Solution:

    def jump(self, nums):

        n = len(nums)

        maxlen = end = 0

        step = 0

        for i in range(n - 1):

            maxlen = max(maxlen, i + nums[i])

            if i == end:

                end = maxlen

                step += 1

        return step
作者：Ann
来源：juejin.cn/post/7262231954191859770