Bood

Bood

Android developer and Emacs user at Glow

Shanghai
2 posts
Website

在线查询系统性能优化

背景 在最近的一个项目是一个后台管理工具,WEB端需要根据后端录入的数据,显示一个庞大的表格。主要的几点需求如下: 每条记录包含多个字段,都需要显示在WEB端界面上 其中有些字段并不能通过数据库查询直接得出,需要另外计算得出 支持设置过滤条件和按字段排序 需求变化很快,字段可能随时调整 对此,后端为了整体解决,会把查询得到的所有记录都合并到一起作计算,得到包含所有字段的完整数据。有了完整的数据,之后的过滤和排序就相对容易实现了。 问题 这种设计在项目初期的确对快速变化的需求表现出了良好的应变能力。然而随着数据量的增加,该方案也出现了明显的性能问题,经分析发现主要的问题出在以下几个方面: 随着数据量增加,对所有记录做计算越来越耗时 因为数据量的关系,从数据库服务器取出记录的过程本身也很耗时 解决这两个问题的根本都是是减少数据量。很明显,不符合过滤条件的记录没有必要传输到后端服务器上,也没有必要做字段计算。如果可以提前得到甚至缩小符合过滤条件的记录ID,可以大大加速整个过程。 索引表 针对前端特殊的展示需求(一张大表格),一个直观的解决方案是扁平化所有的数据。为此我们新建了一张索引表SearchTable,将每条记录的相应字段预先计算并填入。数据表结构如下: 索引表中的每一行对应一条记录的字段及其取值,其中type标识了该行字段名称,value则是对应的值。 这样过滤条件可以转化为类似如下的查询语句,

  • Bood
    Bood
android

在 Android 中集成 React Native 的经验分享

在之前的一篇博客中,Allen已经为大家介绍了React Native在Glow的应用以及大体架构。由于React Native库本身的一些原因,其在Android的成熟度远不及iOS,因此也给在Android的应用带来了更多的挑战。 在本文中,给大家分享一下在Android平台上集成React Native的过程中碰到的一些问题和解决办法。 64位支持 目前React Native的二进制库还不支持64位,而Android并不支持32位和64位二进制库的混合加载(详见Mixing 32- and 64-bit Dependencies in Android)。 因此如果应用中已经包含了64位的二进制库,必须用abiFilters去掉64位二进制库。 ndk { abiFilters "armeabi", "mips", "armeabi-v7a", "x86" } React Native社区也在努力解决这一问题(React Native for Android is

  • Bood
    Bood