上篇文章中实现了基本的打包功能,在这篇我们来解决不同平台打AB包的问题. 本篇文章的核心api还是: BuildPipeline.BuildAssetBundles (outPath, 0, EditorUserBuildSettings.activeBuildTarget); 在第三个参数中,只要传入不同平台 BuildTarget就可以了.目前只考虑Android和iOS平台. 区分iOS.Android平台 很简单,只要在上篇文章的QABEditor类中将原来的BuildAssetBund…

整理前的准备 到目前为止,我们积攒了很多示例了,并且每个示例也都贯彻了最的约定和规则. 在上一篇的小结也说了一个比较新的东西:编程体验优化. 在之前我们还积攒了一个问题:代码重复问题. 我们可是忍住整理的冲动忍了好久了. 所以现在也是时候准备着手整理了. 知识点和问题总结 遗留问题 我们写列出来之前记录的第一个问题: 第八个示例与之前的示例代码重复,功能重复. 这个问题想想就很好解决,只要删除掉第八个示例之前的示例就好了.但是怎么删和删完是否会破坏原来的功能?这两问题要具体看了代码才会知道.现在…

先列出上一篇的总结: 要做的事情: 备份:导出文件,并取一个合理的名字. 遗留问题: 第八个示例与之前的示例代码重复,功能重复. 约定和规则: 每个示例在 QFramework 目录下创建一个文件夹,文件夹的格式是: 数字.示例的功能 每个示例写一个脚本,脚本中包含可复用的静态方法和 MenuItem 方法. 每写一个示例进行一次导出,导出的文件名后边加上日期和时间,这个功能已经在导出功能里内置了. 示例分类: 知识学习&收集 API 收集 C# 语法实践 库本身的功能 规则实现 使用流程提供及…

昨天呢我们把第八个示例整理完了.整理之后学习了类的第一作用:方法的集合,还有 Obselete 这个 API.并且在进行整理的时候贯彻了我们新的约定和规则:先确保功能有效,再去做变更和删除. 今天我们在往下接着整理第九个示例 第九个示例 using UnityEngine; #if UNITY_EDITOR using UnityEditor; #endif namespace QFramework { public class ResolutionCheck { #if UNITY_EDITO…

在前两篇,我们把所有的示例重头到尾整理了一遍. 当前的状态如下: 要做的事情: (完成) 备份:导出文件,并取一个合理的名字. 遗留问题: (完成) 第八个示例与之前的示例代码重复,功能重复. (完成) 方法所在类的命名有问题. 菜单栏显示顺序问题. 弃用的代码警告 约定和规则: 每个示例在 QFramework 目录下创建一个文件夹,文件夹的格式是: 数字.示例的功能 每个示例写一个脚本,脚本中包含可复用的静态方法和 MenuItem 方法. 每写一个示例进行一次导出,导出的文件名后边加上日期…

Unity 游戏框架搭建 2018 (二) 单例的模板与最佳实践 背景 很多开发者或者有经验的老手都会建议尽量不要用单例模式,这是有原因的. 单例模式是设计模式中最简单的也是大家通常最先接触的一种设计模式.在框架的设计中一些管理类或者系统类多多少少都会用到单例模式,比如 QFramework 中的 UIMgr,ResMgr 都是单例.当然在平时的游戏开发过程中也会用到单例模式,比如数据管理类,角色管理类等等,以上这些都是非常常见的使用单例的应用场景. 那么今天笔者想好好聊聊单例的使用上要注意的问…

在上一篇我们整理到了第七个示例,我们今天再接着往下整理.我们来看第八个示例: #if UNITY_EDITOR using UnityEditor; #endif using UnityEngine; using System; using System.IO; namespace QFramework { public class PreviousFunctions : MonoBehaviour { public static string GenerateUnityPackageName(…

在前两篇,我们把所有的示例重头到尾整理了一遍. 当前的状态如下: 要做的事情: (完成) 备份:导出文件,并取一个合理的名字. 遗留问题: (完成) 第八个示例与之前的示例代码重复,功能重复. (完成) 方法所在类的命名有问题. 菜单栏显示顺序问题. 弃用的代码警告 约定和规则: 每个示例在 QFramework 目录下创建一个文件夹,文件夹的格式是: 数字.示例的功能 每个示例写一个脚本,脚本中包含可复用的静态方法和 MenuItem 方法. 每写一个示例进行一次导出,导出的文件名后边加上日期…

我们在整理阶段解决了一些意外的问题.但是这些问题仅仅只是被解决而已,我们并没有去思考过这些问题是为什么产生的?以及在以后我们如何去避免这些问题的产生? 方法所在类的命名问题,最后我们通过方法分类解决了,并且学习了类的第一作用:方法的集合. 解决之后导致了大量的弃用代码,为了标记弃用代码,我们又简单学习了 System.Obselete 这个 API. 这样的意外问题真是好啊,可以让我们一下学习很多东西.不过如果在工作中或者做项目中全是意外问题,而身边又没人知道这么解决,那么每天肯定都会过得非常辛…

applicationContext.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:p="http://ww…