冷启动指标是App体验中相当重要的指标，在电商App中更是对用户的留存意愿有着举足轻重的影响。通常是指App进程启动到首页首帧出现的耗时，但是在用户体验的角度来看，应当是从用户点击App图标，到首页内容完全展示结束。 将启动阶段工作分配为任务并构造出有向无环图的设计已经是现阶段组件化App的启动框架标配，但是受限于移动端的性能瓶颈，高并发度的设计使用不当往往会让锁竞争、磁盘IO阻塞等耗时问题频繁出现。如何百尺竿头更进一步，在启动阶段有限的时间里，将有限的资源最大化利用，在保障业务功能稳定的前提下尽可能压缩主线程耗时，是本文将要探讨的主题。 本文将介绍我们是如何通过对启动阶段的系统资源做统一管控，按需分配和错峰加载等手段将得物App的线上启动指标降低10%，线下指标降低34%，并在同类型的电商App中提升至Top3。
目前实时数仓提供的投放实时指标优先级别越来越重要，不再是单独的报表展示等功能，特别是提供给下游规则引擎的相关数据，直接对投放运营的广告投放产生直接影响，数据延迟或者异常均可能产生直接或者间接的资产损失。
在日常工作中，无论是产品经理写PRD或是开发、测试同学写技术方案、整理业务文档等场景都会用到诸如流程图、时序图、用例图、泳道图等形式的图来辅助阅读者理解。相信平时工作中有画图需要的读者都有这样的感受：有些图制作过程非常简单但逻辑清晰又不失美观，而有些图费时费力制作繁琐，但效果却不是特别惊艳，这其中的底层逻辑尤为关键，毕竟作图也是一门艺术。本文将会以直播商品讲解业务场景出发，给大家分享一些画图小知识。 上面我们提到了很多种的图，归根结底是两类：流程图和UML图。细分的话有活动图、状态图、用例图、顺序图、类图、对象图、协作图等13种。不同的图适用于不同的情形。
随着得物业务规模的不断增加，推荐业务也越来越复杂，对推荐系统也提出了更高的要求。我们于2022年下半年启动了DGraph的研发，DGraph是一个C++项目，目标是打造一个高效易用的推荐引擎。推荐场景的特点是表多、数据更新频繁、单次查询会涉及多张表。了解这些特点，对于推荐引擎的设计非常重要。通过阅读本文，希望能对大家了解推荐引擎有一定帮助。为什么叫DGraph？因为推荐场景主要是用x2i(KVV)表推荐为主，而x2i数据是图(Graph)的边，所以我们给得物的推荐引擎取名DGraph。
消费者在得物下单购买商品后，卖家不会直接发货给买家，而是先发货给得物，由得物鉴别师团队对商品进行真伪鉴别和瑕疵查验分级，确保是全新正品之后，才会发货给消费者。全流程由得物技术提供的系统能力支撑运作。
商家后台前端代码目前代码量达到十万级，每个迭代团队需要在同一仓库中迭代几十个需求，在日渐庞大的巨石应用下如此活跃的迭代，开发效率与构建效率上给我们带来了一些挑战，我们需要优化以下几点： 代码构建体量大，随着时间推移，构建速度的优化空间较少。 巨石应用下各个业务模块没有做物理拆分，管理与维护难度提升。 应用粒度较粗，在发布节点上需要对应用做进一步拆分以优化发布粒度。 巨石应用下，组件与业务的关系需要梳理，避免出现重复开发的情况。 微前端是目前解决应用拆分的主要解决方案，但是由于其隔离性的机制使得各个子应用间完全隔离，使得用户在开发子应用时无法访问其他子应用页面，这对于各子应用存在关联关系需要同时访问开发的场景开发效率较低，并且目前市面上已经完全封装的主流微前端框架对我们来说是黑盒，无法做到高度自定义，无法满足特定拆分需求，因此我们决定采用模块联邦与大仓模式结合的方式解决以上问题。
得物提供大量商品买卖等服务，资金流转量大，任何由于设计缺陷、系统缺陷、系统故障、人为操作、安全漏洞等因素都会引发直接或间接资金损失。资损防控就是在项目全生命周期内，引入多种资金分析和控制手段，预防资损故障或控制资损故障影响范围。
老网关使用 Spring Cloud Gateway （下称SCG）技术框架搭建，SCG基于webflux 编程范式，webflux是一种响应式编程理念，响应式编程对于提升系统吞吐率和性能有很大帮助; webflux 的底层构建在netty之上性能表现优秀；SCG属于spring生态的产物，具备开箱即用的特点，以较低的使用成本助力得物早期的业务快速发展；但是随着公司业务的快速发展，流量越来越大，网关迭代的业务逻辑越来越多，以及安全审计需求的不断升级和稳定性需求的提高，SCG在以下几个方面逐步暴露了一系列的问题。
订单的履约之路就是从发货开始，看似简单的发货功能，其背后却藏着许多的小秘密。 发货的业务特点： B端业务，性能要求不高，因为存在批量发货的场景。 发货时间比较分散，所以并发量不大。 业务复杂，涉及到N种订单类型的发货，不同的订单类型有着不同的业务规则。 随着公司业务的发展，订单类型的增多，没有进行抽象的发货逻辑随着迭代的推进难免会显得落后。当然，在迭代的过程中，也一直在优化，一直在演进，正所谓没有最好，只有符合当前业务现状的最合理。
Flutter虽然火了很久，但是大家对Flutter代码静态检查原理与应用依然有很多大大小小的问题，在Flutter开发中就存在一些大家都会遇到普适性的问题: 团队沉淀了很多flutter编码规范。目前团队完全靠人工CR，人工CR存在效率低，容易遗漏。 另外一方面,我们在业务迭代中也总结了大量代码质量、代码稳定性、代码性能方面的最佳实践。同样这些最佳实践也是通过人工CR来保证的。 上述两个点，均指向了人工CR的缺陷与不足，因此我们急需一些自动化手段来解决人工CR的效率低、容易遗漏这一问题。 所以想通过本文来为大家介绍下，代码静态分析可以在编码时让IDE实时提示程序员其代码存在缺陷甚至根据最佳实践的内容提示更好的代码实现。
