In today's era when all kinds of small programs are in full bloom , If you still insist on using native applet syntax to write all kinds of products , Then there are two situations ： One 、 Only wechat app products . Two 、 There is a lot of redundant manpower to develop all kinds of small programs . According to unreliable tripartite Statistics , Every month 3 Ten thousand new programs , It also reflects that the competition is really fierce . Under the current situation , Still taking the lead with wechat apps , The rest are Alipay. 、 Baidu 、 byte 、QQ、360 Wait a minute, then , And fast applications , And many new platform languages （ In the back of the head, the big factories test run all kinds of ）. So how to run the same product on different platforms ？ This kind of problem exists all the time , All kinds of leading enterprises are still working hard . In this turbulent environment , Some good tools and solutions have come out :uni-app、taro、chameleon、mpvue、wepy（ Regardless of priority ）.
be based on Taro Practice
There are advantages and disadvantages in all kinds of cross end solutions , But more analysis , Our team is mainly based on Taro Practice has been done （ We don't analyze why we use Taro 了 ）. The following is a general description of the whole practice of various matters ：
The first stage , One is selected Taro edition （ It wasn't mature then , There are a lot of problems ）, I have made a deep research and attempt . We didn't choose to go side by side with the community , Because the community will be slow , So the team did a lot of secondary development of functions based on a version at that time .
The second stage , What is the current business Taro The reconstruction of , Start on wechat app first , Very smooth , The problems encountered are not difficult to solve , And then it was transformed RN End （ There are many problems with this content , But it can be done ）, And then after reaping the benefits of cross end development , Start trying to copy products on different ends and run . Not very well , But it can also pass Taro Support .
The third stage , adopt Taro Fast application （ Typical of the unfriendly end ） To transform , It takes a lot of effort to adapt , To catch up with the development progress of wechat app .
Behind the different stages , The team has also done a lot ：1、 intelligence cli Tools to manage the upgrade of multi terminal scaffold .2、 Unified subcontract management scheme .3、 Unified build command .4、 Unified dependency package management .5、 A lot of technical sermons .6、 A lot of thoughts and culture .
Stumbling through the cross end Taro The practice of standardization , We can't boast that the current cross end model within the team is very mature , But it's enough to support the addition of any new end . In the process of practice , There are a lot of problems , Some may have been solved , Some of them may have solutions , Some people may not know whether they should position him as a problem .
Question 1 ： Code stability
Cross end development refers to , Write a code , Be able to run on a variety of different platforms . But in real development , There will be some situations , For example, the code release rhythm of each platform is different , And there may be differences in demand , If wechat 1 Release requirements 1, Baidu 3 Release requirements 2, Apply it quickly 5 Release requirements 3. This is the normal development , There are usually two ways of branching , One is to maintain three unrelated branches , Componentization of public content ; The other is the main branch pull-up 3 Branches , Finally, after the completion of the development, do a more complex merge operation , Careful attention needs to be paid to merge conflicts .
Through a series of practice , We finally chose the second branch mode , Although the operation will be more complicated , But in the long run , As long as the operation is correct every time , High code trustworthiness , It's not easy to have a situation that's hard to deal with .
Question two ： Cross terminal compatibility
although Taro The framework does a lot of cross end compatible operations , But each end is constantly upgrading , And there are some differences between the different ends , So there's still compatibility . So we need to use environment variables , Write different compatible syntax at each end . At this time, there will be two more prominent problems ： One 、 Developing students needs to learn , Languages specific to different platforms , It takes time , Second, I don't want to learn a new language （ I feel like a waste of time ）. Two 、 In the long run , This code is a variety of compatible syntax , Put them in groups , It affects the maintainability of later code （ It's easy to have problems in practice ）.
This problem should always exist , Until the standard of small program is issued , There may be some improvement .
Question 3 ： Division of development
This problem will rise to team management , It's divided by business lines , Or by function . Line of business division will find that each development needs to be different for all DSL Have a certain understanding , Otherwise, problems will be difficult to solve , It's a waste of personal energy . The division of functions will find that making a requirement , There was a big wave of shouting , And then do their own end of the adaptation , Finally, the project is merged , It's a bit messy .
I believe it would be better to divide by business line .
Cross end development will still be a hot topic in the new year , In the current situation, there is no perfect solution , According to the actual situation within the team , Do the corresponding architecture system , Still the best way . Many unsolvable problems , Can do engineering , You can also preach through technology , Doing precipitation and avoiding , To achieve the corresponding effect .