我写了一个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存储；然后鉴于业务迭代频繁，数据结构变动较大，所以完全的关系型数据库使用成本会较高，版本更新时在数据兼容和数据清洗方面要做较多的工作；…