Flink埋点系统 flutter 埋点

引言：全埋点，众所周知是移动端一个收集用户行为和数据分析很重要的一项技术手段。Flutter作为近几年年大热的移动端跨平台技术生态圈已慢慢建设起来，而全埋点始终没有很好的解决方案，于是通过阅读源码找寻了一些思路分享出来。

一、页面埋点

思路：在CupertinoApp中添加NavigatorObserver全局页面监听，当页面push和pop时维护一个自定义的路由栈用来存储需要的信息，方便回溯。监听方法：didPush、didPop、didRemove、didReplace。当触发页面push时监听页面渲染完成，然后从根节点遍历Element树寻找类型为Scaffold或CupertinoPageScaffold的Element，则最后一个元素命中当前页面，记录保存信息在堆栈中。当页面pop时从栈顶取出页面信息上报。

定位到Scaffold或CupertinoPageScaffold则需要遍历子节点寻找我们需要的信息。确定AppBar或NavigationBar有PreferredSize或ObstructingPreferredSizeWidget两种实例，如果AppBar有Title为Text，则data则为我们需要的信息，否则向下遍历子树寻找第一个Text标签。

二、用户点击行为埋点

思路：系统处理手势是在底层生成GestureDetector，传入OnTap等手势事件调用CallBack，分离widget树。包装GestureArenaMember进行竞技场竞争，由获胜者acceptGesture调用手势事件（分层解耦思想体现地淋漓尽致）。当然竞技场还有管理者GestureArenaManager，竞技场管理者放在GestureBinding中，最后调用dispatchEvent处理。我们需要获取到获胜手势，并且关联RenderObject，然后遍历Element树匹配获胜者。因为GestureDetector为Button的chid或者只有自身，所以我们判断常用的Button类，当无法匹配到的前提下说明没有包装Button，则再去寻找最近的GestureDetector，获取其Widget。最后提炼关键信息Text、Icon、Image、SvgPicture等（总体思路就是继承系统组件，添加自己需要的字段，然后回传给系统调用，最方便还是在运行时动态插入代码）。

第一步：参照Flutter框架的WidgetsFlutterBinding进行实现，将其子类化，并将必要的变量与方法替换掉（类似Flutter的testing框架，自定义了TestWidgetsFlutterBinding）。

void runApp(Widget app) {
    var widget = EventMonitorWidget(
      monitor: eventMonitor,
      child: app,
    );
    scheduleAttachRootWidget(widget);
    scheduleWarmUpFrame();
  }

第二步：替换掉竞技场管理者的实例，安插一个由我们实现的实例，用于监测获胜的手势。

@override
  final GestureArenaManager gestureArena = EventMonitorGestureArenaManager();

第三步：覆盖原先的dispatchEvent方法。将HitTestResult替换为由我们实现的实例，将用于建立手势GestureArenaMember与手势的创建者HitTestTarget之间的对应关系。

@override
  void dispatchEvent(PointerEvent event, HitTestResult hitTestResult, {TestBindingEventSource source: TestBindingEventSource.device}) {
    var monitoredResult = (gestureArena as EventMonitorGestureArenaManager).dispatchEvent(event, hitTestResult);
    super.dispatchEvent(event, monitoredResult);
  }

第四步：在自定义的竞技场成员获胜者调用acceptGesture方法里通知监听者。并传入RenderObject遍历Element树确定widget，然后向下查找需要的标识信息。

void acceptGesture(int pointer) {
    if ((member is GestureRecognizer) && (onAcceptGesture != null)) {
      onAcceptGesture(this);
    }
    member.acceptGesture(pointer);
  }

优化：点击事件up状态并不一定还在原触发控件里，需要过滤掉部分手势事件，防止误报信息。

思路：hook掉系统的类GestureArenaMember、GestureArenaManager、HitTestTarget、HitTestEntry、HitTestResult方便添加我们需要的信息。用户的触摸事件在从Down到Up的整个历程中，某个手势一旦获得竞技胜利，只会触发一次AcceptGesture，为了保证整个历程中的每一个事件都能通知给外部处理者，需要补发一次回调。在监听者处过滤event不为PointerUpEvent且GestureRecognizerState不为possible的Tap手势胜利者进行点击处理上报。

三、列表元素曝光

思路：在widget顶部添加全局滑动监听NotificationListener。我们发现在ScrollNotification中带有滚动发起者context(为GestureDetector),则可通过往上查找widget树匹配第一个为ScrollView或SingleChildScrollView类型的列表目标element。需要拿到列表全部cell高度，则可以通过ScrollNotification中metrics.pixels的偏移量，结合列表高度计算出曝光范围width和height。这里我们往下查找第一个元素为RenderSliverMultiBoxAdaptor的RenderObject(通过看源码得知常用ListView等列表widget底层生成的RenderObject)，记录.paintBounds.size并查询所有的child为RenderIndexedSemantics类型是我们找到的cell。注意：这里获取到的曝光cell和缓存区的cell，并不一定是全部的列表元素，所以我们需要记录一个Map类型数据缓存用来进行列表数据更新，保证获取到所有cell的size。考虑到内存问题，所以引入了LRU缓存机制进行优化。最后计算在曝光范围内元素的索引范围。

上报规则：在用户开始滚动时记录曝光元素和当前时间，当有额外交互时检查是否有之前的记录，并且超过一定间隔才做上报处理，否则清空记录。自定义了widget方便业务侧上传需要上报的源数据或提供列表的上下Globalkey获取上下组件的坐标计算出模板列表坐标和size。

优化：1.复杂列表比如NestedScrollView有头部和内容联动，导致查找出来的元素偏多，因为获取到列表高度是整体nestedScrollView不是内部内容高度。2.列表查询的RenderObject覆盖面有待查验，可能有遗漏特殊列表类型。3.当页面加载完毕就应该记录初始化曝光的元素。

int start, end;
  double addHeigh = 0;
  for (var i = 0; i < itemHeighList.length; i++) {
    double itemHeigh = itemHeighList[i];
    if (start == null && (addHeigh + itemHeigh * 0.5) >= 偏移量) {
      //确定开始范围
      start = i;
    } 
    if ((addHeigh + itemHeigh * 0.5) < (offset + 列表高度)) {
      //确定结束范围
      end = i;
    }
    addHeigh += itemHeigh;
  }

四、用户切换前后台

思路：在最顶层widget中聚合WidgetsBindingObserver，监听didChangeAppLifecycleState方法。当AppLifecycleState为paused表示进入后台，resumed表示进入前台。

@override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    super.didChangeAppLifecycleState(state);
    if (state == AppLifecycleState.paused) {
      //后台
    }
    if (state == AppLifecycleState.resumed) {
      //前台
    }
  }