携程火车票营销页使用 css 制作动画很多年了，这大大提高了动画给予页面丰富的视觉体验。不过，在开发的过程中，也遇到了一些性能相关问题和用户反馈，比如头部动画卡顿、页面打开时间较长、页面打开后部分数据加载时间较长等问题。为解决这些问题，我们借助性能检测工具定位问题，并查阅源码、文档等资源解决问题，形成了这篇文章。
我们在开发 H5 营销活动后，通常会将营销活动的入口投放到多端，包括 App、小程序。常见的投放形式有：Native 原生页面、React Native 页面和小程序页面的内嵌弹窗。那么此时，就需要 Native、RN、小程序端的人力投入。由此，整个流程从仅需 H5 开发演变成需要多端开发、沟通，从 H5 营销活动灵活上线演变成受制于 App 和小程序的版本发布。 为了优化此流程，我们引入了一种全新的方案——跨端共享 Web 组件。这一方案秉承“一套 Web 代码，多端共享”的理念，旨在缩短上线周期、降低人力成本、并快速响应迭代。采用跨端共享 Web 组件，我们能够高效地实现多端共享，同时也能够更加丰富地展示 Web 组件，从而为我们的业务带来更多的价值。
在现今的信息时代，微服务技术已成为一种重要的解决方案，微服务技术可以使系统的规模和功能变的更加灵活，从而获得更高的可扩展性和可用性。然而，微服务调用中出现的超时问题，却也成为系统可用性的一大隐患。超时会导致客户端的性能下降，甚至可能无法正常工作。本文针对超时问题，提出相关的优化手段，降低微服务调用超时的风险。
注册风控是企业风控场景中重要的一环，黑产用户想要进行各式各样的欺诈行为，首先需要注册账户。通常，这些黑产用户会采用技术手段批量注册虚假账号，而后进行一系列恶意行为。那么，如何准确快速地识别注册用户是否是异常聚集的黑产用户，这是注册风控场景中需要解决的一个问题。 因此，本文介绍了一种当前在携程商旅应用的基于注册图网络的恶意账户聚集检测模型。
近年来，随着互联网的发展，在线广告营销成为一种非常重要的商业模式。出于广告流量商业化售卖和日常业务投放精细化运营的目的，需要对广告流量进行更精准的预估，从而更精细的进行广告库存管理。 因此，携程广告纵横平台实践了LSTM（Long Short-Term Memory，长短时记忆网络）模型结合Embedding的广告库存预估深度学习算法，在节省训练资源的同时，构建更具泛化性的模型，支持根据不同地域分布、人口学属性标签等进行库存变动预估，并能体现出节假日特征对库存波动的影响，从而对广告库存进行更为精确的预估。
携程各个BU各个时期都有不同营销页面，数量众多，其中很重要的一块是产品模块，运营需求的产品卡片样式众多，各个BU展示字段差别巨大，无法利用通用样式，因此如需新增卡片或字段，传统做法是运营提需求给设计，再提需求给开发，经过需求评审，正式开发，发布测试上线等等。 每次遇到大促活动或者接入新的业务方，都需要重新设计及开发商卡，而新的商卡大多只是新增一些换肤样式，或个别字段，这却需要开发人员多写一套样式代码或新增字段样式，同一个样式应用于不同的业务方也需要重新进行开发，极大地浪费了开发和设计资源。 在DIY商品卡片系统开发前，由于开发成本的限制，营销页面上常用的商品卡片样式基本固定为十几种，这在用户看来缺乏新意，吸引力不足，从而在一定程度上影响了营销页面商卡的点击量。
Android 项目一般使用 Gradle 作为构建打包工具，随着业务需求的不断迭代，代码量提升的同时，Gradle 编译耗时也在不断的增长，而编译速度会直接决定开发流程效率的高低，影响面主要涉及到开发和测试阶段。 对于火车票项目，经过长期的迭代过程导致模块众多工程庞大，优化前一次干净的全量编译时间可达到10m39s，造成开发和测试都需要长时间等待编译出包，严重影响到开发和测试的效率。因此对火车票 App 进行编译速度优化是件亟待解决的事情。 本次编译速度优化采用的方案是模块AAR方案, 优化目标为: 优化后一次干净的全量编译时间缩减为原来编译时间的50%以下。
这篇文章将向大家分享团队在小程序 webview 方面的开发心得，以微信小程序为主要环境，介绍在业务开发中处理小程序webview内嵌H5所遇到的问题及解决方案。具体将从小程序平台与H5差异、小程序内嵌webview通信、小程序webview常见问题展开叙述。
随着历史业务不断迭代和业务场景越来越复杂，携程用车、租车（简称两车）面临历史技术债和系统复杂度越来越高带来的理解、维护、迭代困难等问题，我们开始寻求如何更有效的降低复杂度和提升效率的方法。 本文描述了两车如何利用DDD（Domain-driven Design，领域驱动设计）方法论降低系统复杂度以及在重构历史系统中的取舍和思考。对于复杂业务场景下的领域驱动设计具有借鉴意义。
