移动端

什么是挪动端BI 维基百科 上对于 挪动端商业智能的定义是这样的 \> Mobile BI is a system that presents historical and real-time information on mobile devices for effective decision-making and management support. It enables analysis on smartphones and tablets, leading to increased firm performance. \> 挪动商业智能是一种在挪动设施上展现历史和实时信息的零碎，用于无效决策和治理反对。它能够在智能手机和平板电脑上进行剖析，从而进步公司业绩 挪动端上的数据分析 手机 + BI = 挪动端BI ? 从出现后果上来说是这样的，将数据可视化交互后果通过手机端显示即可。但挪动端自身简单的发展史又在揭示咱们,事件未必如此简略。拿最根本的技术实现来说,挪动端视图如何解决?(pc、mobile 和平板的出现布局差异性微小),挪动端的网络申请是否要专门进行优化(个别状况下挪动端须要利用无限的网络流量实现指定的需要),是否要开发挪动端原生程序,开发运维老本要如何升高? 诸如此类的问题都会导致挪动端的数据分析场景须要和 PC 上的数据分析大屏将是两种不同的开发施行策略。换个角度来讲,相比于PC端，如果挪动端BI须要减少相应的老本，是否还有必要进行挪动端的定制化开发呢,对于公司自身而言，挪动端又是否能保障在收益方面的增长会补救老本上的付出呢。本文就联合挪动端数据分析的倒退历程来聊聊挪动端BI的前世今生。 （图片起源:人人都是产品经理） 挪动端BI的前世今生 晚期的挪动端数据分析 最开始的挪动端商业智能简陋的让人惊讶,所有的数据分析信息都是通过短信或者寻呼机来提供的,而且能提供的数据量十分无限，况且没有交互能力。这就导致了通过简短的短信文本拿到的数据价值倒不如间接用打印进去的纸质报表来的不便。这个阶段的挪动端数据分析只是一个简陋且低廉的玩具，鸡肋且体验极差。 （图片起源:知乎- 第一条短信） 互联网时代的挪动端数据分析 经验了晚期的短信和呼机时代的挪动端数据分析后，进入互联网时代后，挪动端剖析的舞台便跳转到了web端, 用户能够通过手机浏览器来拜访带有数据报表信息的 web 页面, 互联网的买通使得用户能够更便捷疾速的获取到数据信息。然而在那个数据流量按 KB/S流通的时代,狭小的设施屏幕,迟缓到让人解体的网络服务,适度压缩的展现数据让人们依然无奈对掌间的数据报表提起趣味。况且那个阶段的挪动端浏览器并不成熟，无奈满足用户理论的交互需要。 （图片起源: wikipedia） 挪动设施的疾速倒退 ...

导读在哈啰的APP中，流动、大促、周年庆等都须要咱们可能领有更快捷的响应速度、更高效的人力来缩短试错周期，而且流量区域经营位为了可能做到千人千面，又迫切的须要有一种能够依据不同的人群达到展现不同成果的目标。UI 可定制化、疾速迭代、高性能体验始终以来都是挪动端开发畛域的外围诉求，随着哈啰业务的一直拓展，越来越多的业务线对上述三点提出了更高的要求，但因为挪动端 App 发版的人造限度，无奈很好满足业务方的诉求。 基于以上一些业务痛点，咱们联合 Native 黄金流量业务区域对于性能极高的要求，输入了一套 Native 部分动态化计划 Wukong（悟空），截止到目前，已在App外部多个业务模块中失去验证。 Wukong 是什么悟空动静卡片 (Wukong) 最后是为哈啰投放零碎定制的 Native 高性能渲染引擎，是一套残缺的跨端原生部分卡片动静展现的技术解决方案，以业务赋能为核心，致力于解决UI定制化、逻辑动态化、缩短试错周期、晋升人效等相干问题，使得业务能够基于 Wukong 做到一次开发，随时上线，多端复用的成果。 技术劣势Wukong 在规范UI组件、JS 动静能力、款式反对等方面提供多种性能加持，同时反对自定义组件、自定义 JS Bridge的能力以满足更简单、更加定制化的业务场景。 反对 UI & 逻辑 动静公布，进步研发&经营效率原生页面内嵌动态化视图的接入形式，接入成本低Android / iOS 双端侧体现统一，反对实时预览，所见即所得UI渲染纯 Native 实现，体积小、性能好、内存少零碎介绍Wukong 遵循了 CSS3 中提出的 Flexbox 布局标准，旨在磨平多平台在布局零碎上的差别，为了达到一套模板双端统一的成果，对 Android 和 iOS 端组件款式的体现也进行了尽可能的对立，在开发方式上咱们抉择 XML 作为视图 DSL 的语言格局，同时定义了一整套的 xsd 标准来束缚 XML 的编写，辅助开发编写过程中提前躲避一些语法问题的同时也能更加容易进行入门应用。 如上图所示，在开发的过程中次要解决的是业务层相干的逻辑，模版的下载、缓存、校验，在 Wukong 外部有一套默认的实现，但并不是必须的，接入方齐全能够依据本人的业务场景来进行笼罩重写，对于模版产物的治理是一个绝对隐衷的操作，为了达到最大化的灵便度，须要由业务接入方来扩大。 其中 SDK 外部咱们设计了协定层，在初始化的时候来对接各种可插拔的能力，比方：自定义组件、自定义Bridge，同时将 SDK 外部的一些根底能力如：网络、埋点、路由、地位信息、设施信息等进行接口形象，使得业务接入时能够不便的代替为自定义的通用根底能力。 实现原理如果用比拟通俗易懂的形式来介绍 Wukong 的大抵实现原理，能够简略的了解为依照肯定的束缚标准编写的款式形容映射为 Native 的布局，从而达到款式逻辑动态化的成果。 通过 SDK 加载的流程如上图所示： ...

作者：高玉龙(元泊) 首先，咱们理解一下挪动端全链路 Trace 的背景： 从挪动端的视角来看，一个 App 产品从概念产生，到最终的成熟稳固，产品研发过程中波及到的研发人员、工程中的代码行数、工程架构规模、产品公布频率、线上业务问题修复工夫等等都会产生比拟大的变动。这些变动，给咱们在排查问题方面带来不小的艰难和挑战，业务问题会往往难以复现和排查定位。比方，在产品初期的时候，工程规模往往比拟小，业务流程也比较简单，线上问题往往能很快定位。而等到工程规模比拟大的时候，业务流程往往波及到的模块会比拟多，这个时候有些线上问题就会比拟难以复现和定位排查。 本文是笔者在 2022 D2 终端技术大会上的分享，心愿能给大家带来一些思考和启发。 端侧问题为什么很难复现和定位？ 线上业务问题为什么很难复现和排查定位？通过咱们的剖析，次要是由 4 个起因导致： 挪动端 & 服务端日志采集不对立，没有对立的标准规范来束缚数据的采集和解决。端侧往往波及的模块十分多，研发框架也各不相同，代码互相隔离，设施碎片化，网络环境简单，会导致端侧数据采集比拟难。从端视角登程，不同框架、零碎之间的数据在剖析问题时往往获取比拟难，而且数据之间短少上下文关联信息，数据关联剖析不容易。业务链路波及到的业务域往往也会比拟多，从端的视角去复现和排查问题，往往须要对应域的同学参加排查，人肉运维老本比拟高。这些问题如何来解决？ 咱们的思路是四步走： 建设统一标准，应用 标准协议 来束缚数据的采集和解决。针对不同的平台和框架，对立数据采集能力。对多零碎、多模块产生的数据进行主动上下文关联剖析和解决。咱们也基于机器学习，在自动化教训剖析方面做了一些摸索。对立数据采集规范 如何统一标准？ 目前行业内也有各种各样的解决方案，但存在的问题也很显著： 不同计划之间，协定/数据类型不对立；不同计划之间，也比拟难以兼容/互通。规范这里，咱们抉择了 OTel，OTel 是 OpenTelemetry 的简称，次要起因有两点： OTel 是由云原生计算基金会（CNCF）主导，它是由 OpenTracing 和 OpenCensus 合并而来，是目前可观测性畛域的准标准协议；OTel 对不同语言和数据模型进行了对立，能够同时兼容 OpenTracing 和 OpenCensus，它还提供了一个厂商无关的 Collectors，用于接管、解决和导出可观测数据。在咱们的解决方案中，所有端的数据采集标准都基于 OTel，数据存储、解决、剖析是基于 SLS 提供的 LogHub 能力进行构建。 端侧数据采集的难点 只对立数据协定还不够，还要解决端侧在数据采集方面存在的一些问题。总的来说，端侧采集以后面临 3 个次要的难点： 数据串联难性能保障难不丢数据难端侧研发过程中波及到的框架、模块往往比拟多，业务也有肯定的复杂性，存在线程、协程多种异步调用 API，在数据采集过程中，如何解决数据之间的主动串联问题？挪动端设施碎片化重大，零碎版本散布比拟散，机型泛滥，如何保障多端统一的采集性能？App 应用场景的不确定性也比拟大，如何确保采集到的数据不会失落？ 端侧数据串联的难点 咱们先来剖析一下端侧数据主动串联所面临的次要问题。 在端侧数据采集过程中，不仅会采集业务链路数据，还会采集各种性能&稳定性监控数据，可观测数据源比拟多；如果用到其余的研发框架，如 OkHttp、Fresco 等，可能还会采集三方框架的要害数据用于网络申请，图片加载等问题的剖析和定位。对于业务研发同学来说，咱们往往不会过多的关注这类三方框架技术能力，波及到这类框架问题的排查时，过程往往比拟艰难；除此之外，端侧简直齐全异步调用，而且异步调用 API 比拟多，如线程、协程等，链路买通也存在肯定的挑战。这里会有几个共性问题： 三方框架的数据如何采集？如何串联？不同可观测数据源之间如何串联？散布在不同线程、协程之间的数据如何主动串联？端侧数据主动串联计划 咱们先看下端侧数据主动串联的计划。 在 OTel 协定规范中，是通过 trace 协定来束缚不同数据之间的串联关系。OTel 定义了 trace 数据链路中每条数据必须要蕴含的必要字段，咱们须要确保同一条链路中数据的一致性。比方，同一条 trace 链路中，trace_id 须要雷同；其次，如果数据之间有父子关系，子数据的 parent_id 也须要与父数据的 span_id 雷同。 ...

背景逆天文编码（将经纬度转换为具体结构化的地址）调用目前是整个地图服务调用量最大的接口，业务主流程多个节点依赖逆天文服务，接口不可用会间接阻塞订单。目前高峰期高德逆天文接口的QPS（Queries Per Second 每秒查问率）常常会几倍的超掉，超限报错的申请会通过哈啰地图平台的LBS（Location Based Services 基于地位的服务）兜底返回数据。 目前的逆天文调用量日均在2-3亿左右远超现有业务体量，面对业务在业务冲单时预估的几倍调用量增长与供应商较昂扬的提额价格，虽有LBS兜底但高峰期大量流量打到LBS也会极大减少服务压力，可能引发连锁反应，在冲单前优化调用量的问题保障接口稳定性火烧眉毛。 整体方案设计首先是要明确每个节点的调用量是多少，针对调用量头部的节点咱们想通过code review和与业务同学沟通调用节点的业务诉求，看能不能间接删除或通过其余形式进行优化，对于不好优化的，咱们想通过缓存机制来缩小一部分调用。 信息补充目前报表只能从业务维度来拆分，并不能晓得具体每个节点的调用量是多少，是哪个节点的调用量过大。所以第一步就是埋点补充调用节点参数。粗疏的埋点是我认为所有优化的第一步，它能明确线上到底是什么样的，能力更好的针对性优化，并在后续的优化回收，监控等过程中提供数据撑持。拆分后报表示意如下： 一一击破基于第一步的拆分，咱们曾经能晓得调用量较高的节点都是哪些，针对这些节点咱们将联合业务应用诉求与代码细化场景，寻找问题和优化空间进行了一一优化。这步优化总结下来有两局部： 以后节点并不需要调用因信息不对称导致的业务场景使用不当，如：1.业务页面有监控到地位更新就用以后地位触发逆天文的逻辑，理论高德定位组件外部会触发一次以后地位的逆天文调用并返回给业务，业务并不需要额定调用。2.地图缩放时中心点并没发生变化，不须要申请逆天文。 优化调用节点缩小调用联合业务应用场景上下文，尽可能的缩小调用，如：1.业务有一个性能会检测用户如果间隔以后地图中心点超过50m，就把用户以后地位变成地图核心地位并会触发逆天文的申请，但性能上线后因为在APP首页失效无奈开释导致整个APP生命周期始终在触发地位追随性能造成不必要的调用，相似问题的解决办法是对性能限度作用域，感知页面与APP的生命周期，如APP不在前台或不在以后页面就敞开性能。2.POI（Point Of Interest 趣味点）搜寻后会触发的上车点检索并进行逆天文的调用，上车点吸附胜利时须要的逆天文数据POI数据中均蕴含，上车点吸附失败时逻辑是应用POI搜寻的数据也不须要逆天文调用，所以咱们省去了POI搜寻后触发的上车点检索后的逆天文调用，均用POI数据填充逆天文的数据。 阶段产出这部分优化完结后咱们APP调用量级从日均2-3亿降到了3-4千万左右。 应用缓存咱们心愿能通过缓存来进步数据的使用率，用内存+磁盘缓存的形式长久化缓存数据以进步命中率。应用逆天文接口申请的参数（经纬度+申请半径）生成key，将申请后果存入到内存缓存+磁盘缓存中，获取缓存时先从内存中查找，没有再从磁盘中查找。 经纬度的聚合问题因为定位自身就会因为各种起因产生偏差（基站定位？信号遮挡？）或者用户在短距离内挪动，间接以经纬度生成key会重大影响缓存命中率，咱们心愿能聚合肯定范畴内的经纬度，这样能够无效晋升缓存命中率。 GeoHash算法GeoHash是一种地址编码方法，他可能把二维的空间经纬度数据编码成一个字符串。 算法思维GeoHash示意的并不是一个点，而是一个矩形区域，编码越长，示意的范畴越小，地位也越准确，GeoHash编码的前缀能够示意更大的区域。例如wx4g0ec1，它的前缀wx4g0e示意蕴含编码wx4g0ec1在内的更大范畴。 算法原理经度范畴是东经180到西经180，纬度范畴是南纬90到北纬90，咱们设定西经为负，南纬为负，所以地球上的经度范畴就是[-180， 180]，纬度范畴就是[-90，90]。如果以本初子午线、赤道为界，地球能够分成4个局部。 如果纬度范畴[-90°, 0°)用二进制0代表，（0°, 90°]用二进制1代表，经度范畴[-180°, 0°)用二进制0代表，（0°, 180°]用二进制1代表，那么地球能够分成如下4个局部： 会生成相似于Z的曲线，如果在小块范畴内递归对半划分呢？ 当咱们递归的将各个块分解成更小的子块时，编码的程序是自类似的（分形），每一个子快也造成Z曲线，这种类型的曲线被称为 Peano 空间填充曲线， Peano 空间填充曲线有突变性问题（有些编码相邻但间隔却相差很远，比方0111与1000，编码是相邻的，但间隔相差很大）和临界问题（与雷同GeoHash编码的点的间隔有可能大于临界不同GeoHash编码的点的间隔 如上图红点蓝点的间隔是远大于红点与绿点之间的间隔），评估后对于咱们的应用场景可承受。 编码长度就是对方块的划分次数。执行逻辑： 依据设定的编码长度对以后经纬度别离进行划分，失去两组二进制串（10101、01010）后以偶数位放经度，奇数位放纬度的形式合并成一个二进制串（1001100110）将二进制串划分每5位一组，有余5位补0（10011、00110）将各组的5位二进制串转成十进制，5bits对应着10进制的数值为0-31（19、6）用0-9、b-z（去掉a、i、l、o）这32个字母进行Base32编码，即对照下标将其转换为字符串（m、6） 最初拼在一起失去的字符串就是GeoHash编码（m6）编码长度对应的偏差范畴 目前缓存设置的编码长度为GeoHash9（5m左右误差）。 缓存淘汰机制采纳业界支流的LRU算法策略（Least Recently Used，即最近起码应用，是一种罕用的页面置换算法，抉择最近最久未应用的页面予以淘汰）。 算法思维如果数据最近被拜访过，那么未来被拜访的几率也更高。原理解析新数据插入到链表头部；每当缓存命中（即缓存数据被拜访），则将数据移到链表头部；当链表满的时候，将链表尾部的数据抛弃。 其余淘汰机制因为高德逆天文数据偶然也会有badcase须要高德更新数据fix，咱们心愿数据除了LRU被淘汰以外还能有其余维度的机制来更新数据： 工夫维度：咱们限度只应用2天内的数据，如超过则淘汰数据，从新申请并缓存拜访次数维度：咱们限度数据应用10次后，会被动淘汰数据，从新申请并缓存阶段产出冲单当日数据回收缓存命中占比iOS为26% 安卓为29.4%。 缓存算法优化缓存命中剖析目前日均的缓存命中率在25%左右，跟咱们的预期相比还是会低一些，起因剖析如下：目前因为防止占用大量内存（依据左近POI多少不同一条数据在2-8kb之间）造成OOM问题（Out Of Mana法力耗尽 Out Of Memory内存溢出 占用内存过大会被零碎强制杀死 造成闪退），规定了缓存最大数量为50个，那是否调大缓存个数就能进步命中率呢？比方进步到200-300个，咱们认为也不能晋升太高，而且会减少OOM的危险。从咱们的实现与场景剖析下： 1.LRU算法剖析长处：LRU算法实现简略，并且在大量频繁拜访热点页面时非常高效。毛病：因为LRU的机制，遇到偶发性或周期性的批量操作会导致LRU的命中率急剧下降，缓存净化状况比较严重。 2.联合场景剖析依据咱们的出行场景，咱们心愿命中缓存的数据分为两局部：一是短时间内的反复申请，这部分目前曾经能够满足；二是依据用户的应用习惯缓存下家或公司学校等罕用地左近的逆地理信息，这部分权重较高比拟容易命中缓存，但用户在行程过程中会有大量数据写入造成“缓存净化”。所以，咱们须要一种减少权重机制的缓存淘汰算法来解决行程过程中的缓存净化。 LRU-K算法算法思维LRU-K中的K，其实是指最近拜访页面的次数，LRU算法其实就是LRU-1，然而因为仅拜访1次就能代替他人，可能会造成“缓存净化”的问题，因而提出了LRU-K的概念，其核心思想就是将拜访一次就能代替的“1”晋升为"K"。 原理解析LRU-K算法须要保护两个队列：历史队列和缓存队列。 历史队列保留着缓存的对象（内存中），当对象拜访次数达到了K次，该对象出栈，并保留至缓存队列；若尚未达到K次则持续保留，直至历史队列也满了，那就依据肯定的缓存策略(FIFO、LRU、LFU)进行淘汰。 缓存队列则是保留曾经拜访K次的对象，当该队列满了之后，则淘汰最初一个对象，也就是第K次访问间隔当初最久的那个对象。 对应到咱们的实现里就是历史队列的数据获取超过K次后才会退出到内存缓存+磁盘缓存进行长久化保留，而历史队列自身也在充当内存缓存的角色不会有反复的存储,且因为有了历史队列进行权重过滤，会大大减少数据库写入，缩小整体性能耗费。下图为选用的磁盘缓存（YYCache）的读写性能图。 这部分正在进行中，预计能进步缓存10-20%的命中率。 ...

目录介绍01.图片根底概念介绍 1.1 图片占用内存介绍1.2 加载网络图片流程1.3 三方库加载图片逻辑1.4 从网络间接拉取图片1.5 加载图片的流程1.6 Bitmap能间接存储吗1.7 Bitmap创立流程1.8 图片框架如何设计02.图片内存计算形式 2.1 如何计算占用内存2.2 下面计算内存对吗2.3 一个像素占用内存2.4 应用API获取内存2.5 影响Bitmap内存因素2.6 加载xhdpi和xxhdpi图片2.7 图片一些注意事项03.大图的内存优化 3.1 常见图片压缩3.2 图片尺寸压缩3.3 图片品质压缩3.4 双线性采样压缩3.5 高清图分片加载3.6 图片综合压缩04.色调格局及内存优化 4.1 RGB色彩品种4.2 ARGB色调模式4.3 扭转色调格局优化05.缓存的应用实际优化 5.1 Lru内存缓存5.2 Lru内存注意事项5.3 应用Lru磁盘缓存06.不同版本对Bitmap治理 6.1 演变过程6.2 治理Bitmap内存6.3 进步Bitmap复用07.图片其余方面优化 7.1 缩小PNG图片的应用7.2 控件切割圆角优化7.3 如何给图片置灰色7.4 如何解决图片旋转呢7.5 保留图片且刷相册7.6 对立图片域名优化7.7 优化H5图片加载7.8 优化图片暗影成果7.9 图片资源的压缩01.图片根底概念介绍1.1 图片占用内存介绍挪动设施的系统资源无限，所以利用应该尽可能的升高内存的应用。 在利用运行过程中，Bitmap （图片）往往是内存占用最大的一个局部，Bitmap 图片的加载和解决，通常会占用大量的内存空间，所以在操作 Bitmap 时，应该尽可能的小心。Bitmap 会耗费很多的内存，特地是诸如照片等内容丰盛的大图。 例如，一个手机拍摄的 2700 1900 像素的照片，须要 5.1M 的存储空间，然而在图像解码配置 ARGB_8888 时，它加载到内存须要 19.6M 内存空间（2592 1936 * 4 bytes），从而迅速消耗掉该利用的残余内存空间。OOM 的问题也是咱们常见的重大问题，OOM 的产生的一个次要场景就是在大图片分配内存的时候产生的，如果 APP 可用内存缓和，这时加载了一张大图，内存空间不足以调配该图片所须要的内存，就会产生 OOM，所以管制图片的高效应用是必备技能。1.2 加载网络图片流程这一部分压缩和缓存图片，在glide源码剖析的文章里曾经做出了比拟具体的阐明。在这里简略说一下图片申请加载过程……在应用App的时候，会常常须要加载一些网络图片，个别的操作步骤大略是这样的： ...

作者 | 龙卷风 导读：随同着计算机视觉畛域的倒退，动画也变得越来越炫酷。各种动效解决方案在画质晋升时，也要兼顾文件体积和性能。通明MP4计划，能让设计师制作动画所见即所得，充分发挥了设计师的想象力和创造力。百度YYEVA动效播放器是基于通明MP4的根底，自研的一套轻量级、高性能、跨平台的动效计划，反对插入动静元素，提供欠缺的工具链，一站式解决从设计侧的资源导出、在线预览，到客户端渲染SDK。 全文3736字，预计浏览工夫10分钟。 01 YYEVA介绍YYEVA实现了一整套残缺的工具链，包含：资源输入端的AE插件、在线预览工具、客户端渲染SDK, 实现了通明MP4资源，可插入动静的业务元素等性能。 YYEVA是一个 轻量级、高性能、跨平台、动静的MP4资源解决方案YYEVA蕴含一套从设计工具AE插件、在线预览工具、客户端渲染SDK的残缺工具链基于仿射矩阵运算，失去图层每一帧的地位信息集成了MP4（avc/hevc）封装协定等相干性能高度可扩展性，可还原设计师的全副细节反对 Web、Android、iOS等YYEVA目前曾经在多个我的项目中应用，其中YY、贴吧、百度、难看等多个场景应用YYEVA实现简单的动效成果， 还提供给内部公司的项目组应用 案例Demo视频可点击链接查看：https://mp.weixin.qq.com/s/bX... 开源我的项目地址：https://github.com/yylive/yyeva YYEVA官网：https://yyeva.netlify.app/ 02 YYEVA摸索之路2.1 动画的集中实现计划 1.面向后果的记录形式该形式是通过记录动画每一帧的图像，播放时依据图像的RGBA，还原出动画成果。且只记录了最终后果，还原不出设计的动画元素，所以难以去批改动画元素，插入元素也比较复杂 长处：所见即所得，可还原所有设计成果；不必再针对具体特效进行开发反对；元素个数和静止复杂度对播放性能影响小 毛病：文件体积较大；不易反对动静插入或替换元素 2.面向过程的记录形式该形式是通过记录动画创作过程，在播放端，依据过程计算各元素静止轨迹，还原成果；还原动画须要实时计算，越简单的动画计算量越大，比方滤镜和贝塞尔曲线相干的计算十分耗费性能。 长处：体积较小，能够随便拉伸不影响品质；不便动静插入元素 毛病：性能差，耗CPU和GPU；对简单动画反对差，越简单动画越容易卡顿 比照以上2种动画的实现原理，为了达到所见即所得的成果，充分发挥设计师的想象力，YYEVA采纳的是面向后果的动画形式---通明MP4计划 相比序列帧计划，通明MP4具备更高的压缩率的长处，从而解决文件体积大的问题。咱们开发了一套YYEVA工具链，反对动静插入或替换元素 2.2 视频动画 以H264编码，MPEG-4的色彩采样规范是YUV，YUV是亮度和色度的重量叠加，不反对alpha通道，因而，如何让MP4视频反对透明度，业界罕用的形式是应用两个通道别离进行 存储视频的RGB数据和Alpha数据。因为视频动画所见即所得，反对更多简单特效等长处，目前广泛应用在YY各个场景中，成为了YY动效播放的首选计划。 如动画分辨率为500x500， 则Mp4的分辨率为1000x500， 其中右边500x500为RGB数据， 左边500x500为Alpha数据。Player组合成RGBA纹理再进行渲染显示。 2.3 混合MP4动效 在MP4动效里，增加一些如昵称，头像，图片等业务元素，罕用的做法是在MP4播放的时候，再叠加一个原生的View,或者应用 MP4 + SVGA/Y2A的形式来实现。这样往往存在资源下载、同步播放、保护多套资源等问题。 2.4 YYEVA计划 将视频帧和形容信息合到一个MP4资源，同步渲染， 解决了资源下载、同步播放、保护多套资源的问题。 YYEVA的Json形容信息如下所示： descript: 分辨率 、插件版本、rgb区域地位、alpha区域位effect: 类型、keydatas: renderFrame、outputFrame1、YYEVA形容动静元素形容一个动画的几大因素：工夫、地位、形变 工夫:通过Json的frameIndex形容须要呈现的帧索引地位:通过Json的RenderFrame形容元素在画布上的地位和大小形变:通过Json的OutputFrame获取元素形变的遮罩2、遮罩mask的演示形态能够通过2种形式来记录 记录图形的形态形容将图形残缺保留下来 03 YYEVA实现计划YYEVA框架图如下： 工具链的流程图如下： 3.1 YYEVA插件 YYEVA解决方案通过在AE上开发的一个扩大程序，解析设计师按标准制作好的相干图层信息，通过YYConveterMP4插件的图层解析模块、h264模块、资源合成模块，导出一个YYEVA的资源。 1、图层解析模块 规范性检测所选合成是否蕴含通明区域图层 ：目前插件解决的资源是基于YY通明MP4资源，所以源素材必须是一个通明MP4资源。即 RGB/Alpha左右拆散的所选合成是否蕴含Mask遮罩区域 ：文字遮罩区域是以 mask\_text 作为合成的name；图片遮罩区域是以mask\_image作为合成的name是否蕴含YYConverterMP4模板，该模板是用于上面的H264模块转换MP4应用的图层解决计算仿射矩阵：Matrix计算Mask地位：RenderFrame提取 Mask （遮罩） 合成计算 Mask合成下所有图层每一帧的RenderFrameCopy一份输入合成，并放大 Alpha 区域0.5倍后调整地位，同时分为三个局部：rgb 、 alpha 、 mask将所有的无效遮罩图层 Copy 到输入合成，并调整到mask区域，计算OutputFrame调整输入合成的区域大小将下面计算的RenderFrame 、 OutputFrame 组合成一个 Json 数据拷贝合成将制订的输入合成拷贝一份后，并放大alpha区域0.5倍后调整地位，同时分为三个局部：rgb 、 alpha 、 mask。 ...

创立型：单例设计模式1目录介绍01.单例模式介绍02.单例模式定义03.单例应用场景04.思考几个问题05.为什么要应用单例06.解决资源拜访抵触07.示意全局惟一类01.单例模式介绍单例模式是利用最广的模式 也是最先晓得的一种设计模式，在深刻理解单例模式之前，每当遇到如：getInstance（）这样的创立实例的代码时，我都会把它当做一种单例模式的实现。单例模式特点 构造函数不对外开放，个别为private通过一个静态方法或者枚举返回单例类对象确保单例类的对象有且只有一个，尤其是在多线程的环境下确保单例类对象在反序列化时不会从新结构对象02.单例模式定义保障一个类仅有一个实例，并提供一个拜访它的全局拜访点03.单例应用场景利用中某个实例对象须要频繁的被拜访。利用中每次启动只会存在一个实例。如账号零碎，数据库系统。04.思考几个问题网上有很多解说单例模式的文章，但大部分都偏重解说，如何来实现一个线程平安的单例。重点还是心愿搞清楚上面这样几个问题。 为什么要应用单例？单例存在哪些问题？单例与动态类的区别？有何代替的解决方案？05.为什么要应用单例单例设计模式（Singleton Design Pattern）了解起来非常简单。 一个类只容许创立一个对象（或者实例），那这个类就是一个单例类，这种设计模式就叫作单例设计模式，简称单例模式。重点看一下，为什么咱们须要单例这种设计模式？它能解决哪些问题？接下来我通过两个实战案例来解说。 第一个是解决资源拜访抵触；第二个是示意全局惟一类；06.解决资源拜访抵触实战案例一：解决资源拜访抵触 先来看第一个例子。在这个例子中，咱们自定义实现了一个往文件中打印日志的 Logger 类。具体的代码实现如下所示： public class Logger {private FileWriter writer;public Logger() {File file = new File("/Users/wangzheng/log.txt");writer = new FileWriter(file, true); //true示意追加写入}public void log(String message) {writer.write(mesasge);}}// Logger类的利用示例：public class UserController {private Logger logger = new Logger();public void login(String username, String password) {// ...省略业务逻辑代码...logger.log(username + " logined!");}}public class OrderController {private Logger logger = new Logger();public void create(OrderVo order) {// ...省略业务逻辑代码...logger.log("Created an order: " + order.toString());}}看完代码之后，先别着急看我上面的解说，你能够先思考一下，这段代码存在什么问题。在下面的代码中，咱们留神到，所有的日志都写入到同一个文件 /Users/wangzheng/log.txt 中。在 UserController 和 OrderController 中，咱们别离创立两个 Logger 对象。在 Web 容器的 Servlet 多线程环境下，如果两个 Servlet 线程同时别离执行 login() 和 create() 两个函数，并且同时写日志到 log.txt 文件中，那就有可能存在日志信息相互笼罩的状况。为什么会呈现相互笼罩呢？咱们能够这么类比着了解。在多线程环境下，如果两个线程同时给同一个共享变量加 1，因为共享变量是竞争资源，所以，共享变量最初的后果有可能并不是加了 2，而是只加了 1。同理，这里的 log.txt 文件也是竞争资源，两个线程同时往里面写数据，就有可能存在相互笼罩的状况。那如何来解决这个问题呢？咱们最先想到的就是通过加锁的形式：给 log() 函数加互斥锁（Java 中能够通过 synchronized 的关键字），同一时刻只容许一个线程调用执行 log() 函数。具体的代码实现如下所示： ...

1. 简介一个简略易用，而且完全免费的抓包工具 2. 应用npm i whistle --globalw2 start轻松启动，而后依据提醒在浏览器关上相应的监听窗口 3. 应用proxy switch omega 代理搜寻谷歌网上商店，搜这个名字，装置插件。 更改配置，而后抉择启用这个配置。 4.监听HTTPS windows用户，下载关上，而后装的时候肯定要装在 受信赖的证书颁发机构列表 mac用户，同样也是信赖 肯定要将证书装置到受信赖的证书机构。如果你没有装置证书，而后又勾选了Capture TUNNEL CONNECTs，那么点开网页会提醒一个受爱护的xxx的正告。5. 重启浏览器（这一步很重要）6. 手机抓包手机连贯和电脑同一个wifi，并且wifi设置手动代理到该ip和端口。比方这里就是代理到 10.227.42.125:8899 而后扫HTTPS的二维码下载即可。 如果没方法下载，那么能够思考本人起一个下载服务，而后电脑下载好的内容传输给手机。(安卓手机间接微信发给手机关上就行，然而ios要求肯定要拜访某个网页来下载的，什么几把玩意儿，而且IOS肯定要应用safari浏览器关上，其余浏览器关上无奈下载证书)如下是一个 express 服务的简略示例片段，手机和pc同一wifi即可拜访该服务即可下载证书。 如果路由器开启了 AP隔离 那么同一wifi下的不同设施是不能够互相拜访的，须要留神！后面的设置代理扫码无奈下载也可能是因为这个起因！# 间接疾速生成一个express利用npx express-generator// 更改router/index，记得要把动态文件放在public下，而后启动服务即可。var express = require('express');var router = express.Router();router.get('/', function(req, res, next) { res.download('public/rootCA.pem');});module.exports = router;

背景介绍 哈啰的业务的多样性体现到APP页面上，咱们会发现整个APP的页面设计出现的形式产生了很大的变动。早些年哈啰APP页面的性能较为繁多，上图是近几年哈啰APP的页面，能够看出页面更加多样化，很多业务的性能和信息都在这些页面上展现进去，也有很多交互的能力。 这样的业务发展趋势及APP的页面设计形式，给咱们的技术团队带来了两个痛点和挑战。一是交付效率，复合型的页面往往会波及到多个业务团队的需要，也会波及到多个技术团队去合作开发，效率就会降落。同时，这些页面都属于流量曝光型页面，产品侧须要做产品的AB测试，尽快地去上线并回收数据。如果发现性能须要调整，产品就心愿尽快变更，所以用户触达效率及交付速度都对产品的迭代有很高的要求。二是用户体验，哈啰的首页及各个业务的一级频道页，都是一个业务最外围的流量页面，对用户的体验要求很高，如多端一致性、稳定性和交互晦涩度这些指标，绝对于其余三四级页面来说，对稳定性的要求也会更高。 技术计划技术选型的两点思考 面临这些痛点和挑战，咱们想到了一些解决方案，首先介绍一下技术选型的思考。一是咱们要做一个架构，须要晓得架构的能力边界在哪里，要解决怎么的艰难和实现怎么的指标。这里列出了当初成熟的客户端APP的技术体系。从服务端来看，次要包含几个能力，最底端的是中间件的能力形象，下面是业务微服务的能力形象，再下面是面向端的能力形象，比方咱们通常会做一层BFF来面向端的接口封装，一层CDN来面向端的数据高效拜访的能力形象。从客户端来看，当初成熟的APP根本都有一套本人的组件化框架，做一些通用能力的积淀，咱们想要设计和实现的容器框架就是在组件化框架的下面，它的次要目标是承载各个外围页面的展示和相干的业务逻辑，这是整个容器的能力边界的大抵界定。咱们心愿这个容器首先是标准化的，通过标准化的伎俩来尽量抹平业务的复杂性带来的问题。二是隔离的虚拟化技术，尽可能进步本身运行的稳定性。这是容器的两个特点，也是咱们选定了在这个范畴做容器封装的技术。 咱们的容器既然要承载整个页面的渲染，应该用什么技术来实现动态化渲染，这是第二个技术选型的思考。其实业内也有很多成熟的技术计划。咱们能够从三个维度对这些技术进行归类，一是动态化能力，方才也提到这是很重要的思考点。二是原生体验，因为咱们对整个页面的晦涩度、稳定性都有极高的要求，如果在原生体验上做不到，那这个技术选型就不适合。三是开发成本，咱们的老本投入也是有下限的。比如说大家比拟相熟的Web容器的计划，是比拟容易引入到整个挪动端里的，它的劣势就是动静能力，相比整个原生的开发，它人造就具备动静更新的劣势。还有像React Native、Weex前几年也是十分火，它的技术选型是在整个原生体验和动静能力做了取舍。DSL计划绝对于后面两种又各有劣势。咱们怎么去做技术选型次要有两个思考点，包含投入老本和要害收益。一是投入老本，要联合本人业务的状态和团队的人力投入来考量，它须要思考整个技术研发我的项目的老本，从头开发还是在已有的架构上做降级，老本是齐全不一样的。其次现有零碎的降级危险，对现有技术架构兼容性，对业务的影响都须要思考进去。二是要害收益，任何技术我的项目都有很多收益，咱们要思考做这个零碎，哪些技术能力是次要的，哪些是主要的，哪些是可有可无的。这样剖析后咱们能够看到为了保障用户体验，性能优先肯定是最先考量的要害收益。其次咱们要晋升效率，尽可能升高团队单干的边界老本。同时咱们心愿架构可继续地去演进，来满足业务一直增长的诉求。基于这两个思考，咱们最初抉择了DSL计划。 架构模型 挪动端的外围框架有渲染层、协定层和逻辑层。渲染层是解决动态渲染和动静渲染如何实现的，协定层是提供一些标准化的接口封装，不便模块的运行、通信以及扩大。逻辑层是整个容器框架本人运行的时候，它的状态治理、数据管理、日志治理各方面的一些能力的封装。监控层是整个容器框架本人内建的一套监控体系，咱们在这个体系上也搭建了很多可视化的工具和用户触达的能力。模块层更多的就是模块的治理。 动静模块的实现和优化 上图是容器渲染层动静模块的渲染过程。首先还是获取配置，也是方才整个页面配置里繁多模块的配置信息。这个信息里的次要格局有两局部，一是节点信息，决定了这一个渲染素外面每个节点的元素类型，它可能是一个空的容器、一个文本，也可能是一个图片。二是布局信息，咱们用Flexbox的语法来形容所有节点之间互相的关系。咱们把配置信息解析进去生成了配置树，就是把配置文件变成数据模型。接着是动静绑定，最初会生成一个渲染树。在这个过程中会遇到一些性能问题，如中低端的安卓机，渲染性能较iOS机型会呈现显著降落。 咱们从多个维度进行了优化工作，一是数据预取；第二是渲染优化，将前置的渲染操作步骤放到后盾线程来解决，并铺平页面元素的层级；第三个是数据更新策略的管制，包含版本治理、虚构节点、动静绑定和Diff算法。 咱们把这个卡片上屏之后，用户须要交互能力，于是咱们设计了一套action指令的形式来实现，通过预埋在配置信息里的路由命令来实现手势辨认和相应的页面跳转操作。action指令能解决80%的场景需要，但在某些场景下不太好用。 比方这样的页面，有一个优惠券能够领，当点击红色去支付按钮的时候，卡片就会发生变化，比方按钮会置灰，卡片的款式也会发生变化。这种场景咱们通过实现一套jsruntime来进行反对，通过动静获取脚本来实现相似的操作。 容器逻辑层 这张图是容器逻辑层的模型图，能够从几个维度了解容器逻辑层的运作形式。第一是初始化，容器在启动时进行初始化，整个模块首先要进行自注册，咱们在适当时会获取相应的配置数据，接下来会走后面介绍的流程，依据模块的ID做模块的初创立，依据算法来判断是不是要上首屏，而后进行模块上屏。第二是运行时的状态，一个模块运行时次要有四个能力。一是它的布局和款式信息要维持，二是它的业务数据要维持，三是生命周期的状态，包含它的显示、暗藏、创立、销毁，四是事件监听，咱们基于一个模块通信的总线来实现整个模块状态的变更和互相关系的关联。此外容器有状态治理的机制。 容器协定层 第三层是容器协定层，咱们设计这一层的意义是想让模块开发更加标准化，无论是平台方还是业务方，能升高业务开发的复杂度。咱们次要形象了四层容器协定层，首先容器的布局协定和数据协定绝对比拟好了解，布局协定解决了布局的一些信息，如模块单元的大小、地位。容器的数据协定就是容器配置数据的填充，如单元格数量和内容；生命周期协定，包含创立、加载、显示、隐没和销毁。生命周期协定有很多利用的场景，比方性能监控和曝光计算。事件协定，事件总线的运行是依靠事件协定的，比方像模块事件、定时器事件。 容器运行 咱们从全局看一下容器运行是怎么做的，这里会看一下前端和服务端做的事件。前端会有一个配置平台。策略核心由算法驱动决定整个模块排序。业务微服务提供显示模块具体业务数据的起源，所有的信息都会交融成一个BFF层。端启动后，比方首页用了容器框架，启动之后它会做容器的初始化、模块的初始化流程，模块运行时又基于事件状态这样的管线来做一些状态的变更和模块的通信。 研发流程的改良 咱们设计了整个框架，新的系统对研发、测试、运维的工作形式都会带来很多的变动，很多环节上进行了生产提效。绿色标注的是挪动端惯例的发版流程，咱们看到波及到的节点和团队都十分多，跨团队的单干会遇到很多问题，发版速度并没有设想那么快。在新的零碎下，咱们通过在线零碎做的变更，这个环节的节点就会少很多，而且更新效率会快很多。 辅助工具 在整个开发过程中，咱们也做了很多工具来晋升开发的体验和效率。方才也讲到开发能够去配置平台做配置，咱们本地客户端也集成了一个调试工具，会预览渲染的动静卡片的款式。 公布和监控 公布上线的流程不同于传统的客户端发版，它变成了一个在线零碎的公布流程。除了公布的变更，咱们也做了一些监控剖析的能力为它保驾护航，咱们会采集性能的数据、稳定性的数据和异样的数据，在这些数据上建设可视化的剖析能力和告警触达能力。 我的项目实际 2020年咱们做了首页大改版，整个页面会变成右侧这样。咱们心愿首页可能承载流量曝光、业务散发、广告营销各方面的能力，首屏的模块会变得十分多，所以整个页面信息的多样化和逻辑的复杂度会高很多。基于这样的背景，咱们在2020年做了容器化架构的设计和降级。容器化架构降级次要分为两个阶段，2020年做了跨端对立的客户端的框架，2021年做了容器动态化相干的能力，进一步晋升研发效率。咱们打算在前后端各个平台，包含经营平台、算法平台等各方面去欠缺，包含低代码的开发工具，把这个零碎做得更好用更高效。 在1.0阶段，咱们次要为了反对业务的降级，实现两端对立的容器框架，能够把所有业务都出现在整个框架下面，同时具备一些根本的规范，比方协定层的协定，还有整个模块容器运行的状态。基于这个事件驱动的模型，2.0阶段咱们做了模块化，再之后咱们减少了动态化能力，进一步放慢交付效率和升高研发老本。3.0阶段咱们去欠缺前后端各零碎。 回顾整个我的项目，咱们在复盘的时候总结了两个教训。一是要做取舍，业内也有很多现成的计划能够思考，但并不是每一个都能够拿过去用，所以做技术取舍十分重要。要联合本人团队的能力和指标来做取舍，并不是越简单越好。二是咱们要继续去做架构的降级，要看久远些，咱们的指标是继续推动业务的增长。咱们整个首页反对的业务线有10多个，上线之后一年多的工夫里迭代了100屡次，放弃了极高的稳定性，同时团队的研发效率晋升30%，技术改造获得了很好的成果。 将来瞻望 最初介绍一下将来的瞻望，一是原生SDK能够做的工作，一直晋升稳定性，升高解体率和异样率，同时逻辑动态化上还有很多能够做的工作。二是欠缺工具箱，比方IDE、数据可视化等。三是建设生产力平台，让搭建平台更加简略易用，同时要进步零碎自动化能力。 （本文作者：秦阳） 本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。

vConsole是一款由微信公众平台前端团队打造的前端调试面板 个性：查看 console 日志查看网络申请查看页面 element 构造查看 Cookies、localStorage 和 SessionStorage手动执行 JS 命令行自定义插件 应用步骤1.npm下载 npm install vconsole -S2.在main.js中： import VConsole from 'vconsole'const vConsole =new VConsole()Vue.use(vConsole)效果图：

一. 业务背景随着各大视频平台相继推出弹幕穿人性能，广受好评。在公众生产视频的同时，大大增加了观看的娱乐互动性。接着，其余视频、动漫、浏览等内容平台也都减少了弹幕性能。弹幕曾经成为一种重要的内容互动的伎俩。优酷作为视频生产为主的业务平台，也针对相干爆款视频，推出了服务端宰割技术主导的弹幕穿人性能。服务端宰割性能稳固，辨认精度高，但存在肯定的存储和带宽老本，且无奈满足实时的特效，特地是爆款视频，时效性要求特地高。因而，优酷视频弹幕穿人业务对挪动端的人像宰割技术有强烈的需要。 针对优酷弹幕穿人业务，设计了实时性和精度都较高的挪动端人像宰割模型，加上淘系PixelAI SDK的加持，将人像宰割技术上线到优酷挪动端弹幕穿人业务。本文将从算法和工程两个方面，具体论述解决方案。 二. 显著人像宰割优酷弹幕穿人，次要用于视频中显著人像的宰割，对于非聚焦区域的人物和背景都无需宰割。挪动端和服务端模型的设计有很大区别，服务端精度要求高于实时性，因而模型的设计能够更大，对于输出的尺寸要求也能够更大。而对于挪动端而言，模型的设计须要精准到每个模块的设计和耗时需要，因而首先须要和业务明确显著人像的定义。显著人像除了指镜头下聚焦的区域外，还须要明确人物的尺寸比例。在明确算法需要的前提下，进行数据采集，打标，模型设计以及训练优化。1.构建数据集团队通过了几年的宰割积淀，曾经领有了百万级的人像宰割数据，且服务了团体的钉钉和淘系相干业务。针对优酷非凡的场景需要，将视频场景划分为了：古代都市剧，现代剧，军事题材。在不同的题材中，有针对显著人像的特色，分为了：半身、全身、单人、多人，以及人体不同的姿势。因为影视作品中有很多特殊效果镜头，会影响算法的宰割成果，所以针对这些特效，咱们还专门收集了一些长尾的数据，比方逆光、暗光、伸手等场景，能够进步模型的鲁棒性。最终，咱们应用了百万级的训练数据。 **2.模型设计2.1 轻量化网络钻研**目前罕用的轻量化网络模型有mobilenet系列、shufflenet系列，ghostnet系列等，然而这些学术界的挪动端模型离理论的挪动端利用还相差甚远，特地是运行时效上齐全不能达到业务需要。针对这一问题，咱们在团体的MNN挪动端推理框架下，从算子执行工夫，不同模块执行效率，不同网络效率三个维度在CPU和GPU模式下进行了比照试验，后果如下图所示： 通过网络参数控制变量试验剖析，VGG这类直筒型的网络设计性能最佳，效率最优。2.2 自研网络AirSegNet系列设计2.2.1 网络backbone设计基于前述试验论断，咱们从新设计了淘系新的挪动端宰割网络AirSegNet系列，次要的backbone设计思维如下：（1）Decode局部的卷积全副应用1x1 conv，先卷积扭转通道后与low feature map进行交融，从而升高计算量；（2）Decode局部交融了x2，x4，x8倍三种尺度的低层特色，还原更多细节；（3）设置双线性插值参数align_corners=False而非主流的True，获取更精准的边缘宰割，在True模式下，当推理的图片输出分辨率与训练不统一时，会存在像素点误差。 模型会针对不同机型，以及CPU或GPU模型，进行相应的批改，已达到最佳的性能。以后咱们设计实现了AirSegNet-CPU， AirSegNet-GPU，AirSegNet-Server三种骨干架构。2.2.2 训练优化在模型训练中，采纳穿插熵损失函数作为loss函数，在此基础上逐渐试验，发现了几个无效的策略：(1) 背景权重计算，解决误辨认问题。统计训练数据中前景和背景的散布比例，设计分类权重，分类权重采纳经典的计算公式：其中，r 示意前景或者背景的比例。=1/(log(1.1+r))(2) 边缘加权，解决边缘交融成果。 采纳5x5的核查ground truth进行收缩操作；采纳5x5的核查ground truth进行侵蚀操作；判断图1不等于图2的局部，即为边缘，给边缘调配5倍的loss权重。(3) 提出聚类loss，晋升宰割精度。计算公式如下：如果点i、j的ground thuth为同一类，则束缚两者的网络输入小于，否则束缚两者的网络输入大于。loss_(i,j)={█(max(‖e_i-e_j ‖-,0) if l_i=l_j@max(-‖e_i-e_j ‖,0) if l_i≠l_j )┤（4）应用topk loss。针对难负样本，尤其是针对模型稳固阶段的深度优化有较大的成果。在应用边缘加权和聚类loss的前提下，针对GPU训练模型的比照试验后果如下： 最终人像IOU达到了0.98。2.2.3 .后处理优化模型输入的成果在不同的分辨率下会呈现锯齿状的景象，特地是原图尺寸比模型的理论输出尺寸大很多的时候。因而，须要进行一系列后处理优化，进步理论的出现成果体感。（1）边缘优化，分为如下两步： 对原始网络输入应用3x3的高斯含糊，平滑人像边缘，理论在模型转成mnn时，同时将高斯含糊交融进网络，既能够节约解决工夫，又能够防止在C++中调用高斯含糊。因为网络输入的是0-1之间的概率值，因而交融背景图后在边缘处会存在过渡区域，采纳曲线变换放大过渡区域。（2）利用动量克制帧间抖动，为了自适应解决不动场景和跳变场景，动量是一个变动值，会依据变动的幅度扭转阈值。（3）针对画面变动很小时，采纳隔帧检测，缩小计算量。 三. 工程部署AirSegNet系列算法集成到团体的算法部署平台PixelAI SDK中，优酷应用此SDK进行对接。工程端，算法前向次要流程如下图所示，视频序列中每幅图像通过CNN网络，失去初步的宰割后果，随后通过后处理（包含平滑和动量解决等步骤），失去稳固精细化的宰割后果。整个流程中耗时最久的就是CNN网络推理。 基于团体的MNN推理框架，针对咱们的设计的AirSegNet-CPU， AirSegNet-GPU模型，在不同机型上进行了性能测试，如下所示：性能测试后果（单位：ms）：绿色代表CPU推理耗时，粉色代表GPU推理耗时。1.Android机型测试 测试论断：（1）对于高端机型来说（>85），CPU性能很弱小，轻量化模型GPU减速均不太显著。（2）对于中端机型来说（30-70），GPU模型利用GPU减速成果显著，但CPU模型利用GPU反而会变慢，这是因为CPU模型的设计不合乎GPU减速逻辑。（3）对于低端机型来说（<20），因为GPU太弱，所有模型应用GPU推理都会比CPU推理慢。2.ios机型测试 ios测试论断：对于iPhone系列来说，CPU性能很强，CPU模型推理速度高于GPU。3.优酷业务工程逻辑优化优酷业务要求，整个SDK申请耗时要小于15ms。依据如上的测试后果，PixelAI SDK框架会依据不同的机型，下发最优的模型，疾速适配不同的业务场景。但在优酷业务对接中，依然进行了如下两个重大的耗时问题：1）纯GPU模型初始化重大耗时。在下发GPU模型的时候，会存在初始化耗时特地重大的问题，达到秒的级别。因为，MNN的GPU推理初始化时耗时很高，如果单纯下发GPU模型，那么第一帧耗时就会特地高。这就须要从工程端去应用策略来解决。外围解决思路是，如果此类机型GPU模型最优化，则同时下发CPU模型和GPU模型，且同时初始化两类模型。在GPU模型初始化阶段，应用CPU模型后行进行前向，待GPU模型初始化实现后再切回GPU模型进行前向推理。依据如上论断，对于90%以上的机型，CPU的前向推理也是能够满足耗时小于15ms的业务需要的，在用户端达到无感的弹幕体验。2）纯CPU模型弹幕渲染卡顿。针对优酷弹幕业务的特殊性，除了算法以外，也有很多的渲染线程，在挪动端上同时应用模型和这些线程的时候，CPU资源十分吃紧，所以导致渲染卡顿的问题。依据如上的试验论断，对于90%以上机型的GPU模型前向耗时是能合乎15ms以内的需要的，因而采纳了CPU+GPU混合下发的形式。在不影响渲染的状况下，保障了模型的效率。 查看系列文章：优酷挪动端弹幕穿人架构设计与工程实战总结 参考文献：[1]Khoreva A, Perazzi F, Benenson R, et al. Learning video object segmentation from static images[J]. arXiv preprint arXiv:1612.02646, 2016.[2]Jégou S, Drozdzal M, Vazquez D, et al. The one hundred layers tiramisu: Fully convolutional densenets for semantic segmentation[C]//Proceedings of the IEEE conference on computer vision and pattern recognition workshops. 2017: 11-19.[3]Ding H, Jiang X, Shuai B, et al. Context contrasted feature and gated multi-scale aggregation for scene segmentation[C]//Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2018: 2393-2402.[4]Jégou S, Drozdzal M, Vazquez D, et al. The one hundred layers tiramisu: Fully convolutional densenets for semantic segmentation[C]//Proceedings of the IEEE conference on computer vision and pattern recognition workshops. 2017: 11-19.[5]Chen L C, Zhu Y, Papandreou G, et al. Encoder-decoder with atrous separable convolution for semantic image segmentation[C]//Proceedings of the European conference on computer vision (ECCV). 2018: 801-818.[6]Chen L C, Collins M, Zhu Y, et al. Searching for efficient multi-scale architectures for dense image prediction[J]. Advances in neural information processing systems, 2018, 31.[7]Tang J, Aksoy Y, Oztireli C, et al. Learning-based sampling for natural image matting[C]//Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2019: 3055-3063.[8]Li H, Xiong P, Fan H, et al. Dfanet: Deep feature aggregation for real-time semantic segmentation[C]//Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2019: 9522-9531.[9]Zhang S H, Dong X, Li H, et al. PortraitNet: Real-time portrait segmentation network for mobile device[J]. Computers & Graphics, 2019, 80: 104-113.[10]Tang J, Aksoy Y, Oztireli C, et al. Learning-based sampling for natural image matting[C]//Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2019: 3055-3063.[11]Zhang Y, Gong L, Fan L, et al. A late fusion cnn for digital matting[C]//Proceedings of the IEEE/CVF conference on computer vision and pattern recognition. 2019: 7469-7478.[12]Ghosh S, Das N, Das I, et al. Understanding deep learning techniques for image segmentation[J]. ACM Computing Surveys (CSUR), 2019, 52(4): 1-35.[13]Yuan Y, Chen X, Chen X, et al. Segmentation transformer: Object-contextual representations for semantic segmentation[J]. arXiv preprint arXiv:1909.11065, 2019.[14]Wang Y, Zhou Q, Liu J, et al. Lednet: A lightweight encoder-decoder network for real-time semantic segmentation[C]//2019 IEEE International Conference on Image Processing (ICIP). IEEE, 2019: 1860-1864.[15]Wu H, Zhang J, Huang K, et al. Fastfcn: Rethinking dilated convolution in the backbone for semantic segmentation[J]. arXiv preprint arXiv:1903.11816, 2019.[16]Sengupta S, Jayaram V, Curless B, et al. Background matting: The world is your green screen[C]//Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2020: 2291-2300.[17]Park H, Sjosund L, Yoo Y J, et al. Sinet: Extreme lightweight portrait segmentation networks with spatial squeeze module and information blocking decoder[C]//Proceedings of the IEEE/CVF Winter Conference on Applications of Computer Vision. 2020: 2066-2074.[18]Luo L, Xue D, Feng X. Ehanet: An effective hierarchical aggregation network for face parsing[J]. Applied Sciences, 2020, 10(9): 3135.[19]Cheng H K, Tai Y W, Tang C K. Modular interactive video object segmentation: Interaction-to-mask, propagation and difference-aware fusion[C]//Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2021: 5559-5568.[20]Wu T, Tang S, Zhang R, et al. Cgnet: A light-weight context guided network for semantic segmentation[J]. IEEE Transactions on Image Processing, 2020, 30: 1169-1179. ...

弹幕穿人计划次要分为两类：“云端离线人体宰割+端侧渲染”和“挪动端端侧实时人体宰割+端侧渲染”。在这里咱们别离简称为云端计划和端侧计划。本系列文章次要聚焦在优酷端侧弹幕穿人的技术实战上，次要包含优酷跨平台多媒体渲染引擎OPR简介、优酷端侧弹幕穿人架构设计与工程实战、淘系端智能PixelAI挪动端实时人像宰割技术、以及优酷弹幕渲染及弹幕穿人渲染技术的方方面面。 一、背景1、弹幕穿人的价值弹幕是目前用户观影的一个标配，弹幕能使用户在观影过程中与其余用户实时互动，晋升了观影体验。但弹幕也会遮挡视频画面，也会给用户带来一些困扰。弹幕穿人是视频内容与弹幕内容抢夺用户视觉焦点的一种均衡，可能让用户在生产弹幕的同时，仍然能够观看到视频中波及人物等的要害画面区域。在有弹幕穿人成果的时候，用户有更强的志愿关上更多行弹幕，弹幕穿人对用户弹幕开启行数有肯定促进作用，从而证实弹幕穿人能产生正向的价值。2、端侧弹幕穿人的劣势相较于云端计划须要提前针对某个剧生产、部署、下发，在介质有变动时须要从新生产等等不利因素，以及动则上百万的生产、贮存及带宽老本，不适用于直播等实时场景。端侧弹幕穿人则齐全依赖于挪动端本身的算力，最大劣势是实时、低成本，并且利于大规模铺量。3、端侧弹幕穿人的技术要求及难点3.1）穿人成果要精确无论是云端还是端侧，穿人成果都要求精确。否则如果不达标，mask与人物有错位、弹幕渲染频繁抖动等等景象，这些都是不可承受的。3.2）性能要达标咱们要在端侧保障弹幕穿人成果和性能，不能因为端侧弹幕穿人而导致CPU/GPU/内存等资源占用的飙升，或者导致弹幕自身渲染卡顿，更不能影响到视频或音频渲染的成果和性能。否则就是轻重倒置了。相较于云端计划，端侧计划的挑战更大，次要体现在如下几个方面：(1)算力无限端侧计划只能利用挪动端本身的CPU或GPU来实现链路上所有操作。相较于云端计划，端侧的算力十分无限。挪动端、边缘端和云端的GPU算力的介绍能够参考这篇文章《GPU深度报告，三大巨头，十四个国内玩家一文看懂》。(2)模型小因为端侧的限度，咱们不可能用大模型，这给检测的准确性也带来更大的挑战。(3)实时性弹幕穿人须要跟视频画面实时匹配。因为视频帧率个别在25~60之间，为了达到好的穿人成果，咱们对整个端侧弹幕穿人链路的实时性要求是十分高的。端侧穿人链路上所有操作，包含视频画面获取、人像宰割检测、弹幕穿人成果的实现及渲染上屏，所有这些操作加起来要求在20ms以内工夫实现(超过20ms就根本能感知到弹幕的卡顿了)，这样能力达到一个好的成果。否则穿人成果就会有滞后感、穿人成果与画面不匹配，甚至会对弹幕自身渲染的晦涩度和视频渲染的晦涩度都产生重大影响。以上这些因素都会给端侧弹幕穿人我的项目带来微小的挑战。 在淘系算法同学的大力支持下，PixelAI很好地实现了挪动端实时人像宰割的工作，给优酷端侧弹幕穿人性能的上线铺量打下了松软的根底。另外，咱们在工程侧也做了大量的优化（优化伎俩前面会有介绍），使市面上机型的大规模笼罩成为了事实。 二、整体架构设计1、架构图OPR(OPen Render的缩写)作为优酷主客全端的渲染引擎，次要负责audio、video和弹幕的渲染。另外，咱们也在OPR中引入了端智能引擎。因为OPR天生离audio、video和弹幕的raw数据最近，咱们能够间接在OPR里就去生产这些数据，产生咱们所需的端智能后果，给业务带来更大的价值。咱们不须要把数据再一层层地回传给更高的档次去做解决去做生产解决。所以咱们在OPR里融入一层端智能层，间接拿数据就能够解决端侧智能相干操作，而后把后果在OPR层展现、上报或者传给下层去生产，这样做的效率是最高的！ 咱们首先看一下整个OPR的架构图： OPR从上到下分为4个档次：(1)接入层OPR是跨平台的，咱们反对Android(Android手机和OTT设施)、iOS(iPhone、iPad、Mac)和Windows(DX9、DX11、DX12)平台。咱们形象出对应平台的接口，供业务层调用，来实现相应数据元素的渲染。(2)引擎层引擎层，按性能分为Video Engine，Audio Engine和Danmaku Engine，别离对应video、audio和弹幕的引擎。(3.1)渲染层除了根本的Video、Audio和弹幕渲染性能之外，OPR也包含相应的后处理能力，比方视频的帧享相干后处理、特效广告、色盲、zoom等等能力，音频的倍速、均衡器等能力，弹幕的节奏弹幕、流光弹幕、心动弹幕等特效能力。(3.2)端智能层次要包含人脸相干能力、语音能力、超分能力等，上层是其对应的撑持库。(4)平台层对各平台渲染接口的封装，包含2d/3d的opengl es、metal、directx和audio的opensl、audioqueue、directsound等。2、流程图 端侧弹幕穿人流程如下： (1)video失常解码、渲染流程中，咱们去实时截取以后视频画面帧；(2)送给端智能模块，去做人像宰割，失去人体宰割mask数据；(3)mask作为单通道纹理上传至GPU；(4)mask数据上传至GPU之后，咱们做一次5x5的gaussian blur，这样边缘处边缘处更加平滑；(5)把blur解决之后的纹理作为alpha去跟弹幕纹理做blend；(6)有穿透成果的弹幕surface叠加在视频surface之后，就能失去如上丝滑的弹幕穿人成果了。 三、工程实战1、技术选型及实际人像宰割能力，内部开源的opencv和团体内的mnn都有这个能力。然而咱们在挪动端实测之后得的论断是，性能和成果都达不到咱们端侧弹幕穿人的要求。起初咱们理解到，团体外部曾经有一个弱小的端上引擎PixelAI，有弱小的人脸等解决能力，曾经在淘宝直播等场景上线。咱们疾速实测了一下，确实在成果和性能都能满足咱们的需要。所以咱们最终定型PixelAI来作为咱们端智能的主引擎来针对端侧弹幕穿人来实时做人体宰割。2、性能优化1.1）帧画面高效获取（1）失常video渲染流程如下： video失常上屏流程是这样的，video解码后的数据（硬解或软解），通过aliplayer调到opr的接口。video_player->video_engine->video_layer->video_pipeline，前面对接一个个后处理filters去实现各个后处理性能，最初上屏。（2）用户截图场景下，帧画面的获取流程如下： 针对用户截图场景，因为截图场景不须要上屏，所以咱们自然而然想到如下流程，在所有的filter之后加一个snapshot的filter，这个filter实现数据渲染到一个纹理，而后拷贝进去即可。针对用户截图这种场景，上述流程没问题任何问题。咱们在加上snapshot filter之后从新走一遍渲染流程，截图实现后卸载snapshot filter，整个流程耗时若干毫秒。针对用户被动截图这个场景，咱们不会因为这若干毫秒感知到性能存在问题问题。然而，当咱们把整个链路利用到端侧弹幕穿人这个场景下，咱们发现每一帧截图的这个若干毫秒的工夫，就是一个致命的性能问题了。如果不压缩工夫的话，留给算法的解决工夫就太少了，无奈达到上线的规范。 (3)端侧弹幕穿人场景，帧画面获取流程如下 针对这种须要频繁实时截帧的场景，咱们设计了如上链路。咱们在所有filter的末端减少一路quick_snapshot filter，这个filter有两路渲染command。一路command按失常流程去渲染、失常上屏，不做任何额定解决。同时，另一路command把数据渲染到纹理，而后再拷贝进去。这样，两路相当于并行起来。在每一帧渲染过程中，不会有任何多余的创立和销毁snapshot filter的过程，齐全不会对失常渲染链路造成任何影响。同时，新加的一路command使截帧的效率最大化，很好地实时实现了频繁截帧的工作。通过实测，咱们的截帧性能晋升若干倍，为算法去做实时人体宰割节俭了大量的工夫。1.2）防止在cpu中实现耗时操作PixelAI有大模型和小模型，为了使底层的MNN不做频繁的初始化操作，大小模型要求的帧数据尺寸是固定的。如果大于或小于算法要求的尺寸，PixelAI会先应用OpenCV去做scale。理解到这些scale操作全副在CPU中实现，会造成大量的耗时，所以咱们针对大小模型，间接在后面的截帧操作中，通过纹理大小的变动，咱们就能够在GPU里实现了帧画面的scale，使截帧输入的尺寸就是PixelAI大小模型所要求的尺寸。这样就防止了应用OpenCV在CPU中做scale锁耗费的大量工夫了。1.3）异步调用模型从算法同学理解到，PixelAI人像宰割过程是一个原子操作，对应的底层MNN tensor等运算不可中端。一般来说，在GPU和高端手机的挪动端运算比拟快，但也有那种耗时比拟久的场景。算法侧咱们保障在一个固定的工夫内返回后果。如果算法耗时较久不返回数据，咱们在这里死等的话，就会导致弹幕渲染卡顿、穿人成果的错位等异样case，这是不可承受的。为了达到最好的性能和成果，咱们必须要实现一个异步调用模型。在失常工夫内返回后果的，间接应用mask数据上屏。在失常工夫没有返回的，咱们抛弃掉以后帧的mask数据。如果是若干帧以内没有返回，咱们都应用上一次检测的数据；为了防止这种场景下穿人成果的错位，超过若干帧就间接上屏，没有穿人成果了。这也是在工程上对弹幕穿人渲染成果做出的一个平衡解决了。3、成果优化要做到好的穿人成果，咱们在渲染层面也做了大量的优化，参见文章《优酷弹幕穿人渲染技术揭秘》。4、测试论断(1)算法测试后果，参见文章《PixelAI挪动端实时人像宰割》(2)优酷整体测试后果测试论断：咱们并没有因为引入端侧弹幕穿人带来大量的性能损耗。 四、瞻望挪动端端智能是将来一个趋势，挪动端弹幕穿人是端智能一个很好的利用场景。后续咱们会在OPR里衍生出更多的端智能利用场景，给优酷用户的观影带来更好的用户体验。 更多娱乐相干技术解读，移步➡️【阿里巴巴娱乐技术 公众号】

云原生的呈现，以致传统IT模式正在集中向云架构、云开发转型，其中在企业业务的互联网化、数字化过程中尤为突出，并衍生出“麻利开发”、“疾速迭代”的刚性需要。同时在互联网的下半场企业开始更加关注IT生产力所带来的商业价值。 国内软件开发行业也正处在多维度的改革阶段，对于ToB行业，低代码、RPA等一系列以效率为本的技术能力正在疾速崛起，围绕业务翻新开展的挪动开发畛域，不断涌现的多端碎片化和服务云端化正扭转着传统的企业数字化架构。挪动互联网通过10余年倒退，跨平台技术演进百家争鸣极大的促成了技术的倒退。跨平台技术具备的高效率开发与不输原生开发的性能体验，也在继续一直的为企业输入价值。 而LeaRun低代码开发平台也基于混合开发、API连贯、DevOps等能力面向全行业提供挪动开发技术，帮忙企业和开发者开释自动化和流程化能力，缩小大量重复性工作，无效晋升30%-60%IT我的项目效率。 LeaRun挪动端开发框架可在手机端、小程序端、微信公众号端口、H5页面端等各种智能挪动终端来搭载LeaRun低代码开发平台所开发进去的各种APP使用。通过挪动端APP，使用者能够很方便快捷的在手机上实现工作办公，随时随地把握公司企业的经营治理状况，并迅速做出决策治理和优化调整，直观的感触到智能化、信息化治理给企事业单位所带来的各种效益晋升。 在多端的背景下，LeaRun挪动端开发框架是一个高性能JavaScript框架，更趋近于原生的编程体验，同时连续Html5开发者习惯。通过提供简洁的模型来拆散利用的用户界面、业务逻辑和数据模型。或者通过“利落拽”操作，依据不同工业场景需要，用平台上预制的行业特有组件和API，简略几步疾速“定制化”工业利用。没有开发背景、但懂流程和需要的业务员或编程小白也能轻松上手，缩小开发环境、人员等综合老本的投入，适宜高度定制化的我的项目，帮忙企业低门槛、低成本实现数字化转型。 在LeaRun挪动端开发框架设计过程中，开发平台应用主动的形式生成可执行代码，代码的整体品质更有保障，出错更加可控。并且LeaRun低代码开发平台提供全源码交付机制，保障软件公司在不同的利用阶段、不同档次和不同规模的服务需要都能失去满足。同时LeaRun挪动端开发框架采纳组件模式，以及面向对象的开发方式，使得代码的结构化水平更高，代码更容易保护，安全性也会更高。 低代码开发不仅加重了软件维护的累赘。与过来相比，要解决的谬误和集成问题会大量缩小。而且通过LeaRun开发框架的代码生成即可生成安卓、小程序、H5等多端程序包，开发者不须要搭建特定的终端编译环境。通过缩小保护和开发工夫，开发人员能够专一于可带来更大业务价值的翻新工作。 应用LeaRun低代码开发平台弱小的挪动端开发框架，不仅能够无效晋升整体的IT我的项目效率，而且能够满足公司业务经营流程的全方位治理，实现口袋式商务办公。更多挪动端疾速开发性能请返回www.learun.cn/Home/VerificationForm 进行体验。

作者：刘长青(执水) 本文偏重论述手淘团队对挪动畛域全链路技术理念的原创性引入，整篇约1.2万字、浏览须要15分钟，读者将播种挪动技术域体验优化的思路转变，以及软件定义体验的积淀和研发实际。App 现有架构挑战2013年开始All in无线到现在，阿里团体挪动技术倒退十余年，历经几个要害阶段： 第一阶段，解决大规模业务并发研发的痛点，定义了Atlas（容器化框架, 提供组件解耦、动态性等反对）架构；第二阶段，建设ACCS（淘宝无线全双工、低延时、高平安的通道服务）长连双工加密网络能力，补齐端到端互操作挪动服务能力追赶行业；第三阶段，面向业务个性建设Weex、小程序等动态化研发框架，挪动技术进入动态化跨平台期间。中后期通过阿里挪动小组机制进行各BU拉通和能力共建。自此，挪动基础设施根本成型，各个领域各自积淀若干组做到能力复用，App根本造成下层业务、两头研发框架或容器、根底能力三层的架构。咱们团队作为无线端侧基础设施的承建方，过来重点是负责团体挪动端的根底能力建设，近年来，团队重点深刻淘宝业务场景开展性能优化，通过体验优化我的项目横向分析App架构和及相干调用链路，感触到团体App普遍存在如下共性问题： (图1 淘宝App架构挑战) 运维排查效率低下：首先是监控阶段，少数问题无监控或者监控上报后的信息无奈撑持更无效的剖析，须要依赖日志进行问题排查；其次是没有日志的问题，产生异样时并不会被动上传日志，须要手动捞取，用户不在线更是拉取不到日志；拉取到日志后，还会持续遇到日志读不懂的问题问题；跟服务端无关的链路，还会遇到服务端鹰眼日志只保留5分钟的问题，通过这样一轮下来，根本工夫曾经过来半天...端到端追踪不残缺：一个残缺的业务链路，流量会穿梭端到端多层，以一次下单为例，通过客户端所触发的网络申请达到服务器之后，会通过若干客户端模块解决、触发N次后端利用调用以及历经挪动网络的不稳定性，试想一下，这些调用中有哪些出问题会影响这次下单交易，有哪些步骤会拖慢整个解决流程、申请没返回不分明是服务端问题还是网络问题，如果各调用全链路性能定义不清，意味着各层问题得不到充沛裸露，这些因素都是须要思考的，加上端侧人造异步调用，导致各阶段度量和全链路买通存在重大挑战，目前现状就是客户端各层没有对立调用标准，并且不足拓扑构造，无奈还原调用链路，导致端到端无奈追踪；优化短少统一口径：过来因为各研发框架性能口径自闭环，不论是客户端原生技术，还是跨平台技术都是面向技术视角对立采集通用的技术口径，这种状况会人造导致各业务实现和体现差别微小，艰深说就是不靠近用户体感，会导致线上的数据难以反馈真实情况及优劣趋势，长久以来，淘宝的体验也始终在劣化，每年根本都要靠静止式形式来搞体验优化，无奈常态化放弃；挪动Paas流程赋能老本：大量的SDK组件输入团体各BU后，根底能力嵌入到不同的App宿主环境后，同样会遇到下面提到的几类问题，对各BU同学来说，基础设施更是黑盒，如果问题波及到基础设施，排查过程更加艰苦，加上没有现有的工具能够自助诊断问题在哪，遇到问题只能过去征询，各种拉群拉人，导致答疑老本居高不下。以上是从APP构造的角度对以后客户端在运维排查、度量监控、全链路优化等方面的有余进行的一些思考，也是咱们后续的发力方向。 可观测体系监控到可观测性的演变可观测性是一套理念零碎，没有对技术实现的具体要求，重点是通过引入该理念，将理念利用到咱们的业务迭代和问题洞察中。传统的运维可能只能给咱们带来最顶层的告警和异样的详情，当须要更深层次的错误信息定位的时候，往往会通过建群拉人，而后先通过人肉找寻问题的特色，甚至是某个模块的开发承当起剖析各个模块的依赖关系等的工作，问题解决根本波及3个角色以上（业务、测试、开发、架构、平台等）。 相比传统的监控，可观测性可能通过联合数据，并且将数据有机分割在一起，产生更好的连贯，帮忙咱们更好的察看零碎的运行状况，疾速定位和解决问题。「监控通知咱们零碎的哪些局部是工作的，而可观测性通知咱们那里为什么不工作了」，下图2阐明了两者之间的关系，监控偏重宏观大盘展示，而可观测性蕴含了传统监控的领域。 (图2 监控和可观测的关系) 从上图来看，外围还是察看各个模块以及要害调用和依赖等的输入，基于这些输入来判断整体的工作状态，业界通常会把这些关键点总结为Traces、Loggings、Metrics。 可观测性要害数据 (图3 可观测性要害数据) 联合Traces、Loggings、Metrics的定义和淘宝现有状况，做了一些解读： Loggings（日志）：基于现有TLOG（无线端到端日志零碎）日志通道，展示的是App运行时产生的事件或者程序在执行的过程两头产生的一些日志，能够具体解释零碎的运行状态，如页面跳转、申请日志、全局CPU、内存应用等信息，少数日志是没有实现串联的，当初引入结构化的调用链路日志后，日志在调用链场景结构化后其实能够转变为Trace，撑持单机排查；Metrics（指标）：是聚合后的数值，偏宏观大盘应用，对于问题定位不足细节展现，个别有各种维度、指标，Metrics数据量个别很大，须要针对场景做一些采样管制；Traces（追踪）：是最规范的调用日志，除了定义了调用的父子关系外（个别通过TraceID、SpanID），个别还会定义操作的服务、办法、属性、状态、耗时等详细信息，通过Trace可能代替一部分Logs的性能，长期看通过Trace的聚合也能失去每个模块、办法的Metrics度量指标，但日志存储大，老本高。全链路可观测性架构上述可观测体系理念在后端有一些实际落地，但回归到挪动畛域的个性和现状，有种种问题如下： 调用标准的问题：与云端的差别是端侧齐全异步，异步API极其丰富，且没有对立调用标准；多技术域的问题：研发框架数量泛滥，能力对外黑盒，如何串联存在大量难以感知的老本；端云差别的问题：端侧的海量分布式设施，意味着可观测模式的挑战与服务端也有实质差别，logging与metrics在服务端能够基于一套体系齐全上报实现，但单机埋点和日志量差别极大，这也是端侧埋点零碎和日志零碎拆散的起因，端侧则须要实现如何兼顾海量设施的单机问题排查和大数据下的指标趋势定义；端云关联的问题：端到端事实始终是割裂状态，以端侧为视角如何更好感知后端状态，如何做关联，如怎么继续推动serverRT（后端申请调用耗时）从IDC（互联网数据中心）到CDN笼罩，端侧全链路标识如何让后端也感知。因而，咱们须要围绕以上这些问题对挪动技术畛域全链路进行定义，并建设起相干畛域级的剖析能力和好的评估规范，能力更粗浅的洞察挪动端的问题所在，能力在问题排查和性能度量畛域继续服务好团体各App以及跨域的问题。 (图4 全链路可观测架构定义构想) 数据层：定义指标标准和采集计划，基于Opentracing（分布式跟踪标准）数据上报；畛域层：围绕问题发现到问题定位、性能继续优化体系、技术升级积淀几方面演进；平台层：积淀团体&竞对视角的比对，联合线上线下指标，引入厂商视角，驱动App性能晋升；业务层：全链路视角，买通端到端，除了客户端同学，还能够服务不同技术栈跨域的研发人员。回顾全链路可观测我的项目的指标，咱们设定为“打造全链路可观测体系，改善性能并驱动业务体验改善，晋升问题定位效率”，后续章节会重点解说每一层的实际。 挪动端opentracing可观测架构全链路形成 (图5 端到端状况、详情场景分层图) 端到端现有链路长，端侧存在各类研发框架和能力，尽管后端调用链路明确，但从全链路视角看，并没有与端侧买通。以用户浏览详情动线为例，一次首屏关上，会触发奥创、MTOP（无线网关）、DX三个模块不同的调用时序，不同的模块有各自的处理过程，不同阶段有不同的耗时和状态（胜利、失败等）；接着持续看滑动，能够看到模块的调用时序组合又不一样，因而不同场景下能够由若干因素随机组合，须要依据用户理论场景，划分若干维度来定义全链路： 场景定义：一次用户操作为一个场景，如点击、滑动都是独自的场景，场景也能够是多个单个场景的组合；能力分层：不同场景，有业务类，框架类、容器类、申请类的调用，能够对每个畛域进行分层；阶段定义：不同分层有各自的阶段。如框架类有4个本地阶段，而申请类能够蕴含后端服务端解决阶段；用户动线：一次动线由若干场景组成。全链路，就是把简单的大调用合成为无限个结构化的小调用，并且能够衍生出各种case： 「单场景+单阶段」的组合全链路；「单场景+若干分层+若干阶段」组合的全链路；「若干场景+若干分层+若干阶段」组合的全链路；... ...Falco-基于OpenTracing模型全链路为了反对Logs + Metrics + Tracing 行业标准，引入分布式调用标准opentracing协定，在上述的客户端架构上进行二次建模（后续简称为Falco）。 OpenTracing 标准是 Falco 的模型根底，以下不再列举，残缺可参考OpenTracing设计规范，https://opentracing.io/docs/o... 。Falco定义了端侧畛域的调用链追踪模型，次要表构造如下： (图6 Falco数据表模型) span公共头：黄色局部，对应OpenTracing标准的Span根底属性；scene：对应OpenTracing的baggage局部，会从根span往下透传，寄存业务场景，命名规定为「业务标识_行为」。比方详情首屏为ProductDetail_FirstScreen、详情刷新为ProductDetail_Refresh；layer: 对应OpenTracing的Tags局部，定义了层的概念，目前划分为业务层、容器层和能力层。解决业务逻辑的模块归属业务层，命名为business；提供视图容器归属容器&框架层，如DX、Weex都是，命名为frameworkContainer；仅提供一个原子能力的模块，归属能力层，命名为ability，如mtop、picture，层可利用于对同层同能力的不同模块进行横向性能比照；stages：对应OpenTracing的Tags局部，示意一次模块调用蕴含的阶段。每一层基于畛域模型划分了要害阶段，目标是让同层的不同模块具备统一的比照口径，如DX和TNode比照，能够从预处理耗时、解析耗时、渲染耗时掂量彼此优劣。比方预处理阶段名为preProcessStart，也能够自定义；module：对应OpenTracing的Tags局部，更多的是逻辑模块。比方 DX、mtop、图片库、网络库；Logs：对应OpenTracing的Logs局部，日志仅记录到TLog，不输入到UT埋点。Falco-要害要点 (图7 Falco要害实现) 端侧traceID：满足唯一性、生成快、可扩大、可读、长度短等准则生成；调用&还原形象：由traceID和span多级序列号一路透传，明确上下游关系；端到端串联：外围解决云端串联的问题，端侧ID透传到服务端，服务端寄存和鹰眼ID的映射关系；接入层返回鹰眼ID，端侧全链路模型存在鹰眼ID，通过这样的双向映射关系，咱们能晓得一个未返回的申请到底是因为在网络阶段没有胜利、还是没有达到接入层、或者是业务服务没有返回，从而将耳熟能详、粗粒度的网络问题变得可定义和可解释；分层度量：外围目标是让同层的不同模块具备统一的比照口径，撑持框架降级后的性能横向比照，思路为形象客户端畛域模型，如以框架类为例子，尽管框架不同，但一些要害调用和解析是统一的，因而能够形象成为规范阶段，其它相似；结构化埋点：首先采纳列式存储，利于大数据集的数据聚合操作和数据压缩，缩小数据量；其次，业务+场景+阶段积淀到一张表中，不便关联查问；基于Falco的畛域问题积淀：包含简单问题的要害定义、追踪问题的线索型日志、某些非凡诉求的埋点。所有畛域问题的信息被结构化积淀到Falco，畛域技术开发者也能够基于积淀的畛域信息继续发展剖析能力的建设，只有实现数据的有效性供应和畛域性解释合一，能力定义和解决更深层次的问题。 (图8 Falco畛域问题模型) 基于Falco的运维实际运维的领域极为宽泛，围绕问题发现、问题接手、定位剖析、问题修复要害流程，从海量设施的指标观测、告警，到单机排查、日志剖析等，大家都晓得要这么做，外面每个流程都波及很多能力的建设，但理论执行起来很难做，各方也不认可，淘宝客户端始终以来存在指标准确性和日志拉取效率低下的问题。如APM性能指标为例，淘宝App过来很多指标不准，业务同学不认可，不能领导理论优化。本章节会从重点分享下淘宝App在指标准确性和日志拉取效率方面的相干优化实际。 (图9 问题扭转用户动线以及运维零碎) 宏观指标体系以端性能横向战斗为契机，基于用户体感的体验，APM开启了相干降级工作，外围波及启动、外链以及各业务场景下的可视可交互指标，如何做到让指标对应的起点更贴近用户体感，次要有以下一些工作： 8060算法的降级：视觉有用的元素提取进去计算（如图片和文字），剔除用户不能感知的元素（空白控件、兜底图），如制订视图可视标准，满足图片库、鱼骨图等自定义控件打标；H5畛域：反对UC 页面元素可视可交互以及前端 JSTracker（事件埋点框架）回溯算法，与H5页面可视算法买通；深刻简单的场景：制订自定义框架可视标准，买通 Flutter 、TNode（动态化研发框架）并校准等各类研发框架，8060算法交由各研发框架来实现；外链畛域：买通H5页面口径，从新定义外链来到等负向动作。以启动为例，APM 在 校准后，蕴含了图片上屏等阶段后，数据尽管上涨了，但更合乎业务方诉求。 ...

端智能，是指在挪动端设施运行人工智能（AI）利用的技术。本文次要讲述公众点评搜寻场景下，在端侧部署大规模深度学习模型进行搜寻重排序工作的实际计划，包含端上特色工程、模型迭代思路，以及具体部署优化的过程，心愿能对从事相干畛域开发的同学有所帮忙或者启发。1 引言随着大数据、人工智能等信息技术的疾速倒退，云计算曾经无奈满足特定场景对数据隐衷、高实时性的要求。借鉴边缘计算的思维，在终端部署 AI 能力逐步步入公众的视线，“端智能”的概念应运而生。相比于传统的云计算，在智能手机等终端部署运行 AI 模块有以下几个方面的劣势：首先，数据本地化能够缓解云存储的压力，也有利于用户数据的隐衷爱护；其次，计算的本地化能够缓解云计算过载问题；最初，端智能缩小了和云端零碎的申请通信老本，能够更好地利用用户在端上的交互，提供更加实时、个性化的服务体验。 在端智能的利用方面，国内外各大科技公司曾经走在了前列。Google 提出了 Recommendation Android App 的概念，依据用户趣味进行内容举荐；Apple 的 Face ID 辨认、Siri 智能助手等一些咱们熟知的产品，也都是端智能典型的利用代表。阿里巴巴、快手、字节跳动等企业也在各自的利用场景上进行了端智能的落地，并推出相应的端上模型推理框架。比方，快手上线的短视频特效拍摄、智能识物等性能。另外，在搜寻举荐场景下也有一些实际，其中，手机淘宝“猜你喜爱”在端上部署了智能举荐零碎，获得较为显著收益（EdgeRec[1]，双十一 IPV 晋升 10%+，GMV 晋升 5%+）。快手上下滑举荐场景也利用了端上重排的计划，并获得App时长晋升了 1%+ 的成果。 搜寻是公众点评 App 连贯用户与商家的重要渠道，越来越多的用户在不同场景下都会通过搜寻来获取本人想要的服务。了解用户的搜寻用意，将用户最想要后果排在靠前的地位，是搜索引擎最外围的步骤。为了进一步优化搜寻个性化的排序能力，晋升用户体验，搜寻技术核心进行了在端上部署深度个性化模型的摸索实际。本文次要介绍了端智能重排在公众点评 App 上的实践经验，文章次要分为以下三个局部：第一局部次要剖析端智能重排要解决的问题和整体流程；第二局部会介绍端上重排序算法局部的摸索实际过程；第三局部将介绍端上重排零碎的架构设计以及部署优化，最初是总结与瞻望。 2 排序零碎进阶：为什么须要端上重排2.1 云端排序痛点咱们以一次残缺的搜寻行为，来看一下整个前后端执行的过程。如图 1 所示，用户在手机端搜寻入口发动检索申请后，触发云端服务器执行，包含查问了解、多路召回、模型排序与展现信息合并等解决，最终返回给客户端进行渲染出现给用户。 因为整个零碎的每秒查问数（QPS）的限度，以及前后端申请通信、传输包体影响，通常会采纳分页申请机制。这种客户端分页申请，云端服务检索排序返回给用户最终展现列表的 Client-Server 架构，对于公众点评 LBS 场景、类举荐的搜寻产品来说，存在以下两个问题： ① 列表后果排序更新提早 分页申请限度会导致排序后果的更新不及时。在下一个分页申请之前，用户的任何行为都无奈对当前页内的搜寻排序后果产生任何影响。以公众点评搜寻后果页为例，一次申请返回 25 个后果到客户端，每屏展现约 3~4 个，那么用户须要滑动 6~8 屏左右，能力触发新的分页申请到云端获取下一页后果（以美食频道列表页为例，有 20% 以上的搜寻浏览超过一页后果）。云端的排序零碎无奈及时感知用户的趣味变动，并调整已下发到客户端的后果程序。 ② 实时反馈信号感知提早 一般来说，实时反馈信号会通过 Storm、Flink 等流解决平台，将日志流以 Mini-batch 的形式计算后，存入 KV 特色数据库供搜寻零碎模型应用。这种形式往往会有分钟级的特色提早，因为须要对反馈数据进行解析解决，当波及到更多、更简单的反馈数据时，这种提早体现会更加显著。而实时反馈反映着用户的实时偏好，对于搜寻排序的优化有着非常重要的意义。 2.2 端智能重排流程和劣势为了解决分页后果排序调整决策提早，更及时地建模用户实时的趣味偏好变动，咱们在端上建设了重排序的零碎架构，使得客户端具备深度模型推理能力，该计划具备以下几个方面的劣势： 反对页内重排，对用户反馈作出实时决策：不再受限于云端的分页申请更新机制，具备进行本地重排、智能刷新等实时决策的性能。无延时感知用户实时偏好：无需通过云端的计算平台解决，不存在反馈信号感知提早问题。更好的爱护用户隐衷：大数据时代数据隐衷问题越来越受到用户的关注，公众点评 App 也在积极响应监管部门在个人信息爱护方面的执行条例，降级个人隐私爱护性能，在端上排序能够做到相干数据寄存在客户端，更好地爱护用户的隐衷。端智能重排在公众点评搜寻和美食频道页上线后，均获得显著效果，其中搜寻流量点击率晋升了 25BP（基点），美食频道页点击率晋升了 43BP，Query均匀点击数晋升 0.29%。 ...

作者：王文华(连墨) 千牛是阿里巴巴商家的多端开放式工作平台，每天服务数百万的沉闷商家在挪动和桌面端操作业务，蕴含店铺治理、客服接待、资讯音讯等多项性能。 同时，千牛自身是一个凋谢的端体系架构，二三方能通过凋谢体系（咱们称为插件体系）为商家提供服务。之所以叫做插件，是因为咱们在商家的经营链路中，定义了若干个凋谢节点和规范，由业务方依据规范实现，并实现相应的性能。正是因为这些规范和标准的存在，使得不同的插件之间能够串联起经营链路，从而躲避因商家抉择不同插件所导致的性能闭环被突破问题。 上面是千牛定义的凋谢节点： 凋谢促成了业务与三方ISV的入驻，使得千牛能更加充沛地利用内部资源服务，比方放慢开发进度，满足商家的定制化需要等。一款三方插件须要经验4个阶段：ISV开发，服务市场上架，商家购买，在千牛上应用。在商家未抉择默认经营插件的状况下，千牛也有一套规定疏导用户优先试用插件的收费版本，ISV 则可在商家试用过程中疏导降级订购来盈利。然而凋谢也会带来相应的问题 —— 商家体验问题。 为了晋升商家体验，咱们发动了凋谢体验降级我的项目。通过继续的治理，千牛月均凋谢舆情数量实现了缩小50%。那么，千牛有哪些舆情，防治整体计划又是如何设计的呢？ 问题和产生起因千牛凋谢舆情的特点因为凋谢的特点，千牛凋谢舆情比拟扩散，且成因简单。千牛上的工具数量泛滥，由二三方团队提供，局部二方工具历史悠久，保护投入有余，而ISV间的技术能力参差不齐。凋谢技术栈多，有晚期的H5，中期的QAP（weex封装的凋谢框架），以及小程序。插件启动链路长，从前端到ISV服务端波及7个以上技术链路，容易受网络和各个服务抖动影响。泛滥的不稳固因素给凋谢舆情治理带来了挑战。 凋谢体验的外围问题是什么？凋谢类体验问题多样，次要蕴含以下三类外围体验问题： 插件关上整体链路较长，在投放，商业化订购，容器运行加载各个环节都会影响插件启动；千牛端因为有奴才账号的权限管控的设计，主账号能够在各性能限度子账号权限，子账号在应用时会呈现权限有余的阻断性问题；ISV或二方业务本身逻辑问题多，千牛作为平台目前短少足够线上问题感知能力和无效的推动治理的抓手。防治整体计划优化插件启动链路: 晋升启动链路技术产品的容错能力，优化关上成功率到99.7%以上。建设权限申请闭环: 晋升权限申请和审批效率，优化子账号应用插件的体验。建设数据掂量体系: 积淀驱动业务优化的抓手。千牛上业务多，舆情起因简单且变动快，只以舆情问题切入单个解决是不够的。凋谢业务的的治理是循序渐进的，须要一方面解决已知问题，另一方面对插件启动和运行阶段的外围节点建设衡量标准和稳定性监控，坚固治理成绩。以治理-监控-预防-优化的思路驱动舆情降落。 启动链路优化启动流程介绍[]() 协定路由: 千牛官网定义了一组凋谢节点(坑位)和对应的标准协议(e.g.tradeDetail 查看订单详情)，由ISV依据协定实现承接的性能。这个阶段须要解析配置的协定，路由到用户设置或经营配置的默认插件appkey；插件元信息查找: 从服务端下发的插件列表中，找到指标appkey对应的插件元信息；权限校验: 校验子账号是否有权限关上此插件；商业化保障: 为新用户或订购关系过期的用户，实现收费版本的订购；前置受权QAP：对于三方插件，须要用户显式受权来容许三方ISV拜访数据；容器路由和渲染: 依据插件元信息, 组装业务参数并交给对应的容器渲染。全链路监控首先须要定位插件启动失败的起因和散布，并以此确定后续治理和优化计划。尽管实践上能够对每舆个情剖析日志，但实际操作中，因为工作量大，而且短少全局统计视角。因而，首先建设插件启动全链路监控，保留谬误上下文信息，统计精确的启动成功率和失败起因散布，为优化提供掂量根底。 埋点维度包含指标插件appkey, 技术类型（H5, QAP, 小程序)，出错阶段，谬误形容，关上插件起源或入口信息，每个阶段启动和完结的工夫。 这些维度有几个作用： 配置不同维度的告警，比方H5的插件成功率忽然降落或者某个阶段出错的次数明显增加；在整体成功率变动时，不便比拟不同维度的趋势，疾速定位是哪个级别的问题；出错阶段信息不便按阶段来看出错散布，分阶段优化成功率；关上起源和入口信息提供了更多问题呈现的场景信息。插件启动优化专项通过全链路监控能够看到有两类谬误，一类是插件关上的前置链路失败，另一类是订购关系未建设； 前置链路容错能力晋升 启动前置链路谬误的次要起因是弱网或服务端抖动造成的启动链路要害信息缺失，比方插件元信息和小程序包，通过异样弥补优化。千牛通过梳理了外围经营链路的头部插件，内置元信息，利用订阅关系和场景化信息预下载小程序包, 优化后小程序包命中率从85%升高到97%，整体失败次数降落55% 。 商业化保障计划降级 在千牛端，商家必须和插件建设订购关系后能力应用插件，是周期订购的商业化模式。在应用前千牛为商家续订免费版保障次要性能可用。通过Review旧计划，发现原来的产品链路不能笼罩订购失败等场景。降级商业化保障计划后相干谬误次数降落56.7%，前置链路耗时降落170ms。策略如下： 异样弥补：协调服务端减少订购状态信息，如果在建设订购中，则延时重试查问，期待关系建设后再关上 (订购流程波及汇金等内部零碎，失效工夫稳定大)；如果订购无奈胜利 (e.g.ISV被处罚，订购解冻)，疏导更换同类插件 (并用品质分加权影响排序，驱动ISV优化)性能优化：给前置订购链路减少频控策略，升高前置调用频率。减少后置续订缩短有效期，防止进入前置流程，同时也能笼罩那些没有通过插件流程关上小程序的场景。对于最罕用的默认插件，减少闲时静默续订。 启动优化专项后果：成功率从99%升到99.7% ，前置链路从350ms到130ms； 权限申请链路建设卖家端以奴才账号来做团队协同，子账号会遇到权限有余的凋谢体验问题。往年千牛建设了挪动端的权限申请链路，来优化商家的子账号应用体验和权限审批效率。 申请链路： 拓展客户端API给二方，由二方被动调用触发申请疏导，满足通用需要；因为二方校验形式灵便，短少对立收口。切面检测三方链路上的权限有余，主动触发申请提醒。因为历史起因，三方小程序分两类 (权限粒度维度)，有不同的检测形式。a. 从QAP降级的小程序: 打精细化受权标，受权粒度是权限包(匹配TOP响应的错误码) b. 间接以小程序身份入驻：没有精细化受权标，受权粒度是小程序利用级别 (匹配 getAuthUserInfo API错误码）。通过监听小程序API调用，触发申请流程；前者还需用TOP API名去服务端换权限包和权限点信息后，再创建工单告诉到主账号审批。审批链路： 主账号收到待审批音讯，点开中转对应权限审批详情页。 优化后，子账号权限有余的谬误次数降落57% ，相干舆情降落52% 。 数据掂量体系建设凋谢工具的性能和品质次要取决于业务逻辑和服务可用性和稳定性，因而要定义外围指标，监控线上异样，及时处理。数据掂量体系建设次要包含体感指标建设、舆情SOP优化、以及凋谢体验大盘搭建。 体感指标建设通过小程序的事件机制建设了TOP和云利用的业务成功率，自建了体感白屏率（H5，weex和小程序），拓展小程序白屏率检测计划，屡次监控到业务方线上问题，推动回滚和修复。 插件外围运行质量指标 下图千牛插件运行期间的外围节点，能够通过建设对应指标全面监控线上插件运行的稳定性。除了常见的纯技术指标：接口业务成功率，bridge API成功率，JS error率等，千牛还建设了体感白屏率来反馈插件线上运行品质。 体感白屏率 尽管有了外围节点的技术指标，但这些技术指标并不能齐全笼罩性能不可用的场景：某日云利用扩容，新机器配置问题导致订单数据为空，但接口是胜利的；某些技术指标谬误，并不代表肯定会性能不可用，比方局部JS谬误。所以须要建设指标，从体感上间接度量可用行。其中，千牛插件性能不可用最常见的问题是白屏。 ...

销售、服务或营销业余人员的职责仅限于实体办公室的日子早已一去不复返了。当初，企业既有需要也有灵活性，能够让员工在多个地点动静工作——包含在路上和现场与客户一起工作。以上的趋势再加上 CRM 简直从大多数企业的“必备”转变为“必备”的事实， 凸显了对容许公司员工拜访其 CRM 的资源的需要随时随地的数据和通用性能。这就是挪动 CRM 解决方案发挥作用的中央。它们容许销售、服务和营销业余人员随时随地利用他们公司的 CRM。 什么是挪动CRM软件？挪动客户关系治理 (CRM) 软件是一种 CRM 技术，可帮忙企业治理客户数据、分割信息，并使用户可能在远离计算机的状况下拜访无关客户的重要信息。挪动 CRM 软件专门设计为挪动应用程序或响应式 Web 应用程序，具备 CRM 软件的所有性能，但针对挪动体验进行了优化。随着挪动设施使用量的持续增长，许多 CRM 用户当初在这些设施上拜访他们的零碎也就难能可贵了。例如，依据咱们的钻研，近 48% 的受访者通过智能手机拜访他们的 CRM 软件，而 45% 的受访者应用平板电脑。 挪动CRM软件的益处迄今为止，挪动 CRM 软件的采纳迟缓的起因之一是因为它被视为桌面性能的简略附加组件，而其益处要宽泛得多。 获取信息员工外出时常常须要信息。无论是销售代表行将与大型企业的 C 级高管会面，还是采购员行将与要害供应商会面，在散会前疾速查看信息的需要很常见。一个好的挪动 CRM 将确保这能够疾速无效地实现。即便在人们须要提取信息的会议中，将笔记本电脑放在办公桌上也可能是蠢笨且不足人情味的，平板电脑是一个不错的抉择，因而即便在办公室内也有显著的益处。更高的效率CRM 治理的次要问题之一是数据进化，据报道，某些企业每年进化70%。数据衰减是一个继续存在的问题，最无效的补救措施之一是确保员工习惯性地应用新数据更新 CRM。挪动 CRM 有助于促成 CRM 更新。为员工提供随时随地更新的能力至关重要，如果员工须要等到他们回到桌面能力增加更新，那么某些信息将不可避免地失落。挪动 CRM 容许随时随地疾速更新，因而员工能够在会议之间或不在办公室进行更新，而无需启动笔记本电脑。更好的客户服务信息对于提供一流的客户服务至关重要。如果员工不在办公室时能够轻松解决查问，这将有助于改善要害利益相关者的体验。在最近的一个我的项目中，咱们与一家大型连锁商店的供应商单干。订单存在问题，须要立刻解决。我的项目关系经理不在办公室，须要调出一些详细信息来答复问题，在问题降级之前，她还有大概一个小时的工夫。领有易于应用的挪动 CRM 使咱们的客户可能拜访正确的信息并提供零售商所需的信息，这可能就解救了多个客户关系。独特的能力设计良好的挪动 CRM 将比桌面版本更易于应用，借助更具反馈性的导航和触摸屏性能，能够更轻松地查找和更新信息。 挪动 CRM 软件容许更好的聊天施行，因而能够改善员工之间的分割。此外，还能够实现天文定位性能。有各种供应商提供这些应用程序，它们都提供一些不同的货色，但应用挪动设施的天文定位来减少销售过程的价值——可能布局物流和可视化销售区域是几个次要劣势。 挪动 CRM 软件的性能因为业余人员在现场执行的流动通常与在办公室进行的流动不同，因而挪动 CRM 软件可能仅提供最有可能在近程环境中应用的性能。这有助于简化移动用户的挪动体验。以下是挪动 CRM 软件的相干性能： 联系人治理提供对客户、联系人和潜在客户的端到端治理，并提供全面的分割历史跟踪。流动记录提供对客户、联系人和潜在客户的端到端治理，并提供全面的分割历史跟踪。打算和工作治理提供协调和治理日历、创立待办事项列表和将任务分配给团队成员的办法。帐户定位器使用户可能应用挪动设施的反对 GPS 的地图查找左近的潜在客户、联系人和机会并优化路线。管道推送告诉当管道中机会的状态发生变化时，向销售代表发送告诉。销售内容治理为用户提供拜访和共享罕用销售内容的能力，例如产品信息、价目表、合同文件和销售演示。销售订单主动创立、解决和路由现场制作的销售订单。 抉择挪动CRM软件为你解决业务问题从以上的挪动CRM软件的益处和性能展现中，不晓得你是否曾经被挪动CRM软件所吸引。挪动CRM软件无论对员工还是客户都是有肯定的劣势价值的。对于销售来说，挪动CRM软件是必备软件，挪动CRM将所有性能整合到一个简略不便的应用程序中。这些应用程序甚至增加了一些性能，能够将您的手机转变为您能够随时随地应用的超级销售工具。

作者：极光高级工程师—李晓航 目录前言Interruption level（中断级别）APNS Request API定时告诉摘要对于时效性告诉的阐明1、xcode中关上对应能力2、app须要在官方网站反对该权限给开发者的倡议写在最初 前言上一次咱们分享了《初探iOS15推送新个性》，过后还处于一个iOS15的晚期阶段，很多性能还无奈应用和确认。而在2021年9月21日Xcode13正式版公布了，本篇文章会基于Xcode13正式版来对iOS15上的推送新个性做一个残缺的摸索。 Interruption level（中断级别）在公布正式版后，咱们对iOS15上的告诉有了一个比拟明确的意识。整体来看iOS15次要就是对告诉进行了分级，也就是参数interruptionLevel。The interruption level determines the degree of interruption associated with the notification。说白了就是通过给告诉设定不同的级别来达到不同的响应成果。中断级别和iOS15新出的焦点模式非亲非故，如果不理解焦点模式的同学能够参考咱们的上一篇文章。 中断级别目前分为四种： Passive（被动的）人们能够在空闲时查看信息，比方餐厅举荐。Added to the notification list; does not light up screen or play sound被动类型的告诉不会使手机亮屏并且不会播放声音。 Active（流动，默认设置）当信息达到时，人们可能心愿晓得它，比方他们最喜爱的运动队的分数更新。Presented immediately; Lights up screen and may play a sound流动类型的告诉会使手机亮屏且会播放声音，为默认类型，也是在iOS15呈现之前的告诉默认设置。在焦点模式下，流动类型告诉特点和被动类型的一样。 Time Sensitive（工夫敏感）间接影响用户并须要他们立刻关注的信息，如帐户平安问题或包传递。Presented immediately; Lights up screen and may play a sound; May be presented during Do Not Disturb。工夫敏感类型，性质和流动类型的告诉一样，会使手机亮屏且会播放声音；可能会在免打搅模式（焦点模式）下展现。实际上就是在焦点模式下关上工夫敏感类型的告诉后，工夫敏感类型的告诉就可能失常显示的。如果不关上也和被动类型的一样。如图所示，关上时效性告诉后，在开启此焦点模式的状况下，时效性告诉是不会变成被动告诉的。设置了容许告诉的App不受焦点模式影响。 Critical（要害）间接影响用户并要求其立刻关注的无关集体衰弱和公共安全的紧急信息。要害告诉十分常见，通常来自政府和公共机构或医疗保健应用程序。您必须有权应用。（须要非凡申请）Presented immediately; Lights up screen and plays sound; Always presented during Do Not Disturb; Bypasses mute switch; Includes default critical alert sound if no sound provided会立即展现，亮屏，播放声音，有效免打搅模式，并且可能绕过静音，如果没有设置声音则会应用一种默认的声音。关键性告诉须要非凡权限申请，从已知的信息上来看，这种类型的告诉，有一点像过来的警报告诉，会导致手机强制触动播放声音并显示，实用于地震等紧急情况。 ...

近日，蚂蚁数字科技与北京梆梆平安科技有限公司（以下简称"梆梆平安"）签订策略单干。单方将在挪动利用平安畛域进行技术钻研与翻新，独特构建挪动端全链路的平安能力，为用户提供高质量的数字化转型服务。 依据协定，蚂蚁数字科技与梆梆平安将基于各自在挪动开发与网络安全的劣势，独特打造挪动利用的一站式平安解决方案。同时，单方将在技术、产品、市场等畛域继续发展深度单干，推动相干产品利用和落地实际。 梆梆平安是一家国内当先的新一代平安技术及服务提供商，高度重视产品与技术创新工作，创始、凋敝了挪动利用平安蓝海市场，建设了全面的挪动利用平安防护生态体系，并在业务上造成以平安服务为主体，联动挪动平安和物联网平安的“一体两翼”业务体系。 梆梆平安首席运营官周欣示意，“咱们很快乐与蚂蚁数字科技确立策略单干关系，期待将来拓展更多单干新模式，独特打造更多数字化解决方案和平安服务。金融科技向挪动端的倒退是以后倒退的趋势，单方基于这一重点开展策略单干，一方面为蚂蚁数字科技产品生态提供挪动端相干的平安保障，另一方面心愿通过单方单干的发展继续推动公司产品与技术优化，独特推动数字金融生态链的倒退，远洋航行。”目前梆梆平安曾经在物联网平安、工业互联网安全、车联网平安、5G平安等畛域开展钻研与实际摸索，业务宽泛笼罩了车联网、智能交通、智慧能源、智慧医疗、智慧家庭、智慧城市、新基建等畛域。 据蚂蚁团体数字科技事业部副总经理刘昕介绍，此次单干依靠蚂蚁挪动开发平台mPaaS在APP开发、测试、剖析、公布、运维、经营等方面的平安能力和翻新研发劣势，联合梆梆平安的产品能力对外输入，协同推动网络安全技术在金融科技、挪动平安、物联网平安等畛域的落地利用。“mPaaS团队会继续致力深耕产品，保持以稳固、牢靠的技术力量普惠广大客户，继续丰盛服务场景、晋升服务价值。” 据悉，mPaaS是蚂蚁数字科技的外围产品之一，交融了支付宝诸多金融科技能力，为挪动利用开发、测试、经营及运维提供云到端一站式解决方案，已服务中国农业银行、广发银行、华夏银行、西安银行、国寿保险、12306、上海地铁等泛滥客户。 蚂蚁数字科技助力各行业数字化降级，将蚂蚁自主研发的技术能力及实践经验对外输入，打造了分布式架构、挪动开发平台、分布式金融外围套件、数字经营等数十款外围产品和行业解决方案，目前已广泛应用于金融机构、政务民生、交通和能源等泛滥行业，服务超过200家客户。

残缺高频题库仓库地址：https://github.com/hzfe/awesome-interview 残缺高频题库浏览地址：https://febook.hzfe.org/ 相干问题介绍 meta 的 viewport 值rem 和 vw 的值是依据什么计算的1px 显示问题如何适配刘海屏答复关键点viewport 绝对单位 媒体查问 响应式图片 挪动端开发的次要痛点是如何让页面适配各种不同的终端设备，使不同的终端设备都领有基本一致的视觉效果和交互体验。挪动端常见的适配计划有以下几种，个别都是相互搭配应用。包含： 视口元信息配置响应式布局绝对单位媒体查问响应式图片平安区域适配知识点深刻1. 相干概念1.1 像素 分辨率（Resolution） 分辨率是指位图图像中细节的精密水平，以每英寸像素（ppi）掂量。每英寸的像素越多，分辨率就越高。 物理像素（Physical pixels） 物理像素是一个设施的理论像素数。 逻辑像素（Logical pixels） 是一种抽象概念。在不同的设施下，一个逻辑像素代表的物理像素数不同。CSS 像素是逻辑像素。 为了在不同尺寸和密度比的设施上体现出统一的视觉效果，应用逻辑像素形容一个雷同尺寸的物理单位。在具备高密度比的屏幕下，一个逻辑像素对应多个物理像素。 设施像素比（Device Pixel Ratio） 以后显示设施的物理像素分辨率与 CSS 像素分辨率之比。 相干问题：图片或 1px 边框显示含糊 在挪动端中，常见图片或者 1px 的边框在一些机型下显示含糊/变粗的问题。基于对像素相干的概念了解，可知 CSS 中的 1px 是指一个单位的逻辑像素。一个单位的逻辑像素映射到不同像素密度比的设施下，理论对应的物理像素不同。 因而，同样尺寸的图片在高密度比的设施下，因为一个位图像素须要利用到多个物理像素上，所以会比低密度比设施中的视觉效果含糊。 1.2 视口 视口（viewport） 视口个别是指用户拜访页面时，以后的可视区域范畴。通过滚动条滑动，视口能够显示页面的其余局部。在 PC 端上，<html> 元素的宽度被设置为 100% 时，等同于视口大小，等同于浏览器的窗口大小。通过 document.documentElement.clientWidth 或 window.innerWidth 能够获取视口宽度。CSS 布局基于视口大小进行计算。 因为挪动设施尺寸较小，如果基于浏览器窗口大小的视口进行布局，会导致一些没有适配过挪动设施款式的站点布局错乱，用户体验差。为了让挪动端也能失常显示未适配挪动设施的页面，从而引入布局视口和视觉视口的概念。 布局视口（layout viewport） 布局视口的宽度默认为 980px，通常比物理屏幕宽。CSS 布局会基于布局视口进行计算。挪动设施的浏览器基于虚构的布局视口去渲染网页，并将对应的渲染后果放大以便适应设施理论宽度，从而能够残缺的展现站点内容且不毁坏布局构造。 视觉视口（visual viewport） 视觉视口是布局视口的以后可见局部。用户能够通过缩放来查看页面内容，从而扭转视觉视口，但不影响布局视口。 2. 应用 viewport 元标签配置视口开发者能够通过 <meta name="viewport"> 对挪动端的布局视口进行设置。如果不进行 viewport 元标签的设置，可能会导致开发者设定的较小宽度的媒体查问永远不会被应用，因为默认的布局视口宽度为 980px。 ...

近日，蚂蚁团体金融级分布式架构SOFAStack、挪动开发平台mPaaS先后与麒麟软件高级服务器操作系统V10实现兼容性适配测试 。测试结果表明，两款产品具备高稳定性、高兼容性及可靠性，能在国产设施和零碎平台上稳固运行，满足用户的关键性利用需要。 至此，蚂蚁团体曾经与数十家国内支流操作系统、CPU等软硬件厂商实现了产品兼容互认证。 麒麟软件有限公司，简称麒麟软件，是中国电子信息产业团体有限公司旗下子公司。在党政、国防办公等畛域占有国产操作系统90%以上的市场份额，并在金融、能源、交通、医疗等行业取得广泛应用和认可，是操作系统国家队里的旗舰店。 作为国内当先的操作系统企业，麒麟软件始保持凋谢单干打造产业生态。其中，河汉麒麟高级服务器操作系统V10是针对企业级要害业务，是新一代自主服务器操作系统。 蚂蚁团体此次通过河汉麒麟高级服务器操作系统V10认证的有两套自主研发的软件产品。 SOFAStack是一套由蚂蚁自主研发、用于构建金融级云原生分布式应用的技术栈，能保障金融交易的技术平安，同时帮忙业务麻利迭代，实现异地容灾、低成本疾速扩容等，反对金融业务翻新。 mPaaS是交融了支付宝诸多金融科技能力的挪动开发平台，为挪动利用开发、测试、经营及运维提供云到端一站式解决方案，已服务中国农业银行、广发银行，华夏银行，西安银行、国寿保险、12306、上海地铁等泛滥客户。 “此次与麒麟实现兼容互认证，对蚂蚁数字科技而言，具备十分重要的意义，是咱们在国产生态建设中迈出的重要一步。”蚂蚁团体数字科技事业部总经理余滨示意：“将来，咱们将持续保持自主研发之路，与更多国内的优良厂商进行单干，为各行各业的客户提供平安可信的数字化、智能化解决方案，保障数字化时代企业数据的信息安全。”

本文出自于“「2021 友盟+ 挪动利用性能挑战赛」” 中的参赛作品，该文章表述了作者如何借助友盟+ U-APM工具解决了启动问题。 挪动端性能对用户体验、留存有着至关重要的影响，作为开发者是不是被这样吐槽过，“这个 APP 怎么这么大？”、“怎么始终在 APP 封面图转悠，点不进去”、“进入详情成果有些卡”、“用 4G 应用你们的 APP，我的流量有点不够啊”等等，这些问题都直观反映出，一个体验良好的利用，只有性能健全还不够，以下是我在性能优化上总结的几点： 启动速度优化晦涩度优化资源优化内存优化APK 体积优化明天先聊聊，启动速度的那些事 利用启动流程冷启动从点击利用图标到UI界面齐全显示且用户可操作的全副过程。 特点：耗时最多，衡量标准 启动流程：Click Event -> IPC -> Process.start -> ActivityThread -> bindApplication -> LifeCycle -> ViewRootImpl 热启动因为会从已有的利用过程启动，所以不会再创立和初始化Application，只会从新创立并初始化Activity。 特点：耗时较少 启动流程：LifeCycle -> ViewRootImpl 因而判断利用启动速度的的规范是冷启动的速度，即杀掉利用后重新启动的速度，此项次要是和你的竞品比照。 不应在 Application 以及 Activity 的生命周期回调中做任何费时操作，具体指标大略是你在 onCreate，onResume，onStart 等回调中所破费的总工夫最好不要超过 400ms，否则用户在桌面点击你的利用图标后，将感觉到显著的卡顿。 冷启动剖析及优化方向冷启动波及的相干工作冷启动之前 首先，会启动 App而后，加载空白 Window最初，创立过程须要留神的是，这些都是零碎的行为，个别状况下咱们是无奈间接干涉的。 随后工作 首先，创立 Application启动主线程创立 MainActivity加载布局安排屏幕首帧绘制通常到了界面首帧绘制实现后，咱们就能够认为启动曾经完结了。 上面是官网文档中的启动过程流程图，显示零碎过程和利用过程之间如何交接工作。实际上对启动流程的简要概括。 优化方向咱们的优化方向就是 Application 和 Activity 的生命周期这个阶段，启动中的零碎工作咱们无奈干涉，能干涉的就是在创立利用和创立 Activity 的过程中可能会呈现的性能问题。这一过程具体就是： Application 的 attachBaseContextApplication 的 onCreateactivity 的 onCreateactivity 的 onStartactivity 的 onResumeactivity 的 onResume 办法实现后才开始首帧的绘制。所以这些办法中的耗时操作咱们是要竭力防止的。并且，通常状况下，一个利用的主页的数据是须要进行网络申请的，那么用户启动利用是心愿疾速进入主页以及看到主页数据，这也是咱们计算启动完结工夫的一个根据。 ...

挪动端开发中可能会波及到树状数据的抉择，因为mui中没有比拟好的组件能够应用，所以我基于mui和jq开发了一款能够在挪动端操作级联的气泡组件。源码地址：https://github.com/booms21/mC... mCascadermCascader 是一款mui格调的挪动端h5气泡级联框，反对可抉择任意层级、默认值、分隔符 应用办法：首先引入mui和jq库，mCascader.css（cascader的款式） <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.6.0/jquery.min.js"></script> <script src="https://cdn.bootcdn.net/ajax/libs/mui/3.7.1/js/mui.min.js"></script> <link href="https://cdn.bootcdn.net/ajax/libs/mui/3.7.1/css/mui.min.css" rel="stylesheet" /> <link href="css/mCascader.css" rel="stylesheet" /> <script src="js/mCascader.js"></script>间接调用mCascader办法，并传入配置项： mCascader({ input:'#demo', //对应input的id data:data, //mCascader 的数据 value:[''],//mCascader的默认值,默认值节点的id字符串 separator:'/', //input中的分隔符 onClick:function(node){ //当抉择实现时的回调函数，node为以后点击的点击的节点 console.log(node) } });input：对应文本框的选择器，字符串类型 data：mCascader的数据。Array类型，树结构，data中的节点必须要有以下属性： data = [{ id:'', // 必须,惟一的id值，String类型 name:'', //必须,对应mCascader节点的显示文本 ，String类型 children:[...] //子节点 ，Array类型 },...]获取mCascader以后的id值(2种)：1.mCascader.currtId 2.$('#demo').data('id')或$(mCascader.options.input).data('id') 返回上一层级：mCascader.back() 清空mCascader数据及重置界面：mCascader.clear() 例子：mcascader的DOM不写死到js中，保留了本来组件的构造，不便你自定义组件的款式 <div id="mcascaderPopover" class="mui-popover"> <div class="label"> <button type="button" id="goback" class="mui-btn mui-btn-outlined" onclick="mCascader.goBack()" > <span class="mui-icon mui-icon-back"></span></button >请抉择一个节点 </div> <div id="mcascader"> <p id="noData" style="display: none">无数据</p> <ul class="mui-table-view"></ul> </div> </div> <div class="mui-input-row"> <div class="label"><a href="#mcascaderPopover"></a>节点：</div> <input type="text" id="demo" placeholder="请抉择" readonly /> </div> <script src="js/mCascader.js"></script> <script> var json = [ { name: "节点1", id: "1", children: [ { name: "节点11", id: "1-1", children: [] }, { name: "节点12", id: "1-2", children: [ { name: "节点122221", id: "1-2-1", children: [] }, { name: "节点12222222", id: "1-2-2", children: [] }, ], }, { name: "节点123", id: "1-3", children: [] }, { name: "节点244", id: "1-4", children: [] }, ], }, { name: "节点2", id: "2", children: [ { name: "节点24411111", id: "2-4", children: [] }, { name: "节点55555", id: "2-7", children: [] }, ], }, ]; //存储过滤的值 mCascader({ input: "#demo", //对应input的id data: json, //mCascader 的数据 value: ["1-2-2"],//mCascader的默认值 separator: "/", //input中的分隔符 onClick: function (node) { //当抉择实现时的回调函数 console.log(node); }, }); </script>欢送你参加奉献！ ...

挪动端开发中因为mui中没有比拟好用的tab组件，所以我就基于mui开发了一个tab列表组件，能够获取以后的tab并且减少了排序功能，解决了列表的常见需要源码地址：https://github.com/booms21/mF... mFilterToolbarmFilterToolbar 是一款mui格调的挪动端h5顶部过滤栏组件，可依据自定义的条件对列表进行过滤，反对排序、组件默认值、组件取值、角标。 应用办法：首先引入mui和jq库，mFilterToolbar.css（mFilterToolbar的款式） <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.6.0/jquery.min.js"></script> <script src="https://cdn.bootcdn.net/ajax/libs/mui/3.7.1/js/mui.min.js"></script> <link href="https://cdn.bootcdn.net/ajax/libs/mui/3.7.1/css/mui.min.css" rel="stylesheet" /> <link href="css/mFilterToolbar.css" rel="stylesheet" /> <script src="js/mFilterToolbar.js"></script>创立一个mFilterToolbar实例，并传入配置项： // 实例化一个ft对象 var ft = new mFilterToolbar({ defaultValue: { tabValue: "1",//左tab的默认值 cacheSortObj: { //右tab的排序默认值 sortName: "sortType2",//要排序的字段 sortType: "desc",//升序asc 降序desc }, }, //默认值对象 onTabClick: function (obj) { //tab点击实现后的回调函数 console.log(obj); //在这里能够调用加载列表代码... }, });留神：1.defaultValue中的属性都是必须的 2.创立实例前须要先在tc-btn中设置data-value（惟一的tab值）ft实例中有如下办法：getValue：获取以后mFilterToolbar的值 initFilter：初始化mFilterToolbar的值，并重置mFilterToolbar到初始状态 例子：组件的DOM不写死到js中，保留了本来组件的构造，不便你自定义组件的款式 <div class="filterbox"> <div class="filter-tab"> <div class="tab-l active" data-to="tab-l"> <span> <span class="mui-icon iconfont icon-guolvqi"></span>筛选</span> </div> <div class="tab-r" data-to="tab-r"> <span> <span class="mui-icon iconfont icon-paixu"></span>排序</span> </div> </div> <div class="tab-content"> <div class="l-cont" id="tab-l"> <!-- 因为mFilterToolbar依赖data-value，须要在对应的tc-btn上data-value设置tab对应的值（惟一）--> <div class="tc-btn active" data-value="0"> 全副<span class="mui-badge mui-badge-danger allCount">0</span> </div> <div class="tc-btn" data-value="1"> tab1<span class="mui-badge mui-badge-danger countNum1">0</span> </div> <div class="tc-btn" data-value="2"> tab2<span class="mui-badge mui-badge-danger countNum2">0</span> </div> <div class="tc-btn" data-value="3"> tab3<span class="mui-badge mui-badge-danger countNum3">0</span> </div> </div> <div class="r-cont" id="tab-r" style="display: none"> <div class="tc-btn active" data-value="sortType1"> <!--排序对应的key 升序为asc 降序为desc 。 默认为asc 。点击后会toggle这两个值--> 按热度<span class="mui-icon iconfont icon-paixu1"></span> </div> <div class="tc-btn" data-value="sortType2"> 按工夫<span class="mui-icon iconfont icon-paixu1"></span> </div> <div class="tc-btn" data-value="sortType3"> 按评分<span class="mui-icon iconfont icon-paixu1"></span> </div> </div> </div> </div> <list>列表...</list> <script src="js/mFilterToolbar.js"></script> <script> // 实例化一个ft对象 var ft = new mFilterToolbar({ defaultValue: { tabValue: "1", cacheSortObj: { sortName: "sortType2", sortType: "desc", }, }, //默认值对象 onTabClick: function (obj) { //tab点击实现后的回调函数 console.log(obj); //在这里能够调用加载列表代码... }, }); </script>欢送你参加奉献！ ...