知鸦日报2022-06-13

2022-06-12 16:30:00 ~ 2022-06-13 16:30:00

产品

手把手教你绘制用户旅程图

摘要

用户旅程图是用户与产品/服务互动过程的可视化地图。它以典型用户视角,描述了用户为了达成目标而与产品交互的全过程,可以帮助团队提升协同效率,完善产品设计逻辑,把控用户情感,洞察用户需求。

技术

得物技术:基于DataWorks的时效仿真平台

摘要

现货业务目前基于算法模型+运营配置得出订单预计履约时长,由于时效策略调整需求且现货订单数据回收周期较长,因此需要建设时效仿真平台能力,产品自行根据业务需要进行时效仿真实验并得到对应结果。

网易技术:严选APP端上安全体系建设

摘要

APP的每个业务场景都有其既定的运行模式,若被人为破坏就可认为是不安全的。比如秒杀场景、用户拉新场景。APP端上安全要做的就是甄别并防范这种异常场景的发生,简而言之它就是:一种确保官方APP在既定业务模型中运行的能力。

哔哩哔哩技术:WebAssembly 软解 HEVC 在 B 站的实践

摘要

B 站是一家把用户体验放在第一位的公司,在 AVC 编码下我们已经做到了不错的视频播放卡顿率控制,为了进一步的降低卡顿率我们开始了对 HEVC 编码的探索。HEVC 是比 AVC 更加高效的视频压缩标准,可以在同等画质下减少 50% 的文件体积,意味着只要原先一半的带宽下就能流畅播放 HEVC 视频,在更差的网络环境下依旧能得到不错的用户体验。

目前业内 HEVC 编码主要用于各类移动端设备上,Web 端常见浏览器仅在 Safari 、旧版 Edge 和部分魔改的 Chromium 内核浏览器上才支持播放。得益于 Chrome 在 v57 版本支持了 WebAssembly 并在 v68 版本重新开放了 SharedArrayBuffer(WebAssembly 多线程基础) 接口使得在 Web 上实现高性能应用成为了可能,于是我们自研了基于 WebAssembly 实现软解 HEVC 的播放器。我们在 Web 上进行 HEVC 优化就分为了两部分:在支持 HEVC 的浏览器上使用浏览器解码播放 HEVC 和在不支持 HEVC 的 Chromium 内核浏览器上使用基于 WebAssembly 开发的 WasmPlayer 解码播放 HEVC。

WasmPlayer 提供的是软件解码(软解)能力,通俗层面上软件解码是指使用 CPU 进行解码,相对应的硬件解码(硬解)则是使用 GPU 进行解码。软解的兼容性较高,在不支持硬解的设备上也能使用,劣势是相对而言占用更多的 CPU;硬解的兼容性则相对较低,需要硬件厂商提前适配,优势是功耗、CPU 占用低。硬解和软件相辅相成缺一不可,不是所有的设备都支持各类编码的硬解,新编码借助软解方案则可以实现更快的普及,让更多的用户提前使用上优秀的新编码。

哔哩哔哩技术:哔哩哔哩应援弹幕

摘要

B站最新推出的一款应援弹幕交互产品,将用户发送的弹幕与当下视频场景强相关的文字或图片组合,由此打造视频定制化的弹幕体验,以独特性和新鲜感刺激用户发弹幕,贴合视频内容表达情感,增强互动趣味性。

哔哩哔哩技术:哔哩哔哩Android编译优化

摘要

哔哩哔哩的安卓项目的工程结构是Monorepo(单仓)变种,也就是所有的代码都在一个工程结构下编译。我们认为Monorepo(单仓)是一个非常适合我们的开发模式,主要是因为其提供的原子提交,可见性,参与度,切片的稳定性等等优点,这些都是我们选择Monorepo的原因。但是因为权限管控,ijkplayer等双端通用工程的原因,还是拆开了多个git仓库。通过git权限的方式来拆分了工程结构,然后通过Gradle Plugin的形式进行了多工程的组合,在CI打包环境上让工程具备Monorepo的能力。

随着代码长时间迭代,业务模块数量增多,当前工程有500+的模块以及19个复合构建。如果所有的模块都用源代码编译,打一个包本地可能需要大概30分钟的时间才能完成编译。而且哔哩哔哩的安卓工程是一个上百人同时开发的项目,如果一小个改动都需要30分钟的时间投入编译中,对于开发同学来说可能心态都要崩了。

让编译速度变得更快也就迫在眉睫,而且这个模式是针对开发同学,让他们可以快速对模块变更的代码负责。同时也希望这个模式是在不影响当前的工程结构,让他们的打包速度能变得更快。

货拉拉技术:货拉拉Android 包体积优化实践

摘要

货拉拉32位包体积从82.69M减少到了33.86M,减少了60%。

用 Paged.js 做出適合印成 PDF 的 HTML 網頁

摘要

之前在公司內接到了一個需求,需要產生出一份 PDF 格式的報告。想要產一份 PDF 有很多種做法,例如說可以先用 Word 做,做完之後再轉成 PDF。但我聽到這需求時,最先出現的想法就是寫成網頁,然後再利用列印功能轉成 PDF。

我在前公司的時候看過一個用 JS 來產生 PDF 的專案,是用 PDFKit 來做,自由度極高,但我覺得滿難維護的。原因是用這一套的話,就有點像是把 PDF 畫出來,你要指定 (x,y) 座標去畫東西,可能改一個小地方,就要改很多行程式碼。

那時候我想說怎麼不直接用最簡單的 HTML + CSS 就好,切好版之後再轉成 PDF,如果不想手動轉,也可以透過 headless chrome 去轉,因為是網頁的關係所以應該滿好維護的。而且排版的話因為是用 HTML 跟 CSS,應該會比用畫的簡單許多才對。

直到我後來接觸到網頁轉 PDF,才發現事情不像我想的這麼簡單。


‹ 2022-06-12 日报 2022-06-14 日报 ›

qrcode

关注公众号
接收推送