给创业码农的话--如何提升开发效率

最新推荐文章于 2024-06-01 09:18:41 发布

DreamChanDev

最新推荐文章于 2024-06-01 09:18:41 发布

阅读量1.2k

点赞数 1

分类专栏： android 文章标签： android

android 专栏收录该内容

44 篇文章 0 订阅

订阅专栏

本文分享了一位前微信团队成员的实践经验，介绍了RxJava、MVP/MVVM、RESTClient等技术的应用，以及如何选择合适的ImageLoader。此外，还探讨了最佳实践、质量保证措施和开发流程。

摘要由CSDN通过智能技术生成

开篇先友情提示一下，此篇文章所谈论的部分技术点与微信关联不大，如有描述不准确的地方，也欢迎大家指出与讨论。笔者去年从微信团队“毕业”，变成一个创业码农，期间也踩过一些坑，这里与大家分享一些我个人的经验。

微信的整体氛围很像创业公司，快速、高效。但微信团队对技术的挖掘还是很深的，这一点在创业公司比较难做到。创业公司更追求快速、稳定的做出功能，完成迭代。

下面给大家介绍一点我个人觉得很大的提高了我的开发效率的工具。

App架构

RxJava

首先给大家安利ReactiveX，其中Android的核心实现为RxJava。

为了App不卡顿，我们会把所有耗时的操作（比如：网络访问、文件访问）放到Worker Thread中。但是Android本身的AsyncTask的设计个人觉得设计的十分糟糕，不但写出来的代码冗长，而且稍微复杂一些的多流操作就会写的完全无法维护（这里可以用Java本身的线程模式来实现）。而且肆意的开线程也会造成App的卡顿。这里本身最初的想法就是需要一个线程池，以Promise的方式对外提供接口。原先试用过facebook的开源方案Bolts-Android，这个库是parse的开源方案。后来有iOS的同事推荐Reactive的方案，于是就走上了Rx脑残粉的不归路。

这里微信也有类似方案，通过将所有的线程和Handler使用接口收敛，以监控和控制无节操的开线程、卡顿为主要目标。而Rx的方案以帮助我们用少量的code，清晰的实现复杂的时序逻辑为主。

首先Rx会大大减少你的代码量，这一点对“懒惰”的我们十分重要。下面举2个平时开发都会遇到的问题来举例：

1. 搜索界面

我们需要在用户输入完毕后第一时间显示搜索结果，由于这个需要请求后台，我们又不想用户每次输入的时候都去后台请求。并且总需要显示当前最新输入内容的结果，不能因为网络的原因产生乱序的结果。

RxTextView.textChanges(searchEditText)
  .compose(this.bindToLifecycle())
  .debounce(300, TimeUnit.MILLISECONDS)
  .switchMap(SearchService::searchFeed)
  .subscribe(
      feeds -> updateUI(),
      throwable -> RxUtil.handleError(throwable, activity)
   );

几句简单明了的代码，满足上述的需求，而且看起来十分明了简单。其中.compose.(this.bindToLifecycle())是为了防止内存泄露，.debounce(300, TimeUnit.MILLISECONDS)是表示间隔为300毫秒，使用switchMap是会停止之前发出的请求，防止脏数据重入。由于Android并不支持Java 8，所以我们需要Retrolambda，来支持lambda表达式。

2. 防止多次点击重入

RxView.clickEvents(button)
  .throttleFirst(300, TimeUnit.MILLISECONDS)
  .subscribe(this::onButtonClick);

MVP & MVVM

关于MVP&MVVM我一直是拒绝的，因为一开始的几个Screen我是用硬套MVP&MVVM的模式来做的，虽然activity的代码十分简单，但是View和ViewModel都会写一些晦涩、重复的逻辑来保证数据绑定，这不符合D.R.Y.。后来发现google官方有一个data-binding(http://developer.android.com/tools/data-binding/guide.html)的实现，感觉实现和prism十分类似，已经在最新的迭代中开始使用data-binding来实现MVVM，具体可以参考一个第三方例子(https://github.com/ivacf/archi)。

如何优雅的偷懒

REST Client

关于REST API是一件几乎纯体力活，这里应当使用代码生成工具来帮助我们完成繁琐的工作。如果你的App像微信一样追求极致的性能和极少流量耗费，这里可以使用protocal buffer。这个有一个坑，就是PB原生的生成器生成的方法数非常多，会造成Android方法数64K的问题。微信里的pb生成器做了比较多的优化，来减少方法数问题。对于创业者来说，可以关注Square开源的wire。

笔者的APP使用了更容易调试的JSON。其中我们可以定义JSON Schema来描述协议，后台与客户端都可以拿这个schema来生成自己的Model和验证协议数据。Android中可以jsonschema2pojo(https://github.com/joelittlejohn/jsonschema2pojo)来生成自己的Model代码，并且可以生成Parcelable代码(PS:这一部分可能还存在隐藏BUG，如果你在使用过程中有什么问题可以提issue或者直接联系笔者)。

关于REST API还有一个杀手级的库Retrofit。Retrofit可以完美配合jackson+Rxjava来实现一个基于ReactiveX的REST Client。

@GET("/v2/feeds/search")
Observable<List<FeedDetail>> searchFeeds(
  @Query("query") String query,
  @Query("tag") String tag,
  @Query("page") int page
);

声明十分简单明了，具体可以去retrofit的官网了解更多。

Image Loader

整体APP的架构完成后，图片库也是对于APP十分重要的。笔者刚入职的时候，就是在照着google tutorial上的图片加载的例子写过一个ImageLoader，深深感到做一个高效的图片库还是有很大难度的。还好现在各路大神给了我们很多选择，下面3款笔者认为是可以选择的option:

1. Picasso (https://github.com/square/picasso)
2. Glide (https://github.com/bumptech/glide)
3. Fresco (https://github.com/facebook/fresco)

其中Picasso和Glide的接口十分接近，但是benckmark下来Glide的性能更好一些，并且支持更多格式的图片，我们现在使用的的是Glide，而Fresco的功能是这3个库中最强大的，且支持PJPG。但是他需要替换你的View，并且接口设计的不如上述2个库。笔者在3个多月以前用Fresco的时候，他在加载多张图片的时候偶尔会有显示不出的情况，不确定现在是否修复。

微信内的ImageLoader针对自身的一些特有业务做了比较多定制化的工作，特别对内存做了比较深入的优化与监控，其他大体功能上相差不大。

ButterKnife

Jake Wharton是个非常高产的大神，诸多开源库都是他主导的（RxAndroid也是他主要在主导）。ButterKnife可以帮助你少写很多重复的code。配合IDEA的插件可以不用写很多繁琐的findviewByid的搬砖代码。

质量保证

监控数据对于App来讲也十分重要，这方面虽然不体现任何功能，Growth Hacker和开发都需要经常关注。微信的监控与上报可以说做的非常强大，但是对于创业者来说，无法花那么多时间与精力在这些方面，还好有一些第三方提供一些类似的相关服务。笔者现在在用的有一下几款产品：

1. fabric (https://get.fabric.io/)

2. umeng (http://umeng.com)
3. splunk (http://www.splunk.com)

fabric和umeng的功能有很大的重叠，fabric是twitter旗下的数据上报和分析系统，笔者这里使用了他的crash报上，做的十分强大，给App的质量提供了保证。splunk是一款服务端的log分析系统，有了他的支持客户端可以减少需要无谓的事件上报。

另外，DebugDrawer也值得推荐，可以帮你快速的在debug版本分析、诊断问题。

微信内的质量数据监控与上报则因为数据保密方面的考虑使用了自研平台。有实时的分钟级别的上报与报警平台，崩溃上报与分析，以及卡顿、内存、SQL等各种精细化监控模块。

最佳实践

关于最佳实践当然见仁见智，不过笔者还是推荐一些比较成熟的方案android-best-practices，这个建议精读一下，里面的每一条都是别人踩过的坑总结来的，十分有价值。

微信内部的开发流程基本会遵循git-flow(https://github.com/nvie/gitflow)，即单feature单branch，功能完成合入稳定分支。微信在git实践上因为大量使用并行开发，存在多个并行的release分支。笔者在创业时依然延续了这个规则，虽然每个repo只有1-2个人同时提交代码，但是这么做可以快速应对需求的变更，并保证commit的规整性。虽然在commit时会多花5秒钟来操作一下，但是这样留下的是一个规整的历史，方便后续review和bisect。另外TJ开发的git-extras(https://github.com/tj/git-extras)会有很多对github友好的命令，会让你每天少打很多无脑的命令，以下是git-flow官网的流程，建议大家尽量按照其流程进行迭代开发。

另外关于代码格式，也没有官方统一的方案，笔者这里推荐使用Square的java-code-styles(https://github.com/square/java-code-styles)，也可以自己fork做相应的修改。

另外高压的开发很容易让程序员感觉到焦躁，这里我们还是要引入一些趣味的奖惩，笔者这里沿袭微信的“饼干法则”。对于很傻瓜的Bug我们要对Bug的引入者进行一点小小的惩罚，比如可以让他给大家买咖啡或者甜筒。而对于写出优雅且鲁棒的代码，我们可以给他加一个鸡腿。

另外强烈push设计的同学使用Sketch，这样不仅可以解放设计的同学在无尽的切图中，也可以让自己节约更多的时间。

总结

感谢大家可以看完笔者的碎碎念，也感谢微信让笔者从一个青涩的学生成长了还算合格的程序员。笔者离职一年，感觉创业和做freelancer有很多相似的地方，有大量灵活的时间，你需要学习如何去掌握你的时间，毕竟工作只是生活的一部分，你需要合理的分配时间。所以你的代码要尽可能的少些，即能自动生成的就用脚本来做，能抽象的就不重复去写，可以给自己节约更多的时间去玩耍。

编者后记： sim离开微信团队的这一年中，我们完成了平台期发展的思路转换，关注的重点从原来的功能开发迭代开始转向更基础化的平台研发能力。开源和分布式开发的思想也在团队内部兴起，微信内使用的开发工具、组件、流程也陆续诞生了一批内部开源项目。从内到外，相信在不远的未来，大家就可以在github上看到它们。