摘要：原文來自介紹的的框架體系這是架構中最具備吸引力，也是最強大的部分。國內訪問不到，因此轉過來。暫時原文原樣轉，未作翻譯。

原文來自: https://medium.com/@ex3ndr/ho...

actor ceo ex3ndr 介紹的actor,java,gwt,j2obj的框架體系, 這是actor架構中最具備吸引力，也是最強大的部分。 國內訪問不到，因此轉過來。

暫時原文原樣轉，未作翻譯。

Stepan Korshakov
CEO of Actor.im
Jun 9, 2015
How Actor uses Java, GWT and J2ObjC for reuse 80% of code

We are a small startup, and we try to make big thing: implement messaging platform from scratch on modern technologies and one day we realized that implementing clients for three platforms is very hard. It is hard to implement correctly our custom networking protocol, implement all complex sync logic (right messaging app is not straightforward!) and adding new features fast. When we decided to find a way to unify our development we figured out that our Android application internally is very optimized and have the best internal architecture for iOS and Web too. This happens because of our experience in the development of mobile messaging: 5 messengers for Android and WinPhone, Telegram S for Android and our CEO won 3 contests of a rapid development of mobile messaging applications. In this way, this architecture is already 3-rd generation and time-proven.

At the core of the application, we have Actor Model implementation (that’s why we have this name of our project), and we also use Actors in our server: Scala Akka. In one week, we implemented a small subset of Akka Actors. Actors are excellent for web because we have divided work to very small pieces and it doesn’t affect UI. We are extremely lucky. We only removed support for Typed Actors because we can’t use reflection in Web, and we can stripe all reflection information in generated code to reduce a size and improve execution speed.

Good Actor Model implementation doesn’t allow direct working with UI. We created very simple MVVM implementation, and it works very well, reduced listener/subscriber amount to zero and we can easily sync any object in UI with a single line of code. MVVM works well in Web too thanks to Angular/ReactJS. Luck doesn’t leave us in this too.

Also, we have a custom implementation of Protobuf serialization?—?BSer. It is compatible with Protobuf, but much more easy to use. Maybe our implementation bit slower, but we don’t find any problems in speed. Wire use reflection, and it is implemented by someone who doesn’t know Java (Sorry guys, I like you, Square). Original Protobuf is harder to use and generate a lot of code. Also, we have some additional features on top of original protobuf like inheritance.

To build smooth lists experience in Android, we created a complex logic of loading and sync of UI and DataBase. When we started to optimize iOS we found that iOS have same problems with lists that Android have (and one more) and this lists engine works well for iOS too.

Our storage of data was separated to key-value storages and special list storages that store ordered lists of objects. This idea reduce a lot of logic that need to implement for each platform: we need to implement ~10–15 sql queries and library is ready to use.

Java has best tools for profiling and debugging in the market and if you optimize apps. The developer can easily solve most of the problems with reach toolkits like Memory Analyzer Tool, IntelliJ IDEA, and others.

And in a month we separated all our code from Android and built libraries with GWT and J2ObjC.

We performed some speed checks. One interesting was testing crypto in Web. We compare a subset of BouncyCastle for Java that was converted to JS by GWT and various plain-js libraries like CryptoJS. Surprisingly, GWT crypto work faster up to two times when using RSA with 1024 and 2048 keys. Unfortunately GWT crypto can’t generate keys and just freeze, and we use CryptoJS for key generation and we decided not to fix this bugs in random number generation. The main reason is that BouncyCastle originally was developed for slowest JavaME phones and contains best algorithms and execution optimizations. At iOS, we haven’t spotted any noticeable difference. Using plain java implementations, we can make any crypto that is a huge advantage for us.

We also checked the size of libraries. For the web all messaging logic with custom proto, serialization and storage interfaces after all optimizations are only 90kb. iOS Application extended by 1MB, much less than Swift runtime.

After this, we dramatically reduce our codebase size and usually when we find bug?—?it is a bug in the library, and we fix it at all platforms by one single fix. Java/Android developers are much easier to hire than iOS devs and also easier than finding good frontend-developer. Now we and our customers can build custom native applications with much smaller development costs.

We are currently in private beta, and if someone want to try our product, in there’s company they may ask me by writing me email steve@actor.im. We usually suggest our product for businesses with 500+ employees. Also we are interested in partners that can help us to make Actor global.

Go to the profile of Stepan Korshakov
Stepan Korshakov

CEO of Actor.im

Go to the profile of Stepan Korshakov
Never miss a story from Stepan Korshakov, when you sign up for Medium. Learn more