Which should I learn, Uniapp or Flutter?

This article was shared by Ali Xianyu's technical team, and this time it was revised. Thanks to the author for sharing the technology.

1, content o

Which should I learn, Uniapp or Flutter?

This article was shared by Ali Xianyu's technical team, and this time it was revised. Thanks to the author for sharing the technology.

1, content overview This paper summarizes the technical practice of Ali Xianyu's technical team in the process of transforming Xianyu's IM with Flutter, compares the differences between traditional Native and popular Flutter cross-terminal solutions in some major technical implementations, and the specific technical implementation according to the technical characteristics of Flutter, which is worthy of learning and reference for technical colleagues who are also preparing to use Flutter to develop IM.

Learning communication:

-Introduction to mobile IM development article: "One entry is enough for beginners: developing mobile IM from scratch"

-Open source IM framework source code:/jackjiang2011/mobileimsdk

(This article was published at:/thread-3615-1-1.html).

2. The status quo of idle fish IM The mobile frame of idle fish IM is built between 20 16-20 17. During this period, after repeated iterations and upgrades, a lot of historical burdens have been accumulated, and then the IM interface is smooth and the client architecture is more complicated.

From the development level, this paper summarizes the following problems existing in the current architecture of the idle fish IM mobile terminal:

1) R&D is inefficient: the current architecture involves the logic code of Android/iOS and the UI code of Flutter, and the positioning problem can only be found in the native logic layer from the Flutter UI table; 2) Poor architecture level: the architecture design level is unclear, and the core logic layer is mixed with business logic, which leads to the risk of code change; 3) The performance test is slightly poor: the core data source stores native memory, and the data source needs to be serialized to the Flutter end through the Flutter plug-in, which leads to poor performance in the case of a large number of data sources. Summarize the main problems of the current architecture of the idle fish IM mobile terminal from the product level as follows:

1) Positioning problem: There are many kinds of online public opinion feedback, and the test can never reproduce the relevant scenes, so many times we can only guess the essence by phenomena; 2) There are many incurable diseases: problems caused by unstable structure appear repeatedly. At present, the intractable diseases mainly include unread red dot counting, low-end iPhone5C and multimedia transmission. 3) The problem is very different: the logic codes at both ends of Android and iOS are very different, including the difference of embedded logic. When troubleshooting the root cause of the problem, there will be different root causes and different solutions at both ends. 3. Industry Mobile Cross-end Solution In order to solve the current technical pain points of IM, Xianyu specially launched the IM architecture upgrade project this year, focusing on solving the pain points of the consistency between client Andriod and iOS. The initial idea is to realize cross-end unified Android/iOS logical architecture.

In the current industry, cross-end solutions can be divided into the following frameworks:

Cross-end solutions at GUI level include Weex, ReactNative Native, H5, Uni-APP, etc. And most of their memory models need to be stored by bridging to native mode.

On the logical level, cross-end solutions are generally implemented in languages unrelated to virtual machines, such as C/C++. Of course, assembly languages are also feasible.

In addition, there are two architectures independent of the above systems, namely Flutter and KMM (Google has implemented a similar Flutter architecture based on Kotlin), in which Flutter runs a specific DartVM and mounts the memory data into its own isolate.

Considering that idle fish is the frontier explorer of Flutter, Flutter is preferred in the scheme. However, Flutter's Isolate is more like the concept of a process (process mode is not used at the bottom). Compared with Android, in the same process scenario, multiple threads of the Dalvik virtual machine of Android run * * * to enjoy a memory heap, while the isolate operation of DartVM isolates their own heaps, so the communication between isolations is more complicated (serialization and deserialization are needed).

The whole model is shown in the following figure:

If the Flutter application is implemented according to the official mixed architecture, and multiple Flutteractivity/Flutter controllers are turned on, then multiple engines will be generated at the bottom, and there will be multiple isolations. Isolated communication is similar to process communication (similar to socket or AIDL). Here, the design concept of the idle fish FlutterBoost is used for reference. FlutterIM architecture will share the engines of multiple pages, so the memory model will naturally support * * * to enjoy reading.

The schematic diagram is as follows:

4. The comparison between the new and old IM architecture design based on Flutter 4. 1

As shown in the figure below, it is an old architecture scheme, and its core problems mainly focus on the poor abstraction of native logic, in which the logic layer is also designed as a multi-thread multiplication problem. The interaction between Android/iOS/Flutter is complex, the development and maintenance costs are high, the core layer is seriously coupled, and there is no plug-in concept.

Considering the problems of historical buildings, the following new architectural designs have been formed:

As shown in the above figure, the top-down architecture is:

1) business layer; 2) distribution layer; 3) logic layer; 4) Data source layer. The data source layer comes from push or network request and is encapsulated in the native layer. The message protocol data is uploaded to the core logic layer on the Flutter side through the Flutter plug-in, and after processing, it becomes the entity of Flutter DB, and some message protocol entities are mounted in the entity.

The core logic layer flattens the complex data into session memory model data or message memory model data in the distribution layer, and finally distributes it to the business logic through observer mode subscription.

Flutter IM focuses on reforming the logic layer and distribution layer, and encapsulates the data model that isolates the core logic of IM from the business layer. After the core logic layer interacts with the database, the data is encapsulated in the moduleData of the distribution layer and distributed to the data model of the business layer through subscription.

In addition, in IM mode, DB is also the focus of dependence. Individuals completely encapsulate DB database management and realize a lightweight and good performance Flutter DB management framework.

4.2 DB storage model

Flutter IM architecture DB storage depends on database plug-ins, and the current mainstream plug-in is Sqflite.

Its storage model is as follows:

According to the DB storage model of Sqflite plug-in shown above, there will be two waiting queues:

One is the flutter layer synchronous execution queue; One is the thread execution queue of the native layer. Its Android implementation mechanism is HandlerThread, so query/save is read and written in the same thread queue, which leads to slow response, easy to cause DB SQL accumulation and lack of cache model.

So the individual customized the following improvement scheme:

When the Flutter side designs a query through the primary key of the table, it will first get it from the entity cache layer. If the cache does not exist, it will be queried through the Sqflite plug-in.

At the same time, Sqflite plug-in is reformed to support synchronous and asynchronous operations of SYNC, and there will also be synchronous thread queues and asynchronous thread queues on the native side to ensure data throughput. However, it is suggested to query asynchronously and store synchronously, mainly for fear that multiple identical data meta-models will enter the asynchronous thread pool at the same time, and the storage order cannot be effectively guaranteed.

4.3 ORM database scheme

IM architecture relies heavily on DB database, but there is no complete ORM database management scheme in the industry at present. Referring to OrmLite/GreenDao of Android, I designed a Flutter ORM database management scheme.

Its core idea is as follows:

Because Flutter doesn't support reflection, it can't operate directly like the open source database mode of Android, but it can bind Entity and OREntity in APT mode. Operating OREntity is the operating entity, and the whole code style design is very similar to OrmLite.

The reference code is as follows:

4.4 IM memory data model

The memory data model of IM mobile terminal architecture based on Flutter is mainly divided into two granularities: session and message:

1) the session memory data model is delegated to SessionModuleData: the session memory data has a root node, RootNotice, and then it mounts the child node set of the session message notification (where the session message notification is the session DB table model of ORM mapping). 2) The message memory data model is entrusted to MessageModuleData: The message memory data will be managed by a MessageConatiner container, which internally mounts the PMessage(PMessage is the message DB table model of ORM mapping) message set in this session. According to the previous chapter, PSessionMessageNotice designed an OrmEnitity cache. Considering the limited number of sessions in IM, the fake message notice is directly cached in the cache.

The advantage of this method is that the session data elements are all the same object in the cache, which is easy to ensure the consistency of repeated reading and writing. Considering the particularity that the number of PSessionMessageNotice can be infinite, it is mounted in the memory management of MessageContainer, and the number of PMessage collections in the container will be checked when exiting the session, and the memory overhead can be reduced by appropriately shrinking the capacity.

The model is shown in the following figure:

4.5 National Management Program

The state management scheme of IM mobile terminal architecture based on Flutter is relatively simple, and the subscription and distribution mode of data source conversation/message dimension is adopted. The architecture is similar to the EventBus mode, and the page-level state management has little influence whether it uses fish-redux, scopeModel or provider. It is more important to keep the plug-in abstraction at the core.

The architecture is as follows:

4.6 Instant Message Synchronization Model Scheme

The current state of the message synchronization model;

As shown in the above figure, there are multi-thread concurrent scenarios such as accssthread/mainthread/regions thread in the model, which leads to the problem of high concurrency of multi-threads.

The isolation scheme of native push and network request synchronization is handled through the lock mechanism of lock and queue frequency reduction, which is cumbersome and error-prone. Use the regional version gap to judge whether there is a domain vulnerability, and then synchronize the domain to supplement the data.

The improved synchronization model is as follows:

As shown in the above figure, there is naturally no multithreading scene at the Flutter end, and a message queue similar to Handler is realized synchronously and asynchronously through the conversion of a flag bit, so that the architecture is much clearer and simpler, and the overhead and synchronization problems caused by locking are avoided.

5. Comparison of renovation progress and performance 1) For the architecture level:

In Flutter-based IM architecture, the key point is to unify the logical differences between the two ends into the same Dart code, which completely smoothes the problems caused by the code differences between Android and iOS.

The benefits are obvious:

1) Reduce the cost of development and maintenance, test regression and visual acceptance by half, and greatly improve the efficiency of research and development; 2) Reconstruct and layer the architecture to realize the decoupled plug-in IM architecture; 3) At the same time, a large amount of data from Native to Flutter is uploaded to the serialization process conversion process, which solves the problem of private chat in extreme test scenarios. 2) For online public opinion:

1) The group log method of UT and TLog is traceable; 2) Focus on solving many existing intractable diseases, such as the unified planning of the architecture of the iphone5C at the flutter end; 3) Problems such as unread red dot count are also fixed in the upgrade of architecture model; 4) In addition, the multimedia audio and video transmission module is upgraded. 3) Performance data comparison:

When the logic layer and UI layer of IM architecture are switched to Flutter, the overall memory level is flat compared with the original architecture mode.

These include:

1) In the private chat scenario, the memory of Xiaomi 9 test structure drops by 40M, the power consumption drops by 4mah, and the CPU drops by1%; 2) Compared with the old architecture, the memory data of the new architecture in the extreme test scenario has been significantly improved (mainly because the cost of page switching is much lower when both interfaces use Flutter scenario). 6, the future outlook JS cross-end is not safe, C++ cross-end cost is a bit high, Flutter will be a better choice. At that time, the fundamental purpose of the upgrade of the leisure fish FlutterIM architecture was never because of Flutterim, but because of the heavy historical burden, high maintenance cost at the code level, poor new business development, uncoordinated manpower ratio and persistent feedback, so we had to explore new schemes.

Through the ultra-complex business scenario of idle fish IM, the logical cross-end feasibility of flutter mode is verified, and idle fish will always keep the frontier exploration on the flutter road, and finally can feed back the ecological circle.

To sum up, the process of exploration is that you have the courage to take the first step, and then you will be constantly surprised.

(Original link: Click here to enter, this time there are modifications and changes)

Appendix: Summary of more articles [1] More articles shared by Ali team:

DingTalk technology sharing: the king of enterprise IM-Excellence nailed on the back-end architecture.

Discussion on synchronization and storage scheme of chat messages in modern IM system

Ali Technology Sharing: Revealing the Evolution History of Ali Database Technology Scheme 10.

Ali technology sharing: the difficult growth path of Ali's self-developed financial database OceanBase.

Ali OpenIM: Technical Practice Sharing of Creating Safe and Reliable Instant Messaging Service

Nail-the technical challenge of the new generation enterprise OA platform based on IM technology (video +PPT)[ attachment download]]

Ali Technology Crystallization: Alibaba Java Development Manual (Specification)-Huashan Edition [attachment download]]

Heavy release: Alibaba Android development manual (specification) [attachment download].

The author tells the story behind Alibaba's Java development manual (specification).

The story behind Alibaba's Android Development Manual (Statute).

Dry this bowl of chicken soup: from barber shop to Ali P 10 technical Daniel

Reveal the ranks and salary systems of Ali, Tencent, Huawei and Baidu.

Taobao technology sharing: the technological evolution of mobile access layer gateway.

"Rare dry goods, revealing the way to optimize Alipay QR code scanning technology"

Taobao Live Technology Dry Goods: Decryption of HD low-latency real-time video live broadcast technology.

Ali technology sharing: e-commerce IM messaging platform, technical practice in group chat and live broadcast scenarios.

Ali Technology Sharing: Idle Fish IM's Cross-terminal Transformation Practice Based on Flutter.

[2] A more comprehensive article on IM development:

One article suitable for beginners is enough: developing mobile IM from scratch.

Required reading for mobile IM developers (1): Easy to understand and understand the "weakness" and "slowness" of mobile networks.

Must-read for mobile IM developers (2): Summary of the most comprehensive optimization methods for mobile weak networks in history.

On message reliability and delivery mechanism of mobile IM from the perspective of client.

Summary of short connection optimization methods in modern mobile networks: required speed, weak network adaptation and security guarantee.

How to ensure the efficiency and real-time of mass message push in mobile IM? 》

Technical problems in the development of mobile instant messaging

Is it better to design the protocol with byte stream or character stream when developing IM? 》

The Implementation of Instant Messaging Guarantee Mechanism (I): Ensuring the Reliable Delivery of Online Real-time Messages

Implementation of IM message delivery guarantee mechanism (2): Ensure the reliable delivery of offline messages.

How to ensure the "timing" and "consistency" of IM instant messages? 》

Discussion on a low-cost method to ensure the sending time of instant messages

Should I use "push" or "pull" to synchronize the online status of IM single chat and group chat? 》

"IM group chat messages are so complicated, how to ensure that they are not lost? 》

Optimization of login request in mobile instant messaging development

How does IM save traffic by pulling data when logging in on the mobile terminal? 》

Multi-point login and message roaming principle of mobile instant messaging

How to design a "failed retry" mechanism for a completely self-developed IM? 》

Easy to understand: load balancing scheme of IM access layer based on cluster sharing mobile terminal

Technical experiment and analysis of the influence of WeChat on the network (full text of the paper).

The status quo of the open source IM project "Mushroom Street TeamTalk": an open source show with no beginning and no end.

Arrive as scheduled: Mars, the cross-platform component library of mobile IM network layer used by WeChat, has been officially opened.

Behind the Bullet SMS: The Chief Architect of Netease Yun Xin shared the technical practice of Billion IM platform.

Wechat technology sharing: the practice of generating massive IM chat message serial numbers by WeChat (algorithm principle).

"Is it so difficult to develop IM by yourself? Teach you a simple IM (with source code) version of Andriod.

Rong Yun Technology Sharing: Decryption Strategy of Chat Information ID of IM Products in Rong Yun.

Complement the basic knowledge of IM development (6): Does the database use NoSQL or SQL? It's enough to read this article! 》

Suitable for novices: develop an IM server from scratch (based on Netty, with complete source code).

Pick up the keyboard and do it: develop a distributed IM system by hand.

Suitable for novices: Teach you how to quickly build a high-performance and extensible IM system with Go (source code).

What is the principle of realizing the function of "people nearby" in IM? How to achieve it efficiently? 》

"is IM's' sweeping' function easy to do? Look at the complete technical implementation of WeChat "Sweep Things"

Special topic of IM message ID technology (I): the practice of generating serial number of WeChat massive IM chat messages (algorithm principle).

Special topic of IM message ID technology (II): Practice of generating serial numbers from massive IM chat messages on WeChat (disaster recovery scheme).

Special topic of IM message ID technology (III): Generation strategy of chat message ID for decrypting Rong Yun IM products.

Special topic of IM message ID technology (IV): Distributed ID generation algorithm of deep decryption Meituan

Special topic of IM message ID technology (5): technical implementation of open source distributed ID generator UidGenerator.

Special topic of IM message ID technology (VI): Tinyid generator for deep decryption of Didi.

IM development set: the most comprehensive collection of various functional parameters and logical rules of WeChat in history.

IM developing dry goods sharing: how can I solve the problem that a large number of offline messages cause the client to get stuck?

Introduction to zero-based IM development (1): What is an IM system? 》

Introduction to zero-based IM development (II): What is the real-time performance of IM system? 》

Introduction to zero-based IM development (3): How reliable is the IM system? 》

Introduction to Zero-based IM Development (IV): What is the message timing consistency of IM system? 》

IM developing dry goods sharing: how to gracefully realize the reliable delivery of a large number of offline messages.

IM developing dry goods sharing: the design practice of component SDK architecture of Zan mobile IM.

"A set of IM architecture technologies for 1 100 million users (Ⅱ): reliability, orderliness, weak network optimization, etc."

"Special Topic of IM Scan Code Login Technology (I): Technical Principle Debugging and Analysis of WeChat Scan Code Login Function"

"Special Topic of IM Scan Code Login Technology (II): Debugging Analysis of Mainstream Scan Code Login Technology in the Market"

Special topic of IM scanning code login technology (III): Easy to understand, and a detailed principle of IM scanning code login function is enough.

Understand the problems of "reliability" and "consistency" of IM messages and discuss the solutions.

Ali Technology Sharing: Idle Fish IM's Cross-terminal Transformation Practice Based on Flutter.

& gt& gt More similar articles. ...

This article has been published in the official WeChat account "Instant Messaging Technology Circle".

The synchronous publishing link is:/thread-3615-1-1.html.