查看原文
其他

安卓应用跳转回流的统一和复用

鸿洋
2024-12-13

The following article is from 搜狐技术产品 Author 狐友陈金凤

作为一个功能复杂的应用,无法避免地需要支持众多路径的回流,比如从Launcher、从Push通知、从端外H5、从合作第三方App以及从系统资源分享组件等。

我们知道,不同的回流路径会通过App的不同入口,带着不同的参数打开应用。而应用需要根据不同的回流路径,及其参数要求,跳转到目标页面,并完成完成相应的操作。在跳转到目标页面时,回流过程往往会被启动页、登入页、新手引导、升级、主页等条件检测和页面中断,导致无法顺利地完成目标页面的跳转和相应的操作。整个回流过程如果不统一设计,代码会因为涉及的回流入口多,回流操作多,回流中断多,以及业务需求地不断增加和变更,变得复杂且高耦合。所以,接下来我们就从端外回流过程面临的4个问题,来一步步进行方案设计:
  1. 如何解决所有回流入口传入的数据,放到同一个处理入口,方便后续回流的统一管理?
  2. 如何约定一套回流协议,让所有回流入口的相似需求,可以复用页面跳转和控制实现?
  3. 如何支持回流过程中的条件检测,以及检测中断后的回流恢复?
  4. 如何融合回流的复用设计和中断恢复设计?

1回流入口统一


常见业务回流场景

为了更好地理解应用的端外回流的具体业务场景,我用社交应用的回流场景为例说明一下:从图中我们可以大致了解到几个业务常见的回流流程:
  1. 用户从桌面Launcher打开应用,经过Splash页,最后进入应用MainPage主页;
  2. 用户通过端外H5页,下载安装,并打开App。通过启动页后,先登入,再进行个人信息设置、喜好设置、推荐好友、应用MainPage页,最后进入用户主页,或H5活动页等;
  3. 用户通过点击系统通知栏的Push通知,打开应用并跳转到Push指定页,如,用户主页、H5活动页、Feed详情页等;
  4. 用户浏览器中的端外H5分享页,直接进入到应用内的用户主页,Feed详情页等;
  5. 用户从第三方App,通过分享ShareSDK,分享Url和图片到应用中,进入到Feed发布页;
  6. 用户从系统分享组件中,分享URL网页到Feed发布页。

统一回流处理入口

上面举例的这么多回流入口,能不能都统一到一个入口去处理呢?这是我们统一回流方案首先要解决的问题。除了系统分享组件回流入口外,其它回流入口,只要和各合作方协商约定好,都是可以通过 sohuhy://xxx 形式的URL Scheme 请求,跳转到App里的。这样,我们可以将所有回流入口都通过这种形式统一到一个Acitivity去处理,比如我们把这个唯一入口命名为ActionActivity,那我们的入口应该像这段代码显示的这样去处理:

<activity android:name=".ActionActivity">
    <intent-filter> 
      <action android:name="android.intent.action.SEND" />
      <category android:name="android.intent.category.DEFAULT" />
      <data android:mimeType="text/plain" />
    </intent-filter>
    <intent-filter>
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data
        android:host="*"
        android:scheme="http" />

      <data
        android:host="*"
        android:scheme="https" />

    </intent-filter>
    <intent-filter>
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.BROWSABLE" />
      <category android:name="android.intent.category.DEFAULT" />
      <data android:scheme="sohuhy" />
    </intent-filter>
</activity>

你可以看到,通过ActionActivity,我们能接受系统分享组件入口过来的分享,也可以接受给浏览器发送的URL网页分享,还能支持所有通过sohuhy这个Scheme启动的隐式调用。

我们的Push通知,端外H5,集成ShareSDK的三方应用,都可以通过改用Scheme隐式调用的方式回流到应用里。按照上面的代码配置后,ActionActivity就可以统一处理所有回流入口的数据了,统一处理应该像这段代码显示的这样去处理:

public class ActionActivity extends BaseActivity {
    private void dispatchIntent() {
      mIntent = getIntent();//获取入口数据

      if (Intent.ACTION_SEND.equals(mIntent.getAction()))  {
        matchShare();//如果数据来自Send入口,则进入分享处理逻辑
      } else {
        String scheme = mIntent.getData().getScheme();
        //如果数据来自View入口,则区分scheme进行处理
        if (scheme != null && scheme.startsWith("http"))  {
          matchShare();//如果数据来自http网页分享,则进入分享处理逻辑
        } else {
          matchProtocol();//如果数据来自sohuhy内部定义回流,则进入内部处理逻辑
        }   
      }
   }
}

2回流复用


统一回流入口后,我们就可以对回流进行统一管理了。回流下一个需要解决的问题就是:不同的回流入口有很多非常相似的页面跳转和操作需求,如果各自实现会导致大量代码冗余,耦合高,容易互相影响。所以我们继续来考虑如何设计回流的复用。

回流处理的相似性

为了更好理解不同回流入口中相似页面跳转和操作场景,我用社交应用中内容分享的场景举例说明:用户通过系统分享控件和浏览器入口,最终都需要把网页分享到应用中。而通过ShareSDK进行分享的第三方应用,也需要把网页、图片分享到应用中。那这三个分享场景的回流非常相似,我们就应该要考虑复用设计了。还有在活动场景回流中,我们通过Push通知、端外H5页面、端内广告、端内运营私信,都有进入到特定活动页、用户主页、Feed详情页等的需求。那么这些相似的页面跳转以及跳转后的操作逻辑,应该如何考虑复用呢?我们可以在方法级别复用,但更好的方法是在协议级别复用,通过约定一套回流协议,在回流的入口处,就开始解耦入口,并完全复用各种跳转和控制逻辑。在统一回流处理入口这个阶段,我们已经把大多数回流入口,统一成通过 sohuhy://xxx 形式的URL Scheme 请求,跳转到App里,所以,我们可以约定所有回流协议头为"sohuhy",然后将其它系统回流入口的数据,也转换为回流协议的格式,再由回流协议模块进行统一处理。

回流协议定义

而关于回流协议定义,我们遵守了标准的URL格式规范,格式是这样的:scheme://host/path?param1=1&param2=2使用熟悉的协议规范,可以减少团队学习和使用成本。URL格式作为回流协议,我们需要做一些内部约定,比如这张表格中列出的:有了协议规范,我们就可以根据业务需求,定义功能path和params了。我们以唤起应用、打开H5页和分享举例,就可以设计这样的协议:你可以看到, *type=1代表的是,在type=1时,这个字段是必选字段,而type!=1时,这个字段是不需要的。你也能够看到,功能可以通过path信息进行很好的区分,mainPage,browser,shareToNative的命名也能很好表达回流的功能。唤起客户端,属于最基本的回流功能,只需要知道scheme和host,不需要path。对于简单的页面跳转,如跳转到主页,只需要定义path,不需要定义任何参数。对于其它复杂的回流功能,就需要根据业务需求,定义相应的参数键、参数类型、参数是否必选,以及参数枚举值等。比如说内容分享shareToNative协议,分享支持的类型有两种,这两种类型需要的相应参数是不同的。所有我们定义参数type的枚举值:1-网页,2-图片,同时通过*type=1的方式,约定网页标题和URL是网页类型的必选字段。对于通过系统Send控件分享过来的网页和图片,及浏览器分享过来的网页,我们可以在回流入口ActionActivity的matchShare()方法里,将参数映射到shareToNative协议,然后在通过shareToNative协议的实现模块对内容分享进行统一处理。

回流协议实现

协议定义好了,接下来我们一起来看回流协议如何实现。首先我们的目标是低耦合设计,不同协议的处理是完全隔离的,采用Dispatch派发模式来实现设计需求。首先我们定义协议和处理协议的分发配置类ProtocolConfig:
public class BaseProtocolDispatcher implements Serializable {
    //所有协议处理类的基类,
    public void execute() {
    }
}


public class ProtocolConfig // 所有协议处理类的基类,
    public static final String SCHEME = "sohuhy";//协议scheme
    public static final String HOST = "w.sohu.com";//协议host
    //协议path
    public static final String ACTION_MAINPAGE = "mainPage";
    public static final String ACTION_BROWSER = "browser";
    public static final String ACTION_SHARE_TO_NATIVE = "shareToNative";
    ......
    private static final Map<String, Class> ACTION_MAP_NEW = new HashMap<>();

    static {//协议-协议派发器 Map初始化
        ACTION_MAP_NEW.put(ACTION_MAINPAGE, OpenMainPageDispatcher
.class);
        ACTION_MAP_NEW.put(ACTION_BROWSER, OpenBrowserDispatcher.class);
       ACTION_MAP_NEW.put(ACTION_SHARE_TO_NATIVE, ShareFeedDispatcher
.class);
        ......
    }

    public static Map.Entry<String, Class> getMatchResult(String url)         { //根据协议url 获取 协议派发器
    ......
    Uri uri = Uri.parse(url);
    String scheme = uri.getScheme();//根据协议url 解释出scheme
    if (!SCHEME.equals(scheme)) {
        return null;
    }
    String host = uri.getHost();//根据协议url 解释出host
    if (!HOST.equals(host)) {
        return null;
    }
    List<String> pathList = uri.getPathSegments();
    if (pathList != null && pathList.size() == 1) {
        path = pathList.get(0);//根据协议url 解释出path, 只支持一级path
    }     
    ......
    for (Map.Entry<String, Class> entry : ACTION_MAP_NEW.entrySet()) {
        try {
            String key = entry.getKey();
            if (path.equals(key)) return entry;//遍历Map,返回对应派发器
        } catch (Exception e) {
            e.printStackTrace();
            continue;
        }
    }
    return null;
}


所有回流协议处理类继承自BaseProtocolDispatcher,可以通过excute方法处理回流。每个回流协议都会被分配给一个相应的Dispatcher处理,比如shareToNative协议会被分派给ShareFeedDispatcher类进行处理。通过静态变量ACTION_MAP_NEW保证协议配置独一份,通过getMatchResult可以根据协议url获取到相应的协议处理类。接下来我们来实现协议到处理类的转换过程:
public class ProtocolExecutor {//回流协议分发给协议处理类
    public static boolean execute(String protocolUrl) {
        try {
            final Map.Entry<String, Class> result = ProtocolConfig.getMatchResult(protocolUrl);//获取匹配的协议处理类
            if (result != null) {
              final Class clazz = result.getValue();
              ProtocolBaseDispatcher dispatcher = null;
              try {
                dispatcher = (ProtocolBaseDispatcher) clazz.newInstance();//通过反射得到协议处理对象
              } catch (Exception e) {
              }


              Uri uri = Uri.parse(protocolUrl);
              fillFields(dispatcher, clazz, uri);//通过反射将协议参数填充到对应变量中
              dispatcher.execute();//执行协议处理类
              return true;
            } else {
                //对于不识别协议path,说明是新增的回流协议,做升级提示
                //对于空协议path,应用已经被系统唤起,不需要额外处理,直接退出
                return true
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return false;
    }
}


// OpenBrowser协议对应的处理实现类
public class OpenBrowserDispatcher extends BaseProtocolDispatcher {
    public String url;//会通过反射将协议参数赋值到实例对象中
    public int fullScreen;//会通过反射将协议参数赋值到实例对象中

    @Override
    public void execute() {//协议处理实现方法
        super.execute(url);
        //通过WebView打开端外H5页面
        ActivityModel.toNewWebViewActivity(mContext, url, fullScreen);
    }
}


//ActionActivity统一入口中调用协议处理模块
public class ActionActivity extends BaseActivity {
    private void matchProtocol()() {
       mProtocolUrl = mIntent.getData();//获取协议串
       ProtocolExecutor.excute(mProtocolUrl.toString());//协议处理
   }
}


协议派发中,我们主要处理了这几个事:
  1. 通过ProtocolConfig查找对应的协议处理类,并通过反射实例化对象;
  2. 通过反射,将协议中参数值赋值到协议处理对象对应的变量中;
  3. 调用处理类的处理流程,处理类根据协议要求执行相应操作,如跳转到新的H5活动页,进行内容分享、打开用户主页进行关注等。

通过将协议protocolUrl,映射到处理类及其成员变量,就很好地实现了回流协议的分发,达到了我们低耦合高内聚的协议隔离,和回流复用的设计目标。

3回流中段恢复

回流的条件检测场景

在应用的回流过程中往往需要进行一些条件检测,比如,需要强制登入,需要强制升级等场景。为了让你更好地理解回流条件检测具体是个什么样的业务,我用社交应用的回流中断场景举例说明。你可以看到,端外回流进入到App的用户主页,需要经过登入、用户信息设置、兴趣选择、推荐用户、升级检测这5个条件检测。条件检测通过后会直接进入下一个条件检测,否则会中断检测进入相应条件设置界面。

回流的中断恢复设计

我们观察上面的回流条件检测场景,可以发现这种流线式的条件检测,特别像一个节点链。我们可以采用责任链的模式进行处理。也就是说每个节点负责一个条件的检测,只有上一个条件检测通过后才会继续下一个条件检测。我们用Checker来表示一个检测点,可以按如下代码进行处理:
public class BaseChecker implements Parcelable {//检测节点基础类
    //执行回流条件检测,子类需要重写此类
    protected void dispatch() {
    }

    //Checker检测执行入口
    public void execute(){
        dispatch();
    }
}


public class UpgradeChecker extends BaseChecker{//升级检测节点
    @Override
    protected void dispatch() {
        if (UpGradeManager.getInstance().shouldShowUpdate()) {//如果用户需要强制升级,则跳转到升级页面
            UpGradeManager.getInstance().update(mContext, info.mData);
        } else {//否则,则进入最后一个检测节点BaseChecker
            super.dispatch();
        }
    }
}


public class RecommendUserChecker extends UpgradeChecker{//推荐检测节点
    @Override
    protected void dispatch() {
        int guidPage = SPUtil.getInstance().getInt(GuideStep.getGuideKey(), GuideStep.GUIDE_UNDEFINE);
        if (guidPage > GuideStep.GUIDE_CLOUDTAG) {//如果用户已经完成推荐关注,则进入下一个检测节点UpgradeChecker
            super.dispatch();
        } else {// 否则,跳转到推荐关注页
            ActivityModel.toRecommendUserActivity(params);
       }
    }
}


public class CloudTagChecker extends RecommendChecker{//兴趣标签检测节点
    @Override
    protected void dispatch() {
           int guidPage = SPUtil.getInstance().getInt(GuideStep.getGuideKey(), GuideStep.GUIDE_UNDEFINE);
        if (guidPage > GuideStep.GUIDE_CLOUDTAG) {//如果用户已经完成标签选择,则进入下一个检测节点RecommendChecker
            super.dispatch();
        } else {// 否则,跳转到标签选择页
            ActivityModel.toCloudTagActivity(params);
        }
    }
}


public class NewUserGuideChecker extends CloudTagChecker{//新用户资料检测节点
    @Override
    protected void dispatch() {
        int guidPage = SPUtil.getInstance().getInt(GuideStep.getGuideKey(), GuideStep.GUIDE_UNDEFINE);
        if (guidPage > GuideStep.GUIDE_NEWUSERGUIDE) {//如果用户已经完成资料设置,则进入下一个检测节点CloudTagChecker
            super.dispatch();
        } else {//否则,跳转到资料设置页
            ActivityModel.toNewUserGuideActivity(params);
        }
    }
}


public class LoginChecker extends NewUserGuideChecker {//登入检测节点
    @Override
    protected void dispatch() {
        if (UserModel.getInstance().isLogin()) {//如果用户已经登入,则进入下一个检测节点NewUserGuideChecker
            super.dispatch();
        } else {// 否则,跳转到登入界面
            ActivityModel.toLoginActivity(params);
        }
    }
}


public class SplashChecker extends LoginChecker{//启动页检测节点
    @Override
    protected void dispatch() {
        if (!HyApp.getIsAppShow()) {//如果应用没有显示,先展示启动页
            ActivityModel.toSplashActivity(params);
        }else{//否则,继续下一个检测节点LoginChecker的条件检测
            super.dispatch();
        }
    }
}


public class ActionActivity extends BaseActivity{//回流入口
    @Override
    protected void matchProtocol() {//启动第一个检测点SplashChecker
        new SplashChecker().execute();
    }
}


这个方案通过继承的方式实现了条件检测链。如果条件符合,就通过super.dispatch()进入下一个条件检测;如果条件不符合,就跳转到对应页面,引导用户操作。在条件检测链中某节点条件检测不满足时,会跳转到别的页面引导用户操作,这就会导致回流中断。当用户操作完,节点条件检测通过后,应该要恢复原来的条件检测流程。这种情况,涉及到界面之间的跳转和参数传递,考虑到Activity不是应用内部实例化的,我们可以通过加一层特殊功能Activity基类来进行条件检测中断点的保存,和回流协议的保存和恢复。我们以SplashChecker、LoginChecker为例,中断点的保存和恢复,可以像这段代码显示的这样去处理:
public class CheckerActivity extends BaseActivity{//条件检测界面基类
    private BaseChecker restoreChecker; //待回复检测点
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        //存储待回复检测点
        restoreChecker = (BaseChecker)getIntent().getParcelableExtra(BaseChecker.KEY_CHECKER);
    }


    protected void restoreChecker() {//恢复下一个检测点
        if(restoreChecker != null) {
          restoreChecker.execute();
          return true;
        } 
        return false;    
    }
}


public class SplashActivity extends CheckerActivity{
    private void toNextActivity() {//Splash展示完成后,优先恢复检测点
        if(restoreChecker()){
          finish();
        } else {//没有需要恢复的检测点,直接进入到应用主页
          ActivityModel.toMainPageActivity(params);
       }
    }
}


public class SplashChecker extends LoginChecker{
    @Override
    protected void dispatch() {
        if (!HyApp.getIsAppShow()) {//开屏页导致流程中断时,把登入检测点传给Splash页面
            params.putParcelableExtra(BaseChecker.KEY_CHECKER, new LoginChecker.setUri(mProtocolUri));
            ActivityModel.toSplashActivity(params);
        }else{
            super.dispatch();
        }
  }


public class LoginActivity extends CheckerActivity{
    private void loginSuccess() {//登入成功后,优先恢复下一个检测点
        if(restoreChecker()){
          finish();
        } else {//没有需要恢复的检测点,直接进入到应用主页
          ActivityModel.toMainPageActivity(params);
       }
    }
}


public class LoginChecker extends NewUserGuideChecker {
    @Override
    protected void dispatch() {
        if (UserModel.getInstance().isLogin()) {
            super.dispatch();
        } else {//登入导致流程中断时,把新用户资料检测点传给Login页面
            params.putParcelableExtra(BaseChecker.KEY_CHECKER, this)
            ActivityModel.toLoginActivity(params);
        }
    }
}


这里当Checker出现检测不通过中断检测流程时,我们会通过intent的方式,把当前检测点Checker传给中断页面。中断页面则通过父类CheckerActivity,自动存储检测点Checker的实例。当中断页面完成业务流程后,会先调用restoreChecker看是否需要恢复条件检测链。如果需要,则直接销毁界面,后续流程交给Checker处理。否则,中断页面继续根据业务需求进行跳转。

回流中断恢复设计和复用设计的融合

回流时的条件检测都通过后,我们需要继续进行回流的目标页跳转和相应操作,这就需要我们把回流中断恢复设计和复用设计很好地融合起来。我们可以利用中断检测的基类BaseChecker来保存回流协议,以及恢复协议执行,如下代码所示:
public class BaseChecker implements Parcelable {//检测节点基础类
    //用于Intent传递Checker的key定义
    public static final String KEY_CHECKER = "key_checker";
    //检测完后,需要恢复执行的回流协议
    protected Uri mProtocolUri;


    public Dispatcher setUri(Uri protocolUri) {//保存需要恢复执行的回流协议
        mProtocolUri = protocolUri;
        return this;
    }

    //BaseChecker作为最后一个节点, 用来负责恢复执行回流协议
    protected void dispatch() {
        String protocolUrl = mProtocolUri.toString();
        ProtocolExecutor.excute(protocolUrl);//衔接上回流复用设计
    }
}


public class ActionActivity extends BaseActivity{//回流入口
    @Override
    protected void matchProtocol() {//启动第一个检测点SplashChecker,并传递后续要恢复的回流协议mProtocolUri用于后续恢复
        new SplashChecker().setUri(mProtocolUri).execute();
  }
}


首先在ActionActivity回流入口处理中,把mProtocolUri传递给条件检测Checker,然后执行execute启动检测链。如果所有检测条件都检测通过,会调到BaseChecker中的dispatch方法,它则通过ProtocolExecutor.excute 恢复回流协议的后续流程。

完成条件检测链和中断回流恢复的设计,我们页就完成回流的整体方案设计。

4总结


最后我们一起来总结一下整个回流方案的设计。图中灰色底块表示端外回流入口,绿色底块和线,表示有继承关系。整个设计的6个关键信息如下:
  1. 整个方案通过ActionActivity对端外回流入口的进行统一处理;
  2. 通过定义一套合理的跳转协议,为不同回流入口相似功能的复用,建立一个基石;
  3. 采用协议解释器ProtocolExecutor,和Dispatch派发模式实现不同协议的解耦处理;
  4. 当需要条件检测时,通过继承方式的责任链模式,串联众多的条件检测;
  5. 使用CheckerActivity作为各中断界面的基类,处理下一检测节点的保存与恢复;
  6. 检测链检测通过后,通过检测基类BaseChecker对回流协议进行存储和恢复,最后通过协议解释器ProtocolExecutor对回流协议进行分发和逻辑处理。
这个方案基本解决了回流过程中入口和处理分散、逻辑耦合高、冗余代码多的问题,它把整个回流阶段进行三段划分,不同阶段采用恰当的模式对逻辑进行解耦。后续,我们又把Shortcut、DeepLink等跳转方式也融入到这一套回流方案中,让Shortcut和DeepLink也能快速拥有现有回流协议支持的所有功能。除了端外回流,我们的端内H5,私信,消息,活动入口也都在复用这套回流方案,来实现H5和服务端对客户端页面跳转和操作的控制。端内跳转不需要考虑应用启动过程的条件检测Checker,可以直接调用协议解释器ProtocolExecutor。这减少了多端交互混乱繁杂的开发工作,也让回流方案发挥出更大的价值。而且如果你的项目已经有很多旧业务的回流入口和处理逻辑,仍然可以考虑对它们进行兼容。通过将旧回流入口统一转发到这套新回流入口中,将不同的协议先转换为新回流协议,就达到了复用一套处理逻辑。


最后推荐一下我做的网站,玩Android: wanandroid.com ,包含详尽的知识体系、好用的工具,还有本公众号文章合集,欢迎体验和收藏!


推荐阅读

一文搞懂Window、PhoneWindow、DercorView、WindowManager
一个大型 Android 项目的模块划分哲学
细嗅蔷薇,Gradle 系列之 Task 必知必会


扫一扫 关注我的公众号

如果你想要跟大家分享你的文章,欢迎投稿~


┏(^0^)┛明天见!

继续滑动看下一个
鸿洋
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存