gamelauncher下载(gamelauncher)
如何在 PC 上更新《堡垒之夜》
《堡垒之夜》是这一代最受欢迎的游戏之一，游戏内容不断更新以保持用户的参与度。但是，大多数玩家需要帮助来更新 PC 上的游戏。
在 PC 上更新《堡垒之夜》如果您不知道如何在 PC 上更新 Fortnite，我们以下 3 个分步方法将帮助您轻松完成整个过程。
方法#1：让 Epic Games Launcher 更新 Fortnite可以通过以下方式让安装在您 PC 上的 Epic Games 启动器检查 Fortnite 待更新。
双击 Windows 桌面上的 Epic Games Launcher 图标将其启动。
右键单击右下角系统托盘上的 Epic Games Launcher 图标。
单击“退出”。
等待启动器完全关闭并再次打开。
启动器将检查待处理的《堡垒之夜》更新并允许您安装它们！
如果您使用的是 Mac，请右键单击 Epic Game Launcher 图标，单击“退出”，然后重新启动应用程序以检查 Fortnite 更新。
方法#2：在 Epic Games Launcher 中启用自动更新通过执行这些步骤，您还可以在 Epic Games Launcher 设置中启用 Fortnite 自动更新，以自动更新游戏内容。
步骤#1：启用 Epic Games Launcher第一步，在 Mac PC 上的 Windows 上启动 Epic Games Launcher 并登录您的帐户。
接下来，转到启动器设置。为此，请单击启动器右上角的个人资料图标，然后单击下拉菜单中的“设置”。接下来，向下滚动到“管理游戏”部分并启用“允许自动更新”选项。
步骤#2：启用 Fortnite 自动更新在最后一步中，单击“允许自动更新”选项下的“Fortnite”将其展开，并确保选中其“自动更新”框。当新的《堡垒之夜》更新发布时，它将自动开始下载，完成后您将收到通知。
方法 #3：在 PC 上手动更新 Fortnite要在 PC 上手动更新《堡垒之夜》，请按顺序执行以下步骤。
在 Windows PC 或 Mac 上启动 Epic Games Launcher。
使用各种登录选项登录您的帐户。
单击应用程序仪表板左侧窗格中的“库”选项。
单击右侧窗格中的“Fortnite”，挂起的更新将开始下载。
更新开始后，您可以通过单击 Epic Games Launcher 左下角的“下载”部分来跟踪更新进度。下载并安装所有文件后，更新将完成。更新完成后将会出现一条通知，您终于可以玩《堡垒之夜》了。
《堡垒之夜》多久发布一次内容更新？正如我们在开头提到的，《堡垒之夜》定期发布更新，为游戏添加新内容。除了每周或两周后发布的内容更新外，还有季节性更新。
季节性更新添加了大量新内容，例如新武器、地图更改、新战斗通行证等等。 Fortnite 在 Fortnite 赛季结束时发布它们，通常持续 3-4 个月。
还有圣诞节、复活节、万圣节和许多其他节日等特殊活动的更新。针对这种情况，游戏开发者会在地图上的不同位置添加特定主题。
这些定期更新可帮助玩家保持对游戏的投入并保持《堡垒之夜》在用户中的受欢迎程度。
【官方干货】即点即玩，Unity 小游戏开发简介
本文出自“Unity官方开发者社区”，Unity Open Day 北京站-游戏专场分享
微信、抖音、QQ、快手、支付宝、头条、百度等等都是国内的小游戏平台，以微信为例，其 2019 年 5 月已经实现了玩家数量过亿，2021 年流水过千万的产品已经超过 50 款。这些数据足以显现当下小游戏拥有强大的玩家基础以及变现能力，因此 Unity 正在逐步加大对移动端小游戏的支持。
Unity 中国引擎底层架构技术主管赵亮带来以 Unity 小游戏开发为主题的演讲，演讲中分别介绍了主流的小游戏平台及技术方案；即点即玩小游戏需要用到的资源流式加载 Auto Streaming；小游戏技术方案：Native Instant game 与 WebGL。
演讲中除了提供了极为实用的技术意见，还着重介绍了 Unity 引擎侧优化和改进，包括优化内存占用、优化绘制的效率、进一步给引擎瘦身、加快小游戏的启动速度。
以下是分享正文：
赵亮：今天跟大家一起聊一聊使用Unity开发小游戏。小游戏是一种嵌在宿主应用内部，无需下载安装，可即点即玩的游戏产品形式。国内小游戏用户规模庞大，2018年，小游戏市场达到300亿元规模，在移动游戏市场也是一个不小的占比，大概占到20%左右，因此Unity正在逐步加大对移动端小游戏的支持。
我的分享包括几个方面：首先，我们介绍一下当前主流的小游戏平台，以及他们采用的技术方案；接下来，介绍一下即点即玩小游戏需要用到的资源流式加载；然后，分别介绍两种小游戏技术方案：Native Instant game与WebGL；最后，介绍一下我们未来的工作方向。
小游戏平台
微信、抖音、QQ、快手、支付宝、头条、百度等等都是国内的小游戏平台，这里介绍比较有代表性的微信和抖音，以及采用的技术方案。
微信是2017年12月发布“跳一跳”小游戏，2019年1月起开发者数量已经超过10万，2019年5月用户过亿，2021年流水过千万的产品已经超过50款。
图中展示的就是微信小游戏的品类，随着时间的发展，我们可以看出小游戏品类近年逐渐从超休闲向中重度发展，例如MMO、策略游戏等也开始往小游戏平台发展。
大家也可以关注微信公开课，上面有些开发者分享使用Unity开发小游戏的经验。
抖音平台经过调研发现，小游戏受欢迎程度仅次于APP游戏，同时小游戏用户规模较大，特征比较显著，大多是18-40岁的年轻男性，有不俗的消费能力。
在宿主应用中，实现即点即玩的小游戏主要有两种技术方案：
一种是基于浏览器内核，使用wasm+webgl的方案；另一种是在安卓上实现的native instant game。大部分小游戏平台都采用WebGL，但native instant game好处是游戏品质可以媲美原生APP，抖音和快手都在用这种方案。
资源流式加载
前面提到小游戏在从“超休闲”往“中重度”不断发展，小游戏中用到的资产越来越多。有些小游戏资产打包后有几百兆字节，甚至1GB以上。为了让玩家可以即点即玩，减少等待下载的时间，需要实现按需的流式下载。对于游戏开发者来说，管理好资源的流式加载需要投入不少开发时间。因此我们在引擎侧开发了AutoStreaming这个功能，让引擎底层自动处理好流式加载。
这里我们简单介绍一下AutoStreaming（自动流式加载）的工作原理。在Unity Editor里，我们提供了工具，可以在打包时自动分离出重度资源。诸如：Texture、Mesh、Audio、Animation、Font。这些资源将被部署到云上。分离出重度资源后，游戏的首包、游戏的AB包会大大减小,因此可以让小游戏快速的下载、加载。游戏运行时，引擎会根据需要自动从云上下载资源。开发者不用修改游戏的逻辑，可以像往常一样同步实例化prefab。这些texture，mesh会在一个后台队列里，自动被下载、加载。
这里我们以一款线上的小游戏为案例，看一看AutoStreaming的效果：首包中的数据减少了很多，从42M降低为6.8M，因此大大减少了启动耗时（40秒降低为7.88秒）。用户打的AssetBundle也减小了一些，因为我们只选择了一部分贴图做AutoStreaming，所以瘦身程度不是很大。
另一处很重要的收益来自于内存，内存占用减少了75MB。内存对于iOS平台是很珍贵的。减小的原因在于被剥离的重度资源有更加合理的生命周期。未开启AutoStreaming时，这些纹理在加载后依然占用内存（首包内存orAB内存）。
这是webgl平台的一个特殊之处，它没有真正的文件系统，只有一个内存中的文件系统。首包里的资源会持续占用内存,AB在未unload前也会一直占用内存。这跟原生APP不一样，在原生APP中，每次读取文件中的一块，只要通过复用一小块内存就可以访问一个大文件。
Native Instant Game
简单介绍一下Native Instant Game方案：优点很明显，可以直接对标原生APP，性能一样，体验也是一样；支持多线程；支持Gles3、Vulkan；原生APP插件也都可以用。可以采用同步方式访问沙盒中的文件，访问效率比较高，占用内存也比较少；以独立的子进程运行在沙盒中，不会干扰宿主运行；稳定性和安全问题Native Instant Game也提供完整的方案。因此对移动游戏开发者来说适配Native Instant Game成本很低，只要进行流式加载，不需要额外的适配和优化。
右侧图是来自抖音平台的小游戏，叫做《古董就是玩儿》，我们曾经将其适配至WebGL平台，画质降低还是很明显的，所以这是Native Instant Game的优点。
当然了，它的缺陷也很明显，它目前还没法支持iOS平台。所以微信没有集成这种方案，字节、快手等其它平台采用混合方案。在iOS上采用WebGL方案，在安卓上既支持WebGL也支持Native Instant Game。如果有些游戏追求性能天花板更高，可以采用Native Instant Game；假设追求受众更多，游戏品质没有达到性能天花板上限，可以选用WebGL。
下图介绍的就是Native Instant Game工作原理。Unity把每个小游戏运行时都需要的运行时库、默认资源打包在一起，作为一个共享的引擎包，方便宿主APP提前准备，从而减少每个小游戏启动时等待下载的时间。共享引擎包大约有9MB，具体包含libunity，libmono等运行时库、通用的 dll，如：mscorlib.dll System.dll UnityEngine.dll、Unity default resource。
有了共享的引擎包以后，开发者对小游戏平台进行打包，基本上打包成两部分就可以：首先是一个很小的首包，5-10MB左右，可以方便快速加载和下载，包含游戏本身的逻辑和第三方插件的so文件、AutoStreaming资源，以及一个json描述文件（游戏名称、首包下载url、引擎版本和下载链接、文件MD5），供开发者提审，以及客户端加载小游戏使用。
宿主客户端启动一个小游戏的时候会根据刚才提到的json文件描述拿到游戏首包。前面提到的共享引擎包，宿主通常都会提前下载和解压。然后客户端把首包解压到小游戏对应的沙盒文件夹，通过很小的InstantGame Launcher启动Unity小游戏子进程就可以了。
游戏运行的时候可以自动从云端下载这些所需的资源，这些是针对AutoStreaming的情况，否则用户需要自己动态加载。
webGL
下面我们详细介绍WebGL方案，优点是支持iOS和Android，但方案限制很多，我们会用更多的篇幅介绍。
WebGL在iOS平台上内存十分受限，低档机不能超过1GB，高档机大概1.4GB左右，超过这一限制可能就会触发操作系统OOM迫使进程重启。WebGL运行效率比原生APP慢3倍左右，目前只支持单线程不支持多线程，所以WebGL小游戏CPU性能比原生低不少。图形API只支持WebGL1/WebGL2，所以有些高级特性和优化没有办法使用，包括Compute Shader。没有文件系统，所以需要更大的内存模拟文件系统。这也导致Unity cache机制受到很大影响，cache文件无法被同步访问。
由于CPU侧性能比较弱，游戏复杂度提高、计算量增大的时候，手机很容易过热。也会对网络API有限制，因为只支持websocket，所以需要开发者进行适配。由于以上这些限制，导致能使用的插件也比较有限。iOS对于WebGL的支持也不尽如人意，我们经常要为iOS平台做特殊优化、写特别的workaround。
对于WebGL方案来说，iOS平台的问题比Android平台要多。因此接下来的讨论中，我们都关注如何在iOS平台上profile、优化小游戏。iOS平台优化好了，Android平台基本不会有问题。
我们这里使用一个案例分别打包原生APP和WebGL小游戏，对比内存、CPU、GPU的差异。我们使用的测试手机是iPhone12。
相比原生APP，WebGL进程内存占用多了450M左右，增大的部分在于加载和编译占到340M；Wasm heap有些Unallocated内存，多出来90M；File System多了60M。
除了Wasm文件本身之外，浏览器的内核在代码编译执行的时候也会产生更多的内存消耗，相关的缓存、JIT优化也会使用较多内存，总体大约是Wasm文件大小的10倍左右。
接下来分析Unallocated的部分。Wasm heap的大小是从一个预设值开始，然后以一定步长逐步扩容，扩容的方式比较傻，需要复制整个ArrayBuffer。例如从400M扩容到500M，扩容的时候400M也在，500M也在，总共会有900M的峰值。我们建议开发者根据游戏实际内存峰值，刚开始设立一个比较大的预设值。但这样会带来另外一个问题，就是会在wasm heap的尾部留有一段尚未分配的部分，就是90M的地方。
文件系统会多使用内存。浏览器的沙盒机制导致WebGL无法访问本地文件，为了浏览器安全，只能使用JavaScript + IndexedDB模拟一个文件系统。Wasm访问js层，js层再访问IndexedDB，这里js层会占用一定内存，不能像Native文件系统那样直接使用一小块内存访问大的文件。
还有一处值得注意的是Mono Heap和Emscripten malloc的空闲空间。WebGL上，Mono Heap由IL2Cpp分配管理，其他native内存（包括引擎Native Heap和其他第三方库如Lua分配的内存）由Emscripten的malloc分配管理（默认使用dlmalloc）。这两部分都是只增不减，而且相互独立，空闲空间无法共享，因此需要各自都注意控制峰值。
我们看到WebGL相比原生APP也有一部分内存占用减少，比较显著的就是Native Heap中的IL2Cpp Runtime。通过延迟加载meta信息、使用Sparse HashTable等方式使内存从101MB降低到35.3MB。这里主要是针对WebGL平台进行优化，后面会详细介绍这些。Asset相关的部分也有降低，因为资源压缩格式进行了调整，来自引擎底层内存分配器的行为和策略在不同平台上也有不同。
再来看一看CPU计算性能的对比。之前网上看别人的Benchmark研究，webassembly的执行效率约为原生app的三分之一左右。
我们拿了一款真实的小游戏进行测试。Timeline Profile可以看出原生APP耗时3.5毫秒左右，小游戏耗时10毫秒，所以整体来看WebGL的CPU性能与原生App相比相差3倍左右，其中既有WebGL单线程的原因，也有wasm本身执行效率的问题，印证了之前Benchmark结果。
再来看GPU的对比，去除空白网页本身的GPU消耗以外，对一个游戏来说，WebGL和原生APP差距并不大，我们可以认为WebGL小游戏的GPU性能和原生APP差不多。
WebGL小游戏的开发和移植最近几年已经有大量的成功案例，所以新进来的开发者不用很担心，之前踩过的坑都已经处理好了。Unity有一个官方QQ群，大家如果有什么问题可以在群里聊。微信为WebGL小游戏开发也整理了很详尽的教程，公开课也有开发者分享使用Unity开发小游戏的经验。
为了减轻WebGL平台限制对小游戏开发的影响，我们在引擎侧也有很多优化和改进，包括优化内存占用、优化绘制的效率、进一步给引擎瘦身、加快小游戏的启动速度。
在一个案例中IL2CPP运行时内存占用从64M优化到了33M。也有优化DynamicVBO pool的复用机制，测试案例中从59M降低到了38M。后面提到的代码轻量化和资源裁减也会帮助减少运行时的内存占用。
这里我们详细介绍一下IL2CPP运行时内存的优化。我们首先分析一下IL2CPP运行时主要的内存开销。首先是Metadata，它是运行时构建的元数据结构，里面主要是Il2CppClass和它的各种成员变量。然后是global-metadata.dat，它是打包时生成的元数据序列化文件，在webgl平台会完整地加载到内存中。再是HashTable，用来在运行时加速元数据的访问。
接下来，分析一下对Metadata部分的优化。这里主要是针对Il2CppClass及其成员变量的延迟加载，其中MethodInfo占比最大。之前的libil2cpp实现中，在使用到某个类型时，会初始化这个类型完整的元数据：包括它的所有函数、接口、事件、属性、虚函数表等等信息。但分析发现，脚本代码运行时，通常只会用到很少的一部分元数据（在反射或虚函数调用时访问）。例如：数组类型，它有155个方法，25个虚函数，实现了6个接口，但实际在运行时只会用到其中的很小一部分，存在冗余加载的情况。因此我们的优化思路是延迟加载这些元数据，等到真正需要某个元数据项目时才去初始化这份数据。
图中可以看到，除了Field之外的信息都可以进行延迟加载（Field信息在构建对象实例时就需要，它决定了对象实例的的内存布局）。延迟加载粒度可以精确到逐个方法的粒度。延迟加载也会带来一个比较小的开销，就是在访问某个元数据前需要做一次非空判断，目前我们还没有Profile出它引入的性能回退。
我们根据两个实际案例对比优化前和优化后的内存占用，63.8M降低到33.2M，11M降低到6.5M。除了MetaData的内存降低，HashTable也有降低，因为我们用sparse哈希表替代了dense哈希表。未来我们还会优化global-metadata.dat这个序列化文件。它里面包含大量string，有一部分可以用hash值替代。它里面还有大量索引使用32位保存，这也比较浪费内存。
除了内存优化以外，我们也在绘制方面做了很多优化工作。WebGL不支持Compute Shader，这里通过Transform Feedback支持了GPU Skinning。优化Shader Compiler，将non-const global变量移到main函数中，帧率可以从23帧提高到55帧。修改Immediate Const Buffer转换过程，声明成const并赋予一个初始值就可以将某案例从32FPS优化到37FPS。我们还会提供可配置的max visible lights值，改成16甚至更小以后性能会有很大提升。iOS平台对WebGL的支持不够好，所以我们也针对iOS平台做了特殊的Workaround，避免使用过多的Uniform变量。在iOS14.x-15.4的WebGL上有一个Bug，针对这些版本，我们对同一个Canvas不共享IB和VB，可以改善UI渲染性能。
可以看到打开GPU Skinning以后平均每帧消耗42毫秒左右，没有开启的话每帧需要消耗67毫秒左右。
从下图中的Timeline Profile，可以看到MeshSkinning.Update时间开销从57ms降低到了29ms。
看一看引擎代码的轻量化。从前面的内存分析可以知道，30多M的wasm在加载后会占用300多M的内存，因此生成的wasm越小越好。之前Unity的方法主要是Managed Code Strip和Engine Code Strip，它们是通过静态分析依赖的方式做的strip，以函数作为颗粒度。我们在这里会更加深入地分析打包生成的wasm代码，看看除了这两个Strip，我们是不是还有更多的优化空间。
我们分析两个案例。游戏指令数都是1200万左右，其中il2cpp占比约60%，其余是引擎C++代码，占比40%，然后我们按模块对其进行分类，发现其中较重的模块有 Physx, particle system, sqlite, mecanim等，如Physx占了 8%。
通过分析，目前发现的问题有：案例2是一个消除类游戏，并未使用到什么Physx仿真，仅仅在UI上使用了Physx的射线检测，就引入了一个庞大的Physx库，所以是非常不合理的。Wasm中有很多模版展开的代码，拿空间换时间可能在某些平台上是比较不错的策略，但WebGL平台内存特别紧张，所以在WebGL上并不是一个好的策略。
目前我们做了的工作有：将一部分c++模板参数改为函数参数，减少生成的代码量；用宏剔除 webgl项目用不到的模块和函数，例如：Sqlite，ComputeShader，Physx的部分功能。未来我们还会继续清理启动流程、主循环里面不必要的步骤，以及探索如何优化il2cpp代码生成。
在加快启动速度方面，我们主要做了两件事情：一是跟平台合作，让平台提供中文字体，避免每个小游戏都在首包里放一个中文字体，可以节省5-10M左右的下载时间。二是动态裁减Unity Default Resource，这些资源不见得每个小游戏都会用到。目前看来对大部分游戏可以把Default Resource从3.5M降到400K左右。之前我们还尝试通过wasm snapshot方案进行加载。
未来工作
接下来聊一下未来工作的方向。除了前面提到的给global-metadata.dat瘦身、探索如何减少IL2CPP代码生成，主要有多线程和WebGPU这两大块。我们还会探索Web Assembly上的SIMD，甚至尝试让WebGL平台支持Burst。
Unity现在已经可以打开WebGL多线程，可以看到打开多线程以后，DeformSkinnedMeshJob从主线程转到了web worker上。
这里还是针对之前的测试案例尝试使用多线程，使用后每帧消耗从68毫秒降低到38-40毫秒左右。
但是目前Unity多线程还不够稳定、不够完善，切换场景的时候可能Crash，目前也不支持RenderThread，因为web worker无法访问DOM。打开多线程以后，内存增加也比较厉害。另外WebGL多线程只能支持Native代码，不支持C#代码，也是我们要努力解决的问题。
四月底发布的Chrome 113已经支持WebGPU了，目前我们也是一边集成一边研究如何重构GFX Device的接口层，使它更接近于现代图形API，从而能够更多地发挥WebGPU的性能优势。
今天介绍到这里，谢谢大家！
从电视端学习大屏设计原则
生产决定消费，电视载体创新、互联网视频服务和技术之间的交替促进，推动着大众家庭影音体验的升级。那么，如何设计电视大屏的家庭影音应用呢？一起来看一下吧。
回顾以前，我们看电视只能看CCTV、江苏卫视、湖南卫视这些直播内容，可是我们不满足于直播节目，想要去广告想要看收费内容想要回放看上课时播出的电视剧。让我印象很深刻的是那种点播台，要打电话用话费点播，来来回回就放的那几个动画。现在，我们可以在电视上语音搜索到热门网络剧，订阅欧冠英超球赛直播、选择各家综艺影视等等。
生产决定了消费，正是电视载体创新、互联网视频服务和技术之间的交替促进在推动着大众家庭影音体验的升级。如何设计电视大屏的家庭影音应用，就是我接下来想要分享的内容，我打算先从电视和手机的几个不同讲起。
01 智能电视设计和手机的5大不同点用户—上下文场景—行为—工具或媒介—目的。
1. 居家使用的场景不同的场景下人和物都有不尽相同的交互方式。
我们使用手机时的用户使用场景可以是移动的，在地铁上在卫生间，利用碎片化时间，而电视通常都是被固定在客厅卧室这样的居家场景中，使用时长是整段的，一般集中在晚上时段。
场景：在什么时间，什么地点，什么样的环境，最后发生什么事情；
电影里场景的分类：内景、外景、实体场景、虚拟场景。
2. 家庭成员共享在居家场景中，电视是全家的公共设备，覆盖不同年龄段的人。尤其是老人和小孩，各年龄段使用时段也很不同。因此使用电视时，用户学习成本要低，操作要求更简单，还有不同模式切换。
而手机作为个人物品，更具隐私、个性化的特征。手机虽然各种交互感应很灵敏，但是相对的，操作要求更精确，学习成本高。
3. 休闲消费的行为与手机相比，电视不适合承担功能型的操作任务，作为一个家庭休闲娱乐设备，使用场景和功能相对单一。休闲娱乐是电视的主要用途，还有学习、智能助手、家居控制、装饰等。
4. 远距离遥控+语音输入的交互方式与移动端不同，电视体验发生在不同的空间中，并且需要在3米外清晰可见。在近场交互时实体与触控是第一选择，而当中远场交互时语音成为输入方式的第一选择，遥控器这种远程遥控的实体输入方式学习成本低而被保留至今。
5. 沉浸式体验的目的人们经常以轻松的心态使用电视，希望获得一种观看小屏无法获得的身临其境的娱乐体验。电视相比于手机更注重沉浸式体验，做到电影般的效果。
02 如何思考智能电视的界面设计首先，在设计电视端时，我们可以参考安卓和苹果的TV端设计原则来主导界面设计，其次我们依旧可以根据设计五要素去思考界面设计的方向。
1. 使用场景的限制1）配合场景的暗色模式
电视的使用场景：夜晚的客厅环境——具有弱光、安静、舒适的特点，因此我们一般都采用暗色主题，让背景色融入场景氛围，以此突出内容。内容和背景的对比也不需要过于明显，背景颜色的选择不宜过黑而无法辨别出图片的阴影。在主题高亮色上避免使用过于饱和以免产生刺眼的感觉。
2）海报内容一目了然
一般电视里也分为应用图标与内容推荐，它们都需要在3米外就能被清楚地识别出来。每一个图片的色调可以统一区别于背景。
图片内使用简单的背景让主体脱颖而出，并且不会压倒附近的内容。使用过多的渐变反而会减弱整体的对比，因此应该减少图片内颜色的使用，让主要内容凸显。
3）避免主题色刺眼和失真
纯白色 (#FFFFFF) 在明亮的电视屏幕上可能会非常刺眼，建议将浅灰色 (#EEEEEE) 作为深色背景上的默认文本颜色。同样部分高亮主题色运用到电视界面设计时也需要注意，尤其是红、黄、橙色系，这些颜色会特别严重地失真。
4）文字可识别
由于远距离阅读大量文字会使眼睛疲劳，要认真考虑文本显示的字数，能用图像或者动画交流就避免使用文字。确保各类字体在远处清晰可见，一般系统字体不要小于22px（12sp），也尽量精简字体样式并避免过细的字重。
2. 设备本身的限制1）常见电视尺寸
主流电视尺寸一般在43-85寸之间，常见的有43、50、55、60、65、75等，消费者根据观看距离选择适合的电视尺寸。电视屏幕的尺一般都遵循16:9的电视画面宽高比。我们一般使用1920×1080为最小画布，是当下最常见的电视分辨率，所有图片资源都是@1x 分辨率。随着4K内容的普及，也可以使用1920×1080，但是需要提供应提供@2x图的图像。
提问：1920×1080的电视是几K？1080P就是指1920×1080的分辨率大小吗？
2）画布尺寸与安全区设置
由于在旧电视上存在过度扫描，可能会发生意外裁剪，需要留出安全区，使主要内容远离屏幕边缘。一般上下左右留出画布5%左右的距离。
3）显色差异明显需要测试
各家电视主打画质作为卖点，价格各有不同，各家的画质处理技术也不同，可见各家屏幕的画质一定有一些区别。区别主要在于显色、色域、控光、画质等，总结就是显色差异明显，我们应该在消费者主要使用的电视型号上进行显示测试。尤其是绿色、红色、黄色等颜色容易明显色差。
3. 操控的限制正是有了这样一个外设输入源，就需要考虑触碰但未触发的上焦状态（focused），正如当有键盘就有输入时，当鼠标悬浮时。TV焦点态的设计即遵循安卓一般设计原则，也有它的独特性。
1）D-PAD十字交互与网格布局
我们可以把D-PAD和屏幕间的交互形式，称为“十字线互”，也正是这种交互形式决定了输出端的界面布局的基本形式。
在这个大屏里，我们的焦点只能按照D-PAD的指挥走水平或者垂直线，每一个位置的路径只能走二维的“十”线，这样可以更好引导用户到达他想要的内容。（这里运用了非常典型的亲近性原则）
设计师和开发都熟悉用栅格的形式来布局横版页面，而电视上更常采用间距统一的网格形式来规范内容集合，方便远程浏览，也可以方便遥控器快速导航。设计可以根据内容自定列数，最多甚至可以达到9列。
2）焦点在空间中的层次
位置与方向感：在安卓设计语言中，我们可以通过不同控件在Z轴上不同的位置来划分控件间的层次。通常是通过阴影的变化来表现。因此，我们为了突出焦点所在的位置，焦点一般会有明显的阴影。以外可能还会添加别的样式来加强它。
同时，为了明确指向D-PAD所能到达的位置，我们在设计布局时，也需要避免控件间出现重叠。
即Z轴方向，只有一个焦点和普通两种层级，且（可上焦的）普通层级相互不重叠。
4. 多个用户的限制1）家庭共享下的多模式
输入源除了考虑输入设备本身，还可以考虑多个来自多个人，可能是多人协作或者多人共用。在居家环境这个场景下，根据使用者的不同提供对应账号下的信息页面，以及多人共同进行电视操作。
2）年龄分段模式呈现不同内容与UI
在多个用户的模式下，就需要对不同用户进行分类，电视端常见的用户模式有：儿童、普通、长辈三种模式。
三种模式下，视觉上色调、背景、间距、焦点态、字号、内容海报都有相应的调整。它意味着很多控件是需要做成自定义的。（运营也可以对其进行配置的）
3）常驻的“新手”提示和引导
电视还是一种公共设备，不同时段有不同的人使用它。不同年龄层对智能电视的操作熟悉度也不同，我们在做有引导的页面设计时，也会做成可重复提示的过程页面，而非一次性引导。常见的如按钮文案设计成操作描述的文案，以及焦点带气泡提示等。
5. 即时性与沉浸体验在首页用户更多的是找寻感兴趣的内容，用户选中一个内容就可以立即看到视频内容。所以在这里推荐使用获取焦点即执行的方式，能够节省找寻成本。用户点击确认键即可进入播放页面。
一种是背景图片跟随焦点进行切换并自动播放。
一种是焦点聚焦到内容且未移动时，自动播放垫片内容，无需进入二级，所选即时播放。
03 如何规划一个电视应用页面电视应用的层级少，结构扁平，下面我将举例如何思考一个大屏页面的信息排布以及页面焦点的一些设计重点。
1. 常见的四种页面结构安卓设计指南里列出了几种常见的页面结构：浏览视图、详细视图、消费视图、搜索视图。这几类页面结构基本上就构成了TV端浏览一个内容的流程，从语音或推荐项目里选择一个内容，进入详情并开始观看的一个主要流程。
在appleTV中对应的页面效果如下图所示，都无一不体现大画布背景+不拆分视图带来的沉浸感，并且没有多余的状态栏标题栏。
一个常见的流程如下：我们在浏览视图和详细视图里或者搜索视图里选择了观看内容后，进入消费视图（视频播放页），同时可能主动或被动选择相关内容，跳转播放或画中画播放。
04 以一个K歌应用举例1. 产品定位咪咕爱唱是一款主要通过会员付费为用户提供音乐类版权内容（包括音乐MV、K歌伴奏、演唱会）的产品。
2. 重点页面布局——浏览视图当我们从行为开始考虑，一个K歌的信息页面有什么时，我们可以想到，家庭K歌行为下，对应着多人控制、多年龄段使用，平铺直叙的排版方式是最好，一眼进来最好能看到即时的K歌伴奏MV，有可以让多人同时操作点歌的二维码，支持方便的语音搜索。
在确定的功能点模块基础上，根据沉浸式的目的和十字交互的规则，我重新规划了一种以即时播放未主要中心的首页布局，展示的内容其实没有变化，但是整个页面不再是被划分的卡片而是有主次的功能和信息的排布。
新规划的沉浸式布局1
新规划的沉浸式布局2
3. 重点页面布局——消费视图（播放页面）消费视图里不仅承载了最重要的视听内容，还有一些个性化推荐的服务和功能，因此在设计时，需要提到页面最前来考虑。
纯歌词内容视图，歌词逐字上屏是K歌独有一种展示形式，LRC歌词本身有时间刻度，所以这里我将时间进度条和歌词关联，用户上下移动选择单句歌词更加直观，而不是快进或后退。
内容推荐+歌词展示内容视图，其实这个是上一个页面选择播放列表后的页面效果，我倾向于给每个歌曲生成封面图。（一般每个歌曲都会有图片或者MV）
视频展示内容视图，在播放内容时，尽可能减少选择内容对沉浸式观影的体验，当然后期针对运营需求可以权衡。
4.配色常用的深色调配色当然能更好突出，但是考虑与白天的氛围匹配，浅色调也可以，浅色背景上的阴影更能明显突出焦点层次，更重要的是，按钮背景的颜色在不同素材上都能显示出来。以及所有图片整体的色调选择。
暗黑带透明度按钮背景颜色在两种背景上的表现
中度灰带透明度的按钮背景颜色
当然每一个电视大屏的目标用户不尽相同，还是要根据主要人群来设计和规划。因为K歌产品也是一款既有儿童又有老年人用户的产品。因此针对不同用户，频道的风格也有一些区别。
我们不管是从国外的应用如网飞和亚马逊也好，还是从国内的几家头部视频网站也好，我们可以发现影视作品的封面也呈现出以下我举例的一些方向和风格。我们在做电视端应用的图片展示时，更应该遵循那种精简、干净、光效统一的风格。
以前一些设计举例
5. 焦点态设计1）遥控器与焦点的状态
控件状态需要多少种只跟输入源有关系。比如你输入源是鼠标+键盘，那么 focus (给键盘）、 hover （给鼠标）、active （给鼠标/键盘按下），然后细腻点你还会想要加入 disabled。正是由于远距离交互+按键的形式，电视端的焦点态的形式有很大的不同。
电视端焦点态存在的目的是，方便用户时刻都清晰且明确地知道自己的光标在哪里，可以移动到哪里。——通过焦点的统一性、即时性来进一步明确地告诉电视这端的用户停在了哪里，可以往哪里走。
苹果TV统一的焦点态样式
控件的状态和输入端的形式是强关联的。输入源是D-PAD，那么控件焦点态就是二维的，输入源是触控盘，那么控件焦点态就可以是三维动态的。
苹果电视的焦点态动态图
国内由于强运营的需要，对于电视焦点态的设计五花八门，想尽了心思，层层叠加。
2）焦点动效与遥控方向
我们总览两大设计原则，都提到了电影体验、沉浸式体验，一些小屏幕的细微变化（比如spring）会被放大而显得复杂过度，我们可以想象看电影时掉帧卡顿的糟糕体验，电视端的动画时为了在人和屏幕上的内容之间创造一种视觉上的联系。
和移动端一样的也可以按照这样的分类来考虑：启动动画、反馈动画、转场动画。也可以按照交互动作来考虑，仅在响应用户操作时使用，比如在考虑入场和出场动画时，出场动画可以考虑统一——对应遥控器上的返回键，而入场动画则考虑两个点：
关联性：让用户在布局中理解刚才发生了什么，是什么导致了变化。目的性：让用户明白接下来会有什么，可以去哪里。因为电视端更多是一种图片列表的展示形式，因此图片列表的展示经常以视差运动出现，表现一种大屏上纵向内容源源不断的出现的感觉。
3）沉浸式的焦点效果
目前在浏览器和电视端已经可以看到这样的效果——即当你滚动浏览推荐行时，只要在图像上停留超过一两秒钟，每个标题的预览视频就会开始自动播放。这是在电视上一种非常直觉性的交互，就像很久以前我们打开电视就有生动的音画一样。
电视具有数十年的期望值，当您打开电视时，可以播放视频和音频。因此，有一个沉默的经历实际上是很奇怪的。
如果还想深入优化优秀的大屏端动态效果可以去PS这类游戏主机系统里取取经。对于大屏设计如何精进，我认为还是从主机端游戏界面设计可以瞥见一隅。未来大屏就是AR眼镜，就是VR，电视的那套东西已经被搬进了小小主机和轻便的眼镜里。
结语本文主要以交互设计的5个要素为框架，从电视与手机的不同着手分析电视的特有属性，继而引出界面设计一些特殊点，最后以一个电视端K歌APP设计举例，从布局、配色、焦点态设计等几个面展开详细说明。
参考资料:
Adroid design guidlinestvOS-Human Interface Guidlines从物理逻辑到行为逻辑http://www.360doc/content/15/0210/13/21907744_447672901.shtml设计基础：电视交互设计的一些事 http://www.woshipm/ucd/918841.htmlTV端设计原则分析 http://www.woshipm/pd/4105626.htmlTV UI设计快速上手指南 /d/file/gt/2023-09/ooqtlrlmqef.html在电视端，卡片设计如何进行？ http://www.woshipm/pd/1047767.html电视端设计入门，焦点知识不可少 /d/file/gt/2023-09/zcaltlux23j.html /d/file/gt/2023-09/j3jjj0vfqjo.html /d/file/gt/2023-09/rphlzjft3bl.html http://www.woshipm/pd/1060010.html从零到壹 | 企鹅电竞TV初试啼声 /d/file/gt/2023-09/eazw5ouq4nz | 爱奇艺——“我会成为国产版网飞吗”http://www.woshipm/evaluating/4296471.html电视屏推荐系统如何设计？这里有个详细的方案 http://www.woshipm/pd/1089858.html本文由 @皮质大奖得主 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送至邮件举报，一经查实，本站将立刻删除。转载务必注明出处：http://www.hixs.net/article/20231014/169625173869585.html
