客户端技术的一点思考

今天看到CSDN上这么一篇《 彻底放弃没落的MFC,对新人的忠告!》, 作为一个一直在Windows上搞客户端开发的C++程序员,几年前也有过类似的隐忧(参见 落伍的感觉), 现在却有一些不同的想法。

首先,个人职业发展是否成功, 技术只是其中一小块,尤其是在大公司, 更多的是依靠所谓的软实力。作为一个对技术有追求的工匠,我们下面重点说技术相关的。

现在回头看计算机行业的发展,我们看到不同的发展阶段:

1. PC时代,这个时代离我们并不遥远, 也有是2000年前后, 该时代最鲜明的特征是Windows操作系统,Office软件,Exchange邮件服务器等,还有Windows平台上的各种通讯娱乐工具以及行业软件等。这个时代大部分都是和Windows操作系统相关, 这个时代的开发工具也是百花齐放:VC, VB, Delphi, PB, 以及后来的C#, 本质上都是Windows API。

2。PC互联网时代, 这个时代和PC时代很大程度是重合的,因为互联网客户端浏览器的载体还是PC, 这个时代最显著的特征是Google, Baidu, Facebook,淘宝等的兴起, 网络搜索,网络社交, 网上购物成为时髦。这个时代说白一点就是怎么做好一个网站,开发工具包括后端和前端:ASP,JSP, Java, PHP,html, JS等, 本质上是http协议及html.

3. 移动互联网时代, 手机本来只是打电话和发短信用的, 苹果iPhone改变了这一切,开启了智能手机的新时代。现在我们通常说的移动开发主要是指iPhone和Android开发,以及少量的WinPhone和BlackBerry开发。移动互联相对于PC互联,有几点不同:首先移动时代能够让人充分利用空闲时间片,社交(微薄、微信)和游戏娱乐都很方便;另外移动手机有位置定位功能, 导致了O2O创业潮的兴起和成功(比如uber)。移动App的开发语言各异(Objective-C, Java, C++, C#)等都有, 本质上是一个客户端软件。

4。未来, 有人说是互联网+,有人说是万物互联(智能手环,智能路由,智能家电)...

从上面我们可以看到, 每个时代都有自己的特色,一个时代的兴起并不会完全取代另一个时代:PC还是我们的主要办公工具, 手机是我们随身的通讯和娱乐工具,谁都没法完全取代谁。

互联网时代的技术体系无非是分为服务端和客户端:

(1)服务端来说, 如网站后台,主要是如何高效从海量数据中的返回用户需要的数据, 也就是所谓的大数据技术(如Hadoop,spark);如果是IM后台,  常用开源的XMPP服务器(Openfire, Ejabberd).

(2)客户端,客户端主要分为Web客户端和Native客户端。

Web客户端就是所谓的前端开发, html5前几年被吵得很热,这几年有些降温,因为Web UI的用户体验和Native还是有挺大差异, 尤其是在移动手机上。做产品一定要提供最好的用户体验才能在市场中获胜, 所以除非Web的其他优势大大超越了用户体验的需求, 它才会被考虑使用。这也是淘宝前端用Web实现, 而QQ前端用Native C++搞的原因。

下面我们重点说Native客户端开发, 以前写过一篇《客户端架构设计的简单总结》,那时主要是搞Windows, 现在搞跨平台之后,发现各个平台的客户端基本上都是大同小异。我们会发现客户端的大部分技术都是跨平台的, 而且很多技术都是开源的。比如数据存储用SQLite, XMPP通讯用Gloox, Web交互用LibCurl, 数据打包用Protocol Buffer, socket通讯用boost asio。 我们会发现除了UI代码,客户端80%的代码都是可以用跨平台C++代码搞定(Windows, Mac, ios, android, Linux, BlackBerry)。 我们这里要做的就是把框架搭好,协议定好,层次分好,模块切割好,把UI和逻辑分离好。据我所知微软的Office除了UI部分,PC和移动版也是用这总方式实现的跨平台。

回到本文刚开始的问题, 初学者要不要学MFC? 个人觉得先要看自己定位的开发平台, 如果是搞Windows, 那也应该先从Windows API学起,根据工作需要决定要不要学MFC 。总之,无论学什么,先深入一个平台, 从C++编译器到CRT运行库, 再到操作系统, 从用户态API到内核和驱动,越深越好,然后再跳出这个平台,接触其平台,会发现各个平台基本都是大同小异。

时间: 2024-08-02 01:46:45

客户端技术的一点思考的相关文章

客户端技术的一点思考(数据存储用SQLite, XMPP通讯用Gloox, Web交互用LibCurl, 数据打包用Protocol Buffer, socket通讯用boost asio)

今天看到CSDN上这么一篇< 彻底放弃没落的MFC,对新人的忠告!>, 作为一个一直在Windows上搞客户端开发的C++程序员,几年前也有过类似的隐忧(参见 落伍的感觉), 现在却有一些不同的想法. 首先,个人职业发展是否成功, 技术只是其中一小块,尤其是在大公司, 更多的是依靠所谓的软实力.作为一个对技术有追求的工匠,我们下面重点说技术相关的. 现在回头看计算机行业的发展,我们看到不同的发展阶段: 1. PC时代,这个时代离我们并不遥远, 也有是2000年前后, 该时代最鲜明的特征是Win

语音、音频技术的一点思考

语音和图像.视频一样,是人与人之间沟通的交流方式. 语音信号处理是一门综合性的学科,它与语音学.心理学.数字信号处理.计算机科学.模式识别等有着密切联系. 语音技术一般可以分为三大类: 1.人与人之间的通信:语音增强.语音编码.语音通信.VOIP等 简单的说,以网络为载体,实现人与人之间的语音通信,涉及到语音前端去噪,增强,语音压缩编码等. 语音增强.语音去噪等, 主要解决的是前端问题,单纯的语音.音频处理技术主要应用在嵌入式方向. 开源的像Webrtc.Speex之类. VOIP.语音通信主要

关于优化游戏服务器响应客户端消息的一点思考

现在假设有如下构建的游戏服务器,游戏服务器有一组gate服务器,用来验证客户端,并且通过gate服务器来与一组主服务器,然后主服务器与关系服务器进行通信. 其中relation服务器用来处理各种关系,例如好友关系,师徒关系等.现在有一个玩家A添加玩家B为好友,那么客户端发送给服务端的消息流程如上所示.首先gate收到客户端消息,进行验证等,然后转发给Main1服务器, 这里假设玩家A的信息存储在Main1服务器上,然后Main1服务器检测玩家A的各种要求,如果满足要求,则将消息转发给Main2服

关于大型网站技术演进的思考(一)--存储的瓶颈(上)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123

关于大型网站技术演进的思考--存储的瓶颈(转)

(一)第一部分 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那

【转】关于大型网站技术演进的思考(一)--存储的瓶颈(1)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123

关于模板方法和策略模式的一点思考

该随笔的思想原点,应该算是在两三年前了.当时和一前同事聊天.不知怎得就聊到了Http访问. 一.我记得他和我说过的第一句话,大概是:有没有已经封装好的.比较强大的HttpUtil.也可能是受业务的影响(接口对内).我当时接触到的Http访问,大多比较“规范”,至少有一个接口约束在约定着某些东西,不至于一会传递json,返回json, 一会又要传递xml,返回xml,甚至更奇葩的是,上传个文件.返回0或者1.如果真出现这样的状态,HttpUtil依然能够方便.灵活的适应着各种情况.我想这个Util

&quot;简单设计&quot;的一点思考

简单设计是Xp技术实践中开发实践的核心实践,“简单也是价值观中智力色彩最强烈的”,然而,提到简单设计,大家更觉得像原则或者价值观,感觉上还是比较泛,我们不妨从下面的几个角度看一下  1. 为什么要简单设计 <1>. 简单的代码更容易读懂. <2>. 好的设计更能应对变化.  这两点是基于成本和收益考虑的,这里的价值是时间及金钱.更快的满足需求,减少复杂带来的故障排查.修复成本,代码大量修改或者重写成本.  2. 什么是简单设计 对一个团队来讲,简单设计就是团队中每个人都能轻松的读懂

基于http协议通信的APP安全策略的一点思考

声明一点,我没做过过任何商业APP,以下想法仅仅是个人业余时间的一点思考,若你是专业人员,不吝赐教. 概述 微信开发过程中,会使用到微信服务器提供的API,这些API都是基于HTTP协议调用的,为什么我们自己的APP服务器不采用这种方式呢? 这种方式最直观的好处就是,API设计得足够好时,服务器只需要开发一次,无论前端是 WEB,APP ,APK...都通过http调用API请求数据并响应. 这种方式类似于传统C/S模型的开发,服务端/客户端定义相同序列的数据结构(称之为通信协议),差别在于现在