#玻璃房子#
计算一下,改用玻璃每一层省出来的那些被土墙占用的面积,加上因为使用玻璃额外盖出来的土墙撑不起的那些层数,折合一下当地房价,扣除掉当地的工价,得到的余数是多少。
如果这房在上海陆家嘴,差价保守估计够你开几百年空调。
如果这房在陕北农村,土墙有可能真的赢了。
此处没有计算心理感受的折价。
和平房取代了土坯房一样,因为科技进步了,而农民也不虚荣。
在我看来,农村在90年代兴起的平房,其实是多数农人的幸福。
我小时候,家里日不聊生,没有平房,一家人都住在颇有“乡土气息”的土坯房里。由于太过乡土,墙要有半米厚,只能留半米见方的小窗,否则那可怜的木质过梁根本无法承受窗上厚土的巨大压力。窗户是木楞的,没有玻璃。因为玻璃要花钱,所以都用薄如蝉翼的白纸。
白纸比破布光明,但也不是非常光明,屋里永远是黑洞洞的。有个40瓦的灯泡已属奢侈——很多人家用3瓦的。
3瓦的白炽灯发出极为昏黄的光亮,不比萤火虫的尾巴强多少,人就在半黑的情况下干活,结束昏暗的一天。
屋顶是房梁和檁子,上头是高粱杆,高粱杆上是泥巴和秸秆混成的夹层,再往上是瓦,瓦与瓦叠加,雨水顺着往下。由于年久失修,漏雨是常有的事,往往外面下大雨,里面泥石流。夹杂着泥土的水柱,蹿浠似地落在接水的饭缸和脸盆里,发出噗噗哒哒的声音。我只好缩在不漏雨的地方,点上油灯写作业。
农村的雨天往往停电。
一毛钱有一毛钱的工艺,但工艺和工艺也不相同。
同样是时价一天的东西,现在的工艺就比以前的可用性高,片瓦不如预制板,预制板不如现浇。
前些年的时候,学者群里一个朋友说出了他多年的疑惑:“为什么农村要盖土房,不用那种红砖?是不是有什么讲究?”
都猜土房冬暖夏凉。
我说,并不是,也没什么讲究,唯一的讲究,就是红砖要花钱。
上小学的时候,学校里推举贫困生,孩子们的原则,就是谁家住砖房,谁就没有当贫困生的资格。可能现在人觉得难以理解:人家住砖房就不能贫穷了吗?
但是,一如你所在的城区选困难家庭进行救助,你也会反对把救济款划给拥有市中心两套一百二十平精装房的家庭。有人说,人家买了房,还得装修,装修后就没钱了,变穷了,当然符合贫穷的标准啊!那么你就信了吗?你不会信,你只会冷笑。
古今都是同样的道理。
听了我的话,做生意的朋友非常惊讶。在他的观念里,红砖是非常不值钱的东西,其成本可以忽略不计,既然忽略不计,那怎么农村人不盖砖房,而盖土坯呢?所以才有这样的疑问。
事实上,砖不值钱,是工业社会后期的事情。农民盖不起砖房,只好延续身为贫农的祖先们的最佳的做法——打土坯。
做这个决策不容易,因为盖土房也要花不少钱,不是贫户能负担得起的。建国后,这个钱通常不是工钱,那时候的人工并不值钱,主要是请亲邻帮忙盖屋的饭钱。
参与盖屋的都是些年轻力壮的小伙子,为了吃顿好饭,从来不惜力。要是主家能管一顿带点肉的饭,还有白馍,那就拼了命干,从鸡鸣干到晚上。帮忙干活的有五六七八人,有的十多个,大家热火朝天地干,直至起完大梁,铺席盖瓦,全体完工。农家的土坯房,就是这样起来的。
为什么穷人更愿意相互帮助?就是因为只有相互,人才能在贫瘠的生活中活出希望。
有的人似乎没怎么调查土坯房的背景,没去做基本的研究,就说应当鼓励农民盖土坯房,土坯房有乡村田园的美感。
实际情况完全不是如此,住过土坯房的,没人再愿意住进去。那些口头说怀念的,只是怀念他们的过往,他们回不去的童年,那时候他们还是孩子,无忧无虑,不用为太多事情负责,相较于焦头烂额的现在,那时候的一切都是美好的。
可真让他们去住土屋,他们才不会去住。
许多人认为,乡村里钢筋水泥的死板建筑没有任何审美可言,应当禁止,去盖些有美感的建筑。他们还拿徽派建筑举例说明乡村的古典美。
我无需掩藏我的想法,说白了,这其实还是一种居高临下不接地气的残酷的想法,根本就没有对农民最基本的人文关怀。
因专业所在,我对古典园林和现代园林都有了解。
如果你理智地研究一下这个问题,就会知道,自古以来,凡乡村有大建筑群,有雕梁画栋绣阁琼楼者,无不有成体系、成规模的富庶祖先。
徽派建筑是徽商的杰作,山西古宅是晋商的故里,如画的江南,凡稍微好看一些的建筑群,祠堂里头的牌位必定供着什么尚书,什么宰相,一门三进士,三代九举人。
古时村里的少部分人,成为了绝大多数人的共同祖先,贫苦人家往往绝嗣。
古代和现代还有一个不同,那就是,古时候,在外头混发达的人,总是要荣归故里的。当他们辞官回乡,解甲归田,就带来大量的财富和完全不同于乡村野叟的审美。往往在他们居官的时候,诗情画意的住宅就已经兴起。
有心营造自家庭院的官员和商贾,往往花费上万两白银去造一进院子。我们所熟知的乔家大院,花费更是到了惊人的二百万两。
有人喜欢把200块钱和一两白银划等号,从80年用到90年,又从90年用到21世纪,殊不知这么算老大的不靠谱。我们还是应当用工作价值来计算,古时候,地方上的一个技术工人,马不停蹄地干,一个月的收入也才不到二两。而县城没技术含量的洒扫、端盘子等工作,月薪也就七钱。不说乔家大院,就算是一所稍微能看上眼的,有审美的砖瓦院,也要普通打工人工作几百年,中途不生病,才有可能造得起。
这些建筑是非常有本事的富庶祖造的,子孙后代当然可以继承。当他死后,就要看后代自己的造化了,前两代,漂亮的住房还是有的。有闲钱进行修葺,但也有的落魄到了卖祖宅的地步。有的不全卖,把一半卖出去,世世代代如此,直至全部卖光。不过,很多时候,这样的宅子卖不出去,因为光是修缮和维持就是很大一笔开销。
现在和古代最不一样的地方之一,便是发达了的人不会回故乡。混得越好,走得越远。家乡越穷,就越回不去。因此老宅荒芜,墙头长草。将迁居者,不爱护其窗栊,不洁治其庭庑,俗人恒情,亦何足怪?
现下,钢筋水泥和玻璃门窗,改善了绝大多数农民的住房环境。不过,因财力所限,美感自然是不足的,只是贵在实用。
倘使真要像徽派建筑和苏州园林学习,创造出新时代的美丽建筑,就必须招引足够富庶、足够机巧的人回流,可是办不到。
现在的情况是,虽说物料贱了,但是人工又开始贵了。当下的农村,盖一套最普通、最简陋的平房,至少也要7万块钱——土坯房更贵,因为没市场,也没人愿意下这样的苦力。如果真如一些人想象的那样,家家户户“石榻云屏,雕梁画栋”“纷红骇绿,美不胜收”,非要出个100万元不可。
对很多家庭来说,这根本不可能。一下能拿出两三万,就已经到了多数农村人的极限。
什么是人文关怀?
我认为,考虑到最广大人民的温饱、安全、幸福,才是一切人文关怀的基础。
至于说玻璃不如土坯隔温,光做实验拿数据是不行的,会落入空想者的圈套——我比梅西个子高→头球我更容易进→所以我的球技比他好→五大联赛都不用我,他们的脑子让驴踢了。
同理,土坯房单项数据可能更好一点,但其他简直一无是处,这是住了很久土坯房的人的论断。不信这个论断,也倒简单,你让夸土坯的人进去住几年,看看他愿意不。他要是口头表示愿意,就搞清楚他是想三天两头上房揭瓦做防水?还是想大白天开着白炽灯?是喜欢密闭而又窒息的感觉?还是喜欢同虫豸与老鼠共舞?
搞清楚了,再推荐他去一院还是四院,就比较有的放矢了。
(部分内容摘自我正在写的新书《半农主义》。)
但凡进过一次土坯房,都讲不出这样的昏话来
风大掉土,雨大漏雨
老鼠横行,虫子乱飞
门窗矮小,屋里昏暗
屋外太阳,屋里蒸笼
屋外阴雨,屋里湿冷
小时候,住过一阵子草房子,就是土坯房,为了增加泥土的强度,会在泥土里混入稻草。屋顶更不可能有瓦了,木头梁,芦苇编成席子做顶,上面盖上用shan草扎成一捆一捆的(我不知道shan是种草,还是个动作‘苫’)草把绑紧做瓦挡雨。
差不多是这样的。
我家之前的有三间,比这个大,比这个整洁,至少窗户是齐的
现在有忆苦思甜版的,一看就知道不是住人的,那么小的窗户,这是禁闭室么?屋顶草伸出来的太少,雨水会直接冲刷泥墙,等雨停了,太阳晒晒,就知道什么叫斑驳脱落了
这种草房子,各种怕,
怕虫子,咬烂东西。
怕老鼠,打洞。睡觉的时候,老鼠会从你脸上爬过去,婴儿会被老鼠咬伤;过年过节,腌点咸肉灌点香肠,放哪都能被老鼠找到,只能钉个钉子挂墙上。
怕雨,泡烂屋顶,怕大雨,泡软墙体,怕大大雨,洪水一冲就垮
怕草,墙上的和屋顶上的草,都要早点清掉,有些草长的飞快,两个星期,就能把根伸到屋里来。再想清理,就得顺手补墙补屋顶了
怕大风,掀掉屋顶,
怕火灾,天冷屋里不敢点多久火炉子。做饭得小心翼翼的,一旦走火,都是暴晒的草,压根没得救,厨房要跟主屋隔开,单独一两间
怕大雪,雪水会渗进shan草捆里甚至泡到芦苇席子里,天冷再给冻上,来回两次,第二年屋顶就得漏雨。雪水顺着shan草淌下来,会形成冰凌柱。这货要及时清理掉,太重的话会把上面的shan草一把一把的拽下来
泥胚墙,门窗做不大房子也做不大,阳光进不来,空气不流通
屋里太暗,太湿,太阴冷
夏天夜里热的受不了,搬两个长凳,搬个床板或者门板,铺上席子,点把芦苇棒或者蚊香,睡外面。不能睡地上,一是怕毒虫,二是,夜里地面降温快,容易睡出毛病来
所以,一有点钱,都把草房子换成砖房子,所有人家都一样,没有例外。
哪怕一间间的换,哪怕钱只够砌墙不够买瓦的,都得换成砖房子。
我估计多数人第一眼看到,直觉上可能并不会立即反对提问者对于玻璃房和土坯房的描述 —— “土坯房冬暖夏凉,玻璃房更耗费能源”。然而,事实真的如此吗?不如我们来求证一下。
揣测题主本意,应该是想对比两种材料的热工性能,以及所塑造空间的能耗差异。只不过问法有些愤世嫉俗,还有个比较关键的错别字 -_-|l,带偏了不少回应者的关注点,差点浪费了一个有趣的选题。
题主对玻璃的性能可能有一些些误解,让我们一步一步来拆解他的疑问。
— 1 —
“建筑大量使用玻璃后,还不如土坯房保暖 ”
首先说说保暖,玻璃房会不会比土坯房导致冬天室内更冷?
举两个实例:
太阳房听说过吗?它为了冬季获得更暖和的室内体验所设计。
没有听说过的话,蔬菜大棚呢?它还有个名字,叫“温室”。
如果没有切实体会过上面这两个例子所述的环境,对玻璃房的冬季是什么感觉依然没有概念的话,没关系,我给大家建个模型,咱们用数据说话。
下图,是一个全封闭无洞口的纯玻璃盒子(100m2,3m层高,三玻两腔玻璃,传热系数1.8W/m2·K。当下建筑建造时已很少单片玻璃单独使用,常以组合形式形成多层玻璃围护,提升热工性能),放在夏热冬冷地区(以上海为例),无制冷采暖无新风,在最冷月(1月)的室内温度表现 (IES-VE软件,具体模型设置参数见文末):
【玻璃盒子模型截图】
【玻璃盒子最冷月室内温度曲线】
最高温度约57.3℃,最低温度约4.6℃。高于18℃ (舒适温度下限)的时间约占30.9%,正午还能蒸个桑拿。这样来看,玻璃房的冬天,还冷吗?
作为对比,我们也用土坯建个模型。根据相关文献(见文末),350mm厚的土坯墙传热系数约1.8W/m2·K,与刚才玻璃房的三玻两腔镀银的玻璃K值几乎一致(传统土坯民居没有严格意义上的保温层,整体性能并没想象中的好)。
我们用相同的传热系数,看看一个完全封闭无洞口的纯土坯盒子,同样放在夏热冬冷地区(以上海为例),无制冷采暖无新风,在最冷月(1月)的室内温度表现 :
【土坯盒子模型截图】
【土坯盒子室内最冷月温度曲线】
可以看到,同样在最冷的月份,我们的土坯房室内最高温度竟然没有超过16℃,室内温度舒适区间(18℃~26℃)时间占比为0%!
惊不惊喜?
从温度适宜区间时间占比来看,土坯房竟然比玻璃房“冬冷”得多!(应了知友 @禁与千寻 的土坯房真实体验)
再来,我们讨论一下,提问中玻璃房“反而冬冷夏热”的“夏热”是不是真的。
还是刚才的两个模型,我们看一下夏季最热月的室内温度曲线。
【玻璃盒子最热月温度曲线】
这里倒是没有什么惊喜 —— 全封闭玻璃盒子的夏季温度确实高得离谱,最高温度居然可以达到99℃,最低温度在28℃左右。
参考知乎用户@老爸评测的实验结果,四面有透光玻璃的汽车在太阳下密封暴晒几个小时,车内温度可以达到60℃。
咱们这个五个面(包括屋顶)都透光的模拟实验密闭玻璃房,全面暴露在阳光下,里头还算了5个人以及照明、电器等的散热量,冲上99℃也可以理解。幸好里头的五人都是电脑模拟的,不然真实的实验可得出人命咯。
【土坯盒子最热月温度曲线】
纯土坯房在最热月的最高温度为40℃,果然还是要“凉快”得多,但是它最热月的室内最低温度,居然也在28℃左右。
以18~26℃的舒适区间来衡量,纯玻璃房和纯土坯房的舒适温度时间占比都是0%....
这一轮“夏热”比较,虽然土坯房相对更凉快,也免不了有点五十步笑百步的意思。
纯玻璃房和纯土坯房两轮比拼下来,正好1比1打平。那么从全年来看(24小时*365天),到底谁舒适的时间更多呢?
【玻璃房全年温度】
最高温度99.94,最低温度4.58,舒适时间占全年16%
【土坯房全年温度】
最高温度40.06,最低温度6.69,舒适时间占全年23%
16%比23%。从全年整体来看,土坯房的舒适时间占比,好像是要比纯玻璃房的更多一些。
但别着急下结论,我们先来看一下,如果在室外露天环境下,没有任何墙体遮挡围护,全年的舒适时间占比是多少。
【室外露天温度全年曲线】
提取energyPlus epw数据,上海典型气象年,8760个小时中的气象站观测干球温度,最高38℃,最低零下6℃。2607个小时处于舒适区间(18℃~26℃),约占全年时间的30%。
这意味着,全年呆在室外,有30%时间在温度方面是感到舒适的。
发现没?无论是纯玻璃(16%)还是纯土坯(23%),两者居然都比室外舒适温度时间占比要少。
没想到住在室内还没有在室外更舒服,是不是哪里搞错了?
对,一栋正常的房子,它总归是有窗,可以通风;有的也会有遮阳百叶,遮遮隐私也挡挡太阳。
刚才实验里的两个房子都是全面封闭的情况,给大家看一个极限情况下的对比 作为参照预期,看看各自主体材料用到极致时是什么表现。
现在,我们来模拟一下实际真实的有通风有遮阳的条件。为了不影响主体材料属性,我们给两个房子都分别只开两个小窗户(1m*1.5m),适当时形成室内外空气对流,并且给所有透明的部分弄个外部活动百叶,太阳大的时候就合上百叶。
让我们再来看看,在更为接近真实的使用条件下,两者全年的舒适时间对比,到底谁更胜一筹。
【玻璃房,室内过热时开窗自然通风(CIBSE AM10策略)+外遮阳,全年温度曲线】
最高温度38.15℃,最低温度4.48℃,舒适时间占全年52%
【土坯房,室内过热时开窗自然通风(CIBSE AM10策略)+外遮阳,全年温度曲线】
最高温度37.26℃,最低温度6.83℃,舒适时间占全年31%
没想到吧?52%比31%。
在更接近真实使用的条件下,有窗通风有遮阳,无制冷无采暖(纯被动式手段),从全年的尺度上去对比,玻璃房比土坯房的舒适时间更长!而实际使用时土坯房的温度舒适时间,仅仅比露天多了1%。
这是为什么?
原因不难推断:
玻璃透光,可以有效获取太阳辐射能量,而它凭借与传统土坯房差不多的热阻性能可以将热量不断积聚在室内。
在冬季或者过渡季节当室内温度超过舒适上限时,开窗通风,拉起遮阳,可以有效排除多余的热量,将温度维持在舒适的区间内。所以我们可以看到玻璃房在除了夏季之外,其它时间只要是白天,都可以将有效将室内温度控制在舒适区间内,又避免室内过热的情况发生(如全封闭玻璃房时的情况)。
而有了通风之后,由于玻璃蓄热性低,夏季晚上透透气,也基本可以处在与室外类似的凉爽温度。两种情况叠加,大大增加了它处于舒适温度范围内的时间。
而土坯房不透光,即使开了小窗,也没有太多的得热手段。所以我们可以看到,它冬季温度始终无法达到温度舒适区间,影响了全年的整体表现。
另外,土坯蓄热性远比玻璃好,夏季墙体白天被加热后,晚上即使吹了风,也还来不及凉快下来,结果太阳又升起,进行下一轮的升温,导致最热月的表现也没有好太多。如此又些许影响了全年的发挥。
看完全年的对比,谁更“夏热冬冷”其实已经不言自明。不过严谨起见,我们最后再来看一下,实际条件下两个房子的最冷最热月对比:
【玻璃房+遮阳通风,无制冷制热,最冷月温度曲线】
最高温度24.02,最低温度4.09,舒适时间 212/744=28.5%
【玻璃房+遮阳通风,无制冷制热,最热月温度曲线】
最高温度39.52,最低温度24.85,舒适时间 122/744=16.3%
【土坯房+遮阳通风,无制冷制热,最冷月温度曲线】
最高温度13.91,最低温度6.83,舒适时间 0%
【土坯房+遮阳通风,无制冷制热,最热月温度曲线】
最高温度36.76,最低温度25.63,舒适时间 11/744=1.5%
【玻璃VS土坯 实际通风遮阳 无采暖制冷 舒适时间占比】
最冷/最热月两两对比,玻璃房的舒适时间,都要超过土坯房。
所以,不开空调采暖,在纯被动的自然条件下,玻璃房和土坯房谁更冬暖夏凉,大家心里都应该有答案了吧?
题主可能真的在实际环境中体验过玻璃窗越多越冷的感受。其实问题关键在于所在的空间受到太阳辐射的多少,以及窗户的气密性严实度的好坏。如果你处在背阴面的空间,并且窗户气密性差一直有漏风,那确实会有可能感觉更冷。但原因不在于采用了玻璃,而在于设计房间的朝向以及工程质量管控。
玻璃,它不背这个锅。
— 2 —
除了舒适温度时间占比,我们还可以从两者全年温度曲线中发现另外一个信息:玻璃房的每日温度波动要比土坯房大很多,即使有更多累加的时间在舒适区间内,却往往不是稳定连续的(比如清晨温度舒适,正午炎热,傍晚又回归舒适,如此波动)。
原因就在于玻璃的蓄热能力要比土坯低很多,很容易随着外界的温度变化而波动。而这样大幅度大频率的波动很有可能会影响实际采暖制冷的能源消耗量。
所以即使玻璃房舒适的时间比例要多于土坯房,但实际采暖制冷时哪个消耗能源更多,我们现在还不能下定论。
那么说到了能耗,我们就来模拟验证一下,题主的“并且(玻璃)更消耗能源”的论断是不是准确。
按照惯例,先来看一下两个全封闭无窗无百叶的盒子,在设定室内18℃~26℃时,所需的全年采暖制冷能耗(假设设备采暖效率2.5,制冷效率3.0)。
【全封闭无窗 玻璃能耗负荷曲线】
制热26.0 kWh/m2·yr,制冷128.4 kWh/m2·yr,合计154.3 kWh/m2·yr
【全封闭无窗 土坯能耗负荷曲线】
制热42.0 kWh/m2·yr,制冷27.4 kWh/m2·yr,合计69.4 kWh/m2·yr
【全封闭无窗 玻璃房VS土坯房 全年单方能耗对比】
全封闭的玻璃房整体上全年制热制冷的总能耗确实要多于土坯房,玻璃房能耗是土坯房的2.2倍。
玻璃房的得热性能太好,而密闭空间加上良好的保温性能又使热量散不出去,使其室内温度一直较高,虽然降低了室内的冬季采暖能耗,但夏季制冷能耗远大于土坯,甚至连冬季都需要制冷,导致全年节能性不如全封闭无窗的土坯房。
而土坯房的高蓄热性,使其在被室内采暖制冷设备调节到设定温度后,不容易再让温度波动幅度过大频率过高,也大大节约了能耗。
当然,这是全封闭的极端情形。我们再来看看实际有窗通风有遮阳条件下的能耗。
【有窗通风有遮阳 玻璃能耗负荷曲线】
制热31.2 kWh/m2·yr,制冷49.4 kWh/m2·yr,合计80.6 kWh/m2·yr
【有窗通风有遮阳 土坯能耗负荷曲线】
制热41.4 kWh/m2·yr,制冷25.3 kWh/m2·yr,合计66.6 kWh/m2·yr
在实际使用条件下,有通风有遮阳,开启制冷制热设备,玻璃房的要比全封闭时节约近一半的能耗,而土坯房也比全封闭时降低少许能耗。(若不是做了计算模拟研究,我也以为“无门无窗的大土球”是采暖制冷方面最节能的 @羽江 )
整体来看制冷制热总能耗,实际条件下的玻璃房仍然要比土坯房多耗费一些能源,但差距已然不大,两者为1.2倍的关系。
看到这里,题主可以暂时松一口气:“果然,玻璃还是比土坯房更消耗能源的吧!”
是吗?别急。
建筑中的能源消耗,不只有用于制冷制热,还有一个很大的占比属于照明。
假如我们把照明能耗考虑进整体的能耗里,结果会不会有不同呢?
一般有300lux的室内照度,人们即可正常做读写工作。那么玻璃房五面通透,用自然采光就能满足白天的室内照度;但土坯房只开一个小窗,平时室内照度必然受影响,势必有大量的时间需要人工照明。
玻璃房如果平时照度用自然采光即可满足要求,则开灯用电时间少;而开灯少,则灯具散热也少;灯具散热少,则室内用于制冷的能耗也会相应减少(当然,冬季制热的能耗可能会增加)。这样的连锁反应下,玻璃房的节能性会否反超土坯房呢?
为了便于计算,设定全年8760个小时都需要维持在300lux照度以上。
【玻璃房,有窗通风有遮阳+300lux以下时照明,室内采光系数】
国内外常规标准定义满足自然采光条件的空间,需要DF≥2%的空间面积不少于80%。可以看到,全透明玻璃房的采光系数(DF)大于等于2%的空间面积占全部面积的100%。这意味着只要是白天,玻璃房就完全不需要开灯进行人工照明。
【玻璃房 照明能耗曲线,有窗通风有遮阳+300lux以下时照明。照度探测点设置于房间中心】
可以看到,为保持房间中心点300lux照度,玻璃房只需要在太阳落山后(上山前)打开人工照明即可,无论阴晴。
【玻璃房综合能耗】
制热32.7kWh/m2·yr,制冷48.3 kWh/m2·yr,照明22.2kWh/m2·yr,合计103.3 kWh/m2·yr
【有窗通风有遮阳+300lux以下时照明 土坯能耗负荷曲线】
土坯房的采光系数(DF)大于等于2%的空间面积仅占全部面积的5.5%,只有靠窗部分勉强满足自然采光的要求。如此意味着土坯房94.5%的面积需要全年昼夜采用人工照明,其照明能耗基本没有被自然采光所减少。
【土坯房 照明能耗曲线,有窗通风有遮阳+300lux以下时照明。照度探测点设置于房间中心】
可以看到土坯房的照明能耗全年维持在同一水平,意味着如需保持室内中心点300lux照度,则全年都需要持续进行人工照明。
【土坯房综合能耗】
制热41.3kWh/m2·yr,制冷25.4kWh/m2·yr,照明44.3kWh/m2·yr,合计111.1 kWh/m2·yr
【玻璃房与土坯房 实际情况综合能耗对比】
总能耗:玻璃房103.3 kWh/m2·yr,土坯房111.1 kWh/m2·yr。
意不意外?
真是不好意思,题主,真实条件下的玻璃房不仅比土坯房冬暖夏凉,如果考虑建筑的照明能耗,那么它还比土坯房更节能!
是不是很颠覆你的直觉想象?
所以,随着科技的进步,玻璃可以比土坯房更冬暖夏凉,还因为极好的透光性降低了照明能耗,整体综合来看反而可以更节能。
“是人类虚荣还是科学倒退?”
看完了前面的计算验证,我想,这应该已经不成问题了吧?
写在最后
未经求证的直觉往往没有那么靠谱。
让我们用数据说话。
胡子长可持续
附:建筑能耗模拟设定参数
1.气象环境
在正式计算验证之前,我们需要先确定外部气候条件。毕竟不同气候区域,对于室内热舒适环境营造的用能情况是极为不同的。
如果建筑设置在一个四季和昼夜都如春的地方,室外气候条件全年昼夜都基本处在舒适温湿度区间,且多云阴天少太阳直射,那么不管用玻璃还是土坯做建筑围护材料,只要室内保持与外界自然正常对流,两者都不需要采用制冷制热设备,室内就基本上都可以是舒适的。此种情况下,对比热工性能就没有意义了。
为了使结果对比差异更明显一些,我们就选一个冬夏差别比较显著的城市——夏热冬冷地区的上海,作为研究背景环境。
2. 建筑本体设定
除了材料性能外,其他的一切参数如面积、层高、朝向、形状、体形系数、使用人数(5p)、使用时间(24*365)、照明功率密度(10W/m2)、插座设备功率密度(20W/m2)等等等,设定完全一致。
3. 两种主要材料的热工性能
1. 玻璃
采用成熟的技术产品,三玻两腔三银Low-e,结合断桥型材,整体幕墙可以做到1.8 W/(m2·K)的传热系数。幕墙整体太阳得热系数SHGC可以做到0.4. (屋顶同墙体设置)
2. 土坯
根据有限的国内相关论文数据,传统原始350mm土坯墙体的传热系数K值约为1.8 W/(m2·K)(1.75~1.92)(在外围护传热性能基本接近的情况下,K值并不是导致玻璃房与土坯房室内环境差异的主要原因),Thermal mass 约260kJ/m2·K(heavyweight)(屋顶同墙体设置)
参考文献:
1.青海地区农村土坯墙体保温改造热工性能研究 - 太 阳 能 学 报作者:桑鹏飞;谢静超;刘加平;刘德慧;王建平;
2.节能经济;新疆农村民居——“阿依旺”式住宅建筑的节能浅析作者:艾尔肯、吐拉洪、马永军、艾斯哈尔屋面K=1.75W/m2·K
4. 自然通风设定条件
根据CIBSE AM10标准,对不同室内外温度条件,开启相应的窗户面积(全年)
5. 遮阳启闭设定条件
室内温度大于22度,且室内温度大于室外温度时,闭合外遮阳(全年)
注:为突出主要矛盾(材料性能、温度指标)的对比,本次模拟为实验理想环境,不考虑外部周边遮挡、湿度控制等影响因素。实际真实建筑个体环境及能耗表现需要具体项目具体分析。
有一说一,其实性价比最高的4K蓝光播放设备很可能是二手xbox
辫子粉以前顶多荧幕上给人洗脑,现在知乎贴吧上也四处出击,为了打击汉人几十年来重塑的脊梁,把各种汉族英雄虚无化,把汉族领导的朝代抹黑化甚至装做汉粉进吧挑起内讧。
他们从故纸堆里制造无数耸人听闻的“新历史”来欺骗无知历史小白,造谣一句话,辟谣跑断腿,自媒体从明初“朱元璋非汉族”“朱元璋屠苏州”到明末“木匠皇帝爱奶妈”“崇祯冤杀袁崇焕”等等,把明朝描述的宦官专权、皇帝奇葩、厂卫横行、百姓吃土、官员阴暗、军队孱弱。然而“明朝那些事”的一鸣惊人,打破了辫子粉史学界对明朝印象的垄断,大量的历史爱好者纷纷拜读,而心智坚毅者更是撇开满清篡编的《明史》,自费搜阅明朝一手资料,只为看到一个更加真实的大明,这下辫子粉慌了,开始培植网络写手,费尽心机利用历史资料的垄断力,搜肠刮肚寻找明朝的黑历史。并不管这些所谓的“黑历史”是否符合逻辑,一股脑都发到网上,而民间专业的明朝铁粉不甘示弱,从各种能买到搜到的明史资料里一一反驳。网友们看这些世纪辩论贴津津乐道,从中看到的不仅仅是历史基本功的PK,更是挺起几百年来被强行弯下的脊梁的使命感。辫子粉硬钢不起作用又怕更多的汉人觉醒,就开始扣帽子,譬如“明吹”,要知道一个正常的汉朝粉、唐朝粉、宋朝粉都很清楚,那些披着“明粉”来挑衅的必然是辫子粉,同样,辫子粉也知道自己人人喊打,所以尽可能伪装,今儿是宋粉,跑去唐吧里挑衅,明儿装成汉朝粉跑去宋吧里挑衅,仔细一看,这些都是铁杆元清粉。
很少有人不基于框架直接写GUI界面啦,我这个回答就从GUI框架反过来推什么语言做GUI合适。(只聊桌面端GUI编程框架)
几乎是C++领域最流行的跨平台桌面端软件开发框架了,这个框架是两个挪威人在1995年创建的,发展至今可以说历史相当悠久,稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。
它内置了自绘引擎,也就是说界面上的一个按钮,一个文本框,都是Qt的引擎自己画的,这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。
它提供了大量的与界面无关但与软件开发息息相关的API,比如、网络、文件系统、剪切板等,而且让这些API在不同的操作系统下都有效,这极大的节省了开发人员的时间。
但它也有一些缺点,比如在处理一些特殊需求上很不方便,比如:目前Qt有没有比较好解决高分屏下缩放显示的方案?,Qt没有真正完美的无边框解决方案吗?等,在一些组件的渲染上也会出一些隐藏的较深的问题(QListItem),一旦遇到,就很难解决。
Qt近年来不太专一,qml,qtquick等,搞了很多,而且这些新玩意儿一直不温不火,有些模块做了又废弃了,比如:qt script,搞来搞去,搞的模块繁多且复杂,用起来不是很舒服。
Qt有界面描述语言(XML描述界面),可以通过设计器拖拽空间设计界面,编译期界面描述语言被转义成C++代码,性能上没啥损失。
Qt商业授权不太友好,开发商业应用一定要谨慎,之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接,会有版权上的限制,但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。
除了使用C++开发Qt应用外,开发者还可以使用其他语言开发Qt应用,最流行的就是使用Python基于PyQt做Qt应用了,其他语言的绑定不是很成熟,但PyQt仍然有版权的问题。
GTK是1997年创建的,也非常成熟稳定,是C语言开发的,但有很多语言的绑定,比如官方支持的JavaScript、Rust等,当然用C++语言操作GTK也很方便,它也有自绘引擎(Cairo),也提供了大量系统相关的API,商业授权也非常友好,基于GTK开发商业软件不用担心收到律师函的问题,虽然它是一个跨平台桌面软件,但它似乎只在Linux操作系统领域流行,有非常多的Linux桌面软件都是基于GTK开发的。
这也直接导致GTK的维护者很重视Linux领域的发展,而忽视Windows和Mac领域。这个框架提供的很多API,只在Linux下有,Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。
GTK在Windows上也没办法静态连接,它到不是因为版权的问题,而是它依赖MSYS2的一些库,这个库用于在Windows上模拟Linux环境,这也是为什么GTK在Windows上表现不佳的原因之一。
另外,由于GTK是C语言开发的,所以开发风格也很C语言化,这对于部分开发者来说可能觉得繁琐。
wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件,也非常成熟稳定,商业授权非常友好。它没有自绘引擎,而是对不同平台下的界面API做了整合和封装,这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格,这对于某些软件来说,正是他们想要的,但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。
它是C++开发的,所以对C++开发者非常友好,除此之外它还支持静态连接,也就是说开发个应用不用分发给用户一大堆dll,当然Qt也支持静态连接,但是你得自己编译Qt的源码(不是很方便),而且Qt的授权规则也不允许普通开发者这么做。
它会有些小问题,比如我之前提的:wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice,但总体来说还是非常稳的。除了开发的界面比较死板外,没啥大的问题。目前使用这个框架开发软件的人越来越少了。
fltk是1998年创建的跨平台开源GUI框架,历史悠久,商业授权友好,而且C++之父也用它,它非常轻量级,支持静态连接,一个简单的应用编译后只有500K左右,非常赞,
它有自己的自绘引擎,没记错的话用的是OpenGL,但它的重绘机制是按区域重绘的,如果组件A所在的区域上存在组件B,那么A组件重绘时,会把B组件的给重回掉,开发者必须自己写代码处理这种情况。想象一下,如果你想实现一个A组件fade out的同时B组件fade in的效果,就会非常麻烦。
FLTK提供的一些组件样式都比较刻板,绘图API也比较少,你想实现一个漂亮一点的圆角按钮(它内置圆角按钮的圆角大小是不能改的),必须自己画,而且还得借助一些非常奇葩的手段才行(如果你想知道,可以联系我)
它是C++开发的,但API不够现代,用起来总体还算舒服的,它有Rust绑定:fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API,但非常少,几乎可以忽略。
Duilib
是2010年国内一个开发者开发的GUI开发框架,因为底层基于DirectUI开发,所以只支持Windows平台,不支持跨平台,开源协议友好,商用没有任何问题(需要附加Lincence文件),国内有很多大厂基于这个技术做桌面端应用,比如网易、腾讯、百度,这个框架是基于C++开发的,对C++开发者友好。但框架本身还有一些问题,比如对高分屏支持不佳、特殊控件绘制上也有一些小问题,除了界面相关的API外,几乎没有提供系统级的API,作者纯粹是用爱发电来开发这个框架,所以更新不是很及时。
相对来说网易基于Duilib开发的分支更完善一些:NIM_Duilib_Framework,添加了高分屏支持、多国语言、整合了多线程处理的支持,但环境搭建相对比较麻烦。如果开发者要用这个框架,一定要用develop分支下的代码,master分支下的代码问题很多,这个框架看上去也是作者一个人努力的成果。
Sciter是2006年创建的跨平台闭源GUI框架,足够稳定,商业授权不友好,但个人开发者可以随便用(只能用动态链接库),一旦公司规模超过3人,就得买版权了(有权静态连接)。
它内部封了一个浏览器核心,让开发者使用HTML,CSS,JS来创建界面,但对这个浏览器核心做了大量的精简,不像Electron和NW.js动辄上百兆的体积,它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的,比如CSS3的flex布局,它就不支持(但它提供了自己的flex布局实现方式)。以前它使用自研的一个脚本语言(和JavaScript很像),自从集成了Fabrice Bellard大神的QuickJs之后,就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持,比如渲染大列表。
它使用C++开发,对C++开发者很友好,有Rust、go、Python等语言的绑定,但都是社区提供的,质量堪忧。有很多知名厂商都用这个库做界面,比如360、teamviewer、赛门铁克等。
RmlUi和Sciter很像,可以看成Sciter的替代框架,但RmlUi这个项目有三界作者,一个一个的弃坑不知道新任作者会不会弃坑,目前还不是很成熟,比如我正在尝试帮作者解决的CJK输入法的问题,目前还不推荐大家使用这个框架。
CEF是2008年创立的,基于Chromium的跨平台GUI框架,稳定且商业授权友好,国内很多大厂都用的CEF:比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio,装机量破亿。
由于它几乎封了一个完整的Chromium,所以体积非常大,但支持所有的HTMLCSSJS特性,它几乎不提供任何与操作系统相关的API,创建个托盘图标、读写个文件啥的,都要开发者自己完成,它是C/C++开发完成的,对C++用户非常友好,它有gopythonjava等语言的绑定,但都是社区提供的,质量值得担忧。
它对Chromium封装的很好,避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道,很多功能都有默认实现方式,遵从约定由于配置原则,有经验的C++开发者可以很轻松的驾驭CEF框架。
由于Chromium是版本弟,所以CEF版本发布也非常频繁,很多被标记为稳定的版本,还是会出一些莫名其妙的问题,选一个好的版本非常重要。
与Electron一样,它也是分主进程和渲染进程的,所以开发者要非常娴熟的运用跨进程通信的技术,虽然CEF提供了跨进程相关的API,但复杂度还是有点高的,使用的时候要认真细心。
这是微软的跨平台GUI框架,不仅仅支持桌面端,还支持移动端,但官方并不支持Linux的桌面端(黑人问号,感觉与微软近些年向开放、开源的大方针相悖),这个框架新的狠,至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。
它是.NET平台下的GUI框架,有自绘引擎,对C#开发者很友好,界面依然是用XAML描述的,可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些,我觉得WPF没火起来跟XAML有直接关系。
使用这个框架开发桌面应用得封一个.NET框架给用户,当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。
这是JetBrains搞的跨平台GUI框架,也非常新,前段时间刚刚推出1.0.0版本,但这个版本还不是很稳,至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。
它的自绘引擎用的是Google的skia,这个自绘引擎稳的很,Chrome和Flutter都是用的它,所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。
JetBrains的东西当然对Kotlin开发者友好啦,Java生态下的很多东西你都能用,访问系统级API也没啥大问题,同样也得考虑封一个JRE给用户。
这是谷歌的跨平台开发框架,开源、免费、文档齐全、投入力度大且持久,同样也新的很,Windows版本刚刚发稳定版,Mac版本还没稳定。
如果你完全没搞过移动端的flutter,想用这个框架开发桌面应用,那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难,学习曲线比较平缓。
由于flutter在移动端积累了很多年,所以界面上的一些东西在desktop端都比较稳(skia自绘引擎),与操作系统相关的东西还不成熟,生态也不太好,比如你想订制一下窗口的标题栏,想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持,跟C/C++语言打交道很方便。
开发者直接使用Dart语言描述界面,这会导致众多大括号嵌套在一起的问题,可能很多开发者不习惯。
这是微软Edge浏览器团队推出的跨平台GUI引擎,是闭源的,目前只支持Windows,对C#和C++开发者友好,如果使用C#开发,就得考虑把.NET运行时分发给用户,如果使用C++开发,就得自己处理系统级API的操作,webview2本身是不对系统级API做封装的。
这个框架推出也没多久,很多API也还不稳定,更值得担忧的是这个团队,他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心,不知道他们会不会放弃webview2这个框架。
它的优势是可以复用系统当中已存在的webview2二进制资源,也就是说它虽然封了一个Chromium浏览器核心,但如果你可以确定客户电脑已经存在了基于webview2开发的应用,你的安装包体积可以足够小。
它也是多进程架构,甚至比Electron还要多一个进程(为了复用二进制资源),资源占用比较多。
这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题,Mac上使用Cocoa/WebKit,Linux上使用gtk-webkit2,Windows 10上使用Edge(也就是上一个小节里提到的webview2),它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。
开源且免费(MIT)有go、Rust、Python等语言的绑定,不过官方支持的是go语言,C和C++,操作浏览器的API非常少,不支持自定义scheme,更别提系统级API了。
采用的技术方案与webview类似,所以安装包也足够小,非常新,还没发布稳定版,开源免费。webview框架碰到的问题TAURI都有,
使用Rust开发,将来会支持Deno,作者说将来会直接使用webview的技术来支持多平台,
NW.js最早把Chromium和Node绑定到一起,用前端知识做界面,用Node技术访问操作系统,最早叫node-webkit,在2012年创建。NW.js基于MIT开源,可以无忧使用。没记错的话,微信小程序开发工具是用NW.js开发的。作者是英特尔的员工,英特尔的一些工具也是用NW.js开发的。
除了Chromium和Node的能力外,NW.js自己也封装了一些系统级API,类似托盘图标、剪切板、系统菜单这种,但数量明显比Electron要少。
NW.js可以在多个窗口间共享同一个Node.js上下文,而且还可以通过配置让Node的上下文和Dom上下文混合,这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信,哪些模块当前进程不能用这类问题。
NW.js虽然起步早,但奈何没有杀手级应用,周边的生态和工具链没发展起来。用的人越来越少,维护的投入也不如Electron大,再加上Chromium更新非常频繁,导致NW.js的有些API也不是很稳,恶性循环加剧。
Electron的作者曾经在NW.js团队工作过(NW.js项目贡献第二多的人就是Electron的作者),后来辗转到了github公司,于2013年在创建了Electron,也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron,所以从者甚众,生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方(多进程架构及模块归属进程),但瑕不掩瑜。
Electron每创建一个窗口都会多一个进程,这使Electron创建窗口的效率不高(秒级),NW.js有复用进程的机制,即使新窗口加载完全不同域的页面也不会创建新的进程(毫秒级)。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。
无论是浏览器相关的API,还是系统级API,Electron提供的都比NW.js多。
--------2022-02-25更新--------
这些框架除了对开发者使用的编程语言有要求外,还有一个重要的差异就是有没有独立的界面描述语言(也就是UI DSL),这非常重要,涉及到一个框架表达业务的重要能力。
类似XAML、qt的ui文件、HTML+CSS都是界面描述语言,下面这种也可以算界面描述语言,但我感觉它不够纯粹(flutter、qml和Compose Multiplatform都是类似这样的):
panel { row { checkBox(...) row { textField(...) // indented relatively to the checkbox above } } }
但无论如何,显而易见的是,没有任何一个界面描述语言能比的上HTML+CSS组合。想想看:HTML里各种花里胡哨的语义化标签和Dom操作技巧,CSS里的布局方式、伪元素、动画描述...,对比之下你就会觉得XAML、qml直流都是弟弟。
除此之外,一个优秀的GUI框架还有两个重要的需求,这里我简单聊聊:
强大的事件处理机制必不可少。
想想这些:鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外,还得处理事件冒泡、事件捕获、事件分发吧...
qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的(但影响很小)
强大的异步处理机制必不可少
你不能在用户处理业务逻辑的时候,让界面渲染工作阻塞,这就需要一个强大的异步处理机制,让开发者自己去开线程去完成业务处理,无疑是又麻烦又会增加开发者的心智负担。
我记得很早之前在C# WinForm应用中,点击一个按钮,如果不用Invoke执行逻辑处理的话,界面就会卡死。
这么看来,在你的GUI应用里包一个浏览器核心还是挺有必要的,这样你就可以用HTML+CSS强大的能力来描述你的界面,用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。
可能有人会想,这会带来很多问题呀,比如应用体积会增大的100M以上、会占用更多的CPU和内存资源,还会更耗电等等。
确实,目前来看这些都是问题,但仔细想想,这些问题应该不会持续太久,网络会变的更快,用户的磁盘和内存会变得更大,CPU处理能力也会更好,耗电的问题当然会持续存在,甚至会愈发耗电,但电的供应会持续增长呀。
web相关的技术之所以胜出,并不是这些技术的设计者有多厉害,而是这20多年间,有大量的人涌入了这个领域,前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答:
------------2022-02-27更新----------
用Web相关的技术做GUI应用的优势是,让开发者可以把大部分精力投注在业务本身上,而不是处理与GUI相关的技术细节。
实际上所有的框架,都应该是这个目的,比如ORM框架,目的应该是让开发者把大部分精力投注在业务与数据之间的关系上,而不是管理关系型数据的技术细节。
当然这肯定是有损耗的,在性能、稳定性、资源消耗上,都会有所削减。而且,因为有框架的存在,开发者很难深入到框架内部做一些特殊的事情。比如,我们该如何修改HTML的排版渲染机制呢?
所以,有些框架注重性能,有些框架注重开发效率,开发者做选择题的时候也应该衡量这两个问题,你的应用对哪些方面要求多一些呢?
你如果要开发一个视频监控系统,没多少业务功能,但要24小时不间断的记录视频数据,随时调取某一段时间的视频数据,这种应用可能Qt是最好的选择。
你如果要开发一个类似飞书的团队协作应用,业务逻辑复杂的一塌糊涂,而且要在短时间内满足更多用户的需求,占领更多的市场,那么Electron可能是更好的选择(目前飞书已经不再用Electron了,他们自己编译了Chromium核心,自己封了一个类似CEF的框架)
目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架,也在推各自的框架产品,说明桌面应用领域并没有没落,反而应该更加受到重视。
虽然移动端应用大行其道,但我认为,只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些,毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间,更强的存储和计算能力。
希望桌面软件开发领域的从业者都能获得幸福。
满屏荒唐言,一把辛酸泪,一把辛酸泪,一把辛酸泪...
很少有人不基于框架直接写GUI界面啦,我这个回答就从GUI框架反过来推什么语言做GUI合适。(只聊桌面端GUI编程框架)
几乎是C++领域最流行的跨平台桌面端软件开发框架了,这个框架是两个挪威人在1995年创建的,发展至今可以说历史相当悠久,稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。
它内置了自绘引擎,也就是说界面上的一个按钮,一个文本框,都是Qt的引擎自己画的,这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。
它提供了大量的与界面无关但与软件开发息息相关的API,比如、网络、文件系统、剪切板等,而且让这些API在不同的操作系统下都有效,这极大的节省了开发人员的时间。
但它也有一些缺点,比如在处理一些特殊需求上很不方便,比如:目前Qt有没有比较好解决高分屏下缩放显示的方案?,Qt没有真正完美的无边框解决方案吗?等,在一些组件的渲染上也会出一些隐藏的较深的问题(QListItem),一旦遇到,就很难解决。
Qt近年来不太专一,qml,qtquick等,搞了很多,而且这些新玩意儿一直不温不火,有些模块做了又废弃了,比如:qt script,搞来搞去,搞的模块繁多且复杂,用起来不是很舒服。
Qt有界面描述语言(XML描述界面),可以通过设计器拖拽空间设计界面,编译期界面描述语言被转义成C++代码,性能上没啥损失。
Qt商业授权不太友好,开发商业应用一定要谨慎,之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接,会有版权上的限制,但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。
除了使用C++开发Qt应用外,开发者还可以使用其他语言开发Qt应用,最流行的就是使用Python基于PyQt做Qt应用了,其他语言的绑定不是很成熟,但PyQt仍然有版权的问题。
GTK是1997年创建的,也非常成熟稳定,是C语言开发的,但有很多语言的绑定,比如官方支持的JavaScript、Rust等,当然用C++语言操作GTK也很方便,它也有自绘引擎(Cairo),也提供了大量系统相关的API,商业授权也非常友好,基于GTK开发商业软件不用担心收到律师函的问题,虽然它是一个跨平台桌面软件,但它似乎只在Linux操作系统领域流行,有非常多的Linux桌面软件都是基于GTK开发的。
这也直接导致GTK的维护者很重视Linux领域的发展,而忽视Windows和Mac领域。这个框架提供的很多API,只在Linux下有,Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。
GTK在Windows上也没办法静态连接,它到不是因为版权的问题,而是它依赖MSYS2的一些库,这个库用于在Windows上模拟Linux环境,这也是为什么GTK在Windows上表现不佳的原因之一。
另外,由于GTK是C语言开发的,所以开发风格也很C语言化,这对于部分开发者来说可能觉得繁琐。
wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件,也非常成熟稳定,商业授权非常友好。它没有自绘引擎,而是对不同平台下的界面API做了整合和封装,这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格,这对于某些软件来说,正是他们想要的,但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。
它是C++开发的,所以对C++开发者非常友好,除此之外它还支持静态连接,也就是说开发个应用不用分发给用户一大堆dll,当然Qt也支持静态连接,但是你得自己编译Qt的源码(不是很方便),而且Qt的授权规则也不允许普通开发者这么做。
它会有些小问题,比如我之前提的:wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice,但总体来说还是非常稳的。除了开发的界面比较死板外,没啥大的问题。目前使用这个框架开发软件的人越来越少了。
fltk是1998年创建的跨平台开源GUI框架,历史悠久,商业授权友好,而且C++之父也用它,它非常轻量级,支持静态连接,一个简单的应用编译后只有500K左右,非常赞,
它有自己的自绘引擎,没记错的话用的是OpenGL,但它的重绘机制是按区域重绘的,如果组件A所在的区域上存在组件B,那么A组件重绘时,会把B组件的给重回掉,开发者必须自己写代码处理这种情况。想象一下,如果你想实现一个A组件fade out的同时B组件fade in的效果,就会非常麻烦。
FLTK提供的一些组件样式都比较刻板,绘图API也比较少,你想实现一个漂亮一点的圆角按钮(它内置圆角按钮的圆角大小是不能改的),必须自己画,而且还得借助一些非常奇葩的手段才行(如果你想知道,可以联系我)
它是C++开发的,但API不够现代,用起来总体还算舒服的,它有Rust绑定:fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API,但非常少,几乎可以忽略。
Duilib
是2010年国内一个开发者开发的GUI开发框架,因为底层基于DirectUI开发,所以只支持Windows平台,不支持跨平台,开源协议友好,商用没有任何问题(需要附加Lincence文件),国内有很多大厂基于这个技术做桌面端应用,比如网易、腾讯、百度,这个框架是基于C++开发的,对C++开发者友好。但框架本身还有一些问题,比如对高分屏支持不佳、特殊控件绘制上也有一些小问题,除了界面相关的API外,几乎没有提供系统级的API,作者纯粹是用爱发电来开发这个框架,所以更新不是很及时。
相对来说网易基于Duilib开发的分支更完善一些:NIM_Duilib_Framework,添加了高分屏支持、多国语言、整合了多线程处理的支持,但环境搭建相对比较麻烦。如果开发者要用这个框架,一定要用develop分支下的代码,master分支下的代码问题很多,这个框架看上去也是作者一个人努力的成果。
Sciter是2006年创建的跨平台闭源GUI框架,足够稳定,商业授权不友好,但个人开发者可以随便用(只能用动态链接库),一旦公司规模超过3人,就得买版权了(有权静态连接)。
它内部封了一个浏览器核心,让开发者使用HTML,CSS,JS来创建界面,但对这个浏览器核心做了大量的精简,不像Electron和NW.js动辄上百兆的体积,它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的,比如CSS3的flex布局,它就不支持(但它提供了自己的flex布局实现方式)。以前它使用自研的一个脚本语言(和JavaScript很像),自从集成了Fabrice Bellard大神的QuickJs之后,就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持,比如渲染大列表。
它使用C++开发,对C++开发者很友好,有Rust、go、Python等语言的绑定,但都是社区提供的,质量堪忧。有很多知名厂商都用这个库做界面,比如360、teamviewer、赛门铁克等。
RmlUi和Sciter很像,可以看成Sciter的替代框架,但RmlUi这个项目有三界作者,一个一个的弃坑不知道新任作者会不会弃坑,目前还不是很成熟,比如我正在尝试帮作者解决的CJK输入法的问题,目前还不推荐大家使用这个框架。
CEF是2008年创立的,基于Chromium的跨平台GUI框架,稳定且商业授权友好,国内很多大厂都用的CEF:比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio,装机量破亿。
由于它几乎封了一个完整的Chromium,所以体积非常大,但支持所有的HTMLCSSJS特性,它几乎不提供任何与操作系统相关的API,创建个托盘图标、读写个文件啥的,都要开发者自己完成,它是C/C++开发完成的,对C++用户非常友好,它有gopythonjava等语言的绑定,但都是社区提供的,质量值得担忧。
它对Chromium封装的很好,避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道,很多功能都有默认实现方式,遵从约定由于配置原则,有经验的C++开发者可以很轻松的驾驭CEF框架。
由于Chromium是版本弟,所以CEF版本发布也非常频繁,很多被标记为稳定的版本,还是会出一些莫名其妙的问题,选一个好的版本非常重要。
与Electron一样,它也是分主进程和渲染进程的,所以开发者要非常娴熟的运用跨进程通信的技术,虽然CEF提供了跨进程相关的API,但复杂度还是有点高的,使用的时候要认真细心。
这是微软的跨平台GUI框架,不仅仅支持桌面端,还支持移动端,但官方并不支持Linux的桌面端(黑人问号,感觉与微软近些年向开放、开源的大方针相悖),这个框架新的狠,至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。
它是.NET平台下的GUI框架,有自绘引擎,对C#开发者很友好,界面依然是用XAML描述的,可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些,我觉得WPF没火起来跟XAML有直接关系。
使用这个框架开发桌面应用得封一个.NET框架给用户,当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。
这是JetBrains搞的跨平台GUI框架,也非常新,前段时间刚刚推出1.0.0版本,但这个版本还不是很稳,至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。
它的自绘引擎用的是Google的skia,这个自绘引擎稳的很,Chrome和Flutter都是用的它,所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。
JetBrains的东西当然对Kotlin开发者友好啦,Java生态下的很多东西你都能用,访问系统级API也没啥大问题,同样也得考虑封一个JRE给用户。
这是谷歌的跨平台开发框架,开源、免费、文档齐全、投入力度大且持久,同样也新的很,Windows版本刚刚发稳定版,Mac版本还没稳定。
如果你完全没搞过移动端的flutter,想用这个框架开发桌面应用,那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难,学习曲线比较平缓。
由于flutter在移动端积累了很多年,所以界面上的一些东西在desktop端都比较稳(skia自绘引擎),与操作系统相关的东西还不成熟,生态也不太好,比如你想订制一下窗口的标题栏,想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持,跟C/C++语言打交道很方便。
开发者直接使用Dart语言描述界面,这会导致众多大括号嵌套在一起的问题,可能很多开发者不习惯。
这是微软Edge浏览器团队推出的跨平台GUI引擎,是闭源的,目前只支持Windows,对C#和C++开发者友好,如果使用C#开发,就得考虑把.NET运行时分发给用户,如果使用C++开发,就得自己处理系统级API的操作,webview2本身是不对系统级API做封装的。
这个框架推出也没多久,很多API也还不稳定,更值得担忧的是这个团队,他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心,不知道他们会不会放弃webview2这个框架。
它的优势是可以复用系统当中已存在的webview2二进制资源,也就是说它虽然封了一个Chromium浏览器核心,但如果你可以确定客户电脑已经存在了基于webview2开发的应用,你的安装包体积可以足够小。
它也是多进程架构,甚至比Electron还要多一个进程(为了复用二进制资源),资源占用比较多。
这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题,Mac上使用Cocoa/WebKit,Linux上使用gtk-webkit2,Windows 10上使用Edge(也就是上一个小节里提到的webview2),它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。
开源且免费(MIT)有go、Rust、Python等语言的绑定,不过官方支持的是go语言,C和C++,操作浏览器的API非常少,不支持自定义scheme,更别提系统级API了。
采用的技术方案与webview类似,所以安装包也足够小,非常新,还没发布稳定版,开源免费。webview框架碰到的问题TAURI都有,
使用Rust开发,将来会支持Deno,作者说将来会直接使用webview的技术来支持多平台,
NW.js最早把Chromium和Node绑定到一起,用前端知识做界面,用Node技术访问操作系统,最早叫node-webkit,在2012年创建。NW.js基于MIT开源,可以无忧使用。没记错的话,微信小程序开发工具是用NW.js开发的。作者是英特尔的员工,英特尔的一些工具也是用NW.js开发的。
除了Chromium和Node的能力外,NW.js自己也封装了一些系统级API,类似托盘图标、剪切板、系统菜单这种,但数量明显比Electron要少。
NW.js可以在多个窗口间共享同一个Node.js上下文,而且还可以通过配置让Node的上下文和Dom上下文混合,这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信,哪些模块当前进程不能用这类问题。
NW.js虽然起步早,但奈何没有杀手级应用,周边的生态和工具链没发展起来。用的人越来越少,维护的投入也不如Electron大,再加上Chromium更新非常频繁,导致NW.js的有些API也不是很稳,恶性循环加剧。
Electron的作者曾经在NW.js团队工作过(NW.js项目贡献第二多的人就是Electron的作者),后来辗转到了github公司,于2013年在创建了Electron,也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron,所以从者甚众,生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方(多进程架构及模块归属进程),但瑕不掩瑜。
Electron每创建一个窗口都会多一个进程,这使Electron创建窗口的效率不高(秒级),NW.js有复用进程的机制,即使新窗口加载完全不同域的页面也不会创建新的进程(毫秒级)。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。
无论是浏览器相关的API,还是系统级API,Electron提供的都比NW.js多。
--------2022-02-25更新--------
这些框架除了对开发者使用的编程语言有要求外,还有一个重要的差异就是有没有独立的界面描述语言(也就是UI DSL),这非常重要,涉及到一个框架表达业务的重要能力。
类似XAML、qt的ui文件、HTML+CSS都是界面描述语言,下面这种也可以算界面描述语言,但我感觉它不够纯粹(flutter、qml和Compose Multiplatform都是类似这样的):
panel { row { checkBox(...) row { textField(...) // indented relatively to the checkbox above } } }
但无论如何,显而易见的是,没有任何一个界面描述语言能比的上HTML+CSS组合。想想看:HTML里各种花里胡哨的语义化标签和Dom操作技巧,CSS里的布局方式、伪元素、动画描述...,对比之下你就会觉得XAML、qml直流都是弟弟。
除此之外,一个优秀的GUI框架还有两个重要的需求,这里我简单聊聊:
强大的事件处理机制必不可少。
想想这些:鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外,还得处理事件冒泡、事件捕获、事件分发吧...
qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的(但影响很小)
强大的异步处理机制必不可少
你不能在用户处理业务逻辑的时候,让界面渲染工作阻塞,这就需要一个强大的异步处理机制,让开发者自己去开线程去完成业务处理,无疑是又麻烦又会增加开发者的心智负担。
我记得很早之前在C# WinForm应用中,点击一个按钮,如果不用Invoke执行逻辑处理的话,界面就会卡死。
这么看来,在你的GUI应用里包一个浏览器核心还是挺有必要的,这样你就可以用HTML+CSS强大的能力来描述你的界面,用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。
可能有人会想,这会带来很多问题呀,比如应用体积会增大的100M以上、会占用更多的CPU和内存资源,还会更耗电等等。
确实,目前来看这些都是问题,但仔细想想,这些问题应该不会持续太久,网络会变的更快,用户的磁盘和内存会变得更大,CPU处理能力也会更好,耗电的问题当然会持续存在,甚至会愈发耗电,但电的供应会持续增长呀。
web相关的技术之所以胜出,并不是这些技术的设计者有多厉害,而是这20多年间,有大量的人涌入了这个领域,前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答:
------------2022-02-27更新----------
用Web相关的技术做GUI应用的优势是,让开发者可以把大部分精力投注在业务本身上,而不是处理与GUI相关的技术细节。
实际上所有的框架,都应该是这个目的,比如ORM框架,目的应该是让开发者把大部分精力投注在业务与数据之间的关系上,而不是管理关系型数据的技术细节。
当然这肯定是有损耗的,在性能、稳定性、资源消耗上,都会有所削减。而且,因为有框架的存在,开发者很难深入到框架内部做一些特殊的事情。比如,我们该如何修改HTML的排版渲染机制呢?
所以,有些框架注重性能,有些框架注重开发效率,开发者做选择题的时候也应该衡量这两个问题,你的应用对哪些方面要求多一些呢?
你如果要开发一个视频监控系统,没多少业务功能,但要24小时不间断的记录视频数据,随时调取某一段时间的视频数据,这种应用可能Qt是最好的选择。
你如果要开发一个类似飞书的团队协作应用,业务逻辑复杂的一塌糊涂,而且要在短时间内满足更多用户的需求,占领更多的市场,那么Electron可能是更好的选择(目前飞书已经不再用Electron了,他们自己编译了Chromium核心,自己封了一个类似CEF的框架)
目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架,也在推各自的框架产品,说明桌面应用领域并没有没落,反而应该更加受到重视。
虽然移动端应用大行其道,但我认为,只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些,毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间,更强的存储和计算能力。
希望桌面软件开发领域的从业者都能获得幸福。
满屏荒唐言,一把辛酸泪,一把辛酸泪,一把辛酸泪...