业务模块的通信框架设计
大型项目通常都采用了模块化的架构设计,这样就需要设计一些机制来实现模块间的通信和交互,下面会从最简单的实现开始讲起,然后依次介绍两类通信方式的实现思路和区别。
单例模式是一种很常用的设计模式,下面介绍了单例模式的几种应用场景,然后以C#为例给出标准且可靠的实现方式,最后通过Q&A的方式解释一些疑问,便于理解单例模式的实现细节和背后深层次的原理。
在开发Android应用的过程中,常常需要用到数据持久化技术,Android操作系统提供了内部存储和外部存储两种方式,分别对应文件系统下不同的存储目录,可以参考官方文档https://developer.android.com/training/data-storage,下面介绍二者的用途和区别。
本文介绍几种常见的workflow,包括经典但繁琐的gitflow
、简单而敏捷的github flow
、相对折中的gitlab flow
,并简单介绍特性分支开发模式和主干开发模式的适用场景和优劣。
软件项目的版本号可以采用四段式a.b.c.d
,但是d构建版本号只有在内部才会使用,一般对外不可见,所以对外发行的软件版本一般都是采用经典三段式,参考https://semver.org/lang/zh-CN/。
游戏客户端的后门指的是游戏客户端的GM工具,其表现往往是一个内置控制台,该工具往往会随着游戏安装包一起发布,但是对于正常玩家来说是屏蔽状态,只有通过特殊的方式才能打开。对于网游来说,控制台的功能主要是用来进行真机调试,包括实时查看日志、快速执行脚本、修改性能选项、查看机型信息等。虽然它叫做”后门”,但其功能并不敏感,也基本不会影响数据安全,所以相对于后台GM工具,不需要进行严格的权限管理。
游戏客户端的版本号目前主流都是四段式a.b.c.d
,但是和传统的软件版本号不同的是,游戏客户端的版本号常常是由两部分组成的:分别为程序版本号(AppVersion
)和资源版本号(ResVersion
)。因为不同于传统软件,游戏软件的运营需要快速更新迭代游戏内容,而如果每次更新客户端都要重新安装,对于玩家来说体验不佳,对于游戏开发商来说也很麻烦(尤其是手游,需要提交到各应用商店审核)。所以在需要发布新的游戏版本内容时,游戏客户端的更新策略更倾向于仅热更新游戏资源(即保持程序版本号不变,仅更新资源版本号),只在必要的时候才会更新程序版本号。
shell-lab是csapp的配套实验之一,它要求我们实现一个功能和unix shell类似的tiny shell,在源文件tsh.c中已给出了基本框架,剩下的只需要完成实现指定的函数即可,该实验对应csapp的第8章内容。