近年来，随着互联网的发展，在线广告营销成为一种非常重要的商业模式。出于广告流量商业化售卖和日常业务投放精细化运营的目的，需要对广告流量进行更精准的预估，从而更精细的进行广告库存管理。 因此，携程广告纵横平台实践了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，领域驱动设计）方法论降低系统复杂度以及在重构历史系统中的取舍和思考。对于复杂业务场景下的领域驱动设计具有借鉴意义。
携程小程序自动化错误预警方案是一套完整且通用的小程序前端错误监控方案。此方案提供小程序错误自动采集SDK，并对错误所在的页面路径进行偏移矫正，能够准确通知相应的开发负责人；将错误信息分为生产、测试、开发3种阶段，根据错误发生的阶段提供相应的错误预警及处理方案；开发负责人只需在小程序管理平台配置告警所需信息，即可快速接入、实时监控生产报错、生成告警通知；源码映射能力可以帮助开发者快速定位错误原因，提升修复效率。接入此方案可实时捕获开发环境错误，确保在小程序发布上线前发现并解决业务报错，可极大地减少线上小程序的错误量。
在软件开发过程中，团队协作效率的提高是我们共同关注的问题。为了解决这一问题，许多团队都开始使用智能化工具。Design2Code（简称D2C）工具是其中一种广受欢迎的选择。 在本文中，我们将分享D2C工具的核心算法方案设计和实现过程，以及一系列的解决方案。无论你是开发人员，还是设计师，本文都将为你提供有价值的信息。我们希望，通过阅读本文，能帮助你更好地了解D2C工具，并在实际工作中发挥出最大的价值。
在容器化部署成为主流的现在，降低集群中单个容器的资源需求的意义已经不只限于更少的硬件成本，同时也意味着整个集群更加轻量化，这通常会带来一系列其他优势：例如更短的恢复时间，更精确的资源控制和调度，和更快速的伸缩和部署等。但在另一方面，一味的追求压缩容器配置必然会严重影响应用在稳定性、响应耗时和吞吐量等方面的表现，所以轻量化的措施需要在多个性能维度上进行仔细的权衡取舍，以达到一个总体更优的结果。 作为携程计算量最大的接口之一，酒店查询服务一直承担着沉重的硬件成本压力，仅仅详情页集群就包含了千余台服务器实例和数十TB的Redis资源，因此对应用进行全面的轻量化有着很高的必要性和预期收益。在内存方向上，我们的主要目标是将单个容器的内存从32GB压缩到16GB，并在以下两个基本方向上进行了探索： 减少内存增长速度：压缩本地缓存，减少浮动内存的产生，并对线程，类库，参数和代码逻辑进行针对性的优化和调整。 提升内存管理效率：加强JVM等服务依赖的基础组件其本身的性能。 由于第一个方向需要根据应用的具体代码实现来分析和排查，普适性相对较差
今天这篇文章中和大家聊一聊号称世界上第一个 O(1) 的 JavaScript SSR 框架：qwik。 别担心，如果你不是特别了解 SSR 也没关系，文章大概会从以下几个方面作为切入点： 首先会围绕对比 SSR 与 SPA 各自的优劣势，从而展开 SSR 的运行机制以及 SSR 相较于 SPA 究竟为了解决什么问题。 之后，会根据 NextJs 的运行机制思考针对目前主流 SSR 框架设计思路上存在的不足从而引出 qwik 为何会在众多成熟框架中脱颖而出。 最后，会针对于 qwik 提出自己的看法以及聊聊目前 qwik 存在的“问题”。 诸如社区内部 SSR 框架其实已经产生了非常优秀的作品，比如大名鼎鼎的 NextJS 以及新兴势力代表的 Remix 和 isLands 架构的 Astro、Fresh 等等优秀框架。 为何 qwik 可以在众多老牌优秀框架中脱颖而出。接下来，让我们一起来一探究竟吧。
