高德地图

前言 代码覆盖率(Code coverage)是软件测试中的一种度量形式，用于反映代码被测试的比例和水平。 在软件迭代过程中，除了应该关注测试过程中的代码覆盖率，用户应用过程中的代码覆盖率也是一个十分有价值的指标，同样不可漠视。因为随同着业务扩大和性能更新，产生了大量过期和废除的代码，这些代码或者很少甚至齐全不再应用，或者“年久失修”，短少保护，不仅对利用包体积有影响，还可能带来稳定性危险。此时，可能采集生产环境的代码覆盖率，理解线上代码的应用状况，为下线无用代码提供根据，就非常重要了。 指标 咱们的指标很明确：依据云端配置，采集线上每个类的触达和应用频次，上传到云端，在平台进行解决，并提供查问和报表展现能力。 如上图所示，咱们冀望代码覆盖率数据能在平台上进行查问和直观的展现，在须要时能够间接查看，为下线旧代码、资源调度和调配等提供决策依据，最终为用户提供更小的App安装包，更好的性能应用体验。 通过云控核心，咱们能够管制是否启用覆盖率采集，也能够依据覆盖率（类应用频次）动静调整App中金刚位、线程等资源的调度调配策略。其中覆盖率采集计划是最为重要的一环，业界也有很多成熟的计划，但都有各自适宜的场景，而咱们的诉求是在尽量不影响用户应用和App运行的前提下，采集类粒度的代码应用覆盖率。应用的采集计划应该少Hack，实现简略，兼顾稳定性和性能，同时也不会侵入打包流程，带来包体积影响等，在通过深刻摸索后，咱们自研出了一套完满满足这些要求的全新计划。 计划比照 下表为常见计划与自研计划的各项指标比照，绿色示意更优。 从表格中能够看出： Jacoco计划 相似的还有Emma、Cobertura等，他们都通过插桩实现，能够反对所有版本所有粒度的采集，然而插桩带来了肯定的包体积和性能影响，不适宜线上大范畴应用。 Hook PathClassLoader计划 实现简略，无源码侵入，且反对所有Android版本，但Hook PathClassLoader不仅带来了性能影响，甚至可能波及App稳定性。 Hack拜访ClassTable计划 可能按需采集，对App性能简直没有影响，但Hack可能带来兼容性问题，且实现较简单。 自研计划 性能优异，反对按需采集，无损App性能实现简略，未应用任何“黑科技”，稳定性和兼容性极好反对跨过程和插件采集比照得悉自研计划能更好的满足咱们采集线上代码覆盖率的诉求，因为它不仅有着很好的稳定性，而且有着优异的性能，简直不会对用户产生任何影响。那么它是如何做到高性能和高稳定性的呢？请看下文介绍。 计划介绍 原理 要采集类粒度的代码覆盖率，其实就是要晓得在App运行过程中，加载和应用了哪些类。在Java利用中，这能够通过调用ClassLoader的findLoadedClass办法间接查问失去，而在Android App中却没那么简略。起因是Android零碎做了这样一个优化： 为了晋升启动性能，对于App自定义的类，即PathClassLoader加载的类，如果间接调用findLoadedClass进行查问，即便这个类没有加载，也会执行加载操作。 这不是咱们冀望的。 尽管咱们没方法间接调用FindLoadedClass办法查问类的加载状态，然而通过深入研究和剖析，咱们发现ClassLoader最终是通过查问它的ClassTable字段失去类加载状态的，如果咱们也能拜访ClassTable，问题不就迎刃而解了吗？沿着这个思路，咱们创新性地提出了复制ClassTable指针，通过规范API间接拜访类加载状态的计划。 该计划奇妙地实现了对ClassTable的无Hack拜访；同时完满绕开了咱们不须要的类加载优化，寥寥数行代码就实现了类加载状况的获取，奇妙且简洁，同时它还具备以下劣势： 采集速度是一般计划的5倍以上，性能优异应用规范API拜访ClassTable，兼容性与稳定性极佳仅应用一次反射，无任何“黑科技”，简略稳固不影响类加载及App运行完满反对多过程和插件的采集不过有一点须要留神： ClassTable字段是从Android N开始引入的，所以该办法只实用于Android N及以上。出于必要性和ROI思考，咱们也未对Android N以下版本进行适配。 采集流程 基于上述的计划，咱们设计了残缺的代码覆盖率采集性能，要害流程如下： 能够看到整个端侧的采集流程是串行的，十分便于流程管制和数据整合。上面阐明一下设计思路： 采集时将App分为两局部，一部分是主过程和子过程应用的宿主类数据，另一部分是插件类数据。基于查问形式采集，主过程、子过程、插件别离提供查问类加载状态的接口。流程基于串行形式，由主过程管制，顺次调用相应的接口采集主过程、子过程和插件的数据。每个版本只采集和上报未加载过的类数据，首次采集时，以类选集为输出；后续的每次采集，以上一版本未加载的类为输出，采集次数越多，须要查问的类越少。主过程和子过程顺次查问，查问都以上一次查问后残余的未加载类为输出，因而越靠后的子过程所需查问的数量越少，同一个插件在不同过程的实例的查问也与此相似。如下图所示： 采集完结时，会生成一份宿主类数据和N份插件类数据（如果有N个插件）。这些数据会别离与之前的采集后果做Diff，将增量数据上传服务。服务平台进行存储、解Mapping、模块关联等解决，最初以报表模式聚合展现。值得注意的是： 主过程与子过程应用的类都属于宿主，采集后果应该合并为一份数据；同理，一个插件无论在多少个过程加载，最初也只应生成一份该插件的数据。采集时咱们将数据分为两局部，这样能够进步采集效率，也不便后续解混同；在平台展现时，合并展现更有意义。版本治理 Android App的代码大都会通过混同解决，混同后的类名会因版本而异，这就须要依据App版本来治理覆盖率数据。 按版本治理数据后，每个版本会革除上一版本的数据，防止数据错乱；一个特定的类，在以后版本曾经应用过之后，会记录下来，后续此版本的采集不再反复查问它的应用状况。 每个版本首次采集时，须要以App的类名选集作为输出，每一次采集会产生一个未应用类的汇合，作为下一次采集的输出。这样，一个版本中每次采集须要关注的类数量会逐渐缩小，可防止无意义的查问，晋升采集性能。 类名数据获取 类名数据能够通过两种形式获取： 1.从安装包获取 安装包内的类名数据能够从PathClassLoader中获取，插件则能够从对应的BaseDexClassLoader中获取，应用如下办法即可： public static List<String> getClassesFromClassLoader(BaseDexClassLoader classLoader) throws ClassNotFoundException, IllegalAccessException { //类名数据位于BaseDexClassLoader.pathList.dexElements.dexFile中，能够通过反射获取 //先获取pathList字段 Field pathListF = ReflectUtils.getField("pathList", BaseDexClassLoader.class); pathListF.setAccessible(true); Object pathList = pathListF.get(classLoader); //获取pathList中的dexElements字段 Field dexElementsF = ReflectUtils.getField("dexElements", Class.forName("dalvik.system.DexPathList")); dexElementsF.setAccessible(true); Object[] array = (Object[]) dexElementsF.get(pathList); //获取dexElements中的dexFile字段 Field dexFileF = ReflectUtils.getField("dexFile", Class.forName("dalvik.system.DexPathList$Element")); dexFileF.setAccessible(true); ArrayList<String> classes = new ArrayList<>(256); for (int i = 0; i < array.length; i++) { //获取dexFile DexFile dexFile = (DexFile) dexFileF.get(array[i]); //遍历DexFile获取类名数据 Enumeration<String> enumeration = dexFile.entries(); while (enumeration.hasMoreElements()) { classes.add(enumeration.nextElement()); } } return classes;}这种形式简略间接，不过会一次性将DexFile中的所有类名加载到内存中，而依据咱们的测试，每一万个类大概占0.8mb内存，对于动辄数万个类的大型App来说，会是一个不小的内存开销。所以还能够思考第二种形式。 ...

多边形编辑器多边形编辑工具 AMap.PolygonEditor ， 语法：new AMap.PolygonEditor(map, polygon?, opts?)。 opts 参数如下： 名称形容opts.createOptions新创建的多边形款式opts.editOptions编辑多边形款式opts.controlPoint顶点款式opts.midControlPoint两头点款式批改多边形编辑器款式如果想实现下图的多边形编辑器款式，能够通过批改第三个参数 opts 属性来实现。 代码如下： // tips: 第二个参数为 null，是因为在其余中央应用 addAdsorbPolygons 增加了多边形const polyEditor = new AMap.PolygonEditor(map, null, { // 编辑时，设置背景色与边框色彩为绿色 editOptions: { fillColor: "green", strokeColor: "green", strokeWeight: 4, }, // 设置门路顶点色彩为红色 controlPoint: { fillColor: "red", strokeColor: "red", }, // 设置两头点色彩为黄色 midControlPoint: { fillColor: "yellow", strokeColor: "yellow", }})设置 opts.createOptions 色彩，画的过程中没有失效，后续待补充。能够批改的 style 款式有哪些？ 高德 API 里没有具体阐明能够批改的编辑器 style 款式。尝试通过 add 事件打印的 event.target 看下以后编辑的多边形。 // polyEditor 是上文的 polyEditor， 没有设置 createOptionspolyEditor.on('add', event => { console.log('polyEditor add', event.target)})输入后果的 _opts 属性如下图，因为未设置 createOptions ，此处打印的是默认的 createOptions，实践状况下这些属性就是能够批改的 style 款式。其余属性也能够通过此办法查看。 ...

导言2023 年春节，经验了三年的疫情后，咱们终于在春天迎来了曙光。国人的出行激情空前低落：回家看看父母亲；心心念念的旅行终于能够成行了。依照高德的预计，2023 年春节出行的峰值流量将比 2022 年同期和 2022 年十一都有相当大比例的增长。然而，就在不久前，受疫情的影响，零碎的流量还在绝对低位运行。 如何在短时间内疾速实现春节出行的备战筹备工作，保障系统在春节流量顶峰下安稳运行，让民众出行所必须的导航等信息服务拜访能够丝般顺滑，成为了摆在技术人员眼前的迫切事件。要在流量变化很大的状况下保障系统安稳运行，同时做到降本增效，怎么做到呢？ 过来几年，高德始终在动摇、继续地推动利用的 Serverless 化。通过深刻的钻研和选型，最终抉择阿里云函数计算 FC 作为其利用的 Serverless 计算平台。过来的一年，更是获得了长足的停顿。 高德在 Serverless 上的远见帮忙他们以更加麻利、经济的形式应答不确定性以及强劲复苏的春节出行：不必费神思考流量变动带来的资源变动，无需提前依照峰值流量筹备大量的计算资源，不必放心资源是否足够，经济老本大幅降落、研发和运维效率显著晋升。 基于之前的 Serverless 成绩，高德相干业务疾速实现了春节出行备战筹备工作，春节保障顺畅实现。 咱们一起来看一个典型的案例：在 2022 年阿里云函数计算 FC 是如何助力高德 RTA 广告投放零碎实现架构降级的。 业务背景什么是 RTARTA 是一种实时的广告程序接口，通过施展媒体与广告主单方的数据、模型能力，实现实时的广告优选；RTA 是一种接口技术，更是一种策略导向的投放能力。 广告媒体通过高德的 RTA 接口，来询问是否要投广告，RTA 的服务通过查问高德本人的人群信息，返回投放后果。这样媒体投放广告能够更精准。 原零碎的架构&问题 原零碎服务器占用较多，依赖链路较长，每次扩容，依赖服务也需相应扩容，造成资源占用较多。 技术选型人群命中性能人群命中性能，实质能够归结为检索某个元素是否在一个汇合中的问题。 这类问题，业界罕用 bloom filter 进行解决。bloom filter 的实质是一组 hash 算法和 bitmap 的组合。长处是查问效率高，占用空间小。Redis 扩大版提供了 bf(bloom filter)性能。因为读取是用 golang，写入是用 Java 的写入，为了防止跨语言带来的库不统一，可能存在的 bloom filter 不同实现导致的命中不统一的问题，能够采纳 Redis 扩大版的 bf(bloom filter)性能，在 Redis 服务端实现 bf 性能，保障不同语言调用的数据一致性。 借助 Redis 来实现人群命中性能，就能够去掉算法网关，数据中台侧的很多资源也能够因而节省下来。 ...

对于每个应用手机导航App的用户来说，最怕听到的就是“卫星导航信号弱”这个提醒，因为这意味着定位不准了，用户可能无奈取得精确的指引。那么信号弱到底是咋回事呢？明明没有遮挡，咋就收不到信号呢。明天咱们简略讲一下信号弱的产生起因，以及躲避的办法。 目前高德地图播报信号弱的机会，是在导航过程中，手机没有上报卫星定位后果。咱们对信号弱问题进行了一个剖析，起因如下： 可见，在大部分状况下（80%），的确是卫星信号弱，不足以进行卫星定位，多数状况下卫星数够，信号也够强，然而依然无奈定位，起因可能是设施收到的卫星报文存在异样，导致无奈顺利解算出卫星地位，或者不同卫星给出的报文信息互相矛盾，难以确定用户的实在地位。 那么，什么起因导致设施搜不到星，或者能搜到星然而信号强劲呢？这外面存在两种可能： 1.手机周边存在电磁干扰源，导致卫星信号被覆盖在其余信号之下，无奈锁定卫星。卫星信号从2万公里远的卫星处收回，达到高空时信号强度曾经重大衰减，与4G/5G信号比照，其强度只有4G/5G信号的一万亿分之一，所以大家印象中的卫星信号接管天线个别是这样的： 普通用户没有这个条件，起码也得是星链这种 但实际上为了移动性，定位卫星天线都做的很小，比方 这个尺寸还是没法做进手机，手机里的天线长这样 天线变的这么小，信号接管成果必定差很多，所以定位信号在设计上做了很多解决，使得即便很强劲也能被辨认和解码。次要的办法，就是升高数据传输速率（依据香农定理），用更长的工夫发送一个比特，最终GPS的数据发送速率只有50Bit/秒，要发送一个残缺的定位报文须要6秒。作为比照，5G的数据速率能够达到Gb/s。尽管如此，终端设备还是有肯定的概率无奈胜利读取卫星报文，特地是在强电磁环境下。 强电磁环境并不是咱们设想中的大功率信号源左近，因为定位信号非常强劲，任何信号源都可能对定位信号造成烦扰，特地是定位信号的频段内，次要是1.1G-1.6GHz这个区间，这个区间内的干扰源很多，一些其余频段信号的谐波也会烦扰到定位信号，比方车上的各种电子设备。 当初一些手机厂商在做一些检测工具可能辨认车上的干扰源，在这个功能完善以前，普通用户能够尝试在车内扭转手机的摆放地位，比方远离中控台，放在凑近挡风玻璃的中央，看看信号是否能复原。留神，因为一个卫星报文须要6秒能力读取结束，所以扭转地位后须要期待几秒钟能力看到成果。有条件的话，能够走到车外，彻底排除车内的烦扰。如果车外能够车内不行，则阐明不是手机的问题。 说一个题外话，Spacex发射了星链卫星后，很多人设想，当前是不是能够间接用手机打卫星电话，从原理上讲其实不太事实，尽管星链卫星轨道比定位卫星轨道低很多（几百公里 vs 2万公里），但信号的衰减是不可避免的，即便能收到卫星信号，其数据速率也非常低，更艰难的是让卫星接管到手机的信号（定位信号是齐全单向的，手机不须要反向发信息）。之前铱星给出的办法是配一个微小的天线。这可能是将来解决信号弱问题的一个方法（手机减少一个插孔，能够外接天线） 2. 如果在齐全空阔的中央，在车外还是无奈定位，而且周边也没有其余电子设备，那大概率就是手机的问题。这种状况下，只能通过“重启大法”来解决了。很多用户在呈现问题后会尝试从新导航，或者重启地图App，其实这种形式大概率没用，因为此时是手机零碎无奈定位了，而不是地图App无奈定位，重启App没有成果。 据咱们察看，各个手机厂商的手机，都不同水平的存在这种问题，这次要受GNSS芯片和天线影响，一般而言，高端机型采纳的芯片品质会更好一些，卫星信号的跟踪和解算能力也更强一些，而老旧机型出问题的概率绝对更高。 最初，如果用户找不到干扰源，又不想重启手机，就没有方法导航了么？当然不是，高德地图做了大量工作去优化弱信号下的导航体验。从2019年开始，高德地图上线了智能定位性能，就是为弱信号的场景提供继续定位的能力。智能定位次要采纳以下能力提供继续的定位能力： 传感器推算：利用手机上的加速度计、陀螺仪、地磁计去判断手机的速度变动和方向变动，再配合地图匹配来判断以后所处的路线，这样即便在进入隧道当前，车标也能够继续挪动。这种惯导形式在30秒内能够放弃较高的定位精度，工夫再长就要联合其余定位办法来放弃精度了。网络点推算：网络定位是手机上另一个重要的定位能力，在室内没有卫星信号的时候都是通过网络定位来实现定位的，其原理是利用扫描到的周边基站和Wifi来实现定位，其精度在30米-200米不等。个别是市区内Wifi比拟密集，定位成果比拟好，在市区或高速上只能依附基站，车标更新会有一些卡顿或者提早。卫星弱信号解算：针对手机设施有扫描到卫星，然而无奈给出定位后果的场景，高德做了一些算法优化，使得在这种状况下依然能够提供卫星定位后果。

现代人的生存曾经离不开手机，离不开地图，一旦遇到定位不准的问题，就会产生很多问题，而且有些会很重大，比方打车找不到车、外卖找不到顾客，更惨的是开车的时候在高速上转圈圈，多跑个100公里也是有可能的。 大家把定位精确当做一个理所应当的事件，当初定位技术这么发达，北斗3代胜利组网，定位怎么还会不准呢？的确，随着工夫的推动，定位的精度是越来越高的，然而有一个潜在危险，会导致定位精度降落。 这个危险来自卫星定位坑骗技术的泛滥。卫星定位坑骗，或者地位烦扰，是通过高空上的卫星伪基站播送定位信号，让周边的定位设施误以为承受到了实在的定位信号，从而将定位后果设置为烦扰者预设的一个地位。之前咱们比拟多的据说一些人用伪通信基站去群发垃圾短信，而明天，地位烦扰也越来越广泛，比方： 驾考舞弊：驾校学习都会要求学员上车练习，而且车上有一些设施会记录学员的练习轨迹，作为学员实现学习的证据，然而一些学员不想花工夫学车，于是有一些人员会利用伪基站播发伪信号，让车辆记录仪的定位点主动围绕驾校路线行驶，即便这个设施在远离驾校的地点。这样学员不须要花1分钟学车，就能够达到所要求的学车时长。近程打卡：一些企业会基于轨迹对员工进行工时统计，多数员工可能会通过伪造本身地位的办法作假。打车刷单：一些司机为了获取接单处分或者挑单，用舞弊方法批改本人的定位点，让平台认为他在某个指定的地位，或者实现了某个订单。无人机反制：一些企业不心愿无人机凑近本人的场合，于是对无人机的地位进行烦扰，让其误以为进入禁飞区主动起飞，或者偏离航线。反跟踪：经营车辆上都装有北斗定位安装，一些企业或集体不心愿本人的实在地位被发现，于是进行地位烦扰。定位伪造办法有很多种，有些只影响繁多的设施（比方在设施上间接批改定位后果），而卫星伪基站的办法，则是技术含量比拟高的办法，这个办法能够将左近所有设施的地位全副烦扰，具体的影响范畴和基站的发射功率无关，小功率的基站只影响左近几米的范畴，而大功率的基站，能够影响周边几十公里，甚至在室内承受不到卫星信号的状况下，都会被烦扰。 这种烦扰可能将定位点定位到任意地位，而且静止速度、方向都能够指定。于是用户可能发现自己的定位点在几千公里之外，或者轨迹成为一个奇怪的形态，比方画圆圈或者沿某条路线在行驶。 地位烦扰技术的原理是什么呢？简略来说，卫星定位是通过接管到卫星信号，读取信号报文，取得工夫戳，而后用工夫戳和本地工夫相减计算出和卫星的间隔，再求解一个4元方程组（x,y,z坐标以及本地时钟偏移量）。 因为卫星信号的规格是公开的，咱们能够将任意的工夫填充到信号报文中，再通过特定的载波信号发射进来，就能够让其余设施取得谬误的定位信号。最简略的办法，是间接把某个地点的信号录下来，而后在另一个地位回放。要定位到指定地位，只须要用该地位计算出每颗星播发的工夫戳即可。而当初曾经有人把整个报文编写、载波调制、信号发射这一系列步骤做了封装，成为货架产品，任何人只有买了设施就能够本人输出指标经纬度以及速度方向，甚至是整段轨迹，而后就能够进行地位烦扰了。 比方，HackRF是一款设施，能够发射自定义的信号，有一些开源软件能够生产GNSS的软信号，再通过HackRF发射进来，就成了一个伪基站。而且，一个设施能够同时发送多路信号，模仿多颗卫星。 为什么卫星信号这么容易被烦扰呢？因为GPS设计之初并没有在安全性上思考的很谨严，所以报文齐全没有加密，用户侧也没有做鉴权，是齐全凋谢的。 后续的伽利略、格洛纳兹、北斗也都遵循雷同的设计理念，报文、调制过程都是相似的，都会被烦扰。安全性比拟好的形式，是军码，这种报文采纳专门的频率进行发射，其报文规格、编码方式都是窃密的，要读取报文须要专门的秘钥，因而难以破解或者烦扰，但这种办法无奈解决民用设施的安全性问题。 目前一些芯片厂商，以及高德，在做一些工作去发现这种烦扰，从而防止影响到用户。具体的办法包含： 1.载波校验：真信号和假信号同时呈现时，能够查看信号强度是否有异样（假信号往往信号很强，能力笼罩真信号）。 2.信号方向校验：检测信号的起源方向，如果不是来自天空，则有异样（对天线有要求）。 3.报文一致性校验：查看报文的每个字段是否和实在信号统一。 4.解算校验：解算后发现某些卫星的间隔异样，比方同时收到真信号和假信号。 5.多源校验：联合惯导、网络定位以及其余定位形式校验卫星定位的后果是否异样。 以上这些办法能够在肯定水平上升高被烦扰的概率，然而还是无奈彻底杜绝。对于普通用户来讲，当发现自己的定位后果异样时，如何发现是因为卫星信号烦扰导致呢？ 1.首先，看本人的定位后果是不是呈现在机场、油库、驾校这些地点，或者本人的地位左近是否有油库或者是一些敏感设施。 2.而后，确认本人设施的定位后果来自卫星定位而不是网络定位，如果是安卓用户能够下载一个AndroiTS GPS Test软件，如果显示Fix或ON，则代表卫星定位胜利，否则是网络定位。 对于iPhone，下载phyphox，进入GPS页面，如果速度为负阐明是网络定位，否则是卫星定位。 3.此外，在明确手机定位形式是卫星定位的状况下，如果周边的多台手机都定位在了谬误的地位（至多偏离了200米以上，如果偏离间隔不远，有可能是卫星定位点漂移了），则大概率此地被某个周边的伪卫星基站给烦扰了。 有些烦扰未必是烦扰者的本意，他原本可能只想管制某个小范畴的设施，然而天线功率设置不合理，信号被扩散到很远的中央。 可能明确有烦扰，如何解决呢？只能向政府部门寻求帮忙，能够打电话给当地的无线电治理部门，要求排查。无线电治理部门有专门的仪器能够检测伪基站信号，确定地位，并将设施关停。欢送大家举报非法的无线电烦扰行为。 具体电话可参考 https://www.miit.gov.cn/gzcy/cydh/art/2020/art_ba58d28194884d66b0032861a11e0bd2.html

随同着数字化、元宇宙时代的带来，作为图形技术的外围局部，渲染技术正从幕后走向台前，进入咱们生存的方方面面。渲染技术在游戏、影视、地图利用、电商、AR交互、主动驾驶、数据可视化等畛域都有着丰盛的利用场景，其重要性和迅猛发展曾经成为业界共识。 对于很多在校大学生，也把渲染技术作为将来走向职场的重要技术储备和倒退方向，大家在学校期间也或多或少接触到一些图像图像渲染技术的内容，但很多时候困惑于不足体系化学习，难以全面理解渲染技术的前沿技术，以及在企业界的最新利用实际状况。 高德作为国民级的出行生存服务平台，渲染技术在高德业务场景中有着丰盛且深刻的利用，在地图、导航、主动驾驶、高精地图、新一代的AR & 车道级导航等场景均有着业界当先的技术研发和利用实力。 为了让高校同学们有更多机会理解渲染技术在数字世界的最新倒退，让更多有趣味零碎学习渲染技术的同学早日把握实战级的能力，甚至为行业造就更多的渲染技术后备军，高德启动了「渲染练习生打算」。 本打算由阿里巴巴-高德发动，面向符合条件的在校本科、硕士、博士等在校生收费凋谢。咱们旨在开掘和造就对渲染技术感兴趣或致力于成为渲染研发精英的在校学生，提供一个学习的渠道，通过体系化的学习、实在的教训分享，在阿里及高德师兄们的陪伴下开启渲染研发之旅。 高德「渲染练习生打算」将推出7大方向、近40节课程。在这儿，你能够理解渲染畛域，从实践到实际，还能够与业务一线的渲染研发资深从业者1v1探讨沟通，相互启发。不仅于此，你还能在课堂和我的项目中结交到一群气味相投的敌人，大家独特学习，独特成长。 面向群体 对渲染研发畛域感兴趣的2023、2024年毕业的本科、硕士、博士在校学生。 学习形式 在线学习 工夫安顿 报名工夫：2022年1月21日——2022年2月20日 开课时间：2022年2月下旬 整体流程 报名形式 https://yida.alibaba-inc.com/... 课程简介 本次高德「渲染练习生打算」将蕴含以下7大方向的培训课程。 地图渲染技术的前景：从技术视角登程，联合XR、主动驾驶、数字孪生、元宇宙等热点技术话题，聊一聊地图渲染技术的发展前景。 渲染根底：以渲染实战视角理解所须要的C++及渲染的基础知识。探讨C++三大个性以及三维数据成像原理。 GIS根底：地理信息系统（简称GIS），是一门综合性学科，联合了地理学、地图学以及遥感和计算机科学。本课程将介绍地图中用到了哪些GIS技术，以及相干的基础知识。 渲染特效：渲染特效，是指如何以合乎审美或格调的形式用计算机画出各类元素和成果，将会联合地图以及业界最新利用，简略介绍罕用的光照模型、暗影、动画、贴图技术，根底特效和高级特效。 几何算法：本章是计算几何的入门课程，蕴含几何相交（碰撞）算法与三角化算法两局部内容。带你直观地领会计算机算法的技巧与魅力！ 三维建模：本章次要介绍样条线与几类典型的三维模型生成与批改办法，带大家理解如何通过程序与参数来生成一些常见的几何体。 渲染引擎：通过对OSG开源渲染引擎的根本框架及运行逻辑的分析，以及市面上罕用的几款商业引擎特点的剖析，使你对渲染引擎有个初步理解。 划重点啦，课程播种 视线开辟：宏观理解渲染畛域的倒退历程与将来前景，减少一种从业可能性；技能播种：体系化的渲染技术，实践与实际相结合；师长好友：渲染技术专家、学长学姐沟通交流机会，互相学习；面试机会：优良学员可取得阿里巴巴-高德的渲染等岗位直通面试机会；学习材料：课程视频重复屡次观看，突破工夫限度，不错过每一个精彩霎时；权威证书：学习全副课程并实现结业我的项目，取得「阿里巴巴-高德“渲染练习生打算”」结业证书。继续学习是这个大变革时代最外围的能力，时代和行业都在变，而不变的是咱们总能用所把握的技能，去对世界带来渺小而美妙的扭转。 欢送大家的退出！

先看看实现后的样子： 这里就不说根底了，有不懂能够去查一下，网上对于根底还是挺多的 或者能够看看官网文档：入口高德地图vue应用根底疏导 看完就能够把高德地图的根底图层引入到我的项目中了 而后再看看官网遮罩示例：遮罩示例 然而想要应用遮罩插件还须要以下配置： 1、配置平安密钥(留神：不是key) window._AMapSecurityConfig = { securityJsCode:'你的平安密钥', };留神：配置平安密钥必须在初始化地图根底图层(AMapLoader.load)之前！否则没有任何成果！ 2、引入省市区查问插件(其余插件也是这样引入的) AMapLoader.load({ key:"你的key", version:"2.0",//这个是版本 plugins:['AMap.DistrictSearch']//插件在这里引入 }).then((AMap) => { let map = new AMap.Map("container",{ resizeEnable: true, zoom: 11,//地图初始的缩放倍数 center:[res.city.longitude,res.city.latitude],//初始化后地图展现的核心地位 }); this.initPolygon(city, map);//这是创立遮罩的办法，我把城市和初始化的地图传进去 }).catch( e => { console.log(e); })3、初始化遮罩 initPolygon(city, map) { AMap.plugin('AMap.DistrictSearch', function () { new AMap.DistrictSearch({ extensions: 'all', subdistrict: 0 }).search(city, function(status, result) { let outer = [ new AMap.LngLat(-360, 90, true), new AMap.LngLat(-360, -90, true), new AMap.LngLat(360, -90, true), new AMap.LngLat(360, 90, true) ]; let holes = result.districtList[0].boundaries; let pathArray = [outer]; pathArray.push.apply(pathArray, holes); //增加遮罩款式 let polygon = new AMap.Polygon({ pathL: pathArray, strokeColor: '#00eeff', strokeWeight: 1, fillColor: '#71B3ff', fillOpacity: 0.5 }); polygon.setPath(pathArray); map.add(polygon); }) }) },这样，一个遮罩就弄出来了 ...

刚好有个我的项目须要用到，先用了淘宝和新浪的都没有实现频繁报权限谬误问题，改了php.ini文件也不能解决问题，果决放弃抉择了高德。先看文档：https://lbs.amap.com/api/webs...首先须要本人先依据文档注册一个高德账号，获取到key值，而后依据本人的需要抉择用v3还是v5如图所示v3只能获取到国内ip，所以我这边用的是v5。 $ip = '123.125.114.144';//国内 $ip = $_SERVER['REMOTE_ADDR']; $ip = '20.205.243.166';//国外 $url = 'https://restapi.amap.com/v5/ip?ip=' . $ip . '&key=本人的key'.'&type=4'; $number = time() . mt_rand(0, 10); $data = file_get_contents($url); $data = json_decode(($data), true); if ($data['country'] == '中国') { echo '中国用户'; } else { echo '国外用户'; } print_r($data);die;打印数据结构如下：

1.导读 高德启动Go业务建设曾经有段时间了，次要蕴含Go利用落地，Go中间件建设，云原生三个局部。通过继续的发力，在这些方面获得了不错的停顿。高德Go业务落地过程是如何实现的，遇到过哪些问题，如何解决？本文将为大家介绍相干教训，心愿对感兴趣的同学有所帮忙。 2. 高德为什么要落地Go利用 当初高德内支流的语言还是Java，Java利用最多，机器数非常惊人。而且高德整体业务也在疾速向前奔跑，成本增加的速度十分快。在缩小机器负载方面，Go语言在语言级别对Java语言有相当劣势。缩小机器老本是咱们落地Go利用的第一个思考因素。 其次，Go语言近几年发展势头迅猛，不论是阿里团体外部，还是在高德外部，对应用Go语言的呼声越来愈高。落地Go利用能够很好的验证Go中间件的稳定性。当然咱们能够通过混沌工程等伎俩去验证，但通过生产环境考验才最具备说服力。验证积淀Go语言中间件稳定性是咱们落地Go利用的第二个思考因素。 最初，Go语言作为云原生根底框架应用较多的语言，提前落地Go利用，对后续落地云原生能够缩小不少阻力。高德目前落地的Serverless/Faas规模相当大。落地Go利用的第三个思考因素是为后续云原生落地铺路。 3. 大流量场景Go利用落地 3.1 渲染网关介绍 本文所述中提到的高德渲染网关，是咱们落地的Go利用中业务流量、革新难度、危险，收益均处前列的利用。渲染网关在接入层，占高德总流量的一半，重要性可想而知。 接下来简要介绍下渲染网关承接的业务，不便大家有一些更平面的意识。 渲染网关承接高德手机App、车机、开放平台等起源所有的图面渲染。大家在应用高德时，看到的建筑物、地形图、名称、路线、地铁站、公交站、红绿灯等等所有图面，都是由渲染引擎通过渲染网关透出到端。上面放几张图，不便大家有一些更理性的意识。 下面图一为行前，图二为行中，图三为打车页面，图四为景区手绘图。渲染网关波及业务泛滥，以上仅为举例，其余业务就不在这里贴图了。 3.2 重构难点 做过重构我的项目的同学置信都深有体会，重构我的项目中最大难点有二，一是要保障业务正确性，二是要保障服务稳定性。 对于保障业务正确性，一般来说，重构的服务大多数为老服务，老服务面临的最大问题是历史逻辑简单，人员更迭，文档缺失，这些因素都是重构过程中的“拦路虎”。 渲染网关重构同样如此，它波及高德手机端、车机端、开放平台、打车等各个业务线，所有的历史版本，再加上上述因素，所以保障业务正确性是一件十分艰难的工作。 对于保障服务稳定性，做过网关的同学应该都晓得，网关自身的属性就决定了它并不会有频繁的业务迭代，稳定性是网关的第一诉求。咱们要保障，无论外部环境/依赖是否失常，网关始终能放弃高可用。因为Go版本中间件不足在大流量场景的充沛验证，这一难点须要认真评测，用适合的办法和伎俩，尽可能的在仿真环境里验证各种边界状况，从而保障在生产环境不出问题。 3.3 技术计划 在重构高德渲染网关时，咱们整体技术计划分三大步走： 3.3.1 线上流量比照 如何验证新服务的业务正确性呢？咱们采纳了线上流量比照的形式。 咱们后期做了大量调研，心愿找到一个满足（近）实时，二进制级比照的工具，但惋惜并没有找到一个满足要求的工具。因为渲染业务的非凡属性，渲染网关绝大多数接口返回的是二进制矢量数据，所以现实的工具不仅要能反对惯例数据比照，也要能反对二进制级比照。 二进制级比照的另一个益处是，能够排除字符集差别，不同语言库函数差别。更能保障比照的准确性。有些同学可能会想到打日志，而后离线读取比拟的形式来做比照，这种形式有很多弊病。 首先，流量无奈重放至指定机器。其次，这种应用形式个别为固定语料，语料残缺度不够，不能齐全模仿线上环境。此外，打日志比照带来的字符集和语言库函数差别，会对比拟准确性有较大影响，特地是对于特殊字符（当7层协定为二进制协定时更加显著）。没有现成的称手工具，怎么办？"逢山开路，遇水搭桥"。 咱们自主研发了一款（近）实时流量比照工具，它保障了此次重构的业务正确性，并且还能服务于高德其余业务的重构。其技术细节对TCP/IP波及较多，十分有意思，感兴趣的同学能够间接跳至《流量比照工具（ln）技术细节》一节。 3.3.2 仿真环境压测 做服务的同学置信都深有体会，想让服务保障做到5个9的可用性并不是一件容易的事。实在生产环境中可能会呈现各种状况，咱们要想方法验证各种边界状况下服务的稳定性，能力保障服务高可用。对于重构实现的新服务，更须要一个仿真环境，进行各种状况验证。 构建仿真环境，咱们须要放弃机器基线、内部依赖、内部流量均统一（比方从线上引流）。仿真环境不仅要提供失常态环境的能力，更要能提供异样态环境的能力。 异样态包含断网，网络丢包等等。有句话说的好：20%的代码实现性能，80%的代码来解决各种异常情况。咱们在实践中构建异样态的次要伎俩为混沌工程，通过混沌工程模仿下至操作系统级的异样（如断网，丢包等），上至应用层的异样（如消息中间件积压，JVM办法前后Hook模仿业务异样等等）。 在仿真环境里，同时进行长时间极限压测，语料从线上导流，压测在失常态，异样态均进行，察看服务在一段较长时间内的体现，从而得出服务的稳定性，可用性论断。 观测指标包含根底指标，例如CPU、磁盘利用率、内存利用率、连接数，以及业务指标，例如业务接口成功率、胜利量、总量、TP99。通过这种形式，基本上齐全笼罩了可能呈现各种状况，充分保证了服务稳定性和高可用。 3.3.3 平滑灰度切流 前边讲了如何保障业务正确性和服务稳定性。接下来说说如何保障平滑灰度切流。牢牢恪守阿里公布三准则是平滑灰度切流的“法宝”：可灰度，可监控，可回滚。 在具体实际中，咱们依照如下步骤灰度切流： a. 原Java集群不动，新申请一套Go集群。批改路由规定，局部白名单用户应用Go集群服务。 b. 一一接口批改路由规定至Go集群，缓缓灰度，期间亲密察看机器姿势，业务日志，监控指标。如有异样一键切回至Java集群。 c. 接口全量切至Go集群后，Java集群/Go集群同时共存一段时间。 d. 逐步下掉Java集群机器。 3.4 次要收益 第一个重要收益：降本提效。高德渲染网关由Java换成Go语言之后，机器数缩小近一半。用原来一半的资源实现了雷同的工作，大大降低了老本，进步了资源利用率，更好反对了业务倒退，大大降低了业务流量快速增长带来的接入层机器增长速度。 第二个重要的收益是：验证了高德与团体单干共建的Go版本中间件的稳定性，肯定水平上欠缺凋敝了团体Go生态。在大流量场景考验过后，高德与团体单干共建的Go版本中间件稳定性失去了相当充沛的验证。 第三个重要的收益是：为网关云原生化铺路。网关Go化只是第一步，Go是云原生基础设施实现应用较多的语言，第一步抹平语言差别，对于网关后续云原生化，好处多多，可升高革新危险和老本。 当然，高德渲染网关重构过程中还有许多十分有用的工具积淀。可为后续业务重构提供关键性保障，比方自研的流量比照工具ln。 4. 技术干货 4.1 流量比照工具（ln）技术细节 先提一个问题，做一款（近）实时流量比照工具须要实现哪些性能？没错，就是流量复制，流量解析，流量重放，流量比对。其实不止这些，在实践中更多是一个流量回归闭环，如下图： 4.1.1 流量复制 为了反对所有的7层协定，流量获取必须从3层或4层开始。有同学会立马想到tcpdump。没错，就是tcpdump。tcpdump出的文件就是实实在在的流量。复制流量这一步曾经有着落了，至于实时，能够两到三个过程错开工夫，时间段首尾相互重叠即可实现实时。 另外，设计此工具的另一个考量点是，对线上机器不能有太重的负载，防止对线上机器产生稳定性影响。此种流量复制形式十分轻量，对线上机器减少的负载十分小，能够忽略不计。 4.1.2 流量上传&流量拉取 ...

一、背景 高精地图、高精采集车，是做地图和出行畛域同学常常挂在嘴上的一些罕用词儿。然而，圈外的同学可能会问，到底什么是高精？ 高精是指高精度定位，高精地图是指蕴含丰盛地理信息数据、具备高精度坐标的地图。当然，高精采集车就是采集制作高精地图数据的特种作业车。 有些好奇的小伙伴会打破砂锅问到底，高精是怎么实现的呢？怎样才能叫高精度？ 事实上，目前高精度的规范并不是很确定，但根本认为厘米级以上的精度能力算是高精度。高精的实现，次要是靠各类传感器，其中最重要的就是高精度定位定向零碎，包含卫星定位及惯性导航两局部。 本文次要从硬件角度给大家介绍一些这方面的状况，以及在理论工作中对它的使用。 二、术语解释 定位定向零碎：POS零碎（Position and Orientation System, POS），是指惯性导航+GNSS卫星导航组合的高精度地位与姿势测量零碎，利用装在载体上的卫星接收机准确测定空间地位，利用惯性测量安装测定霎时传感器姿势，通过准确时钟将两者联合起来，最初通过运算，获取载体的速度和姿势、地位等信息。 惯性导航零碎：简称惯导，是以陀螺和加速度计为敏感器件的导航参数解算零碎，依据陀螺/加速度计的输入，建设导航坐标系，解算出载体在导航坐标系中的速度和地位。 IMU：惯性测量单元（Inertial Measurement Unit），是测量物体三轴姿势角(或角速率)以及加速度的安装。IMU是惯性导航零碎的一部分。 GNSS：寰球导航卫星零碎（Global Navigation Satellite System），泛指所有的卫星导航系统，包含寰球的、区域的和加强的，如美国的GPS、俄罗斯的Glonass、欧洲的Galileo、中国的北斗卫星导航系统，以及相干的加强零碎，如美国的WAAS（广域加强零碎）、欧洲的EGNOS（欧洲静地导航重叠零碎）和日本的MSAS（多功能运输卫星加强零碎）等，还涵盖在建和当前要建设的其余卫星导航系统。 备注：咱们外部习惯把定位局部简称为惯导，理论不仅仅蕴含惯导设施，是指蕴含整套软硬件的定位定向零碎。 三、高精度定位定向零碎包含什么 采集车上的高精度定位定向零碎，个别次要由上面几局部组成： 定位定向零碎的形成 算法过程 整个零碎由硬件和配套的软件及算法组成，因为组合解算的算法在业界有十分多的钻研，各种办法和思路也是百花齐放，在高德外部有相干的同学做这方面的开发工作。因而，本文仅侧重于硬件角度的介绍。 低精度、高精度定位系统的组成内容差不多，区别只是传感器（IMU、GNSS）的精度等级不同。 四、各传感器的作用和角色 1.GNSS 相似以前常说的GPS，然而随着科技进步，咱们国家的北斗零碎BD在精度和可靠性上也能匹敌GPS了，在理论使用中施展着重要作用。 从几十元的模组，到上万元的高精GNSS板卡，定位原理基本一致，都是测量出已知地位的卫星到用户接收机之间的间隔，而后综合多颗卫星的数据就可晓得接收机的具体位置。卫星地位能够依据星载时钟所记录的工夫在卫星星历中查出。 然而在信噪比、频段、星座数量、通道数、信号捕捉跟踪等能力上，高精度GNSS板卡显著优于一般的GPS，例如手机个别仅反对GPS L1频段的C/A码，然而专业级的板卡根本都反对L1/L2/L5多频段、多通道。 除了在实时定位精度上显著优于一般模组，业余的GNSS板卡还能够进行后处理，精度达毫米级，这就是业余接收机板卡的价值所在。 业内次要的卫星接收机厂商包含国外的天宝Trimble、诺瓦泰Novatel、徕卡LeiCa、拓普康等，以及国内的北斗星通、华测、中海达、司南等。 GNSS在零碎中的次要作用是获取以后地位的相对坐标，长处是不存在地位误差累积，毛病是更新频率低，个别最高不超过10~50HZ。 2.IMU 事实上，IMU才是俗称惯导的高精度定位定向零碎的外围，价格上也反馈了这一点：如某个近百万元的设施，卫星接收机局部仅占数万元，其余大部分都是IMU费用。 从某种程度上讲，选定位定姿零碎，其实重点是选IMU，因为GNSS局部选型绝对简略直观。 本文前面也次要以IMU为偏重论述对象。 IMU通常由三个单轴的加速度计和三个单轴的陀螺仪组成，加速度计检测载体在坐标零碎中独立三轴的加速度信号，而陀螺仪检测载体绝对于坐标系的角速度信号，对这些信号进行解决之后，便可解算出载体的姿势。 值得注意的是，IMU及惯性推算算法提供的是一个绝对的原始定位信息，它的作用是测量绝对于终点所静止的路线，所以它并不能提供你所在的具体位置的信息。因而，它经常和GNSS一起应用，当在某些GNSS信号强劲甚至缺失的中央时，IMU就能够施展它的作用，能够让载体继续取得相对地位姿势信息。 IMU的更新频率较高，个别可达几百至1KHz。应用三个加速度值，通过两次积分可取得位移，以此实现地位定位，有角速度值积分能够获取姿势信息，联合在一起可取得物体的理论状态。 别看IMU这个技术说起来比拟生疏，其实咱们每天应用的手机，以及汽车、飞机，乃至宇宙飞船都会应用到IMU，区别在于资料、老本和精度。 依据不同的应用场景，对IMU的精度有不同的要求，精度高，也意味着老本高。咱们高精车，当然应用最高等级的。 IMU的价格和精度比照 3.里程计 规范的里程计个别外挂装置在车轮上，内置一个旋转编码器，通过车轮带动独特旋转。作用是测量车辆挪动的线性间隔，并在卫星失锁时帮忙克制漂移误差。里程计的模式有多种多样，除外挂旋转编码器外，磁栅式、霍尔式等等都有利用。 4.加强、辅助伎俩 次要是一些陆基和星基加强技术，包含RTK、RTD、PPK、PPP、DGPS、各种SBAS等，咱们平时作业时很少会用到星基加强零碎，次要用到的是陆基加强零碎。高精采集个别采纳预先差合成算解决的办法。 五、惯性导航是怎么炼成的 后面曾经说过，定位定向零碎蕴含惯性导航，惯性导航的次要硬件是IMU，而IMU是由陀螺和加速度计两大部分组成的。 1.陀螺仪 先看看陀螺是啥样子？是的，就是上面这个东东。 这个陀螺和咱们平时了解的惯性导航设施内的角速度传感器有什么关系？ 从制作工艺和资料、原理上讲，没太大关系，是两种不同的货色。然而这些货色，都可当作旋转角速度传感器用，而这种相似机械陀螺状态的产品最先应用，先入为主了，所以起初把这种角速度传感器，都叫做陀螺仪。 事实上陀螺仪的品种很多，依据物理原理大体上可分为机械陀螺、激光陀螺和光纤陀螺、微机械（MEMS）陀螺等等。 机械陀螺仪：在晚期的飞机曾大量应用。它体积大、结构复杂、精度差。前期有一些改良的类型，如：滚珠轴承自在陀螺仪、液浮陀螺仪等。 激光陀螺：利用萨格纳克实践中的光程差来测量旋转角速度。其要点是：当光束在一个环形的通道中后退时，如果环形通道自身具备一个转动速度，那么光线沿着通道转动的方向后退所须要的工夫、要比沿着这个通道转动相同的方向后退所须要的工夫要多。 萨格纳克试验 这个萨格纳克实践很有意思，感兴趣的同学能够自行加深了解。 激光陀螺实际上是一种环形激光器。在闭合光路中，由同一光源收回的沿顺时针方向和反时针方向传输的两束光和光干预，利用检测相位差或干预条纹的变动，就能够测出闭合光路旋转角速度。当环形激光器处于静止状态时，两束激光绕行一周的光程相等，因此频率雷同，两个频率之差(频差)为零，干预条纹为零。 当环形激光器绕垂直于闭合光路立体的轴转动时，与转动方向统一的那束光的光程缩短，波长增大，频率升高；另一束光则相同，因此呈现频差，造成干预条纹。 激光陀螺没有外部静止器件，数据漂移率低，可靠性高，测量精度高。因为光程差的关系，激光陀螺会有肯定的速度门限，低于这个门限，可能会检测不到角速度变动。另外，因为要应用环形激光器的缘故，整个器件体积大、老本高。 ...

一、导读 7月31日，华为HarmonyOS开发者日将在杭州举办。为了不便更多开发者，高德开放平台地图SDK已在业内率先实现鸿蒙化迁徙和重构，全面适配HarmonyOS并面向开发者收费公布。开发者可到高德开放平台官网理解更多内容，获取版本下载、开发文档、常见问题等反对。 拜访高德开放平台：https://lbs.amap.com/ 在往年6月2日，华为就正式公布了HarmonyOS。因为HarmonyOS在兼容Android上有特殊要求，如果APP利用是用Android API开发，开发者能够间接应用Android的SDK。 但如果APP用了HarmonyOS的API开发，就不能用Android的SDK而须要应用HarmonyOS版本的SDK。 为了不便开发者在HarmonyOS的相应设施中进行LBS服务的开发，高德开放平台率先进行了HarmonyOS适配，首批适配范畴包含地图和搜寻SDK，反对嵌入搭载HarmonyOS的手机、Pad及其他智能终端设备。 二、HarmonyOS地图SDK个性介绍 与高德开放平台Android地图SDK平滑切换 已集成高德开放平台Android地图SDK的开发者可无缝切换到HarmonyOS地图SDK，无额定开发量。HarmonyOS与Android零碎间的接口变动由高德开放平台SDK适配层消化，SDK对外接口放弃不变。高德底层引擎对接HarmonyOS NDK，下层代码全面对接HarmonyOS SDK，所有零碎接口均应用HarmonyOS API。 继承高德开放平台Android/iOS地图SDK性能亮点 开发者能够通过高德开放平台API和SDK，轻松实现地图的构建工作，将地图粗劣地出现在您的利用中。地图SDK不仅提供丰盛的地图覆盖物绘制能力，也反对搜寻、多种门路布局、坐标转换、间隔测量、面积计算等性能。适配HarmonyOS后的地图SDK仍旧反对与自定义地图SaaS平台等周边工具配合应用，开发者能够在平台中定制区域面、建筑物、水系、天空、路线、标注、行政边界共7大类40余种地图元素，灵便设计心仪的地图款式。更多地图SDK根底能力、自定义、可视化能力详情请参考高德开放平台官网。 HarmonyOS版地图SDK整体框架 HarmonyOS和Android零碎差别很大，简直所有的API都有调整，不少API都调整了实现计划，所以不能通过改包名来实现适配。咱们将原生SDK中所有调用Android的代码均切换为适配层，在适配层将SDK的接口一一适配到HarmonyOS接口。 HarmonyOS版地图SDK整体框架大抵如下： 三、如何集成-从零开始 第一步 搭建HarmonyOS开发环境 实现DevEco Studio装置、环境配置和工程创立，参考HarmonyOS官网阐明：https://developer.harmonyos.c... 第二步 配置利用的签名信息 利用工程创立实现后，须要配置签名信息，才能够应用真机调试和公布利用。 第三步 获取利用的appId 配置完签名信息之后，就能够获取以后利用的appId了，这个appId次要用于申请高德的apiKey，请确定最终公布利用的appId，避免最终高德SDK鉴权失败。 通过代码获取利用的appId形式如下： getApplicationContext().getBundleManager().getBundleInfo(getBundleName(), 0).getAppId()留神：目前通过DevEco Studio连贯云真机获取到的appId不全，只获取到了"包名_", 应用云真机调试高德地图SDK时会导致鉴权不通过。正确的appId模式为："包名_签名信息"， 例如：com.amap.demo_BGtGgVB3ASqU7XXXXV2/zhoYh6tFQHAd5DASWVTEAgvZfzrEGljjs= 第四步 在高德开放平台官网控制台申请API Key 创立新利用 从开放平台官网右上角入口-控制台，创立一个新利用。如果您之前曾经创立过利用，可间接跳过这个步骤。 增加新Key 在创立的利用上点击"增加新Key"按钮，在弹出的对话框中，顺次：输出利用名名称，抉择绑定的服务为“Harmony平台SDK”，输出AppID，如下图所示： 须要留神：1个Key只能用于一个利用（多渠道安装包属于多个利用），1个Key在多个利用上应用会呈现服务调用失败。 在浏览完高德地图API服务条款后，勾选此选项，点击“提交”，实现Key的申请，此时您能够在所创立的利用上面看到刚申请的Key了。 第五步 在代码中设置申请的Key 请应用API的形式将申请的高德API Key设置给高德地图SDK。 /** * 动静设置apiKey。 * * @param apiKey 在高德官网上申请的apiKey。 */MapsInitializer.setApiKey(String apiKey)留神：请确保在调用任何高德地图SDK的接口之前将API Key设置给高德地图SDK，倡议放到Application的初始化之中。 实现以上5步之后，就能够欢快的应用HarmonyOS版高德地图SDK了。 四、如何应用-创立地图 应用地图SDK之前，须要在config.json文件中进行相干权限设置，确保地图功能能够失常应用。 第一步 配置config.json ...

1. 前言 最近，笔者有幸对高德打车订单Push我的项目进行了重构，与大家分享一下代码重构相干的工作教训，心愿对大家有所启发。 有时候，咱们在做某个性能需要时，须要花掉大量的工夫，能力找到和需要有关联的代码。或者，咱们在浏览他人写的代码、接手他人的我的项目时，总是“头皮发麻”，当你面对构造凌乱、毫无章法的代码构造，词不达意的变量名、办法名时，我置信你基本没有读上来的情绪。这不是你的问题，而是你手中的代码须要进行重构了。 2. 何为重构 每个人对重构都有本人的定义，我这里援用的是“Martin Fowler”的，他从两个维度对重构进行了定义。 作为名词：重构是对软件内部结构的一种调整，目标是在不扭转软件可察看行为前提下，进步其可了解性，升高其批改老本。  作为动词：重构是应用一系列重构手法，在不扭转软件可察看行为的前提下，调整其构造。 我在本文提到的代码重构，更偏差它作为动词的定义，而依据重构的规模水平、工夫长短，咱们能够将代码重构分为小型重构和大型重构。 小型重构：是对代码的细节进行重构，次要是针对类、函数、变量等代码级别的重构。比方常见的标准命名（针对词不达意的变量再命名），打消超大函数，打消反复代码等。个别这类重构批改的中央比拟集中，绝对简略，影响比拟小、工夫较短。所以难度绝对要低一些，咱们齐全能够在日常的随版开发中进行。 大型重构：是对代码顶层进行重构，包含对系统结构、模块构造、代码构造、类关系的重构。个别采取的伎俩是进行服务分层、业务模块化、组件化、代码形象复用等。这类重构可能须要进行准则再定义、模式再定义甚至业务再定义。波及到的代码调整和批改多，所以影响比拟大、耗时较长、带来的危险比拟大（我的项目叫停危险、代码Bug危险、业务破绽危险）。这就须要咱们具备大型项目重构的教训，否则很容易犯错，最初得失相当。 其实大多数人都是不喜爱重构工作的，就像没有人违心给他人“擦屁股”一样，次要可能有以下几个方面的担心： 不晓得怎么重构，不足重构的教训和方法论，容易在重构中犯错。很难看到短期收益，如果这些利益是久远的，何必当初就付出这些致力呢？久远看来，说不定当我的项目播种这些利益时，你曾经不负责这块工作了。重构会毁坏现有程序，带来意想不到的Bug，不想去接受这些意料之外的Bug。重构须要你付出额定的工作，何况可能须要重构的代码并不是你编写的。3. 为何重构 如果我纯正为明天工作，今天我将齐全无奈工作。程序有两面价值：“明天能够为你做什么” 和 “今天能够为你做什么”。大多数时候，咱们都只关注本人明天想要程序做什么。不论是修复谬误或是增加个性，都是为了让程序力更强，让它在明天更有价值。然而我为什么还是提倡大家要在适合的机会做代码重构，起因次要有以下几点： 让软件架构始终保持良好的设计。改良咱们的软件设计，让软件架构向无利的方向倒退，可能始终对外提供稳固的服务、从容的面对各种突发的问题。减少可维护性，升高保护老本，对团队和集体都是正向的良性循环，让软件更容易了解。无论是前人浏览前人写的代码，还是预先回顾本人的代码，都可能疾速理解整个逻辑，明确业务，轻松的对系统进行保护。进步研发速度、缩短人力老本。大家可能深有体会，一个零碎在上线初期，向零碎中减少性能时，实现速度十分快，然而如果不重视代码品质，前期向零碎中增加一个很小的性能可能就须要花上一周或更长的工夫。而代码重构是一种无效的保障代码品质的伎俩，良好的设计是保护软件开发速度的基本。重构能够帮忙你更疾速的开发软件，因为它阻止零碎腐烂变质，甚至还能够进步设计品质。 4. 如何重构 小型重构 小型重构大部分都是在日常开发中进行的，个别的参考规范即是咱们的开发标准和准则，目标是为了解决代码中的坏滋味，咱们来看一下常见的坏滋味都有哪些？ 泛型擦除 //{"param1":"v1", "param2":"v2", "param3":30, ……}Map map = JSON.parseObject(msg); //【1】……// 将map作为参数传递给底层接口xxxService.handle(map); //【2】//看一下底层接口定义void handle(Map<String, String> map); //【3】【2】处将曾经泛型擦除的map传递给底层曾经泛型限定的接口中，置信在接口实现中都是应用“String value = map.get(XXX)”这种形式获取值的，这样一旦map中有非String类型的值，这里就会呈现类型转换异样。读者必定和我一样好奇，为何该业务零碎中未抛出类型转换异样，起因是业务零碎取值的形式并未转换成String类型。可想而知，一但有人应用规范的形式获取值时，就会踩雷。 // 文本1${param1}文本2${param2}文本3${param3}String[] terms = ["文本1"，"$param1", "文本2", "$param2", "文本3", "$param3"];StringBuilder builder = new StringBuilder();for(String term: terms){ if(term.startsWith("$")){ builder.append(map.get(term.substring(1))); }else{ builder.append(term); }}无病呻吟 Config config = new Config();// 设置name和md5config.setName(item.getName());config.setMd5(item.getMd5());// 设置值config.setTypeMap(map);// 打印日志LOGGER.info("update done ({},{}), start replace", getName(), getMd5());......ExpiredConfig expireConfig = ConfigManager.getExpiredConfig();// 为空初始化if (Objects.isNull(expireConfig)) { expireConfig = new ExpiredConfig();}......Map<String, List<TypeItem>> typeMap = ……; Map<String, Map<String, Map<String, List<Map<String, Object>>>>> jsonMap = new HashMap<>();// 循环一级mapjsonMap.forEach((k1, v1) -> { // 循环外面的二级map v1.forEach((k2, v2) -> { // 循环外面的三级map v2.forEach((k3, v3) -> { // 循环最外面的list,哎！ v3.forEach(e -> { // 生成key String ck = getKey(k1, k2, k3); // 为空解决 List<TypeItem> types = typeMap.get(ck); if (CollectionUtils.isEmpty(types)) { types = new ArrayList<>(); typeMap.put(ck, types); } // 设置类型 } } }}代码自身一眼就能看明确是在干什么，写代码的人非要在这个中央加一个不关痛痒的正文，这个正文齐全是口水话，毫无价值可言。 ...

高德地图 API Loca 动画的阐明咱们在应用 Loca 制作地图动画时，外面有几个对应的动画成果，有 center: 平移pitch: 视角zoom: 缩放rotation: 旋转来看一下代码对应的不同动画成果，就很明确的晓得动画是怎么制作的了 具体的例子能够查看这里： https://kylebing.cn/tools/riding-map/Loca 的官网阐明https://lbs.amap.com/api/loca-v2/introcentercenter: { value: POSITION.cityCenter, // 动画起点的经纬度 control: [POSITION.hanyu, POSITION.cityCenter], // 过渡中的轨迹控制点，地图上的经纬度 timing: [0.42, 0, 0.4, 1], // 动画工夫控制点 duration: 2000, // 过渡工夫，毫秒（ms）} pitch// 俯仰角动画pitch: { value: 45, // 动画起点的俯仰角度 control: [[0.3, 20], [0.4, 40]], // 控制器，x是0～1的起始区间，y是pitch值 timing: [0, 0, 1, 1], // 这个值是线性过渡 duration: 5000zoom// 缩放等级动画zoom: { value: 17, // 动画起点的地图缩放等级 control: [[0.4, 18], [0.6, 17]], // 控制器，x是0～1的起始区间，y是zoom值 timing: [0.42, 0, 0.4, 1], duration: 5000,}rotation// 旋转动画rotation: { value: 120, // 动画起点的地图旋转角度 control: [[0.4, 30], [0.6, 120]], // 控制器，x是0～1的起始区间，y是rotation值 timing: [0.42, 0, 0.4, 1], duration: 10000,} ...

1. 概述 地图采集车上有相机、激光、惯导等多种传感器设施，采集的数据为图像、激光点云、轨迹等，生成地图数据的流程中，须要将这些数据关联起来，然而这些设施都是各自独立运行的，而能实现这个工作的就是工夫同步零碎。 工夫同步零碎是以GPS（Global Positioning System，全球定位系统）的工夫信息为根底进行工夫授时的。本文次要讲述工夫零碎中GPS授时原理、授时办法、授时过程以及授时中的异常情况。 2. GPS 授时原理 GPS卫星上搭载有高精度原子钟（铯原子），它可能让各个卫星之间放弃高精度的工夫同步，并且各自的工夫起始时刻也可能对的很准。因为用户接收机与卫星存在钟差，对零点做工夫参考系至多须要四颗卫星能力实现导航定位。 当用户解算出本人和卫星的钟差之后就能够校对本人本地的时钟，将其和卫星精准的时钟同步到同一个时刻，这个过程就叫授时。 原子钟的原理：原子中的电子从一个能级跃迁到另一个能级的时候，频率十分稳固，以此为钟摆就能失去十分精准的工夫。 GPS授时原理是GPS接收机在任意时刻能同时接管其视线范畴内>=4颗卫星信号，经解码和解决后从中提取并输入两种工夫信号： (1)工夫距离为1S的同步脉冲信号PPS（ Pulse Per Second，秒脉冲），其脉冲前沿与国际标准工夫的同步误差<1us. (2)串行口输入的信息是与PPS前沿对应的国际标准工夫和日期，利用最为宽泛的是NMEA-0183协定，如$GPGGA,$GPRMC等。 GPRMC:Recommended Minimum SpeGPS / TRANSIT Data(RMC)举荐定位信息。 协定格局： $GPRMC,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11>*hh<CR><LF> 样例数据： $GPRMC,161229.487,A,3723.2475,N,12158.3416,W,0.13,309.62,120598,*10  3. GPS授时办法 3.1 PPS与NMEA关系 要讲述GPS的授时办法，要先理解PPS与NMEA的关系及作用，如下图所示，在GPS定位的状况下，PPS会先到，NMEA数据后到，然而不同GPS厂商设置的两者之间的工夫距离不尽相同，有的几毫秒，而有的几百毫秒。 PPS与NMEA 黄色：PPS，回升沿为整秒零时刻。 蓝色：NMEA，GPS工夫信息，蕴含年月日、时分秒。 3.2 GPS授时过程详解 GPS授时零碎结构图 如上图所示的GPS授时零碎结构图： (1)GPS接收机在定位的状况下产生输入PPS脉冲信号，以及无效的GPS工夫信息，此信息以串行通信输入，TTL/RS232信号类型，ASCII码，波特率9600bps~460800bps，可配置，遵循的是NMEA-0183协定，此协定的数据信息有十几种之多，而提取GPS工夫信息的语句，通常RMC足以满足要求。 (2)晶振能够为MCU（Microcontroller Unit，微管制单元或者单片机）提供准确的时钟源，维持零碎运行，受环境影响较大，特地是温度变动。可选用OCXO—恒温晶振，温度个性达到3ppb。 (3)具体的做法如下： 通过提取RMC中的GPS工夫信息，失去时分秒、年月日，并赋值给以晶振为时钟源的零碎工夫，使MCU的零碎工夫校对为UTC工夫。MCU利用IO的中断机制失去PPS的脉冲时刻，以此为根底将毫秒及以下工夫清零，从而校对零碎工夫的整秒零时刻。Check工夫，等3秒后，再取GPS工夫与零碎工夫比照，是否吻合，验证PPS授时整秒时可能呈现的+1秒或-1秒的状况。 如上图所示，是授时后测试的数据样例。利用GPS接收机的EVENT性能和MCU同时记录同一个信号脉冲，而后做工夫比照，测试的路段有高架桥、商场、环线、街道等多场景。测试时长为5小时38分钟，比照后果为：秒差值=0，微秒差值<=4us。 3.3 工夫同步零碎的利用之相机同步 图像数据起源是采集车上的传感器——相机，咱们的采集车上装置有多个相机，散布在车顶平台的不同地位，朝向各个方向，采集路线标识、POI等，这些图像信息要与地位轨迹信息匹配能力作为地图数据，工夫同步零碎就能够将这些数据进行惟一匹配。 工夫同步零碎之相机工夫同步结构图 如上图所示，工夫同步零碎的利用之一相机工夫同步结构图，在工夫零碎已授时的状况下，简略讲述相机工夫同步办法： (1)相机工作在外触发模式，MCU提供触发源，也就是脉冲信号，并记录脉冲序号。 (2)相机拍照时，曝光时刻会产生脉冲对外输入，由MCU捕捉，并记录此时刻工夫及序号。 (3)记录的工夫信息及序号会存储起来，照片的存储会一一对应序号，工夫信息也能够与地位轨迹匹配起来，这样就实现了照片与地位的关联。 4. GPS授时异样解决 下面介绍了GPS的授时原理、办法及过程，即可实现工夫的授时，然而理论的利用情景是简单且随机的，因为GPS接收机从失锁到定位的过程不是固定的工夫，设施、环境因素都有影响。以晶振为时钟源的MCU的零碎工夫在授时之前是自在运行状态。这些因素都对GPS授时带了未知的状况，在此列举一些异常情况； 4.1 PPS与晶振 如上图所示，PPS与晶振时钟的对齐存在三种状况： (1)PPS回升沿与晶振时钟对齐，此为现实状态，是晶振经分频、倍频后为MCU零碎工夫提供了完满的1秒时长，但这种状况简直不存在。 (2)MCU的零碎时长慢于1秒，PPS到来进入下1秒，而零碎工夫还未完结以后秒，此时要做非凡解决，提前结束零碎工夫的整秒，立刻进入下1秒的零时刻，工夫信息的秒及以上单位对应“+1”。 (3)MCU的零碎时长快于1秒，在PPS到来之前，零碎工夫曾经进入下1秒，并运行一段时长，此时要将零碎工夫从新归到此秒的零时刻，工夫信息的秒无需“+1”或者“-1”。 4.2 PPS与GPS工夫信息 ...

1. 前言 高精地图（High Definition Map）作为主动驾驶安全性不可或缺的一部分，能无效强化主动驾驶的感知能力和决策能力，晋升主动驾驶的等级。对于主动驾驶来说，高精地图次要是给机器用的，然而在制作和剖析过程中仍然须要人可能了解。本文将为大家简略介绍下，在过来的一段时间里高德高精地图业务团队，在WEB三维引擎技术方面的一些摸索和实际，如何让简单形象的天文数据出现在人们背后，满足其业务编辑和剖析的诉求。 高精地图次要是对道路交通层对象（如：车道高空标线、交通灯、交通牌、防护栏、杆等）的精细化表白，蕴含其几何地位和属性。因为对精度要求极高，它的制作次要还是依赖激光点云，通常都是海量的数据，一个路口的点云量就可能上亿，这就对渲染引擎的性能有较高要求，要满足对海量点云实时渲染和拾取编辑。 起初，咱们调研了市面上支流的Web三维地图引擎：Mapbox、Cesium、JS API、L7等，它们广泛对点云的加载解决能力反对不够，偏差于对形象的点、线、面表白，精细化渲染能力有余，同时也满足不了作为编辑工具对简单Topo关联关系的编辑能力。对于高德高精数据编辑剖析的业务场景，须要更多的底层形象能力建设。于是，咱们在高精业务中开启了三维引擎eagle.gl的摸索实际之路。 先通过一个视频简略理解下目前高德三维引擎eagle.gl的能力，它实现了一套2/3D对立的地图数据编辑和可视化解决方案，具备很好的可扩大能力，目前已利用在高德高精地图数据生产、数据分析、以及新基建我的项目等业务。 2. 引擎方案设计实现 基于下面的剖析，咱们须要实现一套满足高德业务场景需要的数据制作引擎能力。为了不反复造轮子，最大水平利用已有的开源能力，咱们最终选用Threejs当作渲染层框架依赖。基于该框架，在下层构建GIS可视化和简单编辑能力，最终实现构建一套2/3D一体化渲染引擎。同时面向未来智慧城市、5G IOT方向，构建数据团队面向业界看齐的GIS 3D可视化能力。 Figure 2.1 面向高精地图的2/3D一体化数字引擎 整个引擎工作能够拆分为三个局部（点云地图、矢量地图、模型地图），前端团队整体工作须要围绕这三个点去开展。 点云地图：对接多种点云材料格局的可视化(las/laz/bc/xbc/rds/bin)，反对海量点云的实时渲染和编辑，满足主产线对点云材料的作业吸附能力。矢量地图：次要对接在线生产产线矢量化成图能力，通过数据快照、命令行编辑模式、空间数据索引等能力实现矢量化3D数据的增删改查能力。模型地图：次要面向数据成绩应用层，进行数据预处理建模、实时建模编辑等，实现数据能力与高德客户端车道级渲染能力拉齐。3. 技术解题 上面简略介绍一下各个外围模块能力。 3.1 全幅面精细化渲染 高精数据有着更准确更丰盛的信息，反对更精密的数据渲染，更好地还原真实世界。 Figure3.1.1 全幅面精细化渲染 高精原始的产出数据是矢量化骨架数据，这一层数据是真实世界的数字化的点线面形象，怎么依据原始的矢量数据进行模型化渲染展现呢？原始矢量数据是面向主动驾驶等机器应用，为了可能更好的核实数据品质，进行数据问题考察剖析，咱们须要把点线面矢量数据进行建模渲染，达到最终模型化精细化渲染成果，不便人工进行疾速的问题核实。 Figure3.1.2 原始的矢量化数据成绩 Figure3.1.3 端上实时数据建模精细化渲染成绩 为了反对精细化的渲染成果，eagle.gl引擎目前反对罕用的点、线、面、体、文本、模型等多种可视化图层，并且通过配置化的形式实现了数据渲染实现。 整个建模渲染分为以下外围模块流程, 主体流程是原始点线面矢量数据拉取，依据规定进行数据解析，数据建模解决，数据合并和Instance解决，数据渲染。其中工作量最大的局部在于数据预建模解决，因为原始数据的表白更加形象，为了更加实在的还原世界，须要做很多的逻辑计算，例如斑马线/导流带数据表述中只有外边的边框轮廓，为了渲染的更实在，须要依据数据的长短边规格和交通路网标准，进行过程中实时建模生成。 Figure3.1.4 端上渲染建模外围流程 Figure.3.1.5 斑马线原始几何 Figure.3.1.6 斑马线建模后几何 通过同样的解决形式，咱们就可能实现数百种高精数据定制化建模能力。然而好几百种数据规格如果通过硬编码的模式进行建模会导致整个代码构造的腐化和不可保护。因而咱们在引擎层实现数据配置驱动地图图面款式展示的能力。 Figure.3.1.7 多种高精数据建模成绩表白 对于style的定义咱们辨别为两种类型，一种是根本的feature因素对应的展示行为，这层style目前定义为动态的style配置；另外一种style是tile数据源驱动的styleSchema，这种style会定义动静的属性以及空间场景、灯光等共有属性定义。 根底因素层对应的style咱们次要分为以下几个类型： IBaseStyle | ILineStyle | ITextStyle | IPointStyl | IPolygonStyle | IModelStyle | ICustomStyle 举个例子，咱们用模型款式类ModelStyle，新增模型的款式定义，继承自IBaseStyle。 mapView.addDataLayer({ id: 'model', // 图层id，id为惟一标识，不能反复 style: { type: 'model', resources: { type: 'gltf', base: '//cn-zhangjiakou-d.oss.aliyun-inc.com/fe-zone-daily/eagle.gl/examples/assets/theme/default/model/', files: ['ludeng_0.glb'], }, translate: [0, 0, 0], }, features: [ { geometry: { type: 'Point', coordinates: [[116.46809296274459, 39.991664844795196, 0]], }, }, ],});属性 ...

高德开放平台公开课来啦，大量技术干货强势来袭～ 精彩主题领先看：自定义地图与个性化展现，地图空间搜寻，猎鹰轨迹服务，导航原理及利用... 6月首期公开课将于6月23日晚7点在高德开放平台钉钉群（钉钉扫描海报里的二维码或者搜寻钉群号：31886791）中与大家见面！ 更有收费调用量等福利等你入群来拿哦！快来参加吧！

1. 什么是高精数据散发引擎 1.1 高精地图概述 高精地图(High Definitation Map,HD MAP)，和一般导航电子地图的次要区别是精度更高、信息更丰盛。精度更高次要体现在高精地图的相对坐标精度更高(指的是地图上某个指标和内部的真实世界事物所在位置之间的精度)，能够准确到厘米级别；信息更丰盛次要体现在高精地图不仅蕴含了路线信息，还涵盖了简直所有与交通相干的四周动态信息。 相比于一般导航电子地图，高精度地图所蕴含的道路交通信息更丰盛和精确。除此以外，在利用场景方面，一般导航地图次要供驾驶员应用，而高精度地图是面向机器的、供主动驾驶汽车应用的地图。 精度是高精度地图与一般导航电子地图的最大区别。一般车载电子导航地图的精度个别在10米左右，高精度地图利用在主动驾驶畛域，须要精确定位到具体某条车道上，还须要晓得四周所有可能参加主动驾驶决策的路线和交通信息，精度须要达到10~20厘米，这样的精度基本上和一个车道边线的宽度差不多，能力保障智能驾驶的汽车不会逾越到其余车道，防止与其余车辆产生侧面碰撞的危险。 一般导航电子地图要描绘出路线（link），而高精度地图不仅要描述路线，还会描绘出一条路线上有多少条车道（lane），实在地反映出路线的理论款式。 高精度地图信息更丰盛次要体现在以下几个方面： 精确的路线形态：每条车道的坡度、曲率、航向、高程，侧倾的数据。 具体的车道线信息：车道之间的车道线是虚线、实线还是双黄线，线的色彩，路线隔离带，隔离带的材质都会有形容。 此外，人行横道，路线沿线看板，限速标记，红绿灯，路边电话亭等等，这类通常统称为LandMark Object的相对地理坐标，物理尺寸以及他们的特质个性等也都会呈现在高精度数据中。 1.2 高精数据散发引擎 ADAS(Advanced Driver Assistant System,高级驾驶辅助零碎)利用须要用车辆后方路网及属性数据信息用于决策控制及判断，一般数字地图数据通常仅供导航系统应用，但高精地图数据可供车辆内的其余ADAS利用应用，因而须要依赖高精数据及用于高精数据播发的高精数据散发引擎。 ADASIS(ADAS接口标准)定义了“ADAS电子地平线”的概念，“ADAS电子地平线”表白了车辆后方的路网及路网属性信息。为了实现这种表达方式，咱们须要构建车辆的地位模型以及车辆后方路网的各个可能行驶的路线模型，能够通过一个树状的层次结构来表白可通行的路线。此外，路线的几何形态及相干属性也会建设相干的属性模型来表白。“ADAS电子地平线”数据通过车载以太网络来序列化及传输。 1.3 名词解释 ADAS(Advanced DriverAssistance System) 即高级驾驶辅助零碎，利用车载传感器感知车辆环境，并交融计算，事后让驾驶者觉察可能产生的危险，无效晋升车辆驾驶的安全性、经济性和舒适性。 ADASIS(Advanced DriverAssistance System Interface Specification) ADAS论坛制订的行业国际标准，用于标准地图数据和车辆ADAS利用之间替换地图数据的规范接口协议。 AHP(ADAS Horizon Provider) 即高精数据散发引擎，为ADAS利用提供超视距的后方路线和数据信息。 AHR(ADAS Horizon Reconstructor) 用于解析AHP收回的音讯并重建地图数据，供终端ADAS利用模块应用。 2. 为什么须要高精数据的散发引擎 高精数据散发引擎作为高精数据及ADAS利用的桥梁，其价值总结下来有以下几个方面： 主动驾驶近程视距的须要，高精地图作为主动驾驶的地图传感器，能够提供更牢靠的超视距范畴，反对更牢靠的决策判断。精度进步的须要，由导人到导车的转变使得对精度要求进步了。高精地图数据散发的接口标准化。3. 高精数据散发引擎的建设 3.1 高精数据散发引擎与ADAS利用的关系 数据散发引擎波及到以下几个局部组成及交互： AHPAHRADASIS V3 ProtocolADAS利用，详见上图的终端利用部3.2 高精数据散发引擎架构 高精数据散发引擎由多个层级组成，包含引擎层、协定组织层、零碎适配层，相干的平台及工具撑持如下图所示： 引擎层：高精数据的加载，解析及车道路网数据的组织。协定层：次要将引擎层提供的数据组装协定音讯，并向适配层传递散发。适配层：次要负责和零碎对接及交互，并将组织的协定数据分发给ADAS利用。3.4 高精数据散发引擎的模型表白 3.4.1 路网模型的形象及表白 数据散发引擎的路网模型蕴含三层的模型形象，首先经由事实世界模型形象成高精路网模型，再由高精路网模型进一步组织及划分形象为Path及Offset表白的树状模型。 事实世界的形象模型的表白 数字化地图模型及用户设置的导航门路，地图因素的表白 在数据化地图模型的车辆地位及路网表白 在车辆地位左近的路网模型通过links来表白路网之间的连贯关系。在数字地图数据库中，道路网示意为一组连贯和定义链接之间的节点组成。 从ADAS利用角度来看，对车辆前方的路网并不关怀，因而数据散发引擎由车辆后方的路网组成。 将车辆后方路网按Path来组织，每个Path是一组link的汇合。车后方的路网数据能够通过两种算法来表白。简略Path形式，从车所在link开始，每个能够通行的门路都独立表白为Path. ...

1、一般maker创立，而后增加到地图上，页面会呈现卡顿，甚至有可能卡死，页面解体。。。 async initMark() { var map = this.map this.removeMarkers() this.map.setZoom(7) this.map.setCenter([108.907295, 35.601474]) this.infoWindow = new AMap.InfoWindow({ offset: new AMap.Pixel(-3, -16) }) let infoWindow = this.infoWindow let list = this.list let category = this.mapDataType ? '' : this.category for (var i = 0; i < list.length; i++) { let iconType = list[i] && list[i].index ? list[i].index.split('_data')[0] : '' let icon = iconType ? this.newIcon(iconType) : this.icon let lon = list[i].lon || list[i].end_lon let lat = list[i].lat || list[i].end_lat // console.log(i, lon, lat) if (lon && lat) { let marker = new AMap.Marker({ position: [lon, lat], data: list[i], map: map, offset: new AMap.Pixel(-11, -11), icon: icon }) let that = this marker.on('click', function(e) { let myRow = '' let showItem = [] let shwoTitlekey = '' let data =e.target.w.data || e.target.Ce.data let trueKey = data && data.index ? data.index.split('_data')[0] : '' if (data.index) { shwoTitlekey = getKeyByCategory(trueKey).nameKey detailByIndexAndIdApi({ index: data.index, id: data.id }).then( res => { data = res.data showItem = formItem[trueKey] myRow = '<div class="info_title">' + data[shwoTitlekey] + '</div>' if (showItem && showItem.length) { for (let i = 0; i < showItem.length; i++) { if (showItem[i].type === 'objArray') { let val = '' for (let j = 0; j < showItem[i].name.length; j++) { val += data[showItem[i].name[j].value] + showItem[i].name[j].label } myRow += '<div class="info_row"><span class="info_lable">' + showItem[i].label + '：</span>' + val + '</div>' } else if (showItem[i].type === 'array') { let val = '' for (let j = 0; j < showItem[i].name.length; j++) { if (data[showItem[i].name[j]]) { val += j > 0 ? '、' + data[showItem[i].name[j]] : data[showItem[i].name[j]] } } myRow += '<div class="info_row"><span class="info_lable">' + showItem[i].label + '：</span>' + val + '</div>' } else { let currentVal = data[showItem[i].name] ? data[showItem[i].name] : '无' myRow += '<div class="info_row"><span class="info_lable">' + showItem[i].label + '：</span>' + currentVal + '</div>' } } } let html = myRow infoWindow.setContent(html) infoWindow.open(map, e.target.getPosition()) } ) } }) } // marker.emit('click', { target: marker }) }}2、 通过new AMap.MassMarks实现，页面能够很好的渲染，不会呈现卡死。 ...

导读 高德启动Serverless建设曾经有段时间了，目前高德Serverless业务的峰值早已超过十万QPS量级，平台从0到1，QPS从零到超过十万，成为阿里团体内Serverless利用落地规模最大的BU。这个过程如何实现，遇到过哪些问题？本文将和大家分享高德为何要搞Serverless/Faas，如何做，技术计划是什么？目前停顿以及后续打算有哪些，心愿对感兴趣的同学有所帮忙。 1. 高德为什么要搞Serverless 背景起因是高德当年启动了一个客户端上云我的项目，我的项目次要目标是为了晋升客户端的开发迭代效率。以前客户端业务逻辑都在端上，产品需要的变更须要走客户端发版能力公布，而客户端发版须要走各种测试流程，灰度流程，解客户端解体等问题。 客户端上云之后，某些易变的业务逻辑放到云上来。新的产品需要通过在云端来开发，不必走月度的版本公布，放慢了需要的开发迭代效率，离产研同频的现实指标又近了一步（为什么要说“又”，是因为高德之前也做了一些优化往产研同频的方向致力，然而咱们心愿云端一体化开发能是其中最无效的一个技术助力）。 1.1 指标：客户端开发模式——端云一体 尽管开发模式从以前的端开发转变为当初的云 + 端开发，开发同学应该还是原来负责相应业务的同学，而大家晓得，服务端开发和客户端开发显然是有差别的，客户端开发往往是面向单机模式的开发，服务端开发通常是集群模式，须要思考分布式系统的协调、负载平衡，故障转移降级等各种简单问题。 如果应用传统的服务端模式来开发，这个过渡危险就会比拟大。Faas很好的解决了这一问题。咱们联合高德客户端现有的xbus框架(一套客户端上的本地服务注册、调用的框架)，扩大了xbus-cloud组件，使得云上的开发就像端上开发一样，指标是一套代码，两地运行，一套业务代码既能在客户端上运行，也能在服务端上运行。 高德客户端次要有三个端：iOS、Android、车机（类Linux操作系统）。次要有两种语言，C++和Node.js。传统地图功能：如地图显示，导航门路显示，导航播报等等，因为须要跨三个端，采纳C++语言来开发。地图导航根底之上的一些地图利用性能，如行前、行后卡片，举荐目的地等次要是用Node.js来开发的。 在阿里团体，淘系前端团队开发了Node.js Faas Runtime。高德客户端上云我的项目，Node.js的局部就采纳了现有的淘系的Node.js Runtime，来接入团体的Faas平台，实现Node.js这部分的一些业务上云。2020年十一很好的撑持了高德的十一出行节业务。 C++ Faas没有现有的解决方案，因而咱们决定在团体的基础设施之上做加法，新建C++ Faas根底平台，来助力高德客户端上云。 1.1.1 端云一体的最佳实际要害：客户端和Faas之间的接口形象 本来客户端的逻辑移到Faas服务端上来，或者新的需要一部分在Faas服务端上开发，这里的成败关键点在于：客户端和Faas的接口协议定义，也就是Faas的API定义。好的API定义除了对系统的可维护性有益处以外，对后续撑持业务的迭代开发也很重要。 现实状况下：客户端做成一个解析Faas返回后果数据的一个浏览器。浏览器协定一旦定义好，就不会常常变换，你看IE，Chrome就很少更新。 当然咱们的这个浏览器会简单一些，咱们这个浏览器是地图浏览器。如何测验客户端和Faas之间的接口定义好不好，能够看后续的产品需要迭代，如果有些产品需要迭代只须要在Faas上实现，不须要客户端的任何批改，那么这个接口形象就是胜利的。 1.2 BFF层开发提效 提到高德，大家首先想到的应该是其工具属性：高德是一个导航工具，（这个说法当初曾经不太精确了，因为高德这几年在做工具化往平台化转型，高德的交易类业务正在衰亡，高德打车、门票、酒店等业务倒退十分迅猛）。针对高德导航来说，相比团体其余业务，相比电商来说，有大量的只读场景是高德业务的一大技术特点。 这些只读场景里，大量的需要是BFF（Backend For Frontend）类型的只读场景。为什么这么说，因为导航的最外围性能，例如routing, traffic, eta等都是绝对稳固的，这部分的次要工作在用继续一直的优化算法，使得高德的导航更准，算出的门路更优。这些外围性能在接口和性能上都是绝对比较稳定的，而前端需要是多变的，例如减少个门路上的限宽墩提醒等。 Faas特地适宜做BFF层开发，在Faas上调用后端绝对稳固的各个Baas服务，Faas服务来做数据和调用逻辑封装，疾速开发、公布。在业界，Faas用的最多的场景也正是BFF场景（另外一个叫法是SFF场景，service for frontend）。 1.3 Serverless是云时代的高级语言 尽管高德曾经全面上云了，然而目前还不是云时代的终局，目前次要是全面Docker化并上云，容器方面做了标准化，在规模化，资源利用率方面能够全面享受云的红利，然而业务开发模式上根本还和以前一样，还是一个大型的分布式系统的写法。 对于研发模式来说还并没有享受云的红利，能够类比为咱们当初是在用汇编语言的形式来写跑在云上的服务。而Serverless、云原生能够了解为云时代的高级语言，真正做到了Cloud as a computer，只须要关注于业务开发，不须要思考大型分布式系统的各种复杂性。 1.4 Go-Faas补充Go语言生态 后面讲到了因为客户端上云我的项目，咱们在阿里云FC（函数计算）团队之上做加法，开发了C++ Faas Runtime。 不仅如此，咱们还开发了Go-Faas，为什么会做Go-Faas呢，这里也简略介绍一下背景，高德服务端Go局部的QPS峰值已超百万。高德已补齐了阿里各中间件的Go客户端，和团体中间件部门共建。可观测性、自动化测试体系也根本欠缺，目前Go生态已根本欠缺。补齐了Go-Faas之后，咱们就既能用Go写Baas服务，又能用Go写Faas服务了，在不同的业务场景采纳不同的服务实现形式，Go-Faas次要利用于上文提到的BFF场景。 2. 技术计划介绍——在团体现有基础设施之上做加法 2.1 整体技术架构 上文讲了咱们为什么要做这个事件，当初来讲一下咱们具体是怎么做这个事件：如何实现，具体的技术计划是什么样的。 咱们本着在团体现有的基础设施、现有的中间件根底之上做加法的思维，咱们和CSE，阿里云FC函数计算团队单干共建，开发了C++ Faas Runtime 和 Go Faas Runtime。整体和团体拉通的技术架构如下图所示，次要分为研发态、运行态、运维态三个局部。 2.1.1 运行态 先说运行态，业务流量从网关进来，调用到FC API Server，转发到C++/Go Faas Runtime，Runtime来实现用户函数里的性能。Runtime的架构下一章节来具体介绍。 ...

简介： 互联网工程的高速倒退，分布式、微服务、容器化架构的风行，互联网已全面进入云原生时代。构建零碎的形式由最后的单体大利用演变为分布式架构，一台服务器可能仅存几小时甚至几分钟，这种复杂性大大增加了把零碎运行状态可视化的难度。 作者 | 京廊起源 | 阿里技术公众号 一 写在后面互联网工程的高速倒退，分布式、微服务、容器化架构的风行，互联网已全面进入云原生时代。构建零碎的形式由最后的单体大利用演变为分布式架构，一台服务器可能仅存几小时甚至几分钟，这种复杂性大大增加了把零碎运行状态可视化的难度。 高德打车业务的倒退历程也不例外，同样经验了从单体大利用到服务化拆分的过程，宏大的利用体系和架构的一直降级，保障了多个节假日出行顶峰的稳固，业务仍在继续疾速的倒退中，如何保障这套宏大又简单的零碎继续高性能、高可用、高可控？构建360度无死角的多维度可观测能力显得愈发重要。 二 谈零碎可观测性1 什么是零碎可观测性 可观测性(observerbality)，是一个最近几年开始在监控社区流行起来的术语，可观测性的提出最早来自于 Google 驰名的 SRE 体系和 Apple 工程师 Cindy Sridharan 的博文《Monitoring and Oberservability》，感兴趣的同学能够看一下。 可观测性不是一种具体的工具或技术，更偏差于是一种理念，目前已成为简单分布式系统胜利治理的要害组成部分，它是指运行中的零碎可被调试的能力，这种可调试能力的外围就是可能在零碎运行时对其了解、询问、探查和调度。 了解，询问，探查体现在帮忙工程师发现问题 -> 定位问题 -> 解决问题(止损)，调度体现在可依据零碎运行状态做出的自动化，智能化决策的能力。 可观测性的指标是加强工程师对系统运行状况的理解，加强对系统的信念。 目前，业界宽泛推广的可观测性蕴含三大支柱：日志事件(Logging)，分布式链路追踪(Tracing) 和 指标监控(Metrics）。 Logging：不能单纯的了解就是日志，泛指的是利用运行而产生的能够具体解释零碎运行状态的各种事件，日志记录是其中最罕用一种伎俩。Tracing：全链路追踪，面向的是申请，通过对申请打标、透传、串联，最终能够还原出一次残缺的申请，可帮忙工程师剖析出申请中的各种异样点。Metrics：是对Logging事件的聚合，泛指各种指标监控和大盘，通过多维度聚合、剖析和可视化展现，帮忙工程师疾速了解零碎的运行状态。 2 可观测性与监控的关系 可观测性 != 监控 第一印象很容易把“可观测性”认为就是“监控”，人类个别偏向于用之前的认知来了解一些新概念，其实两者是不一样的。 监控是机器代替人工，长期的察看零碎的行为和输入，帮忙团队察看和理解其零碎状态的工具或技术解决方案。监控与可观测性的区别如下： 关注点不同 监控更多关注的是具体指标的变动和报警，关注零碎的失败因素，多与运维相干，强调从外到内，从内部通过各种技术手段去看到外部，关注的是点。而可观测性关注的是利用自身的状态，是对系统的一种自我扫视，强调从内到外，站在宏观的角度去聚合剖析各种指标，不仅理解分布式系统所有链路的运行状况，还能在多指标同时产生问题时晓得什么是因，什么是果，让工程师“了解”零碎产生的所有行为，关注的是点线面的联合。 关注工夫不同 监控更加重视问题的发现与预警，关注软件交付过程中以及交付后的1到2天，也就是咱们常说的“事中与预先”。而“可观测性”是要对一个简单分布式系统所产生的所有行为给出正当解释，关注的是研发与运维的全生命周期。 目标不同 监控是通知咱们零碎在什么工夫、什么中央、产生了什么问题，仅提供对已知问题或故障的答案。而可观测性是为了通知咱们那里为什么产生了问题，还容许工程师提出新问题。具备可观测性的零碎，工程师既能够直观的察看到零碎的整体运行状态，又能够轻易深刻到零碎运行的各个细节角落。在失常运行时，能对系统进行评估，提供操作倡议，在产生故障时，可帮助工程师疾速了解、定位和修复问题。 监控与可观测性又是相辅相成的，监控是可观测性的一项基础设施和伎俩，监控是可观测性的子集，形象如下图： 三 咱们做了什么分享下高德打车在摸索可观测性零碎建设过程中的一些具体实际，交流学习。 1 对立日志 首先对日志进行了对立治理，日志事件(Logging)是可观测性的三大支柱之一，当利用数上百，微服务数上千时，各利用的日志还任由开发人员依据本人爱好得心应手的打，可能会造成一场噩梦。例如形形色色的格局、级别、分类，甚至于error和info都混淆在一起。咱们将日志对立归为三类：监控日志，业务日志，谬误日志，并封装提供专门的日志sdk，将“无效”的日志进行对立管控，还能间接达到管制老本的目标。 监控日志 监控日志只用来做监控，和其余日志进行辨别，输入到一个独自的滚动文件里。 监控的准则是用来发现问题，而不是用来定位问题，要定位具体的问题，须要更具体的日志，通过监控日志中的traceId去关联其余内容即可。 监控日志对立以monitor结尾，业务较多时，也可分多个，如monitor-biz1.log, monitor-biz2.log。监控日志分隔符固定用竖线 | , 监控指标成功失败对立归类为 success，fail (业务失败)，error (接口失败)。耗时逻辑对立在sdk中实现，删除原代码中遍地存在的 long start=System.currentTimeMillis()。 ...

引言 “一图胜千言”，大数据时代降临，数据与人们生存密切相关。简单难懂且体量宏大的数据给人的感觉总是凉飕飕的，让人难以获取到重点信息，也找不出法则和特色，数据价值施展不进去。空间数据可视化就是为了解决这些问题，用通俗易懂的图形符号还原数据，表白多纬度数据信息，让你的数据“活”起来！ 高德 LOCA 数据可视化旨在为各畛域企业和集体提供便捷高效的可视化利用技术，提供基于 WebGL 和高德 JSAPI 的大规模天文数据可视化开发框架，利用于天文空间数据的可视化畛域。与高德动态底图联合，深度定制，领有丰盛的可视化类型，将高性能海量数据渲染能力、丰盛的案例场景、酷炫表白以简略易用的形式提供给用户，让人人都能玩转酷炫的天文数据可视化。 一句话概括，你能够轻轻松松把一堆枯燥无味的数据通过酷炫的形式展现到地图上，并棘手生成那个牛气哄哄的可视化计划！ LOCA数据可视化API 2.0全新降级 LOCA2.0不仅具备简略易用的 API 文档，丰盛的场景案例灵便抉择。还降级了90余种图层能力其中包含数据交互性能及点、线、面、蜂窝、热力等动画反对，让数据鲜活有温度、易了解、可交互。技术上使用全新的渲染管线和架构模式，极大晋升了数据处理能力和数据渲染能力。 LOCA 2.0新个性 视觉&动效 1.用这些配色既难看，又能传递数据语义 LOCA 的根底配色，联合数据关联关系、散布趋势、特色属性等特点，精细化配置色彩在数据维度上的掂量和心理感知。所有案例均应用辨识度高、精确、可信的配色策略，包含：分类色、单双相间断色、发散色、语义色。通过色彩的视觉通道来了解和观测数据，用户可依据 LOCA 案例场景取对应配色计划应用，后续将提供浅色地图的可视化配色主题。 2.简略易懂的图形符号，让你做出人人都懂的可视化 在实现可视化映射时，LOCA 采纳图形易变量的思路，定义了视觉变量的品种：形态、尺寸、方向、色彩，将数据点映射到图形时，基于数据的类别、程序和数值个性，匹配适合的视觉图形。如图所示，LOCA 所应用的视觉变量及可视化编码。 3.高度自定义镜头，反对多数据场景切换 高度自定义的镜头。在地图场景中如何使用镜头语言来展示信息内容尤为重要，因而咱们提供了 Pitch、Zoom、Rotation、Center 四个镜头相干变量，自定义轨迹动画曲线缓入、缓出等，实现对镜头参数顺心所欲的管制。 4.平滑天然的动画成果，让数据转场不再突兀 更多图层因素动效。反对三十多种动画线，高度、半径、透明度、海拔等属性都领有动画过渡特效，解决图层呈现隐没时的突兀问题，让数据之间的转场过渡平滑天然。 5.多光源散布，加强场景视效 一个场景反对多点布光。多种光照类型，多光源散布，可管制光照强度、范畴、色彩、地位等，通过参数管制光照随工夫的转场成果，减少场景光照明暗的视觉档次。 6.表白AB点脉冲和轨迹动画成果，让数据鲜活起来 PulseLine 轨迹线反对脉冲成果，脉冲可管制数量、动画时长、线段宽度等，动画方向和速率均可传递数据意义，例速度快则数据线路忙碌，慢则反之。Scatter 图层反对图标动效绘制。 图层能力&渲染性能 1.三维空间高度线和楼层能力，还原实在空间数据成果 三维空间反对。线图、热力求、网格图、蜂窝图等都已反对天文单位（米）的设置，并且对于线数据图层可设置每一个节点的海拔高度，定义节点之间不同的垂直距离。三维高度面能力，还原理论楼层高度及外部结构，可灵便设置单个楼层和外部面的厚度、透明度和色彩等属性。 2.个性化定制独特的图形，让可视化成果丰盛多样 数据驱动的自定义视觉变量管制。款式字段反对对图层中单个数据进行函数回调，能够针对每一个数据设置独特的图形符号，灵便的配置图形符号半径、透明度、透明度等属性。 3.数据渲染可达百万级，效率晋升近10倍 通过全新的架构渲染管线，优化数据处理和款式解析过程，充分发挥 WebGL 的渲染性能，冲破 LOCA 1.3 大数据量渲染的瓶颈，数据响应速度快可轻松解决大规模数据集。 4.反对多图层任意组合，大小场景实时观测 在业务场景中，通常观测宏观趋势时也心愿能够看到宏观场景下数据分布和数值，辅助数据分析及决策。LOCA 提供双图层交融能力，可对单个图层自定义色彩、尺寸、款式和组合过渡成果。以 3D 热图结合点图层为例，通过镜头管制地图逐级下钻，满足从全局到部分可视的读取数据的需要。 5.数据精准拾取，满足简单场景的展现和交互 反对图面海量因素的疾速获取，细颗粒度管制因素的自定义款式和独立渲染，鼠标滑过元素即高亮反馈并透出数据信息，点、线、面、体最小像素选中后数据精准透出，来满足简单场景的展现和交互。 LOCA 业务场景利用 ...

简介： 订单状态流转是交易系统的最为外围的工作，订单零碎往往都会存在状态多、链路长、逻辑简单的特点，还存在多场景、多类型、多业务维度等业务个性。在保障订单状态流转稳定性的前提下、可扩展性和可维护性是咱们须要重点关注和解决的问题。 作者 | 亮言起源 | 阿里技术公众号 一 背景 订单状态流转是交易系统的最为外围的工作，订单零碎往往都会存在状态多、链路长、逻辑简单的特点，还存在多场景、多类型、多业务维度等业务个性。在保障订单状态流转稳定性的前提下、可扩展性和可维护性是咱们须要重点关注和解决的问题。 以高德打车业务的订单状态为例，订单状态就有乘客下单、司机接单、司机已达到乘车点、开始行程、行程完结、确认费用、领取胜利、订单勾销、订单敞开等；订单车型有专车、慢车、出租车等几种车型，而专车又分舒适型、豪华型、商务型等；业务场景接送机、企业用车、城际拼车等等场景。 当订单状态、类型、场景、以及其余一些维度组合时，每一种组合都可能会有不同的解决逻辑、也可能会存在共性的业务逻辑，这种状况下代码中各种if-else必定是不敢设想的。怎么解决这种"多状态+多类型+多场景+多维度"的简单订单状态流转业务，又要保障整个零碎的可扩展性和可维护性，本文的解决思路和计划同大家一起探讨。 二 实现计划 要解决"多状态+多类型+多场景+多维度"的简单订单状态流转业务，咱们从纵向和横向两个维度进行设计。纵向次要从业务隔离和流程编排的角度登程解决问题、而横向次要从逻辑复用和业务扩大的角度解决问题。 1 纵向解决业务隔离和流程编排状态模式的利用 通常咱们解决一个多状态或者多维度的业务逻辑，都会采纳状态模式或者策略模式来解决，咱们这里不探讨两种设计模式的异同，其外围其实能够概括为一个词"分而治之"，形象一个根底逻辑接口、每一个状态或者类型都实现该接口，业务解决时依据不同的状态或者类型调用对应的业务实现，以达到逻辑互相独立互不烦扰、代码隔离的目标。 这不仅仅是从可扩展性和可维护性的角度登程，其实咱们做架构做稳定性、隔离是一种缩小影响面的根本伎俩，相似的隔离环境做灰度、分批公布等，这里不做扩大。 /** * 状态机处理器接口 */public interface StateProcessor { /** * 执行状态迁徙的入口 */ void action(StateContext context) throws Exception;}/** * 状态A对应的状态处理器 */public class StateAProcessor interface StateProcessor { /** * 执行状态迁徙的入口 */ @Override public void action(StateContext context) throws Exception { }}繁多状态或类型能够通过下面的办法解决，那么"多状态+多类型+多场景+多维度"这种组合业务呢，当然也能够采纳这种模式或思路来解决。首先在开发阶段通过一个注解@OrderPorcessor将不同的维度予以组合、开发出多个对应的具体实现类，在零碎运行阶段，通过判断上下文来动静抉择具体应用哪一个实现类执行。@OrderPorcessor中别离定义state代表以后处理器要解决的状态，bizCode和sceneId别离代表业务类型和场景，这两个字段留给业务进行扩大，比方能够用bizCode代表产品或订单类型、sceneId代表业务状态或起源场景等等，如果要扩大多个维度的组合、也能够用多个维度拼接后的字符串赋值到bizCode和sceneId上。 受限于Java枚举不能继承的标准，如果要开发通用的性能、注解中就不能应用枚举、所以此处只好应用String。 /** * 状态机引擎的处理器注解标识 */@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@Componentpublic @interface OrderProcessor { /** * 指定状态，state不能同时存在 */ String[] state() default {}; /** * 业务 */ String[] bizCode() default {}; /** * 场景 */ String[] sceneId() default {};}/** * 创立订单状态对应的状态处理器 */@OrderProcessor(state = "INIT", bizCode = {"CHEAP","POPULAR"}, sceneId = "H5")public class StateCreateProcessor interface StateProcessor {}再想一下，因为波及到状态流转，不可能会是一个状态A只能流转到状态B、状态A可能在不同的场景下流转到状态B、状态C、状态D；还有尽管都是由状态A流转到状态B、然而不同的场景解决流程也可能不一样，比方都是将订单从从待领取状态进行领取、用户被动发动领取和零碎免密领取的流程可能就不一样。针对下面这两种状况、咱们把这里的"场景"对立封装为"事件（event）"，以"事件驱动"的形式来管制状态的流向，一个状态遇到一个特定的处理事件来决定该状态的业务解决流程和最终状态流向。咱们能够总结下，其实状态机模式简略说就是：基于某些特定业务和场景下，依据源状态和产生的事件，来执行下一步的流程解决逻辑，并设置一个指标状态。 ...

又到一年毕业季，行将开启（实习及正式）职场生涯的同学们会有不少纳闷。比方，热门技术如何在工业级业务场景落地并带来更好的用户体验？学术界科研与工业级研发的区别有哪些？智慧出行核心技术有哪些，目前支流的技术栈将来发展前景如何？校招同学进入互联网畛域须要具备什么样的能力，如何筹备简历和面试，职场环境如何？ 为帮忙大家解疑答惑，阿里巴巴高德地图为大家筹备了本次高德技术开放日流动，并邀请到了外围工程师与大家一起聊聊智慧出行核心技术以及职场实习、成长那些事。4月10日（周六）上午9点半直播，与大家不见不散，咱们也筹备了大量的互动好礼等你来拿~ 局部直播话题剧透： 高德如何深耕技术打造出亿级用户的国民级智慧出行服务平台 最前沿的人工智能、算法、大数据、云计算、AR、Serverless技术如何落地实际驱动业务增长 作为业界当先的主动驾驶技术服务商，主动驾驶核心技术有哪些？发展前景如何？ 校招生进入互联网算法或工程研发畛域，须要具备什么样的能力？在高德能取得哪些成长机会？ 如何抉择本业余或跨专业的工作？找工作有哪些TIPS？各岗位简历投递技巧，业余面试考查重点有哪些？ 直播工夫：2021年4月10日09:30-15:30 直播平台： B站（高德技术） 抖音（高德技术） 微信视频号（高德技术） 直播互动礼品全场不停，每位讲师分享环节都有互动礼品，高德公仔、星巴克咖啡、高德打车券…让你拿到手软。 大量应届生实习岗、社招岗凋谢，欢送对高德地图感兴趣的同学，随时投递简历，退出咱们一起发明更美妙的出行~ 简历投递邮箱：xz2022@alibaba-inc.com 对于高德地图： 高德地图是国内惟一日活过亿的国民出行平台，作为国内当先的数字地图和实时交通地位服务提供商，充分发挥流量，数据和技术等劣势，致力于连贯真实世界，让出行更美妙。除地图导航外，高德地图还为用户提供打车、酒店、门票等一站式出行服务。每年为用户节俭出行工夫超过21亿小时，为30多万挪动利用提供位置服务。

前言：又到春招季！作为国民级出行服务平台，高德业务疾速倒退，大量校招/社招名额凋谢，欢送大家投递简历，详情见文末。为帮忙大家更理解高德技术，咱们策动了#春招专栏#的系列文章，组织各业务团队的高年级同学以业务科普+技术利用实际为次要内容为大家做相干介绍。本文是#春招专栏#系列的第 3 篇，依据 高德视觉技术核心根底研发部 负责人郝志会在AT技术讲坛分享的《视觉技术在POI名称自动化生成的实际》内容整顿而成，在不影响原意的状况下略作删节。 AT技术讲坛(Amap Technology Tribune)是高德发动的一档技术交流活动，每期围绕一个主题，咱们会邀请阿里团体内外的专家以演讲、QA、凋谢探讨的形式，与大家做技术交换。 郝志会所在团队波及到计算机视觉方面很多技术：包含指标的检测、辨认、宰割，几何重建、视觉定位，等等。 高德POI数据的采集 高德有7000万以上的POI（Point of Interest，趣味点）数据。每年还会呈现很多新增的POI，也会有一部分POI进行营业、关门开张。这些POI如何制作和更新？从采集形式来看会有很多获取POI的形式，有一种重要而且直观的采集形式，高德通过众包形式采集街边店铺的图像，利用计算机视觉技术（以及人工辅助）从图像中提取POI数据。 下图演示了一次众包化采集过程。高德的采集人员从这条街走过，拍摄间断图像。最初把图像和GPS坐标，上传给高德。 下图是一个POI从采集到生产，再到应用的示意图。输出的是间断采集的图像，对于生产环节，最重要的是计算每个POI的内容和地位。而后和母库中的POI匹配，确认这个POI是曾经存在的，还是须要新增。从图像中辨认POI的名称，计算坐标，都须要用到计算机视觉技术。 本文次要介绍的是名称的局部。实际上，高德的POI生产不是全自动化的，而是人机联合的形式。当机器不能自动化，或者置信度较低时，交给人工作业。 高德的POI数据采集—生产—应用流程示意图 POI数据丰富多彩的出现模式，给自动化的处理过程带来了挑战，包含：文字的辨认、是否为POI、文字之间关系、如何命名（定名）… 以下图为例，从原始图像，到主动生成POI的名称，蕴含了以下几项要害的计算机视觉技术：天然场景文字辨认、文本属性断定和结构化解决、名称主动生成… 天然场景文字辨认 文字辨认，简略说，就是从一张图片中，找到外面的文本，给出正确的字符。从文字辨认问题的倒退过程来看，它蕴含了不同的子问题。 首先，大家比拟相熟的名词是OCR，中文翻译过去是光学字符识别。原意是利用光学扫描仪，将印刷体文字读成二进制数据，再辨认成ascii码字符，输入进去。 OCR问题历史比拟悠久，上个世纪80、90年代，就有不少钻研论文，以及商业化产品。比方咱们相熟的深度学习创始人之一Yann Lecun，他在90年代初，就用神经网络辨认手写的邮政编码，被美国银行商用化了。 随着文字辨认技术的倒退，它的利用范畴也变多了。除了印刷体、手写体之外，任何一张一般的蕴含了文字的图片，是不是都能够辨认进去呢？ 在下图中，两头一列的问题叫做born-digitial，也就是说文字是由电脑生成的，文字的字体、版式，绝对比拟固定。 第3列是天然场景的文字辨认问题，称为STR，也就是在实在存在的文字，比方店铺名称、路牌，这种文字辨认问题，因为拍照的角度问题、光照问题、图片品质问题，应该说难度是最大的。也是当初学术界钻研比拟多的一种类型。 当然，当初的STR技术，会面临很多的挑战：包含字体问题、排版问题、多语言问题，以及由拍摄带来的光照问题、含糊问题。 一个店铺门匾上的文字，比其余场景的会更简单，因为它要表白本人的特点，要让你“过目不忘”，所以更容易呈现各种艺术字、各种不同的装璜成果。 而且，高德地图要保护全国的POI数据，在不同城市上，它的地名、店铺名、品牌名，自身是一个十分大的词库。 STR技术倒退：传统算法（before 2012） 先简略介绍一下STR技术。 天然场景文字辨认（STR）的倒退大抵能够分为两个阶段，以2012年为分水岭，之前是以传统图像算法为主；之后，进入了深度学习算法的阶段。 2012年之前，文字辨认的支流算法都依赖于传统图像处理技术和统计机器学习办法实现。分为文本行检测、文字辨认两局部。 文本行检测，个别是先预处理，利用二值化、连通域剖析、MSER显著性区域算子等算法，定位文字区域，提取文本行候选，而后通过分类，去除掉有效候选。 文字辨认，个别是通过切割，找出字符/单词的候选，再通过机器学习分类器，对每个字符/单词进行分类。 传统的文字识别方法，在简略的场景下能达到不错的成果，然而不同场景下都须要独立设计各个模块的参数。遇到简单的场景，很难调整参数，失去泛化性能好的模型。 STR技术倒退：深度学习算法（after 2012） 大略从2012年开始，跟其余的计算机视觉问题一样，STR也进入了深度学习的阶段。 下面讲到的文本行检测、文字辨认两个子问题，别离都有一些深度学习的模型来解决。上面列举几个比拟典型的工作。 最右边，是一个文本行检测模型，华中科技大学的Textboxes++，它是在相似SSD的网络结构的根底上，对四边形的四个顶点的坐标别离做回归，以解决长宽比、旋转这类问题。 两头是一个序列辨认模型。能够说这是在深度学习阶段当前，呈现的一类新的解题办法。输出一个字符序列的图像，传统的计划是必须要切割成单个字符，或者单词，再对它们做分类，有了LSTM这种RNN模型，能够对前后特色序列做编码，再通过引入CTC loss，就能够训练一个残缺的序列辨认模型。 除了将文本行检测、辨认两个环节革新成深度学习的计划以外，也有一些工作在试图把两者整合起来，造成一个end-to-end的计划。整合的目标是什么呢？不难想象，如果可能辨认出文本的内容，实践上应该能够检测的更准。比方，如果能够辨认出“深度学”这3个字，那是不是能够通过某种网络的反馈信号通知检测器，前面应该还有一个“学习的习”字。 第三列是一个end-to-end的工作，他是把faster r-cnn和LSTM接到同一个网络里，在对每个proposal做分类和坐标回归的同时，也做字符的辨认。 高德的STR技术 高德在STR上的技术，其实也是分成文本行检测、字符识别两局部。 在理论工作中并没有应用“端到端”的模型，因为这种分模块的模型，更容易优化部分的成果，比方为某一个模块减少样本，或者换一个模型。 在字符识别的环节，能够看到高德是平行应用了两种计划。下面的分支是单字符的检测和辨认，上面的分支是整个文本序列的辨认。 高德的STR技术——文本行检测 首先看文本行检测。在晚期的时候，大略2017年之前，应用语义宰割模型，比方FCN、deeplab来宰割文本行。 到2017年Mask R-CNN呈现之后，Instance segmentation技术越来越成熟，咱们发现实例宰割在文本行检测这个问题上的成果，也超过了语义宰割模型。最重要的是，因为要独自辨认每个文本行，实例宰割很天然地就解决了这个问题。 而语义宰割，还要做大量的后处理，能力把不同的文本行辨别开。 当然除了Mask R-CNN以外，咱们也会应用其余的实例宰割模型。 在理论的业务问题上，高德的文本行检测的成果。不论是文本行密集、还是含糊的状况下，检测的成果都达到了很高的程度。 高德的STR技术——文字辨认 ...

前言：又到春招季！作为国民级出行服务平台，高德业务疾速倒退，大量校招/社招名额凋谢，欢送大家投递简历，详情见文末。为帮忙大家更理解高德技术，咱们策动了#春招专栏#的系列文章，组织各业务团队的高年级同学以业务科普+技术利用实际为次要内容为大家做相干介绍。本文是#春招专栏#系列的第 2 篇，依据高德高精地图业务总经理向哲在AT技术讲坛分享的《面向主动驾驶的高精地图及采集生产体系》内容整顿而成。在不影响原意的状况下对内容略作删节。 AT技术讲坛(Amap Technology Tribune)是高德发动的一档技术交流活动，每期围绕一个主题，咱们会邀请阿里团体内外的专家以演讲、QA、凋谢探讨的形式，与大家做技术交换。 向哲本次次要分享了两方面的内容： 1.面向主动驾驶的高精地图是什么； 2.当下的高精地图数据采集生产体系建设现状和思考。 高精地图是主动驾驶汽车不可或缺的外围条件，它须要精确表白事实世界各类因素的空间地位和绝对关系，因而高精地图的生产对采集材料的精度要求很高。 工业级的主动驾驶分类 向哲联合主动驾驶在工业级的利用现状开始讲起。 目前工业级主动驾驶大抵能够分为两类，第一类是以特斯拉、小鹏等造车新权势为用户生产的具备“辅助驾驶性能”的智能车为代表。用户在应用这些主动驾驶性能时，要随时接管驾驶，驾车过程中呈现的法律问题责任次要在人类。 高德和市场上支流的造车新权势厂商在高精地图方面有深度单干。以小鹏汽车为例，它的辅助驾驶性能应用了高德所提供的高精地图能力。目前用户能够享受到什么样的辅助驾驶能力呢？根本曾经实现了高速公路上点到点的主动驾驶性能。 比方，从北京开车走高速到广州，途中会遇到若干段高速的切换，即从一段高速通过匝道换到另一段高速，以及在高速上的变道超车。小鹏汽车的NGP辅助驾驶能力具备了以上两种能力，根本具备了从北京到广州的全程主动驾驶性能。 但在行车过程中，司机要随时盯着路况，在主动换道等时候如果有剐蹭的危险要人工接管驾驶，持续手动驾驶实现换道。这意味着，驾驶过程中，司机要随时筹备接管驾驶。 另外，在途经收费站的时候，司机也须要手动接管汽车的驾驶，因为目前高精地图还没做到收费站里的车道级信息。在靠近收费站的时候，语音助手会提醒司机，后方收费站路线没有高精地图，须要手动接管驾驶。以上的主动驾驶能力都会利用到小鹏所有P7车型上。 第二类工业级主动驾驶就是典型的L4。例如谷歌在做的在城市里主动驾驶的出租车，物流支线货车等，跟第一类主动驾驶相比，这类L4主动驾驶实践上在车上是没有司机的。尽管当初在验证阶段，司机席还有司机。据向哲预测，这类L4无人驾驶出租车要想走进普通人的生存中还要有4~5年的工夫。 以上的两类主动驾驶都强依赖于高精地图。 高精地图与主动驾驶 高精地图是主动驾驶车辆“脑子”里的地图，可能让车辆晓得接下来"看不见"的路况是什么样的。主动驾驶的四个要害性能：感知、高精定位、决策布局、车辆管制。这外面至多有三个性能都强依赖于高精地图。 感知：人类驾驶汽车时要察看周边的车道线、交通牌、杆等信息。智能车上的传感器会感知路线周边的物体信息。高精地图提供了上帝视角的超视觉感知能力。尤其是在车后方有大货车等遮挡物导致人眼和传感器无奈看清后方车道线等信息的时候，高精地图数据能够告知车辆后方路线信息。 高精定位：主动驾驶的汽车要准确晓得车在地图中的地位，前提就要依附高精地图所提供的底图。主动驾驶的车要晓得本人在地图中的地位，基于两个能力，一是基于GPS、惯导、千寻等定位能力所提供的相对地位信息。相对地位信息跟地图经纬坐标相匹配，能够断定失去车辆在地图中的具体位置（依赖于传感器进行相对地位定位的能力）。 但仅有相对地位定位还不够，在非凡区域，例如高楼、峡谷等会产生遮挡信号的时候，相对定位精度会变差，主动驾驶须要借助于察看四周的车道线、信号牌、杆子进行的绝对定位来辅助，须要跟高精地图中的地图数据进行匹配判断。在理论我的项目中，高德通过和支流车厂的深度单干，一起来判断通过哪些技术能取得更加精准的绝对定位能力。 决策布局：主动驾驶要合乎驾驶规定，所以要高度依赖车道线、交通限度设施、红绿灯等路线元素的。 以上的几个性能都是彼此撑持关系。 面向主动驾驶的高精地图 几个要害因素：路线层、车道层、定位对象、动静层。 路线层：HD（高精地图）和SD（普通地图）的数据是严密匹配的。目前简直所有主动驾驶都是先由用户通知智能零碎，我要从某地开往某地，这两个地点之间的驾驶路线布局由SD路线数据来反对。HD数据并不孤立，要和SD数据连贯。SD数据能力是高德的传统强项，加上业界当先的HD能力，这种匹配高德肯定是业界做的最好的。这也是汽车厂商在抉择地图服务商时很看重的一点。 车道层：所有的主动驾驶底层的对车辆的管制都依赖于高精地图数据。 定位对象：高德跟车厂密切合作，车厂基于哪些技术来做绝对定位，抉择哪些参考对象，精度做到什么程度等等，单方一起沟通联结研发。 动静层：将来的高精地图肯定会含动静层，实时数据，某条车道在某个时刻产生哪些动静交通事件。 高精地图在城市一般路的挑战 目前高德的高精度地图曾经实现了对高速和城市疾速路段超30万公里路线的采集，正在进入稳固的定期更新状态。相比高速城快，更难的题在城市一般路。 城市高精地图数据的一个要害挑战在于路口，很多路口的高空不足交通线绘制。主动驾驶的汽车在路口间转向的时候，车辆驶过高空没有交通线（油漆），这时候就要依赖于高精地图当时做好的数据。当然，要思考的当然不只是路口的高空交通线，还要思考大量其余交通元素。但城市一般路的主动驾驶必定是地图服务商和造车新权势将来会投入很大精力的重要场景。 高精地图的采集和生成 惯例的高精地图生产能够概括为“采集”、“生产”、“产品化”三个阶段。 采集车是由多种先进测量传感器精细集成的挪动采集零碎，个别会蕴含Lidar、惯导、相机等设施，依据采集场景不同搭载不同型号的传感器设施。高德高精团队通过多年深耕，自研了高精采集车零碎，具备精度高、速度快、数据产生周期短、自动化水平高、安全性高、信息全等特点。 采集设施把内部事实世界里含精度的数据采集回来当前，还要通过图像识别、精度解决、人工解决等步骤能力“变成”能够用的高精地图数据。 “鲜”的高精地图 现实生活中的路线数据处在不停的变动之中，如何能力做到“鲜”的高精地图。 首先，最开始的时候要用老本绝对低廉的业余打底车，在全国路线范畴内测量和采集高精地图数据。这种采集要同时保障绝对精度和相对精度。而后，用绝对便宜的业余更新车来采集路面信息的部分变动（绝对变动）图识，例如从新刷过高空标识，新竖立的牌、杆等。同时，咱们也用更便宜的众包设施做更疾速的采集更新。 为实现对既有数据的疾速更新，晋升数据数据鲜度。高德的高精团队，搭建了业余打底车、业余更新车、众包更新三级能力的采集体系，联合在一起解决精度、鲜度的问题。在实在业务场景里须要在精度和鲜度找到均衡，重复的迭代。 要解决高精地图数据的“高精度”、“大规模”、“足够鲜”等诸多挑战，须要在很多技术点上进行冲破。 比方：如何设计制作不同老本、不同精度、不同部署能力的采集测绘设施； 如何协同不同类设施协同进行采集，同时满足精度、鲜度上的产品要求； 如何设计和利用算法，晋升采集材料的相对精度、绝对精度，并保障屡次采集材料之间彼此对齐严丝合缝； 如何综合利用图像和点云做好辨认，晋升生产的自动化程度。 高德高精地图团队的同学别离专一在不同方向上，并以凋谢的心态承受业务挑战，独特探讨和设计方案，也获得了很多问题。 凭借这份国内精度最高、笼罩最广的高精地图，高德胜利拿下了国内外多款支流车厂的商业订单，开始为智能驾驶车型提供高精定位、超视距感知、车道级导航等服务。作为高德在主动驾驶生态中重点冲破的畛域，高德高精地图业务倒退快，机会多，心愿大家一起退出。 对于高精地图业务核心 高精地图是高德最具创新性的业务之一，致力于用传感器丈量世界，用算法了解世界，用数据从新定义世界。咱们简直涵盖最热门前沿学科，高精地图和主动驾驶是多学科穿插的利用工程体系。基于感知了解，三维重建，交融定位，计算几何技术自动化生成高精数字化三维地图。利用边缘计算，大数据处理，云服务，进行实时海量数据地图重建。通过5G/V2X信息替换，实现地图对象间的数据互通，构建一张活地图。咱们不仅仅是数据制作者，更是新生存的定义者。退出咱们，将来“由”你。

年味逾浓，春节渐近。 高德技术年刊如期而至。 过来的一年里，高德业务疾速倒退，国庆出行节的日沉闷用户数冲破1.5亿，又创新高。高德技术人在撑持业务疾速倒退的同时也在继续翻新：导航个性化、引擎服务化、基建架构降级、全面上云、共享打车、信息服务、汽车前后装、大云图等方面实现新的冲破；车道级导航、高精地图落地等畛域获得行业当先；车载环境下的手机定位技术取得国内顶赛冠军······ 在这些过程中，咱们做了大量的技术实际总结和思考，并以文章等模式积淀下来，与大家一起分享胜利的教训和踩坑的教训。 在2021年春节行将到来之际，咱们精选了几十篇高德技术的干货文章及数篇国内顶会论文，制作成了一本厚达750页+的电子书，作为新年礼物赠送给大家。 这本电子书内容笼罩了大前端、算法、架构、汽车工程、品质等多个畛域，以及数篇高德入选顶会论文的解读，心愿能对大家拓展技术思路有所帮忙。 如果大家有志愿针对书中的技术问题深入探讨，想与咱们做更多交换，或者有更好的倡议，欢送扫描下方高德技术公众号二维码与咱们分割。 心愿大家喜爱本书，欢送举荐给身边感兴趣的敌人。 衷心感谢大家始终以来的反对和陪伴！ 最初，祝大家牛年高兴，安全衰弱，阖家幸福。 【附上年刊目录】 【如何收费获取】 长按辨认下图的二维码，关注“高德技术”微信公众号，在对话框回复“2020年刊”，即可收费下载。舒适提醒：年刊18万字、750页+，文件约26M。

背景 依据Apple官网WWDC的答复，缩小内存能够让用户体验到更快的启动速度，不会因为内存过大而导致Crash，能够让APP存活的更久。 对于高德地图来说，依据线上数据的剖析，内存过高会导致导航过程中零碎强杀OOM。尤其区别于其余APP的中央是，个别APP只须要关注前台内存过高的零碎强杀FOOM，高德地图有不少用户应用后盾导航，所以也须要关注后盾的内存过高导致的零碎强杀BOOM，且后盾强杀较前台强杀更为严重。为了晋升用户体验，内存治理火烧眉毛。 原理分析 OOM OOM是Out of Memory的缩写。在iOS APP中如果内存超了，零碎会把APP间接杀死，一种另类的Crash，且无奈捕捉。发现OOM时，咱们能够从设施->隐衷->剖析与改良->剖析数据中找到以JetsamEvent结尾的日志，日志外面记录了很多信息：手机设施信息、零碎版本、内存大小、CPU工夫等。 Jetsam Jetsam是iOS零碎的一种资源管理机制。不同于MacOS、Linux、Windows等，iOS中没有内存替换空间，所以在设施整体内存缓和时，零碎会将一些优先级不高或者占用内存过大的间接Kill掉。 通过iOS开源的XNU内核源码能够剖析到： 每个过程在内核中都存在一个优先级列表，JetSam在受到内存压力时会从优先级列表最低的过程开始尝试杀死，直到内存水位复原到失常水位。Jetsam是通过get_task_phys_footprint获取到phys_footprint的值，来决定要不要杀掉利用。Jetsam机制清理策略能够总结为以下几点： 单个APP物理内存占用超过下限会被清理，不同的设施内存水位线不一样。整个设施物理内存占用受到压力时，优先清理后盾利用，再清理前台利用。优先清理内存占用高的利用，再内存占用低的利用。相比零碎利用，会优先清理用户利用。Android端为Low Memory Killer： 依据APP的优先级和应用总内存的多少，零碎会在设施内存吃紧状况下强杀利用。内存吃紧的判断取决于零碎RSS(理论应用物理内存，蕴含共享库占用的全副内存)的大小。要害参数有3个:1）oom_adj：在Framework层应用，代表过程的优先级，数值越高，优先级越低，越容易被杀死。 2）oom_adj threshold：在Framework层应用，代表oom_adj的内存阈值。Android Kernel会定时检测以后残余内存是否低于这个阀值，若低于则杀死oom_adj ≥该阈值对应的oom_adj中，数值最大的过程，直到残余内存复原至高于该阀值的状态。 3）oom_score_adj：在Kernel层应用，由oom_adj换算而来，是杀死过程时理论应用的参数。 数据分析 phys_footprint获取iOS利用总的物理内存，具体能够参考官网阐明iOS Memory Deep Dive. std::optional<size_t> memoryFootprint(){ task_vm_info_data_t vmInfo; mach_msg_type_number_t count = TASK_VM_INFO_COUNT; kern_return_t result = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t) &vmInfo, &count); if (result != KERN_SUCCESS) return std::nullopt; return static_cast<size_t>(vmInfo.phys_footprint);}Instruments-VM Tracker能够用来剖析具体内存分类，比方Malloc局部是堆内存，Webkit Malloc局部是JavaScriptCore占用的内存等。须要留神的是每个分类的内存值 = Dirty Size + Swapped。 通过Instruments VM Tracker抓取导航中内存散布进行比照剖析。导航前台静置时，高德地图的总内存数值十分高，其中IOKit、WebKit Malloc和Malloc堆内存为内存占用大头。 在剖析过程中能够应用的工具很多，各有优缺点，须要配合应用，互相补救。咱们在剖析的过程中次要用到Intruments VM Tracker、Allocations、Capture GPU Frame、MemGraph、dumpsys meminfo 、Graphics API Debugger、Arm Mobile Studio、AJX 内存剖析工具、自研Malloc剖析工具等。 ...

日前，高德地图联结阿里云天池平台举办的AMAP-TECH算法大赛闭幕。本次大赛以“基于车载视频图像的动静路况剖析”为赛题，来自15个国家和地区的880支战队通过数轮强烈角逐后，1996年出世的北京邮电大学博士三年级学生朱奕达率领的战队夺得冠军。 （高德地图技术委员会主席李小龙给冠军队伍颁奖，从左到右的三位同学别离是北京邮电大学研究生一年级学生谢志庆、广州大学方滨兴班研究生二年级学生黄文锋、北京邮电大学博士三年级学生朱奕达） 本次比赛的赛题来源于高德实在的业务场景。路况信息不仅影响用户抉择出行的路线、出行的形式，预估达到的工夫，对于交通管理部门和城市规划部门也有重要的价值。 此次高德地图号召寰球的开发者利用人工智能技术摸索动静路况难题，收到了国内外顶尖学府、科研机构以及一线出名技术企业等产学研各界技术爱好者的积极响应。历经4个月的初赛、复赛，五强战队从来自于15个国家和地区，309所高校和256家+公司的参赛者组成的880支战队中怀才不遇进入到现场决赛问难。 决赛评审上，北京大学传授、机器感知与智能教育部重点实验室主任查红彬，中科院自动化所研究员、模式识别国家重点实验室主任王亮，高德地图技术委员会主席李小龙，高德地图首席科学家任小枫，阿里巴巴达摩院主动驾驶实验室负责人王刚组成的专家评审团从创新性、实用性和扩展性以及现场体现三个维度对各队计划进行现场的综合评审。 评委们认为，朱奕达战队以模块化的形式设计了一个端到端序列分类模型， 应用了比拟新鲜的滑动窗口法对数据进行裁减。在简洁模型构造中充分利用了图像序列信息，并实现了较为优异的性能。在较量过程中，算法的鲁棒性优良，并具备良好的可扩大能力。同时模型设计过程中应用了学术研究畛域绝对前沿的技术办法，落地和实用性的后劲在决赛的几个作品里更突出。 北京大学传授、机器感知与智能教育部重点实验室主任查红彬示意，针对交通场景，选手们对深度学习网络结构方面下了很大的功夫。交通场景的问题是个动态变化的自适应性问题，心愿同学们可能更多从在线学习角度思考相干问题。 高德地图技术委员会主席、研究员李小龙在决赛现场发言时示意，动静路况剖析是智慧出行场景的重要课题，高德通过智能化伎俩解决动静路况剖析就须要用到人工智能、大数据等技术，这个问题的解决对于精准导航和人们美妙出行具备重要的现实意义。他激励同学们通过更多系统性的深度思考，把更多学术界的前沿办法用到工业界的理论业务场景中，带来新的冲破方向。

导读 作为国民级出行生存服务平台，高德服务的稳定性不论是平时还是节假日都是至关重要的，服务稳定性一旦出问题，可能影响千万级甚至上亿用户。春节、十一等节假日激增的用户使用量，给高德整体服务的稳定性带来了不小的挑战。每年在大型节假日前咱们都会做整体服务的全链路压测。通过常态化全链路压测我的项目的推动，已具备了月度级别的常态化全链路压测能力，把战前演练提到日常，继续推动稳定性保障建设。 TestPG压测平台2018年9月启动，在2019年春节第一次撑持高德全链路压测工作，过后前后花了近2周的工夫才实现3个机房的压测工作。起初成立了常态化全链路压测我的项目，通过对流程的优化以及压测平台技术能力的降级，当初曾经具备了1天内实现全国3个机房全链路压测的能力。大型节假日的全链路压测周期缩短到了3天。 全链路压测的常态化不仅对高德整体服务的稳定性建设起到了推动作用，而且也推动了流程上的优化以及压测平台在技术能力上的改良晋升。具体而言，咱们次要从压测前的语料筹备和压测过程中的压力调控两个方面动手，通过语料平台化生产，标准语料生成流程，对语料生产提效；通过压测过程中对发压能力的精准调控，使咱们可能灵便调整压力模型，从而使其更加靠近于线上真实情况，让全链路压测过程平滑晦涩，效率晋升。本文会重点介绍TestPG压测平台在发压能力精准调控方面的建设实际。 压力调控的两个次要问题 下图是现阶段高德全链路压测的一个大抵流程 高德全链路压测波及到接入层的上百个接口，每个压测接口的压测流量须要在链路梳理阶段由运维和相干同学当时预估给定。压测前会在压测场景里对每个接口的流量进行调配，通过流量占比当时配置好，这是咱们全链路压测的压力模型。压测启动之后，会逐渐加压，直到整体压测流量达到预估值，在整个过程中，可能会对当时配置的压力模型一直做出调整，最终使压测流量模型合乎预期的线上流量模型。 高德全链路压测波及的链路比拟长，压测流量流经接入层，服务层最终达到引擎层，有可能呈现理论达到引擎的流量与预估流量之间存在差别。这时候会先进行压测，更新压测场景里的接口压测流量占比配置，而后再启动压测。 在高峰期，压测集群中可能有百十台施压机同时施压，进行压测，更改压测场景里的接口流量占比配置，再启动压测，而后再一次逐渐加压，这样一整套流程会十分耗时而且效率低下，有时只为了更新一两个接口的流量占比配置，不得不把后面的步骤再走一次，导致过多消耗工夫精力。一直起停也使整个过程不连贯，无端拉长了全链路压测周期。 再者，在全链路压测过程中，整体压力是逐渐减少的，多轮加压，每一轮加压后都会监控服务的各项指标来决定是否进一步减少压力。TestPG压测平台采纳分布式集群施压模式，增压是通过往压测集群里调度新的施压机实现的，这样带来的问题就是，减少压测流量的时候，须要相干人员依据压测时候的单机施压能力大抵估算出须要减少多少机器。因为增减的压力=单机施压能力*n台施压机，这样的压力调控粒度也是比拟毛糙的。比方要加压1w qps，单机的施压能力是3k qps, 那么须要减少3台或4台施压机，那么理论减少的压力为9k或者1.2w。 最初，也是最重要的，高德业务零碎对接口特征参数（对服务的性能/性能有重大影响的接口参数）尤为敏感，比方长短距离导航对后盾服务的算力和资源耗费都是不同，这就提出了更高的要求，咱们须要有能力在全链路压测中对接口的压力调控准确到特征参数级别。 简略总结一下，在压测过程中，针对压力调控，咱们面临两个次要问题，一是压力调控效率低下，二是无奈做到细粒度的精准调控。 实现门路 全链路压测是以实在流量提前对系统进行验证。只有以靠近于线上实在流量的压力模型对系统进行压测，才更能发现可能暗藏的稳定性问题，压测能力更有价值。因为咱们的压力模型是预估给出的，难免会与理论服务预期的流量存在差别。所以压测过程中通过对差别流量做调整，最终使压测流量模型合乎预期的线上流量模型。 既然现阶段压测过程中，压力调整在劫难逃，并且因为其效率低下，曾经影响到了全链路压测的顺利进行，那么就能够以此为抓手，在压力调控能力上做技术改良。首先是解决压力调整效率低下问题，保障全链路压测的晦涩进行，晋升效率。而后联合语料智能化我的项目，实现精准压测，使压测流量（压力模型+压测场景）更加靠近于线上实在流量。将来能够进一步摸索，提供丰盛的压力模型以更好地撑持场景化压测的诉求。 接下来会介绍TestPG压测平台，在施压能力精准调控建设上的技术计划和落地成绩。 技术计划 TestPG压测平台采纳分布式集群施压模式，多台施压机构成一个压测集群。平台的整个架构是典型的master-slaver构造，压测的时候master调度slaver进行施压。这样的架构其实非常适合咱们实现压力动静调控的一个主动控制系统。 上图是压力调控零碎的一个形象示意图。 压力调控核心是压力调控零碎的大脑。其次要作用是依据压力调控策略向压测集群中的施压机下发压力调控指令，并且可能依据调控反馈数据，决定进一步的调控策略。 压测集群作为压力调控对象，接管压力调控核心下发的调控指令，并施行具体的压力调控动作。 压测集群与压力调控核心之间存在一个反馈渠道，这样压力调控核心就能够晓得调控的成果，并依据反馈数据，对下一步的调控进行决策。 落地架构 以上是TestPG压测平台精准控压建设的一个落地架构示意图。 API Gateway模块承接用户压力调控指令，并把压力调控指令转发到Stress Contoller(压力调控核心)。 Stress Controller是压力调控的大脑，会依据压力调控策略向压测集群中的施压机下发调控指令，并依据反馈数据，决定下一步调控策略。 TestPG基于Redis实现了动静配置缓存。压力调控指令通过动静配置缓存下发到压测集群，更具体来说是下发到压测集群中的每台施压机上，目前TestPG采纳两种形式实现动静配置的下发，别离是施压机被动拉取和通过公布订阅模式进行实时推送。 压力调控指令下达到施压机后，压测引擎运行实例会加载压力调控配置，实时调整压力。 每个压测引擎都会实时上报本人到压测指标（比方qps, rt等）和施压机的性能指标（比方cpu占用率，load率等）到TSDB时序数据库，TSDB建设了压测集群和压力调控核心之间的反馈渠道。Stress Controller定期查问TSDB，获取每台施压机以及整个压测集群的压测指标作为反馈数据，依据这些反馈数据断定单机压力调控胜利与否，整个压测集群压力调控胜利与否，并且会依据反馈数据决策是否进行进一步的调控。 基于以上架构，TestPG压测平台在精准控压建设上，已实现了集群和接口两个级别的精准调控。 集群压力调控 通过集群压力精准调控，在压测过程中，能够随时指定要压的预期qps，如果是下调压力，平台会十分快的把压测集群的输入流量，压到指定的预期qps。如果是上调压力，以后压测集群中的施压机整体输入压力上调后不能达到预期的qps，零碎会从施压机公共资源池调配肯定数量的施压机进入压测集群，确保在服务容量以内，压测流量可能上调到预期qps。通过这个性能，压测过程中增减压力，咱们不再须要人工依据单机施压能力估算要增减多少施压机，整个压力调控过程齐全是由零碎主动进行的。集群的整体压力也实现了精准调控，达到平台在压力输入能力上指哪打哪能力。 性能介绍 在压测过程进行中，能够对压测工作预期qps进行指定。 压测集群整体压力输入依据指定的预期qps实时调整. 接口压力调控 接口级别的压力调控，目前平台曾经落地了接口流量占比动静调整能力，压测过程中能够随时对接口差别流量做调整，实现了在不停压测的状况下对接口流量占比的即时调整能力。该性能对保障全链路压测的顺利进行起到了关键作用，让咱们能够不便高效地对压力模型做调整，使全链路压测得以平滑顺利进行，晋升了全链路压测参加各方的幸福感。 往年十一全链路压测，因为业务增长较快，导致压力预估模型与理论预期有较大出入，通过接口比例动静调整性能，在不停压测的状况下咱们对压力模型进行了近百次调整，保障了全链路压测的晦涩度，保障了全链路压测的顺利进行。 针对于接口特征参数级别的精准调控，咱们的解决方案是：通过语料智能化生产，对接口特征参数提取和统计，能够把压测接口按特征参数散布拆分为多个，联合接口调压能力，最终在接口级别压力调控上，能够进一步实现接口特征参数级别的更精密调控，这对于高德业务零碎的全链路压测来说是十分重要，能够使咱们施行更加精准的压测。 性能介绍 在压测过程中，对压测接口流量占比实时调整。 接口发压流量占比实时调整成果。 总结 通过发压能力精准调控的建设，目前TestPG压测平台具备了集群和接口两个级别的高效精准压力调控能力。晋升了全链路压测效率，无效缩短了全链路压测的周期，在全链路压测过程中能够使咱们不便高效地对压力模型做调整，使其更加靠近于线上真实情况。 全链路压测的目标在于验证服务稳定性保障措施是否合乎预期，提前发现服务稳定性问题。压测的真实性至关重要，这里的真实性是指压测的语料数据与线上用户场景相符合，压力模型也要与线上相符合。目前咱们的压力模型是通过计算和预估的形式给出的，往往与线上压力模型存在出入；而压测数据尽管是基于线上流量生产的，但与春节、十一当天的场景还是有差别的。 在真实性保障上，目前TestPG压测平台也曾经有了相应的解决方案，那就是语料智能化生产加上精准控压。将来，咱们冀望通过语料智能化我的项目的推动，借助机器学习等伎俩，通过对压力模型，以及用户场景的预测，并联合精准控压技术，让全链路压测的压测流量模型更加靠近于春节、十一等节假日线上真实情况，实现真正意义上的精准压测。 将来思考 精准控压技术，赋予了平台对压力的精准调控能力，解决了全链路压测过程中，压力调控效率低下问题，保障了全链路压测的顺畅度；并且通过对压力模型的不便高效调整，也使得全链路压测的压力模型更加合乎线上真实情况。然而精准控压技术的用武之地不应该局限于此。 将来咱们能够在压测类型上做进一步摸索。目前从TestPG压测平台的应用状况大抵来看，日常压测上大家并没有无意识的辨别压测类型。绝大多少状况下大家都是以固定qps继续对系统施压。然而，线上零碎面临的实在流量有时候并不是固定，有可能呈现极限尖峰脉冲等状况。平时零碎如果没有压测过这种极限场景，那么线上零碎遇到这种异样流量时就有可能被打挂。 基于精准控压技术，咱们能够在压力模型上做进一步深挖，将来能够在平台上提供多种压测类型反对，比方负载测试、压力测试、零碎容量预估测试等等。并为每种压测类型装备相应的压力模型，比方能够提供负载递增的压力模型，这样能够不便咱们探查零碎容量极限；又比方通过提供极限脉冲压力模型，能够无效测试零碎在遭逢异样流量时候的体现。咱们冀望通过提供丰盛的压测类型反对，把零碎性能的各方面都测到，把零碎压测做全做得更业余。 ...

背景 高德地图作为日活过亿的国民级出行生存服务平台，承载着海量用户服务的是后盾的超大规模集群。从用户角度，如果出问题，影响会很大。3机房异地部署造成线上环境简单，链路简单。在这样的条件下，如何防止因故障造成用户的挫伤，以及在简单链路条件下做好容量布局，做好灾备，并在第一工夫发现问题，通过流量管制和预案演练做应急响应就显得至关重要，而所有的工作都不能等到事件产生之后才做，咱们须要有一种验证伎俩来做好提前性能摸底，这就是全链路压测，让实在的流量提前到来。 全链路压测作为线上服务稳定性保障的重要伎俩，对高德来说也是十分重要的。高德全链路压测平台TestPG从无到有，在经验过常态化压测后，已根本能够保障高德的所有全链路压测和日常压测，达到了平台初期疾速、精确压测和全链路压测的指标。而语料生产(流量解决)作为全链路压测的重要环节，本文将对此做重点介绍。 一次全链路压测可简略总结为3步：压测前的流量解决（也就是生产语料）、压测中确定压力模型启动压测、压测后的后果剖析与问题定位。每次全链路压测，压测前的流量解决是整个压测过程中最耗时的一环。过来往往由运维采集日志交给测试同学写脚本解决，耗时相当严重、老本微小，且存在申请过期等诸多问题。基于这些问题，高德全链路压测平台TestPG后期已标准了高德压测的语料格局，对立了高德压测的流量解决流程。但随着高德全链路压测的演进，后续面临两个次要问题： 语料生产流程不足对立管控。尽管平台后期已标准了语料格局，但各业务只是依照语料标准解决流量，生产流程不足对立、标准化管控，导致语料生产成本仍然很大。尤其对于全链路压测来说，语料筹备是最耗时的环节。接口级别的精准控压无奈满足需要。高德作为国民级的出行利用，流量受天气、地形、节假日的影响比拟大。比方拿驾车导航来说，日常大多都是短距离的驾车导航，而国庆、春节大多都是长距离的驾车导航，而长距离的驾车导航对后端算力的要求是非线性减少的，甚至是成倍增加。但长短距离的驾车导航对压测平台来说是同一个接口，而平台目前的精准控压只能做到接口级别，无奈模仿接口特色级别的压测。基于以上两大问题，高德全链路压测团队设立语料智能化专项，重点解决以上相干问题。 解题思路和门路 引流标准化 高德的全链路压测彼时已根本拉通大多业务，但还属于一个演进阶段。对于语料解决，次要由各业务自行处理后用来压测，语料解决的起源不足统一性，日志、ODPS、流量等解决起源司空见惯。对于语料生产流程的对立管控，咱们首先想到的是对立语料解决起源，必须抉择一个低成本、高效率的形式作为语料生产的输出，而流量录制的形式就很切合。通过调研，发现高德其余业务场景对流量录制也有很大的需要。但高德过来的流量录制形式并不对立，各业务线自行拷贝流量常常会引起线上机器不稳固等问题。所以首先要做的是对立高德的流量录制，标准化引流。 语料生产平台化 要对立管控语料的生产流程，下面曾经对立了语料生产的输出，接下来就是如何把流量转化为合乎平台标准的语料，把整个转化流程平台化。但对于高德业务来说，各个业务都有其本身的特点，如果让平台为每个业务提供定制化的解决逻辑老本微小，再加上平台对各个业务并不是特地相熟，也很容易出错。而整个语料处理过程也存在一些通用的解决逻辑，所以咱们必须提供一种既反对各业务定制化需要，又能够满足平台通用解决逻辑的计划。咱们最终抉择通过Flink来实现整个流量解决逻辑。 引流曾经标准化，业务方只需查看流量的格局内容，编写Flink的UDF(用户自定义函数)，解决本身业务定制化的需要即可，而后续通用的语料存储等逻辑可通过Flink的sink插件来实现。这样既能够提供通用解决逻辑，又给业务的非凡需要提供了反对，扩展性良好。 语料智能化 下面曾经提到高德这种国民级出行利用受各种环境影响比拟大，如何达到接口特色级别的精准控压，是过后面临的又一大难题。平台已具备接口级别的精准控压，只需把接口依照特色分类，提供实在流量的特色散布即可。但流量的特色散布是实时变动的，如何提供合乎流量顶峰的特色散布是语料智能化的最终目标。 要实现语料智能化须要经验3个阶段。第一阶段是流量特色统计。咱们须要明确影响流量变动的因素，体现到流量上就是具体的参数散布，具体有哪些参数会随着外界环境的变动而变动。当然这块高德大多业务线都有一些粗略的剖析后果，后期能够间接采纳，前期就须要有更细粒度的特征分析。 第二阶段是流量特征提取。有了具体的特征参数后，就须要对特征参数进行提取统计，后续可用来做智能预测。但特征参数的提取到底应该如何去做呢？通过综合剖析发现放到语料生产的环节最合适。引流拷贝流量，语料生产环节用来解决流量，在这个环节提取特征参数再好不过了。而整个语料生产扩展性良好，对用户的非凡需要通过UDF实现，整个流量特征提取刚好能够在通用逻辑外面实现。 第三阶段就是智能预测与机器学习。有了特征参数的统计数据，就能够借助今年高德地图国庆或春节的流量特色，加上往年随着业务的流量变化趋势，智能预测出合乎往年国庆或春节流量特色的数据，做到接口特色级别的精准压测，做到真正意义上的全链路压测，为高德地图服务的稳定性保驾护航。后续也能够借助机器学习主动发现影响流量变动的特征参数，主动采集剖析，做到真正意义的语料智能化。 整体计划 整个引流工作将由开发的对立引流平台来实现，引流平台通过引流插件把流量缓存到Kfaka，最终落盘到ODPS。而整个语料生产服务间接对接引流平台，解决来自ODPS的流量即可。 语料生产服务的整体处理过程都由Flink来实现。用户只需编写Flink的UDF来实现本人业务线定制化的需要即可。而且整个Flink的UDF反对多参数传递，用户可灵便编写UDF，在执行过程中动静传递相干参数，解决申请过期等问题。 Flink sink是由平台开发的一个Flink源表解析插件，次要包含流量的特征分析与提取，以及把生产好的语料依照接口命名写入OSS供平台压测应用。目前流量的特色由各业务线本人提供，通过在平台增加实现。Flink sink在执行过程中调用平台凋谢API获取特色数据进行采集，最终上报给平台，平台后续再依据这些数据进行机器学习，智能预测出合乎流量顶峰的流量特色，供全链路压测应用。 外围性能介绍 Iflow引流平台 基于下面的问题剖析，高德工程效率团队踊跃迎接挑战，短短几个月开发了Iflow引流平台，对高德的引流进行了对立管控，具体如下图所示： Iflow引流平台以工作的形式对高德的引流进行治理。目前采纳引流插件的形式进行流量拷贝(后续将反对更多引流形式)，流量通过Kafka缓存，最终写入ODPS供大家应用。用户只须要从ODPS提取须要的数据即可。而启动引流须要相干负责人审批，周知到关联业务，无效的升高了引流引起事变后排查的老本。 TestPG语料智能化 高德全链路压测平台语料智能化次要由3个模块组成：业务线治理、压测名单治理和接口比例治理。业务线治理次要用来治理高德各个链路的相干数据，包含关联引流工作、启动引流、引流记录、语料门路、压测header治理和触发语料生产等性能。一条业务线就是一条压测链路，从引流到语料生产以及语料特征分析等都是在业务线维度实现的。具体如下图所示： 性能介绍： 关联引流工作：次要实现和引流平台工作的关联以及配置相干的参数。启动引流工作：启动引流平台工作，在引流完结后会主动触发语料生产，通过执行用户编写的Flink UDF和平台开发的Flink插件，实现语料的生产和特征参数的提取。语料门路：在每次启动引流触发语料生产后平台会主动生成语料门路，用户可在创立语料的时候自主抉择。压测header治理：每条业务线都有本身的业务特点，在header上的体现也不同，这里次要用来治理压测http服务发送的header内容。触发语料生产：语料生产有2条路径，一是关联好引流工作启动引流后会主动触发语料生产，包含特征参数提取等一系列的操作；二是在引流胜利后，用户可能对UDF等参数有所批改，也能够通过此按钮来触发语料生产。压测名单治理次要用来治理压测的接口。一个公司开始做压测，业务必定是须要跟着去适配的，随之而来的就是业务革新，这是一个漫长的过程。为了方便管理，高德全链路压测平台对高德这边的接口进行对立治理。具体如下图所示： 压测名单是在引流过程中主动上报的，引流只有发现未在压测名单的接口就会主动上报压测平台，平台依据关联利用去关联对应的负责人，并推动确认。如果可压测就确认为压测名单，下次语料生产作为白名单失常引流。如果不能压测就辨别为免压接口或待跟进接口。待跟进接口平台后续会以音讯告诉的模式推动业务线革新，最终达到真正意义的接口笼罩全、链路笼罩全的全链路压测。 接口比例治理后期次要是用来治理BI提供的、以及每次全链路压测调整的比拟贴近真实情况的接口比例数据，作为后续全链路压测的一个参考。前期将通过语料生产提取流量特色的统计数据，智能剖析预测出合乎真实情况的流量比例，供全链路压测间接应用，具体如下图所示： 平台劣势 语料平台化生产 整个语料生产对接了引流平台，并通过Flink来实现。既反对了业务方定制化的需要，也反对平台通用化的解决逻辑，扩展性良好。通用逻辑通过Flink sink来实现，并退出了流量特征提取等性能，推动了语料智能化的顺利进行。用户只须要学习Flink实现UDF的编写，而后在平台实现相干配置即可。很大水平上进步了语料生产的效率和品质，是语料从格局标准化向生产流程标准化的一大飞跃。 语料智能化 平台在整个语料生产的过程中，通过Flink插件实现了特征参数的统计汇总。目前用户只需在平台实现相干特色的配置，平台在语料生产过程中就会剖析特色并统计汇总。有了特征参数的统计数据，将有助于平台后续的智能剖析与预测，达到接口特色级别的精准控压，最终达到齐全意义的全链路压测。 平台目前曾经实现了语料的自动生产，并退出了语料智能化相干的工作。整个压测名单也是通过引流主动上报，后续将通过音讯告诉主动拉通业务线革新解决。接口比例治理模块也已反对接口比例的展现和调整，最终通过语料特色的智能预测，即可生产出合乎流量顶峰实在特色的语料。这些都将推动高德全链路压测智能化的演进。 将来瞻望 高德全链路压测平台语料智能化倒退曾经有一段时间了，通过大家的不懈努力，语料智能化已实现了语料的自动生产，以及特征参数的汇总和提取，为后续智能化奠定了根底。将来平台将通过机器学习的形式剖析学习采集到的特色数据，依据今年流量顶峰的特色状况，加往年流量的变化趋势预测出合乎往年流量顶峰的特色状况，做到接口特色级别的精准控压，齐全模仿实在流量压测达到真正意义的全链路压测。 此外，平台将会借助机器学习主动剖析发现影响流量变动的参数，主动提取剖析，进步语料生产的准确性。 平台也会有置信度评估零碎，别离比照实在的流量特色和预测的流量特色，剖析产生误差的起因，进一步提高预测的精准度，做到齐全实在的流量生产。后续配合平台的精准压测、压力模型和监控等性能达到真正意义的无人化、智能化的全链路压测。

导读 10月30日，华为联结高德、千寻公布了业内首家面向手机用户的车道级导航利用。在这背地是高精度定位技术一直演进倒退，最终走向成熟量产的过程。本文将联合高德地图在车道级导航及主动驾驶等畛域的工作，分享咱们对于高精度定位技术演进的思考，以及在高精定位理论落地利用中的一些实际。   一、高德定位技术概述 定位技术是撑持高德地图的导航、交通等外围业务的要害根底技术，他的次要工作是确定物体（通常是人或车）在一个绝对固定的坐标系中的地位和姿势。咱们用手机高德地图作为例子来阐明都有哪些技术在理论利用场景中发挥作用。  通常手机的根底定位能力是由手机的GNSS芯片提供的，它为咱们在室外的绝大部分场景下提供了5~10米的定位精度。然而在卫星信号不好的时候，定位可能会漂移，咱们须要辨认出这种状况。另外，当信号受到烦扰的时候，地位可能呈现有法则的偏移，咱们也要辨认出烦扰，并且在可能的状况下从新解算出正确的地位。当GNSS定位不准的时候，想要继续定位，能够利用传感器辨认出步行/驾车状态，再进行航位推算（PDR、VDR）。当进入室内卫星信号失落了，罕用的定位办法是依据手机扫描的基站和Wifi、蓝牙等信号做网络定位。 下面这些技术提供了根底的地位坐标，而在导航过程中，咱们更关怀的是行驶在哪条路上，有没有偏航，间隔下个路口有多远，想得到这些信息就须要用到地图匹配技术。在一些非常复杂的场景下，比方高架桥、主辅路，判断路线变得十分艰难，这时候还须要用到一些专门的辨认模型来解决匹配问题。   图1 手机高德地图中的定位技术 下面提到的只是具体一个业务场景中的局部技术，上面展现了高德定位技术的一个更残缺的大图。总的来讲，咱们是通过构建一套“云+端+数据”的残缺的技术体系，并建设品质迭代零碎保障各技术模块的继续更新迭代，来撑持泛滥的定位业务利用。   图2 高德定位技术大图 二、定位技术如何向高精演进 回到图1，咱们能够看到这里提到的定位技术只管扩大了用户场景，但在定位精度方面并没有显著晋升。如果要实现后面提到的车道级导航，乃至更加智能化的主动驾驶，就要求定位精度显著进步到亚米级，甚至厘米级。那么怎么做到这一点？咱们上面会从技术的角度做一个剖析梳理。 首先，咱们把图2中波及的，以及其余更宽泛的定位技术，依照定位原理分成三类，别离是航位推算、几何定位和特色定位。针对不同的定位类型剖析影响精度的因素，总结晋升精度的办法，最终冀望找到实现高精定位的技术门路。 表1 不同定位技术的剖析汇总 1. 航位推算 航位推算的基本原理是从上一时刻地位登程，依据静止方向和间隔推算下一时刻的地位。显然这种定位办法须要一个已知的起始地位，否则就只能失去绝对的地位变动。同时在推算过程中定位误差会一直累积增大，所以影响精度的间接因素就是推算工夫或间隔。 此外，推算精度还受到每个时刻的测量精度的影响，对于惯性传感器，这就间接由惯性器件的精度决定。例如，精度最高的策略级惯导，随工夫发散的地位误差可达30m/hr，相比之下，战术级惯导精度要差3个数量级，而咱们罕用的生产级微机械（MEMS）惯导精度比战术级要再差1~2个数量级。 除了器件精度，推算过程中的模型精度也会影响定位精度，这蕴含两个方面：一是对器件测量误差的弥补模型，二是对计算误差的弥补模型。通常只有当器件自身的精度足够高时，才须要思考更准确的弥补模型。 2. 几何定位 几何定位是对已知地位的参考设施进行测距或者测角，再通过几何计算确定本身地位。依据几何计算的形式不同，包含RSS（信号强度）、TOA（达到工夫）、AOA（达到角）、TDOA（达到时间差）等多种办法。对于测角定位办法，一个小的角度测量误差可能在间隔定位设施较远的中央产生很大的地位误差，因而这种办法（如采纳AOA办法的蓝牙定位）的定位精度通常受范畴限度。在测距办法中，采纳工夫达到模型（如采纳TOA办法的GNSS定位，采纳TDOA办法的UWB定位）比信号强度模型（如采纳RSS办法的蓝牙和Wifi定位）更有可能取得较高的定位精度。但在理论利用中，最终的定位精度受到间隔测量精度的影响，尤其是在卫星定位这一类长距离信号流传的场景中，如何打消信号流传门路上的测量误差，就成为决定定位精度的要害。此外，几何定位的精度也受到定位设施数量和散布的影响，同时观测的设施越多、散布越平均，精度通常也越高。 3. 特色定位 特色定位办法首先获取周围环境的若干特色，如基站id、Wifi指纹、地磁场、图像、Lidar点云等。接下来有两种解决形式，一种是把接管到的特色和当时采集的特色地图进行匹配，确定在特色地图中的地位；另一种是没有特色地图，通过比照前后帧的特色变动来进行地位姿势推算（即SLAM技术），达到相似航位推算的绝对定位成果。显然，影响特色定位精度的间接因素是特色的数量、品质和区分度。 因而，采纳信号指纹特色（如Wifi指纹）的定位办法因为指纹的稠密性通常精度无限。基于环境感知特色的定位办法在采集的特色足够密集的状况下（如高线数Lidar，中高分辨率图像等）能够达到很高的精度，然而在理论利用中受环境影较大，当环境特色繁多的时候（如天空、雪天）精度就会降落甚至无奈定位。另外，特色地图匹配办法的定位精度也受到特色地图精度的限度，特色推算办法（如视觉SLAM）的定位误差会随间隔累积，具备相似航位推算的发散成果。 综合下面的剖析，能够筛选出具备高精度定位能力的技术选型。残缺的高精定位计划首先须要至多一项高精度相对定位技术，如几何定位中的GNSS定位，特色定位中的Lidar点云匹配等；其次，针对这些计划中的场景限度，辅助绝对定位伎俩，如DR、SLAM技术等，进行补充。  表2 高精定位的技术路线 三、高精定位业务场景与解决方案 下面从技术的角度剖析了高精定位可能的实现门路，接下来咱们从高德的具体业务场景登程，看一看这些技术在理论业务中是如何落地的。 1. 理论业务场景须要什么样的高精定位能力 出行场景是高德地图的外围业务场景。以驾车出行为例，传统的出行利用是以TBT(Turn-by-turn)导航为代表的路线级利用，它对于定位精度的要求在10m左右。更精密的导航体验，如车道级导航，须要将汽车定位到车道上，这就须要地位精度达到1米以内。对于智能驾驶场景，为了保障机器主动驾驶的安全性，对定位精度的要求更高，个别在路线横向的精度须要小于20厘米。 图3 驾车出行场景的高精利用 除了对精度的要求，不同业务场景对于高精定位能力还提出了其余维度的要求。 1）可靠性（或完整性）：这次要用来掂量定位系统是不是有能力发现可能的谬误，这对于依赖定位进行智能驾驶的利用尤其重要。比方，零碎须要对以后的地位给出一个精度半径，当理论的地位精度小于这个半径时，零碎就是牢靠的。所以，对于可靠性要求比拟高的利用，这个半径的预计通常是激进的。 2）可用性：如果零碎可能精确的判断以后的定位精度满足导航、主动驾驶等业务的要求，这时零碎就是可用的。显然，可用性要求精度半径的预计不能太大，否则零碎会频繁认为定位不牢靠，导致相干的性能无奈应用。 3）算力：作为传统导航利用的降级，车道级导航对于算力的敏感度较高，通常要求满足目前的手机、车机导航的算力限度。智能驾驶依据不同的智能水平分级（SAE Level1~Level5），对算力的要求也不同。通常低等级智能驾驶搭载的传统汽车电气架构无奈提供更多的算力资源，而高等级智能驾驶应用的集中计算单元能够提供的算力资源更丰盛。 除此之外还有许多与理论利用相干的需要，比方输入定位后果的工夫稳定性，定位可能笼罩的场景范畴等。 总结一下，车道级导航须要的外围能力是辨认以后车道，这个别要求定位精度小于1米，同时作为导航利用，须要在传统导航的根底上进步路线匹配的准确率。低等级智能驾驶（L3以下）要求车道辨认和路线匹配（这次要是为了保障智能驾驶只在容许的路线范畴内关上，如高速路）的准确率更高，更进一步要求横向地位精度达到20厘米，另外对系统的可靠性要求也更高。 下面的两类利用是咱们目前最次要的业务场景，它们都要求在较低算力条件下实现高精定位性能。为了满足这些业务的须要，咱们开发了轻量级的一体化交融定位引擎。 2. 轻量级的一体化交融定位解决方案 这里咱们应用的定位技术次要包含：RTK-GNSS技术，图像语义匹配，IMU或汽车模型DR技术等。其中，图像语义匹配应用视觉设施（通常为车上装载的智能摄像头，如mobileye等）辨认的车道线、高空标记等信息作为输出，与高精地图数据进行匹配定位，这一过程解决的语义因素无限，所以算力耗费不大。至于其余技术在传统导航定位中曾经波及，所以计划整体的算力耗费能够管制在和一般导航同一量级。 图4 一体化交融定位解决方案 下面的一体化计划框架能够接管全副或局部定位信号输出，同时提供路线级和车道级的定位后果，保障了在全场景下定位的连续性。在具体利用中落地时，计划的模式又有所不同。 对于智能驾驶利用，高可靠性要求零碎具备更多的冗余信息来容错，因而通常须要RTK-GNSS、IMU、视觉语义等所有信息输出，在收到这些信息之后须要解决两个问题：1）如何判断输出信号哪些是牢靠的，2）如何充分利用所有信息进行交融定位。 这里咱们采纳了基于多假如的粒子滤波作为高精交融定位的根本算法，并且设计实现了上面的算法改良： 依据假如特色缩减粒子维度，缩小计算量； 采纳分层归一化解决渺小系统误差导致的粒子进化问题； 基于上下文的后验置信度计算，解决输出信号置信度缺失或谬误；基于信号窗口的输出信号提早和乱序解决；利用高精卫星定位和高精地图数据辅助传感器校准，晋升DR能力。目前该算法曾经在一款L3级别智能驾驶车型上落地，正在进行大规模试验验证。 对于车道级导航利用，因为老本和应用条件的限度，通常无奈获取所有输出信息。然而依据表2，咱们至多须要RTK-GNSS或者视觉语义其中之一进行高精度相对定位。在手机终端上，比拟便捷的实现计划是降级手机GNSS芯片反对RTK差分来晋升精度。在后面华为手机上首发的车道级导航利用就是综合了华为和千寻的相干技术和服务来实现高精度的相对定位。 对于车机，能够将车上用于低等级智能驾驶性能的智能摄像头信息接入导航，间接降级车道级导航性能。在这个利用场景下的高精交融定位依然是以下面的粒子滤波算法作为根底，但须要在算法和工程上灵便适配各种不同的输出信号类型和信号特色。 另外，针对导航场景的特点，一体化交融定位还依据车道级定位后果，比方汽车是不是在进口车道上，来辅助判断主辅路、高架桥等简单路况条件下的偏航状况，晋升用户导航的整体体验。 目前基于华为手机的车道级导航要公布上线，车机的车道级我的项目也正在施行落地，不久就会和大家见面。 ...

5G和北斗，是国之重器。北斗作为卫星定位系统，目前在国内上已处于领先地位，而且曾经渗透到咱们工作和生存的方方面面。本文将简要介绍卫星定位的原理和利用状况，不便大家对北斗、卫星定位有更多的理解。 卫星定位的原理 卫星定位系统的英文是Global Navigation Satellite System(GNSS），尽管间接翻译过去是导航卫星零碎，但它真正提供的能力是定位，能定位后，导航就变得绝对简略了。卫星定位的原理，是利用卫星播发工夫信号，当设施接管到后，能够依据信号发射工夫和本地工夫，计算出信号传输工夫，再联合光速取得卫星-设施间隔。 有了多颗卫星的信号，能够列出一组方程，求解4个未知数：设施的三维坐标x/y/z，以及本地工夫与GNSS零碎的时间差。 式中的代表卫星j的三维坐标，这个坐标能够通过卫星星历计算取得。 星历是形容卫星运行轨道的一组参数，卫星轨道是一个椭圆，通过几个参数和工夫，能够惟一确定卫星的精确地位。 星历的获取有两种形式，一种是卫星间接播发，这种形式的益处是定位过程不依赖卫星信号以外的任何输出，即便没有网络也能够定位胜利，但问题是卫星链路带宽很小，要下载残缺星历，须要30秒左右的工夫，晚期的手机和一些车载设施定位过程很慢，就是因为这个起因。 另一种形式，是通过互联网播发，这种形式叫A-GNSS，具体的传输协定叫SUPL(Secure User Plane Location)，这种数据个别不对应用层透出，在手机上，操作系统会在底层定时申请SUPL数据，而后将取得的星历注入GNSS芯片。有了A-GNSS，设施就能够在秒级取得定位，不须要任何期待过程，目前所有的手机都反对这种形式。A-GNSS的服务提供商，次要是通信运营商，以及一些定位服务商，比方谷歌、千寻等。 卫星不间断的向高空播送信号，这个信号次要包含以下信息： 卫星编号。用于从星历中查找卫星轨道，再联合工夫戳取得以后卫星地位以后工夫戳。用于取得卫星地位，另一方面计算伪距。伪距是(本地工夫-信号发射工夫)*光速，之所以叫伪距，是因为本地工夫与卫星工夫不同步，所以这个间隔并不是真正的设施-卫星间隔。星历数据。用于计算卫星地位。像其余所有的通信技术一样，这些信息也是以报文的模式发送的，以GPS为例，卫星会每隔6秒收回一个包，而这个包会合成为数据位-CA码序列-载波波形，通过天线发射到高空。高空设施继续锁定卫星，在解算时，计算每颗卫星以后时刻的工夫戳（用最近一次收到的工夫戳加上报文偏移量），而后进行地位解算。 载波的频率是1.5G左右，波长20厘米左右，比挪动通信的波长稍长一些，所以信号的穿透性还是比拟好的（波长越长，越容易绕开障碍物），能够穿透比拟薄的墙壁或屋顶，所以在一些状况下即便无奈间接看到天空，也是能定位的。然而卫星信号是从上往下，在室内很难穿梭多层建筑。 卫星定位的另一个特点是能够解算出速度，其根据是多普勒频移原理（与交警用的测速仪原理一样）。当信号源与接管设施存在相对运动时，接管到的信号频率会发生变化。 频率变动量与相对速度存在如下公式： 其中，公式右边是频差和波长，v是设施静止速度（矢量），vj是卫星静止速度（矢量），1j是卫星的投影方向，dt'是本地设施的频漂速度。只有测量了4颗星的频差，就能够解出本地设施的静止速度（与设施姿势无关）。 除了定位和测速，定位卫星还能够实现寰球授时（解算过程中取得本地钟差），这也是目前老本最低的高精度授时办法，比绝大部分设施自带的时钟都要精确。 一般而言，伪距测量值精度不如频率测量精度高（伪距定位精度在10米左右，而多普勒定速精度能够达到0.2米/秒以内，授时精度在20ns），起因是伪距测量容易受到多种门路误差影响（前面会介绍），而频率测量的烦扰因素少很多。 卫星定位倒退历程 最早的卫星定位系统，是美国在1960年代开发的子午仪零碎，后续在70年代开发出了GPS定位系统，目前的GPS零碎由24颗卫星形成。除了GPS，世界多国也开发出了本人的卫星定位系统，次要的有中国的北斗零碎、欧盟的伽利略零碎、俄罗斯的格洛纳兹零碎，此外日本和印度在开发区域定位系统。 除了天上的卫星，各定位系统还须要地面站对卫星的运行进行监测，包含衰弱度、轨道参数（计算实现后要注入卫星实现寰球播发）、信号品质等，另外还须要对卫星进行管制。 各种卫星定位系统应用的技术相似，大多采纳中轨道卫星（MEO，卫星高度2万公里），多数采纳了地球同步轨道（GEO，卫星高度4万公里）和地球歪斜同步轨道（IGSO）。同时，信号播发大多采纳CDMA技术，实现在同一个频率上传输多颗卫星的信号。为了让高空设施可能较好的接管来自几万公里外的信号，信号的数据速率都比拟低，比方GPS L1频段的数据传输速率只有50字节/s，依据香农定理，C=B*log2(1+S/N), 在频率带宽B固定的状况下，随着传输速率C的升高，接收端在信噪比(S/N)比拟低的时候也能够解出正确的信号，有利于继续的锁定、跟踪卫星信号。 与其余定位系统相比，北斗的特点次要有： 亚太地区笼罩好。北斗零碎由3颗地球同步卫星、3颗地球歪斜轨道同步卫星和24颗中轨道卫星形成，与GPS相比，北斗有6颗星继续笼罩亚太地区，极大晋升了亚太地区可见卫星的颗数，一方面进步定位成功率，另一方面也能晋升精度（改善了GDOP，缩小了误差）。北斗的同步卫星可用来进行通信，高空设施能够将短报文发送到卫星（只用GEO卫星反对短报文）上，而后转发给指标终端，这种通信是收费的，然而须要专门的天线和设施（须要将信号发射到4万公里远的中央，一般手机必定是不行的）。  多个卫星定位系统的信号同时被收到时，所有的卫星能够一起参加解算（每减少一个零碎，只需减少一个新的参数，即这个零碎绝对于GPS零碎的时间差），使得定位精度能够取得晋升。目前手机上无奈抉择参加定位的星座或者卫星，所以咱们无奈指定只用北斗或者不必GPS定位。 咱们比照了手机端GNSS定位时，应用不同零碎的占比，能够看出GPS和格洛纳兹因为倒退的比拟早，在手机芯片侧的渗透率比拟高，因而被应用的比例也最高，其次就是北斗。 按参加定位的卫星颗数统计，北斗排在第二位，仅次于GPS。  因为各零碎技术相似，其定位精度也是相似的，北斗也不例外，程度定位误差个别在10米以内。垂直定位精度个别会差一些，次要是因为卫星都散布在设施的一侧，垂直方向上的误差难以修改。 卫星定位接收机形成 卫星定位接收机的原理图如上图所示，次要的模块包含： 天线用于接管卫星信号。因为卫星信号强劲，天线当然是越大越好，然而因为接收机须要挪动，天线尺寸受到制约。天线的次要作用是放大信号和克制多径，次要的类型有以下几种 右边的是比拟常见的天线，外部是陶瓷天线，内部带磁铁，能够吸附在车顶；两头的是业余天线，旁边带扼流圈，能够克制来自周围和高空反射的信号，只接管从天顶方向来的信号，这种天线的成果最好，个别用于业余钻研和高精测绘；右侧是手机天线，长度只有几厘米，成果最差。 卫星信号的电磁波是圆极化的（流传时在垂直于流传方向的一个立体上稳定），因而，采纳圆极化天线（如立体的陶瓷天线）接管成果最好。但手机上天线尺寸太小，只能采纳线极化天线，信号捕捉能力大幅降落，再加上不足信号屏蔽（扼流圈），极易受到多径效应以及其余信号烦扰。  射频前端这个模块次要是将原始信号进行下变频、功率放大以及滤波，提取真正有用的信号，便于解码解决。 基带解决这个模块是对卫星信号进行解码，取得卫星报文。每颗卫星的信号须要一个独自的通道进行解决，如果有100颗卫星，2个频段，那可能须要200个通道能力无效解决这些信息。通道数越多，能够取得的卫星观测值也就越丰盛，定位精度也就越高。  解码的过程，分为搜寻-锁定-跟踪三步，首先生成每颗卫星的伪码，而后与信号进行自相干操作，相关度达到肯定水平就能够锁定卫星，而后进行码锁定、位同步、帧同步，最终提取出报文。这个过程要继续进行，因为多普勒效应，信号的频率会一直变动，所以本地生成的伪码也要一直变换频率去适配卫星的变动。一旦失去锁定，就会失落信号，也就无奈定位了。 PVT解算PVT包含Position，Velocity和Time。这一步是真正进行定位的步骤，是利用基带解码取得的报文，提取出工夫戳、星历等信息，代入公式进行计算，而后将计算结果输入给应用程序。 定位误差起源与精度晋升 卫星定位尽管曾经很精确了，然而在某些场景下，还是无奈满足需要，比方，打车的时候定位点离车辆有肯定间隔、步导的时候难以辨别方向甚至会定位到马路对面、静止的时候定位点总数飘来飘去、室内的时候定位点乱飘。这须要从卫星信号的发射、传输、接管过程来解释。 卫星信号从发射到被设施接管，须要通过大气层，其中，大气电离层有数千公里厚，这部分大气十分粘稠，然而存在大量被电离的电子，这部分电子会让电磁波变慢一点，从而产生提早。在对流层，也会产生肯定的提早。在地表左近，因为各种修建、山体、水面的影响，卫星信号可能被反射或折射（多径效应），产生提早。 在卫星信号发射侧和接管侧，也有很多零碎相干的误差，比方时钟偏差、解决提早等，这些提早加上传输提早，使得卫星信号的传输工夫，并不是精确的等于物理间隔/光速，另一方面，卫星的星历也有误差，卫星地位和实在地位存在偏差，最终造成了定位后果产生偏差。 要晋升定位精度，须要想方法打消这些误差，次要有以下几种计划。 双频GNSS 不同频率的电磁波通过电离层时会有不同的提早，人们发现，对两个或多个频率的观测值进行线性组合，能够打消电离层误差，从而能晋升精度。这就是双频GNSS定位的原理。小米8是业界第一款反对双频GNSS定位的手机，后续各大厂商均进行了跟进，一些高端手机均采纳双频定位。打消电离层误差后，定位精度能够晋升到5米以内。 地基/星基加强 星历误差、卫星时钟误差、甚至是电离层和对流层误差都是能够观测或建模的，一旦计算出了实时的误差值，就能够通过一个独自的通道进行播发，接管设施在定位过程中应用这些修改项，就能够晋升定位精度。播发的通道个别有两种，一种是间接通过卫星播发，称为SBAS(Satellite-Based Augmentation System)，益处是笼罩广，但设施须要减少额定的信号接管通道；另一种是地基加强，比方通过互联网，这须要设施具备联网能力。 这些加强形式对于精度晋升是无限的，还是有很多误差项无奈打消，比方电离层误差。 ...

1.背景 当咱们关上导航，开车驶向目的地的过程中，有时候会碰到这样的问题：后方明明没有路，可能在施工关闭，可是导航依然让咱们往前开车，以至于咱们无奈顺利达到目的地。全国路线千千万，每天都有巨量的路线变得不可通行，那么如何动静的辨认出哪些路线走不通了呢？ 图中所示即为因封路事件导致的导航路线扭转 路线不通往往导致该条路线汽车流量忽然升高。监控汽车流量的变动是开掘封路事件的重要指标。然而，目前业务中遇到的一个重要问题是，针对汽车无奈通行的封路事件，行人、自行车可能都能够穿行，这些行人、自行车等的噪声流量大大减弱了路线流量变动。 因而，如果可能对行人、自行车、汽车的轨迹进行分类，就能够对路线流量的噪声进行过滤，仅仅关注汽车流量，流量随着封路事件的变动将更为显著，从而便于路线关闭的开掘。本文次要针对非机动车、机动车分类摸索轨迹分类问题。 2.样本获取与标签制订 因为轨迹数据短少原始真值，咱们将用户导航模式作为轨迹分类的伪标签。例如过后用户采纳汽车导航，其轨迹对应的标签即为汽车。因为汽车导航数据远远多于非机动车，不同伪标签样本比例差别微小，存在重大的样本不均衡问题。此外，用户导航模式与用户理论出行形式可能并不统一。比方有些用户能够依据汽车导航步行达到目的地。下文介绍的标签-概率混合贝叶斯模型将剖析并试图解决上述2个问题。 3.特征分析 能够将轨迹分类相干特色划分为5类。别离是： 轨迹详情特色集，包含轨迹耗时、轨迹长度、轨迹开始工夫等。速度相干特色集，包含最大速度、平均速度、速度标准差等。工夫相干特色集，包含路线末端期待红灯工夫，调头工夫，左转工夫等。行为相干特色集，包含调头行为，往返流动，左转减右转工夫等。用户画像特色集，包含用户职业、有车概率。上面以轨迹开始工夫特色为例，解释该特色的物理意义。其概率密度函数如下所示（drv，汽车；byc，自行车；wlk，步行）： 晚上（5:00~10:00）汽车轨迹概率较高，可能是早顶峰导致。 午时（11:00~13:00）自行车轨迹概率较高，可能是因为外卖送餐。 黄昏（17:00~20:00）步行、自行车概率均较高，可能是因为上班漫步以及外卖送餐。 4.贝叶斯模型的概率分布视角 抉择基于贝叶斯分类器进行改良的起因如下： 贝叶斯分类器属于生成模型，依赖于条件概率密度函数，具备明确的统计学意义。此外，如后面提到的条件概率图示，通过观察不同轨迹、标签的概率密度函数，可能一一剖析、阐明特色的有效性。贝叶斯分类器能够示意为: 通过削减、删减、改变特色的概率密度函数，能够疾速实现贝叶斯分类器的迭代改良。并且相较于决策树，贝叶斯分类器不会对某一个特色的变动过于敏感。贝叶斯分类器最终输入为概率值，能够作为置信度。4.1 标签-概率混合贝叶斯模型 以后轨迹分类问题为样本不均衡（Data Unbalanced）标签不精确（Noisy Label）问题。 Tanaka等人基于卷积神经网络提出了伪标签损失函数，通过穿插熵损失函数与伪标签损失函数的迭代优化实现了谬误标签的修改[2]。受此启发，贝叶斯模型同样可能建设伪标签损失函数实现样本荡涤。 咱们基于贝叶斯分类器的分类后果，提出基于伪标签极大似然预计的伪标签损失函数，实现谬误样本荡涤，再迭代实现贝叶斯分类。该模型的迭代流程如下图所示。 标签-概率混合优化贝叶斯模型迭代流程。 4.2 联结概率密度函数计算 因为贝叶斯分类器假如各变量互相独立，因而不可避免的会对一些场景下的样本产生谬误预测。例如，外卖骑手以及快递员该当被断定为非机动车。这种类型轨迹长度可能较长（超过10公里），最大速度适中（小于50公里每小时）。在假如行驶间隔与最大速两个特色互相独立的状况下，容易谬误地把外卖骑手以及快递员的行驶轨迹断定为汽车。 自行车轨迹行驶间隔以及最大速度联结概率密度函数 汽车轨迹行驶间隔以及最大速度联结概率密度函数 然而，行驶间隔与最大速两个维度的特色并不互相独立。上图构建了针对汽车轨迹这两个维度的联结概率密度函数，能够发现，对汽车轨迹而言，行驶间隔越长，最大速可能越高，当汽车行驶间隔超过10公里时，其最大速度小于50公里每小时的可能性很低。因而，通过构建行驶间隔与最大速度两个维度的联结概率密度函数，替换两个独立概率的相乘，能够帮忙解决长距离非机动车轨迹被误判为汽车的问题。 4.3 基于贝叶斯的轨迹分类试验后果 评测团队抽样约100条数据并人工标记真值。最终模型分类成果如表所示。 5.深度学习模型的图像编码视角 因为轨迹数据短少原始真值，咱们将用户导航模式作为轨迹分类的伪标签。例如过后用户采纳汽车导航，其轨迹对应的标签即为汽车。本次基于深度学习的摸索不思考标签噪声的问题。 5.1 轨迹信息的两种察看形式 深度学习的劣势在于可能从原始数据中学习到无效信息，无需人工开掘特色。针对轨迹数据的特点，存在两种察看轨迹的形式，别离是工夫序列与空间散布。 工夫序列：轨迹当中的GPS点数据随时间推移顺次上传至数据库中。轨迹数据人造具备工夫序列属性。因而，能够采纳TCN或RNN构建模型，学习轨迹中的工夫序列信息，实现轨迹分类。 空间散布：将轨迹数据绘制在地图中，则轨迹形成图片中的一条线。如果可能将速度、方向、等待时间编码到线的色彩当中，则可能采纳CNN从轨迹图像中学习到无效信息[3]。 图左侧大概率为快递员轨迹，图右侧大概率为汽车轨迹。GPS点的空间散布可能为轨迹分类提供无效信息。因而，咱们采纳空间分布模式构建模型，摸索基于深度学习的轨迹分类。 轨迹色彩编码：从GPS点中获取的次要信息为速度、方向、期待时长。将这3个维度的信息进行轨迹色彩编码有2种形式，别离是RGB编码与HSV编码。其中HSV即色相（Hue）、饱和度（Saturation）、亮度（Value）。 因为方向信息为0~360度的角度值，与HSV色调空间种的色相H完全一致。因而，本文采纳HSV色调空间对速度、方向、期待时长进行编码，编码方式为速度：V，方向：H，时长：S。编码后将轨迹缩放为256×256的图片。对地图轨迹的编码后果如下图所示。 5.2 双流神经网络模型 基于编码生成的轨迹图片仍然缺失一些重要信息，包含将轨迹缩放至256×256图片的缩放因子，以及GPS点所在的地位。能够将轨迹匹配后果中通过国道、省道、城市快速路等不同类型路线的比例结构出特色集表征GPS点所在的地位信息，退出缩放因子结构一个一维动态特征向量。 将卷积神经网络学习到的特征向量以及该一维特征向量合并，最终通过全连贯层实现轨迹分类。最终卷积神经网络抉择ResNet50构造。 5.3 基于深度学习的轨迹分类试验后果 评测团队抽样约100个样本，人工标记真值。 如上表所示，以人工标记标签为真值验证深度学习模型，深度学习模型可能获得无效的轨迹分类精度，然而最终分类成果弱于提出的贝叶斯模型。可能的起因有如下几点： ...

2020云栖大会于9月17日-18日在线上举办，阿里巴巴高德地图携手合作伙伴精心组织了“智慧出行”专场，为大家分享高德地图在打造基于DT+AI和全面上云架构下的新一代出行生存服务平台过程中的思考和实际，并重点分享了「高精地图、高精算法、智能时空预测模型、主动驾驶、AR导航、车道级技术」等话题。 「高德技术」把讲师分享的次要内容整顿成文并陆续公布进去，本文为第2篇。 阿里巴巴高级地图技术专家王前卫分享的话题是《AR&车道级导航技术演进与实际》。他为大家介绍了这些畛域的核心技术、阶段成绩及将来方向。 王前卫次要分享了三局部的内容： 技术背景以后停顿核心技术以往，高德通过全球卫星定位系统和数字化的电子地图为用户提供了一款路线级的导航服务，帮忙用户方便快捷的达到目的地。当初通过引入更能了解环境，感知环境的视觉感知零碎，以及通过引入更贴近事实，更精密的车道级数据，为用户精心打造了一款基于实景的车道级导航产品。它能为用户带来一种全新的导航体验，做到所见即所得。 这款产品蕴含哪些性能呢？AR导航通过视频加强技术实现了疏导信息与事实世界更完满的贴合，为用户提供简略易懂的方向性指引。这样用户再也不会因为走到简单路口而走错路；在间隔路口较近，且用户行驶在非正确的车道上时，高德AR导航也能进行及时精确的变道揭示；在路口等红绿灯的时候，帮忙用户实时察看周边环境，及时揭示用户，红灯已变绿灯，或者前车曾经启动。AR导航性能一经上线就取得了用户的好评。 核心技术揭秘 高德AR导航须要具备三方面的能力： 对周边环境实时的感知能力车道级的高精定位能力路线数据的精细化表达能力环境实时感知 在环境感知上，高德AR导航抉择了老本较低但目前应用宽泛的视觉技术，通过深度学习算法来感知四周的环境。其中最大的挑战在于如何设计一款轻量化的深度学习模型，既能在低算力的设施上实时运行，同时能保障较高辨认精度。高德次要在三个方面进行了优化： 第一，在数据上，高德采纳了海量多源大数据的交融和提取来保障训练样本的多样性和覆盖度；第二，在算法上，次要通过优化网络模型，特色共享等办法来保障算法的准确度；第三，在性能上，通过常识蒸馏，模型的量化算法，多任务的跟踪等办法来保障在低算力上能流畅运行。 高精定位 GPS定位精度有余，信号烦扰大，特地是在遇到城市森林或者是天气不好的时候，会产生信号漂移、精度无奈保障。目前精度有余曾经成为大多数导航产品用户体验晋升的瓶颈。基于此，高德提出了一种基于云端一体化视觉定位技术，基于端上图像，联合云端视图大数据，通过神经网络回归出设施相对位姿。与此同时，通过端上辨认车道线、路线边际等标识，进行绝对定位。最终联合时空一致性，进行云和端的交融，大幅晋升了定位精度，将定位误差晋升了一个数量级。 在没有网络的时候，如何应用高精度定位呢？基于老本较低的GPS、惯导和视觉传感器，高德设计研发了多源紧耦合SLAM（MT-SLAM）技术，通过算法的深度交融实现低成本高精度的地位姿势预计，为高精地图众包采集、车道级AR导航等业务提供很好的能力撑持。其绝对地位精度30cm占比在82%以上。 地位姿势的晋升，次要是依据GNSS不同信息的精度个性，采纳分层紧耦合的交融框架，对信息充分利用，同时思考静止束缚，在缩小优化维度的同时也进步精度；依据理论场景的精度特点，缩减内层优化对象，来晋升优化效率；依据协方差利用场景，采纳增量递归的形式晋升协方差复原效率。 在理论的用户场景中，定位遇到的环境是比较复杂的，在实现形式上，有的是基于手机RTK技术，有的是基于视觉传感技术。在不同场景下，有的须要规范精度定位，也有的须要高精度的定位能力。 如何降低成本，晋升效率，以老本最小化的形式来实现一体化定位技术利用和落地呢。高德设计了一套高精/高标一体化交融定位系统。基于成熟的差分卫星定位或环境语义信息，构建轻量化的高精定位能力，并且和标精的导航定位联合造成一体化的交融定位引擎，满足主动驾驶、车道级导航等不同业务的须要。 一体化定位引擎，已具备残缺的路线级标精、车道级高精定位能力，高精、标精定位后果独立输入又互相关联，为导航和主动驾驶联动提供便当，确保在全场景下的定位后果输入，保障定位连续性。 路线数据的精细化表白 当初有了车道级高精的定位，也有了对周边环境的实时感知，最初还须要思考的是如何把规范精度数据表白得更加精密，如何通过建设路线模型，使疏导信息的表白更加贴近事实场景。 大家首先能想到的是通过高精数据。高精数据的厘米级精度，的确能更实在的反映真实世界。然而，为了谋求低成本，高笼罩，高德抉择了利用规范数据精度，加上路线属性信息，通过算法来构建高精路线数据模型。 高德次要通过两个方面来进行模型构建，一是路线的模型，次要是利用SD的形点数据，联合路线的车道属性信息，通过对路口的切分、建模、还原等算法来建设路线的三维模型。二是实景中的疏导信息展现，次要利用布局门路信息和疏导信息，联合实时的路线图像特征提取信息，再加交融的高精定位，在不同的场景下来别离构建对应的疏导线模型。 目前高德的这套模型构建算法，已在理论我的项目中落地。其车道级三维模型曾经可能很好的反映真实世界，更加迫近事实世界；其AR导航的批示疏导的铺路线和疏导线，在绝大多数场景曾经做了和实景路线的贴合。

2020云栖大会将于9月17日-18日在线举办，届时将通过官网为寰球科技人带来前沿科技、技术产品、产业利用等畛域的系列重要分享。 阿里巴巴高德地图携手合作伙伴精心筹备了“智慧出行”专场。咱们将为大家分享高德地图在打造基于DT+AI和全面上云架构下的新一代出行生存服务平台过程中的思考和实际，同时邀请了合作伙伴和业内资深专家分享行业动态、实践倒退方向以及在业界和学术界的最新利用案例。 大量前沿、创新性技术目前曾经广泛应用于高德地图各项产品中，本论坛将着重讲述「高精地图、高精算法、智能时空预测模型、主动驾驶、AR导航、车道级技术」等话题，全面解析最新技术停顿和场景化的实践经验，并与开发者们一起交换、探讨。 欢送大家预约加入2020云栖大会智慧出行专场。 直播网址：https://yunqi.aliyun.com/2020... 【讲师/议题摘要】 1.高精算法推动高精地图落地 分享嘉宾：任小枫 阿里巴巴高德地图首席科学家、研究员 话题摘要：高精地图是主动驾驶走向落地的重要和必要环节，也是高德的一大将来方向。高精地图的生产，在精度、鲜度、效率等方面都提出了全新挑战。要想把高精地图做好，必须有技术上的飞跃。本次分享会从算法登程，整体介绍高德如何打磨和冲破关键技术，把高精地图做到业界当先。 2.面向主动驾驶时代的“节奏式”交通管制 分享嘉宾：李萌 清华大学副教授、博导 话题摘要：交通拥堵是困扰人类近百年的全球性难题，随着主动驾驶、车路协同等技术的倒退，交通信号灯和道路设计也将迎来一场重大改革。“节奏式”管制是一种面向主动驾驶时代的全新交通管制模式，它从抵触本源登程开释交叉口乃至路网的微小后劲，描绘出想象力丰盛的将来交通画面。本次将次要分享这种全新交通管制模式的技术和利用成绩。 3.混合时空图卷积网络：更精准的时空预测模型 分享嘉宾：冀晨光 阿里巴巴高级算法专家 话题摘要：交通预测是智慧出行行业的外围能力，为新一代路线布局、车辆调度等技术的落地提供了重要撑持。高德提出的时空图卷积算法，能奇妙利用海量用户的导航布局信息，“推导”出将来拥挤情况，显著晋升预测准确度。本次分享会重点介绍这一业界当先的技术及其在高德业务中的利用。 4.小鹏汽车的主动驾驶技术实际 分享嘉宾：吴新宙 小鹏汽车主动驾驶副总裁 话题摘要：小鹏汽车自研的全闭环XPILOT主动驾驶辅助零碎，在高速公路实现了准L3级主动驾驶场景表白，可依据导航和路况抉择最优车道并主动变道。本次分享将会介绍小鹏汽车如何针对中国特色驾驶场景和用户习惯，交融高精地图，在“自动化”和“本土化”方面实现技术冲破。 5.AR&车道级导航技术演进与实际 分享嘉宾：王前卫 阿里巴巴高级地图技术专家 话题摘要：门路级导航曾经把用户疾速、精确疏导到目的地。如何让用户在导航驾驶中更平安、更简略，做到所见即所得，是咱们摸索的下一个方向。AR和车道级导航就是利用摄像头将后方路线的实在场景实时捕获下来，再联合深度学习、视觉定位、位姿交融、场景辨认、车道级建模等技术进行交融计算，为用户提供一种全新的导航体验。本次将次要分享其核心技术、阶段成绩及将来方向。 作为寰球顶尖的科技盛会，云栖大会曾经成为科技翻新的风向标。往年是云栖大会首次在线举办，以“3+300”的内容场次设置，为寰球科技人带来三场主论坛和展厅、100场分论坛和专场、100个城市站点线上线下联动和100大新品公布，涵盖云计算、人工智能、机器学习、量子计算、芯片、AIoT、组织协同、新批发、新金融、数字政府等畛域。 大会汇集上千名科学家、技术大咖和国内外知名企业领军人，超过一万名开发者将以在线编程的形式参加到大会当中。同时在35个城市的百个站点设置线上线下联动的“百城汇”会场，与区域经济及产业进行深刻互动。

导读 在软件开发过程中，调试是必不可少的环节，嵌入式操作系统的调试与桌面操作系统的调试相比有很大差异，嵌入式零碎的可视化调试能力比桌面操作系统要弱一点。对于导航这种业务场景比较复杂的程序开发，可视化调试环境能让咱们业务场景开发事倍功半，也能疾速定位导航业务与车机中其余模块交互呈现的问题，进步开发过程中的调试效率。 近程调试是真机调试中最便捷的一种，开发者只需借用在PC端弱小的调试器就能实现业务场景的调试。 背景 Thrift是一种接口描述语言和二进制通信协定，它被用来定义和创立跨语言的服务，是一种RPC（近程过程调用）通信框架，由Facebook为“大规模跨语言服务开发”。在车机系统中，各模块之间也能够应用Thrift通信框架进行通信。导航作为一个独自的为过程提供服务的模块，只提供导航相干的业务以及地图渲染的能力，导航的HMI界面是车机系统中对立的操作界面，零碎HMI界面与导航之间的交互接口则是通过曾经定义好的接口描述语言（IDL），应用自动化工具生成本地可调用的接口，而后应用Thrift框架传输实现零碎HMI与导航之间的通信。   调试伎俩 为了开发过程中调试不便，咱们在PC上做了一套模拟器，能在PC上进行地图渲染。还实现了一套在PC上应用的零碎HMI模仿命令发送工具，模仿工具是作为客户端连贯导航提供的服务，这样能在PC端模仿发送命令，帮忙导航简略业务的开发，但这种形式存在着以下弊病： 模仿命令工具，只能模仿简略的业务场景，有多个交互的场景无奈模仿。无奈操作地图HMI，也看不到HMI界面显示以及过程中的反馈。无奈滚动地图，前面接了Win32下面的鼠标事件，能用鼠标实现滚动，但这种形式与车机中滚动流程不统一。 PC端无奈应用车机中的设施，如导航过程中没有导航音，无奈应用USB等。 PC端拿不到车机中的数据，比方车身数据、GPS信号等。调试计划优化 针对以后调试伎俩存在的以上问题。咱们对调试计划进行了优化，咱们能够借助车机中零碎HMI来与导航进行交互。实现了应用车机环境中的信号对PC端导航业务场景进行调试。次要有以下几点性能： 1.PC端模拟器接管车机发来的信号 在该我的项目中，导航的相干业务都是作为服务端向车机中其余模块提供服务，在车机系统中，零碎HMI连贯导航服务的地址是固定的，咱们在车机中开发了一个代理--Sandwich，次要作用是启动导航服务，这个导航服务并不实现真正的导航业务，而是启动了一个空服务，让车机中其余模块能胜利建设连贯，同时Sandwich作为客户端连贯PC端模拟器提供的导航服务，PC端的导航服务真正实现导航业务，Sandwich负责接管车机发送过去的业务申请，并将申请转发给PC端模拟器，这样PC端模拟器就能接管到车机中的信号，收到的业务申请并做解决再将处理结果通过Thrift反馈到车机端。 这个流程咱们买通了车机中信号发送到PC端模拟器，并能够将解决完的数据反馈给车机端。    2.PC端模拟器向车机发送信号 导航也须要连贯车机中其余模块提供的服务，如，获取车身数据、获取GPS定位信号，将导航语音数据发送到车机语音播放模块等。 PC端模拟器须要作为客户端来连贯车机中的服务，真正连贯的是车机中Sandwich提供的服务，Sandwich作为客户端连贯车机中其余模块的服务，比方Sandwich连贯Sound模块，GPS模块，CarData模块等。PC端模拟器须要应用车机设备播放导航音，须要将播放内容发送给Sandwich，Sandwich收到播放内容后，再发送给车机中的Sound模块，导航音就能播放了。PC端连贯车机中其余模块的工作原理也是一样。   3. 将PC端模拟器中显示的地图投射到车机端显示 实现了以上两步，一个应用车机信号调试PC端导航程序的环境根本实现了。曾经能实现车机信号与PC进行双向接管，然而此时导航的渲染能力还是停留在PC端，车机中还只是显示了一个零碎HMI界面，无奈看到导航地图展示的成果，这样就会带来一个问题，一些须要强依赖地图的操作可能就无奈精准操作，比方点击地图上某个POI等。此时须要将PC端的展示同步到车机侧。 要实现这一目标，个别咱们有两种办法： 车机与PC同步渲染车机中的导航失常运行，当导航接管到零碎模块业务申请时，先是车机导航进行解决，处理完毕后将信号转发到PC端解决，这种计划两端导航业务逻辑并行运行，简单的业务场景下，两端会同时跟车机进行交互，此时可能会产生互斥，会有两端逻辑不同步的场景，达不到预期成果。 将车机中渲染的数据投射到车机端在这里咱们能够将PC上程序每渲染一帧地图则将后果传到车机端，由车机端Sandwich负责接管，当Sandwich接管到一帧地图像素数据后，负责将此帧数据渲染到车机屏幕上，此时车机中出现的成果跟PC端统一。在该我的项目中咱们采纳了这一计划，这种计划中，真正的导航业务逻辑是来自PC端，车机中只是一个转发过程，所以不会存在第一种计划中的问题。   但在某些特定的环境下，导航描绘会很频繁，发送给车机的数据也会很多，频繁的数据发送可能会带来肯定的性能开销，体现上可能会呈现提早。这里能够应用升高图像品质来缩小图像数据，例如，能够应用16位或者8位BMP来传输，还能够压缩传输，这样1920*720分辨率图像传输大小能管制在30-50k左右。 小结 基于车机系统中Thrift通信框架，实现的这套近程调试计划，本质是在车机中应用Sandwich程序接管车机系统中与导航有交互的全副接口解决，通过RPC通信转发，实现了应用实在车机信号调试导航的目标。有了这套调试环境，咱们甚至能够间接在真车上边路测边调试，跟以前的路测拿Log回来剖析、重现相比，整个调试过程，简略，便捷，直观。大大提高了开发效率。 基于RPC通信的个性，咱们还能够对调试计划再进一步优化，能够退出多客户端调试性能，应用同一台车机环境，不同的模块负责人能够同时进行简单业务场景的联结调试。  

导读：丰盛精确的地图数据大大晋升了咱们在应用高德地图出行的体验。相比于传统的地图数据采集和制作，高德地图大量采纳了图像识别技术来进行数据的自动化生产，而其中场景文字辨认技术占据了重要地位。商家招牌上的艺术字、LOGO形形色色，文字背景简单或被遮挡，拍摄的图像品质差，如此简单的场景下，如何解决文字辨认技术全、准、快的问题？本文分享文字辨认技术在高德地图数据生产中的演进与实际，介绍了文字辨认自研算法的次要倒退历程和框架，以及将来的倒退和挑战。 一  背景 作为一个DAU过亿的国民级软件，高德地图每天为用户提供海量的查问、定位和导航服务。地图数据的丰富性和准确性决定了用户体验。传统的地图数据的采集和制作过程，是在数据采集设施实地采集的根底上，再对采集材料进行人工编辑和上线。这样的模式下，数据更新慢、加工成本高。为解决这一问题，高德地图采纳图像识别技术从采集材料中间接辨认地图数据的各项因素，实现用机器代替人工进行数据的自动化生产。通过对事实世界高频的数据采集，使用图像算法能力，在海量的采集图片库中自动检测辨认出各项地图因素的内容和地位，构建出实时更新的根底地图数据。而根底地图数据中最为重要的是POI（Point of Interest）和路线数据，这两种数据能够构建出高德地图的底图，从而承载用户的行为与商家的动态数据。 图像识别能力决定了数据自动化生产的效率，其中场景文字辨认技术占据了重要地位。不同采集设施的图像信息都须要通过场景文字辨认（Scene Text Recognition，STR）取得文字信息。这要求咱们致力于解决场景文字辨认技术全、准、快的问题。在POI业务场景中，辨认算法不仅须要尽可能多的辨认街边新开商铺的文字信息， 还须要从中找出领有99%以上准确率的辨认后果，从而为POI名称的自动化生成铺平道路；在路线自动化场景中，辨认算法须要发现路线标志牌上轻微的变动，日解决海量回传数据，从而及时更新路线的限速、方向等信息。与此同时，因为采集起源和采集环境的复杂性，高德场景文字辨认算法面对的图像情况往往简单的多。次要体现为： 文字语言、字体、排版丰盛：商家招牌上的艺术字体，LOGO形形色色，排版模式各式各样。文字背景简单：文字呈现的背景简单，可能有较大的遮挡，简单的光照与烦扰。图像起源多样：图像采集自低成本的众包设施，成像设施参数不一，拍摄品质差。图像往往存在歪斜、失焦、抖动等问题。因为算法的辨认难度和辨认需要的复杂性，已有的文本辨认技术不能满足高德高速倒退的业务须要，因而高德自研了场景文字辨认算法，并迭代多年，为多个产品提供辨认能力。 二  文字辨认技术演进与实际 STR算法倒退次要历程 场景文字辨认（STR）的倒退大抵能够分为两个阶段，以2012年为分水岭，别离是传统图像算法阶段和深度学习算法阶段。 传统图像算法 2012年之前，文字辨认的支流算法都依赖于传统图像处理技术和统计机器学习办法实现，传统的文字识别方法能够分为图像预处理、文字辨认、后处理三个阶段： 图像预处理：实现文字区域定位，文字改正，字符切割等解决，核心技术包含连通域剖析，MSER，仿射变换，图像二值化，投影剖析等；文字辨认：对切割出的文字进行辨认，个别采纳提取人工设计特色（如HOG特色等）或者CNN提取特色，再通过机器学习分类器（如SVM等）进行辨认；后处理：利用规定，语言模型等对辨认后果进行改正。  传统的文字识别方法，在简略的场景下能达到不错的成果，然而不同场景下都须要独立设计各个模块的参数，工作繁琐，遇到简单的场景，难以设计出泛化性能好的模型。 深度学习算法 2012年之后，随着深度学习在计算机视觉畛域利用的不断扩大，文字辨认逐步摈弃了原有办法，过渡到深度学习算法计划。在深度学习时代，文字辨认框架也逐步简化，目前支流的计划次要有两种，一种是文本行检测与文字辨认的两阶段计划，另一种是端到端的文字辨认计划。 1）两阶段文字辨认计划 次要思路是先定位文本行地位，而后再对曾经定位的文本行内容进行辨认。文本行检测从办法角度次要分为基于文本框回归的办法，基于宰割或实例宰割的办法，以及基于回归、宰割混合的办法，从检测能力上也由开始的多向矩形框倒退到多边形文本，当初的热点在于解决任意形态的文本行检测问题。文本辨认从单字检测辨认倒退到文本序列辨认，目前序列辨认次要又分为基于CTC的办法[4]和基于Attention的办法。 2）端到端文字辨认计划 通过一个模型同时实现文本行检测和文本辨认的工作，既能够进步文本辨认的实时性，同时因为两个工作在同一个模型中联结训练，两局部工作能够互相促进成果。 文字辨认框架 高德文字辨认技术通过多年的倒退，曾经有过几次大的降级。从最开始的基于FCN宰割、单字检测辨认的计划，逐步演进到现有基于实例宰割的检测，再进行序列、单字检测辨认联合的计划。与学术界不同，咱们没有采纳End-to-End的辨认框架，是因为业务的事实需要所决定的。End-to-End框架往往须要足够多高质量的文本行及其辨认后果的标注数据，然而这一标注的老本是极为昂扬的，而合成的虚构数据并不足以代替实在数据。因而将文本的检测与辨认拆分开来，有利于别离优化两个不同的模型。 如下图所示，目前高德采纳的算法框架由文本行检测、单字检测辨认、序列辨认三大模块形成。文本行检测模块负责检测出文字区域，并预测出文字的掩模用于解决文本的竖直、畸变、蜿蜒等失真问题，序列辨认模块则负责在检测出的文字区域中，辨认出相应的文字，对于艺术文本、非凡排列等序列辨认模型成果较差的场景，应用单字检测辨认模型进行补充。 文字辨认框架 文本行检测 天然场景中的文字区域通常是多变且不规则的，文本的尺度大小各异，成像的角度和成像的品质往往不受管制。同时不同采集起源的图像中文本的尺度变动较大，含糊遮挡的状况也各不相同。咱们依据试验，决定在两阶段的实例宰割模型的根底上，针对实际问题进行了优化。 文本行检测可同时预测文字区域分割后果及文字行地位信息，通过集成DCN来获取不同方向的文本的特色信息，增大mask分支的feature大小并集成ASPP模块，晋升文字区域分割的精度。并通过文本的宰割后果生成最小外接凸包用于后续的辨认计算。在训练过程中，应用online的数据增广办法，在训练过程中对数据进行旋转、翻转、mixup等，无效的进步了模型的泛化能力。具体检测成果如下所示： 检测后果示例 目前场景文本检测能力曾经广泛应用于高德POI、路线等多个产品中，为了验证模型能力，别离在ICDAR2013(2018年3月)、ICDAR2017-MLT(2018年10月)、ICDAR2019-ReCTS公开数据集中进行验证，并获得了优异的问题。 文本行检测比赛问题 文字辨认 依据背景的形容，POI和路线数据自动化生产对于文字辨认的后果有两方面的需要，一方面是心愿文本行内容尽可能残缺辨认，另外一方面对于算法给出的后果能辨别出极高准确率的局部（准确率大于99%）。不同于个别文字辨认评测以单字为维度，咱们在业务应用中，更关注于整个文本行的辨认后果，因而咱们定义了合乎业务应用需要的文字辨认评估规范： 文本行辨认全对率：示意文字辨认正确且读序正确的文本行在所有文本行的占比。文本行辨认高相信占比：示意辨认后果中的高置信度局部（准确率大于99%）在所有文本行的占比。文本行辨认全对率次要评估文字辨认在POI名称，路线名称的整体辨认能力，文本行辨认高相信占比次要评估算法对于拆分出辨认高准确率局部的能力，这两种能力与咱们的业务需要严密相干。为了满足业务场景对文字辨认的需要，咱们针对目前支流的文字辨认算法进行了调研和选型。 文字辨认倒退到当初次要有两种办法，别离是单字检测辨认和序列辨认。单字检测辨认的训练样本组织和模型训练绝对容易，不被文字排版的程序影响。毛病在某些"高低构造"，"左右构造"的汉字容易检测辨认谬误。相比之下序列辨认蕴含更多的上下文信息，而且不须要定位单字准确的地位，减小因为汉字结构导致的辨认损失。然而事实场景文本的排版简单，"从上到下"，"从左到右"排版会导致序列辨认成果不稳固。联合单字检测辨认和序列辨认各自的优缺点，采纳互补的形式进步文字辨认的准确率。 单字检测辨认和序列辨认后果交融 1）单字检测辨认 单字检测采纳Faster R-CNN的办法，检测成果满足业务场景需要。单字辨认采纳SENet构造，字符类别反对超过7000个中英文字符和数字。在单字辨认模型中参考identity mapping的设计和MobileNetV2的构造，对Skip Connections和激活函数进行了优化，并在训练过程中也退出随机样本变换，大幅晋升文字辨认的能力。在2019年4月，为了验证在文字辨认的算法能力，咱们在ICDAR2019-ReCTS文字辨认比赛中取得第二名的问题（准确率与第一名相差0.09%）。 单字检测辨认效果图 2）文本序列辨认 近年来，支流的文本序列辨认算法如Aster、DTRT等，能够合成为文字区域纠正，文字区域特征提取、序列化编码图像特色和文字特色解码四个子工作。文字区域纠正和文字区域特征提取将变形的文本行纠正为程度文本行并提取特色，升高了后续辨认算法的辨认难度。序列化编码图像特色和文字特色解码（Encoder-Decoder的构造）能在利用图像的纹理特色进行文字辨认的同时，引入较强的语义信息，并利用这种上下文的语义信息来补全辨认后果。 通用序列辨认构造 在理论利用中，因为被辨认的指标次要以天然场景的短中文本为主，场景文本的几何畸变、扭曲、含糊水平极为重大。同时心愿在一个模型中辨认多个方向的文本，因而咱们采纳的是的TPS-Inception-BiLSTM-Attention构造来进行序列辨认。次要构造如下所示： 文本序列辨认模型 对于被检测到的文本行，基于角点进行透视变换，再应用TPS变换取得程度、竖直方向的文本，按比例缩放长边到指定大小，并以灰色为背景padding为方形图像。这一预处理形式既放弃了输出图像语义的残缺，同时在训练和测试阶段，图像能够在方形范畴内自在的旋转平移，可能无效的进步蜿蜒、畸变文本的辨认性能。将预处理实现的图像输出CNN中提取图像特色。再应用BiLSTM编码成序列特色，并应用Attention顺次解码取得预测后果。如下图所示，这一模型通过注意力机制在不同解码阶段赋予图像特色不同的权重，从而隐式表白预测字符与特色的对齐关系，实现在一个模型中同时预测多个方向文本。文本序列辨认模型目前已笼罩英文、中文一级字库和罕用的繁体字字库，对于艺术文本、含糊文本具备较好的辨认性能。 序列辨认成果 3）样本开掘&合成 在地图数据生产业务中常常会在路线标志牌中发现一些生僻的地点名称或者在POI牌匾中发现一些不常见的字甚至是繁体字，因而在文字辨认成果优化中，除了对于模型的优化外，正当补充缺字、少字的样本也是十分重要的环节。为了补充缺字、少字的样本，咱们从实在样本开掘和人工样本合成两个方向动手，一方面联合咱们业务的特点，通过数据库中曾经实现制作的蕴含生僻字的名称，反向挖掘出可能呈现生僻字的图像进行人工标注，另一方面，咱们利用图像渲染技术人工合成文字样本。理论应用中，将实在样本和人工合成样本混合应用，大幅晋升文字辨认能力。 样本开掘和合成计划 文字辨认技术小结 高德文字辨认算法通过对算法构造的打磨，和多辨认后果的交融，满足不同应用场景的事实须要。同时以文字辨认为代表的计算机视觉技术，已广泛应用于高德数据自动化生产的各个角落，在局部采集场景中，机器已齐全代替人工进行数据的自动化生产。POI数据中超过70%的数据都是由机器自动化生成上线，超过90%的路线信息数据通过自动化更新。数据工艺人员的技能极大简化，大幅节约了培训老本和收入开销。 ...

简介： 丰盛精确的地图数据大大晋升了咱们在应用高德地图出行的体验。相比于传统的地图数据采集和制作，高德地图大量采纳了图像识别技术来进行数据的自动化生产，而其中场景文字辨认技术占据了重要地位。商家招牌上的艺术字、LOGO形形色色，文字背景简单或被遮挡，拍摄的图像品质差，如此简单的场景下，如何解决文字辨认技术全、准、快的问题？本文分享文字辨认技术在高德地图数据生产中的演进与实际，介绍了文字辨认自研算法的次要倒退历程和框架，以及将来的倒退和挑战。 一 背景作为一个DAU过亿的国民级软件，高德地图每天为用户提供海量的查问、定位和导航服务。地图数据的丰富性和准确性决定了用户体验。传统的地图数据的采集和制作过程，是在数据采集设施实地采集的根底上，再对采集材料进行人工编辑和上线。这样的模式下，数据更新慢、加工成本高。为解决这一问题，高德地图采纳图像识别技术从采集材料中间接辨认地图数据的各项因素，实现用机器代替人工进行数据的自动化生产。通过对事实世界高频的数据采集，使用图像算法能力，在海量的采集图片库中自动检测辨认出各项地图因素的内容和地位，构建出实时更新的根底地图数据。而根底地图数据中最为重要的是POI（Point of Interest）和路线数据，这两种数据能够构建出高德地图的底图，从而承载用户的行为与商家的动态数据。 图像识别能力决定了数据自动化生产的效率，其中场景文字辨认技术占据了重要地位。不同采集设施的图像信息都须要通过场景文字辨认（Scene Text Recognition，STR）取得文字信息。这要求咱们致力于解决场景文字辨认技术全、准、快的问题。在POI业务场景中，辨认算法不仅须要尽可能多的辨认街边新开商铺的文字信息， 还须要从中找出领有99%以上准确率的辨认后果，从而为POI名称的自动化生成铺平道路；在路线自动化场景中，辨认算法须要发现路线标志牌上轻微的变动，日解决海量回传数据，从而及时更新路线的限速、方向等信息。与此同时，因为采集起源和采集环境的复杂性，高德场景文字辨认算法面对的图像情况往往简单的多。次要体现为： 文字语言、字体、排版丰盛：商家招牌上的艺术字体，LOGO形形色色，排版模式各式各样。文字背景简单：文字呈现的背景简单，可能有较大的遮挡，简单的光照与烦扰。图像起源多样：图像采集自低成本的众包设施，成像设施参数不一，拍摄品质差。图像往往存在歪斜、失焦、抖动等问题。因为算法的辨认难度和辨认需要的复杂性，已有的文本辨认技术不能满足高德高速倒退的业务须要，因而高德自研了场景文字辨认算法，并迭代多年，为多个产品提供辨认能力。 二 文字辨认技术演进与实际STR算法倒退次要历程场景文字辨认（STR）的倒退大抵能够分为两个阶段，以2012年为分水岭，别离是传统图像算法阶段和深度学习算法阶段。 传统图像算法 2012年之前，文字辨认的支流算法都依赖于传统图像处理技术和统计机器学习办法实现，传统的文字识别方法能够分为图像预处理、文字辨认、后处理三个阶段： 图像预处理：实现文字区域定位，文字改正，字符切割等解决，核心技术包含连通域剖析，MSER，仿射变换，图像二值化，投影剖析等；文字辨认：对切割出的文字进行辨认，个别采纳提取人工设计特色（如HOG特色等）或者CNN提取特色，再通过机器学习分类器（如SVM等）进行辨认；后处理：利用规定，语言模型等对辨认后果进行改正。传统的文字识别方法，在简略的场景下能达到不错的成果，然而不同场景下都须要独立设计各个模块的参数，工作繁琐，遇到简单的场景，难以设计出泛化性能好的模型。 深度学习算法 2012年之后，随着深度学习在计算机视觉畛域利用的不断扩大，文字辨认逐步摈弃了原有办法，过渡到深度学习算法计划。在深度学习时代，文字辨认框架也逐步简化，目前支流的计划次要有两种，一种是文本行检测与文字辨认的两阶段计划，另一种是端到端的文字辨认计划。 1）两阶段文字辨认计划 次要思路是先定位文本行地位，而后再对曾经定位的文本行内容进行辨认。文本行检测从办法角度次要分为基于文本框回归的办法[1]，基于宰割或实例宰割的办法[2]，以及基于回归、宰割混合的办法[3]，从检测能力上也由开始的多向矩形框倒退到多边形文本[2]，当初的热点在于解决任意形态的文本行检测问题。文本辨认从单字检测辨认倒退到文本序列辨认，目前序列辨认次要又分为基于CTC的办法[4]和基于Attention的办法[5]。 2）端到端文字辨认计划[6] 通过一个模型同时实现文本行检测和文本辨认的工作，既能够进步文本辨认的实时性，同时因为两个工作在同一个模型中联结训练，两局部工作能够互相促进成果。 文字辨认框架高德文字辨认技术通过多年的倒退，曾经有过几次大的降级。从最开始的基于FCN宰割、单字检测辨认的计划，逐步演进到现有基于实例宰割的检测，再进行序列、单字检测辨认联合的计划。与学术界不同，咱们没有采纳End-to-End的辨认框架，是因为业务的事实需要所决定的。End-to-End框架往往须要足够多高质量的文本行及其辨认后果的标注数据，然而这一标注的老本是极为昂扬的，而合成的虚构数据并不足以代替实在数据。因而将文本的检测与辨认拆分开来，有利于别离优化两个不同的模型。 如下图所示，目前高德采纳的算法框架由文本行检测、单字检测辨认、序列辨认三大模块形成。文本行检测模块负责检测出文字区域，并预测出文字的掩模用于解决文本的竖直、畸变、蜿蜒等失真问题，序列辨认模块则负责在检测出的文字区域中，辨认出相应的文字，对于艺术文本、非凡排列等序列辨认模型成果较差的场景，应用单字检测辨认模型进行补充。 文本行检测 天然场景中的文字区域通常是多变且不规则的，文本的尺度大小各异，成像的角度和成像的品质往往不受管制。同时不同采集起源的图像中文本的尺度变动较大，含糊遮挡的状况也各不相同。咱们依据试验，决定在两阶段的实例宰割模型的根底上，针对实际问题进行了优化。 文本行检测可同时预测文字区域分割后果及文字行地位信息，通过集成DCN来获取不同方向的文本的特色信息，增大mask分支的feature大小并集成ASPP模块，晋升文字区域分割的精度。并通过文本的宰割后果生成最小外接凸包用于后续的辨认计算。在训练过程中，应用online的数据增广办法，在训练过程中对数据进行旋转、翻转、mixup等，无效的进步了模型的泛化能力。具体检测成果如下所示： 目前场景文本检测能力曾经广泛应用于高德POI、路线等多个产品中，为了验证模型能力，别离在ICDAR2013(2018年3月)、ICDAR2017-MLT(2018年10月)、ICDAR2019-ReCTS公开数据集中进行验证，并获得了优异的问题。 文字辨认 依据背景的形容，POI和路线数据自动化生产对于文字辨认的后果有两方面的需要，一方面是心愿文本行内容尽可能残缺辨认，另外一方面对于算法给出的后果能辨别出极高准确率的局部（准确率大于99%）。不同于个别文字辨认评测以单字为维度，咱们在业务应用中，更关注于整个文本行的辨认后果，因而咱们定义了合乎业务应用需要的文字辨认评估规范： 文本行辨认全对率：示意文字辨认正确且读序正确的文本行在所有文本行的占比。文本行辨认高相信占比：示意辨认后果中的高置信度局部（准确率大于99%）在所有文本行的占比。文本行辨认全对率次要评估文字辨认在POI名称，路线名称的整体辨认能力，文本行辨认高相信占比次要评估算法对于拆分出辨认高准确率局部的能力，这两种能力与咱们的业务需要严密相干。为了满足业务场景对文字辨认的需要，咱们针对目前支流的文字辨认算法进行了调研和选型。 文字辨认倒退到当初次要有两种办法，别离是单字检测辨认和序列辨认。单字检测辨认的训练样本组织和模型训练绝对容易，不被文字排版的程序影响。毛病在某些"高低构造"，"左右构造"的汉字容易检测辨认谬误。相比之下序列辨认蕴含更多的上下文信息，而且不须要定位单字准确的地位，减小因为汉字结构导致的辨认损失。然而事实场景文本的排版简单，"从上到下"，"从左到右"排版会导致序列辨认成果不稳固。联合单字检测辨认和序列辨认各自的优缺点，采纳互补的形式进步文字辨认的准确率。 1）单字检测辨认 单字检测采纳Faster R-CNN的办法，检测成果满足业务场景需要。单字辨认采纳SENet构造，字符类别反对超过7000个中英文字符和数字。在单字辨认模型中参考identity mapping的设计和MobileNetV2的构造，对Skip Connections和激活函数进行了优化，并在训练过程中也退出随机样本变换，大幅晋升文字辨认的能力。在2019年4月，为了验证在文字辨认的算法能力，咱们在ICDAR2019-ReCTS文字辨认比赛中取得第二名的问题（准确率与第一名相差0.09%）。 2）文本序列辨认 近年来，支流的文本序列辨认算法如Aster、DTRT等，能够合成为文字区域纠正，文字区域特征提取、序列化编码图像特色和文字特色解码四个子工作。文字区域纠正和文字区域特征提取将变形的文本行纠正为程度文本行并提取特色，升高了后续辨认算法的辨认难度。序列化编码图像特色和文字特色解码（Encoder-Decoder的构造）能在利用图像的纹理特色进行文字辨认的同时，引入较强的语义信息，并利用这种上下文的语义信息来补全辨认后果。 在理论利用中，因为被辨认的指标次要以天然场景的短中文本为主，场景文本的几何畸变、扭曲、含糊水平极为重大。同时心愿在一个模型中辨认多个方向的文本，因而咱们采纳的是的TPS-Inception-BiLSTM-Attention构造来进行序列辨认。次要构造如下所示： 对于被检测到的文本行，基于角点进行透视变换，再应用TPS变换取得程度、竖直方向的文本，按比例缩放长边到指定大小，并以灰色为背景padding为方形图像。这一预处理形式既放弃了输出图像语义的残缺，同时在训练和测试阶段，图像能够在方形范畴内自在的旋转平移，可能无效的进步蜿蜒、畸变文本的辨认性能。将预处理实现的图像输出CNN中提取图像特色。再应用BiLSTM编码成序列特色，并应用Attention顺次解码取得预测后果。如下图所示，这一模型通过注意力机制在不同解码阶段赋予图像特色不同的权重，从而隐式表白预测字符与特色的对齐关系，实现在一个模型中同时预测多个方向文本。文本序列辨认模型目前已笼罩英文、中文一级字库和罕用的繁体字字库，对于艺术文本、含糊文本具备较好的辨认性能。 3）样本开掘&合成 在地图数据生产业务中常常会在路线标志牌中发现一些生僻的地点名称或者在POI牌匾中发现一些不常见的字甚至是繁体字，因而在文字辨认成果优化中，除了对于模型的优化外，正当补充缺字、少字的样本也是十分重要的环节。为了补充缺字、少字的样本，咱们从实在样本开掘和人工样本合成两个方向动手，一方面联合咱们业务的特点，通过数据库中曾经实现制作的蕴含生僻字的名称，反向挖掘出可能呈现生僻字的图像进行人工标注，另一方面，咱们利用图像渲染技术人工合成文字样本。理论应用中，将实在样本和人工合成样本混合应用，大幅晋升文字辨认能力。 文字辨认技术小结高德文字辨认算法通过对算法构造的打磨，和多辨认后果的交融，满足不同应用场景的事实须要。同时以文字辨认为代表的计算机视觉技术，已广泛应用于高德数据自动化生产的各个角落，在局部采集场景中，机器已齐全代替人工进行数据的自动化生产。POI数据中超过70%的数据都是由机器自动化生成上线，超过90%的路线信息数据通过自动化更新。数据工艺人员的技能极大简化，大幅节约了培训老本和收入开销。 三 将来倒退和挑战目前高德次要依赖深度学习的形式解决场景文字的辨认问题，绝对国外地图数据，国内汉字的基数大，文字结构复杂导致对数据多样性的要求更高，数据有余成为次要痛点。另外，图像的含糊问题往往会影响自动化辨认的性能和数据的制作效率，如何辨认含糊和对含糊的解决也是高德的研究课题之一。咱们别离从数据，模型设计层面论述如何解决数据有余和含糊辨认的问题，以及如何进一步提高文字辨认能力。 数据层面数据问题很重要，在没有足够的人力物力标注的状况下，如何主动裁减数据是图像的一个通用研究课题。其中一个思路是通过数据增广的形式裁减数据样本。Google DeepMind在CVPR 2019提出AutoAugment的办法, 次要通过用强化学习的办法寻找最佳的数据增广策略。另一种数据裁减的解决办法是数据合成，例如阿里巴巴达摩院的SwapText利用格调迁徙的形式实现数据生成。 模型层面含糊文本的辨认 含糊通常造成场景辨认文本未检测和无奈辨认的问题。在学术界超分辨率是解决含糊问题的次要形式之一，TextSR通过SRGAN对文本超分的形式，还原高清文本图像，解决含糊辨认的问题。比照TextSR，首尔大学和马萨诸塞大学在Better to Follow文中提出通过GAN对特色的超分辨率形式，没有间接生成新的图像而是将超分辨率网络集成在检测网络中，在成果靠近的同时，因为其采纳End-to-End的模式，计算效率大幅提高。 文字语义了解 通常人在了解简单文字时会参考肯定的语义先验信息，近年来随着NLP（Natural Language Processing）技术的倒退，使得计算机也领有取得语义信息的能力。参考人了解简单文字的形式，如何利用语义的先验信息和图像的关系进步文字辨认能力是一个值得钻研的课题。例如SEED在CVPR 2020提出将语言模型增加到辨认模型中，通过图像特色和语义特色综合判断进步文字辨认能力。 ...

简介： 咱们开发选型并没有采纳传统的TTS技术（由文本内容生成机器语音），而是采纳了更加通用音频格式(比方mp3)，作为解说的音频输出源，不便解说者进行二次创作。本文将简略回顾高德智慧景区随身听播放器的框架设计与实现。 一、背景 “远看山有色，近听水‘有’声”，景区语音导览是智慧景区重点业务之一，以用地图能够边走边听景区各景点的语音介绍为次要诉求，实现高德智慧景区地图不仅能够看，还能够听，从而使用户交互体验失去跨越式进步。 咱们想要让“技术有温度”，让解说更加有感情和外延，最好能够通过解说结构一个“UGC景区解说生态圈”，并且还能帮忙解说创作者有肯定的收益，以达到“生态圈的正向循环”，让线上向导“天下没有难做的生意”。 试想一下，当游客走进故宫，这时，高德地图的语音包能够播放：“故宫有180万件宝贝，青铜馆、陶瓷馆……”这段话的解说人，是驰名收藏家、古董鉴赏家马未都，是不是更加吸引你关注？另外，当你散步到延禧宫，语音包则会立即讲一讲延禧宫与大热的电视剧《延禧攻略》有什么关系，并且有背景音插入，是如许活泼形象。 所以，咱们开发选型并没有采纳传统的TTS技术（由文本内容生成机器语音），而是采纳了更加通用音频格式(比方mp3)，作为解说的音频输出源，不便解说者进行二次创作。本文将简略回顾高德智慧景区随身听播放器的框架设计与实现。 二、架构设计前思考 “夫未战而庙算胜者，得算多也；未战而庙算不胜者，得算少也”，拉开战斗尾声之前咱们应该尽量去“庙算”，提前预防和判断并保障技术危险可控，俗称“防火”。“防火”更能看出本事，而“救火”只是能力。开发应尽量做到“不打无筹备之仗”。 首先，如何晋升开发和后续迭代效率？此问题波及到是纯Native开发还是用跨平台混合技术开发。如果用纯Native，双端开发人力可能会使工作量翻倍，前期可维护性也差，常常须要双端同步拉齐。但纯Native开发声音相干的技术计划成熟且危险较小。而用跨平台混合技术开发，长处和毛病正好与单纯Native开发相同。通过小组屡次技术探讨，看长远利益，最终确定用跨平台技术计划，用该计划尽管技术挑战和危险大（比方须要和跨平台架构撑持团队一起“无中生有”的去买通JS的播放链路和各种音频中断能力回调等），但这个计划有个强有力的益处，就是能够“Write Once, Run Everywhere”（这里的Everywhere次要是指挪动端操作系统），这样能够人造的拉齐双端业务代码能力，大大节约开发周期和人力，对业务疾速性能迭代很有劣势，再苦再累再难也值得为此致力。 其次，如何节俭CPU和内存资源？做挪动开发的同学都晓得，音频播放是耗零碎软硬件资源的（比方CPU、内存还有电量等），另外音频播放不仅仅是波及到单个App的事件，还波及到第三方App音频播放的影响（比方零碎复电声音焦点抢占，其余音乐App播放焦点抢占问题等）。 所以，业务层开发，要对底层播放器提供的播放能力进行二次封装，一是要管制播放器实例的随便创立。二是要解决各第三方App的音频播放焦点的申请和开释等逻辑业务。由此可见，搭建一个通用的业务播放器框架势在必行，受害良多。 再次，如何使业务与音频自身的播放框架能力隔离？业务多变，而音频播放能力相对来说是稳固的，其根本能力包含但不局限于（首次&续接）播放，暂停，抢占，打断，音量调节（慢慢变强），物理（如耳机）按键响应，打断后场景复原，缓存，预加载，强弱网络和播放异样等。这些音频自身的技术能力，最好应该是和纯业务是解耦的，尽量做到“高内聚，低耦合”。 起初，通过三思而行，咱们认为设计模式中的“ObserverPattern观察者模式”，比拟切合这一技术背景。纯业务和音频框架自身制订通用的接口协议，而后纯业务自在注册监听器到音频播放框架中，依据关怀的回调事件自在解决本人的业务，而音频框架自身只做次要的焦点抢占，现场复原和事件散发等事件，十分合乎SRP准则（繁多职责），后续调试和保护都很不便。 最初，如何实现跨Page播放能力？如下图所示： 随身听很多业务是有跨Page播放要求的，如果将播放能力间接提供进去，由各个页面的Page本人保护，势必会生出很多的Audio，凌乱而且页面互相通信替换信息老本高。后通过探讨，就有了如下图的架构形式设计： 联合跨平台底层播放器的个性，虚构进去一个BizService放在跨平台框架的Service容器（和安卓外面的Service概念差不多，提供一个无界面的能够解决公共业务的容器）外面，解决Page页面业务管理和信息替换以及缓存治理，BizService只和BizVoiceMediaCenter交互治理音频数据，也就是说BizVoiceMediaCenter是通用播放器框架对外一个"门面"（Facade门面设计模式）。BizVoiceMediaCenter外面会有且仅有一个VoiceMediaAlbum实例（播放专辑，提供“上一曲”，“下一曲”，程序播放，续播等能力）。 三、架构设计和开发 首先，咱们先简略看下跨平台底层播放器的生命周期，如下图所示： 相熟Native开发的同学应该晓得，跨平台底层播放器的架构和生命周期，和Android自身零碎播放器十分类似，差别点是音频焦点被抢占和复原的回调局部，iOS设施是onInterrupted，当音频被其余利用打断开始时回调，如电话铃声响起触发此回调（在此回调中保留播放器状态，以便在onInterruptedEnd回调中复原播放）。onInterruptedEnd，当音频被其余利用打断完结时回调，如挂断后触发此回调。而Android是onFocusChanged，当音频焦点变动后回调。当然还有其它一些细微差别，比方双端，播放错误码不统一，播放异样超时逻辑不统一等。但这些都能够通过在业务层构建本人VoiceMediaPlayer来拉齐以及解决通用音频焦点抢占和失落场景的逻辑。 通过下面剖析，咱们能够大体搭出如下图业务播放器的整体框架图(图中箭头示意数据流的方向)。 咱们能够很容易的看出，业务对跨平台底层播放器Audio进行了二次封装为VoiceMediaPlayer，拉齐和解决通用业务场景（比方抢焦点，播放，现场复原，播放异样，蓝牙或耳机物理按键响应等）。 VoiceMediaPlayer再下层是VoiceMediaAlbum（播放专辑），VoiceMediaAlbum专辑类，次要是解决程序播放，上一曲，下一曲，整个专辑播放事件（单曲播放信息和进度，整体播放进度透出，主动切换程序，循环或业务指定下一曲播放等），VoiceMediaAlbum和业务层的BizVoiceMediaCenter打交道，当然BizVoiceMediaCenter也能够间接和VoiceMediaPlayer打交道，但咱们个别不倡议这么做，即使是就播放一首音频，咱们也心愿，把这首音频当成一个专辑来包装和调用（随身听业务也的确是这么做的)，这样更加标准和不便当前扩大。 最初，咱们来看看整体架构的具体类设计图，如下图所示： 四、落地产出 高德智慧景区随身听播放器框架实现后，很好的撑持了随身听后续版本的开发。此外，后续因业务需要对产品做了屡次迭代和变更，但播放器的架构简直不须要做很大调整和降级（即便前面又减少了离线播放能力），很好验证了其稳定性和可扩大能力。上面一系列图，咱们能够看出这颗“种子”(景区随身听播放器框架)，开出的漂亮的“花”，如下图所示： 以上各个页面底层都共用了这个播放器框架，很不便的实现了音频的跨页面播放和治理，以及异常中断的对立解决。高效满足了相干音频业务的播放能力要求，也为高德智慧景区随身听业务后续迭代开发打下了松软的地基。 舒适提醒： 由高德地图发动，阿里云天池平台作为撑持平台的AMAP-TECH算法大赛初赛曾经开启，赛题为基于车载视频图像的动静路况剖析，权威评委、丰富奖金、终面通道、荣誉证书，欢送大家参加，一起用技术帮忙更多人美妙出行! 初赛（7月8日-8月31日，UTC+8）。赛题详情及参赛链接： https://tianchi.aliyun.com/competition/entrance/531809/introduction

一、背景 “远看山有色，近听水‘有’声”，景区语音导览是智慧景区重点业务之一，以用地图能够边走边听景区各景点的语音介绍为次要诉求，实现高德智慧景区地图不仅能够看，还能够听，从而使用户交互体验失去跨越式进步。 咱们想要让“技术有温度”，让解说更加有感情和外延，最好能够通过解说结构一个“UGC景区解说生态圈”，并且还能帮忙解说创作者有肯定的收益，以达到“生态圈的正向循环”，让线上向导“天下没有难做的生意”。 试想一下，当游客走进故宫，这时，高德地图的语音包能够播放：“故宫有180万件宝贝，青铜馆、陶瓷馆……”这段话的解说人，是驰名收藏家、古董鉴赏家马未都，是不是更加吸引你关注？另外，当你散步到延禧宫，语音包则会立即讲一讲延禧宫与大热的电视剧《延禧攻略》有什么关系，并且有背景音插入，是如许活泼形象。 所以，咱们开发选型并没有采纳传统的TTS技术（由文本内容生成机器语音），而是采纳了更加通用音频格式(比方mp3)，作为解说的音频输出源，不便解说者进行二次创作。本文将简略回顾高德智慧景区随身听播放器的框架设计与实现。 二、架构设计前思考 “夫未战而庙算胜者，得算多也；未战而庙算不胜者，得算少也”，拉开战斗尾声之前咱们应该尽量去“庙算”，提前预防和判断并保障技术危险可控，俗称“防火”。“防火”更能看出本事，而“救火”只是能力。开发应尽量做到“不打无筹备之仗”。 首先，如何晋升开发和后续迭代效率？此问题波及到是纯Native开发还是用跨平台混合技术开发。如果用纯Native，双端开发人力可能会使工作量翻倍，前期可维护性也差，常常须要双端同步拉齐。但纯Native开发声音相干的技术计划成熟且危险较小。而用跨平台混合技术开发，长处和毛病正好与单纯Native开发相同。通过小组屡次技术探讨，看长远利益，最终确定用跨平台技术计划，用该计划尽管技术挑战和危险大（比方须要和跨平台架构撑持团队一起“无中生有”的去买通JS的播放链路和各种音频中断能力回调等），但这个计划有个强有力的益处，就是能够“Write Once, Run Everywhere”（这里的Everywhere次要是指挪动端操作系统），这样能够人造的拉齐双端业务代码能力，大大节约开发周期和人力，对业务疾速性能迭代很有劣势，再苦再累再难也值得为此致力。 其次，如何节俭CPU和内存资源？做挪动开发的同学都晓得，音频播放是耗零碎软硬件资源的（比方CPU、内存还有电量等），另外音频播放不仅仅是波及到单个App的事件，还波及到第三方App音频播放的影响（比方零碎复电声音焦点抢占，其余音乐App播放焦点抢占问题等）。 所以，业务层开发，要对底层播放器提供的播放能力进行二次封装，一是要管制播放器实例的随便创立。二是要解决各第三方App的音频播放焦点的申请和开释等逻辑业务。由此可见，搭建一个通用的业务播放器框架势在必行，受害良多。 再次，如何使业务与音频自身的播放框架能力隔离？业务多变，而音频播放能力相对来说是稳固的，其根本能力包含但不局限于（首次&续接）播放，暂停，抢占，打断，音量调节（慢慢变强），物理（如耳机）按键响应，打断后场景复原，缓存，预加载，强弱网络和播放异样等。这些音频自身的技术能力，最好应该是和纯业务是解耦的，尽量做到“高内聚，低耦合”。 起初，通过三思而行，咱们认为设计模式中的“ObserverPattern观察者模式”，比拟切合这一技术背景。纯业务和音频框架自身制订通用的接口协议，而后纯业务自在注册监听器到音频播放框架中，依据关怀的回调事件自在解决本人的业务，而音频框架自身只做次要的焦点抢占，现场复原和事件散发等事件，十分合乎SRP准则（繁多职责），后续调试和保护都很不便。 最初，如何实现跨Page播放能力？如下图所示： 随身听很多业务是有跨Page播放要求的，如果将播放能力间接提供进去，由各个页面的Page本人保护，势必会生出很多的Audio，凌乱而且页面互相通信替换信息老本高。后通过探讨，就有了如下图的架构形式设计： 联合跨平台底层播放器的个性，虚构进去一个BizService放在跨平台框架的Service容器（和安卓外面的Service概念差不多，提供一个无界面的能够解决公共业务的容器）外面，解决Page页面业务管理和信息替换以及缓存治理，BizService只和BizVoiceMediaCenter交互治理音频数据，也就是说BizVoiceMediaCenter是通用播放器框架对外一个"门面"（Facade门面设计模式）。BizVoiceMediaCenter外面会有且仅有一个VoiceMediaAlbum实例（播放专辑，提供“上一曲”，“下一曲”，程序播放，续播等能力）。 三、架构设计和开发 首先，咱们先简略看下跨平台底层播放器的生命周期，如下图所示： 相熟Native开发的同学应该晓得，跨平台底层播放器的架构和生命周期，和Android自身零碎播放器十分类似，差别点是音频焦点被抢占和复原的回调局部，iOS设施是onInterrupted，当音频被其余利用打断开始时回调，如电话铃声响起触发此回调（在此回调中保留播放器状态，以便在onInterruptedEnd回调中复原播放）。onInterruptedEnd，当音频被其余利用打断完结时回调，如挂断后触发此回调。而Android是onFocusChanged，当音频焦点变动后回调。当然还有其它一些细微差别，比方双端，播放错误码不统一，播放异样超时逻辑不统一等。但这些都能够通过在业务层构建本人VoiceMediaPlayer来拉齐以及解决通用音频焦点抢占和失落场景的逻辑。 通过下面剖析，咱们能够大体搭出如下图业务播放器的整体框架图(图中箭头示意数据流的方向)。   咱们能够很容易的看出，业务对跨平台底层播放器Audio进行了二次封装为VoiceMediaPlayer，拉齐和解决通用业务场景（比方抢焦点，播放，现场复原，播放异样，蓝牙或耳机物理按键响应等）。 VoiceMediaPlayer再下层是VoiceMediaAlbum（播放专辑），VoiceMediaAlbum专辑类，次要是解决程序播放，上一曲，下一曲，整个专辑播放事件（单曲播放信息和进度，整体播放进度透出，主动切换程序，循环或业务指定下一曲播放等），VoiceMediaAlbum和业务层的BizVoiceMediaCenter打交道，当然BizVoiceMediaCenter也能够间接和VoiceMediaPlayer打交道，但咱们个别不倡议这么做，即使是就播放一首音频，咱们也心愿，把这首音频当成一个专辑来包装和调用（随身听业务也的确是这么做的)，这样更加标准和不便当前扩大。 最初，咱们来看看整体架构的具体类设计图，如下图所示： 四、落地产出 高德智慧景区随身听播放器框架实现后，很好的撑持了随身听后续版本的开发。此外，后续因业务需要对产品做了屡次迭代和变更，但播放器的架构简直不须要做很大调整和降级（即便前面又减少了离线播放能力），很好验证了其稳定性和可扩大能力。上面一系列图，咱们能够看出这颗“种子”(景区随身听播放器框架)，开出的漂亮的“花”，如下图所示： 以上各个页面底层都共用了这个播放器框架，很不便的实现了音频的跨页面播放和治理，以及异常中断的对立解决。高效满足了相干音频业务的播放能力要求，也为高德智慧景区随身听业务后续迭代开发打下了松软的地基。  舒适提醒： 由高德地图发动，阿里云天池平台作为撑持平台的AMAP-TECH算法大赛初赛曾经开启，赛题为基于车载视频图像的动静路况剖析，权威评委、丰富奖金、终面通道、荣誉证书，欢送大家参加，一起用技术帮忙更多人美妙出行! 初赛（7月8日-8月31日，UTC+8）。赛题详情及参赛链接： https://tianchi.aliyun.com/co...

阿里巴巴高德地图AMAP-TECH算法大赛于7月8日开启初赛，赛题为「基于车载视频图像的动静路况剖析」，流动邀请了业界权威专家负责评委，优良选手不仅能够瓜分丰富的奖金，支付荣誉证书，还有机会进入高德地图【终面通道】！连忙邀请小伙伴一起来参赛吧。 报名请戳： https://tianchi.aliyun.com/co... 上面给大家介绍下大赛详情。 一、背景 高德地图每天会为用户提供海量的定位和路线导航布局服务，其所提供的路况状态信息（即道路交通是拥挤、疾驶还是畅通）的准确性会影响到用户在出行过程中的决策和体验。传统的路况状态次要依附驾车用户的轨迹信息生成。在用户少、驾驶行为异样的路线上，这种办法难以保障路况状态的准确性。 车载视频图像蕴含了更多的信息量，给了咱们另外一个解决问题的视角。通过视频或图片，能够察看到路面的实在状态，包含机动车数量、路线宽度和空阔度等等。基于车载视频图像能够获取更精确的路况状态，为用户出行提供更高质量的服务。 本赛题要求参赛者通过计算机视觉等人工智能算法，基于视频图像中辨认到的路面信息来判断路线通行状态，进步路线路况状态判断的准确性，从而晋升高德地图用户的出行体验。 二、赛题形容及数据阐明 术语阐明 路况：依据路线的均匀车速、路线等级，对路线上车辆通行状态的形容，分为畅通、疾驶、拥挤三个等级，在高德地图上显示为绿色、黄色、红色，如图1所示。 参考帧：存在图像序列内路况状态突变的状况，每个图像序列存在一幅参考帧图像，参考帧时刻的路况状态为该图像序列的真值路况状态。 图1. 路况状态示意图 问题定义 输出：给定一组含有GPS工夫的图像序列（蕴含3-5帧图像），其中一幅图像作为参考帧。 输入：以参考帧为准，输入该图像序列对应的路况状态（畅通、疾驶和拥挤）。 如下图所示，该序列蕴含3帧图像，其中第3帧图像为参考帧。算法须要基于整个序列，推断路况状态。当图像序列内的路况状态不统一时，以参考帧为准。 图2. 路况判断流程示意 图像序列由行车记录仪拍摄，路况真值（ground truth）是对应路线以后时刻实在的路况状态。大部分场景下，后方车辆的数量和密度决定了路况状态，然而也存在一些其余状况供参赛选手参考： 行驶路线存在大量路边停车，但不影响车辆行驶，理论路况状态为畅通。跟车间隔较近，前车遮挡视线内路线的状况，影响对以后路况的判断。行驶在双向路线，对向车道拥挤，行驶车道路况状态为疾驶或畅通。相机装置存在角度偏差，可能会影响路况判断。数据阐明 数据集分为预赛数据集和复赛数据集，预赛数据集先颁布，仅供预赛应用。复赛数据集等预赛完结后颁布，复赛中也能够应用预赛数据集。预赛数据集包含训练集和测试集。训练汇合有1500个序列、共约7000幅图像；测试汇合为600个序列、共约2800幅图像。预赛数据集蕴含不同等级的路线，蕴含高速路、城市快速路、一般路线等。路况真值类型的散布状况约为畅通70%、疾驶10%、拥挤20%。路况真值次要基于参考帧标注。路面车辆较多的状况下，在标注时联合了序列中其余帧的信息。 数据格式 数据组织是以图像序列为单位，每个文件夹蕴含参考帧和其前后相邻帧的图像序列，图像序列最多为5帧图像。 提供数据中蕴含以下信息： 图像序列的参考帧图像名。图像序列的路况状态。0：畅通，1：疾驶，2：拥挤，-1：测试集真值未给出。每帧图像采集时刻的GPS工夫。单位为秒。如GPS工夫 1552806926 比 1552806921 滞后5秒钟。提供JSON格局标注文件，具体数据格式示意如下： "status": 0 畅通，1 疾驶，2 拥挤，-1 未知（测试集默认状态为-1）{ "annotations": [ { "id": "000001", "key\_frame": "2.jpg", "status": 0, "frames": \[ { "frame\_name": "1.jpg", "gps\_time": 1552806921 }, { "frame\_name": "2.jpg", "gps\_time": 1552806926 }, { "frame\_name": "3.jpg", "gps\_time": 1552806931 }, { "frame\_name": "4.jpg", "gps\_time": 1552806936 } \] }, { "id": "000002", "key\_frame": "3.jpg", "status": 2, "frames": \[ { "frame\_name": "1.jpg", "gps\_time": 1555300555 }, { "frame\_name": "2.jpg", "gps\_time": 1555300560 }, { "frame\_name": "3.jpg", "gps\_time": 1555300565 }, { "frame\_name": "4.jpg", "gps\_time": 1555300570 }, { "frame\_name": "5.jpg", "gps\_time": 1555300580 } \] }\]} ...

1.导读 驾车导航是数字地图的核心用户场景，用户在进行导航规划时，高德地图会提供给用户3条路线选择，由用户根据自身情况来决定按照哪条路线行驶。 同时各路线的ETA（estimated time of arrival，预估到达时间）会直接显示给用户，这是用户关心的核心点之一。用户给定起点和终点后，我们的任务是预测起终点的ETA，ETA的准确率越高，给用户带来的出行体验越好。 2.基于深度学习模型的探索和实践 2.1模型选择 传统机器学习模型在ETA中，比较常用的有线性回归、RF（随机森林）、GBDT（梯度提升决策树）等回归预测类模型。线性模型表达能力较差，需要大量特征工程预先分析出有效的特征；RF通过样本随机和特征随机的方式引入更多的随机性，解决了决策树泛化能力弱的问题；GBDT是通过采用加法模型（即基函数的线性组合），以及不断减小训练过程产生的残差来达到回归的算法。 传统机器学习模型相对简单易懂，也能达到不错的效果，但存在两个问题： 模型的表达能力跟选取的特征有关，需要人工事先分析出有效的特征。没有考虑上游对下游路段的影响，产生了如丢失上下游关联信息、下游受上游影响导致的不确定性等问题。第一个问题很好理解，深度学习模型能很好地弥补这方面。针对第二个问题，以历史速度信息选取存在的不确定性为例来说明一下，历史速度信息是一个区分周一到周日七个工作日、10分钟间隔的历史平均时间，可以根据该路段的预计进入时间所在10分钟区间来选定。如下图（历史平均速度）从0:00-24:00的变化曲线，可以看到一天中特别是早晚高峰，速度值存在较大波动。 而在选取历史平均时间时，依赖的是预计进入时间，这个时间依赖于上游路段的预计通行时间，因此其选取存在不确定性，进而导致ETA计算不准确。 考虑到以上问题的存在，我们选择利用RNN的时间序列思想将路线中上下游路段串联起来进行路段ETA的预测。 另外考虑到RNN存在的长依赖问题，且结合实际业务情况，我们选择使用LSTM模型来进行建模，LSTM的门结构具有的选择性还能让模型自行学习选择保留哪些上游的特征信息进行预测。 2.2网络架构 上图为整个模型的框架图，主要分为两部分，使用LSTM模块对路线中的路段ETA的预测和最终使用N层全连接模块对累计路段ETA及路线各特征进行完整路线的ETA预测。 2.3路段ETA预测 上图为各路段ETA预测使用的LSTM结构图，Xt为路线中第t个路段的特征信息，主要包含对应的实时路况信息、历史路况信息、路段的静态特征等。 LSTM本是输入时间序列数据的模型，我们利用该思想，将路线中各路段序列依次输入模型。 2.4完整路线ETA预测 在LSTM模块得到累计路线ETA预测值后，结合该路线的静态属性，使用全连接模块将其整合成最终输出的完整路线ETA预测值。 路线的属性特征主要指一些人工提取的特征，如该路线的长度、导航规划发起特征日、是否早晚高峰时段等，用以加强模型在不同场景下的表达能力。 损失函数选用线性回归常用的平方形式：MSE，公式如下： 其中，N是路线数量，ETA路线j为路线ETA，即预测值；用户实走j为用户在该路线的实走时间，即真值。 3.模型效果 衡量模型效果，即路线上ETA的预测值时，主要考虑的是准确率。一般情况下，用户对ETA偏长和偏短的容忍度不同，对偏长容忍度更高。比如用户要去机场，ETA给的时间偏短10分钟比偏长10分钟对用户的损害更大。因此准确度的指标设计倾向于ETA偏长，定义为满足用户一定容忍范围的请求比例，即准确率作为主要衡量指标。 在北京市上的实验结果显示，ETA准确率得到提升，MSE loss下降比例28.2%，效果有了明显的提升。 4.小结 本文介绍了引入深度学习模型，帮助建模导航规划的预估到达时间预测，成功解决了线性模型的不足，也为后续引入更多特征、进行更多探索打开了空间，如历史速度信息的不确定度、时效性、周期性、突发事件、路网结构等。

2019杭州云栖大会上，高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位、时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆，听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来，本文为其中一篇。 高德地图首席科学家任小枫在高德技术专场分享了题为《视觉智能连接真实世界》的演讲，本文根据现场内容整理而成（在不影响原意的情况下对文字略作编辑），更多视觉智能技术的实现细节请关注后续系列文章。 以下为演讲内容的简版实录： 我今天主要给大家介绍视觉及相关技术如何在高德落地，如何帮助连接真实世界。连接真实世界这句话并不只是我个人的想法，而是高德地图的使命，我们的使命是“连接真实世界，让出行更美好”。 首先，简单介绍下高德地图，有超过1亿的日活用户，超过4亿的月活用户，高德地图不光提供导航，也提供出行相关的其他服务，涵盖了信息服务、驾车导航、共享出行、智慧公交、智慧景区、骑行、步行、长途出行等应用场景。 高德地图做的事情是建立人和真实世界的关系，人要跟真实世界建立联系，地图是基础，地图之上还有更多的信息可以获取。 视觉是连接真实世界的桥梁 视觉是连接真实世界的桥梁。为什么？从人的信息获取角度来看，80%的内容是通过视觉获取到的。从人的信息处理来看，人的大脑30%-60%用于视觉感知。从机器的角度，视觉是非常重要的通用感知手段。 人类感知真实世界的方法，还有很多其他方式，例如传感器、LT...但是，作为通用的手段，我一直觉得视觉是第一选择，通用，信息量非常大，可以远距感知，也可以做到实时。 还有一个原因，人类真实世界里（各种元素）80%以上是为了视觉而设计。有的时候，我们对真实世界太过于熟悉，可能不会太在意。但是看一下周围的标志和信息，包括认识的事物，都是根据视觉设计和获取。 因为人类获取信息的主要方式是通过视觉，所以真实世界的设计也是基于视觉。大家可以想象下，如果获取信息的主要方式是通过嗅觉，那这个世界会非常不一样。基于这些，回到我们在做的事情，大家一定不会奇怪，地图信息的获取和建立，绝大部分也是来自于视觉。 视觉技术@高德地图-地图制作 视觉技术在高德地图的应用有很多不同的方式，如下图所示： 左边是地图制作，有常规地图和高精地图，高精地图对应于未来的无人驾驶。右边是跟导航体验相关的，我们在做的一些跟定位相关的工作，也在利用视觉技术希望使导航变得更加便利。因为时间关系，今天只给大家介绍常规地图和导航相关的部分。 地图服务从哪里来，首先要采集资料，目前绝大部分是通过相机和视觉的方式采集信息。真实世界很大，全国有几百万公里道路，再加上其他信息，人工方式目前是处理不过来的，很大程度上需要用自动识别，通过算法识别资料。当然有时候算法没办法做到100%，还需要人工修正，从而制作成地图数据库，来支持地图数据服务。 地图制作任务，常规地图任务通常分为两大类，一类是道路相关，一类是POI挂牌识别。这两类任务都需要较多的视觉技术。例如，在道路标志识别上，算法要做的就是把道路上的标志一个一个全部找出来，同时识别标志的类型和内容。 道路标志有100多种。如果只是处理这些标志，其实并不是那么复杂。现实中，有时候需要用低成本的方式采集数据，这时如何保证图像质量就是需要考虑和解决的问题。 采集信息的时候，有时候图片会有畸变、反光、遮挡等情况，先不说分辨率压缩的问题，成像本身取决于镜头的质量和成本、天气条件、光线等因素，有时候采集回来的图像中差的图很多。这时候就不只是单纯去解决一个理想当中的算法问题，也需要处理很多实际情况。 给大家举几个例子，下面左边的图是实际采集的图像，会有各种各样的问题。大家对相机有些了解的话，知道相机有内参和外参，内参是焦距、中心、畸变。外参是位置、角度，这些都会影响成像效果。 对于识别问题来说，这些相机参数不会造成太大问题，但是如果需要做一些跟几何、位置相关的计算，这时候相机畸变和内外参不准就会造成很大的问题。我们通过把多源数据放在一起做匹配，基本可以解决这个问题。右边是一个实际例子，相机的畸变纠正角度，有一些斜的被纠正过来了，很大的提高了后面的算法处理。 另一个例子，图像质量。有的图质量比较差，但是没办法丢掉，还是有有用的信息。有的原始图像，放大之后非常模糊。如果这时采用图像增强的方法，可以把这张图变得更清楚。改善原始数据的质量，有很多可用的方法。比如提高识别算法精度，提高人工效率，也可以用它做模糊的检测，对比一下增强前后，可以知道哪些是模糊，哪些是不模糊。 刚才举的只是交通标志的例子。还有一个有趣的问题，就是感知电子眼。电子眼很小，而小目标的检测是一个有挑战的问题，在研究领域大家也比较关注。大家可以感受下，拿一张图，如果是太小的东西，放大之后就看不清了，还不如远景。那怎么能比较精确的找到这么小的电子眼呢？ 通常方式就是放大区域，因为这个东西太小了，光找这个目标比较难，找到区域放大，引入周边的信息。这些信息可以帮助更好的找到这个小目标，放的再大一点，才能看到其他相关的信息来帮助电子眼的智能检测。 但是放的太大也会有问题，放的太大会引入很多无关的信息。从技术上来说有一些解决方法，现在视觉技术上用的比较多的有一个注意力机制，画一个大框，机器自己会学哪块重要哪块不重要，帮助更好的聚焦到目标本身。当然，尽量会用一些先验信息，比如本身的分布、高度、大小。 光检测还不够，很多时候真实世界在变。很多时候要分辨出哪些变了哪些没变。以前检测出一个电子眼，新的资料又检测出一个电子眼，需要知道这两个是否是同一个。 如何判断？因为这张图表达的不一样，如果仔细看，确实可以看到背景的建筑、架设类型都差不多。需要用算法来判断到底是不是，这就牵涉到目标检测、车道归属、架设类型分析，还要做场景匹配。通过这些，很大程度上可以判断这是一个什么场景，从而判断两张图的元素是不是同一个。 刚才说的是道路，下面是几个跟POI相关的例子。POI的牌子，可以分成好多不同类型，有牌坊式、挂牌式、门脸式等。不仅POI各种各样，非POI其实也各种各样。如果只是检测文字的话，你会发现真实世界里的很多不是POI，有的只是标牌、标语、广告、对联、交通标志等。所以，要区分出POI和非POI。 有很多其他的复杂场景，这里不一一举例了，有些可能平时也不太能想到，比如三维挂牌，它不是一个平的牌子，在街角，可能是一个水果超市，沿着街角弯曲过来。这类牌子很难在一张图里完全检测出来，即使检测出来，一不小心就会分成两块牌子，所以真实世界的复杂性还是会造成更多的问题。 面对这么多复杂性，需要去分析具体场景的情况。很多时候最后的结果往往不是一个算法就能解决所有的问题，需要各种算法的融合。比方说，如果是文字，需要做检测，文字本身也需要做检测和识别。位置的话，需要做一些三维方面的推断。很多时候资料获取到以后也有模糊和遮挡的部分，也要做判断。 每一个判断不是单一办法就可以解决，不是光靠一个模型就能够做到最好的效果，需要的是两个甚至更多的模型，从不同的角度去解决问题，才能够达到更好的效果，这是在数据积累的基础之上。 上面列举的一些问题有一定的复杂性，跟所有的问题一样，越做到后面越难，我们现在还在做，这些算法很大程度上决定了地图制作的效率和触达到用户的地图质量，这些是非常重要的核心问题。 POI也不光是以上介绍的只需要判断是不是POI或者文字识别，很多时候还需要做版面的内容理解。如果一个牌子，需要知道这个牌子上的信息，有时候会有主名称，有时候会有分店，有时候没有，有没有联系方式、营业范围，这些都需要用算法去做。 视觉技术@高德地图-导航 以上介绍的是在地图制作方面有很多的复杂性，需要用视觉算法或者其他算法来处理。接下来分享下在导航方面的。 先说下自己的一个体会。前段时间在西班牙休假，欧洲的环岛特别多，谷歌（地图）导航经常提示我，进了弯道之后从第三个出口出去，我当时特别郁闷，因为要数口子，经常你也不知道那个到底算不算出口，所以走错了好几次。我在国内没开过车，国内的交通更复杂，例如在北京的西直门，有时候可以直接右拐，有时候需要转一个810度的圈。 我们希望对导航的方式做一个比较大的变化，让它变成所见即所得的场景。如果有算法能够直接告诉人们往哪边走，对人来说是更加有用的，能够让开车更加简单，导航变得更加直接。 很多汽车现在都会有摄像头，不管是前端还是后端，很多时候可以获取到视频数据。我们把AI算法计算出的效果叠加在视频上，告诉人们到底该怎么走。 高德在今年4月份发布了AR导航产品，这个产品里有一项是实景增强，它会告诉你应该保持在这条线上继续往前开或者转弯，会有压线的提示，会有箭头告诉你前面右转。 这个产品中，除了引导之外，还有别的功能。例如，也加入了前车的碰撞预警功能，会估计前车的距离和速度，这将帮助大家安全驾驶。其他事物也可以用更加直观的方式展示，例如限速，电子眼，跟斑马线相关的，如果看到前方有人，也会做出提示。 以上的功能看起来可能不那么难，但要实现起来很难。为什么？因为我们希望这是每个人马上就能实用的功能，所以要做到很低的成本。这和自动驾驶系统不一样。从传感器的角度，我们要做的是单个传感器，而且是低成本的相机。从计算的角度来说，自动驾驶系统可能会用一个几百瓦的专用芯片，而对于我们来说，所需要的算力大概只是普通手机的五分之一。 给大家看一个AR导航的例子，这是实际算法的输出，这个例子里面有车辆的检测，车道线的分割，和引导线的计算等。刚才提到了，高性能（低算力）是一个主要挑战，那我们在开发算法的时候就要充分考虑计算效率，包括各种手段，比如模型压缩，小模型训练优化，检测和跟踪的结合，多目标的联合模型，和传统GPS导航的融合，等等，需要几件事情在一个模型里做。 真实世界是非常复杂的，要做到高质量、高效的地图制作，或者做到精准的定位导航，在视觉方面还有很多工作要做。希望通过以上介绍，大家对视觉技术在高德地图中的应用，在出行领域的应用，有了更多的了解，也对高德的使命有了更多了解。 我们在很多时候需要去连接真实世界或者是理解真实世界，才能够让出行更美好。希望能够尽快的把这些做好，让大家实际应用高德APP的时候，能够感受到技术进步带来的体验变化。我今天就讲到这里，谢谢大家。 本文作者：高德技术小哥 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

导读与手机导航不同，高德地图的车机版（AMAP AUTO）直接面对各大车厂和众多设备商。这些B端用户采用的硬件参数参差不齐，提出的业务需求涉及到渲染中诸多复杂技术的应用，这对渲染性能提出了极高的要求。 最初车机版沿用手机版的当前屏渲染模式，每一帧都需要实时的将地图元素渲染出来。但在业务实践过程中，我们发现在多屏渲染和多视图渲染场景下，CPU负载急剧增高。以鹰眼图场景为例，在鹰眼图场景下，地图存在多视图渲染的状态：一张是主地图，一张是鹰眼小地图，因此渲染引擎同时渲染了两个地图实例对象，下图右下角即为鹰眼图： 鹰眼图绘制后，平均帧率下降了2帧，如下图所示： 针对上述情况，除了对渲染细节、批次和纹理等进行常规优化外，我们还需要寻找一种全局性的技术优化手段，大幅度提升引擎的渲染性能。为此，我们深入地研究了离屏渲染技术，并结合导航业务，提出了一种基于离屏渲染技术对特定地图的视图进行性能优化的方法。 优化原理在OpenGL的渲染管线中，几何数据和纹理通过一系列变换和测试，最终被渲染成屏幕上的二维像素。那些用于存储颜色值和测试结果的二维数组被称为帧缓冲区。当我们创建了一个供OpenGL绘制用的窗体后，窗体系统会生成一个默认的帧缓冲区，这个帧缓冲区完全由窗体系统管理，且仅用于将渲染后的图像输出到窗口的显示区域。我们也可以使用在当前屏幕缓冲区以外开辟一个缓冲区进渲染操作。前者即为当前屏渲染，后者为离屏渲染。 与当前屏渲染相比，离屏渲染： 在变化的场景下，因为离屏渲染需要创建一个新的缓冲区，且需要多次切换上下文环境，所以代价很高；在稳定的场景下，离屏渲染可以采用一张纹理进行渲染，所以性能较当前屏渲染有较大提升。从上述对比可以看出，在稳定场景下使用离屏渲染的优势较大。但因为地图状态随时都在变化，所以地图渲染通常处于前台动态渲染状态。那么有没有相对稳定的场景呢？答案是肯定的，我们将地图的状态分为沉浸态和非沉浸态。顾名思义，在地图处于变化状态的称为非沉浸态，进入稳定状态称为沉浸态。 进入沉浸态的地图，为我们使用离屏渲染提供了条件。经过统计，地图处于前台状态的场景下，沉浸态时间基本上和非沉浸态时间相当，这样我们采用一张纹理，即可将处于非沉浸态场景下的地图渲染出来，大大降低了系统开销。在鹰眼图，矢量路口大图等特定的视图场景下，地图基本上均处于沉浸态。所以这些视图下采用离屏渲染技术进行优化，取得的收益将是巨大的。 工程实践将以上的技术优化原理，代入到实际的导航应用中，流程如下： 离屏渲染通常使用FBO实现。FBO就是Frame Buffer Object，它可以让我们的渲染不渲染到屏幕上，而是渲染到离屏Buffer中。但是通常的离屏渲染FBO对象不具备抗锯齿能力，因此开启了全屏抗锯齿能力的OpenGL应用程序，如果采用离屏渲染FBO对象进行离屏渲染，会出现锯齿现象。而在非沉浸态地图的状态下，是开启全屏抗锯齿能力的，所以我们必须使用具备抗锯齿能力的离屏渲染技术来进行地图渲染技术优化。 抗锯齿离屏渲染技术简述本节以iOS系统为例，对抗锯齿能力的离屏渲染技术进行简述。iOS系统对OpenGL进行了深度定制，其抗锯齿能力就是建立在FBO基础上的。如下图所示，IOS基于对抗锯齿的帧缓存（FBO）对象进行操作，从而达到全屏抗锯齿的目的： 接下来具体介绍抗锯齿FBO的创建步骤： 创建FBO并绑定：GLuint sampleFramebuffer;glGenFramebuffers(1, &sampleFramebuffer);glBindFramebuffer(GL_FRAMEBUFFER, sampleFramebuffer);创建一个颜色帧缓冲区，在显存中开辟一个具有抗锯齿能力的对象，并将颜色缓冲区挂载到开辟的对象上。创建一个深度模版渲染缓冲区，开辟具有抗锯齿能力的显存空间，并和帧缓冲区进行绑定：GLuint sampleColorRenderbuffer, sampleDepthRenderbuffer;glGenRenderbuffers(1, &sampleColorRenderbuffer);glBindRenderbuffer(GL_RENDERBUFFER, sampleColorRenderbuffer);glRenderbufferStorageMultisampleAPPLE(GL_RENDERBUFFER, 4, GL_RGBA8_OES, width, height);glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, sampleColorRenderbuffer);glGenRenderbuffers(1, &sampleDepthRenderbuffer);glBindRenderbuffer(GL_RENDERBUFFER, sampleDepthRenderbuffer);glRenderbufferStorageMultisampleAPPLE(GL_RENDERBUFFER, 4, GL_DEPTH_COMPONENT16, width, height);glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, sampleDepthRenderbuffer);测试创建的环境是否正确，避免如显存空间不足等造成创建失败的可能：GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER) ;if(status != GL_FRAMEBUFFER_COMPLETE) { return false;}至此，一个具备抗锯齿能力的离屏FBO已创建好，下面将应用这个FBO，步骤如下： 先清除抗锯齿帧缓存空间重的内容：glBindFramebuffer(GL_FRAMEBUFFER, sampleFramebuffer);glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);glViewport(0, 0, framebufferWidth, framebufferHeight);开始进行一系列的渲染函数操作，比如准备顶点数据，纹理数据，VBO，IBO，矩阵，状态等，并执行一系列的渲染指令，选择指定的shader，及其传输数据状态；FBO不是一个具备直接渲染能力的帧缓存空间，在执行完2的操作之后，需要将抗锯齿的FBO内渲染的内容通过合并每个像素，转换到屏幕渲染所在的帧缓存空间去。原理如下图所示：代码如下： glBindFramebuffer(GL_DRAW_FRAMEBUFFER_APPLE, resolveFrameBuffer);glResolveMultisampleFramebufferAPPLE();glBindFramebuffer(GL_READ_FRAMEBUFFER_APPLE, sampleFramebuffer);以上操作完成后，需要进行一些Discard步骤, 将一些原先在当前帧缓存中的内容忽略掉：glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);[context presentRenderbuffer:GL_RENDERBUFFER];Android系统基本思路一致，需要采用gles3.0接口提供的抗锯齿能力来进行渲染，在此不做展开。 ...

咔咔出行（出行可视化）项目简介解决出行问题，用于出行行程记录，路线规划，数据可视化分析的移动端webapp 点击这里查看该项目 项目截图私人出行公共交通历史列表我的信息 技术栈前端：移动端，vue全家桶，Mand组件库，Echarts.js，Scss后端：Node，Express框架，高德地图API数据库：Mysql功能模块个人出行用户个人出行，不确定路程、目的地等信息，选择出行工具，点击开始，系统实时监听用户手机位置得到WGS84经纬度坐标（w3c HTML5 Geolocation地理定位标准），行程结束，记录本次出行信息，经纬度坐标转换GCJ-02坐标体系，通过高德地图提供三方API绘制出行轨迹。 公共交通用户确定出发地、目的地、交通工具，选择公共交通出行，用户输入位置关键字，选择合适出发/目的位置，选择乘坐交通工具，规划出行路线，选择某一条路线，确定后点击保存上传本次出行记录 历史列表按时间顺序查看所有出行的历史记录，可查看出行的详情信息、行程轨迹、路线规划 我的信息（未完成）查看我的详情信息，通过出行数据分析得到的出行趋势折线图，与出行数据相关的数据分析图表，其他功能未写 项目构建前端前端在vue-cli3基础上开发，在此之上根据项目需求对项目工程作出几点修改，前端代码在view/文件夹中 移动端适配：之前做移动端开发一直使用手淘的分辨率适配方案，本项目根据大漠的《如何在Vue项目中使用vw实现移动端适配》，对移动端分辨率用webpack在工程中配置。请求拦截器：在view/src/request/中，基于axios提供的interceptors对所有ajax的请求和响应添加相应操作，如请求头添加，token添加，响应后台错误状态码的识别与报错；简单封装了下axios请求，主要为get，post两种。导航守卫：在view/src/router/中，做了全局导航守卫，未登录用户只能访问项目登录页面。工具类：在view/src/utils/中，对常用枚举值、全局组件注册、常用类封装等功能做模块化封装。css样式：在view/src/style/中，全局公共样式，初始化样式。svg组件：在view/src/icons/中，封装用于svg展示组件，用做小icon的展示，svg保存该文件夹中。模块化：对路由与vuex做模块化封装。地图：所有地图、地理信息、轨迹、路线规划功能有高德地图第三方API提供后端使用Node的express框架，连接Mysql数据库，做数据接口开发，数据的增删改查与简单封装。小结项目简结难度：简单开发时长：前期调研，编码一周关键字：移动端，出行，可视化，高德地图，Echart图表过程总结想法产出：因为在滴滴出行的实习经历，准备做款有关出行平台的，有关前端可视化的产品。需求调研：结合出行 可视化 关键字做需求分析，调研悦动圈、悦跑圈、滴滴出行、百度地图、高德地图确定几个主要功能 实时定位，绘制出行轨迹(悦跑圈，已完成)路线规划，规划路线绘制路径图(百度地图，已完成)网约车，快车，专车，顺风车在线叫车(滴滴出行，未完成)可视化分析，出行数据的可视化分析(已完成)技术调研： 选取HTML5 Geolocation提供的物理位置实时监听功能，获取到WGS84经纬坐标选取高德地图第三方API提供地图，地理位置，轨迹绘制，路线规划等功能选择开发移动端项目，用滴滴的Mand作为移动端UI组件库选取Node为服务端，Express为后端框架，Mysql为数据库难点总结产品从无到有是最困难的，项目虽然不难，可前期产品调研，技术调研，项目构建确花费了大量时间，相比照着成品写多了很多不一样的体验 Github源码 https://github.com/wwenj/tripRecord

分为地图,定位,搜索(我还没做导航功能)建议采用gradle方式集成添加依赖在project/build.gradle文件下添加jcenter的仓库地址allprojects { repositories { jcenter() // 或者 mavenCentral() } }在app/build.gradle下添加依赖android { defaultConfig { ndk { //设置支持的SO库架构（开发者可以根据需要，选择一个或多个平台的so） abiFilters “armeabi”, “armeabi-v7a”, “arm64-v8a”, “x86”,“x86_64” } }}dependencies { compile fileTree(dir: ’libs’, include: [’*.jar’]) //3D地图so及jar compile ‘com.amap.api:3dmap:latest.integration’ //定位功能 compile ‘com.amap.api:location:latest.integration’ //搜索功能 compile ‘com.amap.api:search:latest.integration’}navi导航SDK 5.0.0以后版本包含了3D地图SDK，所以请不要同时引入 map3d 和 navi SDK。添加权限在AndroidManifest.xml文件下添加权限 <!–允许程序打开网络套接字–><uses-permission android:name=“android.permission.INTERNET” /><!–允许程序设置内置sd卡的写权限–><uses-permission android:name=“android.permission.WRITE_EXTERNAL_STORAGE” /> <!–允许程序获取网络状态–><uses-permission android:name=“android.permission.ACCESS_NETWORK_STATE” /> <!–允许程序访问WiFi网络信息–><uses-permission android:name=“android.permission.ACCESS_WIFI_STATE” /> <!–允许程序读写手机状态和身份–><uses-permission android:name=“android.permission.READ_PHONE_STATE” /> <!–允许程序访问CellID或WiFi热点来获取粗略的位置–><uses-permission android:name=“android.permission.ACCESS_COARSE_LOCATION” /> 添加高德key如何获取key看这里 -> 点我查看Key注册时必要数据SHA1和包名的获取方法建议同时设置debug和release状态下的key,方便App在debug模式下也能使用高德地图功能.在app/build.gradle下设置两种key android { buildTypes { debug { manifestPlacesholders = [ //左边的键MAP_API_KEY是自定义的名字,右边的debug-key-value是你申请的debug下的key值 “MAP_API_KEY” : “debug-key-value” ] } release{ manifestPlacesholders = [ //左边的键MAP_API_KEY要和debug下的保持一致,右边的release-key-value是你申请的release下的key值 “MAP_API_KEY” : “release-key-value” ] } } }在AndroidManifest.xml中添加key <application> <meta-data android:name=“com.amap.api.v2.apikey” //要和app/build.gradle文件中设置的保持一致 android:value="${MAP_API_KEY}"/> </application>使用地图在布局中引入地图MapView // R.layout.activity_your_activity <com.amap.api.maps.MapView android:id="@+id/map" android:layout_width=“match_parent” android:layout_height=“match_parent”/>管理地图的生命周期(非常重要),以Activity为例 public class YourActivity extends AppcompatActivity{ MapView mMapView = null; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_your_activity); //获取地图控件引用 mMapView = (MapView) findViewById(R.id.map); //在activity执行onCreate时执行mMapView.onCreate(savedInstanceState)，创建地图 mMapView.onCreate(savedInstanceState); } @Override protected void onDestroy() { super.onDestroy(); //在activity执行onDestroy时执行mMapView.onDestroy()，销毁地图 mMapView.onDestroy(); } @Override protected void onResume() { super.onResume(); //在activity执行onResume时执行mMapView.onResume ()，重新绘制加载地图 mMapView.onResume(); } @Override protected void onPause() { super.onPause(); //在activity执行onPause时执行mMapView.onPause ()，暂停地图的绘制 mMapView.onPause(); } @Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); //在activity执行onSaveInstanceState时执行mMapView.onSaveInstanceState (outState)，保存地图当前的状态 mMapView.onSaveInstanceState(outState); } }构造一个AMap对象 if(mAMap == null){ mAMap = mapView.getMap(); }初始化地图的相关属性地图缩放级别mAMap.animateCamera(CameraUpdateFactory.zoomTo(float zoomLevel));显示定位蓝点未完待续 ...