服务24亿级用户App的大前端实践
茄子科技（海外SHAREitGroup）是国内出海的先行者，2015年成立后就“走出去”。2017年，主要产品SHAREit（国内茄子快传）全球用户总量超12亿，成为新兴市场的“国民应用”。截止目前，茄子科技产品矩阵全球累计安装用户量近24亿，覆盖200多个国家和地区，涵盖全球45种语言。
服务全球几十亿用户，茄子科技如何提升App的用户体验？怎样解决App的崩溃问题？如何应对海外复杂的网络问题？……针对上述问题，InfoQ记者采访了茄子科技前端负责人。
提供高品质用户体验
用户体验是App应用的核心追求之一。在所有用户体验问题中，崩溃属于最高优先级。一旦出现崩溃，就意味着App彻底不可用，这会给用户体验造成非常大的伤害。
解决应用崩溃问题
据茄子科技前端负责人介绍，为解决崩溃问题，他们自建了一个APM平台，这样可以快速发现问题和协助定位问题。APM平台的价值在于把人力从繁琐、重复性工作中解放出来，从而专注于问题本身。
在自建APM平台中，要着重提高的是客户端的抓取成功率和平台易用性。前者是为了尽量全面还原崩溃现场，后者是为了尽可能提升团队解决问题的效率。除了APM平台，要长期解决崩溃问题还需要人和一套持续运转的机制。
最初解决崩溃问题时，落脚点在于解决存量问题和遏制新增问题。首先，他们发起一场集中性战役——全力解决存量崩溃问题。经过一个阶段的治理，崩溃率下降到一个极低水平。其次，为防止崩溃率再次飙升，他们又开始了崩溃预防，把问题消灭在萌芽阶段：梳理出已解决的Crash问题，然后归类，并由点到面地思考总结出预防手段。
例如，针对服务端API脏数据引起的问题，统一在网络层进行校验和兜底；针对一些第三方库引发的问题，用AOP手段进行Hook。
在交付流程中，添加编译检查阶段、自动化测试覆盖、更广的灰度触达等环节，尽可能将问题提前暴露。
即使问题发生在真实场景，APM平台也能实现分钟级报警，并且自动把问题分配到相关同学。
茄子科技前端负责人表示，“我们以APM平台为依托，预防为主，建立了一套完善的响应机制”。
App优化实践
除了应用崩溃，性能优化则是影响用户体验另一个关键。
据了解，茄子科技旗下的SHAREit，其用户覆盖200多个国家和地区。不仅用户设备非常复杂，而且网络状况也不好，因此用户更容易遇到App卡顿、启动慢等体验类问题。
为解决这些体验类问题，他们首先搭建了基于线上的性能指标体系，充分衡量用户遇到的体验类问题。然后根据重要程度评估优先级，抓住重点，逐个击破。比如，在启动速度优化上，常规的优化手段作用有限，他们为此开发和落地了任务调度框架。所有启动任务通过任务调度框架进行调度，这样不仅可以充分利用启动阶段CPU的能力，而且还能方便地收集到每一个任务在线上的真实执行情况。之后根据任务执行情况，进行针对性调整。同时，他们还通过ASM收集到在启动阶段抢先执行的Msg，然后与业务方一起确认并且后移。
网络优化
在网络层面，针对海外用户的网络环境复杂、质量较低等问题，茄子科技通过HTTPDNS、协议优化、按需加载、CDN预热、离线资源包和服务端渲染等方案，大幅提升网络请求的成功率。
考虑到SHAREit也是一个内容型产品，他们还在播放器层面进行优化，加入多码率预缓存策略、软硬解码自适应、动态追帧等技术，大幅提升视频相关的业务指标。
包体优化
在包体积方面，茄子科技进行过一次大的优化，应用包大小从42M缩减为15M。据悉，包体优化主要分为两个方面：技术层面和业务层面。在技术上，他们采取了五项举措：
一是删减无用代码、资源，精简第三方库；二是代码层面的统一优化，比如R文件删除、使用R8；三是图片压缩、格式转换和剔除重复图片；四是资源的混淆；五是dex的再次压缩。
在业务上，梳理出App的整体功能，下掉了渗透率较低的功能，并且对重点功能均实现Bundle化，这样在减小包大小的同时，也方便在不同国家的精细化运营。并且，技术同学为业务同学提供专门工具，从技术视角支撑和指导业务的优化方向。
茄子科技前端负责人表示，体验类的优化工作并不只涉及技术，单纯的技术优化非常容易遇到瓶颈或遇到无法推动业务方修改的困境，从而无法实现优化收益最大化。因此，他们在SHAREit的实践首先是调整项目定位，由技术同学主导，加入业务同学，统一战线。在更高层面统一双方目标，技术同学负责发掘优化项，提供工具和具体方案，业务同学负责更大规模的落地，各自发挥优势，双方共担项目，共享成果。
除了启动、网络优化、包体优化外，他们还对卡顿、内存、布局、电量、存储和线程等性能的多个维度进行优化，“我们的追求就是让用户在使用产品时有一个高品质体验”。
前端工程化建设：从石器时代到信息时代
前端工程化，通俗的理解是，尽可能快速地实现可信赖的产品。其中两个关键词，“快速”，讲求开发速度、构建速度、测试速度、问题定位速度；“可信赖”，包括代码的质量、产品的性能、安全、及重现和定位问题能力。茄子科技前端负责人介绍，SHAREit的前端工程化建设经历了三个阶段：石器时代，工业时代，信息时代。
石器时代
在石器时代，典型特征是单工程的MVC架构，公司发展初期人比较少，反而效率更高，问题也比较少。但随着公司发展越来越快，SHAREit从单业务发展到多业务的平台型产品时，单工程架构在人员节奏方面出现了较多问题，如代码耦合导致一些问题浮现出来。这时，便开始工程组件化重构，进入到工业化时代。
工业时代
工业化时代，典型的特征是组件化。茄子科技使用的是多工程、多仓库的方案，每个组件或SDK都有自己独立的仓库，都可以独立于主工程进行单独的编译和运行。这方面分为三大层：APP的壳、业务层、基础层，基础层再往下还有更多、更细粒度的划分。前端团队自上而下通过AAR的方式进行依赖。组件化采用“分而治之”的思想，很好地解决了多团队协同作战的问题。
信息时代
随着公司孵化更多产品，每个产品在不同国家定制不同功能，规模越来越大了，用以前的组件化形式很难高效地支撑现有的业务，于是，茄子科技引入了GoogleBundle技术，进入到信息化时代。其实针对这一问题，国内多采用插件化的方案，但由于海外不能做插件化技术，茄子科技只能运用谷歌自有特性。在信息化时代，典型的特征是Bundle组件化。Bundle模块具有反向依赖的特征。通过增加Bundle壳及自动化检测工具的形式，让AppBundle的特性和以前已有的组件化融合，让开发者保持已有的开发模式。通过AppBundle，可以做到针对每个国家用一个APP按需定制不同功能，如内容、直播、游戏等。为提升效率和质量，茄子科技还搭建了客户端CI/CD平台，流程主要有编码规范检测、大文件 / 图片检测、静态代码扫描，关键文件触发Review、代码Review、安全风险检测，预编译、包体积监控，编译速度监控等，能做到自动打包、自动检测、自动化测试与发布。
据悉，前端团队已经涵盖开发、测试、构建、部署一系列流程，通过自研APM系统的预警机制、自动分配、辅助信息等，能够及时发现且快速定位问题，并优化迭代，最终形成整个研发流程闭环。
Bundle技术的应用与实践
2019年，茄子科技前端团队开始接触Bundle技术，并在当时做了试点。通过这次尝试，他们发现Bundle模块的开发、编译和发布等都与原来的Library形式有很多不同。因此，他们做了Bundle组件化。
据悉，他们将Bundle的开发、编译、发布等特性与现有组件化方式融合，让业务开发者保持原有开发模式对Bundle的特性几乎无感知。
在具体实践中，茄子科技前端团队做了四件事：
第一，为每个Bundle组件增加一个壳。Bundle组件还是以原有的Library开发和发布。Bundle壳依赖App壳和Bundle组件。Bundle壳中只是配置了Bundle的集成属性，无任何逻辑代码。这样很好的解决了Bundle模块反向依赖宿主的特性。
第二，资源隔离。Bundle组件与宿主资源隔离，不能互相访问。针对这种情况，他们做了自动化检测工具，将问题暴露在编译阶段。
举个例子，GameListFragment是Bundle组件的代码，继承了BaseRequestListFragment（宿主的基础SDK代码）。其布局资源文件使用了ActionPullToRefresh控件。
当调用findViewById（R.id.pull_to_refresh）时，Bundle组件调用了宿主资源，这样编译是可以通过的，但是会在运行时出现问题。解决办法是由子类提供getXXId方法，父类复写即可。
第三，APT/AOP等第三方库不好用，他们通过修改其源码进行适配。比如使用的Android路由框架Router，修改其自定义的GradlePlugin的扫描Scope，让它可以扫描到Bundle组件及其依赖。此外，通过Bundle模块安装状态，判断是否将apt生成路由信息注入到ServiceLoaderInit，保证有无Bundle模块时，路由信息都可以成功注册。
第四，线下模拟真实的Bundle模块组合。结合CI/CD在打包时，增加按国家、语言等多种维度的产出aab集合，方便测试人员在线下测试各种Bundle模块组合成aab的情况。
结果，Bundle组件化的实施不仅极大减小了应用包大小，SHAREit从原来的42M缩小到15M。而且，App实现了动态按需下发，除本身支持的国家、语言、屏幕等之外，还会按照需求下发，比如创作者中心模块只有在创作者登录后才会有入口引导下载。