然后从源码角度分析一下 LifeCycle是如何帮助 Activity 或 Fragment管理生命周期的。后续会继续推出分析 Jetpack其他组件的文章。
我们知道，我们在用某些模块进行数据加载的时候，往往需要去监听 Activity或 Fragment的生命周期。再根据生命周期的变化去调整数据加载或回调的策略。
不使用组件来管理的话，一般我们可以在 Activity或 Fragment的生命周期回调方法里手动去调用模块的生命周期方法。这样页面的生命周期回调方法里可能就会出现大量这样的刻板代码，也不好管理。LifeCycle就用来解决这样的一些问题。
使用 LifeCycle不用添加依赖了，因为已经内置了。如果要使用 Viewmodel和 Livedata则需要加依赖，这两个后续会有文章分析。
首先，既然是生命周期的监听，那就会有观察者和被观察者。被观察者需要实现的接口是 LifecycleOwner，也就是生命周期拥有者（Activity 或 Fragment）。这两者都实现了 LifecycleOwner接口，我们可以看一下 Activity 的父类 ComponentActivity：
public class ComponentActivity extends androidx.core.app.ComponentActivity implements
LifecycleOwner,
...
...
{
生命周期观察者需要实现的接口是 LifecycleObserver。下面我们就结合上次 MVP架构的例子，给 Presenter添加 LifeCycle生命周期监听方法。
首先让 BasePresenter实现观察者接口：
// 实现 LifecycleObserver
public class BasePresenter implements LifecycleObserver {
private V mView;
public void attach(V iView) {
this.mView = iView;
}
public void detach() {
this.mView = null;
}
public V getView() {
return mView;
}
}
然后我们给 BasePresenter的实现类 Presenter添加几个生命周期的方法，并加上**@OnLifecycleEvent**注解：
// Presenter.java
// onCreate
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
public void onCreate(){
Log.d(TAG, "-----------LifecycleObserver -- onCreate");
}
// onStart
@OnLifecycleEvent(Lifecycle.Event.ON_START)
public void onStart(){
Log.d(TAG, "-----------LifecycleObserver -- onStart");
}
// onPause
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
public void onPause(){
Log.d(TAG, "-----------LifecycleObserver -- onPause");
}
// onStop
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
public void onStop(){
Log.d(TAG, "-----------LifecycleObserver -- onStop");
}
// onDestroy
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
public void onDestroy(){
Log.d(TAG, "-----------LifecycleObserver -- onDestroy");
}
然后在 BaseMvpActivity初始化时添加观察者：
// BaseMvpActivity.java
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView();
initView();
initData();
mPresenter = createP();
//mPresenter.attach(this);
// 注释 1， 添加观察者
getLifecycle().addObserver(mPresenter);
}
@Override
protected void onDestroy() {
super.onDestroy();
// mPresenter.detach();
// 移除观察者
getLifecycle().removeObserver(mPresenter);
}
上次例子使用了模板设计模式，所以现在生命周期观察者的添加和移除也放在模板里了。 然后打开 Activity后退出，看打印结果：
com.ethan.mvpapplication D/Presenter: -----------LifecycleObserver -- onCreate
com.ethan.mvpapplication D/Presenter: -----------LifecycleObserver -- onStart
com.ethan.mvpapplication D/Presenter: -----------LifecycleObserver -- onPause
com.ethan.mvpapplication D/Presenter: -----------LifecycleObserver -- onStop
com.ethan.mvpapplication D/Presenter: -----------LifecycleObserver -- onDestroy
Demo： MVP
下面我们来分析一下 Lifecycle生命周期监听的原理。简单粗暴，直接点进上面注释 1的getLifecycle()方法，看看干了啥：
// ComponentActivity.java
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
返回的是一个 LifecycleRegistry 对象，我们可以点进去看。LifecycleRegistry 是抽象类 Lifecycle的实现类：
public abstract class Lifecycle {
@MainThread
public abstract void addObserver(@NonNull LifecycleObserver observer);
@MainThread
public abstract void removeObserver(@NonNull LifecycleObserver observer);
@MainThread
@NonNull
public abstract androidx.lifecycle.Lifecycle.State getCurrentState();
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY
}
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast(@NonNull androidx.lifecycle.Lifecycle.State state) {
return compareTo(state) >= 0;
}
}
}
上面抽象类 Lifecycle 不仅包含了添加和移除观察者的方法，还包含了 Event 和 State 两个枚举。我们可以看到，Event 这个枚举包含了 Activity最主要的几个生命周期的方法。
下面我们继续看 LifeCycle是怎么监听生命周期的：
public class ComponentActivity extends androidx.core.app.ComponentActivity implements
LifecycleOwner,
......{
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
......
// 注释 2， ComponentActivity注入 ReportFragment
ReportFragment.injectIfNeededIn(this);
......
}
......
@Override
public androidx.lifecycle.Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
}
按理说可以在上面的 ComponentActivity的各个生命周期回调中调用观察者的对应方法，但我们可以看到 ComponentActivity 这个类里并没有这样做。而是在上面注释 2处将当前Activity对象注入 ReportFragment中，我们看看ReportFragment干了啥：
public class ReportFragment extends Fragment {
private static final String REPORT_FRAGMENT_TAG = "androidx.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
public static void injectIfNeededIn(Activity activity) {
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
// 注释 3， 创建ReportFragment 添加到 Activity，使得生命周期与之同步
manager.beginTransaction().add(new androidx.lifecycle.ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
static androidx.lifecycle.ReportFragment get(Activity activity) {
return (androidx.lifecycle.ReportFragment) activity.getFragmentManager().findFragmentByTag(
REPORT_FRAGMENT_TAG);
}
// 分发生命周期回调事件
private void dispatchCreate(androidx.lifecycle.ReportFragment.ActivityInitializationListener listener) {
if (listener != null) {
listener.onCreate();
}
}
......
......
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
dispatchCreate(mProcessListener);
dispatch(androidx.lifecycle.Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
super.onStart();
// 注释 4， 开始调用观察者的生命周期
dispatchStart(mProcessListener);
dispatch(androidx.lifecycle.Lifecycle.Event.ON_START);
}
......
......
private void dispatch(androidx.lifecycle.Lifecycle.Event event) {
Activity activity = getActivity();
if (activity instanceof LifecycleRegistryOwner) {
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
}
if (activity instanceof LifecycleOwner) {
androidx.lifecycle.Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
// 注释 5，生命周期事件分发
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
}
上面注释 3处我们可以看到，这里创建了一个 Fragment，然后将 Fragment添加到 Activity中。这样的话，新创建的这个 Fragment和 Activity就可以同步生命周期。之后，在上面注释 4的地方，Fragment的各种生命周期的方法里就可以调用观察者（LifecycleObserver）的相关的生命周期方法了。
也就是说，ComponentActivity 创建了一个 ReportFragment ，并把生命周期回调的事务交给了Fragment。这sao操作是不是很熟悉？没错！我们之前分析过，Glide 也是这么管理生命周期的。
上面注释 5，我们再看看生命周期事件分发，看看观察者方法最终调用的地方：
// LifecycleRegistry.java
static class ObserverWithState {
androidx.lifecycle.Lifecycle.State mState;
LifecycleEventObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, androidx.lifecycle.Lifecycle.State initialState) {
// 获取 ReflectiveGenericLifecycleObserver对象
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, androidx.lifecycle.Lifecycle.Event event) {
......
// 生命周期回调事件分发
mLifecycleObserver.onStateChanged(owner, event);
}
}
// Lifecycling.java
static LifecycleEventObserver lifecycleEventObserver(Object object) {
.....
// 返回 ReflectiveGenericLifecycleObserver对象
return new androidx.lifecycle.ReflectiveGenericLifecycleObserver(object);
}
// ReflectiveGenericLifecycleObserver.java
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
private final Object mWrapped;
private final ClassesInfoCache.CallbackInfo mInfo;
ReflectiveGenericLifecycleObserver(Object wrapped) {
mWrapped = wrapped;
mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
}
@Override
public void onStateChanged(LifecycleOwner source, androidx.lifecycle.Lifecycle.Event event) {
// 生命周期回调
mInfo.invokeCallbacks(source, event, mWrapped);
}
}
// ClassesInfoCache.java
private ClassesInfoCache.CallbackInfo createInfo(Class klass, @Nullable Method[] declaredMethods) {
Class superclass = klass.getSuperclass();
for (Method method : methods) {
// 反射遍历观察者的各个方法，将带 @OnLifecycleEvent注解的方法保存在
// Map对象中，方便生命周期变化时调用
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation == null) { continue; }
Class[] params = method.getParameterTypes();
......
androidx.lifecycle.Lifecycle.Event event = annotation.value();
......
ClassesInfoCache.MethodReference methodReference = new ClassesInfoCache.MethodReference(callType, method);
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
mCallbackMap.put(klass, info);
mHasLifecycleMethods.put(klass, hasLifecycleMethods);
}
......
return info;
}
static class CallbackInfo {
final Map> mEventToHandlers;
final Map mHandlerToEvent;
CallbackInfo(Map handlerToEvent) {
mHandlerToEvent = handlerToEvent;
mEventToHandlers = new HashMap<>();
for (Map.Entry entry : handlerToEvent.entrySet()) {
androidx.lifecycle.Lifecycle.Event event = entry.getValue();
List methodReferences = mEventToHandlers.get(event);
if (methodReferences == null) {
methodReferences = new ArrayList<>();
mEventToHandlers.put(event, methodReferences);
}
methodReferences.add(entry.getKey());
}
}
@SuppressWarnings("ConstantConditions")
void invokeCallbacks(LifecycleOwner source, androidx.lifecycle.Lifecycle.Event event, Object target) {
invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target);
invokeMethodsForEvent(mEventToHandlers.get(androidx.lifecycle.Lifecycle.Event.ON_ANY), source, event,
target);
}
private static void invokeMethodsForEvent(List handlers,
LifecycleOwner source, androidx.lifecycle.Lifecycle.Event event, Object mWrapped) {
if (handlers != null) {
for (int i = handlers.size() - 1; i >= 0; i--) {
// 调用 MethodReference的 invokeCallback方法
handlers.get(i).invokeCallback(source, event, mWrapped);
}
}
}
}
// ClassesInfoCache.MethodReference
static class MethodReference {
final int mCallType;
final Method mMethod;
.......
void invokeCallback(LifecycleOwner source, androidx.lifecycle.Lifecycle.Event event, Object target) {
//noinspection TryWithIdenticalCatches
try {
switch (mCallType) {
case CALL_TYPE_NO_ARG:
mMethod.invoke(target);
break;
case CALL_TYPE_PROVIDER:
mMethod.invoke(target, source);
break;
case CALL_TYPE_PROVIDER_WITH_EVENT:
mMethod.invoke(target, source, event);
break;
}
} catch (InvocationTargetException e) {
throw new RuntimeException("Failed to call observer method", e.getCause());
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
}
}
}
时序图就不画了，大概写一下调用流程吧：
LifecycleRegistry.java
ReflectiveGenericLifecycleObserver .java
ClassesInfoCache.java
MethodReference.java
经过层层调用和包装，注册时最终会用反射将观察者带**@OnLifecycleEvent注解的方法保存在MethodReference中，并放入HashMap。当 Activity生命周期改变时，随着层层调用，最终保存在集合里的观察者LifecycleObserver**生命周期相关方法会被调用。
这波sao操作是不是又似曾相识？没错！EventBus也是这么管理订阅和发送事件的。
潜伏期值得思考 - 凯文 帕萨特
在第13章“高效绘图”中，我们研究了和Core Graphics绘图相关的性能问题，以及如何修复。和绘图性能相关紧密相关的是图像性能。在这一章中，我们将研究如何优化从闪存驱动器或者网络中加载和显示图片。
绘图实际消耗的时间通常并不是影响性能的因素。图片消耗很大一部分内存，而且不太可能把需要显示的图片都保留在内存中，所以需要在应用运行的时候周期性地加载和卸载图片。
图片文件加载的速度被CPU和IO（输入/输出）同时影响。iOS设备中的闪存已经比传统硬盘快很多了，但仍然比RAM慢将近200倍左右，这就需要很小心地管理加载，来避免延迟。
只要有可能，试着在程序生命周期不易察觉的时候来加载图片，例如启动，或者在屏幕切换的过程中。按下按钮和按钮响应事件之间最大的延迟大概是200ms，这比动画每一帧切换的16ms小得多。你可以在程序首次启动的时候加载图片，但是如果20秒内无法启动程序的话，iOS检测计时器就会终止你的应用（而且如果启动大于2，3秒的话用户就会抱怨了）。
有些时候，提前加载所有的东西并不明智。比如说包含上千张图片的图片传送带：用户希望能够能够平滑快速翻动图片，所以就不可能提前预加载所有图片；那样会消耗太多的时间和内存。
有时候图片也需要从远程网络连接中下载，这将会比从磁盘加载要消耗更多的时间，甚至可能由于连接问题而加载失败（在几秒钟尝试之后）。你不能够在主线程中加载网络造成等待，所以需要后台线程。
在第12章“性能调优”我们的联系人列表例子中，图片都非常小，所以可以在主线程同步加载。但是对于大图来说，这样做就不太合适了，因为加载会消耗很长时间，造成滑动的不流畅。滑动动画会在主线程的run loop中更新，所以会有更多运行在渲染服务进程中CPU相关的性能问题。
清单14.1显示了一个通过UICollectionView实现的基础的图片传送器。图片在主线程中-collectionView:cellForItemAtIndexPath:方法中同步加载（见图14.1）。
清单14.1 使用UICollectionView实现的图片传送器
#import "ViewController.h"
@interface ViewController()
@property (nonatomic, copy) NSArray *imagePaths;
@property (nonatomic, weak) IBOutlet UICollectionView *collectionView;
@end
@implementation ViewController
- (void)viewDidLoad
{
//set up data
self.imagePaths =
[[NSBundle mainBundle] pathsForResourcesOfType:@"png" inDirectory:@"Vacation Photos"];
//register cell class
[self.collectionView registerClass:[UICollectionViewCell class] forCellWithReuseIdentifier:@"Cell"];
}
- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
return [self.imagePaths count];
}
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView
cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
//dequeue cell
UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"Cell" forIndexPath:indexPath];
//add image view
const NSInteger imageTag = 99;
UIImageView *imageView = (UIImageView *)[cell viewWithTag:imageTag];
if (!imageView) {
imageView = [[UIImageView alloc] initWithFrame: cell.contentView.bounds];
imageView.tag = imageTag;
[cell.contentView addSubview:imageView];
}
//set image
NSString *imagePath = self.imagePaths[indexPath.row];
imageView.image = [UIImage imageWithContentsOfFile:imagePath];
return cell;
}
@end
图14.1 运行中的图片传送器
传送器中的图片尺寸为800x600像素的PNG，对iPhone5来说，1/60秒要加载大概700KB左右的图片。当传送器滚动的时候，图片也在实时加载，于是（预期中的）卡动就发生了。时间分析工具（图14.2）显示了很多时间都消耗在了UIImage的+imageWithContentsOfFile:方法中了。很明显，图片加载造成了瓶颈。
图14.2 时间分析工具展示了CPU瓶颈
这里提升性能唯一的方式就是在另一个线程中加载图片。这并不能够降低实际的加载时间（可能情况会更糟，因为系统可能要消耗CPU时间来处理加载的图片数据），但是主线程能够有时间做一些别的事情，比如响应用户输入，以及滑动动画。
为了在后台线程加载图片，我们可以使用GCD或者NSOperationQueue创建自定义线程，或者使用CATiledLayer。为了从远程网络加载图片，我们可以使用异步的NSURLConnection，但是对本地存储的图片，并不十分有效。
NSOperationQueue GCD（Grand Central Dispatch）和NSOperationQueue很类似，都给我们提供了队列闭包块来在线程中按一定顺序来执行。NSOperationQueue有一个Objecive-C接口（而不是使用GCD的全局C函数），同样在操作优先级和依赖关系上提供了很好的粒度控制，但是需要更多地设置代码。
清单14.2显示了在低优先级的后台队列而不是主线程使用GCD加载图片的-collectionView:cellForItemAtIndexPath:方法，然后当需要加载图片到视图的时候切换到主线程，因为在后台线程访问视图会有安全隐患。
由于视图在UICollectionView会被循环利用，我们加载图片的时候不能确定是否被不同的索引重新复用。为了避免图片加载到错误的视图中，我们在加载前把单元格打上索引的标签，然后在设置图片的时候检测标签是否发生了改变。
清单14.2 使用GCD加载传送图片
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView
cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
//dequeue cell
UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"Cell"
forIndexPath:indexPath];
//add image view
const NSInteger imageTag = 99;
UIImageView *imageView = (UIImageView *)[cell viewWithTag:imageTag];
if (!imageView) {
imageView = [[UIImageView alloc] initWithFrame: cell.contentView.bounds];
imageView.tag = imageTag;
[cell.contentView addSubview:imageView];
}
//tag cell with index and clear current image
cell.tag = indexPath.row;
imageView.image = nil;
//switch to background thread
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
//load image
NSInteger index = indexPath.row;
NSString *imagePath = self.imagePaths[index];
UIImage *image = [UIImage imageWithContentsOfFile:imagePath];
//set image on main thread, but only if index still matches up
dispatch_async(dispatch_get_main_queue(), ^{
if (index == cell.tag) {
imageView.image = image; }
});
});
return cell;
}
当运行更新后的版本，性能比之前不用线程的版本好多了，但仍然并不完美（图14.3）。
我们可以看到+imageWithContentsOfFile:方法并不在CPU时间轨迹的最顶部，所以我们的确修复了延迟加载的问题。问题在于我们假设传送器的性能瓶颈在于图片文件的加载，但实际上并不是这样。加载图片数据到内存中只是问题的第一部分。
图14.3 使用后台线程加载图片来提升性能
一旦图片文件被加载就必须要进行解码，解码过程是一个相当复杂的任务，需要消耗非常长的时间。解码后的图片将同样使用相当大的内存。
用于加载的CPU时间相对于解码来说根据图片格式而不同。对于PNG图片来说，加载会比JPEG更长，因为文件可能更大，但是解码会相对较快，而且Xcode会把PNG图片进行解码优化之后引入工程。JPEG图片更小，加载更快，但是解压的步骤要消耗更长的时间，因为JPEG解压算法比基于zip的PNG算法更加复杂。
当加载图片的时候，iOS通常会延迟解压图片的时间，直到加载到内存之后。这就会在准备绘制图片的时候影响性能，因为需要在绘制之前进行解压（通常是消耗时间的问题所在）。
最简单的方法就是使用UIImage的+imageNamed:方法避免延时加载。不像+imageWithContentsOfFile:（和其他别的UIImage加载方法），这个方法会在加载图片之后立刻进行解压（就和本章之前我们谈到的好处一样）。问题在于+imageNamed:只对从应用资源束中的图片有效，所以对用户生成的图片内容或者是下载的图片就没法使用了。
另一种立刻加载图片的方法就是把它设置成图层内容，或者是UIImageView的image属性。不幸的是，这又需要在主线程执行，所以不会对性能有所提升。
第三种方式就是绕过UIKit，像下面这样使用ImageIO框架：
NSInteger index = indexPath.row;
NSURL *imageURL = [NSURL fileURLWithPath:self.imagePaths[index]];
NSDictionary *options = @{(__bridge id)kCGImageSourceShouldCache: @YES};
CGImageSourceRef source = CGImageSourceCreateWithURL((__bridge CFURLRef)imageURL, NULL);
CGImageRef imageRef = CGImageSourceCreateImageAtIndex(source, 0,(__bridge CFDictionaryRef)options);
UIImage *image = [UIImage imageWithCGImage:imageRef];
CGImageRelease(imageRef);
CFRelease(source);
这样就可以使用kCGImageSourceShouldCache来创建图片，强制图片立刻解压，然后在图片的生命周期保留解压后的版本。
最后一种方式就是使用UIKit加载图片，但是立刻会知道CGContext中去。图片必须要在绘制之前解压，所以就强制了解压的及时性。这样的好处在于绘制图片可以再后台线程（例如加载本身）执行，而不会阻塞UI。
有两种方式可以为强制解压提前渲染图片：
将图片的一个像素绘制成一个像素大小的CGContext。这样仍然会解压整张图片，但是绘制本身并没有消耗任何时间。这样的好处在于加载的图片并不会在特定的设备上为绘制做优化，所以可以在任何时间点绘制出来。同样iOS也就可以丢弃解压后的图片来节省内存了。
将整张图片绘制到CGContext中，丢弃原始的图片，并且用一个从上下文内容中新的图片来代替。这样比绘制单一像素那样需要更加复杂的计算，但是因此产生的图片将会为绘制做优化，而且由于原始压缩图片被抛弃了，iOS就不能够随时丢弃任何解压后的图片来节省内存了。
需要注意的是苹果特别推荐了不要使用这些诡计来绕过标准图片解压逻辑（所以也是他们选择用默认处理方式的原因），但是如果你使用很多大图来构建应用，那如果想提升性能，就只能和系统博弈了。
如果不使用+imageNamed:，那么把整张图片绘制到CGContext可能是最佳的方式了。尽管你可能认为多余的绘制相较别的解压技术而言性能不是很高，但是新创建的图片（在特定的设备上做过优化）可能比原始图片绘制的更快。
同样，如果想显示图片到比原始尺寸小的容器中，那么一次性在后台线程重新绘制到正确的尺寸会比每次显示的时候都做缩放会更有效（尽管在这个例子中我们加载的图片呈现正确的尺寸，所以不需要多余的优化）。
如果修改了-collectionView:cellForItemAtIndexPath:方法来重绘图片（清单14.3），你会发现滑动更加平滑。
清单14.3 强制图片解压显示
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView
cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
//dequeue cell
UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"Cell" forIndexPath:indexPath];
...
//switch to background thread
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
//load image
NSInteger index = indexPath.row;
NSString *imagePath = self.imagePaths[index];
UIImage *image = [UIImage imageWithContentsOfFile:imagePath];
//redraw image using device context
UIGraphicsBeginImageContextWithOptions(imageView.bounds.size, YES, 0);
[image drawInRect:imageView.bounds];
image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
//set image on main thread, but only if index still matches up
dispatch_async(dispatch_get_main_queue(), ^{
if (index == cell.tag) {
imageView.image = image;
}
});
});
return cell;
}
CATiledLayer 如第6章“专用图层”中的例子所示，CATiledLayer可以用来异步加载和显示大型图片，而不阻塞用户输入。但是我们同样可以使用CATiledLayer在UICollectionView中为每个表格创建分离的CATiledLayer实例加载传动器图片，每个表格仅使用一个图层。
这样使用CATiledLayer有几个潜在的弊端：
CATiledLayer的队列和缓存算法没有暴露出来，所以我们只能祈祷它能匹配我们的需求
CATiledLayer需要我们每次重绘图片到CGContext中，即使它已经解压缩，而且和我们单元格尺寸一样（因此可以直接用作图层内容，而不需要重绘）。
我们来看看这些弊端有没有造成不同：清单14.4显示了使用CATiledLayer对图片传送器的重新实现。
清单14.4 使用CATiledLayer的图片传送器
#import "ViewController.h"
#import
@interface ViewController()
@property (nonatomic, copy) NSArray *imagePaths;
@property (nonatomic, weak) IBOutlet UICollectionView *collectionView;
@end
@implementation ViewController
- (void)viewDidLoad
{
//set up data
self.imagePaths = [[NSBundle mainBundle] pathsForResourcesOfType:@"jpg" inDirectory:@"Vacation Photos"];
[self.collectionView registerClass:[UICollectionViewCell class] forCellWithReuseIdentifier:@"Cell"];
}
- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
return [self.imagePaths count];
}
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
//dequeue cell
UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:@"Cell" forIndexPath:indexPath];
//add the tiled layer
CATiledLayer *tileLayer = [cell.contentView.layer.sublayers lastObject];
if (!tileLayer) {
tileLayer = [CATiledLayer layer];
tileLayer.frame = cell.bounds;
tileLayer.contentsScale = [UIScreen mainScreen].scale;
tileLayer.tileSize = CGSizeMake(cell.bounds.size.width * [UIScreen mainScreen].scale, cell.bounds.size.height * [UIScreen mainScreen].scale);
tileLayer.delegate = self;
[tileLayer setValue:@(indexPath.row) forKey:@"index"];
[cell.contentView.layer addSublayer:tileLayer];
}
//tag the layer with the correct index and reload
tileLayer.contents = nil;
[tileLayer setValue:@(indexPath.row) forKey:@"index"];
[tileLayer setNeedsDisplay];
return cell;
}
- (void)drawLayer:(CATiledLayer *)layer inContext:(CGContextRef)ctx
{
//get image index
NSInteger index = [[layer valueForKey:@"index"] integerValue];
//load tile image
NSString *imagePath = self.imagePaths[index];
UIImage *tileImage = [UIImage imageWithContentsOfFile:imagePath];
//calculate image rect
CGFloat aspectRatio = tileImage.size.height / tileImage.size.width;
CGRect imageRect = CGRectZero;
imageRect.size.width = layer.bounds.size.width;
imageRect.size.height = layer.bounds.size.height * aspectRatio;
imageRect.origin.y = (layer.bounds.size.height - imageRect.size.height)/2;
//draw tile
UIGraphicsPushContext(ctx);
[tileImage drawInRect:imageRect];
UIGraphicsPopContext();
}
@end
需要解释几点：
CATiledLayer的tileSize属性单位是像素，而不是点，所以为了保证瓦片和表格尺寸一致，需要乘以屏幕比例因子。
在-drawLayer:inContext:方法中，我们需要知道图层属于哪一个indexPath以加载正确的图片。这里我们利用了CALayer的KVC来存储和检索任意的值，将图层和索引打标签。
结果CATiledLayer工作的很好，性能问题解决了，而且和用GCD实现的代码量差不多。仅有一个问题在于图片加载到屏幕上后有一个明显的淡入（图14.4）。
图14.4 加载图片之后的淡入
我们可以调整CATiledLayer的fadeDuration属性来调整淡入的速度，或者直接将整个渐变移除，但是这并没有根本性地去除问题：在图片加载到准备绘制的时候总会有一个延迟，这将会导致滑动时候新图片的跳入。这并不是CATiledLayer的问题，使用GCD的版本也有这个问题。
即使使用上述我们讨论的所有加载图片和缓存的技术，有时候仍然会发现实时加载大图还是有问题。就和13章中提到的那样，iPad上一整个视网膜屏图片分辨率达到了2048x1536，而且会消耗12MB的RAM（未压缩）。第三代iPad的硬件并不能支持1/60秒的帧率加载，解压和显示这种图片。即使用后台线程加载来避免动画卡顿，仍然解决不了问题。
我们可以在加载的同时显示一个占位图片，但这并没有根本解决问题，我们可以做到更好。
视网膜分辨率（根据苹果市场定义）代表了人的肉眼在正常视角距离能够分辨的最小像素尺寸。但是这只能应用于静态像素。当观察一个移动图片时，你的眼睛就会对细节不敏感，于是一个低分辨率的图片和视网膜质量的图片没什么区别了。
如果需要快速加载和显示移动大图，简单的办法就是欺骗人眼，在移动传送器的时候显示一个小图（或者低分辨率），然后当停止的时候再换成大图。这意味着我们需要对每张图片存储两份不同分辨率的副本，但是幸运的是，由于需要同时支持Retina和非Retina设备，本来这就是普遍要做到的。
如果从远程源或者用户的相册加载没有可用的低分辨率版本图片，那就可以动态将大图绘制到较小的CGContext，然后存储到某处以备复用。
为了做到图片交换，我们需要利用UIScrollView的一些实现UIScrollViewDelegate协议的委托方法（和其他类似于UITableView和UICollectionView基于滚动视图的控件一样）：
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate;
- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView;
你可以使用这几个方法来检测传送器是否停止滚动，然后加载高分辨率的图片。只要高分辨率图片和低分辨率图片尺寸颜色保持一致，你会很难察觉到替换的过程（确保在同一台机器使用相同的图像程序或者脚本生成这些图片）。
收起阅读 »UIKit的单线程天性意味着寄宿图通畅要在主线程上更新，这意味着绘制会打断用户交互，甚至让整个app看起来处于无响应状态。我们对此无能为力，但是如果能避免用户等待绘制完成就好多了。
针对这个问题，有一些方法可以用到：一些情况下，我们可以推测性地提前在另外一个线程上绘制内容，然后将由此绘出的图片直接设置为图层的内容。这实现起来可能不是很方便，但是在特定情况下是可行的。Core Animation提供了一些选择：CATiledLayer和drawsAsynchronously属性。
我们在第六章简单探索了一下CATiledLayer。除了将图层再次分割成独立更新的小块（类似于脏矩形自动更新的概念），CATiledLayer还有一个有趣的特性：在多个线程中为每个小块同时调用-drawLayer:inContext:方法。这就避免了阻塞用户交互而且能够利用多核心新片来更快地绘制。只有一个小块的CATiledLayer是实现异步更新图片视图的简单方法。
iOS 6中，苹果为CALayer引入了这个令人好奇的属性，drawsAsynchronously属性对传入-drawLayer:inContext:的CGContext进行改动，允许CGContext延缓绘制命令的执行以至于不阻塞用户交互。
它与CATiledLayer使用的异步绘制并不相同。它自己的-drawLayer:inContext:方法只会在主线程调用，但是CGContext并不等待每个绘制命令的结束。相反地，它会将命令加入队列，当方法返回时，在后台线程逐个执行真正的绘制。
根据苹果的说法。这个特性在需要频繁重绘的视图上效果最好（比如我们的绘图应用，或者诸如UITableViewCell之类的），对那些只绘制一次或很少重绘的图层内容来说没什么太大的帮助。
本章我们主要围绕用Core Graphics软件绘制讨论了一些性能挑战，然后探索了一些改进方法：比如提高绘制性能或者减少需要绘制的数量。
第14章，『图像IO』，我们将讨论图片的载入性能。
收起阅读 » 有时候用CAShapeLayer或者其他矢量图形图层替代Core Graphics并不是那么切实可行。比如我们的绘图应用：我们用线条完美地完成了矢量绘制。但是设想一下如果我们能进一步提高应用的性能，让它就像一个黑板一样工作，然后用『粉笔』来绘制线条。模拟粉笔最简单的方法就是用一个『线刷』图片然后将它粘贴到用户手指碰触的地方，但是这个方法用CAShapeLayer没办法实现。
我们可以给每个『线刷』创建一个独立的图层，但是实现起来有很大的问题。屏幕上允许同时出现图层上线数量大约是几百，那样我们很快就会超出的。这种情况下我们没什么办法，就用Core Graphics吧（除非你想用OpenGL做一些更复杂的事情）。
我们的『黑板』应用的最初实现见清单13.3，我们更改了之前版本的DrawingView，用一个画刷位置的数组代替UIBezierPath。图13.2是运行结果
清单13.3 简单的类似黑板的应用
#import "DrawingView.h"
#import
#define BRUSH_SIZE 32
@interface DrawingView ()
@property (nonatomic, strong) NSMutableArray *strokes;
@end
@implementation DrawingView
- (void)awakeFromNib
{
//create array
self.strokes = [NSMutableArray array];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the starting point
CGPoint point = [[touches anyObject] locationInView:self];
//add brush stroke
[self addBrushStrokeAtPoint:point];
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the touch point
CGPoint point = [[touches anyObject] locationInView:self];
//add brush stroke
[self addBrushStrokeAtPoint:point];
}
- (void)addBrushStrokeAtPoint:(CGPoint)point
{
//add brush stroke to array
[self.strokes addObject:[NSValue valueWithCGPoint:point]];
//needs redraw
[self setNeedsDisplay];
}
- (void)drawRect:(CGRect)rect
{
//redraw strokes
for (NSValue *value in self.strokes) {
//get point
CGPoint point = [value CGPointValue];
//get brush rect
CGRect brushRect = CGRectMake(point.x - BRUSH_SIZE/2, point.y - BRUSH_SIZE/2, BRUSH_SIZE, BRUSH_SIZE);
//draw brush stroke 
[[UIImage imageNamed:@"Chalk.png"] drawInRect:brushRect];
}
}
@end
图13.2 用程序绘制一个简单的『素描』
这个实现在模拟器上表现还不错，但是在真实设备上就没那么好了。问题在于每次手指移动的时候我们就会重绘之前的线刷，即使场景的大部分并没有改变。我们绘制地越多，就会越慢。随着时间的增加每次重绘需要更多的时间，帧数也会下降（见图13.3），如何提高性能呢？
图13.3 帧率和线条质量会随时间下降。
为了减少不必要的绘制，Mac OS和iOS设备将会把屏幕区分为需要重绘的区域和不需要重绘的区域。那些需要重绘的部分被称作『脏区域』。在实际应用中，鉴于非矩形区域边界裁剪和混合的复杂性，通常会区分出包含指定视图的矩形位置，而这个位置就是『脏矩形』。
当一个视图被改动过了，TA可能需要重绘。但是很多情况下，只是这个视图的一部分被改变了，所以重绘整个寄宿图就太浪费了。但是Core Animation通常并不了解你的自定义绘图代码，它也不能自己计算出脏区域的位置。然而，你的确可以提供这些信息。
当你检测到指定视图或图层的指定部分需要被重绘，你直接调用-setNeedsDisplayInRect:来标记它，然后将影响到的矩形作为参数传入。这样就会在一次视图刷新时调用视图的-drawRect:（或图层代理的-drawLayer:inContext:方法）。
传入-drawLayer:inContext:的CGContext参数会自动被裁切以适应对应的矩形。为了确定矩形的尺寸大小，你可以用CGContextGetClipBoundingBox()方法来从上下文获得大小。调用-drawRect()会更简单，因为CGRect会作为参数直接传入。
你应该将你的绘制工作限制在这个矩形中。任何在此区域之外的绘制都将被自动无视，但是这样CPU花在计算和抛弃上的时间就浪费了，实在是太不值得了。
相比依赖于Core Graphics为你重绘，裁剪出自己的绘制区域可能会让你避免不必要的操作。那就是说，如果你的裁剪逻辑相当复杂，那还是让Core Graphics来代劳吧，记住：当你能高效完成的时候才这样做。
清单13.4 展示了一个-addBrushStrokeAtPoint:方法的升级版，它只重绘当前线刷的附近区域。另外也会刷新之前线刷的附近区域，我们也可以用CGRectIntersectsRect()来避免重绘任何旧的线刷以不至于覆盖已更新过的区域。这样做会显著地提高绘制效率（见图13.4）
清单13.4 用-setNeedsDisplayInRect:来减少不必要的绘制
- (void)addBrushStrokeAtPoint:(CGPoint)point
{
//add brush stroke to array
[self.strokes addObject:[NSValue valueWithCGPoint:point]];
//set dirty rect
[self setNeedsDisplayInRect:[self brushRectForPoint:point]];
}
- (CGRect)brushRectForPoint:(CGPoint)point
{
return CGRectMake(point.x - BRUSH_SIZE/2, point.y - BRUSH_SIZE/2, BRUSH_SIZE, BRUSH_SIZE);
}
- (void)drawRect:(CGRect)rect
{
//redraw strokes
for (NSValue *value in self.strokes) {
//get point
CGPoint point = [value CGPointValue];
//get brush rect
CGRect brushRect = [self brushRectForPoint:point];

//only draw brush stroke if it intersects dirty rect
if (CGRectIntersectsRect(rect, brushRect)) {
//draw brush stroke
[[UIImage imageNamed:@"Chalk.png"] drawInRect:brushRect];
}
}
}
图13.4 更好的帧率和顺滑线条
收起阅读 »
大力智能客户端团队 西豢沝尔
Rust优秀的安全性、媲美C++的性能以及对跨平台编译和外部语言（ffi）的支持使得其成为高性能跨平台库的上佳实现语言。然而，Rust是否可以在逻辑层之上进一步服务于一些通用性的UI渲染？我们大力智能客户端团队针对开源项目rust-windowing（ github.com/rust-window… ）中几个核心工程进行剖析，并结合在Android系统的接入对此进行探索。
Android系统上使用Rust渲染核心围绕ANativeWindow类展开，ANativeWindow位于android ndk中，是egl跨平台EGLNativeWindowType窗口类型在Android架构下的特定实现，因而基于ANativeWindow就可以创建一个EglSurface并通过GLES进行绘制和渲染。另一方面，ANativeWindow可以简单地与Java层的Surface相对应，因而将Android层需要绘制的目标转换为ANativeWindow是使用Rust渲染的关键，这一部分可以通过JNI完成。首先，我们先看一下rust-windowing对UI渲染的支持。
在rust-windowing项目中，android-ndk-rs提供了rust与android ndk之间的胶水层，其中与UI渲染最相关的就是NativeWindow类，NativeWindow在Rust上下文实现了对ANativeWindow的封装，支持通过ffi对ANativeWindow进行操作，达到与在java层使用lockCanvas()和unlockCanvasAndPost()进行绘制相同的效果，基于这些api，我们可以实现在(A)NativeWindow上的指定区域绘制一个长方形：
unsafe fn draw_rect_on_window(nativewindow: &NativeWindow, colors: Vec<u8>, rect: ndk_glue::Rect) {
let height = nativewindow.height();
let width = nativewindow.width();
let color_format = get_color_format();
let format = color_format.0;
let bbp = color_format.1;
nativewindow.set_buffers_geometry(width, height, format);
nativewindow.acquire();
let mut buffer = NativeWindow::generate_epmty_buffer(width, height, width, format);
let locked = nativewindow.lock(&mut buffer, &mut NativeWindow::generate_empty_rect(0, 0, width, height));
if locked < 0 {
nativewindow.release();
return;
}
draw_rect_into_buffer(buffer.bits, colors, rect, width, height);
let result = nativewindow.unlock_and_post();
nativewindow.release();
}
unsafe fn draw_rect_into_buffer(bits: *mut ::std::os::raw::c_void, colors: Vec<u8>, rect: ndk_glue::Rect, window_width: i32, window_height: i32) {
let bbp = colors.len() as u32;
let window_width = window_width as u32;
for i in rect.top+1..=rect.bottom {
for j in rect.left+1..=rect.right {
let cur = (j + (i-1) * window_width - 1) * bbp;
for k in 0..bbp {
*(bits.offset((cur + (k as u32)) as isize) as *mut u8) = colors[k as usize];
}
}
}
}
这样就通过提交一个纯色像素填充的Buffer在指定的位置成功渲染出了一个长方形，不过这种方式本质上是软件绘制，性能欠佳，更好的方式是通过在Rust层封装GL在ANativeWindow上使能硬件绘制。
窗口系统最主要的目的是提供平台无关的Window抽象，提供一系列通用的基础方法、属性方法、游标相关方法、监控方法。winit以Window类抽象窗口类型并持有平台相关的window实现，通过WindowId唯一识别一个Window用于匹配后续产生的所有窗口事件WindowEvent，最后通过建造者模式对外暴露实例化的能力，支持在Rust侧设置一些平台无关的参数（大小、位置、标题、是否可见等）以及平台相关的特定参数，基本结构如下：
// src/window.rs
pub struct Window {
pub(crate) window: platform_impl::Window,
}
impl Window {
#[inline]
pub fn request_redraw(&self) {
self.window.request_redraw()
}
pub fn inner_position(&self) -> Result<PhysicalPosition<i32>, NotSupportedError> {
self.window.inner_position()
}
pub fn current_monitor(&self) -> Option<MonitorHandle> {
self.window.current_monitor()
}
}
pub struct WindowId(pub(crate) platform_impl::WindowId);
pub struct WindowBuilder {
/// The attributes to use to create the window.
pub window: WindowAttributes,
// Platform-specific configuration.
pub(crate) platform_specific: platform_impl::PlatformSpecificWindowBuilderAttributes,
}
impl WindowBuilder {
#[inline]
pub fn build<T: 'static>(
self,
window_target: &EventLoopWindowTarget<T>,
) -> Result<Window, OsError> {
platform_impl::Window::new(&window_target.p, self.window, self.platform_specific).map(
|window| {
window.request_redraw();
Window { window }
},
)
}
}
在Android平台，winit暂时不支持使用给定的属性构建一个“Window”，大部分方法给出了空实现或者直接panic，仅保留了一些事件循环相关的能力，真正的窗口实现仍然从android-ndk-rs胶水层获得：当前的android-ndk-rs仅针对ANativeActivity进行了适配，通过属性宏代理了unsafe extern "C" fn ANativeActivity_onCreate(...)方法，在获得ANativeActivity指针*activity后，注入自定义的生命周期回调，在onNativeWindowCreated回调中获得ANativeWindow（封装为NativeWindow）作为当前上下文活跃的窗口。当然，android-ndk-rs的能力也支持我们在任意一个ANativeWindow上生成对应的上层窗口。
事件循环是整个窗口系统行为的驱动，统一响应抛出的系统任务和用户交互并将反馈渲染到窗口上形成闭环，当你需要合理地触发渲染时，最好的方式就是将指令发送给事件循环。winit中，将事件循环封装为EventLoop，使用ControlFlow控制EventLoop如何获取、消费循环中的事件，并对外提供一个EventLoopProxy代理用于作为与用户交互的媒介，支持用户通过proxy向EventLoop发送用户自定义的事件：
Android平台的事件循环建立在ALooper之上，通过android-ndk-rs提供的胶水层注入的回调处理生命周期行为和窗口行为，通过代理InputQueue处理用户手势，同时支持响应用户自定义事件和内部事件。一次典型的循环根据当前first_event的类型分发处理，一次处理一个主要事件；当first_event处理完成后，触发一次MainEventsCleared事件回调给业务方，并判断是否需要触发Resized和RedrawRequested，最后触发RedrawEventsCleared事件标识所有事件处理完毕。
单次循环处理完所有事件后进入控制流，决定下一次处理事件的行为，控制流支持Android epoll多路复用，在必要时唤醒循环处理后续事件，此外，控制流提供了强制执行、强制退出的能力。事实上，android-ndk-rs就是通过添加fd的方式将窗口行为抛到EventLoop中包装成Callback事件处理：
PIPE: [RawFd; 2]，并把读端加到ALooper中，指定标识符为NDK_GLUE_LOOPER_EVENT_PIPE_IDENT；// <--1--> 挂载fd
// ndk-glue/src/lib.rs
lazy_static! {
static ref PIPE: [RawFd; 2] = {
let mut pipe: [RawFd; 2] = Default::default();
unsafe { libc::pipe(pipe.as_mut_ptr()) };
pipe
};
}
{
...
thread::spawn(move || {
let looper = ThreadLooper::prepare();
let foreign = looper.into_foreign();
foreign
.add_fd(
PIPE[0],
NDK_GLUE_LOOPER_EVENT_PIPE_IDENT,
FdEvent::INPUT,
std::ptr::null_mut(),
)
.unwrap();
});
...
}
// <--2--> 向fd写入数据
// ndk-glue/src/lib.rs
unsafe fn wake(_activity: *mut ANativeActivity, event: Event) {
log::trace!("{:?}", event);
let size = std::mem::size_of::<Event>();
let res = libc::write(PIPE[1], &event as *const _ as *const _, size);
assert_eq!(res, size as _);
}
// <--3--> 唤醒事件循环读出事件
// src/platform_impl/android/mod.rs
fn poll(poll: Poll) -> Option<EventSource> {
match poll {
Poll::Event { ident, .. } => match ident {
ndk_glue::NDK_GLUE_LOOPER_EVENT_PIPE_IDENT => Some(EventSource::Callback),
...
},
...
}
}
// ndk-glue/src/lib.rs
pub fn poll_events() -> Option<Event> {
unsafe {
let size = std::mem::size_of::<Event>();
let mut event = Event::Start;
if libc::read(PIPE[0], &mut event as *mut _ as *mut _, size) == size as _ {
Some(event)
} else {
None
}
}
}
我们有了跨平台的OpenGL(ES)用于描述图形对象，也有了跨平台的窗口系统winit封装窗口行为，但是如何理解图形语言并将其渲染到各个平台的窗口上？这就是egl发挥的作用，它实现了OpenGL(ES)和底层窗口系统之间的接口层。在rust-windowing项目中，glutin工程承接了这个职责，以上下文的形式把窗口系统winit和gl关联了起来。
Context是gl的上下文环境，全局可以有多个gl上下文，但是一个线程同时只能有一个活跃的上下文，使用ContextCurrentState区分这一状态。glutin中Context可关联零个或多个Window，当Context与Window相关联时，使用ContextWrapper类，ContextWrapper使得可以方便地在上下文中同时操作gl绘制以及Window渲染。在其上衍生出两个类型：（1）RawContext：Context与Window虽然关联但是分开存储；（2）WindowedContext：同时存放相互关联的一组Context和Window。常见的场景下WindowedContext更加适用，通过ContextBuilder指定所需的gl属性和像素格式就可以构造一个WindowedContext，内部会初始化egl上下文，并基于持有的EglSurfaceType类型的window创建一个eglsurface作为后续gl指令绘制（draw）、回读（read）的作用目标（指定使用该surface上的缓冲）。
基于winit和glutin提供的能力，使用Rust进行渲染的准备工作只需基于特定业务需求去创建一个glutin的Context，通过Context中创建的egl上下文可以调用gl api进行绘制，而window让我们可以掌控渲染流程，在需要的时候（比如基于EventLoop重绘指令或者一个简单的无限循环）下发绘制指令。简单地实现文章开头的三角形demo动画效果如下：
fn render(&mut self, gl: &Gl) {
let time_elapsed = self.startTime.elapsed().as_millis();
let percent = (time_elapsed % 5000) as f32 / 5000f32;
let angle = percent * 2f32 * std::f32::consts::PI;
unsafe {
let vs = gl.CreateShader(gl::VERTEX_SHADER);
gl.ShaderSource(vs, 1, [VS_SRC.as_ptr() as *const _].as_ptr(), std::ptr::null());
gl.CompileShader(vs);
let fs = gl.CreateShader(gl::FRAGMENT_SHADER);
gl.ShaderSource(fs, 1, [FS_SRC.as_ptr() as *const _].as_ptr(), std::ptr::null());
gl.CompileShader(fs);
let program = gl.CreateProgram();
gl.AttachShader(program, vs);
gl.AttachShader(program, fs);
gl.LinkProgram(program);
gl.UseProgram(program);
gl.DeleteShader(vs);
gl.DeleteShader(fs);
let mut vb = std::mem::zeroed();
gl.GenBuffers(1, &mut vb);
gl.BindBuffer(gl::ARRAY_BUFFER, vb);
let vertex = [
SIDE_LEN * (BASE_V_LEFT+angle).cos(), SIDE_LEN * (BASE_V_LEFT+angle).sin(), 0.0, 0.4, 0.0,
SIDE_LEN * (BASE_V_TOP+angle).cos(), SIDE_LEN * (BASE_V_TOP+angle).sin(), 0.0, 0.4, 0.0,
SIDE_LEN * (BASE_V_RIGHT+angle).cos(), SIDE_LEN * (BASE_V_RIGHT+angle).sin(), 0.0, 0.4, 0.0,
];
gl.BufferData(
gl::ARRAY_BUFFER,
(vertex.len() * std::mem::size_of::<f32>()) as gl::types::GLsizeiptr,
vertex.as_ptr() as *const _,
gl::STATIC_DRAW,
);
if gl.BindVertexArray.is_loaded() {
let mut vao = std::mem::zeroed();
gl.GenVertexArrays(1, &mut vao);
gl.BindVertexArray(vao);
}
let pos_attrib = gl.GetAttribLocation(program, b"position\0".as_ptr() as *const _);
let color_attrib = gl.GetAttribLocation(program, b"color\0".as_ptr() as *const _);
gl.VertexAttribPointer(
pos_attrib as gl::types::GLuint,
2,
gl::FLOAT,
0,
5 * std::mem::size_of::<f32>() as gl::types::GLsizei,
std::ptr::null(),
);
gl.VertexAttribPointer(
color_attrib as gl::types::GLuint,
3,
gl::FLOAT,
0,
5 * std::mem::size_of::<f32>() as gl::types::GLsizei,
(2 * std::mem::size_of::<f32>()) as *const () as *const _,
);
gl.EnableVertexAttribArray(pos_attrib as gl::types::GLuint);
gl.EnableVertexAttribArray(color_attrib as gl::types::GLuint);
gl.ClearColor(1.3 * (percent-0.5).abs(), 0., 1.3 * (0.5 - percent).abs(), 1.0);
gl.Clear(gl::COLOR_BUFFER_BIT);
gl.DrawArrays(gl::TRIANGLES, 0, 3);
}
}
以上Rust UI渲染部分完全运行在Rust上下文中（包括对c++的封装），而实际渲染场景下很难完全脱离Android层进行UI的渲染或不与Activity等容器进行交互。所幸Rust UI渲染主要基于(A)NativeWindow，而Android Surface在c++的对应类实现了ANativeWindow，ndk也提供了ANativeWindow_fromSurface方法从一个surface获得ANativeWindow对象，因而我们可以通过JNI的方式使用Rust在Android层的Surface上进行UI渲染：
// Android
surface_view.holder.addCallback(object : SurfaceHolder.Callback2 {
override fun surfaceCreated(p0: SurfaceHolder) {
RustUtils.drawColorTriangle(surface, Color.RED)
}
override fun surfaceChanged(p0: SurfaceHolder, p1: Int, p2: Int, p3: Int) {}
override fun surfaceDestroyed(p0: SurfaceHolder) {}
override fun surfaceRedrawNeeded(p0: SurfaceHolder) {}
})
// Rust
pub unsafe extern fn Java_com_example_rust_1demo_RustUtils_drawColorTriangle__Landroid_view_Surface_2I(env: *mut JNIEnv, _: JClass, surface: jobject, color: jint) -> jboolean {
println!("call Java_com_example_rust_1demo_RustUtils_drawColor__Landroid_view_Surface_2I");
ndk_glue::set_native_window(NativeWindow::from_surface(env, surface));
runner::start();
0
}
需要注意，由于EventLoop是基于ALooper的封装，调用Rust实现渲染时需要确保调用在有Looper的线程（比如HandlerThread中），或者在Rust渲染前初始化时为当前线程准备ALooper。
使用Rust在Android上进行UI渲染的可行性已经得证，但是它的性能表现究竟如何？未来又将在哪些业务上落地？这些仍待进一步探索。
收起阅读 »目前有这样一个需求:
首先肯定是可以做的:
三流程序员看到这里已经去写代码了...
二流以上程序员接着往下看。
首先，第1条没问题。
第2条，需要在item对应的数据里面添加一个倒计时组件，这听着就不对，倒计时组件明明是用来更新UI的，应该是UI持有，现在让数据持有，那不就等价于数据间接持有了UI吗，长生命周期持有短生命周期了，不行。而且，数据多的时候，比如10w条数据，就有10w个倒计时组件，cpu不吃不喝也忙不过来(cpu:wqnmlgb)！这明显属于量变引起质变的问题，为了避免这个问题，我们需要将倒计时组件常量化，也就是: 只有常数个倒计时，从而让倒计时组件的个数，不受数据数量的影响。
那么，我们怎么定义这个常量呢？
我们考虑到倒计时是用来更新UI的，那么屏幕内可见的item有多少个，就创建多少个 倒计时组件 不就行了吗，反正屏幕外的，别人也看不见，所以我们可以让ViewHolder持有倒计时组件，而且正好可以利用RecyclerView对ViewHolder的复用机制。
但是，如果让ViewHolder持有，当ViewHolder滑出屏幕外，就会回收，那么倒计时就终止了，此时就无法触发倒计时结束的删除操作，因为即使在屏幕外，只要触发了倒计时的删除数据，我们屏幕内的数据就会向上滑动一个位置，是可以感知的，所以，如果滑出屏幕后，倒计时终止了，就无法触发删除，那么我们可能等了很久，也没发现屏幕内的数据向上滑动，明显是不对的。
程序是为用户服务的，根据以上分析，我们只站在用户角度来考虑:
此乃死锁，无法解决！那么就需要退一步来改下需求了。既然无法完美解决用户的问题，我们就来改变用户的习惯，我们让：倒计时结束后，不再删除item，只是置灰。
为什么这么改呢？因为针对case1，我们没法解决，只能从case2入手，而case2的问题就是: 用户无法感知到删除操作，那我就不删除了，这样你也不用感知了，只置灰即可。
好，第二条解决。
第3条，没啥问题，直接remove(index)，然后调用adapter.notifyItemRemoved()完事。
第4条，也没啥问题，可以if-else/switch-case，根据不同的type返回不同的ViewHolder。但是可以写的更好点，就是使用工厂模式。
可行性分析和需求分析完了后，我们就开始进行概要设计了。
这里面有几点需要注意:
好，分析结束，开始撸码。
首先，我们先定义数据实体:
// 注意这里的terminalTime，指的指终止时间，不是时间差，是一个时间值。
// type可以理解为ViewType，当然中间有对应关系的
data class BaseItemBean(val id: Long, var terminalTime: Long, val type: Int)
很简单的一行代码，是个Bean对象，直接上data class即可。
然后，我们来定义两个ViewHolder，因为有相同布局，我们可以直接用继承关系:
// 基础ViewHolder
open inner class BaseVH(itemView: View) : RecyclerView.ViewHolder(itemView) {
// 展示倒计时
private val tvTimer = itemView.findViewById<TextView>(R.id.tv_time)
// 删除按钮
private val btnDelete = itemView.findViewById<TextView>(R.id.btn_delete)
init {
btnDelete.setOnClickListener {
onItemDeleteClick?.invoke(adapterPosition)
}
}
/**
* 剩余倒计时
*/
private var delay = 0L
private val timerRunnable = Runnable {
// 这里打印日志，来印证我们只跑了 "屏幕内可展示item数量的 倒计时"
Log.d(TAG, "run: ${hashCode()}")
delay -= 1000
updateTimerState()
}
// 开始倒计时
private fun startTimer() {
timerHandler.postDelayed(timerRunnable, 1000)
}
// 结束倒计时
private fun endTimer() {
timerHandler.removeCallbacks(timerRunnable)
}
// 检测倒计时 并 更新状态
private fun updateTimerState() {
if (delay <= 0) {
// 倒计时结束了
tvTimer.text = "已结束"
itemView.setBackgroundColor(Color.GRAY)
endTimer()
} else {
// 继续倒计时
tvTimer.text = "${delay / 1000}S"
itemView.setBackgroundColor(Color.parseColor("#FFBB86FC"))
startTimer()
}
}
/**
* 进入屏幕时: 填充数据，这里声明为open，让子类重写
*/
open fun display(bean: BaseItemBean) {
Log.d(TAG, "display: $adapterPosition")
// 使用 终止时间 - 当前时间，计算倒计时还有多少秒
delay = bean.terminalTime - System.currentTimeMillis()
// 检测并更新timer状态
updateTimerState()
}
/**
* 滑出屏幕时: 移除倒计时
*/
fun onRecycled() {
Log.d(TAG, "onRecycled: $adapterPosition")
// 终止计时
endTimer()
}
}
在基础ViewHolder里，我们添加了倒计时套件，并且在进入屏幕时，计算并开始倒计时，滑出屏幕后，就终止倒计时，下次滑入屏幕，重新计算delay时间差，再倒计时。
然后看另一个ViewHolder:
// 继承自BaseViewHolder，因为有公共的倒计时套件
inner class OnSaleVH(itemView: View) : BaseVH(itemView) {
// 添加了一个名字
private val tvName = itemView.findViewById<TextView>(R.id.tv_name)
override fun display(bean: BaseItemBean) {
super.display(bean)
// 添加名字
tvName.text = "${bean.id} 在售"
}
}
接下来我们来看创建ViewHolder的工厂:
/**
* 定义抽象工厂
*/
abstract class VHFactory {
abstract fun createVH(context: Context, parent: ViewGroup): BaseVH
}
/**
* BaseViewHolder工厂
*/
inner class BaseVHFactory : VHFactory() {
override fun createVH(context: Context, parent: ViewGroup): BaseVH {
return BaseVH(LayoutInflater.from(context).inflate(R.layout.item_base, parent, false))
}
}
/**
* OnSaleVH工厂
*/
inner class OnSaleVHFactory : VHFactory() {
override fun createVH(context: Context, parent: ViewGroup): BaseVH {
return OnSaleVH(LayoutInflater.from(context).inflate(R.layout.item_on_sale, parent, false))
}
}
很简单，接下来，我们来看Adapter:
class Adapter(private val datas: List<BaseItemBean>) : RecyclerView.Adapter<Adapter.BaseVH>() {
private val TAG = "Adapter"
/**
* 点击item的事件
*/
var onItemDeleteClick: ((position: Int) -> Unit)? = null
/**
* ViewHolder的工厂
*/
private val vhs = SparseArray<VHFactory>()
/**
* 用来执行倒计时
*/
private val timerHandler = Handler(Looper.getMainLooper())
/**
* 初始化工厂
*/
init {
vhs.put(ItemType.ITEM_BASE, BaseVHFactory())
vhs.put(ItemType.ITEM_ON_SALE, OnSaleVHFactory())
}
// 直接从工厂map中获取对应的工厂调用createVH()方法即可
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BaseVH = vhs.get(viewType).createVH(parent.context, parent)
// 滑入屏幕内调用，直接使用hoder.display()展示数据
override fun onBindViewHolder(holder: BaseVH, position: Int) = holder.display(datas[position])
override fun getItemCount(): Int = datas.size
// ViewHolder滑出屏幕调用，进行回收
override fun onViewRecycled(holder: BaseVH) = holder.onRecycled()
/**
* 根据数据类型返回ViewType
*/
override fun getItemViewType(position: Int): Int = datas[position].type
}
代码也很easy，就是使用工厂模式来返回不同的ViewHolder。
写代码的心路历程:
我们定义的ViewType(都是int类型的，因为int的匹配速度快):
object ItemType {
const val ITEM_BASE = 0x001
const val ITEM_ON_SALE = 0x002
}
接下来我们就可以在Activity中使用了:
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val binding = ActivityMainBinding.inflate(layoutInflater)
setContentView(binding.root)
binding.recyclerView.layoutManager = LinearLayoutManager(this)
// 添加测试数据
val beans = ArrayList<BaseItemBean>()
for (i in 0..100) {
// 计算终止时间，这里都是当前时间 + i乘以10s
val terminalTime = System.currentTimeMillis() + i * 10_000
// 这里手动计算了ViewType (i%2)+1
beans.add(BaseItemBean(i.toLong(), terminalTime, (i % 2) + 1))
}
val adapter = Adapter(beans)
adapter.onItemDeleteClick = { position ->
// 点击就删除
beans.removeAt(position)
adapter.notifyItemRemoved(position)
}
binding.recyclerView.adapter = adapter
}
}
效果如下:
异步交互可能需要一个理想的机会来进行总结。偶尔，在周期结束之前可能会发出一些值。在 Dart 中，您可以创建一个返回 Stream 的容量，该容量可以在异步进程处于活动状态时发射一些值。假设您需要根据一个 Stream 的快照在 Flutter 中构造一个小部件，那么有一个名为 StreamBuilder 的小部件。
在这个博客中，我们将探索 Flutter 中的 StreamBuilder。我们还将实现一个演示程序，并向您展示如何在您的 Flutter 应用程序中使用 StreamBuilder。
StreamBuilder 可以监听公开的流，并返回小部件和捕获获得的流信息的快照。造溪者提出了两个论点。
A stream
构建器，它可以将流中的多个组件更改为小部件
Stream 像一条线。当您从一端输入值而从另一端输入侦听器时，侦听器将获得该值。一个流可以有多个侦听器，这些侦听器的负载可以获得流水线，流水线将获得等价值。如何在流上放置值是通过使用流控制器实现的。流构建器是一个小部件，它可以将用户定义的对象更改为流。
要使用 StreamBuilder，需要调用下面的构造函数:
const StreamBuilder({
Key? key,
Stream<T>? stream,
T? initialData,
required AsyncWidgetBuilder<T> builder,
})
实际上，您需要创建一个 Stream 并将其作为流争用传递。然后，在这一点上，您需要传递一个 AsyncWidgetBuilder，该 AsyncWidgetBuilder 可用于构造依赖于 Stream 快照的小部件。
下面是 StreamBuilderare 的一些参数:
Key? key: 小部件的键，用于控制小部件如何被另一个小部件取代Stream<T>? stream: 一个流，其快照可以通过生成器函数获得T? initialData: 将利用这些数据制作初始快照required AsyncWidgetBuilder<T> builder: 生成过程由此生成器使用你需要分别在你的代码中实现它:
让我们创建一个流:
下面的函数返回一个每秒生成一个数字的 Stream。你需要使用 async * 关键字来创建一个流。若要发出值，可以使用 yield 关键字后跟要发出的值。
Stream<int> generateNumbers = (() async* {
await Future<void>.delayed(Duration(seconds: 2));
for (int i = 1; i <= 10; i++) {
await Future<void>.delayed(Duration(seconds: 1));
yield i;
}
})();
From that point onward, pass it as the stream argument
从那一点开始，把它作为流参数传递下去
StreamBuilder<int>(
stream: generateNumbers,
// other arguments
)
让我们创建一个 AsyncWidgetBuilder
构造函数期望您传递一个类型为 AsyncWidgetBuilder 的命名争用构建器。这是一个有两个参数的函数，它们的类型都是 BuildContext 和 AsyncSnapshot < t > 。后续的边界(包含当前快照)可以用来确定应该呈现的内容。
要创建这个函数，首先需要了解 AsyncSnapshot。AsyncSnapshot 是使用异步计算的最新通信的不变描述。在这种独特的情况下，它解决了与 Stream 的最新通信。可以通过 AsyncSnapshot 属性获取流的最新快照。您可能需要使用的属性之一是 connectionState，这个枚举将当前关联状态转换为异步计算，在这种特殊情况下，这种异步计算就是 Steam。
StreamBuilder<int>(
stream: generateNumbers,
builder: (
BuildContext context,
AsyncSnapshot<int> snapshot,
) {
if (snapshot.connectionState == ConnectionState.waiting) {
return CircularProgressIndicator();
} else if (snapshot.connectionState == ConnectionState.active
|| snapshot.connectionState == ConnectionState.done) {
if (snapshot.hasError) {
return const Text('Error');
} else if (snapshot.hasData) {
return Text(
snapshot.data.toString(),
style: const TextStyle(color: Colors._red_, fontSize: 40)
);
} else {
return const Text('Empty data');
}
} else {
return Text('State: ${snapshot.connectionState}');
}
},
),
AsyncSnapshot 还有一个名为 hasError 的属性，可用于检查快照是否包含非空错误值。如果异步活动的最新结果失败，hasError 值将有效。为了获取信息，首先，您可以通过获取其 hasData 属性来检查快照是否包含信息，如果 Stream 有效地释放了任何非空值，那么 hasData 属性将是有效的。然后，在这一点上，您可以从 AsyncSnapshot 的数据属性获取信息。
由于上面属性的值，您可以计算出应该在屏幕上呈现什么。在下面的代码中，当 connectionState 值正在等待时，将显示一个 CircularProgressIndicator。当 connectionState 更改为 active 或 done 时，可以检查快照是否有错误或信息。建造函数称为 Flutter 管道的检测。因此，它将获得一个与时间相关的快照子组。这意味着，如果在实际上相似的时间里，Stream 发出了一些值，那么一部分值可能没有传递给构建器。
枚举有一些可能的值:
设置初始数据:
您可以选择传递一个 worth 作为 initialData 参数，这个参数将被利用，直到 Stream 发出 a。如果传递的值不为空，那么当 connectionState 在等待时，hasData 属性在任何事件中首先都将为 true
StreamBuilder<int>(
initialData: 0,
// other arguments
)
要在 connectionState 等待时显示初始数据，应该调整 if snapshot.connectionState = = connectionState.waiting，然后调整上面代码中的块。
if (snapshot.connectionState == ConnectionState.waiting) {
return Column(
crossAxisAlignment: CrossAxisAlignment.center,
mainAxisAlignment: MainAxisAlignment.center,
children: [
CircularProgressIndicator(),
Visibility(
visible: snapshot.hasData,
child: Text(
snapshot.data.toString(),
style: const TextStyle(color: Colors._black_, fontSize: 24),
),
),
],
);
}
当我们运行应用程序，我们应该得到屏幕的输出像下面的屏幕视频。
import 'package:flutter/material.dart';
import 'package:flutter_steambuilder_demo/splash_screen.dart';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Splash(),
debugShowCheckedModeBanner: false,
);
}
}
Stream<int> generateNumbers = (() async* {
await Future<void>.delayed(Duration(seconds: 2));
for (int i = 1; i <= 10; i++) {
await Future<void>.delayed(Duration(seconds: 1));
yield i;
}
})();
class StreamBuilderDemo extends StatefulWidget {
@override
State<StatefulWidget> createState() {
return _StreamBuilderDemoState ();
}
}
class _StreamBuilderDemoState extends State<StreamBuilderDemo> {
@override
initState() {
super.initState();
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
automaticallyImplyLeading: false,
title: const Text('Flutter StreamBuilder Demo'),
),
body: SizedBox(
width: double._infinity_,
child: Center(
child: StreamBuilder<int>(
stream: generateNumbers,
initialData: 0,
builder: (
BuildContext context,
AsyncSnapshot<int> snapshot,
) {
if (snapshot.connectionState == ConnectionState.waiting) {
return Column(
crossAxisAlignment: CrossAxisAlignment.center,
mainAxisAlignment: MainAxisAlignment.center,
children: [
CircularProgressIndicator(),
Visibility(
visible: snapshot.hasData,
child: Text(
snapshot.data.toString(),
style: const TextStyle(color: Colors._black_, fontSize: 24),
),
),
],
);
} else if (snapshot.connectionState == ConnectionState.active
|| snapshot.connectionState == ConnectionState.done) {
if (snapshot.hasError) {
return const Text('Error');
} else if (snapshot.hasData) {
return Text(
snapshot.data.toString(),
style: const TextStyle(color: Colors._red_, fontSize: 40)
);
} else {
return const Text('Empty data');
}
} else {
return Text('State: ${snapshot.connectionState}');
}
},
),
),
),
);
}
}
在本文中，我已经简单介绍了 StreamBuilder 的基本结构; 您可以根据自己的选择修改这段代码。这是我对 StreamBuilder On User Interaction 的一个小小介绍，它正在使用 Flutter 工作。
收起阅读 »UIKit的单线程天性意味着寄宿图通畅要在主线程上更新，这意味着绘制会打断用户交互，甚至让整个app看起来处于无响应状态。我们对此无能为力，但是如果能避免用户等待绘制完成就好多了。
针对这个问题，有一些方法可以用到：一些情况下，我们可以推测性地提前在另外一个线程上绘制内容，然后将由此绘出的图片直接设置为图层的内容。这实现起来可能不是很方便，但是在特定情况下是可行的。Core Animation提供了一些选择：CATiledLayer和drawsAsynchronously属性。
我们在第六章简单探索了一下CATiledLayer。除了将图层再次分割成独立更新的小块（类似于脏矩形自动更新的概念），CATiledLayer还有一个有趣的特性：在多个线程中为每个小块同时调用-drawLayer:inContext:方法。这就避免了阻塞用户交互而且能够利用多核心新片来更快地绘制。只有一个小块的CATiledLayer是实现异步更新图片视图的简单方法。
iOS 6中，苹果为CALayer引入了这个令人好奇的属性，drawsAsynchronously属性对传入-drawLayer:inContext:的CGContext进行改动，允许CGContext延缓绘制命令的执行以至于不阻塞用户交互。
它与CATiledLayer使用的异步绘制并不相同。它自己的-drawLayer:inContext:方法只会在主线程调用，但是CGContext并不等待每个绘制命令的结束。相反地，它会将命令加入队列，当方法返回时，在后台线程逐个执行真正的绘制。
根据苹果的说法。这个特性在需要频繁重绘的视图上效果最好（比如我们的绘图应用，或者诸如UITableViewCell之类的），对那些只绘制一次或很少重绘的图层内容来说没什么太大的帮助。
本章我们主要围绕用Core Graphics软件绘制讨论了一些性能挑战，然后探索了一些改进方法：比如提高绘制性能或者减少需要绘制的数量。
第14章，『图像IO』，我们将讨论图片的载入性能。
收起阅读 »不必要的效率考虑往往是性能问题的万恶之源。 ——William Allan Wulf
在第12章『速度的曲率』我们学习如何用Instruments来诊断Core Animation性能问题。在构建一个iOS app的时候会遇到很多潜在的性能陷阱，但是在本章我们将着眼于有关绘制的性能问题。
术语绘图通常在Core Animation的上下文中指代软件绘图（意即：不由GPU协助的绘图）。在iOS中，软件绘图通常是由Core Graphics框架完成来完成。但是，在一些必要的情况下，相比Core Animation和OpenGL，Core Graphics要慢了不少。
软件绘图不仅效率低，还会消耗可观的内存。CALayer只需要一些与自己相关的内存：只有它的寄宿图会消耗一定的内存空间。即使直接赋给contents属性一张图片，也不需要增加额外的照片存储大小。如果相同的一张图片被多个图层作为contents属性，那么他们将会共用同一块内存，而不是复制内存块。
但是一旦你实现了CALayerDelegate协议中的-drawLayer:inContext:方法或者UIView中的-drawRect:方法（其实就是前者的包装方法），图层就创建了一个绘制上下文，这个上下文需要的大小的内存可从这个算式得出：图层宽*图层高*4字节，宽高的单位均为像素。对于一个在Retina iPad上的全屏图层来说，这个内存量就是 2048*1526*4字节，相当于12MB内存，图层每次重绘的时候都需要重新抹掉内存然后重新分配。
软件绘图的代价昂贵，除非绝对必要，你应该避免重绘你的视图。提高绘制性能的秘诀就在于尽量避免去绘制。
我们用Core Graphics来绘图的一个通常原因就是只是用图片或是图层效果不能轻易地绘制出矢量图形。矢量绘图包含一下这些：
举个例子，清单13.1 展示了一个基本的画线应用。这个应用将用户的触摸手势转换成一个UIBezierPath上的点，然后绘制成视图。我们在一个UIView子类DrawingView中实现了所有的绘制逻辑，这个情况下我们没有用上view controller。但是如果你喜欢你可以在view controller中实现触摸事件处理。图13.1是代码运行结果。
清单13.1 用Core Graphics实现一个简单的绘图应用
#import "DrawingView.h"
@interface DrawingView ()
@property (nonatomic, strong) UIBezierPath *path;
@end
@implementation DrawingView
- (void)awakeFromNib
{
//create a mutable path
self.path = [[UIBezierPath alloc] init];
self.path.lineJoinStyle = kCGLineJoinRound;
self.path.lineCapStyle = kCGLineCapRound;

self.path.lineWidth = 5;
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the starting point
CGPoint point = [[touches anyObject] locationInView:self];
//move the path drawing cursor to the starting point
[self.path moveToPoint:point];
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the current point
CGPoint point = [[touches anyObject] locationInView:self];
//add a new line segment to our path
[self.path addLineToPoint:point];
//redraw the view
[self setNeedsDisplay];
}
- (void)drawRect:(CGRect)rect
{
//draw path
[[UIColor clearColor] setFill];
[[UIColor redColor] setStroke];
[self.path stroke];
}
@end
图13.1 用Core Graphics做一个简单的『素描』
这样实现的问题在于，我们画得越多，程序就会越慢。因为每次移动手指的时候都会重绘整个贝塞尔路径（UIBezierPath），随着路径越来越复杂，每次重绘的工作就会增加，直接导致了帧数的下降。看来我们需要一个更好的方法了。
Core Animation为这些图形类型的绘制提供了专门的类，并给他们提供硬件支持（第六章『专有图层』有详细提到）。CAShapeLayer可以绘制多边形，直线和曲线。CATextLayer可以绘制文本。CAGradientLayer用来绘制渐变。这些总体上都比Core Graphics更快，同时他们也避免了创造一个寄宿图。
如果稍微将之前的代码变动一下，用CAShapeLayer替代Core Graphics，性能就会得到提高（见清单13.2）.虽然随着路径复杂性的增加，绘制性能依然会下降，但是只有当非常非常浮躁的绘制时才会感到明显的帧率差异。
清单13.2 用CAShapeLayer重新实现绘图应用
#import "DrawingView.h"
#import
@interface DrawingView ()
@property (nonatomic, strong) UIBezierPath *path;
@end

@implementation DrawingView
+ (Class)layerClass
{
//this makes our view create a CAShapeLayer
//instead of a CALayer for its backing layer
return [CAShapeLayer class];
}
- (void)awakeFromNib
{
//create a mutable path
self.path = [[UIBezierPath alloc] init];
//configure the layer
CAShapeLayer *shapeLayer = (CAShapeLayer *)self.layer;
shapeLayer.strokeColor = [UIColor redColor].CGColor;
shapeLayer.fillColor = [UIColor clearColor].CGColor;
shapeLayer.lineJoin = kCALineJoinRound;
shapeLayer.lineCap = kCALineCapRound;
shapeLayer.lineWidth = 5;
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the starting point
CGPoint point = [[touches anyObject] locationInView:self];
//move the path drawing cursor to the starting point
[self.path moveToPoint:point];
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the current point
CGPoint point = [[touches anyObject] locationInView:self];
//add a new line segment to our path
[self.path addLineToPoint:point];
//update the layer with a copy of the path
((CAShapeLayer *)self.layer).path = self.path.CGPath;
}
@end 有时候用CAShapeLayer或者其他矢量图形图层替代Core Graphics并不是那么切实可行。比如我们的绘图应用：我们用线条完美地完成了矢量绘制。但是设想一下如果我们能进一步提高应用的性能，让它就像一个黑板一样工作，然后用『粉笔』来绘制线条。模拟粉笔最简单的方法就是用一个『线刷』图片然后将它粘贴到用户手指碰触的地方，但是这个方法用CAShapeLayer没办法实现。
我们可以给每个『线刷』创建一个独立的图层，但是实现起来有很大的问题。屏幕上允许同时出现图层上线数量大约是几百，那样我们很快就会超出的。这种情况下我们没什么办法，就用Core Graphics吧（除非你想用OpenGL做一些更复杂的事情）。
我们的『黑板』应用的最初实现见清单13.3，我们更改了之前版本的DrawingView，用一个画刷位置的数组代替UIBezierPath。图13.2是运行结果
清单13.3 简单的类似黑板的应用
#import "DrawingView.h"
#import
#define BRUSH_SIZE 32
@interface DrawingView ()
@property (nonatomic, strong) NSMutableArray *strokes;
@end
@implementation DrawingView
- (void)awakeFromNib
{
//create array
self.strokes = [NSMutableArray array];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the starting point
CGPoint point = [[touches anyObject] locationInView:self];
//add brush stroke
[self addBrushStrokeAtPoint:point];
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
//get the touch point
CGPoint point = [[touches anyObject] locationInView:self];
//add brush stroke
[self addBrushStrokeAtPoint:point];
}
- (void)addBrushStrokeAtPoint:(CGPoint)point
{
//add brush stroke to array
[self.strokes addObject:[NSValue valueWithCGPoint:point]];
//needs redraw
[self setNeedsDisplay];
}
- (void)drawRect:(CGRect)rect
{
//redraw strokes
for (NSValue *value in self.strokes) {
//get point
CGPoint point = [value CGPointValue];
//get brush rect
CGRect brushRect = CGRectMake(point.x - BRUSH_SIZE/2, point.y - BRUSH_SIZE/2, BRUSH_SIZE, BRUSH_SIZE);
//draw brush stroke 
[[UIImage imageNamed:@"Chalk.png"] drawInRect:brushRect];
}
}
@end
图13.2 用程序绘制一个简单的『素描』
这个实现在模拟器上表现还不错，但是在真实设备上就没那么好了。问题在于每次手指移动的时候我们就会重绘之前的线刷，即使场景的大部分并没有改变。我们绘制地越多，就会越慢。随着时间的增加每次重绘需要更多的时间，帧数也会下降（见图13.3），如何提高性能呢？
图13.3 帧率和线条质量会随时间下降。
为了减少不必要的绘制，Mac OS和iOS设备将会把屏幕区分为需要重绘的区域和不需要重绘的区域。那些需要重绘的部分被称作『脏区域』。在实际应用中，鉴于非矩形区域边界裁剪和混合的复杂性，通常会区分出包含指定视图的矩形位置，而这个位置就是『脏矩形』。
当一个视图被改动过了，TA可能需要重绘。但是很多情况下，只是这个视图的一部分被改变了，所以重绘整个寄宿图就太浪费了。但是Core Animation通常并不了解你的自定义绘图代码，它也不能自己计算出脏区域的位置。然而，你的确可以提供这些信息。
当你检测到指定视图或图层的指定部分需要被重绘，你直接调用-setNeedsDisplayInRect:来标记它，然后将影响到的矩形作为参数传入。这样就会在一次视图刷新时调用视图的-drawRect:（或图层代理的-drawLayer:inContext:方法）。
传入-drawLayer:inContext:的CGContext参数会自动被裁切以适应对应的矩形。为了确定矩形的尺寸大小，你可以用CGContextGetClipBoundingBox()方法来从上下文获得大小。调用-drawRect()会更简单，因为CGRect会作为参数直接传入。
你应该将你的绘制工作限制在这个矩形中。任何在此区域之外的绘制都将被自动无视，但是这样CPU花在计算和抛弃上的时间就浪费了，实在是太不值得了。
相比依赖于Core Graphics为你重绘，裁剪出自己的绘制区域可能会让你避免不必要的操作。那就是说，如果你的裁剪逻辑相当复杂，那还是让Core Graphics来代劳吧，记住：当你能高效完成的时候才这样做。
清单13.4 展示了一个-addBrushStrokeAtPoint:方法的升级版，它只重绘当前线刷的附近区域。另外也会刷新之前线刷的附近区域，我们也可以用CGRectIntersectsRect()来避免重绘任何旧的线刷以不至于覆盖已更新过的区域。这样做会显著地提高绘制效率（见图13.4）
清单13.4 用-setNeedsDisplayInRect:来减少不必要的绘制
- (void)addBrushStrokeAtPoint:(CGPoint)point
{
//add brush stroke to array
[self.strokes addObject:[NSValue valueWithCGPoint:point]];
//set dirty rect
[self setNeedsDisplayInRect:[self brushRectForPoint:point]];
}
- (CGRect)brushRectForPoint:(CGPoint)point
{
return CGRectMake(point.x - BRUSH_SIZE/2, point.y - BRUSH_SIZE/2, BRUSH_SIZE, BRUSH_SIZE);
}
- (void)drawRect:(CGRect)rect
{
//redraw strokes
for (NSValue *value in self.strokes) {
//get point
CGPoint point = [value CGPointValue];
//get brush rect
CGRect brushRect = [self brushRectForPoint:point];

//only draw brush stroke if it intersects dirty rect
if (CGRectIntersectsRect(rect, brushRect)) {
//draw brush stroke
[[UIImage imageNamed:@"Chalk.png"] drawInRect:brushRect];
}
}
}
图13.4 更好的帧率和顺滑线条
收起阅读 »Instruments是Xcode套件中没有被充分利用的一个工具。很多iOS开发者从没用过Instruments，或者只是用Leaks工具检测循环引用。实际上有很多Instruments工具，包括为动画性能调优的东西。
你可以通过在菜单中选择Profile选项来打开Instruments（在这之前，记住要把目标设置成iOS设备，而不是模拟器）。然后将会显示出图12.1（如果没有看到所有选项，你可能设置成了模拟器选项）。
图12.1 Instruments工具选项窗口
就像之前提到的那样，你应该始终将程序设置成发布选项。幸运的是，配置文件默认就是发布选项，所以你不需要在分析的时候调整编译策略。
我们将讨论如下几个工具：
时间分析器 - 用来测量被方法/函数打断的CPU使用情况。
Core Animation - 用来调试各种Core Animation性能问题。
OpenGL ES驱动 - 用来调试GPU性能问题。这个工具在编写Open GL代码的时候很有用，但有时也用来处理Core Animation的工作。
Instruments的一个很棒的功能在于它可以创建我们自定义的工具集。除了你初始选择的工具之外，如果在Instruments中打开Library窗口，你可以拖拽别的工具到左侧边栏。我们将创建以上我们提到的三个工具，然后就可以并行使用了（见图12.2）。
图12.2 添加额外的工具到Instruments侧边栏
时间分析器工具用来检测CPU的使用情况。它可以告诉我们程序中的哪个方法正在消耗大量的CPU时间。使用大量的CPU并不一定是个问题 - 你可能期望动画路径对CPU非常依赖，因为动画往往是iOS设备中最苛刻的任务。
但是如果你有性能问题，查看CPU时间对于判断性能是不是和CPU相关，以及定位到函数都很有帮助（见图12.3）。
图12.3 时间分析器工具
时间分析器有一些选项来帮助我们定位到我们关心的的方法。可以使用左侧的复选框来打开。其中最有用的是如下几点：
通过线程分离 - 这可以通过执行的线程进行分组。如果代码被多线程分离的话，那么就可以判断到底是哪个线程造成了问题。
隐藏系统库 - 可以隐藏所有苹果的框架代码，来帮助我们寻找哪一段代码造成了性能瓶颈。由于我们不能优化框架方法，所以这对定位到我们能实际修复的代码很有用。
只显示Obj-C代码 - 隐藏除了Objective-C之外的所有代码。大多数内部的Core Animation代码都是用C或者C++函数，所以这对我们集中精力到我们代码中显式调用的方法就很有用。
Core Animation工具用来监测Core Animation性能。它给我们提供了周期性的FPS，并且考虑到了发生在程序之外的动画（见图12.4）。
图12.4 使用可视化调试选项的Core Animation工具
Core Animation工具也提供了一系列复选框选项来帮助调试渲染瓶颈：
Color Blended Layers - 这个选项基于渲染程度对屏幕中的混合区域进行绿到红的高亮（也就是多个半透明图层的叠加）。由于重绘的原因，混合对GPU性能会有影响，同时也是滑动或者动画帧率下降的罪魁祸首之一。
ColorHitsGreenandMissesRed - 当使用shouldRasterizep属性的时候，耗时的图层绘制会被缓存，然后当做一个简单的扁平图片呈现。当缓存再生的时候这个选项就用红色对栅格化图层进行了高亮。如果缓存频繁再生的话，就意味着栅格化可能会有负面的性能影响了（更多关于使用shouldRasterize的细节见第15章“图层性能”）。
Color Copied Images - 有时候寄宿图片的生成意味着Core Animation被强制生成一些图片，然后发送到渲染服务器，而不是简单的指向原始指针。这个选项把这些图片渲染成蓝色。复制图片对内存和CPU使用来说都是一项非常昂贵的操作，所以应该尽可能的避免。
Color Immediately - 通常Core Animation Instruments以每毫秒10次的频率更新图层调试颜色。对某些效果来说，这显然太慢了。这个选项就可以用来设置每帧都更新（可能会影响到渲染性能，而且会导致帧率测量不准，所以不要一直都设置它）。
Color Misaligned Images - 这里会高亮那些被缩放或者拉伸以及没有正确对齐到像素边界的图片（也就是非整型坐标）。这些中的大多数通常都会导致图片的不正常缩放，如果把一张大图当缩略图显示，或者不正确地模糊图像，那么这个选项将会帮你识别出问题所在。
Color Offscreen-Rendered Yellow - 这里会把那些需要离屏渲染的图层高亮成黄色。这些图层很可能需要用shadowPath或者shouldRasterize来优化。
Color OpenGL Fast Path Blue - 这个选项会对任何直接使用OpenGL绘制的图层进行高亮。如果仅仅使用UIKit或者Core Animation的API，那么不会有任何效果。如果使用GLKView或者CAEAGLLayer，那如果不显示蓝色块的话就意味着你正在强制CPU渲染额外的纹理，而不是绘制到屏幕。
Flash Updated Regions - 这个选项会对重绘的内容高亮成黄色（也就是任何在软件层面使用Core Graphics绘制的图层）。这种绘图的速度很慢。如果频繁发生这种情况的话，这意味着有一个隐藏的bug或者说通过增加缓存或者使用替代方案会有提升性能的空间。
这些高亮图层的选项同样在iOS模拟器的调试菜单也可用（图12.5）。我们之前说过用模拟器测试性能并不好，但如果你能通过这些高亮选项识别出性能问题出在什么地方的话，那么使用iOS模拟器来验证问题是否解决也是比真机测试更有效的。
图12.5 iOS模拟器中Core Animation可视化调试选项
OpenGL ES驱动工具可以帮你测量GPU的利用率，同样也是一个很好的来判断和GPU相关动画性能的指示器。它同样也提供了类似Core Animation那样显示FPS的工具（图12.6）。
图12.6 OpenGL ES驱动工具
侧栏的邮编是一系列有用的工具。其中和Core Animation性能最相关的是如下几点：
Renderer Utilization - 如果这个值超过了~50%，就意味着你的动画可能对帧率有所限制，很可能因为离屏渲染或者是重绘导致的过度混合。
Tiler Utilization - 如果这个值超过了~50%，就意味着你的动画可能限制于几何结构方面，也就是在屏幕上有太多的图层占用了。
现在我们已经对Instruments中动画性能工具非常熟悉了，那么可以用它在现实中解决一些实际问题。
我们创建一个简单的显示模拟联系人姓名和头像列表的应用。注意即使把头像图片存在应用本地，为了使应用看起来更真实，我们分别实时加载图片，而不是用–imageNamed:预加载。同样添加一些图层阴影来使得列表显示得更真实。清单12.1展示了最初版本的实现。
清单12.1 使用假数据的一个简单联系人列表
#import "ViewController.h"
#import
@interface ViewController ()
@property (nonatomic, strong) NSArray *items;
@property (nonatomic, weak) IBOutlet UITableView *tableView;
@end
@implementation ViewController
- (NSString *)randomName
{
NSArray *first = @[@"Alice", @"Bob", @"Bill", @"Charles", @"Dan", @"Dave", @"Ethan", @"Frank"];
NSArray *last = @[@"Appleseed", @"Bandicoot", @"Caravan", @"Dabble", @"Ernest", @"Fortune"];
NSUInteger index1 = (rand()/(double)INT_MAX) * [first count];
NSUInteger index2 = (rand()/(double)INT_MAX) * [last count];
return [NSString stringWithFormat:@"%@ %@", first[index1], last[index2]];
}
- (NSString *)randomAvatar
{
NSArray *images = @[@"Snowman", @"Igloo", @"Cone", @"Spaceship", @"Anchor", @"Key"];
NSUInteger index = (rand()/(double)INT_MAX) * [images count];
return images[index];
}
- (void)viewDidLoad
{
[super viewDidLoad];
//set up data
NSMutableArray *array = [NSMutableArray array];
for (int i = 0; i < 1000; i++) {
//add name
[array addObject:@{@"name": [self randomName], @"image": [self randomAvatar]}];
}
self.items = array;
//register cell class
[self.tableView registerClass:[UITableViewCell class] forCellReuseIdentifier:@"Cell"];
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
return [self.items count];
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
//dequeue cell
UITableViewCell *cell = [self.tableView dequeueReusableCellWithIdentifier:@"Cell" forIndexPath:indexPath];
//load image
NSDictionary *item = self.items[indexPath.row];
NSString *filePath = [[NSBundle mainBundle] pathForResource:item[@"image"] ofType:@"png"];
//set image and text
cell.imageView.image = [UIImage imageWithContentsOfFile:filePath];
cell.textLabel.text = item[@"name"];
//set image shadow
cell.imageView.layer.shadowOffset = CGSizeMake(0, 5);
cell.imageView.layer.shadowOpacity = 0.75;
cell.clipsToBounds = YES;
//set text shadow
cell.textLabel.backgroundColor = [UIColor clearColor];
cell.textLabel.layer.shadowOffset = CGSizeMake(0, 2);
cell.textLabel.layer.shadowOpacity = 0.5;
return cell;
}
@end
当快速滑动的时候就会非常卡（见图12.7的FPS计数器）。
图12.7 滑动帧率降到15FPS
仅凭直觉，我们猜测性能瓶颈应该在图片加载。我们实时从闪存加载图片，而且没有缓存，所以很可能是这个原因。我们可以用一些很赞的代码修复，然后使用GCD异步加载图片，然后缓存。。。等一下，在开始编码之前，测试一下假设是否成立。首先用我们的三个Instruments工具分析一下程序来定位问题。我们推测问题可能和图片加载相关，所以用Time Profiler工具来试试（图12.8）。
图12.8 用The timing profile分析联系人列表
-tableView:cellForRowAtIndexPath:中的CPU时间总利用率只有~28%（也就是加载头像图片的地方），非常低。于是建议是CPU/IO并不是真正的限制因素。然后看看是不是GPU的问题：在OpenGL ES Driver工具中检测GPU利用率（图12.9）。
图12.9 OpenGL ES Driver工具显示的GPU利用率
渲染服务利用率的值达到51%和63%。看起来GPU需要做很多工作来渲染联系人列表。
为什么GPU利用率这么高呢？我们来用Core Animation调试工具选项来检查屏幕。首先打开Color Blended Layers（图12.10）。
图12.10 使用Color Blended Layers选项调试程序
屏幕中所有红色的部分都意味着字符标签视图的高级别混合，这很正常，因为我们把背景设置成了透明色来显示阴影效果。这就解释了为什么渲染利用率这么高了。
那么离屏绘制呢？打开Core Animation工具的Color Offscreen - Rendered Yellow选项（图12.11）。
图12.11 Color Offscreen–Rendered Yellow选项
所有的表格单元内容都在离屏绘制。这一定是因为我们给图片和标签视图添加的阴影效果。在代码中禁用阴影，然后看下性能是否有提高（图12.12）。
图12.12 禁用阴影之后运行程序接近60FPS
问题解决了。干掉阴影之后，滑动很流畅。但是我们的联系人列表看起来没有之前好了。那如何保持阴影效果而且不会影响性能呢？
好吧，每一行的字符和头像在每一帧刷新的时候并不需要变，所以看起来UITableViewCell的图层非常适合做缓存。我们可以使用shouldRasterize来缓存图层内容。这将会让图层离屏之后渲染一次然后把结果保存起来，直到下次利用的时候去更新（见清单12.2）。
清单12.2 使用shouldRasterize提高性能
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
//dequeue cell
UITableViewCell *cell = [self.tableView dequeueReusableCellWithIdentifier:@"Cell"
forIndexPath:indexPath];
...
//set text shadow
cell.textLabel.backgroundColor = [UIColor clearColor];
cell.textLabel.layer.shadowOffset = CGSizeMake(0, 2);
cell.textLabel.layer.shadowOpacity = 0.5;
//rasterize
cell.layer.shouldRasterize = YES;
cell.layer.rasterizationScale = [UIScreen mainScreen].scale;
return cell;
}
我们仍然离屏绘制图层内容，但是由于显式地禁用了栅格化，Core Animation就对绘图缓存了结果，于是对提高了性能。我们可以验证缓存是否有效，在Core Animation工具中点击Color Hits Green and Misses Red选项（图12.13）。
图12.13 Color Hits Green and Misses Red验证了缓存有效
结果和预期一致 - 大部分都是绿色，只有当滑动到屏幕上的时候会闪烁成红色。因此，现在帧率更加平滑了。
所以我们最初的设想是错的。图片的加载并不是真正的瓶颈所在，而且试图把它置于一个复杂的多线程加载和缓存的实现都将是徒劳。所以在动手修复之前验证问题所在是个很好的习惯！
在这章中，我们学习了Core Animation是如何渲染，以及我们可能出现的瓶颈所在。你同样学习了如何使用Instruments来检测和修复性能问题。
在下三章中，我们将对每个普通程序的性能陷阱进行详细讨论，然后学习如何修复。
在进行研究measure原理之前，我们先带着这三个问题来想想。因为我是遇到这三个问题才开始研究measure的源码，所以我也把下面的三个问题当做引子。
调用measure(int widthMeasureSpec, int heightMeasureSpec)方法传递的参数是什么？ 为什么调用measure方法View控件没有进行测量？ 如何强制view进行测量？ 在进行研究之前，我们先来看一个简单的布局，
<Button
android:id="@+id/btn_click"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="点击"
android:onClick="start"
/>
<LinearLayout
android:id="@+id/linear"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="#FF0000">
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="点击"/>
</LinearLayout>
看效果图：
根据布局文件，我们并没有设置边距属性，为什么显示的效果的Button跟下面的没有对齐。这就是。在实际开发中，我们细心点会发现，对于Button控件，我们选中它的时候显示的区域比它展现的区域大。
如果我们给Button控件添加背景色：
<Button
android:id="@+id/btn_click"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="点击"
android:background="#FF0000"
android:onClick="start"
/>
可以看到Button的背景色和LinearLayout的背景色无缝连接在一起，同时我们观察下面的那个点击的Button，发现它的周围区域实际是存在的，是白色与我们的背景色重叠起来了。这就引入了我们的一个重要概念:控件边界布局和视觉编辑布局。我们在真机上打开【显示布局边界】，在设置——>开发者选项——>显示布局边界。 我们看下效果图。
注：蓝色 为控件的布局边界；粉红色为视觉边界 这就涉及到我们的一个ViewGroup属性：android:layoutMode
说的通俗一点，clipBounds就是默认值，不处理一些控件之间的“留白”，opticalBounds消除控件之间的留白。
我们抽出LinearLayout的布局来说：
<LinearLayout
android:id="@+id/linear"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="#fff000"
android:layoutMode="clipBounds">
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="点击"/>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="测试的"
/>
</LinearLayout>
我们修改属性android:layoutMode=”opticalBounds”，效果图：
通过对比发现就是一个清除的效果。
MeasureSpec 我们分析第一个问题，onMeasure()方法里传的是什么？传的就是MeasureSpec变量。它是View的一个内部类。源码设计非常简单精悍。
一个MeasureSpec封装了父布局传递给子布局的布局要求，每个MeasureSpec代表了一组宽度和高度的要求。一个MeasureSpec由大小和模式组成。由32位组成，头8位为模式，后24位封装大小。它有三种模式：UNSPECIFIED(未指定),父元素部队自元素施加任何束缚，子元素可以得到任意想要的大小；EXACTLY(完全)，父元素决定自元素的确切大小，子元素将被限定在给定的边界里而忽略它本身大小；AT_MOST(至多)，子元素至多达到指定大小的值。它常用的三个函数：
static int getMode(int measureSpec):根据提供的测量值(格式)提取模式(上述三个模式之一) static int getSize(int measureSpec):根据提供的测量值(格式)提取大小值(这个大小也就是我们通常所说的大小) static int makeMeasureSpec(int size,int mode):根据提供的大小值和模式创建一个测量值(格式) Mode的取值：
MeasureSpec.AT_MOST，即十进制2，该值表示View最大可以取其父ViewGroup给其指定的尺寸，例如现在有个Int值widthMeasureSpec，ViewGroup将其传递给了View的measure方法，如果widthMeasureSpec中的mode值是AT_MOST，size是300，那么表示View能取的最大的宽度是300。
MeasureSpec.EXACTLY，即十进制1，该值表示View必须使用其父ViewGroup指定的尺寸，还是以widthMeasureSpec为例，如果其mode值是EXACTLY，控件大小就是它老子的大小
MeasureSpec.UNSPECIFIED，即十进制0，该值表示View的父ViewGroup没有给View在尺寸上设置限制条件，这种情况下View可以忽略measureSpec中的size，View可以取自己想要的值作为量算的尺寸。
我们常看到measure(0,0)或者measure(1,1)之类的，这就是传入的测量模式。
measure()方法 下面就开始分析measure方法。
public final void measure(int widthMeasureSpec, int heightMeasureSpec) {
//判断当前view的LayoutMode是否为opticalbounds
boolean optical = isLayoutModeOptical(this);
if (optical != isLayoutModeOptical(mParent)) {//判断当前view的ParentView的LayoutMode是否为opticalbounds
Insets insets = getOpticalInsets();
int oWidth = insets.left + insets.right;
int oHeight = insets.top + insets.bottom;
widthMeasureSpec = MeasureSpec.adjust(widthMeasureSpec, optical ? -oWidth : oWidth);
heightMeasureSpec = MeasureSpec.adjust(heightMeasureSpec, optical ? -oHeight : oHeight);
}
// 根据我们传入的widthMeasureSpec和heightMeasureSpec计算key值，我们在mMeasureCache中存储我们view的信息
long key = (long) widthMeasureSpec << 32 | (long) heightMeasureSpec & 0xffffffffL;
//如果mMeasureCache为null，则进行new一个对象
if (mMeasureCache == null) mMeasureCache = new LongSparseLongArray(2);
//mOldWidthMeasureSpec和mOldHeightMeasureSpec分别表示上次对View进行量算时的widthMeasureSpec和heightMeasureSpec
//执行View的measure方法时，View总是先检查一下是不是真的有必要费很大力气去做真正的量算工作
//mPrivateFlags是一个Int类型的值，其记录了View的各种状态位
//如果(mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT，
//那么表示当前View需要强制进行layout（比如执行了View的forceLayout方法），所以这种情况下要尝试进行量算
//如果新传入的widthMeasureSpec/heightMeasureSpec与上次量算时的mOldWidthMeasureSpec/mOldHeightMeasureSpec不等，
//那么也就是说该View的父ViewGroup对该View的尺寸的限制情况有变化，这种情况下要尝试进行量算
if ((mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ||
widthMeasureSpec != mOldWidthMeasureSpec ||
heightMeasureSpec != mOldHeightMeasureSpec) {
//通过运算，重置mPrivateFlags值，即View的测量状态
mPrivateFlags &= ~PFLAG_MEASURED_DIMENSION_SET;
//解决布局中的Rtl问题
resolveRtlPropertiesIfNeeded();
//判断当前View是否是强制进行测量，如果是则将cacheIndex=-1，反之从mMeasureCache中获取
//对应的index，即从缓存中读取存储的大小。
int cacheIndex = (mPrivateFlags & PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ? -1 :
mMeasureCache.indexOfKey(key);
//根据cacheIndex的大小判断是否需要重新测量，或者根据布尔变量sIgnoreMeasureCache进行判断。
if (cacheIndex < 0 || sIgnoreMeasureCache) {
// 重新测量，则调用我们重写的onMeasure()方法进行测量，然后重置View的状态
onMeasure(widthMeasureSpec, heightMeasureSpec);
mPrivateFlags3 &= ~PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
} else {
// 通过我们计算的cacheIndex值，从缓存中读取我们的测量值。
long value = mMeasureCache.valueAt(cacheIndex);
// 通过setMeasuredDimension()方法设置我们的测量值，然后重置View的状态
setMeasuredDimension((int) (value >> 32), (int) value);
mPrivateFlags3 |= PFLAG3_MEASURE_NEEDED_BEFORE_LAYOUT;
}
// 如果View的状态没有改变，则会抛出异常“我们没有调用”setMeasuredDimension()“方法，一般出现在我们重写onMeasure方法，
//但是没有调用setMeasuredDimension方法导致的。
if ((mPrivateFlags & PFLAG_MEASURED_DIMENSION_SET) != PFLAG_MEASURED_DIMENSION_SET) {
throw new IllegalStateException("onMeasure() did not set the"
+ " measured dimension by calling"
+ " setMeasuredDimension()");
}
mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;
}
mOldWidthMeasureSpec = widthMeasureSpec;
mOldHeightMeasureSpec = heightMeasureSpec;
//将最新的widthMeasureSpec和heightMeasureSpec进行存储到mMeasureCache
mMeasureCache.put(key, ((long) mMeasuredWidth) << 32 |
(long) mMeasuredHeight & 0xffffffffL); // suppress sign extension
}
在上面的代码中，注释还算详细，仔细看应该能知道测量的流程。 （1）、测量首先判断控件的模式，通过调用isLayoutModeOptical方法进行判断。
public static boolean isLayoutModeOptical(Object o) {
return o instanceof ViewGroup && ((ViewGroup) o).isLayoutModeOptical();
}
//ViewGroup的isLayoutModeOptical方法
boolean isLayoutModeOptical() {
return mLayoutMode == LAYOUT_MODE_OPTICAL_BOUNDS;
}
这个方法就是判断view是否为ViewGroup类型，然后判断layoutMode设定是否为opticalBounds。如果是，则对传入的widthMeasureSpec、heightMeasureSpec进行重新计算封装，通过上面的试验，我们看到了设定的区别，所以需要重新计算封装。
（2）、判断当前view是否强制重新计算，或者传入进来的MeasureSpec是否和上次不同。这两种情况满足一种则进行测量运算。 （3）、系统还不满足，又判断是否为强制测量，如果为强制测量或者忽略缓存，则调用我们重写的onMeasure()方法进行测量，反之，从mMeasureCache缓存中读取上次的测量数据。
为什么调用measure()方法控件没有进行重新测量？
通过前面的源码分析，是不是对结果知道一二，View也不是因为我们调用了measure方法就进行真真切切的重新测量，首先，它会判断我们是否是强制测量或者测量模式发生了改变没有，这个是必要条件，如果这里都不满足就不会进入执行到我们的onMeasure方法，之后还要判断我们是否强制重新测量，不然取缓存的值，只样实际上还没有达到我们的测量。 注：Android不同版本对应的measure方法源码可能有所不同。
说到这里，measure的源码是分析了，我们在往深入的想，我们如果在我们的自定义View时没有对onMeasure()方法进行重写，那么系统调用的onMeasure()方法是怎么实现的呢？不错，我们就瞧一瞧View中默认的onMeasure()方法是怎么实现的。
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}
这里面涉及到三个方法：
稍微思考下，我们也知道肯定是设置一个默认值的，我们看下后两个函数的源码：
protected int getSuggestedMinimumWidth() {
return (mBackground == null) ? mMinWidth : max(mMinWidth, mBackground.getMinimumWidth());
}
protected int getSuggestedMinimumHeight() {
return (mBackground == null) ? mMinHeight : max(mMinHeight, mBackground.getMinimumHeight());
}
都是进行判断backgroud是否为空，如果为空，返回view最小的高度或宽度，如果不为空，返回与backgroud的最小宽高中的最大值。可能你会疑惑，view的最小宽度或高度是怎么来的？这个就要回归到我们的View构造函数。
case R.styleable.View_minWidth:
mMinWidth = a.getDimensionPixelSize(attr, 0);
break;
case R.styleable.View_minHeight:
mMinHeight = a.getDimensionPixelSize(attr, 0);
break;
可以从这里获取，当然我们也可以进行设定：
public void setMinimumWidth(int minWidth) {
mMinWidth = minWidth;
requestLayout();
}
public void setMinimumHeight(int minHeight) {
mMinHeight = minHeight;
requestLayout();
}
我们接着看看看getDefaultSize()的源码：
public static int getDefaultSize(int size, int measureSpec) {
int result = size;
int specMode = MeasureSpec.getMode(measureSpec);
int specSize = MeasureSpec.getSize(measureSpec);
switch (specMode) {
case MeasureSpec.UNSPECIFIED:
result = size;
break;
case MeasureSpec.AT_MOST:
case MeasureSpec.EXACTLY:
result = specSize;
break;
}
return result;
}
在getDefaultSize中，传入进来我们获取的最小值，然后根据我们设定的MeasureSpec获取对应size和mode，然后判断mode，如果为MeasureSpec.UNSPECIFIED就将size赋值我们获取的最小大小。模式为MeasureSpec.AT_MOST、MeasureSpec.EXACTLY时，赋值为我们从MeasureSpec获取的大小。这也证实了自定义控件时，我们没有重写onMeasure方法，同时给控件设置wrap_content属性，控件显示的效果是match_parent的效果。
说到这里measure流程的大概也基本搞明白了。 我们来看第三个问题，如何强制一个view进行重绘？ 根据上面的分析，我们强制重绘就得清除缓存mMeasureCache缓存中的数据。这里就得提及forceLayout()方法，看下这个方法的源码：
public void forceLayout() {
if (mMeasureCache != null) mMeasureCache.clear();
mPrivateFlags |= PFLAG_FORCE_LAYOUT;
mPrivateFlags |= PFLAG_INVALIDATED;
}
这个方法中就是清除缓存mMeasureCache中的缓存数据，然后改变View的mPrivateFlags属性值。这里又得说起requestLayout()函数，用于请求重新布局。
public void requestLayout() {
if (mMeasureCache != null) mMeasureCache.clear();
if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == null) {
// Only trigger request-during-layout logic if this is the view requesting it,
// not the views in its parent hierarchy
ViewRootImpl viewRoot = getViewRootImpl();
if (viewRoot != null && viewRoot.isInLayout()) {
if (!viewRoot.requestLayoutDuringLayout(this)) {
return;
}
}
mAttachInfo.mViewRequestingLayout = this;
}
mPrivateFlags |= PFLAG_FORCE_LAYOUT;
mPrivateFlags |= PFLAG_INVALIDATED;
if (mParent != null && !mParent.isLayoutRequested()) {
mParent.requestLayout();
}
if (mAttachInfo != null && mAttachInfo.mViewRequestingLayout == this) {
mAttachInfo.mViewRequestingLayout = null;
}
}
这样就可以完成View的强制测量。在实际的开发中，我们在对自定义View进行测量的时候，只需要重写onMeasure()方法即可，在onMeasure()方法中指定我们要求的控件大小，除非我们在刷新控件的时候需要我们去考虑一些方法的实现，探究源码让我们知道了为什么是这样，不至于迷惘。
收起阅读 »这些实践可以让你的程序在使用协程的时候更加的易扩展和易测试
不要在创建一个协程的时候或者调用withContext，硬编码来指定调度器 比如这样的
class NewsRepository {
// DO NOT use Dispatchers.Default directly, inject it instead
suspend fun loadNews() = withContext(Dispatchers.Default) { /* ... */ }
}
而应该进行注入
class NewsRepository(
private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
suspend fun loadNews() = withContext(defaultDispatcher) { /* ... */ }
}
原因：依赖注入的模式可以让你在测试的时候容易更换调度器 详细参考Android中简易的协程
比如这样的：
suspend fun fetchLatesNews():ListArtical{
withContext(Dispatchers.IO){
}
}
主线程调用的时候
suspend operator fun updateContent(){
val news = fetchLatesNews()
}
这样可以保证你的App是易扩展的，类挂起方法调用的时候，不需要担心线程是在哪个环境调度的，由具体实现类中的方法来确保线程调度的安全
viewModle更应该去创建一个协程，而不是去暴露一个suspend方法。 比如应该是这样：
//示例代码，viewModle内去创建一个协程
class LastestNewsViewModel{
//内部维护了一个可观察的带状态的数据
private val _uiState = MutableStateFlow<LatestNewsUiState>(LatestNewsUiState.Loading)
val uiState:StateFlow<LatestNewsUiState> = _uiState
//重点来了，这里不是一个suspend方法
fun loadNews(){
viewModleScope.lanuch{
val lastestNewsWithAuthors = getLatestNewsWithAuthors()
_uiState.valule = LastestNewUiState.Success(lastestNewsWithAuthors)
}
}
}
而不是这样的
class LastestNewsViewModel():ViewModel{
//这种是直接返回了一个suspend方法
suspend fun loadNews() = getLatestNewsWithAuthors()
}
除非不需要调用知道数据流的状态，而只需要发射一个单独的数据。（个人理解，是保持viewModle中的定义，维护一个可观察的带状态的数据，而不是直接扔原始数据出来）
应该对其他类暴露不可修改的的类型，这样所有可变类型数据的变更都集中在一个类里，如果有问题的时候，更容易调试（也是迪米特原则） 比如应该是这样的
class LastestNewsViewModel : ViewModel{
//可修改类型
private val _uiState = _MutalbeStateFlwow(LastestNewsViewModel.Loading)
//对外暴露不可修改类型数据（对外不提供修改功能）
val uiState : StateFlow<LatestNewsUiState> = _uiState
}
数据层和业务层通常需要暴露方法，去执行一次性的调用或者需要持续接收数据的变化，这时候应该提供为一次性调用提供挂起函数 或者 提供Flow来帮忙观察数据的变化操作 比如这样的：
class ExampleRepository{
//为一次性的调用提供 suspend方法
suspend fun makeNetworkRequest(){}
//为一需要观察的数据提供Flow对象
fun getExamples():Flow<Example>{}
}
最佳的实践可以使调用者通常是业务层，能够控制业务的执行和生命周期的运转，并且在需要的时候可以取消任务
在数据和业务层需要创建协程的原因可能有不几的原因，下边是一些可能的选项
示例代码：
class GetAllBooksAndAuthorsUseCase(
private val booksRepository:BooksRepository,
private val authorsRepository:AuthorsRepository,
private val defaultDispatcher:CoroutineDispatcher = Dispatchers.Default
){
suspend fun getBookdAndAuthors():BookAndAuthors{
//平行的情况需要等待结果，书籍列表和作者列表需要同时准备好之后再返回
return coroutineScope{
val books = async(defaultDispatcher){
booksRepository.getAllBooks()
}
val authors = async(defaultDispatcher){
authorsRepository.getallAuthors()
}
//准备好数据之后再返回
BookAndAuthors(books.await(),authors.await())
}
}
}
external 的 CoroutineScope ，详细可参考 协程设计模式之任务不应该被取消
参考示例代码：
class ArticalesRepository(
private val articlesDataSource: ArticlesDataSource,
private val externalScope:CoroutineScope,
private val defaultDispatcher:CoroutineDispatcher = Dispatchers.Default
){
//这个场景是这样的，即使我们离开的屏幕，也希望这个预订操作是能够被完整执行的，那么这任务斋要在外部域开启一个新的协程里来完成这wh
suspend fun bookmarkArtical(artical:Article){
externalScope.lanuch(defaultDispatcher){
articlesDataSource.bookmarkArticle(article)
}.join() //等待协程执行完毕
}
}
说明: 外部域需要被一个比当前界面的生命周期更长的一个类来创建，比如说 Application或者是一个navigatin grah的ViewModel
就像最佳实践里边的注入调度器，如果用了GlobalScope，那就是在类里边使用硬编码，可能会有以下几个负面影响
取消操作也是一种协程的操作，意思是说当协程被取消的时候，协程并没有直接被取消，除非它在 挂起 或者 有取消操作，如果你的协程是在操作一个阻塞的操作，需要确保协程是中途可以被取消的。 举个例子，如果你正在读取多个文件，需要在读取每个文件之前，检查下协程是否已经被取消了，一个检查协程是否被取消的方法就是 调用 ensureActivite方法，(或者还有isActive可用) 参考示例代码：
someScope.lanuch{
ensureActive()//检查协程是否已经被取消
readFile(file)
}
更多详细的描述信息可以参考 取消协程
如果协程抛出的异常处理不当，可能会导致你的App崩溃。如果异常出现了，就在协程里就捕获好异常并进行处理
参考示例代码：
class LoginViewModel(
private val loginRepository:LoginRepository
):ViewModel(){
fun login(username:String,token:String){
viewModleScope.lanuch{
try{
loginRepository.login(username,token)
//通知界面登录成功
}catch(error:Throwable){
//通知view 登录操作失败
}
}
}
}
更多协程异常的处理，或者其他场景需要用到CoroutineExceptionHandler，可以参考 协程异常处理
Kotlin 高级函数的特性不仅让代码可读性更强，更加简洁，而且还提高了生产效率，但是简洁的背后是有代价的，隐藏着不能被忽视的成本，特别是在低端机上，这种成本会被放大，因此我们需要去研究 kotlin 语法糖背后的魔法，选择合适的语法糖，尽量避免这些坑。
Lambda 表达式语法简洁，避免了冗长的函数声明，代码如下。
fun requestData(type: Int, call: (code: Int, type: Int) -> Unit) {
call(200, type)
}
Lambda 表达式语法虽然简洁，但是隐藏着两个性能问题。
图中标记 1 所示的地方，涉及一个字节码类型的知识点。
| 标识符 | 含义 |
|---|---|
| I | 基本类型 int |
| L | 对象类型，以分号结尾，如 Lkotlin/jvm/functions/Function2; |
Lambda 表达式 call: (code: Int, type: Int) -> Unit 作为函数参数，传递到函数中，Lambda 表达式会继承 kotlin/jvm/functions/Function2 , 每次调用都会创建一个 Function2 对象，如图中标记 2 所示的地方。
正如你所见 lambda 表达式存在装箱和拆箱的开销，会将 int 转成 Integer，之后进行一系列操作，最后会将 Integer 转成 int。
如果想要避免 Lambda 表达式函数对象的创建及装箱拆箱开销，可以使用 inline 内联函数，直接执行 lambda 表达式函数体。
Inline 修饰符
Inline 内联函数的作用：提升运行效率，调用被 inline 修饰符标记的函数，会把函数内的代码放到调用的地方。
如果阅读过 Koin 源码的朋友，应该会发现 inline 都是和 lambda 表达式和 reified 修饰符配套在一起使用的，如果只使用 inline 修饰符标记普通函数，Android Studio 也会给一个大大大的警告。
编译器建议我们在含有 lambda 表达式作为形参的函数中使用内联，既然 Inline 修饰符可以提升运行效率，为什么编译器会给我们一个警告？ 这是为了防止 inline 操作符滥用而带来的性能损失。
inline 修饰符适用于以下情况
这一小节主要介绍 Kotlin 数组，一起来看一下遍历数组都有几种方式。
forEach 遍历数组.. 、 downTo 、 until)indices 遍历数组withIndex 遍历数组forEach 遍历数组先来看看通过 forEach 遍历数组，和其他的遍历数组的方式，有什么不同。
array.forEach { value ->
}
反编译后：
Integer[] var5 = array;
int var6 = array.length;
for(int var7 = 0; var7 < var6; ++var7) {
Object element$iv = var5[var7];
int value = ((Number)element$iv).intValue();
boolean var10 = false;
}
正如你所见通过 forEach 遍历数组的方式，会创建额外的对象，并且存在装箱/拆箱开销，会占用更多的内存。
在 Kotlin 中区间表达式有三种 .. 、 downTo 、 until
.. 关键字，表示左闭右闭区间downTo 关键字，实现降序循环until 关键字，表示左闭右开区间.. 、downTo 、until
for (value in 0..size - 1) {
// case 1
}
for (value in size downTo 0) {
// case 2
}
for (value in 0 until size) {
// case 3
}
反编译后
// case 1
if (value <= var4) {
while(value != var4) {
++value;
}
}
// case 2
for(boolean var5 = false; value >= 0; --value) {
}
// case 3
for(var4 = size; value < var4; ++value) {
}
如上所示 区间表达式 ( .. 、 downTo 、 until) 除了创建一些临时变量之外，不会创建额外的对象，但是区间表达式 和 step 关键字结合起来一起使用，就会存在内存问题。
区间表达式 和 step 关键字
带 step 操作的 .. 、 downTo 、 until， 编译之后如下所示。
for (value in 0..size - 1 step 2) {
// case 1
}
for (value in 0 downTo size step 2) {
// case 2
}
反编译后：
// case 1
var10000 = RangesKt.step((IntProgression)(new IntRange(var6, size - 1)), 2);
while(value != var4) {
value += var5;
}
// case 2
var10000 = RangesKt.step(RangesKt.downTo(0, size), 2);
while(value != var4) {
value += var5;
}
带 step 操作的 .. 、 downTo 、 until 除了创建一些临时变量之外，还会创建 IntRange 、 IntProgression 对象，会占用更多的内存。
indices 遍历数组indices 通过索引的方式遍历数组，每次遍历的时候通过索引获取数组里面的元素，如下所示。
for (index in array.indices) {
}
反编译后：
for(int var4 = array.length; var3 < var4; ++var3) {
}
通过 indices 遍历数组， 编译之后的代码 ，除了创建了一些临时变量，并没有创建额外的对象。
withIndex 遍历数组withIndex 和 indices 遍历数组的方式相似，通过 withIndex 遍历数组，不仅可以获取的数组索引，同时还可以获取到每一个元素。
for ((index, value) in array.withIndex()) {
}
反编译后：
Integer[] var5 = array;
int var6 = array.length;
for(int var3 = 0; var3 < var6; ++var3) {
int value = var5[var3];
}
正如你所看到的，通过 withIndex 方式遍历数组，虽然不会创建额外的对象，但是存在装箱/拆箱的开销
总结：
forEach 遍历数组的方式，会创建额外的对象，占用内存，并且存在装箱 / 拆箱开销indices 和区间表达式 ( .. 、 downTo 、 until) 都不会创建额外的对象step 关键字结合一起使用， 会有创建额外的对象的开销，占用更多的内存withIndex 方式遍历数组，不会创建额外的对象，但是存在装箱/拆箱的开销
这一小节内容，在我之前的文章中分享过，但是这也是很多小伙伴，遇到最多的问题，所以单独拿出来在分析一次
当我们比较两个字符串，需要忽略大小写的时候，通常的写法是调用 toLowerCase() 方法或者 toUpperCase() 方法转换成大写或者小写，然后在进行比较，但是这样的话有一个不好的地方，每次调用 toLowerCase() 方法或者 toUpperCase() 方法会创建一个新的字符串，然后在进行比较。
调用 toLowerCase() 方法
fun main(args: Array<String>) {
// use toLowerCase()
val oldName = "Hi dHL"
val newName = "hi Dhl"
val result = oldName.toLowerCase() == newName.toLowerCase()
// or use toUpperCase()
// val result = oldName.toUpperCase() == newName.toUpperCase()
}
toLowerCase() 编译之后的 Java 代码
如上图所示首先会生成一个新的字符串，然后在进行字符串比较，那么 toUpperCase() 方法也是一样的如下图所示。
toUpperCase() 编译之后的 Java 代码
这里有一个更好的解决方案，使用 equals 方法来比较两个字符串，添加可选参数 ignoreCase 来忽略大小写，这样就不需要分配任何新的字符串来进行比较了。
fun main(args: Array<String>) {
val oldName = "hi DHL"
val newName = "hi dhl"
val result = oldName.equals(newName, ignoreCase = true)
}
equals 编译之后的 Java 代码
使用 equals 方法并没有创建额外的对象，如果遇到需要比较字符串的时候，可以使用这种方法，减少额外的对象创建。
by lazy 作用是懒加载，保证首次访问的时候才初始化 lambda 表达式中的代码， by lazy 有三种模式。
LazyThreadSafetyMode.NONE 仅仅在单线程LazyThreadSafetyMode.SYNCHRONIZED 在多线程中使用LazyThreadSafetyMode.PUBLICATION 不常用LazyThreadSafetyMode.SYNCHRONIZED 是默认的模式，多线程中使用，可以保证线程安全，但是会有 double check + lock 性能开销，代码如下图所示。
如果是在主线程中使用，和初始化相关的逻辑，建议使用 LazyThreadSafetyMode.NONE 模式，减少不必要的开销。
仓库 KtKit 是用 Kotlin 语言编写的小巧而实用的工具库，包含了项目中常用的一系列工具, 正在逐渐完善中，如果你有兴趣，想邀请你和我一起来完善这个库。
在JS中，每个函数的 this 是在调用时被绑定的，完全取决于函数的调用位置（也就是函数的调用方法）。与声明的位置无关。
理解调用位置：调用位置就是函数在执行时被调用的位置（而不是声明的位置）。
要找到函数的调用位置，最重要是找到函数的调用栈（就是为了到达当前执行位置所调用的所有函数），而函数的调用位置就是当前所在栈顶的前一个位置。
举个栗子
function baz() {
// 当前调用栈是：baz
// 因此，当前调用位置是全局作用域,浏览器下位window，node下为global
console.log( "baz" );
bar(); // <-- bar 的调用位置
}
function bar() {
// 当前调用栈是 baz -> bar
// 因此，当前调用位置在 baz 中
console.log( "bar" );
foo(); // <-- foo 的调用位置
}
function foo() {
// 当前调用栈是 baz -> bar -> foo
// 因此，当前调用位置在 bar 中
console.log( "foo" );
}
baz(); // <-- baz 的调用位置
函数的this在js引擎执行时，会根据一些规则去绑定到上下文中。
默认绑定应用在最常用的函数调用类型：独立函数调用上。可以把这条规则看作是无法应用其他规则时的默认规则。
function foo() {
//默认规则下，this指向全局对象，即顶层作用域
console.log( this.a );
}
var a = 2;
foo()//2
怎么知道这里应用了默认绑定呢？可以通过分析调用位置来看看 foo()是如何调用的。在代码中，foo() 是直接使用不带任何修饰的函数引用进行调用的，因此只能使用
默认绑定，无法应用其他规则。
严格模式下，不能将全局对象用于默认绑定，因此 this 会绑定到undefined，在浏览器和node中是一样的。
这里有一个微妙但是非常重要的细节，虽然this的绑定规则完全取决于调用位置，但是只有 foo() 运行在非严格模式下时，默认绑定才能绑定到全局对象；在严格模式下调用
foo() 则不影响默认绑定：
function foo() {
//在非严格模式下运行
console.log( this.a );
}
var a = 2;
(function(){
//在严格模式下调用
"use strict";
foo(); // 2
})();
以上代码混合使用了严格模式和非严格模式，因此foo的this不受严格模式影响，但混合使用严格模式是不提倡的，幸运的是es6默认是严格模式。
当一个函数的引用被一个对象持有时（作为该对象的方法），那么该函数的this就绑定在了这个对象上。通常这在声明一个对象，并将一个已声明的函数作为该对象属性时触发。
function foo() {
console.log( this.a );
}
var obj = {
a: 2,
foo: foo
};
obj.foo(); // 2
在obj对象声明时，foo作为obj的一个属性，因此其this被隐式绑定到了obj上，因为obj持有对foo的引用。
在对象属性引用链中，只有上一层或者说最后一层在调用位置中起作用。
举个栗子
function foo() {
console.log( this.a );
}
// obj2.foo引用了foo函数
var obj2 = {
a: 42,
foo: foo
};
//obj1.obj2 引用了obj1对象
var obj1 = {
a: 2,
obj2: obj2
};
//但是foo中的this永远指向直接持有它的引用的那个对象，即obj2
obj1.obj2.foo(); // 42
一个函数的引用被一个对象持有，而这个对象的引用又被另一个对象持有，另一个对象的引用再被另一个对象持有...，这就像一条项链，但是不管层次有多深，这个函数的this永远指向直接持有它的引用的那个对象。
一个最常见的 this 绑定问题就是被隐式绑定的函数会丢失绑定对象，也就是说它会应用默认绑定，从而把 this 绑定到全局对象或者 undefined 上，取决于是否是严格模式。
function foo() {
console.log( this.a );
}
var obj = {
a: 2,
foo: foo
};
var bar = obj.foo; // 函数别名！
var a = "oops, global"; // a 是全局对象的属性
bar(); // "oops, global"
虽然bar 是 obj.foo 的一个引用，但是实际上，它引用的是 foo 函数本身，因此==此时的bar()其实是一个不带任何修饰的函数调用，因此应用了默认绑定==。
再看一个栗子，发生在传入回调函数时
function foo() {
console.log( this.a );
}
function doFoo(fn) {
// fn 其实引用的是 foo
fn(); // <-- 调用位置！,很明显，这是个默认绑定
}
var obj = {
a: 2,
foo: foo
};
var a = "oops, global"; // a 是全局对象的属性
doFoo( obj.foo ); // "oops, global"
参数传递其实就是一种隐式赋值，因此我们传入函数时也会被隐式赋值，所以结果和上一
个例子一样。
如果把函数传入语言内置的函数而不是传入你自己声明的函数，会发生什么呢？结果是一
样的，没有区别：
function foo() {
console.log( this.a );
}
var obj = {
a: 2,
foo: foo
};
var a = "oops, global"; // a 是全局对象的属性
setTimeout( obj.foo, 100 ); // "oops, global"
以上的栗子再次向我们证明了，函数this是在运行时绑定的，与声明位置无关。
除此之外，还有一种情
况 this 的行为会出乎我们意料：调用回调函数的函数可能会修改 this。在一些流行的
JavaScript 库中事件处理器常会把回调函数的 this 强制绑定到触发事件的 DOM 元素上。如onclick，addEventListener，会将this绑定在dom元素 上。
显示绑定就是利用js提供的一些内置函数，将this绑定到指定的上下文中。
具体点说，可以使用函数的 call(..) 和
apply(..) 方法。严格来说，JavaScript 的宿主环境有时会提供一些非常特殊的函数，它们
并没有这两个方法。但是这样的函数非常罕见，JavaScript 提供的绝大多数函数以及你自
己创建的所有函数都可以使用 call(..) 和 apply(..) 方法。
function foo() {
console.log( this.a );
}
var obj = {
a:2
};
//执行时，foo的this就是obj了
foo.call( obj ); // 2
如果你传入了一个原始值（字符串类型、布尔类型或者数字类型）来当作 this 的绑定对象，这个原始值会被转换成它的对象形式（也就是 new String(..)、new Boolean(..) 或者
new Number(..)）。这通常被称为“装箱”。
显式绑定仍然无法解决我们之前提出的丢失绑定问题。
硬绑定是显式绑定的一个变种。
function foo() {
console.log( this.a );
}
var obj = {
a:2
};
var bar = function() {
foo.call( obj );
};
bar(); // 2
setTimeout( bar, 100 ); // 2
// 硬绑定的 bar 不可能再修改它的 this
bar.call( window ); // 2
很好理解，就是在函数运行时再把这个函数绑定到我们制定的this上。
硬绑定的典型应用场景就是创建一个包裹函数，负责接收参数并返回值
function foo(something) {
console.log( this.a, something );
return this.a + something;
}
var obj = {
a:2
};
var bar = function() {
return foo.apply( obj, arguments );
};
var b = bar( 3 ); // 2 3
console.log( b ); // 5
另一种使用方法是创建一个可以重复使用的辅助函数
function foo(something) {
console.log( this.a, something );
return this.a + something;
}
// 简单的辅助绑定函数
function bind(fn, obj) {
return function() {
return fn.apply( obj, arguments );
};
}
var obj = {
a:2
};
var bar = bind( foo, obj );
var b = bar( 3 ); // 2 3
console.log( b ); // 5
由于硬绑定是一种非常常用的模式，所以 ES5 提供了内置的方法 Function.prototype.bind，bind(..) 会返回一个硬编码的新函数，它会把你指定的参数设置为 this 的上下文并调用原始函数
function foo(something) {
console.log( this.a, something );
return this.a + something;
}
var obj = {
a:2
};
var bar = foo.bind( obj );
var b = bar( 3 ); // 2 3
console.log( b ); // 5
第三方库的许多函数，以及 JavaScript 语言和宿主环境中许多新的内置函数，都提供了一
个可选的参数，通常被称为"上下文"（context），其作用和 bind(..) 一样，确保你的回调函数使用指定的 this。这些函数实际上就是通过 call(..) 或者 apply(..) 实现了显式绑定。
function foo(el) {
console.log( el, this.id );
}
var obj = {
id: "awesome"
};
// 调用 foo(..) 时把 this 绑定到 obj
[1, 2, 3].forEach( foo, obj );
// 1 awesome 2 awesome 3 awesome
使用new来调用函数时（函数也是对象），或者说发生构造函数调用时，会自动执行下面的操作：
[[Prototype]] 连接。this。new表达式中的函数调用会自动返回这个新对象。function foo(a) {
this.a = a;
}
var bar = new foo(2);
console.log( bar.a ); // 2
使用 new 来调用foo(..)时，我们会构造一个新对象并把它绑定到 foo(..) 调用中的 this上。ne是最后一种可以影响函数调用时 this 绑定行为的方法，我们称之为 new 绑定。
实际判断时，一个场景可能存在多个规则，因此判定时需要由高优先级往下判定。
可以按照下面的顺序来进行判断：
函数是否在new 中调用（new 绑定）？如果是的话 this 绑定的是新创建的对象。
函数是否通过call、apply（显式绑定）或者硬绑定调用？如果是的话，this 绑定的是
指定的对象。
this 绑定的是那个上下文对象。
undefined，否则绑定到全局对象。
在某些场景下
this的绑定行为会出乎意料，你认为应当应用其他绑定规则时，实际上应用的可能是默认绑定规则。
1. 将null或undefined作为this进行显式绑定
2. 赋值表达式的返回值
function foo() {
console.log( this.a );
}
var a = 2;
var o = { a: 3, foo: foo };
var p = { a: 4 };
o.foo(); // 3
(p.foo = o.foo)(); // 2
赋值表达式 p.foo = o.foo 的返回值是目标函数的引用，因此调用位置是 foo() 而不是
p.foo() 或者 o.foo()。根据我们之前说过的，这里会应用默认绑定。
3.软绑定
硬绑定很好地解决了隐式绑定可能会无意间将this绑定在顶级作用对象（严格模式下，为undefined）上的问题，但降低了其灵活性，我们要的结果是，保留其灵活性，既能绑定到指定的this上，但又不想让它默认绑定到全局对象上，解决方法就是软绑定。
通俗的说，就是有一个默认值，指定了绑定对象的话就绑定到指定的对象上，否则就绑定到默认对象。
//实现和硬绑定相同的效果，同时保留隐式绑定或者显式绑定修改 this 的能力。
if (!Function.prototype.softBind) {
Function.prototype.softBind = function(obj) {
var fn = this;
// 捕获所有 curried 参数
var curried = [].slice.call( arguments, 1 );
var bound = function() {
return fn.apply(
(!this || this === (window || global)) ?
obj : this,
curried.concat.apply( curried, arguments )
);
};
bound.prototype = Object.create( fn.prototype );
return bound;
};
}
如果要判断一个运行中函数的 this 绑定，就需要找到这个函数的直接调用位置。
找到之后就可以顺序应用下面这四条规则来判断 this 的绑定对象。
new 调用？绑定到新创建的对象。call 或者 apply（或者 bind）调用？绑定到指定的对象。undefined，否则绑定到全局对象。箭头函数不会以上四条标准的绑定规则，而是根据当前的词法作用域来决定this，具体来说，箭头函数会继承外层函数调用的 this 绑定（无论this绑定到什么）。这和我们创建一个变量来保存当前的this的效果是一样的。
我们以下面这个数组为例，我们首先要明白题目中的第2大的元素指的是4，第3大的元素指的是3，也就是说指的是去重后的数组中的排序。我们之所以要建立一个哈希表是因为我们需要知道第k大和第m大的元素总共出现了几次，因为最后需要进行求和。
[1, 2, 4, 4, 3, 5]
本题博主采用的是哈希表 + 堆排序的方式来求解。
const map = new Map();
for (let v of arr) {
if (!map.get(v)) {
map.set(v,1);
} else {
map.set(v,map.get(v) + 1)
}
}
const singleNums = [...new Set(arr)]
// 堆的尺寸指的是去重后的数组
let heapSize = singleNums.length;
buildMaxHeap(singleNums, heapSize);
function buildMaxHeap(arr, heapSize) {
// 从最后一个叶子节点开始进行堆化
for (let i = Math.floor(heapSize / 2) - 1; i >= 0; i--) {
// 进行堆化
maxHeapify(arr, i, heapSize);
}
}
function maxHeapify(arr, i, heapSize) {
// 首先假定第i个是最大的
let max = i;
let leftChild = 2 * i + 1;
let rightChild = 2 * i + 2;
// 如果下标不越界，并且左孩子的比最大值大则更新最大值
if (leftChild < heapSize && arr[leftChild] > arr[max]) {
max = leftChild;
}
if (rightChild < heapSize && arr[rightChild] > arr[max]) {
max = rightChild;
}
if (max !== i) {
swap(arr, i, max);
// 上来的元素的位置往下要接着堆化
maxHeapify(arr, max, heapSize);
}
}
// 交换数组中两个元素
function swap(nums, a, b) {
let temp = nums[a];
nums[a] = nums[b];
nums[b] = temp;
}
function target(arr, x) {
for (let i = 0; i < x - 1; i++) {
// 交换不需要进行堆化的元素
if (i === min - 1) result.push(arr[0]);
swap(arr, 0, arr.length - 1 - i);
arr
heapSize--;
maxHeapify(arr, 0, heapSize)
}
}
target(singleNums, max)
result.push(singleNums[0]);
return result.reduce((pre,cur) => pre + cur * map.get(cur),0)
/*
* @Author: FaithPassion
* @Date: 2021-07-09 10:06:00
* @LastEditTime: 2021-08-28 11:09:30
* @Description: 找出数组中第k大和第m大的数字相加之和
* let arr = [1,2,4,4,3,5], k = 2, m = 4
* findTopSum(arr, k, m); // 第2大的数是4，出现2次，第4大的是2，出现1次，所以结果为10
*/
/**
* @description: 采用堆排序求解
* @param {*} arr 接收一个未排序的数组
* @param {*} k 数组中第k大的元素
* @param {*} m 数组中第m大的元素
* @return {*} 返回数组中第k大和第m大的数字相加之和
*/
function findTopSum(arr, k, m) {
function buildMaxHeap(arr, heapSize) {
// 从最后一个叶子节点开始进行堆化
for (let i = Math.floor(heapSize / 2) - 1; i >= 0; i--) {
// 进行堆化
maxHeapify(arr, i, heapSize);
}
}
// 最大堆化函数
function maxHeapify(arr, i, heapSize) {
// 首先假定第i个是最大的
let max = i;
let leftChild = 2 * i + 1;
let rightChild = 2 * i + 2;
// 如果下标不越界，并且左孩子的比最大值大则更新最大值
if (leftChild < heapSize && arr[leftChild] > arr[max]) {
max = leftChild;
}
if (rightChild < heapSize && arr[rightChild] > arr[max]) {
max = rightChild;
}
if (max !== i) {
swap(arr, i, max);
// 上来的元素的位置往下要接着堆化
maxHeapify(arr, max, heapSize);
}
}
// 交换数组中两个元素
function swap(nums, a, b) {
let temp = nums[a];
nums[a] = nums[b];
nums[b] = temp;
}
let result = []
// k和m中较大的
let max = Math.max(k, m);
// k和m中较小的
let min = Math.min(k, m);
const map = new Map();
for (let v of arr) {
if (!map.get(v)) {
map.set(v,1);
} else {
map.set(v,map.get(v) + 1)
}
}
// 求第x大的元素
function target(arr, x) {
for (let i = 0; i < x - 1; i++) {
// 交换不需要进行堆化的元素
if (i === min - 1) result.push(arr[0]);
swap(arr, 0, arr.length - 1 - i);
arr
heapSize--;
maxHeapify(arr, 0, heapSize)
}
}
const singleNums = [...new Set(arr)]
// 堆的大小
let heapSize = singleNums.length;
// 构建大顶堆
buildMaxHeap(singleNums, heapSize);
target(singleNums, max)
result.push(singleNums[0]);
return result.reduce((pre,cur) => pre + cur * map.get(cur),0)
}
findTopSum([1, 2, 4, 4, 3, 5], 2, 4)
HTTP协议是一种无状态协议，即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；Session和Cookie的主要目的就是为了弥补HTTP的无状态特性。
cookie是服务器发送到Web浏览器的一小块数据，服务器发送到浏览器的Cookie，浏览器会进行存储，并与下一个请求一起发送到服务器，用于判断请求是否来自同一个浏览器，例如用户保持登录状态。
name：表示cookie的名称
value：cookie对应的值。
domain：该字段为可以访问此cookie的域名，即cookie在哪个域有效
path: cookie的有效路径。Domain和Path标识共同定义了Cookie的作用域：即 Cookie应该发送给哪些URL。
size：cookie的大小(不超过4kb)
expires/Max-Age：有效期。expires是cookie被删除的时间戳；Max-Age有效期的时间戳(服务器返回的时间,和客户端可能存在误差)，默认为-1，页面关闭立即失效。
HttpOnly： 设置为true时不允许通过脚本document.cookie去更改cookie值，也不可获取，能有效的防止xss攻击。但发送请求仍会携带cookie。
secure： 标记为Secure的Cookie只应通过被HTTPS协议加密过的请求发送给服务端，可以保护Cookie在浏览器和Web服务器间的传输过程中不被窃取和篡改。
SameSite： 该属性可以让Cookie在跨站请求时不会被发送，用来防止CSRF攻击和用户追踪。
Strict：完全禁止第三方cookie，跨站点时，任何情况下都不会发送cookie。也就是说，只有当前网页的URL与请求目标一致，才会带上cookie。
Lax： 大多数情况不发送第三方cookie，但导航到目标网址的get请求(链接，预加载请求，GET表单)除外。
None： 网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。
安全问题可以看我总结的这篇：前端安全—常见的攻击方式及防御方法
Session是保存在服务器记录客户状态的机制。客户端浏览器访问服务器的时候，服务器会为这次请求开辟一块内存空间，这个对象便是Session 对象，存储结构为 ConcurrentHashMap。Session 弥补了 HTTP 无状态特性，服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录。
session_id，写入要不干湖的cookiesession_id传回服务器session_id，找到前期保存的数据，由此得知用户的身份。hashtable的数据结构来储存，能支持任何类型的对象内存中，cookie生命周期随浏览器的关闭而结束。如果在浏览器中设置了cookie的过期时间，cookie被保存在硬盘中，关闭浏览器后，cookie数据仍然存在，知道过期时间才消失。HTML5提供了两种在客户端存储数据的新方法：localStorage和sessionStorage，挂载在window对象下。
webStorage是本地存储，数据不是由服务器请求传递的。从而它可以存储大量的数据，而不影响网站的性能。
Web Storage的目的是为了克服由cookie带来的一些限制，当数据需要被严格控制在客户端上时，无须持续地将数据发回服务器。比如客户端需要保存的一些用户行为或数据，或从接口获取的一些短期内不会更新的数据，我们就可以利用Web Storage来存储。
生命周期是永久性的。localStorage存储的数据，以“键值对”的形式存在。即使关闭浏览器，也不会让数据消失，除非主动的去删除数据。如果想设置失效时间，需自行封装。localStorage 在所有同源窗口中都是共享的。
sessionStorage保存的数据用于浏览器的一次会话，当会话结束（关闭浏览器或者页面），数据被清空；SessionStorage的属性和方法与LocalStorage完全一样。
sessionStorage特别的一点在于，即便是相同域名下的两个页面，只要它们不在同一个浏览器窗口中打开，那么它们的 sessionStorage 内容便无法共享；
localStorage 在所有同源窗口中都是共享的； cookie也是在所有同源窗口中都是共享的。除了保存期限的长短不同，
IndexedDB是一个运行在浏览器上的非关系型数据库，储存空间大，用于客户端存储大量结构化数据(包括文件和blobs) 。可以存字符串，也可以存二进制数据，数据以"键值对"的形式保存，不能有重复，否则会报错。除非被清理，否则一直存在。
互联网服务离不开用户认证。一般流程看上面session的创建。
Token的定义：
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。token其实说的更通俗点可以叫暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据操作。
简单 token 的组成：
uid(用户唯一的身份标识)time(当前时间戳)sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）token 的身份验证流程：
token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里tokentoken ，如果验证成功，就向客户端返回请求的数据使用Token的目的：
Token的目的是为了减少频繁的查询数据库，减轻服务器的压力。基于Token用户认证是一种服务器无状态的认证方式，服务器不存放数据，所有数据都保存在客户端，每次请求都发回服务器，用解析token的时间来换取session的储存空间，从而减轻服务器的压力，减少频繁的查询数据库。token 完全由应用管理，所以它可以避开同源策略。
JWT的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户,以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。
Header（头部）：
Header部分是一个JSON对象，描述JWT的元数据，使用Base64编码转成字符串。
Payload（负载）：
Payload是一个JSON对象，用来存放实际需要传递的数据，使用Base64编码转成字符串。
Signature（签名）：
Signature是对前两部分的签名，防止数据篡改。首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用Header里面指定的签名算法（默认是 HMAC SHA256）产生签名。用"点"（.）分隔拼接成字符串后返回给用户。
Token，或者更改Token的权限。即一旦JWT签发了，在到期之前始终有效，除非服务器部署额外的逻辑JWT本身包含了认证信息，为保证安全性，有效期应设置得比较短JWT应使用HTTPS协议传输在现代的工作生活中，手机早已不是单纯的通信工具了，它更像是一个集办公，娱乐，消费的终端，潜移默化的成为了我们生活的一部分。所以作为 iOS 开发者的我们，在日常的开发中，也早已不是处理显示零星的数据这么简单，为了流量往往我们需要在 App 里显示大量有价值的信息来吸引用户，如何优雅的显示这些海量的数据，考量的就是你的个人经验了。
正如大多数 iOS 开发人员所知，显示滚动数据是构建移动应用中常见的任务，Apple 的 SDK 提供了 UITableView 和 UICollectionVIew 这俩大组件来帮助执行这样的任务。但是，当需要显示大量数据时，确保平滑如丝的滚动可能会非常的棘手。所以今天正好趁这个机会，和大家分享一下处理大量可滚动数据方面的个人经验。
在这篇文章中，你将会学到以下内容：
1.让你的 App 可以无限滚动（infinite scrolling），并且滚动数据无缝加载
2.让你的 App 数据滚动时避免卡顿，实现平滑如丝的滚动
3.异步存储（Cache）和获取图像，来使你的 App 具有更高的响应速度
提到列表分页，相信大家第一个想到的就是 MJRefresh，用于上拉下拉来刷新数据，当滚动数据到达底部的时候向服务器发送请求，然后在控件底部显示一个 Loading 动画，待请求数据返回后，Loading 动画消失，由 UITableView 或者 UICollectionView 控件继续加载这些数据并显示给用户，效果如下图所示：
在这种情况下就造成了一种现象，那就是 App 向服务器请求数据到数据返回这段时间留下了一个空白，如果在网络差的情况下，这段空白的时间将会持续，这给人的体验会很不好。那该如何去避免这种现象呢！或者说我们能否去提前获取到其余的数据，在用户毫无感知的情况下把数据请求过来，看上去就像无缝加载一样呢！
答案当然是肯定的！
为了改善应用程序体验，在 iOS 10 上，Apple 对 UICollectionView 和 UITableView 引入了 Prefetching API，它提供了一种在需要显示数据之前预先准备数据的机制，旨在提高数据的滚动性能。
首先，我先和大家介绍一个概念：无限滚动，无限滚动是可以让用户连续的加载内容，而无需分页。在 UI 初始化的时候 App 会加载一些初始数据，然后当用户滚动快要到达显示内容的底部时加载更多的数据。
多年来，像 Instagram, Twitter 和 Facebook 这样的社交媒体公司都使这种技术。如果查看他们的 App ，你就可以看到无限滚动的实际效果，这里我就给大伙展示下 Instagram 的效果吧！
由于 Instagram 的 UI 过于复杂，在这我就不去模仿实现了，但是我模仿了它的加载机制，同样的实现了一个简单的数据无限滚动和无缝加载的效果。
简单的说下我的思路：
先自定义一个 Cell 视图，这个视图由一个 UILabel 和 一个 UIImageView 构成，用于显示文本和网络图片；然后模拟网络请求来获取数据，注意该步骤一定是异步执行的；最后用 UITableView 来显示返回的数据，在 viewDidLoad 中先请求网络数据来获取一些初始化数据，然后再利用 UITableView 的 Prefetching API 来对数据进行预加载，从而来实现数据的无缝加载。
那关于无限滚动该如何实现呢！其实这个无限滚动并不是真正意义上的永无止尽，严格意义上来讲它是有尽头的，只不过这个功能背后的数据是不可估量的，只有大量的数据做支持才能让应用一直不断的从服务端获取数据。
正常情况下，我们在构建 UITableView 这个控件的时候，需要对它的行数（numsOfRow）做一个初始化，这个行数对我们实现无限加载和无缝加载是一个很关键的因素，假设我们每次根据服务端返回的数据量去更新 UITableView 的行数并 Reload，那我之前说的 Prefetching API 在这种情况下就失去作用了，因为它起作用的前提是要保证预加载数据时 UITableView 当前的行数要小于它的总行数。当然前者也可以实现数据加载，但它的效果就不是无缝加载，它在每次加载数据的时候都会有一个 Loading 等待的时间。
回到我上面所说的无限滚动, 其实实现起来并不难，正常情况下，我们向服务端请求大量相同类型的数据的时候，都会提供一个接口，我称之为分页请求接口，该接口在每次数据返回的时候，都会告诉客户端总共有多少页数据，每页的数据量是多少，当前是第几页，这样我们就能计算出来总共的数据有多少，而这就是 UITableView 的总行数。
响应数据的示范如下（为清楚起见，它仅显示与分页有关的字段）：
{
"has_more": true,
"page": 1,
"total": 84,
"items": [
...
...
]
}
下面，我就用代码来一步步的实现它吧！
由于没有找到合适的分页测试接口，于是我自己模拟一了一个分页请求接口，每次调用该接口的时候都延时 2s 来模拟网络请求的状态，代码如下：
func fetchImages() {
guard !isFetchInProcess else {
return
}
isFetchInProcess = true
// 延时 2s 模拟网络环境
print("+++++++++++ 模拟网络数据请求 +++++++++++")
DispatchQueue.global().asyncAfter(deadline: DispatchTime.now() + 2) {
print("+++++++++++ 模拟网络数据请求返回成功 +++++++++++")
DispatchQueue.main.async {
self.total = 1000
self.currentPage += 1
self.isFetchInProcess = false
// 初始化 30个 图片
let imagesData = (1...30).map {
ImageModel(url: baseURL+"\($0).png", order: $0)
}
self.images.append(contentsOf: imagesData)
if self.currentPage > 1 {
let newIndexPaths = self.calculateIndexPathsToReload(from: imagesData)
self.delegate?.onFetchCompleted(with: newIndexPaths)
} else {
self.delegate?.onFetchCompleted(with: .none)
}
}
}
}数据回调处理：
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
...
tableView.prefetchDataSource = self
...
// 模拟请求图片
viewModel.fetchImages()
}然后，你需要实现 UITableViewDataSourcePrefetching 的协议，它的协议里包含俩个函数：
// this protocol can provide information about cells before they are displayed on screen.
@protocol UITableViewDataSourcePrefetching <NSObject>
@required
// indexPaths are ordered ascending by geometric distance from the table view
- (void)tableView:(UITableView *)tableView prefetchRowsAtIndexPaths:(NSArray<NSIndexPath *> *)indexPaths;
@optional
// indexPaths that previously were considered as candidates for pre-fetching, but were not actually used; may be a subset of the previous call to -tableView:prefetchRowsAtIndexPaths:
- (void)tableView:(UITableView *)tableView cancelPrefetchingForRowsAtIndexPaths:(NSArray<NSIndexPath *> *)indexPaths;
@end第一个函数会基于当前滚动的方向和速度对接下来的 IndexPaths 进行 Prefetch，通常我们会在这里实现预加载数据的逻辑。
第二个函数是一个可选的方法，当用户快速滚动导致一些 Cell 不可见的时候，你可以通过这个方法来取消任何挂起的数据加载操作，有利于提高滚动性能, 在下面我会讲到。
实现这俩个函数的逻辑代码为：
extension ViewController: UITableViewDataSourcePrefetching {
// 翻页请求
func tableView(_ tableView: UITableView, prefetchRowsAt indexPaths: [IndexPath]) {
let needFetch = indexPaths.contains { $0.row >= viewModel.currentCount}
if needFetch {
// 1.满足条件进行翻页请求
indicatorView.startAnimating()
viewModel.fetchImages()
}
for indexPath in indexPaths {
if let _ = viewModel.loadingOperations[indexPath] {
return
}
if let dataloader = viewModel.loadImage(at: indexPath.row) {
print("在 \(indexPath.row) 行 对图片进行 prefetch ")
// 2 对需要下载的图片进行预热
viewModel.loadingQueue.addOperation(dataloader)
// 3 将该下载线程加入到记录数组中以便根据索引查找
viewModel.loadingOperations[indexPath] = dataloader
}
}
}
func tableView(_ tableView: UITableView, cancelPrefetchingForRowsAt indexPaths: [IndexPath]){
// 该行在不需要显示的时候，取消 prefetch ，避免造成资源浪费
indexPaths.forEach {
if let dataLoader = viewModel.loadingOperations[$0] {
print("在 \($0.row) 行 cancelPrefetchingForRowsAt ")
dataLoader.cancel()
viewModel.loadingOperations.removeValue(forKey: $0)
}
}
}
}最后，再加上俩个有用的方法该功能就大功告成了：
见证时刻的奇迹到了，请看效果：
好了，到这里我就简单的实现了 UITableView 无尽滚动和对数据无缝加载的效果，你学会了吗？
当你遇到滚动卡顿的应用程序时，通常是由于任务长时间运行阻碍了 UI 在主线程上的更新，想让主线程有空来响应这类更新事件，第一步就是要将消耗时间的任务交给子线程去执行，避免在获取数据时阻塞主线程。
苹果提供了很多为应用程序实现并发的方式，例如 GCD，我在这里对 Cell 上的图片进行异步加载使用的就是它。
代码如下：
class DataLoadOperation: Operation {
var image: UIImage?
var loadingCompleteHandle: ((UIImage?) -> ())?
private var _image: ImageModel
private let cachedImages = NSCache<NSURL, UIImage>()
init(_ image: ImageModel) {
_image = image
}
public final func image(url: NSURL) -> UIImage? {
return cachedImages.object(forKey: url)
}
override func main() {
if isCancelled {
return
}
guard let url = _image.url else {
return
}
downloadImageFrom(url) { (image) in
DispatchQueue.main.async { [weak self] in
guard let ss = self else { return }
if ss.isCancelled { return }
ss.image = image
ss.loadingCompleteHandle?(ss.image)
}
}
}
// Returns the cached image if available, otherwise asynchronously loads and caches it.
func downloadImageFrom(_ url: NSURL, completeHandler: @escaping (UIImage?) -> ()) {
// Check for a cached image.
if let cachedImage = image(url: url) {
DispatchQueue.main.async {
print("命中缓存")
completeHandler(cachedImage)
}
return
}
URLSession.shared.dataTask(with: url as URL) { data, response, error in
guard
let httpURLResponse = response as? HTTPURLResponse, httpURLResponse.statusCode == 200,
let mimeType = response?.mimeType, mimeType.hasPrefix("image"),
let data = data, error == nil,
let _image = UIImage(data: data)
else { return }
// Cache the image.
self.cachedImages.setObject(_image, forKey: url, cost: data.count)
completeHandler(_image)
}.resume()
}
}那具体如何使用呢！别急，听我娓娓道来，这里我再给大家一个小建议，大家都知道 UITableView 实例化 Cell 的方法是：tableView:cellForRowAtIndexPath: ，相信很多人都会在这个方法里面去进行数据绑定然后更新 UI，其实这样做是一种比较低效的行为，因为这个方法需要为每个 Cell 调用一次，它应该快速的执行并返回重用 Cell 的实例，不要在这里去执行数据绑定，因为目前在屏幕上还没有 Cell。我们可以在 tableView:willDisplayCell:forRowAtIndexPath: 这个方法中进行数据绑定，这个方法在显示cell之前会被调用。
为每个 Cell 执行下载任务的实现代码如下：
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
guard let cell = tableView.dequeueReusableCell(withIdentifier: "PreloadCellID") as? ProloadTableViewCell else {
fatalError("Sorry, could not load cell")
}
if isLoadingCell(for: indexPath) {
cell.updateUI(.none, orderNo: "\(indexPath.row)")
}
return cell
}
func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) {
// preheat image ，处理将要显示的图像
guard let cell = cell as? ProloadTableViewCell else {
return
}
// 图片下载完毕后更新 cell
let updateCellClosure: (UIImage?) -> () = { [unowned self] (image) in
cell.updateUI(image, orderNo: "\(indexPath.row)")
viewModel.loadingOperations.removeValue(forKey: indexPath)
}
// 1\. 首先判断是否已经存在创建好的下载线程
if let dataLoader = viewModel.loadingOperations[indexPath] {
if let image = dataLoader.image {
// 1.1 若图片已经下载好，直接更新
cell.updateUI(image, orderNo: "\(indexPath.row)")
} else {
// 1.2 若图片还未下载好，则等待图片下载完后更新 cell
dataLoader.loadingCompleteHandle = updateCellClosure
}
} else {
// 2\. 没找到，则为指定的 url 创建一个新的下载线程
print("在 \(indexPath.row) 行创建一个新的图片下载线程")
if let dataloader = viewModel.loadImage(at: indexPath.row) {
// 2.1 添加图片下载完毕后的回调
dataloader.loadingCompleteHandle = updateCellClosure
// 2.2 启动下载
viewModel.loadingQueue.addOperation(dataloader)
// 2.3 将该下载线程加入到记录数组中以便根据索引查找
viewModel.loadingOperations[indexPath] = dataloader
}
}
}对预加载的图片进行异步下载（预热）：
取消 Prefetch 时，cancel 任务，避免造成资源浪费
经过这般处理，我们的 UITableView 滚动起来肯定是如丝般顺滑，小伙伴们还等什么，还不赶紧试一试。
虽然我在上面对我的应用增加了并发操作，但是我一看 Xcode 的性能分析，我不禁陷入了沉思，我的应用程序太吃内存了，假如我不停的刷，那我的手机应该迟早会把我的应用给终止掉，下图是我刷到 200 行的时候的性能分析图：
内存
磁盘
可以看到我的应用的性能分析很不理想，究其原因在于我的应用里显示了大量的图片资源，每次来回滚动的时候，都会重新去下载新的图片，而没有对图片做缓存处理。
所以，针对这个问题，我为我的应用加入了缓存 NSCache 对象，来对图片做一个缓存，具体代码实现如下：
class ImageCache: NSObject {
private var cache = NSCache<AnyObject, UIImage>()
public static let shared = ImageCache()
private override init() {}
func getCache() -> NSCache<AnyObject, UIImage> {
return cache
}
}在下载开始的时候，检查有没有命中缓存，如果命中则直接返回图片，否则重新下载图片，并添加到缓存中：
有了缓存的加持后，再用 Xcode 来查看我的应用的性能，就会发现内存和磁盘的占用已经下降了很多：
内存
关于图片缓存的技术，这里只是用了最简单的一种，外面很多开源的图片库都有不同的缓存策略，感兴趣的可以去 GitHub 上学习一下它们的源码，我在这里就不做赘述了。
终于写完了，长舒了一口气，这篇文章的篇幅有点长，主要是我花了一点时间做调研，然后看到这个知识点想给大家讲一下，看到那个知识点也想给大家讲一下，最终引经据典（东拼西凑）完成了这篇文章，希望大家能够喜欢 ：）。
Flutter 作为火热的跨端工具包，在 github 上超过 120k 的关注量，可见一斑。
基于目前本人正在学习 Flutter 的路上，会将整个学习的过程记录下来。
本博文主要讲解环境的搭建，先把项目搭建好，跑通 demo 才有玩下去的必要和成就感，你说是吧？
macOS Big Sur 版本 11.2 芯片 Apple M1
磁盘空间：> 2.8 GB （要求的最小的空间）
$SHELL
echo $SHELL
/bin/bash
⚠️ 之后出现并解决的问题都是基于本人的环境
通过官网下载安装包。
将安装包放到自己想存放的地方。这里，我放在 文稿 -> sdk 方便管理，然后解压下载包。
配置 flutter 的 PATH 环境变量，格式如下：
export PATH=$PATH:${pwd}/flutter/bin
或
export PATH=${pwd}/flutter/bin:$PATH
这里我需要编辑 ~/.bash_profile 文件，添加下面这行内容：
export PATH=/Users/jimmy/Documents/sdk/flutter/bin:$PATH
作为一个前端开发者，比较偏向 VS code，直接安装其稳定版即可。
因为需要调试安卓平台，还需要安装编辑器 Android Studio。 Android Studio 为 Flutter 提供了一个完整的集成开发环境。
不管 VS code 还是 Android Studio 都需要安装 Flutter 插件。
Android Studio 我还是安装在 文稿 -> sdk
注意安装android studio的路径，也许会报sdk的错误。类似错误 ❌
# [Flutter-Unable to find bundled Java version(flutter doctor), after updated android studio Arctic Fox(2020.3.1) on M1 Apple Silicon](https://stackoverflow.com/questions/68569430/flutter-unable-to-find-bundled-java-versionflutter-doctor-after-updated-andro)
对应的解决方法：flutter-unable-to-find-bundled-java-versionflutter-doctor-after-updated-andro
之后，运行 flutter doctor 或者 flutter doctor -v 来检查是否安装了必要的安装包。
下面是自己搭建环境的情况flutter doctor -v：
[✓] Flutter (Channel stable, 2.2.3, on macOS 11.2 20D64 darwin-arm, locale
zh-Hans-CN)
• Flutter version 2.2.3 at /Users/jimmy/Documents/sdk/flutter
• Framework revision f4abaa0735 (9 weeks ago), 2021-07-01 12:46:11 -0700
• Engine revision 241c87ad80
• Dart version 2.13.4
[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
• Android SDK at /Users/jimmy/Library/Android/sdk
• Platform android-31, build-tools 31.0.0
• Java binary at: /Users/jimmy/Documents/sdk/Android
Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 12.5.1, Build version 12E507
• CocoaPods version 1.10.2
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 2020.3)
• Android Studio at /Users/jimmy/Documents/sdk/Android Studio.app/Contents # 留意 Android Studio 路径
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
[✓] VS Code (version 1.59.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.25.0
[✓] Connected device (1 available)
• Chrome (web) • chrome • web-javascript • Google Chrome 92.0.4515.159
• No issues found!
出现 No issues found! 的提示，说明你捣鼓成功了～
我们在 VS code 上新建一个项目：
查看 -> 命令面板 -> Flutter: New Application Project
初始化项目之后，运行 -> 启动调试，然后按照下图运行应用：
如果选中 Chrome web 会直接调起你安装好的谷歌浏览器。
如果选中 Start iOS Simulator 会调起 xCode 的模拟器。
如果选中 Start Pixel 2 API 31 会调起 Android Studio 的模拟器。
当然你得在
Android Studio上预设手机型号是哪个，不然初次在VS code上调不起来。
【完】～ 下次可以更加愉快玩耍了
在你的程序里使用枚举声明来引入一个枚举类型。
枚举声明有两种基本的形式，使用关键字enum来声明。枚举声明体使用从零开始的变量——叫做枚举事件，和任意数量的 声明，包括计算型属性，实例方法，静态方法，构造器，类型别名，甚至其他枚举，结构体，和类。枚举声明不能 包含析构器或者协议声明。
不像类或者结构体。枚举类型并不提供隐式的初始构造器，所有构造器必须显式的声明。构造器可以委托枚举中的其他 构造器，但是构造过程仅当构造器将一个枚举时间完成后才全部完成。
和结构体类似但是和类不同，枚举是值类型：枚举实例在赋予变量或常量时，或者被函数调用时被复制。 更多关于值类型的信息，参见结构体和枚举都是值类型(Structures and Enumerations Are Value Types)一节。
你可以扩展枚举类型，正如在扩展名声明(Extension Declaration)中讨论的一样。
如下的形式声明了一个包含任意类型枚举时间的枚举变量
1. enum enumeration name { case enumeration case 1 case enumeration case 2(associated value types) } 这种形式的枚举声明在其他语言中有时被叫做可识别联合(discrinminated)。
这种形式中，每一个事件块由关键字case开始，后面紧接着一个或多个以逗号分隔的枚举事件。每一个事件名必须是 独一无二的。每一个事件也可以指定它所存储的指定类型的值，这些类型在关联值类型的元祖里被指定，立即书写在事件 名后。获得更多关于关联值类型的信息和例子，请查看关联值(associated values)一节。
以下的形式声明了一个包含相同基础类型的枚举事件的枚举：
1. enum enumeration name: raw value type { case enumeration case 1 = raw value 1 case enumeration case 2 = raw value 2 } 在这种形式中，每一个事件块由case关键字开始，后面紧接着一个或多个以逗号分隔的枚举事件。和第一种形式的枚举 事件不同，这种形式的枚举事件包含一个同类型的基础值，叫做原始值(raw value)。这些值的类型在原始值类型(raw value type) 中被指定，必须是字面上的整数，浮点数，字符或者字符串。
每一个事件必须有唯一的名字，必须有一个唯一的初始值。如果初始值类型被指定为int，则不必为事件显式的指定值， 它们会隐式的被标为值0,1,2等。每一个没有被赋值的Int类型时间会隐式的赋予一个初始值，它们是自动递增的。
1. num ExampleEnum: Int { case A, B, C = 5, D } 在上面的例子中，ExampleEnum.A的值是0，ExampleEnum.B的值是。因为ExampleEnum.C的值被显式的设定为5，因此 ExampleEnum.D的值会自动增长为6.
枚举事件的初始值可以调用方法roRaw获得，如ExampleEnum.B.toRaw()。你也可以通过调用fromRaw方法来使用初始值找到 其对应的事件，并返回一个可选的事件。查看更多信息和获取初始值类型事件的信息，参阅初始值(raw values)。
使用点(.)来引用枚举类型的事件，如 EnumerationType.EnumerationCase。当枚举类型可以上下文推断出时，你可以 省略它(.仍然需要)，参照枚举语法(Enumeration Syntax)和显式成员表达(Implicit Member Expression).
使用switch语句来检验枚举事件的值，正如使用switch语句匹配枚举值（Matching Enumeration Values with a Switch Statement)一节描述的那样。
枚举类型是模式匹配(pattern-matched)的，和其相反的是switch语句case块中枚举事件匹配，在枚举事件类型(Enumeration Case Pattern)中有描述。
GRAMMAR OF AN ENUMERATION DECLARATION
enum-declaration → attributesoptunion-style-enum attributesoptraw-value-style-enum union-style-enum → enum-namegeneric-parameter-clauseopt{union-style-enum-membersopt} union-style-enum-members → union-style-enum-memberunion-style-enum-membersopt union-style-enum-member → declaration union-style-enum-case-clause union-style-enum-case-clause → attributesoptcaseunion-style-enum-case-list union-style-enum-case-list → union-style-enum-case union-style-enum-case,union-style-enum-case-list union-style-enum-case → enum-case-nametuple-typeopt enum-name → identifier enum-case-name → identifier raw-value-style-enum → enum-namegeneric-parameter-clauseopt:type-identifier{raw-value-style-enum-membersopt} raw-value-style-enum-members → raw-value-style-enum-memberraw-value-style-enum-membersopt raw-value-style-enum-member → declaration raw-value-style-enum-case-clause raw-value-style-enum-case-clause → attributesoptcaseraw-value-style-enum-case-list raw-value-style-enum-case-list → raw-value-style-enum-case raw-value-style-enum-case,raw-value-style-enum-case-list raw-value-style-enum-case → enum-case-nameraw-value-assignmentopt raw-value-assignment → =literal
使用结构体声明可以在你的程序里引入一个结构体类型。结构体声明使用struct关键字，遵循如下的形式：
1. struct structure name: adopted protocols { declarations } 结构体内包含零或多个声明。这些声明可以包括存储型和计算型属性，静态属性，实例方法，静态方法，构造器， 类型别名，甚至其他结构体，类，和枚举声明。结构体声明不能包含析构器或者协议声明。详细讨论和包含多种结构体 声明的实例，参见类和结构体一节。
结构体可以包含任意数量的协议，但是不能继承自类，枚举或者其他结构体。
有三种方法可以创建一个声明过的结构体实例：
-调用结构体内声明的构造器，参照构造器(initializers)一节。
—如果没有声明构造器，调用结构体的逐个构造器，详情参见Memberwise Initializers for Structure Types.
—如果没有声明析构器，结构体的所有属性都有初始值，调用结构体的默认构造器，详情参见默认构造器(Default Initializers).
结构体的构造过程参见初始化(initiaization)一节。
结构体实例属性可以用点(.)来获得，详情参见获得属性(Accessing Properties)一节。
结构体是值类型；结构体的实例在被赋予变量或常量，被函数调用时被复制。获得关于值类型更多信息，参见 结构体和枚举都是值类型(Structures and Enumerations Are Value Types)一节。
你可以使用扩展声明来扩展结构体类型的行为，参见扩展声明(Extension Declaration).
GRAMMAR OF A STRUCTURE DECLARATION
struct-declaration → attributesoptstructstruct-namegeneric-parameter-clauseopttype-inheritance-clauseoptstruct-body struct-name → identifier struct-body → {declarationsopt}
你可以在你的程序中使用类声明来引入一个类。类声明使用关键字class，遵循如下的形式：
1. class class name: superclass, adopted protocols { declarations } 一个类内包含零或多个声明。这些声明可以包括存储型和计算型属性，实例方法，类方法，构造器，单独的析构器方法， 类型别名，甚至其他结构体，类，和枚举声明。类声明不能包含协议声明。详细讨论和包含多种类声明的实例，参见类和 结构体一节。
一个类只能继承一个父类，超类，但是可以包含任意数量的协议。这些超类第一次在type-inheritance-clause出现，遵循任意协议。
正如在初始化声明(Initializer Declaration)谈及的那样，类可以有指定和方便的构造器。当你声明任一中构造器时， 你可以使用requierd变量来标记构造器，要求任意子类来重写它。指定类的构造器必须初始化类所有的已声明的属性， 它必须在子类构造器调用前被执行。
类可以重写属性，方法和它的超类的构造器。重写的方法和属性必须以override标注。
虽然超类的属性和方法声明可以被当前类继承，但是超类声明的指定构造器却不能。这意味着，如果当前类重写了超类 的所有指定构造器，它就继承了超类的方便构造器。Swift的类并不是继承自一个全局基础类。
有两种方法来创建已声明的类的实例：
类实例属性可以用点(.)来获得，详情参见获得属性(Accessing Properties)一节。
类是引用类型；当被赋予常量或变量，函数调用时，类的实例是被引用，而不是复制。获得更多关于引用类型的信息， 结构体和枚举都是值类型(Structures and Enumerations Are Value Types)一节。
你可以使用扩展声明来扩展类的行为，参见扩展声明(Extension Declaration).
GRAMMAR OF A CLASS DECLARATION
class-declaration → attributesoptclassclass-namegeneric-parameter-clauseopttype-inheritance-clauseoptclass-body class-name → identifier class-body → {declarationsopt}
一个协议声明为你的程序引入一个命名了的协议类型。协议声明使用 protocol 关键词来进行声明并有下面这样的形式：
1. protocol protocol name: inherited protocols {
2. protocol member declarations
3. }协议的主体包含零或多个协议成员声明，这些成员描述了任何采用该协议必须满足的一致性要求。特别的，一个协议可以声明必须实现某些属性、方法、初始化程序及附属脚本的一致性类型。协议也可以声明专用种类的类型别名，叫做关联类型，它可以指定协议的不同声明之间的关系。协议成员声明会在下面的详情里进行讨论。
协议类型可以从很多其它协议那继承。当一个协议类型从其它协议那继承的时候，来自其它协议的所有要求就集合了，而且从当前协议继承的任何类型必须符合所有的这些要求。对于如何使用协议继承的例子，查看协议继承
你可以通过采用在类型的扩展声明中的协议来为之前声明的类型添加协议一致性。在扩展中你必须实现所有采用协议的要求。如果该类型已经实现了所有的要求，你可以让这个扩展声明的主题留空。
默认地，符合某一个协议的类型必须实现所有声明在协议中的属性、方法和附属脚本。也就是说，你可以用optional属性标注这些协议成员声明以指定它们的一致性类型实现是可选的。optional属性仅仅可以用于使用objc属性标记过的协议。这样的结果就是仅仅类类型可以采用并符合包含可选成员要求的协议。更多关于如何使用optional属性的信息及如何访问可选协议成员的指导——比如当你不能肯定是否一致性的类型实现了它们——参见可选协议要求
为了限制协议的采用仅仅针对类类型，需要使用class_protocol属性标记整个协议声明。任意继承自标记有class_protocol属性协议的协议都可以智能地仅能被类类型采用。
注意：如果协议已经用object属性标记了，class_protocol属性就隐性地应用于该协议；没有必要再明确地使用class_protocol属性来标记该协议了。
协议是命名的类型，因此它们可以以另一个命名类型出现在你代码的所有地方，就像协议类型里讨论的那样。然而你不能构造一个协议的实例，因为协议实际上不提供它们指定的要求的实现。
你可以使用协议来声明一个类的代理的方法或者应该实现的结构，就像委托(代理)模式描述的那样。
协议声明的语法 protocol-declaration → attributesoptprotocolprotocol-nametype-inheritance-clauseoptprotocol-body protocol-name → identifier protocol-body → {protocol-member-declarationsopt} protocol-member-declaration → protocol-property-declaration protocol-member-declaration → protocol-method-declaration protocol-member-declaration → protocol-initializer-declaration protocol-member-declaration → protocol-subscript-declaration protocol-member-declaration → protocol-associated-type-declaration protocol-member-declarations → protocol-member-declarationprotocol-member-declarationsopt
协议声明了一致性类型必须在协议声明的主体里通过引入一个协议属性声明来实现一个属性。协议属性声明有一种特殊的类型声明形式：
1. var property name: type { get set }同其它协议成员声明一样，这些属性声明仅仅针对符合该协议的类型声明了getter和setter要求。结果就是你不需要在协议里它被声明的地方实现getter和setter。
getter和setter要求可以通过一致性类型以各种方式满足。如果属性声明包含get和set关键词，一致性类型就可以用可读写（实现了getter和setter）的存储型变量属性或计算型属性，但是属性不能以常量属性或只读计算型属性实现。如果属性声明仅仅包含get关键词的话，它可以作为任意类型的属性被实现。比如说实现了协议的属性要求的一致性类型，参见属性要求
更多参见变量声明
协议属性声明语法 protocol-property-declaration → variable-declaration-headvariable-nametype-annotationgetter-setter-keyword-block
协议声明了一致性类型必须在协议声明的主体里通过引入一个协议方法声明来实现一个方法. 协议方法声明和函数方法声明有着相同的形式，包含如下两条规则：他们不包括函数体，你不能在类的声明内为他们的 参数提供初始值.举例来说，符合的类型执行协议必需的方法。参见必需方法一节。
使用关键字class可以在协议声明中声明一个类或必需的静态方法。执行这些方法的类也用关键字class声明。 相反的，执行这些方法的结构体必须以关键字static声明。如果你想使用扩展方法，在扩展类时使用class关键字， 在扩展结构体时使用static关键字。
更多请参阅函数声明。
GRAMMAR OF A PROTOCOL METHOD DECLARATION
protocol-method-declaration → function-headfunction-namegeneric-parameter-clauseoptfunction-signature
协议声明了一致性类型必须在协议声明的主体里通过引入一个协议构造器声明来实现一个构造器。协议构造器声明 除了不包含构造器体外，和构造器声明有着相同的形式，
更多请参阅构造器声明。
GRAMMAR OF A PROTOCOL INITIALIZER DECLARATION
protocol-initializer-declaration → initializer-headgeneric-parameter-clauseoptparameter-clause
协议声明了一致性类型必须在协议声明的主体里通过引入一个协议附属脚本声明来实现一个附属脚本。协议属性声明 对附属脚本声明有一个特殊的形式：
subscript (parameters) -> return type { get set }
附属脚本声明只为和协议一致的类型声明了必需的最小数量的的getter和setter。如果附属脚本申明包含get和set关键字， 一致的类型也必须有一个getter和setter语句。如果附属脚本声明值包含get关键字，一致的类型必须至少包含一个 getter语句，可以选择是否包含setter语句。
更多参阅附属脚本声明。
GRAMMAR OF A PROTOCOL SUBSCRIPT DECLARATION
protocol-subscript-declaration → subscript-headsubscript-resultgetter-setter-keyword-block
协议声明相关类型使用关键字typealias。相关类型为作为协议声明的一部分的类型提供了一个别名。相关类型和参数 语句中的类型参数很相似，但是它们在声明的协议中包含self关键字。在这些语句中，self指代和协议一致的可能的类型。 获得更多信息和例子，查看相关类型或类型别名声明。
GRAMMAR OF A PROTOCOL ASSOCIATED TYPE DECLARATION
protocol-associated-type-declaration → typealias-headtype-inheritance-clauseopttypealias-assignmentopt
构造器声明会为程序内的类，结构体或枚举引入构造器。构造器使用关键字Init来声明，遵循两条基本形式。
结构体，枚举，类可以有任意数量的构造器，但是类的构造器的规则和行为是不一样的。不像结构体和枚举那样，类 有两种结构体，designed initializers 和convenience initializers，参见构造器一节。
如下的形式声明了结构体，枚举和类的指定构造器：
1. init(parameters) { statements } 类的指定构造器将类的所有属性直接初始化。如果类有超类，它不能调用该类的其他构造器,它只能调用超类的一个 指定构造器。如果该类从它的超类处继承了任何属性，这些属性在当前类内被赋值或修饰时，必须带哦用一个超类的 指定构造器。
指定构造器可以在类声明的上下文中声明，因此它不能用扩展声明的方法加入一个类中。
结构体和枚举的构造器可以带哦用其他的已声明的构造器，来委托其中一个火全部进行初始化过程。
以关键字convenience来声明一个类的便利构造器：
1. convenience init(parameters) { statements } 便利构造器可以将初始化过程委托给另一个便利构造器或类的一个指定构造器。这意味着，类的初始化过程必须 以一个将所有类属性完全初始化的指定构造器的调用作为结束。便利构造器不能调用超类的构造器。
你可以使用requierd关键字，将便利构造器和指定构造器标记为每个子类的构造器都必须拥有的。因为指定构造器 不被子类继承，他们必须被立即执行。当子类直接执行所有超类的指定构造器(或使用便利构造器重写指定构造器)时， 必需的便利构造器可以被隐式的执行，亦可以被继承。不像方法，附属脚本那样，你不需要为这些重写的构造器标注 overrride关键字。
查看更多关于不同声明方法的构造器的例子，参阅构造过程一节。
GRAMMAR OF AN INITIALIZER DECLARATION
initializer-declaration → initializer-headgeneric-parameter-clauseoptparameter-clauseinitializer-body initializer-head → attributesoptconvenienceoptinit initializer-body → code-block
析构声明为类声明了一个析构器。析构器没有参数，遵循如下的格式：
1. deinit { statements } 当类没有任何语句时将要被释放时，析构器会自动的被调用。析构器在类的声明体内只能被声明一次——但是不能在 类的扩展声明内，每个类最多只能有一个。
子类继承了它的超类的析构器，在子类将要被释放时隐式的调用。子类在所有析构器被执行完毕前不会被释放。
析构器不会被直接调用。
查看例子和如何在类的声明中使用析构器，参见析构过程一节 。
GRAMMAR OF A DEINITIALIZER DECLARATION
deinitializer-declaration → attributesoptdeinitcode-block
扩展声明用于扩展一个现存的类，结构体，枚举的行为。扩展声明以关键字extension开始，遵循如下的规则：
1. extension type: adopted protocols { declarations } 一个扩展声明体包括零个或多个声明。这些声明可以包括计算型属性，计算型静态属性，实例方法，静态和类方法，构造器， 附属脚本声明，甚至其他结构体，类，和枚举声明。扩展声明不能包含析构器，协议声明，存储型属性，属性监测器或其他 的扩展属性。详细讨论和查看包含多种扩展声明的实例，参见扩展一节。
扩展声明可以向现存的类，结构体，枚举内添加一致的协议。扩展声明不能向一个类中添加继承的类，因此 type-inheritance-clause是一个只包含协议列表的扩展声明。
属性，方法，现存类型的构造器不能被它们类型的扩展所重写。
扩展声明可以包含构造器声明，这意味着，如果你扩展的类型在其他模块中定义，构造器声明必须委托另一个在 那个模块里声明的构造器来恰当的初始化。
GRAMMAR OF AN EXTENSION DECLARATION
extension-declaration → extensiontype-identifiertype-inheritance-clauseoptextension-body extension-body → {declarationsopt}
附属脚本用于向特定类型添加附属脚本支持，通常为访问集合，列表和序列的元素时提供语法便利。附属脚本声明使用关键字subscript，声明形式如下：
subscript (parameter) -> (return type){ get{ statements } set(setter name){ statements } } 附属脚本声明只能在类，结构体，枚举，扩展和协议声明的上下文进行声明。
变量(parameters)指定一个或多个用于在相关类型的附属脚本中访问元素的索引（例如，表达式object[i]中的i）。尽管用于元素访问的索引可以是任意类型的，但是每个变量必须包含一个用于指定每种索引类型的类型标注。返回类型(return type)指定被访问的元素的类型。
和计算性属性一样，附属脚本声明支持对访问元素的读写操作。getter用于读取值，setter用于写入值。setter子句是可选的，当仅需要一个getter子句时，可以将二者都忽略且直接返回请求的值即可。也就是说，如果使用了setter子句，就必须使用getter子句。
setter的名字和封闭的括号是可选的。如果使用了setter名称，它会被当做传给setter的变量的名称。如果不使用setter名称，那么传给setter的变量的名称默认是value。setter名称的类型必须与返回类型(return type)的类型相同。
可以在附属脚本声明的类型中，可以重载附属脚本，只要变量(parameters)或返回类型(return type)与先前的不同即可。此时，必须使用override关键字声明那个被覆盖的附属脚本。(注：好乱啊！到底是重载还是覆盖？！)
同样可以在协议声明的上下文中声明附属脚本，Protocol Subscript Declaration中有所描述。
更多关于附属脚本和附属脚本声明的例子，请参考Subscripts。
GRAMMAR OF A SUBSCRIPT DECLARATION
subscript-declaration → subscript-headsubscript-resultcode-block subscript-declaration → subscript-headsubscript-resultgetter-setter-block subscript-declaration → subscript-headsubscript-resultgetter-setter-keyword-block subscript-head → attributesoptsubscriptparameter-clause subscript-result → ->attributesopttype
运算符声明会向程序中引入中缀、前缀或后缀运算符，它使用上下文关键字operator声明。 可以声明三种不同的缀性：中缀、前缀和后缀。操作符的缀性描述了操作符与它的操作数的相对位置。 运算符声明有三种基本形式，每种缀性各一种。运算符的缀性通过在operator和运算符之间添加上下文关键字infix，prefix或postfix来指定。每种形式中，运算符的名字只能包含Operators中定义的运算符字符。
下面的这种形式声明了一个新的中缀运算符：
operator infix operator name{ precedence precedence level associativity associativity }
中缀运算符是二元运算符，它可以被置于两个操作数之间，比如表达式1 + 2 中的加法运算符(+)。
中缀运算符可以可选地指定优先级，结合性，或两者同时指定。
运算符的优先级可以指定在没有括号包围的情况下，运算符与它的操作数如何紧密绑定的。可以使用上下文关键字precedence并优先级(precedence level)一起来指定一个运算符的优先级。优先级可以是0到255之间的任何一个数字(十进制整数)；与十进制整数字面量不同的是，它不可以包含任何下划线字符。尽管优先级是一个特定的数字，但它仅用作与另一个运算符比较(大小)。也就是说，一个操作数可以同时被两个运算符使用时，例如2 + 3 * 5，优先级更高的运算符将优先与操作数绑定。
运算符的结合性可以指定在没有括号包围的情况下，优先级相同的运算符以何种顺序被分组的。可以使用上下文关键字associativity并结合性(associativity)一起来指定一个运算符的结合性，其中结合性可以说是上下文关键字left，right或none中的任何一个。左结合运算符以从左到右的形式分组。例如，减法运算符(-)具有左结合性，因此4 - 5 - 6被以(4 - 5) - 6的形式分组，其结果为-7。 右结合运算符以从右到左的形式分组，对于设置为none的非结合运算符，它们不以任何形式分组。具有相同优先级的非结合运算符，不可以互相邻接。例如，表达式1 < 2 < 3非法的。
声明时不指定任何优先级或结合性的中缀运算符，它们的优先级会被初始化为100，结合性被初始化为none。
下面的这种形式声明了一个新的前缀运算符：
operator prefix operator name{}
紧跟在操作数前边的前缀运算符(prefix operator)是一元运算符，例如表达式++i中的前缀递增运算符(++)。
前缀运算符的声明中不指定优先级。前缀运算符是非结合的。
下面的这种形式声明了一个新的后缀运算符：
operator postfix operator name{}
紧跟在操作数后边的后缀运算符(postfix operator)是一元运算符，例如表达式i++中的前缀递增运算符(++)。
和前缀运算符一样，后缀运算符的声明中不指定优先级。后缀运算符是非结合的。
声明了一个新的运算符以后，需要声明一个跟这个运算符同名的函数来实现这个运算符。如何实现一个新的运算符，请参考Custom Operators。
GRAMMAR OF AN OPERATOR DECLARATION
operator-declaration → prefix-operator-declaration postfix-operator-declaration >infix-operator-declaration prefix-operator-declaration → operator prefix operator{} postfix-operator-declaration → operator postfix operator{} infix-operator-declaration → operatorinfixoperator{infix-operator-attributesopt} infix-operator-attributes → precedence-clauseoptassociativity-clauseopt precedence-clause → precedenceprecedence-level precedence-level → Digit 0 through 255 associativity-clause → associativityassociativity associativity → left right none
在swift中，大多数声明在某种意义上讲也是执行或同事声明它们的初始化定义。这意味着，因为协议和他们的成员不匹配， 大多数协议成员需要单独的声明。为了方便起见，也因为这些区别在swift里不是很重要，声明语句同时包含了声明和定义。
GRAMMAR OF A DECLARATION
declaration → import-declaration
declaration → constant-declaration
declaration → variable-declaration
declaration → typealias-declaration
declaration → function-declaration
declaration → enum-declaration
declaration → struct-declaration
declaration → class-declaration
declaration → protocol-declaration
declaration → initializer-declaration
declaration → deinitializer-declaration
declaration → extension-declaration
declaration → subscript-declaration
declaration → operator-declaration
declarations → declarationdeclarationsopt
declaration-specifiers → declaration-specifierdeclaration-specifiersopt
declaration-specifier → class | mutating | nonmutating | override | static | unowned |
模块范围定义了对模块中其他源文件可见的代码。（注：待改进）在swift的源文件中，最高级别的代码由零个或多个语句， 声明和表达组成。变量，常量和其他的声明语句在一个源文件的最顶级被声明，使得他们对同一模块中的每个源文件都是可见的。
作为一个开发者，有一个学习的氛围跟一个交流圈子特别重要，这是一个我的iOS开发交流群：130 595 548，不管你是小白还是大牛都欢迎入驻 ，让我们一起进步，共同发展！（群内会免费提供一些群主收藏的免费学习书籍资料以及整理好的几百道面试题和答案文档！）
GRAMMAR OF A TOP-LEVEL DECLARATION
top-level-declaration → statements opt
代码块用来将一些声明和控制结构的语句组织在一起。它有如下的形式：
1. { `statements` } 代码块中的语句包括声明，表达式和各种其他类型的语句，它们按照在源码中的出现顺序被依次执行。
GRAMMAR OF A CODE BLOCK
code-block → statements opt
引入声明使你可以使用在其他文件中声明的内容。引入语句的基本形式是引入整个代码模块；它由import关键字开始，后面 紧跟一个模块名：
1. import module 你可以提供更多的细节来限制引入的符号，如声明一个特殊的子模块或者在一个模块或子模块中做特殊的声明。（待改进） 当你使用了这些细节后，在当前的程序汇总只有引入的符号是可用的（并不是声明的整个模块）。
1. import import kind module.symbol name import module.submodule 常量声明可以在你的程序里命名一个常量。常量以关键词let来声明，遵循如下的格式:
1. let constant name: type = expression 当常量的值被给定后，常量就将常量名称和表达式初始值不变的结合在了一起，而且不能更改。 这意味着如果常量以类的形式被初始化，类本身的内容是可以改变的，但是常量和类之间的结合关系是不能改变的。 当一个常量被声明为全局变量，它必须被给定一个初始值。当一个常量在类或者结构体中被声明时，他被认为是一个常量 属性。常量并不是可计算的属性，因此不包含getters和setters。（译者注：getters和setters不知道怎么翻译，待改进）
如果常量名是一个元祖形式，元祖中的每一项初始化表达式中都要有对应的值
1. let (firstNumber, secondNumber) = (10, 42)
1. 1 println("The first number is \(firstNumber).")
2 // prints "The first number is 10."
3 println("The second number is \(secondNumber).")
4 // prints "The second number is 42." 类型注释（:type）在常量声明中是一个可选项，它可以用来描述在类型接口（type inference）中找到的类型。
声明一个静态常量要使用关键字static。静态属性在类型属性（type propetries）中有介绍。
如果还想获得更多关于常量的信息或者想在使用中获得帮助，请查看常量和变量（constants and variables）, 存储属性（stored properties）等节。
GRAMMAR OF A CONSTANT DECLARATION
constant-declaration → attributes opt declaration-specifiers opt letpattern-initializer-list pattern-initializer-list → pattern-initializer | pattern-initializer , pattern-initializer-list pattern-initializer → pattern initializer opt initializer → =expression
变量声明可以在你的程序里声明一个变量，它以关键字var来声明。根据声明变量类型和值的不同，如存储和计算 变量和属性，存储变量和属性监视，和静态变量属性，有着不同的声明形式。（待改进） 所使用的声明形式取决于变量所声明的范围和你打算声明的变量类型。
注意：你也可以在协议声明的上下文声明属性，详情参见类型属性声明。
下面的形式声明了一个存储型变量或存储型变量属性
1. var variable name: type = expression 你可以在全局，函数内，或者在类和结构体的声明(context)中使用这种形式来声明一个变量。当变量以这种形式 在全局或者一个函数内被声明时，它代表一个存储型变量。当他在类或者结构体中被声明时，他代表一个存储型变量属性。
构造器表达式可以和常量声明相比，如果变量名是一个元祖类型，元祖的每一项的名字都要和初始化表达式一致。
正如名字一样，存储型变量的值或存储型变量属性存储在内存中。
如下形式声明一个一个存储型变量或存储型属性：
1. var variable name: type { get { statements } set(setter name) { statements } } 你可以在全局，函数体内或者类，结构体，枚举，扩展声明的上下文中使用这种形式的声明。 当变量以这种形式在全局或者一个函数内被声明时，它代表一个计算型变量。当他在类，结构体，枚举，扩展声明的上下文 中中被声明时，他代表一个计算型变量属性。
getter用来读取变量值，setter用来写入变量值。setter子句是可选择的，只有getter是必需的，你可以将这些语句 都省略，只是简单的直接返回请求值，正如在只读计算属性(read-only computed properites)中描述的那样。 但是如果你提供了一个setter语句，你也必需提供一个getter语句。
setter的名字和圆括号内的语句是可选的。如果你写了一个setter名，它就会作为setter的参数被使用。如果你不写setter名， setter的初始名为newValue，正如在seter声明速记(shorthand setter declaration)中提到的那样。
不像存储型变量和存储型属性那样，计算型属性和计算型变量的值不存储在内存中。
获得更多信息，查看更多关于计算型属性的例子，请查看计算型属性(computed properties)一节。
你可以用willset和didset监视器来声明一个存储型变量或属性。一个包含监视器的存储型变量或属性按如下的形式声明：
1. var variable name: type = expression { willSet(setter name) { statements } didSet(setter name { statements } } 你可以在全局，函数体内或者类，结构体，枚举，扩展声明的上下文中使用这种形式的声明。 当变量以这种形式在全局或者一个函数内被声明时，监视器代表一个存储型变量监视器； 当他在类，结构体，枚举，扩展声明的上下文中被声明时，监视器代表属性监视器。
你可以为适合的监视器添加任何存储型属性。你也可以通过重写子类属性的方式为适合的监视器添加任何继承的属性 (无论是存储型还是计算型的)，参见重写属性监视器(overriding properyt observers)。
初始化表达式在类或者结构体的声明中是可选的，但是在其他地方是必需的。无论在什么地方声明， 所有包含监视器的变量声明都必须有类型注释(type annotation)。
当变量或属性的值被改变时，willset和didset监视器提供了一个监视方法（适当的回应）。 监视器不会在变量或属性第一次初始化时不会被运行，他们只有在值被外部初始化语句改变时才会被运行。
willset监视器只有在变量或属性值被改变之前运行。新的值作为一个常量经过过willset监视器，因此不可以在 willset语句中改变它。didset监视器在变量或属性值被改变后立即运行。和willset监视器相反，为了以防止你仍然 需要获得旧的数据，旧变量值或者属性会经过didset监视器。这意味着，如果你在变量或属性自身的didiset监视器语句 中设置了一个值，你设置的新值会取代刚刚在willset监视器中经过的那个值。
在willset和didset语句中，setter名和圆括号的语句是可选的。如果你写了一个setter名，它就会作为willset和didset的参数被使用。如果你不写setter名， willset监视器初始名为newvalue，didset监视器初始名为oldvalue。
当你提供一个willset语句时，didset语句是可选的。同样的，在你提供了一个didset语句时，willset语句是可选的。
获得更多信息，查看如何使用属性监视器的例子，请查看属性监视器(prpperty observers)一节。
class关键字用来声明类的计算型属性。static关键字用来声明类的静态变量属性。类和静态变量在类型属性(type properties)中有详细讨论。
GRAMMAR OF A VARIABLE DECLARATION
variable-declaration → variable-declaration-headpattern-initializer-list
variable-declaration → variable-declaration-head variable-name type-annotation code-block
variable-declaration → variable-declaration-head variable-name type-annotation getter-setter-block
variable-declaration → variable-declaration-head variable-name type-annotation getter-setter-keyword-block
variable-declaration → variable-declaration-head variable-name type-annotationinitializer opt willSet-didSet-block
variable-declaration-head → attributes opt declaration-specifiers opt var variable-name → identifier
getter-setter-block → {getter-clause setter-clause opt}
getter-setter-block → {setter-clause getter-clause}
getter-clause → attributes optgetcode-block
setter-clause → attributes opt set setter-name opt code-block
setter-name → (identifier)
getter-setter-keyword-block → {getter-keyword-clause setter-keyword-clause opt} getter-setter-keyword-block → {setter-keyword-clause getter-keyword-clause}
getter-keyword-clause → attributes opt get
setter-keyword-clause → attributes opt set
willSet-didSet-block → {willSet-clause didSet-clause opt}
willSet-didSet-block → {didSet-clause willSet-clause}
willSet-clause → attributes opt willSet setter-name opt code-block
didSet-clause → attributes opt didSet setter-name opt code-block
类型别名的声明可以在你的程序里为一个已存在的类型声明一个别名。类型的别名声明以关键字typealias开始，遵循如下的 形式：
1. typealias name = existing type 当一个类型被别名被声明后，你可以在你程序的任何地方使用别名来代替已存在的类型。已存在的类型可以是已经被命名的 类型或者是混合类型。类型的别名不产生新的类型，它只是简单的和已存在的类型做名称替换。
查看更多Protocol Associated Type Declaration.
GRAMMAR OF A TYPE ALIAS DECLARATION
typealias-declaration → typealias-head typealias-assignment typealias-head → typealias typealias-name typealias-name → identifier typealias-assignment → =type
你可以使用函数声明在你的程序里引入新的函数。函数可以在类的上下文，结构体，枚举，或者作为方法的协议中被声明。 函数声明使用关键字func，遵循如下的形式：
1. func function name(parameters) -> return type { statements } 如果函数不返回任何值，返回类型可以被忽略，如下所示：
每个参数的类型都要标明，它们不能被推断出来。初始时函数的参数是常值。在这些参数前面添加var使它们成为变量， 作用域内任何对变量的改变只在函数体内有效，或者用inout使的这些改变可以在调用域内生效。 更多关于in-out参数的讨论，参见in-out参数(in-out parameters)
函数可以使用元组类型作为返回值来返回多个变量。
函数定义可以出现在另一个函数声明内。这种函数被称作nested函数。更多关于nested函数的讨论，参见nestde functions。
函数的参数是一个以逗号分隔的列表 。函数调用是的变量顺序必须和函数声明时的参数顺序一致。 最简单的参数列表有着如下的形式：
1. parameter name: parameter type
1. func f(x: Int, y: String) -> String { return y + String(x) } f(7, "hello") // x and y have no name class C { func f(x: Int, y: String) -> String { return y + String(x) } } let c = C() c.f(7, y: "hello") // x没有名称，y有名称 你可以按如下的形式，重写参数名被使用的过程：
在本地参数前命名的第二名称(second name)使得参数有一个扩展名。且不同于本地的参数名。 扩展参数名在函数被调用时必须被使用。对应的参数在方法或函数被调用时必须有扩展名 。
在参数名前所写的哈希符号(#)代表着这个参数名可以同时作为外部或本体参数名来使用。等同于书写两次本地参数名。 在函数或方法调用时，与其对应的语句必须包含这个名字。
本地参数名前的强调字符(_)使参数在函数被调用时没有名称。在函数或方法调用时，与其对应的语句必须没有名字。
参数可以被忽略，值可以是变化的，并且提供一个初始值，这种方法有着如下的形式：
1. _ : <#parameter type#. parameter name: parameter type... parameter name: parameter type = default argument value 以强调符(_)命名的参数明确的在函数体内不能被访问。
一个以基础类型名的参数，如果紧跟着三个点(...)，被理解为是可变参数。一个函数至多可以拥有一个可变参数， 且必须是最后一个参数。可变参数被作为该基本类型名的数组来看待。举例来讲，可变参数int...被看做是int[]。 查看可变参数的使用例子，详见可变参数(variadic parameters)一节。
在参数的类型后面有一个以等号(=)连接的表达式，这样的参数被看做有着给定表达式的初试值。如果参数在函数 调用时被省略了，就会使用初始值。如果参数没有胜率，那么它在函数调用是必须有自己的名字.举例来讲， f()和f(x:7)都是只有一个变量x的函数的有效调用，但是f(7)是非法的，因为它提供了一个值而不是名称。
以self修饰的枚举或结构体方法必须以mutating关键字作为函数声明头。
子类重写的方法必须以override关键字作为函数声明头。不用override关键字重写的方法，使用了override关键字 却并没有重写父类方法都会报错。
和类型相关而不是和类型实例相关的方法必须在static声明的结构以或枚举内，亦或是以class关键字定义的类内。
柯里化函数或方法有着如下的形式：
1. func function name(parameters)(parameters) -> return type { statements } 以这种形式定义的函数的返回值是另一个函数。举例来说，下面的两个声明时等价的:
多级柯里化应用如下
GRAMMAR OF A FUNCTION DECLARATION
function-declaration → function-head function-name generic-parameter-clause optfunction-signature function-body function-head → attributes opt declaration-specifiers opt func function-name → identifier operator function-signature → parameter-clauses function-result opt function-result → ->attributes opt type function-body → code-block parameter-clauses → parameter-clause parameter-clauses opt parameter-clause → () (parameter-list...opt) parameter-list → parameter parameter,parameter-list parameter → inout opt let opt#optparameter-name local-parameter-name opt type-annotation default-argument-clause opt parameter → inoutoptvar#optparameter-namelocal-parameter-name opt type-annotationdefault-argument-clause opt parameter → attributes opt type parameter-name → identifier _ local-parameter-name → identifier _ default-argument-clause → =expression：
使用 HomeBrew 安装 PMD
在 Xcode 的 Build Phases 中，我们增加一个新的 Run Script
上面的脚本中使用 pmd 进行复制粘贴检查， 检查结果会存放在 cpd-output.xml 文件中。--minimum-tokens 的值是一个经验值，这个需要根据具体情况确定。
另外脚本中需要 php 对输出脚本进行分析并显示到 Xcode 中，如果没有安装 php，则需要安装。安装PHP参考文章
还有需要的 cpd_script.php 文件， 需要放到工程根目录，它的作用是利用之前生成的检查结果文件，将检查的结果显示到 Xcode 中，在工程主目录下，创建 cpd_script.php 文件
<?php
foreach (simplexml_load_file('cpd-output.xml')->duplication as $duplication) {
$files = $duplication->xpath('file');
foreach ($files as $file) {
echo $file['path'].':'.$file['line'].':1: warning: '.$duplication['lines'].' copy-pasted lines from: '
.implode(', ', array_map(function ($otherFile) { return $otherFile['path'].':'.$otherFile['line']; },
array_filter($files, function ($f) use (&$file) { return $f != $file; }))).PHP_EOL;
}
}
?>php 脚本可以参考: https://link.jianshu.com/?t=https://krakendev.io/blog/generating-warnings-in-xcode
新建空的 demo 工程，command + b 编译项目，工程目录下会出现 cpd-output.xml 文件，此时文件内容为空
在项目中添加相同代码
cpd-output.xml 文件则会出现重复代码提示信息，项目中代码也同样会给出警告提示信息
原型和继承一直是js中非常基础和重要的部分，我们来看看日常开发中经常会用到的原型和继承。
class Person extends React.Component {
componentDidMount() {}
render() {}
}
这行代码代码大家都很熟悉，Person通过extends关键字继承了React的特性，componentDidMount和render在class类中的是一个普通定义好的函数。特殊的是，它们也是在Component中提前定义好的钩子函数，用于在某个固定的时机触发。
看完了基本的使用，下面我们一起来深入探索下class和extends。
class是ES6中引入的概念，我们也称它为类。class的用途是作为对象模版，用来创建对象。但需要明确的是，class只是一个语法糖，它内部实现上还是和ES5创建对象是相同的。由于class的写法更加符合面向对象编程的习惯，所以被推广使用，逐步替代了ES5中的对象创建。
console.log(typeof React.Component); // function
ES5是通过构造函数函数来创建对象，React.Component的类型同样是一个function，所以想要完全搞清楚对象和原型，还是要去学习下ES5中对象的创建。后面有一篇文章是关于ES5中对象的创建和继承，有需要的大家可以自己去看，这里就不展开说了。
class的本质还是构造函数，但是与构造函数又有些许使用上的不同。
class与构造函数都有两种定义方式，声明和表达式，这两种写法完全等价。且名称都必须大写，以区别于它创建的实例.
// 函数声明
function Person() {};
// 函数表达式
let Person = function () {};
// 类声明
class Person {}
// 类表达式
let Person = class {};
// 创建实例(函数和类)
let person = new Person();
表达式赋值时，可通过name访问原表达式。
let Student = function Person() {};
// 通过name属性获取类表达式的名称
console.log(Student.name); // Person
let Student = class Person {};
// 通过name属性获取类表达式的名称
console.log(Student.name); // Person
let Student = function Person() {};
// 外部无法访问类表达式
console.log(Person); // Person is not defined
let Student = class Person {};
// 外部无法访问类表达式
console.log(Person); // Person is not defined
函数可以变量提升，而类不可以。
// 声明
console.log(Person); // 报错
console.log(Student); // ƒ Student() {}
class Person {}
function Student() {}
console.log(Person); // class Person {}
console.log(Student); // ƒ Student() {}
// 表达式定义
console.log(Person); // undefined
console.log(Student); // undefined
var Person = class {};
var Student = function () {};
console.log(Person); // class {}
console.log(Student); // ƒ () {}
{
class Person {}
function Student() {}
}
console.log(Person); // 报错，Person is not defined
console.log(Student); // ƒ Student() {}
类必须通过new来调用，否则会报错。构造函数不使用new调用也可以，就会把全局的this作为内部对象。
function Person() {}
class Animal {}
let p = Person(); // Person内部this指向window
let a = Animal(); // TypeError: class constructor Animal cannot be invoked without 'new'
class实例化的时候，会调用class中的constructor函数。constructor是类的默认方法，如果没有定义，constructor方法会被默认添加。
class Bar {}
等同于
class Bar {
constructor() {}
}
constructor方法会默认返回一个实例对象（即this），也可以完全返回另一个对象。但返回另一个对象，会导致返回的对象不是Bar的实例(因为它的原型指针没有被更改，具体的原因后面分析)。
// 返回一个对象
class Bar {
constructor() {
return {
name: 1,
};
}
}
let bar = new Bar();
console.log(bar); // {name: 1}
console.log(bar instanceof Bar); // false
// 返回默认对象
class Bar {
constructor() {}
}
let bar = new Bar();
console.log(bar); // Bar {}
console.log(bar instanceof Bar); // true
前面说到了，如果手动返回了一个对象，会导致返回的对象不是class的实例。那么我们看看生成一个对象的过程是什么样的，为什么手动返回一个对象，这个对象就不是类的实例了。
实例化的过程:
通过上面的第二步可以看到，原型的赋值作用在新对象上，只有新对象与原型有关系，人为的在constructor返回的对象，与原型毫无关联，自然不是class的实例。
定义在constructor中的属性，是每个实例独有的，不会在原型上共享。
class Person {
constructor() {
this.name = new String("Jack");
// 定义在constructor中的函数是不被原型共享的
this.sayName = () => console.log(this.name);
this.nicknames = ["Jake", "J-Dog"];
}
}
let p1 = new Person();
let p2 = new Person();
console.log(p1.name === p2.name); // false
console.log(p1.sayName === p2.sayName); // false
console.log(p1.nicknames === p2.nicknames); //false
实例化的时候相当于复制了一个新函数
class Person {
constructor() {
this.name = new String("Jack");
this.sayName = new Function();
this.nicknames = new Array(["Jake", "J-Dog"]);
}
}
如果想在实例间共享方法，类定义语法把在类块中定义的方法作为原型方法。
class Person {
constructor() {
// 定义在constructor中的方法是属于每个实例的
this.locate = () => console.log("instance");
}
// 定义在类块中的方法是所有实例共享的
test() {
console.log("test");
}
}
let person1 = new Person();
let person2 = new Person();
console.log(person1.locate === person2.locate); // false
console.log(person1.test === person2.test); // true
// 实例中有该属性
console.log(person1.hasOwnProperty("locate")); // true
// 实例中没有该属性
console.log(person1.hasOwnProperty("test")); // false
类相当于实例的原型，所有在类中定义的方法，都会被实例继承。如果在一个方法前，加上static关键字，就表示该方法不会被实例继承，而是直接通过类来调用，这就称为“静态方法”。
在日常开发中，我会通过类的静态方法去处理一些名称管理和接口，如下面所示：
class Home {
static getData() {
return [];
}
}
console.log(Home.getData());
需要注意的是，静态方法不要求存在类的实例，所以this引用类自身，而不是实例。
class Bar {
static test() {
console.log(this);
}
}
// 类可以直接调用静态方法
Bar.test(); // class Bar {}
var bar = new Bar();
// 实例与静态方法无关
bar.test(); // 报错，bar.test is not a function
class Bar {
static test() {
console.log(this);
}
}
class Foo extends Bar {}
Foo.test(); // class Foo extends Bar {}
super对象上调用的 class Bar {
static test() {
return "test1";
}
}
class Foo extends Bar {
static test2() {
return super.test() + " test2";
}
}
console.log(Foo.test2()); // test1 test2
类的继承使用的是新语法，但它的本质依旧是原型链。
ES6中，使用extends关键字，就可以继承任何拥有constructor和原型的对象。所以它不仅可以继承一个类，还可以继承普通的构造函数。
class Vehicle {}
// 继承类
class Bus extends Vehicle {}
let b = new Bus();
console.log(b instanceof Bus); // true
console.log(b instanceof Vehicle); // true
function Person() {}
// 继承普通构造函数
class Engineer extends Person {}
let e = new Engineer();
console.log(e instanceof Engineer); // true
console.log(e instanceof Person); // true
派生类的方法可以通过 super 关键字引用它们的原型。这个关键字只能在派生类中使用，在类构造函数中使用 super 可以调用父类构造函数。
提炼几个要点:
class Vehicle {
constructor() {
// SyntaxError: 'super' keyword unexpected
super();
}
}
class Vehicle {}
class Bus extends Vehicle {
constructor() {
console.log(this);
}
}
new Bus();
// Uncaught ReferenceError: Must call super constructor in derived class before accessing 'this' or returning from derived constructor
class Vehicle {}
class Car extends Vehicle {}
console.log(new Car()); // Car {}
class Bus extends Vehicle {
constructor() {
super();
}
}
console.log(new Bus()); // Bus {}
class Van extends Vehicle {
constructor() {
return {};
}
}
console.log(new Van()); // {}
class Test extends Vehicle {
constructor() {}
}
console.log(new Test());
// Uncaught ReferenceError: Must call super constructor in derived class before accessing 'this' or returning from derived constructor
最近在学习一些计算机专业课，学习的过程中二进制的基础是必须要有的，不管是计算机网络，还是组成原理，还是操作系统，都是以二进制为基础的，所以本文总结一些二进制基础。今天，2021年8月30日，写下第一版，后面会陆续增加一些内容，增加一些应用便于更多人理解。
本文目标：
位的概念带着问题阅读：
192.168.1.1共有几位如果所有的问题，你都会，就不用读了，直接退出。
10进制，一位数可以是0-9，共10种可能,如果要表示第11种可能，就要进位。
类比一下，2进制，一位数只能是0或1，有2种可能。
16进制，一位数可以是0-15，有16种可能
10进制的进位规则如下：满10进一位
0 10 20
1 11
2 12
3 13
4 14
5 15
6 16
7 17
8 18
9 19
2进制的进位规则如下:满两位进一位，10进制的0是2进制0，10进制的1是2进制的1，如果要表示10进制的2，就要用两位2进制数，10
0 10 100 1000
1 11 101 1001
110 1010
111 1011
1100
1101
1110
1111
16进制的规则，满16进一位(a表示10进制的10，b:11,c:12...)
0 10（10进制的16）
1 11（10进制的17）
2 12
3
4
5
6
7
8
9
a
b
c
d
e
f
一位二进制数，称为1bit。
1位二进制数，也就是1bit，有2种可能，可以表示数0,1
2位二进制数，2bit，有4种可能(2x2)，可以表示数0,1,2,3
3位二进制数,3bit，有8种可能(2x2x2)，可以表示数0,1,2,3,4,5,6,7
...
n位二进制数，有 2^n -1 种可能。
有一些常用的2的次幂需要记住，必须记在脑子里，例如看到10进制的128，就想起来是2的7次方，就想起来有7位，0000000
2进制是计算机用的，人用起来写起来并不方便，所以就有了16进制。
一个16进制，可以表示16种可能性，也就是2的4次方，就是4位2进制数，就是4bit
举个栗子，
16进制是f，表示为2进制就是1111
16进制的ff，表示为2进制就是1111 1111
规律就是，一位16进制，可以用4位2进制来表示。2位16进制，用8位2进制数来表示。
那么16进制的ffffff表示为2进制是多少位呢
字节（英语：Byte），通常用作计算机信息计量单位，不分数据类型。是通信和数据存储的概念。
一个字节能存储8位2进制数据（这个是规范，需要刻在DNA里面）
1Byte =8bit
2^8是256，1个字节能表示的数就是0-255,共256种可能性。
1位16进制数能表示为4位2进制，所以一个字节能表示2个16进制。
总结如下：
1Byte
8bit 1111 1111
2个16进制位 f f
KB(Kilobyte) 千字节，国际单位法一般以1000来定义千，例如1千米=1000米，但是在信息领域，尤其是表示主存储容量时，千字节一般表示1024（2^10）个字节
1KB = 1024 B 2^10 Byte
1MB = 1024 KB 2^20 Byte
1GB = 1024 MB 2^30 Byte
Kb与KB是不同的,Kb是 Kilobit,
1Kb = 1024bit
我们的宽带的带宽是200M每秒,其实是200Mb/s,但是文件是以Byte为单位的，而不是bit,所以需要换算一下
200Mb / 8 = 25 MB
其实能够达到的最高下载速度是25MB/s
一个ip地址 192.168.1.1,共32位，why?
因为ip地址是10进制表示的，ip地址用.分开，每一段的范围是0-255，就是2^8，共8位,4*8=32，一共32位。
CSS中的颜色表示 #ffaaff，需要占用多大的存储空间存储
1个Byte存储8位2进制，
1个16进制相当于4位2进制，
所以1个Byte存储2位16进制
#ffaaff存储需要 3Byte
本文就先到这里，后续要有一些内容需要补充，比如按位&``|``！，左移，右移以及更多的应用（在内存层面的应用，在计算机网络中的应用，在字符编码中的应用等）等我学会了，整理了，补充在这篇文章的后面。
有问题请在评论区提出。
svg也可以使用一些我们封装好的组件,今天就来分享一种"剑气"加载效果。 <div class="sword">
<span>
</div>
.sword {
position: relative;
margin: 200px auto;
width: 64px;
height: 64px;
border-radius: 50%;
}
.sword span{
position: absolute;
box-sizing: border-box;
width: 100%;
height: 100%;
border-radius: 50%;
}
.sword :first-child{
left: 0%;
top: 0%;
border-bottom: 3px solid #EFEFFA;
}
css的animation动画属性就可以自己给它添加一个动画了。animation属性是一个简写属性，可以用于设置以下动画属性分别是：animation-name：指定要绑定到选择器的关键帧的名称animation-duration：动画指定需要多少秒或毫秒完成animation-timing-function：设置动画将如何完成一个周期animation-delay：设置动画在启动前的延迟间隔animation-iteration-count：定义动画的播放次数animation-direction：指定是否应该轮流反向播放动画animation-fill-mode：规定当动画不播放时，要应用到元素的样式animation-play-state：指定动画是否正在运行或已暂停...
.sword :first-child{
...
animation: sword-one 1s linear infinite;
...
}
@keyframes sword-one {
0% {
transform: rotateZ(0deg);
}
100% {
transform: rotateZ(360deg);
}
}
...
z轴0deg到360deg转动的动画，设定为一秒完成一次一直无限循环，我们来看看效果：x轴和y轴也转动一定角度即可完成一个剑气的转动。...
@keyframes sword-one {
0% {
transform: rotateX(35deg) rotateY(-45deg) rotateZ(0deg);
}
100% {
transform: rotateX(35deg) rotateY(-45deg) rotateZ(360deg);
}
}
...
剑气在组装起来就好了。<div class="sword">
<span></span>
<span></span>
<span></span>
</div>
span添加动画和样式。...
.sword :nth-child(2){
right: 0%;
top: 0%;
animation: sword-two 1s linear infinite;
border-right: 3px solid #EFEFFA;
}
.sword :last-child{
right: 0%;
bottom: 0%;
animation: sword-three 1s linear infinite;
border-top: 3px solid #EFEFFA;
}
@keyframes sword-two {
0% {
transform: rotateX(50deg) rotateY(10deg) rotateZ(0deg);
}
100% {
transform: rotateX(50deg) rotateY(10deg) rotateZ(360deg);
}
}
@keyframes sword-three {
0% {
transform: rotateX(35deg) rotateY(55deg) rotateZ(0deg);
}
100% {
transform: rotateX(35deg) rotateY(55deg) rotateZ(360deg);
}
}
...
这次主要是总结和记录下视频播放遇到的坑，视频播放采用的是AVPlayer这个控件，语法大致如下：
NSURL * url = [NSURL fileURLWithPath:@"视频地址"];
AVPlayerItem *playerItem = [AVPlayerItem playerItemWithURL:url];
self.player = [AVPlayer playerWithPlayerItem:playerItem];
[playerItem addObserver:self forKeyPath:@"status" options:NSKeyValueObservingOptionNew context:nil];
self.player.actionAtItemEnd = AVPlayerActionAtItemEndNone;
self.playerLayer = [AVPlayerLayer playerLayerWithPlayer:self.player];
self.playerLayer.videoGravity = AVLayerVideoGravityResizeAspect;
self.playerLayer.frame = self.view.bounds;
[self.view.layer addSublayer:self.playerLayer];
一般说来，这里要监听AVPlayerItem的status属性:
收起阅读 »
原因：
更新xocde11.4之后发现GPUImage视频画面渲染特别慢，并且控制台输出如下信息：
Main Thread Checker: UI API called on a background thread: -[UIView bounds]
PID: 7360, TID: 1812926, Thread name: (none), Queue name: com.sunsetlakesoftware.GPUImage.openGLESContextQueue, QoS: 0
Backtrace:
4 KXLive 0x0000000100e12e60 __39-[GPUImageView recalculateViewGeometry]_block_invoke + 52
5 KXLive 0x0000000100dec788 runSynchronouslyOnVideoProcessingQueue + 108
6 KXLive 0x0000000100e12e0c -[GPUImageView recalculateViewGeometry] + 108
7 KXLive 0x0000000100e13804 __37-[GPUImageView setInputSize:atIndex:]_block_invoke + 312
8 KXLive 0x0000000100dec788 runSynchronouslyOnVideoProcessingQueue + 108
9 KXLive 0x0000000100e136ac -[GPUImageView setInputSize:atIndex:] + 136
10 KXLive 0x0000000100e0ee38 -[GPUImageVideoCamera updateTargetsForVideoCameraUsingCacheTextureAtWidth:height:time:] + 660
11 KXLive 0x0000000100e0fb48 -[GPUImageVideoCamera processVideoSampleBuffer:] + 2120
12 KXLive 0x0000000100e106c4 __74-[GPUImageVideoCamera captureOutput:didOutputSampleBuffer:fromConnection:]_block_invoke + 180
13 libdispatch.dylib 0x0000000105e5d260 _dispatch_call_block_and_release + 24
14 libdispatch.dylib 0x0000000105e5d220 _dispatch_client_callout + 16
15 libdispatch.dylib 0x0000000105e6be80 _dispatch_queue_serial_drain + 768
16 libdispatch.dylib 0x0000000105e60730 _dispatch_queue_invoke + 328
17 libdispatch.dylib 0x0000000105e6cdd8 _dispatch_root_queue_drain_deferred_wlh + 352
18 libdispatch.dylib 0x0000000105e73ebc _dispatch_workloop_worker_thread + 676
19 libsystem_pthread.dylib 0x0000000181e6fe70 _pthread_wqthread + 860
20 libsystem_pthread.dylib 0x0000000181e6fb08 start_wqthread + 4意思是在子线程中UIView对象调用了bounds ，导致视频画面迟迟渲染不出来。
查找发现GPUImageView的视频渲染类的
(void)recalculateViewGeometry;- (void)layoutSubviews {
[super layoutSubviews];
self.viewBounds = self.bounds;
// The frame buffer needs to be trashed and re-created when the view size changes.
if (!CGSizeEqualToSize(self.bounds.size, boundsSizeAtFrameBufferEpoch) &&
!CGSizeEqualToSize(self.bounds.size, CGSizeZero)) {
runSynchronouslyOnVideoProcessingQueue(^{
[self destroyDisplayFramebuffer];
[self createDisplayFramebuffer];
[self recalculateViewGeometry];
});
}
}
- (void)recalculateViewGeometry;
{
runSynchronouslyOnVideoProcessingQueue(^{
CGFloat heightScaling, widthScaling;
CGSize currentViewSize = self.viewBounds.size;
// CGFloat imageAspectRatio = inputImageSize.width / inputImageSize.height;
// CGFloat viewAspectRatio = currentViewSize.width / currentViewSize.height;
CGRect insetRect = AVMakeRectWithAspectRatioInsideRect(inputImageSize, self.viewBounds);本文介绍了如何使用 GPUImage 来实现一个简单的相机。具体功能包括拍照、录制视频、多段视频合成、实时美颜、自定义滤镜实现等。
AVFoundation 是苹果提供的用于处理基于时间的媒体数据的一个框架。我们想要实现一个相机，需要从手机摄像头采集数据，离不开这个框架的支持。GPUImage 对 AVFoundation 做了一些封装，使我们的采集工作变得十分简单。
另外，GPUImage 的核心魅力还在于，它封装了一个链路结构的图像数据处理流程，简称滤镜链。滤镜链的结构使得多层滤镜的叠加功能变得很容易实现。
在下面介绍的功能中，有一些和 GPUImage 本身的关系并不大，我们是直接调用 AVFoundation 的 API 来实现的。但是，这些功能也是一个相机应用必不可少的一部分。所以，我们也会简单讲一下每个功能的实现方式和注意事项。
在 GPUImage 中，对图像数据的处理都是通过建立滤镜链来实现的。
这里就涉及到了一个类 GPUImageOutput 和一个协议 GPUImageInput 。对于继承了 GPUImageOutput 的类，可以理解为具备输出图像数据的能力；对于实现了 GPUImageInput 协议的类，可以理解为具备接收图像数据输入的能力。
顾名思义，滤镜链作为一个链路，具有起点和终点。根据前面的描述，滤镜链的起点应该只继承了 GPUImageOutput 类，滤镜链的终点应该只实现了 GPUImageInput 协议，而对于中间的结点应该同时继承了 GPUImageOutput 类并实现了 GPUImageInput 协议，这样才具备承上启下的作用。
在 GPUImage 中，只继承了 GPUImageOutput，而没有实现 GPUImageInput 协议的类有六个，也就是说有六种类型的输入源：
1、GPUImagePicture
GPUImagePicture 通过图片来初始化，本质上是先将图片转化为 CGImageRef，然后将 CGImageRef 转化为纹理。
2、GPUImageRawDataInput
GPUImageRawDataInput 通过二进制数据初始化，然后将二进制数据转化为纹理，在初始化的时候需要指明数据的格式（GPUPixelFormat）。
3、GPUImageTextureInput
GPUImageTextureInput 通过已经存在的纹理来初始化。既然纹理已经存在，在初始化的时候就不会重新去生成，只是将纹理的索引保存下来。
4、GPUImageUIElement
GPUImageUIElement 可以通过 UIView 或者 CALayer 来初始化，最后都是调用 CALayer 的 renderInContext: 方法，将当前显示的内容绘制到 CoreGraphics 的上下文中，从而获取图像数据。然后将数据转化为纹理。简单来说就是截屏，截取当前控件的内容。
这个类可以用来实现在视频上添加文字水印的功能。因为在 OpenGL 中不能直接进行文本的绘制，所以如果我们想把一个 UILabel 的内容添加到滤镜链里面去，使用 GPUImageUIElement 来实现是很合适的。
5、GPUImageMovie
GPUImageMovie 通过本地的视频来初始化。首先通过 AVAssetReader 来逐帧读取视频，然后将帧数据转化为纹理，具体的流程大概是：AVAssetReaderOutput -> CMSampleBufferRef -> CVImageBufferRef -> CVOpenGLESTextureRef -> Texture 。
6、GPUImageVideoCamera
GPUImageVideoCamera 通过相机参数来初始化，通过屏幕比例和相机位置（前后置） 来初始化相机。这里主要使用 AVCaptureVideoDataOutput 来获取持续的视频流数据输出，在代理方法 captureOutput:didOutputSampleBuffer:fromConnection: 中可以拿到 CMSampleBufferRef ，将其转化为纹理的过程与 GPUImageMovie 类似。
然而，我们在项目中使用的是它的子类 GPUImageStillCamera。 GPUImageStillCamera 在原来的基础上多了一个 AVCaptureStillImageOutput，它是我们实现拍照功能的关键，在 captureStillImageAsynchronouslyFromConnection:completionHandler: 方法的回调中，同样能拿到我们熟悉 CMSampleBufferRef。
简单来说，GPUImageVideoCamera 只能录制视频，GPUImageStillCamera 还可以拍照， 因此我们使用 GPUImageStillCamera 。
滤镜链的关键角色是 GPUImageFilter，它同时继承了 GPUImageOutput 类并实现了 GPUImageInput 协议。GPUImageFilter 实现承上启下功能的基础是「渲染到纹理」，这个操作我们在 《使用 iOS OpenGL ES 实现长腿功能》 一文中已经介绍过了，简单来说就是将结果渲染到纹理而不是屏幕上。
这样，每一个滤镜都能把输出的纹理作为下一个滤镜的输入，实现多层滤镜效果的叠加。
在 GPUImage 中，实现了 GPUImageInput 协议，而没有继承 GPUImageOutput 的类有四个：
1、GPUImageMovieWriter
GPUImageMovieWriter 封装了 AVAssetWriter，可以逐帧从帧缓存的渲染结果中读取数据，最后通过 AVAssetWriter 将视频文件保存到指定的路径。
2、GPUImageRawDataOutput
GPUImageRawDataOutput 通过 rawBytesForImage 属性，可以获取到当前输入纹理的二进制数据。
假设我们的滤镜链在输入源和终点之间，连接了三个滤镜，而我们需要拿到第二个滤镜渲染后的数据，用来做人脸识别。那我们可以在第二个滤镜后面再添加一个 GPUImageRawDataOutput 作为输出，则可以拿到对应的二进制数据，且不会影响原来的渲染流程。
3、GPUImageTextureOutput
这个类的实现十分简单，提供协议方法 newFrameReadyFromTextureOutput:，在每一帧渲染结束后，将自身返回，通过 texture 属性就可以拿到输入纹理的索引。
4、GPUImageView
GPUImageView 继承自 UIView，通过输入的纹理，执行一遍渲染流程。这次的渲染目标不是新的纹理，而是自身的 layer 。
这个类是我们实现相机功能的重要组成部分，我们所有的滤镜效果，都要依靠它来呈现。
拍照功能只需调用一个接口就能搞定，在回调方法中可以直接拿到 UIImage。代码如下：
- (void)takePhotoWtihCompletion:(TakePhotoResult)completion {
GPUImageFilter *lastFilter = self.currentFilterHandler.lastFilter;
[self.camera capturePhotoAsImageProcessedUpToFilter:lastFilter withCompletionHandler:^(UIImage *processedImage, NSError *error) {
if (error && completion) {
completion(nil, error);
return;
}
if (completion) {
completion(processedImage, nil);
}
}];
}
值得注意的是，相机的预览页面由 GPUImageView 承载，显示的是整个滤镜链作用的结果。而我们的拍照接口，可以传入这个链路上的任意一个滤镜，甚至可以在后面多加一个滤镜，然后拍照接口会返回对应滤镜的渲染结果。即我们的拍照结果不一定要和我们的预览一致。
示意图如下：
[图片上传失败...(image-68bb82-1610618344597)]
<figcaption style="box-sizing: border-box; display: block;"></figcaption>
录制视频首先要创建一个 GPUImageMovieWriter 作为链路的输出，与上面的拍照接口类似，这里录制的视频不一定和我们的预览一样。
整个过程比较简单，当我们调用停止录制的接口并回调之后，视频就被保存到我们指定的路径了。
- (void)setupMovieWriter {
NSString *videoPath = [SCFileHelper randomFilePathInTmpWithSuffix:@".m4v"];
NSURL *videoURL = [NSURL fileURLWithPath:videoPath];
CGSize videoSize = self.videoSize;
self.movieWriter = [[GPUImageMovieWriter alloc] initWithMovieURL:videoURL
size:videoSize];
GPUImageFilter *lastFilter = self.currentFilterHandler.lastFilter;
[lastFilter addTarget:self.movieWriter];
self.camera.audioEncodingTarget = self.movieWriter;
self.movieWriter.shouldPassthroughAudio = YES;
self.currentTmpVideoPath = videoPath;
}
- (void)recordVideo {
[self setupMovieWriter];
[self.movieWriter startRecording];
}
- (void)stopRecordVideoWithCompletion:(RecordVideoResult)completion {
@weakify(self);
[self.movieWriter finishRecordingWithCompletionHandler:^{
@strongify(self);
[self removeMovieWriter];
if (completion) {
completion(self.currentTmpVideoPath);
}
}];
}
在 GPUImage 中并没有提供多段录制的功能，需要我们自己去实现。
首先，我们要重复单段视频的录制过程，这样我们就有了多段视频的文件路径。然后主要实现两个功能，一个是 AVPlayer 的多段视频循环播放；另一个是通过 AVComposition 来合并多段视频，并用 AVAssetExportSession 来导出新的视频。
整个过程逻辑并不复杂，出于篇幅的考虑，代码就不贴了，请到项目中查看。
在拍照或者录视频结束后，通过 PhotoKit 保存到相册里。
- (void)writeImageToSavedPhotosAlbum:(UIImage *)image
completion:(void (^)(BOOL success))completion {
[[PHPhotoLibrary sharedPhotoLibrary] performChanges:^{
[PHAssetChangeRequest creationRequestForAssetFromImage:image];
} completionHandler:^(BOOL success, NSError * _Nullable error) {
if (completion) {
completion(success);
}
}];
}
1、递归查看 view 的子视图（私有方法，没有代码提示）
[self.view recursiveDescription]// 定义一个特殊字符的集合
NSCharacterSet *set = [NSCharacterSet characterSetWithCharactersInString:
@"@／：；（）¥「」＂、[]{}#%-*+=_\\|~＜＞$€^•'@#$%^&*()_+'\""];
// 过滤字符串的特殊字符
NSString *newString = [trimString stringByTrimmingCharactersInSet:set];3、Transform 属性
先说下我们的需求，在一个 tableView 中，左滑删除某个 cell 时，需要展示如下图所示的样式，浅灰色底色，橘红色 文字。
修改删除按钮的文字很简单，只需要实现下面的方法：
//修改编辑按钮文字
- (NSString *)tableView:(UITableView *)tableView titleForDeleteConfirmationButtonForRowAtIndexPath:(NSIndexPath *)indexPath {
return @"Delete";
}首先我按照常规的在 editActionsForRowAtIndexPath 方法中处理：
- (NSArray*)tableView:(UITableView *)tableView editActionsForRowAtIndexPath:(nonnull NSIndexPath *)indexPath {
// delete action
UITableViewRowAction *deleteAction = [UITableViewRowAction rowActionWithStyle:UITableViewRowActionStyleNormal title:@"Delete" handler:^(UITableViewRowAction *action, NSIndexPath *indexPath) {
}];
deleteAction.backgroundColor = [UIColor colorWithHexString:Color_F7F7F7];
return @[deleteAction];
}但发现只能通过 deleteAction.backgroundColor 改变背景颜色，却无法改变字体颜色。
而系统提供的几种 UITableViewRowActionStyle 也不符合我的需求：
typedef NS_ENUM(NSInteger, UITableViewRowActionStyle) {
UITableViewRowActionStyleDefault = 0,
UITableViewRowActionStyleDestructive = UITableViewRowActionStyleDefault,
UITableViewRowActionStyleNormal
}默认 UITableViewRowActionStyleDefault 的样子：
UITableViewRowActionStyleNormal 的样子：
解决办法有我从网上找来的，最新的 iOS12 的则是我自己试验出来的。解决办法也会随着 iOS 系统的升级而发生变化，因为系统控件的结构可能会发生变化，导致遍历不出要找到的视图。
iOS11 以前的处理方式是遍历 Cell 的 subViews 子视图找到 UITableViewCellDeleteConfirmationView ，只需在 Cell 的 .m 文件中添加 layoutSubviews 代码：
- (void)layoutSubviews {
[super layoutSubviews];
for (UIView *subView in self.subviews) {
if ([NSStringFromClass([subView class]) isEqualToString:@"UITableViewCellDeleteConfirmationView"]) {
UIButton *bgView = (UIButton *)[subView.subviews firstObject];
bgView.backgroundColor = [UIColor colorWithHexString:Color_F0F0F0];
[bgView setTitleColor:[UIColor colorWithHexString:Color_MainColor] forState:UIControlStateNormal];
}
}
}这个系统版本需要在 tableView 中添加 layoutSubviews，我是写了一个 tableView 的父类，在父类的 .m 中添加了 layoutSubviews。同时我还在 tableView 的 .h 中声明一个 cellHeightRef 来修改删除 Button 的高度。
- 简单来说就是在 tableView 的 subviews 中遍历出
UISwipeActionPullView，再从UISwipeActionPullView中遍历出UISwipeActionStandardButton。再修改 button 的样式即可。
- (void)layoutSubviews {
[super layoutSubviews];
for (UIView *subview in self.subviews) {
if ([subview isKindOfClass:NSClassFromString(@"UISwipeActionPullView")]) {
//修改背景颜色
subview.backgroundColor = [UIColor clearColor];
//修改按钮-颜色
UIButton *swipeActionStandardBtn = subview.subviews[0];
if ([swipeActionStandardBtn isKindOfClass:NSClassFromString(@"UISwipeActionStandardButton")]) {
CGFloat swipeActionStandardBtnOX = swipeActionStandardBtn.frame.origin.x;
CGFloat swipeActionStandardBtnW = swipeActionStandardBtn.frame.size.width;
swipeActionStandardBtn.frame = CGRectMake(swipeActionStandardBtnOX, 0, swipeActionStandardBtnW, self.cellHeightRef - 10);
[swipeActionStandardBtn setTitleColor:[UIColor colorWithHexString:Color_MainColor] forState:UIControlStateNormal];
[swipeActionStandardBtn setTitleColor:[UIColor whiteColor] forState:UIControlStateHighlighted];
[swipeActionStandardBtn setTitleColor:[UIColor whiteColor] forState:UIControlStateSelected];
}
}
}
}iOS 13 中和上面的 iOS 13 之前的方法几乎一样，只不过是 tableView 内部的父子视图关系发生了变化， UISwipeActionStandardButton 位置变了。即原来把 subView 改为了 subview.subviews.firstObject，才能得到 UISwipeActionStandardButton。
- (void)layoutSubviews {
[super layoutSubviews];
for (UIView *subview in self.subviews) {
if ([subview.subviews.firstObject isKindOfClass:NSClassFromString(@"UISwipeActionPullView")]) {
//修改背景颜色
subview.subviews.firstObject.backgroundColor = [UIColor clearColor];
//修改按钮-颜色
UIButton *swipeActionStandardBtn = subview.subviews.firstObject.subviews[0];
if ([swipeActionStandardBtn isKindOfClass:NSClassFromString(@"UISwipeActionStandardButton")]) {
CGFloat swipeActionStandardBtnOX = swipeActionStandardBtn.frame.origin.x;
CGFloat swipeActionStandardBtnW = swipeActionStandardBtn.frame.size.width;
swipeActionStandardBtn.frame = CGRectMake(swipeActionStandardBtnOX, 0, swipeActionStandardBtnW, self.cellHeightRef - 10);
[swipeActionStandardBtn setTitleColor:[UIColor colorWithHexString:Color_MainColor] forState:UIControlStateNormal];
[swipeActionStandardBtn setTitleColor:[UIColor whiteColor] forState:UIControlStateHighlighted];
[swipeActionStandardBtn setTitleColor:[UIColor whiteColor] forState:UIControlStateSelected];
}
}
}
}我们都知道 copy 一般用来修饰 有对应可变类型的不可变对象上，比如 NSString，NSArray 和 NSDictionary。那么为什么不推荐用 copy 去修饰 NSMutableString 和 NSMutableArray 而是用 strong 呢？
平时没怎么关注过这个问题，那么我就来测试一下。
首先定义两个字符串属性，一个 strong 一个 copy：
用 strong 修饰
@property (nonatomic, strong) NSString *str_strong;
用 copy 修饰
@property (nonatomic, copy) NSString *str_copy; mutString: 原可变字符串+++追加字符串, 0x2828ab6f0, 0x16f027af8
str_strong: 原可变字符串+++追加字符串, 0x2828ab6f0, 0x127f0cab0
str_copy: 原可变字符串, 0x2828ab8a0, 0x127f0cab8可以看出 str_strong 和 mutString 指向对象内存是一样的，因为 strong 是 浅拷贝（指针拷贝），他们指向的都是同一个对象，地址没有变化，值当然也就一样了。
str_copy 指向对象的内存地址和他们不一样，因为 str_copy 对象使用的 copy 深拷贝，是一个新的对象，开辟了新的内存地址，不用以前的地址。
- (void)viewDidLoad {
[super viewDidLoad];
NSString *str = [[NSString alloc] initWithFormat:@"不可变字符串"];
//进行赋值
self.str_strong = str;
self.str_copy = str;
NSLog(@"\n str: %@, %p, %p \n str_strong: %@, %p, %p \n str_copy: %@, %p, %p \n" , str, str, &str, self.str_strong, _str_strong, &_str_strong, self.str_copy, _str_copy, &_str_copy);
}打印结果如下：
通过打印结果可以看出，str、str_strong 和 str_copy 这三者指向对象内存一样，不管是 strong 还是 copy 在这里都进行了 浅拷贝，没有重新开辟新的空间，因为这回的str 是 NSString，是不可变的。
所以一般我们是不希望我们创建的 NSString 字符串跟着之后的赋值 mutString 变化而变化的，所以都用 copy 。当然如果你希望字串的值跟着 mutString 变化，也可以使用 strong。
但是，如果你创建的是 NSMutableString，那么不要用 copy！
我们使用 NSMutableString 肯定是想用字符串的可变这个属性，但如果你用 copy 去修饰，那么生成的将会是不可变的，当你去调用可变方法时，程序将会崩溃！
测试：
用 copy 修饰 NSMutableString
@property (nonatomic, copy) NSMutableString *mutstr_copy;
copy 修饰，不然也有可能出现崩溃。1、当原字符串是 NSString ，即不可变字符串时，不管是 strong 还是 copy 属性的对象，都指向原对象，copy操作也只是做了浅拷贝。
2、当原字符串是 NSMutableString 时，即可变字符串时，strong 属性只是增加了原字符串的引用计数，而 copy 属性则是对原字符串做了次深拷贝，产生一个新的对象，且 copy 属性对象指向这个新的对象，且这个 copy 属性对象的类型始终是 NSString，而不是NSMutableString，因此其是不可变的，这时候调用可变操作，将会造成崩溃！
3、 因为 NSMutableString 是 NSString 的子类，父类指针可以指向子类对象，使用 copy 的目的是为了让本对象的属性不受外界影响，这样无论给我传入是一个可变对象还是不可变对象，我本身持有的就是一个不可变的副本，这样更安全。
所以，在声明 NSString 属性时，一般我们都不希望它改变，所以大多数情况下，我们建议用 copy，以免因可变字符串的修改导致的一些非预期问题。而在声明 NSMutableString 则需要使用 strong。
举一反三：
把 NSMutableArray 用
copy修饰有时就会崩溃，因为对这个数组进行了增删改操作，而copy后的数组变成了不可变数组 NSArray ，没有响应的增删改方法，所以就崩溃了。
- 当修饰可变类型的属性时，如 NSMutableArray、NSMutableDictionary、NSMutableString，用
strong。
当修饰不可变类型的属性时，如 NSArray、NSDictionary、NSString，用copy。
问题原因：
(1)使用系统提供的默认demo开通，目前该demo暂不支持开通MQTT业务；
(2)在console控制台【添加应用】时，数据中心默认为“国内2区”，需要更改为“国内1区”；
解决方案：
新建应用时，数据中心选择“国内一区”。
（2）服务器端SDK下载
说到 HTTP 怎么提升网络加载速度，就不得不聊一聊 HTTP/2 了。
HTTP/2 的主要目标是通过支持完整的请求与响应复用来减少延迟，通过有效压缩 HTTP 标头字段将协议开销降至最低，同时增加对请求优先级和服务器推送的支持。
HTTP/2 没有改动 HTTP 的应用语义。 HTTP 方法、状态代码、URI 和标头字段等核心概念一如往常。 不过，HTTP/2 修改了数据格式化（分帧）以及在客户端与服务器间传输的方式。这两点统帅全局，通过新的分帧层向我们的应用隐藏了所有复杂性。 因此，所有现有的应用都可以不必修改而在新协议下运行。
HTTP/2 所有性能增强的核心在于新的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。
这里所谓的“层”，指的是位于套接字接口与应用可见的高级 HTTP API 之间一个经过优化的新编码机制: HTTP 的语义（包括各种动词、方法、标头）都不受影响，不同的是传输期间对它们的编码方式变了。 HTTP/1.x 协议以换行符作为纯文本的分隔符，而 HTTP/2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。
新的二进制分帧机制改变了客户端与服务器之间交换数据的方式。 为了说明这个过程，我们需要了解 HTTP/2 的三个概念:
这些概念的关系总结如下:
简言之，HTTP/2 将 HTTP 协议通信分解为二进制编码帧的交换，这些帧对应着特定数据流中的消息。所有这些都在一个 TCP 连接内复用。 这是 HTTP/2 协议所有其他功能和性能优化的基础。
在 HTTP/1.x 中，如果客户端要想发起多个并行请求以提升性能，则必须使用多个 TCP 连接（请参阅使用多个 TCP 连接）。 这是 HTTP/1.x 交付模型的直接结果，该模型可以保证每个连接每次只交付一个响应（响应排队）。 更糟糕的是，这种模型也会导致队首阻塞，从而造成底层 TCP 连接的效率低下。
HTTP/2 中新的二进制分帧层突破了这些限制，实现了完整的请求和响应复用: 客户端和服务器可以将 HTTP 消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来。
快照捕捉了同一个连接内并行的多个数据流。 客户端正在向服务器传输一个 DATA 帧（数据流 5），与此同时，服务器正向客户端交错发送数据流 1 和数据流 3 的一系列帧。因此，一个连接上同时有三个并行数据流。
将 HTTP 消息分解为独立的帧，交错发送，然后在另一端重新组装是 HTTP 2 最重要的一项增强。事实上，这个机制会在整个网络技术栈中引发一系列连锁反应，从而带来巨大的性能提升，让我们可以:
HTTP/2 中的新二进制分帧层解决了 HTTP/1.x 中存在的队首阻塞问题，也消除了并行处理和发送请求及响应时对多个连接的依赖。 结果，应用速度更快、开发更简单、部署成本更低。
将 HTTP 消息分解为很多独立的帧之后，我们就可以复用多个数据流中的帧，客户端和服务器交错发送和传输这些帧的顺序就成为关键的性能决定因素。 为了做到这一点，HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系:
数据流依赖关系和权重的组合让客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应。 反过来，服务器可以使用此信息通过控制 CPU、内存和其他资源的分配设定数据流处理的优先级，在资源数据可用之后，带宽分配可以确保将高优先级响应以最优方式传输至客户端。
HTTP/2 内的数据流依赖关系通过将另一个数据流的唯一标识符作为父项引用进行声明；如果忽略标识符，相应数据流将依赖于“根数据流”。 声明数据流依赖关系指出，应尽可能先向父数据流分配资源，然后再向其依赖项分配资源。 换句话说，“请先处理和传输响应 D，然后再处理和传输响应 C”。
共享相同父项的数据流（即，同级数据流）应按其权重比例分配资源。 例如，如果数据流 A 的权重为 12，其同级数据流 B 的权重为 4，那么要确定每个数据流应接收的资源比例，请执行以下操作:
4 + 12 = 16A = 12/16, B = 4/16因此，数据流 A 应获得四分之三的可用资源，数据流 B 应获得四分之一的可用资源；数据流 B 获得的资源是数据流 A 所获资源的三分之一。
我们来看一下上图中的其他几个操作示例。 从左到右依次为:
如上面的示例所示，数据流依赖关系和权重的组合明确表达了资源优先级，这是一种用于提升浏览性能的关键功能，网络中拥有多种资源类型，它们的依赖关系和权重各不相同。 不仅如此，HTTP/2 协议还允许客户端随时更新这些优先级，进一步优化了浏览器性能。 换句话说，我们可以根据用户互动和其他信号更改依赖关系和重新分配权重。
注: 数据流依赖关系和权重表示传输优先级，而不是要求，因此不能保证特定的处理或传输顺序。 即，客户端无法强制服务器通过数据流优先级以特定顺序处理数据流。 尽管这看起来违反直觉，但却是一种必要行为。 我们不希望在优先级较高的资源受到阻止时，还阻止服务器处理优先级较低的资源。
有了新的分帧机制后，HTTP/2 不再依赖多个 TCP 连接去并行复用数据流；每个数据流都拆分成很多帧，而这些帧可以交错，还可以分别设定优先级。 因此，所有 HTTP/2 连接都是永久的，而且仅需要每个来源一个连接，随之带来诸多性能优势。
SPDY 和 HTTP/2 的杀手级功能是，可以在一个拥塞受到良好控制的通道上任意进行复用。 这一功能的重要性和良好运行状况让我吃惊。 我喜欢的一个非常不错的指标是连接拆分，这些拆分仅承载一个 HTTP 事务（并因此让该事务承担所有开销）。 对于 HTTP/1，我们 74% 的活动连接仅承载一个事务 - 永久连接并不如我们所有人希望的那般有用。 但是在 HTTP/2 中，这一比例锐减至 25%。 这是在减少开销方面获得的巨大成效。 （HTTP/2 登陆 Firefox，Patrick McManus）
大多数 HTTP 传输都是短暂且急促的，而 TCP 则针对长时间的批量数据传输进行了优化。 通过重用相同的连接，HTTP/2 既可以更有效地利用每个 TCP 连接，也可以显著降低整体协议开销。 不仅如此，使用更少的连接还可以减少占用的内存和处理空间，也可以缩短完整连接路径（即，客户端、可信中介和源服务器之间的路径） 这降低了整体运行成本并提高了网络利用率和容量。 因此，迁移到 HTTP/2 不仅可以减少网络延迟，还有助于提高通量和降低运行成本。
注: 连接数量减少对提升 HTTPS 部署的性能来说是一项特别重要的功能: 可以减少开销较大的 TLS 连接数、提升会话重用率，以及从整体上减少所需的客户端和服务器资源。
流控制是一种阻止发送方向接收方发送大量数据的机制，以免超出后者的需求或处理能力: 发送方可能非常繁忙、处于较高的负载之下，也可能仅仅希望为特定数据流分配固定量的资源。 例如，客户端可能请求了一个具有较高优先级的大型视频流，但是用户已经暂停视频，客户端现在希望暂停或限制从服务器的传输，以免提取和缓冲不必要的数据。 再比如，一个代理服务器可能具有较快的下游连接和较慢的上游连接，并且也希望调节下游连接传输数据的速度以匹配上游连接的速度来控制其资源利用率；等等。
上述要求会让您想到 TCP 流控制吗？您应当想到这一点；因为问题基本相同（请参阅流控制）。 不过，由于 HTTP/2 数据流在一个 TCP 连接内复用，TCP 流控制既不够精细，也无法提供必要的应用级 API 来调节各个数据流的传输。 为了解决这一问题，HTTP/2 提供了一组简单的构建块，这些构建块允许客户端和服务器实现其自己的数据流和连接级流控制:
DATA 帧时都会减小，在接收方发出 WINDOW_UPDATE 帧时增大。SETTINGS 帧，这会在两个方向上设置流控制窗口。 流控制窗口的默认值设为 65,535 字节，但是接收方可以设置一个较大的最大窗口大小（2^31-1 字节），并在接收到任意数据时通过发送 WINDOW_UPDATE 帧来维持这一大小。HTTP/2 未指定任何特定算法来实现流控制。 不过，它提供了简单的构建块并推迟了客户端和服务器实现，可以实现自定义策略来调节资源使用和分配，以及实现新传输能力，同时提升网页应用的实际性能和感知性能（请参阅速度、性能和人类感知）。
例如，应用层流控制允许浏览器仅提取一部分特定资源，通过将数据流流控制窗口减小为零来暂停提取，稍后再行恢复。 换句话说，它允许浏览器提取图像预览或首次扫描结果，进行显示并允许其他高优先级提取继续，然后在更关键的资源完成加载后恢复提取。
HTTP/2 新增的另一个强大的新功能是，服务器可以对一个客户端请求发送多个响应。 换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源（图 12-5），而无需客户端明确地请求。
注: HTTP/2 打破了严格的请求-响应语义，支持一对多和服务器发起的推送工作流，在浏览器内外开启了全新的互动可能性。 这是一项使能功能，对我们思考协议、协议用途和使用方式具有重要的长期影响。
为什么在浏览器中需要一种此类机制呢？一个典型的网络应用包含多种资源，客户端需要检查服务器提供的文档才能逐个找到它们。 那为什么不让服务器提前推送这些资源，从而减少额外的延迟时间呢？ 服务器已经知道客户端下一步要请求什么资源，这时候服务器推送即可派上用场。
事实上，如果您在网页中内联过 CSS、JavaScript，或者通过数据 URI 内联过其他资产（请参阅资源内联），那么您就已经亲身体验过服务器推送了。 对于将资源手动内联到文档中的过程，我们实际上是在将资源推送给客户端，而不是等待客户端请求。 使用 HTTP/2，我们不仅可以实现相同结果，还会获得其他性能优势。 推送资源可以进行以下处理:
所有服务器推送数据流都由 PUSH_PROMISE 帧发起，表明了服务器向客户端推送所述资源的意图，并且需要先于请求推送资源的响应数据传输。 这种传输顺序非常重要: 客户端需要了解服务器打算推送哪些资源，以免为这些资源创建重复请求。 满足此要求的最简单策略是先于父响应（即，DATA 帧）发送所有 PUSH_PROMISE 帧，其中包含所承诺资源的 HTTP 标头。
在客户端接收到 PUSH_PROMISE 帧后，它可以根据自身情况选择拒绝数据流（通过 RST_STREAM 帧）。 （例如，如果资源已经位于缓存中，便可能会发生这种情况。） 这是一个相对于 HTTP/1.x 的重要提升。 相比之下，使用资源内联（一种受欢迎的 HTTP/1.x“优化”）等同于“强制推送”: 客户端无法选择拒绝、取消或单独处理内联的资源。
使用 HTTP/2，客户端仍然完全掌控服务器推送的使用方式。 客户端可以限制并行推送的数据流数量；调整初始的流控制窗口以控制在数据流首次打开时推送的数据量；或完全停用服务器推送。 这些优先级在 HTTP/2 连接开始时通过 SETTINGS 帧传输，可能随时更新。
推送的每个资源都是一个数据流，与内嵌资源不同，客户端可以对推送的资源逐一复用、设定优先级和处理。 浏览器强制执行的唯一安全限制是，推送的资源必须符合原点相同这一政策: 服务器对所提供内容必须具有权威性。
每个 HTTP 传输都承载一组标头，这些标头说明了传输的资源及其属性。 在 HTTP/1.x 中，此元数据始终以纯文本形式，通常会给每个传输增加 500–800 字节的开销。如果使用 HTTP Cookie，增加的开销有时会达到上千字节。 （请参阅测量和控制协议开销。） 为了减少此开销和提升性能，HTTP/2 使用 HPACK 压缩格式压缩请求和响应标头元数据，这种格式采用两种简单但是强大的技术:
利用霍夫曼编码，可以在传输时对各个值进行压缩，而利用之前传输值的索引列表，我们可以通过传输索引值的方式对重复值进行编码，索引值可用于有效查询和重构完整的标头键值对。
作为一种进一步优化方式，HPACK 压缩上下文包含一个静态表和一个动态表: 静态表在规范中定义，并提供了一个包含所有连接都可能使用的常用 HTTP 标头字段（例如，有效标头名称）的列表；动态表最初为空，将根据在特定连接内交换的值进行更新。 因此，为之前未见过的值采用静态 Huffman 编码，并替换每一侧静态表或动态表中已存在值的索引，可以减小每个请求的大小。
注: 在 HTTP/2 中，请求和响应标头字段的定义保持不变，仅有一些微小的差异: 所有标头字段名称均为小写，请求行现在拆分成各个 :method、:scheme、:authority 和 :path 伪标头字段。
早期版本的 HTTP/2 和 SPDY 使用 zlib（带有一个自定义字典）压缩所有 HTTP 标头。 这种方式可以将所传输标头数据的大小减小 85% - 88%，显著减少了页面加载时间延迟:
在带宽较低的 DSL 链路中，上行链路速度仅有 375 Kbps，仅压缩请求标头就显著减少了特定网站（即，发出大量资源请求的网站）的页面加载时间。 我们发现，仅仅由于标头压缩，页面加载时间就减少了 45 - 1142 毫秒。 （SPDY 白皮书， chromium.org）
简单的知识点搭配合适的业务场景，往往能起到意想不到的效果。这篇文章会用三个最基础人人都知道的前端知识来说明如何助力运营小姐姐、公司48+前端开发同学的日常工作，让他们的工作效率得到极大地提升。
看完您可以会收获：用vue从零开始写一个chrome插件 如何用Object.defineProperty拦截fetch请求` 如何使用油猴脚本开发一个扩展程序 日常提效的一些思考
因为接下来的两个小工具都是基于
油猴脚本来实现的，所以我们提前先了解一下它
油猴脚本（Tampermonkey）是一个流行的浏览器扩展，可以运行用户编写的扩展脚本，来实现各式各样的功能，比如去广告、修改样式、下载视频等。
1. 安装油猴
以chrome浏览器扩展为例，点击这里先安装
安装完成之后可以看到右上角多了这个
2. 新增示例脚本 hello world
// ==UserScript==
// @name hello world // 脚本名称
// @namespace http://tampermonkey.net/
// @version 0.1
// @description try to take over the world!
// @author You
// @match https://juejin.cn/* // 表示怎样的url才执行下面的代码
// @icon https://www.google.com/s2/favicons?domain=juejin.cn
// @grant none
// ==/UserScript==
(function() {
'use strict';
alert('hello world')
// Your code here...
})();
没错当打开任意一个https://juejin.cn/*掘金的页面时，都会弹出hello world，而其他的网页如https://baidu.com则不会。
到此你就完成了一个最简单的油猴脚本，接下来我们看一下用同样简单的代码，来解决一个实际问题吧！O(∩_∩)O
1. 有一天运营小姐姐要在几个系统之间配置点东西
一顿操作，终于把事情搞定了，心情美美的。
但是她心想，为啥每个系统都要我登录一次，不开心 o(￣ヘ￣o＃)
2. 下午一觉醒来，领导让把上午的配置重新改一下(尽职的小姐姐马上开始操作)
但是让她没想到的是：上午的登录页面仿佛许久没有见到她一样，又和小姐姐来了一次亲密接触😭
此时，她的内心已经开始崩溃了
3. 但是这不是结束，以后的每一天她都是这种状态😭😭😭
看完上面的动图，我猜你已经在替小姐姐一起骂娘了，这做的什么玩意，太垃圾了。SSO是统一登录，你们这搞的是什么东西。
是的，我的内心和你一样愤愤不平, 一样有一万个草泥马在奔腾，这是哪个sb设计的方案，简直不配做人，一天啥事也不干，尽是跳登录页，输入用户名密码点登录按钮了，久而久之，朋友间见面说的第一句话不是“你吃了吗？”，而是“你登录了吗？”。
不过吐槽完，我们还是要想想如何通过技术手段解决这两个痛点，达到只需要登录一次的目的。
1. 在A系统登录之后，跑到其他系统需要重新登录。
2. 登录时效只有2小时，2小时后，需要重新登录
根本原因还是公司的SSO统一登录方案设计的有问题，所以需要推动他们修改，但是这是一个相对长期的过程，短期内有没有什么办法能让我们愉快的登录呢？
痛点1: 1. 在A系统登录之后，跑到其他系统需要重新登录。已无力回天
痛点2: 2. 登录时效只有2小时，2小时后，需要重新登录已无力回天
我们不好直接侵入各个系统去改造登录逻辑，改造其登录时效，但是却可以对登录页面（示例）做点手脚
最关键的是：
用户名输入框
密码输入框
点击按钮
所以可以借助油猴脚本，在DOMContentLoaded的时候，插入一下代码，来实现自动登录，减少手动操作的过程，大概原理如下。
// ==UserScript==
// @name SSO自动登录
// @namespace http://tampermonkey.net/
// @version 0.1
// @description try to take over the world!
// @author You
// @match https://*.xxx.com/login* // 这里是SSO登录页面地址，表示只有符合这个规则的才注入这段代码
// @grant none
// ==/UserScript==
document.querySelector('#username').value = 'xxx' // 用户名
document.querySelector('#password').value = 'yyy' // 密码
document.querySelector('#login-submit').click() // 自动提交登录
是不是太简单了，简单到令人发指，令人痛恨，令人想吐口水！！！，没有一点技术含量
是不是太简单了，简单到令人发指，令人痛恨，令人想吐口水！！！，没有一点技术含量
是不是太简单了，简单到令人发指，令人痛恨，令人想吐口水！！！，没有一点技术含量
是的，就这 😄，第一次帮小姐姐解决了困扰她许久的问题，晚上就请我吃了麻辣烫，还夸我"技术"好（此处不是开车）
gif中前半部分没有开启自动登录的脚本需要手动登录，后半部开启了就可以自动登录了。
前端常见的调试方式
这些方式都有各自的优缺点，比如chrome inspect第一次需要翻墙才能使用，只适用于安卓; vconsole不方便直接调试样式; weinre只适用于调试样式等。
基于这些原因，公司很久之前搞了一个远程调试工具，可以很方便的增删DOM结构、调试样式、查看请求、查看application 修改后手机上立即生效。
远程调试平台使用流程
他的使用流程大概是这样的
打开远程调试页面列表
此页面包含测试环境所有人打开的调试页面链接, 多的时候有上百个
看完流程你应该大概知道问题在哪里了, 远程调试页面列表不仅仅包含我自己的页面，还包括很多其他人的，导致很难快速找到自己想要调试的页面
问题解析
有什么办法能让我快速找到自己想要调试的页面呢？其实观察解析这个页面会发现列表是
拦截请求
所以聪明的你已经猜到了，我们可以通过Object.defineProperty拦截fetch请求，过滤设备让列表中只存在我们指定的设备（毕竟平时开发时调试的设备基本是固定的，而设备完全相同的概率是很低的，所以指定了设备其实就是唯一标识了自己）页面。
具体如何做呢？
// ==UserScript==
// @name 前端远程调试设备过滤
// @namespace http://tampermonkey.net/
// @version 0.1
// @description try to take over the world!
// @author You
// @match https://chii-fe.xxx.com/ // 指定脚本生效的页面
// @grant none
// @run-at document-start // 注意这里，脚本注入的时机是document-start
// ==/UserScript==
;(() => {
const replaceRe = /\s*/g
// 在这里设置设备白名单
const DEVICE_WHITE_LIST = [
'Xiaomi MI 8',
'iPhone9,2',
].map((it) => it.replace(replaceRe, '').toLowerCase())
const originFetch = window.fetch
const recordListUrl = 'record-list'
const filterData = (source) => {
// 数据过滤，返回DEVICE_WHITE_LIST指定的设备的数据
// 详细过程省略
return data
}
// 拦截fetch请求
Object.defineProperty(window, 'fetch', {
configurable: true,
enumerable: true,
get () {
return function (url, options) {
return originFetch(url, options).then((response) => {
// 只处理指定的url
if (url.includes(recordListUrl)) {
if (response.clone) {
const cloneRes = response.clone()
return new Promise((resolve, reject) => {
resolve({
text: () => {
return cloneRes.json().then(json => {
return filterData(JSON.stringify(json))
});
}
})
})
}
}
return response
})
}
}
})
})()
通过下图可以看出，过滤前有37个页面，过滤后只剩3个，瞬间就找到你要调试页面，再也不用从几百个页面中寻找你自己的那个啦！
通过插件一键设置ua，模拟用户登录状态，提高开发效率。
插件使用方式
插件使用结果
团队48+小伙伴也使用起来了
日常c端业务中有很多场景都需要用户
登录后才能正常进行，而开发阶段基本都是通过chrome模拟手机设备来开发，所以往往会涉及到在chrome浏览器中模拟用户登录，其涉及以下三步(这个步骤比较繁琐)。
备注：保持用户的登录态一般是通过cookie，但也有通过header来做，比如我们公司是改写ua来做的
获取ua： 前往公司UA生成平台输入手机号生成ua添加ua： 将ua复制到chrome devtool设置/修改device使用ua： 选择新添加的ua，刷新页面，重新开发调试来看一段对话
隔壁98年刚毕业妹子：
又过期了，谁又把我挤下去了嘛
好的，稍等一会哈，我换个账号测测
好麻烦哎！模拟一个用户信息，要这么多步骤，好烦呀！！！
我，好奇的大叔：
“细心”了解下，她正在做一个h5活动项目，场景复杂，涉及的状态很多，需要用不同的账号来做测试。
模拟一两个用户还好，但是此刻小姐姐测这么多场景，已经模拟了好多个（谁都会烦啊）
公司的登录体系是单点登录，一个好不容易模拟的账号，有可能别人也在用，结果又被顶掉了，得重新生成，我TM
看着她快气哭的小眼神，作为隔壁桌友好的邻居，此刻我心里只想着一件事...！帮她解决这个恼人的问题。
通过上面的介绍您应该可以感觉到我们开发阶段遇到需要频繁切换账号做测试时的烦恼，相对繁琐的ua生成过程导致了它一定是个
费时费力的麻烦事。
有没有什么办法让我们的开发效率得到提升，别浪费在这种事情上呢？一起一步步做起来
需求有哪些
提供一种便捷地模拟ua的方式，助力开发效率提升。
基本诉求：本地开发阶段，希望有更便捷的方式来模拟用户登录多账号： 一个项目需要多个账号，不同项目间的账号可以共享也可以不同指定域: 只有指定的域下才需要模拟ua，不能影响浏览器正常使用过期处理: 账号过期后，可以主动生成，无需手动重新获取如何解决
需求1：结合前面生成ua阶段，我们可以通过某种方式让用户能直接在当前页面生成ua，无需跳出，一键设置省略手动过程
需求2：提供多账号管理功能，能直接选中切换ua
需求3：限定指定域，该ua才生效
需求4：当使用到过期账号时，可一键重新生成即可
为什么是chrome插件
浏览器中发送ajax请求的ua无法直接修改，但是chrome插件可以修改请求的ua（很重要的一点）
chrome插件popup模式可直接在当前页面打开，无需跳出开发页面，减少跳出过程
篇幅原因，这里只做示例级别的简单介绍，如果您希望详细了解chrome插件的编写可以参考这里
接下来我们会以下页面为例，说明用vue如何写出来。
基本功能
底部tab切换区域：viewA、viewB、viewC
中间内容区域：切换viewA、B、C分别展示对应的页面
content部分
借助chrome浏览器可以向网页插入脚本的特性，我们会演示如何插入脚本并且在网页加载的时候弹一个hello world
popup与background通信部分
popup完成用户的主要交互，在viewA页面点击获取自定义的ua信息
修改ajax请求ua部分
会演示如果通过chrome插件修改请求header
1. manifest.json
几乎所有的东西都要在这里进行声明、
权限、资源、页面等等
{
"manifest_version": 2, // 清单文件的版本，这个必须写
"name": "hello vue extend", // 插件的名称，等会我们写的插件名字就叫hello vue extend
"description": "hello vue extend", // 插件描述
"version": "0.0.1", // 插件的版本
// 图标，写一个也行
"icons": {
"48": "img/logo.png"
},
// 浏览器右上角图标设置，browser_action、page_action、app必须三选一
"browser_action": {
"default_icon": "img/logo.png",
"default_title": "hello vue extend",
"default_popup": "popup.html"
},
// 一些常驻的后台JS或后台页面
"background": {
"scripts": [
"js/hot-reload.js",
"js/background.js"
]
},
// 需要直接注入页面的JS
"content_scripts": [{
"matches": [""],
"js": ["js/content.js"],
"run_at": "document_start"
}],
// devtools页面入口，注意只能指向一个HTML文件
"devtools_page": "devcreate.html",
// Chrome40以前的插件配置页写法
"options_page": "options.html",
// 权限申请
"permissions": [
"storage",
"webRequest",
"tabs",
"webRequestBlocking",
""
]
}
2. background script
后台，可以认为是一个常驻的页面，权限很高，几乎可以调用所有的API，可以与popup、content script等通信
3. content script
chrome插件向页面注入脚本的一种形式（js和css都可以）
4. popup
popup是点击browser_action或者page_action图标时打开的一个小窗口网页，焦点离开网页就立即关闭。
比如我们要用vue做的页面。
manifest.json对文件引用的结构基本决定了打包后的文件路径
打包后的路径
// dist目录用来chrome扩展导入
├── dist
│ ├── favicon.ico
│ ├── img
│ │ └── logo.png
│ ├── js
│ │ ├── background.js
│ │ ├── chunk-vendors.js
│ │ ├── content.js
│ │ ├── hot-reload.js
│ │ └── popup.js
│ ├── manifest.json
│ └── popup.html
源码目录
├── README.md
├── babel.config.js
├── package-lock.json
├── package.json
├── public
│ ├── favicon.ico
│ ├── index.html
│ └── js
│ └── hot-reload.js
├── src
│ ├── assets
│ │ ├── 01.png
│ │ ├── disabled.png
│ │ └── logo.png
│ ├── background
│ │ └── background.js
│ ├── content
│ │ └── content.js
│ ├── manifest.json
│ ├── popup
│ │ ├── App.vue
│ │ ├── main.js
│ │ ├── router.js
│ │ └── views
│ │ ├── viewA.vue
│ │ ├── viewB.vue
│ │ └── viewC.vue
│ └── utils
│ ├── base.js
│ ├── fixCaton.js
│ └── storage.js
└── vue.config.js
修改vue.config.js
主需要稍微改造变成可以多页打包，注意输出的目录结构就可以了
const CopyWebpackPlugin = require('copy-webpack-plugin')
const path = require('path')
// 这里考虑可以添加多页
const pagesObj = {}
const chromeName = ['popup']
const plugins = [
{
from: path.resolve('src/manifest.json'),
to: `${path.resolve('dist')}/manifest.json`
},
{
from: path.resolve('src/assets/logo.png'),
to: `${path.resolve('dist')}/img/logo.png`
},
{
from: path.resolve('src/background/background.js'),
to: `${path.resolve('dist')}/js/background.js`
},
{
from: path.resolve('src/content/content.js'),
to: `${path.resolve('dist')}/js/content.js`
},
]
chromeName.forEach(name => {
pagesObj[name] = {
css: {
loaderOptions: {
less: {
modifyVars: {},
javascriptEnabled: true
}
}
},
entry: `src/${name}/main.js`,
filename: `${name}.html`
}
})
const vueConfig = {
lintOnSave:false, //关闭eslint检查
pages: pagesObj,
configureWebpack: {
entry: {},
output: {
filename: 'js/[name].js'
},
plugins: [new CopyWebpackPlugin(plugins)]
},
filenameHashing: false,
productionSourceMap: false
}
module.exports = vueConfig
我们希望修改插件源代码进行打包之后，chrome插件对应的页面能主动更新。为什么叫热刷新而不是热更新呢？因为它其实是全局刷新页面，并不会保存状态。
这里推荐一个github上的解决方案crx-hotreload
文件目录结构
├── popup
│ ├── App.vue
│ ├── main.js
│ ├── router.js
│ └── views
│ ├── viewA.vue
│ ├── viewB.vue
│ └── viewC.vue
main.js
import Vue from 'vue'
import App from './App.vue'
import router from './router'
Vue.config.productionTip = false
new Vue({
router,
render: h => h(App)
}).$mount('#app')
router.js
import Vue from 'vue'
import Router from 'vue-router'
import ViewA from './views/viewA.vue'
import ViewB from './views/viewB.vue'
import ViewC from './views/viewC.vue'
Vue.use(Router)
export default new Router({
mode: 'history',
base: process.env.BASE_URL,
routes: [
{
path: '/',
name: 'home',
redirect: '/view/a'
},
{
path: '/view/a',
name: 'viewA',
component: ViewA,
},
{
path: '/view/b',
name: 'viewB',
component: ViewB,
},
{
path: '/view/c',
name: 'viewC',
component: ViewC,
},
]
})
App.vue
viewA、viewB、viewC
三个页面基本长得是一样的，只有背景色和文案内容不一样，这里我就只贴viewA的代码了。
需要注意的是这里会演示popup与background,通过sendMessage方法获取background后台数据
background.js
const customUa = 'hello world ua'
// 请求发送前拦截
const onBeforeSendCallback = (details) => {
for (var i = 0; i < details.requestHeaders.length; ++i) {
if (details.requestHeaders[i].name === 'User-Agent') {
details.requestHeaders.splice(i, 1);
break;
}
}
// 修改请求UA为hello world ua
details.requestHeaders.push({
name: 'User-Agent',
value: customUa
});
return { requestHeaders: details.requestHeaders };
}
// 前面的sendMessage获取getCustomUserAgent，会被这里监听
const onRuntimeMessageListener = () => {
chrome.runtime.onMessage.addListener(function (msg, sender, callback) {
if (msg.type === 'getCustomUserAgent') {
callback({
customUa
});
}
});
}
const init = () => {
onRuntimeMessageListener()
onBeforeSendHeadersListener()
}
init()
content.js
演示如何往网页中插入代码
function setScript({ code = '', needRemove = true } = params) {
let textNode = document.createTextNode(code)
let script = document.createElement('script')
script.appendChild(textNode)
script.remove()
let parentNode = document.head || document.documentElement
parentNode.appendChild(script)
needRemove && parentNode.removeChild(script)
}
setScript({
code: `alert ('hello world')`,
})
大体上和小例子差不都，只是功能相对复杂一些，会涉及到
数据本地存储chrome.storage.sync.get|set、chrome.tabs.query等API
popup与background通信、content与background通信
拦截请求修改UA
其他的大体就是常规的vue代码编写啦！
这里就不贴详细的代码实现了。
为什么会扯到这个话题，最初是源于听 y.qq.com/ QQ音乐，
这里我又联想到了商城的购物车的场景，体验确实有提升。
刚开始，我怀疑的是Web Socket作妖，结果通过分析网络请求和看源码，并没有。 最后发现是localStore的storage事件作妖，哈哈。
回归正题，其实在一般正常的知识储备的情况下，我们会想到哪些方案呢？
先抛开如下方式：
opener多页面通讯的demo, 为了正常运行，请用最新的chrome浏览器打开。
demo的源码地址
这个没有太多解释，WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。当然是有代价的，需要服务器来支持。
js语言，现在比较成熟稳定当然是 socket.io和ws. 也还有轻量级的ClusterWS。
你可以在The WebSocket API (WebSockets)
看到更多的关于Web Socket的信息。
定时器：setTimeout/setInterval/requestAnimationFrame
客户端存储： cookie/localStorage/sessionStorage/indexDB/chrome的FileSystem
定时器没啥好说的，关于客户端存储。
Cross-document messaging 这玩意的支持率98.9%。 好像还能发送文件，哈哈，强大。
不过仔细一看 window.postMessage()，就注定了你首先得拿到window这个对象。 也注定他使用的限制， 两个窗体必须建立起联系。 常见建立联系的方式：
提到上面的window.open, open后你能获得被打开窗体的句柄，当然也可以直接操作窗体了。
到这里，我觉得一般的前端人员能想到的比较正经的方案应该是上面三种啦。
当然，我们接下来说说可能不是那么常见的另外三种方式。
Page 1
localStorage.setItem('message',JSON.stringify({
message: '消息'，
from: 'Page 1',
date: Date.now()
}))
Page 2
window.addEventListener("storage", function(e) {
console.log(e.key, e.newValue, e.oldValue)
});
如上， Page 1设置消息， Page 2注册storage事件，就能监听到数据的变化啦。
上面的e就是StorageEvent,有下面特有的属性（都是只读）：
这玩意主要就是给多窗口用的，Service Woker也可以使用。 firefox,chrome, Opera均支持，有时候真的是很讨厌Safari，浏览器支持77%左右。
使用起来也很简单, 创建BroadcastChannel, 然后监听事件。 只需要注意一点，渠道名称一致就可以。
Page 1
var channel = new BroadcastChannel("channel-BroadcastChannel");
channel.postMessage('Hello, BroadcastChannel!')
Page 2
var channel = new BroadcastChannel("channel-BroadcastChannel");
channel.addEventListener("message", function(ev) {
console.log(ev.data)
});
这是Web Worker之后出来的共享的Worker，不通页面可以共享这个Worker。
MDN这里给了一个比较完整的例子simple-shared-worker。
这里来个插曲，Safari有几个版本支持这个特性，后来又不支持啦，还是你Safari，真是6。
虽然，SharedWorker本身的资源是共享的，但是要想达到多页面的互相通讯，那还是要做一些手脚的。
先看看MDN给出的例子的ShareWoker本身的代码：
onconnect = function(e) {
var port = e.ports[0];
port.onmessage = function(e) {
var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
port.postMessage(workerResult);
}
}
上面的代码其实很简单，port是关键，这个port就是和各个页面通讯的主宰者，既然SharedWorker资源是共享的，那好办，把port存起来就是啦。
看一下，如下改造的代码：
SharedWorker就成为一个纯粹的订阅发布者啦，哈哈。
var portList = [];
onconnect = function(e) {
var port = e.ports[0];
ensurePorts(port);
port.onmessage = function(e) {
var data = e.data;
disptach(port, data);
};
port.start();
};
function ensurePorts(port) {
if (portList.indexOf(port) < 0) {
portList.push(port);
}
}
function disptach(selfPort, data) {
portList
.filter(port => selfPort !== port)
.forEach(port => port.postMessage(data));
}
Channel Messaging API的 MessageChannel 接口允许我们创建一个新的消息通道，并通过它的两个MessagePort 属性发送数据。
其需要先通过 postMessage先建立联系。
MessageChannel的基本使用：
var channel = new MessageChannel();
var para = document.querySelector('p');
var ifr = document.querySelector('iframe');
var otherWindow = ifr.contentWindow;
ifr.addEventListener("load", iframeLoaded, false);
function iframeLoaded() {
otherWindow.postMessage('Hello from the main page!', '*', [channel.port2]);
}
channel.port1.onmessage = handleMessage;
function handleMessage(e) {
para.innerHTML = e.data;
}
至于在线的例子，MDN官方有一个版本 MessageChannel 通讯
在检测到更新后提示用户，让用户选择更新。
设置autoDownload参数为false，让应用检测到更新不自动下载，改成手动下载更新包。
通过在钩子update-available中，加入对话框提示用户，让用户选择。
response为0用户选择确定，触发downloadUpdate方法下载应用更新包进行后续更新操作。否则，不下载更新包。
如果我们不配置autoDownload为false，那么问题来了：在弹出对话框的同时，用户还来不及选择，应用自动下载并且更新完成，做不到阻塞。
本文首发于公众号「全栈大佬的修炼之路」，欢迎关注。
重要代码如下：
autoUpdater.autoDownload = false
在update-available钩子中弹出对话框
autoUpdater.on('update-available', (ev, info) => {
// // 不可逆过程
const options = {
type: 'info',
buttons: ['确定', '取消'],
title: '更新提示',
// ${info.version} Cannot read property 'version' of undefined
message: '发现有新版本，是否更新？',
cancelId: 1
}
dialog.showMessageBox(options).then(res => {
if (res.response === 0) {
autoUpdater.downloadUpdate()
logger.info('下载更新包成功')
sendStatusToWindow('下载更新包成功');
} else {
return;
}
})
})
在更新下载完后提示用户，让用户选择更新。
先配置参数autoInstallOnAppQuit为false，阻止应用在检测到更新包后自动更新。
在钩子update-downloaded中加入对话框提示用户，让用户选择。
response为0用户选择确定，更新应用。否则，当前应用不更新。
如果我们不配置autoInstallOnAppQuit为false，那么问题是：虽然第一次应用不更新，但是第二次打开应用，应用马上关闭，还没让我们看到主界面，应用暗自更新，重点是更新完后不重启应用。
重要代码如下：
// 表示下载包不自动更新
autoUpdater.autoInstallOnAppQuit = false
在update-downloaded钩子中弹出对话框
autoUpdater.on('update-downloaded', (ev, releaseNotes, releaseName) => {
logger.info('下载完成，更新开始')
sendStatusToWindow('下载完成，更新开始');
// Wait 5 seconds, then quit and install
// In your application, you don't need to wait 5 seconds.
// You could call autoUpdater.quitAndInstall(); immediately
const options = {
type: 'info',
buttons: ['确定', '取消'],
title: '应用更新',
message: process.platform === 'win32' ? releaseNotes : releaseName,
detail: '发现有新版本，是否更新？'
}
dialog.showMessageBox(options).then(returnVal => {
if (returnVal.response === 0) {
logger.info('开始更新')
setTimeout(() => {
autoUpdater.quitAndInstall()
}, 5000);
} else {
logger.info('取消更新')
return
}
})
});
未打包目录位于： electron-builder/packages/electron-updater/src/AppUpdater.ts中。 打包后在electron-updater\out\AppUpdater.d.ts中
export declare abstract class AppUpdater extends EventEmitter {
/**
* 当被发现有更新时，是否要自动下载更新
* 场景：可以适用于electron检查更新包提示，用户操作是否需要更新
*/
autoDownload: boolean;
/**
* 在app.quit()后，是否自动将下载下载的更新包更新
* 场景：可以适用于electron下载完更新包提示，用户操作是否需要更新。在第二次打开应用，应用不会自动更新。
*/
autoInstallOnAppQuit: boolean;
}
/**
* 检测是否需要更新
*/
checkForUpdates(): Promise < UpdateCheckResult > {
let checkForUpdatesPromise = this.checkForUpdatesPromise
// 正在检测更新跳过
if (checkForUpdatesPromise != null) {
this._logger.info("Checking for update (already in progress)")
return checkForUpdatesPromise
}
const nullizePromise = () => this.checkForUpdatesPromise = null
// 开始检测更新
this._logger.info("Checking for update")
checkForUpdatesPromise = this.doCheckForUpdates()
.then(it => {
nullizePromise()
return it
})
.catch(e => {
nullizePromise()
this.emit("error", e, `Cannot check for updates: ${(e.stack || e).toString()}`)
throw e
})
this.checkForUpdatesPromise = checkForUpdatesPromise
return checkForUpdatesPromise
}
// 检测更新具体函数
private async doCheckForUpdates(): Promise < UpdateCheckResult > {
// 触发 checking-for-update 钩子
this.emit("checking-for-update")
// 取更新信息
const result = await this.getUpdateInfoAndProvider()
const updateInfo = result.info
// 判断更新信息是否有效
if (!await this.isUpdateAvailable(updateInfo)) {
this._logger.info(`Update for version ${this.currentVersion} is not available (latest version: ${updateInfo.version}, downgrade is ${this.allowDowngrade ? "allowed" : "disallowed"}).`)
this.emit("update-not-available", updateInfo)
return {
versionInfo: updateInfo,
updateInfo,
}
}
this.updateInfoAndProvider = result
this.onUpdateAvailable(updateInfo)
const cancellationToken = new CancellationToken()
//noinspection ES6MissingAwait
// 如果设置autoDownload为true,则开始自动下载更新包,否则不下载
return {
versionInfo: updateInfo,
updateInfo,
cancellationToken,
downloadPromise: this.autoDownload ? this.downloadUpdate(cancellationToken) : null
}
}
如果需要配置updater中的其他参数达到某种功能，我们可以仔细查看其中的配置项。
export abstract class AppUpdater extends EventEmitter {
/**
* 当被发现有更新时，是否要自动下载更新
* 场景：可以适用于electron检查更新包提示，用户操作是否需要更新
*/
autoDownload: boolean;
/**
* 在app.quit()后，是否自动将下载下载的更新包更新
* 场景：可以适用于electron下载完更新包提示，用户操作是否需要更新。在第二次打开应用，应用不会自动更新。
*/
autoInstallOnAppQuit: boolean;
/**
* GitHub提供者。
是否允许升级到预发布版本。
如果应用程序版本包含预发布组件，默认为“true”。0.12.1-alpha.1，这里alpha是预发布组件)，否则“false”。
allowDowngrade设置为true，则应用允许降级。
*/
allowPrerelease: boolean;
/**
* GitHub提供者。
获取所有发布说明(从当前版本到最新版本)，而不仅仅是最新版本。
@default false
*/
fullChangelog: boolean;
/**
*是否允许版本降级(当用户从测试通道想要回到稳定通道时)。
*仅当渠道不同时考虑(根据语义版本控制的预发布版本组件)。
* @default false
*/
allowDowngrade: boolean;
/**
* 当前应用的版本
*/
readonly currentVersion: SemVer;
private _channel;
protected downloadedUpdateHelper: DownloadedUpdateHelper | null;
/**
* 获取更新通道。
不适用于GitHub。
从更新配置不返回“channel”，仅在之前设置的情况下。
*/
get channel(): string | null;
/**
* 设置更新通道。
不适用于GitHub。
覆盖更新配置中的“channel”。
“allowDowngrade”将自动设置为“true”。
如果这个行为不适合你，明确后简单设置“allowDowngrade”。
*/
set channel(value: string | null);
/**
* 请求头
*/
requestHeaders: OutgoingHttpHeaders | null;
protected _logger: Logger;
get netSession(): Session;
/**
* The logger. You can pass [electron-log](https://github.com/megahertz/electron-log), [winston](https://github.com/winstonjs/winston) or another logger with the following interface: `{ info(), warn(), error() }`.
* Set it to `null` if you would like to disable a logging feature.
* 日志，类型有：info、warn、error
*/
get logger(): Logger | null;
set logger(value: Logger | null);
/**
* For type safety you can use signals, e.g.
为了类型安全，可以使用signals。
例如：
`autoUpdater.signals.updateDownloaded(() => {})` instead of `autoUpdater.on('update-available', () => {})`
*/
readonly signals: UpdaterSignal;
private _appUpdateConfigPath;
/**
* test only
* @private
*/
set updateConfigPath(value: string | null);
private clientPromise;
protected readonly stagingUserIdPromise: Lazy<string>;
private checkForUpdatesPromise;
protected readonly app: AppAdapter;
protected updateInfoAndProvider: UpdateInfoAndProvider | null;
protected constructor(
options: AllPublishOptions | null | undefined,
app?: AppAdapter
);
/**
* 获取当前更新的url
*/
getFeedURL(): string | null | undefined;
/**
* Configure update provider. If value is `string`, [GenericServerOptions](/configuration/publish#genericserveroptions) will be set with value as `url`.
* @param options If you want to override configuration in the `app-update.yml`.
*
* 配置更新提供者。通过提供url
* @param options 如果你想覆盖' app-update.yml '中的配置。
*/
setFeedURL(options: PublishConfiguration | AllPublishOptions | string): void;
/**
* 检查服务其是否有更新
*/
checkForUpdates(): Promise<UpdateCheckResult>;
isUpdaterActive(): boolean;
/**
*
* @param downloadNotification 询问服务器是否有更新，下载并通知更新是否可用
*/
checkForUpdatesAndNotify(
downloadNotification?: DownloadNotification
): Promise<UpdateCheckResult | null>;
private static formatDownloadNotification;
private isStagingMatch;
private computeFinalHeaders;
private isUpdateAvailable;
protected getUpdateInfoAndProvider(): Promise<UpdateInfoAndProvider>;
private createProviderRuntimeOptions;
private doCheckForUpdates;
protected onUpdateAvailable(updateInfo: UpdateInfo): void;
/**
*
* 作用：开始下载更新包
*
* 如果将`autoDownload`选项设置为false，就可以使用这个方法。
*
* @returns {Promise<string>} Path to downloaded file.
*/
downloadUpdate(cancellationToken?: CancellationToken): Promise<any>;
protected dispatchError(e: Error): void;
protected dispatchUpdateDownloaded(event: UpdateDownloadedEvent): void;
protected abstract doDownloadUpdate(
downloadUpdateOptions: DownloadUpdateOptions
): Promise<Array<string>>;
/**
* 作用：下载后重新启动应用程序并安装更新。
*只有在' update- downloads '被触发后才会调用。
*
* 注意：如果在update-downloaded钩子中，让用户选择是否更新应用，选择不更新，那就是没有执行autoUpdater.quitAndInstall()方法。
* 虽然应用没有更新，但是当第二次打开应用的时候，应用检测到本地有更新包，他就会直接更新，最后不会重启更新后的应用。
*
* 为了解决这个问题，需要设置`autoInstallOnAppQuit`为false。关闭应用自动更新。
*
* **Note:** ' autoUpdater.quitAndInstall() '将首先关闭所有的应用程序窗口，然后只在' app '上发出' before-quit '事件。
*这与正常的退出事件序列不同。
*
* @param isSilent 仅Windows以静默模式运行安装程序。默认为false。
* @param isForceRunAfter 即使无提示安装也可以在完成后运行应用程序。不适用于macOS。忽略是否isSilent设置为false。
*/
abstract quitAndInstall(isSilent?: boolean, isForceRunAfter?: boolean): void;
private loadUpdateConfig;
private computeRequestHeaders;
private getOrCreateStagingUserId;
private getOrCreateDownloadHelper;
protected executeDownload(
taskOptions: DownloadExecutorTask
): Promise<Array<string>>;
}
最后，希望大家一定要点赞三连。
链接：https://juejin.cn/post/7001682043104919565
一个开放、互助、协作、创意的社区
