Registered users
Ricciflows
好好学习,天天向上!
粉丝数
15
关注数
0
阅读数
46,120
获赞数
18
动态
文章
帖子
提问
回答
收藏夹
Ricciflows发表了文章 2025-03-25 01:00:29

创意总会有枯竭的那天,但创新不会,唯有创新才有可能源源不断、永无止境

根据网上查到的资料,创意这个词是创新的子集:创意是创造意识或创新意识的简称,亦作“剙意”。它是指对现实存在事物的理解以及认知,所衍生出的一种新的抽象思维和行为潜能。但是我认为从实践中讲,更准确地,应该这样定义创意。假设创新是一个集合$A$,那么创意就是任意一个单射$f: B\rightarrow A$且满足$f(B)\subsetneqq A$。By abuse of notation,我们直接将其记作$B$。显然,此定义推广了创意的文字定义。怎么理解这个定义呢?首先两个定义的共同之处是——创意小,创新大。在生产实践中,创意的例子比比皆是,比如说一个商品的包装、一个产品的界面和logo、相同食材的不同煮法等等。这些创意有些是有限的,而有些看似无限其实也是有其上确界。我们可以将这个说法写成一个命题。命题/定义1. 任意一个创意$B$,都存在一个最小实数$M\in\mathbb{R}_{\geq0}$使得$\|B\| \leq M$。此数被称为创意$B$的上确界,并记作$\sup(B)$。为什么说创意是有限的?从生产实践中考虑,绝大多数有创意的产品,经过激烈的商业竞争,在不断的 产生新创意→被抄袭→产生新创意 的这个过程中,最后的结果往往都是创意逐渐枯竭,哪怕还是能挤出来,但是创意的新意已经逐渐下降,产生不了足够的效果。而通过创意取得成功,并在激烈的竞争中存活下来的产品,往往最后也不是靠创意,毕竟创意本身就很难作为护城河,人与人产生重复想法的概率是很高的。因此,我们可以衍生出一个概念有效创意与无效创意。有效创意即是上面所说创意,都是有限集。而无效创意则是在同构意义上,有效创意在创新中的补集。这时我们可以过度到创新了,在现实中,创新往往对应是科学理论以及科学技术。而这两者的发展往往都是无止境的,以数学为例,哪怕一个分支做不动了、死了,那也只是当前的数学工具不足以推动它的发展,如果未来某些领域取得新突破进而产生全新的数学工具,说不定就能借此“复活”那些“死去”的分支。历史上费马大定理、庞加莱猜想等这些问题之所以那么重要,不仅仅是问题的本身,还有解决问题过程中所诞生的新理论、新工具、新思想。所以,希尔伯特才会说他不想解决费马大定理,因为这个问题不解决比解决了好。一个世纪过去了,希尔伯特所列的那23个问题约有一半问题已经解决,其余一半的大多数也都有重大进展。但希尔伯特本人没有解决其中的任意一个。有人问他,为什么他不去解决自己所提的问题,譬如说费马大定理?费马是在一页书的空白处写下该定理的,他同时宣称自己已经想出了一个美妙的证法,但可惜的是空白区不够大,写不下了。希尔伯特的回答同样幽默:“我不想杀掉这只会下金蛋的母鸡”——德国一企业家建了一个基金会奖励第一个解决费马大定律者,希尔伯特时任该基金会的主席,每年利用该项基金的利息请优秀学者去哥廷根讲学,所以对他而言,费马大定律者是只会下金蛋的母鸡。(费马大定律直到1997年才被解决。)对比之下,可知创意往往是有限集,而创新却能是无限集。并且创新是创意诞生的源泉,即我们有这样一个命题命题2. 任意一个创新$A$,都存在一个满射$g: A\rightarrow B$,使得存在一个单射$f: B\rightarrow A$满足$g\circ f=1$。本文关于创意和创新的数学+实践讨论就先到这里,内容并不是十分严格,可以看成一种近似或者fuzzy。

Ricciflows发表了文章 2025-03-22 21:44:27

(✔已修复)弦圈APP下载附件功能存在问题,目前暂时无法修复。如若需要下载附件,请先用Web端

今天有粉丝反馈,弦圈APP里下载的附件并不能打开。接着我马上打开APP测试,发现文件确实是下载了,但是却找不到下载的文件,这也是当初测试的一个疏漏😢。不过令人沮丧的是,我目前找不到解决这个问题的办法😭。目前这个问题的原因已经查明,就是下载路径的问题。文件下载成功后所放的位置file:///data/user/0/com.sinering.manitori/files,在手机里是打不开的,里面的文件对于用户而言不可见。用户下载的文件相当于存到APP的数据里了,我目前也不清楚如何在手机访问这些文件,开发的时候可以通过Android Studio查看,但是这是真机。由于这是我第一次写APP,自己的技术水平有限,而手机端APP与Web端相比,同样的功能没那么好实现,复杂很多。目前这个问题,我暂时找不到解决办法,其实就是一行代码有问题需要修改。import { File, Paths } from "expo-file-system/next"; const new_file = new File(Paths.document, new_filename);就是上面这行代码里的Paths.document,想不到真机实际位置这么离谱,压根找不到。之后我会想办法修改一个合适的位置。最后APP更新没有Web端更新那么方便,因为我没有配置APP热更新(付费的),用的是冷更新,即每次更新都得下载新的安装包,因此挺麻烦的但未来这个问题会改善。2025/3/23 1:46 更新:原本我以为这个问题解决不了了,结果意外之喜,我还是找到解决方案了😁。刚刚所有APP下载方式都已更新,有下载附件需要的可自行下载更新(其实现在也没几个人下载APP用)。之后大家可以直接在手机APP端自由下载附件了!😇

Ricciflows发表了文章 2025-03-19 19:08:07

是否存在人类大脑永远无法理解的数学结构?

是否存在人类大脑永远无法理解的数学结构?答案是存在也不存在。这个问题重点在于“理解”这个词,怎么样才算是理解?本文中,我们就将理解分为直观理解和抽象理解吧。所谓直观理解,指的是能够通过五官直接感受到。基于这个定义,数学从线性代数中最基础的n维线性空间开始,就不是人脑能够直观理解的了,毕竟人脑只能理解四维以下的空间,即只能理解三维的空间,不能理解处在第四维度的时间。到目前为止,四维时空是否存在都还存在争议,因为并没有直接证据表明四维时空真实存在。因此,从物理世界来看,人脑从四维线性空间开始就无法直观理解了。抛开四维空间是否真实存在的物理争议,考虑纯粹数学上的定义,四维空间是存在的。那么有可能通过作图的方式来直观理解高维空间呢?不能。那些所谓画出四维及以上空间的图,其实是通过投影等方法实现降维,将高维空间的东西通过三维的形式表现出来,并不是真正的高维空间。既然存在那么多大脑无法理解的数学结构,这时数学就派上用场了。数学正是人类用于理解人脑无法直观理解的工具,因为人脑有个很强大的功能——抽象化,既然你无法想象、也无法理解,那干脆就将它抽象化为一个数学对象来研究,即抽象理解。人类对于高维空间的理解都是抽象化的,看不见摸不着,只存在于精神世界中。这里又引申出两个有争议的问题人脑是否就是一个宇宙?因为人脑里面的结构,跟大尺度下宇宙网的结构十分相似。人脑是否其实能理解高维空间?但是它可能不通过五官来理解,这就解释了所谓的第六感。本文不过多讨论这两个问题。抽象化和公理化,是数学中的强力武器,数学大厦的建成他们功不可没,现代数学就是从无数的抽象化,然后公理化的过程中诞生的(见数学的发展实际上是一个不断抽象的过程)。在数学中,抽象且无法直观体现的概念无处不在,尤其是在代数几何,任何数学对象都是高度抽象化的,很多数学结构甚至找不到具体的例子。但这不影响数学家们理解它,因此大脑是可以抽象理解几乎任何东西的,直观理解不了,就抽象理解。这里我说的是抽象理解“几乎任何东西”,多了个几乎,为什么不是所有?因为从这里开始,就引申出了一个有争论的哲学问题:宇宙中所有东西都能被数学所描述、解释吗?这个问题在之前的一篇文章 数学与物理公式可以精准简洁地描述自然现象,究竟是世界本就如此巧妙,还是科学家努力简化后的结果?中曾经讨论过。如果能,那么人脑无法“理解”的数学结构,其实就是人没弄懂或还未发现的数学结构。比如说有外星人将未来数千年后的数学给人类看,那自然无人能够理解。就好比古代人类无法理解现代数学一个道理。但是如果外星人的数学发展水平与人类相似,那么即便语言不同,理论上人是可以理解他们的数学的。如果数学并不能描述宇宙中的所有事物,那么哪怕人脑可以理解所有的数学结构,也不可能理解宇宙中的所有结构和规律。这也就意味着包括爱因斯坦在内,许多著名物理学们的信仰崩塌,并且这样的信仰崩塌在数学中也会出现,结果就相当于数学危机+物理危机了。因为所有东西都能数学化,所有好的数学都应该是简洁而美妙,等等这些思想和理念,早就渗透到数学与物理的方方面面,这也是无数人喜欢数学或者物理的原因之一。不过也不必过于悲观,说不定到那时候会发现一个叫做“超数学”的新学科,即数学的超集($\textrm{数学}\subseteq \textrm{超数学}$)。这样所谓东西又能被超数学所解释了,有点套娃那味了。。又或者是数学会继续迎来一次像集合论那样,底层的革新,于是产生无数全新的分支,用于重新解释宇宙。

Ricciflows发表了文章 2025-03-19 12:17:46

数学与物理公式可以精准简洁地描述自然现象,究竟是世界本就如此巧妙,还是科学家努力简化后的结果?

这个问题有点像数学究竟是人发明的,还是人发现的?每个人基于不同理念、哲学观,会有不同的答案。而如今这个问题,可以引申出几个类似的问题。世界的底层运行规律究竟是复杂的,还是简洁的?物理定律究竟是真理,还是人类为解释宇宙而创造的?(类似于数学是否人造?)数学定理或者物理定律是绝对真理吗?或者说存在绝对真理的数学定理或者物理定律吗?这些问题都涉及到一种哲学观,没有标准答案,只是你观念的不同。回到这个问题,我是持爱因斯坦的那种观点,认为宇宙能够由简洁而优美的数学所描述,因为宇宙的底层规律本身就是足够简单的,只是人类未曾发现。换句话说,这就有点像线性空间的基底一样,只需要几条简单的定律,就可以通过线性组合,不断复杂化,最终产生如今的宇宙。这里又涉及到一个问题,即这个线性空间到底是有限维的,还是无穷维的?不过基于世界本质的简单性,从审美角度出发,我更倾向于假设这个线性空间是有限维的。因此,从这个角度看,如果数学或物理公式不够简洁和美妙,那么其本身所蕴含的奥秘也就越浅显,并且距离世界的本质就更远,即引用高斯的话“距离神更远”。故而简洁的数学或物理公式,更多的是科学家们发现的结果,是自然的,而不是刻意简化的结果。

Ricciflows发表了文章 2025-03-18 11:59:21

前端跨平台开发框架对比:Flutter vs Tauri vs React Native

传统移动端开发往往需要同时兼顾Android和IOS的开发,而桌面端开发又需要同时兼顾Windows、MacOS、Linux系统。如果你想要全平台覆盖,不仅意味着要同时维护多套完全不同的代码(极大提高了维护成本),并且代码和逻辑还可能不能复用,这意味着高昂的开发成本(极低开发效率),每个平台都得从零开始写。现在国内还多出个鸿蒙系统,这意味着你要同时开发和维护更多套代码,哪怕补贴钱,这成本也不是小企业能够负担得起的。于是,跨平台框架应运而生,Facebook开源的React Native,曾经是最流行的框架,不过近几年被Flutter超越。它不仅能让你使用React语言同时开发Android和IOS APP,甚至还能进行Windows桌面端开发。而谷歌开源的Flutter,是目前最流行的跨平台框架,略微领先React Native。它能让你使用dart语言开发移动端与桌面端应用。而Tauri则允许你使用任何前端框架进行全平台开发,不过也需要你懂得一些Rust语言。我们先从开发体验出发来对比这三个跨平台框架。首先,React Native能够让你完全用JSX语言来进行跨平台开发,这对于本身熟悉Web技术的Web开发者而言无疑是非常好的。这意味着他们不需要多余学习太多东西即可直接上手。不过React Native虽然前面带个React,却跟Web端React本身有很多不一样的地方(见 给Web开发者写的React Native简介,React Native与React的区别与对比(1)),因此同样需要开发者去适应。而Flutter对于Web开发者而言就没那么好上手了,它需要开发者掌握dart语言进行开发。dart语言跟JavaScript有很大不同,这会让Web开发者觉得“反人类”设计。不过dart的语法跟Java或者Swift有点像,对于Android或者IOS开发者而言,Flutter或许倒没那么难上手。最后Tauri可以说是对Web开发者最友好的跨平台框架了,它允许你使用任何前端框架进行开发。不过想要开发完整的应用,你免不了得懂一些Rust,毕竟Tauri其实就是个Rust GUI框架。而Rust对于新人而言,学起来可比学C++要难一些。接着从性能出发(不准确),React Native会将所有代码编译成原生组件,生成UI画面则是通过原生的渲染,性能上比较接近原生应用。而Flutter则不使用原生的渲染模式,它自己在不同平台使用不同方法实现画面的渲染,性能方面比React Native稍好。最后Tauri通过调用各个平台的WebView来渲染画面,底层使用Rust来进行WebView与OS系统的通信,性能似乎比Flutter和React Native差一些。更细节、更准确的对比网上已经有许多了,我就不过多评价了毕竟性能这方面我也不太懂。最后从生态出发,React Native许多功能的实现非常依赖于社区的第三方库,而有很多库已经没人维护了。Flutter据说也好不到哪里去,但根据我自己的搜索,像渲染HTML、富文本编辑器、渲染数学公式,以及微信、支付宝接口,这些功能Flutter的支持似乎比React Native的要好,故而从整体上而言,Flutter的生态比React Native的要好,这也意味着在React Native想要实现相同的功能,可能要耗费更多时间。而Tauri呢能够完全使用整个Web端的生态,前端方面自然不用多说,主要是Rust的生态还是太不成熟了,有些Rust库早已过时但也没人维护,这就导致有些Tauri的插件用不了,因此你可能会在Rust方面耗费大量时间。总之,移动端方面React Native、Flutter、Tauri各有优劣,对于熟悉Web技术的开发者而言,React Native可能是最好的选择,Tauri次之。但从整体出发,Flutter可能是最好的选择,React Native次之。

Ricciflows发表了文章 2025-03-17 23:14:31

国内曾经出现过很多的数学论坛,但是为什么如今大多数都访问不了了?

今天我在知乎宣传弦圈的时候,回答了一个问题有哪些数学论坛值得推荐?,结果发现有好几个回答里的数学网站已经访问不了了。这些回答里的几乎所有数学网站,我都未曾听说过(正如弦圈很多人不知道一样),这证明国内曾经也出现过很多数学论坛,有些或许曾经也辉煌过,但是最后都坚持不下去了。我做数学的时候,用的数学论坛基本上都是国外的MathStackExchange和Mathoverflow,知乎也很少用。可以说国内目前除了知乎,就没有高人气的数学论坛。毕竟本来纯数学就是一种非常小众的文化,而数学这种严肃的内容,也注定不会有高活跃、高互动的用户。因此可以看到很多国内的数学网站都已经不能访问了,有些还“活”着的,其实也是半死不活,空有用户量,但活跃度却低得可怜。而知乎的数学也早就变味了,彻底娱乐化了,真正有营养的内容已经没多少,真正有实力的大佬也相继退乎,回答都删得干干净净的。似乎中文互联网中已经没有太多数学文化的栖息之地了。国外虽然也好不到哪里去,但却跟国内天差地别,最大的MathStackExchange和Mathoverflow两个数学论坛,虽然也是不能盈利,纯粹靠捐赠维持生计,但是却能保持纯粹的数学氛围。做个纯粹的数学论坛其实就是在做慈善,不仅要维护前后端两套代码,还得兼顾数据库和服务器的运维,前端、后端、数据库、服务器,这四个全是不同的技术,有些甚至毫无关联,都需要你逐个学习。这还没完,你以为只要有技术就可以了?还有像ICP备案等各种琐事烦着你呢。服务器费用也不便宜,当然你可以降低用户体验选配置最低、最便宜的服务器,但这只是缓兵之计,你做一个网站出来肯定也希望人多些吧,但是人多了以后,服务器成本直线上升。而数学网站因其内容本身,就注定没有太大商业价值,打广告也难,想赚回本似乎都不太可能。理想终究只是理想,没有现实物质的支撑,没有任何意义。因此,弦圈在上线以来就不局限于数学内容,其实弦圈刚上线时,我主要更新的也是编程的内容,只是后来发现数学内容看的人也没想象中的少,我就更了很多数学内容。我直到现在也在不停尝试不同类型的内容,这也是圈子的意义,能够容纳不同类型的内容,纯粹靠数学内容真的走不远。我不太喜欢知乎这种数学娱乐化的形式,我更喜欢娱乐跟严肃界限分明,这也是弦圈的意义。我宁愿放弃更新数学内容,也不打算做娱乐数学。最后也感谢大家对弦圈的支持,没有你们的支持,我很难坚持到现在😃。

Ricciflows发表了文章 2025-03-14 19:01:49

给Web开发者写的React Native简介,React Native与React的区别与对比(2)

本文我们继续之前的话题给Web开发者写的React Native简介,React Native与React的区别与对比(1),在上文中我们讲到在React Native想要写<p>或者<span>需要用Text组件。除了展示文本,还有一个很重要的东西就是展示图片。在React Native中你无法使用HTML的<img>,而要用React Native提供的Image组件。处理图片可以说是React Native中的一个难点,因为在React Native中无论是什么图片都需要你设置一个宽度和高度,见实例:import React from 'react'; import {Image} from 'react-native'; import {SafeAreaView, SafeAreaProvider} from 'react-native-safe-area-context'; const DisplayAnImage = () => ( <SafeAreaProvider> <SafeAreaView style={styles.container}> <Image style={{ width: 50, height: 50 }} source={require('@expo/snack-static/react-native-logo.png')} /> <Image style={{ width: 50, height: 50 }} source={{ uri: 'https://reactnative.dev/img/tiny_logo.png', }} /> <Image style={{ width: 66, height: 58 }} source={{ uri: 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADMAAAAzCAYAAAA6oTAqAAAAEXRFWHRTb2Z0d2FyZQBwbmdjcnVzaEB1SfMAAABQSURBVGje7dSxCQBACARB+2/ab8BEeQNhFi6WSYzYLYudDQYGBgYGBgYGBgYGBgYGBgZmcvDqYGBgmhivGQYGBgYGBgYGBgYGBgYGBgbmQw+P/eMrC5UTVAAAAABJRU5ErkJggg==', }} /> </SafeAreaView> </SafeAreaProvider> ); export default DisplayAnImage;你不能像在Web端那样直接写个width: 100%就完事了,由于React Native并不会计算图片的高度,所以如果你没有给高度设置一个数值,那么图片将会不可见。因此,在React Native想要实现Web端里width: 100%; height: 100%的图片,就需要你动态计算每张图片的高度(宽度固定)。好在React Native提供了getSize() API,允许你得到每张图片的原始宽度和高度,你可以根据自己的需要用这个API来造轮子。图片除了宽度和高度两个重要属性,还有一个很重要的属性就是resizeMode,这个对应Web端CSS的object-fit。而跟Web端不同,resizeMode的取值并非跟object-fit一一对应,并且resizeMode的默认值是cover,即图片会自动裁剪以保持宽高比。除了使用React Native本身的Image组件,你也可以使用expo-image,或者react-native-fast-image。不过fast-image已经没有维护了,倒是有个fork这个库的有维护,有需要的可以自行寻找。说完Image,还有一个很重要的东西就是列表List了。在Web端只要你的内容超出了屏幕高度,那么滚动是很自然的事情。但是在React Native仅仅使用View组件是不能滚动的,内容超出屏幕高度的结果就是内容不可见,想要滚动就需要用到ScrollView。而ScrollView提供了大量的API,可以让你非常方便的设置需要跟滚动相关的东西,这跟Web端相比是一个优势。比如说实现无限滚动,在Web端你要么使用别的组件,要么自己实现,实现方法大多都比较复杂,不仅要监听滚动,还要考虑很多其他东西。而在React Native你只需要将相应的handler放到onEndReached这个prop里,当滚动到底部时就会自动执行一次你的handler。又比如监听滚动,在Web端你需要在页面挂载时添加监听器,然后在页面卸载时去掉监听器,而在React Native你只需要直接将handler放到onScroll这个prop里就可以了。见下面例子:const App = () => { function load_more(){ console.log('end!') } function ScrollHandler(e){ console.log(e) } return ( <SafeAreaProvider> <SafeAreaView style={styles.container} edges={['top']}> <ScrollView style={styles.scrollView} onEndReached={load_more} onScroll={ScrollHandler}> <Text style={styles.text}> Long Text...... Long Text...... Long Text...... Long Text...... Long Text...... Long Text...... Long Text...... Long Text...... </Text> </ScrollView> </SafeAreaView> </SafeAreaProvider> ); }除此之外,你还可以设置水平滚动,甚至水平换页实现走马灯效果。ScrollView只是List最简单的一种方式,它会一次性渲染所有子节点,因此性能不好。这时,FlatList和SectionList就派上用场了,他们继承了ScrollView的几乎所有特征,并且性能更好。而FlatList是其中使用率最高的,它提供了numColumns属性,允许你轻松构建网格布局。而除了React Native本身提供的组件,对于大数据列表,你还可以使用第三方库FlashList或者RecyclerListView,来替代FlatList获得更好的性能。值得一提的是,FlashList除了是高性能列表,还提供了瀑布流布局的列表组件MasonryFlashList。说完列表,我们来讲一下React Native的触碰事件。在React Native你不能像在React Web端那样,随便一个地方都能设置onClick。并且React Native只有Press事件,你需要在特定的组件如Touchable、Pressable、Text、Button才能处理Press事件。其中Touchable组件分为TouchableHighlight、TouchableOpacity、TouchableWithoutFeedback,顾名思义他们分别对应触碰高亮、触碰改变透明度、触碰无反馈(触碰不改变样式)。而Press事件在Pressable和Text又分为Press和LongPress。<Pressable onPress={onPressFunction} onLongPress={onLongPressFunction}> <Text>I'm pressable!</Text> </Pressable>最后,想要写按钮和输入框,需要Button和TextInput组件,React Native的按钮自带样式比HTML的按钮要好看,并且安卓版点击按钮自带波纹效果。而React Native的输入框使用体验跟Web端的大体一样,就是提供props有些不同,这里就不多说了。本文到这里,已经将React Native跟React的主要区别过一遍了。由于篇幅问题,更多的内容以及细节就不详细展开了。之后我还会更更多React Native相关的文章,如果你对React Native感兴趣,欢迎在评论区交流讨论。

Ricciflows发表了文章 2025-03-13 23:26:03

弦圈登录功能完成更新,之后只要登录一次便可长期保持登录

原标题:弦圈登录功能完成更新,之后只要登录一次便可长期保持登录。目前该功能仍在测试阶段不稳定,如果发现有登录后掉线问题,可以试试清空cookie。这几天,我对弦圈的登录功能进行了更新,换了目前最新的OAuth2技术,取代以前的session登录。基于OAuth2的登录功能有很多好处,首先第一个就是能够长时间的保持登录状态,现在大家上网,无论是哪个平台,你都会发现自己只要登录一次,哪怕过了很久再打开,仍然是登录状态。第二个好处就是,token是无状态的,因此会占用更少的服务器资源,这意味着弦圈负荷更小、访问更顺畅。旧登录功能基于session是有状态的,如果人多起来,服务器负荷直线上升,这或许也是之前卡的原因之一吧。由于我是第一次在Web端使用OAuth2实现登录功能,因此刚开始更新的时候,网站还是有很多bug。比如说最大的一个bug就是,关闭浏览器后重新打开,需要重新登录,这显然问题很大。而这个bug今天经过我整整一天的艰难调试,终于是修好了。别小看一个简单的登录功能,尤其是OAuth2,前后端实现真的挺复杂。最后虽然网站代码已经更新好了,但是用户浏览器里的cookie是不会因此自动删除的,这就会导致一个问题:打开某些页面,如“写文章”,会掉出登录状态,而且重新登录还不行,刷新也不行。目前这个问题确定是重复cookie问题,右键打开浏览器开发者模式(或者按F12),然后清空cookie即可修复问题。除了这个问题,刚刚上线时还发现了一个测试时没有的问题,就是登录后无征兆掉线,暂时没找到原因。。。真的离谱,只能说基于OAuth2的登录功能,Web端没有手机端APP稳定。如果最后没能解决这些问题,我会用回旧的登录功能。更新:由于生产环境上有未知bug,且无法解决,放弃新登录功能。作为替代方案,我优化了旧登录功能,一样能长期保持登录状态。

Ricciflows发表了文章 2025-03-13 00:18:32

给Web开发者写的React Native简介,React Native与React的区别与对比(1)

React Native是React下的一个跨平台框架,能让你用熟悉的React JSX语法来进行跨平台开发。所谓的跨平台开发是如今的一种趋势,即用同一种语言来同时进行Web端、手机端安卓与IOS、桌面端Windows、MacOS、Linux的开发。这样不仅能极大的提高开发效率,同时大大增加了代码的可维护性,节省了大量的成本。然而React Native虽然带个React,用的也是JSX语言,却跟React有很多不一样的地方。因为React Native不仅面向网页端,还面向手机端APP,而React Native的代码会直接编译为native原生代码。在本文中,我将会列举说明几个React Native的不同之处。首先,在React Native中我们不能像React那样直接使用HTML语言,因为无论是Android还是IOS,都无法编译HTML语言。因此,我们需要使用React Native提供的组件。在React Native中,如果你想要写<div>,则需要换成<View>。View组件在Web端会被编译成<div>,而在Android和IOS则分别对应android.view和UIView。更多的,如果你想要写<p>或者<span>,那么你需要写<Text>。Text组件可以嵌套(nested),而两个Text在一起会跟p一样换行<View> <Text>1</Text> <Text>2</Text> </View>需要注意的是,在Web端你可以在任意HTML标签里写字符串,如<div>Hello!</div>,但是在React Native你不能在Text外写任何字符串,不然会报错。有了<View>和<Text>(<div>和<p>)你很自然的想要修改他们的样式。在Web端React,你可以写CSS然后通过className来设置样式,或者直接写style来改变样式。而在React Native中,你只能通过style来设置样式,并且CSS属性还跟Web端有很多不同。而设置style的方式也跟Web端React有一些不同,倒是跟Vue挺像。首先跟React一样的是,你可以像className那样写style:<View style={styles.container}></View>,也可以直接写<View style={{ marginTop: 50 }}></View>。而第一种写法,你需要在函数体(functional component)外将style写下来,具体例子见下(来自官网):import React from 'react'; import {StyleSheet, Text, View} from 'react-native'; const LotsOfStyles = () => { return ( <View style={styles.container}> <Text style={styles.red}>just red</Text> <Text style={styles.bigBlue}>just bigBlue</Text> <Text style={[styles.bigBlue, styles.red]}>bigBlue, then red</Text> <Text style={[styles.red, styles.bigBlue]}>red, then bigBlue</Text> </View> ); }; const styles = StyleSheet.create({ container: { marginTop: 50, }, bigBlue: { color: 'blue', fontWeight: 'bold', fontSize: 30, }, red: { color: 'red', }, }); export default LotsOfStyles;是不是感觉跟Vue有一点像😂。说完style的语法,接下来就是CSS的属性了。在React Native中,View的display属性默认是flex,并且只有flex或者none可选,并没有Web端的block值。而flexDirection跟往常的一样,除了默认是column,跟Web端相反。因此,在React Native所有layout都是基于flex的,要么不显示(none),要么flex,这跟Web端有很大不同。默认flex也意味着,你想要居中任何东西会变得非常方便,如果你使用React Native版Tailwind CSS——NativeWind,那么你只需要加上className="items-center"。在React Native中,flex: 1将会变得尤为重要,一个screen中的第一个View往往不能全屏,这时就需要flex: 1,而有时字体溢出需要加上flex: 1才会正常。除了flex外,React Native中的margin与padding也与React不同,以margin为例,你不能这样写margin: 10 20,你只能这样写marginHorizontal: 20; marginVertical: 10,而其他属性像marginLeft这些跟原来一样。在某些情况下,我觉得这种写法比Web端还要方便。接着,React Native的边框属性border也跟React有些不同,你不能直接这样写border: 1 solid #ddd,你只能这样一个个列出来borderWidth: 1; borderStyle: 'solid'; borderColor: '#ddd'。而在React Native中position属性只有absolute, relative, static可选,这也意味着如果你想要实现sticky相关的layout,如sticky header、collapsible tabview等,会变得十分困难。而这在Web端,你只需要加个position: sticky或者加个static转到fixed的监听器就能做到。说完View,我们说Text。在React Native中,想要实现文本单行溢出省略或者多行溢出省略,比Web端简便得多。你只需要设置numberOfLines即可:<Text numberOfLines={1}>666666666666666666666666666666666666666666666666666</Text> <Text numberOfLines={4}>999999999999999999999999999999999999999999999999999</Text>需要注意的是,这是唯一方法,你不能像Web端一样设置-webkit-line-clamp: 4或者text-overflow: ellipsis。由于篇幅过长,我将会在下一篇文章中继续本文的话题。

Ricciflows发表了文章 2025-03-12 00:31:56

React Native UI库介绍与对比

React Native的生态与React.js相比,没那么丰富,或者说手机端的生态本身就跟Web端相差甚远。React.js作为Web端虽然生态丰富,但由于其JS库大多数都不能直接用在React native中,因此很多在Web端存在诸多解决方案的问题,如代码块高亮、渲染数学公式,在手机端都难找到合适的办法。React Native的UI库,其实可以选择的并不多,不像Web端百花齐放,选个UI库都能选择困难症。在本文,我将会介绍几个我所知道的React native UI库,其中有几个我是用过的。1. React Native Paper这是一个Material Design风格的UI库,在GitHub拥有13.4k个stars,官方文档👉React Native Paper。该库安装步骤简单,组件使用以及自定义也容易,唯一的缺点就是组件不够多,有些场景需要你另外补充其他库来满足需求。React Native Paper应该是React native唯一一个Material Design UI库,该库能够跟React native navigation整合,构建Material风格的底部导航栏(见下图)。如果你喜欢Material Design风格,那么React Native Paper绝对是不二之选。值得一提的是,安卓版的原生风格本身就是Material Design的。下面是React Native Paper的安装命令:npm install react-native-paper react-native-safe-area-context react-native-vector-icons更多安装细节请看Getting Started。2. Tamagui这是个能够同时在React与React Native使用的UI库,在GitHub拥有12.2k个stars,官方文档👉Tamagui。不推荐使用这个UI库,它是我写React native所用的第一个UI库,当时我被官方文档的UI所吸引,结果自己安装后运行才发现,UI风格得自己设置,官方的UI好像得花钱买。这还没完,Tamagui的theme设置非常麻烦与复杂,很多人表示自己看了半天都没搞懂文档在说什么,有些人甚至说不知道哪来这么多星。而Theme的设置是避免不了的,Tamagui相当于headless刚开始几乎没有任何UI风格,需要你自己设置自己的主题。加上Tamagui引入了过多的概念,如style还得考虑什么size token,总之最后我放弃了这个UI库。如果你想要体验这个UI库,由于安装过程比较长,请看Installation。3. React Native Elements这是个组件相当丰富的UI库,其在GitHub已经积累了25.3k个stars,官方文档👉React Native Elements。不过我没用过该库,主要原因是该库似乎已经过时了,没人维护,上一个release还停留在2023年。该库的作者目前把主要精力放在了另一个新的UI库——gluestack上了。4. GluestackGluestack也是一个可以同时在React跟React Native使用的UI库,可以看成是React Native Elements V2,这个库目前在GitHub积累了3.5k个stars,官方文档👉gluestack-ui。这个UI库的组件还算丰富,像BottomSheet和Actionsheet都有,不需要你额外安装其他React native库。5. Ant Design Mobile RN这是唯一一个国产的React Native UI库,喜欢antd风格的可以使用,官方文档👉Ant Design Mobile RN。Antd RN组件还行,至少比React native paper多,最主要的是有form组件,这对于有表单验证需要的人来说很友好。同时还有Carousel、ActionSheet、Modal,这就不需要你安装太多其他的库。6. RNUILibRNUILib也是一个组件相当丰富的UI库,并且它还提供了很多特殊组件,如键盘相关的组件,官方文档👉RNUILib。同时,它还是唯一一个有WheelPicker的UI库。目前RNUILib在GitHub已经积累了6.7k个stars。除了WheelPicker,RNUILib还提供了DateTimePicker、KeyboardAccessoryView等这些在React native难实现的组件,这些组件在其他UI库都是没有,但它们的需求却不少,这也是RNUILib一大特点。本文React native的UI库就介绍完了😄,不知道你喜欢哪个UI库呢?欢迎在评论区发表你的看法吧!😇