This article is shared by Ali Xianyu Technical Team Qi Qing. This time, there are revisions and changes. Thank you for the author’s technology sharing.

1. Content overview

This paper summarizes the technical practices of Alixianyu’s technical team in the cross-end transformation of Xianyu IM mobile terminal with Flutter. The paper compares the differences in some major technical implementations between traditional Native and the now-popular Flutter cross-end scheme, as well as the specific technical implementations aiming at the characteristics of Flutter’s technology. It is worth the reference of technology peers who are also preparing to develop IM using Flutter.

Learning Exchange:

  • Instant Messaging/Push Technology Development Exchange 5 Group: 215477170
  • An Introduction to Mobile IM: One Beginner Is Enough: Developing Mobile IM from scratch
  • Open source IM framework source:…

(synchronous published in this article:

2, idle fish IM status quo

The mobile terminal framework of Xianyu IM was built between 2016 and 2017. During this period, after multiple iterations and upgrades, the historical burden accumulated. Later, it experienced the Flutter of IM interface, resulting in an increasingly complex client architecture.

From the development level, the current architecture of Xianyu IM mobile terminal mainly has the following problems:

  • 1) Low R&D efficiency: the current architecture involves the logic code of Android/iOS and Flutter’s UI code, and positioning problems can only be traced back to the Native logic layer from Flutter’s UI table;
  • 2) Poor architectural hierarchy: the hierarchy is not clear in architectural design, and the business logic is mixed in the core logical layer, resulting in high risk of code change;
  • 3) Slight poor performance test: the core data source stores Native memory, so the data source needs to be serialized in the Flutter Plugin and thrown to the Flutter side, so the performance is poor in the case of large quantities of data sources.

From the product level, the main problems of the current architecture of Xianyu IM mobile terminal are summarized as follows:

  • 1) Difficult positioning problem: online public opinion feedback is varied, and relevant scenes cannot be reproduced in the test. Therefore, most of the time, we can only guess the essence by the phenomenon;
  • 2) Many problems: the instability of the architecture caused by the recurring problems, the current problems mainly include unread red dot count, low-end iPhone5C and multimedia transmission and other problems;
  • 3) Big differences in problems: Android and iOS have big differences in logic codes, including the logic of burial points. When troubleshooting the root causes of problems, both ends will have different root causes and different solutions.

3. Cross-end solution of mobile terminal in the industry

In order to solve the current technical pain points of IM, Xianyu started the IM architecture upgrade project this year, focusing on solving the pain points of the consistency of both Android and iOS terminals in the client. The preliminary plan is to realize the cross-terminal unified Android/iOS logic architecture.

Cross-end solutions in the current industry can be preliminarily classified as the following framework:

Cross-end schemes at GUI level include Weex, ReactNative, H5, uni-app, etc., and most of their memory models need to be bridged to Native mode storage.

In the logic level of cross-end solutions are roughly C/C++ and other virtual machine-independent languages to achieve cross-end, of course, assembly language is also feasible.

Two other independent architectures are Flutter and KMM (Google is based on Kotlin implementation similar to the Flutter architecture), where Flutter runs a specific dartVM and loads the in-memory data into its own isolate.

Consider that the idle fish is Flutter’s leading explorer, and Flutter is preferred on the scheme. However, Flutter’s isolate is more similar to the concept of a process (the underlying implementation is non-using process mode). Compared with Android, Android’s Dalvik virtual machine has multiple threads running on a shared memory Heap in the same process scenario, while DartVM’s isolate is running on separate heaps. As a result, communication between coordinators is cumbersome (it requires serialization and deserialization).

The whole model is shown in the figure below:

If according to the official system Flutter mixed architecture application, open multiple FlutterAcitivty/FlutterController, underlying will generate multiple Engine, corresponding will have multiple isolate, and isolate communication (similar to a socket or AIDL) similar to the process communication, The design concept of Xianyu FlutterBoost is used for reference here. The Flutterim architecture shares the engines of multiple pages, so the memory model naturally supports shared reading.

The schematic diagram is as follows:

4. Xianyu IM is designed based on the architecture of Flutter

4.1 Comparison of the new and old architectures is shown in the figure below: it is an old architecture scheme, whose core problems mainly focus on the poor abstraction of Native logic, in which the logic level is designed to be multi-threaded concurrency, which multiplicates the problems. Android/iOS/Flutter interaction is complicated, the development and maintenance cost is high, the coupling of the core layer is serious, and the concept of no plug is non-existent.

In consideration of the historical architecture, the new architecture design evolves as follows:

As shown in the figure above, the architecture is shown from top to bottom:

  • 1) Business layer;
  • 2) Distribution layer;
  • 3) Logic layer;
  • 4) Data source layer.

Data source layer comes from push or network request, which is encapsulated in the Native layer. The message protocol data is thrown to the core logic layer of Flutter side through Flutter plug-in, and becomes Enitity entity of Flutter DB after processing. Some message protocol entities are mounted in the entity.

The core logic layer will pack the complex data flat and mount it to the session memory model data or message memory model data in the distribution layer, and finally distribute it to the business logic through the subscription of the observer pattern.

Flutter IM focuses on the transformation of logic layer and distribution layer. It encapsulates and isolates the core logic of IM and the business-level data model. After the core logic layer interchanges with the database, the data is encapsulated into ModuleData of the distribution layer and distributed to the business-level data model through subscription.

In addition, DB is also heavily dependent in the IM model. The individual carries out a comprehensive package solution for DB database management, and realizes a lightweight and high-performance Flutter DB management framework.

4.2 DB storage model Flutter IM architecture relies on database plug-in, the mainstream plug-in is SQFlite.

Its storage model is as follows:

The SQFlite plugin’s DB storage model has two waiting queues:

  • One is the Flutter layer synchronous execution queue;
  • One is the thread execution queue of the Native layer.

The Android implementation mechanism is HandlerThread, so the Query/Save reads and writes will be in the same thread queue, resulting in slow response time, easy to cause DB SQL stack, and the missing cache model.

Therefore, I customized the following improvement plan:

When the Flutter side designs the query by the primary key of the table, the priority is to get the query from the Entity Cache layer. If the Cache does not exist, the SQFlite plugin will be used to retrieve the query.

At the same time, SQFlite plug-in is modified to support sync/Async synchronous and asynchronous operations. In the Native side, there will also be synchronous thread queue and asynchronous thread queue to ensure data throughput rate. However, it is recommended to use asynchronous query and synchronous storage. The main fear is that multiple identical data element models will enter the asynchronous thread pool at the same time, and the storage sequence cannot be effectively guaranteed.

4.3 ORM database scheme IM architecture is heavily dependent on DB database, and currently there is no complete database ORM management scheme in the industry. By referring to Android’s OrmLite/ Greendao, I design a set of Flutter ORM database management scheme by myself.

Its core ideas are as follows:

Since Flutter doesn’t support reflection, it can’t operate directly like Android’s open source database, but it can bind Entity and ORM Entity together through APT. If you operate Ormentity, you can operate Entity. The whole code design is very similar to OrmLite.

The reference code is as follows:

4.4 IM memory data model Based on Flutter’s IM mobile terminal architecture, the memory data model is mainly divided into two granularity: session and message:

1) Session memory data model assigned to SessionModuleData: The session memory data has a root node, RootNotice, which then mount a collection of child nodes of PsessionMessageNotice (where PsessionMessageNotice is the ORM mapped session DB table model). 2) Message memory data model is assigned to MessageModuleData: Message memory data will be managed by a MessageConatiner container, which internally mount the PMessage(PMessage is the ORM mapped message DB table model) message set in this session. According to the section in the last chapter, PsessionMessageNotice designed an Ormenitity Cache. Considering the limited number of sessions in IM, PsessionMessageNotice was directly cached in the Cache.

The advantage of this approach is that the same object is stored in the cache when the session data elements are fetched from different places, so it is easy to ensure the consistency of the data that is read and written repeatedly. Considering that the number of PsessionMessageNotice can be infinite, it is mounted into the memory management of the MessageContainer here, and the number of PMessage sets in the container will be checked upon exitting the session. Appropriate shrinkage can reduce the memory overhead.

The model is shown in the figure below:

4.5 State management scheme Based on Flutter’s IM mobile terminal architecture, the state management scheme is relatively simple. The Session/Message dimension of the data source is implemented by subscription distribution method of Observer mode, and the architecture is similar to EventBus mode. Page-level state management Whether using Fish-Redux, Scopemodel, or Provider has little impact, it is more important to maintain a pluggable abstraction at the core.

The structure is as follows:

4.6 IM synchronization model scheme The current status of the message synchronization model:

As shown in the figure above, there are multiple concurrent scenarios such as ACCS Thread/Main Thread/Region Thread in the model, which leads to the problem of high concurrency of multiple threads.

Native push and network request synchronization isolation scheme through the Lock mechanism of LOCK, and through the queue frequency down and other ways of processing, cumbersome process and error-prone. The overall Region Version Gap is used to judge whether there is a domain void, and then the domain synchronization is performed to supplement data.

The improved synchronization model is as follows:

As shown in the figure above, naturally there is no multi-threading scenario on the Flutter side. Through a kind of mark bit transformation synchronous asynchronous implementation similar to Handler message queue, the architecture is much clearer and simpler, and the overhead caused by locking and synchronization problems are avoided.

5. Progress of this transformation and performance comparison

1) At the architectural level:

In the IM architecture based on Flutter, it focuses on unifying the double-ended logic differences into a single Dart code, and completely smoothing the problems caused by the Android/iOS code differences.

The benefits are clear:

  • 1) Reduce the cost of development and maintenance, test regression, visual acceptance by half, greatly improve the R&D efficiency;
  • 2) Restructuring and layering in architecture to realize a decoupling and pluggable IM architecture;
  • 3) At the same time, a large amount of data in the Flutter side of Native is transferred on the serialization process to transform the Flutter reference to solve the problem of private chat lag in the extreme test scenario.

2) For online public opinion:

  • 1) Complement the group log mode of UT and TLOG to make it traceable and searchable;
  • 2) Focusing on specific solutions to many existing problems, for example, the architecture of iPhone5c is planned in the Flutter side;
  • 3) Problems such as unread red dot count were also fixed in the upgrade of the architecture model;
  • 4) In addition, the multimedia audio and video transmission module shall be reformed and upgraded.

3) Comparison of performance data:

When both the logic layer and UI layer of the IM architecture were switched to Flutter, the overall memory level remained the same compared with the original architecture mode.

Among them:

1) Under the private chat scenario, the memory of MIUI 9 test structure decreases by 40M, power consumption decreases by 4mAh, and CPU decreases by 1%; 2) In the extreme test scenario, the memory data of the new architecture was significantly improved compared with that of the old architecture (mainly because the overhead of page switching was much lower when both interfaces used the Flutter scenario).

6. Future Prospects

JS cross-terminal is not safe, while C++ cross-terminal cost is a little high. Flutter will be a better choice. At that time, the fundamental purpose of upgrading the architecture of Xianyu Flutterim was never Flutter because of Flutter. It was due to the heavy historical burden, high maintenance cost at the code level, poor scalability of new business, uncoordinated manpower ratio and persistent public opinion feedback of difficult and complicated diseases that we had to explore a new scheme.

After verifying the logical cross-end feasibility of Flutter’s mode in the ultra-complex business scene of Xianyu IM, Xianyu will always maintain frontier exploration on Flutter’s road and finally feed back to the ecosystem.

To sum up, the exploration process is about taking the first step, and the surprises that follow.

(The original link: click here to enter, this time has been revised and changed)

Appendix: More article summaries

Article [1] more ali team sharing: the ali nailing technology sharing: enterprise IM king – nailing the backend architecture on the edge of the modern IM chat messages in the system synchronization and storage solution to explore “the ali technology sharing: the deep revelation ali database technology scheme, history of 10 years,” “ali technology sharing: The Hard Growth Road of Alibaba Self-developed Finance-grade Database Oceanbase, From Ali OpenIM: Technical Practice Sharing of Building Safe and Reliable Instant Messaging Service, The Technical Challenges of the New Generation Enterprise OA Platform Based on IM Technology (Video +PPT) [Download Attachment], The Crystal of Ali Technology: “Alibaba Java Development Manual (Statute)- Huashan version” [download the attachment]” “Alibaba Android Development Manual (Statute)” [download the attachment] “” The author talks about” Alibaba Java Development Manual (Statute) “behind the story” “Alibaba Android Development Manual (Statute) behind the story” “dry this bowl of chicken soup: The younger brother to ali P10 technology from the barber’s shop and “, “revealed ali, tencent, huawei, baidu rank and compensation system of the taobao technology sharing: hand tao million level of mobile terminal access layer gateway technology evolution road” reveal rare dry goods, pay treasure to 2 d code and code technology road of best practice in the taobao live technical dry goods: Decryption of High-Definition and Low-Delay Real-Time Video Broadcast Technology, Ali Technology Share: E-commerce IM Message Platform, Technical Practice in Group Chat and Live Broadcast Scenes, Ali Technology Share: Xianyu IM Cross-end Transformation Practice Based on Flutter’s Mobile Terminal [2] Mobile IM Developers Must Read (1) : Understand the Weakness and Slowness of the Mobile Web Most complete history of moving weak network optimization method summary “from the client point of view to talk about the news of the mobile terminal IM reliability and service mechanism, the modern mobile terminal network short connection optimization to summarize: request speed and weak network security, and adapt the mobile IM medium to large group of push message how to ensure the efficiency and real-time?” “Technical Issues for Mobile Terminal IM Development”, “Is It Better to Design Your Own Protocol and Use a Byte Stream or a Character Stream?” “IM message delivery guarantee mechanism realization (1) : guarantee the reliable delivery of online real-time message”, “IM message delivery guarantee mechanism realization (2) : guarantee the reliable delivery of offline message”, “how to guarantee the” timing “and” consistency “of IM real-time message? “A Low-Cost Approach to Timing IM Messages”, “Should Online Status Synchronization Use” Push “or” Pull “in Single IM Chat and Group IM Chat?” IM group messaging is so complicated, how do you make sure it’s not lost or lost? “Talk about the optimization of login request in the development of mobile terminal IM” “How to save traffic by pulling data during mobile terminal IM login?” “A Brief Discussion on the Principle of Multi-Login and Message Roaming for Mobile Terminal IM” “How to Design the” Failed Retry “Mechanism for Completely Self-Developed IM” “Easy to understand: load balance scheme sharing of mobile terminal IM access layer based on cluster”, “technical experiment and analysis of WeChat’s influence on network”, “status quo of open-source IM project” Mushroom Street Teamtalk “: an open source show with no end”, “coming as expected: WeChat’s self-used mobile terminal IM network layer cross-platform component library MARS has been officially open source Behind the Glitter of Bullet SMS: Chief Architect of netease Yunxin Sharing Technology Practice of 100 Million IM Platform WeChat massive IM chat message serial number generation practice (algorithm principle) “is it so difficult to develop IM from yourself? Hands-by hand teach you from a simple Androod IM (with source code)” “Melt cloud technology sharing: decryption Melt cloud IM product chat message ID generation strategy” “IM development basics tutorial (six) : NoSQL or SQL? Just read this article! For Beginners: Developing an IM server from scratch (based on Netty, complete source code) Go is a step-by-step guide to quickly building a high-performance, extensible IM system (with source code). “IM” scan function is easy to do? Look at the complete technical implementation of WeChat “scan object recognition” “IM message ID technology topic (1) : WeChat massive IM chat message serial number generation practice (algorithm principle)” “IM message ID technology topic (2) : WeChat Massive IM Chat Message Serial Number Generation Practice (Disaster Recovery Plan), IM Message ID Technology Theme (3) : Decryption of Chat Message ID Generation Strategy of Rongyun IM Products, IM Message ID Technology Theme (4) : Deep Decryption of Meituan Distributed ID Generation Algorithm, IM Message ID Technology Theme (5) : Technical Implementation of Open Source Distributed ID Generator, IM Message ID Technical Topics (6) : Deep-decipher Didi’s High Performance ID Generator (TinyID), IM Development Bible: The Most Complete History, Data Collection of WeChat Functional Parameters and Logic Rules, IM Development Dry-share: How I Solved the Client Stuck Due to Lots of Offline Messages “Zero Base IM Development Beginds 1: What is an IM System? Zero Base IM Development Introduction (2) : What is Real-Time IM System? Zero Base IM Development Introduction (3) : What is IM System Reliability? Introduction to Zero-Based IM Development (IV) : What is Message Timing Consistency for IM Systems? The IM development dry share: how to implement a large number of elegant offline messages and reliable delivery of the IM development dry share: have a great mobile IM componentized SDK architecture design practice the level a $user IM architecture technology dry (next) : reliability, orderliness, weak network optimization, the sweep IM login code technology project (a) : Debugging and Analysis of WeChat’s Scan Code Login Function Technology Principle, IM Scan Code Login Technology Feature (2) : Debugging and Analysis of Mainstream Scan Code Login Technology Principle in the Market, IM Scan Code Login Technology Feature (3) : Easy to understand, one article is enough for the detailed principle of IM scanning login function, Understanding the “Reliability” and “Consistency” of IM Message and Discussion on the Solution, Ali Technology Sharing: Xianyu IM Cross-end Transformation Practice Based on Flutter’s Mobile Terminal

More articles of the same kind…

This article has been published simultaneously on the public account of “instant messaging technology circle”.

▲ The link to this article on the public number is: click here to enter. The synchronous publishing link is:…