Android tracking technology analysis

1. Tracking is a method of collecting data from websites, apps, or backend applications. By tracking, users’ behaviors in the application can be collected, which can then be used to analyze and optimize the subsequent product experience, and can also provide data support for product operations. Common indicators include PV, UV, page duration, and button clicks.

When collecting behavioral data, you usually need to add some code to the web page/App. When the user's behavior reaches a certain condition, the user's behavior will be reported to the server. In fact, the process of adding these codes can be called "tracking", and this technology has appeared a long time ago. With the development of technology and the continuous improvement of everyone's requirements for data collection, I think the technical solution of tracking has gone through the following stages:

Code tracking: Code tracking means that developers add behavior reporting codes to the source code of web pages/Apps according to product/operation requirements. When the user's behavior meets a certain condition, these codes will be executed and the behavior data will be reported to the server. This solution is the most basic solution. Every time you add or modify the conditions for data reporting, you need the participation of developers, and the effect can only be seen after the next version is launched. Many companies provide this type of data reporting SDK, which encapsulates the background server interface of behavior reporting into a simple client SDK interface. Developers can embed this type of SDK and call a small amount of code at the tracking location to report behavior data.

Full tracking: Full tracking means that all behaviors generated in the web page/App that meet a certain condition are reported to the background server. For example, all button clicks in the App are reported, and then the product/operation will go to the background to filter the required behavior data. The advantage of this solution is very obvious, that is, you don’t need to find developers to modify the tracking code when adding/modifying behavior reporting conditions. However, its disadvantages are as obvious as its advantages, that is, the amount of data reported is much larger than code tracking, and there may be a lot of worthless data in it. In addition, this solution tends to look at user behavior independently without paying attention to the context of the behavior, which brings some difficulties to data analysis. Many companies also provide SDKs for this type of function, which "hook" the original App code in a static or dynamic way to achieve behavior monitoring. When reporting data, it is usually a solution to accumulate multiple requests and then report them to merge requests.

Hook literally means hook. I have heard of it in Windows when I was studying information security. It generally means to change the behavior of a system API by some means, bypass a method of the system, or change the workflow of the system. Here it actually means to replace the object that is supposed to execute a method with another one, usually using reflection or proxy. You need to find the code location of the hook, and you can even replace it during the compilation stage.

Visual tracking: Visual tracking means that the product/operation circles the element on the interface of the web page/App, configures which element on the interface needs to be monitored, and then saves the configuration. When the App starts, it will obtain the configuration pre-selected by the product/operation from the background server, and then monitor the elements on the App interface according to this configuration. When an element meets the conditions, the behavior data will be reported to the background server. With the full tracking technology solution, it is easy to think of on-demand tracking from the perspective of experience optimization. Visual tracking is a solution for configuring tracking on demand. Some companies now provide this type of SDK. When circling the monitoring elements, a Web management interface is generally provided. After the mobile phone installs and initializes the SDK, it can connect to the management interface, allowing users to configure the elements to be monitored on the Web management interface.

There are many SDKs in the industry that support one or all of the three tracking solutions introduced above, such as Mixpanel, Sensorsdata, TalkingData, GrowingIO, Zhuge IO, Heap Analytics, MTA, Umeng Analytics, and Baidu. However, the names of the latter two tracking solutions are not exactly the same, and some are called no tracking or codeless tracking. Since Mixpanel (supports code tracking and visual tracking) and Sensorsdata (supports all) have open-sourced their entire SDKs, the technical solutions are also similar. Let's take their Android SDKs as an example to briefly analyze the technical implementation of the three tracking solutions. For the technical implementation of JS SDK, you can read my other blog - JS Tracking SDK Technical Analysis.

2. Code Buried Points

Most SDKs, including the Mixpanel SDK, encapsulate this tracking solution into a relatively simple interface, which is track(String eventName, JSONObject properties) here. When developers call this interface, they can pass in an event name and event properties, and then report it to the backend.

In terms of implementation, Mixpanel SDK uses a HandlerThread thread to handle events by default. When the developer calls the track(String eventName, JSONObject properties) method, the main thread switches to the HandlerThread and stores the event in the database first. Then it checks whether 40 events have been accumulated in the SDK. If so, they are merged and reported to the backend.

When the developer sets the debug mode or manually calls the flush API, all accumulated events can be reported immediately. However, since there is only one thread, if the previous events have not been processed when flushing, the SDK will process the subsequent events again after an interval of 1 minute.

Developers can set the threshold for the number of events reported cumulatively, the time interval for retrying to report when an event is blocked, etc. This solution is relatively basic and I believe most developers have come across it and do not need to analyze it too much.

3. Full Buried Points

3.1 AOP Basics

Mixpanel's current Android SDK does not provide this function, but the Sensors Android SDK does, and the implementation method relies on AOP. So what is AOP?

In the software industry, AOP is the abbreviation of Aspect Oriented Programming, which means: aspect-oriented programming, a technology that achieves unified maintenance of program functions through pre-compilation and runtime dynamic proxy. AOP is a continuation of OOP, a hot topic in software development, and an important part of the Spring framework. It is a derivative paradigm of functional programming. AOP can be used to isolate various parts of business logic, thereby reducing the coupling between various parts of business logic, improving the reusability of the program, and improving development efficiency. (from baidu baike)

In short, AOP is a technology that can dynamically and uniformly add functions to a program without modifying the source code through precompilation and runtime dynamic proxy.

The implementation of Sensors Analytics Android SDK full embedding is to find the location where events need to be reported in the source code during the code compilation phase and insert the SDK event reporting code. The framework used is AspectJ.

At this point, we must briefly understand AspectJ and some of its concepts. It is the leader of AOP and we can see it in many places, such as Hugo, an annotation logging and performance tuning framework contributed by JakeWartson. AspectJ is also widely used in the Spring framework. I understand the main concepts in AspectJ are:

• JPoint: Code cut point (where we want to insert the code)
• Aspect: Description of code cut point
• Pointcut: describes what the pointcut is, such as where the function is called (Call(MethodSignature)) or where the function is executed (execution(MethodSignature)).
• Advice: describes where to insert the code at the pointcut, such as before the pointcut ( @Before ) or after the pointcut ( @After ), or around the entire pointcut ( @Around )

It can be seen that when implementing AOP functions, the following things need to be done:

• Define an Aspect, which must have two attributes: Pointcut and Advice.
• Write the code that needs to be injected when matching the code described by Pointcut and Advice
• When the code is compiled, a special Java compiler (Aspect's ajc compiler) is used to find the code that conforms to the Aspect we defined, and insert the code to be injected into the location specified by the Advice.

If you are familiar with AspectJ, you can already guess how the full embedding is implemented inside the SDK; if you are not exposed to it, I don’t think you need to rush to learn AspectJ comprehensively, because only a small part of AspectJ’s functions are used inside the SDK. You can directly see the analysis below.

3.2 Full Buried Points-Technical Implementation

How does Sensors SDK monitor View click events? I simplified the SDK code for analysis. There are several steps:

3.2.1 Defining an Aspect

 import org.aspectj.lang.JoinPoint;
 import org.aspectj.lang.annotation.After ;
 import org.aspectj.lang.annotation.Aspect;
 import org.aspectj.lang.annotation.Pointcut; 
 
 @Aspect
 public class ViewOnClickListenerAspectj{ 
 
 /**
 * android. view . View .OnClickListener.onClick(android. view . View )
 *
 *@paramjoinPoint JoinPoint
 * @throwsThrowable Exception
 */
    @ After ( "execution(* android.view.View.OnClickListener.onClick(android.view.View))" )
 public void onViewClickAOP(final JoinPoint joinPoint)throws Throwable {
        AopUtil.sendTrackEventToSDK(joinPoint, "onViewOnClick" );
 }
 }

This Aspect code defines: After executing the original implementation of the android.view.View.OnClickListener.onClick(android.view.View) method, you need to insert the code AopUtil.sendTrackEventToSDK(joinPoint, "onViewOnClick");

AopUtil.sendTrackEventToSDK(joinPoint, "onViewOnClick"); This code reports click events. Because Sensors SDK separates the full tracking function and the main SDK package into two jar packages, the AopUtil tool is used to call the actual event reporting code. Its implementation is not described in detail here. Let's take a look at the actual click reporting implementation behind this code.

 SensorsDataAPI.sharedInstance().track(AopConstants.APP_CLICK_EVENT_NAME, properties);

You can see that AOP implements click monitoring, and *** also reports it using the track method.

3.2.2 Using the ajc compiler to insert aspect code into source code

If you want to inject the code written in the AspectJ framework into the original project code, you need to reference the ajc compiler in /app/build.gradle. The script is as follows:

 ...
 import org.aspectj.bridge.IMessage
 import org.aspectj.bridge.MessageHandler
 import org.aspectj.tools.ajc.Main 
 
 buildscript {
 repositories {
 mavenCentral()
 }
 dependencies {
        classpath 'org.aspectj:aspectjtools:1.8.10'  
 }
 } 
 
 repositories {
 mavenCentral()
 } 
 
 android {
 ...
 } 
 
 dependencies {
 ...
    compile 'org.aspectj:aspectjrt:1.8.10'  
 } 
 
 final def log = project.logger
 final def variants = project.android.applicationVariants 
 
 variants. all { variant ->
    if (!variant.buildType.isDebuggable()) {
        log.debug( "Skipping non-debuggable build type '${variant.buildType.name}'." )
 return ;
 } 
 
    JavaCompile javaCompile = variant.javaCompile
 javaCompile.doLast {
        String[] args = [ "-showWeaveInfo" ,
 "-1.5" ,
 "-inpath" , javaCompile.destinationDir.toString(),
 "-aspectpath" , javaCompile.classpath.asPath,
 "-d" , javaCompile.destinationDir.toString(),
 "-classpath" , javaCompile.classpath.asPath,
 "-bootclasspath" , project.android.bootClasspath.join ( File.pathSeparator )]
        log.debug "ajc args: " + Arrays.toString(args) 
 
        MessageHandler handler = new MessageHandler( true );
        new Main().run(args, handler);
 for (IMessage message : handler.getMessages( null , true )) {
           switch (message.getKind()) {
 case IMessage.ABORT:
 case IMessage.ERROR:
 case IMessage.FAIL:
                    log.error message.message, message.thrown
 break;
 case IMessage.WARNING:
                    log.warn message.message, message.thrown
 break;
 case IMessage.INFO:
                    log.info message.message, message.thrown
 break;
 case IMessage.DEBUG:
                    log.debug message.message, message.thrown
 break;
 }
 }
 }
 }

In SensorsAndroidSDK, the above script is written as a gradle plug-in. Developers only need to reference this plug-in in app/build.gradle.

 apply plugin: 'com.sensorsdata.analytics.android'  

3.2.3 Complete code insertion and check the effect after insertion

After completing the above two steps, we can insert our data reporting code into the android.view.View.OnClickListener.onClick(android.view.View) method. We add a Button to the demo code and set an OnClickListener for it. Compile the code and check the class files in /build/intermediates/classes/debug/. After ajc compilation, the Aspect code is inserted into the original code and the onViewClickAOP method in ViewOnClickListenerAspectj is called.

 public class MainActivityextends Activity{
 public MainActivity(){
 } 
 
    protected void onCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        this.setContentView(2130968603);
        Button btnTst = (Button)this.findViewById(2131427422);
        btnTst.setOnClickListener(new OnClickListener() {
 public void onClick( View v){
                JoinPoint var2 = Factory.makeJP(ajc$tjp_0, this, this, v); 
 
 try {
                    Log.i( "MainActivity" , "button clicked" );
                } catch (Throwable var5) {
                    ViewOnClickListenerAspectj.aspectOf().onViewClickAOP(var2);
                    throw var5;
 } 
 
                ViewOnClickListenerAspectj.aspectOf().onViewClickAOP(var2);
 } 
 
 static {
                ajc$preClinit();
 }
 });
 }
 }

This is the basic usage of AspectJ. SensorsAndroidSDK inserts Aspect code with the help of AspectJ, which is a static method. The static full-point solution essentially modifies the bytecode and inserts the event reporting code.

In addition to this solution, there are also the transform API (version 1.5.0 or later), ASM, and Javassist provided by the Android Gradle plug-in to modify the bytecode. These technologies can be seen in the NetEase Lede tracking solution and the Nuwa hot fix project.

3.3 AspectJ related information

• Aspect Oriented Programming in Android: https://fernandocejas.com/2014/08/03/aspect-oriented-programming-in-android/
• AspectJ comprehensive analysis of AOP in Android: http://www.jianshu.com/p/f90e04bcb326
• Hujiang has open-sourced a plug-in called AspectJX, which extends AspectJ. In addition to AOP for src code, it also supports AOP for kotlin, jar and aar referenced in the project: https://github.com/HujiangTechnology/gradle_plugin_android_aspectjx
• Everything you need to know about Spring AOP (AspectJ): http://blog.csdn.net/javazejian/article/details/56267036

3.4 Other ideas

The above is a "static Hook" implementation represented by AspectJ. Is there any other way to "dynamically Hook" the click behavior when the App is running without modifying the source code? The answer is yes. In the Java world, there is also reflection. Let's see how to implement the replacement of click events.

In the source code of android.view.View.java (API>=14), there are several key methods:

 // getListenerInfo method: returns all listener information mListenerInfo
 ListenerInfogetListenerInfo(){
    if (mListenerInfo != null ) {
 return mListenerInfo;
 }
    mListenerInfo = new ListenerInfo();
 return mListenerInfo;
 } 
 
 //Listener information
 static class ListenerInfo{
 ... // Various xxxListeners are omitted here
 /**
 * Listener used to dispatch click events.
 * This field should be made private, so it is hidden from the SDK.
 * {@hide}
 */
 public OnClickListener mOnClickListener; 
 
 /**
 * Listener used to dispatch long click events.
 * This field should be made private, so it is hidden from the SDK.
 * {@hide}
 */
    protected OnLongClickListener mOnLongClickListener; 
 
 ...
 }
 ListenerInfo mListenerInfo; 
 
 // This method is very familiar to us. It actually sets the mOnClickListener of mListenerInfo to the OnclickListner object we created.
 public void setOnClickListener(@Nullable OnClickListener l){
 if (!isClickable()) {
 setClickable( true );
 }
    getListenerInfo().mOnClickListener = l;
 } 
 
 /**
 * Determine whether this View has a click listener set
 * Return whether this view has an attached OnClickListener. Returns  
 * true if there is a listener, false if there is none.
 */
 public boolean hasOnClickListeners(){
    ListenerInfo li = mListenerInfo;
 return (li != null && li.mOnClickListener != null );
 }

From the above methods, we can see that the click listener is actually saved in mListenerInfo.mOnClickListener. So when implementing the Hook click listener, just replace this mOnClickListener with the click listener proxy object we packaged. Let's take a look at the implementation ideas:

1. Create a click listener proxy class

 // The click listener proxy class has the function of reporting click behavior
 class OnClickListenerWrapperimplements View .OnClickListener{
 // The original click listener object
    private View .OnClickListener onClickListener; 
 
 public OnClickListenerWrapper( View .OnClickListener onClickListener){
        this.onClickListener = onClickListener;
 } 
 
 @Override
 public void onClick( View   view ){
 // Make the original click listener work properly
        if(onClickListener != null ){
            onClickListener.onClick( view );
 }
 // Click event reporting, you can get some properties of the clicked view
        track(APP_CLICK_EVENT_NAME, getSomeProperties( view ));
 }
 }

2. Reflect and get a View's mListenerInfo.mOnClickListener and replace it with the proxy's click listener

 //Hook a View 's click listener
 public void hookView( View   view ) {
 // 1. Reflectively call the getListenerInfo method of View (API>=14) to obtain the mListenerInfo object
    Class viewClazz = Class.forName( "android.view.View" );
    Method getListenerInfoMethod = viewClazz.getDeclaredMethod( "getListenerInfo" );
    if (!getListenerInfoMethod.isAccessible()) {
        getListenerInfoMethod.setAccessible( true );
 }
    Object mListenerInfo = listenerInfoMethod.invoke( view ); 
     
 // 2. Then obtain the mOnClickListener object from mListenerInfo by reflection
    Class listenerInfoClazz = Class.forName( "android.view.View$ListenerInfo" );
    Field onClickListenerField = listenerInfoClazz.getDeclaredField( "mOnClickListener" );
    if (!onClickListenerField.isAccessible()) {
        onClickListenerField.setAccessible( true );
 }
 View .OnClickListener mOnClickListener = ( View .OnClickListener) onClickListenerField.get(mListenerInfo); 
     
 // 3. Create a click listener object for the proxy
 View .OnClickListener mOnClickListenerWrapper = new OnClickListenerWrapper(mOnClickListener); 
     
 // 4. Set the mOnClickListener of mListenerInfo to the new onClickListenerWrapper
    onClickListenerField.set (mListenerInfo, mOnClickListenerWrapper) ;
 // This seems to work: view .setOnClickListener(mOnClickListenerWrapper);
 }

Note that if the API is < 14, mOnClickListener is directly stored in the View object as a Field, without ListenerInfo, so the number of reflections is less.

3. Hook all Views in the App

We are analyzing all embedded points, so how to hook all View clicks in the App? There are two ways:

***: After the Activity is created, start traversing the ViewTree from top to bottom from the Activity's DecorView. When a View is traversed, hookView is performed on it. This method is a bit violent, and performance will be affected because a lot of reflection is used when traversing the ViewTree.

The second method is slightly better than the first method. It comes from an open source library AndroidTracker (Kotlin implementation) on Github. Its processing method is to add a transparent View as a child View in DecorView after the Activity is created. In the onTouchEvent method of this child View, the View on the screen containing the coordinates is found according to the touch coordinates, and then the hookView operation is attempted on these Views. This method is more tricky. First, the position where the finger is pressed is obtained, and the View that needs to be hooked is found according to this position, avoiding the reflection of the View while traversing the ViewTree. The specific implementation is to determine whether the coordinates of this View contain the coordinates of the finger pressed, and whether the View is Visible when traversing each View in the ViewTree. If these two conditions are met, the View is saved in an ArrayList hitViews. Then the Views in this ArrayList are traversed again. If a View#hasOnClickListeners returns true, the hookView operation is performed on it.

Overall, the idea of ​​dynamic Hook uses reflection, which will inevitably affect the performance of the program. If you want to use this method to implement a full embedding solution, you still need to evaluate it carefully.

4. Visualization of tracking points

4.1 Visualized tracking points - technical implementation

Visual tracking requires two steps and can be completed by non-technical personnel. The first step is to use the App embedded with Mixpanel/SensorsSDK to connect to the background. When the mobile App is synchronized with the background, the background management interface will display the same interface as the mobile App. Users can use the mouse to select the elements to be monitored on the management interface, set the event name, the element attributes to be monitored, etc. (It is said that some SDKs' circle selection operations are performed on the mobile phone. Regardless of the method, it is essentially the same, and a configuration needs to be saved to the background). The second step is that when the App embedded with the SDK is started, it will obtain a configuration from the server, and then detect the interface and elements in the App based on this configuration, and report events to the server when the configuration conditions are met. The following takes Mixpanel and SensorsdataSDK as examples to briefly analyze the implementation of the technical solution.

4.1.1 Circle the elements to be monitored and save the configuration

1. Create a WebSocket connection backend

The reason for using WebSocket connection is to keep the mobile phone and the backend connected for a long time, which is a continuous two-way communication. When connected to the backend, the device information of the mobile phone is sent to the backend.

2. Send the screenshot of the App interface to the backend

After creating the Socket connection, in the main thread, scan the Activity started in the App to find the RootView (actually DecorView) of the interface. While searching for the RootView, a screenshot of the RootView will be taken, and the createSnapshot method of the View class is called by reflection.

After taking a screenshot, the SDK will determine the hash value of the image. If the image has changed, it will use a recursive method to deeply traverse the Activity's ViewTree and read the View's properties (id, top, left, width, height, class name, layoutRules, etc.) while traversing.

***, send the collected data to the connected backend, which will parse it and display the App interface on the web page. Users can circle the element to be monitored on this web page, set the time name of this element (event_type and event_name), and save the configuration.

4.1.2 Get configuration, monitor element behavior, and report events

1. Get the configuration

When the SDK is started, it will pull a JSON configuration from the server and save it in sharedPreference. At the same time, the SDK will scan the resource ID and resource name in the android.R file and save them.

After the SDK is configured, it is parsed into a JSON object, and the event_bindings field is read. Then the events field is read. This field contains an array. Each element of the array describes a type of event and contains the Activity and path of the element that needs to be monitored for this type of event. This configuration is basically structured like this:

 event_bindings: {
 events:
 {
            target_activity: ""  
 event_name: ""  
 event_type: ""  
 path: [
 {
 prefix:
                    view_class:
 index :
 id:
 id_name:
 },
 ...
 ]
 }
 ]
 }

After receiving this configuration, the SDK will generate a ViewVisitor based on each event information. The function of ViewVisitor is to find all View elements pointed to in the path array, and set the corresponding behavior monitor for this View element according to event_type. When the View has a specified behavior, the monitor will detect it and report the behavior.

After ViewVisitor is generated, the SDK saves them in a Map structure, which is also relatively easy to understand.

2. Monitor elements and report events

How does ViewVisitor monitor the behavior of elements? The answer is View.AccessibilityDelegate.

In the Android SDK, AccessibilityService provides us with a series of event callbacks to help us indicate some state changes of the user interface. We can derive accessibility classes to handle different AccessibilityEvents. Let's see what event types are in AccessibilityEvent:

 /**
 * Represents the event of clicking on a {@linkandroid. view . View } like  
 * {@linkandroid.widget.Button}, {@linkandroid.widget.CompoundButton}, etc.
 */
 public   static final int TYPE_VIEW_CLICKED = 0x00000001; 
 
 /**
 * Represents the event of long clicking on a {@linkandroid. view . View } like  
 * {@linkandroid.widget.Button}, {@linkandroid.widget.CompoundButton}, etc.
 */
 public   static final int TYPE_VIEW_LONG_CLICKED = 0x00000002; 
 
 /**
 * Represents the event of selecting an item usually in the context of an
 * {@linkandroid.widget.AdapterView}.
 */
 public   static final int TYPE_VIEW_SELECTED = 0x00000004; 
 
 /**
 * Represents the event of setting input focus of a {@linkandroid. view . View }.
 */
 public   static final int TYPE_VIEW_FOCUSED = 0x00000008; 
 
 /**
 * Represents the event of changing the text of an {@linkandroid.widget.EditText}.
 */
 public   static final int TYPE_VIEW_TEXT_CHANGED = 0x00000010;
 ...

Take the click event TYPE_VIEW_CLICKED as an example. When the RootView of the Activity interface starts drawing (onGlobalLayout callback of ViewTreeObserver.OnGlobalLayoutListener), ViewVisitor will also start looking for the specified View and set a new AccessibilityDelegate for this View. Let's take a look at how this new View.AccessibilityDelegate is written:

 private class TrackingAccessibilityDelegateextends View .AccessibilityDelegate{
 ...
 public TrackingAccessibilityDelegate( View .AccessibilityDelegate realDelegate){
                mRealDelegate = realDelegate;
 } 
 
 public   View .AccessibilityDelegategetRealDelegate(){
 return mRealDelegate;
 } 
 
 ... 
             
 @Override
 public void sendAccessibilityEvent( View host, int eventType){
                if (eventType == mEventType) {
 fireEvent(host); // event reporting
 } 
 
                if ( null != mRealDelegate) {
                    mRealDelegate.sendAccessibilityEvent(host, eventType);
 }
 } 
 
            private View .AccessibilityDelegate mRealDelegate;
 }
 ...

You can see that an event report is sent in the TrackingAccessibilityDelegate#sendAccessibilityEvent method of the SDK.

So does View call the sendAccessibilityEvent method in its internal implementation of the click method? The View.performClick method is called when View handles the click event. Take a look at the source code:

 public boolean performClick(){
 final boolean result;
    final ListenerInfo li = mListenerInfo;
    if (li != null && li.mOnClickListener != null ) {
        playSoundEffect(SoundEffectConstants.CLICK);
        li.mOnClickListener.onClick(this);
 result = true ;
 } else {
 result = false ;
 }
    sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
 return result;
 }
 ...
 public void sendAccessibilityEvent( int eventType){
    if (mAccessibilityDelegate != null ) {
        mAccessibilityDelegate.sendAccessibilityEvent(this, eventType);
 } else {
        sendAccessibilityEventInternal(eventType);
 }
 }
 ...
 public void setAccessibilityDelegate(@Nullable AccessibilityDelegate delegate){
    mAccessibilityDelegate = delegate;
 }

From this we can see that when RootView starts drawing, registering AccessibilityDelegate for View can monitor its click events.

4.2 Difficulties and Problems of Visualizing Buried Points

The above briefly analyzes the basic implementation of Mixpanel and SensorsSDK visualization tracking. There is still a difficulty that needs to be carefully considered, that is, how to uniquely identify a View in the App? What information of the View needs to be recorded, how to generate a unique ID for the View, and ensure that these IDs are fixed on different mobile phones, and ensure that the ID does not change each time the App is started. At the same time, the ID must also be able to cope with a certain degree of interface adjustment.

In addition, I saw some netizens online saying that setAccessibilityDelegate can monitor View clicks for most manufacturers' models and versions, but some models cannot successfully capture and monitor click events. From the perspective of View identification generation and monitoring principles, there are some doubts about the stability of this solution.

4.3 References

• sensorsdata git, including multiple versions of SDK such as Android, iOS, js, JAVA, etc.: https://github.com/sensorsdata
• Mixpanel git, including multiple versions of SDKs such as Android, iOS, js, JAVA, etc.: https://github.com/mixpanel
• NetEase mobile data collection and analysis blog: http://www.jianshu.com/c/ee326e36f556

V. Conclusion

***Briefly summarize the advantages, disadvantages and usage scenarios of several solutions. In actual applications, multiple methods should be used in combination to balance efficiency and reliability. The best one is the one that suits your business.