各家大厂的小程序百花齐放，取得了极大的成功。然而各家平台的开发规范不同，同时研发几家平台的小程序和快应用，在前端团队人数有限的情况下，如何能搞定诸多平台的小程序是摆在我们面前的难题。基于uni-app开发跨平台小程序有效地解决了我们的痛点。

早期之家在C端产品的即时通信功能是直接使用第三方商业软件服务（SaaS），功能扩展性上存在很大制约，考虑到后续业务发展需要、数据安全、内容实时审核及性能、自主可控高可用架构等因素，决定自主开发IM即时通信平台并逐步迭代替换。

低代码是无需编码或编写少量代码，通过可视化图形界面，用拖拉拽的方式来快速生成应用程序的开发模式，达到能快速高效完成业务目标。

弹窗作为一种手段，被广泛用于活动或商业化。首页作为App的核心入口，首页的弹窗自然是最重要的活动或商业入口之一，如何平衡好用户体验与商业及活动，就变成了一个核心问题。

App利用首页弹窗和CPL结合，从而产生了重要的商业价值，但是当用户对投放内容意向不够强烈时，甚至没有意向时，如果去弹窗对用户就会产生干扰，严重影响用户的体验。从商业结果衡量上，会重点关注转化率（CVR）等；从用户体验衡量上，会重点关用户投诉，评分。

之家云-云存储采用开源的分布式存储，目前承载之家的计算服务，视频，ARVR，前端JS、CSS等在线数据存储服务。并且针对前端需求提供了合并加载功能。本文通过车商城系统的迁移实例来介绍该存储系统的概念、结构、遇到的问题以及解决方案。

本文首先介绍了强化学习的基本概念，并着重梳理了一类模型无关的强化学习，即策略梯度算法。随后本文对其中的两种算法，进行了重点地分析和比较。最后，本文展示了基本策略梯度在之家业务中的一些应用，并讨论了该方法这些场景下的鲁棒性。

本文主要分享Next.js在海外项目开发实践中的一些技术细节。Next.js是一个非常棒的轻量级的react同构框架，框架自身集成 webpack 、babel 、express等，使用它可以快速的开发出基于服务端渲染的react应用。

汽车之家主app前端开发广泛使用React Native技术，因为其具有跨平台可以动态更新功能。目前有类似自驾游业务线利用React Native技术在汽车之家app上实现无限瀑布流列表的功能。优化前自驾游瀑布流列表在安卓低端机上滑动多页后会出现明显卡顿现象，快速滑动屏幕整体会出现白页的情况。

汽车之家作为汽车行业垂直类重要资讯平台，积累了大量用户，日均流量大；充分利用之家的流量，打造一款以汽车关注效能提升为目的，以内容+人群包智能匹配为核心的优质产品，更好的为买车、看车、用车的用户服务，这是智能关注平台系统这款产品的初衷和背景。

想知道如何让测试更加精准？更加有效？如何做到以一当十？如何让自动化测试在测试工作中发挥更大的作用？本文给你答案！

Unity 优化涵盖范围大,涉及知识面广，随着功能不断增长,需要优化的内容也在增多。在VI销冠神器的几次迭代中发现项目的各项性能指标都存在偏差,所以开始着手进行项目的优化工作。

本篇文章以浅显易懂的角度介绍一下 Unity 优化和VI销冠神器的优化经验。

在前后端分离和服务化的环境下，通常需要一个API网关统一对接C端、B端和运营等前端项目。这个API网关的主要作用有两个：

一是为所有前端项目提供统一的入口，然后按照规则转发到后端服务上，之所以多一层转发，是因为服务化后的项目与前端是多对多的关系，一个前端项目可能会访问多个后端的项目，一个后端项目也可能对多个前端项目提供服务。

二是对所有的前端项目进行统一鉴权，鉴权后将用户ID写入请求头并转发给后端项目，所有的后端项目都是无会话状态的，只需要根据ID对外提供接口。

Spring Cloud Gateway 和 Netflix Zuul 都是这样一个API网关项目，能够按照业务规则实现请求的转发功能，也可以将统一鉴权很好的集成进去。最开始使用的 Zuul，和其他业务项目一样基于 Web Servlet 技术栈。随着 Spring 不断的升级，后来的项目也就从 Zuul 改成了 Spring Cloud Gateway。由于 Spring Cloud Gateway 构建在 Web Reactive技术栈之上，因此相关的业务就开始使用 WebFlux、WebClient 和 Reactor。

随着业务的增长，页面涉及的业务线越来越多, 为了实现一个需求, 往往需要调用多个 RESTful 接口组合数据, 然后绑定到 UI 组件上，呈现给 C 端用户。这样会有几个缺点，最明显的是客户端会发送多次网络请求，浪费tcp的开销。

其次，多个接口的请求，数据返回顺序并不固定，很容易导致bug，另外根据不同的场景，也不是每个接口返回的所有字段都会用上, 浪费了网络流量，还容易泄露敏感字段。前端技术人员也频频吐槽为什么这些接口的活要前端干。

为了解决这些问题, 我们小组引入了 GraphQL 作为 BFF 层, 利用 GraphQL 支持以图的形式构建数据，可实现在单个请求中获取多个资源，以及提供强大的查询语法能力，减少网络请求次数、裁剪冗余数据，缩短需求交付周期，提升应用响应性能。在应用的过程中，我们积累了一些经验，借此机会分享给大家。

汽车之家 H5 页面传统的埋点方式，是由产品申请埋点，技术人员在代码中根据要求添加埋点上报事件。埋点代码和业务代码耦合在一起，造成了对业务代码的侵入，也不利于埋点的查找和维护。

搭建本平台的目的就是为了让埋点和业务代码分离，同时使用可视化的方式，使非技术人员可以独立完成埋点区域、规则、参数的编辑，并生成包含本页面或项目所有埋点事件的 SDK，页面开发者直接引用生成好的线上 JS SDK 地址即可，不用关心具体埋点细节。

本文详细介绍了如何利用Gradle插件，Transform API和ASM在Android端实现全埋点相关过程以及原理，希望通过本篇文章能使大家对全埋点插件有一个较为全面的了解。

需求越复杂，使用DDD的收益越高。当产品只提出一个逻辑修改，而开发评估需要几十人日的时候，可能就该考虑是否应该用DDD来降低重复度，提高可维护性和效率了。