I was trying to figure out how does A/B testing SDK replace assets when sent from the Server by just including one line of Code. I know this can be done by sub classing various UI elements, but that will require a lot of code modification.
I'm the lead Android engineer at Taplytics. We do exactly what you're talking about!
At the core, its actually pretty straightforward. Obviously I can't go into full details on what magic we're doing, but I can give you a general idea!
First off, if you are the one building these A/B tests, I definitely recommend you subclass your UI elements. Doing this is far faster than other solutions, because it’s your code running when you want it to (I'll explain this later). The easiest way would be to subclass View and work from there.
The tech behind A/B testing is the same as pretty much any information you get from a server and present to a user. There really is no difference.
Now, to address your 'one line of code' comment, well, there's the secret sauce. On iOS, those devs are lucky enough to have method swizzling in which they can literally see when a method is being called and replace it with their own stuff. That makes things relatively easy!
But for Android? Well, no such luck. Take a look at the input params for every single A/B testing / Analytics platform on Android: Foo.start(AppContext, "apiKey");
The magic is in the AppContext. Appcontext is essentially an interface into Android itself. It’s what makes it Android instead of just Java. AppContext has information about everything: What activities are running, when they are running, what intents are being passed around, pretty much everything. With the AppContext in hand, you have a lot of control and information about the Application.
From there, you basically build an AppContext tree. Every little bit of information you need from the app just branches off AppContext. AppContext -> Activities -> Views. AppContext -> Activites -> Views -> Fragments -> Fragment Views. AppContext -> Services -> Push. Mixpanel actually calls this 'ViewCrawling' in their solution, which may give you a better mental visualization of what is going on.
You just create this big winding tree with branches reaching into every little aspect of the app so when you want to make a change to something, you are able to find it in your tree! Once you have what you want, you just grab the info from the server (or a local cache), be it JSON or XML or whatever and make the change you need based on that information.
But like I said previously, use your own UI elements. It's far easier on you to just determine what needs to change before even drawing the element. Especially if you subclass View, you shouldn't need a lot of code at all. The One-line installation is pure convenience and makes everything for me (the SDK dev) a lot harder. But I can't go and ask people to change every single view in their app to be a subclass of my own things, can I?
So there it is. It requires an intense knowledge of Android's SDK to be able to crawl into every aspect of it as necessary. The idea is simple, but deeper executions get incredibly complex.
I'm open to any questions! Thats a real rough overview of it all, and it gets more complex, so ask away.
In fact, my experience with A/B testing was using Google Tag Manager, that helps me to manage a "dynamic bundle". Having this bundle inside my app, I inflate layouts, colorize elements and so according with the values provided by this bundle. Take a look at GTM docs and I'm certain you'll find something useful.
As an example, the company Leanplum offers a Visual Interface Editor for iOS and Android: This requires no coding, and Leanplum will automatically detect the elements and allow you to change them. No engineers or app store resubmissions required.
I am an engineer at Leanplum; hence let me give you a little bit more insight about it:
- With installing the iOS or Android SDK in your app, you enable a feature called Visual Editor. While in development mode and with the Website Dashboard open, the SDK sends information about the view hierarchy in real-time to your Browser. The view hierarchy is scanned in a similar way a DOM is built on a regular website.
- You can choose any UI element on your app and change the appearance of it in real-time. This works by identifying the exact element in the view tree and sending the changes to the SDK.
- This can be achieved by adding custom hooks or a technique called "swizzling". Take a look at this blog post, how it works.
To learn more about the Leanplum Visual Interface Editor, check out leanplum.com. They offer a free 30-day trial.
来源：https://stackoverflow.com/questions/29063568/android-how-do-a-b-testing-platforms-modify-assets-on-the-fly