我写了一个TypeScript虚拟机【闪点清单】

TypeScript(TS)是一个伟大的发明,让我们在复用JS生态的同时拥有了静态类型语言的开发体验。TS本质是一门预编译语言,编译到JS后再使用JS虚拟机执行,由于强依赖于JS,也因此无法摆脱JS的一些顽疾,比如执行效率。而TS本身是静态类型语言,拥有确定的数据类型标记,只是在转义为JS时丢失了类型标记;如果我们能直接执行TS程序,而不是先转义为JS再执行,这些数据类型标记可以为程序带来很大的性能提升。…

从0开始设计Flutter独立APP | 第三篇: 一劳永逸解决全局BuildContext问题

鉴于Flutter的高性能渲染、跨平台、多端一致性等优势,闪点清单在移动端APP上,使用了完整的Flutter框架来开发。既然是完整APP,架构搭建完全不受历史Native APP的影响,没有历史包袱的沉淀,设计也能更灵活和健壮。全局BuildContext,几乎是所有Flutter开发者的一个痛点。这个痛点有多痛呢?我们来列举一下场景: 路由跳转、弹窗、媒体查询,全部依赖于BuildContext,如果在Service层(或其他非UI层)做这些操作,必须要逐层传递正确的BuildContext实例。依赖于BuildContext的逻辑,必须写在某一个页面的Widget初始化中,否则无法拿到正确的BuildContext;而一些全局初始化的逻辑必须要写在某一个页面里,而如果首次唤起的不是这个页面,需要手动保证初始化逻辑不出问题。获取当前前台页面的路由,可以用ModalRoute对象,但必须拿到目标页面的BuildContext才可以,Navigator的BuildContext是拿不到的。MediaQuery、Navigator、Overlays的BuildContext不是一个,不能用错了。Flutter绝大部分第三方UI库是依赖于BuildContext,意味着你必须要在APP初始化后才能使用这些库,即使是toast这样的工具UI。等等等等......社区推荐方案在Android中,我们可以用getApplicationContext解决全局context问题,Flutter官方并没有提供建议的方案,不过社区有一些推荐的解决方案,比如使用GlobalKey的方案: @override Widget build(BuildContext context)…

从0开始设计Flutter独立APP | 第二篇: 完整的国际化语言支持

国际化语言的支持,是很多APP都有的一个强需求,APP无论大小,只要还不想放弃国外的客户,一般就需要支持国际化。 鉴于Flutter高性能渲染和跨平台的优势,闪点清单在移动端APP上,使用了完整的Flutter框架来开发。既然是完整APP,架构搭建完全不受历史Native APP的影响,没有历史包袱的沉淀,设计也能更灵活和健壮。…

从0开始设计Flutter独立APP | 第一篇: 数据库与状态管理

鉴于Flutter高性能渲染和跨平台的优势,闪点清单在移动端APP上,使用了完整的Flutter框架来开发。既然是完整APP,架构搭建完全不受历史Native APP的影响,没有历史包袱的沉淀,设计也能更灵活和健壮。 首先列举部分闪点清单的业务特性(较为通用的业务特性): 数据存储上,以本地数据为主,服务器同步为辅前端状态逻辑较为复杂,跨页面、跨组件状态更新频繁这几个业务点,设计到的技术选型有:本地数据库、前端状态管理,对很多业务来说,这几点都是比较核心的东西,也是我们今天重点要讲的内容。 数据库选型数据库选型,首先要定的,就是选择数据库类型:关系型数据库、非关系型数据库还是Key/Value存储。 对于关系型数据库,可选的有比如:SQLite、Core Data、GreenDao等;对于非关系型数据库,可选有Realm、UnQLite等;对于Key/Value存储,有比如Redis、Berkeley DB、Level DB等。 由于业务形态具有复杂的查询场景,所以首先排除了Key/Value存储;然后鉴于业务迭代频繁,数据结构变动较大,所以完全的关系型数据库使用成本会较高,版本更新时在数据兼容和数据清洗方面要做较多的工作;…