论PAGELINK的必要性

通常来说，App内的PageLink机制有几个显著的优点值得我们去做：如，增加运营灵活性，页面开放性，利于效果追踪，反推模块间解耦，降低子工程间的依赖等。

客户端总有那么几个核心业务承接页面，是给用户展示信息的主场，也是运营活动、消息推送时的用户承接页。如微博的个人主页，手淘的商品/店铺详情，微信的公共账号主页等。通常我们会把它们开放给运营，甚至三方应用。这个时候，就轮到PageLink上场了。把页面定位进行URI规范化，由URI的分发中心接受URI并打开目标页页。运营同学在搞新活动的时候，可以通过URI来配置活动承接页，灵活控制跳转路径。

另外，我们也可以为每一次跳转赋予一个唯一ID，横向追踪每个运营活动的效果，如点击，转化率等。把整个活动数据化。

把页面进行URI规范化的同时，也反推了技术在开发时对页面之间的跳转进行解耦。因为只有入参简化，规范了，才能做到以URI中的Query做为输入，提供所需要的关键参数。

PageLink在使用过程中，我们还可以进行扩展，在跳转页面的基础上进一步加强为执行Action。如，播放页面声音，触发网络请求，打电话等。一切Action都由schema://host/action?queryKey=queryValue的形式来表示。将软件中的模块、服务进行解耦，划出界限，最终通过Action组织起来形成一个个的交互。

当我们的工程变得越来越大时，参与人员越来越多时，不可避免的要拆分成为不同的子工程，这个时候不同业务团队之间做直接的代码引用会很痛苦的，内耗和沟通成本都会直线上升。你能想象一个团队的人偶然修改了一个方法导致所有人都编译不了，然后每个都在开发群里骂街的情形么？

这里提两个实现细节方面的事。

一个是Action的数量随着App的版本在不断增加，这个需要做好版本管理，以及前向/后向兼容，避免出现稳定性问题。

另外，在queryKey和queryValue的定义上，最好使用有字面意义的字符来表示，要做到见文知义，不要把程序中的索引值拿出来用。假设我们在AppStore中定义了一个URI来表示，希望程序跳转到详情页时定位到第二个叫做“评论”Tab，那么query最好定义为subTab=comment，这样很容易明白的写法。如果你是使用方，一定不希望开发者定义成这样：subTab=2（表示第二个Tab），这样做一方面会让使用者不名所以，另一方面，当页面的信息结构重构时，如“评论”在某个新版本中变为第3个Tab了，你肯定能想象写代码会是多么痛苦。