iOS Statistics

[[148848]]

Statistics management is a very important part of App development. The running status of the App, the effect of the revision, and various user behaviors all need to be managed. There are also many third-party libraries available on the market. Suppose the product has such a requirement: when the user clicks the purchase button on the details page, record the event. We will probably implement it like this

 // DetailViewController.m   
 
 - ( void )onBuyButtonTapped:(UIButton *)button
 {
 // do some stuff, maybe send a request to server  
 [XXXAnalytics event:kSomeEventYouDefined];
 }

This requirement was easily met, but if you think about it carefully, there are still many problems:

There will be other buttons on the page, and each button may need to have this piece of code.

These statistics are actually irrelevant to the specific business, and there is no need to mix them with the business code, which is not elegant.

When revising or refactoring, you may forget to migrate the corresponding management code.

So we need a better way to do this, which is to use AOP (Aspect-Oriented-Programming), which translates to "Aspect-Oriented Programming"

A technology that uses precompilation and runtime dynamic proxy to dynamically and uniformly add functions to a program without modifying the source code.

In simple terms, it is possible to dynamically insert a piece of code before and after a function call. iOS can use the Aspects library developed by Pete Steinberger, which is roughly implemented at the runtime layer through the swizzle method.

Let's take a look at a small demo

 [UIViewController aspect_hookSelector: @selector (viewWillAppear:) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) {
 NSLog(@ "View Controller %@ will appear animated: %tu" , aspectInfo.instance, animated);
 } error:NULL];

In this way, after UIViewController's viewWillAppear: is called, the Block we defined will be called again, and this log will be output. And the management is just right for this scenario: after finishing the main work, do some extra things that are not related to the business.

In the above example, if we use AOP to do it, it would be like this

 // DetailViewController.m  
 - ( void )onBuyButtonTapped:(UIButton *)button
 {
 // do some stuff, maybe send a request to server  
 // no need to call [XXXAnalytics event:]  
 } 
 
 // AppDelegate.m  
 - ( void )setupAnalytics
 {
 [DetailViewController aspect_hookSelector: @selector (onBuyButtonTapped:) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) {
 [XXXAnalytics event:kSomeEventYouDefined];
 } error:NULL];
 }

In this way, the statistics code is separated from the business code. But a new problem arises. If there are multiple Button Events, wouldn’t it be necessary to write many lines of such code? How can a programmer tolerate such "repetition"? Simply create a method

 - ( void )trackEventWithClass:(Class)klass selector:(SEL)selector event:(NSString *)event
 {
 [klass aspect_hookSelector: @selector (selector) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) {
 [XXXAnalytics event:event];
 } error:NULL];
 }

It is used like this

 - ( void )setupAnalytics
 {
 [self trackEventWithClass:DetailViewController selector: @seletor (onBuyButtonTapped:) event:kSomeEventYouDefined];
 [self trackEventWithClass:ListViewController selector: @seletor (followButtonTapped:) event:kAnotherEventYouDefined];
 // ...  
 }

It looks cleaner. At this time, the product manager put forward another requirement: when this button is clicked, if you are logged in, send EventA, if you are not logged in, send EventB. In other words, it is no longer as simple as [XXXAnalytics event:], and additional logic needs to be added. This is not difficult for us, just add a block.

 - ( void )trackEventWithClass:(Class)klass
 selector:(SEL)selector
 eventHandler:( void (^)(idaspectInfo))eventHandler
 {
 [klass aspect_hookSelector: @selector (selector) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) {
 if (eventHandler) {
 eventHandler(aspectInfo);
 }
 } error:NULL];
 } 
 
 // use  
 [self trackEventWithClass:DetailViewController selector: @seletor (onBuyButtonTapped:) eventHandler:^(idaspectInfo){
 user.loggedIn ? [XXXAnalytics event:EventA] : [XXXAnalytics event:EventB];
 }];

Well, now we can handle any logic that is not too complicated (those that require method context variables), and the next step is to wait for the product to accept it. The product moved a stool and sat next to him, then clicked a button and looked at the Console. After being abused for a few rounds, the product slowly accepted this acceptance method. Later one day, it was suddenly discovered that one or several data items were abnormal, and then found the developer and took a look: Oh, this method has been refactored. Or the newly added method forgot to add statistics. It can only be added in the next version. If it is just general statistical data, it is okay, but it is troublesome if it is related to money.

Is there an intuitive way to verify this? Of course, programmers are the best. An ideal situation is that after the product opens the App, turning on a switch, you can see all the buttons that will send events, like this

The number represents the EventID. How to implement it? Remember when registering an event, we passed in the class and selector. Generally, we have a BaseViewController, so we can do something in the viewDidAppear: of the BaseViewController.

 // BaseViewController.m  
 - ( void )viewDidAppear:(BOOL)animated
 {
 [ super viewDidAppear:animated];
 // Get the registered classes  
 NSDictionary *registeredClasses = [OurAnalytics sharedInstance].registeredClasses; 
 
 [registeredClasses enumerateKeysAndObjectsUsingBlock:^(NSString *className, NSArray *selectors, BOOL *stop) {
 if ([self isKindOfClass:NSClassFromString(className)]) {
 // How to find its host based on the selector?  
 }
 }];
 }

So now the only question left is how to find the corresponding Button based on the selector. Please note that some Buttons may not appear until the network request is completed, such as the Button in TableViewCell.

I can't think of a very convenient method. The simple and crude one is to set a Timer to scan the subviews at regular intervals. If it is a button or contains a tapGesture, compare their actions. If there is a match, you can highlight the button/view.

The same goes for EventID. When registering, an EventID will be passed. You can just display it here. This does not work for those that pass eventHandler.

So theoretically it is feasible, there will be a slight performance loss, especially when the structure of subViews is complex, but it is only used internally for verification, so this is not a problem.

It seems that the effect is good. Is it possible to make this system more flexible? For example, can we set the management rules from the backend? The client just reads a configuration file, like this

 - ( void )setupAnalytics
 {
 // analyticsRules are read from the configuration file  
 [analyticsRules enumerateObjectsUsingBlock:^(NSDictionary *rules, NSUInteger idx, BOOL *stop) {
 Class klass = NSClassFromString(rules[@ "class" ]);
 SEL selector = NSSelectorFromString(rules[@ "selector" ]);
 NSString *eventID = rules[@ "eventID" ];
 [self trackEventWithClass:klass seletor:seletor event: eventID];
 }];
 }

What if you fill in the wrong Class or Selector in the background? Fortunately, there are two runtime methods, objc_getClassList and class_copyMethodList. With them, you can scan the registered classes (filter out those starting with UI / NS) when the App starts, and then save their selectors and send them to the server. Of course, this operation only needs to be done at the appropriate time, such as when integrating and packaging.

Now, this system is relatively complete. Of course, these are just some of my ideas, and I haven't tried them in practice, so there will definitely be various pitfalls, but at least it seems to be a feasible solution.