潘爱民博士生于 70 年代，起于 BASIC 编程，师从汉字激光照排系统之父王选院士，从北大计算机研究所、微软亚洲研究院到任职盛大创新院专家顾问，又先后任阿里 YunOS、阿里安全、飞猪、阿里业务平台首席架构师，进入物联网时代创立指令集深耕并亲自主导物联网操作系统研发，历经中国互联网行业从星火到移动、AI、大数据、IoT 等各种燎原，几乎可以算作是中国互联网发展的一大缩影。
浮生多变化，万事有盈虚。当国内程序员们忧于「35 岁职业坎、45 岁屈服现实、55 岁就得隐退」之时，透过潘爱民博士的 30 年程序人生，我们不仅能够看到一个中国第一代程序员死磕技术，又深邃思考技术如何落地与产业融合，更能从他的身体力行中看到，后浪奔涌，老兵如何不息!
潘爱民
我第一次写程序人生是2000年，当时有很多编程实践，刚刚开始有系统性的思考;第二次是2010年写了我的成长故事(发表在《程序员》杂志上)，当时即将从微软亚洲研究院毕业，准备进入国内工业界。到2020年，又10年过去了。回顾这10年，我一直在工业界努力，经历了三家公司：盛大、阿里巴巴和杭州指令集，亲历了移动互联网的发展，以及物联网时代的兴起。
在计算机技术飞速发展的年代，10年是一个很大的跨度，足以发生翻天覆地的变化。我有幸在正值壮年之际，又一次经历了中国互联网产业的蓬勃发展。本文记录我在这10年中的职业经历、技术感悟，以及从技术转向业务、与产业融合的实践与思考。
职业经历
2010年夏天，我离开微软亚洲研究院，踏上了南下到上海的旅程，加入盛大创新院。当时的感受是，在经历过北京大学的教学科研以及微软亚洲研究院的系统研究以后，非常渴望回到国内的企业或机构进行基础软件的研发。经过多方考察，我选择了盛大创新院作为职业生涯的下一站。
对于程序员来说，盛大创新院是一个理想的创新机构，有老板的大力支持，有大量互联网人才，正赶上移动互联网蓬勃发展的大好时机。有一批优秀的项目脱颖而出，涉及到语音、短视频、云计算、云笔记、LBS、智能手机等很多领域，其中有不少项目在盛大创新院解散以后还在延续并且做成功了。
当时我带领的方向是移动操作系统——VisionOS。为什么要做移动操作系统，以及如何做、技术路径如何选择，这是在立项阶段反复思考和推敲的问题。我至今认为，那是发展自有移动操作系统的最佳时期，Android尚未占据市场垄断地位，并且Android手机的体验和性能离iOS还有显著差距，自研系统有机会快速赶上来。
VisionOS的技术架构跟Windows比起来，简化太多了，所以我在VisionOS的架构设计与技术选型上都能得心应手。得益于盛大创新院良好的技术创新氛围以及相对优厚的待遇，我组建了一个非常优秀的团队，有玩Linux的，有精通图形引擎的，有精通软件工程的，有精通多媒体编解码的，也有擅长系统安全的，共十多个人，用一年多时间建立了一个性能优异的基于Linux/WebKit的移动操作系统。
我从一开始就没考虑跟Android兼容，而是走自建生态的道路。VisionOS从立项到决定解散，差不多两年时间，对我来说，就像一次创业经历，做出了一个原型系统，但未能实现商业化。
2010年潘爱民在盛大创新院
离开盛大创新院，我休息了两个月，拿到了华为和阿里巴巴的操作系统首席架构师的Offer，最终命运使然，2013年初，我来到杭州，加入了阿里云OS。
当时阿里云OS是阿里云下属的一个部门，所以，确切来说，我加入了阿里云。杭州是我家乡的省城，一向以风景优美著称，当时还算不上互联网技术人才聚集地，但我时有耳闻，很多前端工程师经常在杭州聚会，技术的氛围正在浓厚起来。
我在阿里巴巴工作了将近六年，主要分三个阶段：云OS(后更名为阿里YunOS)、集团安全部，以及飞猪和业务平台部。在云OS工作的两年间，正赶上云OS蓬勃发展的时期，从一个以Android BSP为基础的兼容Android应用的移动操作系统，演变为一个自主移动操作系统。
作为云OS首席架构师，最大的挑战是确定新的架构，并且推动各个开发组接受新的架构。我同时也带领了核心系统模块的研发组。基于盛大VisionOS的研发经验和教训，我在设计新架构以及核心模块的技术选型方面，有足够的把握让新的云OS符合未来发展。
两年间，云OS技术团队已经非常强大了，聚集了国内大量的系统工程师。我一心想做成云OS，然而，天时、地利、人和很难三者得兼，最终我还是放弃了继续努力，转到了阿里巴巴安全部。
当时正赶上阿里的电商业务全面从PC互联网转向移动互联网，安全能力也势必要跟着升级。我一方面支持阿里业务的移动安全，另一方面带领一个架构师团队来梳理和重构阿里巴巴的安全体系。经过两年的安全领域实践以后，我希望能到业务部门学习和锻炼，于是选择了阿里飞猪。我认为这是一个小而美的业务部门，既有平台属性，也有行业属性。虽然飞猪的业务体量相对淘宝和天猫的总量小得多，但旅游是一个发展中的行业，业务空间大，创新的机会也多。
最后赶上中台战略下的部门调整与合并，我来到了业务平台部门。我突然发现，加入阿里巴巴时满怀着做成一个移动操作系统的梦想，但现实中却发展成为了企业中的老白兔。结合自己最后两年对于业务的认知，以及物联网行业发展的判断，也感受到杭州这块互联网热土，最终我决定离开阿里巴巴，建立一家创业公司。
在杭州，从阿里巴巴出来创业的前员工是一个广泛的群体，并且不乏成功者。我估计杭州一半以上的科技创业公司的合伙团队中都有前阿里员工的身影。在这样的群体氛围中，我选择出来创业，也就丝毫不奇怪了。
我创立指令集有两个初衷：
早在2005年，我就选择了将来往系统技术方向发展，当时还在微软亚洲研究院工作。我的想法是，在微软工作最有价值的，应该是钻研Windows操作系统，这是独有的机会，所以我从Windows性能诊断分析作为切入点，研究Windows的内部机理，将Windows线程调度、内存管理、I/O等最核心的模块剖析了一遍，并形成了一套系统性的诊断方法。有了这些基础以后，我又进一步考虑应用层的性能问题，以浏览器的渲染引擎作为研究对象，分析渲染引擎的整个计算过程，挖掘可优化的空间。核心的思想是，在计算流程中尽可能把重复的计算移除掉，从而保持整个响应过程的高效。这些研究工作为我后来做操作系统打下了扎实的基础。
2010年，我在盛大创新院有机会设计一个新的移动操作系统VisionOS。基本的思路是，在移动设备上，用Linux加一个Web渲染引擎来支撑一个Web运行环境(Web Runtime)，既可以运行本地的Web应用，也可以运行在线应用，并且通过插件的形式运行Flash控件。我调研了Linux平台上可使用的各种图形软件，最终决定自行开发一套适合于移动设备的图形库，与WebKit高效对接。Linux社区有许多开源的图形库，也有像Qt这类比较成熟的跨平台图形窗口系统，但它们首先为了兼容性的目的牺牲了效率，其次为了提升效率又做了很多优化，从而软件变得很复杂。在移动设备上不需要复杂的图形功能和窗口管理能力，我当时的想法是，借鉴Windows图形窗口系统的思想，简化到极致，只需要基本的图形能力和简单窗口管理，就可以支撑VisionOS的底层图形需求。移动应用内部的控件管理由WebKit自身来完成即可。
在当时的智能手机硬件环境下，要想做到流畅的触控体验，必须进行深入的优化，其中有一点至关重要，把芯片的图形加速能力启用起来。由于我们选择了原生的Linux系统，C库采用glibc，那就要找到芯片厂商提供的硬件加速库，才能完成这一优化。然而我接触了四五家芯片厂商，发现当时的移动芯片厂商基本上只提供Android的BSP，几乎不再提供Linux BSP，除非有足够采购量来提出特殊需求。在没有得到芯片厂商支持的情况下，我们做了一个高难度的折中方案，将Android BSP中的硬件加速库移植到VisionOS中，也就是说，将非glibc环境下的一个二进制代码库链接到glibc中，供上层模块调用。我团队中的同事足够优秀，将这些工作做得很漂亮，VisionOS比当时同机配的Android系统要明显高效，并且也很稳定。
跨进程通信是一个操作系统非常重要的能力，它让应用与应用之间、应用与系统之间便捷、高效地相互调用功能。系统底层往往有很多琐碎的细节要处理，包括应用数据到底层二进制数据的转换、共享缓冲区的管理等。作为一个面向终端用户的操作系统，必须要提供一套便于开发者使用的跨进程通信机制。VisionOS选择了自研方案，在Linux提供的跨进程通信基础上包装了一套可解析应用语义的系统机制。(Android对应有一套binder机制，用于应用与系统、应用与应用之间进行通信。)
除了支持Web应用和Flash内容，我们也移植了一些Linux原生应用。此外，有几个系统应用(包括桌面和相册应用)也是原生开发的。在当时的硬件条件下，Web版本的相册应用与原生版本的相册应用有显著的性能差异。因此，对原生应用的支持也是VisionOS的一个特点。事实上，我调研了当时Android手机上的某一家应用市场中排名前一千个Android应用，大部分应用包含了原生版本的核心模块(譬如图形处理、多媒体处理、重力模型、加解密等)，Java代码只是搭建了应用的框架而已。这些核心模块是以.so文件格式打包在应用发行包中，导致非ARM处理器的其他手机或移动终端根本用不了这些应用。我曾经接触过一家MIPS芯片商，尽管他们也支持Android操作系统，但当时环境下他们的终端设备无法直接运行市场上的这些Android应用。
我做移动操作系统将近五年时间，先是做了VisionOS，后来两年又做了云OS，在技术发挥上可谓淋漓尽致，但遗憾的是，因为种种原因没有真正意义上建立起一个移动操作系统的生态。而随着Android系统越来越先进，其生态粘性越来越强，再要建立一个对标的移动操作系统，可能性微乎其微了，除非某种特定的产业结构需求出现。
胡适曾经在赠给大学生的文章中提到“总得时时找一两个值得研究的问题”。作为IT技术人，虽然已经离开学校，但身处快速发展的产业中，更应该时时思考一些问题。下面列举一些我在过去十多年曾经思考过或实践过的技术题目。
反汇编是逆向工程的基础，但是在x86二进制可执行文件中，反汇编难以做到100%正确，原因是代码段中总有一些空隙，并且指令又是变长的，按顺序反汇编很快就会丢失线索。我改变思路，从原始的程序入口和符号表线索入手，层层递进，不断挖掘新的线索;若没有确定性的线索了，我们再从未反汇编的代码区找出疑似的线索进行尝试，直至代码段全部反汇编出来。最终实验的结果非常理想，比商用的反汇编器达到的覆盖面还要大。在调试过程中，我们也见识到某些商业软件使用花指令(很少听说吧)做了代码混淆。
这是一个异想天开的主意，原始的想法是，既然计算机的本质是计算，每天有大量的计算在不断发生，其中必定有大量的计算是重复的，对于重复的计算，是不是只要算一次，下次直接查表就可以了。进一步的想法是，只要在云端部署一个大计算机，所有的计算都交给云端查表来完成。这其实也是函数式编程的思想，但我们不知道如何框定一个可计算的范围。这种想法也仅限于想想而已。这一思路我和实习生后来用在Web渲染引擎的性能优化上，把渲染树上的重复计算识别出来剔除掉，确实能显著提高渲染性能。
一个安全问题的解决办法。
有一次碰到一个做云安全的朋友，想在云主机里加一些防护措施，但他的方案和思路没有得到技术老大的认可。后来，一支烟的功夫，我跟他讨论了这个方案，如何把风险降到最小，尝试着建立一个最小的代码基让技术老大审核。功能性的代码可以动态加载。据说后来这个方案被接受了。这个方案就是Windows保护模式的变种，也是一些安全软件采用的手段。
坐车或开车的时候经常等红灯，脑子里就想着是不是合理，能不能优化;等电梯也是如此。终于今年4月份我在查阅了一些专业论文以后，系统性地整理了一下思路，将一路绿灯作为目标，进行了概率意义上的分析。并且，进一步以减少停车次数为目标，在红绿灯不能控制的情况下，是否通过控制车速来做到车协同路，变相地实现车路协同。
计算使这个世界的运行变得更加高效，我们的生活也为之发生变化。电脑的计算只是低级(机械)的计算，人脑的才是最聪明的计算;把平时的闲暇时刻用来做一些发散性的思考，说不定会有意外的收获。曾经有一位我很尊敬的老师说过，脑子越用越灵光，对此我深信不疑。程序员受编程思想的影响，平时的思考往往是程序化的，我也逃不脱这种思维的禁锢。
职业成长
在10年以前，我还是纯粹的技术人，以深入钻研技术为乐趣。最近这10年，我的职业生涯发生了很大变化。其中最重要的是，开始接触业务，贴近业务，并且也开始思考产业，最终走向了技术创业。
我的经历是一段极其缓慢地从纯技术岗位走向业务的过程。先是在学校里工作，我职业初期做过一个地图编辑产品，并进一步搭建地理信息系统，但很快就走上了教学科研岗位，脱离了业务需求。接着在微软亚洲研究院工作，比在学校里还纯粹钻研技术。这是一段非常幸福的时光，大部分时间可以海阔天空地思考技术，做实验。能做成原型就不错了。
进入工业界做移动操作系统和安全保障这一阶段开始接触业务，前者需要运营一个移动操作系统，后者要支撑阿里移动业务的安全。实际的需求来自于运营方或业务方，我的职责是做好技术和实施方案。如果把这些工作也看成业务的话，则它们属于后台支撑性的业务。
我在阿里后期阶段的工作跟业务(旅行电商)结合越来越紧密，也参与一些业务发展会议。除了做一些技术决策以外，还需要在业务需求基础上平衡和分配技术资源。如果有人问我，在阿里最值得学习的是什么，我的答案是阿里做业务的方法，包括如何制定目标、拆解目标，以及如何运营一个业务(特别是利用数据来运营业务，这是阿里的优势)。 虽然很多书或者文章也会讲这些方法，但再多书面的学习都抵不上亲身参与一个业务周期更为有效。
能将自己的工作融入到一个产业中，这是扩大视野最好的做法。有些技术或产品天然要从产业的角度来看待，操作系统就是这样的典型产品。做移动操作系统要结合移动互联网产业的发展来思考，上游有芯片厂商，下游有手机厂商和移动服务商，可能中间还有设计公司或系统服务商。
2012年我曾经访问过多家移动芯片厂商，了解到芯片厂商对于移动操作系统的态度和技术支持，知道自研独立系统的困难，并且从一些关键点上探索可能的技术方案。另外，通用市场和垂直领域各有不同的要求，其对应的产业链不一定是相同的。最终如何形成生态，包括硬件产业的生态、移动应用的开发者生态，决定了一个移动操作系统应该使用什么架构、如何运营。
2018年我转到物联网领域，再次赶上了一个快速发展的产业。尽管物联网被提出并发展有很多年了，但是其发展空间仍然广阔。我们在各行各业都能看到设备在联网和升级，智能家居、汽车、监控摄像头、空调、电梯、人车通行道闸、工业生产设备等等，都以各种方式连接上网络。
基于对众多设备连接网络的技术路径和整体软件结构的分析，我认为除了设备上的操作系统，还需要一个针对物联网场景的系统软件，它解决该场景中的设备连接和数据共享的需求，让这些设备形成一个整体来协同工作。
从物体联网的角度来讲，这才是真正的物联网操作系统。产业界既有的做法是建立共享的物联网平台，然而大量的业务场景中这种共享平台并不能满足需要;另一方面，在许多业务领域中已经在以各种方式来解决设备连接和数据共享的问题，但往往是一些局部的非通用方案。
从2018年我选择了加入创业大军，最深刻的体会是：离开大平台了，你就什么都不是了。经历了两年不到的创业历程，说几点感悟：
这一步是把创业的“故事”变成看得见、感受得到的场景，产品可以不完善，但要体现出核心理念。此步骤既可以验证可行性，也会接收到试用客户的初期反馈。创业前期是个不断试错的过程，每走好一步都可以增强支持者(包括股东、投资者，或合作伙伴等)的信心，也让团队更有信心。为了减小试错的代价，快是最有效的手段。
用技术来赚钱有各种途径，越贴近用户需求的技术或产品，相对而言变现容易得多。底层技术和产品要获得市场认可的周期则长得多。
我们经常面临各种诱惑，比如有客户希望做一些他们的应用需求(像小程序之类的)，或者客户已有的系统有遗留的问题需要解决一下。 承接这样的需求可以快速地赚到钱，但影响主线产品的研发进度。作为初创的技术公司，一定要抵挡住诱惑，学会拒绝。做系统软件产品，更要耐得住寂寞。
在大平台上工作，危机感源于自己的职业价值;而一旦开始创业，危机感来自于公司的生死存亡。这种危机感可以把一个人或一个团队的潜能发挥出来。做好技术是一种聪明，而面对内心中的危机感，需要的是智慧。
技术人创业，有大量知识需要补充，涉及财务、法务、品牌、市场、商务等，自己不可能在每个方向都成为专家，所以要依靠团队，信任团队。有了凝聚的、可信任的团队，企业才能走得远。
写在最后
程序人生又10年，但这10年我实际上跟程序代码的接触并不多。曾经有一次，我团队中的架构师给我讲代码实现，他怕我听不懂，就用以前DOS时代或者Windows时代的系统机制打比方，向我解释当前的架构方案。
感谢这些架构师对我的贴心，确实软硬件技术发展都很快，编程的理念也有不小的变化。 用10年的跨度来看技术进步，老程序员的知识结构是需要升级的。在国内IT企业市场，程序员35岁是一个职业坎，45岁很多程序员就屈服于现实了，55岁绝大多数就得退群了。
我在20年前写第一篇程序人生时，提到了我是软件开发队伍中的老兵，那时一方面是由于身体的垮塌，另一方面也是感受到了后浪的力量。
最近这10年，我还培养了一个辅助习惯 —— 跑步，跑的距离从5公里开始，到10公里，再到半程马拉松(约21公里)，然后到全程马拉松(约42公里)。跑得不快，但能坚持下来。 我希望自己的程序人生还能有至少两次续篇，写代码不一定多，但仍然保持跟代码的接触。
公众号：CSDN
