您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

(奔溃的意思)-崩溃和奔溃的意思

页面,地图,公车(奔溃的意思)-崩溃和奔溃的意思

发布时间：2019-02-08加入收藏来源：互联网点击：

最后是 Android 的 onResult 特，实现了页面间数据返回的解耦，如上示例代码就是大致的实现原理。具体来说，从 A 页面跳转到 B 页面，那么 B 页面执行了一段逻辑之后，A 希望得到执行结果，如果按照原来 iOS 的实现方式，只能通过监听 Listener 或 Delegate 等方式将 B 页面的执行结果返回给 A 页面。当 iOS 的页面框架实现了这个特， A 页面就不需要额外注册 B 页面的 Listener 或 Delegate 了，只需重写自己的 onResult 方法并处理结果即可，这样既可以实现页面解耦，又方便了业务同学开发。

接下来，举个高德地图手机端上的具体实例。

有这样一个搜索场景，从一个具体地理位置详情页可以跳转到以它为中心的搜周边页，在搜周边页中又可以跳转到另一个具体地理位置详情页，接着可以跳转到新的搜周边页，以此递归循环，但是返回时，产品希望仅返回到之前搜索过的具体地理位置详情页，略去搜周边页。如上右侧图片展示，查询顺序是：7 天优品酒店详情页 - 7 天优品酒店搜周边页 - 火驴火烧肉亭详情页 - 火驴火烧肉亭搜周边页；返回顺序是：火驴火烧肉亭搜周边页 - 火驴火烧肉亭详情页 - 7 天优品酒店详情页。中间的 7 天优品酒店搜周边页被去掉了。

在 iOS 页面框架未实现 launch mode 前，火驴火烧肉亭详情页在跳转到火驴火烧肉亭搜周边页前，需要自行遍历当前页面栈，将 7 天优品酒店搜周边页从页面栈中移出后，再跳转到火驴火烧肉亭搜周边页，以此保证产品逻辑的正确。在实现了 launch mode 之后，火驴火烧肉亭详情页仅需以 SingleInstance 的方式打开火驴火烧肉亭搜周边页即可，页面框架会自动将之前的 7 天优品酒店搜周边页调到栈顶，并将该搜周边页的内容刷新为火驴火烧肉亭搜周边。极大简化了 iOS 端业务同学的开发成本，规范了 iOS 页面跳转规范，结束了由业务自行操作页面栈的混乱时代，同时双端技术能力的融合也为上层动态 UI 业务提供了一致的体验。

上面，我们介绍了双端融合方案的三种方式，也举例说明了其带来的效果。下沉 C++，实现两套代码合一，解决了一致问题，提高了能，但同时也提高了开发门槛，适用于多年沉淀的核心逻辑；上漂动态 UI，同样解决了双端一致问题，能会稍有损失，但降低了开发门槛，使得开发速度得到提升，适用于频繁变动的业务场景；双端拉齐则是借鉴了双端优势，做到互相融合。

组件化

我们做了一些团队组件化方案的选型和参考，例如手淘的 Atlas、Beehive，网易的 LDBusMediator 等，由于这些组件化方案都比较成熟，这里不再赘述。它们都包含五个概念：容器、模块、生命周期、页面路由和对外服务（通信），我们重新命名了这些概念使其更加形象化。

容器，负责管理模块；模块，是一个独立的功能单元，可以独立编译；微应用，管理模块的生命周期，对于一个手机操作系统，是为每个应用派发生命周期，对于一个单独的应用，是为每个模块派发生命周期，就像一个应用管理着很多微应用一样，因此我们取了这个形象的名字；页面路由，负责进行 URL 的解析和页面跳转；微服务，模块中的逻辑功能，同时提供对外服务。

我们对容器在设计进行了一些改造，如上右半边图，模块被虚化了，被定义成了一个物理概念（即一个独立代码仓库），逻辑上拆分为微应用、微服务和页面路由，容器不再管理模块，而是直接管理这三个元素。之所以这样做，是因为我们希望业务更关注自身需要的服务是什么，而不是它在哪个模块，这些也是借鉴了安卓的组件化思想。

接下来，我们详细介绍下微应用生命周期的设计，如上图，微应用在 iOS 端参考的是 UIApplicationDelegate 的生命周期，而在 Android 端参考的是 Activity 的生命周期。做这样的参考选择，原因有三：一，高德地图内的应用场景大都依赖前后台切换的事件做一些逻辑处理；二，iOS 的 UIApplicationDelegate 作为应用的生命周期，同时支持前后台切换，完全吻合高德地图的场景；三，Android 选择 Activity 是因其组件化的思想，在 Android 的设计中，Application 已经弱化成了一个特殊进程的概念，并不能代表一个应用，且高德地图是基于单 Activity 实现的（上面介绍页面框架时提到过），通过 Activity 的 onStop，onRestart 生命周期中做些逻辑处理，即可判断出应用是否为前后台切换。这样，去除图中虚线框中的生命周期后，双端得到了统一的生命周期，如下左半部分图：

对于虚线中差异化的部分（如上右半部分图），设计为扩展的生命周期，做到抽象相同、扩展差异，既统一了通用生命周期，也支持了双端各自的特。

对于微服务，我们定义了一个通信规范，只能通过接口方法，不能直接调用实现。定义微服务主要是希望 UI 展现与业务逻辑能够分离，并让业务逻辑服务化，不仅服务于当前页面，也能够服务更多页面，提高代码的复用率，降低维护成本。

有了容器框架，代码便可以抽成一个个独立的模块单元，但模块应该放在那里，上下依赖关系是什么，还需要对模块进行分层、分组，下图为分层、分组后的整体架构：

通过容器建设，架构分层、分组，我们实现了组件化，解除了模块间耦合，提高了代码复用率，为后面的高效并行打好基础。分而治之的思想，组件化的“分”也是为后面的“治”做好铺垫。

搭建研发中台

研发中台应该有哪些功能，可以结合组件化和公车流程来分解，如下图：

主流程是公车流程，分为：需求收集、需求串讲、开发、合版、提测、灰度发布和正式上线。开发流程可以分解为更细的建立迭代、选择模块、功能开发、模块构建和安装包构建。这里解释下迭代的概念，即一个发版周期内的功能开发。组件化实现了功能解耦，使得不同业务团队可以在开发阶段创建自己的迭代并行开发，开发完成后在规定的时间段进行合版。提测流程可以分成模块集成、安装包构建和集成测试，其中模块集成是以产物的方式进行集成。测试通过后，通过客户端发布流程，进行灰度发布验证，灰度通过后，再进行正式上线，上线之后，我们会对崩溃、能等维度进行监控。通过流程拆解，我们整理出了研发中台的完整功能：

研发中台建设完成后，我们实现了研发流程、测试流程以及发布流程的自动化，提高了人效。另外，通过质量管控，提高了稳定；通过流程管控，约束了可能产生的风险。

主副收益

首先，通过双端融合、组件化、中台建设提升了代码稳定，实现了流程自动化，做到了开发阶段的并行，使发版周期缩短到原来的一半，从伪公车变成真公车。

其次，通过质量优化，让崩溃率从万分之八降低到十万分之八：双端融合减少了一致问题；架构合理化提高了可维护；关键流程管控，减少了风险源头；通过质量扫描，解决了头部质量问题，通过崩溃监控，解决头部崩溃问题。

然后，通过升级编译脚本，支持并行编译；通过模块化，基于产物构建安装包，大大降低编译时长，从原来的 40 多分钟降至现在的 8 分钟。

 2/3   首页 上一页 1 2 3 下一页 尾页