This article has strong personal feelings, if you feel uncomfortable, please close as soon as possible. This article is only used as a personal learning record, and you are welcome to reprint or use it within the scope of the license agreement. Please respect the copyright and keep the link to the original text. Thank you for your understanding and cooperation. If you find this site helpful, you can subscribe to this site by RSS, so that you will be able to access this site information in the first time.
OhMyStar 2 also took a while, and I switched persistence from CoreData to Realm. Some thoughts, just record them. The following comments are my subjective feelings, not supported by actual test data.
Persistence in iOS
There aren’t many options for iOS persistence, either, with CoreData, Realm, FMDB, KV classes (LevelDB, etc.). Some of the low end ones just write an NSArray as Plist and it will persist.
Nowadays, the network environment is getting faster and faster, and most application data may be network applications. If the business logic is not complicated, in fact, it is good to write JSON to Object at the extreme. And a bunch of such good package, far Mantle near YYModel.
So when it comes to persistence, I think I can carefully evaluate the requirements. Figure it out. You can save a lot of things.
This article will focus on comparing Realm and CoreData, but not the rest.
Realm
advantages
Low barriers to entry
One afternoon is enough to read Realm documents word by word. There is also a Chinese version, not too friendly oh, a little unaccustomed to ah.
The documentation covers 80% of usage and is even a little too rudimentary. But anyway, this entry condition is a lot better than three months of CoreData writing and not figuring out the Context.
Install a Realm Browser on the library’s tool chain and no further assistance is required. Again, simple.
It’s almost ready to use. Five-star reviews.
PS: I spent an overnight switching the OhMyStar 2 persistence from CoreData to Realm, tweaking it for about 5 days to get it barely usable. There was no previous experience with Realm.
It is said that the performance is better
Realm Official introduction to The Fast section
Counts
Queries
Inserts
While writing here I googled and found a Core Data, FMDB, and Realm performance test. I’ll just say a few more words
I always feel that there is a misunderstanding of CoreData. After a look at the code Fork, I always feel that it should not be written in this way to compare performance, but I don’t know how to change it for a while. I can only say that I improved CoreData a lot based on what WWDC taught me. The other thing is that CoreData usually uses Sqlite as the back end. So if your query is optimized, after confirming the science of the SQL statement, Sqlite(CoreData) and Sqlite(FMDB) I think there is a performance gap, this gap is not big enough to choose a decisive factor. If you run into performance bottlenecks with CoreData, you should take a closer look at WWDC and several good articles. Make sure you’re using CoreData correctly and scientifically.
There’s no annoying thing that requires schema Context
This should be a simple aspect of Realm, as long as a Realm stays in its own thread and its own Realm Store operation is correct. If it is CoreData, how to construct a scientific Context Stack is enough to give me a headache. IOS is good, the interface is one after another (the hierarchy between VC and VC is clear). However, OhMyStar 2, the OS X desktop application scenario, is very complicated between VC, and the Context relationship between threads causes many problems.
Support NSPredicate
It wasn’t too much of an adjustment to move from CoreData
It’s easy to use multiple storage files
Take, for example, multi-user logins. The user is an independent storage file and uses the same storage file with all users. The latter requires that each piece of user data be associated with the current user once, and all queries for user data must include the current user’s query item. With a single data file per user, the storage structure is much cleaner.
Technical support
At least if you can’t, you can make fun of them on Weibo, and they are enthusiastic about solving your problems. CoreData, when it comes to problems, can only swallow them silently.
disadvantages
The correlation is weak
Simply put, it is one-to-many relationship and many-to-many relationship between objects. There is no mapping, you need to write properties on both sides, and you need to set both sides at the same time. NSPredicate also supports only some level 1 queries and cannot make complex queries with subqueries.
The forced introspection fault tolerance mechanism results in ever-larger stored files
Realm itself feels like it has a data fault tolerance mechanism. But this mechanism is infinitely larger when the database file has errors that fix themselves. In this case, there are only 3000 pieces of data, but the file size is already 3GB. Reproducing bugs is also easy, as long as you use Realm Browser to view them while writing to the database.
The official documentation says the cause of this situation, and I did my best to avoid the problem. It’s still possible to store files a little less dramatically. But viewing data with Realm Browser is fine. So I think the authorities should provide a function to remove the easy stuff. Keep stored files clean.
No fining notification
That is, when I make a change somewhere. All I know elsewhere is that the Realm has changed, but I have no way of knowing if I added, modified, or deleted data. I don’t know which data I updated. According to the document, it remains to be seen how this will be resolved in the future.
Increase package volume
According to the official, the package size will increase by around 1MB if you are a small app or a mainstream app with tens of millions of users. Use with caution if you are sensitive to package size.
The core code is currently closed source
For us, who grew up in a country full of evil, some children are quite concerned about closed source. I’m still inclined to trust Realm’s character when it comes to open source.
CoreData
CoreData is a little bit more relevant and I’ll just say it briefly
advantages
Official support && real son
The system comes with Apple support
Model editing with graphics
It is friendly to visual animals and can clearly know the relationship between the models designed by myself
Strong relational relationships
I didn’t think it was possible to use a Realm to find CoreData relationships so useful, one-to-many, many-to-many. You can query as you like, and you can write very complex query logic.
Powerful queries
Although setting up an NSFetchRequest might feel like a lot of work, complexity also gives you a lot of power. You can set up a lot of NSFetchRequest Settings, such as limiting the number of queries, limiting the return of certain property values, and so on. I’m not going to expand on that.
Fine notice
You know exactly what was inserted, what was updated, and what was deleted. So that when you’re painting a UI, like a TableView, you can control exactly what you’re doing.
disadvantages
High entry barrier
CoreData is an extensive and sophisticated technology, so don’t expect to be able to use it in just a few days. CoreData is an extensive and sophisticated technology, so don’t expect to be able to use it in just a few days. CoreData is an extensive and sophisticated technology, so don’t expect to be able to use it in just a few days.
If you don’t have enough time and effort to access CoreData. The selection should be carefully considered.
It takes some tools to feel good
For both experienced and novice users, using some third-party wrapper libraries and tools will greatly increase the happiness of using CoreData.
Mogenerator is a must.
MagicalRecord is no. 1 in CoreData, and according to rumors, major contributor Saul Mora may have gone to wechat.
Context
It’s really a high threshold for CoreData, for me. The relationship between contexts and the handling of threads gave me a headache, especially in OS X where there was a lot of VC laid out on the screen and I had a lot of problems.
Multiple persistence files are cumbersome
Not that we can’t, but it’s a real hassle.
There was a third-party library that solved the CoreData problem, CoreStore, but I was not using it very well and finally abandoned it.
conclusion
In fact, you can use any persistence, but it depends on your needs and which solution is best for you.
Simply put, Realm is better suited for scenarios where the business logic is less complex, the team configuration is less demanding, and the experienced user can pick it up in an afternoon.
CoreData is more suitable for complex business logic situations, team configuration requirements are high, and experienced people need weeks or longer to use CoreData scientifically.