Udacity也弃用React Native了！

SimonChen published on 2018-07-18 included in 杂谈

不久之前，Airbnb 团队刚刚宣布放弃使用React Native，才过不久，Udacity移动团队最近也宣布从App中移除了使用React Native开发的最后一批功能。再加上6月中旬，Facebook宣布将大规模重构RN，这一系列的事件，让不少正在使用React Native的开发者瑟瑟发抖，陷入了恐慌之中。

在本文中，Udacity团队将告诉大家他们使用React Native的历程以及放弃他们的原因，也希望给一些开发者一些参考和启发，看自己是否适合React Native。

以下来自Udacity移动团队的自述：

Udacity移动团队

Udacity的移动团队分为iOS和Android两个团队。

团队规模

在引入React Native时：

1个iOS开发
2个Android开发者
1个项目经理
1个设计师

现在：

4个iOS开发者
3个Android开发者
1个项目经理
1个设计师

在使用React Native的18个月中，我们的iOS和Android团队规模都有所增长，整个团队由一名项目经理来领导。

期间，我们还经历了向多设计师和多设计范式转型。

开发背景

在引入React Native时，我们iOS团队唯一的开发人员非常乐于使用React Native，这极大丰富了他之前Javascript和Web的开发经验。两位Android开发人员中的一位对Javascript有丰富的经验，而另一个只有很少的Javascript、React或Web经验。

现在，四个iOS开发人员中至少有三个非常乐于使用Javascript和React Native。后来加入团队的其他Android开发人员也只有很少的Javascript或Web经验。

Udacity的App

用途

Udacity的移动app旨在将Udacity的学习体验带到用户的移动设备上。它支持身份验证、内容发现、程序注册（在某些情况还支持支付），以及消费各种类型的学习资料。

Udacity的App也作为新的实验性功能和旨在提升用户整体学习效果的活动的试验场。

代码库的大小

iOS：97,400行（.swift、.h、.m） Android：93,000行（xml、java、kotlin、gradle）

Udacity为什么以及如何采用React Native？

为什么要引入它？

当时，Udacity正准备推出全新的移动端专用功能。我们希望在两个平台上快速进行实验和验证，因此跨平台具有很大的吸引力。

可以总结为以下几点：

跨平台解决方案具有更高的可行性
大多数（2/3开发人员）团队成员非常适应Javascript和Web开发
可以提高开发速度
来自公司之外其他团队的成功案例

Udacity是如何引入的？

React Native的初始特性是在一个单独的GitHub代码库中构建的，然后作为git子树分别并入iOS和Android代码库。

这样可以进行非常快的原型设计，并且如果有必要，可以将某些功能作为独立产品发布。

Udacity团队设计了很多原型，最终在React Native代码库中引入了第二个更大的功能。

时间线

2016年8月：为功能1创建React Native代码库
2016年11月：在Android上发布了功能1
2016年11月：开始开发功能2
2016年12月：设计功能3原型
2017年1月：功能1开发结束
2017年2月：功能2发布
2017年3月：功能3原型设计结束
2017年11月：在Android上更新功能2
2017年12月：功能4原型作为独立app发布。最终由于性能问题取消了对原生的支持
2018年2月：在iOS上更新功能2
2018年4月：从Android中移除功能1
2018年6月：从两个app中移除功能2

为什么要移除React Native？

原因很简单。因为剩下的唯一一个React Native功能已经没有用了，我们不再需要支持它。

flutter开发系列之一--环境配置

SimonChen published on 2018-07-16 included in 移动开发跨平台

flutter出来已经一段时间，相信有不少开发同学都去尝试了，现在跨平台开发技术火爆移动开发圈，比如RN，Weex等等，但是这些方案如果不是有特殊需求，一般并没有动力去学，flutter不同，google大厂出品，值得信赖。这系列文章主要是用来记录自己学习flutter的一些经验和遇到的问题。

1. 准备

因我使用的开发环境是Mac系统，因此本系列所有的配置都是Mac为主由于网络问题，部分用户可能无法打开flutter官网，这里推荐Flutter中文站

在开始flutter之前，请先安装好Xcode和Android Studio

2. 安装Xcode和Android Studio

2.1 Xcode

直接在Mac App Store下载安装Xcode。

安装完Xcode后还需要安装一些依赖库。而这些库需要通过brew安装。

首先安装brew(已经安装过的跳过此步骤)

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

安装一些依赖库

brew update
brew install --HEAD libimobiledevice
brew install ideviceinstaller ios-deploy cocoapods
pod setup

命令行启动模拟器

open -a Simulator  //打开默认模拟器

或者也可以打开指定的模拟器

xcrun instruments -s //列出你安装的所有可用的设备
xcrun instruments -w "iPhone X" //打开指定模拟器

2.2 Android Studio

温馨提示，这些步骤可能因为国内网络问题导致不成功，请自行解决访问国外网络的问题。

下载并安装Android Studio
启动AS，根据配置向导一步步安装即可。
因Flutter默认使用的Android API 27和buildtools 27.0.3。而AS默认安装的最新版。所以这两个东西需要我们自己手动安装。按照下图打开SDK Manager。

Android热更新技术总结

SimonChen published on 2017-10-26 included in 移动开发

当前市面的热补丁方案有很多，其中比较出名的有阿里的HotFix、美团的Robust、微信的Tinker以及QZone的超级补丁方案。

1、热修复技术的优势？

无需重新发版，实时高效热修复
用户无感知修复，无需下载新的应用，代价小
远程调试

平台	阿里百川HotFix(Sophix)	AndFix	Tinker	Qzone	Robust
即时生效	yes	yes	no	no	yes
性能损耗	较小	较小	较大	较大	较小
侵入式打包	无侵入式打包	无侵入式打包	依赖侵入式打包	依赖侵入式打包	依赖侵入式打包
Rom体积	较小	较小	较大	较小	较小
接入复杂度	傻瓜式接入	比较简单	复杂	比较简单	复杂
补丁包大小	较小	较小	较小	较大	一般
全平台支持	yes	yes	yes	yes	yes
类替换	yes	yes	yes	yes	no
so替换	yes	no	yes	no	no
资源替换	yes	no	yes	yes	no
成功率	?	一般	较高（95.6%）	较高	最高（99.9%）

可以看到阿里的Sophix有很大优势，阿里系在热修复领域有很多积累，我们可以看下阿里系的热修复技术发展路径，一张表格来说明一下各个版本热修复的差别：

Android流行架构分享与解析

SimonChen published on 2016-07-22

如何构建一个优秀的App

Android简介

2008年9月，谷歌正式发布了Android 1.0系统，这也是Android系统最早的版本。随后，第一部Android智能手机发布于2008年10月(HTC G1)。其实Android最早可以追溯到2003年。1.0版本还是比较简陋的，只是一个测试版。
2009年4月，谷歌正式推出了Android 1.5。这个版本极大的完善了1.0版本。
2009年9月，谷歌发布了Android 1.6的正式版，当年搭载这款系统的是HTC Hero(G3)。这款系统就已经非常完善了。这个版本到4.0出来时都还有用户在使用。有一段时间的开发需要同时适配1.6和2.x。
2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。也是从此时开始，大量的企业开始重视起Android App的开发。这个时期还属于架构的早期阶段，大多数人还是没有架构的概念的。Android App开发此时也还处于一个早期的探索阶段，没有任何成熟的框架或者库供开发者使用。所以可以说这个时期还属于架构的萌芽期。早期App功能都比较简单，交互也不像现在这么复杂。所以当时但是随着项目的规模增大和业务的复杂度的增长，App开发技术也随之快速发展。
Android 2.0/2.0.1/2.1 Eclair(松饼)2009.10.26
Android 2.2/2.2.1 Froyo(冻酸奶)2010.5.20
Android 2.3 Gingerbread(姜饼)2010.12.7
Android 3.0 Honeycomb(蜂巢)2011.2.2
Android 3.1 Honeycomb(蜂巢) 2011.5.11
Android 3.2 Honeycomb(蜂巢)2011.7.13
Android 4.0 Ice Cream Sandwich(冰激凌三明治)2011.10.19
Android 4.1 Jelly Bean(果冻豆)2012.6.28
Android 4.2 Jelly Bean(果冻豆)2012.10.30
Android 4.3 Jelly Bean(果冻豆)2013.7.25
Android 4.4 KitKat(奇巧巧克力)2013.11.01
Android 5.0 Lollipop (棒棒糖) 2014.10.16(Material Design)
Android 6.0 Marshmallow（棉花糖） Android在正式发行之前，最开始拥有两个内部测试版本，并且以著名的机器人名称来对其进行命名，它们分别是：阿童木（AndroidBeta），发条机器人（Android 1.0）。后来由于涉及到版权问题，谷歌将其命名规则变更为用甜点作为它们系统版本的代号的命名方法。甜点命名法开始于Android 1.5发布的时候。作为每个版本代表的甜点的尺寸越变越大，然后按照26个字母数序：纸杯蛋糕（Android 1.5），甜甜圈（Android 1.6），松饼（Android 2.0/2.1），冻酸奶（Android 2.2），姜饼（Android 2.3），蜂巢（Android 3.0），冰激凌三明治（Android 4.0），果冻豆（Jelly Bean，Android4.1和Android 4.2）。

各版本UI对比

编译Android APP---30条经验帮你提升

SimonChen published on 2016-02-22

添加任何第三方库时都要三思而后行，因为这是一个非常严肃的决定。
如何用户无法看到它，不要去绘制它！
除非你真的需要，否则不要使用数据库。
65k方法限制非常容易遇到，你可以通过multidexing 来修复它。
RxJava 是用来取代异步操作AsyncTasks 的最佳替代方案。
Retrofit 是最佳的网络库。
通过Retrolambda 缩短你的代码
组合RxJava、Retrofit和Retrolambda 以实现最大化利用。
我使用EventBus ，它非常伟大！但是我并没有大量使用，因为大量使用会导致代码复杂度提高。
通过功能分包，而不是层次。
把任何事情都从应用的线程中移除。
lint 你的视图去帮助你优化布局和布局的层次，以便于你辨认哪些视图是多余的、可移除的。
如果你使用gradle，你可以加速它！
生成你的编译报告 ,看看花费的构建时间;
使用一个众所周知的架构;
测试需要花费时间，但是一旦你掌握了它之后，将会获得比未测试更加快速和健壮的代码。 ;
使用依赖注入 ,让你的应用更模块化并且更容易测试;
收听fragmented podcast 对你来说是有用的。
不要使用你的个人电子邮件作为你的android市场出版商账户;
总是使用适当的输入类型;
使用分析来找出使用平台和隔离缺陷;
掌握新库的状态(可以通过使用dryrun 来快速测试)
你的底层服务应该做它们需要做的事情，并且尽快的销毁。
使用Account Manager 去建议登录用户名和邮箱地址。
使用CI(持续集成)去编译和分发你的beta和production的apk。
不要经营你自己的CI服务器，因为维护服务器包含磁盘空间/安全问题/更新服务器以免受到SSL攻击等等。应该使用circleci，travis或者shippable。它们便宜并且少一点担心。
自动化部署到playstore。
如果一个库非常大而你只需要使用其中一个小功能子集。你应该找到一个更小的替代方案。(例如依赖proguard )
除非实际需要，不要使用更多的模块。如果模块不是经常修改，需要考虑到的重要问题是：从头编译它们所需要的时间(CI 的编译是一个很好的例子)，甚至检查以前的各个模块的构建是否最新的，比起简单的加载.jar/.aar库时间要增加几乎4倍。
开始考虑为了svg格式放弃png格式;
为库创建抽象类，如果你仅仅需要一个开关去简单的切换到一个新的库(例如AppLogger.d(“message”) 能够包含 Log.d(TAG, message))，而后意识到Timber.d(message) 是一个更好的选择。)
监视活跃连接和连接类型(当处于WIFI时有更多的数据更新？)
监控电源和电池(充电时更多的数据更新?当电池电量低时暂停更新?);
用户界面就像是一个笑话。如果需要去解释它，它不是那么好;

译自：https://medium.com/@cesarmcferreira/building-android-apps-30-things-that-experience-made-me-learn-the-hard-way-313680430bf9#.1lb3hoh97

对升级速度忍无可忍谷歌或将收回安卓控制权

SimonChen published on 2016-02-19

新浪美股北京时间19日讯谷歌即将收回安卓升级的主导权，而这将从根本上改变安卓生态系统当前的开发和更新模式。

theregister报道称，Edison Investment Research分析师温莎(Richard Windsor)认为，谷歌已经对迟缓的升级速度忍无可忍，随时可能将固件升级的控制权从硬件玩家的手中收回。

温莎称，安卓6.0，即所谓棉花糖的升级进展迟缓，直接影响了谷歌的新产品推出，如Now on Tap等。他相信，为了改善用户体验，谷歌将会直接接手固件升级，而过去，他们都是将这一任务放手给制造商和运营商去做的。

“谷歌最终将会彻底控制安卓，将整个操作系统整合到他们的服务层Google Mobile Services(GMS)。只有这样，谷歌才能够结束长期以来持续折磨安卓产品的市场高度碎片化问题，并直接控制软件的销售。”温莎指出，“结果就是，谷歌的设备最终也会像iOS或者Windows 10产品那样，制造厂商显然不会再有任何改动的权力。”

温莎指出，根据Edison的统计，尽管和苹果的iOS 9升级大致是同时推出，但是棉花糖到现在也只登上了1.2%的安卓设备。可是，新的iOS却已经覆盖了87%的苹果产品，而这当然要归因于苹果对自己移动产品生态系统的紧密控制。

不能让安卓硬件获得最新版本的操作系统，谷歌自然也就无法发布新的软件和服务升级。温莎相信，正是因为这个，谷歌将最终决定自己全面管理安卓，确保所有的手机和平板都能够跟上最新的软件发布。

“我们估计，与此同时，谷歌在硬件方面的要求也会大大强化，这是为了确保他们的软件都能够顺畅运转。”

“尽管这对于谷歌来说肯定是好事，可以提升用户体验，强化公司的营利能力，但是对于那些长期以来一直处境不佳的手持设备公司而言，这却可能是致命一击。现在，手机几乎就已经日用品化了，只有三星还能够持续保持超过2%到4%的利润率。”

谷歌已经显示出了一些收紧安卓缰绳的迹象。本月早些时候，他们展开了一场针对root手机的打击行动，发布了只能在未解锁手机上使用的Google Pay。(子衿)

原文地址: http://tech.sina.com.cn/it/2016-02-19/doc-ifxprucs6256056.shtml

Udacity也弃用React Native了 ！