1. 如何解决业务方在小程序、H5应用上的接入地图服务的困扰？ 我们统一收口哈啰&高德服务能力，业务侧不需要每次接入LBS和高德服务都做http服务的接入工作，只用接入地图提供的组件包。我们还提供在类型声明，线接入文档，简化业务方的接入成本和工作量。 2. 总是担心服务不稳定，如何缓解心智负担？ 我们在前端侧优化了请求策略，加入了降级兜底能力，稳定性更有保障。 3. 面对调用量增长，减轻服务压力，将如何面对？ 我们从缓存方面入手，为调用量特别突出的逆地理设计缓存方案，通过缓存机制来减少调用，减轻服务压力。
开源之初，我们给自己定下 star 数量超过 70 个就行的心态，却意外得到了 1600 多 star，很受鼓舞～ 那一刻起，我们知道，在前端框架“泛滥”的时代，还有一些人在追随原生技术，大道至简，平淡为归。 这也让我们想起了 kk 说的那句话：所有创新都发生在事物边缘，所有的颠覆都来自边缘。 今天，我们正式对外开源 Quark 生态 的又一成员，Quarkc（Quark core 缩写）。下面来做个简单介绍吧 ：）
右图是哈啰APP的客服中心，用户进入该页面，系统会根据用户的使用情况智能推荐高频问题，并猜测用户想解决的问题，这部分标准问题的解决方案由业务专家进行整理，能涵盖用户大部分的意图。对于解决不了的问题，用户进入IM入口，聊天机器人会和用户进行对话。机器人基于知识库进行匹配，针对每个意图分别配置答案，或者给出具体解决方案。 目前的痛点在于： 知识库迭代更新费时费力 模型难以跨业务通用 解决方案涉及到多模态的复杂数据融合问题 多轮任务型会话上下文的长距离依赖问题
在哈啰的APP中，活动、大促、周年庆等都需要我们能够拥有更快捷的响应速度、更高效的人力来缩短试错周期，而且流量区域运营位为了能够做到千人千面，又迫切的需要有一种可以根据不同的人群达到展示不同效果的目的。UI 可定制化、快速迭代、高性能体验一直以来都是移动端开发领域的核心诉求，随着哈啰业务的不断拓展，越来越多的业务线对上述三点提出了更高的要求，但由于移动端 App 发版的天然限制，无法很好满足业务方的诉求。 基于以上一些业务痛点，我们结合 Native 黄金流量业务区域对于性能极高的要求，输出了一套 Native 局部动态化方案 Wukong（悟空），截止到目前，已在App内部多个业务模块中得到验证。
哈骑士是哈啰的一款终端安全应用，本文主要介绍我们在做新版哈骑士桌面端时的一些技术架构思考和实践，分享我们沉淀的一些桌面端应用的解决方案和经验。
为什么哈啰AI平台需要Faas 一是运维复杂问题，AI平台有多种不同语言的模型推理服务， 如python、C++（tf-serving）、Java等，各自管理上百个不同类型的模型；架构也很复杂，存在大型单体应用、多container应用、小型GPU应用等多种服务组织方式；同时，手动运维有余，自动化工具不足。 二是稳定性问题，成百上千模型集中式部署，存在明显热点问题，在应对一些突发流量的时候，自动伸缩速度也存在问题。同时，模型cpu、gpu资源竞争问题也困扰了我们。 三是IDC成本问题，存在资源利用率低的问题，有很大的提升空间。
Android应用采用Java或Kotlin编写，iOS应用采用Objective-C和Swift编写，但当我们要去开发支持多端的应用，每一端都需要独立研发、测试，直到上线。为了解决多端独立开发的问题，跨端技术的方案备受青睐。 两轮跨端技术的尝试要追溯到2019年，当时整个互联网行业都在提效的大背景推动下开始各种跨端方案的尝试，而前身还是两轮助力车团队的两轮大前端也开始了跨端技术方案的探索。 当时可供选择的跨端方案有React Native方案、Weex方案，H5离线化方案以及当时较火的Flutter技术方案，而我们的目标是希望能够找到稳定、适合我们业务特性，并且可以继续进行深耕的技术方案进行调研和尝试。
在定点还车的模式下，用户还车需要在一些指定的区域里。此时用户停好车后在APP或小程序内点击“我要还车”，手机会将位置信息传输给后端，系统会判断是否在站点内，如在站点内会提示用户点击“确认关锁”，用户手动关闭车锁完成还车。
