我从入坑程序猿开始就是做的客户端开发，到现在也有十余载，这期间客户端的技术也经历了万千变化，遂起文谈谈我所经历过的客户端开发技术演变之路，以及对客户端开发未来的展望。
一、C/S架构时代
第一次接触软件开发是在08 ～ 09 年间，那时候主要是做Windows上的客户端开发，当时用的还是MFC框架，整体用C++编写，记得IDE使用的是Visual Studio 2005版，想当初在学校的时候还是用老式的Visual Studio 6.0 🤦♂️，用过这个的童鞋都暴漏了年龄了哈～。后来微软主推.Net框架，然后又学习使用C#开发，这个语言相对C++更友好一些，接下来微软又基于.Net推出了一个WPF框架，快速搭建美观的Windows窗体应用，不过这个框架到后来也没怎么成为主流。到今天大家也都知道了，微软主推UMP应用开发框架。
在学校学习的内容终究是有些浅显，以为Windows上的客户端开发也就这些东西了，然后在10年开始参与公司的项目开发，那时候才发现，我们公司使用的是自研的UI渲染引擎，UI界面的构建使用的lua语言，没有使用任何什么MFC、WPF、.Net等等微软官方提供的框架工具，对于当时还是小白菜的我惊讶佩服五体投地。当时也问了研发渲染引擎的老大哥们，为什么放着现成的框架不用，要自己研发渲染引擎，答案也比较简单，使用自研的UI渲染引擎可以实现很炫酷的交互效果，还可以根据公司自身的业务特点封装一些组件和提供简化的开发接口，提高研发团队的研发效率。我：....膜拜....
二、B/S架构时代
我在接触Windows窗体应用开发的时候，在网站开发领域已经喊出了Web2.0的口号，最开始了解网页开发也就是使用Dreamware来设计开发的，都是html和css标记语言，就觉得这个东西都是设计师的工作，编程代码部分看着也比较初级。编程比较重的是网站系统开发部分，当时有两种技术栈，一种是java + jsp + mysql，还有一种是微软的.Net + Asp + mssql，当时很流行MFC设计模式，前端和后端的代码逻辑都在一起，是没有严格区分前端和后端的概念的，网页的内容都是在后端通过模板构造好html，返回给浏览器显示出来，页面内与服务器通信的部分则使用Ajax实现。
后来随着Google浏览器的崛起，html5的出现，网页的渲染任务慢慢从后端移到了前端，这才有了比较清晰的前端概念，在本地浏览器上就可以渲染网页处理交互并执行一些业务逻辑，而不是仅仅是解析显示html，这极大的丰富了网页显示的内容，也使网页上的交互效果更加炫酷和友好，也提升了JavaScript语言的热度，成为了标配的前端开发语言。
到今天前端开发已经不可同日耳语了，也不再是当初简单的html网页设计。现在的前端已经成了独立的开发体系，涌现了许多开发框架，耳熟能详的如React、Vue、Angular等等，已经完全成了程序员的工作，而不仅仅是设计师的工作。同时，前端的发展也推动了许多开发语言和设计模式的创新，如TypeScript，Redux，声明式编程等等。
三、移动App时代
C/S和B/S的项目我做的不多，所以篇幅也比较小，仅仅是平时关注技术的内容了解到的一些。我在第一家公司做了不到一年时间的Windows客户端开发，然后公司成立了移动端开发部门，我被调了过去，成为最早开发移动App的一批人。然后后面几年移动互联网爆发，我基本就没有在切换到其他的技术栈，所以对于App开发技术的演变感受更为深刻。
最开始接触Android开发的SDK还是3.x的版本，当时的系统界面和UI组件现在看来都粗糙的很，但对于第一次接触智能手机的我还是忍不住感叹“哇塞～好高级！”，同时期的iPhone还是3GS。怀着对新事物新科技的好奇和激动，我开始了移动App开发的职业道路。
当初开发Android使用的IDE还是Eclipse，是Java开发的神器，不知道现在还没有人在用了，毕竟Intellij Idea太强大了。因为Android的开发语言也是Java，那时候Android Studio还没有推出，Eclipse自然而然成为首选IDE，不过配置开发环境就比较麻烦了，并且代码的Analysis和Intellisense也不是很友好，经常出现标一堆红线但是还可以编译运行的情况。Android Studio刚推出时还不太稳定，中间还使用了Intellij Idea配置Android开发环境，替换了Eclipse，当时就感受到了这个IDE非常好用，Android Sudio也是基于此开发的，各种快捷键操作习惯都一样。
Android SDK 3.x到5.x的时期比较头疼的事情是设备的适配，当时也是被iOS开发者所吐槽，那时Android设备屏幕的碎片化很严重，各种奇葩的分辨率都有，现在起码大家的分辨率都比较规范了，然后现在iOS的开发者也体验到了多个设备分辨率适配是什么感受。。。
我是在iPhone4s推出时涉入了iOS的开发，刚接触iOS开发时也觉得iOS开发好爽，不用考虑分辨率适配问题，并且还是拖拽组件布局UI，和当初开发Windows窗体应用体验一样，效率也很高，除了ObjectC的语法怪怪的。。。但是，没两年就被打脸，从iPhone6 开始，苹果就不着调了，为了支持iPhone的多个屏幕，xcode同时也推出了Auto Layout，这个东西刚开始真是用的吐血，各种莫名其妙的问题，最后被逼的在代码里做不同屏幕的适配，增加了很多工作量，而那个时候Android的自适应布局方式已经很成熟了。
随后移动App开发也开始新一轮的升级，Android推出了支持Kotlin开发，iOS推出了支持Swift开发，新的开发语言提供了很多高效的编码方式，也确实提升了编码的效率。同一时期，React Native跨平台框架也出现在视野里，作为技术的调研试用了一下，感觉性能是个很大的问题，操作的流畅度对比原生差距很大，然后编码上也没有完全达到所宣称的一份代码多端运行，某些UI组件对于iOS和Android还是分成了两份代码。不过RN也是一个很大的突破了，之前的跨平台都是Hybrid方案，网页和原生结合的方式，交互的体验更差，何况当时智能手机的性能远不如今天。
其实在这个阶段我个人是有一点的迷茫，看不到移动App开发未来是什么样子，各大公司都不断升级自己的技术栈，开发者学习使用的成本很高，要两边都学，如果只专注一个平台的话，开发的技能和职业的选择又会很窄，所以当时就很纠结，同时学习Kotlin和Swift，同时做两个平台的开发真的很累，吃不消，并且大部分的移动App的开发都是UI上的开发，做信息层的交互展示，除此之外有做图像的、视频的、3D的等等跟App的开发又不相关，都是底层用c/c++开发。所以对于移动App应用层的开发不知道未来该往哪个方向走，甚至一度以为移动App的开发是否已经到了天花板，走到头了。
转折点是在18年时候接触到了Flutter，试用之后确实被惊艳到，UI的交互体验几乎与原生无差别，同时也真的做到了一份代码多端运行，这才是理想中跨平台框架该有的样子。由于当时Flutter还是测试版，没有正式发布，所以还是比较谨慎一些没有用到公司项目里，真正开始使用是在19年，当时也是迫于业务需求开发的压力，为了追赶进度，决定冒险尝试使用一下，最后整体上线情况还是比较稳定的，没有出现大的问题，而后就开始使用Flutter实现新的业务开发，并逐步替换掉旧的代码，到今天我们使用Flutter开发已经接近两年，得益于Flutter的设计思路，我对移动App的开发乃至全平台的客户端开发有了新的思考。
四、客户端开发的未来？
Flutter全平台的支持确实让人振奋，其实细想这种技术在游戏开发领域早也已经实现了，主流的游戏开发引擎Unreal Engine和Unity都支持全平台构建，能实现的思路也是因为自己实现了渲染引擎，上层的应用使用自身的渲染引擎进行渲染，抹平了平台差异。Flutter也是同样的思路，它是运行在Skia引擎之上，通过Skia适配各个平台，而这之上的Flutter应用就可以运行在各个平台，类似的思路早前的Qt框架也有，不过从开发难度、效率、以及实现的UI效果上看，Flutter优势很明显，当然，Dart作为新兴语言需要学习，不过有经验的开发者上手都会很快的。
同样，作为与游戏引擎的类比，Flutter的开发是否也可以支持可视化编辑，有过Unreal Engine使用经验的伙伴应该知道，UE有个Blueprints功能，可以支持全可视化开发的，没有程序员的参与，仅凭设计师就可以开发出一款游戏。开发的过程从场景的构建，精灵的行为逻辑，碰撞检测等等，都可以通过在Blueprints中可视化编辑。那么同样的思路是否可以用在Flutter上？这也是我想的客户端开发的未来，是否可以实现一个工具，让产品经理或设计师，通过可视化拖拽组件，编辑数据流、逻辑行为，就可以构建出满足自身业务要求的App？目前微软的Power App比较符合这一构想，不过Power App的学习成本比较高，同时构建后生成的App体验也远不如Flutter，所以，借助Flutter实现这一个工具，是我们开发者可以尝试的一个挑战，我想，也是客户端开发的未来，一个不再需要客户端开发者的未来。
