Build

编译构建为开发者提供配置简略的混合语言构建平台，实现编译构建云端化，撑持企业实现继续交付，缩短交付周期，晋升交付效率。反对编译构建工作一键创立、配置和执行，实现获取代码、构建、打包等流动自动化，实时监控构建状态，让您更加疾速、高效地进行云端编译构建。 本节为您介绍编译构建服务的基本操作流程，帮忙您疾速上手编译构建。 请先点击进入流动报名页，支付收费套餐。  前提筹备 已有可用我的项目，如果没有，请先新建我的项目。已在我的项目中新建代码仓库并上传代码，如果没有，请按如下步骤新建。1、进入指标我的项目，在顶部导航栏单击“代码 > 代码托管”。2、进入代码托管页面，单击“一般新建”。3、在“一般新建”页面，填写仓库名称等信息，而后单击“确定”实现仓库创立。4、上传代码至代码仓库。 新建编译构建工作 应用曾经新建好的代码仓库，抉择对应构建模板新建编译构建工作。1、进入指标我的项目，在顶部导航栏单击“服务 > 编译构建”，进入编译构建服务。2、单击“新建工作”，进入配置“根本信息”页面。3、设置工作名称，抉择源码源（“源码源”抉择“CodeArts Repo”，“源码仓库”抉择已创立的代码仓库，“分支”默认抉择“master”），并依据须要增加工作形容，而后单击“下一步”。 1、抉择适宜本人我的项目的“构建模板”，单击“确定”，进入“构建步骤”页签，依据须要自定义配置构建步骤（也可放弃默认配置）。2、配置实现后，单击“新建”实现工作创立。 执行编译构建工作介绍如何执行构建工作以及查看构建后果。单击构建工作名称。进入“构建历史”页面，单击右上角“执行工作”，启动构建工作。 若呈现如下页面，示意工作执行胜利。 若工作执行失败，可通过页面提示信息或剖析日志排查解决。 查看构建包应用默认配置构建生成的构建包，存储在软件公布库“构建名/构建工夫”目录。本节介绍如何查看构建包、验证公布后果。1、在顶部导航栏单击“软件公布库”。2、进入“软件公布库”，依据构建工作名称以及构建工夫，可查找到生成的软件包。 资源清理为了防止不必要的费用产生，实现本示例体验后，可开释构建相干资源。1、代码托管：删除代码仓库。2、软件公布库：删除软件包，并清空回收站。 须知：资源开释后无奈复原，请审慎操作。 产品链接：https://www.huaweicloud.com/product/cloudbuild.html

1）Unity将外围脚本打成DLL是否有性能影响2）预制物嵌套导致AssetBundleName批改后对母预制物失落援用3）真人真机测试报告中AB.LoadFromFile耗时较高4）如何剔除掉Shader中某一个Pass 这是第287篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题，倡议浏览工夫10分钟，认真读完必有播种。 UWA 问答社区：answer.uwa4d.comUWA QQ群2：793972859（原群已满员） BuildQ：Unity将外围脚本打成DLL，比方将某块外围零碎打成DLL后，运行时调用DLL是否有性能影响？ A1：没有影响，Unity默认就是会帮你将C#代码给生成DLL。如果打包到Android或者iOS，当初都会再将DLL用IL2CPP转成CPP代码。感激liu@UWA问答社区提供了答复 A2：当初Unity各平台根本都是用IL2CPP，应用IL2CPP开始构建时，Unity会主动执行以下步骤： 将Unity Scripting API代码编译为惯例 .NET DLL（托管程序集）。利用托管字节码剥离。此步骤可显著减小构建的游戏大小。将所有托管程序集转换为规范C++代码。应用本机平台编译器编译生成的C++代码和IL2CPP的运行时局部。将代码链接到可执行文件或DLL，具体取决于指标平台。<br/>以上摘自Unity官网文档，以便题主了解。<br/>IL2CPP官网文档：https://docs.unity.cn/cn/curr... 感激郑骁@UWA问答社区提供了答复 AssetBundleQ：Unity 2020.3.16预制物嵌套时，子预制物援用的图片AssetBundleName批改后，母预制物会失落援用。 举例来说，预制物A中有个预制物B，而后预制物B上的RawImage援用图片C。ABC三个打到不同AssetBundle中。 首次打包，加载全副AssetBundle，实例化A，A显示失常。 批改图片C包名，再次打包，A所在包不会有变动。然而加载全副AssetBundle，实例化A，A会失落C的援用。 反编译AssetBundle会发现，理论预制物A所在资源包数据中有图片C的援用数据，然而因为二次打包A包无变动，就没有更新C所在包的数据。 这个问题降级Unity是否能够解决？或者在以后版本是否能够避开？ 反编译AssetBundle会发现A所在Bundle会间接以External References模式关联到图片C的地址，并且AssetBundle也会依赖到图片C所在Bundle（然而不依赖到嵌套Prefab B所在Bundle）。 Prefab B从新关联图片D再打包，A援用会失常刷新。然而仅仅批改图片C的BundleName再打包，不会触发A从新打包。 AssetBundle的Manifest显示的A和B依赖关系是不正确的，显示还是A依赖B，B依赖C，和理论解包进去的不一样。 当初曾经用追踪Prefab嵌套树，外加资源BundleName监督的流程临时解决了打包问题。然而还是心愿能取得更标准的解决方案。 A：Unity Prefab嵌套目前只解决了Editor局部，打包AssetBundle时，会将Subprefab的序列化文件局部copy一份到Rootprefab，其实就等于AssetBundle环境下，嵌套Prefab不失效。感激郑骁@UWA问答社区提供了答复 AssetBundleQ：如下图所示，在报告中常留神到资源管理模块中AB.LoadFromFile单次调用耗时较高（几十甚至几百毫秒），且不同AssetBundle包加载耗时差距较大，请问是什么起因导致的？ A：实践上，当应用LZ4压缩的AssetBundle包加载时只须要加载头文件，不应该须要如此大量的耗时。猜想是应用了LZMA的打包形式导致的。 试验将10张、50张纹理别离用LZMA、LZ4打包，屡次测试取中位数，失去AssetBundle加载耗时如下图，根本合乎预测。 其中，LZMA加载AssetBundle须要同时进行解压，耗时与AssetBundle中资源大小相干（如图1，正好成5倍关系）；所以会产生报告中不同AssetBundle包加载耗时差距较大的景象。 而LZ4加载仅需加载头文件，耗时极低。LZMA打包形式 LZ4打包形式 感激Faust@UWA问答社区提供了答复 ShaderQ：如何在公布APK的时候，利用代码主动剔除掉Shader中某一些Pass？心愿这些Pass在Editor环境下能够应用，而在APK包中敞开，这样能够缩小变体构建工夫。 A：通过ShaderSnippetData提供的PassName匹配想要剔除的PassName就能够了。感激题主墙外行人@UWA问答社区提供了答复 封面图来源于网络 明天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题兴许都只是冰山一角，咱们早已在UWA问答网站上筹备了更多的技术话题等你一起来摸索和分享。欢送酷爱提高的你退出，兴许你的办法恰能解他人的当务之急；而他山之“石”，也能攻你之“玉”。 官网：www.uwa4d.com官网技术博客：blog.uwa4d.com官网问答社区：answer.uwa4d.comUWA学堂：edu.uwa4d.com官网技术QQ群：793972859（原群已满员）

1）如何治理大型游戏的美术资源工程2）Google Play强制64位App相干问题3）零散AssetBundle资源再打包疑难4）Unity中Api Compatibility Level .net 4.x与.NET Standard 2.0的区别5）Unity 2020版本OpenGL ES3下SRP Batcher生效问题 这是第252篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题，倡议浏览工夫10分钟，认真读完必有播种。 UWA 问答社区：answer.uwa4d.comUWA QQ群2：793972859（原群已满员） AssetsQ：随着我的项目参加制作的人数变多，各类美术资源的数量也在急速回升，纵然有各种标准和各类资源导入、查看工具，跑一段时间后，依然会呈现工程里各类废除的资源未能及时清理，导致资源和包体大小持续上升，包含：1）各类资源在制作过程中产生的一些两头文件；2）本来在应用，但前面随业务需要变动，已弃用的资源；3）本来就属于要放到游戏中看看成果，但没理论投放的资源。想问下大家在解决这类问题时的一些计划？ A1：题主遇到的问题和技术无关，和流程无关。 （1）监管工作负责到人，凡事预则立、不预则废每个我的项目都须要有一个Performance Owner来对性能、资源等问题进行管控。如果没有这个人，再弱小的工具、再NB的团队也是白扯。这个人能够是我的项目的制作人、主程、QA Leader或者PM（个别小团队不具备）都能够，就咱们单干的团队来看，以QA Leader作为Performance Owner的团队居多。 （2）监管流程要跟上团队中必须要有人来对资源问题、性能问题进行负责，且制订固定的流程来强制团队养成继续监控、继续欠缺的习惯。三天打鱼、两天晒网的模式，是很难成事的，做游戏开发也是如此。所以，将监控变成团队研发的习惯，就须要通过流程来一直把控，流程做到位了，所有就都好了。 以上两点做到了，题主的问题天然就解决了。 该答复由UWA提供 A2：监管负责人个别是PM。因为有些QA没有常识，也没有权力，PM最好懂业务，如果没有PM最好就给客户端主程这个权力，锁版本是很必要的，大部分大厂都有这个。 用工具限度美术的操作，所有不正确的全副报错，而后提醒分明。用锁版本限度提交节点。而后要求不守规矩的人来到，不要问为什么会报错。当然必须从制作人开始就要反对。艰深地讲，美术和策动不会操作工具又不肯学习的，不配单干。 感激马古斯@UWA问答社区提供了答复，欢送大家转至社区交换： BuildQ：Unity能够通过程序集加载对应的代码，且Google Play曾经强制64位APP，是否曾经不反对通过Assembly.Load加载代码了？ A：如下图所示，Unity外面Mono版本还不反对ARM64，所以要上Google Play（64位要求）只能应用IL2CPP，IL2CPP是不反对Assembly.Load的。 能够参考：https://forum.unity.com/threa... 感激Xuan@UWA问答社区提供了答复，欢送大家转至社区交换： AssetBundleQ：Unity的AssetBundle资源有必要把零散的AssetBundle资源做成Zip吗？比方300MB一个。因为在打AssetBundle的时候能够抉择压缩格局，所以不是为了缩小总体的大小，而是如果散的AssetBundle，在下载的时候性能会不会有压力？各位在实践中都是怎么解决的呢？（资源量AssetBundle数量10W+，总大小在4G左右。） A1：一堆散文件下载天然不如一个大文件更快，Http连贯也要工夫和资源，有时候AssetBundle其实只有几KB。不划算。打Zip算比拟不便，能够思考不带压缩打Zip。当然也能够自定义格局来做，然而合大文件当前更新会麻烦点，要做一些治理和替换。感激黄程@UWA问答社区提供了答复 A2：最近刚好做这个性能。将多个包打成Zip，对下载效率有很大的帮忙，特地在国外网络环境下。 1.AssetBundle打包仍旧是零散的AssetBundle包（AssetBundle会做模块辨别，比方特效、UI等）。2.须要热更新时候，生成的AssetBundle包信息和上个版本AssetBundle包比照，将各个模块变动的AssetBundle包生成Zip包。3.热更新的时候，收集须要更新AssetBundle信息（有标记Zip，阐明资源在Zip包里）进行下载，没有标记Zip，则间接下载AssetBundle包，这样兼容跨多个版本热更新性能。4.下载完的Zip包在客户端在解压成AssetBundle。 感激杨宇杰@UWA问答社区提供了答复 A3：当个搬运工补充一个答复：散列的害处比拟集中：下载慢（用cdn，oss后端性能不用思考），上传到oss也是慢得多。 Zip无论跳包治理，下载冗余，都是很头疼的事件，做动静下载更加不可能。因而可能导致比散列更加低廉的oss老本。 感激芭妮妮@UWA问答社区提供了答复 A4：后期开发用零散文件，文件小也省掉了断网续传的问题，前期工夫富裕了再扩大为大包的形式，能够依据版本号生成增量更新包一次下载实现。 放服务器上没什么影响，定期清理一下。 感激rekcah1986@UWA问答社区提供了答复 A5：上一个我的项目用的Zip打包，经营工夫长了当前，冗余资源会越来越多。热更资源要保障完整性不能删，除非你们是换包了，如果你们频繁换包，那么用Zip的形式是最合适的。感激Lim@UWA问答社区提供了答复，欢送大家转至社区交换： EditorQ：Unity中Api Compatibility Level .NET 4.x与.NET Standard 2.0的区别是什么呢？ A：.NET Standard 2.0对平台的支持性更广、兼容性更好。.NET Standard 2.0的API是.NET 4.x的子集。或者说，.NET 4.x反对的API更多一些，兼容.NET Standard 2.0，然而有些API在有些平台上是不兼容的。 Unity默认抉择的是.NET Standard 2.0，如果想要跨平台兼容，那么就选Standard 2.0。如果应用的内部类库或者脚本外面调用的API不被Standard 2.0反对，再思考换成4.x来试试。 以官网文档为准：https://docs.unity3d.com/Manu... 感激Prin@UWA问答社区提供了答复，欢送大家转至社区交换： ...

1）ShaderLab占用疑难2）对于Android下ARM64和ARMV7的问题3）对于ILRuntime相干的性能检测工具4）字体加载问题5）LZ4压缩模式下的资源打包 这是第239篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题，倡议浏览工夫10分钟，认真读完必有播种。 UWA 问答社区：answer.uwa4d.comUWA QQ群2：793972859（原群已满员） ShaderQ：我从官网下载了一份内置Shader，本人写工具刷了一遍，确认界面外面材质球曾经没有援用内置Shader，并且把Standard Shader都革除了，从内存去看也没有这个，然而ShaderLab的占用还是有点大，当初在主场景有47MB。 A1：变体太多就会这样，认真看看那些很多关键字的Shader。感激deviljz@UWA问答社区提供了答复 A2：楼上说的对，分享一段几年前写的扫描工程Shader变体的代码，扫描一下，把Top前几的Shader改改就能降很多了。 [MenuItem("Find/GetAllShaderVariantCount", false, 20)] public static void GetAllShaderVariantCount() { #if UNITY_5_6 Assembly asm = Assembly.LoadFile(@"D:Program FilesUnity_5.6.5f1EditorDataManagedUnityEditor.dll"); System.Type t2 = asm.GetType("UnityEditor.ShaderUtil"); MethodInfo method = t2.GetMethod("GetComboCount", BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic); #elif UNITY_2017_1_OR_NEWER Assembly asm = Assembly.LoadFile(@"D:Program FilesUnity_2018.3.0f2EditorDataManagedUnityEditor.dll"); System.Type t2 = asm.GetType("UnityEditor.ShaderUtil"); MethodInfo method = t2.GetMethod("GetVariantCount", BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic); #endif var shaderList = AssetDatabase.FindAssets("t:Shader"); var output = System.Environment.GetFolderPath(System.Environment.SpecialFolder.DesktopDirectory); string pathF = string.Format("{0}/ShaderVariantCount.csv", output); FileStream fs = new FileStream(pathF, FileMode.Create, FileAccess.Write); StreamWriter sw = new StreamWriter(fs, Encoding.UTF8); EditorUtility.DisplayProgressBar("写统计文件", "正在写入统计文件中...", 0f); int ix = 0; sw.WriteLine("ShaderFile,VariantCount"); foreach (var i in shaderList) { EditorUtility.DisplayProgressBar("写统计文件", "正在写入统计文件中...", 1f * ix / shaderList.Length); var path = AssetDatabase.GUIDToAssetPath(i); Shader s = (Shader)AssetDatabase.LoadAssetAtPath(path,typeof(Shader)); var variantCount = method.Invoke(null,new System.Object[]{ s,true}); sw.WriteLine(path + ","+variantCount.ToString()); ++ix; } EditorUtility.ClearProgressBar(); //革除进度条 sw.Close(); fs.Close(); } 感激李星@UWA问答社区提供了答复 ...

创建包一个包就是一部分代码，它用于表示一部分功能。可以按需异步、并行加载包。与不使用任何代码拆分技术的应用程序相比，合理分包的应用程序可以显著提高响应速度，需要请求的字节数更少，加载的时间更短。在处理大型应用程序时，这一点尤其重要，因为这类应用程序的大部分表现层逻辑在初始化时是不需要加载的。 Dojo 尝试使用路由和 outlet 智能地做出选择，自动将代码拆分为更小的包。通常各个包内的代码都是紧密相关的。这是构建系统内置的功能，可直接使用。但是，对于有特殊分包需求的用户，Dojo 还允许在 .dojorc 配置文件中显示定义包。 默认情况下，Dojo 应用程序只创建一个应用程序包。但是 @dojo/cli-build-app 提供了很多配置选项，这些选项可将应用程序拆分为较小的、可逐步加载的包。 使用路由自动分包默认情况下，Dojo 会基于应用程序的路由自动创建包。要做到这一点需要遵循以下几条规则。 src/routes.ts 必须默认导出路由配置信息部件所属的模块必须默认导出部件Outlet 的 render 函数必须使用内联函数src/routes.tsexport default [ { path: 'home', outlet: 'home', defaultRoute: true }, { path: 'about', outlet: 'about' }, { path: 'profile', outlet: 'profile' }];src/App.tsexport default class App extends WidgetBase { protected render() { return ( <div classes={[css.root]}> <Menu /> <div> <Outlet key="home" id="home" renderer={() => <Home />} /> <Outlet key="about" id="about" renderer={() => <About />} /> <Outlet key="profile" id="profile" renderer={() => <Profile username="Dojo User" />} /> </div> </div> ); }}将会为应用程序的每个顶级路由生成单独的包。在本例中，会生成一个应用程序的主包以及 src/Home、src/About 和 src/Profile 三个包。 ...

翻译自：https://github.com/dojo/frame... Dojo 提供了一套强大的命令行工具，让构建现代应用程序更加简单。 可以自动创建包（Bundle），可以使用 PWA 在本地缓存文件，可以在构建阶段渲染初始的 HTML 和 CSS，也可以使用 Dojo 的 CLI 工具和 .dojorc 配置文件按条件忽略一些代码。或者脱离（eject） Dojo 的构建工具，直接使用底层的构建工具以做到完全掌控。 功能描述Dojo CLI模块化的命令行工具，用于快速启动新的应用程序、创建部件和运行测试等。开发服务器开发时使用的本地 web 服务器，用于监听文件系统，当检测到变化时会自动重新构建。也支持 HTTPS 和设置代理。包(bundle)通过减少用户需要下载的内容和优化用户实际需要的应用程序交互时间（Time-to-Interactive）以提高用户体验。可以根据路由自动创建包，或者在配置文件中明确定义包。按条件纳入代码通过 .dojorc 配置文件可以静态方式关闭或打开使用 dojo/has 定义的功能。由于这些配置而无法访问到的代码分支会被自动忽略掉。这就很容易为特定目标（如 IE11 或 mobile）提供特定功能，而不会影响包的大小。PWA 支持渐进式 Web 应用程序通过缓存内容甚至脱机工作，创建更快、更可靠的用户体验。通过配置文件或者在代码中定义，dojo 很容易创建一个 service work，并将其构建为应用程序的一部分。构建时渲染在构建时渲染路由以生成初始的 HTML 和 CSS。在构建时渲染，Dojo 可以节省出初始渲染的成本，创建出一个响应性更高的应用程序，且不会引入额外的复杂性。基本用法Dojo 提供了一组 CLI 命令，辅助创建和构建应用程序。本指南假设已全局安装 @dojo/cli，且在项目中安装了 @dojo/cli-build-app 和 @dojo/cli-test-intern。如果项目是使用 @dojo/cli-create-app 初始化的，那么这些依赖应该已经存在。 构建Dojo 的 CLI 工具支持多种构建目标或 mode。在 dojo create app 为 package.json 生成的几个脚本（scripts）中可看到所有模式。 运行以下命令，创建一个为生产环境优化过的构建。 > dojo build --mode dist此次构建使用 dist 模式创建应用程序包，并将结果输出到 output/dist 目录中。 ...

Knative 主要由 Build、Serving 和 Eventing 三大核心组件构成。Knative 正是依靠这三个核心组件，驱动着 Knative 这艘 Serverless 巨轮前行。下面让我们来分别介绍一下这三个核心组件。 BuildKnative Build 是基于现有的 Kubernetes 能力之上，提供的一套标准化、可移植、可复用的容器镜像构建方式。通过在 Kubernetes 上运行复杂的构建任务，Knative Build 使你不必再单独开发和重复这些镜像构建过程， 从而通过系统化、工程化的方式，减少了镜像构建时间及成本。 Build 通过 Kubernetes 自定义资源定义(CRD)实现。 通过 Build 你可以自定义一个从运行到结束的构建流程。例如，可以使用 Knative Build 来获取、构建和打包代码。Build 具备以下功能： 支持 Source 源挂载，目前支持的 Source 源包括： git 代码仓库任意容器镜像支持通过 BuildTemplate 创建可重复执行构建的模板支持 K8s ServiceAccount 身份验证典型的 Build 示意图： 虽然目前 Knative Build 并不提供完整的独立 CI/CD 解决方案，但它却提供了一个底层的构建模块，用户可单独使用该构建模块在大型系统中实现集成和利用。 ServingKnative 作为 Severless 框架最终是用来提供服务的， 那么 Knative Serving 应运而生。 Knative Serving 构建于 Kubernetes 和 Istio 之上，为  Serverless 应用提供部署和服务支持。其特性如下： ...

这是设计模式系列的第二篇——建造者设计模式，我希望推送的文章是一个系列的，尽量保持一样的写作风格，尽量把我理解的阐述清楚，关于建造者设计模式主要从以下几个方面来学习，具体如下： 概述本质关键概念具体实现总结概述建造者设计模式(Builder Pattern)属于创建型设计模式，主要用于创建复杂的对象，可将复杂对象的构建过程抽象出来，通过不同实现的构建者和装配者最终组装出不同的对象，可以非常方便的增加不同实现的构建者、组装者而不用修改以前的代码。 本质建造者设计模式(Builder Pattern)分离了对象子组件的构造过程和组装过程，实现了构建与组装的解耦，不同的构建器相同的组装顺序以及相同的构建器不同的组装顺序都可以创建出不同的对象，使得构建与组装充分解耦，进而实现构建算法与组装算法的解耦，从而实现更好的复用。 关键概念构建者(Builder)：构建不同的子组件且返回子组件或者提供获取复杂对象的方法，将构建过程抽象成接口或抽象类，方便扩展具体的不同的构建者。组装者(Dirctor)：通过某个具体的构建者构建相关的子组件，同时对外提供组成复杂产品对象的方法。当需要生成复杂对象时，直接通过某个具体的组装者获得想要的具体对象即可，至于组装过程与构建过程使用者不需要关心，分别由具体的组装者与具体的构建者内部完成。当然复杂对象可以理解为具有很多属性的对象。 具体实现下面以手机的组装过程来说明建造者设计模式的具体实现，产品类如下： /** * 产品 * @author jzman */public class Phone { private Screen screen; private Camera camera; private Cpu cpu; //省略getter、setter、toString 方法 //...}//子组件class Screen{ private String name; //...}//子组件class Camera{ private String name; //...}//子组件class Cpu{ private String name; //...}抽象的构建者： /** * 构建者 * @author jzman */public interface PhoneBuilder { Screen builderScreen(); Camera builderCamera(); Cpu builderCpu();}具体的构建者： /** * 具体的构建者 * @author jzman */public class MiPhoneBuilder implements PhoneBuilder{ @Override public Screen builderScreen() { System.out.println("构建屏幕..."); return new Screen("Mi-screen"); } @Override public Camera builderCamera() { System.out.println("构建相机..."); return new Camera("Mi-camera"); } @Override public Cpu builderCpu() { System.out.println("构建屏幕..."); return new Cpu("Mi-cpu"); }}抽象的组装者： ...

npm 的 scripts 下写的命令太多就很容易很乱，各种第三方轮子都只能解决一部分问题，总感觉不是很好用，想找个类似 make 的工具只能找到 jake, 可是 jake 的 API 太老，居然很多都不支持 promise, 代码也不多，就干脆自己造轮子了, 感觉效果还行。特点:基于 promise 的任务和内置工具函数(fs/shell), 无缝支持 async/await类似于 shelljs 的跨平台 shell dsl, 人人都会写 shell易学易用，无需为写仅仅几个 build 命令而花费几个小时去寻找和学习第三方包很小的安装成本foy: gulp: grunt: 无缝和第三方支持 promise 的工具包整合，不需要封装成插件就能用使用:安装yarn add -D foy # or npm i -D foy# Or Install globally withyarn add -g foy # or npm i -g foy在项目根目录下增加一个 Foyfile.js (或者 Foyfile.ts, 需要安装 ts-node)import { task, desc, option, strict, fs } from ‘foy’task(‘build’, async ctx => { await ctx.exec(’tsc’)})desc(‘Build ts files with tsc’)option(’-w, –watch’, ‘watch file changes’)strict() // This will throw an error if you passed some options that doesn’t defined via option()task(‘build2’, async ctx => { await ctx.exec(tsc ${ctx.options.watch ? '-w' : ''})})task(’task’, async ctx => { await fs.rmrf(’/some/dir/or/file’) // Remove directory or file await fs.copy(’/src’, ‘/dist’) // Copy folder or file let json = await fs.readJson(’./xx.json’) await ctx.env(‘NODE_ENV’, ‘production’) await ctx.cd(’./src’) await ctx.exec(‘some command’) // Execute an command let { stdout } = await ctx.exec(’ls’, { stdio: ‘pipe’ }) // Get the stdout, default is empty because it’s redirected to current process via stdio: 'inherit'.})然后就可以运行任务了# 安装在本地 node_modules 目录下npx foy buildnpx foy build1npx foy task # 安装在全局foy buildfoy build1 ...