作者：blue

v 信号: Mojitok8275

版权声明：本文图文为博主原创，转载请注明出处。

吸顶效果是各家 App 或多或少都会用的一个交互，这种交互也常见于 PC、H5，可以说是一种通用性很强的前端交互体验，相比较来说京东首页的嵌套滑动吸顶效果是各个类似效果中体验比较好的一个，因为在嵌套布局中滑动连贯性处理得非常好，今天我们就来实现同样的交互效果。

这篇文章我会讲些什么

• 对于吸附效果实现的思路
• 3 个版本的 NestedScrollingParent、NestedScrollingChild 简单介绍
• 嵌套组件滑动连贯性（一致性）的处理（事件分发、Fling 等）
• 交互的优化问题

首先，先看一下我们实现的效果图：

这里只介绍我们实现过程中的思路，以及部分代码，源码请查看 NestedCeilingEffect，欢迎建议、Issues、Star

1、实现滑动吸顶效果的简单分析

对于吸顶效果，首先我们要先创造出 “顶” 来，那么如何创造 “顶” 呢？常见的实现方式有很多，比如：

• 通过两个相同的顶部控件显示或隐藏来实现
• 通过动态 layout 顶部控件来实现
• 通过重写 ItemDecoration 来实现
• 通过 CoordinatorLayout 协调子布局来实现

这些方式或多或少在某些方面有一些场景上的限制，这次我们采用另外一种方式来实现 “顶” 的效果，这里先卖一个关子。

作者：blue

v 信号: Mojitok8275

版权声明：本文图文为博主原创，转载请注明出处。

文章似乎有些标题党的嫌疑，但是我相信根据我的理解画出两幅图可以让大家理解 RxJava2 的核心原理，稍后不要吝啬，请叫我灵魂画手😄！相信 RxJava 是大家业务中用到比较多的一个依赖库，RxJava 的强大之处在于它改变了程序员的编程习惯，相比较其他的开源项目，Rxjava 是最弯弯绕的一个。对于 RxJava 种类繁多的操作符，大多数同学都表示很是头疼，也有不少同学陷入了学习操作符不能停的怪圈。操作符要不要学，当然要，但是如果能理解 RxJava 的核心，操作符的使用就像是学会九阳神功的张无忌学招数，必定是手到擒来。所谓器欲尽其用，必先得其法。

这篇文章我会讲些什么

• RxJava2 基本的运行流程
• RxJava2 线程切换的原理（涉及到为什么 subscribeOn() 只有第一次调用时有效）
• 为什么一订阅就回调了 onSubscribe
• 为什么 subscribeOn() 对上面的代码生效，observerOn() 对下面代码生效

以下内容如果涉及到自己写的代码我会采用 Kotlin 进行示例展示，涉及到 RxJava2 会展示部分源码。

1、简单的链式调用（无线程切换）

作者：blue

版权声明：转载请注明出处。

一直以来，Android 项目在构建速度是一大槽点，随着Android Studio 3.0 的大版本的升级使得多Module工程的构建速度加快很多。这主要依赖于 Android Plugin for Gradle 插件版本的升级，因此部分 API 发生了较大变化。本文主要是记录整个迁移过程以及聊一些常用的优化构建速度的建议，以供参考。

android studio 3.1.3; gradle-4.4; gradle plugin 3.1.3

1、Android SDK 构建系统

在正式讲述升级迁移之前，大家应该熟悉一下 Android SDK 的构建系统，Android 构建系统编译应用资源和源代码，然后将它们打包成可供开发人员测试、部署、签署和分发的 APK。Android Studio 使用 Gradle 这一高级构建工具包来自动化执行和管理构建流程，同时也允许开发人员定义灵活的自定义构建配置。每个构建配置均可自行定义一组代码和资源，同时对所有应用版本共有的部分加以重复利用。Android Plugin for Gradle 与这个构建工具包协作，共同提供专用于构建和测试 Android 应用的流程和可配置设置。

作者：blue

版权声明：本文图文为博主原创，转载请注明出处。

随着跨平台技术的发展演进，React Native 被越来越多的公司所接受，因此在这里分享一下 React Native 渲染流程，希望能帮助大家对 React Native 进行更深入的理解。

1、跨平台框架

跨平台一直以来是一个工程实践上的真实需求，用来节约项目开发的人力成本、时间成本等，尤其是在当下移动互联网的时代。在 React Native 诞生之前，已经存在了很多跨平台的方案，例如：Phone Gap 、Xamarin 、Corona 等。

1.1 跨平台框架都是伪命题？

• PhoneGap 利用 open-web 技术，即 HTML 5、CSS3 以及 JavaScript 构建移动 Web 应用。
• Xamarin 利用 C# 语言开发原生移动应用，打包时将 C# 转化为对应平台的原生代码。
• Corona 2D 游戏与应用开发平台，利用 lua 进行开发，主要面向游戏开发。

在以上我们提到这个几个跨平台框架，相对来说是被采用较多或比较知名的，但也缺点十分明显。其实在接触 React Native 之前我一直都认为所谓跨平台框架都是伪命题，但是在接触之后，确实改变了我的认识。

1.2 基于 JS 的跨平台框架

Facebook在 React.js Conf 2015 大会上推出了基于 JavaScript 的开源框架 React Native。

React Native 结合了 Web 应用和 Native 应用的优势，可以使用 JavaScript 来开发 iOS 和 Android 原生应用。在 JavaScript 中用 React 抽象操作系统原生的 UI 组件，代替 DOM 元素来渲染。这种方案与类似 PhoneGap 这种依赖 open-web 技术方案最大的不同就是 React Native 会将标签元素渲染成原生 UI 组件，从而提升性能及交互体验，使得应用本身更加接近原生应用的体验，也因此有越来越多的公司开始考虑 React Native 的跨平台方案。

作者：blue

版权声明：本文为博主原创，转载请注明出处。

今天主要安利一个 JavaScript 代码规范 standard js ，不论你一开始喜不喜欢这个标准，相信我开使用它，你会爱上这个标准！

1、序言

是的最近团队一直在 React Native 上进行探索性业务开发，在团队项目的合作中代码规范对于我们是一个相当重要的素质要求，对于注重代码质量注重代码可读性的团队尤其重要。由于缺乏代码规范，不同的人有不同的偏好，代码可读性会随着团队成员的更迭逐渐降低，也因为这样有可能带来线上 bug，而这些完全是可以通过代码检查避免的。

2、是时候强制要求代码规范了

强制两个字是好说不好听，谁也不愿意被强制要求这样那样，但这个事情我觉得懂的人自然懂，没什么好说的，团队合作就应该采用相同的规范，不同的人写的代码应该看起来是出自同一个人之手。

作者：blue

版权声明：本文图文为博主原创，转载请注明出处。

随着 React Native 的不断发展完善，越来越多的公司选择使用 React Native 替代 iOS/Android 进行部分业务线的开发，也有不少使用 Hybrid 技术的公司转向了 React Native 。要说 React Native 最能吸引开发者的地方那就是其拥有前端的开发速度以及原生的体验。

1、序言

今天要跟大家探讨的是 React Native 的拆包及热更新方案，官方并没有很好的支持这一企业十分看中的热更新能力，因此也催生了第三方的热更新方案，如 CodePush 、 react-native-pushy 。由于公司内部有不同的业务线，所以在采用第三方的热更新方案灵活度不够，在调研的初期，我们参考了携程的提到的 jsbundle 拆分和加载优化方案，但这个方案需要改变 React Native 的打包代码及 Runtime 代码，实施难度上非常大，暂无精力深入研究，但这个方案对加载速度提升也是显而易见的。我们暂时放弃了携程的方案，我们前期需要一套相对简单稳定且可行度高的方案，在经过调研及讨论后定下了这样一套热更方案，今天我们就来聊聊这个方案。

作者：blue

版权声明：本文图文为博主原创，转载请注明出处。

在 2016 年移动端跨平台开发是几个最热的技术之一，相信在 2017 年这股热潮将持续发酵。为什么这么说呢，因为随着业务的爆发式增长，传统的原生开发模式有点显得跟不上节奏了，这也促使各个公司希望寻找到一个更加高效的开发方案，当下可以被选择的方案中，React Native 及 Weex 都是不错的技术方案。在年前团队内部的一场 React Native vs Weex 的技术对垒中本来我选择的是 Weex 的阵营，但当时在多维的技术指标中新生的 Weex 还是不敌 React Native ，团队内部最终敲定了采用 React Native 跨平台方案。

1、概述

闲话不多说，这里的主要目的是跟大家聊聊 React Native 在 Android 平台使用原生自定义 View ，这里默认大家对 React Native 已经有一定的了解，React Native 中的组件都是基于 iOS/Android 的官方组件进行封装，所以在一些特别的场景下并不能很好的满足需求。正如标题中的下拉刷新组件，React Native 在 Android 平台采用的是 android.support.v4.widget.SwipeRefreshLayout ，一些 iOS 设计优先的团队(譬如我司)而言对于 Android 开发人员简直就是灾难。在众多开源的 React Native 项目中大家也不会再这些细节上较真，但是公司的 UED 这关可不好过。

作者：blue

版权声明：本文图文为博主原创，转载请注明出处。

这是一篇 KPI 考核背景下产出的文章，这一切都起源于我司要求提升 App 推送送达率，以节省在短信推广上花费的开销。这里记录了在整个技术调研的关键点。

1、概述

iOS 和 Android 均在系统级集成了推送服务，来说说原生 Android 的推送服务，最在 Android 2.2 时，C2DM 作为系统级服务集成进了 Android 系统，而 GCM（Google Clould Messaging） 在 2013 Google IO 大会发布后就正式取代了 C2DM ，然后 Google 并没有止步，在 2014 年收购了 Firebase ，经过近两年的整合，在 2016 年 Google IO 大会上隆重发布了 Firebase 服务，一个全新的移动和 Web 开发的完整后端解决方案，其中就包括了FCM（Firebase Cloud Messaging）。如果就这么简单，我们就可以在 Android 平台上像 iOS 平台一样使用系统级共享的推送服务了，然而一股神秘的东方力量打破了原本简单的事情…

作者：blue

版权声明：本文图文为博主原创，转载请注明出处。

1、概述

对于插件化框架 Hook 机制是一个核心，那到底 Hook 是什么呢？怎么去理解插件化中的 Hook 呢？在我看来插件化中的 Hook 机制就是通过反射注入和动态代理来实现的。

先来说说何为反射注入，大家都知道依赖注入，其实反射注入算是依赖注入的一种，顾名思义，通过反射的方式将依赖对象注入目标对象。举个例子，想要替换掉 ActivityThread 中的 mInstrumentation：