On Android, because Google's own android standard GCM (Google
Cloud messaging, originally called c2dm) is basically unavailable in China. Therefore, for developers, if the push function is required, how can they choose to become a problem.
So far, there is no free and open push service available to developers in China. There are several third-party push services abroad, but charges are generally incurred. Therefore, developers in China have to consider building push services on their own.
When building the PUSH Service by yourself, a natural choice is to do it based on the open-source current solution.
Using Google or Baidu to search for keywords such as "android push" indicates that many people have studied it. There are several articles on the front:
- Android push Solution
- Push using androidpn
- Push on Android
- Android push notification for Information Push
In the above solution, we basically mentioned an open-source Android push implementation: androidpn.
Androidpn is essentially based on openfire on the server side and asmack on the client side. These two are the two basic components in the xmpp im open-source implementation. It should be said that androidpn only combines the two components more for implementation.
Push scenario.
I have used chat apps and would like to share with you the practical experience of using the XMPP open-source system as Im.
We started with the open-source XMPP im System at the beginning.
Let's talk about server selection first. Openfire is the oldest open-source XMPP
IM server, almost all of which do im should have been studied. However, it is also the most unsuitable IM server for production, because the single-host concurrency is very limited, the cluster solution is not mature, and the code is old and lacks timely updates. For example, the cluster component of openfire is called connection.
Manager, but you can see on the openfire official website that the latest version was released in July. It can be seen that the foundation of androidpn Based on openfire is unstable.
Update: chat with an openfire-based chat app. Their users are large and there are multiple openfire nodes as clusters. They have made a lot of changes to openfire. For example, XMPP protocol interaction is complex and needs to be simplified. XMPP protocol text is bloated and is converted to binary. The cluster is completely self-developed. They can load up to 0.3 million users at a single point.
There are two other relatively better options: ejabberd and tigase. Ejabberd is implemented in the Erlang language and has very few users who know Erlang, so it is generally not selected. At that time, the initial chat server was tigase (implemented in Java ).
The tigase author is very active in maintenance, and the cluster test results can support relatively large capacity, which attracts us. However, according to the actual production and operation conditions, due to the complexity of the implementation of the cluster solution and the limited capacity of a single node, we have no confidence in supporting 0.5 million users on the cluster nodes, so before arriving at 0.5 million users, I quickly developed an alternative solution.
In addition, the XMPP protocol and client problems: for mobile clients, the original XMPP is complicated and the traffic consumption is high. In essence, XMPP is based on the XML structure of strings. Each Protocol has a bunch of strings, and there are many meaningless structures in XML. In addition, for the sake of its flexibility, XMPP requires n back and forth to log on. XMPP is heavy for mobile clients that care about traffic and power usage.
Our practice is: the Protocol format is changed to binary, the Protocol content is simplified for interaction, but the compatibility with the original XMPP is retained.
Androidpn is an open-source push implementation and is integrated based on XMPP open-source components. It does not provide necessary optimization for mobile phone application scenarios. In addition, XMPP is essentially a two-way im protocol, and the push function is directly implemented based on XMPP, which is not particularly optimized for the characteristics of push, such as the client network connection policy.
To sum up the problems that may occur in the typical open-source Android push solution with androidpn:
1) if the capacity of an open-source server is too large, you still need to improve the open-source implementation, or completely reuse the new solution. development investment and high achievement are inevitable.
2) Protocols and implementations, such as traffic consumption and network connection policies, are not optimized specially for mobile push and are not economical.
Based on our team's practical experience in implementing chat apps Based on XMPP open-source systems, we have concluded that in Mobile im scenarios, open-source solutions are not a usable solution. Later, we completely re-built the entire system. |
