野火🔥

生命如野火,骄傲而顽强

RN学习4——QDaily Android app中通信和热修复实践

React Native现在已经到了0.37版本了,在集成RN初期使用的0.30版本还不支持将resources打入bundle实施热更新,0.37版本已经解决了这些问题,如果再不写篇文章,炒炒这份冷饭,那就过气了。

QDaily现在在Android和iOS的版本中都集成了React Native,用其做广告效果页的展示。

本文介绍基于Android平台,在RN进行混合app研发过程中,native部分做过的一些工作和踩过一些坑。

本该双平台一起介绍的,但Android的坑多,先说Android,iOS的对应工作会在下个文章描述。

该文章为系列文章,之前的文章为RN学习1——前奏,app插件化和热更新的探索RN学习2——客户端开发者的一些准备工作RN学习3——集成进现有原生项目

一、Android中RN的View初始化及传参

马上看代码

//React相关组件初始化
ReactRootView mReactRootView = new ReactRootView(this);
mReactInstanceManager = ReactInstanceManager.builder()
      .setApplication(getApplication())
      .setJSBundleFile(getBundleFilePath())
      .setJSMainModuleName("index.android")
      .addPackage(new MainReactPackage())
      .setUseDeveloperSupport(BuildConfig.DEBUG)
      .setInitialLifecycleState(LifecycleState.BEFORE_RESUME)
      .setUseOldBridge(true)
      .build();

//准备参数
Bundle bundle = new Bundle();
bundle.putString("url", "http://www.qdaily.com");
bundle.putFloat("totalSeconds", 12);
bundle.putInt("style", 1);
bundle.putString("extras", "{\"key\" : \"value\"}");
bundle.putStringArray("imagePaths", new String[]{"url1", "url1"});

//组件启动
mReactRootView.startReactApplication(mReactInstanceManager, "adImageLaunch", bundle);

Android M、N适配踩坑

我们上个月才决定开始进行Android M、N的集中适配,发现很多问题,在此一起进行总结。

首先我们把buildToolsVersion和compileSdkVersion都改为24,相关support的lib也都改为24.*,以此放开了适配,遇上了很多坑。

这里不是一个大而全的适配方案,仅仅是一个小app(好奇心日报)的适配总结。

Android N的适配主要为组内同事操刀,所以文内部分内容源于该同事的总结。

ps:此后统一博客文章的路由命名方式,改为文章创见时间命名,如“2016-11-20”,若当天有第二篇则顺序命名为“2016-11-20-1”,以此来统一化,避免未来路由失效问题。

一、权限适配 -- Android M

作为一个新闻类app,适配的最主要的部分应该就是权限了。
Android6.0引入了动态权限控制,7.0使用了私有目录被限制访问Strict Mode API 政策
因此权限适配包含app权限获取部分和私有目录访问部分。

QDaily app连续crash处理方案


上周出现了一次MIUI8.0的开机crash情况,在已经提交应用市场审核后通过的前一刻发现并下架,但也惊出了一身冷汗,深刻感觉开机crash的保护方案尤其重要。
以前有crash的保护方案,但只是在连续crash后进行本地缓存清理,而且在Android端一直做的不够,不能够处理很多复杂情况。事实证明,这半年出现过两次打开crash的情况(一次iPad,一次MIUI8.0),之前的保护方案都未能生效。
本文先进行头脑风暴,画出思维导图,然后进行细化和测试。

思维导图

先出梗概,之后慢慢进行两个系统的细化实现。


iOS实现代码

Android的实现代码

QDaily - Android MVP改造

演进式框架设计。使得工程未来更有设计感和易于维护。
上个月事情多,周末好多时间都周转于河北天津,而且有点懈怠,以后博客继续更新。

整个改造思路来源于google的Android Architecture Blueprints,google这个框架名字就非常霸气,Android架构蓝图,有了这个做参考,给了架构设计一个非常指导性的建议。

QDaily app流量和文章打开速度优化--js和css的加载逻辑


本文属于“好奇心日报app的流量和文章打开速度优化”系列文章第二篇,主要介绍为实现文章尽快的打开速度而进行的js和css的预载和缓存以及重用的逻辑。

整篇代码均为Objective-C,Android可以参考书写。

前言

好奇心日报所有文章都是自产,js和css文件在所有文章中都使用的一套进行逻辑和样式处理。在每次前端同事修改了js或者css代码后,会给该文件直接生成一个64位的hashcode附在其后,以区分不同版本,用于浏览器端更新使用,例如:

    http://app3.qdaily.com/assets/app3/common-bc6aa258d92609720eb97f34f86f978367bd3d849c9c0bbc82feeed9e79b6623.js

其中主要包括common.js、show.js、common.css和show.css四个文件。

【iOS&Android】RN学习3——集成进现有原生项目

在做了短暂的技术调研和分析之后,我决心将RN和现有的QDaily项目进行集成,并替换掉其中的广告效果展示页面。

本文开发环境为Mac,在React Native 版本为0.30。同时RN仅仅作为插件形势集成到原有Native工程中,因此主要还是一个Native工程而非RN工程

而且,本文的前提是你已经在本地配好了iOS开发环境或Android开发环境,也就是说,你起码已经是一个Android开发者或者iOS开发者。

【Android&iOS】QDaily基于WebP的流量优化实践


本文属于“好奇心日报app的流量和文章打开速度优化”系列文章第一篇,主要介绍基于图片压缩的流量优化。
流量优化对于一个app来讲意义非常重大,能节约用户的流量,节约用户的存储空间,而且能有提高网络请求的回包速度,提高app的速度。因此流量优化历来都是app的优化重点,而且是一个持续优化的点。

QDaily是一个多图片的新闻类应用,采编喜欢上传gif图来提高内容的表现力,这也使得流量消耗非常大。粗略估计,用户在浏览完第一页所有新闻(共48篇),会消耗流量达100m,其中98m为图片,这里值得优化的空间非常大。

针对这种情况,我们先后使用的优化包含:wifi条件下预载所有文章、图片和js、css数据;重用所有已经下载的js、css和图片的缓存;后台图片的压缩以及客户端图片的WebP化。

其中,后台压缩和WebP化依赖第三方多媒体处理服务器,已知比较好的国内服务有腾讯优图和七牛。这里我们采用的七牛的服务,以下很多具体的调用都是基于七牛的。

我们的后台通过七牛的图片压缩(包含质量和分辨率),我们将首页流量由100m减少到了80m,依然有极大的提升空间。因此客户端采用基于WebP的流量压缩方案,将流量由80m压缩到了20m,减少了75%!相对于最初的处理,流量减少了80%!(android大多数机型支持WebP animated,压缩能达到80%,但iOS的压缩率取决于首页中gif图的个数和大小,测试大概优化在60%-80%之间)

下面就介绍下这个效果极好的WebP的流量解决方案。

今日好文20160726

本月事情多,师妹的好多事情,还有开发工作。深刻研究了RN的使用,并应用在实践中;极限的流量优化,将QDaily客户端的消耗流量减少了75%。这些都开始囤积文章,稍后慢慢分享出来。

水一些本月学习的东西