【安卓】Poplayer 云音乐优化实践

【安卓】Poplayer 云音乐优化实践

背景介绍

你是否还在为各种特殊场景特殊逻辑而烦恼，是否还在为各种一次性业务而添加一堆代码，是否还在为各种奇奇怪怪的彩蛋而满心疲惫? 在云音乐不断迭代的过程中，我们不止一次的遇到产品说要在某一个地方加个彩蛋，有的是在触及特殊操作时，有的是在播放特定歌曲时，甚至有的是在特定时间点播放特定歌曲到特定播放进度时。

每次听到这些需求，头都大了，又得在老代码上面加一堆特殊逻辑，又得写那么多代码，重点写那么多代码还不能复用，同时也增加了稳定业务的复杂度，也没有什么实时性、动态性可言。

在经历了几次这种需求之后，我们就在想如何去避免这类临时业务和稳定业务融合到一起，如何去把这类临时业务统一成一套通用可行方案？

在这之前，我们先了解下什么是临时业务，什么是稳定业务。

临时业务：特定时间，特定场景，特定配置下需要上线的业务；不可复用，可能只一次使用。对云音乐来说就是彩蛋系列，这里举一个特定的场景，国庆节国歌升旗彩蛋，需要在国庆节期间的天安门升旗时间播放国歌，唤起升旗的视频。对于这类型的场景，基本满足了我们对于临时业务的定义，可以将其认为是临时业务

稳定业务：核心功能，基础功能，长期存在，非必要情况下不随意修改。对云音乐来说就是最重要的就是播放业务，包含播放列表，播放页面等播放核心功能，这块逻辑我们其实是不希望去随意改动的，要是随意增加个彩蛋就疯狂改动这块的逻辑，疯狂添加些临时且不可复用的代码，那将会增加这块的逻辑复杂度，维护复杂度，还未引起一些意外的问题。播放业务也是基本满足了我们对稳定业务的定义，可以将其认为是稳定业务。

了解了临时业务和稳定业务之后，就可以想办法去做区分解决了。对于临时业务，需要的通用方案得满足可配置，可复用，实时性，动态性等要求，在大家的讨论下，便想到了 Poplayer 这个大杀器。

什么是 Poplayer

简介

Poplayer ，顾名思义，就是Pop + Layer的组合，结合 Android 场景来看，其实就是页面上层再加一层，称作 Poplayer。通过 Poplayer 层我们可以将一些临时业务交由这一层去处理维护，而这一层又交由 WebView 去承载，在增加动态性的同时又不影响既有稳定业务。

Poplayer 的设计

设计概要

【安卓】Poplayer 云音乐优化实践

从上面的图可以非常清晰的看出来，所谓的 Poplayer 就是在客户端页面上增加一层，将这一层作为展示临时业务的容器，二者通过 JSBridge 通信，再结合一些客户端页面配置以及容器配置，达到临时业务热插拔，可复用的要求。

整体流程与设计

【安卓】Poplayer 云音乐优化实践

从上图可以看出，我们通过配置能力将客户端页面和容器结合到一起，整体流程结构都是非常清晰的。依赖于云音乐完善的基础设施，在完成 Poplayer 组件的时候减少了很多工作。

Poplayer云音乐优化实践

内存优化

使用 Poplayer 的时候，其中一个技术点就是： 根据触摸坐标获取该处弹框的 ARGB 值, 判断 A 分量的值是否超过阈值，超过则交给 HTML5 处理

那么我们如何去获取点击位置的 alpha 值呢，一般我们想到的是使用类似截图的方式去获取 View 的整个视图。

如下：

// view 是 webView
private fun captureView(view: View): Bitmap {
val bitmap = Bitmap.createBitmap(view.width, view.height, Bitmap.Config.ARGB_8888)
val canvas = Canvas(bitmap)
view.draw(canvas)
return bitmap
}
fun getViewTouchAlpha(ev: MotionEvent, view: View): Float {
if (view.alpha <= 0f) {
return 0f
}
val drawingCache = captureView(view)
return drawingCache.getPixel(ev.x.toInt(), ev.y.toInt()).alpha.toFloat()
}

如此去获取 bitmap，宽高是 Webview 的宽高，在这里相当于屏幕高度。首先，bitmap 占用内存会很大，4 1080 2248byte ，同时去绘制整个 Webview，也会非常耗时，平均时间 90ms 左右。

事件冲突

某些 Activity 在 dispatchTouchEvent 的时候会拦截事件，进行一些操作，举个云音乐播放页面的例子：

 @Override
public boolean dispatchTouchEvent(MotionEvent event) {
// ...
// Poplayer处理
if (Poplayer.isContainerWebViewInterceptTouch(event, this)) {
DebugLogUtils.log(TAG, "isContainerWebViewInterceptTouch");
return super.dispatchTouchEvent(event);
}
return ... || commentGestureHelper.handleDispatchTouchEvent(event)
|| super.dispatchTouchEvent(event);
}

其中一个就是拦截事件，上滑的时候进入评论页。所以我们在这里首先要判断 WebView 是否会拦截这个事件，那么也就会调用 captureView 方法去绘制，那么也就会多一次 captureView 的调用，如果 WebView 未拦截事件，最终事件回到 Activity 又会导致一次 captureView 调用。

总共就是三次调用，所耗费的时间是三倍的绘制时间 3 * 90ms ，申请的内存也是 3 倍。

优化措施

新增位置及 alpha 值的缓存：

data class AlphaCache(var eventX: Int = -1, var eventY: Int = -1, var alpha: Float = 0f)

记录上次点击的 X, Y 及 alpha 值，如果下次方法调用和之前的点击点一致的话，就不重新计算

    fun getViewTouchAlpha(ev: MotionEvent, view: View): Float {
if (view.alpha <= 0f) {
return 0f
}
if (alphaCache.eventX == ev.x.toInt() && alphaCache.eventY == ev.y.toInt()) {
return alphaCache.alpha
}
val drawingCache = captureView(view)
return drawingCache.getPixel(ev.x.toInt(), ev.y.toInt()).alpha.toFloat()
}

这样可以减少 2 次内存申请和 2 次绘制，性能优化了 4 倍。

Bitmap 大小优化

bitmap 如果大小是屏幕宽高的话，申请的内存会非常大，那我们是不是可以缩小 bitmap 的大小，于是想到了一种方案

优化措施一：

// BITMAP_WIDTH = 10
private fun captureView(evX: Int, evY: Int, view: View): Bitmap {
val bitmap = Bitmap.createBitmap(BITMAP_WIDTH, BITMAP_WIDTH, Bitmap.Config.ARGB_8888)
val canvas = Canvas(bitmap)
canvas.translate(-evX + BITMAP_WIDTH / 2f, -evY + BITMAP_WIDTH / 2f)
view.draw(canvas)
return bitmap
}

我们把 bitmap 的大小改为了 10 * 10 ，同时移动画布，使绘制的位置刚好在这个 bitmap 内，通过传入的点击位置去确定画布的位置

此时内存变为 4 10 10byte，内存减少了 20000 多倍。

优化措施二

在优化了 bitmap 内存之后，发现快速点击视频还是会出现一点卡顿，于是测试了 view.draw(canvas) 方法，发现其在每一次触发的时候需要消耗的时间平均在 90ms 左右，所以会导致卡顿出现

draw 绘制的时候是否可以只去绘制一小部分：

    private fun captureView(evX: Int, evY: Int, view: View): Bitmap {
val bitmap = Bitmap.createBitmap(BITMAP_WIDTH, BITMAP_WIDTH, Bitmap.Config.ARGB_8888)
val canvas = Canvas(bitmap)
canvas.translate(-evX + BITMAP_WIDTH / 2f, -evY + BITMAP_WIDTH / 2f)
canvas.clipRect(evX - BITMAP_WIDTH / 2f, evY - BITMAP_WIDTH / 2f ,evX + BITMAP_WIDTH / 2f, evY + BITMAP_WIDTH / 2f)
view.draw(canvas)
return bitmap
}

使用 clipRect 的方式，让其在绘制的时候只去绘制一小部分。

优化后实测在 100 100 的 Rect 中绘制只需 9ms ，而在10 10的 rect 中绘制平均只需 1ms ，这里速度优化了 90 倍！

优化措施三

bitmap 的大小为 4 10 10byte，这个 4 是 ARGB_8888 中来的，但是我们这一次只是用到了其中的 alpha 值，那是不是不用这么多？

    private fun captureView(evX: Int, evY: Int, view: View): Bitmap {
// 使用 ALPHA_8
val bitmap = Bitmap.createBitmap(BITMAP_WIDTH, BITMAP_WIDTH, Bitmap.Config.ALPHA_8)
val canvas = Canvas(bitmap)
//...
return bitmap
}

使用这种方式，又把内存占用优化到了原本的四分之一。

优化总结

整体优化下来，内存占用少了 80000 多倍，绘制耗时少了 90 倍，快速点击 web 页面在播放视频时完全感觉不到卡顿，非常完美！

WebView 增强

在实际上线之后，发现有很多WebView出现 android.webkit.WebViewFactory$MissingWebViewPackageException: Failed to load WebView provider: No WebView installed 异常，这个异常在平时也能看到，但都没有引起重视，由于我们 Poplayer 用在了流量非常大的一个页面，所以该问题直接暴露。

解决方法其实很简单：

// Poplayer容器由一个Fragment包裹
val rootView = runCatching {
super.onCreateView(inflater, container, savedInstanceState)
}.getOrElse {
activity?.supportFragmentManager?.beginTransaction()?.remove(this)?.commitAllowingStateLoss()
return null
}

当然需要注意的是 onCreateView 返回之后，一些 super 的逻辑执行不到，可能引发一些问题，需要在开发的时候规避。

总结

当你一直在做一些重复工作，感觉到恶心时，就必须考虑，这些工作是否存在一定的共通性，是否有办法可以进行优化，是否可以借助一些工具来提升效率，而不是又双叒叕的去重复着这些事情。

很多场景不只是自己会遇到，也许业界早已经有了相对成熟的方案可以使用，平时也可以多关注业界的发展，拓宽自己的思路。当然在参考一些方案的时候也要去适配自己的一些特性，达到高可用状态。

后续改进

目前 Poplayer 容器还是 HTML5 来承载，HTML5 本身的性能以及不稳定性问题仍然存在，后续可以考虑使用 ReactNative 容器，对于非动态化场景，也可以考虑 Flutter 容器来做，只需要容器层去接入，同时传递点击事件即可。

参考资料

利用 Poplayer 在手淘中实现稳定业务和临时业务分离

以上是 【安卓】Poplayer 云音乐优化实践 的全部内容， 来源链接： utcz.com/a/99977.html

回到顶部