TL; DR 是否有办法以有效的方式在应用程序启动时存储至少23,000条数据记录,以便用户能够在离线模式下完成此数据的表单选择(如果需要)?
我目前正在实施一项活动,用户可以从国家/州列表中选择一个位置,如果他们需要的位置不存在,他们就可以添加位置。
选址可以有多种方式:
用户可以使用SearchView
中的ActionBar
搜索某个位置,然后更新RecyclerView
列表中的数据集。
或者,用户可以先选择一个国家/州(来自RecyclerView
),然后选择与该国家/地区对应的城市RecyclerView
。
这个数据是在应用程序首次启动时从数据库中获取的(但是当他们为事件填写表单时,我希望他们能够在初始登录后离线执行,如果需要的话)< / p>
因此,当前位置DataSet
由一个表中的23,000条记录组成,其列为:
id |城市|国家|子系统| geoID |长| lat |时区
每次查询23,000条记录非常慢。所以我认为必须有一种更简单的方法来使用关系来加快查询时间。
此时,我已使用上述所有列的参数在ArrayList<LocationModel>
中存储了所有23,000条记录。
然后将它们分成活动生命周期所需的不同类别(即国家/州和城市),但这包括循环原始ArrayList
内的23,000条记录,然后选择所有国家/地区,然后获取属于该国家/地区的所有城市,然后在每次用户打开应用时将其存储在新的List
中。 我觉得这对性能来说是不必要的。
我想以一种方式设置数据库,在这种情况下,查询网络不仅效率高,而且只有必要的数据存储在List
内的设备上。
我原以为我可以为国家和城市设置两个不同的表格,在城市表格中指向国家/地区ID。
我可以仅使用国家/地区数据加载应用启动时的所有数据,然后当用户选择相应的国家/地区时,它将查询关系列指向正确ID的城市类。
但是我觉得用户会非常依赖网络连接来完成这样一个琐碎的任务(在初始应用程序启动后查询不同的城市)
当用户首次安装应用程序时,我可以从数据库中获取数据并将其存储在与应用程序对应的手机内部存储空间中的JSON
文件中,但我不确定如果APK
大小从此增加太多。
是否建议将此大小的数据存储在Assets目录中的文件中,或者会过多地增加APK
的大小?
当用户首次在应用中安装时,使用SQL
数据库/内容提供商在本地存储。
同样,这会对APK
尺寸造成太大影响吗?
是否有办法以有效的方式在应用启动时存储城市和国家/地区,以便用户能够在离线模式下完成对此数据的选择(如果需要)?
OR
当前任何选项是否都是一个可行的解决方案,牢记APK大小和三者之间的可比性能?
更新:决定最后使用Realm。因为它比SQLlite
更快,并且轻量级的APK大小用于我希望完成的琐事。
答案 0 :(得分:2)
使用SQLite存储数据......
答案 1 :(得分:0)
SQLite是二进制格式,速度相对较快。 使用SQLite或Realm。 Imho,Realm(基于SQLite)引擎可能在您的情况下更好(它比纯SQLite更快)。
Realm vs Sqlite for mobile development
现在有一个来自Google的Firebase数据库。 Imho,你也可以这样格式,因为它有服务器和离线交互。因为两种SQLite格式都必须存储在APK文件中。但是为了在应用程序内部工作,需要将sqlite文件从资产(或原始)目录复制到数据库(可工作)目录中。这就是为什么所有数据都会被公开(!)的原因。 Firebase数据库没有这个缺点。
https://firebase.google.com/docs/database/android/start/
JSON和XML格式太大(并且消耗了内存和机器时间)以便与它们一起使用。
喔。忘记!可以将代码直接集成到代码中。只需创建一个工作类:)