> For the complete documentation index, see [llms.txt](https://www.lanlanx.com/openharmony/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.lanlanx.com/openharmony/xu-lun.md).

# 绪论

***

### description: >- 个人认为如同魔幻一样的openharmony开启。回想起来，openharmony能够一步步做到现在的程度，真的太不容易了，摸索，困难，弯路太多了，我们如此，其他子系统的小伙伴也是一样。

## 绪论

### 初期：

组建团队的时候还不知道要做啥，你敢信么？

当时有两拨人，一拨人做子系统，一拨人做应用。

最终做子系统的人没做最开始计划的子系统，做应用的人和应用也没什么大关系。

“不是做多模输入么？”，我问。

项目经理："已经不是了，我们现在要做telephony。"

“另外一拨人呢”，我再问。

“他们啊，他们也要做别的。”

### 前期：

过了不久，自己终于看到了gitee官网上面发布的1.0版本的代码。

“这是啥？这不就是一个简单实时操作系统么？”，当时脑中的问号一大堆，完全是懵逼的状态，看着当时整个openharmony完全处于一个L0的时代的代码。

“这能做成一个可以和IOS\&AOSP相抗衡的系统么？”这才是当时自己最大问号？而且也有点感觉这个东西的难度之大，可能要远远超出自己最开始的想象。

最让人尴尬的是，再后来拿到了一份aosp基线+hos文件夹的代码，外界的批评原来是真的，鸿蒙当时是真的啥好薄弱，确实还是处于套壳的状态。

再后来又更新了一份代码变成了hos基线+aosp文件夹，突然明白，策略就是慢慢掏空，最终移除，慢慢完善，保证生态的连续性，那个时候感觉这个路线肯定要走定了，一定要一步步的走下去，直到最终胜利。

### 架构期：

![](/files/h7sYFMNfPKYddFAkoHCA)

现在回想起来才知道，架构的重要性，这个是openharmony的总架构，记得从我接触openharmony开始，这个架构图应该就没有几乎变过，一路演进都是依照这个来指导前行。

从未经历过架构阶段需要做什么细的，一个子系统，架构的设计就需要几个月之久，从大架构孵化出来子系统架构设计，再到概要设计，功能设计，接口设计，测试设计。细致程度，远超之前经历过的所有项目。

经历过这个阶段才知道，原来编码真的不是最重要的，架构到这种程度，真就谁来都能来编码。

后面会单开一个章节，讲一下自己的对于架构的一点点收获。

分析阶段的时候，操作系统的很多细节其实大多都是还处于使用阶段，能明白一些经常接触到的子系统大致的运行状态，从0到1原来真的很难，居然需要去啃标准化规约组织的全英文规约文档，大家有空可以了解一下3gpp组织的文档是怎么一种庞大复杂，其中一个文档内容量就可能有将近30M大小，而这样的文档可能有几千份。

### 中期：

终于发布第一版了。内心中还是很高兴的，因为漫长的努力终于迎来了一次上代码仓的时间点。

“大家紧急上线，来开会”。

内心疑惑，都上线了，怎么又开会干啥？

“下线吧，仓库暂时下线吧，法务过不了。”

法务？发个版本和法务有啥关系，这么多年都几乎没听说过。

后来才知道，代码扫描，发现引用了一部分网络上能够相似的代码。？？？，这也不行，说好的程序员ctrl+c、ctrl+v大法呢。

就这么下线了，迎来好长时间代码整改的时间。

中间不仅仅是这个一个问题，还有整改量最大编码规范，？？？，写了这么多年的代码，居然还得考虑这么严密的代码规范，当时一起奋战的同学们，可被这些给折腾的不轻。

### 后期：

东西几乎弄好了，还是不行，只能证明能用了，但是没地方用啊。那个时候才知道生态原来这么重要。

最让人恼火的是，因为制裁和打压，去和硬件、芯片厂商谈能否适配的时候，大多的时候都是打哈哈哈，真的还是蛮心酸的。

这个时期有一段时间，在一个pad的平台上面，拉了海思的兄弟萌，海思自有的芯片，modem相关的很快就调通了，出了一个版本。但是还有很多问题，啥问题呢？其他外围的芯片的适配很多都很难推动。

### 后记：

千帆计划后，自己还是很开心看到这么多的APP，生态慢慢的丰富起来了，中国自有的openharmony，加油。