1. 背景 从2018年开始，有赞移动团队使用Weex做为移动端跨平台动态性技术解决方案。自Weex引入之后需求推进速度得到很大提升，因此被开发同学使用到各个App和各个模块中，在使用过程中各个App为了Weex调用Native功能，都各自实现了不同功能的WeexModule，经过2年多的发展，发现各个App中有很多功能差不多的WeexModule,例如：专用于路由跳转、配置中心、账号信息等类似功能的WeexModule 我们期望能有一个解决Native与Weex交互的通用解决方案，简化业务方接入工作，也方便同个Weex页面可以在不同模块或者不同App进行正常渲染，因此ZanWeexModuleSDK就孕育而生。下面将带大家逐步解析ZanWeexModuleSDK设计方案。 2. 现状分析 我们首先分析一个有赞通用的Native和Weex交互流程图 从上图我们可以看到，一个完善的基础WeexAPP它会有有很多个WeexModule用于Weex和Native组件进行交互，常用的就是路由、…
Read More概述 消息业务作为有赞移动的共享业务，在微商城、零售、美业等 B 端 App 中承担着多客服的角色，多客服是有赞为商家提供的连接商家和买家的即时消息客服工具；在精选、有赞客 C 端产品中扮演着用户联系商家的角色。在整个有赞产品中，是商家和用户沟通的桥梁，起着非常重要的作用。 痛点 我们通常来讲把出现在消息会话页面内的内容称做消息卡片，目前消息业务常见的消息卡片有文字、富文本、语音、照片、视频、通知消息，…
Read More背景 订单是电商服务的核心场景之一，微商城客户端的订单模块已经服务了商家多年，功能和体验上和 PC 端有一定的差距。为了弥补不足，提升商家的体验，产品经过一系列数据调研，发起了微商城订单模块的重构项目。 作为“乐于重构”的开发者，在此次重构中以增强代码维护性以及线上稳定性为目的，接受了这次挑战。接下来将从业务代码架构、历史代码改造两方面，简单地聊一聊我们在此次重构中的一些经验。 业务代码架构的改进 1. 组件拆分 上图为旧订单列表和新订单列表的截图 上图是新订单列表中订单状态配置和筛选项配置的截图 不论是新订单列表还是旧订单列表，页面核心功能区域…
Read More使用场景 作为移动开发的我们经常会遇到两种需求： 1. 展示逻辑线上需要随时变更，例如登录注册页面用户协议链接的变更 2. 新业务的灰度下发，如订单等核心业务的重构，如何去保证灰度到指定的商家或适当的灰度比例，在确保线上业务的稳定性的情况下来进行数据的灰度下发。 现状 为了解决以上问题，就需要App侧具备一定的动态化能力。 目前增强App端的动态性方式，通常来说有下面几类： 1. Hybrid…
Read More背景 & 痛点 & 价值 稳定性始终会是一家成功公司的重要指标，在移动端亦是如此。跟大部分创业公司一样，有赞在创业初期选择以核心业务为主， 在一些基础设施的搭建上主要以使用三方平台为主(腾讯bugly)。随着业务的发展和bugly的长期不维护，慢慢出现一些三方平台的弊端。例如： * 某次版本上线之后，没有及时发现其隐藏的Crash, 导致故障产生 * Crash发生之后，无法根据特定规则分给某位处理人。 * 某个版本上线灰度时，该版本在特定角色下存在Crash。这个时候没法中断灰度版本的下发 crash平台建设的线路规划 为了解决这些问题，我们就开始着手搭建自有的Crash反馈平台。…
Read More