想来想去,决定开个页面用来供奉各位支持过我的老板。
赞助我,让我贡献更多内容吧!
- 有了赞助,我会有更高的热情输出各种内容
- 可以在我的各种内容里获得致谢
- 可以定制感兴趣的内容

感谢剪辑同学的努力工作,第三集上线。
油管地址:https://youtu.be/0Ix-Y-MPQY0
B站地址:https://www.bilibili.com/video/BV1CxnJzfEAk/
继续分享 React Native+Expo 应用开发,帮大家补上全栈开发的最后一块拼图:移动应用开发。
在这个系列视频里,我会用一个入门级小应用 WhiteScreen 作为范例,介绍如何使用 React Native+Expo 开发移动应用,并上传到应用商店。虽然国内市场基本被几个超级应用垄断,但是海外的广阔天地仍然大有可为。而 React Native 可以最大限度的利用我们已有的技术积累,让我们快速完成原型开发与需求验证,是全栈开发的不二之选。
这期是第三次课,主要介绍:
希望能给大家带来更多的可能性,在这个不那么容易的年代,让大家都有更多的选择余地与发展空间。
希望大家留下宝贵的一键三连分享收藏,让更多的人能看到我的视频。
有任何问题和建议,欢迎留言弹幕一起讨论。
谢谢大家!

感谢剪辑同学的努力工作,第二集终于可以奉献给各位同学。
油管地址:https://youtu.be/YEPvihSIQkw
B站地址:https://www.bilibili.com/video/BV1ZgHoztE4v/
(更多…)
前几天我在博客 感谢赞助商 Mizu Financial,重启我的自媒体之路 提到,因为工作调整,下一阶段我要捡起自媒体,在新的工作开始之前,提升一下自身的品牌价值。所以,我开启了新系列视频教程的录制。
现在新视频终于上线,敬请观看。
油管地址:https://youtu.be/YEPvihSIQkw
B站地址:https://www.bilibili.com/video/BV1ZgHoztE4v/
(更多…)
最近开始尝试开发 App,倒不是什么复杂的大项目,只是把朋友网站上的功能移植到移动端。技术栈仍然是 React Native + Expo,不过以前只做过 iOS,这次连 Android 一起做。
那么自然的,这次就要踩 React Native Android 的坑。以后会分享所有相关的知识体验和坑,今天先分享最近两天花了不少时间解决的 Google Play 16KB memory page 问题。
我们的应用提交到 Google Play 后,原本一切正常,前两天突然收到 Google 的政策通知:
为确保您的应用能在最新版 Android 上正常运行,Google Play 要求以 Android 15 及更高版本为目标平台的应用支持 16 KB 内存页面大小。
自 2026年5月30日起,如果您的应用更新不支持 16 KB 内存页面大小,您将无法发布相应更新。
您的最新正式版应用不支持 16 KB 内存页面大小。
嗯,必须承认,看到这个问题我一头雾水。不过好在我也不需要把它理解透彻,只要知道该怎么改就好。可惜的是,Gemini 对这个问题没什么了解,我只好去阅读 Google 的文档,得到的结论是:
我需要修改 /android/app/build.gradle 其中的配置 useLegacyPackaging 将其改成 true:
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
不过我使用的是最新版 expo prebuild 生成的 Android 项目,所以这个配置本身依赖 app.json 的配置,那么理论上,我只需要添加下面这行:
{
"expo": {
"android": {
"useLegacyPackaging": true
}
}
}
于是我改好配置重新打包上传,结果还是不行。认真阅读 app bundle 详细信息,发现错误位于 base/lib/arm64-v8a/librnskia.so 和 base/lib/x86_64/librnskia.so ,很明显,这是 @shopify/react-native-skia 包,也就是我们的绘图依赖。
因为我的项目里用到 Expo,所以我一般用 Expo 安装依赖,安装的版本也由 Expo 决定。目前版本的 Expo 要求的 @shopify/react-native-skia 版本是 v2.0.0-next.4,在 GitHub issues 里搜索一下,发现这个版本果然不支持 16KB Memory page,而修复的版本是 v2.0.6。
按照我的习惯,有新不用旧。于是直接升级到 2.2.9,然后应用就挂了……于是降级到 v2.0.7(2.0 版本的最高版本),测试没问题。打包上传,终于解决了 16KB 警告。
简单总结一下:

感谢 Mizu Financial 成为本站的新赞助商,也帮助我重新拾起自媒体之路。今年由于种种原因,我的博客和视频直播几乎彻底中断。最近终于有了一些富裕时间,在开启下一份职业生涯之前,我准备先把自媒体捡回来。
介绍下赞助商:Mizu Financial 是一家硅谷初创企业,为北美和亚洲的中小型传统企业提供稳定币与比特币的财务管理 SaaS 服务,帮助客户在传统财务系统中安全接入数字资产,实现对加密资金的透明管理与自动化对账。公司成立于 2025 年 3 月,创始团队成员包括资深硅谷Web2/Web3 投资人、前 Meta 工程师、CMU 博士等连续创业者。
接下来,我会尽量在白天保持直播,写各种自己的和甲方的项目,把以前挖的各种坑填上,并保持博客周更,以对得起赞助商的支持。
(更多…)
Mizu Financial 是一家硅谷初创企业,为北美和亚洲的中小型传统企业提供稳定币与比特币的财务管理 SaaS 服务,帮助客户在传统财务系统中安全接入数字资产,实现对加密资金的透明管理与自动化对账。公司成立于 2025 年 3 月,创始团队成员包括资深硅谷Web2/Web3 投资人、前 Meta 工程师、CMU 博士等连续创业者。
(更多…)
此文参加了 TiDB 社区第四届专栏征文大赛,获得二等奖。感谢 TiDB,感谢 Gemini,感谢跟我一起做 Awesome Comment 的某同学。
有空的同学麻烦帮我投个票:https://asktug.com/t/topic/1046966 搜索“深潜”就能找到给我投票的地方
在数据库应用中,慢SQL是常见的性能瓶颈。本文将详细记录一次针对TiDB Cloud v7.5.2环境中复杂评论查询的SQL优化过程,如何通过分析执行计划、添加索引、改写SQL(使用EXISTS、UNION)等手段,将一个40多秒的查询逐步优化到11毫秒,希望能为读者提供有价值的实战参考。
不知道什么时候,TiDB Cloud 升级到 v7.5.2,于是我们的评论应用 RU 消耗开始起飞,达到以往月份的 3 倍左右。没办法,只好拖着病榻之躯来 Debug。还好 Gemini 2.5 Pro 给力,很快我就完成了这次优化,记录在这篇博客里。另外,这篇博客也是 Gemini 2.5 Pro 帮我写的,AI 之力,恐怖如斯 😱😱。
(更多…)
我准备报名参加今年 7 月在广州举办的 IPL 的力量举三项赛,具体组别是大师组 100KG。预测成绩510KG=S175+B135+D200。据说不会有很多选手,所以大概率能拿名次~
现在诚征赞助商!10块8块不嫌少,300、500不嫌多。全身广告位均可用,我还会配合博客、视频增加赞助商曝光,欢迎各位老板踊跃赞助,感恩,比心。
(更多…)