This article was shared by Qi Qing from Ali Xianyu's technical team. There are revisions and changes this time, thanks to the author's technical sharing.
1. Content overview
This article summarizes the technical practices of Alibaba Xianyu's technical team using Flutter in the mobile terminal cross-terminal transformation of Xianyu IM. The article compares the differences between traditional Native and the current popular Flutter cross-terminal solution in some major technical implementations. , And the specific technical implementation for the technical characteristics of Flutter, it is worthy of reference and reference for technical colleagues who are also ready to use Flutter to develop IM.
Learning Exchange:
- 5 groups for instant messaging/push technology development and communication: 215477170 [recommended]
- Introduction to Mobile IM Development: "One entry is enough for novices: Develop mobile IM from scratch"
- Open source IM framework source code: https://github.com/JackJiang2011/MobileIMSDK
(This article was published simultaneously at: http://www.52im.net/thread-3615-1-1.html)
2. Current status of Xianyu IM
The mobile-end framework of Xianyu IM was built between 2016 and 2017. During this period, many iterations and upgrades led to the accumulation of historical burdens. Later, it experienced the Flutterization of the IM interface, which caused the client architecture to become more complex.
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 both Android/iOS dual-end logic code and Flutter UI code, and positioning problems can often only be checked from the Flutter UI table to the Native logic layer;
- 2) The architecture level is poor: the architecture design is not clear, and the business logic is mixed in the core logic layer, resulting in a high risk of code changes;
- 3) The performance test is slightly worse: The core data source stores Native memory, and the data source needs to be serialized through the Flutter Plugin to the Flutter side. The performance is poor in the case of large-scale data sources.
From the product level, the main problems of the current architecture of Xianyu IM mobile terminal are summarized as follows:
- 1) Difficulty in locating the problem: online public opinion feedback is strange, and the test can never reproduce the relevant scenes, so in many cases, it is only possible to guess the essence of the phenomenon;
- 2) There are many intractable diseases: the instability of the architecture has caused problems to appear repeatedly. The current intractable diseases mainly include unread red dot counts, iPhone5C low-end computers, and multimedia transmission;
- 3) The problem is very different: the logic code of Android and iOS is very different, including the burying logic. When troubleshooting the root cause of the problem, both ends will have different root causes, and the solutions are different.
3. The industry's mobile terminal cross-terminal solution
In order to solve the current technical pain points of IM, Xianyu launched an IM architecture upgrade project this year, focusing on solving the pain points of Andriod and iOS dual-end consistency in the client. The preliminary plan is to realize a cross-end unified Android/iOS logical architecture.
In the current industry, cross-end solutions can be preliminarily classified into the following structure:
Cross-end solutions at the GUI level include Weex, ReactNative, H5, Uni-APP, etc., and most of their memory models need to be bridged to Native mode storage.
At the logic level, cross-terminal solutions roughly include C/C++ and other languages that have nothing to do with the virtual machine to achieve cross-terminal. Of course, assembly language is also feasible.
In addition, there are two architectures that are independent of the above systems, namely Flutter and KMM (Google implements a similar Flutter architecture based on Kotlin), where Flutter runs a specific DartVM and mounts memory data in its own isolate.
Considering that Xianyu is a front-end explorer of Flutter, Flutter is preferred in the scheme. However, Flutter's isolate is more like the concept of a process (the bottom layer implements a non-use process mode). Compared with Android, in the same process scenario, Android's Dalvik virtual machine runs and shares a memory Heap, while DartVM's Isolate runs and isolates their respective Heap, so the communication between isolates is cumbersome (need to go through the serialization and deserialization process).
The whole model is shown in the figure below:
If the Flutter application is implemented according to the official hybrid architecture and multiple FlutterAcitivty/FlutterController are turned on, multiple Engines will be generated at the bottom layer, corresponding to multiple isolates, and isolate communication is similar to process communication (similar to socket or AIDL). The design concept is that the FlutterIM architecture shares Engines of multiple pages, and the memory model naturally supports shared reading.
The schematic diagram is as follows:
4. Xianyu IM is based on Flutter's architecture design
4.1 Comparison of new and old architecture
As shown in the figure below: It is an old architecture solution. Its core problems are mainly focused on the poor abstraction of Native logic. The logic level is also designed to multi-threaded concurrency, which makes the problem multiplied. The Android/iOS/Flutter interaction is complicated, the development and maintenance cost is high, and the core layer The coupling is more serious and there is no pluggable concept.
Taking into account the historical architecture, the evolution of the new architecture design is as follows:
As shown in the figure above, the architecture from top to bottom is as follows:
- 1) Business layer;
- 2) Distribution layer;
- 3) Logic layer;
- 4) Data source layer.
The data source layer comes from push or network requests. It is encapsulated in the Native layer. The message protocol data is thrown to the core logic layer on the Flutter side through the Flutter plug-in. After the processing is completed, it becomes the Enity entity of Flutter DB, and some messages are mounted in the entity. Agreement entity.
The core logic layer flattened and packaged complex data and mounted it to the session memory model data or message memory model data in the distribution layer, and finally distributed it to the business logic through the subscription of the observer mode.
Flutter IM focuses on transforming the logic layer and the distribution layer, and encapsulates and isolates the IM core logic and business layer data model. After the core logic layer interacts with the database, the data is encapsulated into the moduleData of the distribution layer and distributed to the business layer data model by subscription. in.
In addition, DB is also a key dependency in the IM model. Individuals comprehensively encapsulate DB database management to achieve a lightweight, high-performance Flutter DB management framework.
4.2 DB storage model
The DB storage of the Flutter IM architecture relies on a database plug-in, and the current mainstream plug-in is Sqflite.
The storage model is as follows:
According to the DB storage model of the Sqflite plugin in the figure above, there will be 2 waiting queues:
- One is the synchronous execution queue of the Flutter layer;
- One is the thread execution queue of the Native layer.
Its Android implementation mechanism is HandlerThread, so Query/Save reads and writes in the same thread queue, resulting in slow response speed, easy to cause DB SQL accumulation, and lack of a cache model.
So personally customize the following improvement plan:
When designing a query on the Flutter side through the primary key of the table, it will be first obtained from the Entity Cache layer. If the cache does not exist, it will be queried through the Sqflite plugin.
At the same time, transform the Sqflite plug-in to support sync/Async synchronous and asynchronous operation. Corresponding to the Native side, there will also be a synchronous thread queue and an asynchronous thread queue to ensure data throughput. However, it is recommended that the query use asynchronous, and the storage use synchronization is more secure. It is mainly afraid that multiple identical data element models will enter the asynchronous thread pool at the same time, and the storage order cannot be effectively guaranteed.
4.3 ORM database scheme
The IM architecture relies heavily on the DB database, and the industry currently does not have a complete database ORM management solution. With reference to Android's OrmLite/GreenDao, I personally design a Flutter ORM database management solution.
Its core ideas are as follows:
Since Flutter does not support reflection, it cannot be operated directly like Android's open source database, but Entity and Orm Entity can be bound together through APT. Operating OrmEntity means operating Entity, and the entire code style design is also very similar to OrmLite.
The reference code is as follows:
4.4 IM memory data model
The IM mobile terminal architecture based on Flutter is mainly divided into two granularities: session and message in the memory data model:
1) Session memory data model is entrusted to SessionModuleData: Session memory data has a root node RootNotice, and then it mounts PSessionMessageNotice (here PSessionMessageNotice is the session DB table model mapped by ORM) child node collection.
2) The message memory data model is entrusted to MessageModuleData: The message memory data will be managed by a MessageConatiner container, which mounts the PMessage (PMessage is the message DB table model mapped by the ORM) message collection in the session.
According to the previous chapter, PSessionMessageNotice designed an OrmEnitity Cache. Considering that the number of sessions in IM is limited, PSessionMessageNotice is directly cached in the Cache.
The advantage of this approach is that when you get the session data element everywhere, it is the same object in the cache, which makes it easy to ensure data consistency for repeated reads and writes. PSessionMessageNotice considers the particularity that its number can be unlimited, so here it is mounted in the memory management of MessageContainer, and the number of PMessage collections in the container is checked when the session is exited. Appropriate scaling can reduce memory overhead.
The model is shown in the figure below:
4.5 State Management Scheme
The Flutter-based IM mobile-end architecture state management solution is relatively simple. It uses the observer mode subscription and distribution method for the data source Session/Message dimension. The architecture is similar to the EventBus mode. The page-level state management does not use fish-redux, scopeModel or provider. The impact is almost small, and it is more important to retain a pluggable abstraction at the core.
The architecture is as follows:
4.6 IM synchronization model scheme
Current status message synchronization model:
As shown in the figure above, there are multi-thread concurrency scenarios such as ACCS Thread/Main Thread/Region Thread in the model, which leads to the problem of high multi-thread concurrency.
The isolation scheme of native push and network request synchronization is handled through the lock mechanism of Lock, and is processed by means such as queue frequency reduction. The process is cumbersome and error-prone. As a whole, the Region Version Gap is used to determine whether there is a domain hole, and then perform domain synchronization supplementary data.
The improved synchronization model is as follows:
As shown in the figure above, there is no multi-threaded scene on the Flutter side. A Handler-like message queue is realized synchronously and asynchronously through a kind of mark bit conversion. The structure is clear and simple, and the overhead and synchronization problems caused by locks are avoided.
5. The progress of this transformation and performance comparison
1) For the architecture level:
In the Flutter-based IM architecture, the focus is to unify the dual-end logic differences into the same Dart code, and completely smooth out the problems caused by the code differences between Android/iOS.
The benefits are obvious:
- 1) Reduce half of the cost of development and maintenance, test regression, and visual acceptance, greatly improving R&D efficiency;
- 2) Refactor and layer the architecture to realize a decoupled, pluggable IM architecture;
- 3) At the same time, a large amount of data from Native to Flutter is thrown in the serialization process to transform the Flutter reference transfer process to solve the problem of private chat stuck in extreme test scenarios.
2) For online public opinion:
- 1) The group log method of supplementing UT and TLog can be traced and checked;
- 2) Focus on special solutions for many existing intractable diseases, such as the unified planning of the iPhone5C architecture on the Flutter side;
- 3) Problems such as the count of unread red dots are also fixed in the architecture model upgrade;
- 4) In addition, the multimedia audio and video transmission module is upgraded.
3) Performance data comparison:
When the logic layer and UI layer of the IM architecture are both switched to Flutter, the overall memory level is the same as the original architecture model.
among them:
1) In the private chat scenario, the memory of the Mi 9 test structure is reduced by 40M, the power consumption is reduced by 4mah, and the CPU is reduced by 1%;
2) The memory data of the new architecture in the extreme test scenario has a more obvious improvement compared with the old architecture (mainly because the two interfaces use the Flutter scenario, the overhead of page switching is much reduced).
6. Future prospects
JS cross-terminal is not safe, C++ cross-terminal cost is a bit high, Flutter would be a better choice. At that time, the fundamental purpose of Xianyu's FlutterIM architecture upgrade was never because of Flutter but Flutter. It was because of the heavy historical burden, high maintenance cost at the code level, poor scalability of new business, uncoordinated manpower ratio, and continuous public opinion feedback on intractable diseases, etc. Other factors have caused us to have to explore new solutions.
After Xianyu IM's ultra-complex business scenarios have verified the logical cross-terminal feasibility of the Flutter model, Xianyu will always maintain cutting-edge exploration on the Flutter road, and finally can feed back to the ecosystem.
To sum up, the process of exploration is that you have the courage to take the first step, and then you will continue to find surprises later.
(Original link: Click here to enter, this time there are revisions and changes)
Appendix: More articles summary
[1] More articles shared by the Ali team:
"Ali DingTalk Technology Sharing: Enterprise-level IM King-DingTalk's outstanding features in the back-end architecture"
"Discussion on the Synchronization and Storage Scheme of Chat Messages in Modern IM System"
"Alibaba Technology Sharing: Demystifying the 10-year history of changes in Alibaba's database technology solutions"
"Alibaba Technology Sharing: The Hard Way to Growth of Alibaba's Self-developed Financial-Level Database OceanBase"
"From Ali OpenIM: Technical Practice Sharing for Creating Safe and Reliable Instant Messaging Services"
"DingTalk-Technical Challenges of a New Generation of Enterprise OA Platform Based on IM Technology (Video + PPT) [Attachment Download]"
"Ali Technology Crystal: "Alibaba Java Development Manual (Statute)-Huashan Version" [Attachment Download]"
"Heavy release: "Alibaba Android Development Manual (Statute)" [Attachment Download]"
"The author talks about the story behind the "Alibaba Java Development Manual (Statute)"
"The Story Behind "Alibaba Android Development Manual (Statute)"
"Dried up this bowl of chicken soup: from the barber shop to the Ali P10 technical master"
"Revealing the rank and salary system of Ali, Tencent, Huawei, and Baidu"
"Taobao Technology Sharing: The Technological Evolution Road of the Mobile Access Layer Gateway of the Hand Taobao Billion Level"
"A Rare Dry Goods, Revealing Alipay's 2D Code Scanning Technology Optimization Practice Road"
"Taobao live broadcast technology dry goods: high-definition, low-latency real-time video live broadcast technology decryption"
"Ali Technology Sharing: E-commerce IM messaging platform, technical practice in group chat and live broadcast scenarios"
"Ali Technology Sharing: Xianyu IM's Flutter-based mobile terminal cross-terminal transformation practice"
[2] More IM development comprehensive articles:
"One entry is enough for novices: develop mobile IM from scratch"
"Mobile IM developers must read (1): easy to understand, understand the "weak" and "slowness" of mobile networks"
"A Must-Read for Mobile IM Developers (2): Summary of the Most Complete Mobile Weak Network Optimization Method in History"
"From the perspective of the client to talk about the message reliability and delivery mechanism of the mobile terminal IM"
"Summary of optimization methods for short connection of modern mobile network: request speed, weak network adaptation, security assurance"
"How to ensure the efficiency and real-time performance of large-scale group message push in mobile IM? 》
"Technical issues that need to be faced in mobile IM development"
"Is it better to use byte stream or character stream for the development of IM? 》
"Implementation of IM Message Delivery Guarantee Mechanism (1): Guarantee the reliable delivery of online real-time messages"
"Implementation of IM Message Delivery Guarantee Mechanism (2): Guaranteeing the Reliable Delivery of Offline Messages"
"How to ensure the "sequence" and "consistency" of IM real-time messages? 》
"A low-cost method to ensure the timing of IM messages"
"Should I use "push" or "pull" for online status synchronization in IM single chat and group chat? 》
"IM group chat messages are so complicated, how to ensure that they are not lost or repetitive? 》
"Talk about the optimization of login request in mobile IM development"
"How to save data by pulling data during IM login on the mobile terminal? 》
"On the principle of multi-sign-in and message roaming on mobile IM"
"How to design a "failure retry" mechanism for a completely self-developed IM? 》
"Easy to understand: cluster-based mobile terminal IM access layer load balancing solution sharing"
"Technical Test and Analysis of WeChat's Influence on the Network (Full Paper)"
"The Status Quo of the Open Source IM Project "Mushroom Street TeamTalk": An Open Source Show with a Beginning and Ending"
"As promised: WeChat's own mobile IM network layer cross-platform component library Mars has been officially open sourced"
"Behind the glamorous bullet message: the chief architect of Netease Yunxin shares the technical practice of the billion-level IM platform"
"WeChat Technology Sharing: Practice of Generating Massive IM Chat Message Sequence Numbers in WeChat (Principles of Algorithms)"
"Is it so difficult to develop IM yourself? Teach you to teach yourself an Andriod version of simple IM (with source code) "
"Rongyun Technology Sharing: Decrypting the Chat Message ID Generation Strategy of Rongyun IM Products"
"IM Development Fundamentals Supplementary Lesson (6): Does the database use NoSQL or SQL? Enough to read this! 》
"Suitable for novices: develop an IM server from scratch (based on Netty, with complete source code)"
"Pick up the keyboard and do it: work with me to develop a distributed IM system by hand"
"Suitable for novices: teach you to use Go to quickly build a high-performance and scalable IM system (source code)"
What is the realization principle of "Nearby Person" function in IM? How to achieve it efficiently? 》
"IM "Scan" function is easy to do? Take a look at the complete technical realization of WeChat "Scan for Knowledge""
"IM Message ID Technology Topic (1): Practice of Generating Massive IM Chat Message Sequence Numbers on WeChat (Principles of Algorithms)"
"IM Message ID Technology Topic (2): Practice of Generating Massive IM Chat Message Serial Numbers in WeChat (Disaster Recovery Plan)"
"IM Message ID Technology Topic (3): Decrypting the Chat Message ID Generation Strategy of Rongyun IM Products"
"IM Message ID Technology Topic (4): Deep Decryption of Meituan's Distributed ID Generation Algorithm"
"IM Message ID Technology Topic (5): Technical Implementation of Open Source Distributed ID Generator UidGenerator"
"IM Message ID Technology Topic (6): Deep Decryption Didi's High-Performance ID Generator (Tinyid)"
"IM Development Collection: The most complete in history, a summary of various function parameters and logic rules of WeChat"
"IM development dry goods sharing: how do I solve a large number of offline messages causing the client to freeze"
"Introduction to zero-based IM development (1): What is an IM system? 》
"Introduction to zero-based IM development (2): What is the real-time nature of the IM system? 》
"Introduction to zero-based IM development (3): What is the reliability of the IM system? 》
"Introduction to zero-based IM development (4): What is the message timing consistency of the IM system? 》
"IM development dry goods sharing: how to elegantly realize the reliable delivery of a large number of offline messages"
"IM development and dry goods sharing: Youzan mobile terminal IM componentized SDK architecture design practice"
"A set of IM architecture technical dry goods for hundreds of millions of users (Part 2): reliability, orderliness, weak network optimization, etc."
"IM Scan Code Login Technology Topic (1): Debugging and Analysis of Technical Principles of WeChat Scan Code Login Function"
"IM Scan Code Login Technology Topic (2): Debugging and Analysis of the Principles of the Mainstream Scan Code Login Technology in the Market"
"IM Scan Code Login Technology Topic (3): Easy to understand, one detailed principle of IM scan code login function is enough"
"Understanding the "Reliability" and "Consistency" Issues of IM Messages and Discussion of Solutions"
"Ali Technology Sharing: Xianyu IM's Cross-End Transformation Practice Based on Flutter"More similar articles...
This article has been simultaneously published on the official account of "Instant Messaging Technology Circle".
▲ The link of this article on the official account is: click here to enter. The synchronous publishing link is: http://www.52im.net/thread-3615-1-1.html
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。