1. Algorithm: 每周至少做一个 LeetCode 的算法题

题目

54. Spiral Matrix



Given a matrix of m x n elements (m rows, n columns), return all elements of the matrix in spiral order.



Example 1:

Input:
[
 [ 1, 2, 3 ],
 [ 4, 5, 6 ],
 [ 7, 8, 9 ]
]
Output: [1,2,3,6,9,8,7,4,5]

Example 2:

Input:
[
  [1, 2, 3, 4],
  [5, 6, 7, 8],
  [9,10,11,12]
]
Output: [1,2,3,4,8,12,11,10,9,5,6,7]



解决

按照顺时针遍历螺旋矩阵，只要定义好上下左右四条边，按照顺序遍历就好。

注意：需要避免重复填值的情况，条件要同时判断left <= right && top <= down.



class Solution {
    public List<Integer> spiralOrder(int[][] matrix) {
        List<Integer> list = new ArrayList<>();
    // check edge
    if (matrix == null || matrix.length == 0) {
      return list;
    }
    int top = 0;
    int down = matrix.length - 1;
    int left = 0;
    int right = matrix[0].length - 1;
    while (top <= down && left <= right) {
      // top
      for (int i = left; i <= right  && top <= down; i++) {
        list.add(matrix[top][i]);
      }
      top++;
      // right
      for (int i = top; i <= down && left <= right; i++) {
        list.add(matrix[i][right]);
      }
      right--;
      // down
      for (int i = right; i >= left && top <= down; i--) {
        list.add(matrix[down][i]);
      }
      down--;
      // left
      for (int i = down; i >= top && left <= right; i--) {
        list.add(matrix[i][left]);
      }
      left++;
    }
    return list;
    }
}



2. Review: 阅读并点评至少一篇英文技术文章

How I Scaled a Software System’s Performance By 35,000%

https://medium.com/swlh/how-i-scaled-a-software-systems-performance-by-35-000-6dacd63732df



这篇文章将高并发优化的，里面从监控数据入手，里面分析CPU load， 内存，缓存等情况。里面提到缓存为王。这篇文章比较匆忙浏览，里面内容确实很好。



3. Tips: 学习至少一个技术技巧

笔者写的博客：



React Native之原理浅析, iOS原理分析与实践解析、Android原理分析与实践解析



一、JavaScriptCore

>讲React Native之前，了解JavaScriptCore会有帮助，也是必要的。React Native的核心驱动力就来自于JS Engine. 你写的所有JS和JSX代码都会被JS Engine来执行, 没有JS Engine的参与，你是无法享受ReactJS给原生应用开发带来的便利的。在iOS上，默认的就是JavaScriptCore， iOS 7之后的设备都支持. iOS 不允许用自己的JS Engine. JavaScriptCore来自于WebKit, 所以，安卓上默认也是用JavaScriptCore.<br>

>你深入了解React Native的第一站应该是 JavaScriptCore



JavaScriptCore在iOS平台上给React Native提供的接口也仅限于那几个接口，你弄明白了JavaScriptCore那几个接口, React Native 剩下的魔法秘密都可以顺藤摸瓜来分析了。

接下来要讲解的就是Facebook围绕这几个接口以及用一个React来颠覆整个native开发所做的精妙设计和封装.



二、浏览器工作原理

浏览器通过Dom Render来渲染所有的元素.

浏览器有一整套的UI控件，样式和功能都是按照html标准实现的

浏览器能读懂html和css。

html告诉浏览器绘制什么控件(html tag)，css告诉浏览器每个类型的控件(html tag)具体长什么样。

浏览器的主要作用就是通过解析html来形成dom树，然后通过css来点缀和装饰树上的每一个节点



UI的描述和呈现分离开了

1. html文本描述了页面应该有哪些功能，css告诉浏览器该长什么样。

2. 浏览器引擎通过解析html和css，翻译成一些列的预定义UI控件，

3. 然后UI控件去调用操作系统绘图指令去绘制图像展现给用户。

4. Javascript可有可无，主要用于html里面一些用户事件响应，DOM操作、异步网络请求和一些简单的计算



在react native 里面，1和2是不变的，也是用html语言描述页面有哪些功能，然后stylesheet告诉浏览器引擎每个控件应该长什么样。并且和浏览器用的是同一个引擎. <br>

在步骤3里面UI控件不再是浏览器内置的控件，而是react native自己实现的一套UI控件（两套，android一套，ios一套），这个切换是在MessageQueque中进行的，并且还可以发现，他们tag也是不一样的



Javascript在react native里面非常重要



• 它负责管理UI component的生命周期，管理Virtual DOM

• 所有业务逻辑都是用javascript来实现或者衔接

• 调用原生的代码来操纵原生组件。

• Javascript本身是无绘图能力的，都是通过给原生组件发指令来完成



三、React Native 架构



参考

http://blog.poetries.top/2019/10/02/rn-yuanli/



https://zhuanlan.zhihu.com/p/41920417



https://juejin.im/post/5a6460f8f265da3e4f0a446d



https://cloud.tencent.com/developer/article/1037539



4. Share: 分享一篇有观点和思考的技术文章

笔者写的博客链接



极客大学架构师训练营 组件设计原则 安全架构 防火墙ModSecurity 第21课 听课总结

说明

讲师：李智慧



组件设计原则

在没有编程语言的时候就已经有了软件组件。

软件的复杂度和它的规模成指数关系

一个复杂度为 100 的软件系统，如果能拆分成两个互不相关、同等规模的子系统，那么每个子系统的复杂度应该是25，而不是50.软件开发这个行业很久之前就形成了一个共识，应该将复杂的软件系统进行拆分，拆成多个更低复杂度的子系统，子系统还可以继续拆分成更小粒度的组件。也就是说，软件需要进行模块化、组件化设计。



组件内聚原则

组件内聚原则主要讨论哪些类应该聚合在同一个组件中，以便组件既能提供相对完整的功能，又不至于太过庞大。



• 复用发布等同原则；

• 共同封闭原则；

• 共同复用原则。



复用发布等同原则

复用发布等同原则是说，软件复用的最小粒度应该等同于其发布的最小粒度。也就是说，如果你希望别人以怎样的粒度复用你的软件，你就应该以怎样的粒度发布你的软件。这其实就是组件的定义了，组件是软件复用和发布的最小粒度软件单元。这个粒度既是复用的粒度，也是发布的粒度。



版本号约定建议：

• 版本号格式：主版本号.次版本号.修订号。比如 1.3.12，在这个版本号中，主版本号是1， 次版本号是3， 修订号是 12.

• 主版本号升级，表示组件发生了不向前兼容的重大修订；

• 次版本号升级，表示组件进行了重要的功能修订或者 bug 修复，但是组件是向前兼容的；

• 修订号升级，表示组件进行了不重要的功能修订或者 bug 修复。



共同封闭原则

共同封闭原则是说，我们应该将那些会同时修改，并且为了相同目的而修改的类放到同一个组件中。而将不会同时修改，并且不会为了相同目的而修改的类放到不同的组件中。



组件的目的虽然是为了复用，然而开发中常常引发问题的，恰恰在于组件本身的可维护性。如果组件在自己的生命周期中必须经历各种变更，那么最好不要涉及其它组件，相关的变更都在同一个组件中。这样，当变更发生的时候，只需要重新发布这个组件就可以了，而不是一大堆组件都受到牵连。



共同复用原则

共同复用原则是说，不要强迫一个组件的用户依赖他们不需要的东西。



这个原则一方面是说，我们应该互相依赖，共同复用的类放在一个组件中。比如说，一个数据结构容器组件，提供数组、Hash 表等各种数据结构容器，那么对数据结构遍历的类、排序的类也应该放在这个组件中，以使这个组件中的类共同对外提供服务。



另一方面，这个原则也说明，如果不是被共同依赖的类，就不应该放在一个组件中。如果不被依赖的类发生变更，就会引起组件变更，进而引起使用组件的程序发生变更。这样就会导致组件的使用者产生不必要的困扰，甚至讨厌使用这样的组件，也造成了组件复用的困难。

组件耦合原则 （强原则，架构师必须要守住）

组件内聚原则讨论的是组件应该包含哪些功能和类，而组件耦合原则讨论组件之间的耦合关系应该如何设计。



• 无循环依赖原则；

• 稳定依赖原则；

• 稳定抽象原则。

无循环依赖原则

无循环依赖原则说，组件依赖关系中不应该出现环。如果组件 A 依赖组件 B，组件 B 依赖组件 C，组件 C 又依赖组件 A，就形成了循环依赖。



很多时候，循环依赖是在组件的变更过程中逐渐形成的，组件 A 版本 1.0 依赖组件 B 版本 1.0，后来组件 B 升级到 1.1， 升级的某个功能依赖组件 A 的 1.0 版本，于是形成了循环依赖。如果组件设计的边界不清晰，组件开发设计缺乏评审，开发者只关注自己开发的组件，整个项目对组件依赖管理没有统一的规则，很有可能出现循环依赖。



稳定依赖原则

稳定依赖原则是说，组件依赖关系必须指向更稳定的方向。较少变更的组件是稳定的，也就是说，经常变更的组件是不稳定的。根据稳定依赖原则，不稳定的组件应该依赖稳定的组件，而不是反过来。



反过来说，如果一个组件被更多组件依赖，那么它需要相对是稳定的，因为想要变更一个被很多组件依赖的组件，本身就是一件困难的事。相对应的，如果一个组件依赖了很多的组件，那么它相对也是不稳定的，因为它依赖的任何组件变更，都可能导致自己的变更。



稳定依赖原则通俗地说就是，组件不应该依赖一个比自己还不稳定的组件。



稳定抽象原则

稳定抽象原则是说，一个组件的抽象化程度应该与其稳定性程度一致。也就是说，一个稳定的组件应该是抽象的，而不稳定的组件应该是具体的。



这个原则对具体开发的指导意义就是：如果你设计的组件是具体的、不稳定的，那么可以为这个组件对外提供服务的类设计一组接口，并把这组接口封装在一个专门的组件中，那么这个组件相对就比较抽象、稳定。



Java 中的 JDBC 就是这样一个例子，我们开发应用程序的时候只需要使用 JDBC 的接口编程就可以了。而发布应用的时候，我们制定具体的实现组件，可以是 MySQL 实现的 JDBC 组件，也可以是 Oracle 实现的 JDBC 组件。



组件的边界与依赖关系，不仅仅是技术问题

组件的边界与依赖关系划分，不仅需要考虑技术问题，也要考虑业务场景问题。易变与稳定，依赖与被依赖，都需要放在业务场景中去考察。有的时候，甚至不只是技术业务的问题，还需要考虑人的问题，在一个复杂的组织中，组件的依赖与设计需要考虑人的因素。如果组件的功能划分涉及部门的职责边界，甚至会和公司内的政治关联起来。