公司:得物
得物,原名“毒”,是中华人民共和国上海市上海识装信息科技有限公司推出的一个电商手机应用。第三方商家和个人可以入驻得物平台与其他用户进行交易。
Android Oreo 的 WebView 多进程模式
Android 应用层的开发有很多模块,其中 WebView 就是最重要的模块之一。对于一个百万级用户的应用,WebView 必然是不可或缺的,而对于 得物App 这样的电商应用,更是不言而喻。而对于大部分开发者而言,并没有深入的去了解过 WebView 的一些实现细节,本文就从 WebView 启动的视角分析一下 Android Oreo 下的 WebView 多进程模式,帮助大家更深入的了解 WebView,并提供一些优化上的思路。
基于DataWorks的时效仿真平台
现货业务目前基于算法模型+运营配置得出订单预计履约时长,由于时效策略调整需求且现货订单数据回收周期较长,因此需要建设时效仿真平台能力,产品自行根据业务需要进行时效仿真实验并得到对应结果。
一种简单的架构设计逻辑
本文探索了基于用例驱动的架构设计逻辑,核心思想是采用用例驱动设计,基于“演绎法+自上而下”的逻辑来设计技术方案,帮助开发人员理清技术方案设计思路并提升技术方案的质量和评审效率。
得物基于Attach to Process的实时调试实践
本文主要介绍得物实时调试的全套解决方案,实现对测试包还原出包环境和无需编译就可以进行断点调试的功能。整体按实时调试方案的可行性分析,方向调研,优化方案设计,推进优化落地,最后在团队推广的流程。本文主要讲4个主要内容,包括:Attach to Process介绍,环境还原,实时调试探索,组件化工程的实时调试。
一个满分的项目文档是如何书写的
项目文档是对于项目一个快速了解的一个最好方式,能从中获取到其是所服务的业务,参与开发所具备的知识体系,开发前所需做哪些准备,遇到问题所需询问的时的人员,不仅能帮助新手快速上手,同时也有助于多个项目并行时,相互之间进行切换起到温故的效果。
浅析如何基于ZooKeeper实现高可用架构
zookeeper是一个比较成熟的,经过市场验证的分布式协调框架,可以协助我们快速的解决分布式系统中遇到的一些难题。另从上面的介绍中发现,zookeeper的核心是zab,etcd的核心是raft,那可以思考下,还有哪些一致性算法?
看完这篇异地多活的改造,我决定和架构师battle一下
异地多活的概念以及为什么要做异地多活这里就不进行概述了。概念性的很多,像什么同城双活、两地三中心、三地五中心等等概念。如果有对这些容灾架构模式感兴趣的可以阅读下这篇文章进行了解:《浅谈业务级灾备的架构模式》。
机器学习在图形验证码识别上的应用
在我们开发测试过程中,登录验证码几乎随处可见。特别是春节抢票,有没有被12306的验证码搞的崩溃呢? 教大家一个办法:利用机器学习来自动识别验证码!
得物拍照搜索的前世今生
大家在逛街,看视频,刷朋友圈时,是否会看到自己一见钟情的鞋子,衣服等商品,却因为不清楚商品的具体系列,款式而苦恼?遇到这种情况大家一般是动口询问,还是到品牌官网或者购物平台海量搜索呢?相信大家都有自己的获取渠道,这里将会为大家介绍一种更直接的拍照搜索方式。
那么多微前端框架,为啥我们选Qiankun + MF
Qiankun是社区的一种微前端框架;MF是模块联邦的意思,在Webpack 5中流行起来的,也属于一种微前端方案。
得物登录组件重构
登录模块对于一个App来说是十分重要的,其中稳定性和用户流畅体验更是重中之重,直接关乎到App用户的增长和留存。接手得物登录模块以后,我陆续发现了一些其中存在的问题,会导致迭代效率变低,稳定性也不能得到很好的保障。所以此次我将针对以上的问题,对登录模块进行升级改造。
多兴趣召回模型实践
MIND多兴趣召回在实践过程中,经过离线和实时两个阶段去执行最终落地,中间的步骤因此记录下来,希望你在阅读到此文能够有所收获。
NOC-SLA 之得物C端业务监控实践
在我们经历过多次大额资损类故障中和影响业务可用性严重性故障后,我们回顾总结怎么从应急保障中做到快速响应,事前预警后。由被动变主动,向全员承诺发起NOC-SLA保障专项,痛定思痛下定决心将告警发现、处理、止血。
Filament Creator材质编辑工具的实现
高质量的3D模型更能激发用户消费的意识,因此提高3D模型的呈现效果就是我们的重点攻坚方向,Filament creator材质编辑工具,可以帮助我们使用不同的渲染引擎材质来呈现球鞋效果,让用户可以通过模型获取更真实的效果。
得物复杂C端项目的重构实践
公司近两年快速发展,社区线C端代码分散在不同仓库中,每个仓库中采用不同的前端框架和选型,且均含有几条业务线的代码,团队整体采用敏捷模式快速迭代,导致开发管理成本较高,升级改造麻烦。比如,所关联的三个仓库中的代码均引了一个内部基础组件库,该组件有非必现bug,导致三个仓库的不同页面均出现了不同表现的异常,由具体负责的不同测试分别报到前端开发,分别沟通、排查、解决并走独立的发布上线流程,耗时耗力。当同一仓库中活跃着不同业务线的开发,一个公共的地方需要修改,开发没有沟通清楚导致冲突线上bug。
此外,公司C端体验分析的统计和报表是应用粒度的,先前代码耦合了其他业务的内容,导致我所在业务线的统计数据不置信。
近期团队对C端项目进行重构,将不同仓库中的代码汇总到一个仓库中管理。以期减少管理成本及方便后续对组内项目做优化和升级改造。
剖析Mooncake的代理原理,实现快速提效
市场上的Mock方案相对较多,得物前端Mooncake平台作为UI测的联调提效工具,通过线上配置平台、代理层,代理注入三层的实现,实现了数据可视化配置和数据转发,提升了前端的联调效率。