React Native错误: “:CFBundleIdentifier”, Does Not Exist

最近项目需要,决定入手React Native。

第一步要做的肯定就是能在本机顺利的把官网的Quick Start 跑出来.

先说一下本机的环境:

  • 系统: macOS Sierra 10.12.5
  • NodeJs: 8.1.0
  • Xcode: 8.3.3 (8E3004b)
  • react-native-cli: 2.0.1
  • react-native: 0.45.1

构建过程

官网是用的brew来安装node,但是我这边根据日常开发的需要,会在多个Node版本之间切换,所以我是用的nvm

接下来是watchmanreact-native-cli,都是按照教程来一步一步安装

brew install watchman
npm install -g react-native-cli

然后是初始化和启动项目

react-native init AwesomeProject
cd AwesomeProject
react-native run-ios

然后就出错了:“:CFBundleIdentifier”, Does Not Exist

debug过程

先是在github上面找到了一个同样错误的issue,发现有这个错误的人很多,给的解释也不少

端口占用

端口8081被别的程序占用了

lsof -n -i4TCP:8081
node    7601 CXI624   23u  IPv6 0xc6b249599e5f1169      0t0  TCP *:sunproxyadmin (LISTEN)
kill - 9 7601 

这里面的7601只是一种情况,具体看真实占用这个端口的是什么程序。

我这边可以确定不是,所以pass

重买一台mac解决了

这… 没钱,pass

react-native upgrade

更新react-native到最新版

我这刚刚下载的,肯定最新版没毛病

sudo

sudo react-native run-ios

这个我是不太想用的,因为用了之后,以后基本都得用sudo,比较麻烦,等确认没别的解决方式再考虑

尝试调整Xcode的配置:

  1. Go to File -> Project settings
  2. Click the Advanced button
  3. Select “Custom” and select “Relative to Workspace” in the pull down
  4. click done, done

按照上面的做了一下,然后直接基于Xcode来运行程序

结果又出了新的问题

double-conversion.build failed

然后是在这个issue下找到了问题的解决方式:

rm -r ~/.rncache
rm -r <your-project>/node_modules/react-native/third_party

不过最终的编译还是失败。

网络问题

最后在刚刚的那个issue里面找到了那么一段话:

The problem is when building react-native for iOS, the process tries to download some files (using curl) into /.rncache. Specifically, they are “boost1630.tar.gz, double-conversion-1.1.5.tar.gz folly-2016.09.26.00.tar.gz, glog-0.3.4.tar.gz”. The sources of them (at least some of them) are from AWS S3, which aren’t accessible in some regions (I’m from China). And that caused the problem.
By using a proxy server and setting the http_proxy and https_proxy environment variables, curl will go through the proxy and the build should succeed.
This is not a problem with React Native. This issue can be closed now.

是说的在build的时候,会从AWS S3里面下载一些资源,但是在咱们国内,很多时候是访问不到这些资源的,也自然就导致了一些文件的缺损。

作者在后面给的方式是给curl配置代理,具体看https://stackoverflow.com/questions/9445489/linux-curl-command-with-proxy

不过我这边用了另外一种方式,把我的蓝灯设置为代理全部流量,接着

rm -r ~/.rncache
rm -r <your-project>/node_modules/

把所有资源删掉,然后重新编译。

最后,成功编译通过!!

QQ内置浏览器下的QQ登录实现

在PC时代,调用QQ, 微博之类的三方登录,对于前端来说是比较轻松的(如果不需要异步登录的话),而且体验也不错,QQ那边可以自动识别是否登录,对于用户只是一个确认和点击的流程。

但是到了现在,移动互联的时代,这样的三方登录完全都是APP那边前端的事情,Web前端无能为力。毕竟,让用户在一个小设备上的小网页里面输入他已经在登录状态的QQ的账号密码,是挺难为人也挺不现实的。

缘于产品庆庆同学的执着,偶然发现在QQ内置的浏览器里面进行QQ登录的话,是也可以跟PC那样自动识别到已登录状态的,这让事情有了一线曙光。不过这种便利也只能在QQ的内置浏览器里面

下面就来说说如何实现web网页在QQ内置浏览器里面的登录

识别QQ的内置浏览器

首先得识别当前所在的浏览器是不是QQ内置的。

QQ浏览器分两种情况,一个是独立的浏览器产品,一个是内置在QQ里面的webview。识别的方式,用userAgent。

先贴出对应平台对应分类的UA(使用v2ex提供的一个工具页面可以方便的打印UA )

安卓平台下的独立的QQ浏览器

Mozilla/5.0 (Linux; U; Android 4.4.4; zh-cn; HM 1S Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko)Version/4.0 Chrome/37.0.0.0 MQQBrowser/7.4 Mobile Safari/537.36

安卓平台下的内置的QQ浏览器

Mozilla/5.0 (Linux; Android 4.4.4; HM 1S Build/KTU84P; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/53.0.2785.49 Mobile MQQBrowser/6.2 TBS/043124 Safari/537.36 V1_AND_SQ_6.7.1_500_YYB_D QQ/6.7.1.3105 NetType/WIFI WebP/0.3.0 Pixel/720

IOS平台下的独立的QQ浏览器

Mozilla/5.0 (iPhone 5SGLOBAL; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 MQQBrowser/7.4 Mobile/14E304 Safari/8536.25 MttCustomUA/2 QBWebViewType/1

IOS平台下内置的QQ浏览器(TIM内)

Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Mobile/14E304 QQ/6.5.5.0 TIM/1.0.5.9 V1_IPH_SQ_6.5.5_1_TIM_D Pixel/640 Core/UIWebView NetType/4G QBWebViewType/1

这里因为测试设备有限,没法确切知道所有版本的QQ下的情况,只能等以后慢慢完善。

从上面的UA可以找到两个关键字QQMQQBrowser。本来两个关键字是分开的,独立浏览器里面是MQQBrowser,内置的是QQ,但是这在安卓的内置里面同时实现了。

所以判断方式需要绕一点:先判断MQQBrowser,如果存在,判断QQ是否存在,存在则是内置,不存在则是独立;如果不存在MQQBrowser,则判断QQ是否存在,存在是内置,不存在,就都不是。

不过我们这次的需求只需要判断内置,所以简单,判断QQ是否存在即可:navigator.userAgent.match(/QQ\/([\d.]+)/)

登录的实现

一开始是打算继续用PC时代用的那个登录SDK好实现一个优雅的异步免刷新的登录效果。在实际测试的时候,也的确是可以做到在登录页QQ自动识别状态只需要用户点击登录按钮确认,可是在登录回跳这块卡住了。

在PC,SDK是用window.open新开一个弹窗来实现登录和各种跳转,在新窗口的最终落地页和主窗口通信返回登录成功获取的AccessToken,然后关闭弹出窗口。

但是内置浏览器里面window.open的效果是替换当前网页展示,类似于location.href赋值跳转,这使得最终落地页一直联系不到主窗口,然后卡着了。

很自然的,就想到了用iframe,把window.open打开的地址放到iframe里面,不就可以实现两个window的通信了吗?说干就干,QQ登录界面顺利的展现了,点击登录,结果主界面跳了,跟之前一样,再次无法通信。看来QQ在登录成功之后是用window.top来跳转的。不明白QQ这样做是出于什么考虑的,安全性?可是登录成功的回调地址不是已经被限制了只能是对应域名下的了吗?唯一知道的就是,这个方法行不通……

所以,目前还是只能走以前的老路,通过页面跳转的方式来实现登录。主要的策略就是在QQ登录成功之后的回调页再跳回之前的发起登录的页面。

本来这个需求是由后端来实现,在回跳发起页之前,在cookie里面记录用户的登录信息,这样发起页就能知道用户登录成功了。

不过我这次的需求,有两个麻烦的地方:

  1. 后端目前还没有在移动站点配置登录功能
  2. 我需要知道QQ用户的OpenIDAccessToken

所以改为由后端配置好回调页路由,具体页面里面的跳转和信息记录由前端自行控制。

然后具体的实现步骤是:
1. 用户点击发起页上的QQ登录按钮
2. 前端在后端给的redirect_url里面加上一个search query字段redirect,方便后面回跳回来
3. 前端根据appIdredirect_url整合出跳转QQ登录的地址(https://graph.qq.com/oauth2.0/authorize? response_type=token&client_id={{appId}}&scope=all&display=mobile&redirect_uri={{回调地址}})并跳转
4. 在QQ登录页面,QQ识别到当前用户的登录状态,自动填充信息并添加一键登录按钮
5. 用户点击登录
6. QQ开始回跳到redirect_url并在redirect_url后附加hash query,这个query里面有 access_token expires_in
7. 这个回调页,js抓取token和token过期时间存储在localStorage,同时还在localStorage记录两个个临时的key: TempQQLoginSuccessTempQQLoginSuccessTime
8. 回调页识别search query里面的redirect字段,获取发起页地址并跳转过去。
9. 发起页初始化的时候,查看localStorage里面有没有token和expire_in对应的字段,如果没有则是未登录状态,执行一次退出操作(退出操作是尝试清空回调页记录的四个key,下文同理)。如果存在,则判断当前时间是否超过expire_in对应的时间,如果超过,则执行退出操作。没有超过,则此时用户是登录状态。
10. 确定用户登录之后,再判断回调页记录的两个临时字段是否存在。如果有,判断TempQQLoginSuccessTime存储的时间和当前时间的时间差是否有超过一定的阈值。如果没有超过则说明上一次的发起页有登录行为,可以提示登录成功,如果超过了,则直接显示登录后的状态即可。同时不管超过与否,清空这两个临时key。

以上,整个登录流程就通了,成功的获取了用户的accessToken。

后面再使用accssToken作为参数,以jsonp的方式访问QQ的接口https://graph.qq.com/oauth2.0/me?access_token={{accessToken}}就能顺利的获取到用户的openId。这里要注意的一点是,QQ的这个接口里面callback的函数名写死了是callback,所以在使用jsonp的时候,以Zepto为例,jsonpCallback需要设定为callback

关于这个项目,具体实现代码在这:https://github.com/shuizhongyueming/fe-qq-login,有兴趣的可以看看

Web端打开APP功能的实现

这两天公司开始发力做APP的推广,很多活动页和移动端站点需要加上打开APP的功能,如果没安装则提示用户下载。

首先,基于隐私保护的目的,浏览器是不会提供接口给网页去获取系统上安装了的APP的列表

然后很多产品经理会在提需求的时候有一种洁癖,希望网页上那个可供用户点击的按钮,在已安装APP的时候是打开,在未安装的时候是下载

早先的做法

为了应对这样的需求,前端程序员们想出了一个很棒的方法,利用浏览器进驻后台之后会暂停js的执行这一特性,顺利实现了对是否安装了自己公司APP的探测。具体实现如下:

在用户点击或者进入页面时候,记录一个当前时间time1,然后设置一个300ms的timeout,在timeout的回调里面记录时间time2,接着就用location.href直接指向对应APP已经配置的url scheme。

如果time1time2的时间差超过400ms(考虑到setTimeout本身的误差)就认为安装了APP,不需要处理,否则则是没安装,提示下载或者自动下载。

因为,如果用户安装了对应的APP,那么会自动的跳转到APP的界面,浏览器这边的计时会被中断,等下次用户偶然再使用浏览器的时候,计时继续,会触发setTimeout的回调,不过这个时候time1time2的时间差就远大于300ms了。

如果用户没有安装对应APP就不会发生跳转,setTimeout也就自然在规定时间内运行回调了。

这种方法曾经是非常有效果的,不过现在会有些问题了。

首先是安卓下,有些浏览器,比如UC会在网页试图打开APP的时候阻断这个行为并弹出一个select弹窗,让用户选择是否打开,是否始终打开等等。

UC的select弹窗

但是这个弹窗并没有像alert那样阻塞js的执行,也就是说setTimeout会正常进行,在用户犹豫怎么选择的时候,300ms就过了,页面就自动跳转了下载页。

接着是IOS这边,到IOS10之后,如果已经安装了对应的APP,浏览器也会在网页尝试打开APP的时候弹出一个confirm窗,让用户选择是否打开对应的APP。

已安装:确认窗提示是否打开APP

如果没有安装对应APP,就会实现一个很丑陋的网页无法打开此链家的错误alert窗。

未安装:提示网址无效

而且这两个窗口也是没有阻断js脚本的执行的,setTimeout也是同样正常进行中。

尝试过把300ms的时间改成3000ms,去预想用户可以在3秒内在浏览器的选择窗内做好选择。可是仔细一想,这种预想又是非常不靠谱的,永远没法猜测用户的未知行为,而且3000ms的响应延迟也是非常不好的交互体验。

是时候去调整思路了

如果浏览器不希望我们知道设备上是否已经安装了对应的APP,那就不尝试去知晓。

目前我们的做法是:在用户通过点击或者别的行为触发了打开APP的策略的时候,首先是尝试直接访问url scheme,在这同时,展现一个弹窗,里面包含一个APP的介绍文案,然后底部是两个按钮,下载APP打开APP

下面是天猫的做法,很值得借鉴:

先尝试跳转
同时显示下载和打开

这样做的好处是:如果用户已经安装了APP,那么就直接跳转了,弹窗对用户不会有任何的影响;如果没有安装,或者用户安装了,但是因为不想跳转或者误操作没有跳转,则用户在关闭了浏览器的错误提示之后,看到弹窗,能大概理解之前的浏览器的行为是什么意思,同时可以再次选择打开或者下载APP。

同时,如果是进入页面立马就跳转的行为,最好能有一个次数限制,不然一个高频访问的页面,每进入一次都有这样一个弹窗,明摆着是想赶用户走了啊