话题公司 › 玩物得志

公司:玩物得志

Groovy引发的内存爆满问题排查

本篇以线上内存持续增长问题的排查为背景,讲解如何使用常用的分析工具来定位和解决。

稳定性之接口监控

接口监控是确保系统稳定性的一项重要措施。

由一个线上问题引出的ParallelStream最佳实践

ParallelStream作为并行计算的一把利器,我们应该理解其原理,正确,合理地使用这把双刃剑。

玩物得志app搜索下拉框的工程实践

搜索下拉框也叫搜索提示、搜索下拉推荐,是指根据用户当前的输入词提供一个query列表供用户选择。

搜索下拉框在搜索引擎中是一个标配的功能,它可以帮助用户减少输入的时间、明确搜索的意图、提高搜索的准确度,在一定程度上可以引导用户的搜索行为,提高搜索的体验。

Android安全知识浅谈

近几年随着网络信息技术迅速发展,移动互联网的生态系统日益庞大,市场上丰富的移动应用也越来越多,在手机APP为我们提供便捷服务的同时,木马病毒、程序破解、广告钓鱼、信息窃取、二次打包等诸多移动端安全问题也一直环绕着我们,若对应用中潜在的安全隐患不能够及时发现和处理,一旦出现问题,无论是对公司或用户,都将受到不可估量的伤害。

2019和2020年是玩物得志高速发展的两年,随着公司的体量越来越大、用户数日益增多,APP工程体积也逐渐庞大,但早期APP应用在安全方面的建设较为薄弱,我们同样面临着这些安全隐患,导致应用程序被破解、核心代码被窃取、API接口被伪造/篡改、黑产用户虚假注册、批量刷单/薅羊毛、推广作弊、群发广告等一系列问题,给公司带来了不小的经济损失。

玩物得志 - iOS业务层级的架构探索、演进以及实践

架构没有好坏之分, 只有更加适合自己业务的架构模式。 设计模式没有好坏之分, 只有更加适合自己业务的设计模式。

玩物数据流的逻辑设计

本文旨在介绍数据从产生到回流可用过程中所经历的各个阶段,帮助理解整个数据的流向。

IM主子账号逻辑设计

在有限的人力、物力跟时间资源下,基于三方IM云服务设计一个能够快速迭代、满足业务、方便扩展的IM系统。

DTS流程解析

数据传输服务(Data Transmission Service,简称DTS)帮助我们在关系型数据库、NoSQL数据库、数据仓库等数据源之间迁移数据。

DTS支持多种数据传输方式,包括数据迁移、数据同步及数据订阅。我们可以根据使用场景选择最适合的数据传输方式。

浅谈数仓分层

各个业务系统数据库中的表都一股脑被放入数仓中,BI在取数做看板的时候,不免会读取全量的表,这其中有许多无用的数据IO会导致资源使用效率低,计算时间过长,导致我司的看板产出时间基本都维持在10点以后,有时候数据产生问题,甚至会延迟到下午2-3点。在没有数据支持的情况下,运营同学进行业务决策就如黑夜中走路一般,没有了方向,会造成一连串的不可估影响。

Android图片加载优化方案

在电商APP中,图片在整个页面中占比最大,清晰高质量的图片能够明显提升转化率。但是APP运行环境错综复杂,往往我们会遇到 图片压缩导致模糊、列表加载长时间显示空白图、查看大图黑屏过久、甚至因为图片过大导致crash等。

可编排下单服务引擎设计

本文分享在多场景、多业务维度的订单下单业务中,透过可编排的业务框架提升代码可扩展性和可维护性。

玩物得志接口自动化实践

自动化测试在当前市场上应用非常广泛,主流有接口自动化测试和UI自动化测试。

在此基础上,加上持续集成,就能实现全自动化测试。今天主要和大家聊一聊接口自动化测试,以及我们做的事情。

初识响应式编程与Webflux

本来数据是我们自行处理的,后来我们把要处理的数据抽象出来(变成了数据流),然后通过API去处理数据流中的数据(是声明式的)。可以参考 java8的stream 来理解。但是stream是同步流。

多线程在业务中的实践

在客服工单系统中,为了方便客服人员处理用户进线反馈问题,需要将工单的日志、工单的基础信息、订单信息、商品信息、客户基本信息、订单的类型、订单的物流信息等重要的数据都要加载出来放在工单详情中供客服人员查阅以便快速处理用户的问题。

如果我们客服工单系统中的工单详情数据采用单线程的方式加载数据,那么我们客服在使用的时候会出来短暂的页面加载转圈的过程,这样一方面客服人员使用的体验度下降,另一方面也会影响其工作效率,为此我们客服工单系统采用多线程的方式加载工单详情数据。

玩物得志APP通用弹窗设计

弹窗作为APP与用户交互最基本、最重要的控件之一,在应用的使用过程中占据着十分重要的地位,尤其是在电商应用的首页展示中,重要的信息往往在第一时间以弹窗的形式向用户展现。如:新人引导、氛围活动、重要的通知公告、APP版本更新以及各种广告类弹窗等。

玩物得志APP经过长时间的业务迭代,项目中已经分散着大量各式各样的弹窗和引导,同样在首页的表现最为明显,例如首页目前需要处理的弹窗有:新用户888元优惠券弹窗、APP版本更新弹窗、通知权限引导弹窗、青少年模式引导弹窗、玩物口令弹窗、各种资源位广告弹窗、全局通知弹窗以及一些新功能引导蒙层等等...

需要处理的弹窗越多,弹窗之间的交互逻辑便越复杂,迭代的风险性也越高,例如弹窗可能出现显示顺序错乱、不同弹窗之间重叠展示等问题,从而给用户造成视觉失调或使用困扰,且弹窗开发层面也面临着成本高、风险大、灵活性差等问题。

因此,我们需要重新梳理APP通用弹窗业务架构,做到降低弹窗需求开发成本、快速响应各类业务场景,同时降低弹窗出错风险、保证弹窗展示的稳定性。

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.123.1. UTC+08:00, 2024-03-29 19:30
浙ICP备14020137号-1 $访客地图$