聊聊自己

”我热爱的是做游戏,相对于玩游戏,我知道这两者的差别 …“

这,是我来北京找工作,面试时自我介绍的开头。


不知不觉,已经工作五年,经历了三家公司,做过五六个项目,一步步,算是摸爬滚打的过来了。

聊聊过去,聊聊自己。



启蒙

上大学前,并没有接触过编程。

仅有的经验只是金山打字通的打字练习、做PPT,管管教室电脑(就是开关机);噢,当然还有打游戏。

大一初识C++,经典的谭浩强老师的 《C++程序设计(第二版)》,拿着忘了从哪蹭的100道经典C++练习题,一顿猛敲。

大二,就拉了个团队去做个游戏,学了点C++的皮毛,就准备撸起袖子大干一场,正好有个齐鲁软件大赛,正好有个手机游戏项目,正好就拉了几个人,一个暑假都在学校奋斗,还好,没有半途而废,算是一个完整的游戏吧?。。

后来,加入仰慕已久的ACM实验室,开始撸题。

后来,没有考研,决定就业。




感悟

游戏开发

从第一份工作到现在一直是在做手机游戏,一直用的是Cocos2d引擎来开发,有接触了解,也做过一些Creator、Unity的Demo,但真正工业级的项目没有碰过。

在我所经历过的各家公司,也各有特色与偏重,没有同质性的公司。

我目前的理解,做游戏(仅客户端而论),可以先大概分为两部分:

  • 游戏;每一行代码都能在游戏中体现,为游戏内容品质服务。
    • 基础组件
    • 中间件
    • 业务功能
  • 产品;项目从立项到上线,所额外负责的工作。
    • 版本控制
    • 打包、SDK接入
    • 跨平台扩展
    • 更新机制
    • 游戏优化
    • 统计反馈
    • 测试支持

游戏

游戏开发中,所做的每个改动,都可以在游戏中直接表现出来。

我把游戏分为三个部分,各部分所重视的角度不同:

  • 基础组件;基础组成部分,一般涉及到自研底层代码及引擎底层代码,相对重视效率与性能。
  • 中间件;为业务功能研发做中间转接口,将基础组件拼接组装或封装调整,相对重视通用性及便携性。
  • 业务功能;实现各种需求,直面用户,相对重视灵活性。

在开发的时候,明确并了解所开发的模块属于哪个部分,从而知晓它的重点偏向。

比如,开发业务功能,更重视灵活性,多与需求方沟通,了解他们的本意,不要厌恶、恐惧变化,甚至要拥抱变化,以 “任它需求千万变,不如我代码灵活又简便” 为目标。

再比如,如果开发基础组件,理论上,不应该为了使用方便,而去牺牲它的执行效率。


产品

这部分可能跟游戏的实际开发无关,但是却是完整的产品必经之路。

这些部分或许与游戏的品质等无直接相关,但是会直接影响团队的研发效率。就如同产品与包装的关系,包装不代表产品品质,但是好的包装亦能影响用户心中的价值。要不然,月饼、白酒的包装会越来越华丽呢?

这部分的特点是 简单繁琐涉及广度大一次就好

  • 简单繁琐;很多简单且繁琐的事情,相对于技术可能更考究细心与耐心。
  • 涉及广度大;一般涉及的范围很大,虽不至于天文地理,但也基本和项目的开发截然不同。
  • 一次就好;基本实现一次就好,不需要频繁迭代维护,甚至不维护。

这些特点,导致这部分的内容,更像一个苦差事。但随着各种自动化工具、集成工具的发展,完全可以把这些内容脚本化,进而可视化、自动化,慢慢的就会找到这部分的乐趣,能把一堆繁琐的东西理的井井有条,还是很有成就感的。

有一点要谨记,做好文档,做好规范。



软技能

很多行业慢慢由增量时代转入存量时代,做开发亦是如此。

由于模块拆分的越来越细,第三方的服务越来越多广泛且专业,导致开发一个产品的门槛越来越低。

不能再像以前那样,闷头只钻研技术,而忽视软技能的发展。我不否认依旧有很多硬靠技术吃饭的人,但我知道,我不是。

技术&软技能,就像一块木板的长和宽;最终拼的是面积,而不是单纯的长或单纯的宽。但不要因噎废食,过于注重软技能而忽视技术;要做的是以技术为基础核心,同时也注重软技能的发展。

沟通

沟通是一门很大的学问。

小的来说,沟通可以简单分为:

  • 向上沟通
    • 向上级汇报
  • 向下沟通
    • 向下级安排任务
  • 跨界沟通
    • 向其他部门咨询或请求援助

其实,不仅仅是说话,所写的文档、代码等,也都可以算是沟通的一部分。

沟通的目标是让别人理解你的观点,或者是理解别人所表达的内容。无论哪一个方面,都需要换位思考,并且有事直问,不要妄加揣测。


主人翁

全心全意去做当前所做的项目。(我可没说把公司当成自己的家。不一样吗?你品,你细品!)

不要只做自己该做的,剩下的高高挂起。

原因如下:

  1. 早晚都要自己带团队做产品,与其到时抓破头皮,不如早做准备。
  2. 看的越多越仔细,会发现一些不曾注意到的细节,都是知识,都是财富。
  3. 有时候,编程也是门经验学科,有很多坑早晚都要踩过一遍就知道,踩得越晚,坑越深。
  4. 给上级一个让你晋升的理由。

在开始,大家都是消费者,但可以慢慢成为一名生产者,产出对团队有利,对自己又何尝不是。

一方的利益获得不一定伴随着另一方的利益损失,世界上有很多多赢的事情,只要利益的获得满足自己的预期即可。

体会一句话:你可能血赚,但我绝对不亏。


一个咖啡杯的故事

真人真事,在一个早上,我去便利蜂买杯咖啡,它们就是那种自助咖啡机,排在我前面的人,并没有放置咖啡杯,就开始扫码结算,这时我可以

  • 提醒他,让他先放杯子。
  • 不提醒他,让他自生自灭。

选择不提醒,最好的结果是,机器检测到没有放咖啡杯,然后提示放咖啡杯;最坏的结果是,机器直接出咖啡,客人手忙脚乱拿咖啡杯去硬放,烫伤自己,然后…。

选择提醒,就一句话的事情,可以避免很多事情;即使对我自己而言,也节省了我的时间,否则按最坏打算,我的这杯咖啡,什么时候能拿到呢。

其实,这个现象就跟团队内的合作沟通一样,很多东西提前通知,做好预备,往往一句话的事情,可以其他人很多的弯路,对整个项目而言,必然有利而无害的。




方向

工作这些年,早期,基本花了很多的时间花在摸索上,更多的关注在如何做一个完整的项目,也就是俗话中的深度和广度中的广度。

现在,对这一行有了大概的认知与理解,更需要的是去进阶一些深一层的东西。就像之前的策略 以技术为主,软技能为辅的发展一样,在技术中也要找到一个专精领域,再以其他领域为辅去进行进一步的发展。

然后,技术上很多东西是相同的,没有必要把自己局限于某个角色,在不同的角度思考问题,会发现不同的内容。

最后,依旧是那句话,屁股决定脑袋。所在的位置,利益诉求,会影响信息、判断与决定,每个人的阅历、想法不尽相同,不需要逼迫着所有人 思想的统一、行为的统一。

准则

专业的事情交给专业的人,简单繁琐的事情交给脚本,留出时间做重要且核心的事。

目标

不做总线,做一个被自己替代的人。

总线,是必不可少的组件;它的阻塞会导致系统无法运行。

但有的时候,有些总线就没必要存在。

一个例子:

之前在生成 Android包及热更的时候,必须由开发来执行。

大概流程是这样的:

  1. A想要包测试内容
  2. 告知开发出包
  3. 开发出包完成,交给A

这样有诸多弊端:

  • 出包占用开发电脑资源,影响开发原有功能开发
  • 由于出包不便,必然会减少出包测试的请求,整体上讲对项目不利
  • 期间有多个交接口,无法查进度,隐性所需时间拉长。(比如A告知开发出包,开发是否立马去出包,或者忘记出包等)
  • 在忙碌的时候,手抖导致出包错误,重新出包
  • 等等

这个流程中,开发就是总线,但是这个总线是必要的吗?显然不是。

于是,采用一些方法去把总线替换掉:

  1. 将出包相关脚本化、自动化
  2. 使用Jenkins实现接口暴露及工作空间共享

这样,出包的流程变为:

  1. A想要包测试内容,登录内网jenkins地址,根据需求出包
  2. jenkins出包
  3. A从jenkins空间中拿包

这样,开发从这个流程脱离出来,并且对于A有更多的配置选项可以配置,更为便捷,同时,出包进度也可视化,更有利于减少隐性时间消耗。

当然,这只是简单的一步,为了让它更加可靠且易用,必然要经历大量测试并且有一些预警机制,每隔一段时间进行使用者的反馈来扩展功能。

这只是简单的关于总线的例子,其实很多东西,都是表面上的总线,就如同那句话:

世界正在变得越来越自动化。因此我认为,并非每个人都需要学习编程,而是每个人都需要学习和理解如何实现自动化。—— 《Don’t Learn to Code — Learn to Automate》




未来

未来,谁都不知道会怎么样。

能做的就是总结过去经验,把握当下。

确定长目标与短目标,以一年或关键时间点为期,进行总结,看是否在既定的路上前进。

重视并珍惜每一个机会,每一个项目,只有在总结的时候才去考虑收益的事,剩下的期间全心全意的去做事。

多想多讨论多实践多总结,步入一个良性的循环。

然后,多读书,保持健康。





引用内容:

<think>嗯,用户让我聊聊关于FreeRTOS。首先,我需要确定用户对FreeRTOS的了解程度。可能他们刚开始接触嵌入式系统或者实时操作系统,想了解基本概念和应用。FreeRTOS是一个开源的实时操作系统内核,广泛用于微控制器,所以应该先介绍它的基本特性和应用场景。 接下来,我应该解释FreeRTOS的核心功能,比如任务调度、内存管理、通信机制等。用户可能想知道它如何实现实时性,比如任务优先级和抢占式调度。这部分需要详细说明调度器的类型,比如使用最广泛的抢占式调度器,以及协程调度器的适用场景。 然后,内存管理方面,FreeRTOS提供了多种分配策略,需要解释heap_1到heap_5的不同之处,以及用户如何根据需求选择。这可能涉及到静态和动态内存分配的区别,以及在不同嵌入式系统中的资源限制问题。 通信机制也是关键部分,括队列、信号量、互斥量等。要说明它们的作用和使用场景,比如任务间同步和数据传递。互斥量用于资源保护,防止优先级反转的问题,这里可能需要提到优先级继承机制。 另外,软件定时器和中断处理也是用户关心的点。需要解释定时器的回调函数如何执行,以及中断服务程序中的API限制,比如哪些函数不能在ISR中使用。 用户可能还想知道FreeRTOS的移植性,支持哪些架构,以及配置选项,比如通过FreeRTOSConfig.h文件调整功能。这部分需要提到裁剪系统以适应资源有限的设备。 最后,应用场景方面,列举一些具体的例子,比如工业控制、物联网设备,帮助用户理解实际使用情况。可能用户有项目需求,想评估是否适合采用FreeRTOS。 在代码示例部分,给一个简单的任务创建和队列使用的例子,帮助用户直观理解如何编写FreeRTOS程序。确保代码正确,并注释关键部分,比如任务函数、队列创建和发送接收操作。 相关问题需要覆盖基本概念、组件、移植、配置和常见问题,这样用户可以根据自己的需求进一步深入。比如,任务状态转换、优先级反转解决方法、内存分配策略比较,以及中断处理的注意事项,这些都是学习FreeRTOS时常见的问题点。</think><< FreeRTOS是一个开源的实时操作系统(RTOS)内核,专门为嵌入式系统和微控制器设计。以下是其核心特性和关键概念: --- ### 1. **核心功能** - **任务调度**:支持抢占式、协作式和时间片轮转调度,基于任务优先级分配CPU时间。 - **内存管理**:提供静态/动态内存分配策略(如`heap_1`到`heap_5`)。 - **通信机制**:通过队列(Queue)、信号量(Semaphore)、互斥量(Mutex)和任务通知(Task Notification)实现任务间通信。 - **低功耗支持**:提供Tickless模式以降低功耗。 - **软件定时器**:允许创建周期性或单次触发的定时器。 - **中断管理**:与硬件中断紧密结合,支持中断嵌套和中断安全API。 --- ### 2. **任务管理** - **任务创建**:通过`xTaskCreate()`或`xTaskCreateStatic()`创建任务。 - **任务状态**:运行(Running)、就绪(Ready)、阻塞(Blocked)、挂起(Suspended)。 - **优先级**:数值越大优先级越高(0为最低)。 ```c // 示例:创建任务 void vTaskFunction(void *pvParameters) { while(1) { // 任务逻辑 vTaskDelay(1000 / portTICK_PERIOD_MS); // 阻塞1秒 } } int main() { xTaskCreate(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL); vTaskStartScheduler(); // 启动调度器 return 0; } ``` --- ### 3. **通信与同步** - **队列(Queue)**:传递数据或同步任务。 - **信号量(Semaphore)**: - 二进制信号量:资源互斥访问。 - 计数信号量:管理多个资源实例。 - **互斥量(Mutex)**:防止优先级反转,支持优先级继承。 ```c // 示例:队列使用 QueueHandle_t xQueue = xQueueCreate(5, sizeof(int)); // 创建队列 // 发送数据 int data = 42; xQueueSend(xQueue, &data, portMAX_DELAY); // 接收数据 int received_data; xQueueReceive(xQueue, &received_data, portMAX_DELAY); ``` --- ### 4. **内存管理** - **静态分配**:编译时确定内存大小,通过`pvPortMalloc()`和`vPortFree()`管理。 - **动态分配**:支持多种堆实现(如`heap_4`适用于碎片敏感场景)。 --- ### 5. **中断处理** - 中断服务程序(ISR)需使用`xxxFromISR()`结尾的API(如`xQueueSendFromISR()`)。 - 通过`configMAX_SYSCALL_INTERRUPT_PRIORITY`配置可屏蔽中断优先级。 --- ### 6. **应用场景** - 工业控制(PLC、传感器) - 消费电子(智能家居设备) - 物联网(低功耗传感器节点) - 汽车电子(ECU单元) --- ### 7. **移植与配置** - 支持ARM Cortex-M、RISC-V、ESP32等架构。 - 通过`FreeRTOSConfig.h`文件配置内核功能(如任务数量、堆大小)。 --- ### 8. **优势与局限** - **优势**:轻量级(内核仅10KB)、可裁剪、社区活跃。 - **局限**:无图形界面或文件系统(需依赖第三方库)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值