广告接入相关

作为吃瓜群众，最近meta的股价回升，看新闻是AI+广告带来的营收效果，从商业化看，广告确实是一个很好的商业化变现方式。
作为用户，前段时间，所有app闪屏就跳淘宝，大概是面对广告最直接的体验吧.
作为普通的app开发者，我们能接触到的是更基础的，广告sdk接入。

最近产品更换了广告SDK的聚合供应商，这篇文章梳理一下广告SDK常见的功能、以及接入过程（Android）中我遇到的一些坑点吧。

广告提供商

目前有很多提供商，比如：
腾讯的广点通aka优量汇广告（GDTSDK_unionNormal）
字节的融合穿山甲（open_ad_sdk）
快手广告（kssdk-ad）
京东广告（jad_yun_sdk_jingdong）
百度广告（Baidu_MobAds_SDK）
趣盟广告（qumeng）
万维广告（Oneway）

广告的接入基本上是纯客户端的事情。
开发者的服务端只是作为广告id下发、展示成功的日志记录作用而已，不参与广告的展示流程。

广告展示

广告的流程大约是这样的：

广告id配置：

这些平台的后台的id上，配置好广告参数。测试、正式可以使用不同的id。

广告展示

服务端动态下发id，客户端获取到id之后，用id在程序的对应位置去展示广告。
常见的位置有 闪屏、开屏、信息流、激励。

闪屏、开屏、信息流，这几个都是我们提供view组件，广告sdk填充我们的组件，填充的时候，高宽的设定每个广告都可以在后台配置，客户端不能限制其高宽。生命周期部分需要仔细处理。

激励广告 是唤出一个新的、sdk提供的 activity 去承载，所以生命周期部分的处理相对简单一点。
激励广告还是比较特别的，它是用户看广告之后，由我们提供奖励。比如奖励时长、成长值之类的。
所以激励广告很可能在app中的很多场景都有嵌入。比如看书看到一半，没阅读时长了，可以看广告领取。比如每天的任务，用户可以主动签到看广告领取。
接入也比较麻烦。一是因为场景多，二是激励前后需要和服务端交互，确认是否有激励次数、是否被刷、是否看完广告领取。

广告竞价

通过客户端接入多个广告sdk，同时加载，加载后对比广告的收入，ecmp高的广告展示，低的就淘汰。
某些营收有压力的app，可能会接入十几个广告sdk，然后卷价格。
不过这些广告sdk本身有一些缺陷，所以用户手机性能不够，卷的时候可能把用户卷没了。

从上面的描述，你也可以看到，服务端的工作主要是激励广告部分的处理，其他的接入工作基本上是客户端处理。

坑点

穿山甲、优量汇动态下发代码导致低端机卡死

一开始我是发现系统出现了anr的窗。
然后我通过mainhandler的looper去检测ui线程的耗时的。
发现每次出现anr的时候，都是有个looper执行超过了5秒，一般是6-15秒。
然后我另外开了一个线程，在检测到这个问题looper的时候，就把堆栈打出来。代码示意如下：

@Volatile
private var trace = false
private fun printStack() {
    trace = true
    Thread({
        val stack = Thread.getAllStackTraces()
        (0..50).forEach { index ->
            if (!trace) return@Thread
            stack.keys.forEach { thread ->
                if (thread.name == "main") {
                    Lg.e("anr_stack", "------------ ${System.currentTimeMillis()} ------------------ $index")
                    val mainStack = stack[thread]
                    mainStack?.forEach {
                        Lg.e("anr_stack", "line:${it.lineNumber} class:${it.className} ,method:${it.methodName} file:${it.fileName}")
                    }
                    Lg.e("anr_stack", "------------------------------ $index")
                }
            }
            Thread.sleep(300)
        }
    }, "print stack").start();
}

观察发现调用展示信息流的时候，每次都主线程的堆栈都停了在奇怪的位置。
猜测是虚拟机加载这些动态程序的时候，暂停了jvm环境的程序执行。

解决的思路有几个：
一是这个信息流的初始化，尝试改成在异步线程执行；
二是反馈给这两个平台，让他们优化好代码；
三是识别到低端机，就不初始化这两个平台的广告。

题外话提一句。
从安全的角度，如果这些广告商节操低一点，下发点恶意代码，防无可防。
如果这些广告商被攻击，下发了恶意代码，也是没有很好的处理方法。

穿山甲信息流广告内存泄漏

一开始我是 dumpsys meminfo，去看我的程序的内存开销，看了几个信息流之后，内存从 200m 飙升到 500m，有点奇怪，所以仔细查了一下。
我主要是查是不是我这边没接好。几个检查点：
一是销毁接口有没有正常触发；
二是加载未完成中，切页面后，有没有补触发销毁接口；
三是回掉callback是不是弄了内部类，强绑定了activity之类的大组件。

最后一点我是这样做的：

class XXXListenerAdapter(var listener: XXXListener?) : XXXListener {
    override fun onLoaded(p0: XXXX?) {
        if (listener == null) {
            p0?.destory()
        } else {
            listener?.onLoaded(p0)
        }
    }
    override fun onError(p0: XXXXX?) {
        listener?.onError(p0)
    }
}

即对方提供的回掉我都包一层。等生命周期结束的时候，我手动清理掉 listener 的对象就好。
但是很不幸，上述几个检查点做完了，还是内存不见减少。

这时候我去广告商提供的demo上build.gradle加了leakcanary的库，然后把堆栈dump出来。

implementation 'com.squareup.leakcanary:leakcanary-android:2.11'

穿山甲是一定泄漏，其他几个sdk是有概率出现问题。
观察每次都是调用信息流，一个信息流大约泄漏40m-50m的内存。看10个广告，泄漏的内存就奔500m去了。
手机差一点的，看几个之后，就会出现 OutOfMemoryError、art::gc::Heap::ConcurrentGC 等相关的崩溃。

解决的思路：

1. 提单问他们，对方表示不改，是feature（如果你也是受到这个困扰，可以一起提单督促他们）。
2. 编译期修改代码，帮他们处理这个泄漏
3. 对用户手机做下设备判断，内存不够的，就别加载穿山甲广告了【连崩个几次，用户就没了，还不如展示其他功能稳定点的广告】。