您当前的位置: 前面有一篇博客说到了淘宝UWP的"四核驱动的三维导航—淘宝新UI（需求分析篇）"，花了两周的时间实现了这个框架，然后又陆陆续续用了三周的时间完善它。
多窗口导航，与传统的导航方式的最大的不同点是：
- 需要指定目标窗口（target Frame）
- 维护上下文关系（context）
- Back Stack的维护
- 页面间的异步通信
- 适配Desktop和Mobile界面
- 支持Continuum（optional）
本篇博客先说一下前三个问题如何解决。
在从页面A跳到页面B时，单窗口模式下，很简单，只要在页面A中调用系统方法就可以了：
this.Frame.NavigateTo(typeof (PageB));
因为页面A使用的Frame和页面B使用的Frame相同。但是在多窗口（多Frame）时，你需要指定页面B使用那个Frame作为目标窗口。
比如，淘宝首页：
在点击了"淘抢购"频道的入口后，你想在什么地方显示淘抢购的主页面呢？在目前的Taobao UWP中，我们选择在主页的右侧显示（但是考虑到淘抢购的使用频率，我们可能会考虑在下一版中把它作为一个独立的Scenario来对待，也就是说可能要在目前的主页的位置显示）。于是，界面就会变成这样：
这就要求在导航方法中多一个参数来指定具体的位置。按照我们的设计，在Taobao UWP中有以下4个Frame承担具体的导航工作：
Home Frame：作为一个Scenario的首页，必须存在。
List Frame：显示商品列表，可以存在。有些Scenario，它的首页就是一个商品列表，就在Home Frame里显示了，List Frame可以不存在。
Detail Frame：详情页，必须存在。基本上所有的商品，都是要通过详情页来展示具体的商品信息的。当然，在别的Scenario中，如"我的淘宝"场景，可以用此Frame显示别的非商品内容。
Chat Frame：附加页，一般用于显示内置旺信聊天窗口，必须存在。
淘宝首页是显示在Home Frame中的，点击淘抢购入口后，code里都做了什么坏事儿呢？
Nav.To(NavToUrls.RushBuy_Home, mode: NavMode.List_Replace);
其中，Nav是我们自定义的一个导航帮助类，To()是它的静态方法，定义如下：
public static bool To(string url, object param = null, NavMode mode);
参数解释：
- string url：这个是必须的。我们把所有的页面都指定了一个URL，淘抢购的主页的URL定义如下：
public const string RushBuy_Home = "taobao://go/RushBuy/index";
- object param：指定页面间传递的参数。
- NavMode mode：指定导航模式，是一个枚举值，定义如下：
public enum NavMode { Default, // show page in scenario frame Home_Add, // show page in scenario frame List_Add, // show page in list frame, keep old page (if exists) in back history List_Replace, // show page in list frame to replace the old page (clear old page in back history) Detail_Replace, // show page in detail frame to replace the old page (clear old page in back history) Detail_Replace_Clear, // same as above, also delete page in list frame Chat_Add, // show page in chat frame, keep old page (if exists) in back history Chat_Replace, // show page in chat frame to replace the old page (clear old page in back history) Chat_Replace_Clear, // same as above, also delete pages in list/detail frame }
每个枚举值都包含有两个信息：位置，方式。如List_Add，下划线前面的"List"表示位置，在List Frame中显示目标页面；下划线后面的"Add"是方式，一共有三种方式：
- Add：如果在目标Frame中已经有其它页面存在，则在已有页面基础上再做一次Navigation，也就是back stack历史中会多出一个记录。
- Replace：如果目标Frame中已有其它页面存在，则"删除"它，也就是在back stack中清空历史记录，然后做一次Navigation，最后back stack中只有最新的页面记录。
- Replace_Clear：同Replace，另外，如果前面的Frame中（除了Home Frame以外），如果有页面存在，则清除它们。
我们逐个解释一下这些参数的用法。
为什么需要Add/Replace方式？举个例子，在淘宝首页，假设用户先点击了天猫：
然后用户又在左侧首页上点击了淘抢购：
由于天猫和淘抢购都是在List Frame中显示，于是淘抢购把天猫覆盖了。此时用户按Back键，希望看到什么？显然不是要回天猫！于是，我们是这样指定淘抢购的导航方式的：
Nav.To(NavToUrls.RushBuy_Home, mode: NavMode.List_Replace);
它指定了淘抢购在List Frame中显示，用Replace方式，也就是清掉前面的天猫的痕迹。
何时用Add方式呢？比如用户在首页点了搜索：
右侧进入了搜索起始页面，用户输入搜索词后按回车，再进入搜索结果页面：
此时用户想改一下搜索的关键字为lumia 950 xl，点击一下搜索结果页上方的搜索框，就会回到搜索起始页。对于这个Scenario，我们需要这样使用导航方法：
1）在首次进入搜索起始页时，使用Replace方式来清空历史：
Nav.To(NavToUrls.Go_Search, mode: NavMode.List_Replace);
2）在进入搜索结果页时，使用Add方式附加搜索结果页：
Nav.To(NavToUrls.Search_Result, mode: NavMode.List_Add);
如此一来，当用户在搜索结果页按返回键，或者点击搜索框（等同于按返回键）时，就会在List Frame中调用Navigation Back方法，回到搜索起始页，因为此时搜索起始页一直在List Frame的历史stack中等候。
何时使用Replace_Clear这种方式呢？对于有些Scenario，有一些特殊的导航需求，主要是为了保证左右两侧窗口的上下文关系。比如店铺：
假设我们先看了店铺简介，现在左右两侧的窗口内容是有上下文关系的。此时，店铺首页在Home Frame中，店铺简介在List Frame中。我们用这个方法来显示店铺简介页：
Nav.To(NavToUrls.Shop_Brief, param: ViewModelData.ShopInfo?.ShopId, mode: NavMode.List_Replace);
现在，左右两侧的情况是：Home Frame <-> List Frame。然后用户在左侧的店铺首页上点击了一个商品，想看该商品的详情，页面就会变成这个样子：
此时左右两侧的情况是：Home Frame <-> Detail Frame。那么刚才的用于显示店铺简介的List Frame哪里去了呢？被清掉了！因为我们使用了这个方式来显示详情页：
Nav.To(data?.H5Url, mode: NavMode.Detail_Replace_Clear);
请大家注意第二个参数，使用了Detail_Replace_Clear方式，表示在Detail Frame中显示详情页，Replace该Frame中以前的内容，并且Clear掉List Frame中的所有页面。于是，店铺简介页面神奇地消失了，因为它不符合现在的上下文关系。当然，此时还需要其他一些手段来隐藏空白的List Frame，比如判断List Frame的Content是否为空。
写累了，喘口气。刚才在写博客做截图时，还发现了个Navigation的bug，顺手给fix了，是调用参数写错了，应该写成Detail_Replace_Clear，但是写成了Detail_Replace，导致现在线上的版本，在店铺页，先点击店铺简介，再在左侧点击全部宝贝，再点击任意商品，此时，随着窗口左滑，左侧是店铺简介，右侧是一个商品详情，上下文关系不对。
本篇博客只是简述了多窗口导航的原理和一些code片段，具体的实现可以根据个人应用场景的需求自己定制，尤其要注意多窗口之间的上下文关系。下次再说说页面间通信和屏幕适配吧，Continuum其实也是一种屏幕适配。
- 7楼codename.net
- 我能不能提个意见，甭管UI是谁设计的，为啥这个配色看起来这么丑？布局看起来也很丑，总感觉有什么另类。，我感觉直接抄ios的样式得了，就别搞UWP自己的设计准则了，MS的设计已经证明是最丑，最难用的了，微软的原来的优势就是提供一张白纸，让别人任意发挥，还是继续走这个路线吧，在这么弄下去，我这个靠微软技术吃饭的人就被逼到别的平台了
- Re: 梦影决幻
- @codename.net，，看样子你团队并没有给你配备美工，MD2设计稍微发挥一下还是很漂亮的，包括用在X86的软件上，淘宝的配色和布局确实有不少需要修改的地方，准确说设计师没有把淘宝的整体自家风格和MD2风格融合妥当，，另外上几张我做过概念图你可以参考一下，，，，，，，，，，，，，，
- 6楼EcitGis
- mark
- 5楼jesse hao
- 呃~~~~~~~~两个建议：，1.主磁贴的【淘】字偏大：你把系统自带的邮件/日历/电话/短信/音乐，跟淘宝app放一起就能对比出来，【淘】字偏大，，2.透明磁贴的【淘】字偏上：将透明磁贴固定到开始屏幕，跟其他app对比就能发现，【淘】字跟其他icon对不齐，偏上，
- Re: 梦影决幻
- @jesse hao，更新一下版本吧，1.0.17已经调整过了
- 4楼梦影决幻
- 已经更新到1.0.17版本，惊喜的发现磁贴已经调整过了，不过我想说这次被整的过小了(笑哭)，比标准要小4~6px左右的宽度，不过不仔细看是看不出来的，尚能接受，没必要再麻烦那边美工再调整了，(不然淘宝美工发飙：一会大一会小，到底要怎么样！)
- 3楼小ia
- 其实我是一名用户。，知道开发者是辛苦的。，但从现在的交互体验来说。确实水准不高。，，希望能够更加给力，辛苦了
- 2楼梦影决幻
- 先提前声明一下，下面的的文字包含大量过激批评内容，阅读之前请做好心理准备，，仔细看了整个系列的文章，尽管文中关于代码的构建和逻辑等方面写的很高大上，但是不得不吐槽软件实际成品中很多UI细节依然一塌糊涂。，这里不是指阿里那边控制的内容，而是指软件本身的界面和操作逻辑，，比如淘宝HD的Vertical Menu Bar这一块，我不登陆淘宝账号就无法进入软件设置，这是什么操作逻辑？左下角的返回按钮和左上角的返回按钮功能完全重复，为何要这样留下？ 微软官方所有的APP的Vertical Menu Bar宽度都是48px，为的是可以和开始按钮宽度对齐以确保美观，为何淘宝要用64px这么奇怪的数值？如果借口说是因为图标很大，那么为何不缩小一点图标，把文字放到可以展开收缩的汉堡菜单里面？ 顺便批评一下旺信的Vertical Menu Bar也是，展开效果是什么鬼？注销按钮居然是圆角矩形，这早在WP7WP8时代微软就明确在设计指南文档里面写了请勿使用圆角矩形。，诸如此类的不到位的细节数不胜数，难听点的说不得不怀疑邹老师的团队到底有没有认真研读过从WP7到Win10微软官方给出的开发设计指南，如果说微软中国自家团队做的项目都不严格按照微软自己的规范来做，抱着quot;差不多就行了quot;抱着quot;我觉得看上去还算马马虎虎quot;的这种心理去做这种示例APP，说实话，安卓的国产软件生态环境已经够乱了，如果现在这个阶段的UWP软件质量也这样不高的话，那么就是把用户活生生的往苹果怀里推，而UWP生态环境和用户数量在中国的前景将甚是堪忧！，，以上言论对事不对人，请不要生气也请不要忽视这一段话的分量，我本身是从事UI设计工作的，也是某手机论坛的一个老版主了，也做过不少软件测评，不是要自诩什么，只是想说一下我或者我的话还是能代表一些用户感受和用户需求方向的。而且这些应该是团队内部开会所提出的内容，并不应该是我一个粉丝或者一个外人所提出的议论。上面言论比较过激，再次抱歉！
- Re: MS-UAP
- @梦影决幻，左侧Vertical Menu Bar在即将发布的1.0.17版中已经改为48epx。，淘宝/旺信，这些产品的UI设计是淘宝团队给的，我们能做主的地方有限，但是也可以根据用户反馈据理力争。，淘宝团队，现在仍然叫做手机淘宝团队，他们的重点只是在手机上，而不是在UWP的Desktop上。这么说你可能就明白了。，我们这个开发团队，吃亏就吃亏在没有自主的UI设计权力，当然也就没有配备相应的UI设计人员。产品的任何细节都是淘宝团队来决定的。，还有一点要说明，由于业务变动频繁，在淘宝UWP中嵌入了大量的Html5页面，这些页面的UI，完全由服务器端决定。至于那些是H5页面，大家看一下加载速度和页面框架就知道了。
- Re: MS-UAP
- @梦影决幻，新的1.0.17版今天晚上发布，届时在界面上用户有选择权，是单页模式还是双页模式，喜欢哪种用哪种。有的用户显示器较大，可能会喜欢双页模式，有上下文关系。有些显示器小的自然喜欢单页模式。而双页模式（实际上是多页模式，不同于IT-Home的那种左右模式），在整个业界也是一种创新，一种尝试，喜欢的就用，不喜欢的就用单页的，我们把选择权留给用户。，欢迎你在细节上给予指正，我们会联系淘宝方把意见转过去。
- 1楼茶语咖啡
- 厉害，写博文的同是顺手fixbug