The Wrapper Workflow

Use the Flutter Wrapper to get the following benefits:

• Standardizes a project on a given Flutter version, each Flutter project has its own version of Flutter SDK
• Provides the same Flutter SDK version for different users and execution environments in a Flutter project

Flutter Wrapper contains the following files:

flutterw
flutterw.bat
flutter/wrapper/flutter-wrapper.properties

简述

一般来说，SDK依赖库的Api兼容性问题一直是个隐藏的问题，通常没有很好的方式解决，即使使用语义化版本管理，在众多基础SDK的引用依赖下，不能100%保证其中一个基础SDK的Api发生不兼容的改变后，该改变可能是对外暴露方法的签名改变、方法名称改变亦或是类名包名等改变，而发生这些不兼容Api的变化后，不能保证所有依赖该基础SDK的上层SDK全部对应的升级依赖版本。当然，良好的开发模式对于基础SDK开发来讲，对外暴露的Api的改变，一般不能直接改变其方法签名以及包名类名等，而应该相应的标为@Deprecated提供向下兼容

但是，作为团队多人协作开发模式下，不能100%保证所有基础SDK的开发都以兼容方式进行Api的改变，除此之外，使用到的一些三方开源SDK，这个也不能保证它提供的Api是否是兼容的，以及在进行组件化、插件化过程中，Api兼容性问题是必须要考虑的

为什么要考虑？这里所说的Api兼容性问题，不是发生在项目编译期，而是在运行期，因为项目中的SDK依赖库依赖进来时，是已经编译好的字节码文件，所以SDK依赖库内的兼容性问题，只有在程序运行期才可出现，一般表现为Crash或无响应，且出现上述情况的前提条件是代码刚好执行到了这段，否则还是不会有任何异常

一、简述

对于构建Flutter类型应用，因其开发语言Dart、虚拟机、构建工具与平时我们开发Native应用不同且平台虚拟机也不支持，所以需要Flutter SDK来支持，如构建Android应用需要Android SDK一样，下载Flutter SDK通常有两种方式：

1. 在官网下载构建好的zip包，里面包含完整的Flutter基础Api，Dart VM，Dart SDK等
2. 手动构建，Clone Flutter源码后，运行flutter --packages get或其它具有检测类型的命令如build、doctor，这时会自动构建和下载Dart SDK以及Flutter引擎产物

在团队多人协作开发下，这种依赖每个开发本地下载Flutter SDK的方式，不能保证Flutter SDK的版本一致性与自动化管理，在开发时如果Flutter SDK版本不一致，往往会出现Dart层Api兼容性或Flutter虚拟机不一致等问题，因为每个版本的Flutter都有各自对应的Flutter虚拟机，构建产物中会包含对应构建版本的虚拟机。Flutter工程的构建需要Flutter标准的工程结构目录和依赖于本地的Flutter环境，每个对应Flutter工程都有对应的Flutter SDK路径，Android在local.properties中，IOS在Generated.xcconfig中，这个路径会在Native工程本地依赖Flutter工程构建时读取，并从中获取引擎、资源和编译构建Flutter工程，而调用flutter命令时构建Flutter工程则会获取当前flutter命令所在的Flutter SDK路径，并从中获取引擎、资源和编译构建Flutter工程，所以flutter命令构建环境与Flutter工程中平台子工程的环境变量一定得保持一致，且这个环境变量是随flutter执行动态改变的，团队多人协作下这个得保证，在打包Flutter工程的正式版每个版本也应该有一个对应的Flutter构建版本，不管是本地打包还是在打包平台打包

我们知道Flutter应用的工程结构都与Native应用工程结构不一样，不一致地方主要是Native工程是作为Flutter工程子工程，外层通过Pub进行依赖管理，这样通过依赖下来的Flutter Plugin/Package代码即可与多平台共享，在打包时Native子工程只打包工程代码与Pub所依赖库的平台代码，Flutter工程则通过flutter_tools打包lib目录下以及Pub所依赖库的Dart代码。回到正题，因工程结构的差异，如果基于现有的Native工程想使用Flutter来开发其中一个功能模块，一般来说混合开发至少得保证如下特点：

1. 对Native工程无侵入
2. 对Native工程零耦合
3. 不影响Native工程的开发流程与打包流程
4. 易本地调试

显然改变工程结构的方案可以直接忽略，官方也提供了一种Flutter本地依赖到现有Native的方案，不过这种方案不加改变优化而直接依赖的话，则会直接影响了其它无Flutter环境的开发同学的开发，影响开发流程，且打包平台也不支持这种依赖方式的打包

再讲讲Flutter SDK，平时进行Flutter开发过程中，难免避免不了因Flutter SDK的Bug亦或是需要改Flutter SDK中平台链接的脚本代码导致直接改动或者定制Flutter SDK，这种方式虽然可以解决问题或定制化，不过极其不推荐，这种方式对后续Flutter SDK的平滑升级极不友好，且带来更多的后期维护成本

接下来，本文主要是介绍如何对上述问题解决与实现：

1. Flutter SDK版本一致性与自动化管理
2. 无侵入Flutter SDK源码进行BugFix或定制化
3. Flutter混合开发组件化架构
4. Flutter混合开发工程化架构

前言

我们知道构建一个apk时必然存在的一个过程—res与manifest的合并，因为资源与manifest除了存在于主资源集中，对于第三方aar或构建变体中也可存在，当构建一个apk时，必然会对它们所含有的资源或manifest进行合并，而不是把所有存在的资源或manifest全打包进apk中，构建一个apk时，主要有以下三种资源会进行merge：

1、主资源集(src/main/)
2、构建变体(buildType、productFlavor、productFlavorBuildType)
3、三方依赖(aar)

当一个资源名在上述资源集中唯一存在时，那么将直接打包进apk中，当一个资源名在不同资源集中存在多个版本时(资源类型与资源限定符相同情况下)，这时将只有一个会被打包进apk中，这种情况就是通过merge进行处理，同理，manifest也一样，对于相同的标签存在多个版本时，也将进行merge。资源和manifest的merge都遵循如下优先级：

build variant > build type > product flavor > main source set > library dependencies

简介

随着目前设备像素的不断提高，基本随便一张照片即是M级别的大小，对于如此大的图片，不管是在内存空间、带宽资源和服务器数据空间上都是非常耗费的，特别是在移动端，由图片引起的OOM和图片上传质量过大等问题我想大家都遇到过，所以对于图片内存占用上和物理空间占用上进行压缩很有必要，在Android上，我们使用到的图片格式无非这五种：PNG、JPEG、Webp、SVG、GIF。其中GIF的位深为8位，所以文件通常比较小而且支持alpha通道以及动画，Webp在等质量的大小上和等大小的清晰度上都占极大优势，而SVG矢量图是由xml文件进行描述的，可以适配于任何分辨率的设备而保证图像不失真，Google的官方视频中也提到可用这两种格式进行某些场景下替换PNG或JPEG图像，这不但能节约带宽资源还能提高图片加载速度，所以图片压缩主要是对PNG和JPEG这两种格式，关于图片的压缩，有无损压缩和有损压缩两种方式，这两种压缩方式区别如下：

无损压缩：通过对冗余数据的存储方式进行优化，该方式不会丢失文件内容，压缩率受冗余度的影响，所以压缩率较低
有损压缩：通过丢失不会对文件造成太大影响的数据来达到压缩效果，所以压缩率较高

其中PNG是无损压缩格式图片，JPEG是有损压缩格式图片，所以对应的也有各自的压缩算法，在Android系统中，png的压缩是使用libpng进行压缩，场景有两个：编译阶段以及api层调用方式进行压缩。其中在编译阶段通过aapt打包工具会对drawable目录下png图片进行压缩，压缩率大约在40%以下，如果我们对编译后的apk进行解压，可以发现解压后drawable目录下的png图片比原先的变小了，但是，也有例外，对于NinePatch(.9)图片却变大了，这里先讲下原因，因为对于.9图片在编译过程中aapt会对它额外进行处理，使得.9图片会增加2~3个不同类型的Chunk块（注：api层调用方式进行压缩不会对.9进行额外处理），而jpeg的压缩是用libjpeg（7.0后有变化，后面另外说）进行压缩，场景只有在api层进行调用方式进行压缩。下面将主要围绕图片的压缩原理、压缩策略以及在Android上的运用进行讲解。

目的

为了简化对图片压缩的调用，提供最简洁与合理的api压缩逻辑，对于压缩为Bitmap根据屏幕分辨率动态适配最佳大小，对于压缩为File优化底层libjpeg的压缩，整个图片压缩过程全在压缩线程池中异步压缩，结束后分发回UI线程。

支持的压缩类型

Tiny图片压缩框架支持的压缩数据源类型：

1、Bytes
2、File
3、Bitmap
4、Stream
5、Resource
6、Uri（network、file、content）

Tiny支持单个数据源压缩以及批量压缩，支持的压缩类型：

1、数据源—>压缩为Bitmap
2、数据源—>压缩为File
3、数据源—>压缩为File并返回压缩后的Bitmap
4、批量数据源—>批量压缩为Bitmap
5、批量数据源—>批量压缩为File
6、批量数据源—>批量压缩为File并返回压缩后Bitmap

RTMPDump概述

RTMPDump主页，RTMPDump库主要包含三部分：

1、一个基本的客户端程序
2、两个服务器程序（rtmpsrv、rtmpsuck）
3、一个支持rtmp协议的库—librtmp

下载RTMPDump最新源码，可以通过git拉取master分支上的最新代码：

1

git clone git://git.ffmpeg.org/rtmpdump

或者下载以前版本的代码—Download old version

下面主要介绍librtmp和librtmp的编译

librtmp概述

librtmp库提供了大量客户端函数和少部分的服务器端的函数用来支持RTMP、RTMPT（RTMP使用Http通道），RTMPE（加密的RTMP），RTMPS（基于SSL/TLS的RTMP）和RTMPTE、RTMPTS（使用Http通道的加密和基于SSL/TLS的RTMP）协议

使用librtmp库进行的流媒体交互都是使用FLV封包格式进行传输的，当然编码不限定，不过为了拉流端同时也支持HLS协议，最好使用H264编码视频和AAC编码音频数据

FFmpeg简介

FFMPEG是一套具有非常强大功能的多媒体处理工具，它几乎涵盖了目前所有主流的多媒体数据封装格式、多媒体传输协议以及音视频编解码器，并且支持多媒体后处理，视频色彩转换、滤镜和缩放等，也支持众多主流的协议：HTTP、RTP、RTSP、RTMP、HLS、UDP等
安装可以通过Homebrew

FFmpeg它主要含有以下几个核心库：

1、libavcodec-提供了更加全面的编解码实现的合集
2、libavformat-提供了更加全面的音视频容器格式的封装和解析以及所支持的协议
3、libavutil-提供了一些公共函数
4、libavfilter-提供音视频的过滤器，如视频加水印、音频变声等
5、libavdevice-提供支持众多设备数据的输入与输出，如读取摄像头数据、屏幕录制
6、libswresample,libavresample-提供音频的重采样工具
7、libswscale-提供对视频图像进行色彩转换、缩放以及像素格式转换，如图像的YUV转换
8、libpostproc-多媒体后处理器

以及包含以下几个工具：

1、ffmpeg-一个流媒体的编解码、格式转换以及多媒体流的内容处理工具
2、ffplay-一个使用FFmpeg编解码的播放器
3、ffprobe-一个多媒体分析工具
4、ffserver-一个流多媒体服务器

简介

App Crash的恢复，这个想法很早之前就有，目前有些时间就实现了一把，主要是对App运行时发生Crash后，对Activity的堆栈和数据进行恢复，或者重启应用，或者重启并清空缓存，避免因本地的数据类型或格式错误而导致App在读取时一直Crash，Debug模式还包括Crash信息的显示和保存，便于在开发、测试时查看相应CrashInfo

Crash的处理

对于应用的Crash，一般的做法我们往往都是实现个自定义UncaughtExceptionHandler，而这个自定义的CustomUncaughtHandler我们一般都用于捕捉Crash信息进行上报和监控是否发生Crash，还有一个作用就是可以屏蔽系统默认的Crash对话框，也就是拦截Crash后不把系统默认的UncaughtHandler设置进去，而是直接进行KillProcess，这个过程就是屏蔽了系统的默认Crash处理流程，原因是系统的处理其中在AMS的crashApplication()中会执行这么一段代码：

1
2
3
4
5
6
7

Message msg = Message.obtain();
msg.what = SHOW_ERROR_MSG;
HashMap data = new HashMap();
data.put("result", result);
data.put("app", r);
msg.obj = data;
mUiHandler.sendMessage(msg);

发送一个显示Dialog的消息，之后便创建一个AppErrorDialog进行显示。

前言

最近部门内抛出了一个问题，应用启动很慢、卡图标？主要表现在中低端机型中。究其这个问题，由于对性能优化比较感兴趣，借了个低端机和一个中端机来一看究竟，对同一应用分别测了下它在中低端机的启动时间，下面为启动耗时情况：

启动了三次，基本都在4s左右。