With so many open source frameworks, which one is better?

Link to the original text ：http://www.jianshu.com/p/f3227c7008d4
Reprint please indicate the source ：http://blog.csdn.net/sange77/article/details/51980764

Doubt questions

So many open source frameworks , Which one is better ？ Presumably, such a problem , Everyone has doubts . I think most of the doubts are just the following ：

• Is this framework stable ？ If there is bug What do I do ？
• Can this framework meet all my needs ？ What if half of it is not applicable ？
• Is this framework highly coupled ？ Whether you can customize the extension according to your needs ？

What kind of framework should not be adopted

Don't look at the above points first , Let's talk about what kind of framework must not be adopted ：

• Aggregate frameworks must be abandoned ( such as Afinal,xUtils),why？ The bigger and more complete , The easier it is to pull one hair and move the whole body , And in the framework world, there is no 1+1>2 This saying . On the contrary, the readability is poor , High coupling , Difficult to expand . yes Afinal Is it better to cache pictures in fresco,Picasso Wait , It goes without saying ？
• github On last commit More than one year or issues A lot of nothing fix Do not use . There will be many pits , If something goes wrong , You don't know who to ask . Corresponding , The question I fear most from others is ：Stay, You used xxx The framework? ？ Help me see this problem ..
• Imitation xxx UI Effect Encyclopedia , Please use , If possible , Communicate more with the product manager , Use as much as possible Material Design Design , In addition, you can refer to InstaMaterial. Don't spend a lot of time and energy on the adjustment UI In effect .UI Performance and potential bug Is the most difficult to debug . Most people are right touch event ,view Drawing is a little knowledge .

Pass the above conditions , Basically pass fall 60% Open source projects for . The technology update is still very fast , Many requirements that were previously complex or have no solution at all can have good solutions in the future . When you haven't found the solution you want for several days , You might as well communicate , Choose other alternative needs .

If your project is from 0 To 1 The initial stage of

You might as well spend a week doing research . What kind of product is this , Do competitive product analysis , Consider possible future extensions . The best solution is to choose the framework according to the product business . The possibility of reconstructing the overall project structure in the future is very small , So you have to think about expansion as much as possible at the beginning , Otherwise it will be very painful .

in addition , You can safely and boldly try the new open source lib, Whenever you write a frame , They all aim at simplicity and ease of use , With the advancement of technology , The new framework will also absorb the experience of predecessors and become more and more mature . And the number of users is still small , There is still a long transition period in the early stage , You have enough time to verify whether this framework works .

If your product is from 1 To N The mature stage of

At this time, the replacement of each frame needs careful consideration , When the user base is large , Any one of them bug Will lead to serious consequences . Use gray publishing as much as possible , Unified upgrade after small-scale test .

For example , You feel universal-image-loader It's not easy to use , often oom, And the download display speed is slow , Then you can choose fresco,glide Right . that , If you haven't resealed the image caching framework before , Try to do some encapsulation when you change the framework . namely ： Don't show calls in code UniversalImageLoader.display() or fresco.display(), Because these codes are called in too many places , Once you change the frame , Then the place to change is fried chicken . In order to have such problems in the future , You might as well wrap them up again . It will be easier in the future . You're right .

Or say ,IM The delivery of messages , Now there are so many cloud push platforms , How to choose is also a problem , If you're not sure , Then try to decouple and , Don't explicitly call any cloud push API, Pack another layer by yourself , You can change it as you like , There is no need to change the business logic , Just replace the cloud platform API Just ok 了 .

As for how to choose between similar frameworks , In fact, they are almost , There are some guidelines , For reference only ：

• If the framework A Rely on others jar More , Use caution , Learning also costs .
• If the framework B No detailed documentation , Use caution , For the same reason .
• If the framework C For your current App Greater impact , There are many changes , Use it carefully .
• If the framework D High coupling degree , It's not easy to expand , Use caution .

Pure recommendation

• The network layer ： Retrofit perhaps Volley＋OkHttp,async-http-lib Try not to use it , Relatively old . In addition, these need to be further expanded , You can search it yourself , Integrate what is useful .
• database ： GreenDao,LiteORM、 ORMLite perhaps Realm, To encrypt, use SqlCipher
• Image caching ： Fresco, glide, If the effect of integration is not ideal , Check whether the configuration parameters are correct
• Tools ：
  
  • Check for memory leaks （leakcanary）
  • Asynchronous notification （RxJava Use caution ）
  • Mathematical expressions （expression4j）
  • Date processing （joda time android）

Link to the original text ：http://www.jianshu.com/p/f3227c7008d4
Reprint please indicate the source ：http://blog.csdn.net/sange77/article/details/51980764