弹窗

1. 前言在 App 的经营流动中，对用户进行弹窗提醒，是一种常见的经营形式。例如：用户曾经下单但未付款的时候，能够给用户一个优惠券的弹窗提醒。 神策 Android 弹窗 SDK[1] 次要针对的就是上述经营场景，经营人员能够在神策智能经营中配置弹窗的 UI 以及触发弹窗的一些条件，当用户满足配置的条件时，集成了弹窗 SDK 的 App 会展现弹窗。UI 成果如图 1-1 所示： 图 1-1 弹窗 UI 效果图 2. 弹窗的实时性在很多场景下，弹窗须要很高的实时性。如果弹窗的计算规定通过后端解决，符合条件时再下发给客户端，实时性将得不到保障。 为了解决这一问题，把计算逻辑等放在了客户端。简略来说，就是触发埋点事件之后会判断是否触发弹窗。 此外，弹窗 SDK 为了保障实时性，也做了很多工作，上面就逐个为大家进行介绍。 3. 计划演进3.1. 计划一：共用埋点数据采集线程触发弹窗的机会，取决于经营同学在神策智能经营中的配置，那弹窗 SDK 如何来决定是否弹窗呢？ 举个例子，经营同学的配置条件是：有商品页面的浏览数据就弹窗。因而，在 App 端监控到有商品页面浏览的埋点数据产生就会弹窗。 埋点数据采集工作是在埋点数据采集线程中执行的。因而，最后的想法是在埋点数据采集线程中监控埋点数据，如果有合乎弹窗条件的数据，那么就展现弹窗。示例代码如下： //判断是否弹窗PlanManager.ensureShowDialog(data);//数据缓存到数据库enqueueEventMessage(data);这种做法很简略，也能满足需要。它的长处如下： 从代码上来看，逻辑比拟清晰；判断是否弹窗和埋点数据采集都是在一个线程，不便保护。然而，它的毛病也很显著： 如果在判断是否弹窗这一步，有阻塞或者异样，那么会影响埋点数据缓存到数据库；耦合度十分高。当初是弹窗的业务须要监控数据，如果未来其余业务也须要监控数据，那么在埋点数据缓存之前，还须要减少更多的业务逻辑。为了解决上述问题，咱们拆分了埋点数据采集线程和弹窗判断线程。 3.2. 计划二：拆分埋点数据采集线程和弹窗判断线程思考到共用埋点数据采集线程的毛病，咱们做了线程的拆分，如图 3-1 所示：图 3-1 线程拆分示意图 此时，埋点数据采集线程和弹窗判断线程，是两个独立的线程。当埋点数据采集线程有新的数据时，会被动告诉弹窗判断线程，让其解决弹窗业务。 这样做不仅升高了耦合度，并且弹窗业务不会影响到埋点数据采集。即便最极其的状况，比方弹窗判断线程因为某些起因呈现了异样，埋点数据采集线程依然能失常工作。 埋点数据采集线程只须要依据接口，回调给数据接收端就行，示例代码如下： // 监控数据，并传给注册接口的中央DataMonitorInterface.trackEvent(data);// 数据缓存到数据库mMessages.enqueueEventMessage(eventType.getEventType(), dataObj);在弹窗判断线程中，收到数据后会缓存在队列，示例代码如下： public class SFDataMonitorImpl{ public void trackEvent(String data){ mSFPlanTaskManager.addTriggerTask(new Runnable() { //判断是否弹窗 PlanManager.ensureShowDialog(data) } }}在新的线程中去执行此队列的工作，示例代码如下： public class SFPlanTriggerRunnable implements Runnable { @Override public void run() { Runnable downloadTask = mSFPlanTaskManager.getTriggerTask(); mPool.execute(downloadTask); }}这种计划看上去曾经很完满了，升高了埋点数据缓存和弹窗业务之间的耦合，并且代码上也做了拆分，相互之间的影响很小，同时也能满足各种业务场景。 ...