网站网页设计师,php英文网站源码,工程设计方案主要内容,刷排名seo软件2019杭州云栖大会上#xff0c;高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位、时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆#xff0c;听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来#x…2019杭州云栖大会上高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位、时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来本文为其中一篇。
2019杭州云栖大会高德技术专场讲师系列
《视觉智能在高德地图的应用》
《高德在提升定位精度方面的探索和实践》
《高德亿级流量接入层服务的演化之路》
阿里巴巴高级无线开发专家宋照春在高德技术专场做了题为《高德客户端及引擎技术架构演进与思考》的演讲主要分享了高德地图客户端技术架构沿着「上漂下沉」、「模块化、Bundle化」的思路演进所做的一系列架构升级中的经验和思考。
以下为宋照春演讲内容的简版实录
主要分享三个方面的内容
融合架构治理动态化
一、三管齐下 深度融合
高德最初有两个端车机版的高德导航手机版的高德地图两个团队一个是2B一个是2C分别是汽车业务和手机业务。当时在引擎/技术上分为离线引擎和在线引擎但两个团队之间交流比较少各自有自己的研发、产品和测试而作为一款端上的APP两块业务都需要有地图渲染、路线规划、导航以及定位等通用能力。从公司层面看存在较大的重复建设整体研发效率较低。 于是我们做了一件事利用技术手段打通端上引擎打造一套能同时支撑多端的APP能力。具体到执行层面先从A团队拉一部分人到B团队一起建设建设完之后再从B团队拉到A团队。在同时支撑好主线业务发展的情况下通过一年左右时间完成了引擎上的融合做到同时支撑手机、车机以及开放平台。 这样就从引擎的维度实现了渲染、定位、规划和引导的统一。具体来说我们的各大引擎有好多套代码好几个开发团队每个团队有各自的开发方式和开发环境LinuxWindowsMac OS。各种开发环境工程配置文件大量重复修改非常繁琐。
为此我们通过两种方法
1.建立了一套构建系统Abtor通过一个配置系统实现统一构建能够同时支持多个子引擎在构建集成效率上得到了很大的提升
2.对基础库进行了整体重构形成了一套涵盖了文件I/O、KV存储、多线程框架异步框架、归档、基础容器等一系列标准能力的基础库同时也做了引擎核心架构的统一。 二、架构治理
通过引擎的融合同时支持多端在研发效率上实现比较大的收益。而通过技术的抓手来实现团队的融合对公司发展而言这其实是更大的收益团队融合的意义在于人才拉通和复用组织效率得到了较大提升。
随着高德业务的快速发展业务上持续扩品类需求量激增高德地图从最初的驾车导航到后来的步行、骑行、摩托车导航等等App所承载的业务发展非常快而原有的架构治理模式的问题也逐渐暴露出来。
首先就是App的代码规模变得特别大。当时一个仓库达到了10G以上由此导致的一个典型的问题就是编译慢编译出一次安装包需要一个小时。伴随代码规模的另一个问题是团队规模快速增长。代码增长和大团队并行开发最终导致合版慢每次迭代客户端合版需要2天。
代码膨胀导致的架构腐化问题特别突出所以测试质量以及线上的质量有段时间也比较差。此外从产品提出需求到上线平均需要45天版本迭代周期很长。
为解决以上架构问题我们采取了三个手段升级Native基础组件搭建Native容器和页面框架Bundle化分拆微应用。
下面重点介绍下页面框架和微应用。
页面框架主要借鉴和融合了Android和iOS的生命期管理机制。从高德地图App架构看下层模块是一套标准地图所有上层业务都要基于地图模块开发。为确保上层业务低耦合、一致性我们设计了一个页面框架。 如上图左边的Activity是Android的系统页面控制器右边的UIViewController是iOS的系统页面控制器通过虚线连接比较我们发现两端的页面状态设计基本相同。
所以我们在设计自己的页面框架时沿用了这些系统页面状态同时从命名上也保持一致这样可以让Android和iOS原生开发的同学更容易理解和上手。
我们吸取了双端各自的优点。比如Android端页面有四种启动模式但是iOS 端并没有这些我们就把Android的四种启动模式运用到了iOS端iOS端有Present特性但是Android端没有那么也把这种特性融合到Android端的页面框架中最后还有一些小设计比如Android的onResult设计也可以借鉴融合到iOS端。
此外我们还做了微应用所谓微应用首先是模块化就是把大模块仓库大模块拆成一个个小的Bundle除了实现模块化还主要实现以下几个目标
粒度以业务为单位以业务线为分组
编译二进制级别的产物可独立编译、出包时链接
依赖松耦合以“服务”为导向不关心模块归属
而Native容器层面要实现四个核心目标路由管理、服务管理、UI生命期管理、微应用管理。
通过一年时间的Bundle化改造高德地图单端App完成了300多个页面的建设拆分了100多个Bundle。
从收益来看总编译时间从原来的60分钟降低到了8分钟合版周期从原来的3天降到1天需求上线周期降到了1个月以内线上质量和测试质量都得到了极大的提升崩溃率从万分之八降低到十万分之八。
三、动态化
随着高德地图业务发展沿着扩品类、在垂直品类做精做细景区、酒店、银行商铺、充电桩等个性化定制需求凸显对前端展现提出了更高的要求对“快速应变”要求也更高了。
实际上在2015年高德就开始做动态化。最早的时候业内就有React Native团队做了技术调研发现不能完全满足业务上的需要尤其是性能方面。最后我们决定自研一套动态化技术。
具体来说就是通过一个核心C引擎把两端业务Android、iOS用一套JavaScript代码解决实现双端归一Android实现业务动态化发布。
架构层面最下面是高德App核心的地图引擎我们在上面搭建了一套动态化应用引擎通过C来实现。应用引擎的作用是为了承上启下上面承载动态化业务下层完成地图引擎的直接打通。众所周知GUI的核心是DOM树所以应用引擎不但要实现和JavaScript引擎的整合还要负责DOM树的核心逻辑计算。
其次动态化的技术和前端Web技术一致样式、布局。应用引擎负责完成样式的布局计算、DOM树Diff、事件生成。而GUI的绘制通过Diff事件交由原生的Android以及iOS去完成。这样所有的GUI都是原生的组件。
在之上我们搭建了一套前端框架前端框架采用当前前端响应式框架做前端框架之上又搭建了一套前端的UI卡片库和UI组件库让上层业务能够更高效的开发。
而对于一些通过动态化的技术无法实现或者性能上存在卡点的功能我们就通过Native扩展能力来支撑这样完整的动态化的业务能够直接运行在Android以及iOS上。 JS去执行代码之后前端框架会产生虚拟的DOM树最后提交到C引擎形成C的DOM树。C引擎去完成布局、样式计算Diff计算将每个节点的属性和坐标交给Android以及iOS由Native来完成最终UI的渲染。
总体来说动态化的特点首先是它与主流前端框架融合充分融合了大前端的生态第二性能、扩展性较好。因为采用C实现整个核心逻辑静态和动态的语言绑定技术能够保证地图引擎的能力能够直接透出到上层或者从上层能够直接call底层的C能力第三多端归一和动态化充分利用Native优势接近原生Native体验。
动态化技术改造完成之后双端不一致的问题降低了90%开发、测试成本降低30%发版周期从T30到T0。
最后总结下高德客户端及引擎技术架构演进的几个重要阶段第一个阶段通过在线离线引擎的融合拉通让高德最核心的导航能力提到提升第二阶段在客户端发展成为“巨型”APP代码量发展到超大规模的时候通过架构治理满足业务快速增长的诉求解决大规模业务体量下的架构合理性问题消除架构瓶颈第三个阶段通过动态化的技术实现多端归一以及动态发版能力为业务发展提供更大的助力。
原文链接 本文为云栖社区原创内容未经允许不得转载。
